Reseting inventory costing history

Alex_Chow

Hi Guys,

So we have a client that went live in NAV in version 4.0 back in 2007. They're a full manufacturing company but has never ran adjust cost before.

A few upgrades (to version 2009, then to version 2013) they decided that they want to start using NAV costing. The problem is that the adjust cost process takes too long to process even if we break it into small chunks. One item took 5 hours to finish adjusting, but their down time is only 4 hours every day.

At this point, I've given up on running the adjust cost and decided to wipe out the cost adjustment history and reset the standard cost. We've agreed that the historical inventory costing will be based on the current standard cost and we will sync up the G/L going forward.

My question is, has anyone done something like this where they've wiped out the adjust cost process for historical transactions and start fresh while maintaining the sales and purchase history?

How did you go about it? Anything I need to watch out for?

jglathe

Hi Alex,

yes. Did this, not really a happy ending.

Our starting scenario:
NAV5.00 database, started as 2.x sometime around the millenium, got upgraded / merged / tinkered with / botched up completely. Some items had holes in their application histoy, lots of negative stock, completely jumbled up value entries.

What we did:
- Patch the posting logic to disallow negative inventory, clean-up runs to eliminate negative stock, clean-up runs to bring warehouse entries and item ledger entries into sync.
- Fill (synchronously) two inventory journals, one for posting all inventory to zero, one for reposting the actual stock - with unit cost provided by an external assessment / calculation / audit.
- Do the posting to zero inventory. Check up all item application entries, everything must be applied, no remaining quantities. If not... hammer time Post the G/L side of the inventory to zero (against inventory correction account).
- Run a batch to create value entries egalizing all remaining vaules, this by item ledger entry.
- Clean out table 5811 "Post Value Entry to G/L".
- Set all Items to not adjusted, run ACIE. Nothing should show up. If something shows, up... see hammer time.
- Post the second inventory journal. Do very thorough post-procedure checking.

The whole routine is far more detailed, but you get the picture. What we intended was to create a containment around the entries garbage we had, and start with a clean slate - with the minimum effort for production. What we got was a sequel of "Resident Evil", the biggest mistakes being these:

- To avoid a lot of hassle with the production, we identified and allowed certain ILEs and VLEs to be kept - for all shipped not invoiced purchase/sales/service orders. This didn't cut the valuation chains for some items, and this became trouble afterwards. The same is true for items in transit.
- There is a bug in the revaluation posting routine (not found yet) which leads to a mis-distribution of the revaluation among the open entries for the item (by location, for instance). This leads to botched up values by location - again. This only happens on revaluation, not in normal operation.

What I recommend should anybody try this kind of thing:

- Create archive tables for Item Ledger Entries, Item Application Entries, Reservation Entries, Value Entries and so on.
- Close all open orders, finish all production orders - record the state of the to-be fullfilled parts to recreate them again. Post all invoices (also partial ones) if possible. If not possible, record the shipped not invoiced positions.
- Create the inventory batch for your actual inventory you're starting with. Provide the unit cost from an external assessment / audit.
- Archive the whole lot of the entries. Delete them from the normal tables. Make sure you have one (dummy) entry left with the last entry no. for a seamless follow-up posting with the right entry nos.
- Handle the G/L side via general journal posting. Clean out Table 5811.
- Post the inventory batch.
- Recreate the partial orders, do the shippings / receipts not invoiced via special posting batch (preferrably by tying the entries to the already posted shipments).

This way, you don't have this zombie effect, because you remove the history to separate tables that can't interfere with NAV operation. For history you can tie them into navigate and registers. The whole prcedure is quite a lot of work, though.

with best regards

Jens

Alex_Chow

Thanks for sharing your experience!

I was hoping to avoid problems down the line but there's no guarantee what future of NAV that will require the historical values.

Plan D (only when Plan A to C has been exhausted) is to just create a new company and copy the master data over.