Dynamics 365 Finance

Please have a dark mode within the app. A black/dark grey background with white/light grey text will be highly appreciated.

In Organization administration > Organizations > Legal entities it's impossible to set that the primary address is not primary any more. The only thing we could do is to edit the existing primary address with new one (because LE changed their headquarters). Now, when we print already posted invoices, a new address appears on them, and in our country, it is forbidden to change such information on already posted documents. 

Idea is to be able to change the Expiration date on the primary address (by default is Never) so that the old address remains on the already posted documents, and the new one on those created after the change. Or another solution- to be able to set completely another new address primary, while the old documents stay intact.

Starting from 01.01.2025 it is mandatory to be able to receive electronic invoices in B2B Business context in Germany. The legal requirement will be implemented in steps depending on company size etc.

However Microsoft released the ability to send Electronic invoices via xml in the ubl syntax. So far so good.

This is meeting legal requirements.

When receiving invoices however customers are dependent on what format the vendor sends and are not allowed to deny a transmitted invoice. There are 2 main formats used: Zugpferd and XRechnung. While MS decided to go for a standard solution with the XRechnung the vendor can still choose between the syntaxes UBL or CII. So far MS does not cover the import of CII which is a legal requirement as described.

This functionality should be added since it is a must!

Cashbook transactions, the transactions that do not appear on the bank statement, for example, when cheque has been raised and then cancelled internally, cannot be viewed in Reconciliation relations for audit purpose and their reconciliation cannot be cancelled. Cashbook transactions can be easily reconciled from Bank transactions screen, however when the user wants to see the reconciliation relations, the screen is empty. Also the user cannot cancel the reconciliation, if the reconciliation is done in error. The current workaround suggested is to upload a dummy bank statement and reconcile the cashbook transactions against the dummy bank statement lines, which is a lot of extra work.

Many forms, typically those for journals, have locked filters that get populated with user id's and user group id's specific for that user. That makes sharing workspace objects for those journals impossible, because the importing user cannot make changes to the existing filters.

Trying to import a workspace with such a form included on it, even if the user is a System Admin, results in the following error:

"The imported document contains one or more personalized lists or tiles that failed security validation and cannot be used in this workspace. The list(s) that failed validation has been removed from your workspace."

Those filters should be using methods that provide the appropriate results regardless of the user running them. An example of this is how other forms, like "My cases" work.

There is a forum post, https://community.dynamics.com/365/financeandoperations/f/dynamics-365-for-finance-and-operations-forum/275653/user-personalization-import , that includes details on how one user implemented such filters via customization to overcome this issue.

Within Accounts receivable parameters > Update > Invoice there is a parameter called "Default language for sales invoices". This parameter can be set to "Order account" or "Invoice account".

When selecting "Order account" the invoice will always be printed in the language that is stored at the customer account that is currently selected within the sales order - that's fine.

When selecting "Invoice account" in the parameter then the invoice will always be printed in the language of the invoice account that is stored at the customer account at the time when the customer is selected. Though, it can occur that the invoice account will get changed on purpose within the sales order. The new invoice account might have a different language stored. But the invoice is not printed in the deviating language.

This leads to the fact that in these cases the invoice will be printed in a language that the invoice account doesn't speak, neither maybe does the customer account. So, none of them would understand the invoice properly.

The idea is that by setting this parameter to "Invoice account" the system will always consider the invoice account, that is currently selected in the sales order, and not the default invoice account language of the customer account.

Current situation

It is not possible to change the parent amount on the billing schedule line entity. In case an update is processed on the billing schedule line entity for the parent amount for example via Excel add in or dual write, the parent amount is not allocated to the revenue split child lines.

With 10.0.42 it is possible to change the parent amount directly in the billing schedule form and the amount is correctly allocated to all child lines.

Suggested solution

Similar to the behavior in the billing schedule form, it should be possible to change the parent amount via the billing schedule line entity and the parent amount is allocated to all child lines, so that the same process can also be used via interfaces such as in the standard via dual write.

We could reduce the operational cost for our customers drastically if we had the possibility to disable certain indexes that come with standard F&O that are not used in the context of a customer.

In AX 2012, it was possible to achieve this by setting a SysDeletedObjects config key that was disabled through overlayering. Unfortunately this is no longer possible in D365FO. I believe it should be possible to safely use the same strategy through table extensions, at least for nonclustered and non-PK indexes.

Bonus point if we also get insights in the index usage of the production environment through the SQL DMV dm_db_index_usage_stats to perform this exercise properly.

Database logging offers a possibility to track changes that all users make to specific tables. This covers the scenario when a company needs to have control over changes that are made to critical data, however it does not cover the scenario when a company needs to have control over changes that are made by critical users. For example, there is a regulatory requirement for pharmaceutical companies to record an audit trail for user with admin privileges. To cover this scenario we would need to be able to track changes that specific users make to all tables.