Introduction

Microsoft Dynamics^® AX 2012 provides an easy & flexible way of creating & releasing new products. Products can be created in a central company and then released to other companies that transact them. For simpler scenarios, it is possible to create products in particular legal entity; Dynamics AX 2012 creates them in the central company in the back-end and releases them to the concerned company.

However if process manufacturing is used, different properties can be setup on these products depending on customer requirements for instance some products maybe short life products while others maybe dual unit of measure products and so on.

This blog provides an overview of properties that can be set on products to enable different functionality in process manufacturing solution. Hopefully, it will help application consultants and pre-sales consultants who need to understand the system for either preparing for a demo or for implementing at a customer site.

Overview of properties that can be defined on the product

When process manufacturing is used, several additional product properties can be specified depending on the requirements. These properties can be grouped into following buckets:

• Production
• Inventory unit, storage & tracking dimension
• Vendors
• Inventory batch attributes
• Containerized packaging
• Product compliance

Production related setup

Production type

After creating a new product user must setup production type for the product. This field determines behavior of the product in the system subsequently. There are several validations that depend on this setup. Therefore this is an important decision and usually not expected to change once product setup has been completed.

Production type can have following values:

1. Co-product
2. By-product
3. BOM
4. Formula
5. Planning Item
6. None

User must choose between the following options:

1. Co-product: when the product is produced as part of producing another product. Usually when production type is set to co-product, the product is also setup as a co-product on one or more formula versions of other products.
2. By-product: when the product is produced as part of producing another product. Usually when production type is set to by-product, the product is also setup as a by-product on one or more formula versions of other products.
3. BOM: when the product is produced using a bill of material as opposed to being produced using a formula. The property can be changed later as long as there are no associated transactions.  
4. Formula: when the product is produced using a formula as opposed to being produced using a bill of material. The property can be changed later as long as there are no associated transactions.  
5. Planning item: when the product is produced using a formula in a disassembly scenario. The property can be changed later as long as there are no associated transactions
6. None, if product does not belong to any of the other types

There are several validations that help the user with this setup:

1. A co-product or a by-product cannot be changed to ‘BOM’ or ‘formula’ if the product already exists on formula version of another product
2. If a BOM or formula is changed to ‘co-product’ or ‘by-product’ then user is prompted to accept that all formulae attached to the product will be removed
3. Catch weight items cannot have production type ‘BOM’ because BOMs do not support dual unit of measure products. 
4. Catch weight items cannot have production type ‘Planning item’ because planning items do not have inventory
5. Any production type can be changed to ‘Planning item’ as long as there are no existing inventory transactions for the product, user is prompted to either keep the existing formula versions or remove them. If any approved formula and/or versions exist for the product, they are unapproved.
6. A production type of ‘BOM’ can be changed to ‘Formula’ and vice versa but user will be prompted to delete existing BOM or formula versions.
7. Access to buttons on the ‘released products’ list page ribbon depends on the value in this field, so for instance, lines button inside formula button group on Engineer tab is disabled for all products except those with production type of formula.
8. Default order type in default order settings form is automatically set to production when production type for a product is set to BOM or formula since the assumption is that this product is most likely produced. Default or per site supply policy can be changed at any time and will determine whether planned purchase order, planned production order or a planned transfer order is created irrespective of production type.
9. Creation of Kanbans is supported for common scenarios like a purchase kanban can be created for a product with production type ‘None’, if so desired.

Max. Report as finished

Using this option, user can calculate the quantity of finished product that can be produced given the amount of ingredients on-hand. The form can be used for products with single or dual units of measure (catch weight products). 

Inventory related setup

Catch weight

During product creation, user can chose if the product is a catch weight product. If a product is chosen such, then it is considered to be catch weight product in all legal entities. Usually only one unit conversion will be defined globally and the product will be traded in that unit and inventory unit with defined conversion between them for all legal entities. However, different conversions can be defined if the product is transacted with different nominal weights in different legal entities.

It is not allowed for the product to be catch weight traded in one legal entity and not catch-weight traded in another.

Product masters and service type products can be setup to be catch weight products

Catch weight products can be of two types. Type of the product and business process will determine which of the two catch weight methods is used.

Full visibility catch weight

To setup a full visibility catch weight product, serial tracking dimension have to be turned on with serial number control checked. This usually works when (1) each individual unit is important enough to be tracked like expensive hams or cheese, (2) there is variation in weight possible within a narrow range and (3) weight is entered once at a process stage after which it is not expected to change.

Partial visibility catch weight

To setup a partial visibility catch weight product, it is not necessary to have serial tracking dimension turned on. It is also not mandatory to have batch tracking dimension turned on, however that will be considered as an edge case. Partial visibility catch weight works best for products that are usually not measured and controlled as single units and for which weights vary within a narrow range and can be changed one or more times during the process for example a sack of potatoes or a box of chicken parts.

Item model group

Several critical parameters for a product can be setup here, these are defined here:

Stocked product: it is not allowed to setup a catch weight product with an item model group that has this flag unchecked

Same batch selection: sales agreements & sales order lines for a product with such setup will have same batch selection flag checked by default, it can be toggled as desired

Consolidate requirement: Requirements that fall outside one batch can be consolidated together into a larger batch if this field is setup in item model group

FEFO date controlled: the flag determines if inventory reservation for the product should follow first expiry first out principle or not. If this flag is checked, user can select whether the principle should be applied based on best before date or expiry date. If the principle is applied based on best before date and if the product is setup with batch tracking dimension turned on then it is mandatory to fill in the best before period in days in the released products details page. Similarly, if the principle selected is expiry date and if the product is setup with batch tracking dimension turned on then it is mandatory to fill in the shelf life period in days in the released products details page.

Batch disposition code: every inventory batch created for the product defaults to the batch disposition code supplied here

Purchase registration: if a product is setup with this option, users get option to record vendor batch information like vendor batch number, country of origin etc., while registration of a purchase order line

Approved vendor check method: the value in this field is defaulted to the product as soon as it is created, it can be toggled at any time

Default order settings

Define default order type that will be used by master planning to determine what kind of planned order should be created to meet the demand. Here user can also specify multiple, minimum order quantity, maximum order quantity and standard order quantity for catch weight products.

Note: when process manufacturing is used, multiple quantity specified on inventory tab for both catch weight and inventory units is only used for transfer orders. Multiple specified on formula is the one used for production.

Bulk item conversion

It is possible to setup conversion between a bulk and a pack item for any product that has a production type of formula. When such a product is selected on released products list page, bulk itemconversion button becomes available.

Multi-dimension on-hand

It is possible to check on-hand in multiple dimensions for any product that has been setup with different packing configurations. When such a product is selected on released products list page, multi-dimension on-hand button becomes available for clicking. Note: it is recommended to use containerization (bulk/pack) functionality instead of containers functionality. Containers functionality will most likely be deprecated in a subsequent release.

Consolidated on-hand

It is possible to check on-hand (1) for bulk item, (2) for pack item in pack units and for (3) pack item in bulk item units for any product that has been setup as a bulk or a pack item. When such a product is selected on released products list page, consolidated on-hand button becomes available for clicking.

Inventory batch attributes

On released products list page, three options are available to (1) setup inventory batch attributes per product (2) setup inventory batch attributes per product and customer and (3) search available inventory batches based on certain batch attributes

Note: Inventory batch attributes functionality that is specific to inventory batches in Process Manufacturing is different from Product attributes functionality which is specific to products.

Product specific: When a product with batch tracking dimension active is selected on released products list page, this button becomes enabled. Using the form that opens up, user can setup a specific inventory batch attribute for the product.

Customer specific: Once a product has at least one inventory batch attribute attached, buttons customer specific and search inventory become available. Using the form that opens up, user can setup a specific inventory batch attribute for a product & customer combination. The minimum, maximum, tolerance action & increment are selected from the product specific setup done earlier. However these values can be changed on this particular record for the customer as long as the new range specified is narrower than the one specified for the product.

Search inventory: clicking this button will open a form that shows the existing inventory batches that match the criteria already setup for search. If user wishes to change the search criteria, this can be done by using the batch attribute search form.

Compliance related setup

Regulated products

Using this option, user can setup countries and regions where a particular product is (1) regulated or (2) regulated and reported. If the product is reported as well, then reporting lists need to exist in the system before this setup can be done.

Restricted products

Using this option, user can setup countries and regions where a particular product is restricted. System assumes that there is a public restriction list on which this product exists, therefore restriction lists need to exist in the system before this setup can be done.

Product Safety Data Sheet

Using this option, user can setup product safety data sheets in various languages and versions. The sheets can be activated as needed. If the records are changed, then a modification reason can be entered and log of changes can be maintained.

Note: there are several parameters in inventory module that control the display and timing of alerts specific to events that may occur related to product safety data sheets.

Reporting details

Using this option, information can be set up about allowed limits from various authorities for usage of this product. Also use this form to setup CAS numbers for the product. The form also has a function to calculate the quantity consumed, produced and on-hand currently for the product.

Purchase related setup

Approved Vendor List

If a product can only be supplied by certain vendors then this information can be set up using buttons available on purchase tab of release products list page. Users can also define the time period in which these vendors are allowed to sell products to company. Note: the time period uses date effectivity framework like in many other parts of the application, which makes it easier to setup this information.

It is also possible to query from released products list page, (1) vendors that are allowed to supply a certain product for any time period and (2) vendors that are allowed to supply the product as on a particular date.

Formula management is a key requirement for process manufacturers. In most cases, process manufacturers process raw materials that are found from natural sources which inherently means they have to deal with a lot more variability than discrete manufacturers. This variability could result from lack of control over physical properties of the materials. Which in turn means process conditions need to continually adjust in order to produce a finished product within certain range with some consistency. Natural ingredients, variable physical properties, altering process conditions and highly controlled & regulated environments mandate that process manufacturers manage their formulae with good discipline. Formula management in Dynamics AX is built on Bills of material which is the natural place it should be, however in previous versions the formula was less secure and there were several inconsistencies in the behaviour.

Security of approved formula

In previous versions, formula lines could be created without a header and co-by products could be attached and deleted at will. While this is great from ease of use point of view, feedback that we received clearly showed that customers expect more stringent measures since most people used formula in a regulated environment. Therefore following enhancements were made in process manufacturing AX2012.

1. Formula header is required before a version or lines can be entered
2. Formula version is required before co-by definitions could be setup
3. Formula version is required before lines could be setup so that per series can be defaulted from formula size on formula version
4. Furthermore the BOM modification policies were made extensible to formula, this means the following
   1. When block editing is turned on, no fields on an approved formula or version or on co-by setup can be changed
   2. When block removal of approval is turned on, formula or version cannot be unapproved
   3. When block editing is off, fields can be changed on formula, version and on co-by setup any time

This allows stricter discipline in formula maintenance and makes it easier for design or product department or any other authority to secure the formula definitions from intentional or unintentional changes unless authorized.

Scalable formula

Consider the scenario where manufacturing site has a standard approved formula to produce a certain dye blend in certain size vat. Normally, the formula will be used every time the blend is scheduled to be produced. But not always, all the required ingredients may be available in right quantities. You can enter the quantity of short ingredients and the other ingredients will scale accordingly and will change the formula size. This will allow you to determine what quantity of dye blend can be produced. Similarly if the normal vat is busy with another process and you have an alternative vat, putting the size of the vat in the formula size will allow you to see the quantity of scalable ingredients required for this vat. This is a powerful capability that gives you flexibility to configure the production based on available ingredients and equipment without affecting existing production in progress.

Formula for different vat sizes

Taking the previous example a bit further, in most cases plants, processing lines do not have just one vat/vessel/equipment for processing something. They have multiple size equipment - for samples, for small orders, for medium to large orders for standard products. In previous versions it was only possible to have scalable ingredients tied to one formula size. If you created another version with another formula size, ingredients on the formula line will not scale. In process manufacturing AX2012 it is possible to setup multiple versions with different formula size. A new field "use for calculation" determines which formula size from which version is being used to scale the ingredients. So, in previous example, now it is possible to setup all versions for all vat sizes that you have. Depending on which vat is available at the time, you can switch the "use for calculation" flag and scalable ingredients will scale based on that vat size.

Step consumption

Please see this post for more details.

Electronic signatures

This capability has existed since AX2009, now it works together with BOM modification policy and the new security framework. As previously, you can setup if you require users to authenticate any changes to formula or versions. If you would like to capture authentication on change of any other fields on the formula or for that matter anywhere else in the application it can be setup. For more details on how to do this, please see the documentation.

Miscellaneous updates

Now it is possible to copy co-by lines when a formula is copied. Behaviour of Percent controlled items have been modified to ensure that use for calculation flag does not change the quantity of percent controlled items when a different vat is used for calculating consumption of scalable ingredients.

Cost calculation

Based on customer feedback, we have modified the previously implemented cost calculation for co-by products and now the new method is called Total cost methodology and among other aspects, it uses price of co-products to determine the ratio of total cost that should be allocated. For more details please see this link.

With this blog entry, I would like you to familiarize you with the concepts that we have introduced in Microsoft Dynamics AX 2012 R2 to support potency management.

Potency management lets users define products as having a concentration of an active ingredient. The concentration of active ingredient can be used to affect the amount of material that is required in production or the amount that should be paid to a vendor based on the
concentration level.

Process industries often have formulas that contain one or more active ingredients. For each active ingredient there may be one or more compensating ingredients. These compensating ingredients for a single active ingredient may have different effects based on the difference in the concentration level of the reserved inventory batch and the standard level of concentration for that particular active ingredient. In some cases, the requirement of compensating ingredient may increase to offset the increase in the concentration level of the active ingredient. In other cases, the requirement of compensating ingredient may decrease to offset the increase in the concentration level of the active ingredient. These are known as complimentary and opposing effects.

A complimentary effect occurs when the concentration level of the reserved batch for the active ingredient increases and therefore, less of the active ingredient is required and less of the compensating ingredient is required. A complimentary effect
also occurs when the concentration level of the reserved batch for the active ingredient decreases, and more of the compensating ingredient is required. In ice cream manufacturing for example, a formula for ice cream may contain milk that has a potency of 2% milk fat as an active ingredient, and milk powder as a compensating ingredient. If milk that has 4% milk fat is used for that production batch instead, then less milk powder, which compensates for the milk fat, is required.

An opposing effect occurs when the concentration level of the reserved batch for the active ingredient increases, and therefore more of the active ingredient is required and more of the compensating ingredient is required. An opposing effect also occurs when the concentration level of the reserved batch for the active ingredient decreases and less of the compensating ingredient is required.  In food production for example, a formula for potato chips may contain potatoes that have a certain level of moisture,  as the active ingredient. The compensating ingredient is the oil that is used to fry the potato chips. When the moisture content in the potato chips rises, then more oil is required to boil off the excess moisture. If the potatoes are drier, then less oil is needed.

There can be one or more formula ingredients that are configured as filler ingredients. Filler ingredients are used to fill up or ”top off” the batch quantity to achieve a required amount. Due to the nature of active ingredients and the required amount of compensating ingredients that result from the principle factor, the total amount of the active and compensating ingredients may be less than the estimated quantity totals. When this situation occurs, an adjustment is made to the quantities of filler ingredients to achieve the required quantity of the formula item. When more than one filler ingredient exists in the formula, then the adjustment amount is applied to the filler ingredients based on their relationship to each other.

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.

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

What's new?

In R3 there were some issues in the support for generating put away Work when you used the reporting as finished process for batch orders (for formula items as well as for co-products and by-products). When for example reporting a formula item or a co-product or by-product as finished in production, the location directive could not find an applicable put-away location. Instead, the user was prompted to manually enter a put away location.

We made some changes to the location directives for production and batch orders to fix these issues. In R3 we had location directives with the types "Production order put away" and "Batch order put away" as shown in the picture below:

In CU8 the two types has been replaced with new ones. The first one "Finished goods put way" represents the produced item for production orders and the formula item for batch orders. The second one "Co-product and by-product put away" represents the co-products and the by-products that can be produced as output from batch orders. The two new types are shown in the picture below:

Let’s walk through a scenario that describes how to set this up.

Scenario: The company uses formulas with co-product and by-product outputs. The by-products are always stored in a location called SCRAP, and the co-products are stored in an area called FLOOR.

First we need to create work classes for finished goods put away, and co-products and by-products put away. Open the Work classes form by clicking Warehouse management> Setup> Work> Work Classes. For the work class for finished goods put-away, select the work order type Finished goods put away:

 For the work class for co-products and by-products put-away, select the work order type Co-products and by-products put away:

Next we need to set up the work templates that defines how pick and put work for finished goods, co-products and by-products is created. Open the Work templates form by clicking Warehouse management> Setup> Work> Work templates. Select Finished goods put away in the field: Work order type. Set up a pick and a put line in the lower part of the form and remember to select a work class for finish goods put away for each line:

Now select the Work template for Co-product and by-product put away. Set up the pick and put lines in the lower part of the form with an appropriate Work class for each line:

The last step is to set up the location directives for finished goods and co-products and by-products. Open the Location directives form by clicking Warehouse management> Setup> Location directives. Select Finished goods put away in the Work order type field:

Now select Co-products and by-products put away in the Work order type field. Create one line for co-products and one line for by-products. Go to the line for by-products and select the Edit Query button. In the Query form select the Production co-by products table and the field Production type. Select by-product as a criterion. With this setting we made the location directive specific for by-products output:

The by-products should be stored in a location called SCRAP. This location has an associated Location profile ID also called SCRAP:

Now select the Edit Query button in the Location Directive Actions section. Add a line for the field Location profile ID and use SCRAP as a criterion for that line in the Query:

With this setting the location directive will direct all by-products to the SCRAP location in warehouse 15

As the last thing we will set up the location directive for co-products. Go to the location directive we defined for co-products and select the Edit Query button in the Location Directives Actions section. As the co-products, in this example, should all be stored in an area calloed FLOOR, add a line for the field Location profile ID and add the criterion FLOOR:

Summary

The work order types that are used for production output have changed in AX 2012 R3 CU8 which fixed some issues in the R3 version. If you are upgrading from R3 to CU8, you will need to re-configure your work classes, work templates, and location directives as outlined in the example in this blog.

In short, negative days time fence represents the number of days you are willing to wait with negative inventory, before ordering new replenishment. But if you ever wondered yourself: ’How do the negative days really work?’, then keep reading.

In this post:

I will be explaining how planned orders get created, taking into account the negative days time fence.

I will touch upon the correlation between the negative days time fence and the item’s lead time.

I will also explain the Dynamic negative days time fence calculation and how that factors in the item’s lead time into the calculation of the time fence.

I will also try to better explain the MRP runtime improvement suggestions related to negative days that you can find here: http://blogs.msdn.com/b/axmfg/archive/2015/01/02/checklist-for-improving-mrp-performance-part-2-how-to-setup-planning-parameters.aspx

I will explain the above in the context of three different situations. The difference between these situations is at what point within the item’s lead time you get demand.

Please excuse the poor quality of the screenshots. Click on them to get a better view

Situation 1

Item _DemoProduct has a 6 days purchase lead time

On day 0 (1st Jan) the inventory level for item _DemoProduct is 0

On day 0 (1st Jan) you get a sales order for item _DemoProduct, quantity 10

On day 7 (8th Jan) there is an existing purchase order for item _DemoProduct, quantity 10

Case A

Negative days are set to 2, a value not really close to the 6 days lead time of _DemoProduct. We don’t use Dynamic negative days.

In this case, MRP will look for receipts for item _DemoProduct within the negative days time fence, and since it won’t find any, it will create a new planned purchase order. This planned order will immediately be delayed with 6 days (the lead time) so it will arrive on 7th Jan. The existing purchase order will get a Cancel action message, since it is now made redundant by the creation of the new planned purchase order.

So far so good, but if you take into account MRP performance and plan nervousness it may be not so good. Why? From a performance standpoint, MRP had to create a new planned order, calculate delays and actions, which are all time consuming tasks. From a plan nervousness perspective, you just got 2 more transactions to deal with…

What you gained? The sales order will not be delayed with 7 days, but with 6 days.

Case B

If this gain is not that important for you, then what you could do is set the negative days to be greater than or equal to the item’s lead time. There is no way you can get the supply inside the lead time anyway, so then why not search for receipts as long as it makes sense? On the bright side, it will make MRP run faster, but beware of orders being further delayed!

Case C

Another thing you could do is use Dynamic negative days (Master planning – Setup – Master planning parameters – General – Coverage – Use dynamic negative days). This setting will automatically correlate the item’s lead time to the negative days time fence. What will happen in this case is that MRP will look for receipts inside the dynamic negative days time fence, which is calculated based on the following formula:

DynamicNegativeDaysTimeFence = PurchaseLeadTime* + NegativeDaysTimeFence + (TodaysDate – RequirementDate)

*If the default order type of _DemoProduct would have been Production or Transfer, than the lead time would be the Inventory lead time.

With Dynamic negative days, the time fence MRP looks for receipts is now 6 + 2 + 0 = 8. So MRP will find the existing purchase order and will peg the sales order against it. No new planned orders will be created, hence MRP runtime will be shorter. The Net requirements for _DemoProduct look as follows:

Schematically, this is what happened:

Case D

So what happens if you set negative days to 0 and use Dynamic negative days only? Would that help you deliver on time and not create impossible planned orders? This actually works just like not using Dynamic negative days, as in the example below.

If you set Negative days to 0 and use only the Dynamic negative days time fence, which will now be 6 + 0 + 0 = 6, you will end up in the same situation as in case A: from a performance standpoint, MRP had to create a new planned order, calculate delays and actions, which are all time consuming tasks. From a plan nervousness perspective, you just got 2 more transactions to deal with… The demand still can’t be fulfilled on time, it will be late anyway.

Case E

If you both set the negative days to be greater than or equal to the item’s lead time and you use the Dynamic negative days time fence as well, than this will be 6 + 6 + 0 = 12. This may lead to a very long time fence MRP will search for results in. At the end of this post, there is a section related to what happens if you set Negative days to a long time fence, so please refer to that in order to understand Case E.

Situation 2

Item _DemoProduct has a 6 days purchase lead time

On day 0 (1st Jan) the inventory level for item _DemoProduct is 0

On day 4 (5st Jan), inside the item’s lead time, you get a sales order for item _DemoProduct, quantity 10

On day 7 (8th Jan) there is a purchase order for item _DemoProduct, quantity 10

Case A

Negative days are set to 2 and don’t use Dynamic negative days.

In this case, MRP will look for receipts for item _DemoProduct within the negative days time fence, and since it won’t find any, it will create a new planned purchase order, order date current date. This planned order will immediately be delayed with 6 days (the lead time) so it will arrive on 7th Jan. The existing purchase order will get a Cancel action message, since it is now made redundant by the creation of the new planned purchase order, with delivery date 7th Jan.

Case B

This is similar to situation 1: if you set the negative days to greater than or equal to the item’s lead time, then you will not get a new planned order. The sales order will be pegged to the existing purchase order.

Case C

This is also similar to situation 1, in the sense that dynamic negative days will work just as well. The dynamic negative days time fence will now be 6 + 2 – 4 = 4. So MRP will find the existing purchase order and will peg the sales order against it. No new planned orders will be created, hence MRP runtime will be better.

Case D

If you set Negative days to 0 and use only the Dynamic negative days time fence, which will now be 6 + 0 – 4 = 2, you will again end up in the same situation as in Case A. For a graphical view, refer to Situation 2, Case A.

Case E

If you both set the negative days to be greater than or equal to the item’s lead time and you use the Dynamic negative days time fence as well, than this will be 6 + 6 – 4 = 8. This may lead to a very long time fence MRP will search for results in. At the end of this post, there is a section related to what happens if you set Negative days to a long time fence, so please refer to that in order to understand Case E.

Situation 3

Item _DemoProduct has a 6 days purchase lead time

On day 0 (1st Jan) the inventory for item _DemoProduct is 0

On day 7 (8st Jan), outside the item’s lead time, you get a sales order for item _DemoProduct, quantity 10

On day 10 (11th Jan) there is a purchase order for item _DemoProduct, quantity 10

Case A

Negative days are set to 2 and you don’t use Dynamic negative days.

MRP will look 2 days ahead from the sales order’s requirement date. Since it doesn’t find anything, it will create a planned purchase order on 2nd Jan, that will be shipped just in time to fulfill the sales order demand. The existing purchase order will get cancelling action message, since it’s not needed.

You may notice that in the above AX screenshot, the Purchase order Requirement date is 12th Jan. That is because the screenshot was taken in 2015, when 11th Jan is a Sunday, so MRP moves the Requirement date to 12th Jan, the next working day. But the purchase order has a Delivery date of 11th Jan.

Case B

This is a case to take a minute and think about. If you set the negative days to be greater than or equal to the item’s lead time, then you will not get a new planned order. The sales order will be pegged against the existing purchase order, so in this case the sales order will be delayed, although if you were to create a planned order you could ship the sales order on time!

Case C

This is also similar to situation 1, in the sense that dynamic negative days will work just as well and even better than if you compare to case B.

The dynamic negative days will be 6 + 2 – 7 = 1, but in this case the system will still consider the negative days lead time (2), because MRP takes into account the maximum value between negative days lead time and dynamic negative days lead time. So the result in case C is the same as in case A.

Case D

If you set Negative days to 0 and use only the Dynamic negative days time fence, which will now be 6 + 0 – 7 = -1, but in this case the system will still consider the negative days lead time (2), hence case A is the same as case D. So all the pitfalls you have in A you will have in D. For a graphical view, refer to Situation 2, Case A.

I will not refer to case E anymore, since it’s exactly the same as in situation 1 and 2 – it has more or less the same benefits and pitfalls.

Based on the above it seems a good idea to set the negative days to be greater than or equal to the lead time of the items in the coverage group and/or to always use dynamic negative days and set the negative days to number of days you are willing to wait with negative inventory, before ordering new replenishment (in other words, the number of days you are willing to further delay demand).

The above hopefully also illustrates why items in the same coverage group should have similar lead times.

If you set the negative days to 0 and you don’t use Dynamic negative days, then MRP will always create a new planned order to fulfill demand. So if you setup the system like this, it’s important to work with the Action messages to make sure you don’t pile up inventory.

I have come across blogs and went to conference session where it is recommended to set the negative days to long time fences and then work with the action messages. This will indeed provide good planning results, but will just be a bit slower and potentially more difficult to analyze, due to the need to analyze and apply the action messages.

Let’s look at the following example:

Item _DemoProduct has a 6 days purchase lead time

On day 0 (1st Jan) the inventory for item _DemoProduct is 0

On day 0 (1st Jan) you get a sales order for item _DemoProduct, quantity 10

On day 10 (10st Jan) you get a sales order for item _DemoProduct, quantity 10

On day 12 (12th Jan) there is a purchase order for item _DemoProduct, quantity 10

Negative days are set to 20, which is a lot more than the item’s lead time.

MRP will create the following result:

You may notice in the above that the sales order Requirement date is 9th Jan, instead of 10th Jan. That is again because the screenshot was taken in 2015, when 10th Jan is a Saturday, so the Requirement date of the order should be the previous working date, hence Friday, 9th Jan.

MRP creates a planned purchase order to fulfill the demand requested by the first sales order, but then it also recommends you cancel this planned order, because you can advance the existing purchase order and increase the quantity on it.

The results are not wrong by any means. But MRP will potentially run longer, because it will need to create all the delays and suggestions. Also, the planner may need more time to understand the MRP results. And, most importantly, in this case it’s essential that the planner understands and uses the action messages!

Setting the negative days to a lower value, close to the item’s lead time (hence also adhering more to the definition that they represent the number of days you allow negative inventory) and using the Dynamic negative days setting, will give the following result:

MRP will create a planned order pegged to the first sales order. Then the second sales order gets pegged against the existing purchase order, as expected based on the negative days setting. This planning result is also correct and in this case MRP will potentially run a faster. In this case it’s not essential that you understand and know how to work with the action messages.

So all in all, it’s not easy to come up with the right setting for negative days. There are some ‘do’s and ‘don’t’s, but finding the right values for your business is a trial and error game, and you have to think in terms of both functionality and MRP runtime.

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

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

The hotfix in Microsoft Knowledge Base (KB) article 3093049, that is planned to be released mid-October, enables order picking from license plate locations for raw material picking. This hotfix also introduces a policy that controls the status of the material line after raw material picking has been completed.

Order picking from license plate locations

For raw material picking, there are two picking principles: order picking and staging. The term order picking is used when the ordered quantity is being picked, whereas the term staging is used when the full quantity on the picked license plate is being moved. Up to now, only staging from license plate locations has been possible. However, this hotfix now makes it possible to configure which of the two principles should be used for raw material picking. This policy is controlled at the item level, where a new Material picking in license plate locations field has been added on the Warehouse management FastTab.

By default, when a new product is created, the value of this field is set to Order picking. When you apply this hotfix on a customer installation, it’s important to change the value of this field to Staging for the items that are picked. Typically, these are the items that have been stored at the license plate locations. 

Controlling the status on the material line after material put

A new Status after material put field has been added to the Inventory and warehouse management parameters.

The value of this field controls the status of the inventory transactions for the production material line after warehouse work for raw material picking has been completed. Up to now, the status has always been Picked.

The Picked status deducts physical on-hand inventory. However, feedback indicated that users expect to see the physical on-hand material at the input location after the warehouse work has been completed but not yet consumed by the production order. Therefore, it’s now possible to switch the Issue status between Picked and Reserved physical.

When you select Reserved physical, the material appears as physical on-hand (but reserved) inventory at the input location after warehouse work has been completed. Be aware that with this setting material is reserved at the location and dimensions above the location in the reservation hierarchy. If the material reserved for example has batch number below the location in the reservation hierarchy, then the batch number is not included in the reservation. In this case it will not be possible to backflush the material. If back-flushing is a requirement, then the batch number must above the location in the reservation hierarchy, because that will include the batch number in the reservation.

The hotfix in Microsoft Knowledge Base (KB) article 3093049, which is planned for release in mid-October, enables scenarios where registration of a component’s serial number can be postponed until the time of consumption in production. Here is one of the customer scenarios we have been looking at:

Most of the components we use for our machine assemblies are delivered from vendors. These components are typically received on pallets packed in a quantity of for example 200 pieces. Each component has a unique engraved serial number, but we don’t need to register the serial numbers at product receipt. We just register the receipt of the pallet, so that we don’t have to spend time breaking up the pallet and registering each serial number individually. The serial number also isn’t registered when the warehouse worker picks the component for the production order. However, when the assembly worker mounts the component in the assembly, she reads the engraved serial number on the component and updates it in the system. By registering the serial number at the time of consumption, we can print a list that shows exactly which component serial numbers were used in a given assembly. Then, if we receive a complaint, and the issue that is reported can be tracked to a specific component, we can communicate the serial number back to the vendor. In a worst-case scenario, if the issue is systematic (for example, a batch of bad-quality rubber sealing has been used in the component), the vendor will track all the components that are affected and communicate the serial numbers affected back to us. Because we can track the serial number that is used in a given assembly, we can now identify all the assemblies that are affected and take the necessary measures.

This scenario is now supported in Dynamics AX and can be demonstrated by using a simple bill of materials (BOM) that is named Assembly and a serial-controlled item that is named Component.

In the warehouse, the component is tracked only by location and license plate. The serial number of the individual components on the license plate aren’t known at this point.

A production order is released for the assembly, and warehouse work is created to pick up the component.

The warehouse work is processed without specifying the serial number of the picked component.

The production order is started, and the production picking list journal is created.

The picking list journal can’t be posted unless a serial number is specified. Any attempt to do so will cause the following error message:

This message indicates that a serial number must be registered before the picking list journal can be posted. The new Register serial numbers menu item that has been added to the Inventory Action Pane button can be used to resolve this error.

The journal can now be posted, and the serial number is updated on the issue transaction for the production material line.

The bill of serial for the assembly can now be printed from the tracing tool.

A new field Register serials before consumption has been added to the Tracking dimension groups form to enable this scenario. This field works together with the Capture serial field for the values Picking and Packing. For example, when Picking is selected in the Capture serial field, the serial number also needs to be provided at the time of picking.

The core team has been engaged in a couple of requests about how to set up raw materials that acts as consumables in production. In these requests the following characteristics has been used for consumables:

• They are never stored in the raw material warehouse, but filled up directly at the production locations, therefore warehouse work for raw material picking is never needed for these materials.

• They often represent a low value and are not accounted for at time of consumption, but cycle counted at a periodic basis.

• They are often set up to allow for physical negative inventory to avoid blocking issues when they are back-flushed in production.

As we encountered some issues using items that are WMS-enabled for consumables with the above mentioned properties, we recommend to use items that are NOT WMS-enabled for this purpose. With this item is possible to:

• Setup a default issue location either at the item-warehouse level or by the resource (resource consumption). This location will be defaulted to the production bill of material line, and act as the production input location i.e. the material will be consumed from this location.

• Use it in a warehouse that is WMS-enabled, and there is no problem setting up this product to allow for negative inventory.

• Ensure that warehouse work will never be generated for this item.

   

The problem with using a WMS-enabled item in combination with allowing for negative inventory is, that warehouse work will be generated in case there is no on-hand on the production input location. This happen instead of deducting the input location with a negative quantity, which would be the expected behavior. An attempt to back-flush the material in a later stage will result in a blocking error “Item XXX does not have enough inventory”.

The recommendation of using a WMS-enabled item for consumables, will not support a scenario where the warehouse processes is applicable for the item in other processes, for example, in the product receipt process. Supporting these different scenarios for the same item is currently identified as a gap, but we are currently investigating possible solutions to enable this capability.

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

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

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

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

Configuration of the menu item

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

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

Reporting as finished with End job

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

The formula line is set up with flushing principle Finish

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

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

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

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

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

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

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

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

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

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

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

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

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

In total a quantity of 1003 has been reported as finished

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

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: 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

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

 After installing this hotfix it is now possible to configure the location directive for raw material picking, so work can be rounded up to the nearest handling unit in which the material is picked for production.

Consider following scenario:

A food manufacturer uses a special flour for making a powdered soup mix. The flour is stored on pallets in 50 lb bags in the bulk warehouse. For making 4,475 lb of the powdered soup mix 510.15 lb of flour is needed. This corresponds to 10 x 50 lb bags + 10.15 lb. As the material is always picked in bags (the handling unit), the warehouse worker will in this case pick 11 bags. After the 11 bags are moved to the production floor, the bags are broken and 510.15 lb is weighed off and applied to the production process. The remaining quantity from the last bag will remain on the input location and either be consumed by the next batch order or moved back to the warehouse.

Before the release of this hotfix it was possible to set up in which handling unit the material should be picked, but it was not possible to round-up the quantity to the nearest handling unit. In the above example, work for raw material picking would have been created for 10 x 50 lb bags and 10 lb i.e. for the same work the material would be picked in two different units. This scenario is still supported, and is relevant for some customers who wants to weigh of the material at the warehouse location (in this case the remaining 10.15 lb).

Let us take a closer look at how the mechanism to round up work to the nearest handling unit has been enabled.

Setting up the location directive for raw material picking

In the location directive for raw material picking a new field Round up to handling unit has been introduced:

This field works together with the field Restrict by unit. In this example the location directive is set up to pick in the unit of Bag, and selecting Round up to handling unit indicates that the work generated out of the directive should be rounded up to a multiple of one handling unit.

Setting up formula and ingredient

In this example a formula version for making the soup mix is set up with a batch size of 4475 lb, consuming 510.15 lb of Flour

A unit conversion has been set up for the Flour ingredient between the unit’s bag and lb.

The following Unit sequence group is used for the item. The inventory unit must be the first unit in the sequence group, in this case lb.

Releasing work for raw material picking

A batch order is now created and released for the batch size of 4475 and warehouse work for raw material picking is generated.

As it can be seen from the work details work is in this case rounded up to 11 bags. The batch order is still only reserving the required quantity 510.15 which can be seen from the work transactions form that can be opened from the work details form:

If the rounding option had not been used on the location directive, then the resulting work would have looked like this:

In this case the warehouse worker would have to pick 10 bags and weigh of the remaining 10.15 lb on a warehouse location. This process is enabled in the location directive by adding a line that is not restricted by unit. This line will make work for the remaining quantity.

In this blog post I will elaborate on the processing of configuration models in Microsoft Dynamics AX 2012 R2 and R3.

Figure 1

Client 1 loads a configuration model using an RPC call to the AOS to retrieve an XML representation of the configuration model. After this the processing of the configuration session happens on the client.

When Client 2 wants to load a configuration model, it goes through the same process as Client 1, by retrieving its own XML representation of the configuration model, which it wants to load. Then processing of this model happens solely on Client 2. In this way processing is distributed on the hardware of the different clients.

However, the reality for many of our customers and partners is a bit different to the picture shown Figure 1.

Figure 2

The setup in Figure 2 should be more familiar to those of you who have experience with Microsoft Dynamics AX 2012. Instead of having fat clients as in Figure 1, the users are instead connecting to the Dynamics AX windows client, using a remote desktop session, set up on a Windows server running Terminal services.

Thus when Client 1 wants to load a configuration model, it happens via the Terminal service, which is then retrieving the XML representation of the configuration model from the AOS. The processing of the configuration session then happens in the context of the remote desktop session, which is on the host of the terminal services.

The same thing repeats itself when Client 2 wants to load a configuration model. The difference between this and the previous setup is, that processing for both configuration sessions are now centralized on the host of Terminal services. This processing includes not only the processing of the underlying configuration model, but also the processing related to handling the rendering of the UI.

When we look at what is happening at a lower level, with more details, the picture looks like this:

Figure 3

The diagram in Figure 3 shows what happens when the XML representation of the configuration model has already been retrieved from the AOS. From the Xpp client it is then passed on to the Product Configuration .NET component crossing the CLR interop. In the loading phase of the configuration model inside the .NET component, the following action are executed:

• Parsing the XML representation of the configuration model
• Creation of supporting data structures

After these processes the .NET component starts to process the loaded model and then starts to issue events whenever it is able to deduce that an attribute must take on a certain value. These events are send back to the Xpp client which updates the page accordingly.

At some point the user will want to accept the configuration and this is done by pressing the OK button on the dialog. When this happens a method is invoked on the .NET component, which aborts any running task, and starts a new task which verifies whether the configuration is complete. The definition of a complete configuration is that all mandatory attributes have been assigned a value.

If the verification fails in the first attempt, the configurator will issue a new task to attempt to deduce any unassigned mandatory attributes. In the illustrated example, the configurator is not able to deduce all mandatory attributes, and so a message will be shown that informs the user that additional assignments are required. The user must then assign values to the remaining mandatory attributes. Here the user makes a new assignment and then presses the Ok button again, to complete the configuration. This time the verification passes as all mandatory attributes now have a value.

An important thing to notice is that the configurator instance is active or ‘alive’ throughout the configuration session. As you may know, the .NET configuration component uses a background thread to process the configuration model without locking the UI. In this way the configurator is always able to act on new user input.

In this blog post I will explain how on user interactions are handled by the product configuration module for Microsoft Dynamics AX 2012 on the Enterprise portal.

The figure above, is a high level illustration of how user interactions in general are processed on the Enterprise Portal (EP) for Microsoft Dynamics AX 2012. The clients access the AOS through EP, which is a web implementation built on top of Microsoft Sharepoint, hosted on a web server (IIS). The communication between EP and the AOS is synchronous using the .NET Business Connector RPC call. Each RPC call must be completed and returned, before http request timeout is exceed on the IIS.

To understand what implications the above has, when using the Product configuration module, we will go through the sequence of events, which take place when the user loads a configuration model and assigns a value to an attribute.

The above illustrates the sequence of loading a configuration model and assigning an attribute a value on the Enterprise portal.

Loading a configuration model

When the user wants to configure a product, e.g. from a sales order, the requests will be handled by EP.  The EPPCConfigurator web control will be loaded, inside the web control a proxy Instance of the PCEnterprisePortalMain class is created. This proxy is used to interact with the AOS Product configuration logic.

On the AOS, the XML representation for the specific configuration model is retrieved from the database. Then the XML string is passed as argument to Product Configuration Server API, which unlike the Client API is design to support synchronous execution. In the creation of the ProductConfigurationServer instance, the XML is parsed and supporting data structures are created, just like on the Windows client implementation.

Once the data structures have been created, the configurator instance can start processing the constraints and calculations of the configuration model. Unlike the Windows client however, the processing on EP needs to respect a fixed time limit, in order not to cause a timeout on the web server.

Another difference between the Windows client an EP is the way the model is being processed. The EP implementation will attempt populate all visible enumeration and Boolean attributes. This is the equivalent of opening all the visible attribute controls on the active component in the form, and letting the configurator deduce feasibility of the values of each attribute.

The more attributes that are visible, the less time that is available to process each attribute. For components with over 20 enumeration and boolean attributes, it can happen that there is not enough time to process the feasibility of all values within the domain of the attribute.

Assigning values to attributes

When the user   makes an assignment to an attribute, the web form is then posted back to EP and  a request to assign the attribute is made on to the AOS. On the AOS, each call from EP executes in its own context, this implies that a new instance of the configurator is created. This instance must again parse the XML representation of the configuration model, before being able to process the user assignment. After this, the instance is disposed and a new one is created to process the assignment , same as before.

The main problem can be seen from the diagram in Figure 2, is the activation line of the ProductConfigurationServer object. Unlike the Windows client implementation , the configurator instance is not kept alive throughout the configuration session. The synchronous execution combined with the time limitation is the main limiting factor, which forces us to create and dispose instances of the configurator for each request.

The consequence of this is that the EP implementation of the configuration module, is not able to deliver a user experience which is similar to that of the Windows client for models of medium to high complexity.

Please keep this in mind when considering implementations of the Product Configuration module on Enterprise Portal for Microsoft Dynamics AX 2012.

With KB-3164415 a new work flow for the hand held device has been introduced. This work flow enables the user to report raw material consumption for production and batch orders.

This work flow is for example relevant when there is a strict requirement for material traceability. In that case e exact time and quantity for must be reported for the consumption. This process can be seen opposed to back-flushing .

Let’s look at a simple scenario that explains how the new work flow can be used. A production process is consuming a raw material RM that is stored on a license plate 4543 with two batches B1 and B2. The material is registered consumed on a continuous basis.

Configuration of the new flow

First create a new Mobile device menu item with the activity code: Register material consumption

Add the menu item to a Mobile device menu

Make the consumption registration on the hand held device

Create a production order for the finished product FG

The production order has a simple bill of material with a raw material RM The Bill of Material line is set up with a flushing principle: Manual.

The raw material is on-hand with two batches on a license plate on location 00901.

The production order is started.

The production order is now in status: Started.

Let’s look at an example where the user registers the consumption of 100 lbs. of the raw material RM.

Some additional comments to the flow:

• If the user cancels the flow after a journal line is created, then the journal is in an un-posted state.
• If the same user starts up the flow again, for the same production order, then any new line will be created in the existing open journal.
• The new flow is also supporting the registration of serial numbers.
• It is only possible to register an item number that is defined in the bill of material or formula for the selected production or batch order.
• It is possible to over-consume a material. If a material for example is estimated to be consumed with the quantity of 100 lbs., then it is possible to over-consume with a quantity of for example 105 lbs.

Warehouse processes don’t always include warehouse work. By using the new warehouse work policy introduced with KB3184505, you can omit work warehouse processes in production for specific products and locations.

Below figure shows a scenario how the Work Policy can be used (double-click on the figures to make them bigger).

In this scenario, we have two production orders; one for painting Comp-1 and one for the assembly of Fg-1. The production order for Comp-1 is reported as finished to the location 001. The production order for Fg-1 is later consuming Comp-1 and Rm-1 from location 001. When the production order for Fg-1 is released, warehouse work for raw material picking is generated to move Rm-1 from the Bulk locations to 001.

For this scenario, we can set up following requirements for the warehouse processes:

• No warehouse work for Finished goods put away should be created when reporting as finished Comp-1 to location 001 because Comp-1 is later consumed on the same location by the Assembly operation.
• No Work for Raw Material Picking should be generated for Comp-1 when releasing the Assembly operation to the warehouse.
• Work for Raw material picking should be generated for Rm-1 when releasing the production order for the Assembly operation to the warehouse.
• It should be possible to define location 001 as non-license plate controlled, as it acts both as a production input location and a production output location (so far it has not been possible to define the production output location as non-license plate controlled).

The following walkthrough shows how these requirements are supported by the Work Policy. First we will set up a Work policy named NoPickPutAway-001-FG1 as shown below

As it can be seen from the figure, the Work policy uses the following three criteria to define work creation:

• The Work Order Type
• The Location
• The Product (selected or all products)

Above policy will prevent Finished good put away work to be generated when Reporting as finished product Comp-1 to location 001 in warehouse 51.

The policy will also prevent Work for raw material picking to be generated when releasing a production order that is consuming product Comp-1 from production input location 001.

Location 001 is defined as a non-license plate controlled location. It is pre requisite for defining a non-license plate output location, that a work policy exists for the location that prevents work for Finished goods put-away from being created.

Let’s take a closer look at the setup of the products and then how the work policy works in this scenario. Product Comp-1 has a Painting operation which is associated a resource group with output location 001

The Assembly operation for the production order for FG-1 is consuming the products Comp-1 and RM-1 from the input location 001. The input location is setup on the resource requirements for the Assembly operation

The active bill of material version for Fg-1 is setup for materials Comp-1 and Rm-1

Now we create a production order for Comp-1 for 20 pieces

The production order is Started

The production order is Reported as finished from the hand-held device in the below flow

In this case Comp-1 was reported as finished directly to location 001 and no put-away work was generated because of the Work policy.

Now we create a production order for FG-1

The production order is Estimated and Released

Work for raw material picking has been generated for Rm-1, because the Work policy is only preventing work for raw material picking for product Comp-1 to be generated from location 001

In the first release of the Work policy only the following three Work order types for production are supported

• Raw material picking
• Finished goods put away
• Co-product and by-product put away

Introduction

A new flow for the handheld device has been released with KB article: 3148600. This flow enables the user to register the finished good serial number when reporting as finished in production. This flow is targeting a process where the finished good serial number is generated under the following conditions:

• It is assigned by the system at the time when the production or batch order is created.
• It is configured to be unique per one single unit of the production order. If, for example, a production order of five pieces is created, five unique serial numbers are created.

Configuration of the flow

This section provides information about how the flow is configured.

Create a new Mobile device menu item, and name it, for example, Register serial number. In the field Work creation process select Register report as finished by serial number.

The menu item can be added to a menu, for example, the Production menu, as shown below.

Use the flow in production

This section provides information about how the new flow can be used in production.

Create a finished good

Create a new finished good that is controlled by serial number.

As this is an item enabled for the new warehouse processes, make sure the Number sequence group ID is added the product. Note: This flow is only applicable for a product that is enabled for a managed warehouse.

Associate a Serial number group, with this setup, with the released product.

With this setting, a serial number per quantity of the finished good will be created, when the production or batch order is created.

Create a production order

Create a production order for the finished product.

When the production order is created, open the Transactions form and notice each of five transactions has a serial number assigned.

Estimate and start the production order

Open the menu for the handheld device and register report as finished for the serial number: 000006.

Open the Transactions form again and notice that the serial number has been reported as finished to the inventory.

Open the Work details form and notice that work of type Finished goods put away has been created.

A new feature for cross-docking from a production or batch order to a transfer order has been released together with KB 3207958.

Input about this feature has come from manufacturers that produce in high volume – for example, food manufacturers. These manufacturers are constantly shipping their finished goods from the bay doors of the manufacturing site to distribution centers. This flow is reflected in the layout of the production floor, where the palletizers at the end of the production lines are located close to the bay doors. The transportation plan is based on the production plan. Therefore, in most cases, when a product is reported as finished, a transfer order is waiting, so that the finished good can be shipped to a distribution center right away.

This scenario starts at the end of the production line, where goods are reported as finished. When goods are reported as finished, work of the Finished goods put away type is usually created to guide the warehouse worker to pick the goods from the production output location and put to a location that is determined by the location directive for Finished goods put away. This feature enables a process where, during the process of reporting goods as finished, the system looks for an opportunity to cross-dock the goods to the bay door locations where there is transfer order demand. From a system perspective, the cross-docking opportunity is a transfer order that is released to the warehouse. This transfer order represents the transportation between the manufacturing plant and a distribution center. If a released transfer order exists, the system generates work of the Transfer issue type instead of the Finished goods put away type. This work suggests that the warehouse worker pick from the production output location and put to a location that is determined by the Transfer issue location directive for the Put work order type. The following illustration shows this process.

In the preceding illustration, the truck driver picks up the pallet at the end of the production line. If a released transfer order exists, the system directs the forklift driver to the bay door location. If there is no demand at the bay door, the system directs the truck driver to a location in the warehouse.

How to configure cross docking

You configure the cross-docking process in work policies. A work policy includes a work order type, a location, and a product. In the following example, cross-docking is configured for product X and location Y.

Work order types

• Work order type: Finished goods put way
• Work creation method: Cross docking
• Cross docking policy name: Transfer orders

Inventory locations

• Warehouse: 51
• Location: Y

Products

• Item number: X

Currently, cross-docking can be configured for only two work order types:

• Finished goods put away
• Co-product and by-product put away

In the cross-docking policy, you define which document types are applicable for cross-docking. Currently, the only document type that is supported is Transfer orders . The following example shows the configuration of a cross-docking policy.

Cross docking policy name: Transfer order

• Sequence number: 10
• Work order type: Transfer issue
• Cross docking demand requires location: False
• Cross docking strategy: Date and time

The sequence number indicates the priority of the document type. Currently, Transfer issue is the only type that is supported. Therefore, the sequence number will become relevant only when more work order types are supported.

The cross-docking policy also sets the policy for the prioritization of transfer order demand. For example, if multiple transfer orders exist for the same product, the scheduled date and time that are set on the load and associated with the transfer order determine the prioritization between the orders. The scheduled date and time can be set directly on the load, or they can be set on an appointment schedule that is associated with the load. The prioritization is determined by the cross-docking strategy. Currently, there is only one strategy: Date and time.

In the cross-docking policy, you can set up a criterion to require that transfer orders have an assigned location in order to be eligible for cross-docking. This criterion is set in the Cross docking demand requires location field. In this case, the location on the appointment schedule that is associated with the load is used as the final location for the goods that are being cross-docked. If the Cross docking demand requires location field isn’t set, the transfer order can be eligible for cross-docking even if a location isn’t set on the appointment schedule. In this case, the final location for the goods that are being cross-docked is determined by the location directive for Transfer issue for the Put work order type. You might find it useful to set the Cross docking demand requires location field in a scenario where the finished goods should be cross-docked only if a trailer is assigned to a bay door. In this scenario, the goods are moved directly from the production line into the trailer. When a trailer is assigned to the bay door, a user will assign the location to the appointment schedule and will therefore make the location applicable for cross-docking.

The following sections walk you through two examples.

Scenario 1 – Cross-docking to bay door locations

Finished good L0101 is reported as finished to production output location PRODRECV in warehouse 51. Transfer orders for L0101 are set up to manage transportation between location BAYDOOR in warehouse 51 and a receipt location in warehouse 61. If a released transfer order for L0101 exists, the product should be cross-docked to the BAYDOOR location when the product is reported as finished.

Scenario 2- Cross-docking to a bay door location assigned a trailer

Finished good L0101 is reported as finished to production output location PRODRECV in warehouse 51. Transfer orders for L0101 are set up to manage transportation between location BAYDOOR in warehouse 51 and a receipt location in warehouse 61. If a released transfer order exists for L0101, the product should be cross-docked to the BAYDOOR location when the product is reported as finished.

Scenario 1 – Cross docking to bay door locations

Use company USMF.

2. Enable a new number sequence for cross-docking

Go to the Number sequences page, and select the Generate button. A wizard will guide you through the process.

2. Create a Cross docking policy

Go to the Cross docking policy page, and create a new policy that is named Cross docking to transfer order.

Note that the only work order type that you can select is Transfer issue, and the only cross-docking strategy that is available is Date and time.

3. Create a Work policy

Go to the Work policies page, and create a new work policy that is named Cross Dock L0101.

4. Set up loads so that they are created automatically for transfer orders.

In the warehouse parameters, set up loads so that they are created automatically when transfer orders are created. A load is a prerequisite for making the transfer order eligible for cross-docking.

5. Set up the item load mapping.

Go to the Item load mapping page, and set up a standard load template for the CarAudio item group. This mapping will automatically insert the load template on the load when the transfer order is created.

6. Create a transfer order

Create a Transfer order for item number L0101

7. Release the transfer order from the Load planning workbench

On the Ship tab, select the menu item for the Load planning workbench.

Release the transfer order from the load by selecting Release to warehouse on the Release menu on the load line.

An open wave line of type Transfer issue now exists for the transfer order.

8. Create a production order

Go to the production order list page, and create a production order for product L0101.

Estimate and start the production order by using the settings in the following screenshot. Note that the Post picking list now field remains set to No.

9. Report as finished from the mobile device

Go to the mobile device portal and select menu item: Report as finished and put away. Now report as finished L0101 from the hand held device.

Note that the put location is BAYDOOR. This location is found from the Transfer issue location directive for the Put work order type.

Also notice that work of type Transfer issue has been created and completed. Go to the transfer order Work details to verify the work.

Now try to start 20 pieces more on the production order

Now try to report 20 ea as finished by using the handheld device.

This time, location LP-001 is suggested as the put location. This location is found from the location directive for Finished goods put away. This location directive is being used, because no opportunity for cross-docking exists. The transfer order for LP-001 was completely fulfilled by the first cross-docking activity.

Work of type Finished goods put away was created and processed

Scenario 2- Cross-docking to a bay door location assigned a trailer

Use company USMF.

1. Change Cross-docking policy

Change the cross-docking policy that you created in scenario 1 by selecting the Cross docking demand requires location check box.

2. Create a new transfer order

Create a transfer order, and go to the Load planning workbench.

Open the Load planning workbench.

3. Create an Appointment schedule.

From the Load planning workbench, go to the Loads section, and select Appointment schedule on the Transportation menu.

Create a new appointment schedule. Note that the appointment schedule has a reference to the transfer order in the Order number field. In the Planned start date/time at location field, you can set the date and time for the appointment. This date and time will be used when cross-docking demand is prioritized during the cross-docking process. The date and time that you set in this field will update the Scheduled load shipping date and time field on the corresponding load. The location on the Shipping details FastTab determines the location that the transfer order is shipped on.

Back on the Load planning workbench release to the warehouse

4. Create a production order

Create a production order for item number L0101, and set it in status Started, as you did in scenario 1.

5. Report as finished from the mobile device

Go to the mobile device portal, and select the Report as finished and put away menu item. Now report item L0101 as finished from the handheld device.

Note that the put location is now BAYDOOR 2. This location is found from the appointment schedule instead of the Transfer receipt location directive.

Flow diagram

The flow is explained in below flow chart diagram:

Additional information

• The cross docking scenario is supported for batch and serial controlled items, both with the batch and serial number dimensions defined above and below location, in the reservation hierarchy.
• The quantity that is being reported as finished cannot be split to a transfer order demand that is lower. If, for example, 20 pieces is being reported as finished and a transfer order exist for 5 pieces, then the transfer order will not be found applicable for cross docking.