Dynamics AX 2012 provides a new feature that allows you to validate the released product setup and ensure data integrity and overall process readiness. This feature is useful for managing master data and we expect it to be widely used by our partners and customers in order to support the product data life cycle processes, engineering change, approval workflows etc.
Traditionally, the system stores item definition data in one main table (Invent Table). Every time a user creates a new item, a set of mandatory fields must be addressed in order to successfully save the new item definition. This approach looks simple and logical; however, the item definition requires a good overview of all the mandatory settings. Insights into these settings are usually divided between users in multiple departments in an enterprise organization and it usually requires quite a lot of work to coordinate this information. A common approach in order to ensure consistency is to create shared and approved item templates which are strictly controlled and can be re-used across enterprises for the initial item data creation.
Another inconvenience of requiring users to address all mandatory fields relates to in-flexibility since it makes users working with the system less agile and process driven. Say, for example, that an engineering department wants to create a new product definition in the ERP system. There is an urgent need to send product descriptions to the external vendor for the localization and for the creation of marketing materials for the upcoming sales campaign. However, users cannot simply create items with the settings to control the external vendor relation processes. In this case, ALL settings must be defined which includes setup of financial accounts, inventory tracking, reservation rules etc.
Item master data setup enables the core business processes within ERP, so it’s not a surprise that we see a number of partner customizations in this space. If, for example, a company wants to retire an item, the company must ensure that the item cannot be produced or sold any longer within the organization. At the same time, it should be still possible to handle customer returns based on the existing customer agreements. When the item master data setup changes, one would expect some validation mechanism to ensure that the new item master data state is consistent with the user’s expectation. Unfortunately, there is no single centralized place to support such item validation process, so our partners and customers have to introduce such capabilities by themselves.
With the introduction of the Product Information Management (PIM) module in Dynamics AX 2012 we get an opportunity to remove some of the above described boundaries and to build a more flexible and process-oriented solution. There are a couple of key differences for users who deal with products compared to the previous versions of Dynamics AX:
No mandatory fields
Figure 1 Create new product
Figure 2 Create new released product
Once you have a basic product or released product definition in place, the system allows you to continue with the various master data setup processes such as to define translation, attach documents and images, sync product data to an external solution via existing product-item services etc.
This is a valid question at this point because if there are no mandatory fields anymore, how do I know when my product can used for procurement, sales, production, quotation …?
In order to answer this question let’s focus on process readiness and how the system behaves in Dynamics AX 2012.
There are hundreds if not a thousand different business processes which can be controlled by product master data. The total number of those processes varies from industry to industry and the processes vary a lot based on the end customer business requirements. It’s hard, if not impossible, to predict or know in advance which product master data is required in order to enable each unique business process.
Therefore, in Dynamics AX 2012, every single business process has to, metaphorically speaking, verify all required product master data. In other words, if some master data is not set for a given business process, the system will throw an error and the end user must set the master data before the system can continue.
A user creates an inventory movement journal. The system tries to retrieve all inventory dimensions that should be tracked for the product. If the setup is not complete, the process will fail since the basic pre-requirements are not fulfilled.
Figure 3 Create journal line for product with missing setup
The new product validation process has been introduced in order to help assess the overall product data readiness for the main business processes.
As mentioned before, it’s impossible to predict what master data will be required for what process in the system. However, we can definitely focus on the setup that is most essential in order to cover key processes in Dynamics AX 2012.
The product master data validation logic can be triggered from released product list pages and released product details forms. The functionality will verify that the following essential fields are specified for the released product:
In addition to the previous fields list, the following essential fields have been added to the validation logic to cover the Process Industry for Dynamics AX 2012 Feature Pack:
All these settings can be set on the released product list page which prevents the need to navigate across different places and modules in the system. Users can then leverage one single form to complete all the setup that is required.
We strongly recommend to always validate the product data setup to ensure overall process readiness. This process helps to prevent last minute issues for end users.
You can run validation logic for one or for multiple products and you can apply a product template for multiple products at the same time.
Figure 4 Run a product validation function for multiple products
Tip: Read more about how to use product templates: previous blog post
The EcoResProductValidationService class holds all the product validation logic. The class gets the number of released product references as an input, runs the validation logic, and reports all validation errors in a standard infolog message.
1: static void runValidationForReleasedProducts(Args _args)
3: container packedProductsPerCompanyInfo;
4: InventTable inventTable;
5: EcoResProductValidatonDataContract dataContract = new EcoResProductValidatonDataContract();
6: EcoResProductValidatonService service = new EcoResProductValidatonService();
8: // Find all released product with the itemId pattern like 'production*'
9: while select itemId from inventTable
10: where inventTable.ItemId like 'production*'
12: packedProductsPerCompanyInfo += [[inventTable.ItemId]];
15: if (conLen(packedProductsPerCompanyInfo) > 0)
17: // Create service operation data contract class and pass all released product references
18: dataContract = new EcoResProductValidatonDataContract();
21: // Run validation logic
Assume that we need to make sure that all items are produced with a production order for the current manufacturing company. The existing EcoResProductValidator can easily be extended to accommodate such a validation check:
Figure 5 Customization example
Managing product master data can be a complex and challenging task. We hope that the product information management features in Dynamics AX 2012 can help your organization to deal with some of these challenges. The product validation process is there for you, so please learn how to use it and enhance it if you need to.
Thanks for reading.
Agree with the Validation approach and customizing the validation is something we will do immediately.
We think the unit of measure should be part of the product. something so essential should be defined up front. The default order type can be part of the product also. And other fields that are typically "engineering" info like commodity code or category.These values will be identical in every legal entity. It is a good sign that ATF now includes the default order type also, we need that. A true ERP validation of an item however should include a cost, if the item is on standard cost. that is one single point of failure we have seen countless times with our customers. Especially businesses that create new part numbers every day (engineer to order). so the concept is right on the money. An engineering design, a product, needs ERP validation once it hits the legal entity.
Let me know if you agree with
1. adding additional fields to the product so it can be the landing point for a PDM interface
2.expanding the validation so a released product is truly "ready for transactions".