E-COMMERCE

LESSON 10: ELECTRONIC DATA INTERCHANGE

Topic:
Introduction EDI Implementation Summary Exercise

the trading partner may supply the software or recommend a third party supplier.
The VADS supplier. As part of application package, e.g. packaged software for

Objectives
After this lecture the students will be able to:
Understand details of the technical elements of an EDI

production control, order processing or accounting may include EDI software as an integral feature or as an optional module.
A third party. An example of this is that a number of banks

system:
EDI Implementation

Now we will discuss the physical implementation of VADS. EDI in the Internet. Recently a number of organisations have started using the Internet as an EDI VADS. Using the Internet provides the basic store and forward facilities but not necessarily the other features of a VADS service that are listed above. Security and reliability are two of the major concerns, unlike the traditional VADS, the Internet does not guarantee the safe delivery of any data you send into it. The plus side of using the Internet is that it is cheaper than any of the commercial networks that provide specific EDI VADS services.

provide EDI solutions that include the collection of and accounting for electronic payments. Obtaining EDI software from an interested party has both advantages and disadvantages. If the software is, for example, bought from the VADS supplier then, hopefully, there would not be any problem interfacing with the chosen network but using an additional VADS or switching to a new network supplier may be more problematic. The basic functions of the EDI Software are the two already outlined, namely: Coding business transactions into the chosen EDI Standard;

Interfacing with the VADS.

EDI Implementation
The final technical element of the EDI system is the EDI software. If a company is to send an order from its production control system to Packaging Solutions it needs to code that order into the agreed EDI standard and squirt it into the chosen VADS. To pick up the order at the other end, Packaging Solutions has a similar need to extract the data from the network and to decode the data from the EDI message into its order processing system. The coding / decoding of the EDI message and the interfacing with the VADS is normally achieved using EDI Software. The overall picture is summarized in Figure 10.1.

Many EDI software suppliers provide additional functions.These may include:

A trading partner database integrated into the EDI

Software.This can provide for code translation (e.g. internal customer codes to a trade sector standard code) and / or for the specification of the EDI requirements of each trading partner;
Support of multiple EDI Standards. The selection of the

appropriate standard may be determined by the trading partner database;

Sophisticated facilities to ease the formatting of internal

application data to and from the EDI Standard. Drag and drop interfaces are available for this purpose. Various EDI Software suppliers have associations with the large suppliers of business applications (production planning, order processing, etc.) and provide standardised interfaces to those packages;
Facilities for transactions to be sent by fax or e-Mail to

customers that do not use EDI. The identification of such customers may be determined by the trading partner database;
Interfacing with a variety of EDI VADS (including the

Fig. 10.1 Sending an order using EDI Software. EDI Software The EDI software is normally bought in from a specialist supplier. There are a number of software houses supplying EDI solutions or the EDI software may come from: A major trading partner -

Internet). The selection of the appropriate VADS may be determined by a trading partner database;
The option to encrypt the EDI Message; Facilities for the automatic acknowledgement of the EDI

message;

44

Copy Right: Rai University

3.231/3A.231/3B.231

 Message tracking and an audit trail of messages sent and

received;
Direct input and printed output of EDI transactions

The order print run is modified so that orders for EDI capable suppliers are not printed; EDI capable suppliers and format the data onto the flat file;

E-COMMERCE

An additional run is included to take the orders from the The flat file is accessed by the EDI software and, using user

allowing free standing EDI Operation-in effect the EDI system provides the service of a fax machine. EDI Software is available on a variety of platforms from the basic PC up to a mainframe system. As with all classes of software the price varies: the basic PC packages starting at (say) 500 pounds sterling / 800 US dollars and the price then goes up from there for the larger machines, additional facilities and services such as consultancy. For some EDI software the support of each standard and / or VADS is an additional plugin that is paid for separately. Yearly maintenance charges, that include updates as the new versions of the EDI Standards are released, tend to be quite hefty. At the top of the range is the concept of an EDI Corporate Interface. This software, often mounted on its own, mid range, machine acts as a central clearing house for all the e-Commerce transactions of a large organisation. The external interfaces can link to several EDI VADSs and translate to a variety of EDI Standards to meet the needs of a large number of trading partners. The internal interfaces can link to a number of business systems such as order processing and accounts payable,possibly systems that are replicated across the various divisions of the organisation. The system can also be used for intra organizational transactions - if the interface for external customers and suppliers uses EDI, why not use the same interfaces for trades between divisions of the organisation.

supplied parameters, the order data is formatted into the required EDI standard and posted into the VADS. The reverse process is used for incoming EDI messages. This will involve the creation of a batch input routine to run in parallel with the online facilities utilized by most business applications. The additional worry with incoming EDI messages is validation. For orders, invoices and any other data manually input into a business application there will be (or should be) comprehensive primary and secondary validation built into the system and there is a human operator there to deal with any queries. For EDI messages there will not be any input errors at the receiving end but there is(normally) no guarantee that the data sent by the trading partner is correct or acceptable. Arguably the EDI routines taking input messages need all the same validation checks as the equivalent manual input routines and there needs to be procedures for correcting the problems or informing the trading partner and getting them to transmit a corrected message. EDI Operation Once the EDI system is set-up it, like any other data processing systems, needs careful and systematic operation. A big difference between electronic transactions and their paper equivalents is that with electronic transactions there is no paperwork to fall back on should anything go wrong. In these circumstances, therefore, it is sensible to keep a security copy of all incoming transactions preferably in their EDI format as soon as they enter the system. This then gives a fall-back position should any data be lost or corrupted and is an aid to the diagnosis of any problems. The second aspect to EDI operation is how often should the system be run. EDI has been implemented, in part at least, to cut down transaction cycle time and there is no point in reintroducing unnecessary delays. For many organisations a daily download from the mailbox and processing run is sufficient - however, this is not entirely satisfactory if the daily run is timed for an hour before a major trading partner sends out their daily orders. In some circumstances, such as just-in-time manufacture in the vehicle assembly business, cycle times can be as short as one hour and obviously order processing needs to be very frequent / real-time. Sample EDI Application WebLogic Integration provides an EDI sample application that demonstrates how WebLogic Integration with the EDI Connect for WebLogic Integration add-on can be used to exchange EDI purchase-order information over a VAN. In the sample application, a supplier trading partner uses the EDI integration functionality of WebLogic Integration to connect to a buyer over a VAN. The interactions between the buyer and supplier occur in the following sequence: 1. A buyer trading partner submits an EDI purchase order, over a VAN to the supplier.

EDI Integration
EDI software will do its job well at a relatively modest price. What pre-packaged EDI software cannot do is automatically integrate with the business application and a comprehensive solution to this requirement can take a lot of time and cost a lot of money. The simple way to implement EDI is not to link the EDI software and the applications - a set-up sometimes referred to as EDI-Fax or EDInterruptus. This is, a course, followed by many organisations when they first start and persisted with by many small organisations who are only doing EDI because a large trading partner has told them to. In this mode of operation: Incoming EDI messages are printed out from the EDI software and then manually keyed into the business application that they are intended for;
Outgoing EDI messages are extracted from the business

application and typed into the EDI software for formatting and onward transmission. The use of EDI in this way ensures that the transactions get through quickly (hence the term EDI-Fax) but it rules out any of the other advantages of using EDI. For full integration of the business application and the EDI Software there needs to be an interface to transfer data from the business application to the EDI software and vis a versa. To ease this process, most EDI software provides for a flat file interface. If the data to be sent is (say) an order then the business application can be modified so that:
The supplier record in the order processing system has an

indicator to say that its orders are to be sent via EDI;

3.231/3A.231/3B.231

Copy Right: Rai University

45

2. The EDI-to-XML transformation engine bundled with Power.Server! converts the purchase order to XML. 3. The XML document triggers a business process in the supplier application. The business process generates an XML purchase order acknowledgment. 4. The supplier forwards the acknowledgment to the transformation engine which converts it to EDI, and then forwards it over a VAN to the buyer.

E-COMMERCE

Summary:
A number of organisations have started using the Internet

as an EDI VADS

Unlike the traditional VADS, the Internet does not guarantee the safe delivery of any data you send into it The plus side of using the Internet is that it is cheaper than any of the commercial networks that provide specific EDI VADS services. The coding / decoding of the EDI message and the interfacing with the VADS is normally achieved using EDI Software For full integration of the business application and the EDI Software there needs to be an interface to transfer data from the business application to the EDI software and vis a versa.

A big difference between electronic transactions and their paper equivalents is that with electronic transactions there is no paperwork to fall back on should anything go wrong. In these circumstances, therefore, it is sensible to keep a security copy of all incoming transactions

Exercise:
1. How do you achieve coding\decoding EDI messages in VADS? 2. How secure is the EDI VADS in delivery of the data Notes

46

Copy Right: Rai University

3.231/3A.231/3B.231