Thanks for your detailed answer, Michael. Since I am not limited by someone elses software, I write my own, I have the liberty and and the burden to solve this conclusively. And with all the helpful answers in the last two days, I come up with the following.
I will keep the ISA_06 element as my record key to the trading partner file. For one, my inbox service for incoming EDI transactions needs to read ISA,GS and ST segments to place the files in the correct bin for further processing and I need rules to send the 997 back to my TP. (ftp, email, dial-up, VAN, Outbox etc.) I will create an extra field for the GS Identifier, though the default value is the same as the ISA identifier. I will allow multiple GS_02 identifiers for a trading partner, anticipating that the receiver might want to have internal routing information embedded based on transaction type or who knows what. The same I will do with the NM1 identifier. Default identical, but option to have even multiple values there for one trading partner. I decided against using the NM1_09 element as the TP ID because only the 837 transaction has the 1000 loop, for that matter historically EDI allowed multiple repeats of the 1000 loop, creating an audit trail. Thanks again, Martin Scholl Scholl Consulting Group, Inc. 301-924-5537 Tel 301-570-0139 Fax [EMAIL PROTECTED] www.SchollConsulting.com ----- Original Message ----- From: "Michael Mattias/Tal Systems" <[EMAIL PROTECTED]> To: "WEDi/SNIP ID & Routing" <[EMAIL PROTECTED]> Sent: Thursday, May 30, 2002 7: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 > > > >
