Закрытие склада и корректировочные проводки

[Vol4ok]

Подскажите, может кто сталкивался с такой проблемой...
В системе AX 2009, после закрытия склада по средневзвешенной модели сформировались корректировочные проводки. Но по какому принципу формируются проводки в ГК мне не совсем понятно, поскольку крректировочных сумм в проводках номенклатуры гораздо больше чем проводок, которые пошли в ГК после закрытия склада. Как можно проверить\ просчитать корректность сумм по проводкам, которые пошли в ГК при закрытии по конкретной номенклатуре? Или может существует какая - то логика расчета?

[fed]

Цитата:

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

Подскажите, может кто сталкивался с такой проблемой...
В системе AX 2009, после закрытия склада по средневзвешенной модели сформировались корректировочные проводки. Но по какому принципу формируются проводки в ГК мне не совсем понятно, поскольку крректировочных сумм в проводках номенклатуры гораздо больше чем проводок, которые пошли в ГК после закрытия склада. Как можно проверить\ просчитать корректность сумм по проводкам, которые пошли в ГК при закрытии по конкретной номенклатуре? Или может существует какая - то логика расчета?

В ГК идут только те корректировочные суммы, которые были сделаны для проводок, изначально разнесенных в ГК. Например - если перенос скорректировали, то в ГК эта сумма не пойдет. Единственное исключение - списание округлений и ошибок. Если по переносу будет списываться округление, то эта корректировка пойдет в ГК, даже если сама проводка (перенос например) в ГК не разносилась.
Не хорошо сравнивать корректировочные суммы в проводках с чем бы то ни было. Поле costAmountAdjustment в inventTrans - это адское изобретение, автор которого породил больше проблем чем решил. Если хочешь что-то с чем-то сравнивать то ВСЕГДА надо брать costAmountPosted из inventTrans, а сумму корректировок - не из inventTrans, а из InventSettlement с датами меньшими или равными чем отчетная дата.
Тот кто добавил поле costAmountAdjustment просто надеялся слегка снизить время сложных рассчетов баланса по проводке. Скажем если у нас проводку 1000 раз скорректировали, то проще взять inventTrans.costAmountAdjustment и вычесть из него те коррекции inventSettlement, которые были сделаны после отчетной даты. (Посмотрите метод inventSumDateValueReport.selectInventTransPostingFinancial чтобы понять правильную логику работы с costAmountAdjustment). В итоге, 95% внедренцев прямолинейно считают обороты и балансы по inventTrans.costAmountPosted+inventTrans.costAmountAdjustment. Пожалуйста - не делайте так. Каждый раз когда кто-то складывает inventTrans.costAmountPosted с inventTrans.costAmountAdjustment, Бенни Олесен икает...

Если вам очень надо выверить обороты по ГК по закрытию с чем-то, вы можете сравнить данные в ваучере ГК с суммой inventSettlement, у которого что-то есть в BalanceSheetPosting. Но я не думаю что вы там что-то найдете интересное. Эта логика хорошо выверена и ее партнеры редко переписывают. Не думаю что у вас там что-то интересное вылезет во время такой сверки.

[Logger]

Мне кажется, идея поля costAmountAdjustment - банальная денормализация. Чтобы не тормозило.
А используют его неправильно - от непонимания и недостатка внятной документации.
Я, например, основные знания по закрытию склада от твоих статей почерпнул, а не от документации. Бестолковая она.

[Dolores]

Поясните , пожалуйста, почему при закрытии склада возникают в InventSettlement корректировочные проводки (без количества), которые связаны по полю SettleTransId с операцией закрытия склада за предыдущий месяц?

[fed]

Цитата:

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

Поясните , пожалуйста, почему при закрытии склада возникают в InventSettlement корректировочные проводки (без количества), которые связаны по полю SettleTransId с операцией закрытия склада за предыдущий месяц?

Это - ненормальная ситуация.
Вариант 1 - у вас просто слетела номерная серия по номеру сопоставления в модуле логистики. Поскольку никаких проверок уникальности там нету, система будет молча вставлять записи со значением SettleTransId уже использованой в прошлых месяцах.
Вариант 2 - доработки. (Маловероятно - тяжело представить кому бы может потребоваться этот кусок кода менять и зачем).

[SRF]

Увы, но так работает стандарт, стек выглядит примерно так InventCostItemDim\updateReceiptAdjustment\updateReceiptAdjustmentTrans\updateSettlementReceipt - в нем хорошо видно, что в некоторых случаях система создает корректировки с уже существующим SettleTransId.

Перед основными коррекциями происходит следующее - алгоритм пробегает по всем частично сопоставленным проводкам прихода и проверяет сумму сопоставления текущего и рассчитанного по следующей формуле: себестоимость * кол-во сопоставленное / общее кол-во в проводке, и если суммы различны и она превышает порог указанный в параметрах закрытия, то система формирует коррекцию по данной проводке прихода и рассчитанную сумму размазывает на все проводки, которые связаны с указанной проводкой, при этом корректировки и формируются с новой датой закрытия и существующим SettleTransId и еще в этот момент система не смотрит открыта ли связанная проводка или нет, таким вот образом система может подкорректировать ранее закрытую проводку.

Это хорошо заметно становится, если использовать средневзвешенную модель в DAX 2009 и выше, если у вас виртуальный перенос который создает система используется в нескольких закрытиях(например приход был в одном периоде закрытия, а расходы в нескольких), то вероятность получить указанные коррекции увеличивается.

[Dolores]

Можно ли как-то решить эту проблему, т.е. избавиться от этих корректировочных проводок?

[S.Kuskov]

Цитата:

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

проверяет сумму сопоставления текущего и рассчитанного по следующей формуле: себестоимость * кол-во сопоставленное / общее кол-во в проводке, и если суммы различны и она превышает порог указанный в параметрах закрытия, то ...

А что это за ситуация такая? Когда такая разница возможна? После выполнения операции корректировки открытых проводок?

[fed]

Цитата:

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

Увы, но так работает стандарт, стек выглядит примерно так InventCostItemDim\updateReceiptAdjustment\updateReceiptAdjustmentTrans\updateSettlementReceipt - в нем хорошо видно, что в некоторых случаях система создает корректировки с уже существующим SettleTransId.
.

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

[Pustik]

Цитата:

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

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

Коллеги, как Вы считаете, это правильно трогать ранее закрытую проводку? Я, так понимаю, что после таких коррекций она становится открытой и снова участвует в расчете себестоимости? Или я где-то ошибаюсь?

[fed]

Цитата:

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

Коллеги, как Вы считаете, это правильно трогать ранее закрытую проводку? Я, так понимаю, что после таких коррекций она становится открытой и снова участвует в расчете себестоимости? Или я где-то ошибаюсь?

Строго говоря - такая ситуация говорит о нарушении хронологии. Закрытие склада корректирует, в первую очередь списания и только во вторую - приходы. И корректировка старого (закрытого) прихода происходит только в том случае, если какие-то из старых закрытых списаний было на самом деле не покрыто товаром. Например - 1ого числа купили 20 штук на склад A, потом 30ым числом прошлого месяца разнесли перенос со склада А на склад Б, потом 31ым числом прошлого месяца разнесли накладную на продажу со склада Б. В итоге приход на склад Б и продажа со склада Б закрылись друг на друга, а списание со склада А осталось висячим. Потом в следующем месяце склад закрыли, и скорректировалось списание со склада А. После этого система вынуждена скорректировать закрытые проводки прихода на склад Б и списания со склада Б.

Если эту операцию коррекции закрытых проводок заблокировать (это нелегко, но в целом возможно), то обороты по переносу останутся не-нулевыми (то есть -со склада А списали больше чем на склад Б пришло). Я раздумывал над вариантом когда все коррекции закрытых приходов автоматически списываются на прибыли и убытки и даже писал об этом вот в этой вот теме. Однако же, этот вариант тоже имеет один очень и очень заметный минус: Возможно через цепочку переносов целевой товар все еще находится где-то на предприятии. По хорошему - в такой ситуации надо было коррекцию прогнать через все переносы и производства (пусть даже закрытые) и дотащить до того места где товар находится. А мы на первом же закрытом переносе все списали в прибыли и убытки... Тоже вариант так себе, на самом деле.
В общем - я на самом деле не вижу внятного способа решения данной проблемы.