Ian Luu

In real-world business scenarios, a physical bank account often processes transactions in multiple currencies.

However, the current system only supports bank statement reconciliation when the currency of the bank statement transactions matches the default currency of the corresponding bank account in the system.

When users attempt to reconcile bank statements containing transactions in currencies different from the bank account’s default currency, the system returns the following error:

"Bank statement currency is not consistent with bank currency."

Ideally, the system should support reconciliation of bank statements containing transactions in non-default currencies, without requiring users to create and maintain separate bank accounts for each currency.

In the header section of the Purchase Order invoice within Finance and Operations (FnO), there is a Purchase Order drop-down field that enables users to select a single Purchase Order (PO).

Many organizations rely on this field containing a PO number as a condition within their invoice posting workflows. Specifically:

• If the Purchase Order field is left empty, the invoice is treated as a non-PO invoice.
• If the field contains a PO number, the invoice is processed as a PO invoice.

Currently, the system does not support the scenario where an invoice—transferred from Invoice Capture—is associated with multiple POs. In such cases, the Purchase Order drop-down field in FnO remains unpopulated, as no PO number is applied automatically.

This gap in logic presents a challenge for organizations attempting to automate PO invoice posting via workflow, as the absence of a PO number in the field prevents the system from correctly identifying the invoice type.

Proposed Design Enhancement:

To align with the manual process in FnO, the system should populate the Purchase Order drop-down with one of the associated POs—preferably the first PO in the sequence—when a multi-PO invoice is transferred from Invoice Capture. This approach reflects current user behavior during manual entry, where the first PO added to an invoice is automatically set in the drop-down field.

Implementing this enhancement will enable businesses to maintain workflow automation for PO invoices, even in multi-PO scenarios.

Currently, the Project Transaction Adjustment functionality in Dynamics 365 Finance and Operations does not support batch processing. This limitation poses challenges when users need to adjust a large volume of project transactions, as the process may be interrupted due to browser session timeouts or database connection issues.

To mitigate these risks and enhance usability, it is recommended that a batch mode option be introduced for this function. Enabling batch processing would ensure greater reliability and efficiency when handling high-volume adjustments.

Under the current system design, enabling the parameter “Summarize amounts in bank account” within the journal name setup disables the Post and Transfer function, making it unavailable for user selection.

Design Change Request:

We recommend enhancing system compatibility by allowing the “Summarize amounts in bank account” parameter to function in conjunction with the Post and Transfer feature.

In the current design, several parameters—such as Override Transaction Date—are missing from the Recognition Batch Processing functionality compared to the Recognition Processing form.

I strongly recommend considering the addition of the Override Transaction Date parameter to the Recognition Batch Processing form. This enhancement would align both processes and provide greater flexibility for batch operations.

The system currently allows general ledger settlements for the same main account across different financial dimension values without restriction.

Example:

A transaction posted to Main Account A with financial dimension value ‘a’ can be settled against another transaction posted to Main Account A with financial dimension value ‘b’.

During the financial year-end close, the system excludes settled transactions. This can result in discrepancies where the closing balance of a main account–financial dimension combination in the previous year does not match the opening balance in the new year.

Proposed Design Change

Implement a warning mechanism in the system to alert users when attempting to settle transactions across different financial dimension values for the same main account.

Additionally, before executing the year-end close (YEC), the system should provide a warning if cross-financial dimension ledger settlements exist for specific main accounts.

This enhancement will allow users to review and reverse such settlements prior to running YEC, ensuring accurate carry-forward balances.

In the current system design, a billing schedule can only be terminated once all periods have been invoiced. However, in real business operations, there are scenarios where users may need to cancel or skip invoicing for specific periods.

The system should be enhanced to support such scenarios.

In the current design of the Project management and accounting module in the Finance and Operations application, when a purchase order is linked to a project, users are prompted to decide whether the vendor’s default financial dimensions on the purchase order header should be overridden with the project’s default financial dimensions.

However, there is no option that allows users to retain the default financial dimensions for item lines. As a result, users must manually restore the item-level financial dimensions, which is both inefficient and time‑consuming.

We would like to formally request a design enhancement to introduce an option that allows users not to override the item’s default financial dimensions when adding lines to a project purchase order.