This document has been provided as a courtesy to anyone who wants to learn more about EDI and how it applies to their TrueCommerce solution. We hope you find this guide to be helpful and informative, but please note that you need not become an EDI expert to enjoy the full benefits of the TrueCommerce Solution.

1. EDI Overview
A practical guide to EDI and
the TrueCommerce solution
This document has been provided as a courtesy to anyone who wants
to learn more about EDI and how it applies to their TrueCommerce solution.
We hope you find this guide to be helpful and informative, but please note
that you need not become an EDI expert to enjoy the full benefits of the
TrueCommerce Solution.
This document contains copyrighted information that is owned by TrueCommerce, Inc. and may not be
copied, disclosed, or otherwise used without the express written consent of TrueCommerce, Inc.

2. Table of Contents
1. What is EDI?... 2
1.1. EDI Defined... 2
1.2. The problem addressed by EDI... 2
1.3. The benefits of using EDI... 2
1.4. History of EDI... 3
1.5. ANSI ASC X12 Standards... 3
1.6. EDI Message Dissected... 4
1.7. Four Key Components of EDI... 6
2. How does the TrueCommerce solution work?... 6
2.1. TC.Net™... 7
2.2. TrueCommerce Transaction Manager™... 6
2.3. Electronic Partner Plug-Ins™... 6
2.4. Business System Plug-In™... 6
2.5. Professional Services... 7
3. Typical Transaction Flow... 7
1

3. 1. What is EDI?
1.1. EDI Defined
Electronic Data Interchange (EDI) is a set of standards that collectively provide a common
protocol or syntax for transacting business documents electronically. In essence, EDI is to
electronic commerce as grammar is to verbal communication – it is a set of rules and
guidelines that are applied when developing and implementing software and services
designed to transmit business documents electronically. Just as a group of individuals with
diverse backgrounds can use a common language (such as English) to converse with each
other, EDI provides a common “language” that enables businesses with dissimilar
computer-based business systems to communicate with each other.
Although by pure definition EDI is a standard, in many respects this description is a contra-
diction to the reality of EDI. There are myriad variations and versions of EDI standards in use
today. In this regard EDI is much like the English language with its many regional dialects and
colloquialisms. The federal government and numerous trade associations have developed
EDI standards for specific vertical markets, and large companies typically have additional
requirements that uniquely govern how EDI standards are explicitly applied to their electronic
transactions.
1.2. The problem addressed by EDI
Without the use of EDI or some other form of electronic commerce, companies must use a
paper-based system for transacting business – meaning paper documents are mailed or
faxed between companies to exchange information. In this scenario, a company typically
enters data into a PC-based business application (ex. accounting software), prints a form
containing the data (such as a purchase order or an invoice), and mails or faxes this document
to a trading partner (customer or vendor). The trading partner, after receiving the document
containing the data, must then re-key the data into their PC-based business application.
Inherent in this process is the inefficiency associated with waiting for large volumes of
business data to be transferred, processed and verified, and the potential for errors as the
information is manually transcribed.
The costs associated with data entry errors include:
lost revenue due to incorrect billing
chargebacks assessed by trading partners
added expenditures required to correct mistakes
delays in orders being processed
damage to reputation/client relations
1.3. The benefits of using EDI
Companies that are EDI enabled can send and receive business documents electronically with
their trading partners. In simple terms, EDI enables the computer system of one company to
“talk” to the computer system of another company and digitally exchange data. Because
this digital exchange of data is facilitated using computers, most if not all of the associated
business processes (such as data population and verification) can be automated so that they
occur with little or no manual intervention. As such, key benefits include the reduction or
elimination of data entry errors and transaction processing that is more expeditious
and streamlined.
2

4. Ultimately, using EDI can save a business time and money when sending and receiving vital
business documents. As an example, it is not uncommon for vendors who supply goods and
services to large organizations to receive payments for invoices sent via EDI as much as 30
days sooner than those sent via fax, simply because EDI transactions are processed by their
customers more quickly and efficiently. Receiving payments sooner can deliver real-world
savings by improving cash flow and mitigating the need to borrow money. Other savings are
realized through the reduction or elimination of costly data entry errors.
1.4. History of EDI
EDI has been under development in the U.S. in one form or another since the mid-1960s. In
1968, a group of railroad companies concerned with the quality of inter-company exchanges
of transportation data formed an organization to study the problem and to do something to
improve it. This organization was the Transportation Data Coordinating Committee (TDCC).
At about the same time, individual companies such as General Motors, Super Valu, Sears and
K-Mart were also addressing the inefficiencies of inter-corporate document movement by
using their own electronic (but proprietary) systems with their major trading partners.
The problem lay in the fact that each system was specific to that company with no standard
except in a proprietary sense. A hypothetical company in the late 1960s doing business with
GM, Sears and K-Mart therefore needed three different systems interfaces.
Several industries in the early 1970s sponsored a shared EDI system and usually turned it over
to a third party network. In some cases, the shared system was developed by the third party
for a group of common companies or industry trade group. Examples of this early sharing
include IBM IVANS, which the U.S. property and casualty insurance industry sponsored.
Another was ORDERNET, sponsored by the pharmaceutical industry.
These industry trade group systems had the same disadvantage as the company proprietary
EDI system: they were standard, but limited in scope, unable to communicate with other trade
group EDI systems. (ORDERNET, for example could not communicate with the transportation
carriers’ EDI system.)
In 1973, the TDCC decided to develop a set of standards for EDI between companies and to
invent a so-called “living standard” -- a standard that included standards on how to change
the standards! This resulted in the first inter-industry EDI standard in 1975 covering air, motor,
ocean, rail and some banking applications.
What evolved now includes the ANSI X12 standards first published in 1981 for general
business use, the WINS standards for the warehouse industry; the UCS standards for the food
and drug industry; HIPAA standards for the healthcare industry and TDCC standards for the
transportation industry. European development of TRADACOMS, ODETTE and JEDI started
around 1984.
In 1985, work started on EDIFACT (EDI For Administration, Commerce & Transportation), an
international standard through the auspices of the United Nations.
1.5. ANSI ASC X12 Standards
The most common EDI standard in use in the United States is known as ANSI ASC X12, or
simply as X12. ANSI is an abbreviation for the American National Standards Institute. The
institute has been coordinating standards in the United States since 1918 and maintains a
3

5. number of voluntary committees including the ANSI Accredited Standards Committee X12.
This committee is comprised of members from both the private and public sectors represent-
ing a broad range of industries. Subcommittees, using a consensus process, propose new
standards or modifications to existing standards.
1.6. EDI Message Dissected
An EDI message contains a string of data elements,
each of which represents a singular fact, such as a
price, product model number, and so forth,
separated by a delimiter. A delimiter is a character
that identifies the beginning or the end of a
character string (a contiguous sequence of
characters). The delimiting character is not part of
the character string. In EDI transactions, asterisks (*)
are commonly used as delimiters.
The entire string is called a data segment.
One or more data segments framed by a header
and trailer form a transaction set, which is the EDI
unit of transmission (equivalent to a message). A
transaction set often consists of what would usually
be contained in a typical business document or form,
such as an invoice or purchase order.
Examples of commonly used EDI transaction sets
X12ID Code Transaction Set Document Usage
850 Purchase Order (PO) A trading partner sends a PO to order
products from a vendor.
810 Invoice The vendor sends an invoice back to
their trading partner as a bill for the
products ordered.
997 Acknowledgement An acknowledgement is sent as a
receipt to the sender upon the retriev
al of a document.
856 Advanced Ship Notice (ASN) The vendor sends an ASN to their
trading partner specifying to a mutu
ally agreed level of detail the dates
and contents of a shipment. Many
businesses require the receipt of an
ASN from a supplier before the shipment
reaches their receiving docks.
820 Remittance Advice Remittance advice informs the vendor
that their trading partner has made a deposit
into their bank account.
852 Product Activity Data The Product Activity Data is used by trading
partners to advise vendors of inventory, sales
and other product activity information.
4

6. All transaction sets begin with the Transaction Set Header (ST) segment and end with the
Transaction Set Trailer (SE) segment, and typically other specific types of segments are re-
quired to be used in a particular sequence within a transaction set. As an example, the follow-
ing shows some of the segments that may be used within a purchase order and the required
sequence in which they must appear:
ID Title
ST Transaction Set Header
BEG Beginning Segment for Purchase Order
CUR Currency
REF Reference Identification
PER Administrative Communications Contract
TAX Tax Reference
FOB F.O.B. Related Information
CTP Pricing Information
PAM Period Amount
CSH Sales Requirements
TC2 Commodity
List Continues…
Many Transaction Sets have a unique beginning segment that immediately follows the ST
segment, such as the 850 BEG Segment used for purchase orders or the 856 BSN Segment
used for advance ship notices. The ANSI ASC X12 standard designates every available segment
as either “mandatory,” “optional” or “conditional,” and in some instances there are limits as to
the number of times a particular segment may be repeated at its location within a
Transaction Set.
A Loop refers to when a group of segments (two or more segments) are repeated in a
Transaction Set, such as a Purchase Order requesting multiple items. A Nested Loop refers
to when a loop exists within another loop, such as when multiple allowances are applied to
an item being ordered along with other items.
Once generated, Transaction Sets are transmitted using an electronic Envelope as defined
by the ANSI ASC X12 Standard. For every message there are three levels of enveloping:
1. The innermost level is the
Transaction Set, which can be
identified by the ST/SE segments.
2. The middle level, defined by GS/GE
segments, is the Functional Group
envelope and is used to group
similar types of Transaction Sets
(such as Purchase Orders and
Purchase Order Acknowledgements)
within a transmission.
3. The outermost level is the
Interchange envelope that is
defined by ISA and IEA segments.
The Interchange envelope encloses
the data from sender to one receiver.
5

7. 1.7. Four Key Components of EDI
Successfully implementing EDI requires the following four key components:
1. Connectivity with your trading partner(s) provides a means of transmitting EDI trans
actions, whether directly via the Internet or through a proprietary data network.
Companies that provide network-only services are typically called “Value Added Net
works,” or VANs.
2. Translation Software that is needed to translate the raw EDI data into a meaningful
format, such as a human-readable version.
3. Data Mapping and Integration provides the ability to seamlessly import and export
information from EDI-based transactions to and from your back-end business or ac
counting system, as well as properly format transactions being sent to your
trading partners.
4. Support for all of the above that provides technical proficiency as well as expertise
regarding the many protocols associated with establishing and maintaining EDI
relationships is also necessary.
2. How does the TrueCommerce solution work?
Your patent-pending TrueCommerce solution is comprised of the following:
2.1. TC.Net™
TC.Net is an Internet based transactional gateway across which your EDI transactions are
transmitted, providing connectivity with all your trading partners. TC.Net is compliant with
virtually any connectivity protocol, including AS1/AS2, HTTP, FTP and (if required)
VAN interconnects.
2.2. TrueCommerce Transaction Manager™
TrueCommerce Transaction Manager™ is translation software that converts business
documents into the ANSI ASC X12 EDI standard, as well as converts it out of the standard into
a meaningful format, such as a human-readable business form.
2.3. Electronic Partner Plug-Ins™
Electronic Partner Plug-Ins, or EPPs, are intelligent software modules that are programmed to
format your inbound and outbound transactions so that they match your trading partner’s
requirements. EPPs help keep you compliant and avoid chargebacks. Each one of your
trading partners may have different formats for POs, Invoices and Advance Ship Notices. You
will have one EPP for each of your trading partners and as you grow and add trading partners,
you simply add EPPs.
2.4. Business System Plug-In™
The Business System Plug-In or BSP, maps your EDI transactions so that they will seamlessly
transfer to and from your business or accounting system. You will have one specific BSP for
whatever business system you are operating. If you replace your business system, simply
6

8. swap out your BSP and the rest of your EDI solution remains.
2.5. Professional Services
Professional Services team members are available to provide unlimited phone & email
assistance at no charge Monday through Friday, 8 am to 7 pm EST. They’ll help you with
everything from setting up and configuring your TrueCommerce system, to establishing
and maintaining your EDI connection with your trading partners.
To contact the Professional Services team:
Call 1-724-940-5520 and press 3 when prompted
or send an e-mail to support@truecommerce.com
3. Typical Transaction Flow
Step 1: A buyer at your trading partner
issues a purchase order
(850 Transaction Set).
Step 2: A functional acknowledgement
(997 Transaction Set) is automatically
forwarded to your trading partner that
confirms the time and date the P.O. was
accepted by your EDI system.
Step 3: Using functionality built into
TrueCommerce Transaction Manager, you
can generate and send an Advance
Shipping Notice (856 Transaction Set) to
indicate to your trading partner what
items will be arriving and when.
Step 4: A functional acknowledgement
is automatically forwarded by your trading
partner to your TrueCommerce EDI system
confirming the time and date the ASN was
accepted by their EDI system.
Step 5: The order is filled and an Invoice (810 Transaction Set) is submitted.
Step 6: A functional acknowledgement is automatically forwarded by your trading partner
to your TrueCommerce EDI system confirming the time and date the invoice was accepted by
their EDI system.
7