Customer Service Bulletin

Transcription

1 Delivering Competitive Edge Customer Service Bulletin What is Electronic Data Interchange? Publication No A December st Edition

2 1st Edition, December 2000 It is the policy of BCT Software Solutions Ltd, and its subsidiaries, to improve products as new technology, components, software and firmware become available. BCT Software Solutions Ltd, and its subsidiaries, therefore, reserve the right to change specifications without prior notice. All software products are licenced to users under the terms of the BCT Software Solutions Ltd Program Products Licence. All features, functions, and operations described herein may not be marketed by BCT Software Solutions Ltd, and its subsidiaries, in all parts of the world. Therefore, before using this document, consult your system supplier for information that is applicable and current. Copyright Notice This document contains information which is proprietary to BCT Software Solutions Ltd, and its subsidiaries. Reproduction of this document for any purpose is prohibited without the prior express written authorisation of BCT Software Solutions Ltd. Disclaimer BCT Software Solutions Ltd, and its subsidiaries, makes no representation and no expressed or implied warranty of any kind with the regard to the documentation for any particular purpose. Whilst every effort has been made to ensure the accuracy of the documentation BCT Software Solutions Ltd, and its subsidiaries, accept no liability for any losses or consequential damages arising directly or indirectly from the use of the documentation. BCT Software Solutions Ltd, and its subsidiaries, reserve the right to amend this documentation without obligation to notify any person or organisation of any such amendments BCT SOFTWARE SOLUTIONS LTD

3 ELECTRONIC DATA INTERCHANGE (EDI) Introduction offers significant benefits to organisations involved in the production of large volumes of paper from their computer systems, of which data contained therein will eventually be input into another computer system. This process is wasteful in the extreme, when one considers the technology available which allows this process to be accomplished ÔelectronicallyÕ. Such organisations are now making demands upon their external business relationships to exchange data electronically, hence the term Electronic Data Interchange, or to use the acronym, EDI. A major UK organisation receives in excess of 50,000 invoices from suppliers each week, the data contained in which needs to be entered into its computer system for purchase ledger processing. When 70%* or more of these documents have already been produced on the suppliersõ computer system, clearly electronic transfer of this data to the customer machine achieves considerable labour savings. At the same time, it is also clear that pre-printed stationery, envelopes, postage and paper handling, all cost money and may be eliminated or at least partially eliminated if a more modern approach to the exchange of data is employed. This Customer Service Bulletin attempts to take the mystery out of EDI and explain some of the important issues to be considered by organisations and businesses who wish to become EDI capable. * KPMG conducted a survey of businesses which showed that 70% of all business forms used as the basis for the entry of data into a computer system had themselves already been produced by other computer systems. EDI usage continues to grow, driven by major organisations, that stand to gain as much as 40% in cycle-time improvements, 30% error reduction 3.50 per document cost savings. (Journal of Electronic Commerce, Vol 11, No.2, 1998) A 1

4 WHAT IS EDI? EDI is the exchange of ÔdocumentsÕ conforming to a specialised format such that the data contained therein may be processed directly on another computer system, eliminating the necessity to re-enter such data involving manual intervention. Today there are many different types of business documents originating on one computer system where the data contained therein is the basis of input to another computer system. Documents are no longer sales and purchase orders, acknowledgments, invoices etc, but also include, for example, patient treatment forms. In the case of the NHS, it has created an EDI document format to replace the Patient Treatment Form which dentists completed and sent, by post, to the Dental Payment Board (DPB), following each course of treatment they administered, in order that the dentist might be paid. The DPB would then key the data from each of these forms into its computer system, validate and eventually process the data producing the payment for the dentist. Now, the DPB is able to process EDI data, sent electronically by the dentist directly to the DPBs computer system via the network service provider thereby eliminating the manual data entry process. When you consider the DPB has to process over 40 million forms each year you are able to understand why it is that EDI is such an important aspect of their operation. Clearly there are many other examples that might be quoted where the use of EDI has made a significant contribution to streamlining data handling, where the data was previously re-entered from a paper form and thus the consequential cost reduction to organisations employing EDI. EDI however, is not . The difference between EDI and is that involves documents which are designed to be physically read by a person, whether that be on a piece of paper or on a computer screen. Whereas EDI involves documents which are intended to be ÔreadÕ by a computer system and processed automatically A 2

5 DATA INTERCHANGE EDI need not be the interchange of data across a telephone line from one computer system to another. It is the data which must be in an electronic format in order that it may be processed by the computer system. Once data is in the prescribed electronic format it may then be transferred by, for example, magnet media: on flex disc or magnetic tape. This is not an unusual mechanism through which EDI documents are delivered. If there are many thousands of documents to be ÔtransferredÕ it may be more cost effective to dump them to flex disc or magnetic tape and use a secure postal service for the disc or tape delivery, rather than spend many hours using modems and PSTN telephone lines as the transport mechanism. Most often, however, the interchange of EDI data is electronic and, in the UK at least, it involves using an EDI Network. There are several main EDI Networks (see next section) which operate a similar service, albeit at quite different costs. The basis of these services is that the sender of data sends everything it has for all its intended recipients, down a telephone line, to the EDI service. The service (operator) reads the electronic envelope surrounding each packet of data and deposits it into each recipientõs ÔmailboxÕ. Periodically, recipients log into the service, via their telephone line, and collect anything in their mailbox. The frequency of sending and collecting data varies according to the nature of the transactions involved. If the transactions are orders for an automotive production line they might be sent at hourly intervals (or more frequently) and would need to be collected at the same rate. In other situations transactions could be weekly or monthly. NOTE You will now realise that EDI is not a real-time operation and the parties computer systems never directly connect to each other. You have to initiate the collection of data or documents addressed to you; it doesnõt get delivered A 3

6 EDI NETWORKS The role of EDI Networks is to provide a Ôpostal sorting office mailbox serviceõ so that senders can send all their data into one place and recipients can choose their own time of collection. You will need to purchase third party software from suppliers such as IBM or GEIS, in order to achieve a connection and data link to the Network of your choice. Some examples of EDI Network Service Operators in the UK are:- Operator AT&T GEIS (General Electric Information Services) IBM EDI SERVICES Network Name IP EDI Tradanet Services Interchange Services for e-business Until recently it was not unusual for companies to be forced into using more than one EDI Network because different major customers would be on different services and would be inflexible. You had to join the one they used. Thankfully this is becoming less of an issue because all the EDI Networks can pass data to any other service for it to be delivered. The networks all have their own pricing policy which is available upon request from each network. Some networks may exercise a joining fee coupled with an annual fee, whereas some may operate on a minimum monthly charge, dependent upon data volume A 4

7 THE INTERNET The Internet seems to be the business topic of 2000/1 and it certainly will have an impact on EDI. This is not the forum to go into detail about the Internet, other than to say that one of the major uses of this ÔglobalÕ facility will be sending/receiving of electronic documents. The only limitation to this happening will be the Ôother partyõ to an EDI transaction. If your major customers use an EDI Network and you want to use the Internet then: EITHER your major customers will have to provide an Internet ÔaddressÕ which can be used for EDI; or OR the present EDI Networks provide a ÔgatewayÕ onto the Internet. Both of the above requirements are likely possibilities now, more than they would have been a year ago. There is now far more acceptance of the fact that the method of interchanging data is much less important than getting organisations to handle EDI data. This is why there is now the ability to send data via one EDI Network to recipients on any other EDI Network. With the publicity of the Internet, and the increase in general awareness of the ability to send data around the world, it will not be long before all EDI Networks have become more ÔopenÕ. The EDI ÔenvelopeÕ however, will not change. The transportation mechanism will and the internet is just a form of transportation mechanism A 5

8 DATA FORMATS EDI data is intended for ÔconsumptionÕ by computers. Computer programmes require data in a consistent, precise and unambiguous format in order that such data may be processed automatically. EDI data may relate to any document generated by a computer which is to be used as input to another computer or computers. It is therefore necessary to pre-agree the format of this data and pre-agree its syntax. The format relates to the way in which the presented data is structured and the syntax relates to the way in which the different pieces of data are separated one from another. Without wishing to over complicate the subject of data presentation, let us take a real world example. A sales order will contain various types of data. ÔHeaderÕ information, provides details of the sender, the date, the sales order number, where delivery of the products ordered are to be delivered, where the invoice for the products ordered is to be sent, etc.. There will be certain ÔdetailÕ information. This information, in our real world example, would be the order line detail, including product code, quantity ordered, product description, unit of measure, price per unit, etc.. We may then have other information such as delivery date required or even a schedule of delivery dates required. We may have ordered 1000 widgets, of which 200 are to be delivered on a specific date, 300 on another date and the balance by another date. Finally, there may be some ÔtrailerÕ information in our real world example, where the total number of order lines is shown along with the total order value plus exceptional information such as Ôdeliveries not accepted after 4pmÕ. The above is not intended as an exhaustive definition of an order data content, but is given as a real world example to make the point to the reader of the considerable complexity level which is built up in the data contained in such a document. The intention of EDI is that the computer should produce such documents or an EDI message and that another computer should be capable of ÔreadingÕ such an EDI message, without intervention of human assistance. Computers are completely hopeless at accomplishing anything unless they are specifically programmed to do so, but having done so will perform the same task consistently and with great speed A 6

9 EDI data formats have to be programmed for both the sending end of the process and receiving end of the process. In other words the output and input translation process. This is where standards come in. Some group of people must specify what data will constitute an EDI message (that is what data items will be in the header, the detail and the trailer) and how will the pieces of data be separated from each other. If any data is considered to be mandatory this must be covered as part of the specification, as must any data which can be considered to be optional. If data has to be in a particular format, e.g. a date, a numeric field, a whole number or a decimal quantity (how many decimals?) etc., this must also be covered in the specification. In an ideal world there would only be one standard and one body specifying the messages. In the real world there are three main standards (in the UK) and any number of bodies doing the specifying. The standards are:- Tradacoms - used mainly in retail areas (and other business communities which adopted EDI in the early stages of its development, i.e. pre 1988). Odette Edifact - used mainly in the automotive and related industries. - developed as the unifying standard under the auspices of the United Nations and used by most communities adopting EDI since (Early users of EDI are expected to switch to Edifact messages at some stage.) The specifying bodies tend to relate to business sectors and they concentrate on developing EDI messages to replace documents in their sector. Some (by no means all) of the bodies involved are:- ANA SMMT EDIFICE CEFIC EDIPAP PIE SBAC EDICON EDIA - retail and related supply chain sectors (which are very varied). - automotive and related supply chain sectors. - electronic industry - chemical industry - paper industry - printing industry - aerospace industry - construction industry - shipping, transport, banking, petroleum sectors A 7

10 In addition, EDI messages are subject to revision so you can encounter more than one version of the same message from the same issuing body being used. Some organisations prefer to stay with an ÔoldÕ version of a message even when a new version is released. You should also be aware of and appreciate certain other indisputable points. One is that you canõt choose which EDI standard you are going to adopt and which issuing authority you are going to use. You will tend to be told by your trading partners (customers or suppliers) if they are the commercially more dominant organisation. Inevitably this means you have to be prepared to accommodate any message, any standard, any issuing authority and any version. The other point is that EDI Networks (and other methods of interchange) are able to handle any form of EDI message. They are only interested in the electronic ÔenvelopeÕ which surrounds EDI data. What is inside the envelope is not of interest to them. Therefore so long as the envelope is properly formatted and contains an appropriate recipient ID it will get processed. One final point is that unless a document has had an EDI message format specified for it you cannot send/receive it using EDI. There have been over 500 documents converted into EDI messages across many different sectors not all of which are trading documents, e.g. Health Service forms/information, Customs & Excise forms, insurance documents, etc. New messages are currently in progress across various sectors. In time, all documents produced by computers and used as input for other computers, will have had EDI messages specified for them A 8

11 EDI SOFTWARE The previous section dealt with EDI standards, message types, issuing bodies and version numbers in order that you should be aware of some of the complexities of EDI. EDI products can only deal with data formats and interchanges, but end users of EDI data are not interested in these issues. They want application solutions capable of generating EDI data and/or process EDI data received; in addition to doing the things that they already do e.g. sales order processing, purchasing, accounting, etc. To accomplish EDI effectively you should be guided by your application software solution provider. There are dozens of so-called EDI packages on sale. All of them should be able to handle different EDI standards, different messages, different authorising bodies, different versions etc.. However, none of them can make an order process through your order entry application or extract an EDI invoice out of your invoicing application. Unless your software solution provider specifies an EDI package, which it recommends, both your organisation and your trading partners are going to have a problem! The problem is that although there are standards for EDI data formats there are no standards for the format of data prior to being put into EDI format or after it has been translated from EDI format. The next section deals more fully with the application software. The final point here is that you should be extremely circumspect when told that you must purchase a particular EDI package in order to trade with a particular organisation. If this were the case then you can forget EDI. Can you envisage having to purchase a unique product in order to trade with each customer and/or each supplier? This would completely defeat the point of EDI. There is no logical reason why, if you are an end user, you shouldnõt purchase one EDI product to meet all your EDI requirements A 9

12 APPLICATIONS SOFTWARE The previous section stated that EDI is a function of the application software solution. You might want your Order Processing application capable of processing EDI orders. You might also be required to generate EDI order acknowledgements and also EDI delivery notifications. In future you will require your Purchase Ledger application capable of receiving and processing EDI invoices and even make EDI payments. If you wish to envisage the extent of the impact of EDI on your organisation, analyse all the documents which your computer application software solution generates and consider how many of these will be used as a basis for keying data into another computer application. All those documents may be replaced by EDI messages over time. This is an important issue to be considered in that it will become either a competitive advantage if implemented, or disadvantage if not, for businesses in the future. Also, consider all the types of document your organisation currently receives which are then used as input documents to your application software solution. All those documents too, may be replaced by EDI messages. For the time being it is not possible for any organisation to say that they have completed EDI, EDI is still evolving. All that one can say is you have completed EDI for certain message types for certain trading partners (customers or suppliers). From an applications developers standpoint it is important to make a decision on how to accommodate EDI. Each application may be affected over time. Also, changes are likely to have to be made for different trading partners. As has already been stated there are dozens of EDI products which can put data into an EDI format or translate it from an EDI format. Your applications developer will choose the EDI product which most easily interfaces with your proprietary system. New EDI messages are coming along all the time and organisations using EDI are moving on to more and more documents. If end users have been forced into buying an EDI product already, it is probably cheaper if they switch to the one supported by their software A 10

13 solution provider. If they donõt they will keep paying more and more for customising and they will become more and more of a problem to the software provider. ItÕs a no win situation. Unfortunately, not enough software developers have realised the significance of EDI or the ramifications as far as their product is concerned A 11

14 GETTING STARTED Nobody gets into EDI in a hurry. There is a fairly well developed route to becoming EDI capable and it takes weeks (even months) rather than days. This section addresses the steps for an end user, i.e. an organisation which needs to be EDI capable in order to trade with another organisation. The most frequently encountered scenario is that a major organisation tells its suppliers they have to become EDI capable or risk losing its business. The major organisation will have an EDI strategy and it will have decided which EDI messages it will be using and which standard. It will also have decided which EDI Network it will be using. With its EDI Network, the large organisation will usually have produced a document explaining the reasons for adopting EDI and why it wants itsõ suppliers to do the same. In defining their EDI policy, important points may consist of:- Messages Used EDI data format standards & versions Data fields to be used Specific codifications used in message fields such as: Location Codes, Statuses, etc. The most typical approach to EDI is that the major organisation proposes to send EDI orders to its suppliers. In some instances (depending on industry sector) the supplier is required to send back EDI acknowledgements (usually after a period of grace, e.g. one or two months after being capable of receiving EDI orders). After a certain period (which can vary from a month to a year) of receiving orders a supplier will be asked to start sending EDI invoices. This is tending to happen sooner now, than it used to, as major companies are becoming able to receive EDI invoices. The main point to keep in mind is that you will be approached formally to accept EDI. There will be some form of booklet which tells you what you are expected to do and there will, more often than not, be a A 12

15 suggestion that you should join a particular EDI Network. There might also be an indication that you should buy a particular EDI product. The booklet you receive might also indicate that your organisation will be required to sign an EDI agreement. The reason for this is that electronic data is not automatically permissible evidence in a Court of Law. However, if two parties to a contract can show that they had entered into an agreement to use EDI electronic data, then it can become permissible evidence in the event of disputes. If there isnõt a draft agreement or an indication that an agreement will be supplied it is worth you querying the point. (Usually the larger party will be able to send a specimen agreement). At this stage it is important to involve your application software solution provider. They may advise on the most appropriate network, the most suitable EDI product and necessary communication equipment. Most importantly, your application software solution provider needs to ensure that the EDI is operating, application to application - thus enabling EDI received Ôtest dataõ to be processed automatically, and that the application automatically generates the required outgoing messages. Once you are at this stage you will be ready to do some tests, interchanging data with your trading partner. Only when testing has been successful, will you agree to start using real data rather than test data. Even then, there is usually a period of parallel running where both paper documents and EDI messages are being exchanged. Only when everyone is happy will the sender of data be asked to discontinue sending paperwork. Now you can see why no one gets into EDI in a hurry. There is alot of work for the end user to complete. Fortunately once you are EDI capable and using it successfully with one trading partner it becomes easier to EDI with subsequent partners. Even so, you still go through all the same steps A 13

16 Regional Offices SCOTLAND NORTH MIDLANDS Douglas House Beauchief Hall Midland House Avondale Campus Beauchief New Road Pochard Way Sheffield S8 7BA Halesowen Strathclyde Business Park Telephone: West Midlands B63 3HY Bellshill, ML4 3HB Fax: Telephone: Telephone: Fax: Fax: SOUTH MIDLANDS NORTH LONDON Sunrise Parkway Britannia House Linford Wood 958 High Road Milton Keynes MK14 6LJ London N12 9RY Telephone: Telephone: Fax: Fax: BML (OFFICE COMPUTERS) LIMITED Unit 4 The Barns Perrywood Business Park Stretton Road Honeycrock Lane Stretton Salfords Warrington Redhill Cheshire WA4 4NP Surrey RH1 5FH Telephone: Telephone: Fax: Fax: DISYS ASSOCIATES LIMITED Enterprise House The Barns Southmead Industrial Park Stretton Road Hawksworth, Didcot Stretton OXON OX11 7PH Warrington Telephone: Cheshire WA4 4NP Fax: Telephone: Fax: BCT SOFTWARE SOLUTIONS LIMITED The Barns, Stretton Road Douglas House Stretton, Warrington Avondale Campus, Pochard Way Cheshire WA4 4NP Strathclyde Business Park Telephone: Bellshill, Lanarkshire, ML4 3HB Fax: Telephone: Fax: GROUP HEADQUARTERS (RESEARCH & DEVELOPMENT CAMPUS) Beauchief Hall, Beauchief, Sheffield S8 7BA Telephone: Fax: Website: