Но это далеко не все артефакты вторичного закрытия в валюте, на одном приложении делал вот такие исправления в DAX2012 R3, думаю в AX2009 такая же беда
InventCostItemDim\updateReceiptAdjustmentTrans
X++:
while select forceplaceholders pessimisticlock
#settlementFieldList from settlementReceipt
index hint RecIdTypeIdx
where settlementReceipt.TransRecId == _receipt.RecId
&& settlementReceipt.SettleType == InventSettleType::Receipt
&& settlementReceipt.InventTransId == _receipt.inventTransOrigin().InventTransId
// <GEERU>
&& (!countryRegion_RU || settlementReceipt.InventTransCurrency_RU == inventTransCurrency)
// </GEERU>
&& settlementReceipt.Cancelled == 0
&& settlementReceipt.QtySettled > 0
join forupdate
#settlementFieldList from settlementIssue
index hint TransactionIdx
where settlementIssue.SettleTransId == settlementReceipt.SettleTransId
&& settlementIssue.SettleType == InventSettleType::Issue
//+ sn
//// <GEERU>
//&& (!countryRegion_RU || settlementReceipt.InventTransCurrency_RU == inventTransCurrency)
//// </GEERU>
&& (!countryRegion_RU || settlementIssue.InventTransCurrency_RU == inventTransCurrency)
//- sn
&& settlementIssue.Cancelled == 0
&& settlementIssue.QtySettled < 0
InventCostItemDimSecCur_RU\updateReceiptAdjustmentTrans
X++:
...
if (adjustment &&
(abs(adjustment) < inventClosing.MinTransferValue ||
(_receipt.CostAmountSecCurAdjustment_RU - _adjustmentLater == 0 &&
//+ sn
// Currency::amount(_receipt.CostAmountSettledSecCur_RU / _receipt.QtySettled) == Currency::amount(costAmount / _receipt.QtySettled))))
Currency::amount(_receipt.CostAmountSettledSecCur_RU / _receipt.QtySettledSecCur_RU, secondaryCurrency) == Currency::amount(costAmount / _receipt.QtySettledSecCur_RU, secondaryCurrency))))
//- sn
...
while select forceplaceholders pessimisticlock
#settlementFieldList from settlementReceipt
index hint RecIdTypeIdx
where settlementReceipt.TransRecId == _receipt.RecId
&& settlementReceipt.SettleType == InventSettleType::Receipt
&& settlementReceipt.InventTransId == _receipt.inventTransOrigin().InventTransId
&& settlementReceipt.InventTransCurrency_RU == inventTransCurrency
&& settlementReceipt.Cancelled == 0
&& settlementReceipt.QtySettled > 0
join forupdate
#settlementFieldList from settlementIssue
index hint TransactionIdx
where settlementIssue.SettleTransId == settlementReceipt.SettleTransId
&& settlementIssue.SettleType == InventSettleType::Issue
//+ sn
//&& settlementReceipt.InventTransCurrency_RU == inventTransCurrency
&& settlementIssue.InventTransCurrency_RU == inventTransCurrency
//- sn
&& settlementIssue.Cancelled == 0
&& settlementIssue.QtySettled < 0
...
//+ sn
//settleValue = Currency::amount(settleValueDec, secondaryCurrency);
//
//if (abs(settleValueDec) < abs(settleValue))
//{
// settleValue += (settleValueDec > 0 ? -roundOffunit : roundOffunit);
//}
if (abs(settleValueDec) > abs(roundOffunit))
{
settleValue = Currency::amount(settleValueDec, secondaryCurrency);
}
else
{
settleValue = sign(settleValueDec) * roundOffunit;
}
//- sn
InventCostItemDimSecCur_RU\updateItemReturnAdjustments()
X++:
public void updateItemReturnAdjustments(ItemId _itemId = inventCostList.ItemId)
{
...
this.updateTransKeyAdjust(); //sn
}
InventCostItemDimSecCur_RU\financialOpenValue
X++:
//+ sn
//CostAmount costAmount = _inventTrans.isUpdatedFinancial() ? _inventTrans.financialOpenValueSecCur_RU() : _inventTrans.CostAmountSecCurPhysical_RU;
CostAmount costAmount = _inventTrans.isUpdatedFinancial() && _inventTrans.DateFinancial <= inventClosing.TransDate ? _inventTrans.financialOpenValueSecCur_RU() : _inventTrans.CostAmountSecCurPhysical_RU;
//-sn
+
Разница InventSplitTrans и InventSplitTrans_Remain
Но самым интересным квестом оказался следующий :
1. Если у вас используется две модели по средней(для первичного и для вторичного), то когда вы запускаете вторичное закрытие виртуальный перенос по средней созданный в рамках первичного закрытия становится Нефинансовым (рвётся маркировка между лотами) со всеми вытекающими последствиями.
2. В результате такой ошибки при начислении НР за прошлые периоды все проводки зависают на средней и не корректируют связанные расходы.