Tag: Dynamics AX

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

Product Configuration Synchronous Execution

This blog post describes an new way of interacting synchronously from code with the
Constraint-Based Product Configurator which has been introduced in Microsoft
Dynamics AX 2012 R3 CU8.

 

Scenario

The scenario that drove the introduction of this feature can be described as follows:

 

An external 3rd party sales configurator outside of Microsoft Dynamics AX 2012 is used to
assign values to a subset of attributes(a partially configured order), from
which the remaining mandatory attributes can have their values deduced using
the Microsoft Dynamics AX 2012 Configurator, thereby completing the order.

 

 

Once the all the values have been deduced, assuming all values are valid, they can be passed on
to the back end configuration module, which will create the BOM and potentially
the Route (if the model has a Route).

 

Implementation

Included in Microsoft Dynamics AX 2012 R3 CU 8 is a new derived version of the PCRuntimeConfigurator class, named PCRuntimeSynchronousConfigurator.

This class is designed, as the name indicates, for synchronous interaction with the .NET
Configurator component.

 

The configure method on the class is the method
which exposes the new functionality added to the .NET Configurator to Xpp. The
method takes three arguments; the model as xml, the attribute assignments as
xml and a the number of milliseconds which can be used before a timeout occur.
The return of the method is a IsConfigurationComplete enum value, from which
result of the configuration can be determined;

 

  • Complete
    • The configuration is complete
  • Incomplete
    • One or more mandatory attributes does not have a value
  • Timeout
    • The configurator was not able to complete the configuration within the given timeout limit
  • Contradiction
    • One or more constraints have been violated

 

Note:

The PCRuntimeSynchronuosConfigurator class exposes
the functionality required by the .NET configurator component to support the
above scenario but it is not yet integrated with any order (sales, production
etc) or product variant creation nor is it integrated with the BOM and Route
generation.

 

KB Article with number 3028719 should be Applied on top of R3 CU 8 as it addresses a stability issue in the solution.

 Example

 In this example values are passed from the simulated 3rd party configurator into Dynamics AX 2012 through a web service, as illustrated below:

 

 

To expose the PCRuntimeSynchronousConfigurator class through
a web service, we start by introducing a new class
PCTechDemoService which implements a method with the SysEntryPointAttribute code attribute, which is
needed for a method to be exposed as a web service.

 

In this simple implementation the example method looks like this:

 

[SysEntryPointAttribute(true)]

public boolean configure(PCName _modelName, str _xmlValues)

{

    boolean ret;

    str values;

 

    PCRuntimeSynchronousConfigurator configurator  = PCRuntimeSynchronousConfigurator::construct();

    PCProductConfigurationModel productConfigurationModel  =  PCProductConfigurationModel::findByName(_modelName);

    values = ‘<Assignments>’ + _xmlValues  + ‘</Assignments>’;

   
if(configurator.configure(productConfigurationModel.getXML(), values,120000) == Microsoft.Dynamics.Ax.Frameworks.Controls.ProductConfiguration.IsConfigurationComplete::Complete)

    {

        ret = true;

    }

 

    return ret;

}

Now we can create a Service in the AOT which uses the PCTechDemoService
class and its configure method as an operation. To use this service, it needs
to be put in a service group, which can then be deployed.

 

 

To test the service, navigate to System administration > Services and Application Integration Framework > Inbound ports. Here we find our new PCTechDemoServiceGroup, copy the WSDL URI value.

 

 

 

Open Visual Studio Command prompt and type:

Wcftestclient <Your WSDL URI>

 

This will open the WCF test client where we can now see our web service.

 

For the demo data set I have used, I will use the following argument values

 

_modelName : 20001

_xmlValues : <Assignment xPath=”powerCableLength” value=”10″/><Assignment xPath=”videoSystem/television/size” value=”42″ />

 

Note: the xPath mechanism used to identify the attributes in model.

 

 

If you are familiar with the 20001(Home theater system) model, you will know that it has just two
mandatory attributes which are not assigned by defaults; the powerCableLength
on the root component and the size on the television component.

 

Attached you will find an Xpp project with code used for the example.

 

Enjoy

 

 

 

Demo.zip

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.

 

 

 

 

Support for Recycled By-products in AX 2012 R3 CU8

This new functionality is available with KB 2989470 / HF 2989470 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 recycled or recurrent products in process industry, it is now possible to use the same product as both input and output on a formula. As an example, this is useful in plastic molding where consumed plastic regrind can be recovered from the manufacturing process. Other examples are processes where you put metal scrap from the stamping/forming process in a foundry.
The recurring co-product solution in Microsoft Dynamics AX2009 had some limitations on the costing side and was not ported to AX2012. This new solution use by-products with a stronger support for costing.

Feature solution
This new feature enables the consumption and reuse of the same by-products in the production of formulas and batch orders, by allowing BOM circularity for output that has the production type, By-product.
For costing purposes a new Burden type, Recycled, was added to handle the cost of the recycled by-products. Use of the Recycled Burden type deducts the joint production cost that is allocated to the formula and co-products, by using the standard cost value of the recovered by-product.
By-product output from planned and firmed batch orders is ignored during planning. This is done to ensure that demand for the recycled product isn’t pegged against by-product output from the same order, or other orders from the same process or BOM chain. This means that the recycled by-product cannot be pegged until it is on-hand (posted from the batch order).
Finally as a small additional improvement on the Explosion form, it is now indicated when a formula output is a by-product. This is done by adding ‘(By-product)’ to the line.
 
Set up recycled by-products
In order to allow BOM circularity, the recycled item must use standard cost and use the production type By-product or in special cases Co-product. On the formula the recycled product input is a normal formula line, and the output on the same or other formulas is a co-product output of the Production type, By-product, and the Burden type, Recycled.

  1. Product 
    1. The recycled functionality only supports standard cost, so ensure that you select an Item model group that uses the Inventory model, Standard cost, on the General FastTab:
    2. Ensure that the Production type is By-product on the Engineer FastTab for the product:
       
      Note: Products with production type Co-product can also be used, but then you will have to change the Production type to By-product on the formula or batch order, to use the recycled by-product functionality.

  2. Input – formula consuming the recycled product
    The recycled product is added as a normal formula line on the formula:
  3. Output – formula producing the recycled product
    On the formula (can be the input, or another formula) that produces the recycled item, the recycled item must be added as a co-product output of the production type, By-product, with the Burden type, Recycled:

    We are aware that the name Burden is not full correct with the Recycled option added. However, the nature of a hotfix release didn’t leave room for renaming.

 

Let’s try an example to see the feature in action:
 
We have the following three products:
M1 – Main ingredient, Standard cost – $10/Kg, Purchase, 100 kg On-hand
B1 – By Product, Standard cost – $5/Kg, Purchase, 15 kg On-hand
F1 – Formula item, Standard cost, Production, 0 kg On-hand
 
To produce F1 we use the following formula:
F1-FORM, Formula Size: 10 Kg

With the following lines
M1, 20 kg
B1, 10 Kg

Co/By-Product lines
B1, Production type = By-product, Burden = Recycled, 8 Kg 

In AX it looks like this:

With the B1 added as By-product under the Co-products output:


First sales order
To generate a demand for F1 let’s create a sales order for 10 kg:

Running the explosion on the sales order will generate a batch order to produce the 10 kg because we don’t have any F1 on-hand:

Notice that the first line for B1 indicates that we get an additional co-product output of the type, By-product.
 
As both M1 and B1 are on hand, we can firm the planned batch order and start the production. (Planned orders -> Firm)
 
Processing the batch order
Let’s report the batch order as finished with the expected input and output:

What happened to the cost?
I have set a material overhead of 10%, so looking at the cost perspective we get the following.

Batch cost:
     M1 20 kg = 20 * $10 = $200
     B1 10 kg = 10 * $5 = $50
     Overhead 10% = 10% * ($200+$50) = $25
     Total = 200+50+25 = $275

B1 cost share (8kg): 8 * $5 = $40 (note this is fixed to the Std. Cost – no overhead)
F1 cost share (10kg): $275 – $40 = $235 (Incl. all $25 in overhead)

For the formula product – F1:

And for the by-product – B1:
 

Second sales order
Let’s create another sales order for 20 kg F1, to see how planning handles a shortage of the recycled by-product.

Running the explosion on the sales order will generate a planned batch order to produce the 20 kg. Notice the planned order for B1.

We still have plenty of M1: 

  • We have 80 kg and we need 40 kg for the additional order.

However, we are running short of B1:

  • Initially, we had 15 kg. The first batch order consumed 10 kg and output was 8 kg, so now we have 13 kg.
  • For the new order we need 20 kg, so a planned order for 7 kg is created to cover the missing ingredient.

Summary:
With HF 2989470 that is included in Microsoft Dynamics AX 2012 R3 CU8, it is now possible to recycle and reuse by-product output from batch orders.

  • The recycled product must use standard cost and have the production type, By-product or Co-product
  • On the formula, co-product output must be of the type, By-product, and have the Burden type, Recycled
  • Planning will now consider only on-hand inventory for by-products. So potential supply from batch orders is not used for pegging until the batch order output is posted.

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