Being able to handle consignment inventory in Microsoft Dynamics NAV is a common requirement. There are four scenarios of consignment inventory that I frequently bump into;
1. Inventory at a Customer
2. Inventory at a Vendor
3. Customer Owned Inventory
4. Vendor Owned Inventory
Some may argue that case 2 and 3 is not consignment, and they might be right, but nevertheless they are cases that needs to be handled and to me the overall concept is closely related to consignment inventory and therefor I included them here. Case 2 and 3 are typically found in relation to subcontracting or product repairs. Case 1 and 4 are the classic examples of Vendor Managed Inventory (VMI).
Here is how it can be handled in Dynamics NAV using the standard functionality;
Inventory at a customer can be handled by creating a location that represent the customer and replenish it using transfer orders. You then invoice from the customer location based on what they used.
What I recommend is to create locations using the same codes as the customer numbers, the location ‘C-10000’ is created for customer ‘C-10000’ for example (I prefer to have prefix for master data codes and not just numbers like it Cronus). The location should have the same name, address, etc. and typically does not require bins or any type of warehouse transactions.
You can then define the inventory posting setup for the customer location(s) to point to a specific consignment inventory account in the balance sheet. This way it is separated from an accounting point of view as well.
When the customer asks you to replenish the inventory you just create a transfer order to transfer the items to the customer.
The transfer order has the advantage that you can process the shipments the same way as you process regular sales order shipments (see processing of shipments) and you get packing slip etc. printed from Dynamics NAV.
You also have the option to create a SKU for the items at the customer locations and through the planning parameters and MRP get suggestions of what to transfer. This could be useful if you have an agreement with the customer to keep the stock at a certain level. Don’t forget to setup the transfer routes if you want to do this.
In your balance sheet you now see the inventory you have at customers separated on a different account.
When the customer communicates that they have used some of your inventory you just create a sales invoice with the items at the customer’s location and post it. This depletes the inventory at the customer, creates the COGS, revenue and the AR. The alternative to a sales invoice would be to create a sales order that is shipped and invoiced; the end result will be the same.
This way of handling consignment inventory at a customer location is straight forward and works well.
Similar to how you would handle inventory at a customer you can also have your inventory at a vendor. This is typically for subcontracting processes where a vendor performs operations on your parts (see subcontracting posts).
You create a location for the vendor, preferably with the same code as the vendor number and the same address. Just like with the customer in the previous example.
You also have the option to define the inventory posting setup to separate the inventory at vendors on a separate inventory account in the balance sheet. This time it might be raw material that you have at the vendor (and not finished goods like in the case of the customer). If it is for subcontracting where the vendor is going to consume your inventory then you also need to setup a WIP account, the WIP account is by NAV determined using the location where the components are consumed in combination with the inventory posting group of the item being produced (see production order posting into general ledger for more information).
I am a big fan of doing the posting setups as needed in Dynamics NAV, so if you never going to have finished goods at a vendor then don’t do the setup for this account. This way you also control what transactions that are possible. I know consultants that by default sets up all different combinations and populates all the accounts in the setup matrixes, I think that approach makes the setup more confusing than necessary.
You then replenish the inventory at the vendor using transfer orders and you can get packing slips, etc. (the same way as with the customer example).
The inventory value in the balance sheet has now moved to the inventory at vendors account.
When the vendor informs you that they have used any of the inventories you consume it against the production order (in case of subcontracting). The inventory at the vendor location is then credited and WIP is debited.
If you handle inventory that is owned by the customer then you want to make sure there is no inventory value associated with the items. You do this by checking the inventory value zero field on the item card (a field that needs to be added to the page).
If it is an item that you initially sold to the customer that is going back to be repaired then a good option is to create a new item with the same item number plus a prefix (like ‘-C’ in the end). No need to setup separate g/l accounts or posting groups.
You can then handle the inventory just like any other inventory on your regular location(s), which is typically what you want. The receiving part can be done based on sales return orders, this way you have a process to do the receiving and you have a record for the receipt (the sales return receipt).
The only thing to make sure is that the sales return order is for a zero amount (if the customer is not going to get a credit that is) and that it gets closed by being invoiced.
If the customers inventory is used as a component in a production process (like performing subcontracting or repairs) then the value of the finished product will be the value of the components that where used from your regular inventory (if any) plus the capacity costs (labor and overhead) you added to the production process.
If you have inventory that belongs to vendors then the main thing is to setup posting groups that allows you to separate the inventory value that belongs to vendors from your own inventory. You do normally want the inventory costs on the items to be maintained since you are going to pay for it when you use it. If you are on a standard costing method you want the standard costs of your manufactured items to include the cost of the vendor owned items and if you are on a FIFO costing method you want the cost of your products to include the costs of the vendor owned items once they have been produced (since you pay for them).
From an operational point of view you want to be able to receive the inventory, move it around, count it, and use it just like it was your own inventory.
The way to handle this is to create separate posting groups, you need both a separate inventory posting group and a separate general product posting group. In this case I call them both ‘CONSIGN’.
The inventory posting setup is then defined to have the expected inventory value on a separate consignment inventory account in the balance sheet.
In the general posting setup you define the inventory accrual accounts to go to a separate account next to the expected inventory account in the balance sheet. The direct cost applied can be the same as the regular direct cost applied account in the P&L.
Now you have separate accounts in the balance sheet where you will have transactions when you receive the vendor owned inventory which net each other out. Note that some would prefer to use liability accounts (instead of an asset accounts) for this, I prefer having it together with the rest of the inventory like below, both ways work.
When you do get the invoice from the vendor those transactions will be reversed and the in inventory will be posted against the regular inventory accounts.
Here is how it would work;
The item is setup with the consignment posting groups. In this case I use the standard costing method and the cost of the item is $10.
I establish a purchase order with the vendor that would cover a period of time (almost like a blanket purchase order). The vendor sends you inventory and you receive it just like you would receive any other inventory against the purchase. The transactions you get in the general ledger will be as below after receiving 100 pcs @ $10.
The offset account makes sure that you don’t inflate your inventory value with something that is owned by a vendor. The inventory sub ledger will still show that you have 100 pcs in inventory and when you run your inventory valuation report you could exclude the items with the ‘CONSIGN’ posting groups.
You can then move then inventory around and use it as you normally would do. When consumed it creates WIP as regular inventory would, and if sold it creates COGS as regular inventory would. This is ok, and something you want since you are now going to pay for what you have used.
Below is the result of consuming 40 pcs of the vendor inventory against a production order. The vendor consignment inventory account is credited and WIP is debited.
The inventory used is communicated to the vendor who sends you an invoice. The purchase invoice is posted just like a regular purchase invoice (in this case I use the ‘get receipt lines’ function to retrieve the oldest receipt and invoice it (I want the oldest one since that is the item ledger entry that has been consumed or sold, the exception to this might be if the inventory is serial or lot number tracked, then you need to invoice the receipt that is related to the serial or lot number that was used). Note that you only want to invoice what you have used and not what has been received. In our case 40 pcs out of the 100 pcs received.
Invoicing the receipt debits the vendor consignment offset account and credits accounts payable. In case of standard cost you might also get a purchase price variance posted into the P&L. The inventory value for the vendor’s inventory is now netted to zero again.
Note that the above examples uses the expected cost postings, which is something I think everybody should use (at least if you are in a manufacturing environment).
This was all I could think of in relation to consignment inventory.
Make sure to visit the new Dynamics NAV FAQ section on my blog.
The post Consignment Inventory first appeared on Olof Simren - Microsoft Dynamics NAV & 365 Business Central Blog.
Olof Simren - Freelance Microsoft Dynamics NAV Expert
Naviona - Microsoft Dynamics NAV Partner