Salvador Espinosa Support engineer

To run tests and demos, you need to activate the tool called Customer Payment Predictions. This is not possible without first installing a plugin called Finance Insights. The problem is that if you have a UDE environment, this is not possible, which does not allow you to run tests or demos of the tool. Therefore, it would be great to have this plugin in the UDE environment and not just in the LCs self-service environments, which helps with more processes in the system and not just for payment predictions.

When generating electronic accounting reports, the system inverts the balances, whether debit or credit, that have a negative sign, which causes my balance to become unbalanced. This results in the information being rejected by the authority (SAT).

In budget planning, when adding the lines and selecting a revenue account, the budget class field automatically has the value of expense and not revenue. This can be modified manually, but ideally it should come by default depending on the account type in the main account configuration.

When generating an invoice proposal from project operations, it is not synchronized in d365 f&o. The characteristics of this invoice proposal are that it is "0" and is not chargeable.

This request is for the system to synchronize invoice proposals in in d365 f&o. when generating invoices from project operations with "0" as non-chargeable.

Today this would be inconsistent data between project operations and in d365 f&o.  This request is to ask the “0” invoice to be consistent with Project Operations and FSCM.

Contracted Invoices - consistent with all Invoice Proposal.

Problem Description:

Currently, when generating vendor payments using the check payment method, the system automatically voids the payment if more than 36 invoices are included. While the system can print multiple pages, starting from the second page, a “void” message appears, and the payment is invalidated.

Additionally, it causes gaps in check numbering, since voided checks are still counted in the sequence, leading to confusion and audit complications.

Customer Impact:

This behavior significantly limits the system’s functionality. Users are forced to manually split payments into batches of 36 invoices or fewer. This slows down the process, increases the risk of errors, and adds unnecessary manual effort.

Why This Should Be Changed:

• More intuitive: The system does not warn users about this limitation in advance, leading to confusion and wasted time.
• More scalable: Businesses that handle high volumes of invoices per vendor cannot automate their payment processes efficiently.
• Clear justification: If the system supports multi-page printing, it should not void payments based on an arbitrary invoice count.
• Real-world alignment: Users need the system to reflect operational realities, where settling more than 36 invoices in a single payment is common.

Proposal:

Update the system design to allow more than 36 invoices in a single check payment without triggering automatic voiding.

Description:

In the Mexican localization of Dynamics 365 Finance and Operations, the system currently requires users to manually activate the "Foreign trade" checkbox in order for the Registration Number (foreign country tax ID) to be inherited when creating a sales order for a foreign customer.

This occurs even when the registration number has already been configured in the customer record. If the checkbox is not selected, the field remains empty, which can lead to compliance issues or data inconsistencies.

Proposal:

We request that the system automatically inherit the foreign country registration number from the customer record without requiring the user to activate the "Foreign trade" checkbox. While the checkbox can still be used to enable other fields like Commodity Code or Intrastat data, it should not be a prerequisite for inheriting a value that already exists.

It is requested that the purchase order number, invoice number and vendor appear in the fixed asset book master if the process starts with a purchase order (the fixed asset is created) and ends in an acquisition journal (the fixed asset is acquired), because when it is done from that process, the data does not appear in the master.

and there are certain criteria and necessary points for which this is important to be modified in future versions:

Industry Standard Requirement – Audit & Traceability

Fixed Asset (FA) acquisitions typically originate from Purchase Orders (POs). Even when assets are capitalized via acquisition proposals (CIP clearing), the PO remains the business origin. Without linking the PO and its dimensions to the FA card and acquisition transaction, auditability is compromised. A clear trace from PO → Invoice → CIP → Asset is essential for compliance.

Financial Dimension Consistency

Dimensions such as cost center, project, and plant are applied at the PO and invoice stages to support budget control, reporting, and approvals. If these dimensions are not carried into the FA acquisition journal, reporting becomes inconsistent—Trial Balance by dimensions no longer aligns with asset balances, undermining D365’s dimension-driven reporting.

System Design Inconsistency

D365 allows FA card creation at receipt but omits dimensions during acquisition, creating a disconnect between procurement and finance. This inconsistency contrasts with inventory capitalization, where PO number and dimensions are tracked end-to-end.

Operational Impact

For some customers, CIP is a critical interim step for invoice approval and project validation. The current system forces a choice between:

• Direct PO acquisition (bypassing CIP validation), or
• Journal-based acquisition (losing PO reference and dimensions).
• Neither option fully supports compliance or reporting needs.

Expectation of a Modern ERP

D365 are expected to offer built-in financial traceability and consistent reporting. The current limitations in FA processes lead to manual workarounds, increasing risk and reducing system reliability.

Requested Resolution / Enhancement

We request to address this product design gap by:

• Enhancing FA creation at product receipt to inherit PO financial dimensions and carry them into the FA journal.
• Ensuring the FA card retains a permanent link to the originating PO, regardless of acquisition method (PO or CIP).

This enhancement is critical—not optional—for financial compliance, audit traceability, and consistency across procurement, CIP, and asset accounting.

We suggest adding a dedicated configuration option in credit management settings to handle direct delivery orders differently from regular orders.

Currently, the system applies the same credit blocking rules to all order types, which causes unnecessary holds and manual reviews for direct delivery orders—even after the product has already reached the customer.

Customers want these orders to flow through without further credit checks once released.

However, skipping credit checks entirely is not acceptable for regular orders. That’s why we propose a separate configuration that allows tailored behavior for direct delivery orders—preserving necessary checks for standard orders while streamlining the process for direct deliveries.

Additionally, error messages like “release reason is mandatory” appear even when a reason is provided, which adds confusion.

This enhancement is important because it would:

• Reduce manual intervention and delays for direct delivery orders.
• Improve operational efficiency and customer satisfaction.
• Preserve compliance and control for regular orders.
• Provide flexibility to meet diverse business process needs.

The consecutive number used to generate dmuisca files always ends in 1 and is not consecutive, forcing the client to manually modify the file name. If uploaded this way, an error message appears when uploading it to the DIAN government website. The DIAN government website has a counter and knows what number it should follow, and that's exactly what the file should have.

The consecutive number used to generate sample files always ends in 1 and is not consecutive, forcing the client to manually modify the file name. If uploaded this way, an error message appears. The request is for the number to be consecutive, so the client doesn't have to manually modify it, avoiding risks.

example:

File name should be like this:

Dmuisca_01010011020250000001 .xml , then Dmuisca_01010011020250000002 .xml

File name shouldn't be:

Dmuisca_01010011020250000002 .xml , Dmuisca_01010011020250000002(1) .xml

Dmuisca_01010011020250000002(2) .xml