BC Price Calculation v16

Business Central 2020 Wave 1 has been released to the public since April this year. If you have been following the news, Microsoft started introducing a new way of calculating sales and purchase price in Business Central. The new one is called v16, the existing one is v15.

You can read about the release here.

If you are working with app development, you will see below warning on your code.

Table ‘Sales Price’ is marked for removal. Reason: Replaced by the new implementation (V16) of price calculation.. Tag: 16.0.

V16 price calculation is provided as an alternative to the v15 calculation. V16 is supposed to have the advantage that it is much easier to extend or replace the calculation. Since there is not much information about this, I decided to gather all the information that I have in this blog post.

Why there is a new price calculation ?

Microsoft had multiple requests for extensibility in pricing area that could not be done without changing the existing calculation (breaking changes). The decision was to build a module that would require minimum repeat of the existing functionality and be more extensible. Extensibility is provided by using a unified price line table with a simple primary key, extensible enums instead options, interfaces, and the extensible setup.

What is the difference between v15 and v16 ?

The new v16 implementation of price calculation does the same calculations as v15, but is structured differently to provide for better and easier extensibility. The old calculation is still in place and it should work as before. The goal was not to break the existing pricing.

The main change is that all prices are to be stored in one table “Price List Line”. The old tables are compatible with it, meaning that we can copy all information from old tables to the new one. It also means that, for example, the resource price calculation automatically gets the functionality of sales price, like “minimum quantity” and “starting/ending date”. If you had extended the “Sales Price” table with a new field you will have to do the same for the “Price List Line”.

The “Price List Line” includes an extensible source (Customer, Vendor, Job, Price/Discount Group, Campaign, Contact) and an extensible asset (Item, Item Discount Group, Resource, Resource Group, G/L Account). The extensions can add new types of sources and assets.

For instance, a sales line would produce a list of sources related to it: Customer, Campaign, Contact, Customer Price Group, Customer Discount Group, therefore the search for the best price line would be done taking all of them into account. That is nothing new, the existing pricing works the same way but the code is written separately for different prices. The approach is unified, so the search of a purchase, sales, or resource price is mostly the same, while the difference is in sources and assets.

The setup will allow to customize calculation for a combination of the method, the type (sale/purchase), and the asset type. It means that if you want to change the calculation for one of asset types you can set it up by adding a setup record via extension and implementing a new calculation codeunit. All other combinations will continue using the default calculation (v15 now and v16 later). The detailed setup lines would allow to setup exceptions that could include a certain customer or item that require a very special calculation.

The upgrade will be a copy of all existing prices from tables marked as obsolete to the new table.

Can we still use v15 calculation ? Will it break the current pricing method ? Will it break my price extension ?

V15 deprecation is scheduled with BC18 not with BC16. When UI for the new implementation is shipped (Wave 2 – 2020), users will be able to choose one of price calculation implementations: v15 or v16. By default, if they do nothing, they stay with the old (v15) one. Only when you decide to migrate to the new (extensible v16) implementation, you will have to redo the extensions.
However, v15 price calculation will be part of base application until deprecation in April 2021 (Wave 1 – 2021). This gives you a year to roll this out.

How do we handle custom field in sales price ?

First, you need to extend the “Price List Line” table with the new field. Then, you need to subscribe to OnCopyFromSalesPrice() inside Codeunit 7009 CopyFromToPriceListLine and add the code below.

PriceListLine.”New Field” := SalesPrice.”New Field”;

Can we start using v16 now ?

Yes, but it is difficult and not recommended. The only Microsoft documentation that I found so far is here. The UI to support new price calculation is going to be available in BC17. You can try to dig and figure out yourself on how to use it. Things may change in BC17, so I would recommend to wait until BC17.

thatnavguy

Experienced NZ-based NAV Developer and Consultant with 15+ years of experience leading multiple IT projects, performing business analyst, developing, implementing, and upgrading Dynamics NAV and Business Central. Passionate to deliver solution that focuses on user-friendly interface while keeping high standard of compliance with the needs.

You may also like...

2 Responses

  1. Marina says:

    Soooo… How do you use a field you have added to the PriceListLine-table?
    Let’s say, you have added a code to identify a discount and want to have that code be transferred to a purchase line, when the system selects this particular price list line. With events that was easy as pie, but there currently are none in the Purchase Line Price-codeunit. Would you now have to copy the entire Purchase Line Price-codeunit and add it to your extension to change just this one little thing? That would make upgrading to a new version quite a bit harder than it used to be in the old days, so that can’t be it… 😀
    Do you have any insights on that?

    Cheers!

    • thatnavguy says:

      Hi Marina,

      There is very limited information about v16 price calculation. I would suggest to avoid using this until Microsoft published more information (which probably on BC17).

Leave a Reply

Your email address will not be published. Required fields are marked *