Navigation:  Articles > May-1998 >

Electronic Commerce, Part 1

Previous pageReturn to chapter overviewNext page

David Irvine  
 
Electronic commerce didn't appear with the Internet. Companies have been exchanging purchase orders, bills, and other documents using Electronic Document Interchange (EDI) for years. Here's what you should know and how Access fits in, from the former chairman of one of Canada's EDI advisory boards. Part 2 will go into the programming that will make all this work.
 
You've heard the buzz from your customers. You've got the feedback from your vendors. EDI. Electronic Commerce. The technology for the next millennium! So what do you do? Where do you start? Many companies today are faced with the challenge of implementing Electronic Commerce (EC) solutions in order to stay competitive.
 
Access can play an important part in this process. EDI is fundamentally about exchanging data between different companies. In this article, I'll help you understand EDI and describe the data structures that you need to support an EDI application (I've included those tables in the sample database EDI.MDB, available in the accompanying Download file). Next month, I'll get down to the nitty-gritty and look at some of the application support that Access can provide to your EDI initiative.
 
By the way, if you're wondering whether the Internet will have an impact on EDI, the answer is yes. But, more than likely, the effect is going to be a tremendous explosion in EDI. Until now, one of the major difficulties in implementing EDI between two companies has been getting both partners on the same network. With the advent of the Internet, every company is, potentially, on the same network with every other company.
 
Most companies that have implemented EDI/EC solutions have had at least one false start. As I'll discuss in this article, it's not technology that's the problem. Before you can start coding, there are a bunch of business issues that you have to address. To keep this part of the discussion short (and because I like them), I'm going to provide you with a set of checklists for "EDI readiness." If you don't have the answers to these questions, close up your Access database and wait until you do. Working through these checklists will also give you the understanding you need of what EDI is.
 
How ready are you?
The first thing to consider when examining an EC project is your own readiness. Trying to develop an EC strategy while in the middle of a hardware platform or core system change is a recipe for disaster. As a result, many companies are forced by major customers to respond to a request for EDI or EC by selecting a stop-gap measure that doesn't oblige them to install new hardware.
 
One example is to install a dedicated PC with an EDI translation package. This PC will accept EDI messages, automatically send a response to the customer, and print out the transaction. This printed transaction can then be keyed into the primary business system, making the whole arrangement the world's most expensive fax machine.
 
However, this keeps the customer who's demanding EDI happy for the moment, though it provides none of the benefits of an integrated EDI/EC strategy. An integrated EDI solution greatly reduces errors in transactions and speeds response time. Those targets (and the consequent cost reductions) won't be met with this solution. Access can be useful here as middleware. Using Access's ability to work with multiple databases will allow you to pull data from the standalone EDI computer's database and integrate it into your existing systems (more on this in Part 2, next issue).
 
So, are you ready for EDI? The following questions need to be asked to take stock of your readiness for EC:

How stable is your primary platform and application?
How stable is your data? Is your data, such as part numbers, standard? Can you provide vendor part numbers? UPC codes? Can you accept customers' part numbers?
How are you going to integrate external data into your core applications?
Do you have the staff resources to drive and maintain the project?
Do you have senior management commitment and resources to undertake a project of this scope? (This is a crucial item.)

 
How ready are your trading partners?
You've heard the old joke -- what if they gave a war and nobody came? Well, there's a parallel here with EDI. Suppose you go ahead and implement a full EDI system, then you find that you have no one to communicate with. Some industries, particularly the automotive and grocery industries, have a robust and tested EC infrastructure. In other industries, such as hardlines manufacturing and distribution, EC is in its infancy. Before making a massive commitment to EDI or EC, you need to conduct a survey of your customers and vendors to determine their readiness to partner in an EDI/EC relationship. Make sure to concentrate on the following:

Are your partners doing true EDI, or are they using EDI as a large and expensive fax machine? (This is sometimes referred to as "Tear and key EDI.")
Are your trading partners capable of processing your part numbers? Can they handle UPC codes?
Do your partners have e-mail or a Web presence? Companies that don't probably don't have the technological savvy to embark on an EC partnership.
What documents are your trading partners capable of accepting? EDI defines a series of standard business documents, and not all companies accept or send all of them.
What standards are your trading partners using? What version of EDI? EDI hasn't stood still over the years.
Are your trading partners' systems year 2000 compliant? Failure to ensure this could cause a major failure in your business, not to mention your trading partners' businesses.

 
Where do you start?
Many companies embark on an EC strategy with vigor and gusto, only to fail miserably. After lack of readiness, the number-two reason is lack of planning. Without a good, sound business and implementation plan, even the most conservative of EC projects is doomed to fail, or at least not to meet the expectations of your internal or external customers. The key points to remember here are:

Have a dedicated EDI Coordinator. EDI has a fair amount of administrative work involved, from keeping track of your trading partners to handling any problems that might arise from the day-to-day transactions. Having a dedicated staff member assigned to the task of driving and coordinating the EDI effort is key. Remember, this isn't necessarily an IS function. The EDI Coordinator is half technology, half salesperson.
Target the most bang for the buck. It's one thing to be able to say that you're EDI compliant; it's another to reap benefits from being truly EDI compliant. The ability to take, for example, purchase orders or invoices into your system eliminates the need for your staff to key them. This saves in labor and should reduce errors, since the majority of errors introduced into any business flow happen in manual keying.
Deal with an outbound document first. It's easier to export data from your system than it is to import, since exported data doesn't require as much editing or verification. If you're new to EDI, get your feet wet by implementing an outbound transaction, such as a purchase order to your vendors.
Choose your first trading partner carefully. Starting up EDI, like starting any new technology initiative, is a learning experience, and it can be fraught with problems. Choosing a business partner that you're on excellent terms with -- and that understands the situation and is willing to work with you -- is an important step. You don't want to deal with the exasperation of an unsatisfied customer as well as the trials of initiating a new technology.
Select your EDI software and value added network (VAN) carefully. The key to a successful EDI program is the ability to quickly and easily expand your number of trading partners and your number of documents. To assist in this, it's vital that your EDI translation software is solid, reliable, and easy to use. There are many excellent packages on the market, and some very poor ones as well. These considerations are key in the selection of your software:
--- Does the software handle both X12 (North American) and UN/Edifact (International) standards?
--- Does the software allow for "drag and drop" mapping of your information to an EDI document?
--- What is the user base of the software? Get references and talk to companies that are using the software to see what their experiences have been.
Also important is the selection of a VAN. The VAN provides "mailbox" services, allowing you to drop off and pick up documents to be exchanged by your partners. There are many experienced companies providing VAN services, such as IBM, Sterling Commerce, GE Information Services, and Harbinger, to name a few. Things to consider when selecting a VAN include:
--- How long has the company been in the VAN business?
--- What type of support do they provide?
--- What type of training do they provide?
--- What kinds of services are available to assist you in establishing and expanding your EDI program?
--- What VANs are your trading partners using? There can be advantages in using the same VAN that the majority of your target trading partners are using.

 
One further consideration is using software and VAN services provided by the same company. This isn't essential, but it makes sense, since it generally means one support number to call in the event of a problem. Most VANs also supply EDI translation software.
 
The purchase order -- a fine place to start
That's probably enough scene setting to give you an understanding of what needs to be done before you start coding. Now I'm going to take a look at an example of implementing an EDI transaction from an Access application. One of the favorite starting places for a company embarking on EDI is the purchase order. In EDI parlance, a purchase is referred to as an 850 (using the ASC X12 standard). Figure 1 shows the standard flow for an 850 transaction.

199805_di1 Figure 1
 
You first step is to define some of the basic information required for the purchase order. As a minimum, the PO must contain:

A purchase order number. This is a unique number identifying the PO. It will be used for reference by both parties.
A purchase order date. This is the date a PO was generated.
Ship-to information. This is the name and address of the company that the product will be shipped to. It might be necessary to export the entire name and address, or you can have your trading partners cross-reference this information. In this case, rather than exporting the whole name and address from your database, you simply export some unique code that your partner can use to extract the name and address information from their system.
Bill-to information. This is the name and address of the location the invoice is to be sent to. Like the ship-to information, this can be exported in full from your database, or it can be cross-referenced by your trading partner.
Shipping instructions. These are any special instructions on how the product is to be delivered.
Buyer. This is the information on who the purchaser's contact is. It will be used by the supplier to determine a contact if there are any questions regarding the purchase order. This information generally consists of the buyer's name and phone number.
Requested date. This is the date the product(s) are expected to be delivered. This date can be an exact date, meaning that the product is to be delivered not before or not after the date, or it can be an end date for delivery, meaning that the product can be delivered earlier, but must not be delivered any later, than that date. The ASC X12 standard provides several coding options to identify a requested date. Also, requested dates can be at the entire order level, or they can be at the line-item level, allowing for multiple delivery dates for a single purchase order.
The items requested. There are many ways to identify the requested items, and it must be agreed with your trading partner how they're to be handled. Remember, the point of an EDI document is to eliminate manual handling of a document, so you want this to be able to flow into your trading partner's system. Common identifiers are your part number, the vendor's part number, or the UPC code. It's also advisable to send the description. In the event that your trading partner's system can't identify the products requested by the codes supplied, the description allows the partner to print or view the document and (hopefully) identify the product by description.
The item price. This isn't vital, but most vendor/customer relationships have set pricing for products. You might have a special contract with your supplier that guarantees you preferred pricing. By sending the price you expect to pay, you have a legal stand should your partner make a mistake in billing.
The unit of measure. This is a good idea, since you don't want to order one dozen widgets and receive one dozen cases of widgets.
A summary line. This is generally just a count of the number of detail lines in the Purchase Order. It's used by the receiving party to ensure that the document they picked up is complete.

 
This is simply a summary of some of the basic information required in a purchase order, and by no means is it intended to be a complete list.
 
Once you have your application capable of creating the desired EDI document, it's necessary to extract, translate, envelope, and send your document to your trading partner. To do this, you need to:

Develop a VB or VBA application to extract the necessary data to a flat file. The example database includes a sample query called "Purchase Order," which lists the necessary information.
Export a flat file, in a standard, pre-defined format. Your EDI Translation software will need to be able to recognize the file format and layout in order to translate the purchase order into an 850 document. This is a function of the EDI software.

 
Once translated, the document is enveloped, which is to say that it's identified and addressed to the correct trading partner. Your EDI software will then export it to a formatted EDI transaction. This is the standard document that will be sent to your trading partner.
 
Your EDI software will then immediately -- or at a specified time, depending on how the software is configured -- transmit the document to your VAN. Once the VAN receives it, it will determine where to forward the document, and it will deposit it to your trading partner's mailbox. Your trading partner will, at pre-determined times, check its mailbox for new documents. It will receive your document, translate it to a flat file, and import that file into its order entry application.
 
Okay, so how do I know it worked?
One of the great advantages to EDI is the ability to verify that your document got through to your trading partner. It's an interesting phenomenon that most people trust printed documents far more than electronic media. This is due in part to the "touchy, feely" comfort provided by printed documents. A report can be read, held, written on, filed, and shredded. An electronic document exists only on a computer screen and has no tangible value.
 
Interestingly enough, studies have indicated that one percent of all paper documents never make it to their destinations. These are the documents that are lost in the mail, fall down behind the filing cabinet, or are sent to the fax machine with no paper in it. One of the distinct advantages to EDI is the ability for your trading partners to respond with a confirmation of receipt of a document. This is referred to as the 997 Functional Acknowledgement in the X12 standard and is an acknowledgement that an EDI document of a certain type, like an 850 purchase order, has been received and translated by the receiver's EDI software. It's necessary to remember that the Functional Acknowledgement doesn't mean the receiver has the items in stock, or that it can process the information in a timely manner. The Functional Acknowledgement simply means that the receiver has been able to receive and translate the document. This acknowledgement of receipt is usually sent immediately upon receipt, but it's up to the trading partners to agree on the time frame for acknowledgement. The standard is 24-48 hours.
 
Looking ahead
That's the basics for an EDI transaction in an EDI-ready environment. Next month, I'm going to look at the forms and the code that you'll need to manage these transactions, including getting the order out the door and flagging the orders for which you've received acknowledgements.
 
Read about the download EDI.ZIP on this page