Wim Van Eynde Solution Architect

With tax calculation method Total, the detailed tax calculation is not stored when the total amount is 0.

I would suggest to always store the detailed amounts on line level. This shouldn't be a big change, since the calculation already happens (otherwise you wouldn't know whether the total result is 0 or not).

This will allow to use the breakdown on line level in several functionalities (eg reporting on specific lines, writing off specific lines etc.).

It is possible to use advanced date queries in views and entities as described here. However, these date queries only make sense when they are evaluated dynamically: in the current solution, the date queries are stored as a static date that is determined during the database synchronisation (typically as a part of the installation of a release).

It would be good if this behaviour was changed to use dynamic dates instead, based on the current datetime (and the timezone).

An example of a view that is defined as "all invoices with an invoice date in the future":

In the current solution, the view looks like this:

select INVOICEDATE from CUSTINVOICETABLE

  where INVOICEDATE > '2022-08-17 06:35:15'

With a dynamic date determination, it could look like this:

select INVOICEDATE from CUSTINVOICETABLE

  where INVOICEDATE > SYSDATETIME()

Thus, the change should take place in the database synchronisation, where the views/entities are created.

The documentation suggests there are no limitations when setting up party relationship types:

https://learn.microsoft.com/en-us/dynamics365/finance/accounts-receivable/location-relationship

However, some relationship types are not supported and will result in unexpected errors. I consider this a bug, but PG team claims this is an (undocumented) feature, see support case 2412191420001753.

Ideally this bug should be fixed, alternatively the behaviour should be documented in the documentation (which essentially comes down to documenting the bug as a feature).