When a buyer firm wants to send an electronic purchase order to a supplier, it must first transform data from internal computer applications used for managing inventory or production into the common language of EDI. Similarly, the supplier firm must convert the received order into data formats that its shipping and order entry applications can process. In a perfect world, all the associated internal applications would directly receive EDI formats, and conversions would not be necessary. However, even in 2002, many real-world applications require conversion into proprietary data formats in order to work. Therefore, translation is necessary for EDI data formats, and a secure communications network environment is required for EDI delivery.
To send EDI transactions between two trading partners, a special type of software called a translator or “EDI management software” is needed to convert the data into ANSI syntax. Similarly, data received from trading partners in ANSI formats must be converted to a format that an internal business computer application can process. It is not necessary that trading partners both use the same specific product or “brand” of translator, but both must have this capability for EDI to work.
When an EDI message has been formatted by EDI management software into ANSI, EDIFACT, or industry formats, it must still travel electronically to the trading partner in order to be received. Traditionally, EDI transmissions flow through closed networks called value added networks or (VANs) (See Exhibit IV. for an illustration of the EDI delivery process.). As communications alternatives have developed in the late 1990s for the use of TCP/IP (Internet) protocol and file transfer formats for Internet and direct transmission to company and proprietary networks, EDI is being increasingly transferred over non-VAN networks and Internet VANs as well.
Exhibit IV: EDI Delivery Process
VANs
A firm can use VANs to make one connection to an electronic mailbox housed at the VAN and communicate with many trading partners. VANs eliminate the need to match communication protocols, and transmission timing as required for many direct connections to trading partners.
North American VANs include many of the traditional communication providers, such as AT&T and MCI, and also IBM Global Information Services, General Electric Exchange, Sterling Software’s Commerce Net division and several others. These firms offer the special transaction and envelope processing necessary to exchange EDI. They also provide “value added” services, including the following:
·Retransmission of data;
·Conversion of EDI to internet formats, eforms, fax, paper or other electronic media;
·User groups and training sessions;
·Implementation of trading partners through enabling services; and
·Extensive customer service in resolving any communication issues.
VANs interconnect with each other through communication gateways, so that if one firm has a mailbox on an individual VAN (e.g., General Electric’s Network) and several trading partners are using Sterling Commerce Network, GE and Sterling (as well as all other VANs) will automatically interconnect with one another. VANs price their services in a variety of ways, but most include a monthly mailbox fee, transmission charges, and per-message charges depending on volume.
Direct Connections and the Internet
In the past, when two trading partners had a significant volume of EDI transactions flowing between them, they often set up a direct connection or high-speed communications line between the two firms. Often, this will occur between a production firm and its key distributor, or between a parent company and its captive subsidiary.
As an alternative to using a VAN, a few large hub firms with hundreds or even thousands of trading partners have chosen to set up internal EDI mailbox systems with sophisticated computer communications software. For instance, several large automotive OEM (original equipment manufacturers) firms give suppliers a choice between using an internal mailbox on the OEM computer or using a VAN. For communication with the OEM, the internal mailbox allows the company to keep the trading partner on-line while an initial message is received, until a turn-around response or acknowledgment is produced. Some hub firms using this approach also price transmissions at a lower rate, reducing VAN transmission costs for both the hub and the smaller firms, (called spokes). Direct connection via dial-out from the spoke’s EDI management software is used to connect to the internal mailbox at the hub.
In the late 1990s, the use of Internet communication in FTP (file transfer protocol) or TCP/IP (Internet protocol) became possible with the advent of new types of translation software. Many vendors of EDI translators today offer “secure EDI” transmission via the Internet as an alternative to sending and receiving EDI from a VAN. This software contains the same functionality as traditional translators but is able to use electronic signatures and encryption techniques to protect the EDI messages as they travel through the Internet. Additionally, small trading partners that are not EDI capable, but have access to the Internet through a browser can send and receive electronic forms which are then processes by EDI translators---either as ANSI or EDIFACT transactions, or as XML (extensible markup language) linked directly to a company’s internal applications.
The advent of Internet communication also provided traditional EDI VANs with an opportunity to set up their own Web servers, capable of converting between the familiar closed VAN environment and the open communications environment of the Internet. This Web-based EDI architecture is illustrated in Exhibit V. Many VANs offer electronic forms services over the Internet with conversion to ANSI or EDIFACT syntax occurring at the VAN Web server. A small non-EDI-capable firm will use an Internet browser to fill out the form, such as a purchase order or invoice. It then sends the form to the Web address of the VAN. The VAN converts the form to an EDI transaction set, envelopes it, and places it in the VAN mailbox (a closed communications environment) of the EDI-capable firm. For example this approach is used for large medical suppliers working with small laboratories or dental offices; a mortgage banking firm receiving mortgage applications from thousands of field agents; and a large defense contractor receiving supplier bids from small firms for a defense project.
Exhibit V. Web based EDI (One Alternative)
With increasing use of interoperable XML (extensible markup language) and other software advances in the last two years, some firms are also using linkage from their own web servers and industry internet applications to bypass conversion to traditional EDI standards. This approach will be examined in Part III of this series of papers discussing electronic commerce.
Linkage Between Banks and VANs in Financial EDI
Because a payment order must flow through the U.S. banking system before it can become “good funds” or available funds, it is impossible to exclude banks from business payment transactions for financial EDI. Firms that implement financial EDI through the invoicing process may choose to use traditional EFT or wire mechanisms, rather than financial EDI formats, for payment. However, to achieve the full benefits of EDI through the cash flow timeline, the use of EDI formats is preferred.
EDI-capable banks interconnect to VANs in the same way that VANs connect with each other. An EDI bank may receive an 820 payment order directly from a company’s treasury system (with the bank providing conversion to ANSI syntax), or an EDI bank may link to a company’s regular VAN mailbox for fully formatted ANSI payment orders and remittance advices. There are many variations of this linkage, including bank services that receive the remittance advice in ANSI syntax and match it to a simple EFT payment order in ACH format, prior to processing. Some EDI banks also provide media conversion for non-EDI capable trading partners by converting a file of ANSI-formatted 820 orders to ACH payments, wires, and even checks.
Today, EDI management software products are available for virtually any type of computer platform including personal computer (PC), server network, mainframe, midrange, and even Internet-based operating systems. Depending on the platform and the capabilities desired, a firm purchasing EDI management software may invest from several thousand dollars (for a simple PC-based product) to hundreds of thousands of dollars for a large-scale installation.
Most EDI data is processed via file transfer from a network or connection to a business application, such as an accounts receivable or inventory management system. This is the preferred method of entering and receiving EDI data into the translator software, since it promotes application integration and reduces errors from keying and rekeying data. However, some PC-based and web-based products allow business data to be keyed into the translation software from a terminal and are called stand-alone EDI installations. (Many firms start their EDI implementations in this way and later move into file transfer).
The transfer of data files directly to and from computer applications is generally the best way to implement EDI, because it eliminates errors from human interpretation and keying. (See Exhibit VI. for an illustration of the software linkage process.) In the mid 1990s, some large EDI firms such as General Motors and Ford began requiring their supplier base to demonstrate application linkage from their EDI translation software. This demonstrated capability was demanded not only from major or “first-tier” suppliers but also as a quality certification item for second-and third-tier suppliers to remain in the procurement programs for Ford and GM.
Exhibit VI: Software Linkages
Communications Capability
EDI management software allows a company to communicate with trading partners by handling the dial-out to a VAN or a direct transmission to the receiving trading partner. Many translation software packages currently available also communicate with secure features such as encryption or electronic signature to enable EDI communication over the Internet. By far the majority of firms doing EDI today, however, use EDI management software to access an electronic mailbox on a VAN.
The communications portion of the software schedules the dial-out to the network and contains specific formats for VAN access called scripts that are specific to each major VAN. In PC software packages, this dial-out capability is part of the standard product. For mainframe, UNIX, and server platforms, and other mid-range computers, communications capability may be an optional component of the EDI management software. Firms using these larger computer systems often have already installed sophisticated communications handling and messaging systems, so that communications in the translator becomes redundant.
Software vendors of EDI translation products have also recently developed enhanced communications for very large and experienced EDI users (sometimes called “Enterprise EC Systems”). These communications modules work with an EDI translator to notify managers via beeper, e-mail, or other method when an EDI exception occurs in processing. Communications to automated fax, legacy computer applications, Internet server, and an in-house mailboxing system may also be tied into the EDI management system. Normally, the expense of this capability is only justified for large corporations with high EDI volume measured in hundreds or thousands of trading partners and transactions per day.
Standards Validation
EDI management software contains multiple versions of the ASC X12 standards and often EDIFACT and/or industry conventions of the standards. Incoming data is interpreted by the validation rules contained in the software. Any errors in ANSI syntax, code usage, or data structure are noted and sent back to the trading partner in a functional acknowledgment. Transmissions received normally with no errors are also typically acknowledged to the trading partner with an EDI functional acknowledgment.
Outgoing data is generated by processing a file in business format through the standards and syntax rules to create an outbound EDI transaction in ANSI or EDIFACT format. The transaction is enveloped in ANSI with the identifiers pertaining to each specific trading partner and then sent through communications to the VAN mailbox, or via direct connection.
Trading Partner Profile Management
To send and receive EDI with a specific trading partner, each trading partner’s EDI requirements must be defined in the EDI management software. These requirements include the following:
· The standards version;
· The mailbox identifier;
· Passwords;
· Data element separators; and
· Segment delimiters.
When an EDI transaction is generated to go out to a trading partner, the software uses the specific trading partner profile data to create the specific envelope for transmission and to format the data as required by the trading partner. When an EDI transaction is interpreted, the software checks to ensure that it originated from a valid trading partner and uses the appropriate profile data (including the version of the standards) to convert the data from ANSI syntax to business format.
Some EDI management software packages also store administrative data in the profile, such as telephone and fax contact numbers and testing versus production requirements for each trading partner.
Mapping
An optional capability included in most translation software products today is the ability to map to different data formats when integrating EDI data to an internal application. Some software vendors also market EDI mappers as separate software products that may be attached to other translators or simply as application integration tools.
Mapping greatly simplifies the effort to integrate data from multiple trading partners into an application. As shown in Exhibit VII, a mapper creates an outbound or inbound directory of data structures so that EDI can be converted directly into an application format without passing through an intermediate proprietary “flat file” format, as older versions of EDI management software required. Mappers also contain logical rules for processing data so that conversions can be made between virtually any two data formats.
Often, the implementation of EDI for specific trading partners requires a unique map for each trading partner. In a perfect world, an EDI firm would use only one map for all purchase orders and a separate set of maps for transactions such as invoices and forecasts. However, actual implementation (especially with customers) often reveals subtle differences in segment and data element usage between two firms. Thus a different map from the translator is required on a trading partner per transaction basis. The mapping functionality of EDI management software accomplishes the management of these separate maps in an efficient manner and takes the place of cumbersome computer programming to create the needed linkages.
Exhibit VII. Mapping Tools
EDI has the potential to affect financial and information flows across the entire cash flow time line. Benefits include:
· Reduced transaction and banking costs (in financial EDI applications);
· Reduced delays and errors; and
· Stronger relationships with trading partners.
In fact, as discussed below, there are at least eight major areas of benefit for firms and organizations that implement EDI.
Reduced Cycle Time
EDI reduces the elapsed time that it takes for information to travel from a trading partner to a firm, and from application to application inside a firm. Studies have shown that reduction in cycle times within individual processes such as order entry, procurement, or updating of accounts receivable can be as high as 45 percent after implementing EDI (EDI Research, Inc., 1998–99). This, in turn, has an impact on inventory cost, inventory turnover, collection float (for collection of receivables), customer service perceptions, loss of discounts in procurement, and many other financial performance measures that are time dependent.
Reduced Error Rate
When paper and manual keying of data is used to move data from one application to another, and between trading partners, errors are always introduced into the process. Even the high performance rates measured by U.S. banks in keying of payment operations data still approach 1 to 2 percent of transactions, while business manufacturing quality standards increasingly demand a six-sigma (three errors in one million transactions) performance. The use of EDI greatly reduces errors from transmission and keying when it is integrated from the EDI translation software to internal computer applications, because data flows directly from the mailbox through the translator to the resulting application, such as the order entry or accounts payable system.
Labor Savings
Most firms that implement EDI in a manual function (such as accounts payable) are able to achieve significant labor reductions of as much as 50 to 75 percent over a several-year time frame. However, the implementation of EDI also tends to shift jobs from purely clerical to more technical and customer service positions. Firms that are successful in introducing EDI to a previously manual environment normally use attrition and shifting of positions to avoid a cultural resistance to EDI. In the finance function, EDI especially has an impact on accounting reconciliation functions, research and adjustments in billing, and data entry.
Reduced Storage Costs
Storage of paper documents and records can be greatly affected by conversion of archival formats to EDI and imaged messages. When EDI is used (as in evaluated receipt settlement) to eliminate whole documents and associated processing, the office space allocated to record storage is also significantly reduced. R. J. Reynolds claimed in 1996 that a “ballroom-sized” storage area was eliminated when it used EDI in accounts payable for receipt of invoices and vouchering, together with imaging systems for storage of records.
Reduced Uncertainty
In treasury management, a frequently overlooked benefit of EDI usage for payments is the greater certainty of cash flow timing . In payables, EFT and EDI payments can be “warehoused” with a fixed entry and settlement date, so that the timing of disbursement funding is known with certainty. In collections, companies may use the 820 transaction as an advance notification of the remittance advice to improve the forecasting of receivables. With improved forecasts, companies may reduce borrowing and excess balances, and the investment time horizon may be lengthened with a resulting positive impact on cash flow.
Enhanced Security
EDI transmissions in production use functional acknowledgments on receipt of data, control numbers, time and date logs (both at the translator and the network), and counts and checks built into EDI transaction sets and envelopes. These security mechanisms are requirements built into the data standards and messaging services that make EDI far superior to paper both for audit/control purposes and for privacy. The security of outbound payments may also be increased by using an EDI transmission in combination with bank products such as positive pay. Issued payments are matched to payments presented by the payee, before clearing through the banking system.
Transaction Cost Savings
In finance, the use of EDI in place of check formats cuts issuing costs of check stock, postage, bank charges, envelopes and delivery charges. When lockboxes are eliminated by EDI for collections, the savings can frequently be compounded. However, most firms implementing EDI in treasury do not convert 100 percent of their customer base to electronic formats so that savings in transaction costs are usually greater in originating payments than in receiving payments, depending on the industry and the nature of the customer base.
Trading Partner Relationships
When two firms implement EDI, they must negotiate closely on such technical matters as timing of transmission, data details, VAN addresses, and standards versions. However, the real benefits of EDI come from negotiating business matters related to EDI in a “win-win” environment. You can strengthen trading partner relationships in the implementation process by including discussion of price and trade term discounts, incentives for demonstrated integration to applications, sharing of price and product catalogue data, and the use of EDI capability in supplier rating and quality programs. Firms that are successful users of EDI realize that EDI benefits are actually 20 percent technical and 80 percent business-related.
