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)

Technical Best Practices


See also Notes about EIDX Supporting Documentation

Compliance Checking Transmissions

Compliance checking allows you to compare a file you've just received or a file you are about to see if it conforms to the chosen standard.  A compliance checking function in your gateway checks for one or more of the following:

  • Document structure
  • Formatting of data fields and records
  • Data field attributes, cardinality, and constraints
  • Data content for fields that use a pre-defined list of valid values (code lists)

Using a compliance checker can save a great deal of time and money when building data maps because it can automatically trap a number of errors; your data map only need trap errors that the compliance checker won't trap.

EIDX recommends that a sender validate  their own outbound documents for compliance with the standards before sending the documents to a trading partner.  Errors always have costs associated with them; if the receiving partner is trapping a sender's errors, the overall cost of processing the errors is doubled, because both parties have take action on the errors.

Private vs. Public Processes

EIDX develops guidelines and recommendations for public processes.  Although EIDX cannot dictate how companies should handle their private processes, certain activities must take place in private processes in order for the public processes to work, and EIDX does describe and make recommendations for those processes.

Resending Rejected Transactions

The reference here is to technical rejections - transactions with a transmission failure at the receiver's end  - not transactions that have been rejected for business reasons.   An original transaction/message may be resent under the following conditions:

  • The transaction/message has been rejected by the VAN or ISP and the error has been corrected.
  • The transaction/message has been rejected in the receiver’s gateway and the error has has been corrected.
  • The transaction/message has been rejected in the receiver’s translator/parser and the error has been corrected.

The following condition must apply:

  • The receiver’s business application system has not processed the given document, i.e., the transaction was not passed to the business application system.

If the original transaction is rejected by the business application system, then regular system procedures for error correction are employed. The transaction should not be resent since the transaction is now in the business application system.

Cross-Referencing or Converting Codes

EDI is a process which depends on codes processed by the sender’s and the receiver’s systems. The process is simplified if standard codes such as ISO, EDIFACT, ASC X12 and industry code lists are used as code sets in their applications. Examples include ISO country and currency codes, SCAC carrier codes, and UPC numbers.

If a standard code is not used, the sender or receiver of the code must cross reference or convert the code in order to use it. Consequently, the buyer’s codes must be cross referenced to the seller’s codes for processing in their respective system. Though the seller needs to cross reference codes to their internal codes for transaction processing, the seller should return the buyer’s original codes. The returned original codes enable the buyer to match the response transaction/message to the original transaction. Trading partners must agree on the required name and address segments.

Sellers should not expect buyers to maintain their sellers’ codes, such as sales order number, customer number, etc. Buyers should be expected to maintain a seller’s part number only in cases where the buyer has not assigned their own part number.

The codes or identifiers cross-referenced in the following table are representative. Order numbers, and any name, location, or product code in a transaction may require a conversion. These items having corresponding key data elements between the buyer’s and the seller’s systems and the data must be retained in each system.

In all cases where the code cross reference suffices to identify the trading partner’s locations in the receiver’s application, full physical names and addresses are not needed in the EDI transactions. Review the locations with the trading partners to determine if any full names and addresses are needed in the transactions.

Buyer’s Product ID Seller’s Product ID Either the buyer’s Product ID or the seller’s Product ID may additionally need an Engineering Change (Revision) number to accurately reference the product.
Buyer’s Ship-To Location Code Seller’s Ship-To Location Code for that Buyer’s Ship-To Location Code An additional N1/NAD Name segment for the ‘Buying Party’ may be needed if the buyer’s Ship-To Location Codes are not unique in the receiver’s system and the receiver cannot make use of the sender data in the electronic envelope.

Drop shipments to occasional customers who are not defined in the order entry system may require the full name and address.
Buyer’s Bill-To Location Code Seller’s Bill-To Location code for that buyer’s Bill-To Location Code If the Bill-To location can be identified in the system given the Ship-To location data, the Bill-To data may not be necessary in the transaction.
Buyer’s Corporate Location Code (Buying Party) Seller’s Corporate Location Code for that buyer’s Corporate Location Code Buying Party may only be needed in selective transactions.

If the buying party location can be identified in the system given other location data in the transaction, the buying party data may not be necessary in the transaction.
Buyer’s Remit To Location Code Seller’s Remit To Location Code for that buyer’s Remit To Location Code Seller often has the Remit-To Location Code defaulted in their system since a Remit To Location is linked to the buyer’s Bill-To Location Code.
Buyer’s location for the Seller’s Ship-From location Seller’s Ship-From Location The Seller is the owner of the location; hence, the buyer may need to cross reference the location when they receive it.
Buyer’s Contract Number Seller’s Contract Number There may be multiple buyer Contract Numbers to one seller Contract Number.
Buyer’s Carrier Code Seller’s Carrier Code for that buyer’s Carrier Code Recommend that all trading partners use SCAC codes from the transportation industry so code cross referencing is not needed.

Even if the business application does not use SCAC code, the EDI process can cross reference their internal codes to SCAC codes for the EDI transactions.
Buyer’s Currency Code Seller’s Currency Code for that buyer’s Currency Code ISO currency codes should be used so code cross referencing is not needed. See ISO document 4217.

Even if the business application does not use ISO codes, the EDI process can cross reference their internal codes to ISO codes for the EDI transactions.
Buyer’s Country Code Seller’s Country Code for that buyer’s Country Code ISO country codes should be used so code cross referencing is not needed. See ISO document 3166.

Even if the business application does not use ISO codes, the EDI process can cross reference their internal codes to ISO codes for the EDI transactions.
Purchase Order Number Sales Order Number A given purchase order number may have one or more corresponding sales order numbers. A sales order number should reference only one purchase order number.


Using Codes from Standards Data Dictionaries

If data element definitions, data attributes, and valid code lists are used consistently by all trading partners, cross referencing of sender codes to receiver codes may be substantially reduced or eliminated. Code conversions are overhead processing which may be avoided.

Business systems should consider using the following code lists and data definitions as their internal system codes:

  • ISO (International Standards Organization) codes
  • UN EDIFACT Data Directory
  • Industry association code lists, such as SCAC (Standard Carrier Alpha Code)
  • EDI Association code lists, such as EIDX
  • Other Association Codes, such as EAN (European Article Numbering)
  • ASC X12 Data Dictionary

The UN EDIFACT data dictionary is preferred over the ASC X12 Data Dictionary because of the long term direction to have the data dictionaries merged into the UN EDIFACT data directory. If the UN EDIFACT directory does not have the desired data element definition and code list, then the ASC X12 data dictionary may be necessary.

The transportation industry SCAC code list of carrier codes is recommended. This common carrier code list will avoid a lot of cross referencing of codes between buyer and seller systems.


ISO country codes, currency codes and unit of measurement codes should be used in all applicable transactions. Some ISO codes have both a numeric and alpha code set, or two character codes and three character codes. The alpha codes are recommended.


ISO or UN/ECE Document

Alpha Length

Web Sites (as of publication date of this document)


ISO 3166

2 and 3 or

ISO 4217:1981

3 or
Unit of Measurement

UN/ECE Recommendation No. 20


Free Form Text - Notes and References

Note segments provide a free form text data element. Notes have been used to convey standard boilerplate information and other special notes. Standard boilerplate information should be established outside of the electronic transactions/messages. They should not need to be sent with every transmission.

Notes are discouraged since they require a human review for interpretation even to ignore them for the application. This prohibits streamlining transaction processing.  It is desirable to codify all data in specific data fields. Data sent as free-form text requires a person to review and respond to the information to review the actual data. The notes are always different from each customer, e.g. 'CONTRACT IS 65476 AND DELIVERY QUOTE IS AB5434 ', 'PROMISE DELIVERY = AB5434'. Typically, systems cannot automatically interrogate the note looking for specific items like contract number or delivery quote number.

Often notes contain various authorization numbers in free form text format. If the type of data found in notes are common business fields, they should be defined in explicit data fields in the purchasing system in the long-term. This allows use of coded reference elements. Use of coded reference elements educes the chance of important data being overlooked which could have been  in free-form text.



Note Segments





Note Segment



Free Text Segment








The following are examples of types of information that can be codified.  This is not an exhaustive list.

X12 REF or N9 Qualifier UN/EDIFIACT RFF Qualifier OAG RosettaNet Meaning
CJ       Clause Number
DQ       Delivery Quote Number
GC       Government Contract Number
GP       Government Priority Number
PH       Priority Rating
PR       Price Quote Number


Segment and Data Element Delimiters

Delimiters in ASC X12

There are no default delimiters (a/k/a "service characters," "control characters") reserved for use in X12.  Allowable service characters should be discussed between trading partners.

Consider the impact of which delimiter you might choose.  For example, asterisks are often found embedded in product identifications (parts). When an asterisk is used as a data element terminator and an EDI translator encounters an asterisk embedded in a data field like a part, it ends the data element at the point where the asterisk is found. This causes the data to be misinterpreted by the EDI translator.

Use characters for delimiters which are most likely not used during data entry.   Note that @ and ~ may interfere with email addresses which may be sent.  Hexadecimal (non-printable) characters may be used as segment terminators, but are not recommended as data element separators.

The basic character set used in ASC X12 includes those selected from the uppercase letters, digits, space, and  special characters as specified in the Character Sets Table on this web site.   An extended character set may be used by negotiation between the two parties and includes the lowercase letters, national characters and other special characters in the Character Sets Table.

The X12 standard makes no provision for a release character.

Delimiters in UN-EDIFACT

UN EDIFACT has default service characters. The default service characters reserved for use in EDIFACT are:

Colon : Component data element separator
Plus sign + Data element separator
Question mark ? Release character
Asterisk * Repetition separator
Apostrophe Segment terminator

It is recommended that the defaults be used. However, the conditional Service String Advice (UNA) provides the capability to specify the service characters used in the interchange, if it is necessary to use characters that differ from the above defaults. UNA is transmitted as a single string of 9 characters prior to the UNB interchange segment.

Hierarchical Loops in ASC X12

Hierarchical (HL) segments allow the identification of dependencies among and the content of hierarchically related groups of data segments within the ASC X12 transactions. UN-EDIFACT does not use an equivalent to the HL loop. The following pages are for illustration only. It does not imply the order or relationships of HL loops in any particular transaction.

The official comments from ASC X12 and (EIDX Comments) are:

1. The HL segment is used to identify levels of detail information using a hierarchical structure, such as relating line item data to shipment data, and packaging data to line-item data. (It enables the sender to use the full grouping of a number of segments in each use of the HL loop.)

2. HL01 shall contain a unique alphanumeric number for each occurrence of the HL segment in the transaction set. For example, HL01 could be used to indicate the number of occurrences of the HL segment, in which case the value of the HL01 would be ‘1’ for the initial HL segment and would be incremented by one in each subsequent HL segment within the transaction. (This is generally the recommended EIDX Usage.)

3. HL02 identifies the hierarchical ID number of the HL segment to which the current HL segment is subordinate.

4. HL03 indicates the context of the series of segments following the current HL segment up to the next occurrence of an HL segment in the transaction. For example, HL03 is used to indicate the subsequent segments in the HL loop form a logical grouping of data referring to shipment, order, or item-level information. (HL03 indicates the context, or purpose, of the series of segments following the current HL segment up to the next occurrence of an HL segment in the transaction. For example, HL03 could be used to indicate the subsequent segments form a logical grouping of data referring to shipment, order, or item level information.)

5. HL04 indicates whether or not there are subordinate (or child) HL segments related to the current HL segment. (EIDX guidelines do not use HL04 because it usually adds very little value but it does involve a fair amount of processing overhead for both the sender and receiver of the transaction.)

ASC X12 HL Segments









Hierarchical ID Number (Mandatory) A unique number assigned by the sender to identify a particular data segment in a hierarchical structure




Hierarchical Parent ID Number Identification number of the next higher hierarchical data segment that the data segment being described is subordinate to

HL03blank_space.gif (96 bytes)



Hierarchical Level Code (Mandatory) Code defining the characteristic of a level in a hierarchical structure. There is a list of valid codes in ASC X12.

Sample List of Codes







Bill of Materials








Shipping Tare



HL04blank_space.gif (96 bytes)



Hierarchical Child Code Code indicating if there are hierarchical child data segments subordinate to the level being described.




No Subordinate HL segments


Additional Subordinate HL segments


The following table illustrates a representative example of possible coding of the HL loops. HL04 is illustrated only to show a full example. HL04 is not recommended by EIDX.

blank_space.gif (96 bytes) HL01 HL02 HL03 HL04
HL01 is just a counter of each HL loop in the given transactions HL02 indicates the parent HL loop number (HL01) HL03 is a code from a list of ASC X12 codes indicates the type of data HL04 indicates whether this HL loop has subordinate or no subordinate HL loops
Example 1
[email protected] 1 for first HL loop The first HL loop is not subordinate to any other HL loop. (Not Used; Leave Blank) ‘S’ for Shipment Data Optional HL04 not used.
[email protected] 2 for second HL loop This ‘Item’ HL loop is subordinate to the HL01=‘1’ (the shipment HL loop) ‘I’ for Item Data Optional HL04 not used
[email protected] 3 for third HL loop This ‘Item’ HL loop is also subordinate to the HL01=‘1’ (the shipment HL loop) ‘I’ for Order Data Optional HL04 not used
HL~1~~A~1 1 for first HL loop The first HL loop is not subordinate to any other HL loop. (Not Used; Leave Blank) ‘A’ for Assembly ‘1’ to indicate subordinate HL segment(s) exist.
[email protected] 2 for second HL loop This ‘Component’ HL loop is subordinate to the HL01=‘1’ (the assembly HL loop) ‘F’ for Component ‘0’ to indicate no subordinate HL segment(s) exist.
[email protected] 3 for third HL loop This ‘Subassembly’ HL loop is subordinate to the HL01=‘1’ (the assembly HL loop) ‘U’ for Subassembly ‘1’ to indicate subordinate HL segment(s) exist.
[email protected] 4 for fourth HL loop This ‘Component’ HL loop is subordinate to the HL01=‘2’ (the subassembly HL loop) ‘F’ for Component ‘0’ to indicate no subordinate HL segment(s) exist.
[email protected] 5 for fifth HL loop This ‘Component’ HL loop is subordinate to the HL01=‘2’ (the subassembly HL loop) ‘F’ for Component ‘0’ to indicate no subordinate HL segment(s) exist.



Last updated 06 February 2003