Control numbers and duplicates

A duplicated EDI order is one of the most expensive integration defects: two sales orders for 50 alternators, two deliveries, one angry customer and a credit memo. Duplicates happen because B2B is built on retries. Partners resend when they don't get an MDN, AS2 software retries on timeouts, operators reprocess failed messages. Every layer has its own control number, and you need to know which layer catches which kind of repeat.

The control numbers in one file

Each layer catches a different repeat. An AS2 retransmission of the same post is caught by the AS2 Message-ID. A partner who regenerates the same order through its translator produces a new AS2 Message-ID and a new ISA13, so only the business key catches it. And an operator who reprocesses a message inside Cloud Integration never touches AS2 at all, so only an idempotent receiver or the business key protects you.

EDIFACT has the same layers with different names. The interchange control reference sits in the UNB segment and is repeated in UNZ; the optional functional group reference sits in UNG and UNE; and each message has its message reference number in UNH, repeated in UNT. The EDI Splitter's CONTRL error codes 28 and 29 point exactly at these pairs: code 28 means a control reference in UNB, UNG or UNH doesn't match the one in UNZ, UNE or UNT, and code 29 means a count of groups, messages or segments doesn't match. When an EDIFACT partner reports a duplicate, ask which reference they checked before you start looking.

Transport-level duplicate checks in the AS2 adapter

The AS2 sender adapter has two checks on its Processing tab. Duplicate Message ID ensures an AS2 message with the same message ID isn't processed more than once; Duplicate File Name does the same for file names. Both use a Persist Duration in minutes and let you choose the MDN response type when a duplicate arrives. SAP adds a tip worth repeating: enable duplicate handling on the receiving system as well, because the adapter only sees its own window.

Inside the flow: idempotent processing

Cloud Integration offers an Idempotent Process Call step that runs a local process only once for a given message ID, which you can set to a stable business value such as the sender ID plus ISA13 plus ST02. Use it around the step that has side effects, typically the call to the receiver, so a retried or reprocessed message doesn't post twice. In TPM's generic flows you don't build this yourself; there the B2B monitor's Restart and Retry keep the original interchange ID, and Duplicate and Retry deliberately creates a copy, so operators must check the receiver before using it.

In SAP S/4HANA: the business key

The last line is in the ERP system. In sales, the sales document type can be set to check whether the customer's purchase order number was already used, so a second order with Great Lakes' PO GLF-PO-55120 raises a message instead of quietly creating a duplicate. Whether that message is a warning or an error, and how Maria's team works the resulting IDoc, is a business decision to agree with the order-to-cash process owner. Test it, because many EDI duplicates are caught only here.

Outbound: never reuse a number

Outbound, you are the sender, and your partner's translator will reject a repeated ISA13 as a duplicate interchange. Three rules keep you safe:

• One number range per partner and direction, so a reset for one partner never affects another.
• Continue, don't restart, at cutover. If Process Orchestration last sent ISA13 000004511 to Great Lakes, the Cloud Integration range starts at 4512.
• Size it and watch it. Nine digits last for years, but if Rotate resets a range, check with the partner how long it remembers old numbers.