Dynamics 365 Finance

Hi,

there is a mistake in the Accounts Payable parameter - Ledgers and Sales Tax page.

In the "Cash flow forecast" area, field "percentage of amount to allocate to cash flow forecast", if you hover with the mouse, you forgot the s in the word "transactions". Correct please.

Idea Summary:

In Microsoft Dynamics 365 Finance and Operations, within the Advanced Bank Reconciliation functionality, the matching rules allow users to perform automatic actions such as "Generate Voucher." However, when using this action type, it is currently not possible to input or assign a financial tag (also known as a financial dimension tag).

Proposed Enhancement:

Extend the capabilities of the "Generate Voucher" action in reconciliation matching rules to allow users to specify a financial tag. This would ensure that vouchers generated during reconciliation are properly classified and aligned with financial reporting requirements.

Business Value:

• Improved accuracy in financial reporting through better tagging and classification of generated vouchers.
• Enhanced automation by reducing the need for manual voucher adjustments post-reconciliation.
• Consistency in financial tagging across all types of transactions, including those created automatically via reconciliation rules.

Use Case:

A company that uses financial tags extensively for internal reporting needs to ensure that all transactions, including automatically generated vouchers during bank reconciliation, carry the correct tag.

Suggested Implementation:

• Add the Financial Tag field as an editable input option when configuring the “Generate Voucher” action within the reconciliation matching rule setup.
• Ensure this tag is applied to the resulting voucher transactions.

Enhance the Cancel and Correct functionality for product receipts (AP)/ Packing slip (AR) to ensure consistent financial audit trails. Specifically, ensure that a voucher is always generated when using the Cancel or Correct actions, regardless of whether the "Post product receipt in ledger"/ "Post Packing slip in ledger" parameter is enabled or not at the time of correction/Cancellation.

This enhancement addresses scenarios where configuration changes during the process lifecycle can lead to inconsistencies in ledger postings.

Business Scenario:

Initially, the customer enables the"Post product receipt in ledger"/ "Post Packing slip in ledger" parameter, so product receipts (AP)/ Packing slip (AR) generate vouchers. Later, the customer decides to disable this parameter. If a user then attempts to Cancel or Correct a product receipt that previously generated a voucher, the absence of a new voucher causes inconsistencies in ledger transactions and inaccurate financial reporting. This enhancement ensures transactional consistency and compliance by aligning the reversal with the original posting method.

We have observed that the OCR module currently does not provide a dedicated section or notification mechanism to identify rejected invoices. This is causing challenges in tracking and addressing such cases in a timely manner. I would like to check the feasibility of implementing a notification feature. (email or in-app) for invoices that are rejected during OCR process.

We propose enhancing the Product Lifecycle State configuration in Dynamics 365 Finance and Operations by introducing separate toggles for “Purchase Order Generation” and “Purchase Order Receiving” under the Enabled Business Processes section.

Many organizations, including several of our customers, need the ability to phase out Released Products in a controlled and operationally efficient way. A common and practical requirement is to allow existing Purchase Orders (POs) for the item to proceed (i.e., continue receiving and invoicing), while preventing the creation of new POs for the item going forward.

Currently, the only method to manage this is by modifying the item description to include a manual note such as “Do not order,” which is prone to error and lacks enforcement by the system.

In the Product Lifecycle State configuration, the existing “Block Purchase Order” option disables both Purchase Order Creation and Purchase Order Receiving. This eliminates the ability to support in-flight procurement while blocking new activity.

We suggest introducing two distinct options: one to enable or block Purchase Order Creation and another to enable or block Purchase Order Receiving. This would provide precise control over the product’s procurement phase and better support phase-out and obsolescence planning.

If separating PO actions is not feasible in the short term, an alternative solution would be to add “Purchase Requisitions” to the list of processes available in Enabled Business Processes. Since most procurement flows are initiated through requisitions, this would allow organizations to restrict early procurement steps while still allowing open POs to complete.

This enhancement would support more sophisticated product lifecycle management practices, reduce reliance on manual workarounds, prevent unintended purchases of obsolete or restricted items, and better align D365 with real-world supply chain practices.

Select "JBA(JP) - Format A" for "Import format" in "Methods of payment".

Specify any string for "Document" in the "Journal names" setting.

After selecting the "Journal names" created in the Journal in "Customer payment journal" and importing the JBA format file in "Import payments", the "Document" field in the imported line is Blank.

The string value set in “Document” in the "Journal names" screen is not retained.

Since the "Document" field value is retained when creating records using the "New" button or when using the payment proposal, the same behavior is expected when creating records through payment import — the "Document" field should also be carried over.

Regards,

Currently there're no official electronic reporting configurations for Malaysia ISO20022 credit transfer to use for vendor payments.

This makes it difficult for users who want to perform this process within FnO.

Each cost invoice captured by the app is currently created as a sperate Invoice Journal in D365 Finance - i.e. a one-to-one relatonship between invoice an Invoice Journal.

This causes a lot of records on the invoice journal grid and makes it hard to navigate and search for a specific journal. In addition the description on each journal is vague which makes the task of looking for a particular journal even more difficult.

Suggestion: Group all cost invocie over a given period of time in one journal - where each invoice is a separate voucher within the journal. The attachments would be at the voucher level.

Currently, reversing a purchase order invoice in Dynamics 365 involves a multi-step process that includes creating a purchase return order, selecting the specific invoice to be reversed, and then posting the reversal transaction. This process is time-consuming and can lead to inefficiencies for users managing frequent invoice reversals. To enhance user experience and operational efficiency, we propose implementing a single-click functionality that enables users to reverse a purchase order invoice directly from the invoice or related form. This feature would automate the reversal process without the need to create a separate purchase return order or manually select the invoice, streamlining the workflow and reducing the risk of errors. By simplifying invoice reversals into a single action, this improvement would save time, reduce user effort, and improve accuracy in financial transactions.

For blanket PO scenarios in indirect procurement space there's a possibility where the PO document might have been fully invoiced as the initially allocated funds have already been used up. But we can expect fresh supplier invoices as the project may not have been ended from supplier endpoint and they would require additional funds to be allocated.

On such occasions, the Accounts Payable team will expect the invoice capture application to allow them to associate the invoiced blanket PO document with the captured invoice that can then be transferred to D365 pending invoice queue.

Once transferred to DAX, they will coordinate with global indirect procurement team to add additional funds to the invoiced PO by adding line items to the PO document and thereby allocating extra funds that the pending invoice can be processed against.

Currently, only fully or partially open (open order, received etc.) purchase orders appear in the purchase order lookup menu for the captured invoice in OCR. It will be extremely beneficial if this can further be extended to associate invoice purchase orders to the list to accommodate similar blanket PO scenarios.