As pointed out by various folks, including Jan Root and Bob Poiesz , the
1000A (Submitter Name) and 1000B (Receiver Name) "audit trail" are of
limited usefulness - they most likely just reflect what's on the ISA.
And the ISA sender ID is used solely for reporting TA1 and 997
acknowledgements.
Determining the ISA receiver of an interchange containing application
transaction turnarounds depends on identifiers supplied for the billing
provider (in the case of the 837) or information receiver (270 or 276).
For example, at least one of the IDs supplied in the 837's 2000A loop to
identify the billing provider would be used to locate the CPP
(Electronic Partner Profile) for that provider.
Depending on attributes of the desired exchange (e.g., functional group
of the response, say the 277U), the CPP may provide DeliveryChannels
("EDI Addresses") describing the portal to which the interchange is
sent, along with the desired receiver ID to be inserted into the ISA.
This ISA receiver ID may very well be different from that of the sender
ID on the interchange containing the original 837!
William J. Kammerer
Novannet, LLC.
Columbus, US-OH 43221-3859
+1 (614) 487-0320
----- Original Message -----
From: "Michael Mattias/Tal Systems" <[EMAIL PROTECTED]>
To: "WEDi/SNIP ID & Routing" <[EMAIL PROTECTED]>
Sent: Thursday, 30 May, 2002 07:59 AM
Subject: Re: Trading Partner ID
----- 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
