Month: December 2015

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

Reporting as finished with the option to mark the order as ended

This blog post describes a new hofix that is released in the Microsoft Knowledge base (KB) in article 3124753.

When reporting a batch order or a production order as finished with End job, the order state will be updated to Reported as finished. This state indicates that no more finished goods are going to be reported and no more time and material is going to be consumed by the order. As a consequence, any inventory transactions with remaining quantities for both materials and the finished goods will be closed.

So far the End job option has only been supported when reporting as finished from the AX Client and not from the hand held device. With this hotfix the End job option is now also available with reporting as finished from the hand held device.

This hot fix also leverages the Physical reduction parameter in the production control parameters. Setting this parameter can be helpful in for example material back flushing scenarios where it will prevent the reporting as finished process to error out in case of material stock out.

Configuration of the menu item

A new parameter End job has been introduced in the Mobile device menu item for the work creation process Report as finished and put away.

When setting this parameter the End job field will be visible when reporting as finish on the hand held device.

Reporting as finished with End job

Reporting as finished with the End job option can be demonstrated by using a simple Formula FinGood with a formula line named Ingredient. A batch order is created for FinGood

 

The formula line is set up with flushing principle Finish

 

Also note that the formula line is set up with a variable scrap percentage of 5.

The batch order is now Released and warehouse work for raw material picking is created. 

 

The work for raw material picking is processed and the ingredient is now available and physically reserved on the production input location.

 

Note that the quantity is 1050 as it includes the estimated 5% scrap.  

The batch order is Started and after some time a partial quantity of 500 is reported as finished from the hand held device

 

Note that the field End job is set to No as we are reporting a partial quantity.

After reporting as finished is completed a quantity of 500 pieces of the finished product is on-hand and the material Component has been back flushed proportional to the reported as finished quantity which can be seen on the material inventory transactions.

Now the last quantity of the FinGood is reported as finished. To indicate it is that last quantity the End job field is set to Yes.

In this example the batch order is over producing with a quantity of 3 (500+ 503), because less material than the estimated 5% was scrapped during the production thereby enabling more finished goods to be produced. As back flushing is consuming proportional to the reported as finished quantity, the system will in this case try to consume 503 + 5% = 528. As there is only 525 left on the input location this will cause the process to error out due to material shortage

 

 As only 525 was consumed (because we had a lower scrap than estimated) we want the system to consume the remaining quantity of 525 on the input location and not try to consume more.

To support this scenario, the Physical reduction property, that is set up in the Production control parameters, can be used. Using it, will ensure that the system will only try to consume the physical available quantity during back flushing. The parameter is only leveraged, in this scenario, when the End job is set to Yes on the hand held device.

 

 

With the Physical reduction parameter set, let us again try to report a quantity of 503 as finished with End job

Looking at the batch order, the status has now changed from Started to Reported as finished

In total a quantity of 1003 has been reported as finished

With the consumption of the original estimated quantity of 1050 of the ingredient