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

[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 иметь поле, которое позволит определить, был ли при разноске кредит-ноты сторно или реверс.