This conceptual idea refers rather to system architecture:

In projects I face regular issues that the posting behaviour of the system is not sufficient.

The ledger integration framework comes from older Axapta versions is seems a bit outdated.

The idea is to replace the business logic-based (hard-coded) ledger integration by a "posting cockpit" where all the GL accounts are defined on a global level in one single place.

Basic concept:

1. The currently existing transactions types, posting types, posting profiles, journal types, system functions and any other accounting-related or even not yet accounting-related functional transactions are collected in a central transaction library.

2. The transaction library can be extended by user-defined transactions.

3. In the business logic, where a hard-coded posting integration is included, this source code segments are replaced by a system-wide standardised tie point that contains a set of transaction information used to post that information to the GL.

4. Basic transaction information includes:

    a. Transaction of origin (acc. to 1.)

    b. Affected quantity values: i.e. fixed assets, items, charges, bank, customer, vendor, tax information, etc.

5. In the "posting cockpit" it is defined:

    a. Design of the transaction flow covering posting-relevant and also non posting-relevant information.

    b. Link the transaction flow to business logic.

    c. Clearly defined posting entries by

        - quantities (balance sheet-related or off-balance)

        - transactions (P&L and cash flow-related) - covers also shared categories

Advantages:

 - Huge improvement of product quality: Business transaction flow instead of single postings

 - The Approach is much more flexible to define than the current static approach

 - Reduced source code

 - More flexible for localisation/customisation (as it is possible to do in the User Interface)

 - Increased data consistency (based on process flow instead if isolated transactions)

 - Additional posting entries easily enabled as required

 - Easily possible to include non-GL postings (planned, purchased, expected values)

 - Easier setup: all in one place

 - Reduced number of parameter settings in various modules

 - better transparancy of the configuration

 - Tax setup and any reporting setup can be user-defined, no need to apply localisations/customisations: ready for all legislations

If you are interested in this approach, I may give additional informations. This would be a unique selling point for Dynamics 365 for Finance and Operations compared to competitive Software.