There is at least one network that uses ZZ in ISA qualifiers (mind you, this does not represent advocacy or condoning on my part--it's just an observation): When sending X12 interchanges via Advantis (IBM, right?), when you specify ZZ as the qualifier, the receiver identifier, specially formatted, contains an Advantis-specific account value that tells the network exactly which mailbox to deliver to.
The idea in this particular case is that there's no extra protocol stuff. Dump the file onto Advantis (no control statements, just the raw interchange) and the network will do two things: 1) recognize and classify the data as X12-style EDI and 2) deliver it to the recipient based on the value in the ISA receiver ID. Of course, this service is only available when sender and receiver are both Advantis users... For what it's worth... Best regards, Bill Chessman Peregrine Systems, Inc. (though the opinions expressed, if any, are my own) -----Original Message----- From: Martin Scholl [mailto:[EMAIL PROTECTED]] Sent: Friday, May 31, 2002 8:45 AM To: William J. Kammerer; WEDi/SNIP ID & Routing Subject: Re: Trading Partner ID William, you wrote: The ISA sender and receiver IDs must be valid identifiers from a limited set of domains, e.g., HIBCC HIN, NAIC Company Code, Dun & Bradstreet D-U-N-S, IRS Tax ID (FEIN), etc. It is my impression that when you choose the qulifier "ZZ" you can put anything in there. Whatever you and your trading partner deem to be fit. Martin ----- Original Message ----- From: "William J. Kammerer" <[EMAIL PROTECTED]> To: "WEDi/SNIP ID & Routing" <[EMAIL PROTECTED]> Sent: Friday, May 31, 2002 9:43 AM Subject: Re: Trading Partner ID > I don't think the 1000A (Submitter Name) and 1000B (Receiver Name) > "audit trail" in the 837 are all that important. Besides, the other > transactions (like the 270/271, 276/277 and 835) don't have an analog of > this "audit trail." Based on previous observations, though, it's > probably the usual case that the 1000A and 1000B Electronic Transmitter > Identification Numbers exactly reflect the sender and receiver IDs on > the enclosing interchange envelope. > > The ISA is incapable of carrying application data - unless you can > manage to squeeze it into a ZZ-qualified sender or receiver ID! The ISA > sender and receiver IDs must be valid identifiers from a limited set of > domains, e.g., HIBCC HIN, NAIC Company Code, Dun & Bradstreet D-U-N-S, > IRS Tax ID (FEIN), etc. IDs of this sort can serve as both routing > identifiers *and* application identifiers. Therefore, it's entirely > possible that any of these also appear in the "application" NM1s (e.g., > the 837's 2000A loop to identify the billing provider). > > Generally, you would use one of the NM1 "application" identifiers (say, > the Tax ID) for a provider to locate his CPP (Electronic Partner > Profile). The CPP would then tell you what identifier to use in the ISA > for the receiver. It would be mere serendipity if it turned out to be > the same (the Tax ID in this case) - it could just as well be the > D-U-N-S or HIN of the provider. > > William J. Kammerer > Novannet, LLC. > Columbus, US-OH 43221-3859 > +1 (614) 487-0320 > > ----- Original Message ----- > From: "Bill Chessman" <[EMAIL PROTECTED]> > To: "'WEDI Routing & ID List'" <[EMAIL PROTECTED]> > Sent: Thursday, 30 May, 2002 04:06 PM > Subject: RE: Trading Partner ID > > > Wouldn't it stand to reason that the NM1 elements and the ISA elements > would be different? Two things would seem to suggest that: > > 1. ISA elements are not supposed to be used to carry any application > data. > 2. ISA receiver (at least) is commonly used to help in the routing and > delivery through networks. Or is it not used that way anymore? > > Best regards, > Bill Chessman > Peregrine Systems, Inc. > > -----Original Message----- > From: Rachel Foerster [mailto:[EMAIL PROTECTED]] > Sent: Thursday, May 30, 2002 12:02 PM > To: 'WEDi/SNIP ID & Routing' > Subject: RE: Trading Partner ID > > > Code 40 in NM108 specifies receiver > Code 41 in NM108 specifies submitter > > > Since these two terms can be somewhat ambiguous and interpretable I very > early on in this work group's efforts recommended that a glossary be > developed which provided specific unambiguous definitions to terms. > > For example, I could argue that the submitter is the "actual" submitter > of the claim transaction, which would be the provider. Others argue that > the submitter is the entity that puts the claim data into the standard > format - a clearinghouse. I would argue that the clearinghouse then is a > business associate of the submitter. > > I could also argue that the receiver is the end-point payer. Others > could argue that the receiver could be the payer's clearinghouse. > > We've gone round and round on this topic with no real resolution in my > mind. And Martin's question certainly confirms my belief that these > terms are not universally and unambiguously understood throughout the > industry. > > So....pick a number, put a blindfold on and toss the dart! > > Rachel > >
