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

[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(...))

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

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

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