Dynamics 365 Finance

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 feature "Awareness between ledger settlement and year-end close"

Enforces the users to settle on the same account and same year.

At the year end user must settle the open account against the year-end closing transaction.

This feature solves so many problems in closing the year and revaluation.

The only problem with this feature is that if you made cross-year settlements in previous years the feature doesn’t allow you to proceed.

I hope that this feature will be upgraded, and a new parameter will set the validity of the feature so I can use it, since there is no way I can open settlement from the last three years.

When activating the credit management checkpoint 'Release to warehouse' for blocking rules, when a sales order line is released to warehouse the total amount of the sales order is checked an not the amount of only the released sales order line(s). When the checkpoint 'Packing slip' is used, only the amount of the sales order line is checked, so both options works different.

Also when you release the sales order line with the 'Release to warehouse' credit hold checkpoint, the total sales order is released for credit hold and not only the sales order line you want to release to warehouse.

The suggested idea is to let the 'Release to warehouse' checkpoint work so that only:

• the released sales order line values will be checked and not the total sales order value.
• only the sales order line will be released for credit hold that needs to be released to warehouse and not the total sales order.

New validation was implemented (by hotfix ID 1025443) to ensure that no cross-year ledger settlements exist before enabling the "Partial ledger settlement" GL parameter. It should prevent problems with out-of-balance error during the year-end close.

This validation makes sense only when the "advanced awareness option" is enabled in the current - open - fiscal year, which may have transactions settled with transactions from previous years and the customer wants to enable "Partial ledger settlements" in the next step. In this scenario, validation should block enabling "Partial settlement" because once partial settlement is enabled, "Enable advanced awareness options" (GL parameter) will be permanently enabled. And cross-year ledger settlements are impossible to reverse when "Enable advanced awareness options" GL parameter is enabled. If cross-year ledger settlements are kept, they will cause an out-of-balance error during the year-end close. It will be hard for the customer to mitigate the issue in this situation.

However, if "advanced awareness options" was enabled before closing the previous year, the cross-year settlement reversal for that year was performed and year was closed correctly. According to documentation, ledger transactions that are settled across fiscal years could remain settled if they weren't settled against a transaction that was posted into year that's being closed.

Therefore, there should be no problem with the year-end closing process in the current year, which was open with enabled "advanced awareness options" and without any cross-year settlements, even if partial settlements were enabled.

When using the Invoice register, the Due date will not be updated based on the setup on the Purchase order header. The Due date from the Purchase order header is not going to be updated on the Pending vendor invoice. It will not be possible to maintain the due date manually.

We have posting layer in General ledger module. 

We have custom posting layer 1 to 7 .However we do not have a provision to name the layers from the screen itself.

We had a provision to rename posting layers in Project module ->Project parameters in AX 2012 , from the screen itself, where we can rename the posting layers which in turn updates the labels.

Similarly we should have an option to rename the labels for Custom Posting layer 1 to 7 from the UI itself without customization. This would be helpful for reporting

When I try to generate a free text invoice from subscription billing schedule the sales tax group of the customer is not inherited to the free text invoice an I get an error message that the free text invoice can not be created.

The sales tax group should be inherited from the customer.

In the Netherlands it is mandatory to apply the WIK (Wet Incassokosten/Law Collection Fee) on a collection. This is a fee which can be calculated based on a percentage of the outstanding balance stated on the collection letter.

The minimum fee amount is €40,- and the maximum fee is €6.775,-. However in between the fee is calculated based on a percentage:

To 2.500 -> 15%

The next 2.500 -> 10%

The next 5.000 -> 5%

The next €190.000 -> 1%

Above €200.000 -> 0.5% with a maximum of €6.775,-.

We considered using the standard functionality, however this fee is fixed. Secondly we considered to use the interest note functionality, however this is a different document than the collection letter. Thereby this functionality is working slightly different, it is calculating the percentage per range based on the total of the collection letter. So in case the collection letter value is €3.000,- (and we apply the same logic as stated above), the calculated percentage is 10% instead of 15% based on the first €2.500 and 10% over the last €500,-.