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

[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, заложенная датскими разработчиками...

[maxk]

Цитата:

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

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

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


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

[b_nosoff]

Цитата:

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

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

кмк, эту проблему можно глобально решить в классе BatchHeader - при добавлении новой задачи к шапке инициализировать у нее batchGroupId (вообще непонятно, почему этого нет в базовой комплектации ))

[vallys]

Цитата:

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

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

При суммировании сумм сопоставлений следует добавить еще тип корректировки "В наличии" (InventAdjustmentType::InventOnHand). Иначе при калькуляции ПЗ после "уценки/дооценки" (корректировка в наличии), сначала будет "отмена", а затем повторная коррекция на сумму "уценки/дооценки", только возможно (в зависимости от настроек) с другим корр. счетом (из InventAdj::errorAccountOperations(...))

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

Только при "доукомплектации ПЗ" аналогичная проблема все равно останется

т.е. вместо

    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;

следует использовать

    select sum(CostAmountAdjustment)
        from inventSettlement
        where inventSettlement.Cancelled   == NoYes::No
        &&    inventSettlement.TransRecId  == this.RecId
    exists join inventClosing
        where inventClosing.Voucher        == inventSettlement.Voucher
        &&    inventClosing.TransDate      == inventSettlement.TransDate
        &&   (inventClosing.AdjustmentType == InventAdjustmentType::Transaction
        ||    inventClosing.AdjustmentType == InventAdjustmentType::InventOnHand);

[Bega]

Цитата:

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

При суммировании сумм сопоставлений следует добавить еще тип корректировки "В наличии" (InventAdjustmentType::InventOnHand). Иначе при калькуляции ПЗ после "уценки/дооценки" (корректировка в наличии), сначала будет "отмена", а затем повторная коррекция на сумму "уценки/дооценки", только возможно (в зависимости от настроек) с другим корр. счетом (из InventAdj::errorAccountOperations(...))

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

Только при "доукомплектации ПЗ" аналогичная проблема все равно останется

Согласен, это если ПЗ рассчитывается в двух отчетных периодах, у меня таких ситуаций нет.