CompTIA EIDX Technical Business Best Practices

• Compliance Checking Transmissions
• Public vs Private Processes
• Resending Rejected Transactions
• Cross-Referencing or Converting Codes
• Using Codes from Standards Data Dictionaries
• Free Form Text - Notes and References
• Segment and Data Element Delimiters
  • Character Sets Table
  • Hierarchical Loops in ASC X12

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.

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, Unit of Measurement
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.

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.

The following are examples of types of information that can be codified: 

Segment and Data Element Delimiters

Delimiters in ASC X12
There are no default delimiters (a/k/a service characters or 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:

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:

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.