Adjust Cost endless loop because of "same lot consumption"

Bleika

Hi all,

I'm working on a standard upgrade from 4.03 native with manufacturing and have come across the following problem:

A long time ago my customer processed a FIFO Item they normally purchase through a Production Order, generating these ILEs (sorted by "Entry no."):

Posting Valuation Entry type Qty Doc Location code (Always the same Item No. and same Lot No.)
Date Date
18/06/11 18/06/11 Output + 1000 ProdOrder 1 (Production location)
18/06/11 18/06/11 Transfer - 1000 TransOrder 1 (Production location)
18/06/11 18/06/11 Transfer + 1000 TransOrder 1 (Transit location)
18/06/11 18/06/11 Transfer - 1000 TransOrder 1 (Transit location)
18/06/11 18/06/11 Transfer + 1000 TransOrder 1 (Warehouse)
18/06/11 18/06/11 Transfer - 1000 TransOrder 2 (Warehouse)
17/06/11 18/06/11 Transfer + 1000 TransOrder 2 (Transit location)
17/06/11 18/06/11 Transfer - 1000 TransOrder 2 (Transit location)
17/06/11 18/06/11 Transfer + 1000 TransOrder 2 (Production location)
17/06/11 18/06/11 Consumption - 1000 ProdOrder 1 (Production location)

From time to time they need repair a purchased lot and I suppose that was their intention in this case, only that they made a mistake choosing the lot for consumption.
The outcome of this excersise was therefore 0 Qty but they slightly reduced the cost of the Output Entry through Revaluation Journal so the Value Entries sum is not 0. Please note also that the posting dates do not coincide.

Needless to say the Adjust Cost Batch Job stopped working, so their former NAV partner "solved" the issue by applying a filter to exclude this Item in InvtToAdjustExist (CU5895).

The Item code is still active so an important part of the problem is that the Item hasn't had its costs adjusted ever since (even though all other entries related to this Item are correct).

Now I'd like to clean up this mess before I migrate the data to 2009 and in an effort to do so amongst other I've tried manipulating ILE."Applied entry to adjust" and IAE."Cost Application" and checking the Item Application Entries sequence but I'm afraid I've run out of ideas (really only drastic ideas remain like creating a fictious Item card and transferring these movements or even delete the associated ILE, VE, PO lines, etc.).

I already know there are a lot of posts on the "endless loop issue" with different clues and I've even seen some of them describe similar problems (same lot consumption within a Production Order) but none of those seem to have a definitive solution posted and I'd really appreciate any input.

Thanks,
Bleika

ppavuk

There was significant changes in cost adjustment process since ver, 4.03. What I'll do in same situation - I probably omit this item on 4.03, and run cost adjustment process on upgraded DB (if you upgrade object, of course). There is very big chance that new code will process this entries.

If not - I would not spend a time to investigate why cost adjustment fails in particular item, but just manually write off the quantity with neg. adjustment, block item, create new one and put right quantity and value just by item journal.

The investigation of cost issue can take enormous time, so I would go for simple solution.

Bleika

Hi ppavuk,

Thanks for your suggestions

I've already done a test upgrade with data and 2009 Adjust Cost gets stuck on it as well

This has already been time consuming - you're absolutely right on that... but since Inventory Cost Management has changed a lot between the 2 versions, I'd like to make a clean start :roll:

I can't just block this Item and create a new one because my Customer is part of a group and the Item No. for this particular product is common to all.
However, since Qty totals 0 on this operations I think I might go for the other idea - that is: create a new Item Card and modify all the related entries of this mess to point to that Item and then block it. Then I'll be able to adjust costs on this code before the upgrade.

Of course, unless there are other ideas out there...

Regards

ara3n

Have you tried and use the item application worksheet and un-apply the entries?

ppavuk

You also can rename this item prior blocking, this is time consuming, but better than manually (or by code) adjust entries. After this you can create new one with same name.

Bleika

ara3n wrote:

Have you tried and use the item application worksheet and un-apply the entries?

No - I haven't tried that since I've been trying to fix the problem within 4.03 the whole time. However I can give it a try in my 2009 test data - will get back on that one

ppavuk wrote:

You also can rename this item prior blocking, this is time consuming, but better than manually (or by code) adjust entries. After this you can create new one with same name.

Creating a routine that renames the problematic entries would be a lot faster than to rename the item since it has many entries. Besides (if I opt for this solution in the end), I'd just want to break the link to these particular entries but not loose the rest of Item history. Of course this must always be done with much care - if anyone finds this post in future situations - please don't try this if you're not absoluteley sure you'll get it right

ppavuk

I agree that creating a process which will decouple some item entries from one item and put them to another can be dangerous! To be honest, I'll prefer not to do this at all, as all my experience (which is big enough;) ) say me "NEVER EVER CHANGE ITEM ENTRIES!!!!". But, this definitely doable, if you understand what exactly you are doing

Bleika

EUREKA!!! :whistle:

I tried first to remove the applications in 2009 but I'm afraid it didn't help on this one.

Turns out there's this \:D/ lovely little field \:D/ on Production Order Lines called "Cost is Adjusted".
I feel a bit silly for not having tried that one before, but since this particular PO results in 0 quantity I've just forced it to true and Adjust Cost finished in 45 secs.

Thanks for your help :-)

btw: how can I change the status on the thread??

ppavuk

Great hack! :thumbsup:

kiranisht

Hi,
The Idea Given by ara3n has no side effects in NAV2009 SP1 for sure. Once application entries are unapplied, when the application work sheet is being closed, the entries automatically get reapplied AND the ACIE job proceeds past the entries at which it was stuck in

Bleika

I'm afraid unapplying the entries did not do the trick in this particular case...