This is the second post in a row for me, centered on a seemingly random checkbox setting. Don’t worry, I’m not on a personal mission to use only obscure checkboxes as my blog inspiration. Although, when the thought crossed my mind, I did pause to reflect on the possibility. There’s plenty of them available to choose from, after all.
I was working with a client having some issues getting their desired sales cost to post. When describing the issue, he was deep into some complexities related to costing of configurable items (they use a configurator), and he was also concerned about potential complications with the drop ship scenario in question. The key, in this case, came down to a few facts:
- A unique Configuration ID is being used on each transaction (meaning that each time the sell this product, we have a new Configuration ID), but they do sell the product a lot. Because of this, the assumption was made that there is plenty of inventory and on-hand value.
- They are using the ‘cost by combination’ setting that means each unique combination of Product Dimensions has its own cost calculation. This also means that with a new configuration ID on each sale means we have zero receipt transactions and zero inventory value for that configuration ID at the time of the sale.
- The sequence of events consists of: Purchase order receipt, sales order shipment, purchase order invoice.
I suspected, based on these three facts, that the purchase order receipt was not being used in the calculation of cost. There’s a setting that controls this behavior on the item model group called ‘Include Physical Value’.
What is the setting ‘Include Physical Value’ and what does it do?
At the core, Include Physical Value is a simple setting. If marked, receipt transactions in a ‘physical’ status will be used when calculating COGS and/or inventory value during a sale any issue transaction. If unmarked, they will not be used in the calculation of COGS and/or inventory value.
If a receipt transaction is in a ‘physical’ status, that means that it is Received but not Invoiced (in the case of a purchase order), or Reported as Finished but not Ended (in the case of a production order).
At first glance, it seems like an obvious choice to mark and make sure all inventory is included in the calculation of COGS and/or inventory value. There are a couple of key things to consider.
Considerations for Purchased Items
There are a couple of purchase order scenarios that may be problematic if you have ‘Include Physical Value’ marked:
- Unreliable purchase prices – If you cut and receive purchase orders, without having reasonable pricing on the order, this can result in large variances of cost between receipt and invoice. This just means that your inventory value when you post an issue transaction may be way out of line.
- Product with large swings in price – This is a similar situation as the first issue. If the purchase price of any items swing significantly between receipt and invoice, this can result in a significantly incorrect COGS/inventory value posting.
It’s worth noting that both of these issues result in temporary incorrect COGS/Inventory posting, as long as inventory close is run, as that routine will correct the variation if the receipt is financially posted.
Considerations for Manufactured Items
The implications of this setting may be more important for manufactured items. As you may know, the Report as Finished (RAF) function cannot calculate Actual costs for a production receipt. Rather, the best we can do is use estimated cost to value RAF inventory. (You need to set a parameter in order for estimated to be used – otherwise it will be zero.) The setting in Dynamics AX 2012 can be found at: Production Parameters > Report as Finished > Use estimated cost price. I suspect this could be a calling for my next article.
Since we cannot use actuals to value inventory at RAF, this means we’re depending entirely on the estimation (uses BOM and Route and recent calculation) for valuation of the finished good inventory, and thus, the value of that inventory if sold or issued into another production.
In this case, with a zero dollar RAF value or badly estimated cost, significant deviations, and large dollar value issues may come up.
*It must be noted that this setting is not relevant for Moving Average costing.
Include Physical Value Setting Summary
You’ll want to carefully consider this setting, and it may cause you to split your products into more model groups than expected. Don’t assume that all products are created equal in terms of the way you want to value inventory/COGS.