Tricks to protect Inventory Value

Shenpen

In every installation we always get a phone call after 3 months of going live:

"I can't understand why our margin is just 3% for this item..." or
"Post Inventory Cost to G/L stops with a strange error message" or the most dreaded one:
"Inventory value seems to be bit strange, would you check it?"

and then we look at the customer's database and what we usually find a is a complete, total mess. So what can we do to make inventory value and inventory posting as foolproof as possible?

1) Use automatic cost posting and expected cost posting.

I may be arguable that why the hell do we post unadjusted ( = totally wrong) value to the G/L. Well, simply because then if something is wrong, users get an error message right on the spot when it is still possible to repair it, and not when they are running the posting batch job when it is very hard to repair. This is also true for expected cost posting: it shows errors right on receipt and shipment.

2) Don't take CRONUS posting groups, posting setup and Chart of Accounts seriously.

They are a fairy tale - a setup that does not work in real life because very error-prone.

I usually have General Business Posting groups like:

PURCH_NTNL (national)
SALES_NTNL
PURCH_EU
SALES_EU
PURCH_FRGN (foreign)
SALES_FRGN
INV_SURPLUS (surplus Inventory: Positive Adjustment)
INV_SCRAP (Scrapped inventory: Negative Adjustment)
INV_MISSNG (missing inventory: Negative Adjustment)

I also convice the customer to have as much Accounts as possible: expected and actual inventory Account different for every location AND for every major item group.

Inventory Adjustment accounts different for all INV groups (actually a legal requirement in Hungary, but also very, very helpful in spotting errors)

Yes, they will have a huge Chart of Accounts, but why not?


The point is that it really helps spotting errors. If you do this, the customer will not make the dreaded "There is something wrong with inventory value, it seems to much" phone call resulting in endless nights in database hacking, but a more precise phone call of "I have a bit too much inventory value in location BLUE for item group MATERIALS. Also my surplus inventory account seems a bit too much. " - and then it is much easier to investigate (never, ever forget the Value Entry No. and System-Created Entry fields in the G/L - very important)
and then call Mr. XYZ of the BLUE warehouse: "Why did you find a surplus of 100.000 EUR in March?" So it helps in investigating problems.

I also setup the General Posting Setup, Inventory Posting Setup etc. as minimal as possible.
If there is a business rule that you only sell item group A in Location B then Inventory Account and Inventory Account (interim) will not be set in other locations for these items. And as automatic cost posting and expected cost posting is ticked, when they try to receive an item from group A to Location C they get an error message. Then they call me and I can ask "And why did you even try it? You are not supposed to do it!". And then they usually find out they tried to receive a wrong Item or the Item was created with wrong Inventory Posting Group or whatever.

Also, if you have General Business Posting group for all Positive and Negative Adjustments (and manufacturing, jobs etc.)
then the only transaction with a blank G.B.P. group is a Transfer Order. I also put it to a different account. It is VERY important. When the customer makes the usual phone call I can look at that account and say "Hm, are you sure you have 300.000 EUR items in-transit? Maybe you warehouse employees forgot to receive some transfers, don't you think?" It is very, very helpful.

3) Harcoding is better than hand-hacking errors from the database. Flexibility is less important than usability.

Whenever you think you should leave Navision as flexible as it is by standard, you misunderstand users by 100 miles. Not that they are stupid, they are not. But they are not Navision hackers. Their job is to sell stuff or carry heavy around stuff in the warehouse or spend their day yelling in the phone to untrustworthy vendors. They don't want to go deep into Navision and think like a Navison hacker: "Now, what is the difference between Posting Date and Document Date?" Instead, they expect the software ask simple and logical questions. And they are completely right.

So, they only thing you don't need is flexibility - what you need is a robust system. So what I do is:

They three typical Pos/Neg Adjustments are Surplus, Scrap, Missing (and maybe Change Item No. when you find it was wrongly received). I always mercilessly say "Save As" to Form Item Journal and create three such forms. Then I:

- remove unnecessary fields: only Posting Date, Item No., Location No., Bin Code, Quantity are needed for Negative ones and these and Direct Cost is needed for Positive ones.
- hardcode Type (Positive Adjustment, Negatve Adjustment). It also means they cannot do Sales or Purchase. They are not supposed to do - they don't need it and it usually messes up accounting.
- hardcode General Business Posting Group. Yes, it is ugly. I am thinking on adding it instead to a new field to Item Journal Template, but I don't really like modifications that compromise installing service packs.
- change Quantity field to not allow negative amounts - users can really make a big mess with a Positive Adjustment with negative quantities
- make Item Journal Templates for all these types and set forms to them
- In 4.0 I change the OnOpenFrom trigger to relate to my forms (check it, you will see why)
- set document no. to Item Journal Batch etc.
- For negative ones, it is okay. For positive ones (surplus) there is also a question of Direct Unit Cost. They best way to make a complete and total mess in inventory value is to make Positive Adjustments the way standard Navision is doing them.
What I do 1) zero out Direct Unit Cost 2) write code to the Post and Post and Print menu buttons to don't allow zero cost
thus forcing users to DECIDE on costs, not just accept the standard that is usually totally wrong 3) make a button with size 28 fonts called "Check purchase price!!!" that throws up a form for Posted Purchase Invoice Lines for this Item showing
costs and when they select one, the costis validated to the Direct Unit Cost. If there is no Posted Purchase Invoice for the Item, then they have to make a decision, but if they make a wrong one, at least it is their fault, not Navision's fault, so they can't blame me.
- also change Phys. Inv. Journal to harcode INV_SURPLUS and INV_MISSNG

4) Don't forget that if you use Job Journal or BOM Journal, you have to program Adjust Costs - Item Entries for yourself, becase Navision will not adjust them.

For BOM's the tricky thing is that consumption and output is not connected. Luckily, they are always right after each other in the BOM Ledger. So I have a report that shows difference and throws differences into a Revaluation Journal and then the users can post it. For Jobs, not inventory value is the problem but Job Ledger. I changed Navision to save the Entry No. of the Item Ledger Entry to the Job Legder and made flowfields to show real adjusted value, and changed Job statistics to use that field.

As for Jobs, I never use them if I not forced to use them by the partner NSC of the HQ of the customer. They are simply useless. Better to use a Dimension as Job Code and develop everything else. Why? 1) Because Job Journal is a joke: the first thing you have to make is to "Save as" as "Hand Out Material for Job", "Report Time to Job" with all the usual hardcodings etc. If you don't do this, users will mess up everything. Then, you have to changes Budgets, as they are also a joke - never anyone plans like this. Then you have to change Statistics, because never anyone analyses like this. You have to change everything - so it is better to don't use it and develop it from scratch.

5) Sometimes I change PO to have a Quantity to Receive zero.

It also makes errors less frequent as it forces users to decide on how many they receive.

6) Organize the business process

I tell users "Now we are in January. Until April, when you receive goods, you will 1) review quantity to receive 2) print Test Report (I change it, of course) 3) SIGN it showing you are commited to receive these quantities 4) click post and print (I disable Post), and also SIGN it proving you received these goods.

Such stuff makes users take Navision seriously. They start to feel that they can't be careless like they were in the previous, non-integrated software: in an integrated software like Navision, everything they do has an important impact on everything else - especially on the G/L.