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

[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

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

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

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

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

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