X12 EDIFACT Mapping

In 1979, the American National Standards Institute (ANSI) chartered the Accredited
Standards Committee (ASC) X12 to develop uniform standards for interindustry
electronic exchange of business transactions-electronic data interchange (EDI)

In 1986, the United Nations Economic Commission for Europe (UN/ECE) approved the
acronym "UN/EDIFACT," which translates to United Nations Electronic Data
Interchange for Administration, Commerce and Transport. UN/EDIFACT is an
international EDI standard designed to meet the needs of both government and private
industry.

The UN/EDIFACT Working Group (EWG), a permanent working group of the United
Nations Centre for Trade Facilitation and Electronic Business (UN/CEFACT), develops
and maintains UN/EDIFACT

X12 is used in the USA but most of the rest of the world uses the EDIFACT transaction
sets.

Mapping
This is a partial list of the more popular transaction sets.

TRANSACTION SET/DOCUMENT ANSI EDIFACT

SET

PRODUCT/PRICING TRANSACTIONS

Price Sales Catalog 832 PRICAT

Price Authorization Acknowledgement/Status 845 --

Specification/Technical Information 841 PRDSPE

Request For Quotation 840 REQOTE

Response To Request For Quotation 843 QUOTES

Electronic Bid Form 833 --

ORDERING TRANSACTIONS

Purchase Order 850 ORDERS

Purchase Order Acknowledgement 855 ORDRSP

Purchase Order Change 860 ORDCHG

Purchase Order Change Acknowledgement 865 ORDRSP

Order Status Inquiry 869 ORSSTA

Order Status Report 870 ORDREP

Contract Award 836 --

MATERIALS MANAGEMENT TRANSACTIONS

Planning Schedule/Material Release 830 DELFOR

Shipping Schedule 862 DELJIT

Production Sequence 866 --

Ship Notice/manifest (ASN) 856 DESADV

Report of Test Results 863 QALITY

Material Safety Data Sheet 848 --

Contract Award 836 --

SHIPPING/RECEIVING TRANSACTIONS

Shipment Information (Bill of Lading) 858 IFTMCS

Receiving Advice 861 RECADV

Non-conformance Information-Disposition Transaction, 842 NONCON

Cause/Correction

INVENTORY MANAGEMENT TRANSACTIONS

Inventory Inquiry/Advice 846 INVRPT

Product Transfer and Resale Report 867 SLSRPT

Product Transfer Account Adjustment 844 --

Response To Product Transfer Account Adjustment 849 --

FINANCIAL TRANSACTIONS

Invoice 810 INVOIC

Freight Invoice 859 IFTMCS

Payment order/Remittance Advice (EFT) 820 REMADV

Lockbox 823 --

Financial Information Reporting 821 --

CONTROL TRANSACTIONS

Functional Acknowledgement 997 CONTRL

Application Advice 824 BANSTA

Trading Partner Profile 838 PARTIN

EDIFACT
From Wikipedia, the free encyclopedia

Jump to: navigation, search

UN/EDIFACT is the international EDI standard developed under the United Nations.
The acronym stands for United Nations/Electronic Data Interchange For Administration,
Commerce, and Transport. The work of maintenance and further development of this
standard is done through UN/CEFACT, the United Nations Centre for Trade Facilitation
and Electronic Business under the UN Economic Commission for Europe, in the Finance
Domain working group UN CEFACT TBG5. EDIFACT has been adopted by the
International Organization for Standardization (ISO) as the ISO standard ISO 9735. The
EDIFACT standard:

• Provides a set of syntax rules to structure data.

• Provides an interactive exchange protocol (I-EDI)
 • Provides standard messages (allows multi-country and multi-industry exchange)

This is an example EDIFACT message used to answer to a product availability request:

UNB+IATB:1+6XPPC+LHPPC+940101:0950+1’
UNH+1+PAORES:93:1:IA’
MSG+1:45’
IFT+3+XYZCOMPANY AVAILABILITY’
ERC+A7V:1:AMD’
IFT+3+NO MORE FLIGHTS’
ODI’
TVL+240493:1000::1220+FRA+JFK+DL+400+C’
PDI++C:3+Y::3+F::1’
APD+74C:0:::6++++++6X’
TVL+240493:1740::2030+JFK+MIA+DL+081+C'
PDI++C:4’
APD+EM2:0:1630::6+++++++DA’
UNT+13+1’
UNZ+1+1’

• ' is a segment terminator

• + is a data element separator
• : is a component data element separator
• ? is a release character

Note: The line breaks after each segment in this example have been added for readability.
Typically, there are no line breaks in EDI data.

UNH+1+PAORES:93:1:IA’- This is the header segment. It is required at the start of every

message - this one specifies that the message name and version is PAORES 93 revision 1
and it was defined by the organisation IA (IATA).

IFT+3+NO MORE FLIGHTS’ - This is an 'Interactive Free Text' segment containing the text
'NO MORE FLIGHTS'

UNT+13+1’ - This is the tail segment. It indicated that the message sent contains 13
segments.

Contents
[hide]

• 1 Structure
• 2 Current state of EDIFACT
 • 3 See also

• 4 External links

[edit] Structure

EDIFACT has a hierarchical structure. The top level is referred to as an Interchange.

Underneath an Interchange, one or more Messages can exist. Messages consist of
Segments which in turn consist of Composites and the final iteration is called an Element.
Elements are derived from the UNTDED (United Nations Trade Data Element Directory)
and are normalised throughout the EDIFACT standard.

A group or segment can be mandatory (M) or conditional (C) and can be specified to
repeat, for example C99 would indicate between 0 and 99 repetitions of a segment or
group, whereas M99 would mean between 1 and 99 repetitions.

A group, like a message, is a sequence of segments or groups. The first segment/group

beneath a group must be mandatory. If the logic of the situation demands it is conditional,
then the group itself should be made conditional instead.

[edit] Current state of EDIFACT

It seems there is a battle between XML and EDIFACT. An equivalent EDIFACT message
will be smaller in size than an XML message but the XML message will be easier to read
for a human (which is correct but of course not necessary because the content of such
messages are not developed to be read by human but by computers). Another possible
explanation is that compatibility is being favored over performance, since more tools
exist to work with XML data than with EDIFACT. As mentioned in the beginning,
EDIFACT-messages are smaller, in some cases about ten times smaller than XML-
messages, and therefore not recommended for large message contents. The advantage of
EDIFACT is the availability of agreed message-contents and the XML-world today needs
these contents to develop similar "agreed" contents for XML.

One of the emerging XML standards is RosettaNet, widely used in the semiconductor and
high tech industry in general. Another is UBL, currently being adopted by Scandinavian
governments as legal requirement to send invoices to governments. For example, all
invoices to the Danish government have had to be in electronic format since February
2005.

An other XML standard (also built by UN/CEFACT, like EDIFACT) is ebXML, often
seen as a standard best suited for small and medium enterprises.

However, EDIFACT is still widely used in the high tech, civil aviation, retail and tourism
industries and is likely to remain so for some time due to the amount of software making
use of it and the need for newer systems to be able to integrate with legacy systems.
Europe started early with adopting EDIFACT and therefore has a large installed base,
where as for example the Asian region started later with B2B implementations and is
therefore using more XML standards. As mentioned EDIFACT is widely used in Europe
in nearly all areas of economy and the application will grow in future. One example is the
energy market where the EDIFACT-Standard in Europe is a requirement for now and the
future.

X12 Document List

From Wikipedia, the free encyclopedia

Jump to: navigation, search

The following is a list of the approved EDI ANSI X12 documents for EDI version 4
Release 1 (004010):

Contents
[hide]

• 1 Order Series (ORD)

• 2 Materials Handling Series (MAT)
• 3 Tax Services Series (TAX)
• 4 Warehousing Series (WAR)
• 5 Financial Series (FIN)
• 6 Government Series (GOV)
• 7 Manufacturing Series (MAN)
• 8 Delivery Series (DEL)
• 9 Engineering Management & Contract Series (ENG)
• 10 Insurance/Health Series (INS)
• 11 Miscellaneous ANSI X12 Transactions Series (MIS)
• 12 Mortgage Series (MOR)
• 13 Product Services Series (PSS)
• 14 Quality and Safety Series (QSS)
• 15 Student Information Series (STU)
• 16 Transportation
o 16.1 Air and Motor Series (TAM)
o 16.2 Ocean Series (TOS)
o 16.3 Rail Series (TRS)
o 16.4 Automotive Series (TAS)

• 17 See Also

[edit] Order Series (ORD)

18
Return Merchandise Authorization and Notification
0

29
Cooperative Advertising Agreements
0

81
Invoice
0

81
Organizational Relationships
6

83
Price/Sales Catalog
2

85
Purchase Order
0

85
Purchase Order Acknowledgment
5

85
Ship Notice/Manifest
6

85
Shipment and Billing Notice
7

86
Purchase Order Change Request - Buyer Initiated
0

86
Purchase Order Change Acknowledgment/Request - Seller Initiated
5
87
Grocery Products Purchase Order
5

87
Grocery Products Purchase Order Change
6

87
Manufacturer Coupon Family Code Structure
7

88
Grocery Products Invoice
0

88
Manufacturer Coupon Redemption Detail
1

88
Retail Account Characteristics
5

88
Coupon Notification
7

88
Item Maintenance
8

[edit] Materials Handling Series (MAT)

511 Requisition

51
Material Obligation Validation
7

52 Material Due-In and Receipt

7

84
Request for Quotation
0

84
Response to Request for Quotation
3

84
Price Authorization Acknowledgment/Status
5

84
Material Claim
7

85
Asset Schedule
1

87
Product Authorization/De-authorization
8

87
Price Information
9

89
Item Information Request
3

[edit] Tax Services Series (TAX)

14
Notice of Tax Adjustment or Assessment
9

15 Electronic Filing of Tax Return Data Acknowledgment

1

15
Statistical Government Information
2

15
Business Credit Report
5

15
Notice of Power of Attorney
7

17
Revenue Receipts Statement
0

52
Income or Asset Offset
1

54
Notice of Employment Status
0

81
Electronic Filing of Tax Return Data
3

82
Tax Information Exchange
6

[edit] Warehousing Series (WAR)

88
Market Development Fund Allocation
3

88 Market Development Fund Settlement

4

88
Customer Call Reporting
6

89
Deduction Research Report
1

94
Warehouse Shipping Order
0

94
Warehouse Stock Transfer Shipment Advice
3

94
Warehouse Stock Transfer Receipt Advice
4

94
Warehouse Shipping Advice
5

94
Warehouse Inventory Adjustment Advice
7

99
Response to a Load Tender
0

[edit] Financial Series (FIN)

24
Account Assignment/Inquiry and Service/Status
8

81 Invoice
0

811 Consolidated Service Invoice/Statement

81
Credit/Debit Adjustment
2

81
Commission Sales Report
8

81
Operating Expense Statement
9

82
Payment Order/Remittance Advice
0

82
Financial Information Reporting
1

82
Account Analysis
2

82
Lockbox
3

82
Application Advice
4

82
Financial Return Notice
7
82
Debit Authorization
8

82
Payment Cancellation Request
9

83
Application Control Totals
1

85
Freight Invoice
9

98
Functional Group Totals
0

[edit] Government Series (GOV)

10
Business Entity Filings
5

15
Tax Rate Notification
0

15
Electronic Filing of Tax Return Data Acknowledgment
1

15
Statistical Government Information
2

15
Unemployment Insurance Tax Claim or Charge Information
3
15
Uniform Commercial Code Filing
4

17
Court and Law Enforcement Notice
5

17
Court Submission
6

18
Royalty Regulatory Report
5

19
Federal Communications Commission (FCC) License Application
5

25
Periodic Compensation
6

28
Voter Registration Information
0

[edit] Manufacturing Series (MAN)

19
Contractor Cost Data Reporting
6

83
Planning Schedule with Release Capability
0

84
Product Transfer Account Adjustment
4
84
Inventory Inquiry/Advice
6

84
Response to Product Transfer Account Adjustment
9

85
Product Activity Data
2

86
Receiving Advice/Acceptance Certificate
1

86
Production Sequence
6

86
Product Transfer and Resale Report
7

86
Order Status Inquiry
9

87
Order Status Report
0

89
Delivery/Return Base Record
4

89
Delivery/Return Acknowledgment or Adjustment
5

[edit] Delivery Series (DEL)

21
Logistics Service Request
9

22
Logistics Service Response
0

22
Cartage Work Assignment
2

22
Consolidators Freight Bill and Invoice
3

22
Motor Carrier Summary Freight Bill Manifest
4

22
Response to a Cartage Work Assignment
5

25
Purchase Order Shipment Management Document
0

85
Routing and Carrier Instruction
3

85
Shipment Delivery Discrepancy Information
4

85
Ship Notice/Manifest
6

85
Shipment and Billing Notice
7
85
Shipment Information
8

86
Shipping Schedule
2

88
Direct Store Delivery Summary Information
2

[edit] Engineering Management & Contract Series

(ENG)

19
Contractor Cost Data Reporting
6

50
Vendor Performance Review
1

50
Pricing History
3

50
Clauses and Provisions
4

53
Logistics Reassignment
6

56
Contract Abstract
1

56
Contract Completion Status
7
56
Contract Payment Management Report
8

62
Excavation Communication
0

62
Well Information
5

65
Maintenance Service Order
0

80
Contract Pricing Proposal
5

80
Project Schedule Reporting
6

83
Procurement Notices
6

83
Trading Partner Profile
8

83
Project Cost Reporting
9

84
Specifications/Technical Information
1

87
Component Parts Content
1
89
Product Dimension Maintenance
6

[edit] Insurance/Health Series (INS)

10
Insurance Plan Description
0

112 Property Damage Report

14
Report of Injury, Illness or Incident
8

18
Insurance Underwriting Requirements Reporting
6

25
Insurance Producer Administration
2

25
Underwriting Information Services
5

26
Individual Life, Annuity and Disability Application
7

26
Annuity Activity
8

27
Eligibility, Coverage or Benefit Inquiry
0

27 Eligibility, Coverage or Benefit Information

1

27
Property and Casualty Loss Notification
2

27
Insurance/Annuity Application Status
3

27
Health Care Provider Information
4

27
Patient Information
5

27
Health Care Claim Status Request
6

27
Health Care Claim Status Notification
7

27
Health Care Services Review Information
8

28
Wage Determination
8

36
Cargo Insurance Advice of Shipment
2

50
Medical Event Reporting
0

83 Benefit Enrollment and Maintenance

4

83
Health Care Claim Payment/Advice
5

83
Health Care Claim
7

92
Loss or Damage Claim - Motor Vehicle
4

92
Claim Tracer
5

92
Claim Status Report and Tracer Reply
6

92
Automotive Inspection Detail
8

[edit] Miscellaneous ANSI X12 Transactions Series

(MIS)

10
Name and Address Lists
1

15
Motion Picture Booking Confirmation
9

24
Data Status Tracking
2
81
General Request, Response or Confirmation
4

81
Cryptographic Service Message
5

86
Text Message
4

86
Electronic Form Structure
8

99
File Transfer
6

99
Functional Acknowledgment
7

99
Set Cancellation
8

[edit] Mortgage Series (MOR)

19
Real Estate Title Evidence
7

19
Loan Verification Information
8

19
Real Estate Settlement Information
9
20
Mortgage Credit Report
0

20
Residential Loan Application
1

20
Secondary Mortgage Market Loan Delivery
2

20
Secondary Mortgage Market Investor Report
3

20
Mortgage Note
5

20
Real Estate Inspection
6

26
Application for Mortgage Insurance Benefits
0

26
Real Estate Information Request
1

26
Real Estate Information Report
2

26
Residential Mortgage Insurance Application Response
3

26
Mortgage Loan Default Status
4
26
Real Estate Title Insurance Services Order
5

26
Mortgage or Property Record Change Notification
6

83
Mortgage Credit Report Order
3

87
Residential Mortgage Insurance Application
2

[edit] Product Services Series (PSS)

14
Product Registration
0

14
Product Service Claim Response
1

14
Product Service Claim
2

14
Product Service Notification
3

18
Return Merchandise Authorization and Notification
0

24
Product Source Information
4
88
Promotion Announcement
9

[edit] Quality and Safety Series (QSS)

13
Testing Results Request and Report
8

24
Animal Toxicological Data
9

28
Commercial Vehicle Safety and Credentials Information Exchange
5

28
Commercial Vehicle Credentials
6

84
Nonconformance Report
2

84
Material Safety Data Sheet
8

86
Report of Test Results
3

[edit] Student Information Series (STU)

13
Student Educational Record (Transcript)
0

13 Student Educational Record (Transcript) Acknowledgment

1

13
Student Loan Application
5

13
Student Loan Guarantee Result
9

14
Student Loan Transfer and Status Verification
4

14
Request for Student Educational Record (Transcript)
6

14
Response to Request for Student Educational Record (Transcript)
7

18
Educational Course Inventory
8

18
Application for Admission to Educational Institutions
9

19
Student Enrollment Verification
0

19
Student Loan Pre-Claims and Claims
1

19
Grant or Assistance Application
4

[edit] Transportation
[edit] Air and Motor Series (TAM)

10
Air Shipment Information
4

10
Motor Carrier Rate Proposal
6

10
Request for Motor Carrier Rate Proposal
7

10
Response to a Motor Carrier Rate Proposal
8

110 Air Freight Details and Invoice

20
Motor Carrier Load Tender
4

21
Motor Carrier Freight Details and Invoice
0

211 Motor Carrier Bill of Lading

21
Motor Carrier Delivery Trailer Manifest
2

21
Motor Carrier Shipment Status Inquiry
3

21
Transportation Carrier Shipment Status Message
4
21
Motor Carrier Pick-up Manifest
5

21
Motor Carrier Shipment Pick-up Notification
6

21
Motor Carrier Loading and Route Guide
7

21
Motor Carrier Tariff Information
8

25
Purchase Order Shipment Management Document
0

25
Pricing Support
1

60
U.S. Customs Export Shipment Information
1

60
Transportation Services Tender
2

71
Intermodal Group Loading Plan
5

92
Loss or Damage Claim - General Commodities
0

[edit] Ocean Series (TOS)

10 Vessel Content Details

9

30
Reservation (Booking Request) (Ocean)
0

30
Confirmation (Ocean)
1

30
Booking Cancellation (Ocean)
3

30
Shipping Instructions
4

30
U.S. Customs Manifest
9

31
Freight Receipt and Invoice (Ocean)
0

311 Canadian Customs Information

31
Arrival Notice (Ocean)
2

31
Shipment Status Inquiry (Ocean)
3

31
Status Details (Ocean)
5
31
Delivery/Pickup Order
7

31
Terminal Information
9

32
Terminal Operations and Intermodal Ramp Activity
2

32
Vessel Schedule and Itinerary (Ocean)
3

32
Vessel Stow Plan (Ocean)
4

32
Consolidation of Goods In Container
5

32
Consignment Summary List
6

35
U.S. Customs Status Information
0

35
U.S. Customs Carrier General Order Status
2

35
U.S. Customs Events Advisory Details
3

35
U.S. Customs Automated Manifest Archive Status
4
35
U.S. Customs Acceptance/Rejection
5

35
U.S. Customs Permit to Transfer Request
6

35
U.S. Customs In-Bond Information
7

35
U.S. Customs Consist Information
8

36
Carrier Interchange Agreement (Ocean)
1

[edit] Rail Series (TRS)

16
Train Sheet
1

40
Rail Carrier Shipment Information
4

41
Rail Carrier Freight Details and Invoice
0

41
Rail Carhire Settlements
4

41
Rail Carrier Waybill Interchange
7

41 Rail Advance Interchange Consist

8

41
Advance Car Disposition
9

42
Car Handling Information
0

42
Estimated Time of Arrival and Car Scheduling
1

42
Shipper's Car Order
2

42
Rail Industrial Switch List
3

42
Rail Waybill Request
5

42
Rail Revenue Waybill
6

42
Railroad Retirement Activity
9

43
Railroad Station Master File
1

43
Rail Deprescription
2

43 Railroad Reciprocal Switch File

3

43
Railroad Mark Register Update Activity
4

43
Standard Transportation Commodity Code Master
5

43
Locomotive Information
6

43
Railroad Junctions and Interchanges Activity
7

44
Shipment Weights
0

45
Railroad Event Report
1

45
Railroad Problem Log Inquiry or Advice
2

45
Railroad Service Commitment Advice
3

45
Railroad Parameter Trace Registration
5

45
Railroad Equipment Inquiry or Advice
6

46 Railroad Price Distribution Request or Response

0

46
Rail Rate Reply
3

46
Rate Request
6

46
Rate Docket Journal Log
8

47
Railroad Clearance
0

47
Rail Route File Maintenance
5

48
Ratemaking Action
5

48
Rate Docket Expiration
6

49
Rate Group Definition
0

49
Miscellaneous Rates
2

49
Rail Scale Rates
4

[edit] Automotive Series (TAS)

12
Vehicle Shipping Order
0

12
Vehicle Service
1

12
Vehicle Damage
4

12
Multilevel Railcar Load Details
5

12
Vehicle Application Advice
6

12
Vehicle Baying Order
7

12
Dealer Information
8

12
Vehicle Carrier Rate Update
9

16
Transportation Automatic Equipment Identification
0

16
Transportation Appointment Schedule Information
3

Electronic Data Interchange

From Wikipedia, the free encyclopedia
Jump to: navigation, search

Electronic Data Interchange (EDI) is a set of standards for structuring information to

be electronically exchanged between and within businesses, organizations, government
entities and other groups. The standards describe structures that emulate documents, for
example purchase orders to automate purchasing. The term EDI is also used to refer to
the implementation and operation of systems and processes for creating, transmitting, and
receiving EDI documents.

Despite being relatively unheralded, in this era of technologies such as XML services, the
Internet and the World Wide Web, EDI is still the data format used by the vast majority of
electronic commerce transactions in the world.

Contents
[hide]

• 1 Standards
• 2 Specifications
• 3 Transmission
o 3.1 Value Added Networks
o 3.2 Internet
• 4 Interpreting data
• 5 Advantages of using EDI
o 5.1 Advantages over paper systems
 5.1.1 Barriers to implementation
• 6 See also
• 7 Standards bodies

• 8 External links

[edit] Standards
Generally speaking, EDI is considered to be a technical representation of a business
conversation between two entities, either internal or external. Be noted that there is a
perception that "EDI" consists of the entire electronic data interchange paradigm,
including the transmission, message flow, document format, and software used to
interpret the documents. EDI is considered to describe the rigorously standardized format
of electronic documents.

The EDI (Electronic Data Interchange) standards were designed to be independent of

communication and software technologies. EDI can be transmitted using any
methodology agreed to by the sender and recipient. This includes a variety of
technologies, including modem (asynchronous, and bisynchronous), FTP, Email, HTTP,
AS1, AS2, MQ, etc. It is important to differentiate between the EDI documents and the
methods for transmitting them. While comparing the bisynchronous 2400 bit/s modems,
CLEO devices and value-added networks used to transmit EDI documents to transmitting
via the Internet some people equated the non-Internet technologies with EDI and
predicted erroneously that EDI would be replaced along with the non-Internet
technologies. These non-internet transmission methods are being replaced by Internet
Protocols such as FTP, telnet and email but the EDI documents themselves still remain.

As more trading partners use the Internet for transmission, standards have emerged. In
2002, the IETF published RFC 3335, offering a standardized, secure method of
transferring EDI data via e-mail. On July 12th, 2005, an IETF working group ratified
RFC4130 for MIME-based HTTP EDIINT (aka. AS2) transfers, and is preparing similar
documents for FTP transfers (aka. AS3). While some EDI transmission has moved to
these newer protocols the providers of the value-added networks remain active.

EDI documents generally contain the same information that would normally be found in
a paper document used for the same organizational function. For example an EDI 940
ship-from-warehouse order is used by a manufacturer to tell a warehouse to ship product
to a retailer. It typically has a ship to address, bill to address, a list of product numbers
(usually a UPC code) and quantities. It may have other information if the parties agree to
include it. However, EDI is not confined to just business data related to trade but
encompasses all fields such as medicine (e.g., patient records and laboratory results),
transport (e.g., container and modal information), engineering and construction, etc. In
some cases, EDI will be used to create a new business information flow (that was not a
paper flow before). This is the case in the Advanced Shipment Notification (856) which
was designed to inform the receiver of a shipment, the goods to be received and how the
goods are packaged.

There are two major sets of EDI standards: the United Nations recommended
UN/EDIFACT is the only international standard and is predominant outside of North
America; and the U.S. standard ANSI ASC X12 (X12) is predominant in North America.
These standards prescribe the formats, character sets, and data elements used in the
exchange of business documents and forms. The complete X12 Document List includes
all major business documents, including purchase orders (called "ORDERS" in
UN/EDIFACT and an "850" in X12) and invoices (called "INVOIC" in UN/EDIFACT
and an "810" in X12).

The EDI standard says which pieces of information are mandatory for a particular
document, which pieces are optional and give the rules for the structure of the document.
The standards are like building codes. Just as two kitchens can be built "to code" but look
completely different, two EDI documents can follow the same standard and contain
different sets of information. For example a food company may indicate a product's
expiration date while a clothing manufacturer would choose to send color and size
information.

Standards are generally updated each year.

[edit] Specifications
Organizations that send or receive documents from each other are referred to as "trading
partners" in EDI terminology. The trading partners agree on the specific information to be
transmitted and how it should be used. This is done in human readable specifications
(also called EDI Implementation Guidelines). While the standards are analogous to
building codes, the specifications are analogous to blue prints. (The specification may
also be called a mapping but the term mapping is typically reserved for specific machine
readable instructions given to the translation software.) Larger trading "hubs" have
existing EDI Implementation Guidelines which mirror their business processes for
processing EDI and they are usually unwilling to modify their EDI business practices to
meet the needs of their trading partners. Often in a large company these EDI guidelines
will be written to be generic enough to be used by different branches or divisions and
therefore will contain information not needed for a particular business document
exchange. For other large companies, they may create separate EDI guidelines for each
branch/division.

[edit] Transmission
Trading partners are free to use any method for the transmission of documents. In the past
one of the more popular methods was the usage of a bisync modem to communicate
through a "Value Added Network" (VAN). Some organizations have used direct modem
to modem connections, "Bulletin Board System" (BBS), and recently there has been a
move towards using the some of the many Internet protocols for transmission, but most
EDI is still transmitted using a VAN. In the healthcare industry, a VAN is referred to as a
"Clearinghouse".

[edit] Value Added Networks

In the most basic form, a VAN acts as a regional post office. They receive transactions,
examine the 'From' and the 'To' information, and route the transaction to the final
recipient. VAN's provide a number of additional services, e.g. retransmission of
documents, provide third party audit information, and act as a gateway for different
transmission methods, handling telecommunications support, etc. Because of these and
other services VAN's provide, businesses frequently use a VAN even when both trading
partners are using Internet-based protocols. Healthcare clearinghouses perform many of
the same functions as a VAN, but have additional legal restrictions that govern protected
healthcare information.

[edit] Internet

Until recently the Internet transmission was handled by nonstandard methods between
trading partners usually involving FTP or email attachments. There are also standards for
embedding EDI documents into XML. Many organizations are migrating to this protocol
to reduce costs. For example, Wal-Mart is now requiring its trading partners to switch to
the AS2 protocol.

[edit] Interpreting data

Often missing from the EDI specifications (referred to as EDI Implementation
Guidelines) are real world descriptions of how the information should be interpreted by
the business receiving it. For example, suppose candy is packaged in a large box that
contains 5 display boxes and each display box contains 24 boxes of candy packaged for
the consumer. If an EDI document says to ship 10 boxes of candy it may not be clear
whether to ship 10 consumer packaged boxes, 240 consumer packaged boxes or 1200
consumer packaged boxes. It is not enough for two parties to agree to use a particular
qualifier indicating case, pack, box or each; they must also agree on what that particular
qualifier means.

EDI translation software provides the interface between internal systems and the EDI
format sent/received. For an "inbound" document the EDI solution will receive the file
(either via a Value Added Network or directly using protocols such as FTP or AS2), take
the received EDI file (commonly referred to as a "mailbag"), validate that the trading
partner who is sending the file is a valid trading partner, that the structure of the file
meets the EDI standards and that the individual fields of information conforms to the
agreed upon standards. Typically the translator will either create a file of either fixed
length, variable length or XML tagged format or "print" the received EDI document (for
a non-integrated EDI environments). The next step is to convert/transform the file that the
translator creates into a format that can be imported into a company's back-end business
systems or ERP. This can be accomplished by using a custom program, an integrated
proprietary "mapper" or to use an integrated standards based graphical "mapper" using a
standard data transformation language such as XSLT. The final step is to import the
transformed file (or database) into the company's back-end ERP.

For an "outbound" document the process for integrated EDI is to export a file (or read a
database) from a company's back-end ERP, transform the file to the appropriate format
for the translator. The translation software will then "validate" the EDI file sent to ensure
that it meets the standard agreed upon by the trading partners, convert the file into "EDI"
format (adding in the appropriate identifiers and control structures) and send the file to
the trading partner (using the appropriate communications protocol.

Another critical component of any EDI translation software is a complete "audit" of all
the steps to move business documents between trading partners. The audit ensures that
any transaction (which in reality is a business document) can be tracked to ensure that
they are not lost. In case of a retailer sending a Purchase Order to a supplier, if the
Purchase Order is "lost" anywhere in the business process, the effect is devastating to
both businesses. To the supplier, they do not fulfill the order as they have not received it
thereby losing business and damaging the business relationship with their retail client.
For the retailer, they have a stock outage and the effect is lost sales, reduced customer
service and ultimately lower profits.

In EDI terminology "inbound" and "outbound" refer to the direction of transmission of an

EDI document in relation to a particular system, not the direction of merchandise, money
or other things represented by the document. For example, an EDI document that tells a
warehouse to perform an outbound shipment is an inbound document in relation to the
warehouse computer system. It is an outbound document in relation to the manufacturer
or dealer that transmitted the document.

[edit] Advantages of using EDI

[edit] Advantages over paper systems

EDI and other similar technologies save a company money by providing an alternative to
or replacing information flows that require a great deal of human interaction and
materials such as paper documents, meetings, faxes, email, etc. Even when paper
documents are maintained in parallel with EDI exchange, e.g. printed shipping manifests,
electronic exchange and the use of data from that exchange reduces the handling costs of
sorting, distributing, organizing, and searching paper documents. EDI and similar
technologies allows a company to take advantage of the benefits of storing and
manipulating data electronically without the cost of manual entry or scanning.

[edit] Barriers to implementation

There are a few barriers to adopting electronic data interchange. One of the most
significant barriers is the accompanying business process change. Existing business
processes built around slow paper handling may not be suited for EDI and would require
changes to accommodate automated processing of business documents. For example, a
business may receive the bulk of their goods by 1 or 2 day shipping and all of their
invoices by mail. The existing process may therefore assume that goods are typically
received before the invoice. With EDI, the invoice will typically be sent when the goods
ship and will therefore require a process that handles large numbers of invoices whose
corresponding goods have not yet been received.

Another significant barrier is the cost in time and money in the initial set-up. The
preliminary expenses and time that arise from the implementation, customization and
training can be costly and therefore may discourage some businesses. The key is to
determine what method of integration is right for your company which will determine the
cost of implementation. For a business that only receives one P.O. per year from a client,
fully integrated EDI may not make economic sense. In this case, businesses may
implement inexpensive "rip and read" solutions or use outsourced EDI solutions provided
by EDI "Service Bureaus". For other businesses, the implementation of an integrated EDI
solution may be necessary as increase in trading volumes brought on by EDI force them
to re-implement their order processing business processes.
The key hindrance to a successful implementation of EDI is the perception many
businesses have of the nature of EDI. Many view EDI from the technical perspective that
EDI is a data format; it would be more accurate to take the business view that EDI is a
system for exchanging business documents with external entities, and integrating the data
from those documents into the company's internal systems. Successful implementations
of EDI take into account the effect externally generated information will have on their
internal systems and validate the business information received. For example, allowing a
supplier to update a retailer's Accounts Payables system without appropriate checks and
balances would be a recipe for disaster. Businesses new to the implementation of EDI
should take pains to avoid such pitfalls.

Increased efficiency and cost savings drive the adoption of EDI for most trading partners.
But even if a company would not choose to use EDI on their own, pressures from larger
trading partners (called hubs) often force smaller trading partners to use EDI.