This section covers the technical aspects of EDI as specified in the figure below. The major topics are:
• Definitions
• Invoice Processing Example
• Communication Methods / Options • EDI Software
• X12 Data Format Description
• Accounts Payable • Accounts Receivable • Purchasing
• Inventory • MRP
Company A's Existing Information Systems: EDI Software Purchase Orders Invoices Remittance VAN & Communication System Account Activity & Status Payment Order/ Remittance Advice A B C D To Company-B
Section 2
EDI Diagram
Figure 6
Company A's Bank
Each of the above items, (A), (B), (C) and (D) will be discussed later in this section. • Item (A) is covered in the section Communication Methods / Options.
• Items (B) and (C) are covered by the topic EDI Software. • Item (D) is covered in section X12 Data Format Description.
Definitions
Mapping
Mapping is the process of identifying the relationship of internal systems data
elements to those in the X12 standards so that the interchange of information
Logging
Event logging is writing a time-stamped record for each key event to a file for later review by EDI operations, auditing, and/or security.
Transactions
Examples of X12 transactions are: Purchase Order, Invoice, Advance Shipping Notice, Contract Award, Freight Invoice, Price Sales Catalog, Railway Bill, and Payment Order / Remittance Advice.
Value Added Networks
Value Added Networks provide services such as: a data communication network, translation between versions and standards, audit trails between trading partners, transaction archiving, and education and consulting services.
Invoice Processing Example
The following events take place when Company-B sends Company-A an invoice. • Company-A's EDI software receives an invoice from Company-B through the
VAN.
• Company-A's EDI software verifies that the X12 structure is correct, and because company-B requested it, returns an acknowledgment to Company-B.
• The EDI software records in its logging database who the invoice was from, and when, and how the invoice was received.
• The EDI software translates the fields of the X12 invoice into the internal company format using the mapping information previously defined by the programmers. The actual exchange of information is normally in the form of a series of neutrally-defined flat files. The exchange of the flat files is usually through a batch job.
• The internal system receives the invoice and matches it against the internal Accounts Payable files. If what was delivered matches what was ordered, the company issues a payment to company-B. (At this point, many companies have human intervention to approve a payment over some preset limit.)
26
• Company-A reconciles the invoice with the internal system, and transfers the payment information to the EDI software mapping routines.
• Company-A's EDI software converts the payment information into a Payment Order / Remittance Advice X12 data stream and transmits to its bank by way of the VAN.
• The EDI software logs to whom and when the X12 transaction was sent. If it does not receive a functional acknowledgment within a predetermined amount of time, it will notify the EDI software operator that there may be a problem with the transmission.
• Company-A's bank receives the Payment Order / Remittance Advice from Company-A and issues an Electronic Funds Transfer to Company-B's bank. See Section 3 - Electronic Funds Transfer for further details.
• The invoice has been submitted and paid entirely electronically.
Communication Methods / Options
Two means exist for communicating with trading partners. The first is a direct connection not using a VAN. The second is through a VAN. Each has benefits and detriments.
Direct Connection
Direct connection is the use of the X.25 network, or leased or dial-up lines directly between two trading partners. EDI information is generally data communications insensitive. (This assumes the recommendations for constructing the transmission package are followed.) An EDI Envelope may be transmitted using a PC to PC file protocol such as X.PC or ZModem. It may be transmitted using normal mainframe to mainframe protocols such as 2780/3780.
The direct connection method assumes that two partners communicate with a single data communication protocol out of over ten available options. This works well when only a few partners are involved or if one party can dictate to all their trading partners the single protocol to use. As the numbers of partners increase, so does the number of protocol options one must support, and therefore, the management of the trading partner communications becomes more complex.
Direct EDI data communication connections b e t w e e n partners often become less effective as the number o f partners grows.
Direct connection can be less costly than connecting through an intermediate VAN. Direct connections, using leased line or dial-up, are not sensitive to the number of characters transmitted between the two parties. Direct connect costs are usually determined by a flat monthly charge or a per-minute usage charge. One of the VANs' normal charging methods is on a character volume basis.
Value Added Networks
VANs are large networks, usually international in nature, which transport EDI information among participating trading partners. VANs offer services such as EDI packet transportation, conversion between different EDI versions and standards, audit trails, security, trading partner identification, education, and consulting. VANs can greatly facilitate a company's entrance into the EDI arena.
VAN to VAN Interconnection
Over the last five years, the VANs have interconnected their networks so that any company using one of the several VANs can communicate with any other EDI user, whether on the same VAN or a different VAN.
VAN Charging Methods
VANs have different methods of charging for services and usage. The VANs' pricing structures change over time as they adjust to market pressures. Most have a flat monthly fee and charge by the volume of EDI envelopes or data characters transmitted. Several have minimum monthly charges. Many VANs charge for the detailed monthly billing statement. Many VANs offer volume discounts.
Even if one is using a VAN, it may be more c o s t - effective to implement a direct connection b e t w e e n high volume trading partners.
Most VANs surcharge users for EDI exchanges w i t h other VANs.
28
VAN Protocol Conversion
One of the significant offerings from the VANs is the ability to offer transparent data communications protocol conversion between trading partners.
Example: If Company-A transmits EDI using the IBM Bisynchronous 2780 protocol and Company-B uses the PC protocol X.PC, they will not b e able to communicate directly without changing to the other's d a t a communication protocol. However, by an intermediate VAN, t h e y could each communicate using their chosen protocol. The VAN would transparently convert protocols as it delivered t h e information between the two partners.
The protocols most VANs support are:
• X.25 • SNADS • TCP/IP • X.400 (84) • X.400 (88) • X.435 • 2780/3780 • 3270 BSC • 3270 SNA • RJE/HASP • X.PC • XModem • YModem • UTS
Not all VANs support conversion between all protocols. They may support conversion between 2780 and X.25 but not support conversion between 2780 and X.PC. These offerings are constantly changing.
It is important to query the VAN market through a Request For Information (RFI) to obtain the best value and price before entering into a contract with a VAN. A current list of VANs is included in Appendix C f o r this purpose.
EDI Software
The EDI software is the software that connects the company to the Electronic Data Interchange world. The software usually has the following features:
• Interchanges data with the existing in-house computer applications (Some PC packages do not offer this capability.)
• Communicates using different data communications protocols and VANs • Converts between different versions of the X12 transaction sets
• Converts between different industry-specific EDI formats
• Manages the specific trading partner profiles and interface requirements
• Verifies that the EDI transactions and surrounding EDI envelopes are properly constructed
• Records an event log of activity
• Reports the transaction activity and notifies the staff of specified error conditions
Existing In-house and EDI System Mapping
In a previous section, EDI Implementation Cost Model, the cost of integrating the EDI software with the internal computer applications was reported to be at least 5 times (5X) the cost of buying and installing the software and hardware.
Mapping is the activity that integrates the EDI and existing in-house systems. This can be a personnel-intensive effort. Many vendors are offering increasingly more sophisticated tools to support the mapping effort and reduce the personnel involved in integrating the two systems.
Before buying an EDI software package, review t h e mapping support tools carefully. The a p p r o p r i a t e tools can significantly reduce the effort and cost o f integrating EDI with the existing in-house systems.
30
Mapping Example
The following simple mapping example shows some of the issues involved in moving data back and forth between the internal purchasing system and the X12 purchase order in the EDI software system.
Example: Company-A orders 10 cases of widgets at $100 each f r o m Company-B. The information is found in internal file ABC, with t h e value "10 Cases" in field XYZ and the value "100" in field EFG.
These two pieces of information will be placed in three fields in the 4 3 r d record of the X12 Draft Version 3 Release 1 Purchase O r d e r transaction. The first four fields of this 25 field record are: L i n e Number, Quantity Ordered, and Unit of Measure Code, and Unit Price. Figure #7 shows what part of the actual 43rd record of the X12 P u r c h a s e
Order transaction would look like for the above data.
Purchase Order PO1 Record Example
PO1*1*10*CA*100*n/l
Record Type Name = PO1 Line Number
Quantity Ordered
Unit of Measure Code Unit Price
Data Element Separator =*
Data Segment Terminator
Figure 7
Note: The asterisk character is used as the Data Element S e p a r a t o r in t h i s example. The asterisk character starts each new field.
The single item "10 Cases" in the internal system was separated into t w o separate fields in the X12 document.
Once the mappings between "like" data items in the internal and the EDI software systems are defined, the data mapping can be automated and used for all future purchase orders.
Some of the fields in a transaction may not be used by all trading partners. The software may need to handle the differences in field and record usage for different partners -- a slightly different mapping for each trading partner. This can rapidly get complex. A software package with a highly functional Trading Partner Profile database can reduce the management and cost of maintaining the trading partner specifics.
X12 Data Format Description
Introduction
The information in this section is from the X12 Draft Version 3, Release 1 Standards. This section gives an overview of an X12 transaction and the interchange control structure, within which the transactions are placed, for transmission to trading partners. The primary section topics are:
• Introduction • Definitions
• X12 Data Structure Overview • X12 Interchange Control Structure • An X12 Encoded Data File Example
The X12 Standards define the data and interchange control structures of EDI transactions such as purchase orders, invoices, and shipping notices.
32
Definitions
X12 Standards
X12 is the inter-industry EDI standard in the United States of America.
Historically each industry, such as grocery or transportation, developed its own EDI standards. These industry standards required ongoing translation in order to communicate with other industries. In 1978, the X12 Committee was formed to create the cross-industry EDI standards. In 1979 the American National Standards Institute (ANSI), the official United States standards organization, chartered the X12 Committee as the official Accredited Standards Committee (ASC) for cross-industry EDI standards in the United States.
Interchange Control Structures
The interchange control structures are composed of two envelopes, one inside the other. The outside envelope will be called the EDI Envelope throughout this document. The inside is the Functional Group Envelope. See Figure #9.
The EDI Envelope, the outside envelope, contains the source and destination address data as well as other information.
The inside envelope, the Functional Group Envelope, is used to group "like" transactions, all purchase orders, all invoices, etc., together inside the mailing envelope -- the EDI Envelope.
The EDI Envelope will be the primary interchange control structure discussed below.
EDI Envelope
The EDI Envelope is the outside envelope of an EDI exchange.
ISA Header
The ISA Header is a record that forms the front of the EDI Envelope. It is a 16 data
IEA Trailer
The IEA Trailer is the record that forms the back of the EDI Envelope. It is a short two data element record. Between the ISA Header and the IEA Trailer, all EDI data is placed for inter-company transportation.
Data Segments
A data segment is analogous to a flat file record. Data segments are variable in length, have a two or three character name, and are composed of data elements.
Data Element
A data element is the field in X12. It, like fields in most applications, has a length, either variable or fixed, and a set of edit criteria, such as string, numeric, date, time, or specific character sequences.
Data Element Separator
The data element separator separates data elements in the file. The recommended
separator characters are specified in the X12 standards. For the sake of discussion,
"*" will always be used as the character that separates data fields. This implies that "*" may never be used within the actual data.
Data Element Separator Example
ISA*xxx*yyyyy**...*zzz*n/l
Data Segment First Field
34
Data Segment Terminator
The data segment terminator ends each record. It may be one of several characters. For the sake of discussion, "n/l", the new line character will always be used.
X12 Data Structure Overview
X12 Interchange Control Structure
The Electronic Data Interchange protocols were developed to transfer computer- readable business documents between computer systems independently of data communication protocols. The smallest meaningful piece of transmitted information is called a Transaction. Examples of transactions are business documents such as Purchase Orders, Shipping Notices, Invoices, and Purchase Order Status.
Throughout the discussion of X12 data structures t h e terms data s e g m e n t , s e g m e n t , and record are u s e d interchangeably. Additionally, the terms data
X12 Envelope Structure Diagram
Purchase Order Total: Invoice Total: Invoice Total: Invoice Total: Invoice Total: Purchase Orders Within To: From: Date: Time: Authorization Info: Standard Version: X12 Version: Ack. Requested?: Sender Cntrl #: Test Message?: EDI Envelope . Destination Invoices Within Figure 9Functional Group Envelope
Functional Group Envelope
A number of transactions may be transmitted to a trading partner in EDI envelopes called the Interchange Control Structure. The Interchange Control Structure is composed of two nested envelopes: (1) EDI Envelope and (2) the Functional Group Envelope. See Figure #9.
The EDI Envelope will be wrapped inside a data communication protocol, such as SNA, X.400, or 2780/3780, for transmission to the recipient.
36
record is part of a single transaction. Several transactions may be included within a single EDI Envelope, each with its own beginning ST and ending SE segment. See Figures #9, #10, and #13.
The ST record always begins a transaction, whether it is an invoice, a purchase order, or etc. The ST segment identifies the type of transaction contained between the ST and SE segments.
Transaction Identifi ers
Each transaction has a unique identifying number assigned. For example the number for the purchase order is 850, the invoice is 810, and the Payment Order / Remittance Advice is 820. The ST segment of an invoice contains the value "810" to identify the data between the ST and SE segment as an invoice transaction. See Appendix B for a list of transactions and their identification numbers. See Figure #14 for a usage example.
Data Segment
EDI X12 files are composed of ordered data segments. The data segments may be thought of in the same manner as the data processing records in a file.
Each record is terminated with the data segment terminator. The terminator used for the examples is the new line character represented by "n/l." See Figure #10.
Data Segment Names
An X12 file, unlike most flat files, contains many different record formats. Each record or data segment has a unique two or three character name to identify the record and its format as it occurs in the overall file. The name of the EDI Envelope Headers
segment is "ISA", EDI Envelope Trailer is "IEA", Transaction Headers segment is "ST",
Transaction Trailer segment is "SE", the name for one of the segments in a PO transaction is "PO1". These names occur in the actual data stream. See Figures #8 and #10.
Data Element
A data segment is composed of several data elements. Data elements are separated within the X12 file by the data element separator character, in this case an "*" asterisk.
The data segment terminator is defined in the ISA segment of the EDI E n v e l o p e for each t r a n s m i s s i o n . However, in practice, trading partners c o n s i s t e n t l y use a single agreed-upon character. The new l i n e character, "n/l" is used in the examples.
Each record in X12 has a name which is two or t h r e e characters long. The name actually occurs in the d a t a at the start of its record.
Each transmission may define the data e l e m e n t
38
Example X12 Data Stream Encoding
In the purchase order example following, Item 1, Item 2, and Item 3 are each a single occurrence of the X12 Data segment named PO1.
The PO1 record contains information such as the name, quantity, and price of the ordered product. In Item 1 in Figure #11, the product being ordered is a shovel with a vendor catalog number of 456, a quantity of 54, and a price of $0.99.
Purchase Order Example
Bill To: John Smith, ABC Corporation
Purchase Order
Deliver To: A&D Company
Item 1 54 Shovels @ $0.99 Each, Ven.Cat.#:456 Date: July 3, 1992
Item 2 1 Saw @ $5.49 Dozen, Ven.Cat.#:654 Item 3 12 Batteries @ $14.39 Each, Ven.Cat.#:DEF
Total: $226.60 Contact: Sally Smith @ (111) 234-4567
ACS
Consultive Services
00037551
1234 Easy Street, Great, TX 98761
Item 4
1009 Stella, St. Louis, MO 34567
Figure 11
In the Purchase Order example above, if the raw data stream of an X12 purchase order were printed and the data from Line Item 1 viewed, it would appear as in Figure #12.
X12 Encoding Purchase Order Example
PO1*1*54*EA*0.99*CA***VN*456n/l
Data Segment Terminator Data Element Separators
Product ID two empty fields
Unit of Measure
Product ID, VN=Vendor Catalog Price Code, CA=Price from Catalog
Quantity Ordered Unit Price
Assigned Identifier
Segment Name for the Line Item segment
40
X12 Interchange Control Structure
Introduction
This section discusses in detail the contents of the EDI Envelope structure.
The EDI Envelope is composed of two data segments: the ISA Header and the IEA Trailer. The transactions are placed between these two segments for transmission to trading partners. See Figure #13.
These two segments contain information usually associated with any paper mailing envelope:
• Source of information • Destination of information
• Date and time the envelope was mailed • Optional return receipt
Besides information contained on paper envelopes, the electronic EDI Envelope contains verification, security, and other information. Some of these will be discussed in more detail below.
The contents of the EDI Envelope may be either of two items: • TA1 Interchange Acknowledgment segment
• Transaction data
Interchange Control Structure Diagram
ISA - EDI Envelope Header
TA1- Interchange Acknowledgment Segment GS - Functional Group Header ST - Transaction Header Transaction Data SE - Transaction Trailer GE - Functional Group Trailer IEA - EDI Envelope Trailer
Figure 13
Data Portion of the EDI Structure.
EDI Envelope Header Detail
The EDI Envelope Header is a single Data segment composed of the data segment
The ISA Header is the front of the EDI E n v e l o p e . T h e IEA Trailer is the back of the EDI Envelope.
identifier characters ISA and 16 additional data elements for a total length of 114