23 Jul New pricing functionality in BC version 16

Posted at 10:00h in Triangle Know How by

One of the innovations published in wave 1 of 2020, in version 16 of Dynamics 365 Business Central, has been a relevant change in the internal functionality that calculates rates and discounts. It is a novelty that has not yet been published in production environments, but to which we have had access as partners of the testing tool.

Carrying out these tests allows us to understand how this change will impact our clients, what conflicts can be generated and we have one year of margin to make the necessary changes. Of course, it is important to note that the functionality is not validated as definitive and, therefore, it could still undergo additional changes until its publication.

In this blog we are going to explain the first conclusions that we have detected at a technical level. Remember that if you are looking for a functional explanation you can find it in the third section of this blog.

1. Price changes in Business Central: New interface type object

After the release of version 16 of Dynamics 365 Business Central, you may have noticed that a new type of object called Interface has been introduced. For now, specifically it is only used for the new price calculation functionality, but it will surely extend to other modules over time.

If you already know this new type of object, do not hesitate to review this article where we detail the change in price calculation at a functional level and also at a technical level. But this type of object is also important to know in case you want to use it in the customizations that we can make as partners.

First of all, note that this is an unnumbered object. It is simply a protocol by which a structure or series of procedures / functions is defined without associated code.

Once we have defined the interface, its procedures are specified in different codeunits that implement it. In this way, it is possible to make developments that work with the structure and generic characteristics of the interface, regardless of which of its implementations is being used. You may already be familiar with this concept as it is used in multiple programming languages ​​such as Java, C #, PHP …

In the following image we can see how the new Price Calculation interface has been created in A/L, which has a set of functions, but without associated code:

Implementation Interfaces

The implementation of the code of these functions is done in codeunits that will have to be associated with the interfaces according to the implements parameter written after the name of the codeunit and indicating which interface we want to implement.

In the following example we show the two price calculation codeunits of the two versions of Business Central that implement the Price Calculation interface:

It indicates that in the 7002 and 7003 codeunits all the functions indicated in the interface to which it is implemented will have to be created and developed. If this condition is not met, the compilation will fail.

It should also be noted that a codeunit can implement multiple interfaces, indicating it with the implements parameter plus all the interfaces separated by ‘,’.

codeunit Id MyCodeunit implements Interface1, Interface2, Interface3

To facilitate this implementation, the light bulb icon or Show Fixes (Ctrl +.) Offers us the Implement interface option, which automatically drags all the interface functions that we must implement.

If the light bulb is not shown or the option of Implement interface is not offered, it is because in the settings file the Enable Code Analysis option must be activated for the AL Language extension.

Implementation Interfaces from Enum object

The last point that remains to be addressed is how to know how to select the codeunit (or implementation of the interface) to be used. To do this, an Enum object must be defined with all possible options implemented, which is also related to the interface with the implements method.

Following the same example of the Price Calculation interface, its Enum is as follows:

Here we see that it only assigns the two values of the possible implementations (V16 and V15), plus a blank or undefined value (which associates it with the V15 implementation).

In each option in the Enums list we have to indicate to which implementation this value is associated. For this, the new Implementation¸ property is used, in which we will indicate the value of the codeunit that implements the interface in the following way:

Implementation = “NOMBRE INTERFACE” = “NOMBRE CODEUNIT”

Finally, this Enum value is displayed on the configuration page that suits us best and can be associated with the Interface variable as a direct assignment from the value of the enum field.

2. Price developments in Business Central: Technical process

Going into the matter, the BC developers will have already noticed that in the codes that affect the tables of rates and discounts (both sale and purchase) a warning of the type Table ‘Sales Price’ is marked for removal appears. Reason: Replaced by the new implementation (V16) of price calculation .. Tag: 16.0.AL (AL0432).

This message is displayed to notify partners that a change will occur at this point in the application. At this point, the technical team has one year to adapt the customizations that affect this functionality so that they do not conflict.

To understand the change, the first thing to know is to use the new type of interface object. If you do not know the existence or characteristics of this object, we recommend that you first address the first section where we go into detail about its characteristics.

If you are already familiar with the operation and logic of the interface object, you may have understood that, with this new structure, price calculation is defined by the Price Calculation interface. Microsoft provides 2 implementations for this interface: version 15 (codeunit 7003) or version 16 (codeunit 7002). In addition, we can extend the functionality with completely different rates and discounts calculations from the standards, defining new codeunits that implement the Price Calculation interface.

At the time of calculating a price or a discount, for example in a sales line, in the NAV 2018 version the functions of the 7000 codeunit were simply called (Sales Price Calc. Mgt.).

Now use the Init and ApplyPrice functions of the Price Calculation interface and it is the codeunit 7003 that calls the previous codeunit 7000 (in the case that we have activated the calculation v15 in the new configuration table of price calculation).

If we review the code in detail, we see that to calculate the prices in different tables (sales, purchase, daily product, project, demand or service lines), variables such as RecordRef or Variant are not used, but rather work with the Line With Price interface, which Depending on the module in which we work, different codeunits that implement this interface are initialized (7020: Sales Line – Price, 7021: Purchase Line – Price …).

Technical circuit

The technical circuit to calculate prices with the V16 implementation uses the same steps. The difference is that the definitions of the functions of the Price Calculation interface (Init, ApplyPrice…) are different.

To reflect all the objects created in this functionality and the interface implementations we have created the following scheme:

The main difference, and the main reason why the warning appears, is that the Sales Price table has been marked as obsolete. This is so since the version 15 price tables (Sales Price, Sales Line Discount, Purchase Price …) have been unified into a single table named Price List Line. For this reason, the extensions developed in the previous version will have to be redesigned taking into account this new table.

In addition, to transfer the values ​​from the previous tables to the new one, you will also have to subscribe to the corresponding OnCopyFromXXX event (OnCopyFromSalesPrice) of the CopyFromToPriceListLine codeunit by assigning said field.

And you, do you think you are going to have any conflict caused by this change? Had you heeded Microsoft’s notice?

In conclusion, the important thing is to understand how the new pricing functionality has been structured, both the v16, and the small changes of the v15 and, mainly, how to fix the warnings errors, described in the first paragraph.

3. Pricing news in Business Central: Functional process

In this section we will explain the first conclusions that we have detected at the functional level and also in the configuration of this redesign of the price functionality.

Although in another entry we talked about how this change affects the technical level, that is, at the development level, it is important to note that a great structure has been created with new tables, codeunits and interfaces. At the functional level, we highlight the following tables:

  • Price Calculation Setup table: used to indicate if version 15 or 16 of the solution is used. For the 16th, we can also indicate if we use the “lower price” Method or some other in the case that we have extended it with its own functionality; what type of documents it applies to (Sales, Purchases, or both); and the type of line, or Type of asset (Products, Resource …).

For example, with the following configuration we will have activated the price calculation type of version 16 for product purchases and sales, but version 15 for resource sales.

  • Price Calculation Setup Table: dragging the Method, Type, Asset Type and Implementation fields from the previous configuration, we can indicate what type of implementation we want to select at the source Group level (Customer, Supplier or Project) and its code. It can also be done at the Asset No. level, in the event that the configuration in the table above is separated by “Asset”.

For example, in the following image we see a configuration in which we have activated the price calculation type of version 16 for sales of Client 10000.

  • Table Price List Line: it is the equivalent to the previous tables of sale prices, purchase prices, sale discounts … but unified all in one. According to the Amount Type field, it is indicated whether it is price, cost or discount.

With the combination of Type provenance mov. + Code provenance mov. it is indicated if you want to apply to all customers / suppliers, one in particular, a price / discount group … (which previously corresponded to the Sales Type field in prices and sales discounts).

By the combination of Asset Type + Asset No. we indicate if we want a product, resource, groups … (what was the Type before); and the other fields of minimum quantity, dates, price, cost … are already known.

  • It is also important to note that the Price calculation method field has been created in customers, suppliers or purchase / sale configurations. The first tests indicate that it will be useful in case we want a different method to be applied to the one of the “lowest price”.

In conclusion, although at first glance this functionality seems like a very big change, the impact should really be minimal, as we believe that the configuration tables in most environments will simply be to activate one line for purchases and another for sales, related to the implementation V16 and rarely will another or in more detail be used.

Regarding the Price List Line table, there are some processes (CopyFromToPriceListLine codeunit) that transfer the records of the old tables to this new one, so it should not result in any problem either. The only important thing is that the configuration of prices and rates from the publication of this novelty is unified in a table.