Hansjuergen Mueller Prodware Deutschland AG

According to the existing production posting setup in the cost management or inventory management, several WIP posting entries including offset accounts are enabled:

- Estimated cost of materials consumed, WIP

- Estimated cost of materials consumed

- Estimated manufactured cost

- Estimated manufactured cost, WIP

- Cost of materials consumed, WIP

- Cost of materials consumed

- Manufactured cost

- Manufactured cost, WIP

However, in the standard case these entries will refer to inventory accounts.

What is missing and urgently required for covering financial statement requirements is to include the P&L posting applied at least for semi-finished and finished goods. This is quite a standard requirement not possible to define in the system.

The proposed solution is to provide a 4 column setup table with the possibility to define up to 2 debit account entries and up to 2 credit account entries in order to limit the amount of line entries.

In the customer group, using menu item SETUP, the possibility to enter default customer financial dimensions is enabled.

However, in the vendor group this is missing.

The idea is to provide this also to the vendor group such that default vendor dimension values are applied to any new vendor created.

In the fixed assets module, derived books trigger the same transaction types as defined in the books setup - derived books.

However, the use of financial dimensions is rather incomplete:

In the fixed asset journal, the entered financial dimensions are not applied in the derived book postings. They remain just empty.

A preset financial dimension value in the journal name definition is not applied in the derived books.

An entered dimension value in the journal line is neither considered in the derived book entry.

In the Books tab of the fixed asset journal, the applied main accounts and financial dimensions are not visible (nor editable) at all.

The only possible workaround is to enter the financial dimension value in advance into the book-related master data. However, as far as the dimension values need to be changed (according to respective transaction) this is not manageable.

We should improve the financial dimension handling in the derived books accordingly and provide this kind of basic functionality.

In some industries, the final customer invoice amount is finalised just after weighting and quality analysis on the customer's side.

The idea is to allow customer invoice adjustments at least for the net amount, and also on the invoiced quantity.

The idea is to enable an invoice adjustment that corrects the net revenue and creates a credit note (or additional invoice, respectively) for the difference amounts.

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.

For some localisations, a report is available at

Accounts payable > Inquiries and reports > Open Transactions report.

This is the by far most valuable report for the breaking down of accounts payable and pretty essential for auditing and internal controlling purposes.

So it should be activated for all countries by standard.

For some core reporting requirements, market values are essential. Not only for commodity traders, market values could be useful for:

- computing market value reserves,

- computing write-offs of inventory items to lower market value,

- providing a guideline for sales people concerning expected sales prices in volatile markets.

The handling of market values should be date-related such as it is implemented for currency exchange rates. Different market price types may be considered. Values could be connected to commodity exchanges via URL links.  

This extension would help to provide underlying data for accounting and reporting purposes.

In most implementations it needs to be made sure that the item master data contains complete values on the level of financial dimensions. For this purpose it helped very much to define financial dimension default values on the level of ITEM GROUPS which are inherited to the item master data entry.