Extend general ledger posting aggregations (Invoice Post. Buffer refactoring)

Source : Read here

Feature details

The Invoice Post. Buffer table has been at the center of localizations and partner customizations when changes to G/L posting are needed, or when G/L entries need to be aggregated in a different way when they’re posted to the general ledger. The previous design is not extensible because the primary key in that table cannot be changed without introducing breaking change across partner solutions and localizations. There are significant differences in this table across localizations, in particular for APAC, BE, ES, IT, NA, and RU, and this has made it difficult to extract localizations to extensions.

This refactoring makes the posting process for sales, purchase, and service transactions extensible, and enables partners to change the way the posting algorithm aggregates G/L entries—for example, by specific document lines, posting groups, or the tax setup required by local legislation. Partners can replace customizations by using the interface for G/L invoice posting, resolve legacy issues for the Invoice Post. Buffer table, and use their own implementation of G/L invoice posting.

We have removed the dependencies from the Invoice Posting Buffer table in the Base Application and built an Invoice Posting component with an interface and an extensible enum for the implementation setup.

Prepare for the new invoice posting engine!

Source: Read here

The reason for this new feature is that the table "Invoice Post. Buffer" could not easily be extended. This table is used to buffer the entries that will be created during a posting procedure. Entries are combined (amounts are added up) based on their values in the primary key, which consists of 15 different fields. A number of localizations include modifications to this table, resulting in significant changes. This includes changes to the primary key because of certain requirements to further break down the posting entries that will be created during the posting process.

The table will be replaced by a new table "Invoice Posting Buffer" (note that this table has almost the same name!) that has a different table structure. The primary key is a Text[1000] field that by default is composed of the same fields as before. But the function BuildPrimaryKey now features an event OnAfterBuildPrimaryKey that allows extending the value in the primary key with extra values.