Attribute based sales prices for the Product configurator

Product configurator – Attribute-based sales prices

In Cumulative Update number 7 to Dynamics AX 2012 R2, we have introduced an
alternative to the cost-based sales prices in the Product configurator, namely
attribute-based sales prices. This new feature will allow you to build sales
price models with sales prices based on components and attributes rather than on
the physical bill of material and the route. You can build several sales price
models for a product configuration model.

Before you start building your price models, you must define a default currency. The
default currency is used when you build your sales price models. You can also
decide whether you want to attach an Excel-based price breakdown to the order
or quotation lines. The price breakdown will enable you to share details with
customers about how you arrived at a specific sales price for a configured
product. You can maintain these settings in the Product information management parameters.

With these properties in place, you are all set to start building your sales price models.
Click the Price models action on the Action Pane in Product configuration models.

The Price models list opens.

After having added at least one entry to the list, you can click Edit to display the Price
form. In the header of the form, you see the default currency and you can add new currencies for your price setup.

In the left pane you see all the components and user requirements of the product model.
Each node in the product model tree can have one base-price expression and an
optional number of expression rules. An expression rule consists of a condition
and an expression and each expression rule covers a product option that helps
control the price of the product.

The example above has a base price of a static number of 900 and two expression rules. The
first rule sets the price for the cable according to the selected length. The
second rule deducts 110 from the price if the same color is applied to all components.

When you build your conditions and expressions, you have the same operators available as
those that are used for calculations in a product model. Moreover, the expression editor supports

both conditions and expressions.

Once you have specified a base price and a set of expression rules for one node, you can
click on another node to continue building your price model.

If you want to maintain your prices in several currencies, you can add new currencies by clicking
the plus icon on the Action Pane and then you can select from the list of available currencies in the system.

In the example below, EUR has been added as a currency. When a configurable product is sold, the system

checks if the prices have been set in the currency of the customer. If this is not the case, the default currency

is converted to the currency of the customer using the currency exchange rates in the sales company.

What you can observe immediately is that for each price element there are now two expression

  • Default, which shows the expression you created in the default currency.
  • Expression, which is the field you will use to express the price for the new currency.

Please observe that the condition field for the expression rules is “owned” by the
default currency. This means that you cannot modify the condition for the new

Also, you cannot add expression rules for an additional currency. To create expression rules
that would be relevant only for a currency other than the default currency, you
can set the price expression for the default currency to zero. Then set the
appropriate expression for the non-default currency.

To test how the sales prices behave in a configuration session, click Test on the Action Pane. The Configure
form opens and you can select attribute values and immediately see the impact on the price.

If you want to see how the total price, in this case 3,466.90 US Dollars, was calculated,
you can click View price breakdown on the Action Pane. This will open Excel and display both the absolute

value and the contribution as a percentage for each active price element. If you have set
the Price breakdown parameter, this Excel sheet gets attached to the order or quotation line.

When your price models are in place, you must establish at least one selection criterion
to pick up the price model when you configure to quote or to order. You build
the selection criteria using the standard Dynamics AX SysQuery form.

To get started with this, click Price model criteria on the Action Pane in Product configuration models.

The Price model criteria list opens.

Enter a name and a description, then select which price model the query is related to,
what order type it should be used for and its validity period. When you click Edit, the SysQuery form is

displayed showing the primary tables for the selected order type. In the example below,

the order type is Quotation type prospect.

You can add to the list of tables by right-clicking on the tables in the header. Under Fields

on the Range tab you can add and remove filtering options.

Once your queries are created, you need to place them in the proper order in the

Price model criteria list. At configuration time, the system starts looking from the top of the

list and uses the first query that matches the data on the quote or the order line. So if you
place a general query at the top of the list, this is the one that will be used
even though there might be a query further down the list that targets the exact
customer or prospect of the configuration. Use the Up and Down arrows to change
the order of the queries.

You can filter the Price model criteria list to view Valid, Expired, or All queries. Use the

View action to set the filter appropriately.

Queries for price model criteria can be duplicated. When you create a duplicate, you must
enter a new unique name and a start date.

When you click OK to save a new query, the expire
date of the query that you duplicated is set to the day before the selected
valid from date.

In a combination with matching sales price models, the queries provide great
flexibility in targeting sales prices for particular customers, regions, periods,
and other criteria. To create new sales price models, you can either duplicate
an existing model or start from scratch.

The final step is to specify attribute-based sales prices for the product model version.
Select Attribute based in the Pricing method field in the Versions form.



Comments (20)
  1. Thomas Bremer Hansen says:

    Hi Sverre,

    This is certainly good news, and something the users has requested!

    Is it possible to setup price dependencies?

    Let’s say you have two attributes:

    Attribute A with sales price 150

    Attribute B with sales price 250

    If customer is choosing both attributes then I would like to be able to setup up specific price or discount for the combination.

    It could be:

    Select both attributes and prices would be:

    Attribute A with sales price 120

    Attribute B with sales price 200


    Select both attributes and prices and discounts would be:

    Attribute A with sales price 150 and discount 10%

    Attribute B with sales price 250 and discount 15%

    Is that possible?

  2. SverreThune says:

    Hi Thomas

    It most certainly is!

    One way to solve the first example is to use three Price expressions with three Unique conditions, e.g.

    1) Condition: A == True & B == False, Expression: 150

    2) Condition: A == False & B == True, Expression: 250

    3) Condition: A == True & B == True, Expression 120 + 200

    An alternative for the discount example is:

    1) Condition: A == True, Expression: 150

    2) Condition: B == True, Expression: 250

    3) Condition: A == True & B == True, Expression: – ((150 * 0.1) + (250 * 0.15))

    Makes sense?


  3. Thomas Bremer Hansen says:

    It certainly makes sense! And I'm glad to see that prices/discounts are maintained with expressions.

    I guess, that it is possible to setup price for either a customer, group of customers or all customers?

    And I also guess, that it is possible to setup the pricing for a product configuration model that are using the Table constraints?

  4. SverreThune says:

    Yes to can set up different prices for different customers, customer groups, time periods or any other criteria you can write a Query for.

    Setting up the prices is a two-step process where you first define the Price models required to target different customers, customer Groups or other. Then you define the queries which will determine who gets which prices and associate them with the corresponding Price models.

    Table constraints are first class citizens in the product models, thus they can be included in both the product models and the sales Price models.

  5. HARI says:








  6. SverreThune says:

    Hello Hari

    BOM-lines in Product configurator can be controlled by a condition including one or more attributes.

    It is important to note that the components used in product configuration models are reusable. This Means that you can only reference attributes on the component itself or any of its sub-components in a condition for a BOM line.

    You can read more about working with product configurator components here:…/hh351819.aspx

  7. Affan says:


    That is really something helpful for pricing.

    Can we use is to define pricing based on quality test results?


    I am producing a product "A"

    Then quality test is applied on product "A".

    If Quality of A is 01 then price is =250

    If Quality of A is 02 then price is =200

    If Quality of A is 03 then price is =180

  8. SverreThune says:

    Hello Affan

    I believe you can do what you want through a combination of a system defined table constraint and the attribute based prices.

    You need to define a table constraint which relates the quality field to an attribute type. In your product model you must relate one of the attributes in the model to the same attribute type.Thirdly you create a constraint of type table constraint in your model and map the attribute in the model to the quality field in the table constraint.

    You can now define a Price model which includes the conditions and Price expressions you have listed.



  9. Jan says:

    Hi Sverre !

    I have some questions .

    Is it possible to have a spec. price for only one customer on only one spec. component, for example a spec. speaker in your test model 20001?

    Is it possible to copy a complete price model/pricelist A, to a new price model/pricelist B?

    Is it possible to view/print all entered prices (pricelist) on a price model to get a complete overview of the price updates?

  10. SverreThune says:

    Hi Jan

    Thank you for the questions. I'll try and answer them as best I can.

    A Price model is defined for a product model. So a component used in several product models can be priced differently in each Price model.

    It is possible to enter a criteria which picks out a single customer and use one Price model for this criterion only.

    Price models can be duplicated/copied.

    You can view all active Price elements for a configured product in the Excel based Price breakdown.

  11. Jan says:

    Hi Sverre !

    Thanks for your informative answer, but one more for the moment…

    Is your answer to my question "Is it possible to copy a complete price model/pricelist A, to a new price model/pricelist B",  also applicable for discounts.. ?

  12. SverreThune says:

    Hello Again Jan

    The attribute based sales prices contain Price expressions which can be positive or negative, Thus a discount can be expressed as a negative amount.

    At the end of the configuration a unit Price is written back to the order line and actual discounts can be Applied.



  13. Jon Bing says:

    Assume that we have an attribute of type text, with a fixed list of values.

    The values are





    We would like to set the price according to (for example) the first character in the value.

    If the value starts with "A" we want to set the price to 100.

    If the value starts with "B" we want to set the price to 200.

    The reason for this is that we actually have 700+ unique values for the attribute, with more to come.

    Managing all of these with statements like 'if [ Attribute == "A1", 1, 0]' and a corresponding price is a giant task.

    But the letters used in these attributes are only about ten (A-J).

    Is is possible to use wildcards in the matching? Example:

    'if [ Attribute == "A*", 1, 0]'

    Or is there any other way of accomplishing the same thing?

  14. SverreThune says:

    Hi Jon,

    We don't have text operators in our operator set, so I don't believe there is a condition that can be written to pick all the right text attribute values.

    One possibility that you could consider is to leverage the fact that the solver converts all text attribute values to integers in a simple range starting from 0, e.g. [A1, A2, B1, B2] -> [0, 1, 2, 3].

    This fact can be used in Calculation where you set an Integer attribute to take the integer representation of the text attribute value. Subsequently you can use this integer attribute in a condition with <, >, <= or >= to set the range for the Price elements.

    In order for this to be a feasible solution your attribute values must be organized in ranges and fairly static.



  15. T Fjelde says:

    Issues after CU8


    After installing CU8  we now have issues with solver values / attributes that are used in sub components,

    The configuration validation returns a OK but if we run either a test or an actual configuration on a sales order we end up getting a error like this "Value "ABC" not found in map" The ABC is the fist solver value in the sub component, if we try to remove this from the configuration the error occurred on the next solver value.

    any tips on what to look for.



  16. SverreThune says:

    Hi Thrond

    You have posted this issue in my blog post on the attribute-based sales prices, but I can't tell if the behavior you experience is related to a Price model or a generic configuration issue.

    Can you add a few more details on your data composition to help me reproduce it?



  17. anra says:


    we are evaluating to use price modelling in pc,

    how to integrate standard ax sales price for items as customer discount groups and/or item discount groups (trade Agreements)?

    We would like to read all Price values from database and not fixed inside the pc price modell.

    How would you do this?

    Thanks Andreas

  18. SverreThune says:

    Hello Andreas

    The Attribute-based sales price models for product configuration models are maintained in the context of the product models. They do not read values from other sources, e.g. trade agreements, but rely on attributes, fixed values and expressions included in the model.



  19. Anra says:


    i understand. so i would load item prices via table based constraint from type system into pc attributes. In Price Modell i would assign these attribute as component base price expression.

    should it work?

    best regards


  20. SverreThune says:

    Hi Andreas

    Unfortunately constraints (Both expression constraints and table constraints) don't allow for the use of decimal numbers, so you can't use a table constraint to map an attribute of type decimal to a Price field in an AX table.



Comments are closed.

Skip to main content