Ian Luu

There has been an increasing number of customers in South Africa utilizing the Invoice Capture solution.

However, the prebuilt AI model currently does not support the South African Rand (ZAR) currency. This limitation results in the incorrect capture of the currency code, requiring users to manually select the correct currency code.

This process is not only time-consuming but also prone to errors, significantly impacting efficiency.

Therefore, it is critical and urgent to add support for the South African Rand (ZAR) in the prebuilt Invoice Capture model to enhance accuracy and improve user experience.

At present, the system generates umbrella error messages that are generic and often not meaningful to end users, which complicates the troubleshooting process.

For example:

• “The selected report can’t be found. Make sure the report hasn’t been deleted, or work with your administrator to find the correct report. The report exists, but its data is missing. [An internal error occurred in the provider. An error occurred connecting to the source system.]
• <“Exception has been thrown by the target of an invocation.”, “The remote server returned an error: (404) Not found.”>”

In one actual scenario, this error message occurs when there has been a change to operational data, such as a legal entity name change, which was not reflected in the financial report design (specifically the Reporting Tree definition). However, the current error message does not point users to the specific data they need to check, which prolongs the troubleshooting process and negatively impacts user productivity.

This becomes especially problematic in time-sensitive situations, where users need to generate a large number of reports quickly to avoid penalties. The lack of clarity in error messages leads to unnecessary delays and business impact.

To address this, we propose implementing more detailed and user-friendly error messages that can guide users directly to the issue, enabling them to identify and resolve problems more efficiently. Clearer messages would ultimately improve the user experience, reduce troubleshooting time, and mitigate potential business.

For example, when the legal entity name has been changed in the main system and the change has not been updated accordingly to the financial reporting tree, there should be an error like: "The report cannot be generated. Check the Reporting tree definition."

Current behavior

In the current system design, when fixed asset is acquired through purchase order, the posting of product receipt only generates the fixed asset with book status 'Not yet acquired', with no Fixed asset subledger acquisition transaction. On the General ledger side, there are Debit transactions posted to the main account.

Only when the purchase order invoice is posted will the Fixed asset book status change to 'Open', and an acquisition transaction is generated in the subledger.

This causes FA subledger - ledger discrepancy during the time gap between product receipt posting and invoice posting.

System design change request:

System should provide an option to acquire the fixed asset right when the product receipt is posted.

Currently, the option ‘Batch submission invoices’ to view the invoices that were submitted in batch is only available for retail invoices. 

When users submit non-retail sales invoices using the Consolidated invoice format, they are not able to see the option ‘Batch submission invoices'. 

This is very inconvenient if users need to view the detail of each invoice. They need to resort to download the XML output file from the Create document action. 

Design change request: System should also enable the option ‘Batch submission invoices’ for non-retail invoice submissions.

Current IRBM Submission Flow

1. A document is created.
2. A submission request is sent to IRBM to submit all the document details.
3. A submission response is received, containing submission results (accepted/rejected) and the submission UID.
4. A status request is sent to retrieve document validation status.
5. A status response is received with the final validation outcome (valid/invalid), including the document UUID, LongID, and Status.

Problem Summary

While the submission response (Step 3) includes the submission UID, this information is not stored in the system at that point. As a result, even though the document is technically submitted and accepted by IRBM, the system continues to display the status as "Failed" until the final validation (Step 5) is completed.

Due to this incomplete status feedback, users believe the submission has failed and make a re-submission of the same document. This is further enabled by the current system behavior, which allows re-submission if the status request (Step 4) fails or is delayed.

Consequences of Current Behavior

• Each re-submission generates a new issuance date and UUID at IRBM, despite the document content being identical.
• All submitted versions appear in the customer's MyInvois portal under their account.
• Customers typically accept only the first document and reject subsequent versions.
• However, D365 F&O retains only the last submitted document’s UUID and metadata, overwriting any earlier accepted version.
• This results in a mismatch between the customer's accepted document and the one stored and processed in our system, which may lead to:
• Customer confusion or rejection,
• Internal record misalignment,
• Risk of compliance and audit issues.

Proposed Solution

We propose the following logic change to improve the reliability and alignment between IRBM and D365 F&O:

1. Mark the document flow as “Completed (Pending Validation)” immediately after receiving the submission response (Step 3).

• This reflects the successful submission and prevents premature user actions.
• Store the submission UID at this stage, as it is already available.

1. Only allow re-submission if Step 5 (validation status) explicitly returns an “Invalid” status.

• This prevents unnecessary re-submissions due to delays or issues in the status-checking process.

In the current design, the Business activity statement report must strictly follow the setup in the official document.

The tax calculation logic for the tax fields on the report is hard coded in the backend, leaving no room for flexible adjustments for end users in case they want to change the mapping to tailor to their actual business scenarios.

Design change request:

It would be better if system provides more flexibility in the tax field mapping logic.

In the current system design, the 'Override sales tax' checkbox is not available for Project Hour journals. As a result, when the Tax Calculation Service is enabled, all Project Hour journal lines are automatically subjected to tax calculation.

This behavior presents challenges in the following business scenarios during the creation of Project Invoice Proposals:

• Scenario 1: The invoice proposal includes only Hour journal lines — no sales tax should be applied.
• Scenario 2: The invoice proposal includes only Item journal lines — sales tax should be calculated for all lines.
• Scenario 3: The invoice proposal includes both Item and Hour journal lines — sales tax should be calculated for all lines.

In Scenario 1, despite the expectation that no tax should be applied, the system continues to calculate sales tax on Hour journal lines when the Tax Calculation Service is active. This requires users to manually adjust the tax amounts, which is inefficient and time-consuming.

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.

Current Behavior and Known Issue

The WBS task ID is currently not considered during the import process using DMF. As a result, the original task order from the import file is not retained once the data is imported into the production environment. This behavior has been documented under known issue 963721 on LCS.

This limitation has led to significant overhead for customers, especially those managing large volumes of projects and WBS tasks and might cause a critical blocker for go-live readiness

Design Change Request:

Introduce an option within the DMF import process to retain the original WBS hierarchy, including task ID order, as defined in the import file.

In the current ER formats for Malaysia e-invoice, there are no elements for Supplier/Buyer NRIC, PASSPORT, ARMY. There are scenarios in which the government requires this information.

Proposal:

Add elements to support Supplier/Buyer NRIC, PASSPORT, ARMY