И снова про средневзвешенную стоимость списания

[AKIS-Falcon]

У нас часто получается, что определенный товар мы производим несколько (до 10) партий за день. В системе это оформляется так: вводится производственный заказ на общее количество, соответствующее всем партиям; затем специальной фичей этот заказ разбивается на столько партий, сколько нам нужно, с присвоением каждой уникального номера партии; после чего все получившиеся заказы разом проводятся (Started, Report as finished, Costing). Т.е. в общем вся бодяга нужна для того, чтобы оприходовать произведенное количество не чохом, а с разбивкой на партии.

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

- Приход первой партии из производства на склад ГП
- Перемещение первой партии из ГП в карантин
- Перемещение первой партии из карантина обратно в ГП

И так по каждой партии.

Самое интересное творится со стоимостями.
1. Стоимость перемещения из ГП в карантин определяется после Report as finished как средневзвешенная на тот момент
2. Стоимость прихода из производства в ГП - после костинга, т.е ПОСЛЕ того, как товар уже ушел в карантин (первая корявость, не самая большая пока)
3. Стоимость перемещения из карантина в ГП - средневзвешенная в момент совершения операции перемещения. Т.е., для случая нескольких партий, ПОСЛЕ выпуска всех партий (они, напомню, выпускаются все вместе и разом).

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

Кроме того, стоимость перемещения отдельных ПАРТИЙ - тоже может отличаться, и по той же причине. Иными словами, если б мы производили все вместе, без разбивок на партии, то была бы одна стоимость, а с разбивкой получается другая.

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

Самый простой выход разумеется - вообще отказаться от weighted average cost и все списывать по standard cost. Но нас он, увы, не устраивает.
Вариант два - сделать небольшую коррекцию программы, чтобы по standard cost шли ТОЛЬКО перемещения в карантин и обратно. Но тогда придется править и функционал пересчета и закрытия склада, чтобы там эти транзакции тоже считались по-особому. А мне это не хочется.

Может кто-то подскажет третий (четвертый, пятый...) варианты?

[Valery]

Цитата:

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

Почему вы не работаете в одном производственнном заказе? А разные партии можно задавать разными строками журнала приемки или даже одной строкой, но через регистрацию?

[AKIS-Falcon]

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