on Modern bank reconciliation is enable, vendor/Customer payment transaction can be Posted directly from bank statement.

System should allow an option to either create journal and post OR post automatically the journal.

Users want to control journal before any validation as business process may be complex.

If transactions are incorrect, all reversal will be complex and bank reconciliation a mess.

It is difficult to fully trust a system (at least at beginning) and the option to not post directly journal will help our customers.

When generating the report the information displayed is the same for all legal entities.

It is necessary to include a filter by company for the information to be displayed correctly. It is suggested that the information be displayed based on the legal entity from which this report is generated.

Currently, there's no quick and easy way (from the UI/front-end) for users to find about on which PO Invoices specific Prepayments have been applied to, particularly if they’ve been applied to more than 1 PO invoices.

One suggested workaround is to check via the Prepayment reversal form (> Accounts payable>Vendors>All vendors – select the impacted Vendor> Click Invoice tab>Prepayment>Reverse).

Aside from that workaround being a cumbersome and very manual process, you will also not see from the Prepayment reversal form any applied Prepayment transactions if the PO Invoice they’ve been applied to had been adjusted through foreign currency - exchange rate adjustment process.

We need to have some form of Prepayment application inquiry form, where users can see all Prepayment invoices lines and the PO Invoice that they’d been applied to = i.e., if a Prepayment invoice has been applied to more than 1 PO Invoices, we should show all Prepayment application lines and not just one.

In the trial balance and in the voucher transactions forms balances from multiple currencies can be presented:

Transaction Currency

Accounting Currency

Reporting Currency

In the voucher transactions form the Transaction Currency abbreviation is mentioned for each transaction in the column 'Currency', but the abbreviations of the Accounting Currency and Reporting Currency are not visible. You need to find these at the Ledger setup. Not all users have access to this option (or it costs time to find these) and when you work in many legal entities with different currencies you can make mistakes in the interpretation of these columns.

I think it would be an improvement to present the symbol or the abbreviation in the Accounting Currency and Reporting Currency column headers in at least:

The trial balance form columns: Opening balance, debit, credit, Closing balance (including the Reporting currency balance columns when the accounting currency and reporting currency are different)

The voucher transactions form columns: Amount, Amount in reporting currency

Example:

Trial balance column header names in a legal entity using Accounting Currency EUR and Reporting Currency USD:

Opening balance (EUR), Debit (EUR), credit (EUR), Closing balance (EUR), Opening balance – Reporting currency (USD), Debit – Reporting currency (USD), Credit – Reporting currency (USD), Ending balance – Reporting currency (USD).

In AX2012, open balance transactions were created in accordance to current account structure and fixed dimension values setup.

Unfortunately, this very useful option is for some reason no longer available in D365.

The reason, why this option is so useful is, that in case users changed the account structure - add or remove financial dimensions or define new default dimension values on ledger accounts - based on their organizational changes, the old transactions were in most cases automatically adjusted to the new setup with the opening balances.

Currently, users would need to do the manual correction before they make adjustments to accounting structure and fixed dimension values. But they usually do not think of it and if they want to do corrections later, they need to revert the changes in accounting structure and financial dimension values, which is not recommended. Updating subledger accounts to the new setup is even more challenging.

If removing this feature was requested by some clients, it should still be available for others by including it as a feature or as a setup option.

Posting simulation is very useful, it saves time by ensuring accuracy of the invoice before being sent for approval, or posting.

In case you are using AP automation and pending vendor invoices for all types of invoices, the option to simulate posting is even more appreciated.

The feature is already available, however, after various issues encountered, we propose the following enhancements:

1. All the simulation errors should be displayed at once (e.g. missing financial dimensions, period not open):
2. The current system design logic is to skip other validations when the first error is found;
3. Validation for approval check should be skipped during the simulation:
4. Currently, the invoice simulation status is always Failed, until the review (part of the approval process) is performed;
5. The simulate posting button shuld also be available in the pending vendor invoice form:
6. Currently, the button is only available in the pending vendor invoice list.

We can only generate payments interactively. Generating payments interactively requires we hit the WAIT button every 10 minutes. Why do we not have the option to run in batch processing? Please offer batch processing for this process. We have been forced to break up large check runs into many small batches which is very inefficient and increases risk with all the manual intervention.

Due to the vendor invoice posting on the date earlier than the product receipt date the client experiences a misalignment that generates a negative inventory balance at the end of the month. 

Currently in D365 there is no automatic feature/parameter or something alike that can prevent users from backdating transactions, means at the step of the vendor invoice posting the system does not give any error controlling the dates of the invoice and receipt postings.

Therefore the idea is to make it possible to receive an error in this case to avoid invoice posting on the date earlier than the receipt date and hence avoid any future misalignments. The error would be driven by setting a parameter that can be activated o deactivated.

There are some things in place to automate the process of placing Billing Schedule lines on Hold or Terminate them in bulk. This can be done through the periodic tasks and through the Odata entities created for this. However, these processes miss some options.

First of all, all current options ignore the fact that Holds and Terminations can be placed on Billing Schedule header level as well on each Billing Schedule and not only on line level. It would help a great deal in processing and keeping all lines in check placing these Holds and Terminations in bulk on header level, making sure all underlying lines are taken into account as well. Making this possible in the same manner as now done for the lines (through a periodic task and through Odata) gives us all flexibility in processing the Billing Schedules within the application but also from an integration perspective.

Also, it would be very beneficial to not only be able to remove Holds through Odata and periodic tasks, but also to be able to remove Terminations (as can be manually done on each header and line that has a current termination). This makes processing things in batch and correcting mistakes of placing Terminations in large amounts also a lot more user friendly.

Invoice automation is only available for vendor invoices imported from data management. It would be really useful if this functionality is extended to invoices submitted by the vendor from the vendor collaboration workspace.