Пересчет себестоимости отгрузок

[Peter Savintsev]

Я достаточно долго занимался изучением данного вопроса и пришел к выводу, что добиться создания именно сторнирующих проводок при закрытии можно только путем очень тяжелых и опасных модификаций. Объясню почему.

Для примера возьмем проводку списания материалов Д20 К10 на сумму 1000.

Как известно, сторнирующие проводки отличаются от обычных тем, что в поле Коррекция у них стоит Да (LedgerTrans.Correct = NoYes::Yes), а реверсированные - это проводки с обратной корреспонденцией. Для нащего примера сторнирующей проводкой будет Д20 К10 -1000, а реверсирующей Д10 К20 1000.

За создание проводок отвечают классы LedgerVoucher и LedgerVoucherObject. Последний при создание объекта прнимает параметр Correction, который и отвечает за то, будет ли проводка сторнирущей или реверсированной. Важное замечание: документ ГК может быть либо целиком сторно, либо целиком реверс. То есть ситуация, когда часть провдок в рамках одного документа ГК являются сторнирующими, а часть реверсированными, невозможна (в рамках стандартного функционала, естественно ). Чтобы убедится в этом, достаточно взглянуть на конструктор класса LedgerVoucherObject newVoucher, который принимает в качестве параметра помимо прочего документ ГК для проводки (_voucher) и признак сторно (_correction).

Теперь помотрим на механизм закрытия склада. При закрытии создается множество проводок с ОДНИМ документом ГК. За это отвечает класс InventAdjustPost и его метод updateNow. Поскольку используется один ваучер, то все его проводки будут либо сторно, либо, как в стандартном функционале, реверсом.

Вернемся к нашем примеру. Предположим теперь, что было списано два вида материалов. Возникли две проводки: Д20 К10 1000 и Д20 К10 500. В ходе закрытия склада система обнаружила, что себестоимость первого материала была на 100 руб. меньше, а второго - на 200 больше. Хотелось бы, чтобы при закрытии возникли две проводки: Д20 К10 -100 и Д20 К10 200. Однако, всвязи со всем вышесказанным, система не может сделать такие проводки в рамках одного документа ГК. Поэтому имеем Д10 К20 100 и Д20 К10 200. Если же слегка подправить метод InventAdjustPost.updateNow, то опять же получится лажа: Д20 К10 -100 и Д10 К20 -200.

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