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

[IvanHARD]

Подскажите, пожалуйста, какие проводки создаются при пересчете себестоимости продаж через "Закрытие и коррекция"?
При уменьшении себестоимости отгрузки я ожидал увидеть сторно , но, похоже, аксапта делает реверс. Так ли это? Можно ли изменить поведение системы?

[konopello]

Цитата:

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

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

Выполнял недавно модификацию, которая изменяет данную логику, и она мне далась довольно малой кровью. Была выполнена следующая модификация:

ledgerVoucherTransObject = LedgerVoucherTransObject::newCreateTrans(
                                                                    _ledgerVoucher.findLedgerVoucherObject(),
                                                                    this.postingBalanceSheet(),
                                                                    this.accountBalanceSheet(),
                                                                    this.dimension(),
                                                                    Companyinfo::standardCurrency(),
                                                                    costAmount,
                                                                    0);

                ledgerVoucherTransObject.parmCorrect(this.correctLedgerTransObject() ? this.correctLedgerTransObject() : ledgerVoucherTransObject.parmCorrect());

                _ledgerVoucher.addTrans(ledgerVoucherTransObject);

[fed]

мои пять копеек: Привязка признака сторнирования к всему ваучеру исчезла еще во времена версии 3.0. Теперь признак сторнирования можно привязывать к постингу (LedgerVoucherTransObject). Механизм корреспонденции не позволяет корреспондировать сторнирующую и обычную проводки (что логично). Теперь по смыслу задачи. Кусочек кода по понятным причинам тоже не могу привести Задача решается следующими шагами:
1. Добавляется признак сторнирования в шапку журналов
2. Добавляется признак сторнирования в строки журналов (инициализируется из шапки)
3. Метод inventJournalCheckPost.postLedgerTransправится таким образом, чтобы parmCorrect() у ledgerObjectVoucher инициализировался из признака сторнирования в строке журнала.
4. В inventTrans добавляется поле с признаком сторнирования. (Correct). Метод inventMovement.initInventTransFinancial() правится так, чтобы копировать в складскую проводку признак сторнирования из ledgerVoucherObject
5. В классе inventCostItemDim (или в таблице inventTrans) создается статический метод SetSettlementCorrect. Он заполняет в inventSettlement признак коррекции в том случае, если знак суммы положительный, а корректируемая складская проводка – списание или если знак суммы отрицательный, а корректируемая складская проводка – приход. При наличии в складской проводке признака сторнирования (из пункта 4) – логика инвертируется. При любых созданиях/обновлениях inventSettlement из кода закрытия/пересчета склада (класс inventCostItemDim) перед вызовом update/insert вызывался бы метод setSettlementCorrect.
6. Класс inventAdjustPost и его наследники правится так, чтобы группировать проводки еще и по признаку сторнирования (correct) из inventSettlement. При создании объекта ledgerVoucherTransObject - parmCorrect инициализируется из ключа mapSettlement.
7. После того как я все это сделал – выяснилось что у меня случилась засада входящими накладными расходами. Они тоже создаются как записи в inventSettlement и разносятся классом inventAdjustPost. Учитывая что в тех классах, которые создают inventSettlement по накладным расходам признак коррекции не заполняется, то при некоторых операциях (кажется при возврате накладной с накладными расходами или при вводе отрицательных накладных расходов) все разваливалось. Изначально - я глупо заткнул эту дырку, просто передавая в inventAdjustPost какой-то параметр, который приводил к тому что признак коррекции не подставлялся из inventSettlement, а брался из исходного ledgerVoucher. Несколько позже я эту дырку починил более правильным способом. Я нашел все классы в которых создается inventSettlement (InventTransAdjust и еще парочка кажется) и вставил туда код, который правильно выставляет поле сторнирования в inventSettlement.

[konfet]

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