New Price Lists in Business Central

In preparation for 2021.1 release of #msdyn365bc I wanted to see if I could take advantage of the new price list functionality to improve our small businesses productivity and reduce data entry issues. For our per-tenant extension we have some fairly heavy customization in this area and whilst we don't yet have to adopt the new functionality - I also don't want it to be an emergency situation.

This blog post will cover three areas:

Our customisations
Pros and cons of the existing pricing management system
Impact on new price list features in our context
Current approach

Our customisations

Pricing is a core part of our advantage in the market and we have invested significant IP in what takes are far beyond the standard pricing calculation features to support our industry vertical.

Per kilogram pricing on sales
Flexible weight based pricing on purchases (per mt, per kg, per lb, per unit)
Support for automated generation of freight inclusive pricing by region based built on top of sophisticated landed cost estimates, drop ship supplier data and multiple other factors
Generation of advanced price list per customer that includes intelligence on pricing changes
Access to item pricing straight from item list

Pros and cons of the existing pricing system:

Pros

You only need to update an individual item price when it changes and you can future date that price change
You had a built-in and easily accessible history of that price change meaning that you can provide additional context on price lists and via interaction with the system
The sales price worksheet showed the current effective price for a customer group or customer and the new price that you were going to change it to.

Cons

If you wanted to change the ending date on multiple prices you had to do this manually one by one or extend the solution to do this automatically (which we did)
There was no way for an user to just bring up a price list to review it. We extended the item list to show a default customer price group and provide easy access to other prices.
It does not easily display quantity based pricing tiers, nor multiple currencies side by side - instead the date dimension is given priority. i.e. No matrix view, even if the data model supports this.

I understand that there was a lot of factors driving this redesign. To harmonise purchase and sales price management, to provide for extensibility of price calculations and to begin the process of convergence with the broader Dynamics 365 product suite (gulp).

Impact of the new pricing management features

It is to be unambiguous that the new price list management features dramatically improve how purchase pricing works and for that we are happy. We feel sure that the existing system has developed bugs that are not being resolved.

However, the sales side is not quite as clear. From some of the minor release changes it seems we are not the only ones feeling that the price list restricted by header level means that some of the advantages of the old system are lost.

For us, the key issue is that we use up to six customer groups as the vehicle to deliver zone specific freight inclusive pricing. These take into account different drop ship supplier cost variations to different regions both at a supplier level and also allowing an override for specific items. Key, when a drop ship supplier may be located in a different region and price differently to ourselves.

Prior to this new functionality we simply populated the sales price worksheet by identifying where new prices generated by item costing were different from that in any sales price. Only one sales price could be 'active' at a time (meaning it had no end date).

If we had a new price, we essentially closed-off the existing price by adding an end date the day before the new price was due to take effect. This process to us was called 'fixing pricing' and ensured this business rule was enforced.

This was all done in only a two-step process and the majority of our time was spent focused on the decisions around pricing - not changing prices. Life was good.

Now as I understand it we have three options:

Option 1 - Keep open price list per customer pricing group

Ensure that we either have six price lists that have an open end date and allow line exceptions
Place that price list into draft and add just the lines that have changed in the price list

Option 1 is almost status quo, but without the benefit of the sales price worksheet functionality and still requiring us to go into each price list separately to update it.

Option 2 - Create new price list each month per customer pricing group

Create six new price lists each month
Include all items that need to be priced for that customer group

Option 2 would mean we might have up to 72 price lists created per year at a minimum - assuming we only create one a month.

Although our price list isn't large that is still 72 x 140 items or 10,000+ records. At the moment we have no more than 20-30 changes per month or 2,160 items. I could imagine this quickly getting sizeable for larger organizations.

Option 3 - Create a new pricing engine that dynamically adjusts price based on rules

Reduce down to a single price list (treat price list as true customer group)
Build a pricing engine that dynamically adjusts price to be freight inclusive based on customer location

Option 3 means we would reduce to a single price list - say strategic customers - and then either use dynamically calculated item charges using a technique like Bredit Auto charges or build a extension that custom generates freight inclusive prices in real-time for a specific item/delivery location combination. That seems like a lot of work!

Current Approach

The new sales price list has slightly reduced the number of pages and sub pages in which prices are shown at the moment and created a converged page to review both purchase and sales price lines. The extension of these pages have seemed relatively trivial.

We abandoned the old method of creating a table field for weight based pricing, instead using a page field based on a global variable. If we offer weight based pricing via API - it would be a custom extension and we can address in the same way. The only restriction is that filtering and searching could not be done against that weight based pricing.

The additional of context factboxes on sales and purchase price lists are also important for us to provide at least as much context as we use to get on the sales price worksheet. They provide a quick link to the current item costing and highlights if it is different. It also scans through the existing price list lines for that match and looks for the last time the price has changed.

We also have a function adapted from the old sales price worksheet that looks at our item costings and retrieves all valid prices that match the specific customer price group - this time not caring if they have actually been updated or not as it seems it is best to always have all our items in the price list.

Final wrap-up

Under the new structure we have need to be careful to:

Always designate a current price list and manage the descriptions clearly
Have our own filtered views that only show active price lists
Find a way to properly archive and/or delete old price lists
Explore a better ways of handling freight inclusive pricing that does not depend on price lists
Find a way to intelligently suggest pricing decisions based on current/future business forecast

As always you can borrow or look at our messy source code at my public github repository and offer helpful suggestions or ideas.