Copyright © TIBCO Software Inc. All Rights Reserved
Copyright © TIBCO Software Inc. All Rights Reserved


Chapter 4 Configuring Protocol Features : Control Number Management

Control Number Management
Control numbers are used to uniquely identify the interchanges, groups, and transactions that you exchange with a trading partner.
Interchange control numbers   These numbers used by one trading partner uniquely identify each interchange from that trading partner.
Group control numbers   These numbers uniquely identify the functional group within an interchange. For a particular trading partner, the interchange control and functional group control number together uniquely identify each functional group.
Transaction control numbers    These numbers uniquely identify each transaction within a functional group. The interchange control number, functional group control number, and transaction control number together uniquely identify each transaction for a particular trading partner.
TIBCO BusinessConnect EDI Protocol powered by Instream provides the following control number management capabilities:
Control Number Validation
Control numbers are used to identify EDI transactions. For example, any acknowledgment must indicate what EDI transaction it is acknowledging.
A control number is used to indicate the transaction. Also, if a problem occurs with a transaction, trading partners contact each other and note that control number X transaction had a problem.
For information on how to use control numbers to reconcile acknowledgments, see Reconciling Acknowledgments. The fields are found in the X12 protocol Control Numbers tabs. See the Setting Control Number Properties sections
Increment Group Control Numbers Across Outbound Interchanges
This field determines whether to generate group control numbers that always increase when sending EDI documents.
For example, if it is set to false, the pattern of control numbers are similar to the following information:
int 1
grp 1
txn 1
txn 2
grp 2
txn 1
int 2
grp 1 <---- the group number has been reset
txn 1
If it is set to true, the pattern looks like the following information:
int 1
grp 1
txn 1
grp 2
txn 1
int 2
grp 3 <---- the group number continues to increase
txn 1
Increment Transaction Control Number Sequentially Across Interchanges
This field determines whether to generate the transaction control numbers that always increase when sending EDI documents across interchanges.
For example, if it is set to false, the pattern of control numbers are similar to the following information:
int 1
grp 1
txn 1
txn 2
grp 2
txn 1
int 2
grp 1
txn 1 <---- the transaction number has been reset
If it is set to true, the pattern looks like the following information:
int 1
grp 1
txn 1
grp 2
txn 2 <---- the transaction number continues to increase
int 2
grp 1
txn 3 <---- the transaction number continues to increase
Group Control Numbers Increment Across Inbound Interchanges
This field determines whether group control numbers are expected to increase when receiving EDI documents. This is important only if the control number validation (Group Control Number Sequence Check) is on.
If the field is set to true and the Group Control Number Sequence Check is set to Incremental or Chronological, the following sequence comes in:
int 1
grp 1
txn 1
txn 2
grp 2
txn 1
int 2
grp 1 <---- the group number has been reset
txn 1
This results in a validation failure. The group number must be 3 (for Incremental) or >2 (for Chronological). The group control numbers can always increase because of acknowledgment reconciliation. 997s only acknowledge at the group and transaction level, not the interchange level.
Any trading partner that only sends back 997s (and not TA1) might have reconciliation problems unless the group control numbers always increase. For example, without setting the field to true, the following sequence is ambiguous for 997-only acknowledgment reconciliation:
int 1
grp 1
txn 1
int 2
grp 1
txn 1
Since 997s have no interchange information, int 1/grp 1/txn 1 looks exactly the same as int 2/grp 1/txn 1.
Interchange Control Number Sequence Check
This field determines how interchange control numbers on inbound must be validated.
If the field is set to Incremental, the following sequence comes in:
int 1
grp 1
txn 1
txn 2
grp 2
txn 1
int 2 <---- this number must be exactly one greater than the               previous interchange any value other than 2 will fail
              validation
grp 1
txn 1
For chronological, int 2 can also be any value greater than 1. For none, the value can be anything. When a resend of an interchange is received from a trading partner, the chronological or incremental sequence check of the Control Number is not validated.
Interchange Control Number Seed
This field determines what number to start at for the interchange control number.
Group Control Number Sequence Check
This field determines how group control numbers are validated. It works with the Group Control Number Increment Across Interchanges.
For example, the following sequence might come in:
int 1
grp 1
txn 1
grp 2
txn 1
int 2
grp 1
txn 1
The preceding information is valid for Incremental or Chronological, but the group is not expected to always increase.
int 1
grp 1
txn 1
grp 2
txn 1
int 2
grp 3 <-----
txn 1
The preceding information is only valid for Chronological and always increase.
For transaction settings:
int 1
grp 1
txn 1
txn 3 <-----
grp 2
txn 1
This is only valid for Chronological. If validation for transactions is set to Incremental, the highlighted value must be 2.
When a resend of an interchange is received from a trading partner, the chronological or incremental sequence check of the Control Number is not validated.
Transaction Control Number Sequence Check
When a resend of an interchange is received from a trading partner, the chronological or incremental sequence check of the Control Number is not validated.
Alphanumeric Control Numbers and Validation
If you set control number validation to Incremental or Chronological and try to process control numbers that are not strictly integers, control number validation always fails.
For example, if control number validation is set to anything but None, and you try to process a control number like A123SXX, control number validation fails.
Control Number Validation and Non-Matching Segment Headers and Trailers
In UN/EDIFACT and ASC X12, the envelope segments have control numbers that must match. For example, in ASC X12, the control number for the IEA segment must match the control number specified in the ISA segment. The same is true for the group and transaction envelopes.
If the control number for a segment header passes validation, it is accepted as the next control number even if the segment trailer fails.
For example, if validation is set to Incremental, and the following information arrives:
ISA, control number 1
....
IEA, control number 2
The preceding interchange fails validation at the IEA segment because 2 !=1. But the next expected interchange control number will be 2.
Generate a Unique Control Number for a Transaction Automatically
When the property named Increment Transaction Control Number Sequentially is added in the Control Numbers tab for the X12 and EDIFACT protocol, its default value is False.
By selecting the value True, this option supports an automatic generation of a unique control number. To select the option, see:

Copyright © TIBCO Software Inc. All Rights Reserved
Copyright © TIBCO Software Inc. All Rights Reserved