Hansjuergen Mueller Prodware Deutschland AG

Transaction-based financial dimension:

There was an easy-to-implement possibility to largely improve GL reporting and analysis capabilities by extending the ledger integration by financial dimensions.

In several setups, a posting integration is defined by ledger account defined in the posting profiles and some additional set-up tables (i.e. item postings, resources postings, fixed asset postings, indirect cost postings, project postings, bank postings, customer/vendor postings, automatic postings, etc.).

The idea is to add financial dimensions to the main account entries. The filled dimension depends on the posting type / transaction type and brings all types of transactions together (cross-module) and hence makes it easier to run reports on GL postings on general level.

Advantages:

1. Quite easy to implement since the framework is already there.

2. Separation of quantity values from transaction values in the GL - more transparancy

3. Enables cash-flow statement according to the direct method as required in financial reporting of many groups of companies

4. Enables standard reports (tax development, provision development, cash development, fixed asset balances, inventory changes) or makes it easier to create from GL (using financial reporting)

5. Reduces number of required GL accounts

This kind of "movement" or "flow" analysis is almost always required by customers but so far hardly supported by D365. The extension brings big improvements by low effort.

In the bank management, the Central European way of posting payments is not supported at all.

In Central Europe, instead of performing bank reconciliation, all bank transactions are posted directly based on bank account statement lines. However the possibility to import and post statements to the GL is dismissed (finally the import method "Finnish Basic").

We need a link from bank statement to GL posting functionality (all ledger/sub-ledgers, mainly customers). According to what we heard in the TechConference 2016, this was already "high priority" but nothing has been released since then.

Budget register entries require "account structure" as field Information. However, according to General ledger the account structure has been clearly defined per main account. In order to fill the account structure in the budget register, it is required to investigate the account structure for each main account. This is an unnecessary extra loop and blocks the data import on GL level.

In the Expense Management, any number sequence assignment is only enabled "through the back door" in the number sequence master table.

As in other modules, pls. provide a parameter setup form where you can assign number sequences directly in the module.

The system should allow automated currency conversion in the General ledger in the following cases:

1. Profit and loss carried forward: In the year-end close, any foreign currency balances from the P&L are carried forward as foreign currency entries to the equity. However, equity is hardly recognised in foreign curreny! So a foreign currency conversion to the accounting currency is required, at least as an option in the year-end closing process.

2. Bridging accounts: In case of a bridging account, for example if payments are done in USD and the offset is posted in EUR, there should be the possibility to convert the currency to the accounting curreny. Otherwise the amounts in each curreny are cumulated up and incredibly high opening amounts are forwarded to the new business year.

In the financial dimensions setup, standard dimensions (i.e. item group) are mostly defined on company level, custom dimensions (value list) are always cross-company. For legal entity override, each single value needs to be marked as suspended. Additional values will be then shared again.

In fact real value tables are rather company-specific and can't be synchronised to that extent.

It was better to have the possibility to chose custom dimensions as either global or company-specific in order to avoid all this value suspending and get a clear separation of what is allowed to post per legal entity.

In the ledger allocation rule, the "Destination" form does not allow to keep the financial dimension (those not allocated) according to the original value.

If you want to allocate dimension 1, you need to even though define each value of dimension 2 for destination posting. This is not manageable.

Just use the logic of

Main accounts > Legal entity overrides > Allocation terms > Destination ledger account.

This is exactly what is missing in the allocation rule definition.

It would be perfect if this logic could be made available in the ledger allocation rule definition, Destination, too. As is the Main accounts table, the selection should be per single financial dimension (could also be applied in the form "Offset").

In the fixed assets area, reclassifications of fixed assets (from one group to another) are covered by a functionality in D365 (mainly from "under contruction" to the final asset group), not by a posting entry.

However, from financial reporting perspective reclassifications need to be tracked as postings. This means, we need to define

1. Reclassification (gross acquisition cost) and

2. Reclassification (cumulative depreciation)

as additional posting types, to be tracked in the GL and to be reported on in the asset balances.

This is very much a standard requirement. Since this requires at least 4 posting transactions, the background postings may be defined similar to disposals where also some additional postings to the sales/scrap main account entries are done.

The standard inquiries and reports are still very much restricted to the current companys where the user is currently working in.

Since in the accounting departments, functional responsibilities are replacing more and more the responsibilites by company, the user increasingly requires global reports and cross-company inquiries.

Hence, it would be perfect to check all reports and inquiries in each module if cross-company views and company selections are enabled and add according to this all missing filter functionalities.

In the Cost management/Inventory management, as posting setup used for the purchase process the posting types

(I) Purchase expenditure, un-invoiced (physical) and

(II) Purchase expenditure for product (financial)

are used.

However, the account is used as an offset account for both inventory accrued/final posting and payables accrued/final posting. Hence, it ends up to zero in the standard case (if applied values are equal).

In fact we should have 2 different P&L entries for

(a) the inventory offset: P&L "Change in inventory" and

(b) the payables offset: P&L "Material expense"

In order to cover this, we may define an additional charge posting. However, this was only possible for the physical posting entry and does not cover the requirement.

It was better to split up the posting type into two and allow different setting for firstly inventory offset and secondly liability offset such that we get 2 separated postings without thisoutcancelling posting entries.