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.