CompTIA EIDX Partner and Location Identification

Contents

• Sender/Receiver, Name and Location Identifiers
• Enveloping Identification
• Name Segments
• Party Identification Code
• Party ID Code Cross-Reference
• Name and Address Formats
• Contact Names Format
  • Telephone and Fax Number Formats
  • E-mail Address Formats

Sender/Receiver, Name and Location Identifiers
The identification of locations and parties is particularly important in EDI. Identification is used to route electronic documents through third party networks, to route them within company networks, and to identify locations and parties relevant to the business transaction. There are many opportunities for complexity and confusion, which can be minimized if companies agree upon rules for what to identify and where to identify it.

What can be identified in an EDI transaction/message:

• Legal entities - whole companies, subsidiaries, or divisions, such as supplier, customer, bank, forwarder, etc.
• Physical entities - a particular building warehouse, a particular location within a building or warehouse, delivery point, transmission point.
• Functional entities - specific department within a legal entity, a physical mailbox, an electronic mailbox, a file within a computer.

What types of Location/Name Identifiers may be sent:

• Party name
• Postal address
• Type of location
• Region
• Telephone, fax numbers
• Email addresses
• Contact person
• Delivery requirements and logistics restrictions
• Dock, room, mail stop numbers

The recommendations in this section will identify which party, name and location identifiers should be sent at which level in a transaction or message to help facilitate efficient flow of information between trading partners.

Theoretically, a recipient should be able to identify the sending party of a transaction or message from the outer enveloping segment (ISA/GS in X12, UNB in EDIFACT).

Example of ideal usage:

• ISA/UNB Level One: Central corporate electronic mailbox
• GS/Level Two: Division or site - e.g. a buying entity, which may have one or more Ship-To addresses
• N1/NAD: Specific Ship-To address for that buying entity
• SDQ/LOC: More specific location within the Ship-To address, such as a particular product line location

The reality is that the recipient often has to query the data within the transaction or message in order to fully identify the sender and instructions for where to ship goods. Historically, the header level Ship-to on the N1 (X12) or NAD (UN) has contained the most reliable primary identifier. As we move into a world where applications have to deal with detail level multiple Ship-to addresses on a document, a world where customers are increasingly moving processes that require goods to be delivered directly to a specific location within a factory, and a world where the customer could redirect goods to another location even while goods are in transit, we will need to rethink how we identify names, parties and locations.

Usage of Ship-To Addresses
Ship-to address needs to be treated as a variable data item, rather than a key identifier. A task group is evaluating how identifiers will be affected by the move toward multiple Ship-to addresses for one transaction/message, and this document will be revised based on the results of that work. trading partners may have to start using another identifier as a key value for identifying buyer or seller, such as Buying Party (N1*BY or NAD+BY). The following table illustrates the relationship between identifiers at various levels:

Interchange and Group Level IDs
The correct term for codes in the electronic envelopes ISA/GS and UNB is the "Sender/Receiver ID."

Historically, when trading partners are establishing a new relationship, parties often asked each other for their "DUNS" numbers. However, this is incorrect terminology, since DUNS numbers are only one of many possible choices for EDI trading partner identifiers.

There are DUNS (Data Universal Numbering System) numbers, DUNS+4, Telephone Numbers and proprietary IDs used for general identification of trading partners. DUNS numbers are the recommended choice. DUNS numbers are assigned worldwide by Dun and Bradstreet, who ensure that unique values are assigned for legal entities. However, since Dun and Bradstreet assign DUNS numbers only for legal entities, and many companies need identifiers for physical and functional entities, other choices are increasing in usage, such as EAN (European Article Numbering) numbers.

Sample Enveloping Segments
Second Level ID Not Used
The GS segment must always be sent in X12; if GS ID’s are not significant, the IDs used at the Interchange Level are used on the GS. In EDIFACT, if the Second Level ID is not used, it is not sent on the UNB segment.

X12

UN-EDIFACT
In UN-EDIFACT, default delimiters are used; if other delimiters are to be used, they can be specified on an optional UNA segment preceding the UNB segment. See "Segment and Data Element Delimiters" above.

UNB+UNOA:1+01234567879:16 +987654321:16 +961230:1528+12'

GS/Second Level ID Used

X12

ISA`00` `00` `00`0123456789 `01`987654321 `961230`1528`U`00200`012345678`0`P``|

GS`PS`EDIGSSDRID`EDIGSRCVRID`961230`1528`012345678`X`003020|

UN-EDIFACT
In UN-EDIFACT, default delimiters are used; if other delimiters are to be used, they can be specified on an optional UNA segment preceding the UNB segment. See "Segment and Data Element Delimiters" above.

The qualifier for sender and receiver IDs within the UNB segments are optional. This differs significantly from X12, and can cause problems for some EDI translators which require a sender/receiver ID qualifier. EIDX recommends the use of sender/receiver ID qualifiers.

UNB+UNOA:1+01234567879:16:EDI2NDLEVELSDR+987654321:16 :EDI2NDLEVELRCVR+961230:1528+12'

This segment, used alone, provides the most efficient method of providing organizational identification. To obtain this efficiency the "ID Code" (N104) must provide a key to the table maintained by the transaction processing party.

This method allows trading partners to avoid repeatedly transmitting and processing static data.

ASC X12: EXAMPLE OF N1 SEGMENT
N1*ST *ACME CO, INC.*1*04598776

UN: EXAMPLE OF NAD SEGMENT
NAD+ST+04598776::16’

The examples above show Name segments that sufficiently identify an address. In this case, the sender maintains a cross-reference table. When the table is queried for the key value "04598776", the sender’s internal identification code and the complete Ship-To address is retrieved from the receiver’s system. The internal identification code is a key into the receiving system.

Party Identification Code
The ENTITY IDENTIFIER CODE (N101) or PARTY QUALIFIER (NAD01) is a code which qualifies the content of the N1/NAD segment and N1 loop/NAD segment group in which it exists. For example, N101 or NAD01 = ‘ST’ indicates that the entire Name loop/segment group contains the ‘Ship-to’ location detail.

The following is the core set of name/entity/location/party identifiers which should be evaluated for inclusion in all transaction/message guidelines using the N1/NAD segment. Some transactions/messages may require additional party identifiers.

See Third-Party Reference Data section for clarification of terminology used in multi-party models.

Identifying Type of Code
The Identification Code (N104) or PARTY ID IDENTIFICATION (NAD02.C08201) is a code to represent the entire address as it is qualified by the N101/NAD01 on the segment.

he IDENTIFICATION CODE QUALIFIER (N103) or CODE LIST RESPONSIBLE AGENCY, CODED (NAD02.C08203) indicates the source of the code list.

The IDENTIFICATION CODE is often a key field to cross-reference the customer’s location codes to the supplier’s location codes. If the supplier can cross-reference the N104/NAD02.C08201 code, there is no need to send the N2, N3, N4 segments (ASC X12) or NAD03 - NAD09 elements (UN EDIFACT) with the detail physical addresses for the location.

Typically, the receiver cross-references the location code regardless of the N103 or NAD02.C08201 qualifiers which indicate who generated the code.

Party ID Code Cross-Reference
One method of converting the sender’s code to the receiver’s internal code is to simply use a conversion table. This practice is optional but highly recommended. The following types of tables may be used:

• General data conversion table which contains all trading partner codes
• A table for a particular trading partner or a group of trading partners
• A combination of conversion tables across trading partners

The conversion table may be internal to the translator process or it may be a table designed and accessed after the translator processes the data. Often conversion tables may be updated manually in the translator or uploaded from another process. Maintenance and updating of conversion table and the timing of table updates may be a support issue depending upon the responsibilities of the EDI coordinator and the business organization who may generate the data. The following examples illustrate the use of conversion tables:

Rules for Identification Codes 

1. N104/N NAD02.C08202 identification codes do not have to be unique on different name segments, i.e., same code could be used on BY and ST segments. One identification code can represent multiple addresses, but any Identification Code should represent one, and only one of each type of address (one BT address plus one ST address). The same code should not be used to represent another buyer address and another Ship-To address.
   
2. Different identification codes representing the same physical address may be used, as long as a particular identification code on a particular type of name segment from a particular trading partner represents only one address.

Examples:
1. In the examples for PCSRUS above, the same code (04598776, their DUNS number) is used for both their Buyer and Ship-To addresses, but the actual addresses are different. However, that code represents only one buyer address and only one Ship-To address.

2. In the examples for ACME above, proprietary codes are used. The buyer has assigned unique BY and ST codes, even though the physical address is the same. However, the code "ST01" on an ST type Name segment from Acme always represents the one address.

RECOMMENDATIONS FOR CROSS-REFERENCING PARTY ID CODES

1. Only static codes like currency or unit of measurement may be converted by EDI translators. Static codes do not require frequent updates. Dynamic codes like part numbers which require business data from users should be cross-referenced in the receiver’s application or any process outside of the EDI translator. Dynamic code may have frequent updates.
2. If cross-referencing is necessary in order to determine routing of the data, trading partners should discuss using higher level party identification, such as a GS level code or a UNB level two or level three code.
3. The receiving trading partner may cross-reference or convert any sender’s code. The receiver’s cross-referenced code determined by this process may be a key in a data base or table. Since Identification Codes may not be unique by themselves, the receiver may also need to concatenate the Identification Code data element with another data element. The additional information may come from 1) GS level sender ID code or the UNB level sender ID code, 2) other identifier of the trading partner defined in the EDI translator, 3) another code from within the transaction, or 4) retrieved data from the application in order to have a unique look-up key. The third case may be satisfied by examining both the N1 for the Distributor (DS) and the N1 for the Distributor Branch (DB).
4. If a trading partner sends an identification code data element, this code should be cross-referenced in the receiver’s process. It is usually the preferred code to cross-reference. It is not recommended that the free-form NAME data element be cross-referenced in the receiver’s process. Using free-form text to cross-reference is risky, since free-form text can easily be changed by the trading partner, and there are often usage inconsistencies, e.g., fully spelled out name versus abbreviation versus acronym. The example for ACME on the previous page illustrates this. The Identification Code data element is considered to be the cross-reference key from the sender’s code to the receiver’s code in the cross-reference (or conversion) table or data base. Some code cross referencing may need a concatenated (additional) cross-reference key to access the internal code.
5. Though a sender may send several Name segments, the receiver needs to cross-reference only the Name segments required by its applications. For example, if the internal Bill-To Location code can be determined from the SHIP-TO location code, further cross referencing and processing of the sent Bill-To location code from the sender may not be necessary.
6. The Receiver’s converted code (the resulting code from the cross-reference process) may be used to access a data base or table to retrieve other detailed data elements which are needed to successfully load the transaction into the system.
7. If a cross-reference or code conversion is done by accessing a simple table, then it is likely that a single key converted code is retrieved. A second step may be necessary to access other application data, if the data is needed to successfully load the transaction into the application.
8. If a cross-reference or code conversion is done by reading an expanded or a full application data base or table, then other application data may be retrieved at the same time.
9. Any response transaction should revert the codes back to those codes which were on the original source document. For example, purchase order acknowledgments should return the buyer’s original codes which were sent in the purchase order.

CASE (1): Regular Shipments Between Parties
The seller should cross-reference buyer location codes in Identification Code in data elements their system for the Bill-to location and Ship-to locations, if the Bill-To location cannot be determined given the Ship-To location. The seller may or may not need the N1 segment qualified by ‘BY’ for the Buying Party if the Ship-to location totally identifies the buying party.

CASE (2): Occasional Shipments Between Parties
The seller should cross-reference buyer location codes in the Identification Code data elements in their system for the Bill-to location and Ship-to locations, whenever possible, if the Bill-To location cannot be determined given the Ship-To location code. However, if the Ship-To location is not associated with a regular customer (as in a drop shipment order) and the seller does not maintain the ship-to location codes for these customers, then the full name and address are needed in the N2, N3, and N4 segments (ASC X12) or NAD03 - NAD09 elements (UN EDIFACT). The seller will capture the full address if necessary and not rely on the Identification Code value to cross-reference to retrieve the full name and address. Check with the trading partner for which N1 loops or NAD segment groups need the entire full physical address, since the Identification Code value cannot be cross-referenced. See "Name and Address Formats" below for how full name and address should be formatted.

The seller may or may not need the Name segment qualified by ‘BY’ for the Buying Party if the Ship-to location completely identifies the buying party. Check with the trading partner.

Drop Shipments
Two codes should be present in a transaction to indicate a drop shipment. One code is in the beginning segment which flags the order type as a drop shipment; one code in the N1/NAD segment to identify the end user.

In ASC X12, PO TYPE CODE (BEG02) in the BEG segment should be set to ‘DS’ for drop ship so the seller will review the Name segments properly. In EDIFACT, the Document Message Name/Coded (BGM01.C00201) should be set to ‘227’ for consignment order. (Note: The usage of the word "consignment" is different in Europe from U.S. usage.)

For drop ship orders, Identification Codes may be sent in the "Bill-To" and "Buyer" Name segments. The "Buyer" name segment should identify the particular buying location, and it should not identify the individual buying buyer. Instead of using a "Ship-To" Name segment, send the "End Use" name segment. The full name and address of the drop ship party can be sent in the "End User" Name segment if the supplier does not maintain location codes for the customers of their customers. See "Name and Address Formats" section for formatting the full name and address.

Name and Address Formats
It is important to note that there is no international standard for address format.  Every country has their own way of formatting addresses.  No component address fields should be treated as mandatory, and avoid limiting fields sizes based on the address formats of a few major countries.  There are many countries who use no postal code.  There are even regions where City name is not used.  The two most popular collections of address formats are on the Bitboost Systems Web site and the Business Start Page Web site.  There is an interesting exposition at www.iarchitect.com, starting about half-way down the page.

Note:  We don't advise using the information on the United States Postal Service Web site or other U.S. government Web sites about how international addresses should be formatted; the information does not match many countries' address formats.

In UN EDIFACT, one segment, the NAD, is used to send name and address information; it is the first segment in a segment group that may also contain contact information. In ASC X12, a series of segments called an "N1 loop" is used. The N1 (Name and Address) loop is named such because the first segment in the group is the N1 segment. The N1 loop in X12 transactions often consists of the segments illustrated in the table below. Different segments may be included in an N1 loop depending upon the transaction.

The following rules generally hold true for Name and Address data:

1. A transaction/message should include only necessary name and address information. The receiver’s process can ignore certain segments or elements if the receiving process does not need the detail. Often the receiving process can internally determine the detail data given data on specific Name and Address segments which they cross-referenced.
   
2. Detailed addresses need to be sent only if the receiving trading partner does not cross-reference key codes in the N104 ID code (ASC X12) or the NAD02/C08201 (UN) element. In ASC X12, detailed addresses are sent using the N2, N3 and N4 segments, and in UN EDIFACT, detailed address information is sent in elements NAD03 through NAD09 all on one segment.

ASC X12: Example of N1 Loop Segments

UN: Example of NAD Segment

SEG+QUAL+ID CODE+NAME+ADDITIONAL NAME+ADDRESS+CITY+COUNTRY SUB-ENTITY+POSTAL CODE+COUNTRY

NAD+ST+04598776::16+ACME CO, INC.+HDQTR:SUB ABC+133 MAIN ST:SUITE 23+CHICAGO+IL+60501+US’

Contact Names Format

Telephone and Fax Number Formats
Telephone numbers should be fully qualified, including country code and area code. The common international usage for formatting telephone numbers is to use spaces or periods, rather than parentheses or hyphens. However, the best method to use if a system is interrogating a number is to have the system ignore any separator characters, and process only the numbers. The separators are not part of the dialed number, and are used only to make numbers easy to read. 

Standards for telephone number formats and assignments for telephone country codes are set by the International Telecommunications Union (ITU).  Copies of the standard are not available for free, and not available for general Web access.

Format recommended by EIDX:

+<country code> <area or city code> <subscriber's exchange prefix> <subscriber's number>

An access code may be needed.  This is specific to the caller and the requirements of their country and/or service provider, so no access code should be included as part of telephone number. It is difficult to require a specific format from a trading partner, since systems typically have been set up without referencing a standard, and it's a lot of work to go in and change all the records in an existing system. 

Examples of Telephone/Fax Number Formats

E-mail Address Formats
The Communication Number field may be too short for some e-mail addresses, especially in older versions of ASC X12. In addition, INTERNET e-mail addresses use "@" (At sign) as part of the address, and other special characters such as "%", "#" may be part of an e-mail address format. These characters are commonly used data element separators in ASC X12. Trading partners may have to adjust their EDI translators if INTERNET e-mail addresses are to be exchanged.

Because of the limitations of the field length, standard abbreviations should be used for X.400 e-mail addresses.  X.400 e-mail addresses are rarely used today.

Examples of Abbreviations for X.400 Address Fields: