In message <[EMAIL PROTECTED]>,
Moree, Shannon <[EMAIL PROTECTED]> writes
> I have a question for the list. I have quite a bit of experience
> mapping X12 documents but this is my first EDIFACT document. I am
> mapping an outbound EDIFACT D.97 A ORDERS document. My question
> relates to Segment Group 28, Item number identification (C212),
> Code List Qualifier (1131) and Code List Responsible Agency, coded
> (3055). These two segments are marked as conditional. What
> exactly, are they conditional on? These segments are also utilized
> elsewhere in the document. Are they required? Any help would be
> greatly
Group 28 is the container for line item information. The first segment
in it is a LIN (Line Item), and I suspect this is what you are referring
to. C212 is the composite which is used to identify the item (article)
which is being dealt with on this iteration of the group. If you are
used to X12, which has only a few composite data elements, then EDIFACT
can come as a rude shock, since the bulk of the data is contained in
them.
A composite data element typically contains one component element which
carries the actual data (often the first), and then one or more
additional component data elements which act as qualifiers for it (they
tell you how it is to be interpreted; fulfilling a function akin to
adjectives in natural language). The composite as a whole can be marked
as mandatory or conditional, and each component element within it can
similarly be marked as mandatory or conditional. If you have a
conditional composite with one or more mandatory components then it
means that you can leave out the composite altogether, but if you use it
at all then all the components marked as mandatory must be present. This
may seem like labouring the obvious, but this dependency seems to cause
difficulties for some humans - and some converters. Fortunately in this
case our C212 is conditional within the LIN, and all its components are
conditional as well, so we don't have to worry about dependencies.
When we look at the structure of C212, it contains four components.
The first is 7140, the item number itself. This is what you would expect
to find; the 'real' data at the start of the composite.
Next we have 7143, a code to indicate what type of item number it is.
This could be something fairly specific like EN, to indicate that it is
an article number registered by the International Article Numbering
Association (EAN), or much vaguer like BP, to indicate a Buyer's part
number.
The final two qualifiers are qualifying the 7143, rather than the 7140.
They are the 1131, a Code List Qualifier which is widely used in EDIFACT
definitions and tells you roughly what sort of code list is being
referred to, and the 3055, Code List Responsible Agency, which tells you
the reference authority for the code list.
We can now finally start looking at your actual question, which was
about dependencies. The first thing to note is that the LIN C212 is
itself conditional (in EDIFACT conditional means optional, not a
dependency relationship of conditional ON something else - I wonder if
this may not be the source of your confusion). At first sight this seems
paradoxical; how can you have a whole group describing a line item
without identifying the line item itself? The answer to that is in the
next segment in the group, PIA Additional Product Information, which
also contains C212 composites and can be used to identify the line item.
In practice the LIN is normally used to carry the item number and the
PIA (or several; you can have up to 25 of them) is used for
complementary designations; the LIN might contain the EAN article number
and the PIA the buyer and seller internal part numbers.
What are the C212 components conditional on? They are conditional on
your need to provide the information according to the terms of your
interchange agreement. As such, although all components are conditional
in the EDIFACT definition, they may be marked in your Message
Implementation Guideline as Required (meaning that in this
implementation they are mandatory), Optional (meaning that you can
decide yourself whether to include them), Not required (normally meaning
that you should not include them), or Dependent (in which case there
will be some explanatory text to define the circumstances in which they
should be included).
EDIFACT (pre version 4, and EDIFACT 4 has only recently been formally
approved, is not seen in the field, and possibly may never be) does not
give the same scope for defining dependencies that you have in X12.
Logically you would not expect to find anything in a C212 if you did not
have the 7140 data present, and 3055 seems pointless without the 7143.
You could generate a C212 which contained only the 1131, and it would be
street legal according to UN EDIFACT, but of very doubtful utility
(personally I have difficulty in seeing why the 7140 was not made
mandatory).
In practice you most often encounter a C212 with 7140 and 7143
instanced. 7140, 7143 and 3055 is also a popular combination. EDIFACT
UNSM's are much less tightly defined than X12 transactions because they
are boilerplates intended for branch sub-setting, and it is the subset
that you work with.
Regards
Chris
--
Chris Johnson tel: +44 (0)20 8 501 1490 (home)
EDIMatrix Ltd +44 (0)20 8 559 2454 (work)
+44 (0)20 8 559 2497 (fax)
http://www.edimatrix.demon.co.uk
=======================================================================
To signoff the EDI-L list, mailto:[EMAIL PROTECTED]
To subscribe, mailto:[EMAIL PROTECTED]
To contact the list owner: mailto:[EMAIL PROTECTED]
Archives at http://www.mail-archive.com/edi-l%40listserv.ucop.edu/
