Странное поведение при закрытии склада-ошибка в коде?

[Aquarius]

Добрый день, подскажите пожалуйста:
Акс 2009. Sp 5
Настройки Группа складских аналитик:
1.1 активный включено аналитики склад, партия, паллета, ячейка-
1.2. физ. наличие включено для аналитик склад, партия, паллета, ячейка,
1.3 .первичные аналитики -склад
1.4. финансовый склад включен для аналитик склад.
Настройки Группа складских моделей:
1.1. Складская модель ФИФО
Включены настройки:
1.2. Отрицательный физ склад,
1.3. Отрицательный фин склад,
1.4. Заказ на отгрузку,
1.5. Разносить физ операции,
1.6. Разносить фин операции,
1.7. Резервирование- контроль по дате.

У нас возникла следующая ситуация -некорректно проставляется корректировка сторно заказа при закрытии склада.
Заказ первоначально проведен и отсторнирован апрелем, затем повторно проведен и осторнирован в мае , затем окончательно проведен в мае.
1.до закрытия апреля
проводки
1.1. 30.04.2013 заказ 1698 продано -2000 шт сумма -146400 грв.
1.2. 30.04.2013 заказ 1698 куплено 2000 шт сумма 146400 грв.
1.3. 07.05.2013 заказ 1698 продано -2000 шт сумма -146400 грв.
1.4. 07.05.2013 заказ 1698 куплено 2000 шт сумма 146400 грв.
1.5. 07.05.2013 заказ 1698 продано -2000 шт сумма -146400 грв.
2. после закрытия апреля (ФИФО)
2.1. 30.04.2013 заказ 1698 продано -2000 шт сумма -20294,6 грв. полностью финансово закрыта проводка
2.2. 30.04.2013 заказ 1698 куплено 2000 шт сумма 81347,3 грв. проводка открыта
2.3. 07.05.2013 заказ 1698 продано -2000 шт сумма -146400 грв.
2.4. 07.05.2013 заказ 1698 куплено 2000 шт сумма 146400 грв.
2.5. 07.05.2013 заказ 1698 продано -2000 шт сумма -146400 грв.
если сделать пересчет в мае ( например 7 мая),то проводка 2.2 становится корректной, там итоговая сумма получается 20294,6.
перечень всех складских проводок по данной номенклатуре до закрытия и после закрытия привожу в ексель. там по 45 строк.
Мы планируем ежемесячно переоценивать складские запасы через корректировку в наличии путем указания процента изменения себестоимости- для всех номенклатур одинаковый процент изменения.
Данная складская проводка 2.2 вылазит в в открытые , должна быть переоценена вместе с другими.Но у нее абсолютно неправильная себестоимость. Если мы эту проводку переоценим через корректировку в наличиии,то последующие пересчеты себестоимости ее уже никак не затронут. Поэтому нам очень нужна правильная себестоимость в этой проводке на конец месяца.

Я обнаружила ,анализируя закрытие склада для данной номенклатуры в дебагерре, что в методе updateTransIdReturnReceipt класса InventCostItemDim
вызывается из :
[s] \Classes\InventCostItemDim\updateTransIdReceipt
[s] \Classes\InventCostItemDim\updateLevelAdjustment
[s] \Classes\InventCostItemDim\updateItem

при выборе расходных проводок , исходя из которых должна рассчитаться цена приходной проводки, нет ограничения по финансовой дате расходной проводки . (которое есть при выборе приходных проводок )
таким образом в моем случае при закрытии склада апреля при расчете цены для приходной проводки сторно заказа берутся две расходные проводки:
одна из апреля -2000 штук сумма -146400 грв уже имеет корректировку 126105,4 (корректировка рассчитана ранее в момент закрытия склада)
а другая из мая. -2000 штук -146400 грв
и получается некорректная цена (-146400-146400+126105,4)/4000 штук=41,67
которая и протягивается в приходную проводку сторно заказа и создает неправильную сумму 81347,3 грв.

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

Я обнаружила,что если поставить в коде в данном методе (см ниже отмечено комментариями TEMP) ограничение по финансовой дате расходной проводки,
то для приходной проводки сторно заказа выберется только одна расходная проводка :
30.04.2013 -2000 штук сумма -146400 грв уже имеет корректировку 126105,4
и получится цена (-146400+126105,4)/2000 штук=10,15
которая протянется в приходную проводку сторно заказа и создаст правильную сумму 20294,6 грв.

Подскажите, пожалуйста:
Почему не стоит такое ограничение по финансовой дате расходной проводки? Возможно есть ли случаи, в которых важно чтобы этого ограничения не было?
Можем ли мы у себя поставить такое ограничение, если мы будем всегда использовать ФИФО?
Проверила в Акс3, там тоже такого ограничения нет.

protected void updateTransIdReturnReceipt(
InventTransId _inventTransId,
InventTransId _inventTransIdReturn,
Price _costPrice = 0 // if 0 then it will be recalculated
)
{
InventTrans receipt;
InventTrans issue;
CostAmount adjustNow;

boolean onHandIsAdjusted;
;



if (!_inventTransId || !_inventTransIdReturn)
return;

if (!_costPrice)
{
select sum(Qty), sum(CostAmountAdjustment), sum(CostAmountPosted) from issue
index hint TransIdIdx
where issue.InventTransId == _inventTransIdReturn &&
issue.StatusReceipt == StatusReceipt::None &&
issue.StatusIssue == StatusIssue::Sold &&
issue.PackingSlipReturned == 0 &&
issue.InventTransIdReturn == _inventTransId
//TEMP
&&issue.DateStatus <= inventClosing.TransDate;
//TEMP

if (!issue.Qty )
return;

_costPrice = (issue.CostAmountPosted + issue.CostAmountAdjustment) / issue.Qty;
}

onHandIsAdjusted = InventAdj::isOnhandAdjusted(_inventTransId, _inventTransIdReturn, '');

while select forupdate receipt
index hint TransIdIdx
where receipt.InventTransId == _inventTransId &&
receipt.StatusReceipt == StatusReceipt::Purchased &&
receipt.StatusIssue == StatusIssue::None &&
receipt.PackingSlipReturned == 0 &&
receipt.InventTransIdReturn == _inventTransIdReturn &&
receipt.DateStatus <= inventClosing.TransDate
{
adjustNow = Currency::amount(receipt.Qty * _costPrice - receipt.CostAmountPosted - receipt.CostAmountAdjustment,standardCurrency);

if (adjustNow)
{
receipt.CostAmountAdjustment += adjustNow;

this.createAdjustSettlement(receipt, adjustNow, '');

// The adjustment for a std cost item will always be
// reverted to bring the item cost down to std cost
// So there is no need to create an adjustment.
/* <SYS>
if (!this.inventModelGroup(receipt.ItemId).inventModelType().stdCostBased())
</SYS> */
// <GEEU>
if (! this.inventModelType_RU(receipt.ItemId).stdCostBased())
// </GEEU>
{
if (onHandIsAdjusted)
{
this.createErrorAdjustment(receipt, -adjustNow);
}

if (this.costValue(receipt) < 0)
this.createErrorAdjustment(receipt, -adjustNow);

if ((inventClosing.AdjustmentType == InventAdjustmentType::Closing) &&
(abs(adjustNow) < inventClosing.MinTransferValue || inventClosing.NumOfIteration >= inventClosing.MaxIterations))
{
this.createErrorAdjustment(receipt, -adjustNow);
}
}
else
{
/* <SYS>
this.inventModelGroup(receipt.ItemId).inventModelType().postUpdateFinancialAdjustment(receipt, inventClosing.Voucher, inventClosing.TransDate, adjustNow);
</SYS> */
// <GEEU>
this.inventModelType_RU(receipt.ItemId).postUpdateFinancialAdjustment(receipt, inventClosing.Voucher, inventClosing.TransDate, adjustNow);
// </GEEU>
}

this.updateCostAmountStd(receipt);
receipt.update();
}

mapInventTrans.insert(receipt.RecId, receipt);



}
}