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

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

Цитата:

Сообщение от 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

[b_nosoff]

Цитата:

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

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

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

[Logger]

Коллеги, отмена пересчетов по складу требует, чтобы отменялся сперва последний пересчет, потом предпоследний и.т.д.
Обязательно ли это ?
Если да, то получается что при пакетной отмене пересчетов содержится ошибка. Там не учитывается этот порядок.

см. метод
\Classes\InventCostClosingCancel_Init\execute
там сперва перебираются записи в InventClosing в правильном порядке (по убыванию InventClosing.transDate)
Для каждого InventClosing перебираются записи в InventSettlement и для каждой номенклатуры создается своё пакетное задание по отмене сопоставлений (класс InventCostClosingCancel_WorkInvent) в таблице Batch

Но при этом никаких зависимостей между созданными пакетными заданиями InventCostClosingCancel_WorkInvent, учитывающими порядок следований InventClosing не создается.

Из-за этого отмена пересчетов по конкретным InventSettlement может идти в произвольном порядке.

[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> в данном методе на тестовом приложении. Но даже с ним зависшие проводки не уходят...

[Bega]

Цитата:

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

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

А в вашей средневзвешенной расходной проводке, которая пропускается, чему равны CostAmountPosted и CostAmountAdjustment?

[zelibobis]

оба по 0

[Bega]

Цитата:

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

оба по 0

Получается у вас расходная средневзвешенная проводка прошлого периода оказалась почему-то открытой. Это именно проводка прошлого периода? Какая у нее финансовая дата? Она и перед закрытием тоже открыта? Или оказывается открытой в процессе закрытия из-за корректировки приходов прошлого месяца?

Если это средневзвешенная расходная проводка прошлого периода, то по логике она и не должна сопоставляться со средневзвешенным приходом этого периода, а именно это происходит в указанном куске кода.

Мне кажется нужно сначала выяснить, почему эта проводка оказалась открытой.

[zelibobis]

Да, проводка прошлого периода, более того таких проводок довольно много по разным номенклатурам. Мне кажется это как раз последствие не корректного метода currencyTransfer_RU - так как из-за него оставались открытые и приходы и расходы с типом "Средневзвешенное закрытие запасов". Вопрос теперь как с этим жить дальше? После фикса currencyTransfer_RU - все новые создаваемые "Средневзвешенное закрытие запасов" будут сопоставляться корректно. Но вот что делать со старыми проводками прошлых периодов?

[Bega]

Цитата:

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

Да, проводка прошлого периода, более того таких проводок довольно много по разным номенклатурам. Мне кажется это как раз последствие не корректного метода currencyTransfer_RU - так как из-за него оставались открытые и приходы и расходы с типом "Средневзвешенное закрытие запасов". Вопрос теперь как с этим жить дальше? После фикса currencyTransfer_RU - все новые создаваемые "Средневзвешенное закрытие запасов" будут сопоставляться корректно. Но вот что делать со старыми проводками прошлых периодов?

Первое, я бы попробовал модифицировать код, чтобы эти проводки в этом периоде были все-таки сопоставлены, потом убрать модификацию. Другой вариант - джобом через doUpdate() проставить дату "Финансовое закрытие", флаг "Открытое значение" = Нет, "Сопоставленное количество" и "Сопоставленная сумма" в значение по сумме сопоставлений. Это чтобы эти проводки не участвовали больше в закрытии.

[zelibobis]

Спасибо. Попробую.

[Bega]

Цитата:

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

Спасибо. Попробую.

Обнаружил у себя такую же проблему. Некоторые номенклатуры у нас двигаются с нулевой стоимостью. Для части таких проводок сопоставление не работает и проводки постоянно висят открытыми.

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

Причина, как и в прошлые разы оказались российские модификации расчета средневзвешенной стоимости в методе InventCostItemDim::updateModelAverage().
Там есть три условия, где идет проверка метода this.currencyTransfer_RU(). Не знаю, чего хотели локализаторы, но работает не верно.
Итак.

РЕШЕНИЕ ПРОБЛЕМЫ 6 (ВЕРСИЯ 2)

Нужно все эти три проверки this.currencyTransfer_RU() убрать из метода InventCostItemDim::updateModelAverage()., то есть в этих трех условиях if() вернуть все к слою syp.
УДАЛИТЬ:

УДАЛИТЬ и ВЕРНУТЬ (выделено зеленым).

УДАЛИТЬ и ВЕРНУТЬ (выделено зеленым).


С этой модификацией я закрыл ноябрь и у нас не было выдано ни одной ошибки про сопоставления, все висевшие несколько месяцев несопоставленные проводки были сопоставлены.

[Bega]

Цитата:

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

Первое, я бы попробовал модифицировать код, чтобы эти проводки в этом периоде были все-таки сопоставлены, потом убрать модификацию. Другой вариант - джобом через doUpdate() проставить дату "Финансовое закрытие", флаг "Открытое значение" = Нет, "Сопоставленное количество" и "Сопоставленная сумма" в значение по сумме сопоставлений. Это чтобы эти проводки не участвовали больше в закрытии.

По поводу закрытия проводки джобом, делать так НЕ нужно. Если что-то несопоставлено, нужно искать причину и исправлять ее, иначе проблема так и будет тянутся из месяца в месяц и может вылезти, когда на конец периода остаток будет нулевым, а сумма ненулевая (были уже темы по этому поводу).

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

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

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

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