Standards for electronic data exchange Nigel Fenton describes the Tradacoms standards for data communications
Despite the increasing use of computers by companies to handle their trading data, the communication of orders, invoices and statements between organizations still relies heavily on the issue and transfer of paper documentation. However, moves to computerize this exchange have been hampered by a lack of standardization in the documents and data files used by different companies. In 7980, the Article Number Association established a Working Party to define a set of trading standards, and the result of their study was the Tradacoms system. The paper describes the background to and application of the standards. Keywords: standards, trade literature, electronic data exchange Trading companies devote a surprising proportion of their resources to the handling of paper documentation. They generate, despatch and cross-check a plethora of orders, invoices, statements and price lists, and, as well as taking up time, this laborious routine creates a breeding ground for clerical and accounting errors. Of course, this processing of trading data is unavoidable, but it can and has been streamlined in many companies by the introduction of computers. Unfortunately, computerization does not solve all the problems. Certainly, the computer provides an excellent means for performing the internal 'number crunching', but all these figures are generally converted into paper documents for despatch to the trading partner, who must then type them all back into his own computer. The idea of arranging direct computer-to-computer communications, thereby eliminating the intermediate paper chase, is not a new one, but until quite recently there was a fundamental Article Number Association (UK) Ltd, 6 Catherine Street, London WC2B SJJ, UK
problem: every company structured their documents and data files differently, so that they could not be recognized or processed by any other company's computer system. Even worse, an alarming response to this dilemma was beginning to appear. Companies were adopting ad hoc data formats, which they were then imposing on their trading partners. An initiative was required to develop a standard language for these communications, and this was taken in 1980 by the Article Number Association (ANA). The ANA, whose principal role is the administration of the European article numbering (EAN) and barcoding system in the UK, was a suitable centre for this work, since it has a large membership of manufacturers, retailers, wholesalers and allied sectors of trade. Furthermore, an interest in standardization of data communications followed logically from the Association's concern with standard product numbering. A Working Party was formed to address the issue of defining one set of data communications standards that could be used in a wide range of trade applications. The grocery trade is only one of the industry sectors represented within the ANA membership: any application where products can be given identity numbers stands to benefit from an efficient system of data exchange and the Working Party had this very much in mind when assessing the requirements for standardization. There were two important basic steps: • defining the type of data to be exchanged, • defining the format of that data. The system of standards that the Working Party produced is called Tradacoms (Trading Data Communications). It provides for two types of data: master files and transaction files. The master files, for product, price and customer information, ensure a clear understanding by both parties in a trading agreement of the goods'
0140-3664/84/040181-05503.00 © 1984 Butterworth & Co (Publishers) Ltd. vol 7 no 4 august 1984
181
discription, price and delivery point prior to any transaction taking place. The transaction files translate the information hitherto appearing on paper into computer format; files have so far been defined for orders, invoices, credit notes, delivery notes, statements and general text. Moreover, if product, price and location files have been exchanged in advance between trading partners, the transaction files can be dramatically simplified by omitting from them all the predefined information. The task of defining these master and transaction files was undertaken by the Working Party, which included representatives from the entire spectrum of ANA membership. The Working Party also adopted a system of syntax rules which would structure this data content. The syntax rules chosen were those developed by SITPRO (Simplification of International Trade Procedures Board), a Government-sponsored body, which, as part of the UN Economic Commission for Europe, has done much work internationally in the area of data exchange via computer media. The SITPRO syntax rules have the following advantages: • they are independent of machine, media or systems, • they do not affect the existing structure of data processing within users' in-house systems, • they are not affected by use of different communications protocols, • they offer a maximum of flexibility through the use of variable length data and conditional fields. The outcome of this bringing together of the SITPRO syntax rules and the Working Party's data content definition was a manual of standards for electronic data exchange. The publication of this manual (entitled Trading Data Communications: Standards for Electronic Data Exchange) in November 1982 cleared the first hurdle in the path to achieving direct data exchange. One additional development which made this advance possible was HM Customs and Excise's agreement that paper documents could be replaced for VAT purposes by computer transactions on electronic media.
• the transmission: an interchange of one or more data messages at one time between two companies, • a message: a component of a transaction file e.g. order header, order details, order trailer, • a segment: each message is made up of data segments e.g. message header, supplier details, document-totals, message trailer, • an element: each segment is further split into a group of related data elements, these being items of information e.g. 'quantity delivered'. Every message, segment and data element used throughout the standards has a mnemonic identifier, which permits easy recognition and interpretation by the programmer. Figure 1 illustrates the structure of an order file. The structure of a transmission is always: • a start segment 'STX' (contains sender and recipient details) • a number of messages • an end segment (contains a count of the messages sent) The structure of a message is: • a message header segment 'MHD' (identifies the message type) • data segments (e.g. order lines) • a message trailer segment 'MTR' (contains a count of the number of segments) The structure of a segment is: • a segment identifier (a defined mnemonic e.g. OLD for Order Line Details) • a number of data elements (e.g. 'Order Line Details' includes Line Sequence Number, Suppliers Product Number and Quantity Ordered) • a number of subelements (e.g. Quantity Ordered contains subelements for Number of Traded Units, Total Measure Ordered and Measure Indicator). Data separator and terminator characters have also been defined, such that a document in the Tradacoms format is reduced to a string of data units, readily intelligible to any computer system that has been programmed to recognize the Tradacoms structure. Figure 2 illustrates the component messages of an order assembled according to the syntax rules.
STRUCTURE OF THE T R A D A C O M S STANDARDS Use of the standards The Tradacoms system is a true standard in that it is not confined to one specific application or area of trade. It provides a working bridge between trading partners who wish to take advantage of direct computer-tocomputer communications.
Structure of the standards How are the Tradacoms standards structured? They can be thought of as four levels of syntax:
182
How are the standards used in practice? Since their publication, several hundred copies of the manual have been sold, and about 1O0 companies have implemented the standards, principally for the exchange of orders and invoices. Because the standards are intended to bridge, rather than to replace, inhouse computer systems and file structures, users must make arrangements to convert data from one format to the other. There are two principal ways in which this can be achieved. The
computer communications
Message:
Consisting of segments -
ORDHDR
MHD = Message Header
Order file header
TYP = Transaction Type Details
Repeating as follows, :
SDT = Supplier Details One message only,,et the start of the file
CDT = Customer Details FIL = File Details MTR = MessageTrailer ORDERS
MHD = Message Header
Order details
CLO = Customers Location
One message for each order
ORD = Order References DIN = Delivery Instructions OLD = Order Line Details
Repeatingfor each line ordered
OTR = Order Trailer MTR = MessageTrailer ORDTLR Order file trailer
MHD = Message Header OFT = Order File Totals
One message only, at the end of the file
MTR = MessageTrailer
Figure 7.
Order file structure
message structure can be hard coded into messaged e p e n d e n t application programs or it can be defined by means of parameters held in tables. The former approach allows easy programming, ready interfacing within inhouse systems and short development times, while the latter offers better flexibility and can permit several partners to jointly develop one conversion system. Additionally, SITPRO have developed a software package called Interbridge, which allows for conversion between inhouse and Tradacoms layouts. The Tradacoms standards are not media dependent, and they have been used with success on magnetic tapes, floppy discs and via telecommunications. The manual gives guidance on requirements for all these media types.
vol 7 no 4 augus t 1984
THE
EFFECTS
Eliminating a vast amount of paperwork and removing the need for recipients of communications to key punch data from documents are two of the cost savings that Tradacoms can provide. Computer-to-computer communications are more accurate using the standards, and the number of queries is therefore reduced. Much of the time and money spent on resolving queries can be saved by improving communications efficiency. Retailers, for example, have reported that the use of Tradacoms reduces the level of errors typically associated with the manual input of invoices by anything from 2% to 20%. A reduction in errors leads to a faster authorization of data and update of the corresponding ledger: this in
183
STX=ANA:I +ANY SHOP PLC+:XYZMANUFACTURING PLC+820321+REFS+REFR' MHD=I+ORDHDR:3' WP=O430-I-NEW-ORDERS' SDT=5000100001014:7215+XYZMANUFACTURING PLC+LEEDS-I-000000000' CDT=5000600003101:68100+ANYSHOP PLC+HEADOFFICE:72KING STREET:LONDON EC2'
FIL=1+1+820321'
MTR=6' MHD=2+ORDERS:3' CLO=5000600003240::68322' ORD=981::820321' DIN=820328++RING BEFOREDELIVERY' OLD=I -I-5000100481452+5000100074326+-I-12+1 ++++PRODUCT A' OLD=2+5000100350666+5000100068271++6+2++++PRODUCT 8' OLD=3 +5000100154073+5000100154066++4+3 ++++PRODUCT C' OTR=3+6' MTR=9' MHD=3+ORDERS:3' CLO=5000600003282::68347' ORD=982::820321' OLD=I +5000100769680-1-5000100769673-1-+6+5++++PRODUCT K' OLD=2 +5000100658465-1-5000100668136++6+8++++PRODUCTL' OTR=2+I 3' MTR=7' MHD=4+ORDTLR:3' OFT=2' MTR=3' END=4'
Figure 2.
Order assembled according to syntax rules
turn permits tighter control of payment and cash flow. Suppliers also benefit from receiving clean orders to a predefined format. These permit faster, more efficient deliveries and a reduction in stock shortfalls. Reconciliation of invoices and credit notes with delivery and with orders placed can, using Tradacoms, become automatic. Using standard product codes and location codes in electronic communications means that the essential data - - company name and address, product, quantity, value - - can be immediately recognized by the computer, and there is no need for human intervention to interpret the information or to convert from one system of coding to another. In this way, the cost of administrative procedures is reduced. Furthermore, it has been found that the use of Tradacoms imposes useful disciplines within the departments concerned, e.g. improvement of internal codification procedures, greater liaison between trading partners and streamlined operation of data-preparation systems The various Tradacoms messages also provide for an integrated system of communications. The product information, price information and customer information files can be communicated to provide the background data in the master files. The first step in a transaction would then be for the retailer to produce a suggested order on the basis of sales data collected by his electronic point-of-sale equipment. This would be displayed for discussion with the supplier's representative and amended to take account of particular circumstances such as promotions, specials, local variations, new products, etc. The order is then transmitted to the supplier whose computer immediately
184
checks the stock availability and makes adjustments for any stock shortages. The computer then produces delivery instructions, picking lists and delivery notes. The delivery notification can be transmitted to the customer (although it is unlikely that paper delivery notes can be replaced by electronic communications). The goods are then delivered and the EAN codes shown on the outer cases checked against the EAN codes on the delivery note. Discrepencies between goods received and the delivery note are input to the customer's computer and could be transmitted to the supplier. The supplier's computer can produce accurate invoices, showing only goods actually received by the customer, and transmit them to the customer. The customer's computer then transmits the remittance advice, according to the normal payment terms. It should be noted that companies need not use the whole cycle of electronic communications if they prefer to take advantage of individual parts. It is expected that companies will gradually move towards the integrated total system. There is no doubt, however, that the need for efficient direct links between trading partners' computer systems will continue to grow, not least because the rapid development of electronic point-of-sale techniques is already allowing sales and reorder data to be generated in electronic form.
THE NEXT STEP By the third quarter of 1984, over 1 O0 companies will
computer communications
be sending data to their trading partners using the Tradacoms standards, mainly on magnetic tape. It has been recognized for some time that there are even greater benefits to be gained from the exchange of data in Tradacoms format using direct telecommunications between computers. These include increased speeds of data transfer, reduction in control problems associated with physical media such as magnetic tapes and floppy discs, and flexibility for intercommunication with future systems. The existing standards allow for one-to-one transmission between companies and, indeed, several partners are already exchanging data using telecommunications. However, there are practical difficulties to be overcome before such direct data exchange can take place between large numbers of companies. These arise principally because of the absence of international file transfer protocols which would enable users with different computer hardware types to communicate directly. Such protocols are certainly being developed: for example, the standards for open systems interconnection being developed by the ISO since 1977. Some of these are sufficiently advanced to permit their introduction into service, albeit prior to final acceptance, and the Department of Trade and Industry have launched an Intercept Strategy to identify and promote standardization 'recommendations' that may usefully be implemented. ANA strongly supports this work and intends to give every encouragement to its members to adopt true OSI standards when these are available. However, the fact remains that such standards are unlikely to be approved and practically implemented by equipment manufacturers within the next five years. Another requirement of a direct data exchange system is that it should permit rapid transmission of very large volumes of data, such as a batched consignment of invoices or orders. Networks for data transfer already exist, but the available options such as packet switching are not able to provide adequate, cost effective capacity for the anticipated data loads. A solution to the problem is to use a third-party
vol 7 no 4 august 1984
bureau facility. A bureau, by performing protocol conversion, could facilitiate efficient multilateral exchange of trading data between users with different hardware types, in addition to providing a range of value-added services from which users can select, according to their needs. For example, the bureau could also perform the service of arranging for transmissions to be sent or received in batches at times to suit the users. This would be achieved through the use of electronic post and mail boxes, enabling users to transmit and collect data selectively, e.g. according to its type, urgency or source. The bureau would service the needs of a wide range of user sizes, e.g. from the mainframe-based manufacturer with sophisticated DP facilities, to the small shop equipped with a backroom microcomputer and humble teletype. Telecommunications would be achieved via a range of channels from dial-up t o leased line as necessitated by the user's volume of data. One-to-one company links would become unnecessary, although, of course, use of the bureau would remain optional. When international file transfer protocol standards become available, the bureau would assist in their implementation. The ANA has already moved towards making the bureau operation a reality. During 1983, the Tradacoms Working Party has developed a detailed specification for the requirements of a bureau service, and undertook a rigorous assessment of candidate bureau operators. Trials will take place during the latter part of 1984 (with Baric Computing Services- the selected bureau company) in order to test their proposed solution. The potential data traffic for an economically run bureau network service is enormous. It has been calculated that if 40 suppliers and 25 retailers were all interchanging data with each other, they would generate around 1 000 M characters per week for invoices alone. Clearly, both the user and the bureau operator stand to profit from an efficient network operation that allows fast, inexpensive and secure exchange of data. The Tradacoms standards provide the foundations on which to build such a system in the near future.
185