bug in cost adjustment batch. (transfers and rounding)

Phenno

I have found pretty strange problem with adjust cost - item entries batch.

yes, there are a lot of problems with this batch but I haven't found any report here (nor on mbs.microsoft.com) about this.

To recreate this problem do next:

1) create an item called ITEM (or whatever).
2) create positive adjustment of this item to location A as follows:
3 pcs with total amount = 10 (so, item will get 3,33).

3) create transfer if 1pcs of ITEM from A to B location.
4) create transfer (again) of 1pcs of ITEM from B to A.

5) now, you have 3pcs of ITEM in location A again, but splitted to 2 Item Ledger Entries. Create another transfer of all 3 pcs from A to location C.
6) finally, create negative adjustment of ITEM => all 3 pcs from location C.

Run adjust cost batch if you want, now.


The problem happens if you:
run revalorisation of FIRST positive adjustment.
make revalorisation journal of first positive adjustment and make total amount not 10 but 10,02. (only 0.02 positive amount is added).

If you run Cost adjust NOW, it will gave amount 0.02 to all entries (which is regular to do) BUT
it will add an extremly strange Rounding amount at the and with amount of 6,67 (???) to first Positive Adjustement.

This recreation is made by me but our client had this situation with different amounts, and got positive adjustment with amount of 8.000 which is huuuge problem.


I found that the problem is in Inventory Adjustement Buffer thath holds all adjustment entries that happens in Adjust Cost. At the end, rounding entries are made by checking total amount for positive adjustments from here and Item Ledger entries and post rounding if difference is found. Problem is that in Inventory adjustment, for this positive adjustment Item Ledger Entry, there is one extra entry that shouldn't be there and value for it is 6,67 (for first test example) and 8.000 (for my real problem).

I check it out, Navision 4.0 does not have this problem but inventory costing is pretty much changed in 4.0. I have almost all hot-fixes for 3.60, including one that "clears a problem with strange rounding values"...

kine

Which version and Hotfix you are using?

Phenno

kine wrote:

Which version and Hotfix you are using?

which version of what? Navision? 3.60.
Inventory Adjustment (codeunit 5895) has NAVW13.60.00.27,L3.13
(L3.13 is irelevant in this case).

I found another thing. After adjust cost batch, if I manually check "Applied Entry for Adjust" on that Item Ledger Entry and than run Adjust Cost, it corrects that ugly rounding entry.

jreynolds

There is code near the end of the CalcAdjustedCost function in codeunit 5895 that looks like

  IF (ItemLedgEntryNo <> ItemApplnEntry."Transferred-from Entry No.") THEN
    UpdateInvtAdjmtBuffer(ItemApplnEntry."Inbound Item Entry No.",NewAdjustedCost[4],NewAdjustedCostACY[4]);

The first line should be changed to

  IF (ItemLedgEntryNo <> ItemApplnEntry."Transferred-from Entry No.") AND (LevelNo[3] = 0)  THEN

Phenno

jreynolds wrote:

There is code near the end of the CalcAdjustedCost function in codeunit 5895 that looks like

  IF (ItemLedgEntryNo <> ItemApplnEntry."Transferred-from Entry No.") THEN
    UpdateInvtAdjmtBuffer(ItemApplnEntry."Inbound Item Entry No.",NewAdjustedCost[4],NewAdjustedCostACY[4]);

The first line should be changed to

  IF (ItemLedgEntryNo <> ItemApplnEntry."Transferred-from Entry No.") AND (LevelNo[3] = 0)  THEN

Is this an official solution or custom (yours or someones)?

Thanx for reply, we did look at this line but... was not sure if we should stop cost forwarding at some point (level)...

jreynolds

This is not an official solution; it is my fix. I tracked this same problem down a week ago in 3.70. I also checked in 4.00 and observed that the problem does not occur and this is because that line of code has been replaced by a function call:

IF AdjustAppliedCostEntry(ItemApplnEntry,InbndItemLedgEntryNo,Recursion) THEN

If you look into that function you will see that it returns TRUE only if there is no recursion. This is exactly what (LevelNo[3] = 0) does in my fix.

Phenno

jreynolds wrote:

This is not an official solution; it is my fix. I tracked this same problem down a week ago in 3.70. I also checked in 4.00 and observed that the problem does not occur and this is because that line of code has been replaced by a function call:

IF AdjustAppliedCostEntry(ItemApplnEntry,InbndItemLedgEntryNo,Recursion) THEN

If you look into that function you will see that it returns TRUE only if there is no recursion. This is exactly what (LevelNo[3] = 0) does in my fix.

Ok. I'm testing this and will reply in few minutes or so..

Phenno

Seems that your solution fixed my problem too. Is there a special reason why should adjustment buffer not include transfer "sub"-entries?

Thanx for reply, as for me, this problem is solved. (I notices that in subjects, someone can change it to [SOLVED] but I'm not sure if I (as opener of thread) can...

Tatjana.si

We have the same strange rounding amounts but considering production orders and consumption entries and output entries. Is your solution applicable for my case please?
Thanks.

Tatjana.si

Another one:
Is there any possibility to automatically correct those wrong rounding entries? Something like put check marks to field Applied Entry to Adjust on those wrong entries, or on all entries...and do the adjustment batch job?
Any idea how to fix those entries??

Phenno

I haven't tried this on production/consumption ledgers so...

I thing that, after you setup right solution for this and run Item Adjust, ledgers should be corrected automatically cause sum of inbound costs will not match sum of outbound costs (and that should trigger rounding entry to be posted). That's why, without this fix, you Always get a rounding entry cause, sums are never equal.