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

[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.

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

[konfet]

Цитата:

Сообщение от Peter Savintsev

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

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

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

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

ВОПРОС К НАРОДУ.
Ситуация со времен написания данного поста (2004 год) никак не изменилась? Имеем 3.0 SP4 с указанным в ветке поведением системы: при операции коррекции - закрытия склада, вместо создания сторно - система создает реверсивные проводки и, соответственно, плывут обороты по 20 счету и воют бухгалтера.
Было ли сие пофиксено в SP5 или, быть может, в каких-то дальнейших хотфиксах? Если нет - то может кто-нибудь добрый поделится рабочим решением проблемы в виде проектика?

[Raven Melancholic]

Цитата:

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

ВОПРОС К НАРОДУ.
Ситуация со времен написания данного поста (2004 год) никак не изменилась?

Нет, не изменилась. Более того, в DAX4 то же самое. Про DAX2009 сказать не могу (не видел). Проектик дать не могу (собственность фирмы, а не моя), но идея модификации следующая (правда InventAdjustPost не переписывали, а создали свой):

• в методе updateNow создаем не один, а два LedgerVoucher и LedgerVoucherObject - один с флагом корректировки correct, а другой !correct.
• в методах updateItem* (точнее у нас такой метод один, просто есть иерархия классов - свой класс для каждого типа) расширяем список полей группировки таким образом, чтобы понять направление проводки (приход или расход);
• ну и в updateTrans разбираемся какой из LedgerVoucher использовать (учитывая, что мы отказались от использования локализаторских извращений с mapSettlement, то для нас это все - вам же придется думать как их обрабатывать).

PS: еще одна деталь - желательно в InventTrans иметь поле, которое позволит определить, был ли при разноске кредит-ноты сторно или реверс.