Support for BOMs that includes items with different product dimensions of the same item

This blog post describes new functionality released with the Microsoft Knowledge base (KB) in article 3089402.
 
When using one or multiple of the product dimensions in production, you can have situations where you would like to produce an item, based on a different variant of the same item.
There are many scenarios where this can be useful, e.g.
•  A Green variant of a specific item that is produced using a white variant of the same item.
•  An item variant produced using a different configuration of the same item.
•  Large item variant cut into multiple smaller variants of the same item.
 
Until now it has been mandatory to use different items for the parent and child product respectively. If this was not the case, the user would get a warning from the BOM check that circular reference is not allowed. If the warning was ignored MRP might fail. This warning was caused by the fact that the level check and the BOM level calculation was done per item.
 
With KB3089402 you can use the same item as both parent and child in a BOM - as long as minimum one product dimension differs.

This means that an item can now have multiple levels. In this case:
•  Item A Config 1 is level 0
•  Item A Config 2 is level 1
•  Item A Config 3 is level 2

Required setup
Inventory model: To ensure correct costing, items with BOMs including variants of the same item must use standard cost.
BOM check: Circularity check strategy have to be set to 'Optimize for high complexity'. The other option 'Optimize for low complexity' has not been updated, and will detect circularity for item variants produced from the same item.

High level KB changes
•  Update BOM level calculation for planning: Will include any used product dimensions (Configuration, Size, Color, Style).
•  A correct configured BOM will need to have at least one product dimension that differs. Blank is not a value. The product dimension that differ must be set on both parent and child item in the BOM structure.
•  MRP, Predetermine cost calculation, and Actual cost calculation (inventory closing) is updated to use item and product dimensions with the new BOM levels.

Important implementation note
Ensure that the reqItemLevel table is empty before the first MRP (Master Schedule) run. Any change, like creating or modifying an item, will generate entries to the table and as a result it will not be empty.
The simplest way to do this is to truncate the reqItemLevel table, and then run a full MRP (regenerative with no filters). Otherwise MRP will not generate any planned orders!

 

Q&A

Q: What dimensions are supported?
A: The Product dimensions: Configuration, Size, Color & Style

Q: Will this require additional setup?
A: Only adding the relevant product dimensions to the BOMs, and ensuring to use Standard cost as well as the Circularity check strategy Optimize for high complexity. Also notice the implementation note regarding reqItemLevel.

Q: Will BOM circularity be checked for local changes on Production and Batch orders?
A: No, this KB is not changing what triggers the circularity check, as this is beyond the scope of the KB.

Q: Will this KB address issues related to rework scenarios, where exactly the same item and product dimensions are both input and output of production/batch order?
A: No, rework is outside the scope of this KB.

Q: What is the impact on performance?
A: Impact is none or minimal for both circularity check and MRP. There is a bit more data to process, but information is now stored outside InventTable. MRP tasks are per Product and BOM level, so multi thread of products with variants on different BOM levels is possible and can give minor performance improvements. Our tests have shown less than 5% change in performance based on this KB.

Q: Can I produce a specific variant from “any variant” - e.g. a Red variant from any (Blank) variant of the same item?
A: No, blank is not a value. The product dimension that differs must be set on both parent and child item in the BOM structure. So in this example you will have to choose a color for the used component.

Q: Will the BOM level calculation be stored in the same location for both Planning and Costing?
A: No, that changed with this KB. Costing will continue to use the current BOM level calculation stored in the InventTable. For planning (MRP) a new table is created to store the BOM levels with both Item and Product dimension information. This design will make it possible in the future to differentiate the processed data for Planning vs costing, e.g. ensuring that ended production orders are not included in BOM level calculation for MRP planning.

Q: Will the BOM consistency check uptake support for product dimensions as well?
A: Yes, with Circularity check strategy set to Optimize for high complexity.

Q: Does this mean that we now have the same options for product dimensions as for items?
A: No, but this is a step on the road to full variant support in AX - and a very important step :-)

T-Shirt example with screenshots
A Green variant of a T-Shirt item is produced, using a white variant of the same item.

First we set the Circularity check strategy to Optimize for high complexity. Optimize for low complexity does not support BOMs that includes items with different product dimensions of the same item.

Create new T-Shirt item with Product dimension for Size and Color, using standard cost

Define size and colors for the product

Create all the variants for the product. We now have 9 variants of the T-Shirt:
 - Size: Small, Medium and Large
 - Each size in the Color: White, Red, Green

We can now create a BOM for producing a medium green T-Shirt, using a medium white T-shirt

The Circularity check will pass, since the color dimension differ

Say we made a mistake and tried to produce a medium green T-shirt from the same medium green. Then we would get an error, indicating that we have a circularity loop in our BOM:

Let’s modify the item coverage to ensure that the white T-Shirt is purchased. The green T-Shirt is produced and with a minimum of 3 to trigger a supply when running MRP

Now let’s run MRP and look at the planned orders generated for the T-Shirt

Notice that we get planned orders to produce 3 medium green T-Shirts, and purchase 3 medium white T-Shirts. Also, looking at the Explosion, you can see that the two colors have different levels

Comments

• Anonymous
  December 22, 2015
  Hi Cristian, very good post! I want add that this feature will be very helpful with the repair process: In this process you consume the same ítem as the finished one, linking the cost and the traceabilty of bom ítems (from the original one up to the repaired one). With the product dimensión you can separate the good ones from the repaired ones. Regards, Carlos B.

• Anonymous
  December 22, 2015
  The comment has been removed

• Anonymous
  December 22, 2015
  Hi, thanks for this excellent explanation. Any particular reason why standard cost is needed? Is it imposed and/or what are the consequences of using another model? All oportunities in our customer base that I know of would require FIFO... Regards, John

• Anonymous
  January 03, 2016
  Hi Carlos, thank you for the input. I agree, as long as you avoid circular references of the product dimensions this would be possible for repair processes. Meaning that the repared item should not return to a previous product dimension again. Product dimensions could be Original -> Broken -> Fixed.

• Anonymous
  January 03, 2016
  I'm also curious about the 'standard costing' requirement, especially because the new bom level calculation is specific to planning/mrp. However, it was a feature that we were asking for for a very long time so I'm pleased to see some progress here! Thanks!