InventTransIdReturn и Закрытие склада - DAX: Программирование

DenisS · 21.11.2008, 16:34

Доброго времени суток!
Axapta 3.0 sp 5

Наткнулся на баг в закрытии склада в случае заполнения номера возвращенного лота (InventTransIdReturn) в приходной проводке НЕ по заказу. В этом случае себестоимость приходной проводки не корректируется.

В классе InventCostItemDim есть 2 основных метода, которые отвечают за коррекцию приходной возвратной проводки:

Этот метод корректируе все приходные проводки по заказам с заполненным лотом возврата перед выполнением закрытия по номенклатуре

X++:

void updateItemReturnAdjustments(ItemId _itemId = inventCostList.ItemId)
{
    InventTrans     inventTrans;
    InventTrans     issue;
    Price           costPrice;
    CostAmount      adjustment;
    ;

    while select sum(Qty), sum(CostAmountAdjustment), sum(CostAmountPosted) from inventTrans
        index hint StatusItemIdx
        group by   inventTransId, inventTransIdReturn
        where inventTrans.ItemId                == _itemId                      &&
              inventTrans.ValueOpen             == inventTransOpen::Yes         &&
              inventTrans.StatusReceipt         == StatusReceipt::Purchased     &&
              inventTrans.StatusIssue           == StatusIssue::None            &&
              inventTrans.TransType             == InventTransType::Sales       &&             inventTrans.DateStatus            <= inventClosing.TransDate      &&
              inventTrans.PackingSlipReturned   == 0                            &&
              inventTrans.InventTransIdReturn   != ''
    {
        select sum(Qty), sum(CostAmountAdjustment), sum(CostAmountPosted) from issue
            index hint TransIdIdx
            where issue.InventTransId           == inventTrans.inventTransIdReturn  &&
                  issue.StatusReceipt           == StatusReceipt::None              &&
                  issue.StatusIssue             == StatusIssue::Sold                &&
                  issue.PackingSlipReturned     == 0                                &&
                  issue.InventTransIdReturn     == inventTrans.inventTransId;

        if (issue.Qty)
        {
            costPrice   = (issue.costAmountPosted + issue.costAmountAdjustment) / issue.Qty;
            adjustment  = Currency::amount(inventTrans.Qty * costPrice - inventTrans.costAmountPosted - inventTrans.costAmountAdjustment);

            if (abs(adjustment) >= inventClosing.minTransferValue && !InventAdj::isOnhandAdjusted(inventTrans.InventTransId, inventTrans.InventTransIdReturn, ''))
                this.updateTransIdReturnReceipt(inventTrans.InventTransId, inventTrans.InventTransIdReturn, costPrice);
        }
    }
}

Второй метод "протаскивает" возвратную проводку на следующий уровень расчета, но опять-таки только проводку по заказу:

X++:

protected void updateTrans(
    InventTrans     inventTrans,
    CostAmount      adjustment
    )
{
    if (adjustment)
    {
        switch (inventTrans.transType)
        {
            case InventTransType::QuarantineOrder:
                this.addkeyAdjustment(true,inventTrans.inventTransId,adjustment,'',inventTrans.voucher);
                break;

            case InventTransType::InventTransfer:
            case InventTransType::WMSTransport:
                this.addkeyAdjustment(true,inventTrans.inventTransId,adjustment,'','');
                break;

            case InventTransType::ProdLine :
                this.addkeyAdjustment(false,inventTrans.inventTransIdFather,adjustment,'','');
                break;

            case InventTransType::BOMLine  :
                this.addkeyAdjustment(false,inventTrans.inventTransIdFather,adjustment,'','');
                break;

            default:
                if (inventTrans.inventTransIdReturn && inventTrans.qty < 0 && inventTrans.transType == InventTransType::Sales)
                    this.addkeyAdjustment(true,inventTrans.inventTransIdReturn,adjustment,inventTrans.inventTransId,'');
        }

        inventAdj::updateModule(inventTrans,adjustment,inventClosing);
    }

}

Наткнулся на эту ситуацию при попытке сторнировать расходный журнал Проводка.

Если из методов убрать условие
inventTrans.transType == InventTransType::Sales
то закрытие корректирует себестоимость возврата как мне и нужно.

У кого есть опыт подобной модификации, просьба откликнуться...

Logger · 21.11.2008, 17:24

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

**fed** · 21.11.2008, 18:40

Маркировка дает абсолютно другой результат. При маркировке будет откорректирована себестоимость списания (расхода то есть), хотя автору как раз надо себестоимость прихода скорректировать по себестоимости расхода. То есть - может быть сальдо после маркировки и закроется в ноль, но обороты по проводкам будут странные. По этому я считаю что маркировки нужно применять при возврате ПРИХОДОВ и лоты возврата при возврате РАСХОДОВ.

Кстати - мне очень кажется что поддержка лотов возврата для складских журналов и вообще не-заказов была реализована в 4.0 Feature pack 2 для восточной европы. Я этот FP2 со своего компа куда-то снес, но процентов 90 уверен что там это было (вместе с другими правками себестоимости)

Logger · 21.11.2008, 18:48

Как я понял автору нужно добиться чтобы суммы двух проводок при сторно совпадали. Поэтому и написал, что разницы нет, как корректировать.

Цитата:

но обороты по проводкам будут странные.

А что именно там странного получится ?

Logger · 21.11.2008, 18:55

Цитата:

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

Кстати - мне очень кажется что поддержка лотов возврата для складских журналов и вообще не-заказов была реализована в 4.0 Feature pack 2 для восточной европы. Я этот FP2 со своего компа куда-то снес, но процентов 90 уверен что там это было (вместе с другими правками себестоимости)

Именно поэтому мне кажется что код расчета себестоимости лучше не менять. Его часто корректируют - подниматься на сервис паки тяжко будет. А если какой нить баг пропустить, то исправлять потом сложно.

**fed** · 22.11.2008, 08:21

Цитата:

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

Как я понял автору нужно добиться чтобы суммы двух проводок при сторно совпадали. Поэтому и написал, что разницы нет, как корректировать.

А что именно там странного получится ?

Ну получается что у тебя есть некий приход, сделанный по не очень понятной себестоимости (насколько я помню - если в строках заказа ручками не вписать себестоимость прихода в отдельное поле, то себестоимость прихода будет просто нулевой). А потом мы еще и расход до этой непонятной себестоимости корректируем. И вообще с точки зрения логики бухучета - странно получается. Выходит мы предыдущее событие (списание), корректируем по последующему (возврат).
Ну то есть - конечно можно втихаря пользоваться маркировкой вместо лота возврата, поскольку вряд ли какой-то бухгалтер начнет выверять КАЖДЫЙ приход и расход. Но вот если такое случиться - ждите много интересных вопросов...

miklenew · 22.11.2008, 13:07

Можно воспользоваться функцией корректировка проводок.
Выбрать эту проводку.
Она как раз корректирует себестоимость приходов.

DenisS · 22.11.2008, 21:36

Спасибо всем за ответы!
К сожалению, маркировка здесь не поможет, т.к. расходная проводка может быть уже в закрытом периоде, и сторнировать в этом случае нужно будет первым числом следующего месяца.
Коррекция тоже не подходит, т. к. при закрытии склада себестоимость исходной проводки изменится, а приходной (без модификации) - нет.
Я вижу 2 пути:
1. Модификация закрытия склада для корректировки возвратных приходов не-заказов
2. При разноске сторнирующего журнала в исходной (сторнируемой) проводке проставлять ValueOpen = No, чтобы она не пересчитывалась при закрытии. Естественно при этом при разноске сторнирующей проводки себестоимость брать из сторнируемой.

Первый вариант мне нравится больше, но он более опасен...

2 fed: Спасибо за наводку про 4.0 fp2 - попробую посмотреть там...

donMigel · 24.11.2008, 14:45

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

Logger · 24.11.2008, 15:09

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

Т.е. возможно бага спрятана не в закрытии склада а в разноске.

DenisS · 24.11.2008, 15:27

2 Logger
По-моему, не совсем так:
В методе updateItemReturnAdjustments класса InventCostItemDim все возвратные проводки по заказам корректируются в соответствии с исходными расходными проводками. То есть не важно, по какой себестоимости провелся возврат при разноске. А дальше возникающие при закрытии коррекции расходной проводки (проводок) протягиваются по графу себестоимости.

Logger · 24.11.2008, 15:49

Цитата:

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

2 Logger
По-моему, не совсем так:
В методе updateItemReturnAdjustments класса InventCostItemDim все возвратные проводки по заказам корректируются в соответствии с исходными расходными проводками. То есть не важно, по какой себестоимости провелся возврат при разноске. А дальше возникающие при закрытии коррекции расходной проводки (проводок) протягиваются по графу себестоимости.

Возможно что и так.
Я сейчас точно не помню. Смотрел давно, мог ошибиться.

Чтобы точно быть уверенным нужно проверять на конкретном примере.

А вообще указанный код

X++:

        if (issue.Qty)
        {
            costPrice   = (issue.costAmountPosted + issue.costAmountAdjustment) / issue.Qty;
            adjustment  = Currency::amount(inventTrans.Qty * costPrice - inventTrans.costAmountPosted - inventTrans.costAmountAdjustment);

            if (abs(adjustment) >= inventClosing.minTransferValue && !InventAdj::isOnhandAdjusted(inventTrans.InventTransId, inventTrans.InventTransIdReturn, ''))
                this.updateTransIdReturnReceipt(inventTrans.InventTransId, inventTrans.InventTransIdReturn, costPrice);
        }

в методе
\Classes\InventCostItemDim\updateItemReturnAdjustments

не обязательно приведет к вызову

X++:

this.updateTransIdReturnReceipt(inventTrans.InventTransId, inventTrans.InventTransIdReturn, costPrice);

на каждом шаге цикла.

я смотрел для случая переносов для Ax3 SP5
Была попытка изменить код расчета себестоимости чтобы не было усреднения по партиям. Под это дело был изменен метод updateTransIdReturnReceipt()
Но подстава была в том что если при расчете себестоимости расходная проводка не корректировалась (а такое бывает особенно часто если партионный учет включен) - ну повезло нам что мгновенная себестоимость совпала с той которая нужна, то метод updateTransIdReturnReceipt() - не вызывается. Считается что нефиг зря пересчеты гонять, что при первоначальной разноске все должно было правильно перенестить по связи возвращенных лотов.

Соответсвенно моя модифа втаком случае не отрабатывала.
Возможно что здесь у donMigel похожий случай. (По идее метод одинаково работает что для лотов возврата, что для переносов)

P.S.
При сравнении кода нужно еще учитывать, что с SP3 по SP5 закрытие склада поменялось, так что у вас код может отличаться. Я приводил примеры для SP5

donMigel · 24.11.2008, 16:43

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

Logger · 24.11.2008, 17:59

А вы уверены что описанная ситуация всегда бывает, а не для какого-то частного случая/глюка ?

donMigel · 25.11.2008, 09:07

Цитата:

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

А вы уверены что описанная ситуация всегда бывает, а не для какого-то частного случая/глюка ?

Уверен,тестировалось на Demo, которая итёт с поставкой версии 3.0

AlexeyBP · 03.12.2008, 09:02

Добавлю еще ложку дегтя в использование номера возвращенного лота и пересчета остатков.
Используем пересчет остатков на каждый день.
У номенклатуры активная аналитика склад (фин. склад=Да), складская модель закрытия ФИФО. Версия Ax 3.0 sp3 (Проверял на рабочем приложении и на стандартном).
Столкнуля с такой проблемой:
Например, есть две закупка

Закупка: количество +1 себестоимость +10
Закупка: количество +1 себестоимость +20
Оформляем продажу: Продажа: количество -1 себестоимость -15.

Запускаем пересчет. Проводки становятся:

Закупка: количество +1 себестоимость +10
Закупка: количество +1 себестоимость +20
Продажа: количество -1 себестоимость -10 (Фин. сумма = -15, Коррекция = +5). Оформляем возврат продажи. Возврат продажи: количество +1 себестоимость +10.

Перед закрытием склада в конце месяца отменяем пересчет. Получаем проводки:

Закупка: количество +1 себестоимость +10
Закупка: количество +1 себестоимость +20
Продажа: количество -1 себестоимость -15. (Фин. сумма = -15, Коррекция = 0)
Возврат продажи: количество +1 себестоимость +10.

Запускаем закрытие склада. Получаем проводки:

Закупка: количество +1 себестоимость +10
Закупка: количество +1 себестоимость +20
Продажа: количество -1 себестоимость -10. (Фин. сумма = -15, Коррекция +5)
Возврат продажи: количество +1 себестоимость +5. (Фин. сумма = +10, Коррекция -5)

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

Похожие темы
Тема	Автор	Раздел	Ответов	Посл. сообщение
Denis Fedotenko: Себестоимость и закрытие склада	Blog bot	DAX: База знаний и проекты	44	29.03.2010 14:54
И снова закрытие склада...	Apriori	DAX: Функционал	3	21.01.2008 10:03
Закрытие склада. Параметр "Спецификация"	DenWolf	DAX: Функционал	0	05.06.2006 14:46
Закрытие склада по заказам по которым нет приемки...	netbas	DAX: Функционал	3	26.11.2004 22:24
Закрытие склада в основной и вторичной валюте, отключенная корреспонденция счетов	May	DAX: Функционал	1	02.04.2004 13:25