Clickable Business Models eBusiness Education Acronyms Cross References
B2B Content Standards EC Technology Standards Glossary Implementation Guidelines
Implementation Options General Recommendations References Methodology/Legends
 Home | Copyright Notice and Legal Disclaimers | Navigation Help | Tour! | Downloads | Contact Us | Site Index | Search
 Product Identification | Partner/Location IDs | Doc/Reference IDs | Dates | Other Best Practices |
EIDX General Supporting Documentation
Status:  Provisional draft.  Adapted from previous published version (Balloted and Ratified by Membership, June 1997)

EIDX General Recommendations - Party and Location Identification


Contents

See also Notes about EIDX Supporting Documentation


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:

What types of Location/Name Identifiers may be sent:

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:

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. At this writing, 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.

X12/UN SEG Sender DE
Pos.
Receiver DE
Pos.
Meaning
ISA/UNB I06/
S002.0004
ISA06/
020.01
I07/
S003.0010
ISA08/
030.01
X12: Outermost envelope segment; Interchange Sender ID.
UN: Sender/Recipient Interchange Identification, Level One
  I05/
S002.0007
ISA05/
020.02
I05/
S003.0007
ISA08/
030.02
X12: Outermost envelope segment; Interchange ID Qualifier.
UN: Sender/Recipient Interchange ID Qualifier

Description

This level identifies the electronic mailbox. The sender and receiver identification codes in this segment may not be available to be reviewed with the transaction/message which it surrounds. Its availability depends on the functionality of the EDI translator.

Relation

An electronic mailbox is by definition it’s own functional entity. There may or may not be a one-to-one relationship between electronic mailbox and either legal, physical, or other functional identity. The qualifier and ID value for each party must be unique for all parties involved in the transmission, including third-party networks.
GS/UNB 142/
S002.0008
GS02/
020.03
124/
S003.0014
GS03/
030.03
X12: Inner envelope segment; Functional Group Sender/Receiver Identification
UN: Sender/Recipient Identification, Level Two

Description

This level identifies a subgroup within the electronic mailbox, such as a site or division. The sender and receiver identification codes in this segment may not be available to be reviewed with the transactions which it surrounds. Its availability depends on the functionality of the EDI translator. In Europe, the Second Level ID is also known as "Reverse Routing Code".

Relation

Ideally, there should be a one-to-one relationship between this level ID and a legal, physical or functional entity.

Data Value

The value must be unique within the specified ISA or Level One identification. In effect, the ISA or Level One ID serve as a qualifier for this level GS or Level Two ID.

Override

A value here does not override the ISA/Level One ID, but further qualifies it.
N1/NAD 67/
039
N104/
02.01
blank_space.gif (96 bytes) blank_space.gif (96 bytes) Party Identification Code
  66/
3055
N103/
02.03
blank_space.gif (96 bytes) blank_space.gif (96 bytes) Party ID Code Qualifier

Description

The Party ID Code is a code to identify a location such as the customer ship-to location or invoice-to location. This data relates to the business applications and not the identifiers for the electronic mailbox.

Relation

This should always have a one-to-one relationship with a physical and/or functional entity. Name segments are discussed further below.

Data Value

The value must be unique within the specified GS or Level Two identification (if used) or within the specified ISA or Level One identification if GS/Level Two is not used.

Override

A value at the header level of the transaction/message does not override the previous level, but further qualifies it. Subsequent N1/NAD data sent at any lower level overrides data sent at the previous level. For example, an N1/NAD Ship-To code sent at the line item level overrides any N1/NAD Ship-To code sent at the header level.
SDQ/LOC 67/
3225
SDQ03/02.01 blank_space.gif (96 bytes) blank_space.gif (96 bytes) Specific Location
blank_space.gif (96 bytes) 66/
3055
SDQ02/02.03 blank_space.gif (96 bytes) blank_space.gif (96 bytes) blank_space.gif (96 bytes)

Description

A segment giving more specific location information, e.g. of the party specified in the NAD segment, such as internal site/building number, or the location to which part of the shipment is to be delivered.

Relation

This should always have a one-to-one relationship with a physical entity.

Data Value

Technically, the value must be unique only within the specified N1/NAD loop, but practically, it should be unique within the specified GS or Level Two identification (if used) or within the specified ISA or Level One identification if GS/Level Two is not used.

Override

A value here does not override the previous N1/NAD, but further qualifies it. Normally, this level of specific detail is not transmitted at a header level, but always at a detail line item or schedule level.

 


Enveloping Identification

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.

Don’t:

Ask partner for their DUNS number

Do:

Ask partner for their Sender/Receiver Ids

Don’t:

Ask just for one ID

Do:

Ask if they are using the same ID at the ISA and GS levels (X12)

Do:

Ask if they are using Secondary level or Reverse Routing IDs (UN)

 

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

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

GS`PS`012345678`987654321`961230`1528`12`X`003020|


UN-EDIFACT

In UN-EDIFACT, default delimiters are used; if other delimiters are to be used, they can be specified on an optoinal 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 optoinal 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'

 

 


Name Segments


The Name and Address segments are very important, since the sender/receiver IDs in the ISA/GS or UNB may not be sufficient to identify the key parties involved in a transaction.

N1 loops/NAD segment groups may contain complete free-form text addresses, or codes which trading partners cross-reference. The latter is the most highly recommended method for identification between parties making regular exchanges of data. In the comments for the segment in the ASC X12 dictionary, it says about the N1:

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.

ASC X12 N101 (DE98) Entity Identifier Code

UN NAD01 (DE3035) Party Qualifier



MEANING


COMMENT

28

EV

Subcontractor Firm performing part of the work for a contractor. Used by a prime contractor (end customer) or component supplier when identifying a contract manufacturer to one another.

AK

AK

Acknowledgment Recipient Party to whom (paper) acknowledgment should be sent. Many trading partners no longer use this Name segment, since electronic acknowledgments are expected.

BT

BT

Party to be billed for other than freight Also known as "Invoice To" party.

BY

BY

Buyer Party to which merchandise is sold.

CN

CN

Consignee Party to which goods are consigned.

DB

DB

Distributor Branch Specific branch of a distributor of goods. Used by an end customer or supplier when identifying a distributor’s branch to one another. Certain transaction may require both the DS and DB location codes.

DS

DS

Distributor Party distributing goods, financial payments or documents. Used by an end customer or supplier when identifying a distributor to one another.

EN

  End User This is the ultimate recipient of the product. Use this code for drop shipments.

MA

MA

Party for whom item is ultimately intended Used by a distributor when identifying an end-customer to a component supplier.

MG

MF

Manufacturer Party who manufactures the goods.

RE

  Remit To Party to receive the payment.

OP

PO

Ordering Party To be used only if ordering party and buyer are not identical.

PG

PG

Prime Contractor Party responsible for the whole project if other than the buyer. Used by a contract manufacturer when identifying an end customer to a supplier.

SE

SE

Selling Party Party selling merchandise to a buyer.

SF

SF

Ship From Location from which goods are to be shipped. Might be specified by a buyer if goods are to come from consigned inventory owned by the seller but physically located at the buyer’s plant.

ST

ST

Ship-To Location to which goods are to be shipped.

SU

SU

Supplier / Manufacturer Party which manufactures or otherwise has possession of goods, and consigns or makes them available in trade.

WH

WH

Warehouse Use to identify a third-party warehouse.

 

 


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.

ASC X12 N103 (DE66) Party Identification Qualifier

UN C08203 (DE3055) Code List Responsible Agency




MEANING



COMMENT

1

16

DUNS (Data Universal Numbering Standard) DUNS codes are used to identify legal entities.

9

N/A

DUNS plus suffix DUNS + suffix has been used in US to identify locations/organizations within legal entities.

14

9

EAN (European Article Number) EAN codes are used to identify locations/organizations within legal entities.

91

91

Assigned by seller or seller’s agent Used for seller’s proprietary ID codes

92

92

Assigned by buyer or buyer’s agent Used for buyer’s proprietary ID codes

 

 

 


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:


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.


NAME SEGMENT (X12/UN)

QUALIFIER MEANING

SENDER’S CODE

XREF TO

RECEIVER’S CODE

ADDRESS RETRIEVED FROM TABLE

N1~BY~PCSRUS~1~04598776
NAD+BY+04598776::16+PCSRUS’

Buyer

04598776

=

09876

PCSRUS, 1520 WOZNT WY
SANTA CLARA, CA 95051
N1~ST~ PCSRUS ~1~04598776
NAD+ST+04598776::16+PCSRUS’

Ship-To

04598776

=

09345

PCSRUS, 1 BACK ALLEY WY,
SAN JOSE, CA 95188
N1~SE~TOP DOG~91~3476
NAD+SE+3476::91+TOP DOG’

Seller

3476

=

34867

TOP DOG, 1 TOP DOG PL
DOGTOWN, NY 10013
N1~BY~ACME~92~BY01
NAD+BY+ST01::92+ACME’

Buyer

BY01

=

09877

ACME, 18 WILEY PL
SAN JOSE, CA 95188
N1~ST~ACME INC~92~ST01
NAD+ST+ST01::92+ACME INC’

Ship-To

ST01

=

09346

ACME, 18 WILEY PL
SAN JOSE, CA 95188
N1~SE~WE NAIL IT
NAD+SE++WE NAIL IT’
(Note: Using the Name data element and not the Identification Code)

Seller

(WE NAIL IT)

=

34868

WE NAIL IT, P.O. BOX A
NEW YORK, NY 10013

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. 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.
  8. 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 http://www.iarchitect.com/global.htm, 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

SEGMENT

EXAMPLE

N1 - NAME:

N1*ST *ACME CO, INC.*1*04598776

N2 -ADDITIONAL NAME:

N2*HDQTR*SUB ABC

N3 -ADDRESS:

N3*133 MAIN ST*SUITE 23

N4 -GEOGRAPHIC LOCATION:

N4*CHICAGO *IL *60501*US

 

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’

 

X12/ UN Element

X12 / UN Data Element



Description


Meaning

N101 / NAD01

98 / 3035

Entity ID code / Party Qualifier Code for the type of name/address being identified.

N102 / NAD03. C05801

93 / 3124

Name Free form text name for the party. This data may be ignored for further processing if the party identification code N104/NAD02.C08301 is cross referenced by the receiving system.

N103/ NAD02.
C08203

66 / 3055

ID Code Qualifier / Code List Responsible Agency Qualifier identifying what party or agency has assigned the ID code being sent, e.g., Buyer, Seller, DUNS.

N104 / NAD02. C08201

67 / 3039

ID Code / Party ID Identification The ID code for the party. This code is often cross referenced in the receiver’s system to 1) identify the party in their own application data base for their internal code and 2) retrieve the full name, address or other data, if needed by the receiving system. Elements containing free-form text are usually ignored, if the ID Code for the party is cross referenced to an internal code.

It is important to have this code uniquely cross referenced in the receiver’s system to distinguish the same number from multiple trading partners. If the code is not unique, the receiver should develop a method to distinguish trading partners using the same code.

N201 - N202/ NAD04. C08001 - C08005

93 / 3036

Name / Party Name Any extended name or title. ASC X12 allows two elements to contain this data, and UN EDIFACT allows five sub-elements to contain this data.

N301 - N302 / NAD05. C05901 - C05903

166 / 3042

Address Information. / Street and Number, PO Box Address lines for the party. X12 allows two address lines, and UN EDIFACT allows 3 address lines. It is advisable that the receiving system retain all address data if party ID Codes are not being cross-referenced.

N401 / NAD06

19 / 3164

City Name City/town/village for the Party

N402 / NAD070

156 / 3229

State/Province State or province for the Party.

N403 / NAD08

116 / 3251

Postal Code Postal code for the Party

N404 / NAD09

26 / 3207

Country Code Country code for the Party. In EDIFACT, use ISO 3166 two-alpha country code. ASC X12 is defined as 2-3 characters. EIDX recommends using the ISO country code.

N405

309

Location Qualifier See the ASC X12 standards for usage. Not used in EDIFACT.

N406

310

Location Identifier See the ASC X12 standards for usage. Not used in EDIFACT.

 

 


Contact Names Format

 

X12 / UN Element

X12 / UN Data Element



Description



Meaning

PER01 / CTA01

366 / 3139

Contact Function Code Code identifies the type of contact in this PER or CTA segment, e.g., ‘BD’ for buyer name or department, ‘SU’ for Supplier Contact.

PER02 / CTA02 C05602

93 / 3412

Department or Employee Free form text area for the name of the person or entity such as a department for contact.

PER03 and PER05 / COM01 C07602

365 / 3155

Communication Number Code Code indicates the type of number found in the following PER or COM field, e.g., ‘TE’ for telephone.

PER04 and PER06/ COM01 C07601

364 / 3148

Communication Number This is a free form area for a number such as a telephone or fax number or e-mail address.


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>

When dialing, 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:

Example format: Preferred format: Dialed as (preceded by local access code if applicable):
1-415-555-1234 +1 415 555 1234 14155551234
1 (408) 555-1234 +1 408 555 1234 14085551234
+32 16 76 54 40 +32 16 76 54 40 3216765440
44.1313.555.123 +44 1313 555 123 441313555123
65 555 1234 +65 555 1234 655551234

 

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:

Instead of:

Use

ADMD=

A=

COUNTRY=

C=

GIVEN-NAME=

G=

INITIALS=

I=

ORGANIZATION=

O=

PRMD=

P=

SURNAME=

S=


Last updated 06 February 2003