edifact: the international standard for edi

EDIFACT: the international standard for EDIContribution to eLib Study on Document Requesting Standards

David Martin, Co-ordinator, EDItEUR Message Development [email protected]

· CONTENTS

1. CONTENTS......................................................................................................................................................1

2. INTRODUCTION............................................................................................................................................2

3. THE EDI ENVIRONMENT...........................................................................................................................3

4. GENERAL DESCRIPTION...........................................................................................................................4

4.1 Structure of an interchange.........................................................................................................................4

4.2 Structure of a message.................................................................................................................................5

4.3 Structure of a segment.................................................................................................................................6

4.4 Character sets and separators.....................................................................................................................64.4.1 Character sets.......................................................................................................................................64.4.2 Separators.............................................................................................................................................64.4.3 Representation of numeric values........................................................................................................7

4.5 Omission of unused elements.......................................................................................................................7

4.6 Examples of two EDIFACT segments..........................................................................................................74.6.1 Date/time/period segment....................................................................................................................74.6.2 Name and address segment..................................................................................................................8

5. DEVELOPMENT AND MAINTENANCE.................................................................................................10

5.1 Development and maintenance processes.................................................................................................10

5.2 EDIFACT syntax version 4........................................................................................................................10

6. EDIFACT FOR BOOK AND JOURNAL TRADING APPLICATIONS..................................................11

6.1 EDItEUR....................................................................................................................................................11

6.2 EANCOM...................................................................................................................................................11

6.3 EDItEUR developments to date.................................................................................................................12

7. IMPLEMENTATION PROGRESS.............................................................................................................13

7.1 Trade applications.....................................................................................................................................13

7.2 Library applications..................................................................................................................................13

8. CONCLUSIONS............................................................................................................................................14

eLib Document Ordering: EDIFACT 1 David Martin

· INTRODUCTION

EDIFACT is the recognised international standard for EDI trading in a wide range of commercial and non-commercial sectors. Its established applications are in store-and-forward “batch” communication of transaction messages of many kinds. EDIFACT begins with an underlying syntax, which is an ISO standard1. Within that syntax, there are directories of data elements, composite data elements, segments, and messages; and there are conventions for placing messages in an “envelope” which identifies the sender and receiver and other attributes of a transmission.EDIFACT itself does not define the medium by which the message is sent, or the protocols which are used in any particular form of communication. The standards are completely neutral in this respect - they define messages and their contents: nothing else.EDIFACT is an enabling standard which provides a great deal of flexibility - some might say too much - for individual application requirements to be accommodated. For this reason, very precise application guidelines are needed in addition to the basic standards. For book and serials trading, from publishers, through wholesalers, booksellers and subscription agents, to libraries, EDItEUR is the agency which develops and maintains those guidelines.This paper outlines the context in which EDI trading messages have developed; describes the underlying EDIFACT standards, and illustrates them with some very basic examples. It briefly explains the processes by which both the EDIFACT standards and relevant implementations are maintained; and identifies the agencies which are responsible for supporting them.EDItEUR book and serials applications, and their implementations to date, are described; and a final section summarises some key characteristics of the standards and their relevance to library “trading” applications.

1 ISO 9735: Electronic data interchange for administration, commerce and transport (EDIFACT) - Application level syntax rules, first edition 1988-07-15, amended and reprinted 1990-11-01, together with Amendment 1 of 1992-12-01.


· THE EDI ENVIRONMENT

EDI - Electronic Data Interchange - is defined in this context as the exchange of transaction messages from computer to computer, using structures based on a recognised national or international standard.Early developments of EDI were driven primarily by large buying organisations - supermarkets, chain stores, health services - which had the financial muscle to influence their trading partners to adopt a standard method of electronic trading, initially largely to the benefit of the buyer, though ultimately with benefits for both sides. The typical application would be based on a “hub and spoke” model, the hub being the buying organisation, and the spokes its suppliers. Messages would be transported over dial-up or, for large users, leased line connection, to a value-added network (VAN), using proprietary protocols for assuring integrity, security and end-to-end audit trail. Each party would have a mailbox on the VAN.The economics of this form of communication would certainly involve a volume charge for communication, so that the message standards aimed for conciseness, the fullest possible use of coded data, and minimal use of text.Since the real payoff from EDI came not just from more efficient communication, but also from faster and more efficient processing and turnround of transactions at each end, it was important that a message could be processed automatically, and this was and is another powerful factor favouring coded data rather than text.Early applications did nothing more than automate the existing way of doing simple transactions like orders, delivery notes and invoices, so that the benefits came from speed, accuracy, removal of duplicate keyboarding and elimination of paper and postage. More sophistication has crept in as companies have realised that continuous electronic communication between supplier and customer can bring additional benefits, eg by anticipating and planning for demand rather than waiting for orders, or even by allowing the supplier to take control of the maintenance of appropriate stock levels in stores (so-called “vendor-managed inventory”).The consequence of the widespread adoption of EDI messaging standards - now increasingly focused on EDIFACT - is that there is an equally wide range of software and systems available to support their use. Most commercial users do not develop their own EDI front-ends. They buy in a package which typically handles mapping between the EDI standard and internal file formats defined by the user; the management of trading partner relationships, by maintaining a database of who’s who and what messages are enabled as part of the trading agreement; and the timetabling and automatic running of online sessions to send and receive messages.Increasingly, the Internet is now being used for sending and receiving EDI messages, either by FTP or by email transfer. A simple MIME for encapsulating an EDIFACT message was defined as long ago as 19952; and, under the aegis of the Internet Engineering Task Force, a much more comprehensive standard3 is

2 RFC1767, March 1995, Mime encapsulation of EDI objects: see http://www.rfc-editor.org3 See http://www.ietf.org/ids.by.wg/ediint.html


being finalised which is claimed to enable an EDI message to be sent over the Internet with the same levels of security and audit trail which the Value Added Networks have traditionally provided.


· GENERAL DESCRIPTION

Section 4 of this paper gives a general description of the EDIFACT format, with some specific comment on how it is used in book trade and library applications.EDIFACT standards define the structure and content of an EDI transmission or interchange. They do not cover any aspects of transmission media or communications protocols.

.1 Structure of an interchange

An EDIFACT transmission, or interchange, using the current version (Version 3) of EDIFACT syntax, is opened and closed by a number of mandatory or conditional service segments, which constitute the “envelope” for the transmission as a whole and for messages and groups of messages within it. Inside this envelope, each message is made up of user segments. Both service segments and user segments begin with a three-letter identifier, and end with a segment separator.The structure is organised on three levels: interchange, group, and message. An interchange begins with a UNA or UNB segment and ends with a UNZ segment. A group begins with a UNG segment and ends with a UNE segment. A message begins with a UNH segment and ends with a UNT segment.A complete interchange can be represented like this:

UNA

UNB UNZ

UNG UNE UNG UNE

UNH UNT UNH UNT UNH UNT UNH UNT

data data data data

The UNA Service String Advice segment has a simple fixed format, and defines the codes which are being used as standard separators throughout the rest of transmission. The UNA segment may, however, be omitted, in which case a default set of separators is assumed.The first mandatory segment is the UNB Interchange Header, which identifies the sender and addressee for the transmission, specifies the character set used, and carries other housekeeping data. It is important to note that there is no assumption that the sender and addressee for the transmission are the same as the sender and addressee for individual messages within it, and there are indeed


real situations in which they are not. For example, a library network may act as a clearinghouse for transaction messages between member libraries and their book suppliers, so that one transmission from the network EDI gateway carries messages from a number of different senders.This header segment is matched with a mandatory UNZ Interchange Trailer segment, which ends the transmission, and provides a first level of checking on the integrity of the interchange.If a single transmission includes messages of different types, each different type is placed into a group introduced by a UNG Functional Group Header segment and terminated by a UNE Functional Group Trailer segment. In practice, there is no need in most EDIFACT applications to mix different message types in a single transmission, and the Group level is not generally used. Specifically, it is never used in book trade and library applications.Finally, each message is introduced by a mandatory UNH Message Header segment, and ends with a mandatory UNT Message Trailer segment. The UNH segment identifies the message type and version, and the agency responsible for its maintenance. The UNT segment provides another level of basic integrity checking.The format and content of the UNA, UNB, UNZ, UNG, UNE and UNT segments are identical, irrespective of the message types carried within the interchange. The format of the UNH segment is the same for all message types, but the content differs for each message, and is defined as part of the message specification.In some messages there is an additional service segment, UNS, which acts as an internal separator between two major sections of the message.Where a standard EDI software package is used to handle incoming and outgoing communications, all of these service segments will normally be generated and/or processed and checked by the EDI software, and will be invisible to the user application.

.2 Structure of a message

Each data segment has a specific place within the sequence of segments in the message. Each message is composed of three sections: header, detail and summary. Each section is made up of segment groups and segments.The header section is a group of segments containing information which relates to the entire message. The header section as a whole is not repeatable, though some segments or sub-groups of segments in the header may be individually repeated.The detail section is a group or groups of segments carrying information which relates to repeating elements in the message, such as order lines or invoice lines. By analogy with paper documents, in many of the simpler standard transaction messages each repeat of the detail section is referred to as a line (but note that carriage returns and line feeds have no particular significance in EDIFACT). In more complex messages the structure of the detail section may involve nested repeats at several levels: for example, a despatch advice may describe a number of consignments, each containing a number of cases or parcels, each in turn containing specified quantities of product items. The summary section is a group of segments containing totals or control information, eg invoice total amount or number of lines in a purchase order. Like the header section, it occurs only once per message.


The sequence of the three message sections can be represented by the following simple example:Header section UNH..... BGM..... ........... ...........

...........Detail section LIN....... QTY..... ........... ...........

...........LIN....... QTY..... ........... ........... ...........

Summary section CNT..... UNT.....The same segment type may occur in more than one of the message sections, e.g. in the header and in the detail section, and/or more than once in the same section.Some segments may be repeated a certain number of times at their specific location in the message. The status, mandatory or conditional, and the maximum number of repetitions of segment types are indicated in the message specification.Within a message, specific groups of functionally related segments may be repeated; these groups are referred to as segment groups. The maximum number of repetitions of a particular segment group at a specific location is included in the message specification.A segment group may be nested within other segment groups, provided that the inner segment group terminates before any outer segment group terminates.

.3 Structure of a segment

A segment consists of:· A three-letter segment tag, which identifies the segment type· Data element separators· Simple, composite, or component data elements· A segment terminatorData elements can be defined as having fixed or variable length.A composite data element contains two or more component data elements.A component data element is a simple data element used in a composite data element.A data element can be qualified by another data element, the value of which is expressed as a code that gives specific meaning to the data. The data value of a qualifier is a code taken from an agreed set of code values.

.4 Character sets and separators

.4.1 Character sets

EDIFACT standards define a number of character sets, coded in the UNB segment at the beginning of each interchange as UNOA, UNOB, UNOC, etc. UNOA and UNOB correspond to the basic ASCII character sets of ISO 646 and ISO 6937. UNOC to UNOF correspond to the alphabets defined in Parts 1, 2, 5 and 7 of ISO 8859.Book Industry Communication (BIC) in the UK and EDItEUR internationally have adopted UNOC as the standard character set for book and serials trading within


EDIFACT syntax version 3. This character set permits the representation of a full repertoire of special characters, including accents, for the following languages using the Latin alphabet: Danish, Dutch, English, Faroese, Finnish, French, German, Icelandic, Irish, Italian, Norwegian, Portuguese, Spanish, Swedish. It corresponds to the international standard character set ISO 8859.14.Version 4 of EDIFACT syntax, most of which has recently completed the ISO approval process, will extend the character set options to include support for UNICODE

.4.2 Separators

In principle, any five available characters may be defined as separators by declaring them in the UNA segment at the start of a transmission. In practice, the following are the most widely used:Apostrophe ' segment terminatorPlus sign + segment tag and data element separatorColon : component data element separatorPeriod . decimal point (in numeric data elements only)Question Mark ? release characterThe function of the release character is to allow a symbol which has been defined as a separator to be used with its normal meaning in a text data element. The release character precedes the separator which is to be returned to its normal meaning. For example, if + and ? are used as separators, an international telephone number could be expressed as ?+44 171 607 0021. A question mark would be expressed as ??. (The release character is not needed with the symbol defined to represent a decimal point, since this applies only in numeric data elements, not in text data elements.)The release character is not counted within the maximum length defined for an EDIFACT data element. Most standard EDI conversion software will handle these coding conventions in such a way that the user application is unaware of them. There is a default set of separators associated with each standard character set UNOA, UNOB etc. If the default is not used, the UNA segment must be sent. The set shown above is the default for UNOA, but is also widely used with extended character sets. BIC and EDItEUR have adopted it as the recommended set for book and serials applications. Since the recommended set is not the default for the UNOC character set, it follows that the UNA segment is expected to be sent.

.4.3 Representation of numeric values

Numeric data elements in EDIFACT are sent as real, positive or negative, decimal numbers, with a decimal point and/or a minus sign if required, and without leading or trailing zeros, except for a single zero before the decimal point if the value is less than 1. The decimal point and the minus sign are not counted within the maximum length of the data element.Thus the following are all valid contents of a numeric data element in EDIFACT:123 12.3 0.12 -123 -12.3 -0.12and all would be counted as having three characters.

4 ISO 8859-1:1987, Information processing - 8-bit single byte coded graphic character sets - Part 1: Latin alphabet No 1


Within the overall maximum length of a numeric data element, EDIFACT itself does not define how the number may be divided between an integer part and a decimal fraction part. However, BIC and EDItEUR implementation guidelines include recommendations to be followed for book and serials applications.

.5 Omission of unused elements

To keep messages concise, EDIFACT omits unused elements wherever possible. Any complete segment or segment group which is not required in the message is omitted. A segment is terminated immediately after the last data element for which there is actual content. Empty data elements are represented by including the required separators, and nothing else (as, for example, in a comma-delimited format).

.6 Examples of two EDIFACT segments

To illustrate the principles which have been described above, we show in this section two standard EDIFACT segments: a DTM (date/time/period) segment and a NAD (name and address) segment.

.6.1 Date/time/period segment

A DTM segment is used in any context where it is necessary to represent a date, a date and time, or a time period. It consists of the segment tag DTM and one composite data element with three components: a date qualifier, which specifies the function of the date segment in the context in which it occurs; the date/time or time period itself; and a date format qualifier, which specifies which of a very wide range of standard formats has been used for the date/time or time period.The date qualifier can indicate, for example, that this occurrence of the DTM segment represents the date of the message, or the date at which an order line is to be cancelled if the item has not yet been supplied, or the time period during which a special price is applicable.DTM example 1DTM+137:19990401:102'DTM Segment tag, identifying a Date/time/period segment+ Data element separator137 Date qualifier, indicating that this DTM segment carries the

date of message: Component data element separator within a composite19990401 Date: 1 April 1999, in the format specified by the date format

qualifier: Component data element separator102 Date format qualifier, indicating the format CCYYMMDD' Segment terminator.DTM example 2DTM+44:199904:610'DTM Segment tag, identifying a Date/time/period segment+ Data element separator44 Date qualifier, indicating that this DTM segment carries an

availability date (eg the expected publication date of a forthcoming book)


: Component data element separator19990401 Date: 1 April 1999, in the format specified by the date format

qualifier: Component data element separator610 Date format qualifier, indicating the format CCYYMM' Segment terminator..6.2 Name and address segment

A NAD segment is used in any context where it is necessary to represent a personal or corporate name and address. It consists of the segment tag NAD, a party qualifier which specifies the function of the NAD segment in the context in which it occurs, and a series of simple and composite data elements which allow the name and address to be represented by an agreed code and/or by structured or relatively unstructured text fields.NAD example 1Name and address identified by code.NAD+BY+5012345678987::9'NAD Segment tag, identifying a Name and address segment+ Data element separatorBY Party qualifier, indicating that this NAD segment identifies the

buyer in a purchase transaction+ Data element separator5012345678987 EAN location number identifying a corporate name and address:: Two component data element separators, indicating that a

component data element has been omitted9 Code list agency identifier for EAN' Segment terminator.


NAD example 2Name and address sent as structured text.NAD+BY+++Stadt- und Universitätsbibliothek :FfM:Erwerbungsabteil+Bockenheimer Landstrasse 134:PO Box 1006+FRANKFURT++60325+DE'NAD Segment tag, identifying a Name and address segment+ Data element separatorBY Party qualifier, indicating that this NAD segment identifies the

buyer in a purchase transaction+++ Data element separators, showing that two composite data

elements have been omittedStadt- und Univers... First line of corporate name: Component data element separatorFfM Second line of corporate name: Component data element separatorErwerbungsabteil Third line of corporate name+ Data element separatorBockenheimer Land... First line of address: Component data element separatorPO Box 1006 Second line of address+ Data element separatorFRANKFURT City name++ Data element separators, showing that a data element has

been omitted60325 Postal code+ Data element separatorDE ISO country code' Segment terminator.It is hoped that these rather elementary examples will give some indication of the way in which standard segments provide very considerable flexibility and scope. These standard segments are the “building blocks” from which EDIFACT messages are constructed.


· DEVELOPMENT AND MAINTENANCE

.1 Development and maintenance processes

EDIFACT is developed and maintained under the aegis of UNECE5, the United Nations Economic Commission for Europe, whose remit in this respect runs globally - in spite of the name. The responsible agency is UN/CEFACT, the Centre for the Facilitation of Procedures and Practices in Administration, Commerce and Transport.CEFACT is supported by national and regional bodies worldwide; and through a series of working groups and plenary meetings, it publishes successive revisions of the EDIFACT Directory.The EDIFACT Directory is the authority which specifies data elements and code lists, segments and messages. New directories are issued normally twice a year, and can be downloaded as text files from a UNECE website6. A number of commercial suppliers of EDI software also maintain websites from which the directories are available in other formats, together with software for viewing them and using them to derive specific application subsets.The standards are, however, more stable than a twice-yearly revision process might seem to imply. Since 1992, when there was a rather major review of the basic messages, almost all change has been upwards-compatible. Most changes are additions or clarifications.Successive EDIFACT directories are developed within the current version of EDIFACT syntax. New versions of the syntax are infrequent, and when they are required they go through a full ISO approvals process. The current syntax version is Version 3. Version 4 will shortly be brought into use.

.2 EDIFACT syntax version 4

Most sections of EDIFACT syntax version 4 have recently completed all stages of ISO approval, and can be expected to appear in commercially-available EDI software in the next twelve months. There are three enhancements to the syntax which may be particularly relevant to book and serials applications.First, new features are being added specifically to support interactive communication. Traditionally, EDI message standards have been designed only for store-and-forward “batch” transfers. Recently, there has been pressure from a number of sectors, most notably the travel business, for international standards for interactive sessions linking disparate computer systems, for example airline, car hire and hotel reservations systems.Second, provision is being made for including “non-EDI objects” within an EDI transmission, so that, in effect, binary data strings can be wrapped within an EDIFACT envelope.Third, support for extended character sets will now include a UNICODE option, consistent with the universal character set standards adopted on the Internet.

5 See http://www.unece.org6 For example, the EDIFACT D96A Directory on which current EDItEUR book and serials implementations are based can be found at http://www.unece.org/trade/untdid/d96a/content.htm


Other new features in version 4 relate to the security of messages. Some of these have not been finally approved at the time of writing.

· EDIFACT FOR BOOK AND JOURNAL TRADING APPLICATIONS

EDIFACT is a world-wide, cross-industry, standard for trading communications of all kinds. Consequently it is highly generalised, and rich in optional elements which many business sectors may not need to include. For any specific application, an implementation subset must be defined; and industry coding schemes (for example the availability status codes used by publishers and booksellers when an ordered item is not immediately available) may need to be accommodated.In the classic “hub-and-spoke” EDI model described in section 2, the “hub” will usually specify the implementation. In the book and serials businesses, there have so far been few if any dominant “hubs”, and implementation models, within national EDI standards or in EDIFACT, have developed cooperatively, through organisations like BISAC7 in the United States, Book Industry Communication (BIC)8 in the UK, and EDItEUR9 internationally.

.1 EDItEUR

EDItEUR is the International Book and Serials EDI Group, recognised by the Commission of the European Union and by the Western European EDIFACT Board, and supported by the European Federations of Library, Booksellers and Publishers Associations (respectively EBLIDA, EBF and FEP), and by the International Publishers Association. EDItEUR’s aim is to co-ordinate the development, promotion and implementation of EDI in book and serials trading, and to do so by collaboration with national EDI groups in these business sectors and with other relevant international groups (such as ICEDIS, the International Committee on EDI for Serials). The Secretariat is housed at the offices of Book Industry Communication in London. The development and maintenance of the EDItEUR EDI Manual and Implementation Guidelines is the primary task of the EDItEUR Message Development and Maintenance Group.Despite its name and origins, EDItEUR is a truly international organisation with over 100 members from 20 countries, including Australia, Canada, Japan, South Africa, United States and most of the European countries. EDItEUR acts as an international umbrella body for various national book sector EDI groups.EDItEUR is officially recognised as an EDIFACT code assignment agency for industry code lists applicable to the book and serials businesses.

.2 EANCOM

One of the key organisations involved in the development and promotion of EDIFACT standard is EAN, the international article numbering association. EAN is the body which administers product numbering and barcoding standards worldwide through its national affiliates. The book trade has a long-standing

7 Part of Book Industry Study Group - see http://www.bisg.org8 See http://www.bic.org.uk9 See http://www.editeur.org


relationship with EAN with whom it collaborates to ensure that ISBNs can be used within the EAN barcoding standard.Under the name EANCOM, EAN International maintains a stable and well-documented subset of EDIFACT messages. EANCOM is the most widely-used EDIFACT standard in the international retail and distribution sector among others.From a very early stage, EDItEUR determined that it would wherever possible work within the EANCOM subsets of EDIFACT message standards, and to this end it has established a close working cooperation with EAN International.The key benefits of working within the EANCOM subset are that the book and serials trades are using standards which are widely recognised in related sectors with whom trading communication may also be required, and that, through EAN, EDItEUR is able to keep in close touch with, and where necessary help to influence, wider EDIFACT developments.

.3 EDItEUR developments to date

EDItEUR has been working since 1992 to develop user guidelines for EDIFACT messages, based on the EAN subset, and covering a number of application areas. Influenced both by BIC’s experience with TRADACOMS standards in the UK, and by the EDILIBE project, EDItEUR has always emphasised the need to relate EDI message implementation to the complete business cycle in a specific area. The processes of ordering, receiving and paying for trade book supply are different from those in library book supply, and both are very different from those of entering or renewing journal subscriptions - though all will use the same standard messages.So EDItEUR Implementation Guidelines10 focus on the three specific areas of Trade book supply, Library book supply and Serials. Trade book supply deals with the transaction cycle between booksellers, wholesalers and publishers, from orders to invoices and credit notes, using EDIFACT Purchase Order, Purchase Order Response, Purchase Order Change, Order Status Enquiry, Despatch Advice and Invoice messages.Library book supply covers a similar transaction cycle between academic or public libraries and specialist library booksellers, and adds the facility for suppliers to start the cycle by sending an electronic equivalent of a traditional new title notification slip. The messages used are EDIFACT Quotes, Purchase Order, Purchase Order Response, Purchase Order Change, Order Status Enquiry, and Invoice.For serials, EDItEUR has so far covered three separate applications: the communication of journal issue despatch information from publishers to subscriptions agents, or from agents to libraries; electronic claims and claims responses, again at both levels of the supply chain; and subscription renewal invoices, from agents to libraries only.Other application areas which are at various stages of development include communication between suppliers and their shippers or parcels carriers, allowing the tracking of shipments from despatch to delivery; the handling of returns authorisation between booksellers and publishers; and the whole trading cycle between publishers and manufacturers (book printers or binders).

10 Available for downloading in PDF format from http://www.editeur.org


Perhaps the most important EDItEUR work-in-progress at the time of writing is the development of a data dictionary for product description, and an associated EDIFACT Price Sales Catalogue message for communicating “rich” product information from publishers to all levels of the supply chain. The data dictionary covers bibliographic, transactional, promotional and rights data, potentially for published products in a wide range of media.


· IMPLEMENTATION PROGRESS

EDIFACT, and specifically the EDItEUR implementation, has established itself as the accepted international standard for trading communications for books and serials; but, having said that, progress in real-life implementation has inevitably been uneven. In North America and in the UK, where national or regional standards already existed and were in widespread use, it will take longer to translate acceptance in principle into actual use. By contrast, in countries where no previous standard existed, EDIFACT has been accepted as the natural choice for both national and international trading.Interestingly, library supply is leading the trade in its adoption, partly because there were fewer existing applications using previous standards, partly because much library book and journal supply is inherently an international business, and partly because so many library systems suppliers operate in an international market and want to implement one standard for as many of their customers as possible.

.1 Trade applications

Book trade EDI systems in Finland, Sweden, Denmark, Germany, the Netherlands and Italy have adopted standards based wholly or partly on EDItEUR guidelines. New Zealand has announced plans to do so. BIC in the UK has adopted a policy of developing all new EDI applications only in EDIFACT, and of encouraging publishers and booksellers to accept both EDIFACT and TRADACOMS. BISAC in the USA has started a programme of mapping all its existing US X12 EDI message standards into EDItEUR equivalents.In journal supply, ICEDIS, the international group which has developed EDI trading between journal publishers and subscription agents, has adopted a policy of working with EDItEUR to migrate its existing formats to EDIFACT and to develop any new applications also in EDIFACT. EDItEUR claims and claim response messages are being piloted between ICEDIS members in 1998.

.2 Library applications

The EDILIBE project was mentioned in the last section. This EU-funded project linked a number of academic and national libraries in Germany, the Netherlands, the UK, Spain and Italy with library suppliers in the UK, Italy and Germany. The message standards developed for the project were a central part of the first release of the EDItEUR Manual (1995). A considerable number of library system suppliers have installed basic EDIFACT book ordering functions in existing systems, and these are in daily use with suppliers such as Dawsons and Blackwells, Harrassowitz and Casalini. Currently, many if not most international library systems suppliers are working on more comprehensive implementations, for both books and serials. It has been particularly encouraging to EDItEUR that US libraries and their systems suppliers have been among the first to adopt these standards, in spite of the existence and widespread trade use of the US national EDI standard, X12.


· CONCLUSIONS

The key characteristics of EDIFACT which are relevant to the present discussion are these:· It is the accepted international standard for electronic transaction messages

across many fields, including, in this context, library book and journal supply.· It is already implemented, and well understood, by many library systems

suppliers.· It is independent of any particular transport medium or protocol - EDIFACT

defines the messages, not how they are carried.· Messages are already defined for many basic transactions, including financial

transactions which are not always adequately considered in library-specific standards.

· The message standards are very flexible in terms of content and coding for specific applications.

· Book and journals applications of EDIFACT are actively developed and supported by EDItEUR, an agency which represents libraries as well as trade interests, and by competent national agencies in the UK, the USA and other countries.

· To date EDIFACT has supported store-and-forward rather than interactive transactions, so that although the latest version of EDIFACT syntax also has interactive functionality, it is probably more realistic to regard it as appropriate to batch, or at least off-line, applications.

There seems no reason to doubt that EDIFACT messaging for book and journals acquisitions will be the norm in the next generation of academic and public library systems. It is beyond the scope of this paper to speculate on whether this will lead to its use in any ILL-related transactions; but, as mentioned in Ruth Moulton’s paper11, EDIFACT syntax has been used within the ILL Protocol to define message formats specific to this application. If it were to be newly considered, it would be appropriate to look first at the feasibility of using subsets of the same EDIFACT standard messages - orders, order responses, and so on - which are already being applied to library book and serials ordering, rather than designing new messages from scratch. Experience in developing other library applications in EDIFACT strongly suggests that this approach would be feasible.

11 ???????????????????


edifact: the international standard for edi

Documents