kurthatlevik: New Microsoft Dynamics AX – A guide for using retail sales prices and discounts
This is a guide I have been looking forward to publish, but due to the NDA restrictions I needed to wait until the new Dynamics AX was made public preview, and today it is J This blogpost is not about AX licenses prices, or implementation costs, and if you were looking for that, you have to google again. It’s about what product sales price and discount options that exists MSDAX – “out-of-the-box”, and it’s not about product sales price tactics and strategies, but how to apply them into AX and most of the presented information here can also apply to earlier releases of Dynamics AX.
Pricing and discounts is a science, and the number of variations and combinations is amazing. When I talk to my customers I like to show the following overview of the most common used pricing strategies available in AX. Here I have tried to put “retail names”, and exemplify what they mean.
The Microsoft documentation on TechNet visualizes quite clearly the relationship between prices, discounts, channels and programs with the following many-to-many relationship diagram;
It basically means that you can combine and mix pricing elements to achieve the strategy you are aiming for. The combination of these gives us the functionality we are looking for, but we have also realized that not all combinations are practical or possible. Remember that much of the pricing possibilities became available with the introduction of Retail, Call- center and in some cases the lean-modules. Some pricing options will therefore not work in combination with each other, and also not across the Omni-channel.
Product prices and RRP (Recommended Retail price)
RRP, or Recommended Retail Price is a very common and known concept. It is very often used on, when the sales channels are more complex, and includes producers, distributors, partners and resellers. Often the ownership structure of the sales channel is fragmented and differentiated. The recommended retail price is therefore often specified based on geography, currency and channel. The RRP if very often just the baseline on which prices are built on, and as the name suggests, just a recommended price. In Dynamics AX either the standard (single currency) sales price on the released product or having a “All/Group” sales trade agreement (multiple currencies, dates, quantity) is sufficient to make this work. One restriction to make this work within AX, is that the product must be released, in order to do this. If a more “Global recommended retail price” is wanted, I suggest reading my blogpost on this subject, where prices are made global, and distributed to all legal entities.
Price/discount matrix’s (Trade agreements)
The price discount matrix has been available for AX users since the beginning, and handles most requirements in a B2B scenario. The setup is quite easy, and involves setting price or discounts on groups, or in relation to specific entities like product or customer accounts.
In the following example we have different sales price on a single item, but it differences per customer price/discount group.
In AX ‘7’, you will just create a trade agreement journal, and create the necessary lines to reflect the different prices.
Maintaining sales prices on the item-level per customer group, or per specific customer can quickly be a maintenance nightmare. The different combinations quickly end up with so many price points, that oversight is lost. A customer of me had 4000 products, 6 currencies and 12 different account selection options. This would mean that they would maintain 288.000 price points. That was impossible! The option was to use discounts instead, and just maintain recommended retail prices per currency. This resulted in 24.012 price points to maintain. With the use of smart rounding, and generic currency we reduced the number further down to 4012 price points. A discount matrix would look like this, where the combination per item price group and customer price group resulted in a discount.
In AX ‘7’, you will just create a trade agreement journal, just like for prices, and create the necessary lines to reflect the different discounts.
If you want to test a sales price, with all the different combinations, you can use the “Find prices” feature. Here I have a specific customer belonging to the price group “Retailer”, The item belongs to “Apparel”, and the combination of this gives me a net amount of “127,5”.
Generic currency and smart rounding
As seen in the example above, I have specified prices for different account selections, but only in USD. If multiple currencies are used, and you don’t always want to maintain currency based pricelists, then the generic currency option is a nice feature. The first step is to specify what is the generic currency, and what exchange rates that should be used. Also if smart rounding should be applied after currency conversion. In the setup of smart rounding you also need to set up member currencies that belongs to the smart rounding.
Enabling this, will open the “include generic currency” option on the trade agreements, and when creating sales orders in a different currency, the sales order. Here we have a sales order, converted from USD to €, and then the automatic smart rounding is applied.
Trade agreements and Retail/Call center in combination
As shown here we, the trade agreement matrix can solve quite a few price requirements, but in a retail scenario it would not solve the all requirements we see. We are missing elements like retail channel, categories and more advanced features. Going deeper into retail functionality shows that there are many additional possibilities that opens up. I have met quite a few companies, that have advanced price and discount requirements, but they have never thought about enabling the retail module. Many thinks the retail is for POS, but the retail module is for Omni-channel. This means that we can also use this in traditional sales orders (The “call center module” enabled retail functionality to be used in traditional sales.)
But there are some elements in AX, that you should be aware. I often see good old AX consultants getting confused when they start looking at retail discounts. Let’s say we have the following scenario; We have item 0001 with a recommended price of 150 USD.
And then we have a 15% discount on the customer;
You would then expect that when using the retail module, it will just use these values. But it don’t ! It actually calculates the discount amount, and not the percentage. Keep this in mind, because it will confuse you later.
When using the retail discounts, they will work together with the traditional trade agreements, but not exactly as you would expect. To better understand the actual code executing, then take a look at the class\RetailOrderCalculator.saveSalesOrder(). The CRT (Commerce Run Time) engine returns quantity, price and total discount amount. Based on this, the unit discount amount is calculated. I’ll also show the actual source code on this, because when we are talking about discounts, we are most likely going to think in percentages, and the same are customers and users.
And one more thing. The CRT will not apply both the trade agreement discounts and the retail discount. It will select the best of them.
The use of Retail Discounts in Sales orders
Let’s take some scenarios, that is common in the retail industry, and I’ll try to link them to what you find in the standard Contoso demo dataset. In AX ‘7’, the retail module mainly has 4 discount types of discounts, and a price adjustment;
First step is to use the retail discount rule.
Periodic discounts on categories
“50 % off on accessories this week” can be a strong trigger to make the customer open the wallet.
To create such discounts, we can use the same screen.
PS! The Retail discounts have a “discount code” field, but I have never managed to use it in the call-center sale order screen. But in POS, it works J
Happy hour J
Happy hours are an efficient way of attracting and breaking customer’s shopping routine. It’s also fun, and can give retailers a lot of attention. This feature is excellent also for Black Fridays.
The validation period has an advanced setting, that opens up the field “Discount period number”, and select a discount period. I have here created a happy hour between 12 AM and 1 AM for early birds.
We can further specify the valid periods here, so that more period based discounts can be given. Just remember that the valid period is current time +/- the offset time defined on the retail channel. In the AX ‘7’ CTP 7 version, the call-center channel details screen is not showing the time zone, like it does for retail stores, and this could have some implications on using “Happy hour” in an installation that works across time zones. A small service request to Microsoft have been created, and I’m sure they will fix this J
Coupon discounts (Call center)
Coupon discounts seems to be very popular in US, and we also see an increasing use of this in Europa. Especially in relation to mobile coupons.
In Dynamics AX 2012 there are two ways of working with Coupons. One solution for POS, and one solution for Call-Center. And these two don’t work in common. It is a bit sad, because it means we have a GAP in the Omni-Channel offering. But with enough push on Microsoft, I’m certain it will merge in future versions.
Call-Center Coupons, can be defined to be an amount or a percentage, and may have valid period. The coupon can be a unique, and a one-time use, and
It can have item rules attached, that specifies what products the coupon can be used with or excluded from.
So solve Coupons for Retail/POS, you can see that all discounts have the option to apply a “Discount code”. I have not found a way to make this discount code to behave as a unique and on-time code. Even though AX-Sales orders not can use CRT as the price engine, there are no places, where the discount code can be applied to a sales order. It therefore only works on POS/eCommerce scenario’s It is a bit sad, because it means we have a GAP in the Omni-Channel offering.
Dynamics AX for retail have a GAP in relation to coupons to solve “One-Time” coupons, and in future versions I hope to see more features, like Store coupons, Manufacturer coupons, Mobile/Cell codes and promotion codes.
Trade discounts is a most common way of creating discounts. 3 very common discounts are
A quantity discount is a discount that is given to customers when they purchase a particular quantity of a product. For example, you can set up a 5 percent discount for the purchase of two products of a particular category or brand.
A threshold discount is a discount that is given to customers when the total for a transaction reaches one or more specified amounts. For example, you can create a discount that gives a 5 percent discount for purchases over 100.00 or you can specify a fixed discount amount.
– Buy for 100 $ get 5%, Buy for 200 $ get 10%, Buy for 900 $ get 40%
Price adjustments per channel
The loyalty module in Dynamics AX is a large module with a lot to offer.
But there are some small GAPS you should be aware of, and that is to use loyalty points for payment in the call-center sales order. It could be I’m wrong, but I have not been able to efficiently use the Dynamics AX sales order screen efficiently with the loyalty module. A good blog for loyalty is available here.
Smart rounding is a feature that have no direct effect on retail pricing.
But it can adjust trade agreements, that indirectly works with retail. Also remember that it is not “automatic smart rounding”, and the smart rounding is applied to a price discount journal. A good blogpost on smart rounding is this one.
Recurrence and discounts
The ability of creating recurring sales is not directly related to Retail/POS. In AX there is a feature called continuity programs where delivery schedules can be setup.
I don’t think this modules works very nicely with POS and eCommerce, and is mainly a tool for call-centers and selling recurring items. More information is available on TechNet.
B2B Discount agreement
Price agreements is not working with retail-POS, and is not very good supported through the CRT. It is mainly used for B2B orders, and features exists both for sales and for purchase.
Расскажите о новых и интересных блогах по Microsoft Dynamics, напишите личное сообщение администратору.
|kurthatlevik: DAX2012 R3 – Playing with Retail CRT||Blog bot||DAX Blogs||0||28.10.2015 20:11|
|kurthatlevik: DAX2012 R3 – Playing with Retail CRT||Blog bot||DAX Blogs||0||21.05.2015 15:11|
|dynamics-coe: What we talk about when we talk about KITS in Dynamics AX||Blog bot||DAX Blogs||0||02.03.2015 11:11|
|emeadaxsupport: Retail POS Technical Reference: Microsoft Dynamics AX 2012 Feature Pack||Blog bot||DAX Blogs||1||26.04.2012 06:11|
|emeadaxsupport: New Content for Microsoft Dynamics AX 2012 : October 2011||Blog bot||DAX Blogs||0||27.10.2011 17:11|
|Опции темы||Поиск в этой теме|