Your Guide to Getting Started with EDI

Getting started with EDI can seem like a daunting proposition. At first sight it can be difficult, highly technical, and even obscure. Once you dig a little deeper, however, you quickly see that EDI can be a great deal of help to small and mid- sized businesses that are seeking to automate their order processing and invoicing systems. From reduced workforce costs to increased accuracy, EDI can deliver the promise of E-Commerce to small and mid-sized businesses around the world. With this free E-Book you will get an in-depth introduction to EDI along with a primer on getting the most out of your EDI investment

What is EDI?

Electronic Data Interchange (EDI) is the computer-to-computer movement of routine business data in an approved standard format (e.g., ANSI ASC X12, EDIFACT or TRADACOMS). Companies that decide to trade business data with each other using EDI are called trading partners. The trading partners must decide which transaction sets (EDI business documents) will be exchanged electronically, what information will be included (i.e., what segments and data elements within the transaction set should be sent and received), and what method of communications will be used (e.g. asynchronous communications via a Value Added Network or bisynchronous direct communications).

The EDI Standard data format can be thought of as a common language that allows all companies to communicate with each other. That is, if all companies were able to accept or send data not only in their company's internal format(s), but also in an EDI standard format (ANSI ASC X12, EDIFACT or TRADACOMS), then all companies would have one data format in common for trading EDI mail.

DiTranslator translates the data coming into and going out of your PC, so you and your trading partner will be able understand each other's data. An example of an EDI exchange could involve a buyer and a seller. Suppose the buyer identified an inventory need. A purchase order is produced by manual data entry or from data within the buyer's business application.

DiTranslator will take this data and translate it into EDI standard format. The EDI data then passes through communications software that routes it over an electronic communications link to the seller. When the seller receives the transmission, the data is converted into a format that can be passed to the seller's order entry system or printed using their EDI software.

Once the seller has received the data, a Functional Acknowledgment should be sent to the buyer indicating the transmission was received, and detailing any errors found when the transmission was validated against the EDI standard. Then the seller may initiate an EDI Invoice to the buyer, and perhaps the buyer will respond by acknowledging the Invoice and paying for the items with an EDI Payment Order/Remittance Advice.

EDI Terminology


A group of data consisting of three components: an Interchange Control Header, a series of functional groups, and an Interchange Control Trailer. The Interchange Control Header and Interchange Control Trailer encloses the series of functional groups. An interchange can be thought of as a large envelope from your trading partner. Inside that envelope are individual, smaller EDI mail envelopes.

Transaction Set and Message

Realizing that many small to mid-sized companies fail to realize the benefits of EDI because of high cost and technological complexity, DiCentral develops affordable, plug-and-play EDI solutions. The company specializes in "Zero Effort" EDI to minimize installation, integration, and management cost and effort. With DiTranslator's wizard-based installation, the software installation was seamless. DiCentral prides itself on the support it provides to customers and Glazier appreciates the unique level of vendor support. "Altogether my experience with DiCentral has been excellent," he said. "They are an exceptionally customer-oriented company and have made my life a lot easier. I get my questions answered - without having to navigate through a bureaucratic help desk." With assistance from DiCentral, Glazier configured the EDI mapping for Advance Auto Parts and AutoZone, as well as integrated DiTranslator with their ERP application, Industrial Financial Systems (IFS). When an order comes into DiTranslator, the software automatically transfers the data to the IFS system. And when Flowmaster creates an invoice from IFS, the invoice is exported to DiTranslator, where it is sent to the customer.


A segment is a collection of elements that has a segment identifier, followed by one or more data elements. Between each data element is a data element separator.

Segment Identifier (ANSI ASC X12) and Segment Tag (EDIFACT)

A code that uniquely identifies a segment as specified in the appropriate segment directory. For example, the ANSI ASC X12 Invoice Name segment identifier is “N1.” Note: “Segment Identifiers” are also used in EDIFACT. An EDIFACT Segment Identifier is a unit of information consisting of a Segment Tag, which may be followed by a list of numbers that control how many collections of segments appear in the data.


A unit of information within a segment.

Composite Data Element

A collection of two or more data elements.

Data Element

The smallest unit of information in a transaction set or message.

Data Element Separator

A character used to separate elements in a segment.

Sub-element Separator

A character used to separate the data elements of an ANSI ASC X12 composite data element. Currently, sub-element separators are reserved for future use.

Composite Data Element Separator

Used in EDIFACT to refer to a separator that appears between each data element of a composite element.

Segment Terminator

A character used to indicate the end of a segment. Usually not a printable character in ANSI ASC X12, and typically an apostrophe (‘) in EDIFACT.


The control information, such as identifiers and addresses, that surrounds data. The data is bound together by header and trailer information. For details, see the ANSI ASC X12 or EDIFACT Interchange Control Structure section in this chapter.


ANSI ASC X12 Interchange Control Structure

Trading partners send data in a very specific format called the Interchange Control Structure. There are three basic levels of ASC X12 envelopes: the interchange envelope, the functional group envelope, and the transaction set envelope. The outermost envelope of EDI data is the interchange. An interchange consists of three components: an ISA Header segment, a series of functional groups, and an IEA Trailer segment. Header and Trailer segments contain sender and receiver addresses. They envelope the series of functional groups.

The second level of enveloping is a functional group. A functional group consists of three components: a GS Header segment, a series of similar transaction sets, and a GE Trailer segment. The Header and Trailer envelope the series of similar transaction sets. For example, if a trading partner sends a transmission containing 50 purchase orders and 30 invoices, all the purchase orders belong to a PO functional group and all the invoices belong to an IN functional group. A GS Header segment and a GE Trailer segment bind the functional groups together. The third level of enveloping is the transaction set level. Transaction sets consist of three components: an ST Header segment, a collection of related segments, and an SE Trailer segment. The ST Header segment and the SE Trailer segment bind the related segments to a PO functional group and all the invoices belong to an IN functional group. A GS Header segment and a GE Trailer segment bind the functional groups together. The third level of enveloping is the transaction set level. Transaction sets consist of three components: an ST Header segment, a collection of related segments, and an SE Trailer segment. The ST Header segment and the SE Trailer segment bind the related segments.

Reading an ISA Line

You can view the ISA line when you open the New Mail In file in WordPad, or the text editor you are using. The following is a sample ISA segment (followed by GS and ST segments). Find ISA (second line down, far left). This marks the beginning of the ISA segment. Find the fields contained within the ISA listed in order and described in the following table.

Reading A GS Line

You can view the GS line when you open the New Mail In file in WordPad, or the text editor you are using. The following is an example GS segment (between the ISA and ST segments). Find GS (fourth line down, far left). This marks the beginning of the GS segment. Find the fields contained within the GS listed in order and described in the following table.

EDIFACT Interchange Control Structure

Trading partners send data in a very specific format called the Interchange Control Structure. The EDIFACT Interchange Control Structure consists of an optional Service String Advice, followed by three basic levels of EDIFACT envelopes: the Interchange envelope, the Functional Group envelope, and the Message envelope. The Service String Advice (UNA) is a character string at the beginning of an interchange, defining the syntactical characters used in the interchange. The Service String Advice character string is optional. The Interchange Envelope consists of three components: a UNB Header segment, a series of functional groups or a series of messages, and a UNZ Trailer segment. The UNB header segment and a UNZ trailer segment contain sender and receiver addresses. The UNB and UNZ segments are mandatory.

A functional group consists of three components: a UNG Header segment, a series of similar messages, and a UNE Trailer segment. The Header and Trailer segments envelope the series of similar messages. For example, if a trading partner sends a transmission containing 50 purchase orders and 30 invoices, all the purchase orders belong to the same functional group and all the invoices belong to another functional group. Functional group segments are optional. If there are no functional groups, the interchange envelope surrounds a series of messages of the same type. For example, the messages must all be Purchase Order messages or they must all be Invoice messages. A message consists of three parts: a UNH Header segment, a collection of related segments, and a UNT Trailer segment. The Header and Trailer segments envelope the collection of related segments. Message Header and Trailer segments are mandatory. Segments are used as required.

Reading The UNA And UNB Lines

You can view the UNA and UNB lines when you open the New Mail In file in WordPad, or the text editor you are using. The following is an example of both the UNA and UNB segments.

Find UNB (second line down, far left). This marks the beginning of the UNB segment. Find the fields contained within the UNB listed in order and described in the following table.

Reading A UNG Line

You can view the UNG line when you open the New Mail In file in WordPad, or the text editor you are using. The following is a sample of the UNG (after the UNA and UNB segments and before the UNH and BGM segments).

Find UNG (third line down, far left). This marks the beginning of the UNG segment. Find the fields within the UNG listed in order and described in the following table.

Reading A UNH Line

You can view the UNH line when you open the New Mail In file in WordPad, or the text editor you are using. The following is an example of the UNH segment (following the UNA, UNB and UNG segments).

Find UNH (fourth line down, far left). This marks the beginning of the UNH segment. Find the fields contained within the UNH listed in order and described in the following table.

Functional Acknowledgments

The Functional Acknowledgment (ANSI ASC X12 997) transaction set acknowledges the receipt of functional groups. The Functional Acknowledgment is sent to report the system’s syntactical analysis of received functional groups. The system analyzes the data based on the ANSI ASC X12 EDI standards. Like all other transaction sets, a 997 Functional Acknowledgment can be sent or received by a trading partner. For example, if you send an (ANSI ASC X12) 810 Invoice, your trading partner may send you a Functional Acknowledgment in reply. The Functional Acknowledgment will indicate whether or not the transaction set had the correct syntax, looping, and structure. The Functional Acknowledgment does not indicate that the business data within the transaction sets is acceptable to your trading partner.

EDI and Data Communications

Data communications is an essential ingredient in the EDI process. It is the conduit enabling you to exchange electronic business transactions with your trading partners. In the EDI model, data communications is used as a subsystem to transfer information from a source computer to a target computer. It is important to understand that EDI and data communications are two distinct technologies. EDI defines an encoding standard for business information. Data communications defines mechanisms to transfer this EDI encoded information between your computer and your trading partner’s computer.

  • First, your customer prepares the Purchase Order data following the language rules of EDI standards. The Purchase Order data resides at a remote location.
  • You then launch a data communications session using DiTranslator, which connects your computer to this remote location. During this data communications session, a file transfer mechanism is used to move the Purchase Order data, already in EDI format, from the remote computer to your computer. The data communications session is then terminated.
  • You are then able to process the Purchase Order data using DiTranslator. You may need to send an Invoice to your trading partner. In this case, you prepare the Invoice using DiTranslator.
  • You then launch a communications session, which connects your computer to the remote destination. The Invoice, in EDI standard format, is moved from your computer to the remote computer during this communications session.

Occasionally, EDI standards define guidelines for data communications used in an EDI process. These guidelines may include time constraints, which help assure that responses to transaction sets received will be sent within a specific time period. EDI standards also define how the sender’s address and receiver’s address are encoded. However, EDI standards do not normally define the communications, which actually cause the data to move from source to destination. A variety of data communications modules are supported by DiTranslator. You simply use the module required to link to the desired remote location. This topic is discussed in more detail later.

The Value Added Network Concept

When you send a paper business correspondence to a trading partner you normally use the services of a post office or a private carrier. The Value Added Network (VAN) concept is fundamentally the same as an electronic post office. VAN services are provided by third party organizations. Using paper correspondence, either you or the recipient pays for the postage. The same model applies with VAN services. Normally, each sender pays the VAN a service charge based on the number of characters sent (typically kilo-characters).

Don’t be misled by the term network. This term does not imply a local area network (LAN) nor wide area network (WAN). A VAN simply contains a network of electronic mailboxes. When you are dealing with a trading partner through a single VAN, then both you and your trading partner will have private mailboxes in the VAN. Overall, the VAN may contain thousands of mailboxes. The only ones that you will be interested in are your mailbox and your trading partner’s mailbox.

The VAN conceptual model is very simple. Again, let’s consider the example in which you want to obtain Purchase Orders from your trading partner. Both you and your trading partner have private mailboxes in a single VAN. Your computer is at one physical location. Your trading partner’s computer is at a second physical location. And, the VAN resides at a third physical location. Your trading partner’s computer first sends the EDI Purchase Orders to the VAN. A file transfer mechanism is used to move the Purchase Orders from your trading partner’s computer to the VAN. The EDI format includes an outer envelope (much like the outer envelope of a paper letter), which defines the sender’s address (in this case your trading partner’s address) and a receiver’s address (in this case your address). Typical envelopes are the ANSI ASC X12 ISA, BG, and EDIFACT UNB envelopes.

When the VAN receives the EDI Purchase Orders, the VAN reads the envelope to determine the ultimate destination of the data. In this case, the receiver’s address indicates that the receiver is you, and the VAN will place the EDI Purchase Orders in your electronic mailbox. The communications session between your trading partner’s computer and the VAN is then terminated. Note that your computer is not yet directly involved with this process. At this point, the EDI Purchase Orders are stored in your mailbox. You may, then, use DiTranslator to launch a communications session between your computer and the VAN at your convenience. The DiTranslator communications module that you are using will automatically request the VAN send the data contained in your mailbox. The VAN will then send the EDI purchase orders from your mailbox in the VAN to your computer. Note that your trading partner is not directly involved in the communications session between your computer and the VAN.

There are a number of questions that might arise at this point. First, “How do I know if there is mail in my mailbox before I call?” The answer is you don’t know. Some VANs provide mailbox contents reports that you receive via a separate communications session. Normally, you simply check your mailbox at various points in time. If you call the VAN and there is no mail in your mailbox, the VAN will send a ‘no mail’ indicator during the communications session and DiTranslator will report the ‘no mail’ status to you. You can configure DiTranslator to periodically call the VAN to check for mail while you are away from the computer. See Automating DiTranslator for details.

Another question that might arise is, “Will my mailbox only contain data from one trading partner?” If you are only dealing with one trading partner on the VAN, your mailbox will contain only mail from that one trading partner. If you are dealing with multiple trading partners on the VAN, your mailbox may contain mail sent by one or more trading partners. Remember that when you are dealing with a VAN, your computer doesn’t connect to your trading partner’s computer.

So far, we have considered the case in which you receive mail sent by your trading partner through a VAN. Now let’s consider the case in which you send mail (such as Invoices) to your trading partner through a VAN. It is once again a two-stage process. First, you use DiTranslator to start a communications session between your computer and the VAN. DiTranslator will then send the Invoices to the VAN. The communications session between DiTranslator and the VAN is terminated. The VAN processes the envelope and determines to whom you are sending the mail. The VAN then deposits the mail in your trading partner’s mailbox. At some later point in time, your trading partner picks up its mail from its mailbox.

Note that when you call the VAN, you can send mail to multiple mailboxes belonging to your trading partners, but you can only receive mail from your mailbox. Similarly, your trading partner and other users of the VAN services cannot extract mail from your mailbox.

In certain cases, a situation might arise in which you prefer to use a particular VAN and a trading partner prefers to use a different VAN. DiTranslator can connect you to multiple VANs. Or, if you prefer, some VANs perform transparent interconnection between each other. You deal directly with your VAN and your trading partner deals directly with the other VAN. The two VANs take care of the rest. This is commonly known as a VAN interconnect. VAN communication is very common when exchanging EDI data with your trading partner. A second common approach is to use what is called pointto- point communication. In point-to-point communication, your computer establishes a direct connection to your trading partner’s computer in order to exchange EDI files. Under normal circumstances, your trading partner will rarely call your computer in order to establish a communications link and exchange EDI files. The most common occurrence is for DiTranslator to initiate the communications session. This is true for both VAN and point-to-point communication.

Data Communications Terminology

The data communications field is flooded with terms used to describe a wide variety of concepts. Data communications technology is continually enabling faster data rates on normal dial lines, and as a result, the complexity is increasing. The data rate has roughly doubled every 3 years. Fortunately, you don’t have to be a data communications expert to utilize data communications in EDI. DiTranslator does the hard work for you. However, it is a good idea for you to become acquainted with fundamental data communications terminology. This knowledge will enable you to make decisions when faced with multiple data communication options in dealing with EDI and trading partners. A data communications session is accomplished via a combination of software and hardware installed in your computer. The hardware consists of a modem, interconnection cables, as well as the telephone line. A modem (MOdulator / DEModulator) converts digital signals from your computer to analog signals on the telephone line, and vice versa.

Data communications software and modems work as a unit to accomplish a successful communications session. There are five major attributes, which collectively specify a communications session. They are:

  • Communication Types
  • Signaling Speed
  • Data Compression
  • Error Control
  • File Transfer Protocol

Communication Types

DiTranslator supports two types of data communications: asynchronous and bisynchronous. Asynchronous is the most popular data communications type. The shift towards asynchronous communications in EDI has gained momentum. Today, just about all VANs Support asynchronous communications. During an asynchronous communications session, start and stop bits are used to frame the data characters. This framing approach allows varying gaps of time to occur between each character sent. The two end points do not need to be precisely synchronized when data is sent. The receiving node can receive a character, and then wait idly for the next character. The start bit indicates the next character, and the stop bit flags the end of the character. This asynchronous approach does not require elaborate modem synchronization circuitry, which is why asynchronous modems are significantly less expensive than bisynchronous modems.

Signaling Speed

Two modems must use the same signaling speed during a communications session. The signaling speed is usually designated as the number of bits per second (bps) sent. Common speeds are 1200, 2400, 9600 and 14400 bps. The trend is definitely toward higher data rates, 9600 bps, 14400 bps, and higher. Not all VANs support these higher speeds. For cases in which a VAN does support a higher speed, you are not always guaranteed the data throughput will be at the highest speed. Noise bursts and low quality lines can cause higher speed modems to fall back to a lower speed, some modems do this automatically, some do not. The situation is much like that of a high performance car: you can’t usually utilize all the horsepower it has.

Data Compression

A common characteristic of the new breed of asynchronous modems is to have provisions to compress data before it is sent as electrical signals on the communications line. This has the overall effect of increasing the throughput while still using the same signaling speed. There are varying degrees of data compression offered by the various data compression standards. As with signaling speed, if a certain type of data compression standard is used, both modems must support it. Common data compression standards are tabulated later in the Data Communication Standards section.

Error Control

Error-free communications is absolutely essential. An error, which drops or adds a digit in an invoice, could mean disaster. There are a number of different error detection and correction standards used in modems and software today. The trend towards higher data rates underscores the need for assurance of error-free data transfers. A number of different error control mechanisms are tabulated later in the Data Communication Standards section.

File Transfer Protocol

The file transfer protocol used during a communications session defines the ground rules that must be followed by the two nodes. A common bisynchronous protocol is the 3780 bisynchronous protocol. Common asynchronous protocols include xmodem, ymodem, zmodem, and kermit, to name a few.

Data Communications Standards

Now that we have reviewed the general attributes associated with a communications session, let’s take a closer look at specific data communications standards. Recall that data communications standards are separate from EDI standards.

Any particular modem can contain any combination of the standards depending on how a modem manufacturer wants to position itself in the market. For example, a particular model can contain V.32 bis for signal speed, V.42 for error control and MNP for data compression. Modem manufacturers mix and match which set of standards their modems support. The important fact to remember is that not all asynchronous modems are compatible with each other, and not all asynchronous modems are compatible with all VANs.

Electronic Commerce in the 21st Century

There are a number of ways to define the term ”Electronic Commerce." Today, most consumers think of electronic commerce as the use of a Website to search and place an order or purchase a product. In fact, electronic commerce is significantly more involved and has been in practice for a number of years prior to the explosion of our current definition of e-commerce. As far back as 1994, the need was driven by work performed related to the electronic exchange of transaction documents for several large corporate entities (the most basic definition of electronic commerce), and the difficulties faced in performing tasks within this field.

One of the lessons from this work was that transactions can exist within separate business entities and between groups or divisions within the organization. This concept of ‘trading partners’ clearly shows that there are often many different trading patterns within and between organizations, and that there is no one solution that addresses both. Consider that within business-to-business markets, most businesses do the majority of their trading volume with a few loyal customers who have set trading patterns. Nevertheless, most businesses also have a lot of customers who trade with them in irregular patterns. This, of course, is a result of the inherent nature of the market and the position of different businesses within their market categories. There is very little if anything that an individual business can do to change this fact. As a result, the electronic commerce solutions they implement should take this inherent nature of doing business into account. Electronic commerce solutions are implemented as a tool in order to reduce costs and increase efficiency.

The Business-to-Business e-Commerce Value Chain

The Internet has revolutionized electronic commerce and has provided a standard protocol for the exchange of information, thus giving companies a window into a worldwide market for their products. Though electronic commerce has been around for a long time, electronic commerce has historically been prohibitively expensive for small and mid-sized businesses. The introduction of the Internet has made it possible for companies of any size to benefit from e-commerce. Figure 1 illustrates the electronic commerce value chain where the marketplace network is the Internet or Internet technology-based network. There are two orientations in the e-commerce value chain: (1) Transaction orientation and (2) Information orientation.

The Transaction Orientation

The transaction orientation is focused on business transactions that take place on the Internet, i.e., purchase orders, order confirmations, invoices, payments, etc. Network-based business transactions can be done by using the Internet or other types of networks. The characteristics of the different transaction-oriented electronic commerce solutions are listed in the table below.

Information oriented transactions on the other hand are practically always restricted to the Internet. The Internet has opened vast opportunities for suppliers to exchange information with their customers. Information about product design, specifications, capabilities, and availability flows freely through the value chain, while the supplier gets feedback through the value chain on market demands and needs. This information is not only restricted to product information, services can be offered and demanded, project plans can be exchanged and worked on by several parties, and workgroups can be formed to exchange joint information. A basic characteristic of the information orientation is that no transaction or purchase is performed. The transaction or purchase has taken place or will take place depending on the information exchanged.

The Fully Automated e-Commerce Solution

The definition of a fully automated solution is that there is full integration between the information systems on both ends. A significant characteristic of the fully automated electronic commerce solution is that each trading partner only works within their business application. The process is initiated by either an application or by an operator registering information into the business application. An example, for instance, is registering purchase orders in the purchase order system. The electronic commerce system will then automatically communicate this purchase order to the vendor. In a fully automated system all further exchange of information will be done by software applications. All necessary actions are triggered by the system. Companies with established trading relationships are using fully automated solutions with suppliers and/ or customers.Usually, the trading pattern is high volume and repetitive in nature. Important aspects are lead times, fault tolerance, and accuracy.

The Case of the Automobile Industry

A common trait for the automobile industry in more recent times has been “just-in-time” delivery and manufacturing. Since cars are high cost items, excess inventory is costly, and there is a risk of producing units that will not move in showrooms, increasing the need for discounts and purchase incentives. As a result, automobile manufacturers have increasingly pushed the inventory risk of raw material and sub-assemblies over to their suppliers, resulting in a massive focus on delivering materials and sub-assemblies only when needed by the manufacturers, a concept commonly known as “just-in-time” deliveries. In fact, it is fairly common for a supplier to build a new factory and warehouse close to the automobile assembly plant in order to fulfill the terms of their contracts of delivering just-in-time. Naturally, this has also led to high demands on the information system infrastructure in both organizations. The automobile manufacturers have fully automated assembly plants, where each and every aspect of logistics, planning and purchasing is being handled by the computers. The human involvement has been reduced to the minimum, as the risk of not having the right part at the right place at the right time, is too high. Car manufacturers have demanded that their suppliers cater to this situation by instituting similar information-systems capability on their side to handle the flow of information back and forth. Most supplier contracts within the automobile industry have specified time limits for the processing and response to any given exchange of information, with accompanying fines should these limits be exceeded. Some also risk the cancellation of contracts should they miss deadlines repetitively. In this environment, electronic commerce is not only an efficient tool, it is absolutely necessary in order to operate the business. It also means that there is a very high level of integration between the information systems being used on both sides, and the exchange of data is fully automated. This characterizes the Fully Automated Electronic Commerce Solution.

Hybrid Electronic Commerce Solution

Hybrid electronic commerce solutions use the World Wide Web in the electronic commerce process. The hybrid solution implies that there is at least one manual process involved to complete the exchange of data, and that this operation is done outside the customer's business application. A typical configuration could be a distributor that uses a web site that allows customers to manually make purchases. Four criteria have to be fulfilled to qualify as a hybrid solution: The customer enters the purchase order manually on the supplier's web site. The order confirmation is returned from the supplier both to the browser as a web page and an application-readable structured message (order confirmation/purchase order copy) is returned either through the browser as an ActiveX object, a Java Bean or an XML message, or an applicationreadable structured message (order confirmation / purchase order copy) is returned by e-mail. The structured message is automatically interpreted and registered in the customer’s business application/ERP system. On the supplier side, the process will be totally automated, while on the customer side there is one manual operation only – entering the purchase order on the web. The hybrid solution ensures that there is a complete integration between the business applications of both trading partners. The hybrid solution offers some superior qualities compared to the fully automated solution and the manual solution. Compared to the fully automated solution the hybrid solution is superior under the following circumstances:

  • The customer wants to have instant access to product availability before purchasing
  • The customer wants to have information about delivery times prior to purchasing
  • The customer wants to have information about substitute products available and the availability and delivery times of such products

None of this information is available in a fully automated e-commerce solution since the purchase order is either generated automatically or the person entering the purchase order can only access information stored in their own business application. Yet, the hybrid solution is inferior to the fully automated solution when the above mentioned circumstances are not of importance. The hybrid solution is superior to the manual solution under the following circumstances:

  • The customer needs to have all purchase orders registered in his own business application
  • The volume of purchase orders from the specific supplier is large enough to defend the substantial in-vestment the hybrid solution needs compared to the manual solution

The hybrid solution is not yet widely in use because the software technology is not commercially available yet. Companies can create a hybrid solution today by combining a web site for customers to make purchases as well as software for fully automated solutions to send an order confirmation to the customer. However, the technology where a structured message is sent back to the customer in ActiveX, XML, or Java Bean and integrated with the customer’s business application is not yet available. DiCentral is in the forefront of researching this technology and is committed to providing products that enable companies to take advantage of the superior qualities of the hybrid electronic commerce solution. We think that the hybrid solution will grow to become the most important business-to-business electronic commerce solution for purchases of production related products. The flexibility and integration capabilities of this solutionsatisfy both the supplier's and the customer's needs and wishes for an efficient electronic commerce solution. The hybrid solution truly reduces costs and increases the productivity of the trading partners, but it especially caters to the needs of the customer when using the World Wide Web to purchase products. .

Manual Electronic Commerce Solution

The modern manual electronic commerce solution is focused on Internet shopping, where there may be no prior relationship between the supplier and the customer. The key distinction between the manual electronic commerce solution and other solutions is that there need not be any prior relationship between supplier and customer since there is no data flow between the parties’ applications. In both the fully automated solution and the hybrid solution both parties need to agree on the structure of the application-to-application data flow. These characteristics make the manual electronic commerce solution not only the only viable solution for consumer-based electronic commerce, but also superior for new and infrequent business customers. The manual solution provides an effective tool, as it does not require any system integration on the customer side. Thus, the manual electronic commerce solution does not require an investment from the customer. For small and medium-sized businesses with low volume this is a very efficient way to purchase goods from their vendors. The purchasing volume for such companies is not large enough to make the necessary investment to move into a hybrid electronic commerce solution or a fully automated electronic commerce solution. The supplier’s Web site gives the customer immediate feedback on stock availability and delivery times.

The supplier enjoys the benefits of selling and marketing on the World Wide Web and, depending on the level of integration with the business application, the supplier can enjoy cost reductions and productivity increases in order-entry and order-processing.

The manual electronic commerce option is well suited for purchasing nonproduction products, such as office equipment, since the customer’s need for updating internal inventory systems is limited.

Getting Strategic with EDI

Your business has been profitable and successful for years, you understand your market, your product provides a solution to a critical need, and you just signed a major national retailer that will mean significant expansion for your business. The only problem is that you keep being told that you need to implement EDI and you are not quite sure where to turn. Your problem is not unique, in fact even companies that understand and use EDI often struggle with how much or how little attention to pay to EDI. Having a critical understanding of EDI, how it impacts your business, and how you can maximize use of this technology is critical for any small and mid-sized business in today’s market of margin pressures and high competition. As a business embarks on the road to effectively using EDI, it naturally progresses through three phases:

  • Phase 1 - Reactive - At this phase you have just started using EDI, usually as a result of pressure from a significant
    trading partner, EDI becomes a required nuisance.
  • Phase 2 - Proactive - Eventually the business begins to see the advantages of EDI and realizes the potential cost savings and decreased time to revenue. EDI becomes more important and dedicated resources are assigned to its expansion.
  • Phase 3 - Strategic - Ultimately EDI becomes a mature part of an integrated IT infrastructure with data seamlessly being shared with trading partners directly out of in-house ERP systems and becomes a critical strategic component of the company’s IT infrastructure in support of revenues and cost reduction.

Reactive: Getting Started with EDI

As a small business, your first exposure to EDI is often a forced one. Most frequently small businesses are faced with a daunting proposition: you have signed an agreement with a major national retailer - great news for your business - but in order to work with that business you are being mandated to use “EDI technology” to exchange transaction documents like purchase orders, advance shipment notices, etc. At this phase of the EDI adoption curve most businesses will typically opt for out-sourced services or for low cost, easy to use in-house software. Of course the benefits of the outsourced service is that the EDI work is done with little or no involvement from the business - there is no software to buy, no complicated terminology to learn - you just simply use a web-based system to receive purchase orders and enter advanced shipment notices, invoices and other transaction documents. While such a solution is perfectly viable for many small organizations that are gaining first exposure to EDI, questions begin to eventually arise that make an in-house solution more viable - both for the small business and for the growing one.


Regardless of available technology we have all seen stories in the press about sensitive credit card data, user information, and other types of restricted data being compromised. The simple truth of the matter is that there is only one way to guarantee that your data will not be at risk of compromise: keep it within your firewalls. Of course with any web-based system this is simply not feasible.


As with security, the availability of a web-based system is 100% reliant on an outside party. As a business begins to rely more and more on EDI, not having access to that data can have dire consequences on financial results in understated revenues, mis-allocated expenses, and break-downs in relationships with critical trading partners due to faulty or missing EDI data exchanges.

Integration with IT Policies

Although web-based systems try to account for issues such as secure access, integration of a web-based system into broader IT policies can be daunting. Disaster recovery, business continuity, access and security planning, and other mission- critical IT functions and policies are simply not designed to account for a web-based system; the task often proves impossible. It is at this stage that businesses begin to look to bring EDI in-house.

Proactive: Bringing EDI In-House & Under Control

Once a business has made the decision that EDI is important to the organization there are several considerations that need to be made. Carefully planning an EDI purchase, deployment and integration within the larger context of an IT policy must be done cautiously and in advance. 1) Selecting the right Vendor: Selecting a vendor with a solid reputation for developing reliable and easy to use EDI software is a critical first step. As a mid-sized business you want to ensure that the vendor has significant experience with EDI, that they will be able to understand your problems and provide you with the type of advice that you need in order to properly establish EDI as a critical function of your business. 2) Selecting the right software for your needs: Is the software easy to use? Does it have a reputation as a trusted, reliable product that can grow with your needs? Ensuring that you have positive answers to both questions will mean that you will have an easier time setting up EDI properly and that your staff will use it accordingly. 3) Understanding the growth potential: Does the vendor you are selecting provide an upgrade path to more sophisticated products? Will you be able to start with a single-user system and grow to a multiuser and perhaps to an integrated system as your EDI needs grow? Ensuring that you have growth opportunity with the investment you are making will mean not having to re-invest in new and unproven equipment as your business grows. 4) In what other ways can my vendor help? Can the vendor provide you with consulting services to help you best utilize your newly purchased EDI software? Will they provide you with reviews of your environment to help you identify areas that need bolstering? Ensuring that you work with a vendor that can help you and will treat you as a key customer is critical for the small and mid-sized business that does not want to get lost in the “other” revenue category of a multi-national corporation that happens to also provide EDI software.

Strategic: Using EDI for Growth & Profitability

Eventually as your business grows you will find that having EDI as a stand-alone, dedicated system begins to become cumbersome and begins to use too much man-power in managing data and reports. As your business matures and you invest in more sophisticated business tools it’s critical to keep EDI in the forefront of that planning. Integrating your EDI transactions into your ERP back-end system can save you money in faster transaction turn-around, reduced errors due to mistakes in re-keying information, and improved usage of EDI. Ensuring that the vendor you have selected for your EDI software can help you through this transition is critical to ensuring that when your EDI software becomes integrated with your ERP system it will be done quickly, efficiently, and with few worries. An integrated EDI system will have some significant up-front costs, but the long term benefits to a growing business will mean a return on investment measured in mere months. At this stage of development it’s also critical to understand how EDI will fit into the larger IT perspective. Is EDI part of the IT department’s disaster recovery plan (DRP)? Are you considering issues relating to security and access and how they relate to EDI? For EDI to become a strategic aspect of your company it must become a key component for both line of business and IT departments. At this stage having the right vendor to assist you and provide you with the right advice and the right tools will be critical.

Getting Strategic with EDI

As you explore the brave new world of EDI: or begin to ponder how to make better use of EDI in your business, DiCentral is ready and able to become a key partner in helping you develop your EDI strategy. With over twelve years of expertise in EDI, DiCentral has worked with Fortune 500 as well as small and mid-sized businesses and understands the complexities and advantages of a properly implemented EDI strategy. DiCentral can help you navigate EDI across the three phases of growth; our suite of products provides a robust, easy-to-use EDI translation package that has been deployed and is being used by thousands of companies world-wide.

5 Keys to EDI Integration Success

Over the course of the past six years the market for ERP software has seen dramatic shifts. During that period, over 60% of mid-market companies (companies whose revenues are above $100M per year but below $1B) have bought new ERP systems. As mid-market companies bring new and expanded ERP systems in-house they are beginning to face the same challenges that were once the exclusive domain of large enterprises. One of these requirements is the need to integrate data received via Electronic Data Interchange (EDI) into their newly acquired ERP and accounting systems. The benefits of EDI integration are well established and quantifiable both for major companies and for growing mid-market companies. The most significant benefit is that of the reduction or elimination of manual data entry and the associated costs - both in terms of manpower as well as costs associated with errors in data entry due to manual processes. As businesses begin to consider deployments of new systems they invariable also review internal processes and procedures.

Eliminating the manual data entry process required to move EDI data into ERP systems can produce significant savings for mid-market companies. A typical manual data entry process often involves a series of steps as laid out in the table on the following page. With even the most basic EDI transfer procedure, the steps typically involve the printing of a report, the duplication of this report for the benefit of multiple data entry clerks, and the manual keying of that data into the ERP system. The manual process does, however, not end here. It continues at the opposite end of the transaction - when orders are fulfilled the procedure must be reversed with printed reports of pending shipments being duplicated and provided to data entry clerks, who in turn re-create the data for the EDI system that is then used to communicate with outside trading partners. As the following table illustrates, the cost of such a procedure when measured in time can be astounding, especially when one considers that this procedure must be duplicated for every order and transaction that is processed in-house. Couple this with the enormous costs associated with mistakes and errors that are invariably made during the manual data entry processes, and an integrated solution that dynamically routes data between EDI and ERP systems becomes imperative.


The single biggest mistake mid-market companies often make in EDI integration is to underestimate the project they are about to embark on when they choose to integrate EDI. No matter what you read on vendor sites, EDI integration is complex; it requires in-depth knowledge of your data and it takes time. Being prepared for that will make you have more realistic goals of the time-frame involved, and the results you can expect. As you think about the EDI integration project it’s also important to think about how EDI integration will affect your company - both before and after your data integration project is completed. The first question is: how will your process change after you integrate your data? As you think about this question, consider all aspects of how EDI data is handled today. What reports are created? How are the reports printed? How often? What data is available? What should happen next to that data? Who is responsible for it? How will all of these processes have to change after your integration is complete? Planning for all these types of questions will ensure that you minimize the number of surprises you have after your integration project is complete. A second key question to consider is: who will need to be involved in the integration project? This may seem like an obvious question but it’s important to consider all aspects of the project and the people that may have valuable input. Where does the expertise reside in your organization? As companies grow and manual processes expand, much of the information that is vital to keeping processes functional and healthy is often undocumented and resides in the minds of the people involved with the daily work. Involving the people who do the work as early in the EDI integration planning as possible will ensure that you are exposed to all the different aspects of your manual procedures and how they will affect the integration process. An important related question is: how will these “manual operators” be affected by the EDI integration after it is complete? Companies often don’t consider the role these employees will have post-integration, but these people will come to realize that their jobs will become redundant and unnecessary in an integrated environment. Planning for the repurposing of these employees before embarking on the integration project will minimize the frustrations you have to deal with before and after it’s complete.


Any EDI integration project is going to have initial problems. Once again, don’t believe the hype - you can plan as much as you want but you will always find that there are challenges in your EDI integration project that you simply did not foresee. For this reason, it is critical that you follow a process that allows for mistakes and unforeseen challenges. As your EDI integration project proceeds, you will notice that it is significantly easier to deal with unexpected circumstances on a small scale than it is on a large scale. For this reason, we always recommend that our clients begin with a sub-set of their EDI integration goals. Perhaps it’s integrating only the data from one or two of your trading partners that use EDI - the smaller ones - so that you can iron out some issues before you move on to the larger trading partners. It’s important to remember that you are integrating data that is critical to your operational health; act accordingly. As you being to wrap up your smaller “trial” integration project it’s important to have a review process in place where the team can analyze what went right, what went wrong, and what could have been done differently or better. Through this process of implementation, review, and re-implementation, problems will be ironed out and your chances of success will be maximized when the larger integration project is embarked upon. As you start on the larger EDI integration plan, be sure to set it up so that the integration happens in stages; don’t attempt to do everything at once. Stage your integration so that each set of data that can be segmented is handled as an individual mini-project. You may start by integrating by trading partner, or perhaps by transaction set with all in-bound purchase orders first. Regardless of how you do it, make sure that you have thought through a process that you can manage and that has the least negative impact on your organization.


You have looked at your existing processes, you’ve planned a phased implementation of your EDI integration, you are ready to go, right? Maybe. For mid-market companies one of the biggest implementation challenges often deals with data. There are two aspects of the data you are going to be dealing with that you need to consider: data cleanliness and subject-matter expertise. Data cleanliness simply means that before you embark on your EDI integration project you should consider the state of your data and how it will impact the project. More specifically, think about issues like duplication or inaccurate data; for example, you may employ a look-up table to cross reference purchase orders with stock keeping units (SKUs) that your company uses. Duplicate SKU numbers with different descriptions may not be a problem for a data entry clerk who may intuitively know the difference, but they could create significant problems for your data integration project. This is just one example of how dirty data could impact your project. As you prepare for your EDI integration project, review all the data sets that are going to be impacted by the project and ensure that the data has been scrubbed and corrected.

A second aspect of managing data that mid-market companies often have trouble with is access to a subject-matter expert. It’s important to understand that whether you are doing the data integration with consultants or with services provided by your EDI integration vendor, their subject matter expertise is data integration - not necessarily the systems involved. For this reason you will need access to someone who is familiar with your ERP and your EDI systems to be able to answer technical questions as they arise during the project. Having access to such a subject matter expertise will make it significantly easier to get your project completed on-time and within budget.


As you research EDI integration solutions for your business, you are bound to find yourself on a vendor’s website with an impressive list of companies to which they have sold data integration software. As a mid-market business it’s important to keep in mind that just because it worked for a Fortune 500 organization does not necessarily mean it will work for you. As you embark on your vendor and software selection process, consider several key issues about the software you select that will help you narrow your field:

Q1 What is my budget?

This may seem obvious but data integration projects are notorious for going over budget. The reason for this is two-fold: scope-creep is responsible for a significant part of the problem - companies that have’nt prepared properly have to adjust for changing circumstances. The second reason, however, is related with poor planning regarding software. It’s critical that your software budget is established as early as possible so that when possible vendors are selected, you will be able to quickly gauge whether the software being considered is within your budget.

Q2 Who will do the integration work?

It’s surprising how often companies will embark on an EDI integration project only to realize after they have already committed to it, that they don’t have any in-house expertise to perform the integration. Learning how to work with data integration packages is not something you should embark on unless you plan on having that subject-matter expertise inhouse even after your integration is completed. If you decide to do the integration using in-house resources, the software features and ease-of-use utilized in the implementation process should be important factors in your decision. If, on the other hand, you will use third party consultants or rely on the software vendor to perform the work, the features of the software you should focus on might be more related to your post-implementation needs.

Q3 What formats will you need to support?

Understanding the file formats involved in your EDI integration project goes back to having a subject-matter expert available. How does your ERP system import and export data? Via a flat-file? Proprietary format? XML? APIs? What kind of format does your EDI system use? Having the answers to the questions will allow you to know to ask the software vendor if they support the specific formats you need to use.

Q4 How fast does it need to be?

The speed of EDI integration software is a factor that mid-market companies don’t often consider. After all, just about any data integration package on the market today can handle the data volume generated by a mid-market organization. The key question to consider however, is room for growth. As your business grows, your data volumes will expand exponentially; and since data integration is not an easy process you want to ensure that your systems will be able to handle the expanded data volume without having to re-architect your EDI integration solution.


Choosing the right EDI integration vendor is the fifth, and in some cases, the most critical aspect of your EDI integration planning. The choices available to mid-market companies for data integration are many, and often selecting the most appropriate vendor can be a very confusing process. As you seek a vendor, consider a number of key criteria:

Q1 How much experience in integrating EDI does the vendor have?

One of the first aspects of selecting the right vendor is to consider how much experience the vendor has in EDI integration. There are many vendors of data integration packages; however, working with EDI integration requires a specific skill set and introduces a set of challenges that are unique to EDI integration. When selecting your EDI vendor, ensure that you work with one that has been in the EDI integration business and understands the challenges involved.

Q2 What is the vendor’s primary market focus?

Everyone wants to work with the big guys right? The right answer is going to depend on the market focus of your EDI integration software vendor. Do they primarily focus on enterprise customers? If that’s their main area of focus, how much attention will you be able to get as a mid-market organization? Will you be on the top of the priority list if there are any problems? Are you going to get access to the best resources the vendor has available? Select a data integration vendor that focuses on small and mid-market companies and you are much more likely to get the kind of service that will mean the difference between success and failure for you.

Q3 Will you have access to professional services?

Even if you have in-house resources, or if you have hired consultants to do most of the EDI integration work, it’s still important to have ready access to professional services from the software vendor. The reason for this is simple: you may only rely on them for training, or you may end up needing their expertise to help you resolve a challenging part of your project. Whatever the case, if you don’t have ready access to professional services it may put your integration project in jeopardy.

Q4 Do you have access to more than one integration package?

One size fits all - it’s often one of the biggest challenges of buying EDI integration. A package designed for an enterprise class deployment at a Fortune 500 organization may be overkill for your organization. Similarly, a package designed to do basic EDI integration with small business software may not provide the type of processing power or business process management that your business needs. As you talk to possible software vendors, make sure they have products that span both ends of the spectrum in a way that allows you to start with low-end packages and migrate upwards as your needs grow over time.

Q5 Are you getting too many promises?

This last aspect is often one of the biggest challenges of finding a good vendor. It’s common practice in the EDI integration business to promise first and deal with repercussions later. Be wary of software vendors that seem to be able to deliver on all of your requirements without any concerns. Over the twelve years that DiCentral has been in the business of integration, we have seldom run across a project that didn’t force us to ask questions at the very beginning. As you select your software vendor, these are just some of the questions to consider. The most important aspect of choosing an EDI integration vendor is to ensure that it is a company with which you are comfortable doing business; you will be spending a lot of time talking to them over the coming months - make sure it’s someone with whom you can work.


At DiCentral we understand Business Intelligence, EDI, and data integration. For over twelve years, DiCentral has powered EDI integration for midmarket companies. Our professional services team has decades of combined experience and has worked in all phases of EDI integration in a multitude of industries. As a company, DiCentral can help you with all five elements of buying EDI integration - from planning your integration project to helping you select the right product from our family rich with EDI and data integration solutions. Our network of resellers and consultants can work with you to help ensure a successful integration project.

Learn more

Learn more about DiCentral by visiting our web site at and by downloading our other whitepapers on data integration and EDI. Since 2000, DiCentral has been an industry leader in supply chain and supplier performance management software and services. With over 6000 valued customers processing millions of transactions annually, DiCentral has consistently delivered quality products and services across the retail, chemical, logistics, warehousing, food, consumer goods, and pharmaceutical industries. In short, our offerings simplify the way you do business through supply chain integration. By using DiCentral solutions companies of all sizes can be provided with the tools necessary to act quickly with increased insight, efficiency, and flexibility. In addition, DiCentral solutions streamline the communications that drive commerce, manage orders and inventory, reduce costs, optimize performance, and provide the insight and agility needed to compete on a global scale.