Companies in process industries usually manufacture products that are subject to varying degrees of regulation by regional, national or global organizations to safeguard workers and/or consumers. For instance DDT is banned in most countries but allowed in some countries or use of asbestos is completely banned but use of benzenes up to 5mg/Kg in toys is allowed in EU.

Process Manufacturing for Microsoft Dynamics^® AX 2012 provides a rich toolset for food, drug and chemical manufacturers to manage products containing restricted and / or regulated substances. Process manufacturing solution has been extended further by several ISVs to meet specific requirements of chemical and pharmaceutical manufacturers.

First it is important to familiarize with key terms and definitions as used in Dynamics AX2012

Regulated product

A product is considered to be a regulated product if it is regulated by a government authority and if it requires compliance and audit reporting.

Restricted product

A product is considered to be a restricted product if its distribution is limited or constrained by a government authority.

Reported product

Reported product is a product that is regulated and company is required by regional or national authority to provide usage data on the product.

Product safety data sheet

Product safety data sheet is a brochure that contains handling, emergency and other related information about the product for example, flash point, boiling point etc. of the substance.

Now, follow these steps to setup controls on your products.

Inventory setup

Restriction lists

Restriction lists for countries and regions can be setup in Inventory management module. There are two types of lists – inclusive and exclusive. Inclusive type lists need to be setup for a country before exclusive type list can be setup for its regions.

Figure 1 – maintaining regional lists for restricted products

If number of regions in which product is allowed are more than the number in which it is not allowed, setup an inclusion list for country and an exclusion list for provinces where it is not allowed. If the product and excluded region appear together on a sales order line, system will throw a warning and prevent the sale.

Once the restriction lists are setup, products can be added to such lists. Once products are added to such lists, they are treated by system as restricted products.

Figure 2 – maintaining individual products on a specific restricted products list

Regulated and reported products

Regulated products and reporting lists for countries and regions can be setup in Inventory management module. If the product is only regulated in a country or region then it need not be marked as reported. However if usage data of a product needs to be reported then it needs to exists on a reporting list.

Figure 3 – maintaining regulated products and reporting lists

In the adjoining figure, all products that are regulated in Germany but not reported can be setup against the last record in the table. All other records are for specific reported lists and hence will contain only products that need reporting in specific regions on given reporting lists.

Product safety data sheet

Using this form, default parameters like validity interval and expiry advice interval for product safety data sheets can be setup.

Figure 4 – maintaining defaults for product safety data sheets

Setup on Released products list page

Figure 5 – Options available on released products list page to maintain compliance data

Once standard lists are defined in the inventory management module, individual products can be added to such lists from the released products list page.

Regulated products

A (1) regulated or (2) regulated and reported list needs to exist before it can be selected from this option. The user is only able to see the country/ region in the list if a list is already defined. Using this option is faster if a product exists on multiple lists. 

Restricted products

A restricted list needs to exist before it can be selected from this option. The user is only able to select the list ID for a given country/region if a list for that combination is already defined. Using this option is faster if a product exists on multiple lists. 

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 an update log is automatically 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

Figure 6 – maintaining compliance data as required by a specific regulating authority

Using this form the user can setup additional information as required by some US-centric regulatory authorities. This information can be printed to documents or exposed to external interfaces as maybe needed. If a substance name as defined by a regulatory body is referenced from an external system, then all the product related information attached to such a name can be retrieved. Regulatory authorities covered by this form are as below.

v  EPCRA: Emergency, Planning and Community Right-To-Know Act

v  CERCLA: Comprehensive Environmental Response, Compensation, and Liability Act

v  TSCA: Toxic Substances Control Act

v  TRI: Toxics release Inventory from United States Environmental Protection Agency

v  OSHA: Occupational Health and Safety Administration

v  EHS: Extremely Hazardous Substances

Figure 7 – viewing usage data

Using this form, the user can check the usage data for a particular product. Such information can then either be exposed to custom reports or provided to external systems electronically. CAS numbers (Chemical Abstract Registry) can be linked to the product on this form. 

Using product safety data sheets

Figure 8 – using product safety data sheets

If a product is regulated and if a product safety data sheet already exists then it automatically appears during purchase order or a sales order entry. If a new safety data sheet or a newer version of existing data sheet is received from a vendor then it can be added during purchase order entry. If a new or existing data sheet is to be sent to a customer then that can be added to the log as well. This form keeps a log of all safety data sheets sent or received on each order. Parameters can be setup in inventory management module to control the system behavior regarding safety data sheets at various points in the logistics process.

Figure 9 – setting up product compliance parameters

As shown in adjoining figure, parameters in the inventory management module can be setup to receive warnings and / or e-mail notifications during following processes

v  Purchase order entry

v  Sales order entry

v  Sales packing slip posting

v  Sales invoice posting

Figure 10 – warning received during purchase order entry

Figure 10 shows one such warning received when a product set to be regulated in Germany is received in a company with German address and if product safety data sheet for such a product is in expiry advice interval.

Figure 11 – parameters control printing and posting on sales packing slip

Figure 11 shows how sales packing slip or invoice posting can be prevented from sales packing slip. It also shows that product safety data sheets attached to the sales order can be optionally printed along with the packing slip posting if setup on parameters in inventory management module.

Hopefully with the help of above setup you will be able to utilize regulatory compliance capabilities in Process Manufacturing for Dynamics AX2012.

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 item conversion 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.

A lot of poeple have asked me what can process manfuacturing do in Dynamics AX2012? This post will hopefully serve the purpose.

Process manufacturers deal with resource rich industries on buy side and with aggregators & retailers on sell side, both having larger bargaining power. The constant squeeze between two powerful groups’ reduces already thin margins and this is likely to exacerbate for US & Western European manufacturers in the coming years as manufacturers in the emerging markets stake their claim for even larger share of the pie.

Process manufacturers therefore continuously need to reduce costs, improve quality & maintain security standards to be able to keep their margins in the markets that are important to them.

Process Manufacturing for Microsoft Dynamics^® AX 2012 (formerly known as process industries or PI) gives process manufacturers a low cost solution that can model lean, discrete & process manufacturing in one box, is versatile & flexible to model new organizations, products or processes, supports most common multi-X scenarios and can be extended to support specific vertical requirements without the need of additional IT investments.

Process Manufacturing for Microsoft Dynamics^® AX 2012 enables manufacturers and distributors of natural, industrial or consumer packaged products to control costs, increase profitability, maintain stringent quality standards and manage compliance using a familiar user interface on an advanced technology platform with cost of ownership that is significantly lower than the competition.

Process manufacturing for Microsoft Dynamics^® AX2012 is available in two different SKUs. Process Manufacturing logistics is targeted at customers who would like to automate their distribution processes for products that are usually manufactured in a batch or semi-continuous processing environment. Process Manufacturing production is targeted at customers who would like to automate their batch or semi-continuous manufacturing processes. Process manufacturing logistics SKU is a pre-requisite for process manufacturing production SKU.

Both SKUs contain enough functionality that can also address some needs of customers with discrete manufacturing environment. Key functionalities enabled by process manufacturing are:

• Maintain complex formulae
• Manage short life products
• Manage commodity pricing
• Manage product compliance
• Setup & apply complex rebates
• Advanced lot tracking & control
• Enhance cost management of multiple outputs
• Procure, store & sell products in dual units of measure
• Manage production for assembly or disassembly for single or dual units of measure

SKU 1- Process manufacturing production

Process manufacturing production for Microsoft Dynamics^® AX 2012 enables manufacturers of processed goods to quickly define complex formulae, to accurately control production costs, to easily model discrete & process production scenarios and to switch between make or buy decisions with agility.

FORMULA MANAGEMENT

• Easily model disassembly sequences or products with multiple outputs in different batch sizes or multiples
• Effectively model batch processed products that are consumed into a discrete or lean assembly or model discrete or lean sub-assemblies consumed into multiple output products
• Flexibly consume or produce products in dual units of measure with constant or varying consumption
• Dynamically calculate ingredient consumption even for items consumed non-linearly in single or dual units of measure
• Maintain with ease many formulae for producing same product by using different material combinations or for producing different products using same combinations
• Setup, measure & improve production yields by having the flexibility to define yield for several different combinations and comparing it to the production results
• Quickly scale some or all ingredients in the formulae based on available inputs to estimate outputs
• Reduce inventory & purchasing costs by defining several alternate ingredients and consumption priority for each on the formula
• Easily toggle security restrictions on formulae access by activating any of the four built-in security levels
• Control packaging material costs by setting up configurable products as different packaged products and linking them to processed products

PRODUCTION MANAGEMENT

• Reduce waste by using production policies to ensure right formula for production is automatically selected based on a given tank size and other factors
• Link multiple packed productions to multiple bulk productions. Consolidate them to improve operational efficiency, minimize bulk storage and optimize packed product production
• Quickly add, remove or alter number, type or amount of multiple outputs
• Improve profitability for each of the multiple outputs in a production by accurate allocation of costs over them before, during or after production & revalue goods by comparing actual with estimated costs
• Always produce to customer specifications by ensuring discretionary picking of ingredients based on certain attributes
• Rapidly react to a change in production conditions based on results of automatically created quality orders
• Consume ingredients and produce multiple outputs in dual units of measure and record nominal or actual values in such units all through the process
• Achieve real time visibility on plant floor and at higher levels by re-sequencing jobs based on actual capacity on the floor and by recording production output on such jobs in dual units of measure and for multiple outputs

SKU2 - Process manufacturing logistics

Process manufacturing logistics for Microsoft Dynamics^® AX 2012 enables distributors of processed goods to forecast and plan supply & demand and to manage procurement & sales in dual units of measure natural or consumer packaged products with short or long shelf life while meeting strict quality standards, complying with regulatory requirements & providing visibility into profitability for the distributor.

DUAL UNITS OF MEASURE MANAGEMENT (CATCH WEIGHT)

• Easily create & release products with dual units of measure to multiple legal entities
• Seamlessly manage products with dual units of measure through forecasting, planning and production and be able to define & view such products on forecasts, planned orders, demand & supply views, and on production and consolidated orders
• Manage flexibly single and dual unit of measure products on purchase requisitions, purchase agreements and release order lines together with stocked and non-stocked products
• Manage flexibly single and dual unit of measure products on sales quotations, sales agreements, release order lines and delivery schedules together with stocked and non-stocked products
• Improve product yield and operational efficiency by recording actual values in both units of measure at every stage of the process

LOT MANAGEMENT

• Enhance backward traceability and reduce time required for recall by integrating information about vendor batches for purchased lots into manufactured lots of semi-finished or finished products
• Improve profitability by differentiating product based on specific product characteristics per lot & only shipping lots that meet certain company or customer criteria
• Reduce costs of rework by arresting the progress at any stage for any process, of a poor quality lot through various supply chain processes
• Enhance lot control with the ability to record and recall as needed, characteristics of an inventory lot as procured, produced or as sold
• Measure quality of each lot with or without dual units of measure for single or multiple production outputs at any stage of processing and attach such results to the inventory lot
• Increase customer satisfaction and reduce cost of rework by meeting all demand of a particular customer from the same lot if so desired
• Enhance operational efficiency and order promising by having the ability to instantly search all inventory and find lots with specific characteristics
• Improve inventory visibility by having access to all the inventory lots and associated functions in one unified view

SHELF LIFE MANAGEMENT

• Manage plan, procure and sales processes for fresh, frozen or long shelf life products based on expiry period or best before period
• Improve warehousing efficiency by earmarking locations based on product shelf life and issuing goods only as per process or customer requirements
• Reduce waste by using the ability to retest shelf life products reaching the end of their shelf life
• Improve order promising & reduce stockouts by incorporating shelf life information into planning processes and planning views
• Differentiate service and increase profitability by incorporating residual shelf life demanded by customer at ship-to location

WAREHOUSE MANAGEMENT

• Manage full or partial visibility dual units of measure based products through all inbound and outbound warehouse processes
• Increase warehouse efficiency by using the ability to mix products in same shipment that are constrained by varying levels of additional requirements like ship from single lot, based on specific characteristics, shelf life and dual units of measure

REGULATORY COMPLIANCE MANAGEMENT

• Receive, store and send product safety data sheets for hazardous products as needed
• Keep product safety data sheets current with the company and customers
• Comply with local regulatory agencies by restricting or regulating the sale of certain products in certain regions
• Record necessary compliance related product data for various regulatory agencies
• Record usage data for all products and use available third party integrated service to calculate usage of regulated substances for yearly reporting
• Manage quality and compliance by ensuring that certain products can only be supplied by approved vendors

REBATES MANAGEMENT

• Improve profitability by managing different rebate & trade merchandising programs for different customer segments
• Monitor and manage rebates processed either at invoicing or accumulated by user defined periods. Rebates can be setup by different currencies, units of measure or by differing qualifying levels and can be paid to customers by several different methods

COMMODITY PRICING MANAGEMENT

• Effectively react to changing commodity costs so the prices of sellable goods always stay current with the market
• Manage sellable product prices such that trade agreements are always up to date and new contracts reflect the price change

You can find more detail about how to use process manufacturing capabilities in the product on technet

Let me provide some context behind the decision to introduce step consumption capability in Process Manufacturing  Dynamics AX2012.
Discrete manufacturing almost always involves linear consumption of ingredients - four tires are required to put together a car. Whereas in process manufactured products consumption can be linear and it can also be non-linear. As the home brewers know 5 Kg of malt gives 12 litres of beer and 10 Kg of malt gives 24 litres of beer but the bitterness is more in smaller lot, so if you want to keep same bitterness in bigger lots you need to add some extra malt, how much extra is non-linear - based on experience. Another industrial example will be use of carbon as a catalyst in plasticizer manufacturing. You can use 1 Kg of carbon to make up to 5 kiloliters of phthalates. Then you need 2 Kg of carbon up to 8 Kilo litres of phthalate (of course, it’s a different matter that phthalates are banned in many regions for some products, so you shouldn’t really be making them).

Many such reactions have non-linear consumption across different industries but sometimes it's not essential to capture them in an ERP and at other times it is possible but cost intensive to capture and maintain the formulae. This is where step consumption comes useful. Setting up Bills of material is fairly straightforward when compared to setting up formulae. It isn't because  formulae setup in AX is not user friendly, it's just because the number of parameters required to setup a formulae are many more. In order to setup formulae with non-linear consumption in previous versions, the only possibility will be to setup many different formulae where every detail is same except the quantity of the ingredient that is consumed non-linearly. Since this would be extremely cumbersome in itself and furthermore because process manufacturers needed multiple set of versions - master formula, production formula,  distributed formula, batch card formula and so on, we decided to introduce the concept of step consumption into AX2012.

So for the non-linear consumption of malt, you will create two lines in the formula for malt product. On one line you will setup linear consumption, 5 kg for 12 litre, 10 kg for 24 litres and so on. On the second line you can change the formula to "STEP" on the setup tab. This will make the step consumption grid available. Here you can specify that an extra 0.1 kg of malt is needed when finished beer quantity is between 12 and 24 litres and an extra 0.15 kg of malt is needed when finished beer quantity is more than 24 litres and so on. So, this gives you flexibility to setup non-linear consumption in the same formula.

During production estimation system will look at the finished quantity of beer you want to manufacture and will automatically calculate the correct quantity of malt needed. In case of carbon example above, it can be achieved by using just one line on the formula lines for carbon where you can setup step consumption of carbon of 1 kg up to 5 KL and then of 2 kg between 5 - 8 KL and so on.

Hopefully this will be useful for your scenarios. In case you have suggestions for improvement please email me.

I am writing this post to expose one of the new capabilities that for various reasons has not received the attention it deserves. This is the new on-hand inventory list page for batches. This is a really cool one stop shop for Karl, materials manager or for Sammy, John and other personas who need to know the details of inventory. Using this list page will do wonders for the productivity of these scenarios.

We have put together most of the capabilities tied to inventory batches on this one list page. In previous versions, this capability did not exist and users had to go through different places in the menus to perform different actions. This consumed extra time and clicks, was difficult to learn and operate.

Below you will find a quick summary of what inventory batch related information is available and what actions can be performed from this list page.

In the grid

All inventory batches will display in this grid. You can use standard filter capabilities to narrow down the list to specific products, sites, warehouses as you desire.

On the ribbon

• On Batch tracking button group, you can

1. Trace the batch
2. Change the batch attributes
3. Change the vendor batch details
4. Look up and change the shelf life information

• On Inspect button group, you can

1. Check the connected quality orders
2. Check the connected non conformances
3. See where and how the batch is blocked or create a blocking transaction
4. Change the disposition status to block/unblock the batch

• On View button group, you can

1. Check the multi dimension on-hand if containers have been setup
2. Check the consolidated on-hand if containerization has been setup
3. Check the intercompany on-hand if the batch participates in intercompany transaction
4. Check all inventory transactions related to a particular batch

In the fact boxes

There are five fact boxes

1. In the first box, you can quickly see totals of on-hand inventory data that is not shown by default in the grid
2. In the second box, you can quickly see totals of on-hand inventory data for a catch weight product
3. In the third box, you can quickly see totals of physical inventory data that is not shown by default in the grid
4. In the fourth box, you can quickly see totals of cost of the batch
5. In the third box, you can quickly see totals of physical inventory data of the catch weight product

Availability of this data in fact boxes saves the user from opening up multiple forms to preview this information. The calculation results shown in the fact box are dynamic - so these are summarized or detailed depending on the inventory dimensions chosen on the list page.

In the preview pane

Here again main goal for us has been to save the user from opening multiple forms. So as user browses through inventory batch records, disposition history, shelf life information and vendor batch detail information is made easily available for preview in this pane.

If you have suggestions to further improve this capability, please email me.

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.

In previous versions it was not possible to collect data on shop floor for process manufactured products. Many customers use both process and discrete manufacturing capabilities in Dynamics AX in their environments regardless of whether they are generally dealing with process manufactured products or with assembled products. Therefore in AX2012 it was made possible to do data collection on products that were manufactured using formulae and batch orders. This post describes the context in which some decisions were made and also lists a number of enhancements to process manufacturing in AX2012 that make this possible.

Synchronous updates
Manufacturing execution in AX2012 is changed so that progress updates made on job registration are instantly updated in the production module. It is now possible to track the production progress within production module by viewing jobs and quantity form from production orders as soon as the progress entry is made. This is also extended to batch orders.

Job registration form
On the job registration form it is now possible to see operations or jobs depending on whether operation or job scheduling was run on batch orders. The setup required for this is described in the documentation here.
Since batch orders can produce multiple outputs, it is now possible to see these multiple outputs by shop floor worker on their terminal. This is made possible by allowing access to co-by products form from job registration form. It is possible to configure job registration form so the co-by products button appears here. Setup of action pane that is needed to set this up is described here.
It is now made possible to set up the action pane on job registration form so that linked quality orders to the batch order in progress can be seen from within the job registration form. This capability enables either shop floor worker or supervisor to easily access and see the status of quality orders for the batch order on which they are still recording progress. 
It is now made possible to set up the action pane on job registration form so that linked non-conformances to the batch order in progress can be seen from within the job registration form. This capability enables either shop floor worker or supervisor see the associated non-conformances

Production status list page
This page is intended as an overview for shop floor supervisor. In previous versions it was not possible to see batch order jobs on this page.

In process manufacturing AX2012 it is possible to do the following.

1. View the batch order jobs, 
2. View the formula connected to the batch order for which jobs are being displayed 
3. View the non-conformances connected to the jobs being displayed
4. View the consolidated orders form, this form will show consolidated orders, bulk or pack orders that are related to the batch order that is currently in focus on production jobs list page
5. "Cancel finished report" button will cancel the quantity reported as finished against the batch order, just like in the case of production order

Report as finish
In AX2012 it is possible to report as finish multiple outputs through manufacturing execution. This is achieved by simply making it mandatory for the user to open up report as finish form while reporting quantity as finish. The report as finish form that opens up is standard form that is used for reporting against a batch order. So, all the capability of adding co-by products and reporting against already available multiple co-by products is possible just like through the production module.

Edit job lists form
This is a new form in AX2012 where it is possible to re-prioritize individual jobs. This allows greater flexibility on shop floor. None of the changes are synchronized with master planning and scheduling. Based on our research users wanted some capability to do this without the changes going through master planning and scheduling.  Shop floor supervisors often change the resources or get asked to prioritize certain jobs and there wasn’t a way to capture such changes without running master planning. Running MRP is huge overhead, not in control of a single supervisor since it impacts larger site/organization and usually decisions of such an immediate timeframe should not be run through master planning. Therefore, this capability was added in AX2012 in Manufacturing execution module. This job prioritization can be done for individual jobs or multiple jobs. Jobs can be moved from one position to another in the queue. Resources allocated for a job can be also manually changed here if the allocated resource is not available for a short period for whatever reason. This capability is now also available for jobs originating from batch orders.

Inventory Picking
While picking for a batch order from manufacturing execution module, AX2012 ensures that picking is done in FEFO order is this is setup for the item being picked

Catch weight and production module
A number of new fields have been added to many forms. All forms that are used to process products and those that are used to show progress of products through shop floor have new fields to handle products that have dual unit of measure defined.

Forms that have been modified

1. Production journals
2. Route jobs form
3. Route form
4. Materials form

Grid setup for catch weight products
CW started quantity, CW start quantity and CW requested quantity are three new fields that can now be setup on the grid in the job registration form.

Catch weight and manufacturing execution module
Catch weight fields are now available on several forms so that products with dual unit of measure defined can be processed using the manufacturing execution module.

Forms that have been modified are:

1. Edit jobs list form
2. Change feedback form
3. Raw registrations form
4. Posted registrations form
5. Quantity reports form
6. Approve form

Hopefully this post introduces you to the changes made to allow shop floor workers to record progress against products that are being manufactured using batch orders and formulae.

Master scheduling has to deal with an increasing number of transactions, especially if a company goes through  a lean transformation. The lean transformation leads to shorter lead times and smaller batch-sizes. Having reached the ideal of batch size one may suddenly increase the number of transactions that master scheduling deals with by factor 10 to 100.

This is especially true if your configuration is set for your operative scheduling - usually covering few weeks, or in the lean ideal a few days. But if you use the same configuration to calculate your tactical plan, that usually spans over a couple of month up to a year, the volume of transactions can be considerable. At a customer review we found more than 7000 planned transactions for a category C part - a part that should be planned on minimum stock level instead.

In a meeting I had with the planning team of the customer, it became transparent, that one of the challenges is to configure the lead times as well as the positive and negative days for master scheduling. You need to start with analyzing how demand patterns of different products and materials behave. Unfortunately, the formula "longer is better" does not apply here. Having 200 planned purchase orders in the future for an item that has a purchase lead time of only few days is - in lean terms - waste.

To limit the runtime of master scheduling on one hand and the number planned orders and action messages on the other side, It is recommended to work with 2 different plans:

• An operational plan, that uses fences and other parameters from the coverage groups and item coverage, not overwritten by the plan itself. The operational plan is updated every night.

• A tactical plan that overwrites the planning and coverage fences to a longer horizon to make a full explosion in all details. The tactical plan is re-calculated once a week, usually on the weekend. Firming of planned orders should usually not   be done based on the tactical plan.

 It is recommended to structure the coverage groups by demand patterns and use item coverage only to punctually override settings for products, that require special treatment or to evaluate modified behavior.

 Negative / Positive days:

•  Positive days:
  Positive days allows master scheduling to use a planned receipt to cover a specific demand, that lies n days before the demand. In other words, it allows master scheduling to plan for excess inventory to minimize the number of planned orders. To consider actual on-hand for any demand, the positive days have to be at least as long as the coverage fence. This is valid for low turning products or products that are covered by high security stocks. For quick turning products that have a regular replenishment or receipt per day, week or month  (EPEI = n days) should use positive days that are close to the EPEI. Another way of expressing this: positive days should not be more than MAX 2 times inventory  turnover rate.

• Negative days:
  Negative days allows master scheduling to use a planned receipt to cover a specific demand, that  lies n days AFTER the demand. It basically allows Master scheduling to plan for being late. It is important to understand that in a supply  chain this setting can cumulate for every planning step with the end result of allowing to be late on almost every planned order. Negative days are needed when the inventory or purchase lead times are longer than the corresponding Sales lead times, to avoid multiple creation of planned orders for the case where a new demand that cannot be covered is placed earlier than the new planned order will be scheduled.

• In AX 2012, the new possibility of Dynamic negative days have been introduced.
  Negative days can be hard to set, as lead time can be different for products assigned to the same coverage group. That is where Dynamic negative days should be used (found under master planning/ setup / master planning parameters). Once dynamic negative days is set, the lead time defined on released product (default order settings, site specific or item coverage) will always be the minimum negative date counted from today. If a demand is calculated in the future, then  negative days will be equal to number negative days set on the coverage group.
  This feature is a significant change in defining negative days, and should be much easier to define. When calculating with dynamic negative days, the negative days settings should now be 0-5 days - depending on the demand pattern of the related product, and not as earlier recommended = lead time. The usage of dynamic negative days will decrease actions and futures. + all issues that are within lead time will always see receipts within lead time. Especially useful for long lead time items, where periodic or min max is used as requirement policy.

For the improvement of the settings of the operational plan the following guidance should be considered:

• The coverage fence of  purchased material should not be longer than double the lead time of the material, ideally only 2-3 weeks longer than the purchase lead time. The operational plan should only contain planned purchase orders that are needed to take action by the planner, not the tactical forecast. If a planner needs a longer term view he can consult the tactical plan. For purchase products the positive days should be mostly equal to the coverage fence. Purchase
  material should not have negative days = the purchase lead time or even better, use Dynamic negative days. Then purchase material should run with 0 negative days.

• Planned transfers that are used for replenishment and internal logistics between warehouses should not have negative days. The positive days should also be very small, ideally 0 to create the planned transfers at the point in time that the     transfers are really needed.

• Finished goods should only have negative days, if the sales lead times are smaller than the corresponding inventory lead times (or for finished goods that are directly purchased, the corresponding purchase lead time). The negative days would then be the delta between sales lead time (first possible new demand) and the inventory or purchase lead time (first possible new supply). And again, the alternative is to use the Dynamic negative days principle, where again the negative days are calculated automatically based on the lead times.

Master scheduling with Microsoft Dynamics AX is truly a dynamic task. There are many ways of influencing the  planning results and the performance of master scheduling by modifying the right parameters. The resulting plan can only be as good as the configuration allows - and of course, dependent on the quality of the actual and the forecasted demand. We would love to hear about your experiences and your best practices related to positive and negative days and Dynamic negative days. We are also interested in your experiences with multi-plan strategies.

Meet the Microsoft Dynamics AX manufacturing team at the AXUG Summit next week or at Microsoft Dynamics AX Technical conference 2012 in the manufacturing focus room.

In this blog I’ll explain the concept of table constraints as it is implemented in Constraint-based product configuration in Microsoft Dynamics AX 2012.

Definition

A table constraint lets you specify the valid combinations of attribute values that can be assigned when configuring a product configuration model. The structure of a table constraint consists of one or more columns and one or more rows. Each column is assigned to an attribute type that specifies the attribute values that can be combined in the rows. Each row defines a valid combination of the attribute values for the attribute type.

Constraint based product configuration for Microsoft Dynamics AX 2012 supports two types of table constraints:

• User-defined – You can manually specify the combinations of attribute values that are valid for the product configuration model.
• System-defined - You can specify the table or view in the Application Object Tree (AOT) that will define the combinations of attribute values that are valid for the product configuration model.

Example

The following example shows a table constraint that could be used for a television. The table constraint is described as an expression and as a table. The expression describes the attribute types and values for Color, Size, and IsLCD. The table constraint contains three columns with the valid combinations of the attribute values for each attribute type.

Attributes types and values written as an expression

IsLCD : { True, False }      

Color : { "Red", "Green", "Blue", "Black" }     

Size : [ 42 .. 55 ]   

Table constraint

The Color, Size and IsLCD attribute types serve as the column headings in the table constraint definition. The rows specify the valid combinations of attribute values.

Column_Color = Color

Column_Size = Size

Column_IsLCD = IsLCD

Written as a Boolean expression, the table would look as follows: 

(Color == “Red” And Size == 42 And IsLCD == True )

Or

(Color == “Red” And Size == 55 And IsLCD == True )

Or

(Color == “Green” And Size == 42 And IsLCD == True )

Or

(Color == “Blue” And Size == 55 And IsLCD == False )

There are some important things to note about the attribute types that are used in the example:

• Color:  This attribute type includes the attribute value “Black.” However, because Black is not specified in a row it cannot be assigned. In a case like this, consider whether the table constraint or attribute type are incorrect. The two rows for the attribute value "Red" implies that if Red is assigned then Size can either be 42 or 55. This also means that the IsLCD attribute is always True because the values for Red and IsLCD is True are not combined in a row.
• Size:  Although the attribute type is defined as an integer with an interval from 42 to 55, only the values 42 and 55 are valid attribute values because these are the only values within the interval for which a row is defined.
• IsLCD:  If False is assigned to an attribute value that is included in the IsLCD column, then only "Blue" and 55 are valid assignments for the respective attribute values that are included in the Color and Size columns.

The difference between System and User defined table constraints

Although the same rules apply to both system-defined and user-defined table constraints, there are some differences in behavior. In this section I’ll elaborate on the key differences, but focus primarily on system defined table constraints.

User defined

User defined table constraints let you manually define the combinations of attribute values that you want to allow for a product configuration model. In Figure 1, the Table fields and Allowed combinations FastTabs of the Edit table constraint form show an example how attribute types and values are combined in a user defined table constraint.

Figure 1

System defined

For system defined table constraints, you select a table or view which is defined in the AOT. You then specify the relation between the columns of the table constraint and the fields that are included in the table or view in the AOT. This table or view provides the value combinations for the table constraint. You can also add a filter on the AOT table or view by adding a database query that selects rows by adding ranges to query.

One important thing to know about system defined table constraint is that at runtime the system changes the type definition of any attribute that is associated with a column. For example, the value for an enumerated text attribute will be replaced with the set of distinct values for the column in the AOT table. For an integer-based attribute, the ranges will be replaced with the maximum and minimum values for the column.

Figure 2

Example

The InventTable table in Microsoft Dynamics AX 2012 contains the following data in the AltItemId and BOMLevel fields.

In order to use the InventTable as the source of a system defined table constraint for a component in a product configuration model, the following must be set up:

• Two attribute types, one of the type Text and another of the type Integer. The Text attribute type must have at least one value. The Integer attribute type must have a value range.
• A table constraint definition, as illustrated in Figure 2. The table constraint that will reference the definition must be created for a component. The component must have attributes that match the attribute types that are referenced by the columns of the table constraint definition.

For a component that uses a system defined table constraint, the system replaces the following values:

• For the attribute type of the attribute that is matched to the AltItemId column, the values are replaced with { “LCD_42”, “Plasma_55”, “LCD_55” }.
• For the attribute type of the attribute that is matched to the BOMLevel, the range is replaced with [ 1 .. 7 ].

The ultimate lean goal – the single piece flow with zero inventories – is not an illusion. Many industries have been able to replace build to stock/supermarket by assemble to order scenarios that support single piece flow. Lean manufacturing for AX 2012 provides a powerful new instrument to support these scenarios: Kanban production and replenishment based on Events.

The best implementations of Lean manufacturing I have seen so far are mostly driven by a common pain: The explosion of item variants – for the most different reasons – makes it impossible to hold inventory on final product level, without running into a huge risk of holding excess inventory or even worse – constantly depreciating or expensing products that have been hold in the final product stock but cannot be sold based on material expiry or engineering changes.

The need to remove or at least reduce this huge waste of money and resources usually leads to the cleanest implementations of lean manufacturing. Final assembly, packaging and shipping activities are streamlined and aligned to the targeted sales lead time – shipping the product out of final assembly within a very short lead time, usually days or few weeks (ideally 1). Some industries – like JIS (just in sequence) in Automotive – reach lead times of 2.5 hours from call-off to shipment for an assembly process!!

No need to explain that this requirement lies beyond Master scheduling – even if some implementations of Microsoft Dynamics run a net-change on master scheduling in a frequency of 30 minutes.

The new Lean manufacturing framework of Microsoft Dynamics AX 2012 allows definition of kanban rules with the replenishment strategy Event. The creation of event kanbans based on this strategy is triggered by a source requirement and the new kanban is pegged to the source requirement.

The event kanbans replace the previously released modules of LOS-BTO Schedules (Lean order schedules – Build to order) and PTO Kanbans (Pull to order)  that were part of Lean manufacturing for Microsoft Dynamics AX 2009 with a single
architecture.

The sales event

The sales event is triggered by the creation or a change of a sales line – no matter if this is happening manually, through enterprise portal or using the sales creation services of Microsoft Dynamics AX.

Each sales line creates one or multiple kanbans to fulfil the related demand, based on the maximum product quantity defined in the kanban rule that corresponds to the maximum handling unit size.

The kanban cards printed for sales event kanbans contain customer and customer order references and can be used as shipment labels for the handling units.

The kanban line event

Kanban line events can be created to pull from a pre-processing activity. In the following example a lean work cell assembles painted parts (B) to finished products (A). The kanbans for A can be of any replenishment strategy – fixed, scheduled or event. While all standard colours – red, green or blue – are picked from a supermarket that is replenished as fixed quantity kanban, the special colours – gold and silver – create event kanbans.

Another application of kanban line events is transfer of material to a production location. In the following example we are assuming that products are produced on two sites 1 and 2, the related components are produced on site 1 and stored in a supermarket. While process B on Site 1 can directly pick from the supermarket, the material for process B on site 2 needs to be transferred to site 2.

By defining a kanban line event withdrawal rule for the transfer from site 1 to site 2 for the item relation All, transfer kanbans are created for all BOM-lines of items in Process B on Site 2. The related kanban transfer jobs can be grouped to consolidated shipments with non kanban material that needs to be transferred to Site 2.

The BOM line event

Like kanban lines, where the picking or transfer issues of a kanban trigger other kanbans, a production order can consume material that is supplied by lean manufacturing. Again, this can happen by picking from a supermarket or by creation of a BOM line event kanban, that pulls material to the production order.

On estimation of the production orders for the final assembly, the BOM Line event kanbans are created and loaded on the Pre-Assembly work cell.

The kanban rule can enforce a consistent reservation, to ensure that the components supplied by event kanbans are automatically reserved for the source of demand, in this case a production order.

Pegging event processing

In different application scenarios the volume of kanbans that are created based on events can be in a range of few event kanbans per day – where event kanbans only cover exceptions – to multiple kanbans per minute. To find the right balance between actual requirement view in the work cells and performance load each event definition on a kanban rule defines the kanban creation policy:

• Automatic
  
  The event kanbans are created with the source of demand. On the creation of
  sales order lines the correspondent event kanbans are directly created,
  allowing the work cell or warehouse to take immediate action on the new demand.
  This setting is recommended to be used, when execution is expected to happen on
  the same day.

• Batch
  
  Instead of the event kanbans a pegging requirement is created. A recurring
  batch process that is independent of master scheduling is processing all new
  pegging requirements. This light-weight process can be set up in the background
  specific to selected production flows or activities ensuring an appropriate
  reaction time for every application scenario.

• Manual
  
  When event processing is a pure exception taken on priority and capacity
  considerations, an sales order line or a kanban can be manually selected to
  create event kanbans.

The minimum stock event

When running master scheduling in Microsoft Dynamics AX, additional planned orders are created whenever minimum on-hand is reached. For a lean manufacturing application that surveys minimum on-hand of important parts, this might easily lead to a delay of a day until the signal for replenishment reaches the replenishing work cell. The pegging event processing in Lean manufacturing for AX 2012 checks minimum inventory for selected kanban rules and creates the needed kanbans to replenish instantly.

Lean manufacturing without event driven scenarios is only half the story. Lean manufacturing for Microsoft Dynamics AX 2012 provides a complete suite of tools to model any pull based scenario and scale the processes on volume and frequency of demand. The time effective nature of the kanban rules that model the scenarios support continuous modification and improvement. The bad news is: you can no longer use Microsoft Dynamics AX as the reason why you are not going Lean – it is all up to you now.

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.

In Microsoft Dynamics AX 2012 R2 we introduce the batch balancing and attribute based pricing features that are used with potency management. Batch balancing feature enables you to modify a production formula by selecting the inventory batches of the active ingredients based on their current potency. Attribute based pricing is applied to the pricing of a potency item.

As the potency of an active ingredient can differ per batch, the quantities of active, compensating, and filler ingredients for a batch order need to be balanced to accommodate the amount of material that is required for production. This also means that after a batch order is created for a formula that includes an active ingredient, the picking list journal cannot be automatically created and posted. The batches of inventory that are selected for the required active ingredient must be picked before the batch order can proceed. This is performed by using the batch balancing function of the batch order. After inventory is reserved for the active ingredients, the balanced quantity for the compensating ingredients can be calculated. To determine the balanced quantity of the compensating ingredient, the following formula is used:

These calculations are part of the batch balancing function in Microsoft Dynamics AX 2012 R2 .

Attribute based pricing is applied to the pricing of a potency item which is an item that has a concentration of an active ingredient. This potency, or concentration, of active ingredient can be used to affect the amount of material that is required in production or the amount that is paid to a vendor based on the concentration level.

To calculate batch attribute pricing, take the purchase price and divide it by the batch attribute target to get a price per unit at 100% concentration. Then multiply by the batch attribute actual value. For example, a potency item has a price of $55.00 per lb. at a standard/target potency of 40%. If a batch of inventory of this item is received, and it is determined to have an actual potency of 46%, the price per lb. is (($55.00/40) * 46) $63.25. This is a higher price than the standard price that is paid for this material, because the active ingredient concentration of the material is higher and therefore, you use less than the normal quantity in production.

Process industries often produce items for which certain characteristics, or attributes, of the ingredients need to be transferred or inherited to the manufactured items. These manufactured items may be finished goods and/or co-products. In many cases, only certain characteristics need to be inherited since these characteristics may become diluted when mixed with other ingredients. In some cases, the characteristic may represent an important attribute that needs to be tracked to the end items due to regulatory or other reasons.

Lot Inheritance enables users to configure items in a manner in which the product characteristics and shelf life information of the finished products can be updated by using the ingredients of the formula that is used to produce that item. For shelf life information, this enables users to define items so that the inventory batch that has the earliest shelf life dates updates the finished products, and the shelf life dates of the finished products are inherited from the inventory batch. For product characteristics, this enables users to define batch attributes for both the finished items and their ingredients, and then select the ingredients that pass their characteristics or attribute values to the finished good items. Users can also select to update co-products by using the same information for shelf life and product characteristics on a formula-by-formula basis.

Many process industries are faced with a need to sequence the production of their products by using multiple levels of complexity. Production is sequenced based on a particular criteria that is assigned the highest priority. Production within that sequence is then further sequenced based on additional criteria that are assigned appropriate priorities. For example, a paint facility is configured so that production is first sorted by color and then by package size. This enables the cleanup time between colors to be reduced. However, there is a change to the packaging line equipment. Then the container configuration has a higher priority than the cleanup time that is required for color changes.

The batch order sequencing feature enables a production planner to sequence products on a bottleneck resource in the production facility. You can define sequences and sequence groups. The sequences can be characteristics of items that are used to identify how to sequence the items in production. Sequence groups define how certain sequences are prioritized. You can assign sequences to items and assign sequence groups to bottleneck resources. When you apply a sequencing principle to the MRP, the expected results are calculated.

Understanding why software acts like it does can be an overwhelming task. There can be discrepancies between what we expect a program to do and what it actually does. The more complex a program is the more likely we are to experience these discrepancies.

Master planning (MRP) in Microsoft Dynamics AX is a prime example. Because it’s designed with a huge set of parameters that provide the flexibility required to fit a wide variety of businesses, configuring MRP is a complex task. And, historically speaking, the lack of transparency has made it difficult to analyze and understand the results of an MRP run by looking at its configuration. To provide this transparency, tracing and event logging functionality that gives a planner better insight into an MRP run has been added to Microsoft Dynamics AX 2012 R2.

Enabling MRP Logging and Tracing

The new logging and tracing features in MRP come in two flavors: One is purely a UI centered experience. The other ties in to the existing facilities for tracing and logging, and uses the Event Tracing for Windows (ETW) with the normal Microsoft Dynamics AX tracing providers.

Tracing/Logging in the UI

The UI centered experience is a powerful, light-weight tool that a planner can use to find out why certain choices were made during an MRP run, and to validate changes in an MRP configuration. A planner can quickly view the impact of a change when the dynamic master plan is updated. The Explanation tree view uses familiar UI elements, which makes it easier to use. In Figure 1 below, the requirement calculation is set to update an explosion for a production order (note that the Explanation tree view is available only for explosions). The setup for this requires only that the Enable trace check box is selected.

Figure 1

When the explosion is complete, information about the MRP run is displayed in the Explanation tab on the Explosion form. Figure 2 provides an example of what the explanation looks like.

Figure 2

A couple of things in Figure 2 are worth noting. First, the tree structure denotes the hierarchical nature of MRP. As can be seen from the tree, in producing the speaker enclosure (level 1), an issue is generated for which a receipt is sought. As none is found, a planned order is created (level 2). All of the details for the new planned order are listed and indented below the event – in this case the creation of a planned order. Additionally, the issue is pegged to the planned order, and at level 2 the initial futures date is set.

Another cool thing about the explanation is that you can perform a free text search. In Figure 2, for example, you could search for any lines that contain the word “delay.” If there are any hits, the text for the line is displayed in bold font. You can navigate between multiple hits by using the Up and Down arrows that are next to the Find text field.

Tracing/Logging of MRP Runs using Event Tracing for Windows (ETW)

While the tracing and logging experience in the UI is targeted towards the planner, the tracing and logging that uses ETW is geared more toward offline diagnostics scenarios. Using the offline capabilities requires the steps that are described in this section. Also, whereas the Explanation tree view is available only for explosions that are started manually to update the dynamic master plan, the ETW tracing is also available for generating full master plans.

First you must set up a data collector set by using the Performance Monitor utility. The steps to do this are as follows:

1. Open Performance Monitor.
2. Right click the User Defined node in the tree view, point to New, and select Data Collector Set.
3. Give the collector a meaningful name, like Dynamics AX MRP Trace.
4. Select the Create manually (Advanced) option, and click Next.
5. On the next step of the wizard, verify that the Create data logs radio button is selected, and then select the Event trace data check box. Click Next.
   Note To avoid generating a lot of data that is not related to MRP tracing, you may want to clear the other check boxes.
6. You must now select the data providers. Do this by clicking the Add button.
7. In the dialog that appears, select Microsoft-DynamicsAX-Tracing, and then click OK.
8. After the provider is added, the Properties field displays properties related to the provider. In the list, select Keywords(Any), and then click Edit. On the list of properties that comes up, select MRP. Click OK to exit the Property dialog. In the wizard, click Next.
   
   
   Figure 3
   
9. On the next step of the wizard, specify where you want to store the tracing data, and then click Next.
10. On the final step of the wizard you can either change some selections or click Finish to accept the defaults.

You can verify that ETW has started collecting the tracing data by clicking the new collector set (in the example, it’s “Dynamics AX MRP Trace”) and then looking at the icons on the toolbar.

Let’s take this functionality out for a spin by doing the explosion again. The same information that was displayed in the UI in the example is now available to a multitude of tools via the data collector. For instance, you can use Event Viewer to open the log file that the data collector creates, and you can export the data to Excel or to a database for further analysis. Let’s look at an example of what the data looks like in the Event Viewer.

To view the data, start Event Viewer. Right-click Saved Logs, select Open Saved Log and navigate to the location where you store the log data. The file should be called DataCollector01 or something similar, depending on how many data collector sets you defined. After selecting the data collector, you’ll be prompted to decide where the log data is to be displayed in the Event Viewer tree – I usually just select the default.

Since the collector we defined is collecting all data related to MRP, there will be a lot of events logged. In my particular case, the number of events is around 9,500. Fortunately, you can filter by clicking the Filter Current Log in the Actions pane on the right hand side of the Event Viewer. In this context, the two events of interest are:

• 107 (This will be referred to as ReqExplanation)
• 108 (This will be referred to as ReqExplanationDetail)

You can specify multiple events in the filter dialog by separating them with commas. Using the filter to limit the number of events in the view leaves around 650 events from my MRP run.

The first of the event types, ReqExplanation, is shown below in Figure 4 below.

Figure 4

The following table describes a couple of interesting pieces of information that the event log gathered during the MRP run.

The second type of events logged, a ReqExplanationDetail, is shown below in Figure 5.

Figure 5

 Looking at Figure 4 and Figure 5, one major difference between the Explanation tree view and the ETW stands out. While the Explanation tree view graphically shows the BOM levels that were considered during the MRP run, that cannot be done graphically if you use ETW. To doing this by using the data from the ETW, you’ll have to examine the sequence and BOM Level fields in the data. Also, a detail event (108) is tied to its parent by the Parent Event ID field (incidentally, the two examples shown here are parent/child as the Parent Event ID of the ReqExplanationDetail (shown in Figure 5) matches the Event ID of the ReqExplanation (shown in Figure 4).

So, What’s the Cost?

Obviously, cool features like this are not entirely free of charge. We have, however, done our utmost to limit the impact that this will have. First, the Explanation tree view is totally independent of the ETW logging. That is, you can have ETW logging for explosions and full master plans without enabling the Explanation tree view. Conversely, you can enable the Explanation tree view without having the ETW logging enabled.

Because of the nature of the two independent logging and tracing methods, we check in a couple of ways to ensure that we don’t spend cycles doing unnecessary work. For instance, since the ETW tracing is governed solely by enabling a data collector and the MRP keyword, before we do an explosion or master plan generation we check whether the required ETW setup steps have been completed. Based on this check, we minimize the impact during the explosion or when the master plan is generated.

This is simpler for the Explanation tree view: If you don’t enable tracing when you start an explosion, we keep that in mind when doing the explosion and thereby minimize the impact of the feature.

If you do decide to enable the ETW logging for a full master plan generation, there will be some cost related to generating the necessary messages to log. Despite the fact that the ETW was designed with huge volumes of events in mind, you should expect to see some degradation of performance. This, however, we think is acceptable as the feature is a diagnostics feature, and not meant to be switched on and left on, but only switched on while the diagnosis is going on.

Wrapping up this post, I think you’ll find great value in the functionality we have added to assist you in understanding choices/decisions made by the MRP subsystem. Finding the right configuration and set of parameters for master scheduling that are exactly right for your business is difficult. With the tracing/logging, we believe we have made that task a lot easier for you.

Some of the new features in Product configurator for Microsoft Dynamics AX 2012 R2 required that changes were made to the schema for product configuration models. As a result, if you want to import a product configuration model that was exported from a previous version of Microsoft Dynamics AX, you must make sure that the schema adheres to the new structure.

This blog post describes how to transform a product configuration model that was exported to xml from Microsoft Dynamics AX 2012 so that it adheres to the new schema for Microsoft Dynamics AX 2012 R2.

Disclaimer:

This method of importing product configuration models is not supported. The below xslt file is provided as is. You should review the imported product configuration models to verify that they do not contain any issues.

Use XSL transformations to update the schema

A product configuration model is exported from Microsoft Dynamics AX 2012 as a plain xml file named model2012.xml. You can update the xml to the new schema by using XSL transformations. By running the following command from a command prompt, you can convert the XML file using the attached xslt file and the MSXSL tool.

msxsl "model2012.xml" "transform2012toR2.xslt" -o model2012R2.xml

The command simulates what would happen during a standard upgrade process, and creates new file named model2012R2.xml that has the default values for new fields. You can import this file into Microsoft Dynamics AX 2012 R2.

Many Microsoft Dynamics AX users have asked for a solution that supports kitting. To support a kitting solution, two primary components are needed:

• Configuration of a kit for the order management
• An activity that assembles the kit

Many ERP and SCM solutions support kitting as part of the Warehouse management or logistics functionality. Without having native support for kitting, Microsoft Dynamics AX 2012 offers an approach where it might not have been expected: Using to product configurator to configure kits based on a product configuration model combined with a lean process activity where the kits are built or packaged to order.

So in fact, the kits are built based on sales event kanban's, with a single kanban per kit.

It all starts with modeling the kit as a configurable product, and then creating a configuration model that represents the products that can be combined in kits, possibly also including the packaging material.  In our example we have a configurable speaker set that consists of two front and two rear speakers per kit. This is represented by a simple product configuration model.

The model structure is rather flat, and consists of the front and the rear car speaker set. The products that can be selected in each configuration step are modeled as conditional BOM lines. In our example the configuration model makes sure that while different models of speakers can be selected for the front and rear speaker pairs, all speakers - front and rear - will have the same cover color.  Because the assembly of the kit is done by a lean production flow, route operations are not
needed in the configuration of the product model.

Therefore a global attribute of Color is associated to the Car speaker set. This constrains the selection of components to the common color.

Based on the model shown above, a sales order taker can configure the kits based on the customer’s demands, or use pre-configured kits by selecting a specific configuration of the kit.

The individual configuration is done in the sales order line as shown below, by clicking Product and supply > Product model > Configure line.

The Configure line form allows the configuration of the kit to be based on the product model.

Before finishing the configuration, the sales price of the kit can be calculated based on the configuration of the new kit:

After the configuration is done, a new variant of the kit is created with a corresponding BOM version, and the sales line is updated with the new configuration and sales price.

Note that the BOM version is automatically approved and activated.

Once the configuration is final, the order taker can create the kanban that is to assemble the kit on the packaging work cell directly in the order form:

This creates one or more kanbans, depending on the number of packages that are needed, and load them on the kanban board of the packaging work cell.

In our example, Set05 with the new configuration has been added and is now ready to be picked and completed.

On the same work cell, other preconfigured kits (in our example  CSS_SS1B) and other products can also be packaged and delivered to order or to stock.

The kanban rule

The magical configuration that enables this process is the kanban rule. A kanban rule uses the activities that are configured for a production flow. Evaluating the possibilities of configuration of the production flow would go too far for this blog entry. To learn more about that, refer to the Whitepaper "Lean manufacturing for Microsoft Dynamics AX 2012 - Production flow and activities." Assume that for the kitting application, a single activity production flow, as described in the whitepaper, could apply.

In the actual case, the kanban rule is a manufacturing kanban rule with a replenishment strategy event.

The packaging activity is followed by a transfer to a vendor managed warehouse.

Some highlights of the kanban rule configuration should be emphasized in the context of our scenario. Let's start with the Product selection field in the Details FastTab of the kanban rule.

Notice that product CSS_SS_CUST is a configurable item for which the configuration dimension is mandatory. A configuration is not assigned to the kanban rule, so it is valid for all configurations of this product. In other words, any kit that is configured based on this model by using the product configurator will be supplied using this kanban rule.

The Events FastTab specifies the events that will trigger the creation of a kanban. In this case, Manual is selected in the Sales event field. The event cannot be created automatically when using the product configurator because the configuration of the line must be completed before the event kanbans are created.  The dependency to the source requirement - in our case the sales line - ensures that the sales line cannot be shipped before all kits have been assembled and received. However, in the current example, a reservation is not needed. Because every sales line will have a separate configuration it’s unlikely that the wrong kit will be reserved so the lean approach would be to not make a reservation.

The maximum quantity of a kit per kanban is 1. Every kit creates a separate kanban and receives a separate kanban card. The automatic planning quantity of 1 ensures that every
kanban is directly loaded to the schedule, so the picking and packaging can start immediately after the kanban is created from the sales order line.

Depending on the settings of the kanban rule, the kanban card can be printed automatically in two ways:

• When the kanban is created,
• When the first activity is planned for the kanban and printed on the printer that is associated to the work cell responsible for the picking activity.

The picking list can be automatically added to the kanban card as well. Instead of having to look at the kanban board first, the worker can take the kanban card directly from the printer and start the picking process. When the kit is assembled, the worker can complete the packaging activity by scanning the card ID.

Costing the Kit

In many cases, the cost of a kit is mainly driven by its components. The cost of the packaging activity can be calculated based on the activity time. To enable the full cost support for the kitting solution, the cost price needs to be calculated and activated for each configuration. However, the value of costing the kitting might be really low, especially if this process usually creates no or only low variance. On top of that, the configured kits usually don’t stay in the warehouse for very long because they are assembled to order shortly before the shipment. For this reason, it might be a good idea to configure the kit so that it has only one standard cost activated for all of its configurations. This is done by clearing the Use cost
price by variant check box in the product master.

This configuration will result in material variances because different materials are used in the kits. To avoid manual corrections, the account that is used for material variance could be redirected to the cost of goods sold. Some people might disagree with this, but from the lean perspective, if costing of the kits and the related variances are not an issue then a manual or even an automatic cost calculation and activation should be avoided.

Both Product configuration and Lean manufacturing in Microsoft Dynamics AX 2012 are powerful tools that support manufacturing and the logistics processes required in many industries. When combined, they can support many use
cases in a very flexible way. I hope this example provides insight into the capabilities and opportunities and how they can be used to empower your business.

The approach that is described in this blog might leave open a couple of requirements that a kitting process in your company might require. If that’s the case, we’d very much like to hear more about your scenarios. But without a doubt we would also like to hear from you if this matches your requirements.

A few times already I’ve been asked to investigate customer cases that went something like this:

Create a production order for some item from the standard test data.

Schedule the order (job scheduling or operation scheduling, doesn’t matter).

Expected result:
The order gets scheduled.

Actual result:
Production order ### could not be scheduled. Not enough capacity could be found.

In some cases it turned out it was a product bug. In other cases the message was perfectly valid.

The question is: how would you, as a user, know what’s happening? How would you figure out why capacity was not found?

Ideally the scheduling engine should not only return a dull message saying that it didn’t find enough capacity. It should come up with a reason or a trace or something you could analyze. And we sincerely hope that in future releases we will get to enhance the error reporting of the scheduling engine! But until then, here is a list of things you can do when you get the error:

1. Check if there are any applicable resources that satisfy the operation requirements at the production order site.

Path:
Production order list page – chose the production order that can’t be scheduled – Production details – Route – chose the operation that’s causing the failure – Applicable resources – check if you have any applicable resource on the production order site

Img 1– There are applicable resources, but none on the production site

2.  If it turns out that there are no available resources at the production order site, make sure you have resource requirements enabled for the type of scheduling you are doing: operations vs job.

Path: Production order list page – chose the production order that can’t be scheduled – Production details – Route – chose the operation that’s causing the failure – Applicable resources – toggle ‘Use requirements for’ between Job and Operation scheduling.

3.  Make sure you have calendars associated to the resources/resource groups identified as applicable and that the calendars have working times and that efficiency percentages are not 0.

Path: Production order list page – chose the production order that can’t be scheduled – Production details – Route – chose the operation that’s causing the failure – Applicable resources – for each applicable resource right click and or click
View resource – Resource form – Resource groups – make sure there is a Calendar associated with the resource.

If there is a calendar, make sure it has working times: right click on the Calendar and View details or Organization administration – Calendars – Calendars – chose the calendar – Working times and check the form is not empty or that the days don’t have Control set to Closed. Pay attention to the base calendars as well, and make sure they have working times and correct efficiencies and the days are not closed.

If the error occurs during Operations scheduling, make sure that there is a calendar on all the applicable resource groups.

In operations scheduling, the resource group’s calendar is used for determining the start and end times and dates for each operation. The resource group’s calendar puts a limit on how much time that can be operations scheduled for one specific
operation for one specific day in one specific resource group. For example, if the working time for a resource group on one specific date is between 8-16, one operation can’t put more load on the resource group than what can be fit into 8 h, no matter how much capacity that the resource group has available on that day. The available capacity can however limit the load further

4.  Due to performance reasons, the scheduling engine will only search for a resource for a certain time/number of scheduling conflicts encountered. Make sure that in Organization Administration - Setup - Scheduling - Scheduling parameters you
haven't turned on any of the scheduling parameters. If you did, try to change the values and reschedule the order.

5.  If you are doing finite scheduling, it may very well be that you really have no free capacity. To make sure this is not the case, you can either:

6.  Revert to doing infinite scheduling, by un-checking Finite capacity check box during scheduling.

7.  Check the available capacity on the resources/resource groups applicable for the operations that couldn’t be scheduled.

Path: Resources/Resource groups form, opened either by View details or from Organization administration – View – Capacity load or Capacity load, graphically and make sure there is available capacity.

8. And if none of the above worked, then you need to revert to more ‘serious’ stuff – doing scheduling engine diagnostics, by enabling logging. Here’s how you do it.

(Note: you’ll need to have extended permissions to some files and the AX database in order to perform this, so if you are a production planner, shop floor supervisor, etc you will need to contact your internal AX support person to help you)

First of all, you need to know that the scheduling engine can produce 3 logs:

1. Log that gives you the full picture of all the input data that the scheduling engine will work with when trying to figure out the schedule for the production order: list of jobs/operations that need to be scheduled, applicable resources, scheduling constrains, etc

Log file name: Program Files\Microsoft Dynamics AX\60\Server\MicrosoftDynamicsAX\Log\SchedulingDataModel_[funky_numbers_here].xml

It is pretty easy to read. Look at this log in order to determine if the correct input information is fed to the scheduling engine.

       2.  Log with all the available capacity slots that the engine receives for scheduling – we will not get into details about who is providing these slots and so on, what is important to understand is that basically these are the available resource working times, based on the calendars associated with the resources.

Log file name: Program Files\Microsoft Dynamics AX\60\Server\MicrosoftDynamicsAX\Log\SchedulingSlots_[funky_numbers_here].xml

It is also fairly easy to read. Look at this log to see if the capacity slots that are sent to the engine make sense.

     3. Log with all the capacity reservations that the scheduling engine wants to make, that should be saved in the AX database.

Log file name: Program Files\Microsoft Dynamics AX\60\Server\MicrosoftDynamicsAX\Log\SchedulingResults_[funky_numbers_here].xml

This is basically the scheduling result.

By default, the scheduling engine does no logging at all, so none of the above files will be created. So how do you enable these logs? You go to Program Files\Microsoft Dynamics AX\60\Server\MicrosoftDynamicsAX\bin, open SchedulingEngine.config and set:

UseXmlOutput = true, in order to generate SchedulingDataModel_[funky_numbers].xml

UseSlotsXmlOutput = true, in order to generate SchedulingSlots_[funky_numbers].xml

LogResults = true, in order to generate LogResults_[funky_numbers].xml

Don’t bother with LoggerEnabled and LogVerboseEnabled - they are there just for historical reasons and are, in fact, never used. LogToTextFile will be explained later.

Don’t bother to stop/restart the AOS – no need for that in order to enable logging.

Now, as soon as you schedule your production order again, you’ll get the log files.

These logs that you’ve just got are very generic, as you can see, so it would be a huge step forward for us if a ‘Not enough capacity found’ customer case had these attached!

I will not go now into detail about the fields in the logs, what they mean and so on – this will be explained in a future post, more technical. What you can do until then is play with different parameters, play with applicable resources, play with different route parameters and you will get a decent understanding, I believe.

So what does LogToTextFile do? Up until now we’ve produced log files that are decently readable by anyone. You can also enable the scheduling engine to log every tiny thing it does, using standard Windows event tracing. Here’s how you enable this!

1. Go to Performance monitor (go to Run – type Perfmon.msc)

       2. Create a new User defined Data collector set. Give it a name to remember and follow the wizard.

       3.Chose Create manually

 
        4. Chose Create data logs – Event trance data

       5. Add a trace provider

       6. Chose Microsoft-DynamicsAX-Tracing

       7. Specify what you want to trace from AX, by clicking Edit. You want to choose MRP from the list of all keywords.

       8. Specify where you want to keep the log

9. And you’re done, just click Finish

      10.  Well, you’re not 100% done – you need to start tracing, by clicking start in the tool bar

If you now schedule a production order, you can view the trace in the standard Windows Event viewer – Action – Open saved log – open the log saved at the location you set in the wizard, in my case C:\PerfLogs\Admin\DAXTrace\[MachineNameHere]_20130116-000001

 And good luck keeping track of these!

What you could do to make your life a little bit easier is to convert all the messages into a .csv file, which you can open in Notepad and search for some keywords or something like that. You do this by running the following command:

tracerpt [location_of_the_trace_file] -o [destination_file] -of csv

Whatever you do, remember to switch off tracing after you’ve collected your data! You don’t want to keep on piling data you don’t need, not to mention that tracing always has a negative impact on scheduling performance.

Microsoft Dynamics AX 2012 R2 - Selection List     

A feature that enables persistent selections on list pages

In earlier versions of Microsoft Dynamics AX, the paging, selection methods, and actions that were available on list pages varied across the different areas of the product. For example, some list pages let you select only one line at a time in the grid while others allowed multiple selections. Some list pages had a Mark column with check boxes, which were handled by background code on the forms, while others would not let you mark rows in the list.

Figure 1: On the left: custom row marking. On the right: kernel-managed (standard) row marking

Microsoft Dynamics AX 2012 brought consistency to the selection behaviors. The kernel now manages row selections, and the overall selection experience is aligned with other Microsoft products such as Excel, as shown in Figure 2.

Figure 2: Row selection in Microsoft Excel 2013 

The new kernel behavior has replaced prior methods. Some of the requirements that were addressed in earlier versions were not compatible with the new mechanics and have been removed. One of these requirements is the ability mark a record independently of the row selection. For example, a collection of records could be marked while others would be selected. This scenario is no longer possible.
Some customers expressed concerns that the new behavior would prevent them from selecting some records while investigating the details of others. For example, for a production planner it’s important to be able to mark the production orders that he or she expects to firm (at the same time) while looking at the details of other orders to determine whether to firm them as well. According to the new behavior, the planner’s selections are cleared when a second record is selected or the details form is opened.
We’ve worked closely with these customers, and in the Microsoft Dynamics AX 2012 R2 release we’ve delivered a solution that adheres to the standard selection experience and enables this scenario.
The feature is called the Selection list, and it’s available on the Action Pane.

Figure 3: Selection list-enabled Production Order list page in Dynamics AX 2012 R2

The Selection list feature is not enabled by default. To use the feature, you must enable the Selection list usage configuration key for the Production series I license key. The Selection list is then available on the list pages for planned orders and production orders.

Figure 4: The Selection list configuration key

The Selection list is similar to the Task list in Microsoft Outlook. You can select a group of records on the list page and add them to the Selection list. You can query the records, and you can also filter the records on the list page to match the list, or show only those records that are not in the list. This gives you better control of the amount of information that is displayed.

Figure 5: The Selection list Action Pane Group

The following functions are available:

• Add to selection
• Adds the selected record(s) from the list page to the Selection list.
  
• Remove from selection
• Removes the selected record(s) from the Selection list.
  
• Clear selection
• Clears all records from the Selection list.
  
• View selection
• Applies a view to the contents of the list page that shows only records that are included in the Selection list. The view is applied until you click the button again.
  
  Left: View is on. Right: View is off.
  
• View unselected
• Applies a view to the contents of the list page that shows only records that are not included in the Selection list. The view is applied until you click the button again.
  
  Left: View is on. Right: View is off.
  

The Selection list feature also includes the Selection list FactBox, which is available to the right of the list. The Selection list FactBox displays all of the records that have been added to the Selection list. Additionally, you can also use the FactBox to apply the View selection view.

Figure 6: The Selection List fact box

The Selection list remains available when you close and reopen the client. The selections in the list are saved for a user in the context of one legal entity.
A separate blog post will show how partners can consume and extend the Selection list for use on other list pages. Many other list pages can be customized to take advantage of this feature.

Andre Lamego,
reviewed by Brent Holtorf and Roxana Christina Diaconu

Microsoft Dynamics AX R&D

Microsoft Dynamics AX 2012 R2 – Developer perspective on the Selection list

Extending the Selection list to other list pages

In a previous blog titled Microsoft Dynamics AX 2012 R2 – Selection List, I described how this simple feature can help you keep and manipulate a persistent selection on list pages for planned orders and production orders. In that blog I also mentioned that you can extend other list pages so that they can also use the Selection list feature. In this blog, I’ll provide developers with the specifics of just how to do that. I’ll also describe the foundation beneath the implementation of the Selection list.
During implementation, the conceptual name of this feature was Production Record Basket. This name became the ProdRecBasket prefix, which is assigned to the elements of the feature and will help us to locate the artifacts in the system that we’ll need for the extension.

 
Figure 1: The artifacts related to the Selection List

The Selection list is implemented in a context-agnostic manner. The feature recognizes only that records from the root data are displayed in the grid, and is neither domain specific nor dependent on the type of records it displays. One important note is that the Selection list works only with the source of the root data for the list page. The root data source for a form is easy to identify. It’s the one data source that has the Joins property clear and usually appears first on the list of data sources.

For this exercise, the most relevant artifacts to keep in mind are the following:

1. The ProdRecBasket configuration key
1. You must enable this configuration key to use the feature because it controls access to the table definitions and menu items.
2. The Selection list button group
1. These are buttons that need to add to the Action Pane of the list page that are the front-end UI for this feature.
   Their functions are detailed in the previous post. I recommend using the form ReqTransPOListPage as a data point to retrieve these.
   
   
   Figure 2: The Selection list buttons, as implemented in the ReqTransPOListPage form.
   
   

3. The ProdRecBasketPart (the Selection List Factbox part)

1. This is the form part to attach to the list page. It functions as the engine that
   supports the feature.
   

4. The ProdRecBasketUse (the security privilege)

1. This security privilege enables the user roles to read and write to the tables.

Using these four elements I’ll go through the process of extending another list page so that it consumes the Selection list.
For this example, I’ll use the EcoResProductListPage form.

My first concern is security. I must ensure that the user role can read and write to the selection list tables. I’ll start by locating the duties that are related to the Products form, which are EcoResProductDefinitionMasterInquire and EcoResProductDefinitionMasterMaintain. To these duties I’ll then add a reference to the privilege called ProdRecBasketUse.

Figure 3: Extending the duties for the Products list page to be able to use the Selection List.

Now that I’ve taken care of security, my next step is to add the buttons to the EcoResProductsListPage form. I’ll use the ReqTransPOListPage as the source of the metadata information. I’ll copy the button group from the planned orders list page, and paste it on the Action Pane of the Products list page. When you do this, please remember to change the metadata property called
DataSource to match the root data source of the form. In this case, the root data source of the Products form is called EcoResProduct.

Figure 4: Adding the selection list buttons to the Products list page.


The last step is to add the controlling fact box to the Products list page. I’ve just created it, but I also could have copied it from the Planned orders list page. Now that it’s added, I’ll align the metadata properties as shown in Figure 5.

Figure 5: Adding the Selection list part to the Products list page.

When the process is done, my Products list page should be ready for the Selection list.



Figure 6: The Products list page extended to support the selection list

Please make sure to add a comment or send me a message with any questions or concerns regarding this topic.

Andre Lamego,
reviewed by Brent Holtorf and Roxana Christina Diaconu

Microsoft Dynamics AX R&D