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.
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.
When looking for an GL-account, for example in General ledger > accounts > main accounts there is no possibility in Operations furthermore to directly have a look on the postings. Instead a time consuming trial balance has to be run (for all accounts) before the account can be selected to view the transactions. From the technical point of view this may be ok. But from the view of an accountant not. An accountant needs the possibility to quickly access the transactions of a main account like he could in former Ax-Versions.
D365 ships with a lot of automatic financial dimensions such as the customer, vendor, project, etc., which are automatically crated at the time a new customer, vendor, project, etc. is created.
Quite unfortunate is the fact that those financial dimensions are automatically created but not automatically assigned. That is, even though a financial dimension for a customer, vendor, Project, etc. is created, users have to assign that value manually to the customer, vendor, Project master.
Create new parameters that allows setting those financial dimensions automatically without any user interaction.
Thank you and best regards,
Suggested by Microsoft – Under Review – 5
Category: General LedgerCustomers Group structure includes many companies e.g. 20 companies in one or many countries. Intercompany transactions need main account at least for IC accounts receivables/payables, sales, purchases. In this scenario with current standard functionalities customer would need to setup many intercompany main accounts. Worst case this might mean many hundred intercompany main accounts. We have not done this but created just few intercompany main accounts and use with this one dimension to separate transactions inside main account. So we have dimension with values of legal entity e.g. in contoso USMF, USSI etc. We would like to have this dimension option to be available in needed intercompany functionalities in AX/Operations e.g. creating intercompany invoices (customer/vendor) and in adjustment. We have faced modification needs in Project accounting but this concerns many other modules too.
7 additional posting layers have been added in Dynamics 365 for Operations - I would like to suggest that the names of these additional posting layers can be changed to reflect what the individual posting layer is used for (preferable with the ability to provide language specific descriptions)
I would be great to have the ability to show and edit and filter the financial dimensions on the grid. This will help clients to easily identified the dimensions of the records across the system.
Before AX2012 we have ability to put financial dimensions on the grid, without any modification. This was one of the most common requests that we received from our clients.
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 Dynamics 365 for Finance and Operations, Trial Balance (General Journal > Inquiries and reports > Trial balance) is displayed with Main accounts and Dimension segments in separate columns. This is enabled by the parameter "Display segments in separate columns". Hence, when the Trial Balance is exported to excel, all segments are exported into separate columns in Excel too.
Similar functionality is also required in all other places where we view financial transactions viz. Voucher transactions (General Journal > Inquiries and reports > Voucher transactions). Currently, when Voucher transactions (posted data) are exported into excel, segments and main account is combined into a single column, and hence not understandable which segment value belongs to which Segment.
Companies who works with a double ledger : one statutory in EUR (= accounting currency) , one IFRS in USD (= reporting currency).
Their mandatory need is to be able to obtain, in real time, a direct valuation in their reporting currency (USD) of all their inputs entered in transaction currency (whichever it might be).
Example : If the transaction currency is GBP, the accounting currency is EUR and the reporting currency is USD, we need to convert GBP to EUR and GBP to USD.
Of course, all foreign currency revaluation processes (customer, vendor and general ledger modules) have to follow the same rule of accounting.