Category Archives: Inventory

Is Inventory Periods Needed to Control Inventory Posting?


Over the years, I’ve written a lot of articles about inventory and inventory costing. I realize there are some tools that I do not mention that are in the inventory module. This is not because I don’t know about them, it’s because I don’t think companies need them.

Everyone is super busy these days, the last thing people want to do is administrative work. I’m an minimalist when I help our clients setup Dynamics 365 Business Central (Formerly Dynamics NAV).

I believe we should take the simplest route in setup and configuration to get the company up and running. Why? Because the simplest route is usually the easiest route to maintain for the customer ON THEIR OWN going forward.

It’s easy for us consultants, who does this for a living, to recommend all of these cool functions that controls this and that. But what happens when the customer is live and actually using the system in their day to day operation? In addition to their daily workload, now they have to click some buttons in order to properly close?

The new ERP system is supposed to save us steps, not increase them. We, as consultants and developers, often forgets this important goal.

Remembering details to close out the period in the system should be, in my opinion, be kept at a minimum (none if possible).

Making the system more complicated to maintain is not good for anyone.

Let me get into why I’m picking on Inventory Periods…

Why Inventory Periods?

The purpose of the inventory period is to enforce the rule that no item transaction can be posted before the date on the inventory period that is closed.

In this example, you if the check mark for the field Closed is checked, you will not be able to post any transactions prior to 9/30/18 in Dynamics 365 Business Central:

Sounds good right? I mean why would you want people to be able to back date inventory?

Why Not Inventory Periods?

The reason why I don’t advocate using this function is because, as a financial controller or accounting manager, you’re job is already to ensure people do not back date to the prior periods that have been closed.

There are 2 ways to control this in Dynamics 365 Business Central

1. Allow Posting From on the General Ledger Setup

2. Allow Posting From on the User Setup

Both will prevent people from posting into prior periods. IN ADDITION, these functions extends out to other parts of the system that the users should not be back dating into, not just specific to inventory.

You can control who can/cannot post into prior periods with the Allow Posting From on the User Setup screen.

Why do an additional step of closing inventory periods when you already have premade functions that controls when the user can/cannot post into?

But Why Are You Really Not Using Inventory Periods?

Simple, error messages.

Quite simply, error messages freaks people out. I hate them and I suspect you hate them too.

To be able to close out an inventory period, you have to ensure the following:

  1. Run adjust cost, which what you should be doing already. (We typically set this up in the Job Queue so it runs automatically)
  2. Make sure there are no negative inventory. Technically, this shouldn’t happen, but it does.

Negative inventory is something the financial controller would’ve caught when they print their inventory reports for the management or auditors.

All of the restrictions that the Inventory Periods tries to manage is something the accounting manager is already doing in their standard operating procedure.

  • You have the Allow Posting From dates to control when people can back date to.
  • You should be running adjust cost already or it should be setup on the Job Queue to be ran automatically.

    Side Note:
    If users don’t remember to run Adjust Cost, I don’t see how they can remember to close the inventory period.
  • You should be printing inventory reports for management and would’ve caught and resolved any negative inventory problems. If your company does not care about negative inventory (some companies don’t), I doubt you’ll ever use the Inventory Period function anyway.


I do believe Inventory Periods have their uses in certain situations. I just haven’t been convinced yet.

More often than not, I walk into companies with elaborate setups, with Inventory Periods being one of them, that has not been used since the first 1 or 2 periods since the company went live.

Most companies using Dynamics 365 Business Central don’t even know they’re supposed to run the adjust cost process. Adding additional step of inventory periods will not help the situation.

Microsoft likes to add functions to keep track of functions. In my opinion, this makes the system and its maintenance more complicated, which nobody wants. Fortunately, this function is not mandatory.

Keep it simple! Don’t make your life hard!

Prevent Inventory Adjust Cost Entries from Back Dating


Hopefully, by now every company that uses the inventory module in Dynamics 365 Business Central (aka Dynamics NAV) knows that they MUST run the Adjust Cost – Item Entries process.

If not, please check out my other articles on the subject on how to properly care for the inventory module in Dynamics 365 Business Central (formerly Dynamics NAV)

Adjust Cost Back Dating Transactions

While asking companies to run the adjust cost process, some people will report that they experience unwanted entries made to the previous accounting periods.

Why? The reason is because the adjust cost process will always adjust to the date of the original sales transaction (unless specified otherwise).

For example, it’s 6/30/18 and you run the adjust cost process. If you haven’t run this process in a while, and there was a sales transaction that occurred in 3/15/18 that has not been adjusted yet, the resulting adjusting entry will be on 3/15/18.

This will cause problems if you’ve already closed the books for March.

General Ledger Setup – Allow Posting From

This is where the Allow Posting From field from the General Ledger Setup screen comes to the rescue.

If you set the Allow Posting From on the General Ledger Setup, any adjust entries that are BEFORE the Allow Posting From date will have same posting date as the Allow Posting From field.

In our example above, it’s 6/30/18 and you run the adjust cost process. In addition, you set the Allow Posting From to 6/1/18. If there was a sales transaction that occurred in 3/15/18 that has not been adjusted yet, the resulting adjusting entry will be posted on 6/1/18.


Setting the Allow Posting From should be done after you close the month out, NOT before.

I’ve seen situations where the user changed the Allow Posting From BEFORE the adjust cost was ran. So all of the adjusting entries were posted in the current period instead of the period that they should’ve been in.

Just little things to help make your life (hopefully) easier.

Why Your Inventory Valuation Does Not Match the Inventory Account on the General Ledger


At the end of every month, we will inevitably get some questions on why their inventory valuation figures does not match the G/L inventory account. We would investigate and find out why and provide solutions on how to fix them.

Some of the reasons are pretty common so I’d thought I compile a list of reasons why your inventory valuation does not match your general ledger, and how to fix them.

Note that this is not a comprehensive list, but it’s most common symptoms we’ve come across.

Did Not Run Adjust Cost – Item Entries Process

The windows version of Navision aka Dynamics NAV aka Dynamics 365 Business Central has been out since 1995, and I’m still amazed how many NAV partners do not emphasize how important this function is to the end users.

No, setting up the Automatic Cost Adjustment on the Inventory Setup is NOT enough.

I wrote an article covering this specific topic here. The article was written in 2012 and it’s still relevant today. When I went to the Navision training class back in 1999, this was one of things that they stressed on when using inventory function in NAV.

Run Adjust Cost people! Do it before you run any inventory, costing, or financial statements!


What we do for our clients is to set it up on the Job Queue so it’s ran automatically DAILY. Don’t wait too long until this is ran or else it may take a long, long time to finish, which may lead to other problems if you’re running 24 hour shifts.

If you’re not setup to run this process automatically, run it manually! Just. Do. It.

You can read more about why this process is important on this link:

Why Your Inventory Cost is Wrong

Allow Direct Posting to Inventory Account on the G/L

This is a common one as well. This case usually happens when there’s a change in the accounting personnel, rules and procedures that was in place gets broken because of reasons.

This problem occurs when people posts directly into the inventory accounts. Here’s an example of what we found when we were analyzing why the inventory valuation didn’t match G/L entries (the amounts, document, etc has been changed to protect the innocent). The customer did not know why there was a huge variation between the inventory valuation report and what’s on the General Ledger.

Digging deeper into the ledgers, we found the entries that are causing the problem:

At some point, some within the company had allowed Direct Posting to the Inventory G/L accounts. Based on the Change Log, it was changed by their previous accounting manager for unknown reasons.


Set the Direct Posting on the G/L account for Inventory to OFF!

To look at and fix the entries that’s causing the problem, you’ll need to do the following:

  1. Go to the Chart of Accounts and bring up the G/L Entries for the Invenventory G/L Account
  2. Filter on the Source Code field with ‘<>INVTPCOST‘. You’ll probably need to show the column first.

The resulting entries you’ll need to determine what account you should reclass these entries to.

The INVTPCOST is basically the special source code that is used to mark the transactions that originated from the inventory sub ledger. If you have transactions that does not go through the inventory sub ledger, you’re inventory figure will be off.

Running the Wrong Reports

People will try to run the Inventory Valuation report and try to match it to the G/L.

The problem is, the standard Inventory Valuation report will include transactions not have hit your G/L yet (for example, items received/shipped not invoiced).

The better report to run is the Inventory to G/L Reconcile. This gives you a breakdown of what items are received/shipped not invoiced and include it with your on hand valuation.

In addition, you will need to run the Inventory Valuation – WIP report so it can match what’s in WIP to G/L.

Why is this important? Because your WIP account, and if you’ve turned on the Expected Cost Posting, will most likely be different G/L accounts. Make sure you’re matching all those up.


Turning on the Expected Cost Posting on the Inventory Setup will mitigate the problems stated above. So you can run the Inventory Valuation and match it up against your regular inventory and the inventory Interim account.

In the past, I’ve argued against turning on the Expected Cost Posting, however, I realize not everyone will become experts in NAV (nor should they need to be) and know what reports to run to close the month and go home. I’m still against turning this on, but I’m softening my stance on this.

I still believe people should truly understand the software so they know what reports to run and how to reconcile properly…

Relying on consultants is okay… Being self-reliant is better.

Inventory Posting Setup is Incorrect

Take a look at the following screenshot for the Inventory Posting Setup.

The inventory account is set to expense account. This means whenever you purchase or sell an inventory item with this inventory posting group for that location, it will go to account 70500.

This may be done in accident or on purpose, but when people reconcile inventory they’re typically going to only look at your inventory G/L accounts. When you go to your typical inventory accounts, you’ll be missing transactions entries for FINISHED Inventory Posting Group for the location GREEN.

Again, there may have been a reason this was setup in the first place. But I’m willing to guarantee that 5-6 years later or if there’s a personnel change, this will have been forgotten.


With NAV 2018 and Dynamics 365 Business Central, they’ve taken steps to reduce this problem from occuring by introducing the Account Category and Account Subcategory field on the G/L Account table. This means when you drill down to select an account, you can’t select a “wrong” account.

I would recommend hiring someone who knows what they’re doing to do the initial company setup for you. Why? Because most companies will only need to do this (hopefully) once in a lifetime. Learning and ins-and-outs of posting setup, especially when you only really need to set this up once, is not a good use of your time.

General Posting Setup is Incorrect

This scenario is similar to the above. Instead of setting the Inventory Posting Group (the balance sheet side) incorrectly, they set the General Posting Setup incorrectly.

This means everytime something is sold, it will hit the inventory G/L account instead of the sales account.

Same as the previous point, there may be a special (and probably good) reason for doing this, but over time, this knowledge will be lost.

Make anything complicated or weird and you’re almost guaranteed problems down the road. This concept applies to Dynamics 365 Business Central aka Dynamics NAV as well


Same as above. Just pay someone who knows what they’re doing to do this setup for you. The chances are, you’ll only need to do this once.

“But Alex, how do we know who says they really knows and who really knows?”

I’m not sure. I have problems identifying those who talk a big game and those who can actually deliver as well. I’m sure that’s a separate article at some point in the future.

Abnormal Posting Date

Basically, when you post a receipt on a date later than when you post the invoice. For example, you posted the receipt on 5/6/2018, but you post the purchase invoice with the posting date of 4/30/2018. The primary reason companies do this is because they want certain purchase transactions to occur in certain periods.

When you do this, the inventory valuation will not pick up this particular transaction if you run the inventory valuation as of 4/30/2018. Why? Because the inventory transaction occurred on 5/6/2018. However, the G/L transactions occurred on 4/30/2018.


The subject of Abnormal Posting Dates has been covered in an article I posted. You can read the article here.

Basically, you will need to run a supplemental report to balance out the inventory.


There are probably other common reasons, but these are just from the top of my head.

Note that these symptoms usually comes with follow up questions on why the inventory costing is weird. But that’s a topic for another article.

The bottom line is as long as you can reasonably explain what happened to the auditors, you will be OK. The key is understanding and setting up the system so it can’t fail you.

Doing a Physical Inventory Count with Warehousing in Dynamics NAV or Dynamics 365


Here’s a quick video about doing a physical inventory count in Dynamics NAV (or Dynamics 365) when you have the Directed Pick and Put-away feature turned on.

There are basically 5 steps:

  1. Go to the Whse. Phys. Invt. Journal
  2. Run the Calculate Inventory process
  3. Fill in the Qty. Physical field
  4. Register the journal
  5. Go to the Item Journal and run the Calculate Whse. Adjustment process to true up the Bin Content and the Item Ledger

Note that this video assumes you do not have ADCS (wireless barcode scanner) setup to do physical count.



Properly Setup Bin Code for Warehouse Management in Dynamics NAV

One of the most often asked about features when dealing with inventory is the ability to keep track of inventory by bins in the warehouse. While The Warehouse Management System will benefit the accuracy of the items that are stored in the bins, careful consideration must be made during setup so when you go live, less additional work is needed for the system to work for you.

On a macro level, before you eve consider implementing a warheouse management system, your warehouse itself MUST BE ORGANIZED! What I always tell customers is that the purpose of a computer systems is to help you do something faster. This means that if you’re warehouse is a mess, implementing a warehouse system will make it more messy, faster. However, if you’re warehouse operation is efficient and optimized, then implementing a warehouse system will help you become more efficient and optimized, faster.

The Bin Codes
While there are many considerations for setting up warehouse management in NAV, this article will focus on one of the most overlooked areas.

The Bin Codes.

The Path of the Picker
There are many differnet theories about how to create the most efficient picking path. But generally, you want the path of the picking so the following occurs:

1. When picking for an order, they would not have to come back to the same bin in the same level
2. When picking, they should pick from the eye level (or the level where they don’t need special equipment). This is typically the first level.

Keeping it simple and not concerning with spliting into Zones, wave picking, and whatnot, the pattern the warehouse picker should walk is the following:

Warehouse path for picker

Warehouse path for picker

Only when the above is exhausted, do we use special equipment and pick from the higher levels. The general rules are the same, you want to use the run time for the special equipment should be as minimal as possible.

The Sort Order of the Pick Bins
In order to get the path described above, we have to first understand how Dynamics NAV priortizes what bin is selected when a pick is generated. Consider the following bins numbers for your warehouse:

Typical Bin Code for Warehouses

Typical Bin Code for Warehouses

The first 2 characters is Section, then Isle, then Level

When the pick from NAV is generated, it will suggest the pick in the following order (assuming no bin ranking is used).

NAV Suggested Pick Order

NAV Suggested Pick Order

As you can see, it will create the pick on a decending order.

Why Suggest the Bins in Decending Order?
The answer lies in the help for the Bin Ranking field found in the Help or on MSDN:

The program will suggest a pick from the bin with the highest numerical ranking. Items in the highest-ranking bins (bins with the highest number in the field) will thus be picked first

Makes sense.

Why Not Use the Bin Ranking?
We could. But tread carefully! Bin Ranking provides a lot of flexibility on how the bins are ordered during the directed pick/put-away. Not paying special attention to how to rank the bins will give you more pain and suffering.

Assuming you rank all of the 1st level bins the highest, and level 4 the lowest. The resulting pick order NAV would generate for its pick is the following:


This means that NAV will ask the warehouse picker to pick from the section that’s furthest away from the warehouse (assuming that’s section C). Very good for letting your warehouse picker get excercise, not really good for pick efficiency.

Two Ways You Can Go About This

Property Setup the Bin Ranking
If you want to utilize the Bin Ranking, then you will need to sort it based on how you want the warehouse user to logically pick/put-away. In the example above, the bin ranking would be set as the following:

Proper Bin Ranking Setup for a Warehouse

Proper Bin Ranking Setup for a Warehouse

You will need to carefully configure how to assign the bin ranking. In addition, if there are any changes to your bins (add/remove), you will need to break out the spreadsheet and reassign all bin rankings again.

Modify the Default Bin to sort in Acending Order instead of Decending Order
Doing so will allow Dynamics NAV to “sort” to pick from A section to D section. However, it will also ask the picker to pick from multiple levels first instead of the 1st level.

You will need to reconfigure how your bin codes are setup. Instead of Section – Row – Level, you will need to reconfigure your layout as Level – Section – Row:


This will ensure that all of the 1st levels are picked first. Then it will then pick the 2nd level, then the 3rd, etc. This option may not be feasible if you’ve already spent the time and effort on labeling all of your bins. This option may also not be feasible if you want them to pick from the same column once they got the forklift truck. However, this option will require the least amount of maintenance.

Having implemented both methods for clients with warheouse management requirements for Dynamics NAV, both methods have their pros and cons. And they both work for the respective companies.

Bin Ranking will work wonders if you take the time to set it up right, but maintenance is a hassel. Reconfiguring the bins is simple, but you have to becareful about how NAV sorts the bins.

Again, both methods work. It really depends on how you implement this.

Common Mistake in Updating Standard Cost in Dynamics NAV

Recently, I’ve been contacted by one of our readers on why their inventory cost was wrong. This particular company utilizes standard cost and the inventory cost never matched their inventory G/L account. Learning about how they updated standard cost, it was very apparent what went wrong. It was how the user updated their standard cost.

Companies will periodically update their Standard Cost to reflect closer to what the cost of their items. The timing of this really depends on the company and the industry they’re in. I’ve seen companies revaluate their standard cost every month, some do it every quarter, some companies revaluate their standard cost every year.

Updating the standard cost is a must for every company, or else you will see big variances when you run your financials, which accountants and auditors will question every single time.

Update Standard Cost without Changing Existing Inventory on Hand
Depending on how your company wants to recalculate standard cost, you may not want it to change the inventory value on hand.

To do this, all you need to do is just updating the Standard Cost field on the Item Card of the Stockkeeping Unit Card is only part of the process.

The folks at Microsoft made it even convenient for you to do so:

Standard Cost Update

All you need to do is just change the Standard Cost to whatever you like and you’re done. For manufacturing companies they may use the Calculate Standard Cost functionality.

What’s missing is you need to revaluate what you current have on hand to the new standard cost. Just updating the standard cost on the item card will only affect purchase or incoming items going forward. It will not affect historical standard cost values!

Where the Common Mistake Occurs
Not running Adjust Cost – Item Entries aside, the problem is not with the actual update of the standard cost, but the current inventory you have on hand.

Instead of running the Inventory Valuation report or the Inventory to G/L Reconcile report to get their inventory value, most accountants do the following:

  1. Grab the Standard Cost on the item card
  2. Multiply by the standard cost from step 1 by the quantity on hand
  3. Manually adjust the inventory G/L account

The 3rd step is what kills you. Making manual G/L entries will only make reconciliation between the item ledger and general ledger extremely tough and add a tremendous amount of (unless) work. In my career, I have not met a person that wants to do more work that is useless.

Update Standard Cost and Changing Existing Inventory on Hand
If you want to change your current inventory value on hand, you have to run the Revaluation Journal AFTER you update your standard cost.

Microsoft even published an article detailing the proper way of updating standard cost for your Dynamics NAV implementation. Click here for the article.

Properly used, the inventory function in NAV never goes wrong and will never require human intervention. What’s wrong is the information you feed it.

Undo Receipt with Directed Put-away and Pick for Dynamics NAV

Undo receipt has become a necessity in some warehouse environments where the staff may not be able to keep up with the paper flow. Strictly speaking, the undo receipt process shouldn’t be necessary because the process in place should be able to accommodate. However, if there is a situation where a department “can’t keep up”, it usually means that something is wrong within that particular department. It may not be the people, it may just be how things are being done or may just lack the manpower.

Nonetheless, while you’re trying to figure out a more efficient way in that particular department; in our case the warehouse, mistakes in receipt will be made. We need to be able to correct the mistakes in the warehouse without causing the other departments (such as accounting) a ton of headaches on reversing.

Undo Receipt
The Undo Receipt functionality is pretty straightforward. Basically, you just bring up the Posted Purchase Receipts and do the undo receipt. In fact, it’s so easy it’s explained in a step by step instruction here: Undo Receipt in Dynamics NAV

Undo Receipt with Directed Pick & Put-away
When you enable the Directed Put-away and Pick (or the full Warehouse Management in Dynamics NAV), it may be a little more complicated.

If you follow the steps on MSDN, you’ll get one of these 2 error messages:
“You cannot undo line xxxxx because warehouse activity lines have already been posted.”

“You cannot undo line xxxxx because there is not sufficient content in the receiving bins.”

One error says you do not have enough on the receiving bin for undo, the other error message says you have a put-away (registered or not) out there.

How Is This Possible?
Right now you may be asking, “how is it possible to register the put-away when it’s physically not there?”

You’re absolutely right. It is impossible to physically put-away something that you didn’t even receive. This is what makes Warehouse Management in Dynamics NAV work; it’s the accuracy of data entry from the actions performed in the warehouse. In real time!

The real problem here is the process within the warehouse receiving department. If the procedures are followed, you should never have to undo. We have to dig deeper on why the warehouse receiving staff are not following the rules for unloading the truck and putting the stuff away. Sometimes there are legitimate reasons why the procedures cannot be followed. In those cases, a new process needs to be thought out to better accommodate the receiving staff.

Resolving issues like this may take a while and this is where we spend time with the client. Often times, I wish it was as easy as just telling the warehouse people to just follow directions.

But I digress…

Undo Receipt After the Put-away is Registered
Here are the steps that need to be done in order to undo receipt after the put-away is registered.

Delete the Registered Pick:
1. Locate the Posted Purch. Receipt
2. Click on Navigate
3. Show the Posted Whse. Receipt Line
4. Click on Navigate –> Show Posted Whse. Document
5. Click on Navigate –> Registered Put-away lines
6. Click on Navigate –> Show Registered Document
7. Push Delete

Adjust the items into the Receipt Bin. In this case, our receipt bin is R:
1. Warehouse Item Journal
2. Negative adjust the item from the bin you want to take out
3. Positive adjust the quantity to the R bin

Do the undo Receipt:
1. Locate the Posted Purch. Receipt
2. Click on the line that you want to undo receipt
3. Click on Function –> Undo Receipt

This is just to get by until you can get to the bottom of why the receiving staff are having trouble with receiving. That’s where the real problem and the solution lies.

Unexpected Changes the Expected Receipt Date in Dynamics NAV

This is one issue that I hear from customers using Dynamics NAV (formerly Navision) quite often is why does the Expected Receipt Date keep changing?

The Expected Receipt Date in Dynamics NAV is the main driver for inventory planning. Dynamics NAV uses this field to calculate the availability of the item. Based on this date, Dynamics navNAV calculates when the item can be received into your warehouse.

On the purchase order, the field is on the header and on the lines. Dynamics NAV will only use the field on the purchase lines in the calculation.

What the Help Says
Looking at the help, the explanation is simple enough:


Basically, what it says is that the Expected Receipt Date on the purchase line should copy the information from the purchase header, if it exist. Otherwise, it will follow a formula:

Planned Receipt Date (Order Date on the purchase line + Lead Time Calculation on the Vendor/Item Catalog, if it’s blank, then the Lead Time Calculation on the vendor card)
+ Safety Lead Time (On the Item card or SKU card)
+ Inbound Whse. Handling Time (On the Inventory Setup or the Location card)
= Expected Receipt Date

However, if you continue to drill into the help, you’ll find another formula for the Expected Receipt Date:


Order Date (on the Purchase Order)
+ Lead Time Calculation (From the Item Vendor table, if blank it’ll use the field on the SKU, then the item card)
= Expected Receipt Date

If you drill down on the Lead Time Calculation Help, it will say:


If I follow the formula correctly based on the help:
Order Date + Lead Time Calculation =
= Planned Receipt Date
= Planned Receipt Date + Inbound Warehouse Handling Time + Safety Lead Time
= Expected Receipt Date

Yes… Nice and Simple…

Other Fields that Affect this Date
What the help doesn’t mention is that there are other fields that will affect the Expected Receipt Date. To test this, just create a purchase order and go to the Shipping Fasttab (or tab if you’re using the classic client) in your version of Dynamics NAV.


The Safety Lead Time, Lead Time Calculation and the Inbound Whse. Handling Time explanation is pretty straight forward. In our test, the CRONUS database has 1 day on the Safety Lead Time.

Here’s what happens when you change the following dates on the Purchase Header:

Requested Receipt Date, it will changed/updated on the Purchase Line:
– Order Date
– Planned Receipt Date
– Requested Receipt Date

Promised Receipt Date, it will changed/updated on the Purchase Line:
– Planned Receipt Date
– Expected Receipt Date
– Promised Receipt Date

Expected Receipt Date, it will changed/updated on the Purchase Line:
– Planned Receipt Date
– Expected Receipt Date

Here’s Where It Gets Awkward
These dates work FIFO. So whatever date you change on the Purchase Order header will take precedent over what was entered before.

Worst, when you update the dates on the header, you’ll get a message asking if you want to change the Purchase Lines, WHERE ALL THE INVENTORY CALCULATION TAKES PLACE!

There are a lot of instances where the user will want to look at the purchase order header and get a feel for what is coming in what by who. Make sure the user know exactly what’s going on.

An option would be to remove these dates from the header and force the user to enter the lines. But if you have long purchase order, this is not really an option.

In the end, becareful about changing those dates when you’re entering purchase orders in Dynamics NAV!

Why Your Inventory Cost is Wrong

The Problem
I hate beating a dead horse to death, but there are a couple of incidences that prompted me to write this article. Navision 1.0 has been out since 1996, yet it always astounds me when I walk into a company claiming that their inventory costing and cost of goods sold is incorrect because Navision is bugged.The first question I always ask is: Have you guys ran the Adjust Cost – Item Entries process? Most of the time, I get the blank stare asking what the hell I’m talking about.

The Mandate
Straight from the Dynamics NAV help:

The Adjust Cost – Item Entries batch job adjusts inventory values in value entries so that you use the correct adjusted cost for updating the general ledger and so that sales and profit statistics are up to date. The cost adjustment forwards any cost changes from inbound entries, such as those for purchases or production output, to the related outbound entries, such as sales or transfers.

Basically, it will update your COGS and the Unit Cost on the item card to the correct cost that the item was brought in. Simply put, you HAVE to run this process BEFORE you do any meaningful financial and costing analysis.

It doesn’t matter what your costing method is. Doesn’t matter what your setup is. You HAVE to run this if you want to do inventory costing analysis in Dynamics NAV (Navision).

Here’s what the process looks like in RTC:

Adjust Cost - Item Entries RTC


Here’s what the process looks like in Classic Client:

Adjust Cost - Item Entries version 5.0

Note that the Adjust Cost – Item Entries will look different depending on the what version of Navision you use.

If you do not run this, no analyst in the world can begin to figure out what exactly the cost should be and address any incorrect inventory values you may have.

Side Effects
Note that if your company has never ran this before, or have not ran this in a long time, there may be detrimental affects on your inventory and COGS. Here’s a partial list of what you may encounter:

1. Your COGS on the G/L will go wild. The reason for this is that most companies, when they do not run the adjust cost, will use the general journal to “calculate” what the COGS should be. So when you do decide to let NAV do what it’s suppose to do, you will need to reverse these journal entries.

2. Your Inventory on the G/L will go wild. The reason is the same as above. The journal entries will need to be reversed.

3. Your item unit cost will go wild. The reason, again, is the same as above. A lot of times when you make an inventory journal adjustment to “take out” the inventory with the incorrect cost and positive adjust in the item with the correct cost, you are only doing it on the surface. The way NAV allocates and applies the inventory entries will most likely be different than what you adjusted.

Why Bother Going Though the Trouble?
Looking at the side affects, you may be wondering, why do I want to bother going through this process if I’m running fine as it is? The answer is simple, but it will reduce time and free up your company’s human resources to focus on important things.

Think about the manual spreadsheets and human memories that your salespeople need to figure out what cost the item should be before you can quote a competitive price to your customers. Think about the time it takes your internal accounting staff to figure out what your bottom line should look like on the financial statement. Think about if those times are freed, what other amazing things your employees can come up with to make your business even better.

A lot of companies will give their Trial balance to their CPA and let them make do the calculation. But realize that what they’re doing is just an estimate. It is NOT accurate. The CPA’s priority is to make the number seem reasonable so he/she can do your tax return and having paper trail if there’s an audit. His/her goal is not to get the accurate inventory cost.

Ask any good accountant, reconcilation is one of the most time consuming and useless tasks.

Ask any good salesperson, having a quote rejected because they cannot get the competitive price to the customer is not only a colossal waste of time on the company, but also for the customer. It reflects on the reputation of your company

Ask any good business owner, not having accurate profit and loss for each transaction… Well, you get the idea.

Let Dynamics NAV do its thing so it can help your business can do its thing.

Abnormal Item Charges

Dynamics NAV is a ERP software that’s built on best business practice. However, that’s not to say that the users of Navision operates on best business practice.

This post describes what I would like to call Abnormal Item Charges. Again, as with what I’ve described with Abnormal Posting Date, don’t bother looking it up on any GAAP dictionary or NAV website. It’s a term that I made up because I lack the vocabulary to think of a better name. English, afterall, is my second language.

What is Abnormal Item Charge?
Abnormal Item Charge are posted item charges that are applied to the open Purchase Order that has not been received or invoiced.

An Example
A lot of times when a company orders some items from factories, they will buy the finishes of the goods that you want to order, i.e. special metallic paint. Because of the competitiveness of factories, they will sometime offer the company to pay only partial (or no payment at all) until the products are successfully manufacturered. The special finishes they will have to pay now.

So at the time of the PO creation, the company will only have paid for the special metallic paint. The company wants to pay for the paint while allocating the cost of the paint to the inventory that they will possiblity receive in the future. So an item charge line is created on the PO and allocated the cost of the paint ot the purchase lines.

The Effects on G/L
As we discussed previously, this item charge will post to the following G/L accounts:
+ Inventory
– A/P
+ Item Charge G/L Account (Purchases)
– Direct Cost Applied

So the additional cost of the item is correctly accrued to the inventory value.

The Problem
The additional cost components of the item has been allocated and correctly posted to the G/L. The problem is, there’s no inventory for the additional cost to apply to.

This means that the value entries will be created, but it will not reflect on the inventory valuation report until the items are received.

The Solution
In version 6.0 (NAV2009), they put out a fix for this in codeunit 90. Now if you try to post an item charge when there are no item ledger entry, it’ll give an error. However, this solution causes problems for the business case described above.

The solution for this was to comment out the code in NAV2009, then create a report that captures the additional cost posted to the G/L that did not have the corrosponding item ledger. We call this report the Abnormal Item Charge report. It’s a pretty simple report. If your company has the same problem, let me know. I’ll send you the report.

EDIT: One of my colleagues reminded me that we can also use the Prepayment Functionality in the US version to handle this. Basically, we would set the item charge line prepayment percentage to 100. Doing this will post the transaction into the prepayment account instead of the inventory account.

Again, NAV is designed to be best practice. This cause in particular forces us to break that best practice because it makes business sense. Note that I don’t usually like to break NAV’s built in best practices, but in this situation, it was a frequent part of the some of our client’s business, especially when factories are competing for orders in a down economy.