Extend general ledger posting aggregations
Some of the functionality described in this release plan has not been released. Delivery timelines may change and projected functionality may not be released (see Microsoft policy). Learn more: What's new and planned
|Enabled for||Public preview||General availability|
|Users by admins, makers, or analysts||-||Nov 2023|
Regulations in different countries and industries, and customer business practices, might require a change to how general ledger entries are aggregated during posting.
The Invoice Posting 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 must be aggregated in a different way when they're posted to the general ledger. The previous design was not extensible because the primary key in that table cannot be changed without introducing a 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, which has made it difficult to extract localizations to extensions.
This refactoring makes the posting process for sales, purchase, and service transactions extensible. Partners can also change the way the posting algorithm aggregates G/L entries—for example, by specific document lines, posting groups, or any tax setup that is required by local legislation. Partners can replace customizations by using the interface for G/L invoice posting, resolve legacy issues for the Invoice Posting Buffer table, and use their own implementation of G/L invoice posting.
We remove the dependencies from the Invoice Posting Buffer table in the base application and build an invoice posting component with an interface and an extensible enum for the implementation setup.
This feature is currently available only for developers and can't be turned on in production environments yet.