Overproduction in Microsoft Dynamics AX 2012

 

With the introduction of the new warehouse management capabilities in Microsoft Dynamics AX 2012 R3, it is possible to Report as finished a production or batch order from a handheld device. The only disadvantage of using this capability is that you can’t overproduce. The user will be blocked by the error: Quantity reported as finished exceed the quantity started, and have no option to override the setting.

With Hotfix KB 3034999, we leverage the quantity validation parameters, originally built for the Manufacturing execution module, so the user can now report overproduction from a handheld device.

Overproduction is the term used in Microsoft Dynamics AX 2012 for reporting a production or batch order as finished when the quantity produced is greater than originally planned. This is a common scenario in the process industry and can be caused by many factors, for example, potency and yield.

When you produce more items than planned for a production or batch order, you will get the following blocking error: Quantity reported as finished exceeds the quantity started.

In order to allow for overproduction, you have to select the parameter Accept error in the Report as finished parameters. This will bypass the quantity validation check and then allow for overproduction.

For companies that use the Manufacturing execution module in Dynamics AX2012, there is a more advanced support for overproduction. In this module, you can set up a quantity validation based on different criteria. For example, you can accept overproduction in percent based on the planned quantity, the started quantity, or the quantity reported on the previous operation.

 

To show an example of how overproduction is reported, I have changed the demo script for CU8 “SCM Demo Script – Batch orders and WMS integration” (Attached). I have changed the section:

DEMO: REPORT THE PRODUCTS AS FINISHED AND MOVE THEM TO LOCATION FOR FINISHED PRODUCTS

The following diagram shows the complete logic. The logic was originally only applicable for reporting overproduction from the job registration form in the Manufacturing execution module, but is now applicable for the scenario where the user needs to report overproduction from a handheld device. 

 

SCM Demo Script – Batch orders and WMS integration – Overproduction.pdf

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 input location

This new functionality is available with KB 2995227 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 raw material picking in production, it is now possible to split warehouse work for raw material picking per route operation. As an example, this is useful in a so called bulk / pack production scenario. In this scenario there could be one operation for making the bulk material and one operation for bottling and packing. These two operations are both consuming materials, but will be carried out in different physical locations, maybe even different buildings. Splitting the work per operation will, in this case, secure a process where the warehouse worker is directed, by warehouse work, to deliver the picked materials to the exact locations, where the materials are consumed. This blog will explain how this is enabled by using the official demo data released for Microsoft Dynamics AX 2012 R3 CU8 Virtual Machine (VM).

The illustration below shows the Pellets production from the USPI Company:

 

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

As it can be seen from the illustration, ingredients from the pellets production are consumed at two different operations. Let us see how work is now split per operation when releasing a batch order for the Pellets formula. First we create a batch order for Pellets and perform the following steps Estimate, Schedule and Release. In the Release step warehouse work is created:

 

In the work details form it can be seen that two warehouse works has been created in the release step. The first work is for allocating materials to the extruder operation, which is the first operation in the route. The materials are allocated to the production input location: EXT:

The next illustration shows the work details for the second work for the order. This work is for allocating materials to the Mixer operation. The materials are allocated to a production input location: MIX

Let us take a closer look how to enable this feature. First we need to set up the production input locations that will be applicable for the route operations. The Pellets formula has a production route with four operations

The first operation PPExtCut is consuming MW4004 – Polypropylene and MW4005 – Rubber. An applicable production input 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 input location can be specified at the resource group but also on the relation between the resource group and the resource, as it can be seen in below illustration

In case no input locations can be found from the resource groups or resource group relations, then a default production input location is used as a fallback location. This default input location is setup on the warehouse

After setting up the input locations we need to specify which operations that are consuming which materials. This mapping is set up on the material lines using the field Oper. No. This is shown in the below illustration

If no operation is specified on the material line, then the production input location will be found from the resource group or resource group relation, applicable for the first operation in the production route. If no applicable input locations can be found, then the default output location for the warehouse is used. In the diagrams below the defaulting hierarchy is shown. The first diagram shows the rules that applies for finding the production input location for a material line that is mapped to the first route operation or does not have a location defined:

 

The second diagram shows the rules that applies for finding the production input location for a material line that is not mapped to the first operation but to one of the following operations in the production route:

 

In order to enable the split of warehouse work a minor change has been introduced to the work template for raw material picking. When a new template is created a Work break is automatically inserted. This work break is configured by the system to group work per route operation. It is possible to remove the work break, and in that case only one work will be generated when releasing to the warehouse from production. In that case the input location found from the first operation in the route will be used as production input location, and if none found on the route the default output location set up for the warehouse

If the hotfix is deployed to an existing installation, then the work template for raw material picking needs to be recreated in order to establish the work break. An alternative is to insert the work break manually in the existing work template.

Again looking at the work details for the released batch order for pellets, we should now understand how the input locations for the two sets of work are found

 

Summary

In CU8 work for raw material picking can now be split per route operation. On the resource groups and the relation between the resource group and the resource it is possible to setup a production input location to be used in warehouse work. Installing this hotfix on an existing installation will require you to recreate or update the work template for raw material picking. This new capability secures a more efficient picking process for production and batch orders, as the warehouse work will now direct the warehouse worker to the exact locations where the material is consumed.

 

 

 

 

Lean manufacturing: Picking activities and kanban line events

When using Lean manufacturing in Microsoft Dynamics AX 2012, you can model production flows that use multiple activities to produce a single product. This was described in the whitepaper, Lean Manufacturing: Production flows and activities, in the section “Semi-finished” on page 26. In that context, “semi-finished” refers to the output product from an activity that has not yet reached the next BOM level and requires additional activities.

With R2, we extended this functionality with the capability to distribute the material consumption over the different activities of the production flow. In order to achieve this, specific picking activities must be created and assigned for each process activity of the production flow. This determines which kanban line will be associated with which kanban job.

In this blog, I will walk you through a small scenario, to illustrate how to define a production flow that uses this capability, and to provide a couple of hints to help you understand the possible issues in this process.

Assume the following production flow:

A finished product is produced from one lean production flow with a kanban rule spanning over two activities. The finished product needs two components, the first is consumed by process 1 and the second is consumed by process 2.

Additionally, both components are pulled to the activities by using a withdrawal kanban line event kanban.

In the following we will explain the critical elements of the definition of the production flow. We will not include every step of the configuration, to keep the focus on the elements that influence and enable the specific desired behavior.

We start with defining the products and the bill of material (BOM):

Consider that the BOM and BOM version do not specify a site, and the lines specify resource consumption. This allows us to produce the same product on multiple sites or multiple alternative production flows. The warehouse
and locations will be determined out of the production flow during creation of the kanban.

Now we will define the work cells, the production flow, version, and the respective activities.

We define two work cells for the two activities, WCP1 and WCP2 as resource groups:

SpProd is the warehouse on the production shop floor on Site 2. Each work cell has a dedicated input and output location. The input location of WCP1 is Input, the input location of WCP2 is SpAsm.

The finished products will be put to location Pack when the kanbans are received.

We will now create a production flow and version:

And then create the activities for that version:

The first activity is Process 1, activity type Process.

In the next step, we select the work cell WCP1. As this activity is not the activity that finishes the product and posts the receipt of the product back to inventory, we must deselect Update on hand receipt. Instead we select receive Semi finished product, to specify that this activity requires one (or multiple) successor activities to finish the product.

As the first process activity in the production flow, the Pick up semi finished check box must stay unselected. Because this check box is unselected, the next step will open the Picking activity definition and show the default picking activity that has been created for the input location of work cell WCP1:

The picking activity is set up to Update on hand and Register scrap by default. Click Next.

In the last step we assign an activity time, and finish the creation of the activity. (Note that time and capacity are not specifically discussed in this blog, as they do not influence the discussed behavior. However, they are mandatory data to set up to make the scenario work.)

We will now create Process 2.

Again, we assign a Name and select the activity type Process.

As the second activity in the flow after Process one, we have to specify the activity as Pick up Semi finished product. If you forget this setting, you will receive an error when you attempt to create the activity relation between these two activities.

As this is the last activity in the production flow, the activity must be set to Update on hand receipt. The output of the activity must be posted to inventory. This configuration deselects and disables the Receive Semi Finished product check box.

Because the activity is set to Pick up Semi finished product, the Next button will take you directly to the activity time definition. Notice that there is NO default picking activity defined for this activity. You may define picking activities in a later step by using the activity details form. We will return to this, as this must be done for the given scenario.

Back to our activity, again, we have to specify a runtime to complete the creation:

Then we can finish the creation of the activity.

If everything has been correctly created, you should be able to create the activity relation between the two activities now:

The next step is to create the two transfer activities that will be used to pull the material to the work cells.

Again, add a new version activity:

Select the name Transfer 1 and the type Transfer and click Next.

For transfer activities, the second page of the activity wizard is different. To make the configuration simpler, you can directly select the work cells that replenish or are replenished by this transfer activity. In our case, we select WCP1 as the replenished work cell, as the activity should pull material to this cell. (Note that the relation to the work cell is not persisted in the data model. This is just used to provide the input and output locations from the selected work cells.)

Use the default settings for finished products and update the on hand for this activity. (There are variations to this scenario that would not update the on hand inventory, but that is another story.)

On the next page, note that the Transfer to location has been included from the replenished work cell WCP1. Select a source warehouse and location for the transfer, and select Shipper in the Freighted by field:

Finish creating the activity by assigning an activity runtime. Then you can assign Transfer 1 as a predecessor activity to Activity Process 1:

Be aware that this only works because there is a default picking activity on activity Process 1, that matches the target warehouse and location of the transfer activity. If one of these conditions is not met, an error message is displayed.

We will now repeat the activity creation for Transfer 2, to replenish WCP2:

Again, specify a process time to complete the creation of the activity.

However, our attempt to connect this transfer activity to Process 2 will fail:

As mentioned earlier, Process 2 does NOT have a default picking activity.

In order to create the activity relation, we need to create a default picking activity for this activity. We can do this in the activity details form:

Open the details form for Process 2, open the FastTab for picking activities, and add a new line:

Add a default picking activity for warehouse SpProd and Location SpAsm. A default picking activity has NO item and no product dimensions.

Close the form and repeat the creation of the activity relation and you will get the following result:

We are now almost done.

In order to configure the expected picking behavior of Process 2, we need to get back to this activity again and change the picking activities once more. For this, open the details again:

To ensure that Component 2 is picked for Activity 2 and that a kanban line event is created for this activity, there must be a valid picking activity for Component 2. The previously created default picking activity (no item) would be valid for this as well. However, it would also catch Component 1 to be picked at activity 2. Therefore, the picking activity should be updated with Component 2 and the default picking activity should remain on Process 1.
Remember that for any product that should be picked on Process 2 instead of Process 1 you will need to add a line to the picking activities of Process 2. You can also do this after the production flow has been activated.

You can now activate the production flow. (Depending on your capacities, you may have to adjust the takt requirements of the production flow version. Again this mandatory setup, but it is not important to the outcome of this scenario.)

We will now proceed with creating the kanban rules. We start by creating the two kanban line event rules for Component 1 and Component 2:

The kanban rule type is Withdrawal. Select the activity Transfer 1 and the replenishment strategy Event. The kanban line event should be set to Automatic. The product selection is Component 1.

Create a similar rule for Component 2 and activity Transfer 2:

Finally, create the kanban rule for the finished product:

Select Manufacturing type. The replenishment strategy could be any. In this case we use Fixed. The first plan activity is Process 1. Check multiple activities, which activates the last activity field. Fill in Process 2, which opens the selection of the Kanban flow form. As this is the first rule created for these activities, you need to generate the flows by using the Generate flow button and then confirm the warning message that will be shown.

There will be one resulting line: Process 1 > Process 2. Select the line and close the dialog with Ok.

Enter the default quantity and the fixed kanban quantity to complete the kanban rule definition.

If you now go to the Kanbans FastTab and click Add, you can create the first kanban:

After the creation of the kanban, open the kanban details form and view the Jobs and Pegging FastTabs:

Two kanbans and the respective kanban cards have been created and pegged to each of the activities of the parent kanban.

Summary:

To model more complex material flows for Lean manufacturing for Dynamics AX you need some basic understanding of the underlying concepts:

  • Use kanban line events to pull material to kanban activities
  • Use activities  that consume or receive semi-finished products (work in process between two BOM levels) to model lean manufacturing processes that require multiple process activities to produce a product
  • Use picking activities to allocate material consumption to specific activities in a production flow
  • Understand and use default picking activities in production flows that have multiple activities

When you have understood these basic concepts, the full power of the Lean manufacturing for Microsoft Dynamics AX is available to you.

 

 

 

Choosing the right coverage setting for when to Fulfill minimum

Why this blog post?
Multiple people have asked how the four different options to Fulfill minimum works and I was missing a detailed description of this. Therefore, I decided to describe the different options to ‘Fulfill minimum’ in Microsoft Dynamics AX.

So here we go:
Fulfill minimum defines when the Minimum (in this case 10) should be achieved. The minimum and the Fulfill minimum parameters are active for all Coverage codes, except for Manual that is not planned at all.

 


Today’s date

With ‘Today’s date’ planning will try to fulfill the minimum with a supply delivered today. However, unless the supply can be delivered on the same day (zero lead time) you will not be able to achieve this.

Example:
Product @Min is purchased with a lead time of 5 working days (7 calendar days)

 
 


Today’s date + procurement time

With ‘Today’s date + procurement time’ planning will fulfill the minimum with a supply delivered today + lead time + any safety margins. Compared to ”Today’s date’ adding the procurement time will prevent futures in most situations.

Example:

Product @Min is purchased with a lead time of 5 working days (7 calendar days)

 
 

First issue
With ‘First issue’ planning will place the supply to cover the minimum at the same time as the first issue (e.g. a sales order). This ensures that you do not carry unnecessary inventory for new products until there is an actual demand for them.

Example:

Product @Min is purchased with a lead time of 5 working days (7 calendar days) and Coverage code Period to combine demand within the Coverage period into one supply order.
Two sales orders for one pcs each exists: first on 17-07-2014 and second on 28-07-2014
 

 


Coverage time fence

With ‘Coverage time fence’ planning will place the supply to cover the minimum at the last day of the Coverage time fence.

Example:

Product @Min is purchased with a lead time of 5 working days (7 calendar days) and a Coverage time fence of 100 days. 

 

 
 

I hope this explained the meaning of the Fulfill minimum parameter.

 

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.

 
 

'Demand forecasting in Dynamics AX 2012 R3' whitepaper available for download

Download the paper from http://www.microsoft.com/en-us/download/details.aspx?id=43128 if you want to learn more about:

– demand forecasting in Dynamics Ax 2012 R3 value proposition and market positioning

– what this forecast tool is, but also what it isn’t

– functionality details

– demand forecasting parameters and how to set them up

– troubleshooting and improving demand forecasting performance

Product Configuration: Setting values based on system variables – example, current user ID

In this blog post we will describe how you can  set values
based on the current user ID by leveraging system-defined table constraints
together with the build-in query range methods.

 

If you are familiar with the Product Builder configurator,
you may by familiar with the User Profile
feature where you can associate a collection of default values with a given
user. Use the following description to achieve a similar behavior using the
Product Configurator.

Creating the System Table

 

The table we create for this example should look like this and have two columns, that is, one for
the User ID (uses the  UserID EDT) and one for our user-specific value (an Integer to keep it simple).

 

 

 

Once the table is created, we can add the user specific data.

 

As seen above, we have added the value 42 for the Admin
user ID. The intention is that when the table constraint is created and used in
model, the attribute, which will be bound to the UserSpecificIntegerValue
column, will be assigned the value that corresponds to the current user ID.

 

Creating the Table Constraint

Now that the System Table is created, we can create the actual table constraint. This is done by
opening the Table constraint definition
form, under Product information management -> Common -> Product configuration models.

Create a new table constraint by clicking the new button.

 

Select System defined, and enter the name of the table created previously.

 

Add a column for the user-specific integer value and choose an integer attribute type with ranges.

  

Now comes the part which gives the attribute a user-specific value. This can be accomplished by
opening the Select query (SysQuery) form and entering the range specified
below. The content of the table will be filtered to just return the records
associated with the current user ID.

 

Click OK to complete the table constraint creation, click Next in the Wizard, and then click OK again.

Using the system-defined table constraint in a Product configuration model

Having just created our system-defined table constraint, we are now ready to use it in a Product
configuration model. Below I have create a very simple model with 3 attributes:

  1. One integer attribute to hold
         the user-specific value
  2. Two boolean attributes for
         each of which I will be using the Hidden modifier with a condition
         expressing that the attribute is only to be shown if the user-specific
         value matches that of the current user. 
         The “Only Admin” attribute will be hidden if the user
         specific value is different from 42.

 

 

Similarly, I have added an attribute named “Only Dmitry”, which only will be
visible if the user log on to Dynamics AX is associated with User ID Dmitry.

 

Once the attributes have been defined, it’s time to attach the table constraint to the
model. This is done by creating a new constraint in the constraints section and
selecting Table constraint in the opened dialog.

Then select the new table constraint and associate the user-specific value attribute with
the user-specific value column, as shown below.

 

Launching the model and understanding the results

We are now ready to launch the model we created with the attached table constraint. As can be seen
below, once the model is loaded, the User Specific Value is assigned the value 42 by the configurator. The “Only
Admin” attribute is shown and the”Only Dmitry” attribute is hidden.

 

 

This example can be extended to include several other concepts like hiding subcomponents and
grouping user specific value into table constraints. An obvious use case would
be that you hide some parts of the Product configuration model from the order
takers (Susan persona). This could be engineering-specific details and the
product designer (Emil persona) would still be able to see them.

 

Furthermore, the above pattern can be used together with other of the build-in query range
methods.

 

  • currentCompany
  • currentLanguageId
  • currentUserLanguage
  • currentLegalEntity
  • currentParty

 

Note:

It you are running
on a build that has a performance fix to run the XML generation in IL, you will
need to generate IL for the SysQueryRangeUtil class.

 

I hope you find this useful 

 

 

 

PrivateProject_MyUserSpecificValuesDemo.xpo