Announcements
Hi All,
A Customer contacted us with a Problem. They have a significant difference between inventory value and corresponding gl account.
i tracked it down and got to the Point where i could find the origin of that difference.
in may they did a inventory recalculation, and the sum of the adjustment postings exactly matched the difference between inv value and gl account Balance.
Strangely they reversed the recalculation once and redid it. Now i reversed all of the recalculations back to may, including the one in question and yet we still have the different values.
All the recalculations were as of May 31st. For May 30th, inventory value report and gl account Balance STILL SHOW THE SAME AMOUNT!!!
what could be the reason for it? configuration issue?
best regards.
ruben
*This post is locked for comments
Hi Ruben,
I have same issue here, but i don't have missing recalculation voucher like you have.
Try to cancel and redo recalculation but still got the same result.
Hopefully you have this solved and share the solution. I suspect those are only because of rounding issue as the difference is very small, less than 60, but still it should by the same by nature.
I will also share if i come up with the solution
Cheers,
Albert
Hiii all..
Iam facing the same problem and found this topic and went through all the discussions and surely i will try the same @Ruben (last code mentioned).
Just wanted to add that
"Recalculation voucher stuck at my end because the "FINANCIAL PERIOD" was on hold and after opening the financial period system is not allowing me to either "resume recalculation" or "cancel the recalculation".
Therefore as a precaution first check whether financial period is open or not for recalculation date.
@Magic we have also had discussion on same topic through below mentioned question.
"inventory recalculation error (update cancelled and deleted)"
thanks.
Thanks Muthusamy.
MS Support corrected their Statement after checking back with escalation engineer.
i now commented out the following:
InventCostCLosingCancel_End/execute
protected void execute()
{
setPrefix("@SYS17508");
// Check if I am allowed to proceed
if (this.checkStatus())
{
this.openPreClosedInventTrans();
/*
// Create the ledger postings
// <GEERU>
if (inventTransCurrency == InventTransCurrency_RU::PrimaryCur)
{
this.updateLedger();
}
else
{
this.updateLedgerSecCur_RU();
}
// </GEERU>
*/
// Get rid of all the virtual transfer records that might have been created
// during inventory closing
this.deleteVirtualTransfers();
// Now update the records
this.updateInventClosing();
this.updateCancelClosing();
// <GEERU>
this.cancelNextWIPCalculations_RU();
// </GEERU>
// Remove the inventCostTransSum records that have not been removed yet
InventCostTransSumCalcCancel::cancelFromInventClosing(cancelClosing);
}
this.writeInfoLog();
IT WORKS!
this is a screenshot as of 31st of May 2016 (the date in Question)
so thanks to everybody (including MS) for their Input.
Hi Ruben,
InventCostHelp\updateLedgerPosting is the class which is used to create the ledger posting for inventory recalculation or cancellation process.
I guess only you need to pass parameter value as "False" in the below mentioned code. Hope it will work.
// Post to ledger
if (inventClosing.Ledger)
{
inventAdjustPost.updateNow(ledgerVoucher, true);
}
Hope it will works.
After commenting or changing the code, do the Incremental CIL and then cancel the recalculation process.
Thanks,
Thanks all for the very constructive discussion. Magic, i guess having experience in this area, is very valueable especially since even most Consultants are a bit helpless with the issue.
UPDATE:
Microsoft Support DID give us a Suggestion. We re just about to test it.
- Creating the Voucher in InventClosing Table (with the correct Date)
- Commenting out the code, that Posts/updated the GL Account 1010
- Cancelling the Recalculation
I did run this once, the Inventory value was CORRECT after, but unfortunately it also updated the GL Account so the difference was the same. So we re looking for the CODE where recalculation gets postet to the GL Account.
Any Ideas ? Microsoft came up with the InventCostHelp\updateLedgerPosting it didnt work but i will retry.
My last advice is that I consider it very bad practise, albeit common, to not run inventory close monthly.
The sort of error you discovered typically occurs because of this. That may seem patronising but it practical experience - for many years a large chunk of my consulting revenue has come from sorting out such problems.
To quote TechNet: " ...Since inventory recalculation can be run on a subset of items, and because inventory recalculation will not make an adjustment for less than the throughput amount, it is not as accurate as an inventory close and should not be relied on to replace inventory close."
and
"When you click the Transaction button in the Settlements for voucher form, you will not see the associated receipt transaction as you do for inventory close. The form will show you the adjustments that were made, but you will only see adjustments for the issue transaction."
Inventory close will mark receipts to issues, which recalculation does not do. This means inventory close (when you finally do it) can change which receipts are used to cost an issue.
Recalculation puts all the items that are to be processed into a queue, and then stores the queue in the InventCostList table. It then processes each item from that queue sequentially, and makes a "virtual" settlement between individual receipts and issues for the item according to the Inventory Model Group such as FIFO, Weighted Average. This is a "virtual" settlement because it occurs only in the Recalculation's calculations. However, the detailed settlement data that shows the explicit matching of each issue to the various receipts is not stored in the InventSettlement table. The only data that is stored is the cost adjustment that is made to the issue.
When you do not close the inventory, the recalculation will recalculate from an older past period, for example, if the last inventory closing was in January 2016, then the recalculation starts calculate from then.
During the recalculation, the current inventory transaction will also recalculate the Cost (COGS), and so when the recalculation periods start from a long time back, it will make Ax will be slow while doing inventory transactions such as receive good, picking list, packing slip and, sales invoice.
Hi Ruben,
I do agree with Ludwig here. By the way: great catch!! There should be a reason why you speak of a "former partner". According to all best practices and accounting rules, posted vouchers may not be deleted manually. I doubt if Microsoft will guide you how to do data corrections as they are supporting the product, but not the data.
So like Ludwig mentioned, the best would be get the missing vouchers back or have the InventSettlement aligned as well. For sure only with new data manipulation it can be corrected. Start in a copy of the production environment to test it carefully. Like Ludwig mentioned: get help from experienced persons. Inventory transactions and ledger integration and also related recalculations and closings are not easy. Well one thing about this is easy here as you might have noticed... cripple the data.
Hello Ruben,
That's a very good question how to get this fixed correctly :-)
Do you know if the customer has a database backup that includes the deleted vouchers?
If that is the case, can you obtain the debit and credit accounts used for that voucher?
Provided that the overall variance between GL and inventory that you identified is not 'material' it might be ok for the company's auditors to post a manual GL accrual transaction to account for that difference. This is something you would need to clarify with the customer. Yet, in this case the difference that your reports identified would exist forever. The advantage would be that this is probably the simplest and fastest way to go forward.
If the customer is not ok with this GL correction approach you would somehow require a technical solution where you bring back the deleted vouchers from a backup. That might be quite difficult and you need the help of MS and some very experienced developer how to realize that. I am not the technical expert who can help you with that but probably the one or the other community member here.
Other than that, I would appreciate if you could keep us updated here on what was decided to get this issue resolved.
Many thanks and best regards,
Ludwig
So, i have now found the Problem. I exported the Report for Adjustments and filtered for the day in Question, and Cancelled = false. There were 3 recalculation voucher id's which did not exist in the System, there were deleted manually (AOT or Database)
see how *84-*86 are missing? But in the AOT Table inventSettlement, the records STILL EXIST and did not have the Checkbox "Cancelled" marked.
By the Looks of it, a former Partner of our Customer somehow deleted those vouchers as a work around, when the customer had a Problem closing the recalculation.
We are working with Microsoft on a clean and effective way to reverse thoose 3 vouchers.
Ludwig Reinhard do you have suggestions how to correct this in regards to best german finance practices ? :)
Hi Ludwig
just to clarify, we re not talking about an inventory CLOSE, only a recalculation, the Close is only done at the end of the year (by customers choice) , as i mentioned the recalculation was done 4 times, and reversed 4 times, the last voucher (LRB0000116) is done by myself.
We have opened a case with Microsoft, we re talking AX2012 R2 !!!
as you see, the origin of Transaction is simply a whole load of revaluations.
André Arnaud de Cal... 291,280 Super User 2024 Season 2
Martin Dráb 230,253 Most Valuable Professional
nmaenpaa 101,156