Цитата:
Сообщение от
fed
Если ты борешься с митуацией, когда себестоимость прихода и расхода в переносе не равны - то это последствия принципиального архитектурного бага в пересчете склада. Если не хочется ломать закрытие намертво - могу порекомендовать делать все пересчеты с очень большим количеством итераций (типа 200 - для этого надо поломать проверку числа итераций - это не страшно).
Вылезло изначально на этом. Конечно хочется решить проблему капитально. Потому что переносы - это частный случай.
Боюсь число итераций тут не всегда поможет. Иногда по кругу бегает одна и та же сумма - не уменьшаясь. Но она, конечно, не очень большая. Единицы или десятки рублей. Редко сотни.
Цитата:
Сообщение от
fed
Если хочется решать проблему более капитально - надо слегка дописать закрытие чтобы перед началом первой итерации (то есть - первой итерации которая себестоимость прогоняет, а не проводки сопоставляет), оно рассчитывало бы разницы между приходными и приходными проводками по всяческим переносам и производствам, а потом эту коррецию стандартным механизмом применяло бы к приходным проводкам.
Я кстати пытался такое делать. Решали проблему когда при разборке спецификации (InventTransType::BOM, InventTransType::BOMLine) коррекции не протаскивались на полученные при разборе составляющие. Но там все равно бывает неоднозначность, плюс придется особым образом учитывать такие расхождения для случая когда была коррекция в наличии на приходную проводку. В этому случае уже нельзя их тупо выравнивать. Я на этом накалывался.
P.S.
Если я правильно понимаю, ты считаешь что можно не постировать в главную книгу записи Inventsettlement c ненулевым значением CostAmountAdjustment ?
Про этот способ ты ничего не написал. А мне он кажется самым надежным.