Закрытие склада. Разъехались InventSettlement и LedgerTrans

[Logger]

Привет всем.

Ковырял закрытие склада, обнаружил странное поведение :
Простановки отметки о разнесенности InventSettlement
\Classes\InventAdjustPostClosing\updatePosted
ставится для любых записей с ненулевой коррекцией :

    update_recordset inventSettlement
        setting posted = NoYes::Yes
        where inventSettlement.TransDate                == transDate
           && inventSettlement.Voucher                  == voucher
           && inventSettlement.CostAmountAdjustment     != 0
           // <GEEU>
           && inventSettlement.InventTransCurrency_RU   == this.inventTransCurrency_RU()
           // </GEEU>
           && inventSettlement.Posted                   == NoYes::No
           && inventSettlement.Cancelled                == _canceled;

А разноска в ГК
(см. \Classes\InventAdjustPostClosing\updateItem и далее по коду)
идет только для непустых
InventSettlement.BalanceSheetAccount
InventSettlement.BalanceSheetPosting
OperationsAccount.OperationsAccount
OperationsAccount.OperationsPosting

Что очень странно.
У нас это привело к тому что суммы коррекций в InventSettlement разошлись на сотни рублей с суммами разнесенными в LedgerTrans.
Проблема проявилась для переносов.

Как посоветуете лечить ?
1. Заполнять принудительно BalanceSheet* и Operations* поля ?
2. Поправить постирование InventSettlement ?

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

P.S.
Dax 2009 SP5

[fed]

А зачем сравнивать эти две суммы ? Просто мысленно переименуй Posted в Processed и все станет на места. А если вы сделали отчеты для сравнения inventSettlement и LedgerTrans, то просто добавьте в условия фильтрации проверку на пустоту счетов и коррсчетов и разносок по счету и коррсчету.

[Logger]

Пожалуй, ты поспешил с ответом. Не могу согласится с таким подходом.

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

[fed]

Цитата:

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

Пожалуй, ты поспешил с ответом. Не могу согласится с таким подходом.

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

Мы не отказываемся от корреляции. Просто галочка inventSettlement.posted говорит не о том что реально какие-то проводки ГК были созданы, а о том что запись была обработана модулем разноски. А для сверки с ГК надо проверять комбинацию posted+Account+OffsetAccount+Posted+OffsetPosting. Просто изначально имя поля posted было выбрано неудачно и это создает впечатление что оно действительно помечает сопоставления разнесенные в ГК. Назвали бы 'Processed' - путаницы бы не было.

[Logger]

Ага.
Но у меня вопрос связан не с названием поля InventSettlement.posted
Возможно я не совсем понятно проблему описал. Можно вообще поле posted выкинуть из рассмотрения.

Суть в том, что возможна ситуация, когда в InventSettlement.costAmountAdjustment ненулевая коррекция (и, соответсвенно, в поле InventTrans.CostAmountAdjustment), и пустые счета разноски InventSettlement.BalanceSheetAccount и InventSettlement.OperationsAccount.

Это приводит к тому, что двигается себестоимость в модуле управления запасами, но нет соответствующих проводок в LedgerTrans. Я считаю это неправильно. Легко получить ситуацию когда весь товар продан в 0, а на счете учета запасов (10, 41 и.т.п.) болтается остаток. Ну и множество других вариаций.

[fed]

И между прочим, inventAdjustPosting пропускает записи с пустыми счетами и разносками не потому что это баг, а потму что это коррекции к складским проводкам, по которым исходная операция принципиально не разносилась в ГК (карантинные заказы, WMS-заказы, переносы внутри одного сайта и тп). Причем под "принципиально не разносились" подразумевается что они не разнеслись не потому что себестоимость была нулевая, а просто в силу своего эконоимического смысла. Если ты в такие коррекции начнешь счета писать или просто сломаешь разноску чтобы в ГК всегда разносилось, то у тебя породятся коррекции по операциям, которые в ГК не попали.В этом случае будет куча левых проводок между складскими счетами и счетами прибылей и убытков. По складским счетам этих левых оборотов будет нулевым, но поскольку P/L не сальдируется, бухгалтера тебе спасибо не скажут

[Logger]

Цитата:

И между прочим, inventAdjustPosting пропускает записи с пустыми счетами и разносками не потому что это баг, а потму что это коррекции к складским проводкам, по которым исходная операция принципиально не разносилась в ГК

Это я понимаю.

Я имею в виду что способ лечения был неудачный. Ценой разваливания сумм по модулям. Зачем тогда функционал выверки нужен ?
Ведь почему переносы не разносились в ГК ? - Они по смыслу не должны были менять себестоимость в модуле управления запасами. По ним даже коррекция проводок невозможна. Но если возникает ситуация когда сумма приходной и расходной части переноса не дает 0, то уже надо разносить. Т.е. это просто баг реализации по отключению разноски. Замели под половичок и ладно.

Можно кровотечение из носа прекратить, перетянув шею жгутом ?
Конечно. Но...

Надо все равно в ГК разносить операции по которым есть коррекция. Например на счета учета ошибок
InventAdj::errorAccountBalanceSheet()
InventAdj::errorPostingOperations()

В подавляющем большинстве случаев, перед разноской в ГК, после группировки сумм в Inventsettlement плюсы и минусы от переносов закрываются в 0, исключение - всякая экзотика, типа ошибок округления, которая приводит к неравенству приходной и расходной части переноса. Она и вылезет на счета прибылей и убытков. Т.е. не будет никаких гигантских оборотов по дебету и кредиту. (Я нигде не предлагал постировать в ГК разноску переносов)

[Logger]

Цитата:

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

В подавляющем большинстве случаев, перед разноской в ГК, после группировки сумм в Inventsettlement плюсы и минусы от переносов закрываются в 0, исключение - всякая экзотика, типа ошибок округления, которая приводит к неравенству приходной и расходной части переноса. Она и вылезет на счета прибылей и убытков. Т.е. не будет никаких гигантских оборотов по дебету и кредиту.

С этим я поспешил. Обороты будут конечно, по дебету и по кредиту.
Не очень хорошо получается, (но по крайней мере лучше чем просто выкинуть суммы из разноски).
Можно попробовать одну из половинок переноса как сторно проводить, тогда валюта баланса не поедет.

Либо InventSettlement не трогать, а просто разносить в ГК записи InventSettlement с пустыми счетам ГК - назначая им какие-то условленные счета, например счета учета ошибок и сворачивая дебет и кредит.
Вот тогда получится, что и оборотов лишних не будет. И суммы все разнесутся.

[fed]

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

[Logger]

Цитата:

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

Если ты борешься с митуацией, когда себестоимость прихода и расхода в переносе не равны - то это последствия принципиального архитектурного бага в пересчете склада. Если не хочется ломать закрытие намертво - могу порекомендовать делать все пересчеты с очень большим количеством итераций (типа 200 - для этого надо поломать проверку числа итераций - это не страшно).

Вылезло изначально на этом. Конечно хочется решить проблему капитально. Потому что переносы - это частный случай.
Боюсь число итераций тут не всегда поможет. Иногда по кругу бегает одна и та же сумма - не уменьшаясь. Но она, конечно, не очень большая. Единицы или десятки рублей. Редко сотни.

Цитата:

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

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

Я кстати пытался такое делать. Решали проблему когда при разборке спецификации (InventTransType::BOM, InventTransType::BOMLine) коррекции не протаскивались на полученные при разборе составляющие. Но там все равно бывает неоднозначность, плюс придется особым образом учитывать такие расхождения для случая когда была коррекция в наличии на приходную проводку. В этому случае уже нельзя их тупо выравнивать. Я на этом накалывался.

P.S.
Если я правильно понимаю, ты считаешь что можно не постировать в главную книгу записи Inventsettlement c ненулевым значением CostAmountAdjustment ?
Про этот способ ты ничего не написал. А мне он кажется самым надежным.

[fed]

Цитата:

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

P.S.
Если я правильно понимаю, ты считаешь что можно не постировать в главную книгу записи Inventsettlement c ненулевым значением CostAmountAdjustment ?
Про этот способ ты ничего не написал. А мне он кажется самым надежным.

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

Вообще - если там всю цепочку просмотреть, то в момент разноски исходной складской проводки, система заполняет поле inventTransPosting.isPosted. Закрытие/пересчет исходя из значения этого поля заполняют/незаполняют счета в сопоставлениях. Если разноски в ГК исходной проводки не было - коррекцию разносить тоже не нужно.

[Logger]

Цитата:

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

Если разноски в ГК исходной проводки не было - коррекцию разносить тоже не нужно.

Ну вот это главный вопрос.
Почему коррекцию разносить не нужно ?

Переносы почему в ГК не постируются ? Потому что они ничего не меняют в себестоимости.

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

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

[fed]

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

[Logger]

Ну хорошо, пусть так.
В такой терминологии - описанную мной выше ситуацию как назовем ?
Если сумма коррекций по всем переносам затронутым закрытием склада не равна 0, то счет хранения объекта изменился или нет ?

[fed]

Счет не изменился. Если ты товар только переносил внутри сайта, не продавал, не списывал в производство, не списывал журналом P/L, не терял в интентаризации и тп - то он так и остался на том же счете.

[Logger]

Денис, я не буду дальше спорить. Наверно каждый останется при своем мнении.

P.S.
Напоследок все же скажу (мне кажется что ситуация очевидна, а ты, как бы поточнее выразиться, придираешься к мелочам и формулировкам, а не к сути) :

Я думаю, что ситуация когда коррекция на приходную и расходную части переноса отличается, - как раз и подпадает под твое определение о смене счета. Формально счет не поменялся, но сальдо на нем изменилось.

Если например был перенос между сайтами, то получится что ушла одна сумма,а пришла на другой сайт другая сумма.
Теперь делаем сайт одинаковыми. Что изменилось ? Принципиально - ничего. С чего бы тогда сальдо по счету не должно уменьшится ?

[fed]

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

[Logger]

Цитата:

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

Да и к слову сказать - проводку по переносу между сайтами сделали ТОЛЬКО для того чтобы поддержать разные стандартные себестоимости на разных сайтах. Я когда-то видел спеку на это дело.

Ээээ.
Т.е. изначально предполагалось что номенклатура будет рассчитываться при этом по стандартной себестоимости ? И именно для этого случая все и проектировали ?

Любопытно.

[fed]

Цитата:

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

Ээээ.
Т.е. изначально предполагалось что номенклатура будет рассчитываться при этом по стандартной себестоимости ? И именно для этого случая все и проектировали ?

Любопытно.

Именно. Просто если у тебя движения между счетами нету, но при этом со складского счета почему-то списали отклонения - это странно выглядит...