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
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!
A: The Product dimensions: Configuration, Size, Color & Style
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.
A: No, this KB is not changing what triggers the circularity check, as this is beyond the scope of the KB.
A: No, rework is outside the scope of this KB.
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.
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.
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.
A: Yes, with Circularity check strategy set to Optimize for high complexity.
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