Subject: / Proprietary document support
EXTOL Integrator can support non-standard (or, proprietary) EDI documents with certain constraints and limitations.
Custom coding additions to the incoming data analysis program are currently required to identify the proprietary format being used. Other requirements for proprietary documents include:
· The record types (segments) must be identified by an identifier positioned at a consistent location within each segment. The segment identifier may be one, two, or three characters in length, and all segment identifiers in a non-delimited (fixed record length) document must be the same length.
· If a group of segments is to be repeated (loop), a specified segment must always be used at the start of that group. This is the same requirement for loop start segments in traditional EDI. If the standard is not constructed in this manner, a “dummy” loop start segment must be inserted at the appropriate places in a pre-process – prior to data analysis – for incoming data. For outgoing data, a “dummy” loop start segment will be created but will be automatically removed prior to wrapping.
· For non-delimited data, all non-envelope records in an incoming document must be the same length.
· For outgoing data, “dummy” segment IDs built into the document definition to meet translator requirements can automatically be removed prior to wrapping.
Envelope records
To eliminate the need for EXTOL custom coding additions to the data analysis program, a proprietary set of envelope records has been defined. These records, when properly constructed and placed at the beginning and end of a block of proprietary data, will provide sufficient information to the data analysis program to identify the type of proprietary data, the trading partner ID, the assigned group, document type, and message class (map) to be used for translation.
Data contained in these records include:
· Sender/Receiver Ids
· Date
· Time
· Interchange number
· Group number
· Message control number
· Group ID
· Message ID
· Standard class code
· Industry group code
· (for fixed length data) Record length and the number of characters in the segment identifier
· (for delimited data) The delimiters to be used will be specified in the envelopes
· Optionally included in the ending envelopes are counts of the number of records in each message, messages in each group, and groups in each interchange
If the following conditions apply, the incoming envelope records can be specified in the EXTOL control script, eliminating the need to pre-process the data:
· All of the information required to build the envelope records is known in advance of the call and can be specified in the control script. Control script variables are available to specify date, time, control numbers, etc. This implies that all data in the connection is from the same trading partner, and that the data can be considered one document of a specified type.
· “Dummy” segments to specify loop start positions are not required. Nor are modifications to the segment IDs.
EXTOL Proprietary Envelope Definitions
Introduction
The EXTOL proprietary envelope segments are modeled after both the X12 ISA-GS-ST-SE-GE-IEA segments and the UN/EDIFACT UNB-UNG-UNH-UNT-UNE-UNZ segments. A familiarity with either the X12 or the EDIFACT envelope segments will, in general, be transferable to understanding of the EXTOL envelope segments.
As in the EXTOL system itself, the design is primarily based on EDIFACT conventions, since in almost all cases the X12 elements are definable as more-restricted subsets of the corresponding EDIFACT elements. The segment tags for the EXTOL envelopes are based on the corresponding EDIFACT segment tags with “UN” replaced by “EX”.
Figure 13-1shows the envelope segments for X12, UN/EDIFACT, and for EXTOL Proprietary. /
The design goals on which the EXTOL envelope segments are based are:
· Enable all functionality currently available in X12 and EDIFACT envelopes
· Allow for simple implementations by requiring only a minimal set of mandatory elements
· Use fixed-length syntax (no element delimiters) in the envelope segments themselves
· Provide a “short” version of envelope segments enabling most functionality within 80-byte records
· Provide a “long” version of envelope segments (EDIFACT-lengths for IDs, control numbers, etc.)
· Permit fixed-length data segments of any reasonable length (up to 99999)
· Process record type codes (data segment IDs) of length 1 to 3 at any fixed position
· Allow for variable-length element syntax in data segments (using element delimiters)
· Allow for variable-length segment syntax in data segments (using segment delimiters)
· Allow for variable-length component elements in data segments (using component delimiters)
· Enable optional segment, message, and group counting in trailer envelopes
· Enable optional message, group, and interchange control number matching in trailer envelopes
As a general principle, it is intended that a “simple” implementation can be accomplished with minimal effort. For example, if control number tracking is not desired, all envelope segments may be implemented entirely with constants for a given document type. Even in this “trivial” case, all normal EXTOL functionality is available (such as log tracking, auto-route, and workflow triggers).
On the other hand, it is possible to design extremely sophisticated “proprietary standards” using these envelope segments without requiring custom programming modifications to the EXTOL system.
Detailed envelope segment and element specifications
In the tables which follow, all elements used in the EXTOL envelope segments are defined. The usage of M/O (Mandatory/Optional) should be understood in terms of fixed-length syntax: mandatory simply means that the corresponding element may NOT be all-blank.
All elements are considered to be alphanumeric character strings, except for the following:
· Date and time elements must have either all numeric characters (0-9) or (if unused) all blanks; see also note #4, in the list of Envelope definition notes below.
· Segment ID length and position, and segment length must have all numeric characters (0-9); see also notes #8 and #9.
· Segment, message, and group count elements in the trailer segments must have either all numeric characters (0-9) or (if unused) all blanks; see also note #19.
Envelope segment sequence requirements
In order to enable the use of the “standard” structure of multiple functional groups within an interchange and multiple messages within a group – while simultaneously avoiding the complications in EDIFACT of making the group envelopes optional – the decision was made to always require at least one group within each interchange.
This should not be a significant burden, since the only required element in the group start segment (EXG) is the group code itself, and the group end segment (EXE) requires no elements at all.
Figure 13-2shows the
sequence of envelopes. /
Figure 13-3
shows a minimal set
of segments. /
Interchange start segment – EXB (long version)
Segment ID / 3 / M / “EXB” / 1
Syntax name/version / 10 / O / Key to Syntax file --
Anything not starting with “S” / 2
Sender ID qual / 4 / O
Sender ID / 35 / M / Needed to find trading partner / 3
Receiver ID qual / 4 / O
Receiver ID / 35 / M / Needed to find trading partner / 3
Interchange date / 8 / O / YYYYMMDD / 4
Interchange time / 6 / O / HHMMSS / 4
Interchange control number / 14 / O / Recommended:
Unique sequence for tracking / 5
Interchange ack. Request / 1 / O / “1”=”Y” == Yes; “0”=”N”=” “ == No / 6
Test/Production flag / 1 / O / “1”=”T”=”Y” == Yes; “0”=”P”=”N”=” “ == No / 6
Authorization qual / 4 / O / 7
Authorization info / 14 / O / 7
Security qual / 4 / O / 7
Security info / 14 / O / 7
Segment ID length / 1 / M / Zero = variable; must use element delimiter / 8
Segment ID position / 5 / M / 1 = starting in first character / 8
Segment length / 5 / M / Zero = variable; must use segment delimiter / 9
Component delimiter / 1 / O / Blank = not used / 10
Element delimiter / 1 / O / Blank = fixed-length elements / 11
Segment delimiter / 1 / O / Blank = fixed-length segments / 12
Total length / 171
Interchange start segment – EXB (short version)
Segment ID / 3 / M / “EXB” / 1
Syntax name/version / 5 / M / Key to Syntax file – must start with “S” / 2
Sender ID qual / 2 / O
Sender ID / 15 / M / Needed to find trading partner / 3
Receiver ID qual / 2 / O
Receiver ID / 15 / M / Needed to find trading partner / 3
Interchange date / 6 / O / YYMMDD / 4
Interchange time / 4 / O / HHMM / 4
Interchange control number / 9 / O / Recommended:
Unique sequence for tracking / 5
Interchange ack. Request / 1 / O / “1”=”Y” == Yes; “0”=”N”=” “ == No / 6
Test/Production flag / 1 / O / “1”=”T”=”Y” == Yes; “0”=”P”=”N”=” “ == No / 6
Segment ID length / 1 / M / Zero = variable; must use element delimiter / 8
Segment ID position / 5 / M / 1 = starting in first character / 8
Segment length / 5 / M / Zero = variable; must use segment delimiter / 9
Component delimiter / 1 / O / Blank = not used / 10
Element delimiter / 1 / O / Blank = fixed-length elements / 11
Segment delimiter / 1 / O / Blank = fixed-length segments / 12
Total length / 77
Group start segment – EXG (long version) [must be used if EXB is long version]
Segment ID / 3 / M / “EXG” / 1
Group code / 6 / M / Needed to find trading partner group / 13
Application Sender ID qual / 4 / O / 14
Application Sender ID / 35 / O / 14
Application Receiver ID qual / 4 / O / 14
Application Receiver ID / 35 / O / 14
Group date / 8 / O / YYYYMMDD / 4
Group time / 6 / O / HHMMSS / 4
Group control number / 14 / O / Recommended:
Unique sequence for tracking / 5
Standard class / 1 / O / 15
Industry group / 1 / O / 15
Responsible Agency / 2 / O / 15
Version/Release / 6 / O / 16
Association assigned code / 6 / O / 17
Segment delimiter / 1 / O / (if variable) / 12
Total length / 132
Group start segment – EXG (short version) [must be used if EXB is short version]
Element name / Length / M/O / Comments / NotesSegment ID / 3 / M / “EXG” / 1
Group code / 6 / M / Needed to find trading partner group / 13
Application Sender ID qual / 2 / O / 14
Application Sender ID / 10 / O / 14
Application Receiver ID qual / 2 / O / 14
Application Receiver ID / 10 / O / 14
Group date / 6 / O / YYMMDD / 4
Group time / 4 / O / HHMM / 4
Group control number / 9 / O / Recommended:
Unique sequence for tracking / 5
Standard class / 1 / O / 15
Industry group / 1 / O / 15
Responsible Agency / 2 / O / 15
Version/Release / 6 / O / 16
Association assigned code / 6 / O / 17
Segment delimiter / 1 / O / (if variable) / 12
Total length / 69
Message header segment – EXH
Segment ID / 3 / M / “EXH” / 1
Message Identifier / 6 / M / Needed to find trading partner message class / 18
Message control number / 14 / O / Recommended: unique sequence for tracking / 5
Segment delimiter / 1 / O / (if variable) / 12
Total length / 24
Message trailer segment – EXT
Element name / Length / M/O / Comments / NotesSegment ID / 3 / M / “EXT” / 1
Number of segments in message / 6 / O / Zero = not checked / 19
Message control number / 14 / O / Blank = not checked / 20
Segment delimiter / 1 / O / (if variable) / 12
Total length / 24
Group end segment – EXE
Element name / Length / M/O / Comments / NotesSegment ID / 3 / M / “EXE” / 1
Number of messages in group / 6 / O / Zero = not checked / 19
Group control number / 14 / O / Blank = not checked / 20
Segment delimiter / 1 / O / (if variable) / 12
Total length / 24
Interchange end segment – EXZ
Element name / Length / M/O / Comments / NotesSegment ID / 3 / M / “EXZ” / 1
Number of groups in interchange / 6 / O / Zero = not checked / 19
Interchange control number / 14 / O / Blank = not checked / 20
Segment delimiter / 1 / O / (if variable) / 12
Total length / 24
Envelope definition notes
1. The segment ID tags for the envelope segments must be exactly as indicated – all capital letters in the first three positions of each envelope segment.
2. EXTOL has under development a totally table-driven syntax analyzer which will be controllable through this field. The current implementation uses this field only to differentiate between the “short” (must start with “S”) and “long” (anything not starting with “S”, including blanks) envelope definitions. The “short” definitions are implemented in recognition of the fact that many proprietary document definitions are based on 80-byte records, and it may be desirable to keep the envelope segments to the same length. Note that this is simply for convenience, not a requirement – either envelope definition may be used with any data segment length.