Зависание учета

[anlex]

Nav 2009 R2

Были ли доработки, исправления, связанные с Товар Применением?

Проблема в том, что по некоторым операциям, которые имеют сложную историю применения при учете происходит реальное зависание...


(сложная история - это продажа из партий, которые пришли из транзитных перемещений, те в свою очередь тоже из ТП и т.д. - много промежуточных перемещений м/д складами)

[RedFox]

У меня такая же ситуация бывает.

Обычно такое, когда "накрутили с товарными перемещениями" и я правил вручную. Но при этом выдавало сообщение.
Конечно это не дельный совет, но если это у Вас на НАСе крутится, то попробуйте найти ошибку запустив задание вручную с фильтром по этому товару

[anlex]

Возможно (скорее всего...) проблема в том, что в транзитных перемещениях операция на транзитном складе объединяется по партии. т.е. происходит "срастание" ветки дерева партии... т.е. при отгрузке со склада источника несколько партий (несколько операций) - на транзите одна операция (срастание веток) - на складе получателе опять несколько партий - операции получаются не одна-к-одной и системе нужно искать партии по дереву... с учетом кол-ва....

сумбурно, но вроде так....

[prefreitor]

Что то странное, не должно оно так быть хоть какая там цепочка операций будет. Может у вас автоматическая коррекция включена или/и автоматический финучет? Вообще длина цепочки операций скорее должно коррекцию себестоимости тормозить, что с ней? Если все нормально, то тогда надо посмотреть в "ручном" режиме на то что в момент применения происходит, может что-то доделывали и неоптимальный ключ применили...

[anlex]

Цитата:

Сообщение от prefreitor

Что то странное, не должно оно так быть хоть какая там цепочка операций будет. Может у вас автоматическая коррекция включена или/и автоматический финучет? Вообще длина цепочки операций скорее должно коррекцию себестоимости тормозить, что с ней? Если все нормально, то тогда надо посмотреть в "ручном" режиме на то что в момент применения происходит, может что-то доделывали и неоптимальный ключ применили...

мысль понятна. нет у нас коррекция себестоимости не тормозит - скорее всего из-за того, что она считается по-средней.

[Kalex63]

Цитата:

Сообщение от anlex

Цитата:

Сообщение от prefreitor

Что то странное, не должно оно так быть хоть какая там цепочка операций будет. Может у вас автоматическая коррекция включена или/и автоматический финучет? Вообще длина цепочки операций скорее должно коррекцию себестоимости тормозить, что с ней? Если все нормально, то тогда надо посмотреть в "ручном" режиме на то что в момент применения происходит, может что-то доделывали и неоптимальный ключ применили...

мысль понятна. нет у нас коррекция себестоимости не тормозит - скорее всего из-за того, что она считается по-средней.

Согласен, что длина цепочки ни при чём. При учете расходных операций производиться подбор открытых приходных операций по тому же складу. Если выключены и автоматическая коррекция себестоимости и фин. учет товарных операций, то возможно тормозит именно этот подбор операций (функция ApplyItemLedgEntry в 22-м кодеюните).