EDIFACT: the international standard for EDI

Contribution to eLib Study on Document Requesting Standards

David Martin, Co-ordinator, EDItEUR Message Development Group

david@bookdata.demon.co.uk

1.CONTENTS

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

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

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

4. GENERAL DESCRIPTION.......................................................................................
4.1 Structure of an interchange...........................................................................................................................
4.2 Structure of a message...................................................................................................................................
4.3 Structure of a segment...................................................................................................................................
4.4 Character sets and separators.......................................................................................................................
4.4.1 Character sets.........................................................................................................................................
4.4.2 Separators...............................................................................................................................................
4.4.3 Representation of numeric values..........................................................................................................
4.5 Omission of unused elements.........................................................................................................................
4.6 Examples of two EDIFACT segments............................................................................................................
4.6.1 Date/time/period segment......................................................................................................................
4.6.2 Name and address segment....................................................................................................................

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

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

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

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

6.1 EDItEUR........................................................................................................................................................
6.2 EANCOM.......................................................................................................................................................
6.3 EDItEUR developments to date.....................................................................................................................

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

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

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

8. CONCLUSIONS................................................................................................................................................

eLib Document Ordering: EDIFACT 1 David Martin

2.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.

eLib Document Ordering: EDIFACT 2 David Martin

3.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.org
3 See http://www.ietf.org/ids.by.wg/ediint.html

eLib Document Ordering: EDIFACT 3 David Martin

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.

eLib Document Ordering: EDIFACT 4 David Martin

4.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.

4.1Structure 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

eLib Document Ordering: EDIFACT 5 David Martin

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.

4.2Structure 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:

eLib Document Ordering: EDIFACT 6 David Martin

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.

4.3Structure 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 terminator
Data 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.4Character sets and separators

4.4.1Character 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

eLib Document Ordering: EDIFACT 7 David Martin

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.4.2Separators
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 terminator
Plus sign + segment tag and data element separator
Colon : component data element separator
Period . decimal point (in numeric data elements only)
Question Mark ? release character
The 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.4.3Representation 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.12
and all would be counted as having three characters.
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

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

eLib Document Ordering: EDIFACT 8 David Martin

include recommendations to be followed for book and serials applications.

4.5Omission 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).

4.6Examples 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.

4.6.1Date/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 1
DTM+137:19990401:102'
DTM Segment tag, identifying a Date/time/period segment
+ Data element separator
137 Date qualifier, indicating that this DTM segment carries the
date of message
: Component data element separator within a composite
19990401 Date: 1 April 1999, in the format specified by the date format
qualifier
: Component data element separator
102 Date format qualifier, indicating the format CCYYMMDD
' Segment terminator.
DTM example 2
DTM+44:199904:610'
DTM Segment tag, identifying a Date/time/period segment
+ Data element separator
44 Date qualifier, indicating that this DTM segment carries an
availability date (eg the expected publication date of a
forthcoming book)
: Component data element separator
19990401 Date: 1 April 1999, in the format specified by the date format
qualifier

eLib Document Ordering: EDIFACT 9 David Martin

: Component data element separator
610 Date format qualifier, indicating the format CCYYMM
' Segment terminator.

4.6.2Name 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 1
Name and address identified by code.
NAD+BY+5012345678987::9'
NAD Segment tag, identifying a Name and address segment
+ Data element separator
BY Party qualifier, indicating that this NAD segment identifies the
buyer in a purchase transaction
+ Data element separator
5012345678987 EAN location number identifying a corporate name
and address
:: Two component data element separators, indicating
that a component data element has been omitted
9 Code list agency identifier for EAN
' Segment terminator.

eLib Document Ordering: EDIFACT 10 David Martin

NAD example 2
Name and address sent as structured text.
NAD+BY+++Stadt- und Universitätsbibliothek
:FfM:Erwerbungsabteil+Bockenheimer Landst
rasse 134:PO Box 1006+FRANKFURT++60325+DE'
NAD Segment tag, identifying a Name and address segment
+ Data element separator
BY 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 omitted
Stadt- und Univers... First line of corporate name
: Component data element separator
FfM Second line of corporate name
: Component data element separator
Erwerbungsabteil Third line of corporate name
+ Data element separator
Bockenheimer Land... First line of address
: Component data element separator
PO Box 1006 Second line of address
+ Data element separator
FRANKFURT City name
++ Data element separators, showing that a data element has
been omitted
60325 Postal code
+ Data element separator
DE 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.

eLib Document Ordering: EDIFACT 11 David Martin

5.DEVELOPMENT AND MAINTENANCE

5.1Development 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.

5.2EDIFACT 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.org
6 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

eLib Document Ordering: EDIFACT 12 David Martin

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.

6.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.

6.1EDItEUR
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.

6.2EANCOM
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
relationship with EAN with whom it collaborates to ensure that ISBNs can be
used within the EAN barcoding standard.

7 Part of Book Industry Study Group - see http://www.bisg.org

8 See http://www.bic.org.uk
9 See http://www.editeur.org

eLib Document Ordering: EDIFACT 13 David Martin

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.

6.3EDItEUR 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).
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

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

eLib Document Ordering: EDIFACT 14 David Martin

dictionary covers bibliographic, transactional, promotional and rights data,
potentially for published products in a wide range of media.

eLib Document Ordering: EDIFACT 15 David Martin

7.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.

7.1Trade 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.

7.2Library 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.

eLib Document Ordering: EDIFACT 16 David Martin

8.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 ???????????????????

eLib Document Ordering: EDIFACT 17 David Martin