Dynamics 365 Finance

Currently, it is not possible to recognize multiple Purchase Orders within the same invoice that is read by Invoice capture.

Within a business, it can often happen that suppliers can send one invoice combining multiple Purchase Orders.

Hence, instead of having an automated way to capture the vendor invoices, the business has to manually review the invoices and assign the right PO on each line of the PO invoice before transferring to F&O.

This has a big impact on the purpose of Invoice capture and the automation of the process to facilitate the business processes of the Finance team.

The recognization of multi PO within one invoice would be then very appreciated.

'Bulk editing in grids' is a feature On by default in 10.0.44. 

We request that this feature is never made mandatory as a user could inadvertently incorrectly mass update a grid, causing operational stop for the company and a major clean up issue. 

This feature should never be forced on clients and ideally Disabled by default, so clients have to directly opt-in.

Description:

When the year-end close process is executed, the Trial Balance Snapshot includes year-end close entries. This behavior is unexpected, as the Trial Balance report excludes these entries.

Expected Outcome:

As observed in the Trial Balance report—where year-end close entries are not included—we expected the Trial Balance Snapshot to reflect the same behavior.

As per Italian localization - Payment traceability - Finance | Dynamics 365 | Microsoft Learn the inheritance is only happening when using Payment proposal.

When the Payment process is not using Payment proposal, but instead Settlement process, the CIPE/Tender values are not inherited from the original transaction.

The requested is to extend the inheritance to other processes as well.

Thank you!

Background:

Currently, reversing a Free Text Invoice (FTI) in D365 Finance requires a manual workaround due to limitations in the reversal functionality. The reversal process does not generate a legally compliant credit note, particularly in terms of invoice numbering, referencing the original FTI and the reason for the reversal . This has led to increased manual effort, risk of human error, and non-compliance with EU invoicing regulations.

Customer Feedback Summary:

• The reversal function does not issue a legally correct invoice.
• Manual creation of credit notes is required, which is error-prone.
• Credit notes must have a unique invoice ID, as per EU law.
• Settlement between the original invoice and the credit note is not automatic.
• 
  

Proposed Enhancement:

Introduce a fully automated process for reversing Free Text Invoices that includes:

Legally Compliant Credit Note Generation:

• Ensure the credit note has a unique invoice ID.
• Maintain a clear reference to the original invoice.
• Automatically settle the credit note against the original invoice in the General Ledger.
• Eliminate the need for manual matching and reduce reconciliation errors.
• Provide a one-click reversal option that handles both document creation and settlement.
• Include audit trail and traceability between the original and credit note invoices.

When we generate check payment on a payment journal with multiple vendors, the current design is that the check number will be generated and assigned according to the alphabetical order of vendor names.

The generation and assignment of check number should be following the either the line number or the voucher number. This is a more logical behavior and aligns with the original design on AX2012.

Many customers need to export files directly to Azure Blob Storage. While this is possible with X++, there is no standard way to configure the Azure Blob connection or use these destinations with X++ and DMF.

The idea is to have a file destination configurator that allows configuring multiple destinations (Blob Storage accounts) that can be used from X++ and DMF.

For additional security control, communication to this blob storage should be possible via an Azure Blob Storage private link.

When we have a tax combination " Group and group Item' with a sales tax code shared between them with a Zero Rate it throughs an error that the tax combination is not valid.

This happened because the result of the combination is Zero, so the tax code validation read the combination as a wrong one.

To resolve that we need to turn the toggle for "Check sales tax code " to None or Warning.

But this is not the best option as we need the validation when we have a wrong combination to prevent users from proceed also we need to use the Zero rate so we trace which transactions were posted using this VAT code >tracing error or missing tax transactions becomes easier.

So the suggestion would be to remove the Zero tax code form the validation as long as the setup for the sales tax code, Item and group is correct it should proceed as normal with no error. 

For Belgian local requirement, the F01DGS report (BLWI) would enable the creation of multiple lines in case of credit notes (from customers or vendors). In case of a credit note, the original line with correct central bank code must be the base to create another line with an adapted central bank code (original central bank code + CN) with exactly the same information.

When creating the output report (XML file) this will fit the Belgian local requirement for the F01DGS report.

Description:

The customer has reported that in Budget Planning within Dynamics 365 Finance (version 10.0.43), the Forecast Position functionality is not correctly sourcing worker compensation fixed plan data from the Human Resources module.

Details:

When an existing position is added to a Forecast Position and the "Assign a compensation group" option is set to No, the system is still deriving the budget amount from a Budget cost element instead of using the employee’s compensation fixed plan.

Current Outcome:

After creating the Forecast Position and the "Assign a compensation group" option is set to No, the budget cost amount displayed is pulled from the Budget cost elements section, rather than reflecting the employee’s compensation fixed plan.

Expected Outcome:

Given that "Assign a compensation group" is set to No, the system should instead display the pay rate from the employee’s compensation fixed plan in the Human Resources module.