Duplicate integration events must not automatically create a second order. The system needs to determine whether an event retransmits an already received business submission or represents a new, legitimate order from the same customer. The key is not only a technical message identifier, but a business identifier and a clear processing rule.
An integration often sends an event representing an order, an order change, a cancellation, or another business request. Transmission may be repeated because the source system resends an event, the connection fails, a response times out, or a user initiates reprocessing. Receiving the same message a second time does not itself establish a new business intent.
If an ERP treats every received event as a new order, operational consequences can follow: duplicate production or delivery lines, inaccurate open amounts, incorrectly reserved stock, and additional accounting work. The opposite extreme also creates risk. A rule that identifies duplicates too broadly can reject a customer's legitimate second order.
The question is therefore not only, "Is the message the same?" It is, "Does this submission represent the same business request already accepted in an official ERP transaction?"
Uniqueness of a business submission requires an identifier that the source business process recognises as stable. It may be an order number from an online store, CRM, EDI message, or another source system, combined with a source marker when the number is not globally unique.
A sound business identifier has three properties:
A message identifier serves a different purpose. It may distinguish delivery attempts, a processing log entry, or a technical request. When each retransmission receives a new message identifier, that identifier alone cannot prevent a second order from being created.
A combination such as customer + date + total amount is not a reliable substitute for a business identifier. The same customer may submit two orders with the same amount on the same day. That record should remain a second order when the source process confirms two separate business submissions.
Before creating an ERP order, the integration should find an existing record using the agreed business key. A common key may contain the source system marker and the external order number. The exact composition depends on the process and needs a business owner.
A practical flow can work as follows:
It is important to define in advance what "the same request" means. In some processes, the same business identifier with unchanged content means retransmission. In others, the same identifier with changed lines may represent an amendment, a new version, or an invalid input. The integration should not infer the business meaning of a change on its own.
Assume a customer submits an order with the external number WEB-4581 . The integration receives it, and the ERP creates an official order. The source system does not receive a response confirmation and sends the same event again.
The second event has a new technical message identifier, but the same source, the same external order number, and content that represents the same business submission. The outcome should be a recorded retransmission, not a second ERP order.
Later, the same customer submits a new order with external number WEB-4582 , even if the customer, items, and amount are identical to the earlier order. This is a separate business submission. The system should create a new order because the business identifier distinguishes the requests.
If content with a changed quantity arrives for WEB-4581 , the decision depends on the agreed process. It may be an amendment, an unauthorised overwrite of an already accepted order, or a source error. This case needs a separate rule rather than either blindly creating a new order or silently discarding it.
Data constraints are useful for implementing part of the control. They can check uniqueness, mandatory fields, and relationships between records. PostgreSQL documentation describes constraints including UNIQUE , NOT NULL , primary keys, and foreign keys: PostgreSQL Constraints .
For example, a unique constraint on the combination of source system and external order number can prevent two records with the same business key in a selected register. However, a database cannot determine on its own whether a changed submission should update an existing order, open a new version, or enter an exception queue. Those are business rules.
This division of responsibility reduces ambiguity:
A stable process needs more than a field called "order number". Each key input and decision needs an owner.
Handle at least the following cases separately:
Every exception needs an owner, expected action, recorded reason, and rule for continuing processing. Without this, decisions move into messages, personal memory, and later reconciliation work.
An acceptance criterion is not a broad statement such as "the system handles duplicates." It needs to describe the input, expected action, and verifiable evidence. Examples include:
An acceptance measure can be a review of the outcomes from an agreed set of test submissions: the number of ERP orders created, the number of repeat submissions recorded, the number of exceptions, and the ability to link each outcome to its source event. The process owner should set baseline and target values before testing, not retrospectively from the result.
Before changing an integration, bring together the owner of the sales or order process, the ERP accountable person, the integration team, and accounting where the order affects financial documents. Define the business key, change lifecycle, and exceptions together using the actual submission types received by the process.
When the business key or accountability is unclear, Business process screening can provide a structured starting point for separating data constraints from business rules. Only after that decision should uniqueness of the business submission be built into the integration and official ERP transactions.