Проблемы при закрытии склада DAX2009 SP1 RU5/RU6

[Logger]

Если уж начали перечислять баги закрытия, то добавлю свои 5 копеек.
В методах
\Classes\ClassFactory\inventLastClosingDate
\Classes\ClassFactory\inventLastClosingDateSecCur_RU

некорректно сделано кеширование даты последнего закрытия склада.
Оно не учитывает тот факт, что закрытие склада выполняется в конкретной компании. Поэтому если мы поработали в одной компании, в которой период закрыт, а потом переключаемся в другую, в которой период не закрыт, и пытаемся в этом периоде разносить что-то - то получаем ошибку.

Лечится например так :

TransDate inventLastClosingDate(boolean  reSelect = false)
{
    // GRD_FixLastClosingDateCalc_pkoz // pkoz 16.01.2011 -->
    // проект GRD_FixLastClosingDateCalc_pkoz сделан для того чтбы исправить кеширование даты последнего закрытия склада
    // это кеширование не учитывало компанию, так что если, например, у нас в одной компании
    // склад закрыт по одоной число, а в другой по другое, то аксапта могла для обоих компаний считать дату одинаковой -
    // в случае если сперва метод вызвали в одной компании,  а потом в другой
    #define.GRD_date("_date")
    #define.GRD_integer("_integer")
    sysglobalCache      GRD_globalCache = this.globalCache(); // получаем через метод так как может оказаться неинициализированным
    // GRD_FixLastClosingDateCalc_pkoz // pkoz 16.01.2011 <--
    ;

    // GRD_FixLastClosingDateCalc_pkoz // pkoz 16.01.2011 -->
    inventLastClosingDate   = GRD_globalCache.get(funcname() + #GRD_date,    curExt(), dateNull());
    inventClosingTtsVersion = GRD_globalCache.get(funcname() + #GRD_integer, curExt(), 0);
    // GRD_FixLastClosingDateCalc_pkoz // pkoz 16.01.2011 <--

    if (inventClosingTtsVersion != appl.ttsVersion() || reSelect || (!inventClosingTtsVersion && !inventLastClosingDate))
    {
    // pkoz 02.01.2009 -->
    // слишком много коррекций накопилось - так будет быстрее
//      inventLastClosingDate = (select maxOf(transDate) from inventClosing
        inventLastClosingDate = (select forceliterals maxOf(transDate) from inventClosing
    // pkoz 02.01.2009 <--
                                    index hint TypeActiveIdx
                                    where inventClosing.active                 == NoYes::Yes &&
                                          // <GEEU>
                                          inventClosing.InventTransCurrency_RU == InventTransCurrency_RU::PrimaryCur &&
                                          // </GEEU>
                                          inventClosing.adjustmentType  == InventAdjustmentType::Closing).transDate;

        inventClosingTtsVersion  = appl.ttsVersion();

        // GRD_FixLastClosingDateCalc_pkoz // pkoz 16.01.2011 -->
        GRD_globalCache.set(funcname() + #GRD_date,    curExt(), inventLastClosingDate);
        GRD_globalCache.set(funcname() + #GRD_integer, curExt(), inventClosingTtsVersion);
        // GRD_FixLastClosingDateCalc_pkoz // pkoz 16.01.2011 <--

    }

    return inventLastClosingDate;
}

[Владимир Максимов]

Цитата:

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

Если уж начали перечислять баги закрытия, то добавлю свои 5 копеек.
В методах
\Classes\ClassFactory\inventLastClosingDate
\Classes\ClassFactory\inventLastClosingDateSecCur_RU

некорректно сделано кеширование даты последнего закрытия склада.
Оно не учитывает тот факт, что закрытие склада выполняется в конкретной компании. Поэтому если мы поработали в одной компании, в которой период закрыт, а потом переключаемся в другую, в которой период не закрыт, и пытаемся в этом периоде разносить что-то - то получаем ошибку.

Вообще-то, вероятность этого события чрезвычайно мала, поскольку первая проверка стоит

if (inventClosingTtsVersion != appl.ttsVersion())

Чтобы получить совпадение счетчиков транзакций в разных компаниях - это надо какое-то очень уж уникальное стечение обстоятельств. Или что формирует значение appl.ttsVersion()?

Ну, а раз счетчик имеет значение отличное от сохраненного, то и дата закрытия будет вычислена заново. Прямым запросом по таблице invetnClosing

[Bega]

ПРОБЛЕМА 6. При расчете по средневзвешенной проводки не всегда сопоставляются, стоимость расхода из-за этого неверная.

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

В феврале при создании виртуального переноса для средневзвешенной цены , поскольку на момент создания этого переноса у сопоставляемых проводок была нулевая стоимость, создались складские проводки «Средневзвешенное закрытие запасов» (InventTransType = SummedUp) с нулевой финансовой суммой (CostAmountPosted = 0). Далее на следующих шагах закрытия февраля, средневзвешенная была скорректирована (сумма CostAmountAdjustment), значение CostAmountPosted так и осталось нулевым, это все вполне корректно. На конец февраля мы имеем остаток по номенклатуре и единственную складскую открытую проводку «Куплено» с типом «Средневзвешенное закрытие запасов».

В марте в методе InventCostItemDim::updateModelAverage происходит сопоставление приходов и расходов в соответствии со средневзвешенной моделью себестоимости.
В этом куске кода происходит поиск подходящих приходов для сопоставления:

while (tmpreceiptScan.RecId&&tmpreceiptScan.TransDate<=endDate)
{
receiptScan = this.tmpReceipt2Trans(tmpreceiptScan);
            // <GEEU>
            if (receiptScan.TransType != InventTransType::SummedUp || this.currencyTransfer_RU(receiptScan))
            { 
            // </GEEU>

вызывается метод this.currencyTransfer_RU(), в котором проверяется только CostAmountPosted, а она у нас равна нулю.

protected boolean currencyTransfer_RU(InventTrans _inventTrans)
{
    return _inventTrans.CostAmountPosted != 0;
}

таким образом, наша открытая проводка «Средневзвешенное закрытие запасов» будет исключена из сопоставления и мартовская расходная проводка не будет сопоставлена и ее стоимость будет неверной.

РЕШЕНИЕ

Я закрыл слад вот с такой модификацией и проблема была решена:

//+ DPL InventClosingFix_OK 11.04.2011 OK
            //if (receiptScan.TransType != InventTransType::SummedUp || this.currencyTransfer_RU(receiptScan))
            if (   receiptScan.TransType != InventTransType::SummedUp || receiptScan.costValue() != 0)
            //- DPL InventClosingFix_OK 11.04.2011 OK

Можно бы было доделать currencyTransfer_RU(), чтобы он анализировал и CostAmountAdjustment но он используется ниже в других местах и такая модификация потребует еще тестирования, проверю отдельно и напишу.

[Bega]

В решении проблемы 2 есть ошибка, при пересчете нужно использовать стандартную логику, то есть в методе InventCostItemDim::updateItem():

//+ DPL InventClosingFix_OK 12.02.2011 OK
if (inventClosing.AdjustmentType==InventAdjustmentType:Closing & &
calculationProdWIP_RU
)
{
this.updateReceiptAdjustment();
}
//- DPL InventClosingFix_OK 12.02.2011 OK

[zelibobis]

К проблеме № ПРОБЛЕМА 6. А что делать если остались проводки со статусом "Продано" и типом «Средневзвешенное закрытие запасов»? при последующих пересчетах они тоже не уходят...

[Bega]

Цитата:

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

К проблеме № ПРОБЛЕМА 6. А что делать если остались проводки со статусом "Продано" и типом «Средневзвешенное закрытие запасов»? при последующих пересчетах они тоже не уходят...

Цитата:

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

Можно бы было доделать currencyTransfer_RU(), чтобы он анализировал и CostAmountAdjustment но он используется ниже в других местах и такая модификация потребует еще тестирования, проверю отдельно и напишу.

Я в результате изменил метод currencyTransfer_RU() и убрал модификацию в методе updateModelAverage(), скорее всего это поможет.

protected boolean currencyTransfer_RU(InventTrans _inventTrans)
{
    //+ DPL InventClosingFix_OK 12.04.2011 OK
    //return _inventTrans.CostAmountPosted != 0;
    return _inventTrans.costValue() != 0;
    //- DPL InventClosingFix_OK 12.04.2011 OK

}

Мы уже много раз склад закрыли, вроде работает.

[zelibobis]

Хм.. мы тоже подправили этот метод - но при пересчете все-равно остаются указанные мною выше проводки. Анализировали код - нашли участок в классе InventCostItemDim методе updateModelAverage:

...
while (tmpIssue.RecId && tmpIssue.TransDate <= endDate && this.financialOpenQty(distributionReceipt) >= InventAdj::settleQtyDiff())
        {
            issue = this.tmpIssue2Trans(tmpIssue);
            // <SYS>
            if (issue.TransType == InventTransType::SummedUp && issue.DateFinancial == endDate)
            //</SYS>
            {
                this.ssue(issue);
                next tmpIssue;
            }
...

А метод updateMapOреnІssue содержит в себе достаточно информативный комментарий: Add an issue to mapOреnІssue because it could not be closed. Messages about these will later be written to the infolog.

[Bega]

Цитата:

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

Хм.. мы тоже подправили этот метод - но при пересчете все-равно остаются указанные мною выше проводки. Анализировали код - нашли участок в классе InventCostItemDim методе updateModelAverage:
А метод updateMapOреnІssue содержит в себе достаточно информативный комментарий: Add an issue to mapOреnІssue because it could not be closed. Messages about these will later be written to the infolog.

А у меня вот такой код:

while (tmpIssue.RecId&&tmpIssue.TransDate<=endDate&&this.financialOpenQty(distributionReceipt)>=InventAdj::settleQtyDiff())
        {
            issue = this.tmpIssue2Trans(tmpIssue);

            /* <SYS>
            if (issue.TransType==InventTransType::SummedUp&&issue.DateFinancial== endDate)
            </SYS> */
            // <GEEU>
            if (issue.TransType==InventTransType::SummedUp&&(issue.DateFinancial== endDate||!this.currencyTransfer_RU(issue)))
            {
                if (this.currencyTransfer_RU(issue))
                // </GEEU>
                {
                    this.updateMapOpnIssue(issue);
                // <GEEU>
                }
                // </GEEU>

                next tmpIssue;
            }
            else

Какой у вас роллап?

[zelibobis]

RU5. Сори, это уже я убрал код обрамленный <GEE> в данном методе на тестовом приложении. Но даже с ним зависшие проводки не уходят...