Tag: SCM

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

Checklist for improving MRP performance – Part 2: How to setup planning parameters

If Master Planning (MRP) runtime is too long, here are a couple of simple things you can try in order to improve it. You must, of course, try these out on a test environment first and, if you see an improvement, apply the same settings to the production environment. It is recommended that you apply one setting at a time, so you can get a good sense of what helped and what didn’t. Some of the settings below will not only have an effect on runtime, but may also improve your plan quality. The list was compiled for Microsoft Dynamics Ax 2012, so parts of the checklist may not apply to earlier versions.

1. Items assigned to the same coverage group should have similar lead times

Coverage parameters, such as the coverage time fence, negative days and positive days, relate to the lead times of the items inside the coverage group. If there is a disconnect between the lead times of the items and these parameters, master planning may create unnecessary planned orders, leading to potential suboptimal planning outcome and potential longer execution times. Items assigned to the same coverage group should have similar lead times.

Be sure at all times that you have the latest hot fixes related to lead times applied to your environment. One example is KB article 2938941: https://mbs2.microsoft.com/Knowledgebase/kbdisplay.aspx?WTNTZSMNWUKNTMMYZWLSWZQTLLRPPXLZNRORZMMMSSMTMNPU

 

2. Master planning parameters – Use dynamic negative days parameter should be checked

The negative days setting is connected to the lead time of the items. If the negative days are less than or equal to the item’s lead time, unnecessary planned orders may be created. Consider the following example: current date is 1st May, there is a sales order for 1 piece of item A on 5th May, item A has a lead time of 6 days and there is a purchase order for 1 piece of item A on 8th May. The negative day setting is 2, which is less than the item A’s lead time. Master planning will create a new planned purchase order for 1 piece of item A, which, according to the lead time will be delivered 7th May. This is just 1 day before the already existing purchase order. Firming this new planned purchase order may lead to unused inventory piling up. Creating planned orders that are not useful increases master planning runtime for no reason.

Checking Use dynamic negative days parameter makes sure that the connection between the item’s lead time and the negative days is taken into account during planning. Consider the following example: current date is 1st May, there is a sales order for 1 piece of item A on 5th May, item A has a lead time of 6 days and there is a purchase order for 1 piece of item A on 8th May. The negative day setting is 2, which is less than the item A’s lead time. Master planning will not create any planned purchase orders. The sales order will be fulfilled using the existing purchase order.

 

3. Negative days parameter on the coverage group should not be less than the lead time of the items assigned to the coverage group

If the negative days are less than the item’s lead time, unnecessary planned orders may be created. Consider the following example: current date is 1st May, there is a sales order for 1 piece of item A on 5th May, item A has a lead time of 6 days and there is a purchase order for 1 piece of item A on 8th May. The negative day setting is 2, which is less than the item A’s lead time. Master planning will create a new planned purchase order for 1 piece of item A, which, according to the lead time will be delivered 7th May. This is just 1 day before the already existing purchase order. Firming this new planned purchase order may lead to unused inventory piling up. Creating planned orders that are not useful increases master planning runtime for no reason.

Negative days parameter on the coverage group should not be less than the lead time of the items assigned to the coverage group.

A KB article you should make sure you have installed is 2736992 https://mbs2.microsoft.com/Knowledgebase/kbdisplay.aspx?WTNTZSMNWUKNTMMYMWMSYTMOWZPWLSWNTQWWSZZVXMWPMSOX

 

4. Positive days parameter on the coverage group should not be 0 or empty

If the positive days parameter on the coverage group should is 0 or empty, then existing incoming orders will not be taken into account for planning and new planned orders will be created. Note that on hand will always be consumed, regardless of the number of positive days set. Creating planned orders that are not useful increases master planning runtime for no reason. Firming these planned orders may lead to unused inventory piling up. Positive days parameter on the coverage group should not be 0 or empty.

 

5. Items that are regularly procured or produced should be assigned to coverage groups where the Positive days parameters is equal to the item’s lead time

If items have lead times bigger than the Positive days parameter on the coverage group, unnecessary planned orders may be created. Creating planned orders that are not useful increases master planning runtime for no reason. Firming these planned orders may lead to unused inventory piling up. Items that are regularly procured or produced should be assigned to coverage Groups where the Positive days parameters is equal to the item’s lead time.

 

Checklist for improving MRP performance – Part 1: How to run MRP

If Master Planning (MRP) runtime is too long, here are a couple of simple things you can try in order to improve it. The list was compiled for Microsoft Dynamics Ax 2012, so parts of the checklist may not apply to earlier versions. You must, of course, try these out on a test environment first and, if you see an improvement, apply the same settings to the production environment. It is recommended that you apply one setting at a time, so you can get a good sense of what helped and what didn’t. It is also recommended that the test environment is as close as possible to the production environment in terms of data volumes: number of products and number of transactions. If you are running MRP in recurrent batch, note that some of the settings will be cached, so it’s better to make the parameter change and re-create the batch and then run MRP again.

 

1. Use helpers for master planning

Using helpers (parallel processing threads) during master planning will most likely improve the runtime. Request one or more helper threads when running master planning, by setting the Scheduling helpers – Number of helpers parameter in the Master scheduling dialog to a value greater than zero.

More information about helpers can be found here:

TechNet: http://technet.microsoft.com/en-us/library/gg242496.aspx

InformationSource: https://informationsource.dynamics.com//RFPServicesOnline/Rfpservicesonline.aspx?DocName=TC2014+Help!++MRP+is+slow%7cQJ4JEM76642V-8-1608

Also make sure you have applied to the Ax environment the latest hot fixes related to helpers. Below are just a couple of KBs that you should consider installing or porting to your AX version:

KB article 2693422 https://mbs2.microsoft.com/Knowledgebase/kbdisplay.aspx?WTNTZSMNWUKNTMMYTPNRYVZNNPWYSWVQRWURNYWNXVKVRNQY

KB article 2690230 https://mbs2.microsoft.com/Knowledgebase/kbdisplay.aspx?WTNTZSMNWUKNTMMYTPNRYVZNNPWYSWVQUOLKVSMVQULNVYQT

KB article 2862912 https://mbs2.microsoft.com/Knowledgebase/kbdisplay.aspx?WTNTZSMNWUKNTMMYVWQXNRNXTVKNSKYVQNYNRZQRRRTPMQYY

 

2. Number of helpers used during master planning needs to be less than or equal to the maximum number of threads allowed on the batch server

It makes no sense to have the number of threads requested by planning greater than the sum of available batch threads on all batch servers in the selected batch group that runs master planning. Set the number of master planning helpers to be lower than the sum of available batch threads on all batch servers in the selected batch group to run master planning or increase the number of threads on selected batch servers.

To check the number of available batch threads per server/batch group go to System administration – System – Server configuration

 

3. Use multiple AOSs for master planning

Using more AOSs during master planning will most likely improve the planning runtime. It is also very important that you make sure no other lengthy routine is running simulataneosuly with master planning. It is also very important that you make sure no other routine requireing locks on tables used by master planning (for example InventTrans, InventSumLogTTS, ReqItemTable, etc) is running at the same time as MRP. 

 

4. Configuration keys that are not actively used should be disabled

For example, when Process Industries functionality is used, a lot of additional planning logic is being triggered, like for instance expiration dates for batches. This will increase the master planning runtime. If Process Industries functionality is not used, make sure the ‘Process manufacturing’ configuration key is switched off.

 

5. Action message usage

Calculating action messages leads to longer master planning runtime. If action messages are not analyzed and applied on a regular basis (daily, weekly, etc), consider disabling the calculation during the master plan run, by making sure the Action message time fence is 0 on the master plan you are running (Master planning – Setup – Plans – Master plans). Also make sure all the coverage groups have Action message setting disabled.

 

6. Futures usage

Calculating futures leads to longer master planning runtime. If you are not planning BOMs or if propagating delays from supply to demand during planning is not needed for you, consider disabling futures calculation during MRP, by making sure the Futures time fence is 0 on the master plan you are running. Also make sure all the coverage groups have Futures setting disabled.

 

7. Number of tasks in a master planning helper task bundle

Changing the number of tasks in the task bundle may have a positive effect on the runtime. The number of tasks in a bundle controls how many items are planned together by a single helper. It is recommended to increase the number of tasks when the number of items is very large (hundreds of thousands) and decrease the number  of tasks otherwise. In most cases it is a trial and error approach before an optimal value is determined. Remember to change this value as you add to Dynamics Ax more and more products!

 

8. Caching during master planning should be set to Maximum

Master planning logic is controlling the amount of caching used. This parameter is obsolete and is a candidate for removal in future versions of Microsoft Dynamics AX. In all the companies master planning is executed, consider setting Master planning parameters –  Use of cache to Maximum

Generating put away work when reporting as finished from the Dynamics AX client

This new functionality is available with KB 2999768 and will be included in Microsoft Dynamics AX2012 R3 CU8. To find the HF you can use LCS Issue Search.

What’s new?

In the AX2012 R3 release put away work could only be generated when you used the reporting as finished process on a mobile device for a production or batch order. In CU8 put away work can now also be generated when you use the reporting as finished process for a warehouse-enabled item from the AX client.

In this blog I am going to walk through two scenarios showing how put away work is now created when reporting as finished from the Dynamics AX client. In this example I am going to use item L0101 from the USMF demo data company

 

Simple scenario : Shannon has completed the assembly of ten speakers in her work cell. She reports the speakers as finished in the route card journal and put away work is generated.

A production order for twenty pieces of mini-speakers exists and is in the status Started:

Shannon completes the assembly of the twenty Mini-speakers and reports the quantity as finished in the route card journal:

Shannon provides the journal line with a license plate number:

When Shannon posts the journal, put away work is generated:

 

Advanced scenario : Shannon is working on a production order assembling ten Mini-speakers. Shannon has completed the assembly of eight speakers and reports them as finished in the job registration terminal form and put away work is generated. Shannon completes the assembly of the remaining two speakers but does not have time to report them in the terminal, because she has to rush home. Lars promises Shannon that he will take care of reporting the remaining quantity as finished.

A production order for ten pieces of mini-speakers exists and is in the status Started:

Shannon has started the assembly of 10 mini-speakers:

Shannon is now going to report eight pieces as finished from the Job registration form in the manufacturing execution system. In the feedback form Shannon provides a license plate number. This number identifies the goods that Shannon is reporting to the output location of her work cell. The license plate number will be used by the warehouse worker to identify the goods that he is going to put away from the output location to the finished goods locations:

Note: The license plate field is enabled in the feedback form under the following conditions

  • The item is enabled for the new warehouse processes
  • The shop floor operator is reporting on the last operation in the production route

After Shannon has confirmed the feedback of eight pieces of mini-speakers, put away work is generated:

As it can be seen this work suggests that the eight Mini-speakers are put away from the production output location to the finished goods location.

In order to report the remaining two Mini-speakers, Lars opens the production order form and selects the Report as finished function. Here he enters the remaining two pieces and the license plate. In this case he uses the same license plate as Shannon did when she reported the first eight speakers:

After confirming the report as finished, put away work has been generated for the remaining two speakers that were reported by Lars:

The different options for reporting as finished is outlined in the table below. All these options now supports the generation of put away work:

Option

Description

Report as finished

Dedicated function on the production/batch order form or list page. Has advanced options to for example back flush materials. Typically used by the shop floor supervisor role

Report as finished journal

Journal to post the quantity reported as finished for production or batch orders. Typically used by the shop floor operator role

Job card journal

Journal to report time and quantity for route operations. Option to report a quantity as finished when reporting on the last operation. Typically used by the shop floor operator role

Route card journal

Journal to report time and quantity for production jobs. Option to report a quantity as  finished when reporting on a process job for the last route operation. Typically used by the shop floor operator role

Current operations

List page showing ongoing operations on the shop floor. Option to report a quantity as finished when reporting on the last operation. Used by the shop floor operator role

Report feedback in job registration form

Form that is optimized for manufacturing execution on the shop floor in a kiosk or terminal installation. Option to report a quantity as finished when reporting on the last operation or a process job for the last operation. Used by the shop floor operator role

Hand held device

Menu items on hand held device offering reporting production or batch orders as finished. Used by the shop floor operator role

 

Summary

In CU8 it is now possible to have put away work generated when reporting quantity on a production or batch order in the Dynamics AX client. For example this can be useful for customers who wants to enable the new warehouse processes offered in the R3 release, but wants to continue to use the shop floor terminal for manufacturing execution, or also want to enable the shop floor supervisor to make corrections.

 

 

Setting up the production output location

This new functionality is available with KB 2995954 and will be included in Microsoft Dynamics AX2012 R3 CU8. To find the HF you can use LCS Issue Search.

What’s new?

To support an efficient process for putting away produced products, it is now possible to define an output location specific for a production or a batch order. This will enable the warehouse worker to exactly know where to go, to pick up the goods for put away.

The illustrations below shows the difference between the R3 and the CU8 implementation. The first illustration shows the R3 implementation where it was only possible to define one output location per warehouse:

The second illustration shows the CU8 implementation. In this implementation it is possible to set up an output location per production or batch order. This will give the warehouse worker a better overview of where to pick the finished products for final put away

This blog will explain how this new capability is enabled by using the official demo data released for Microsoft Dynamics AX 2012 R3 CU8 Virtual Machine (VM).

In the company USPI there is a formula for making Pellets. This formula will be used for showing how this feature is enabled and used.

The illustration below shows the Pellets production:

The item numbers for the ingredients (or raw materials) as MW4004 – Polypropylene and MW4005 – Rubber are pre-fixed with MW and the four end items are pre-fixed with PW. PW4000 – Pellets is the formula item, and PW4001 – Chips and PW4002 – Blocks are co-products. PW4003 – Slag is a by-product

Let us take a closer look how to enable this feature. First we need to set up the production output location. Looking at the route for the Pellets formula operation 40 DryFilling is the last operation:

An applicable output location for this operation is found through the Resource requirements for the operation. In the Resource requirements, criteria for finding an applicable resource or resource group during scheduling, is set up:

The output location is specified on the resource group, as it can be seen in the illustration below:

In case no output location is defined on the resource group, then a default production output location is used as a fallback location. This default output location is set up on the warehouse:

In the diagram below the defaulting hierarchy is shown. The diagram shows the rule that applies for finding the production output location when reporting as finished for a production or batch order:

 

Example

To see how this works, let us report as finished a quantity of the formula item PW4000 – Pellets. The batch order is in status Started and is ready to be reported as finished:

 

Reporting as finished is done from the mobile device:

Batch order number, Item number, quantity and license plate is entered:

And the process is completed and put away work is generated:

Taking a closer look at the put away work, the pick location for this work is FILL-01. This location is the output location that was set up on the resource group that is applicable for the last operation DryFilling

Let us try to remove the output location from the resource group and then report as finished one of the co-products from the batch order

We report as finished a co-product PW4002 – Blocks and put away work is generated

The put away work will in this case have the default output location OUTPUT. This location is the fallback location set up in the warehouse

The defaulting of the output location is enabled for all the places where the reporting as finished process can be performed. This includes

  • Using the report as finished function from the batch order
  • Using the report as finished journal
  • Reporting as finished from the job or route card journal. This is possible when user reports on last operation and marks the field Report as finished on the journal line
  • Report as finished from list page Current operations. This is possible when reporting as finished the last operation
  • Reporting as finished from the Job registration form in the manufacturing execution module (MES). This is possible when the user reports as finished the last operation

Summary

In CU8 it is now possible to set up an output location for the last operation in a production route. This supports a more efficient process for putting away produced products from the shop floor to the warehouse. The output location is set up on the resource group that is applicable for the route operation. A fallback output location set up on the warehouse is used in case no output location is defined on the resource group. Using the output location defined for the last operation in the production route is applicable for all the places where the report as finished process can be performed.

 

Microsoft Dynamics AX Production floor app is available in the Microsoft Windows App store

Along with Microsoft Dynamics AX 2012 R3, Microsoft has released the Windows 8 Production floor app that works with the product. This app is compatible only with installations of Microsoft Dynamics AX 2012 R3 or later.

With the Production floor app, you have a mobile, actionable overview of the production jobs that need your attention today. You can quickly perform daily production tasks such as starting jobs, reporting jobs as finished, and registering breaks and absence. Large font sizes and input controls improve readability and make the app easy to use while you’re on-the-go.

Want to try it out? You can download the app from the Microsoft Windows App store  http://apps.microsoft.com/windows/en-us/app/cc07f817-e74c-48aa-86ad-1c0345fff989 and run it in a demonstration mode that lets you explore the features without a connection to Microsoft Dynamics AX.

 
 

Supply chain excellence in manufacturing

Today I had the opportunity to take part at a Master Class on Supply chain management with Professor Martin Christopher from Cranfield University, Bedford, UK. The master class was hosted by Implement Consulting and the attendants were coming from all Industries in Denmark.

 

Professor Christopher succeeded to draw a relevant picture of the future trends and challenges to global supply chain management and to manufacturing in particular, and I would like to share a couple of quotes and thoughts.

 

  • Move from forecast driven to demand driven – Instead of planning to replenish inventory, establish supply chains that allow you to fulfill demand as a single event.
  • For products, where individuality and responsiveness are relevant, the agile supply chain – and the agile manufacturing process – must be designed for responsiveness,      not for the lowest cost. Responsiveness has to be built in the process and comes with a certain cost.
  • Substitute information for inventory – sharing information on demand and supply chain execution across the supply chain helps reducing or even eliminating inventory.
  • Flexible capacity – Move from static capacity to flexible capacity models, that allow to scale according to actual demand. Instead of acquiring manufacturing and distribution capacity based on forecast before the fact, a now model of
         acquiring capacity options that can be used on specific actual demand is emerging in the markets.
  • Economics of scale vs. Economics of scope – Instead of the volume of products, the bandwidth of products that can be delivered out of a supply chain drives the economic success.

 

It was an inspiring morning, leaving me with a lot of thoughts and ideas.

If you are inspired as well about these topics, join Roxana, Sverre and me at our session on Mass customization in a distributed supply chain in Microsoft Dynamics AX 2012 R2 at Convergence EMEA in Barcelona next
week, where we will share our vision on how the combination of product configuration, intercompany planning and lean manufacturing can bring you to the next level of supply chain excellence.