----- Original Message -----
From: Martin Scholl <[EMAIL PROTECTED]>
Subject: RE: Trading Partner ID
> Thanks for all the input.
> That helped a lot with the ISA/GS issue.  But how about the loop 1000 , NM1_08
and NM1_09 with the 40/41 qualifier.
> What are you guys doing there usually? Again use the same IDs as in ISA 06 and
08?

As has been pointed out by others, the ISA, GS and "between the ST-SE"
identifiers are COMMONLY set to the same values.

Of course, it is also COMMON for people to go out in the rain without an
umbrella; but that doesn't make it smart.

One of the "problems" setting the ISA, GS and N1/ NM1/PRV segment identifiers to
the same value "solves" is the problem of poorly-designed EDI software. (This
does not apply just to "homegrown" systems, it includes several commercial
offerings). Poorly-designed software comes from designers who do not understand
the purposes for which the various ANSI ASC X12 envelopes were designed:

ISA/IEA Envelope:  Gets the interchange to the correct destination (application
partner, agent or backup processing site); often (well, nearly always) used by
VANs to route to the correct destination mailbox, with a check that the VAN
receiver has in fact authorized the receipt of interchanges from a certain
sender (this is a bad check: it should be done after the file is delivered, but
this is not a universally held view).

GS/GE Envelope: Routes the functional group to the correct party or department
within the destination; e.g,  Purchase orders (group PO) and PO changes (group
PC) go to the sales department; Invoices (group IN) go to accounting, etc, etc.

ST/SE envelope: Delimits documents containing the specific identities for this
business transaction; e.g, "My customer/vendor/provider number is xxxx."

You mentioned, "If I receive a transaction, I key the trading partner to the
ISA_06 element".  This is, IMNSHO, an inferior choice. It's like tracking mailed
documents based on the post-office of the sender. You don't do this in real
life: you track documents based on the identifiers found within the document,
don't you?

You asked, "For me the issue is: What do I use as a unique key to store trading
partner rules and information under? What do others in the field do?"

What others in the field do is immaterial, as many of them are limited by their
software (and their wetware). Given your druthers (and yes, I understand we
don't all get our druthers), use the identifiers within the transaction set.  So
you have answered this yourself: ".. in the 837 I also have this pesky 1000A
loop with another set of Sender IDs. "  As the identifiers within the
transaction set, these should be your ID's of choice.

This does NOT mean you cannot use something else to accomodate your mapping
software. For example, you may need to map the transaction set "somewhere" just
to figure out if you wish to further process this document from the sending
party as identified within the transaction set. However, you should be able to
do this kind of mapping without regard to the applications identifiers based
solely on the version/release in the GS segment.

In an ideal world (give me a break, I grew up in the 1960's and I am an
idealist), using this "document" approach will be the long-term winner.

Michael Mattias
Tal Systems, Inc.
Racine WI
[EMAIL PROTECTED]
www.talsystems.com




Reply via email to