After the business system request times out, the caller may not know whether the document has been created, so it submits it again. If ERP treats each request as a new business, inventory, receivables, or purchasing records will be duplicated. The interface needs to be able to identify the same business submission and return the existing processing results.

How to arrange records and operations

Specify a stable business identifier for the request, record the source system, external order number and processing status. The server uses clear constraints to prevent repeated writing, and distinguishes between failed requests that can be retried and those that require manual verification. Cross-system processing status is synchronized through query interfaces or result notifications to avoid relying on only one response.

The scope of idempotent identification needs to be clear. For example, the source system and the external tracking number jointly identify a submission, and you cannot just use short numbers that are easy to repeat. When the same identifier but different content is received, a conflict description is returned and cannot be directly accepted as a retry. External systems can query the processing results by identifier and distinguish between those that are still being processed and those that have been completed. The retry frequency and exception retention period must also be agreed to avoid endless retransmissions occupying resources, and business personnel never know where the request is actually stuck.

Specific scenarios that need to be verified

The test is called again when the document is created but the response is not delivered. The verification system only has one valid document. After changing the business content, a clear change process should be used instead of quietly overwriting the old logo by reusing it. The exception queue retains error information and review entries to facilitate personnel to find out the actual execution status.