dynamics-coe: Override configuration ID in the constraint-based product configurator in AX2012

[Blog bot]

Источник: http://blogs.msdn.com/b/dynamics-coe...in-ax2012.aspx
==============

The new constraint-based product configurator was a huge leap forward compared to the old product builder. In version AX2012 R3 we additionally got

• “Calculations” and a slight possibility to work with real numerical values
• A feature to automatically re-use configurations instead of generating a new one every time

Yet with regards to the integration with the rest of the Dynamics AX system both tools sometimes share similar weaknesses:

1. The configurator cannot take main product attributes as parameters to build one complex re-usable model with forks for similar products with some slightly varying properties.
2. The used product configurator attributes are not stored in a human readable format on the generated configuration record. Needless to say, an AX configuration does not possess its own attributes at all, nor are the attributes searchable in the AX rich client.
3. Lookups from AX master tables (usually products, units, product groups) seem to only be leveraged in Retail attributes, while in the product configurator every value should be re-entered as a “free text” in a dedicated attribute type.
4. Process manufacturing formulas are not supported even if they are technically exactly the same as discrete BOMs.
5. New configuration IDs are taken from a number sequence (000147, 000148, 000149…) and together with the resulting configurations names bear no meaning to the user. Furthermore, a constraint-based product may not have a pre-configured set of initial configurations with distinct codes. One may only use configuration templates for that.

While the ivory towers are high, thanks to customizable interfaces in AX we can help ourselves. Below is a solution to the last issue, a feature that allows the user to enter a voluntary free-text ID for the new product configuration record. The feature is looking for an attribute with the solver name ConfigID among the options chosen by the user:



and takes it instead of drawing a new number from the number sequence. One screen of X++ code is attached to this blog. The issue with the dummy configuration name may also be solved following this pattern. A natural approach would be a name composed of the same unique attributes as in the "re-usable configuration cache".
Now, who is going to tackle the points 1-4?




Источник: http://blogs.msdn.com/b/dynamics-coe...in-ax2012.aspx