Dynamics 365 Finance

Actually in the free text invoice templates, the “Description” and the “Invoice text” fields are linked only when a Billing code is selected.

The Idea is to unlock the "Invoice text", to be able to enter a free text. So, the value can be different between the "Description" field and the "Invoice text" field.

Invoice capture - Cost Invoice - Need to support multiple lines in Tax Invoice journal.

When a reclassification is carried out, the last date of depreciation is overwritten with the acquisition date of the reclassified asset (reclassification date) instead of keeping the date of the original asset.

If reclassification date is in the middle of depreciation period, this will cause to inaccurate depreciation calculation of new fixed asset.

(KB595453)

In real business practice, fixed asset reclassification can happen at any time during depreciation period. It does not make sense when new classified asset takes reclassification date as last depreciation run date.

Manual task to correct last depreciation run date in asset book can be replaced if last depreciation run date is copied from Original asset.

We have an asset with depreciation adjustment transactions created during life use. 

When disposing off the asset, system will always generate Depreciation adjustment to reverse the created ones, even we turn off all parameters relating 'Auto create Depreciation adjustment' from FA parameters and FA Book. 

That being said, as long as depreciation adjustment transactions exist during asset life, the same transaction type will be automatically created when disposing off the asset.

We need to prevent creating Depreciation adjustment automatically in this situation.

We need a feature which allows users to reject duplicate AP invoice number across legal entities. This will help users to avoid creating duplicate AP invoices in other legal entity.

We actually think a warning message will improve accuracy and user experience for the following scenario:

When user disabled "Amounts include GST" in general journal, the system will add GST on top of the entered debit amounts. Now, the system will adjust the credit side without any warnings. By right, it should warn the users that if the GST is added, the debits and credits are not balanced first. 

This is similar to LCS issue 665443.

We have needs to filter the data on transaction level based on Dimension and Main Account for Customer Aging Report and showing the Main Account and Dimension on Report when using option Details = Yes.

Currently, users need to apply more filters or split the date range to reduce data volume when it comes to exporting a large amount of data.

We need an enhancement on available options such as Export to Excel, Open in Excel add-in, Reporting, Data Management to have a more efficient data export for large amount of data.

It would be good to see improved validation around vendor bank account details, particularly the account and routing numbers.

There are two main areas where this could be addressed. The first is at the point of creating or editing the vendor bank account. This would need to be configurable, as the right validation will depend on the bank the company is paying from, but this is the best point at which to catch errors such as existence or lack of special characters or numbers that are too short or long.

The next point at which to implement further validation is in the electronic reporting payment configuration. For example, the maximum field length for an account number in the payment configuration is 9 characters, but the user has entered the account number with a space, meaning that it is 10 characters. Some of the standard configurations, such as CBA Direct Credit Service (AU), simply truncate the number, meaning you finish up with the wrong account number without knowing it. It should return an error instead.

With the "Enhancements to bank foreign currency revaluation feature", system is allowing the summarization at the journal name level and summarization on the bank account entry (by enabling Summarize amounts in bank account’ in your Journal names).

Accordingly, the system will ignore the dimensions because it would not know which ones needed to be put into the transaction.

As a result, when running Bank FCR, the voucher transactions will also be generated without dimension.

In Australia region, customer must pay for each bank transaction. By implementing “Summarise amounts in bank account”, it reduces the total cost against bank transaction. However, summarization cannot fetch the financial dimensions when running FCR. Meanwhile, turning off summarization function might allow us to track until dimension level, but it will lead to the financial impact with the dramatically-increased-cost due to paid amount per bank transaction line. 

Upon the above points, it's necessary to improve the function, in which the Dimension values can be retrieved in bank revaluation voucher even though FCR is run against summarized bank transactions.