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

[Bega]

Решил поделиться проблемами и решениями, которые возникли при закрытии склада. Большая часть проблем связана с расширенным расчетом производственной себестоимости, который был добавлен RU5.

ПРОБЛЕМА 1: Неверная себестоимость расходов при расширенном расчете себестоимости.

Основная логика по закрытию склада находится в классе InventCostItemDim. В методе updateItem вызывается updateLevelAdjustment() в котором коррекции, которые «прилетели» на данную номенклатуру с предыдущих шагов, распределяются на приходные проводки этой номенклатуры.

while select sum(Adjustment) from inventCostListTrans
            index hint ItemIdx
            group by InventTransId,InventTransIdReturn,VoucherPhysical
            where inventCostListTrans.Voucher           == inventClosing.Voucher            &&
                  inventCostListTrans.NumOfIteration    == inventCostList.NumOfIteration    &&
                  inventCostListTrans.ItemId            == inventCostList.ItemId
        {
            // <GEEU>
            if (calculationProdWIP_RU 
               && inventCostListTrans.InventTransId &&  this.calcWIPProdHistoricalCost_RU(inventCostListTrans.InventTransId, 
inventCostListTrans.VoucherPhysical))
            {
                continue;
            }
            // </GEEU>

            this.updateTransIdReceipt(inventCostListTrans.InventTransId,
                                      inventCostListTrans.Adjustment,
                                      inventCostListTrans.InventTransIdReturn,
                                      inventCostListTrans.VoucherPhysical);
        }

Без включенного расчета расширенной себестоимости (calculationProdWIP_RU = НЕТ) всегда выполняется метод updateTransIdReceipt(), который распределяет коррекцию inventCostListTrans.Adjustment на приходные проводки. В этом методе, после того как коррекция была добавлена к приходной проводке, эта проводка добавляется в мап mapInventTrans.insert(receipt.RecId,receipt). Дальше этот мап используется в методе updateReceiptAdjustment(), чтобы «распространить» коррекции, сделанные по приходным проводкам на сопоставленные с ними расходные проводки.

Если включен расширенный расчет себестоимости и приходная проводка имеет тип «Производство», то вызывается метод calcWIPProdHistoricalCost (), в нем вызывается написанная в RU5 логика, рассчитывается фактическая себестоимость расходов по производственному заказу, себестоимость выходов (побочной и основной продукции), делается коррекция приходов.

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

РЕШЕНИЕ

Нужно в конце метода ProdCalculatingWIPEngine_RU:: createAdjustSettlement() вызвать inventCostItemDim.updateInventTrans(_inventTrans):

    //+ DPL InventClosingFix_OK 11.02.2011 OK
    if (inventCostItemDim != null)
    {
        inventCostItemDim.updateInventTrans(_inventTrans);
    }
    else
    //- DPL InventClosingFix_OK 11.02.2011 OK
    _inventTrans.update();
}

Метод updateInventTrans() защищенный (protected), измените его на public:

//+ DPL InventClosingFix_OK 11.02.2011 OK
//protected void updateInventTrans(InventTrans _inventTrans)
public void updateInventTrans(InventTrans _inventTrans)
//- DPL InventClosingFix_OK 11.02.2011 OK
...

[Bega]

ПРОБЛЕМА 2. Неверная себестоимость расходов по побочной продукции.
Эта проблема очень похожа на предыдущую, но причина немного в другом. Рассмотрим на примере. Вся логика выполняется на 0-й итерации.

Есть продукция «какао-масло» и побочная «жмых», в расход идет «какао-тертое». На предыдущих шагах закрытия склада были сделаны коррекции «какао-тертого», то есть изменилась себестоимость расхода. Эта коррекция попала в таблицу inventCostListTrans, чтобы система переоценила стоимость связанных выходов «какао-масла» и «какао-тертого».

Далее система доходит до расчета «какао-масла», запускает расчет RU5, рассчитывается стоимость выхода основной и побочной продукции. Для побочной продукции локализаторы , в отличие от проблемы №1 сделали правильно – вызвали из своей логики метод updateTransIdReceipt(), который отразил коррекцию на приходе побочной продукции и добавил проводку в mapInventTrans, чтобы «распространить» коррекцию на сопоставленные расходные проводки.

Все бы было хорошо, если бы это не было 0-й итерации и самым первым расчетом для «какао-масла». На нулевой итерации в методе InventCostItemDim:: updateItem() запускается сопоставление по модели:

se = setInventDim.getEnumerator();
while (se.moveNext())
{
     inventDim = se.current();

     this.initMapInventTrans();
     this.load(inventDim);
     this.updateReceiptAdjustment();
     this.updateModel(inventDim);
}

При вызове this.initMapInventTrans() все сохраненные в mapInventTrans данные ОЧИЩАЮТСЯ, так что стоимость расходов по побочной продукции никогда не будет приведена в соответствие с приходами.

РЕШЕНИЕ

В методе InventCostItemDim:: updateItem() перед циклом сопоставления нужно вызвать updateReceiptAdjustment():

        else
        {
            // if this is not a closing, or if this is the first time, then match ..

            // first match issues and receipts that are marked
            this.updateSettleRefItem(inventCostList.ItemId);

            //+ DPL InventClosingFix_OK 12.02.2011 OK
            //если здесь не вызвать этот метод-не идут дальше коррекции по побочной продукции
            if (calculationProdWIP_RU)
                this.updateReceiptAdjustment();
            //- DPL InventClosingFix_OK 12.02.2011 OK

            // then match remaining issues and receipts according to inventory model
            if (! isServiceItem)
            {
                setInventDim = new Set(Types::Record);

                // find all financial dimension combinations
                queryRun = inventCostHelp.initQueryRunTrans(this.inventTable(inventCostList.ItemId),
 this.inventModelGroup(inventCostList.ItemId));
                while (queryRun.next())
                {
                    inventDim = queryRun.get(tablenum(InventDim));

                    setInventDim.add(inventDim);
                }

                // match issues and receipts per financial dimension combination
                se = setInventDim.getEnumerator();
                while (se.moveNext())
                {
                    inventDim = se.current();

                    this.initMapInventTrans();
                    this.load(inventDim);
                    this.updateReceiptAdjustment();
                    this.updateModel(inventDim);
                }

                setInventDim = null;
            }
        }

[Bega]

ПРОБЛЕМА 3. Все коррекции, сделанные по приходным проводкам с типом «Производство» при помощи коррекции проводок в форме «Закрытие и коррекция» отменяются!

При расширенном расчете себестоимости, который запускается из InventCostItemDim ::calcWIPProdHistoricalCost_RU после расчета стоимости основного выхода, себестоимость этого выхода корректируется в ProdCalculatingWIPEngine_RU ::createProdReceiptAdjust по формуле [коррекция] = [рассчитанная стоимость] – [текущая стоимость]. Таким образом, если вы перед закрытием распределили затраты на приходы из производства, то эти суммы будут успешно отменены и себестоимость выходов будет равна себестоимости расходов по производственному заказу.

РЕШЕНИЕ

На таблице InventTrans создайте метод:

// DPL InventClosingFix_OK 13.02.2011 OK
//расчет суммы коррекций добавленной распределением затрат
Amount calcManualCorrAmount_OK()
{
    InventSettlement            invSettlement;
    InventClosing               inventClosing;
    ;
    select sum(CostAmountAdjustment) from
        invSettlement
            where invSettlement.Cancelled == NoYes::No
               && invSettlement.TransRecId == this.RecId
    exists join
    inventClosing
        where inventClosing.Voucher == invSettlement.Voucher
           && inventClosing.AdjustmentType == InventAdjustmentType::Transaction;

    return invSettlement.CostAmountAdjustment;
}

В методе ProdCalculatingWIPEngine_RU::createProdReceiptAdjust() перед вызовом createProductionRecord вставьте:

//+ DPL InventClosingFix_OK 13.02.2011 OK
//отнимаем чтобы не отсторнировать распределение затрат
costAmount -= inventTrans.calcManualCorrAmount_OK();
//- DPL InventClosingFix_OK 13.02.2011 OK

ProdWIPHistoricalCostTable_RU::createProductionRecord(prodTable.ProdId,

[Bega]

ПРОБЛЕМА 4 . Есть проблемы с производительностью при расширенном расчете себестоимости.
Есть неоптимальные запросы, которые вызываются из логики, добавленной в RU5.
РЕШЕНИЕ.
Рекомендую добавить следующие индексы:
1. На таблице InventTrans по полям InventTransIdFather,DateFinancial.
2. На таблице InventTrans по полям TransRefId, TransType, DatePhysical.
3. На таблице ProdWIPHistoricalCostTable_RU по полю ReleaseRefRecId.
4. На таблице InventByProductTable_RU включить индекс на RecId.

[Bega]

ПРОБЛЕМА 5 . Не работает отмена закрытия или пересчета в пакетном режиме, если есть выделенный пакетный сервер.
Если делать отмену закрытия в пакетном режиме и указывать пакетную группу, система создает первую задачу с указанной пакетной группой, а все остальные, от которых зависит первая создает с пустой пакетной группой. Если на эту пустую группу не настроен ни один АОС, то она никогда не завершится.
РЕШЕНИЕ.
Если без доработок, то нужно добавить пустую пакетную группу к какому-либо серверу.

[fed]

Цитата:

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

ПРОБЛЕМА 5 . Не работает отмена закрытия или пересчета в пакетном режиме, если есть выделенный пакетный сервер.
Если делать отмену закрытия в пакетном режиме и указывать пакетную группу, система создает первую задачу с указанной пакетной группой, а все остальные, от которых зависит первая создает с пустой пакетной группой. Если на эту пустую группу не настроен ни один АОС, то она никогда не завершится.
РЕШЕНИЕ.
Если без доработок, то нужно добавить пустую пакетную группу к какому-либо серверу.

Вообще-то должна использоваться та группа пакетных заданий, которая указана в inventClosing.closeBatchGroupId. Очень подозреваю, что при программировании расширенного расчета себестоимости это не сломали и оно должно работать...

[Bega]

Цитата:

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

Вообще-то должна использоваться та группа пакетных заданий, которая указана в inventClosing.closeBatchGroupId. Очень подозреваю, что при программировании расширенного расчета себестоимости это не сломали и оно должно работать...

Эта проблема не связана с RU5.

[Bega]

Цитата:

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

Вообще-то должна использоваться та группа пакетных заданий, которая указана в inventClosing.closeBatchGroupId. Очень подозреваю, что при программировании расширенного расчета себестоимости это не сломали и оно должно работать...

Вы наверное имели в виду InventParameters.CloseBatchGroupId - это поле у нас заполнено, однако в связанных пакетных задачах все равно не было подставлено.

[fed]

Цитата:

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

Вы наверное имели в виду InventParameters.CloseBatchGroupId - это поле у нас заполнено, однако в связанных пакетных задачах все равно не было подставлено.

Извини - протормозил. Не заметил что ты про отмену закрытия пишешь.
В принципе - это не совсем баг, это скорее misfeature, заложенная датскими разработчиками...

[Ivanhoe]

Обнаружена такая проблема:
Производство не используется (отключена лицензия). При закрытии склада система пытается сделать какой-то расчет по производственным заказам (InventCostHelp.runProdWIPCalculation_RU()), при этом не находит номерной серии, которая должна быть настроена в параметрах модуля Производство и закрытие останавливается с ошибкой.
Я так понимаю, проверка на то, что вообще нужен этот расчет, должна быть до начала каких-либо действий. Стоит добавить проверку на конфигурационный ключ Prod или есть какой-то еще признак, который позволит это сделать?

[Bega]

Цитата:

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

Обнаружена такая проблема:
Производство не используется (отключена лицензия). При закрытии склада система пытается сделать какой-то расчет по производственным заказам (InventCostHelp.runProdWIPCalculation_RU()), при этом не находит номерной серии, которая должна быть настроена в параметрах модуля Производство и закрытие останавливается с ошибкой.
Я так понимаю, проверка на то, что вообще нужен этот расчет, должна быть до начала каких-либо действий. Стоит добавить проверку на конфигурационный ключ Prod или есть какой-то еще признак, который позволит это сделать?

Можно вставить в методе:

    ..
    if (masterClient 
        && CompanyInfo::features_W() == CRSEFeatures_W::RU
        //+DPL
        && isConfigurationkeyEnabled(configurationkeynum(Prod))
        //-DPL
        )
    {
    ...

[Ivanhoe]

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

[Bega]

Цитата:

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

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

Да, локализаторы в 5-м роллапе допустили много ошибок, как-то в попыхах все, на бегу

[fed]

Цитата:

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

Да, локализаторы в 5-м роллапе допустили много ошибок, как-то в попыхах все, на бегу

Причем бежали всем колхозом
Я после этого предпочитаю одиночные забеги...

[Alexius]

Ну раз пошла такая пьянка

Отмена закрытия склада при отключенном ключе двух-валютного склада пропускает удаление проводок SummedUp со всеми вытекающими вкусностями

Class / InventCostClosingCancel_WorkInvent / deleteVirtualTransfers

...
    while select forupdate inventTrans order by InventTransId
    where inventTrans.ValueOpen             == InventTransOpen::Yes
       // <GEEU>
//       && inventTrans.ValueOpenSecCur_RU    == InventTransOpen::Yes 
       && inventTrans.ValueOpenSecCur_RU    == (isConfigurationKeyEnabled(configurationkeynum(InventClosingSecCur_RU)) ?
                                                    InventTransOpen::Yes : InventTransOpen::No) 
       // </GEEU>
...

На SQL по закрытому ключом полю уходит условие 1=0 и ...

PS. Интересно, много ли еще таких мест ?

[EVGL]

Bega, а вы с Microsoft по поводу этих багов связались? Как-то не хотелось бы править из версии в версию.

[Bega]

Цитата:

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

Bega, а вы с Microsoft по поводу этих багов связались? Как-то не хотелось бы править из версии в версию.

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

[Bega]

Цитата:

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

Ну раз пошла такая пьянка

Отмена закрытия склада при отключенном ключе двух-валютного склада пропускает удаление проводок SummedUp со всеми вытекающими вкусностями

Class / InventCostClosingCancel_WorkInvent / deleteVirtualTransfers

PS. Интересно, много ли еще таких мест ?

Мне кажется тут надежней вот так, чтобы вообще не важно было, как система обрабатывает отключенные конфигурацией поля:

...
  while select forupdate inventTrans order by InventTransId
    where inventTrans.ValueOpen             == InventTransOpen::Yes
       // <GEEU>
       //+ DPL InventClosingFix_OK 28.02.2011 OK
       //inventTrans.ValueOpenSecCur_RU    == InventTransOpen::Yes)
       && (  !isConfigurationKeyEnabled(configurationkeynum(InventClosingSecCur_RU))
           || inventTrans.ValueOpenSecCur_RU    == InventTransOpen::Yes)
       //- DPL InventClosingFix_OK 28.02.2011 OK
...

[maxk]

Цитата:

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

ПРОБЛЕМА 5 . Не работает отмена закрытия или пересчета в пакетном режиме, если есть выделенный пакетный сервер.
Если делать отмену закрытия в пакетном режиме и указывать пакетную группу, система создает первую задачу с указанной пакетной группой, а все остальные, от которых зависит первая создает с пустой пакетной группой. Если на эту пустую группу не настроен ни один АОС, то она никогда не завершится.
РЕШЕНИЕ.
Если без доработок, то нужно добавить пустую пакетную группу к какому-либо серверу.

Это должны были поправить в последних роллапах.


Отличная тема.
Попросил соответствующих людей чтоб посмотрели что тут описано.

[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;
}