Which Microsoft Dynamics NAV Costing Method Should Manufacturers Choose?

I am often asked by manufacturers, “Which costing method should we use in our Microsoft Dynamics NAV system?” Before addressing the question, let’s set the stage with some important definitions.

In large part, “Cost Accounting” should be considered “Managerial Accounting,” not “Financial Accounting.” The exception to this is that cost accountants are responsible for providing and being able to validate the value of inventory items on the balance sheet. As for managerial accounting, cost accountants are responsible for providing “actionable information” to the management team so that management can make necessary adjustments to improve a company’s financial performance. There are no GAAP rules for managerial accounting, so a company’s cost accounting should be tailored to provide management with the information they need. Also, cost accountants are, at times, responsible of informing management with the future cost of items.

While the ultimate choice of which costing method to use should be left to your company’s financial management team and CPA, I can offer the following thoughts:

Microsoft Dynamics NAV gives us the choice of FIFO, LIFO, Average, Standard, and Specific costing methods.

FIFO: In Dynamics NAV, FIFO means that the items taken out stock for production or sales shipments will be taken out in the order of first received, first out and are costed with the actual cost of procurement for that FIFO layer (there are specific exceptions to this costing method if you are using lot or serial number tracking, but they are beyond the scope of this discussion). Using Dynamics NAV FIFO, the balance sheet will reflect the actual procurement/production cost of items remaining in inventory.

LIFO: In Dynamics NAV, LIFO means that the items taken out stock for production or sales shipments will be taken out in the order of last received, first out and are costed with the actual cost of procurement for that LIFO layer (Again, we will ignore specific exceptions here). Using Dynamics NAV LIFO, the balance sheet will reflect the actual procurement/production cost of items remaining in inventory.

Average: In Dynamics NAV, instead of using the actual cost when items are taken from inventory for production or sales shipments, the items are costed at the average cost for that item in inventory (before taking the items). The averaging period can be set to day, week, month, or accounting period. The balance sheet will reflect the actual procurement/production cost of items remaining in inventory.

Standard: Instead of using the actual procurement cost or the average of the costs, Standard in Dynamics NAV uses a fixed value set by cost accountants. In a distribution environment, cost accountants, with the cooperation of the purchasing staff, set the standard for the purchased items which ultimately becomes the COGS when shipped. This standard may contain provisions for overhead absorption and/or landed cost elements. In a manufacturing environment, not only do cost accountants set the standard for purchased items, but they also set the standard for produced items. The standard cost for a produced item may contain material, direct labor, overhead, or subcontracting cost. Cost accountants need the assistance of production engineers for establishing the standard cost of an item. The balance sheet will reflect the standard cost of items remaining in inventory. When there is a variance between the standard and actual costs, a Purchase Price Variance will appear on the P&L statement as a period expense.

Specific: For Specific, Dynamics NAV assumes that the company is going to buy, produce, and sell items one at a time. Specific requires that the items in inventory are serialized. In Dynamics NAV, Specific costing means that the items taken out stock for production or sales shipments will be taken out by serial number and the cost reflects the actual cost of procurement. The balance sheet will reflect the actual procurement/production cost of items remaining in inventory.

There are advantages and disadvantages to using each method.

Using any of the methods but Standard, you can provide an up-front estimate, but the actual cost and margins will vary from accounting period to accounting period. There is no easy way to provide an answer to the question, “Why are our margins what they are?” because all of the costs are coming out of inventory at the actual costs. We are only able to provide COGS analyses, because the margin at the end of the accounting period is either higher or lower than estimated, but why? Did you use more material and labor, or did it just cost more to procure them? It is easier with Standard costing because you can compare actuals against the standard to see where the costs originated.

An advantage of using Average cost is that COGS is smoothed and does not swing when emergency purchases are made to fulfill a special customer order. In this way, a salesperson is not penalized when a shipment goes out using the FIFO or LIFO layer that was procured at an inflated cost when sales commissions are based on margin.

In a distribution company, identifying the costs is easier: You purchase the product at one price; you sell it at another price.

But in manufacturing, there are often several stages of sub-assemblies, making it nearly impossible to understand why margins are high or low for a specific accounting period. Therefore, manufacturing companies typically use Standard costing when management is interested in tracking variances for the purpose of identifying where the process can be improved. Using Standard costing:

• COGS is fixed and you can provide management with purchase price variance, material usage variance, and labor efficiency variance.
• You can provide sales and marketing with a fixed cost number that can used to set sales prices.
• Margins will remain the same until new standards are set.
• A drawback for Standard is that there is a significant amount of up-front effort to set the standards.

Ultimately, costing accountants must choose the most appropriate costing method to provide management with the actionable information they require. However, it is important to understand how each method is handled within your Dynamics NAV system to make a well-informed decision.

Dynamics NAV’s flexibility and some creative thinking can address unique business processes without the need to customize

The other day, a client presented me with a scenario that took some thinking on to how to set it up in Dynamics NAV without requiring a customization. 

The client, who is running Microsoft Dynamics NAV 2009 R2 with the Role Tailored Client, sells wooden stakes.  A vendor supplies green (not dry) stakes, which the client then sorts, dries, shapes, treats, and bundles for shipment.

The challenge he presented is in the purchasing and receiving process. The green stakes are stocked in NAV as ‘each,’ but the purchase unit of measure is 1,000 ‘Board Feet.’  There are approximately 3,000 stakes per 1,000 board feet. 

When the delivery of the green stakes is made, the vendor expects an 80 percent cash on delivery payment. The stakes are then sorted to determine which are of good quality and which are of 2^nd quality. The client makes the final payment to the vendor for the good quality stakes only. The client is able to keep the 2^nd quality stakes and use them for other purposes; these are put into inventory with a zero value. 

Here is the solution I came up with to manage this process within Dynamics NAV without requiring a customization:

1. We created the following 3 items in NAV with associated costing methods:
   • Green Stake - FIFO Cost
   • Good Quality Stake -FIFO Cost
   • 2^nd Quality Stake - Standard Cost = 0.00
2. We create a purchase order for 1,000 board feet of Green Stakes.
3. We receive the purchase order for 1,000 board feet that will put 3,000 Green Stakes into inventory.
4. We make a prepayment for 800 board feet.
5. We create a NAV Released Production Order for 3,000 to output Good Quality Stakes.
6. The workers do the sorting and report the quantity of Good and 2^nd Quality Stakes.
7. Using the NAV Consumption Journal, we consume all 3,000 Green Stakes to the production order.
8. Using the NAV Output Journal, we output as many Good Quality Stakes that were counted. This will bring all of the cost to the Good Quality Stakes.
9. We calculate the total price to pay and ‘invoice’ the receipt for the entire 1,000 board feet.
10. We create an item journal entry to put the 2^nd Quality Stakes into inventory at zero value.
11. We apply the prepayment to the invoice.
12. At a later date, we pay the balance of the cost to the Green Stake vendor.

As you can see, with a bit of creativity and the flexibility of Dynamics NAV, many business process challenges can be addressed without resorting to a customization.  This particular solution could be used in similar situations where the purchase prices are in part determined by the quality of the goods received.

If you’re challenged with unique business processes, talk to ArcherPoint today. If you have a creative solution to share, we welcome you to leave a comment.

Managing Negative Inventory in Microsoft Dynamics NAV

I think that we all can agree that in the real world there can be no such thing as negative inventory; likewise, inventory on hand accuracy is vital to any company that uses a computer to track its inventory.

In an accounting/business management software system, however, it is quite common to see a negative quantity on hand. This can be caused by poor inventory accuracy or by ‘timing issues.’ For instance, an item can be issued to production before the purchase order is received in the system for that item.

Potential Problems with Negative Inventory

Given that you have good inventory accuracy, there should be no negative inventory at the end of any day. Negative inventory means your replenishment planning system is using invalid data—which yields incorrect reordering recommendations—and your costing system has no chance of reflecting accurate inventory and COGS values.

In Microsoft Dynamics NAV, we can also think of negative inventory as being negative in one location and positive in another location. For instance, in Location A, the system shows 1 on hand, but in location B, it shows -1 on hand. When we look at the total, the system shows 0 on hand, which is accurate when viewed globally. However, this is still not acceptable and needs to be addressed.

An easy way to prevent negative inventory in Dynamics NAV would be to change the system to never allow negative inventory. This sounds good in theory, but I find that in some companies it would be culture shock to do so. You can imagine if, at the end of a month, quarter, or year, the boss asks why you didn’t make the shipment that would have made the company’s shipping goal, and you answer, “Because the system wouldn’t let me post negative inventory.”

It is best to identify the areas that are causing a negative inventory number to occur and then correct those issues. However, because there can be many reasons for negative inventory numbers, this blog post focuses on identifying negative inventory and determining the cause rather than correcting the issues.

Finding which items have negative inventory

To discover what items have negative inventory in total is quite easy. In Dynamics NAV, go to the item list and set a filter for Quantity on Hand as less than zero, which will display a list of items showing negative inventory.

To find the items that have a negative inventory in one location only, you will need to access the Item Ledger Entry Table. Follow these steps:

1. Go to any item card.

Item Card - Quantity on Hand

2. Drill down on the Quantity on Hand. This will bring you to the Item Ledger Entries for that item.

Item Card - Ledger Entries 

3. To see the Item Ledger Entries for all items, clear the filters set by the system.

Item Ledger Entries - Clear Filters

The system will display a list of all of the Item Ledger Entries for every item.

Item Ledger Entries - Display All

4. Now we want to make a list of all of the items with negative inventory, either in total or in one location only. To do this, set a table filter with Positive = NO and Open = YES.

Item Ledger Entries - Filter on Negative

The system will display a list of all Item Ledger Entries that need to be corrected.

Item Ledger Entries - Display Negative Entries

Now that you have identified the negative inventory entries, you can correct them. Keep in mind, however, that inventory values should never reflect a negative value, so it is just as important to correct the root cause of why the inventory went negative in the first place.

If you need assistance dealing with negative inventory or managing your inventory effectively, contact ArcherPoint for more information.

The Effects of Inventory Setup in Microsoft Dynamics NAV 

I am often asked questions on the effects of Inventory Setup in Microsoft Dynamics NAV. The two most common questions are:

1) How do the settings affect system performance?

2) How do the settings affect what is posted to the General Ledger and when?

In this blog, I will discuss these questions in the context of Automatic Cost Posting, Expected Cost Posting to G/L, and Automatic Cost Adjustment in Dynamics NAV, saving Average Cost for a later blog.

Let’s start by going to Inventory Setup. Go to Warehouse->Inventory->Setup->Inventory Setup:

Inventory Setup Window in Microsoft Dynamics NAV Classic Client

Automatic Posting

To understand what Automatic Cost Posting does, it’s important to understand Dynamics NAV’s Value Entries. When an inventory transaction is recorded in Dynamics NAV, an associated Value Entry is automatically entered into the Value Entry Table. This Value Entry reflects the cost of that transaction, whether positive or negative. Additional Value Entries can be added later by the Adjust Cost program.

If Automatic Cost Posting is checked, every time a Value Entry is entered into the Dynamics NAV database, the corresponding General Ledger entries are automatically made.

Expected Cost Posting

The key to understanding how Expected Cost Posting to G/L works is being aware that there can be two types of Value Entries. For instance, when a purchase order is received but not invoiced, Dynamics NAV automatically enters a Value Entry with an expected cost. When that purchase is invoiced, NAV automatically enters a Value Entry that reverses the original expected entry with the expected cost and replaces it with one with the actual costs.

By checking Expected Cost Posting to G/L, the system will post expected values to the General Ledger. If this is not done, an accrual General Journal Entry should be posted at the end of an accounting period to bring the General Ledger into balance with the Inventory Sub Ledger.

Inventory Setup Window with focus on Automatic Cost Adjustment

Automatic Cost Adjustment

Automatic Cost Adjustment is a fairly complex process and will be covered in more detail in a later blog, but for now, I’ll explain it this way:

There are two types of inventory transactions: 1) those that add inventory (inbound) and 2) those that remove inventory (outbound). For each transaction type, NAV enters at least one Value Entry to represent the cost of that transaction. Outbound Value Entries get their cost from the Inbound Value Entry that supplied it, for instance, a purchase order lot is received and a sales order is shipped from that lot.

There are times, though, when the original cost that was entered for the purchase order receipt was incomplete and, therefore, the cost transferred to the sales order cost of goods sold is incomplete (i.e., freight costs were added later). When the added cost is made to the purchase receipt, the Adjust Item Entries Cost program finds the outbound entries that were supplied by the purchase order and adjusted to show the additional cost.

To explain Automatic Cost Adjustment, I have included the following from NAV Help:

In this field you can set the program up to adjust for any cost changes automatically every time you post inventory transactions. The adjustment process and its consequences are the same as for the Adjust Cost - Item Entries batch job.

Because potential cost adjustment during every inbound posting could slow down database performance, this setup field includes time options (see below) so that you can define how far back in time from the work date an inbound transaction can occur to potentially trigger adjustment of related outbound value entries.

When setting a time option for automatic cost adjustment, you should therefore select one that balances your requirements for cost accuracy with the performance level of your database. Generally speaking; the shorter the time setting, the less accurate the cost information, but the better the database performance during posting.

In my experience, I have always selected ‘Never’ or ‘Always.’ If you select ‘Never,’ however, you must run the batch job Adjust Cost – Item Entries.

Microsoft Dynamics NAV Financial Management Window

If you are experiencing system performance issues (locked tables), it probably means you have set up Automatic Cost Adjustment to Always and Automatic Cost Posting is turned on. To alleviate these performance issues, change the setting Automatic Cost Adjustment to Never and turn off Automatic Cost Posting. This means, however, that you will need to run the Adjust Cost and Post Cost batch jobs.

For a new implementation, I try to make a determination as to transaction volume. If there is a high transaction volume, then I recommend turning off the automatic features.

As for Expected Cost Posting, it is the choice of the financial team as to whether to use it or not. From a performance point of view, there is not much effect, but it does add a significant number of records to the General Ledger. My choice is to turn it on as it does provide valuable information and it does make reconciling the Inventory Sub Ledger to the General Ledger much easier.

If you are in doubt about which setting to use, the good news is that you can turn Automatic Cost Adjustment on or off without compromising costing accuracy.

If you would like to learn more or have questions about Inventory Setup for your company, contact ArcherPoint.

Manufacturing and Costing Sessions Set for NAVUG Forum 2013

It’s just a short five months until NAVUG Forum 2013 will be held in Tampa, Florida.

I just participated in a planning session for Forum 2013 to set the session content in the Microsoft Dynamics NAV Manufacturing and Costing areas. As it looks at this time, there will be a repeat of the popular sessions in the past, along with some new and informative content.

I will be presenting again and will be conducting a new two-hour session on “Manufacturing Accounting for non-Accounting Professionals.”  As Manufacturing and Material Management Professionals, we are graded on key performance indicators like quality, delivery, and efficiency, but, in the end, our performance is ultimately graded on how our departments perform financially.

The session will be directed to Manufacturing and Material Management Professionals who may have had a course or two in accounting, but never got to the advanced courses in cost accounting.

This two-hour session will start with the fundamentals of accounting, then progress to manufacturing accounting.  At the end of the session, attendees should have a good understanding of “where do these numbers come from?”

Don’t miss this and other informative sessions and an opportunity to network with others in the NAV community. Register for NAVUG Forum and be sure to become a member of NAVUG.

Component Flushing Methods in Microsoft Dynamics NAV

I get a quite a few questions related to Component Flushing Methods in Microsoft Dynamics NAV. After looking at the various NAV Forums, I thought a more in depth explanation of this function might be of some help.

First of all, we need to define flushing. The APICS Dictionary defines it as "A set of inventory bookkeeping methods that automatically adjusts computerized inventory records based on a production transaction. Examples of automatic relief methods are backflushing, direct-deduct, and pre-deduct processing."  This concept is quite complex, so I have written a more detailed definition:

Flushing is the process of recording the movement of inventory items from a storage location to Work-in Process (WIP). Work-in-Process here means the production area where the material will be used. There can be three type of flushing:

Forward Flushing (pre-deduct processing)—An automatic flushing type in which the movement of inventory items to WIP is automatically recorded before the Production Order is started or a single Production Order Routing step is started.

Backward Flushing (backflushing)—An automatic flushing type in which the movement of inventory items to WIP is automatically recorded after the Production Order is completed or a single Production Order Routing step is completed.

Manual Flushing (direct-deduct)—The movement of inventory items is recorded to WIP as it happens

If this were not complicated enough, we also have to consider something called Routing Link Codes in Dynamics NAV.

First let’s define routing.  I again went to the APICS dictionary to get this: "Information detailing the method of manufacture of a particular item. It includes the operations to be performed, their sequence, the various work centers involved, and the standards for setup and run. In some companies, the routing also includes information on tooling, operator skill levels, inspection operations and testing requirements, and so on."

Using the screen shots from Dynamics NAV 2013 for a Routing and Bill of Material and Item, we can see that the routing has Routing Link Codes 100 and 300 assigned for Operation 10 and Operation 40 and the Bill of Material has the Routing Link Codes assigned to components on the Bill of Material.  The Flushing method is set up on each item card.

Dynamics NAV Routing

Dynamics NAV Production Bill of Material

Dynamics NAV Item Card

Following is how Dynamics NAV handles the timing for each flushing method:

Manual Flushing—A manual flush is performed when the consumption transaction is posted by the user using the Dynamics NAV Consumption Journal or the Production Journal.

Automatic Flush—The table below discusses timing for forward and backward flushing:

The choice of which flushing method to use is dependent on your situation, but here are some thoughts to keep in mind:

• If you are using Lot or Serial Tracking, automatic flushing is not a choice.
• If the items you actually consume and use in production are typically different from what is in the Bill of Material, automatic flushing is not a choice. This may be particularly true in process manufacturing where the quantity of items consumed may be more or less than what the Bill of Material calls for.
• If your production cycle is long (more than a week), you should consider Routing Link Codes so that consumption can be recorded when the Routing Step is started or completed.
• If your production cycle is short (e.g., one day), you should consider back flushing without Routing Link Codes so that all of the items are consumed when the production order is Finished.

How to Handle Expense Items in Microsoft Dynamics NAV

I am often asked how to set up Dynamics NAV to handle Expense Items.  After searching the various NAV Forums, I thought it would be helpful to offer my solution.

The Scenario

• You want to set up Expense Items in NAV so that it is easier to enter Purchase Orders without typing the description each time as you would if you charged all expense purchases to a General Ledger Account.
• You want to be able to see the quantity on hand of all of the Expense Items.
• When you purchase an Expense Item, you want to charge the Expense in the General Ledger as opposed to putting the cost in the Balance Sheet Inventory Account.
• When the Expense Items are taken from inventory, you do not want to affect the balance in the Expense General Ledger Account.
• When you run the Inventory Valuation Report, you do not want the Expense Items to be included in the total.

The Solution

1. Create a new General Product Group = Expense

2. Create a new Inventory Posting Group = Expense

3. For each Expense Item, go to the Invoicing Tab and set up as follows:

• Set the Costing Method to FIFO.
• Set the Purchases to be the Expense Account that you want to use.
• Set the Inventory Adjustment Account to be the same Expense Account that you want to use.
• Set the Direct Cost Applied Account to be the same Expense Account that you want to use.
• Set the Inventory Account to be the same Expense Account that you want to use.
• Set the Interim Inventory Account to be the same Expense Account that you want to use.

4. On the General Tab, check the “Inventory Value Zero” box.

Accounting Detail

You purchase an expense item for $1.00

1. Receive the item – There is No G/L Effect
2. Invoice the Receipt – There is a $1.00 debit to the Expense Account and a $1.00 credit to Accounts Payable. What you are left with is $1.00 in the Expense Account and $1.00 in Accounts Payable
3. Using the NAV Item Journal, remove the Expense Item from Inventory – There is no G/L Effect

This removes the Expense Item from inventory, but leaves the balance in the Expense Account the same, and because you checked the "Inventory Value Zero" box, the item will not show up on the Inventory Valuation Report.

I hope this scenario and its solution helps with your understanding of expense items. If you have any questions, I invite you to contact us at ArcherPoint.

Adjust Cost – Item Entries Program and Prior Period Adjustments in NAV

This question often comes up:  What date does the Dynamics NAV Adjust Cost – Item Entries program use for prior period adjustments?

To understand the function of the Adjust Cost-Item Entries program, you first need to understand NAV’s Value Entries. When an inventory transaction is recorded in NAV, an associated Value Entry is automatically entered into the NAV Value Entry Table. This Value Entry reflects the cost of that transaction whether positive or negative.  Additional Value Entries may later be added by the Adjust Cost-Item Entries program. 

For example:

• A purchase receipt is made in April – A Value Entry is inserted to record the expected cost of the receipt
• A sales shipment is also made in April using the inventory received in the purchase receipt above – A Value Entry is inserted to record the Cost of Goods Sold
• A vendor invoice for the receipt is posted in May.
• NAV has been set up to allow posting only in May
• Then the Adjust Cost-Item Entries Program is run – A Value Entry is inserted to reverse the expected cost from above, and another Value Entry is inserted to adjust the Cost of Goods Sold for the shipment.

So, on what date will the program post these adjustments to the General Ledger?

There are three setups that may affect this date:

1. The General Ledger Setup “Allow Posting From/Allow Posting To”

2. The User Setup “Allow Posting From/Allow Posting To”

3. The Closed Inventory Period

Dynamics NAV will use the “most restrictive” of these dates to post the adjustments. In this case, the Adjust Cost-Item Entries will post the adjustments on May 1.

If the user wanted Adjust Cost-Item Entries to post in April, he would need to reopen the Inventory Period and change both the allow posting dates back to April.

This raises yet another question: What if the company still wanted to restrict all other users from posting in the prior period (April)?  The setup would then have to be the following:

1. Reopen the closed April Inventory Period
2. Change the General Ledger Setup for Allow From/Allow To dates to April 1 through May 31
3. Change the User Setup for Allow From/Allow To dates to April 1 through May 31
4. Then change the User Setup for all other users to May 1 through May 31

If you need help working with your Dynamics NAV installation, contact ArcherPoint for more information.

Using Routing Link Codes in MRP Planning in Microsoft Dynamics NAV

In a production environment where the production cycle is long (greater than one week) and you want to schedule in component material on a just in time basis, you can use Routing Link Codes in Dynamics NAV.

Routing Link Codes are used to make an association between a routing operation step and the BOM components that will be used in the operation.

I have set up a simple example in Dynamics NAV 2013 to demonstrate how this feature can work.  In this example, my busses are in production for five weeks and are in each work center for a week.  I want my component material to be scheduled in just in time to start production in each work center.

I set up a routing with five operation steps to produce the bus. For each operation step, I added a Routing Link Code:

Figure 1: Routing setup for five operation steps to produce the bus – each operation step has a Routing Link Code

I then set up a Bill of Material for the bus components that also have Routing Link Codes to make the relationship between the routing and the components used in that operation step.

Figure 2: Bill of Materials for the bus components – the components also have Routing Link Codes  

When I ran the MRP process (Calculate Regenerative Plan in the Dynamics NAV Planning Worksheet), I could see that the system accurately calculated the need date for each component based on the start date of each operational step.

Figure 3: Planning worksheet shows the date each component is needed based on the start date of each operational step

While my example is a simple one, it demonstrates that Routing Link Codes in Dynamics NAV may be a valuable tool in your procurement planning process. If you have questions about Routing Link Codes or your procurement planning, please contact ArcherPoint.

Revaluing Inventory with Microsoft Dynamics NAV Revaluation Journal

There are times when it becomes necessary for a company to revalue inventory. This blog entry explains how to revalue inventory using the Revaluation Journal in Dynamics NAV.

NOTE: Because Standard Cost is handled differently, I will explain it in a future entry and deal only with costing Methods of FIFO, LIFO, Average, and Specific at this time.

There are typically two scenarios regarding inventory revaluing. In the first scenario, you would want to revalue all of the remaining quantity in inventory for an item. In the second scenario, you would want to revalue a single increase to inventory (positive adjustment, for instance). This scenario could be caused by an incorrect cost posted in a Dynamics NAV Item Journal in which that inventory has already been deducted from inventory.

Most Dynamics NAV users are familiar with using the Dynamics NAV Revaluation Journal for the first scenario, but are not familiar using it with the second. Let’s look at how to revalue in each scenario using the Revaluation Journal:

Scenario 1

Looking at a Dynamics NAV 2013 Item Card below, we can see that the Unit Cost for this item is 148.10. We would like to revalue the entire inventory to 150.00.

Figure 1 – Item Card showing original cost of $148.10

Using the Dynamics NAV Revaluation Journal, run the function to “Calculate Inventory Value”.

Figure 2 – Run the function “Calculate Inventory Value” using the Revaluation Journal

The function will populate the Revaluation Journal with a line for all of the Item Ledger entries for this item that have a “remaining quantity” greater than zero. Then, repopulate the “Unit Cost (Revalued)” with 150.00:

Figure 3 – Repopulate “Unit Cost (Revalued)”

When the Revaluation Journal is posted, you can see the result on the Item Card, where the Unit Cost is now 150.00:

Figure 4 – Item Card showing revised Unit Cost

Scenario 2

If you would like to revalue a single positive entry only, you will need to use the Revaluation Journal differently. First, find the “Entry No.” you want to revalue in the “Item Ledger Entries” list for this item. 

I want to revalue the positive adjustment posted on 12/31/2013.  In the Item Ledger Entries list below, the Entry No. for that Item Ledger Entry is 34:

Figure 5 – Locate the Entry No. of interest in the Item Ledger Entries list

Next, populate the Revaluation Journal by manually entering the item number, then the Entry No.  Finally, enter the “Unit Cost (Revalued)” and post: 

Figure 6 – Enter the item number, the Entry Number, and the Unit Cost (Revalued)

You may encounter the error regarding being out of the allowed posting date range.  In this case, you might need to change the General Ledger Setup date range, the User Setup date range, and/or reopen an inventory period. The challenge here is that the General Ledger posting may be in a prior accounting period. If this is the case, you would likely post a General Journal that moves the accounting effect out of the closed period into the current period.

If you have a specific question or unique situation regarding revaluing inventory or any other Dynamics NAV costing topic, contact ArcherPoint.

Order Tracking Policy in Microsoft Dynamics NAV: A Misunderstood Setup

When you are setting up Dynamics NAV to run MRP, you want to be able to create Action Messages and track where the demand is coming from.

Because of some differences in how tracking is defined in Dynamics NAV, however, order tracking is often misunderstood. Let’s start with some definitions:   

In APICS terminology, tracking is called “Pegging”. The APICS dictionary defines Pegging as, “In MRP and MPS, the capability to identify for a given item the sources of its gross requirements and/or allocations; pegging can be thought of as active where-used information.” 

From the Dynamics NAV “Help” for the Order Tracking field: “Order Tracking Policy specifies if and how order tracking entries are created and maintained between supply and its corresponding demand.”

Our instinct, then, is to set the Order Tracking Policy to “Tracking and Action Msg.” if we want to get MRP (NAV Planning Worksheet) Planning Action Messages and Order Tracking (Pegging), shown in the screenshot below:

Figure 1 – Item Planning Tab for Item 1100 from Dynamics NAV 2013

However, when I Calculated Regenerative Plan and then selected "Order Tracking" for Item 1100, shown in the screenshots below, I not only got Action Messages but Order Tracking information as well.

Figure 2 – Planning Worksheet from NAV 2013 – Action Messages for Item 1100

Figure 3 – Order Tracking information for Item 1100

So what is the Order Tracking Policy Used for?

There is a seldom used feature in the NAV Planning Worksheet called “Get Action Messages”.

Figure 4 – Planning Worksheet Get Action Messages… command

The purpose of this feature is to do somewhat manual ”level-by-level” planning using the Planning Worksheet.

For example:

There is a sales order entered for a bicycle. Go to the Planning Worksheet and select “Get Action Messages”. The system will populate a line on the Planning Worksheet to create a new Production Order for a bicycle. Select “Carry out Action Messages” to create the Production Order for the Bicycle, then select Get Action Messages again.  The program will then suggest creating a Production Order for Front and Back Wheels.  Select Carry out Action Messages to create the Production Orders for the Front and Back Wheels.  And so on…

My recommendation is that if you are not using the Get Action Messages feature of Dynamics NAV, you should set the Order Tracking Policy to “None”. While this might seem insignificant, it is important to understand that if you set the Order Tracking Policy to anything but None, the system will create unnecessary tracking entries in the Dynamics NAV Reservation Entry Table.

If you have any questions regarding Order Tracking, please contact ArcherPoint.

Using Low Level Codes in Microsoft Dynamics NAV

In the early days of MRP (Material Requirements Planning), the designers realized that in order for the program to accurately plan inventory replenishments, they had to define demand in two ways:

Independent Demand– The demand for items that comes from outside of the company.

Dependent Demand– The demand that can be derived from upper level requirements. For instance, if you are planning to build cars, the demand for tires is dependent on how many cars you are going to build.

Once the dependent/independent demand definition was settled, the MRP designers realized that, for MRP to accurately plan for inventory replenishments, the program needed to know the levels in the Bill of Material, starting from the top to the bottom. The invention that came out of this is called the Low Level Code.

The American Production and Inventory Control Society (APICS) Dictionary defines a Low Level Code as “A number that identifies the lowest level in any bill of material at which a particular component appears. Net requirements for a given component are not calculated until all the gross requirements have been calculated down to that level. Low-level codes are normally calculated and maintained automatically by the computer software.”

Below are examples of Low Level Codes in BOM structures:

Figure 1 - Example BOM Structure 1

Figure 2 – Example BOM Structure 2

If we look at Example 1, we can see that there are four levels in the Bill of Material. We assign level numbers starting with level 0 as the top level and level 3 as the lowest level. Looking at Example 2, we can see that there are only 2 levels, 0 and 1.

The question is: What is the lowest level that a component resides in any Bill of Material structure? Looking at Item F in Example 1, we see that it is at level 3. Looking at Item F in Example 2, we see that it is at Level 1. So Item F’s Low Level code will be set to 3.

Now, when MRP runs, it will start with the Level 0 items (independent demand) and work its way down through the levels. As it plans replenishment orders at each level, it will propagate requirements for the lower level components (dependent demand). Until MRP reaches an item’s Low Level Code it will not begin to plan replenishment orders for that item.

In Microsoft Dynamics NAV, the system calculates Low Level Codes for you. This can be done in two ways.

If we look at the Manufacturing Setup Window from a Dynamics NAV Classic Client screen, there is a check box for Dynamic Low Level Code. This means that when a NAV Production BOM is certified, it will automatically recalculate the Low level Code for this BOM’s components.

Figure 3 – Select the Low-Level Code checkbox from the Manufacturing Setup screen

If we do not check the Dynamic Low Level Code checkbox, then we must run the batch job by selecting the Manufacturing->Calculate Low-Level Code function. I recommend that this batch job is run before each MRP run.

Figure 4 – Select Calculate Low-Level Code from the Manufacturing window

There is another function in Dynamics NAV that uses the Low Level Code. The program Adjust Cost –Item Entries uses Low Level Code in the reverse order. Adjust cost works its way through the BOM Structures from the bottom up (more on this in a later Blog).

If you have questions regarding MRP functioning in NAV, please contact ArcherPoint.

Determine the Actual FIFO or LIFO Value of Inventory Using Standard Cost in Microsoft Dynamics NAV

From time to time I am asked if you can you determine the Actual FIFO or LIFO value of your inventory if you are using Standard Cost. There are companies that will value their inventory at Standard for managerial accounting reasons, but for reporting or tax reasons will value their inventory at FIFO or LIFO.

To understand how Microsoft Dynamics NAV calculates Inventory Value, it is important to understand NAV’s Item Ledger Entries and NAV’s Value Entries. When an inventory transaction is recorded in NAV, an Item Ledger Entry and an associated Value Entry are automatically entered into the NAV database.  The Value Entry reflects the cost of that transaction, whether positive or negative. Additional Value Entries can be added later by adding an Item Charge or the Adjust Cost program. 

When you are using Standard Cost, you can enter two or more Value Entries in the Value Entry Table when a purchase receipt or Production Output is posted—one for the actual cost and another for the “Variance(s)”.

This means that if you want to know the actual cost of procurement or production for the remaining inventory you need to find the Item Ledger Entries that have a remaining quantity, then drill into the Value Entries to find the Value Entries with the Type = Direct, as well as eliminating those that are of the Type = Variance.

Example:

I created an item that is coded for Standard Cost and set the cost at $1.00

Figure 1 – Item Card with Standard Cost set to $1.00

I then created a Purchase Order for the item with a cost of $1.50.

Figure 2 – Create Purchase Order for the same item with a cost of $1.50

I posted the receipt and invoice for the purchase order, which created the following Item Ledger Entries and Value Entries:

Figure 3 – Updated Item Ledger Entries

Figure 4 – Updated Value Entries

You can see that, when I drilled down into the Value Entries, I can find the Direct Cost of $1.50.

To get the total cost of the remaining inventory you would divide the cost amount actual by the original quantity to get the unit cost, then multiply the remaining quantity times the unit cost.

Dynamics NAV’s costing capabilities are quite flexible. If you have a unique costing requirement, contact ArcherPoint to discuss it.

Changes to Automatic Cost Posting and General Ledger Setup in Microsoft Dynamics NAV 2013

The other day a colleague of mine at ArcherPoint pointed out that there is a change in Dynamics NAV 2013 setups that may change the advice that I have been giving to clients regarding Automatic Cost Posting and GL setup.

If we look at the Inventory Setup in the screenshot below, we can see that I have “Automatic Cost Posting” turned on and “Automatic Cost Adjustment” set to “Always”.

Figure 1 – Inventory Setup with Automatic Cost Posting turned on and Automatic Cost Adjustment set to Always

If we look at the General Ledger Setup, we can see that I have “Use Legacy G/L Entry Locking” checked (ON/YES).

Figure 2 – General Ledger Setup with Use Legacy G/L Entry Locking checked

If I try to uncheck the Use Legacy G/L Locking to OFF/NO, I get the following error:

“The field use Legacy G/L Entry Locking should not be set to NO if field Automatic Cost Posting in Inventory Setup is set to YES because deadlocks can occur.”

Figure 3 – Error in G/L Setup when Use Legacy G/L Locking is not checked

The ramification of this is that if we want to use the enhanced G/L posting performance in NAV 2013, we will not be able to use Automatic Cost Posting.  This may not matter for companies in a low transaction volume environment, but it will certainly be important for those in a high transaction volume environment.

In a later blog, I’ll discuss another difference to be aware of in Dynamics NAV 2013.

If you have any questions on this topic, please contact ArcherPoint.

To read more about changes and new features in Microsoft Dynamics NAV 2013, see ArcherPoint's NAV 2013 Blogs.

New and Changed Item Setups for MRP Planning in Microsoft Dynamics NAV 2013

The MRP planning functionality in Microsoft Dynamics NAV 2013 has some changes from the previous versions of NAV to be aware of when setting up items for MRP planning.

If we look at the Planning Tab of an Item Card, we can see the following new fields:

• Dampener Period
• Dampener Quantity
• Lot Accumulation Period
• Rescheduling Period

Figure 1 – New fields in the Planning Tab of an Item Card

The Dampener Period and Dampener Quantity were in the Manufacturing Setup form in previous versions of NAV. The purpose of these fields is to suppress insignificant “Reschedule” Action Messages.  For instance, you could suppress reschedule action messages that are under one week by setting the Dampener Period to 1W. The Dampener Quantity field suppresses “Quantity Change” Action Messages if they are smaller than what is populated in this field.

The Lot Accumulation Field was called “Reorder Cycle” in previous versions of NAV.  The APICS (American Production and Inventory Control Society) name for this field is called “Period Order Quantity”. If we look in the APICS dictionary we find the definition for Period Order Quantity is “A lot-sizing technique under which the lot size is equal to the net requirements for a given number of periods (e.g., weeks into the future).”

If we look in the APICS Dictionary for “Rescheduling Assumption” we find the following: A fundamental assumption of MRP logic that existing open orders can be rescheduled in nearer time periods far more easily than new orders can be released and received. As a result, planned order receipts are not created until all scheduled receipts have been applied to cover gross requirements.

NAV 2013 modifies this a bit:

A fundamental assumption of MRP logic that existing open orders within the Rescheduling Period can be rescheduled in nearer time periods far more easily than new orders can be released and received. As a result, planned order receipts are not created until all scheduled receipts have been applied to cover gross requirements.

If you have questions regarding changes in Dynamics NAV 2013 or MRP planning questions, please contact ArcherPoint.

To read more about changes and new features in Microsoft Dynamics NAV 2013, see ArcherPoint's NAV 2013 Blogs.

Purchases and Direct Cost Applied Accounts in Microsoft Dynamics NAV

When working on new Dynamics NAV implementations (and for that matter, existing NAV solutions), I get a lot of questions about the Purchases and Direct Cost Applied Accounts—namely, what are they used for?

We were trained in accounting that, when an inventory purchase receipt is invoiced (vouchered), we would debit the Inventory Account and credit the Accounts Payable Account and be done with it.  Dynamics NAV doesn’t handle it that way.

When we look at the General Posting Setup in Dynamics NAV 2013 (see below), we see that there is a column for the Purchases Account and the Direct Cost Applied Account.

Figure 1 - General Posting Setup in Dynamics NAV 2013

When a purchase receipt is invoiced (vouchered) in NAV, we get the following General Ledger entries:

• Dr Purchases Account for the Actual Invoice Amount
  • Cr Accounts Payable Account for the Actual Invoice Amount
• Dr Inventory Account for the Actual Invoice Amount (or Standard Cost if using Standard cost Method)
  • Cr Direct Cost Applied Account for the Actual Invoice Amount

The Purchases and Direct Cost Applied accounts should net to zero.

The net effect of these postings is that the Inventory and Accounts Payable Accounts are debited for the actual amount.

The first thing to do is to understand how this works in Dynamics NAV and set up your Posting Groups appropriately.  Then we are still left with the question, “Why?”

I am still left with no satisfactory answer.  One explanation that was given to me is that some companies budget for inventory purchases.  With the purchases account, it is then easy to compare actual to budget. Another explanation is more technical in that, depending on your setup, you can just get the General Ledger Postings for the A/P side of the transaction, then later with the Adjust Cost-Item Entries Program get the Inventory side of the transaction.

Do you have questions about other functionality in Dynamics NAV? Contact ArcherPoint; we’ll be happy to help you find the answers.

To read more about changes and new features in Microsoft Dynamics NAV 2013, see ArcherPoint's NAV 2013 Blogs.

How Microsoft Dynamics NAV Calculates the Unit Cost on the Item Card

From time to time I get the question, “How is the Unit Cost on the Dynamics NAV Item Card calculated?” It seems like a simple question, but in large part the answer is not well known.

I sometimes describe the Unit Cost on the Item Card as the “weighted average cost of the remaining inventory”. If we look at the Invoicing Tab on the Dynamics NAV 2013 Item Card, we see that the Unit Cost is 42.80.

Figure 1 – Invoicing Tab on the Dynamics NAV 2013 Item Card

The question is, how did Dynamics NAV calculate that number?

To understand how Microsoft Dynamics NAV calculates Unit Cost, one has to understand NAV’s Item Ledger Entries and NAV’s Value Entries.  When an inventory transaction is recorded in NAV, an Item Ledger Entry and an associated Value Entry are automatically entered into the NAV database.  The Value Entry reflects the cost of that transaction, whether positive or negative.  Additional Value Entries may later be added by adding an Item Charge or the adjust cost program. 

Dynamics NAV calculates the unit cost by finding the Value Entries for the item and then adds up the Cost Amount (Expected) and Cost Amount (Actual) to get the total cost.  It then adds up the Item ledger Entry Quantity and then divides the total of the costs by the total of the Item Ledger Entry Quantity to get the Unit Cost.

Figure 2 – The Unit Cost is the sum of the cost amounts divided by the total of the Item Ledger Entry Quantity

If you would like to discuss this or any other Dynamics NAV costing or inventory valuation topics, please contact ArcherPoint.

Advanced Dynamics NAV MRP Training Class at NAVUG Forum 2013

If you’re looking to learn more about Dynamics NAV MRP, you’ll have an opportunity in October of this year. Join me, Bob Bergman (ArcherPoint), at NAVUG Forum 2013 in Tampa, Florida, where I will be teaching a 4-hour, pre-conference session on Advanced Dynamics NAV MRP on Monday, October 21^st, 2013.

This is an advanced course in NAV MRP Planning whose objective is to help attendees develop a deeper understanding of the NAV MRP Planning Process. We will work with Stockkeeping Units (SKU), Multi-Location Planning, BOM Versions and ECN Effectivity Dates, Planning Parameters, and an introduction to the new NAV 2013 Planning Features.

This course is geared towards Materials Managers, Inventory Planners and Production Schedulers, and Material Management Professionals. The prerequisites include being trained or having experience in NAV Manufacturing and the ability to navigate in NAV Classic or Role Tailored Client.

Find out more about NAVUG Forum and register soon; this conference is a great source for learning and networking. I look forward to seeing you all there.

Using the Microsoft Dynamics NAV Item Journal to Issue Items to Different Expense Accounts

This blog entry discusses how to use the Dynamics NAV Item Journal to issue items to different expense accounts.

Scenario:

You would like to Debit different General Ledger Expense Accounts when you issue stockroom material using the Dynamics NAV Item Journal.  For instance, if the engineering department uses stock room inventory for a project, you would like to debit the Engineering Expense Account for the cost of the inventory.

Without doing any additional setups, we know that when stock room material is issued, we get the following General Ledger effect:

Dr Inventory Adjustment Account

Cr Inventory Account

Instead of debiting the single Inventory Adjustment Account, however, we would like to debit the Engineering Expense Account

Using the Dynamics NAV 2013 General Posting Setup in training classes, I explain that the General Business Posting Group is the “Who” part of the transaction and the General Product Posting Group is the “What” part of the transaction.  The General Business Posting Group comes from the Vendor or Customer Card, and the General Product Posting Group comes from the Item Card.

For transactions that are internal to the company, there is no Who part of the transaction, so the system uses the General Business Posting Group “blank”.  In this case, the Inventory Adjustment Account is 53400.

Figure 1 – General Posting Setup. Note that the General Business Posting Group is blank because the transaction is internal to the company

If we want to use another account for inventory adjustments, we need to find a way to direct the Inventory Adjustment Account to a different account number.

In this example, we set up a new account for Engineering Expense:

Figure 2 – G/L Account Card with new Engineering Expense account

Then we set up a new General Business Posting Group called Engineer:

Figure 3 – New General Business Posting Group called “Engineer”

We then make a new setup in the General Posting Setup to use our new General Business Posting Group to direct the Inventory Adjustment Account to the Engineering Expense Account:

Figure 4 – Modify the General Posting Setup Card to use the new General Business Posting Group

The stockroom personnel will be trained that when material is issued to the Engineering Department, they will need to populate the General Business Posting Group with ENGINEER.

Figure 5 – Item Journal with General Business Posting Group set to ENGINEER

When the Item Journal is posted, we see that the Debit did in fact go to the Engineering Expense Account:

Figure 6 – General Ledger showing debit to Engineering Expense Account

To further discuss this or another Dynamics NAV costing question, please contact ArcherPoint.

Creating Production Orders in Bulk Using the Microsoft Dynamics NAV Planning Worksheet

I have a couple of clients that have not yet gone live with the MRP (Planning Worksheet) functionality in Dynamics NAV. They determine the need for Production Orders outside of Dynamics NAV and then create the production orders one at a time in NAV.  There are times when they create over 100 production order in a day.

The keystrokes to create a Production Order manually are:

1. Select ‘New’
2. Key in ‘Enter’ to get the next Production Order from the Number Series
3. Key in the ‘Source Number’
4. Key in the ‘Due Date’
5. Key in the ‘Quantity’
6. Key in ‘Location Code’
7. Select ‘Refresh Production Order’
8. Wait until it refreshes, then key in the next order

Using the Planning Worksheet in Dynamics NAV 2013 to Bulk Create Production Orders is much simpler:

1. Key in the Item Number
2. Key in the Quantity
3. Key in the Due Date
4. Key in the Location code

(For the next lines use the <f8> key to copy the cells above if applicable)

Figure 1 – Using the Planning Worksheet in Dynamics NAV 2013 to Bulk Create Production Orders

Then, for all of the lines in the Planning Worksheet, select ‘Refresh Planning Line.’  Remove the Line No. filter, then select OK.  This will refresh all of the lines in the worksheet, bringing in the component demand and routing.

Figure 2 – Selecting Refresh Planning Line on the Planning Worksheet

Select ‘Carry Out Action Message’ and ‘Firm Planned,’ then OK.  This will create Production Orders for all of the lines in the Planning Worksheet.

Figure 3 –Carry Out Action Message will create Production Orders for all of the lines in the Planning Worksheet

If you would like to create ‘Released Production Orders’ in this way, ask your Microsoft Partner to give you that option.

I did not calculate the time savings by using this method to create Production Orders, but my guess would be over a 50% time savings.

For more information on creating production orders in bulk or other topics related to Dynamics NAV Manufacturing, please contact ArcherPoint.