Закрытие склада. Сумма коррекции

[plumbum]

На проекте, который сдали год назад всплыл "актуальный нюанс" :

Опишу вкратце ситуацию: AX4 SP2, фирма имеет центральный склад и сеть магазинов, занимается розничной торговлей и т.д. Используются 2 складские аналитики: склад и конфигурация. Финансовая аналитика только конфигурация (ConfigId) Единицы измерения всегда штуки. Склад закрывается каждый месяц. Достаточно много работается с маркировками (cross docking, прямые поставки, заказы на перемещение, возвраты поставщикам и т.д.)

Проект предусматривал замену журналов переноса заказами на перемещение, соответсвенно резко выросло количество складских проводок (ну это и ладно )

Склад закрывался каждый месяц на протяжении года собственно без проблем. Единственная модификация стандартного функционала заключалась в собственной процедуре разноски в ГК после закрытия склада. Эта модификация (прикочевавшая еще с незапамятных времен, до начала нашего проекта) кроме всего прочего подставляла нужные значения финансовых аналитик, отсутствующих в табице сопоставлений. Речь правда сейчас и в последующем не в разноске ГК, а в том, что происходит на стадии сопоставления и прогона себестоимости.

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

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

Заранее спасибо за ответ!

[EVGL]

В AX 4.0 журналы переноса принципиально неправильно считаются: приходы с переноса идут в счет приходов, а расходы попадают в общий котел расходов. Это было исправлено только в AX2009: переносы стали обрабатываться как маркировки, с отслеживанием цепочки.

Журналы переноса, возможно, в 4.0 считаются без ошибок. В итоге имеем разницу.

[plumbum]

Спасибо, но в данном случае разноска по счетам идет по нестандартной процедуре.

Вопрос именно: на что указывает возрастание суммы коррекции и как с этим могут быть связаны заказы на перемещение (InventTransferTable)

[EVGL]

Разноска по счетам не имеет отношения к сумме коррекции. Я говорю о том, что сумма коррекции по журналам переноса в 4.0 считается принципиально неверно.

[plumbum]

Цитата:

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

Разноска по счетам не имеет отношения к сумме коррекции. Я говорю о том, что сумма коррекции по журналам переноса в 4.0 считается принципиально неверно.

Спасибо, Евгений, а где об этом почитать можно?
Но журналы переноса использовались и ранее, при этом бухгалтерию все устраивало
А вот заказы на перемещение появились в системе недавно.

[EVGL]

Тут на форуме много обсуждалось. Роман, диагноз прост: стоимость прихода не равна стоимости расхода в проводках журнала переноса. Находится select-ом по InventTrans. Если стоимость везде равна... хм, проблема в чем-то другом.

[plumbum]

Спасибо, Евгений, на форуме находил похожее, но всюду упоминается партионный учет, а у нас его не было...

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

Цитата:

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

Если стоимость везде равна... хм, проблема в чем-то другом.

Да я и не уверен что тут есть проблема, как писали уже, эта сумма коррекции со временем "утрясется" . Просто интересно, что влияет на ее удвоение