Henk-Jan,
Some clarifications for you (I hope).
Regarding question 2 (Which versions exist of X12?): There is a some
confusion about versioning in X12 because there is versioning of the
interchange envelope structure and there is versioning of the
transaction sets (as a whole). The interchange (ISA) version you spoke
of does not define the version of the 850...it only defines the version
of the interchange segments. X12 standards (transaction sets) are
released three times per year in the form of a "major release" (in
December/January of each year) plus two "sub-releases" (spring and
fall). Each of these releases contains the latest description of the
transaction sets, segments and elements as well as the overall syntax
used for transmission of X12 messages. The functional group envelope
layer (GS header, GE trailer) provides the indication of the version of
the 850 (for example). Major releases are designated by a version
number (currently "5") and a release number (currently 4). Sub-releases
are designation by version, release and sub-release numbers. The X12
version is usually written as a 6-digit number with the first three
digits being the version, the next 2 the release and the last digit as
the sub-release (which is 0 in the case of the major release).
Therefore the latest major release, version 5, release 4 is written as
005040 and the first sub-release following that was 005041. The number
of releases per version has varied over the years (spanning over 20
years).
Typically, when people refer to the X12 versions, they mean the overall
version of the standard and its transaction sets (as in 003020, 004060,
005030, etc.). These are comparable to EDIFACT directory versions.
Regarding question 4 (concerning character sets), X12 can be transmitted
in EBCDIC or ASCII. This does create some interesting problems when
various national character sets are used, but generally a little
cooperation between trading partners goes a long way.
Regarding question 5 (bounded loops), perhaps there is another way to
look at it. In EDIFACT, the new syntax version 4 (first used with
D.99B), two new segments were introduced: UGH and UGT. They provide
exactly the same functionality as the LS and LE. The big difference is
that they are defined much more simply in EDIFACT. In both cases the
idea is to avoid segment collision. (In a segment collision situation,
the structure of a message or transaction set is ambiguous such that the
receiver of an EDI message or transaction set is unable to associate a
given instance of a segment to one of it's locations within the defined
structure.)
In X12, the LS and LE are defined as boundary segments around a loop
structure and are designated as being Optional (which has caused much
misinterpretation). The fact is, if the loop between the LS and LE are
used, then the LS and LE are required. Another way to think of this is
to treat them in the same way as UGH and UGT: as an additional layer
segment group that occurs one time.
For example in X12 version 004060, within the 850 transaction set, there
is a bounded loop structure that looks like this:
. . .
LS O 1
LDT (loop) ------------- >1 --+
LDT O 1 |
QTY O >1 |
MTX O >1 |
REF O 3 |
LM (loop) ---------- >1 ---+ |
LM O 1 | |
LQ M >1 | |
-----------------+-+
LE O 1
. . .
Let's put it in a slightly more EDIFACT-like representation to clarify
the functionality:
. . .
LS (implied loop) - - - - O 1 - +
LS M 1 |
LDT (loop) ----------- O >1 --+
LDT M 1 | |
QTY O >1 |
MTX O >1 | |
REF O 3 |
LM (loop) -------- O >1 ---+ | |
LM M 1 | |
LQ M >1 | | |
-----------------+-+
LE M 1 |
- - - - - - - - - - - - - - +
. . .
Therefore, based on the X12 syntax: If you use the LDT loop (which is
bounded), you must use the LS and the LE.
With regard to question 6 (binary data), there are two things to
consider:
1. Binary data does not travel alone. If you look at the structure of
the BIN segment or the BDS segment, you will see that the binary data
element is preceded by another element that tells the length of the
binary data element. Any EDI processor worth its salt knows that
separator checking is suspended for the length specified in that
element.
2. Binary data is, as Mike Rawlins pointed out, usually encoded.
Depending upon the transmission protocols, raw binary could cause some
problems. In addition, since both EBCDIC and ASCII are possible
transmission forms and in fact may be changed en route, an encoding such
as Base64 or hexadecimal is necessary to mitigate the character
transpositions that would otherwise destroy binary data.
Does that help at all?
Best regards,
Bill Chessman
Inovis(tm)
-----Original Message-----
From: [email protected] [mailto:[EMAIL PROTECTED] On Behalf Of
henkjanebbers
Sent: Wednesday, September 12, 2007 10:47 AM
To: [email protected]
Subject: [EDI-L] Re: questions about X12 syntax (building ta X12
translator)
--- In [email protected], Mike Rawlins <[EMAIL PROTECTED]> wrote:
Thanks for you answer.
> > 2. Which versions exist of X12?
> >
> Many, and yes, the transaction set definitions can differ quite a bit
> across different versions/releases.
Let's if I udnrstand this:
a ISA version 00401 with message orders (850) is different from the
same 850 in a ISA version 00303??
> > 4. In X12 there is a *Basic Character Set, and a Extended
Character Set;
> > and there's also Control Characters.
> >
> Unlike the EDIFACT syntax, there is no indicator in the X12
interchange
> to advise the consumer the character set (or even the encoding) that
is
> used. Encoding (EBCDIC vs. ASCII, for example) is beyond the scope of
> the standards.
This is new for me - you are saying that I can recieve a file in
EBCDIC? Are x12 fils actually snet in EBCDIC??
>
> > 5. I do not understand 'bounded groups'.
> >
> Yes, they are used. Bounded loops are groups of segments that may
> repeat. The first instance of a bounded loop is preceded by an LS
> segment, and the last instance is followed by an LE segment. In
> practical terms for implementing a translator, I think you probably
> don't need to do anything special to handle them. They are defined in
> the standard to prevent a condition in transaction set instances
called
> "segment collision", in which a parser might not otherwise know
where it
> is without the inclusion of the LS and LE segments.
OK.
But I still do not understand it.
>
> > 6. Concerning data type 'binary': is this really used? How?
(because it
> > seems to me this would lead to syntax problems with
separators/terminators.
> >
> Yes, it is really used, though rarely. It would cause syntax
problems if
> it weren't for the fact that in transaction set instances most
"binary"
> data is "filtered", i.e., represented in a transmission friendly
> encoding such as binhex or base64.
I mean: if data is binary, it is possible that in the binary data
there is a character that is in use as a separator/terminator. This
would lead to an invalid EDI file, wouldn't it?
kind regards,
Henk-Jan Ebbers
...
Please use the following Message Identifiers as your subject prefix:
<SALES>, <JOBS>, <LIST>, <TECH>, <MISC>, <EVENT>, <OFF-TOPIC>
Job postings are welcome, but for job postings or requests for work:
<JOBS> IS REQUIRED in the subject line as a prefix.
Yahoo! Groups Links
...
Please use the following Message Identifiers as your subject prefix: <SALES>,
<JOBS>, <LIST>, <TECH>, <MISC>, <EVENT>, <OFF-TOPIC>
Job postings are welcome, but for job postings or requests for work: <JOBS> IS
REQUIRED in the subject line as a prefix.
Yahoo! Groups Links
<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/EDI-L/
<*> Your email settings:
Individual Email | Traditional
<*> To change settings online go to:
http://groups.yahoo.com/group/EDI-L/join
(Yahoo! ID required)
<*> To change settings via email:
mailto:[EMAIL PROTECTED]
mailto:[EMAIL PROTECTED]
<*> To unsubscribe from this group, send an email to:
[EMAIL PROTECTED]
<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
