0

The UNB segment contains the Interchange control reference as the last element. The documentation says it must be unique (see the UN/EDIFACT Syntax Rules, for example):

 ___________________________________________________________________

 0020   an..14  M  INTERCHANGE CONTROL        Unique reference
                   REFERENCE                  assigned by sender
 ___________________________________________________________________

The UNB contains also sender ID, recipient ID, date and time.

Now... In what context the interchange control reference must be unique? It is assigned by sender. So, is it unique for the same sender ID or for combination of the sender and recipient ID?

Say, if the sender uses more systems to send the messages, should that be reflected in the sender ID? Say, if some serious hardware failure happens, should the new hardware use a different sender ID to ensure the uniquenes of the Interchange Control Reference?

pepr
  • 20,112
  • 15
  • 76
  • 139

2 Answers2

1

The combination of reference number, sender id and receiver id, must be unique. The reference numbers are often sequentially generated for the sender id\receiver id pair.

Many applications internally use a simple table, with sender id\receiver id as the primary key, and a ref number column that gets incremented or set to 0.

The usual reset time is 30 days, after which you can start re-using the same ref numbers, but this varies between applications and trading partners.

Destination systems are sometimes configured to detect duplicates by these three values so that if you send out the same interchange more than once, all subsequent interchanges will be rejected.

Don Zoeggerle
  • 1
  • 1
  • 6
  • 1
    Thanks, Don, for the information. Is it only an information of the kind "what some say", or is there any EDIFACT-standard document that says that? I am solving the situation when communicating with our customer that is rather rigid, not open to informal communication. – pepr Oct 10 '19 at 20:54
1

The interchange control number must be unique between a specific sender / receiver pair.

Generally this is handled as a counter which increments for each interchange. Sometimes a sender maintains a single counter used across all sender IDs and for all recipients, other times a separate counter for each sender ID / recipient ID pair. Occasionally they may maintain two counters for each pair separated by 500000 or so (eg. when different interchanges are generated by multiple systems - eg an outsourced warehouse, or following an upgrade to a new system if it's not practicable to retain each recipient's counter).

I've also seen an encoding of date and time used as the interchange control number when the sender is confident that there will never be more than one interchange for each recipient encoded within a second (or for any recipient within a millisecond).

In practice it's highly unusual for a repetition of the control number to cause a problem if they're separated by 3 months or more, and most schemes I've seen used will go for over a year before the counter rolls over. eg. taking the last 9 digits of a POSIX timestamp (to 100ths of a second) will guarantee no repetition for around 4 months (as long as there won't be more than one interchange to the same recipient in that first 100th of a second) and will probably make chances of a duplicate vanishingly small for many years. If you do it to 10ths of a second instead, you're guaranteed not to have a duplicate for over 3 years.

Are you solving the situation where your rigid customer is rejecting interchanges you're sending, or where they're sending control numbers which you're flagging as duplicates? The way I'd handle these situations are quite different (and also depend on how rigid your organisation is).

I have (once only thankfully) seen a customer insist that all interchange control numbers between a specific sender/receiver pair not only be unique but be sequential and that message control numbers within those interchanges must also be sequential and formatted as four digit numbers with leading zeroes, and always starting from 0001 in each interchange. None of those additional requirements are supported by EDIFACT standards, but it was in this customer's message implementation guides and they were big enough to insist that their suppliers comply.

AdamKent
  • 366
  • 2
  • 8