Dynamics 365 Supply Chain Pricing management module overview

Dynamics 365 Supply Chain Pricing management module overview

Introduction

Microsoft has recently announced a new pricing engine called Pricing Management. There is a very good summary already available on the Microsoft Learn site. As the feature is already available in preview, and the mentioned summary provides detailed description with examples.

This current article is not a 100 % complete and comprehensive list of all available features and settings, rather a collection of interesting new, or changed functionalities, as well as a handful of advices to be considered for future implementations. You should also check other available sources, like this great video showing basic settings and the resulting price calculation.

Background

Two key factors played a role in the development of this functionality. The first one being the ever growing requirements of pricing in some business cases (like traditional B2B companies moving towards B2C direct selling), and the second one being the vision of Microsoft to bring all Dynamics applications to one Platform. This later can also be observed in the increasing number of projects where the classic ERP (Finance and Operations) is integrated with one or more applications from the Customer Engagement palette (CRM, Field Service Management, and/or Project Operations to name a few).

Philosophy

The key difference between the "old" pricing (Trade agreements) and this new Pricing Management is not only the advanced setup possibilities resulting in higher complexity, but also the fact that the processing of the price calculation itself is more dynamic. Additionally, it also provides more support for price adjustment business processes.

• Trade agreements provide a good static method to use fix master data for pricing. Price is determined in real time when entering a sales order, but uses the static prices in the background. Apart from this, the process of adjusting prices, or creating new criteria was not that well supported. Companies had to rely more on business processes and less on IT tools if they wanted to update their price list for the new year for example.
• In opposition, the new Pricing Management can still have static records, but it shifts towards applying a dynamic method to calculate prices based on multiple input parameters. It can be very useful for companies operating in retail, that rely on purchase prices, or likewise for manufacturing companies with fluctuating raw material prices (copper for example, but almost all kinds of raw materials in these post-covid times, not to mention other current economical and political factors). Based on your setup, a well defined set of rules can make regular or ad-hoc adjustments and new price lists more easier than before.

Remark: the Pricing Management refers to sales prices. Product costs are not directly affected, and purchase prices are still defined through Purchase trade agreements (and/or Purchase agreements). 

Before we dive deeper, here is an overview of the new Pricing Management.

Picture taken from the official Microsoft Learn Website

Some elements were already available in previous versions as well, but the way there are processed is partly new.

What's new?

Below is a short summary of new key terms and new or changed functionalities, supported by possible and real life examples.

Base price

Finance and Operations can now use different sources to define the base price for a product. You can define a base sales price, to be processed by further settings. It is also possible to use your purchase prices as the base price. This is the first important consideration.

In case you apply a markup (also called "margin" - see below) which could be described with the following formula: (sales price) = (purchase price) + X % markup, your output will definitely change, if your input was modified. If you setup your purchase price to be updated with each purchase order, be prepared that it will affect your sales price calculation (which is definitely different from the static master data of sales trade agreements).

Similarly, pricing management can also use your item cost as the base price - again, consider how you calculate your item cost (e.g. FIFO, or average cost), and how often does your setup allow recalculation with processes like inventory close.

That would be the first lesson learned: if you use a dynamic calculation, make sure your input data is what you expect it to be, otherwise your output will not match your expectations. It is not necessarily good, or bad - it is simply a change compared to the old pricing.

Remark: you can still use sales trade agreements as base price. The user simply has to allow the attribute based trade agreements to have a hybrid solution as they are already available today in trade agreements, combined with price attributes (see below).

With regards to trade agreements, note that some new method might use the inventory dimensions differently than the legacy solution. A base price can be setup without a site specified, while the old trade agreements had the risk of users setting up different agreement dimensions from the defined price relevant dimensions.

Price attributes

Pricing Management uses "Price attributes" (imagine them as tags, as properties) as one of the main input criteria for the price definition rules. It is an easy, straight forward way to define attributes relevant for your pricing logic. However, there are two considerations:

1. Price attributes can be defined for products, customers, and for sales orders (header or line level). All of those attributes are defined as product attributes. As the product attributes are only used effectively as product attributes once you assign them to a hierarchy, a workaround is to define your customer, and sales order price attributes as product attributes with no hierarchy association. It works, but maybe it would be more elegant to have them separated from product attributes.

2. Price attributes (product attributes) are linked to products only, not variants, in case you have product masters. Meaning, you cannot apply a +20 % margin for items with a shiny finish for example - at least not with the attributes. It is possible to achieve that later where the calculation itself is defined. However, you would need to define it per product and per variant - example: Product A, normal finish: price 10 USD, shiny finish: price 1 + 20 %; Product B, normal finish: price 20 USD, shiny finish: price 2 + 20 %.

Classifying your customers and products through price attributes is obvious. Sales order attributes allow setting criteria linked to other types of input parameters, like sales channel  (header) or delivery method (line level). It is definitely an addition which was long time due, but make sure to automate as much of those input parameters as possible, a company with hundreds of orders per week will definitely not allow manual intervention for each and every sales order to have the correct sales price as a result.

Margin components

It is now possible to define margin price adjustments. Companies will definitely benefit from such options, as that was one of the pain points with trade agreements: the lack of applying a simple margin (markup) calculation. Setup one or more margin components based on your attributes (product, customer, sales order properties) to fit your business needs. Another example might be when your deliverables take months or years to be delivered, any you plan to adjust your price over time. That was not a trivial setup with trade agreements: discounts we know and use today do not allow negative values to be used as a workaround for price increase.

This option provides a flexible way to apply a complex set of margin components:

• fix margin representing the idea of pricing based on a markup percentage,
• plus a variable margin, representing seasonality for example.

Discounts

Next to the already existing option of line, multiline and total discounts, two main improvements include mix and match discounts, as well as free items. While other new features seem to please the B2B processes, this one was planned most probably to support B2C sales. It is welcome that Microsoft is really enhancing and expanding the pricing engine in multiple directions.

A beginner's guide to discounts:

• simple discount: buy items from product line A, get 5 % off,
• quantity discount (multiline discount): buy two or more items from product line A, get 7 % off (if it would refer to one item only, it could also be mapped with step pricing, without the use of discounts),
• threshold discount (total discount): buy a total of 1000 USD or more, get 8 % off,
• mix and match: buy 5 or more items of product line A, get 5 % off of items from product line B,
• free item: buy more than (quantity / amount threshold), get a free item from product line C.

The list above contains only the simplest discount possibilities, retail companies typically have multiple discounts based on those building blocks.

There is also an option to use coupon codes - although this might be just an entry level solution, hopefully a placeholder of a more rich functionality to come.

Price structures

The price structures are the core of the pricing engine. It would take days (if not weeks) to list all possible settings, and the calculation results, bottom line is this new engine provides way more flexibility than simple trade agreements with prices and discounts. The base price, attributes, margins and discounts are the input or the price calculation, but your price structure defines which component to be considered. Don't forget, you can have multiple different rules from each type.

Without going into granular details about all its capabilities, price structures define the sequence, and the applicable logic of all inputs above. Example: if you have one rule for Swedish customers, and another rule for customers located in Malmö, and different prices and discounts also linked somehow to the location of the customer, these rules define which component to apply, and how to combine them.

The most trivial setup options are:

• ranking: sequence in which a certain price component is considered, like the physical location: does the rule for Sweden override the rule for Malmö, or the other way around,
• combination rank if there are multiple filter criteria applied: discount percentage for the combination of customer and item for example, again if there are multiple records valid for all combinations for Sweden vs Malmö, and Timber product group vs. product Timber, 12x8 cm, 200 cm long, premium quality. The possibilities are way more complex than the "old" all - group - table options F&O has in other settings,
• concurrency mode for discounts: exclusive discount (only one considered at a time) vs. compounded (combination of multiple discounts allowed according to preset rules) vs. best price (largest discount = lowest sales price, considering all allowed discounts and their combinations),
• currency management.

And if one set of rules (price component code setup) would not be enough for your company, you can define multiple sets of rules (called "Price trees"), something similar to this schema:

Picture taken from the official Microsoft Learn Website

As also visible in the picture above, charges and rebates are also part of the Pricing management functionality - however, their setup has not changed, so they are not discussed in this article. The way they are considered (involved on a sales order header / line) are also setup in the price component code setup / price trees.

Posting

Apart from sales related settings and functions, some features extend the finance possibilities in the background: it can also be defined if Finance and Operations should use separate general ledger accounts for price components (like margins, or discounts). Having mentioned finance, if you are familiar with the Costing sheet functionality in Finance and Operations (for indirect cost calculation and display formatting for production), I have the feeling this Pricing Management brings a similar complexity and sophistication to sales price management.

Scope

All settings are legal entity specific. If your company already uses trade agreements, that is probably not a surprise, those are also company specific agreements - even the product master has most of its configurations setup on local level (released products). As for Pricing Management: on one hand, it can be easily understood with different countries having different currencies, posting GL accounts, VAT settings and other internal and external factors considered. But on the other hand, if the aim is to have one common, harmonized pricing, it should be beneficial to have some parts of the setup made global - however challenging the technical solution might be.

Reports

I am also glad to note that the Price details report / functionality, which was already available for sales orders in the legacy version, is still available, enhanced to incorporate pricing management data as well:

The setup above is very simple, but all the needed information pieces are there: unit price (base price), margin component, and discount (if applicable, not setup thus not shown in the current example).

Wishlist

I assume Microsoft will further enhance Pricing management based on customer feedback. As already pointed out, there are a few rooms for improvement regarding the configuration of the functionality itself. Next to those smaller nice to have gaps, there are more essential gaps I'd personally classify as a must:

• priority number 1 would be: it is not explicitly communicated, but this pricing does not apply to sales quotations,
• and although Project Operations does not support stocked scenarios at all (yet - hopefully will do in the near future), the same pricing engine would be very useful for project quotations and projects. Service items can still be consumed on projects (would make probably less sense for fees and expenses, and hours have a different pricing logic) - I would gladly accept this as "only" priority number 2.

You might add your own personal favorites to this list: more advanced reports, workflow approval, simulation to get a preview of the applicable prices etc. If you are persistent enough, feel free to suggest it on the Microsoft Ideas homepage.

Note: sales agreement prices override the pricing management prices, however, that is as designed, a customer-specific agreement in effect is "stronger" as a generic rule set based on input parameters like customer and product attributes.

Summary

After reading about Pricing Management, and trying these functions in Finance and Operations, it is clear it brings added value to most companies using Finance and Operations. As the main logic is quite different from the previous methods, and there is a huge complexity available now, perhaps the most important takeaway is to carefully analyze and consider each and every business requirement. If you think this new solution fits your business needs better, try to forget all your "old" Finance and Operations preconceptions, define your business rules, and configure Pricing management accordingly. And don't forget to check what might impact your settings even if you wouldn't see that happening. This is especially important if you use a base price which is subject to modification (based on purchase price, or item cost, as described above). Test your setup thoroughly, have them approved by stakeholders - and checked even after the initial implementation. If you stick to these guidelines, you will have implemented Pricing Management successfully, adding complexity to your pricing engine, and reducing administration efforts.

As the functionality is very new (at the time this article is written), feel free to share your opinion: inputs, questions, feedbacks in the comments below.

Dynamics 365 Supply Chain Pricing management module overview