Electronic Data Interchange using Two Dimensional Bar Code
Robert B. Johnston and Alvin Khin Choy Yap
Department of Business Systems, Monash University, Australia
johno@fcit-m1.fcit.monash.edu.au
Abstract
The development in the late 1980s of two dimensional bar
code symbologies capable of storing kilobytes of
information in a single symbol and unlimited data in
multiple symbols has led to the suggestion that bar code
could be used as a medium for transmitting EDI
messages. This paper considers whether such a
suggestion targets any real business problem and whether
such a system would work in practice. The transmission
of shipment information between suppliers and customers
was identified as a potential application of bar code EDI.
Conventional EDI approaches encounter problems
deriving from lack of synchrony between the electronic
message and the physical delivery and these problems
become especially acute in a Just-In-Time replenishment
environment. Results are reported of three studies
conducted addressing different aspects of the feasibility
of bar code EDI: its organizational feasibility, its
technical feasibility and its practical feasibility.
1. Introduction
Electronic Data Interchange, EDI, is defined by
Emmelhainz as "the Interorganizational exchange of
business documentation in a structured, machineprocessable form" [1, p4]. It is normally assumed that the
communications media involved in EDI are the usual
speed-of-light telecommunications media. However,
since the development, in the late 1980s, of two
dimensional bar codes with a high data carrying capacity
[2,3] it is conceivable that structured business data could
be transmitted in machine readable form between
computer applications using paper as the medium of
transmission. This idea has been termed "paper-based
EDI" [4]. Since one of the aims of EDI is the elimination
of paperwork in the business cycle, it would only make
sense to consider this medium when a suitable printing
surface remains even in an electronic trading situation.
Transmission of shipment information is one such
situation, not only because some form of delivery docket
is often retained in this transaction but also because the
packaging of goods itself provides a potentially suitable
medium. Although a number of authors have suggested 2D bar code as a replacement for conventional EDI for
advance shipping information [4-8] and for import/export
documentation [9], there appears to be no account of an
actual implementation in the academic literature.
All this begs the questions: Is there any point in doing
EDI this way; and would it work in practice? One reason
to consider encoding delivery information in bar code
form is that this way its transmission can then be
synchronous with the delivery of goods. The conventional
approach to transmission of shipment information via
EDI using the Advanced Shipping Notice, ASN,
transaction set has two disadvantages. Firstly, the ASN
must somehow be identified with the physical shipment
and, secondly, timing problems in sending or processing
the ASN can disrupt goods receiving [5,7] especially in a
Just-In-Time environment where many small shipments
arrive daily from suppliers often situated close at hand.
Also, in a JIT environment telecommunication costs
become significant.
This paper reports an investigation of the feasibility of
using a 2-D bar code symbology (PDF417) as a means of
transmitting shipping information by printing the bar
code symbols that encode the data on the normal human
readable paper delivery docket. Three aspects of its
feasibility have been studied [10];
• Organizational feasibility: Are there problems with
existing approaches to materials replenishment for
which bar code EDI would be a feasible, cost effective
and sensible solution? To answer this question two
interview case studies were conducted with two
Melbourne, Australia based automotive manufacturers
who are advanced users of EDI in a Just-In-Time
replenishment environment.
• Technical feasibility: Do the hardware and software
components currently exist from which a practical and
robust system for 2-D bar code EDI can be built? This
question was investigated by building a prototype
system using Windows based PC tools.
• Practical feasibility: Would such a means of
transmitting EDI withstand the rigors of the practical
physical environment? This was investigated by
1060-3425/98 $10.00 (c) 1998 IEEE
testing the bar coded delivery dockets for their ability
to remain readable by machine after physical abuse.
It should be stressed that it is not being suggested that
high density bar code can completely replace EDI in the
replenishment cycle. Rather, we want to encourage the
view that an EDI system could use a number of media to
transmit machine readable information, the medium
being chosen to satisfy the particular operational
constraints applying each information requirement. Most
EDI enabled customers with a large number of vendors,
including the case study companies, use EDI to transmit
transaction sets other than the ASN. Vendor Schedules or
Forecasts are transmitted with a time scale of weeks to
months. Remittance Advice and Electronic Funds
Transfer transaction sets are transmitted with similar
frequency. For these, conventional EDI is perfectly
adequate. It is only at the operational level where tight
coordination between physical delivery and receipt of
information becomes crucial that an opportunity for bar
code based EDI opens up. Even Receipt Confirmation
messages, which are used by some companies, are
generally not time critical and so can be batched and sent
very efficiently using conventional EDI means.
The paper is organized as follows. A brief overview of
2-D bar coding and its applications and relationship to
EDI is given. Then the particular 2-D bar code
symbology selected for this study is described in detail. A
description of the three feasibility studies and their results
follows, and then conclusions are drawn.
where, if the whole data record could be encoded into the
bar code, the result would be desirable [8]. These
applications arise • When the data is essentially unchanging e.g. in
labelling historical samples of products.
• When reliance on a connection to a remote computer
is not desirable e.g. hazardous goods information in
fire fighting situations.
• When the data encoded is for once only use e.g.
shipment information.
For these applications, high density bar codes, which
use the vertical dimension of the symbol to carry extra
information, have recently been developed [2,3]. They
can hold up to 2 kilobytes with a single symbol and
unlimited data in multiple symbols. The concept is often
referred to as a "portable data file" [3].
Two main approaches have been used to extend the
data capacity and data density of bar codes; stacked
linear bar codes and matrix symbols [2,3,10,13]. The first
approach is to stack a number of conventional (linear) bar
code symbols of reduced height above each other. The
second approach is to divide the whole area of the symbol
into pixels and encode the information in the color (light
or dark) of the pixels. The latter matrix symbol systems
(figure 1) have generally been developed for special
applications and, while they can achieve high data
density, they require complex, and often proprietary,
equipment based on Charge Coupled Device (CCD)
technology and pattern recognition software.
2. Two Dimensional Bar Codes.
Conventional linear, or one dimensional bar codes
have been used to automate the identification of products
since about 1970 [11]. However their small data capacity
(around 30 characters) limits their usefulness for the
direct transmission of business data in machine readable
form. Within the standard Electronic Commerce model
[12] their main role is to allow a connection to be made
between physical shipments and Advanced Shipping
Notice information sent by electronic means ahead of the
physical shipment. A bar code printed on a delivery
docket or on a carton encodes a shipment number that
can be scanned at the receiving station and used to
retrieve the pre-loaded shipping data sent via EDI.
This application of linear bar codes is typical - the
data encoded in the bar code is a key field or "licence
plate" and additional information about the object marked
with the bar code is necessarily held off-line on a
database record to which the coded data is a key. This
arrangement is necessary and desirable for many
applications, such as point of sale systems, where the offline data is changeable. However, there are applications
Figure 1: Matrix bar codes: The Datacode and
Philips Dot Code. (After Pavlidis (1992). These
example do not necessarily represent legal codes).
By contrast, stacked bar codes can be read by
conventional laser scanners and the output signal can be
translated using conventional signal processing
techniques. Several stacked bar code symbologies have
had their symbology standards placed in the public
domain [2]. This is important for large scale Electronic
Commerce adoption because it means that a number of
independent scanner and printer manufacturers are being
encouraged to support these symbologies as standard. The
chief disadvantage of stacked bar codes is that reading is
rather sensitive to symbol orientation. This is not a great
1060-3425/98 $10.00 (c) 1998 IEEE
problem for the applications discussed here where
(compared to, say, a point of sale applications) the
orientation can easily be controlled.
Figure 2: A PDF417 stacked bar code symbol. (This
symbol encodes 1437 bytes of text data and is
reproduced approximately full size.)
through another scan path or they can manually enter the
data which is usually printed conventionally under the
machine readable symbol. Neither of these options is
available to the user of 2-D bar codes, firstly because
they lack the symbol redundancy in the vertical
dimension and, secondly, because it is impractical to
accurately enter several thousand characters of data
manually. Consequently, it is insufficient to just detect
read errors with 2D bar codes: they also require error
correction features. These are achieved using internal
coding redundancy and checksums (Reed Solomon error
correction routines [14]). PDF417 allows for 9 levels of
error correction. At level 0, none of the symbol data is
devoted to error correction and no symbol corruption is
tolerable. At level 8 approximately 50% of the symbol
data is dedicated to error correction check sums and the
symbol can still be completely decoded with
approximately 50% of the symbol corrupted.
3. PDF417
The most sophisticated stacked 2 dimensional bar code
symbology to date is PDF417 developed in 1989 by
Symbol Technologies, a significant US bar code
equipment manufacturer [3]. PDF417 appears set to
become the dominant 2 dimensional bar code symbology
for several reasons;
• It is readable by conventional laser scanning
equipment (most recently designed laser readers
support it) and printable on ink-jet printers.
• Its symbology encoding standard is public domain.
• Its use has been incorporated into the standards of a
number of important bodies in the U.S. including the
Automatic Identification Manufacturers trade body
AIM, the influential Automotive Industry Action
Group, AIAG, and the American National Standards
Institute, ANSI [10].
• It has a very high data capacity and density. Each
symbol can code up to 2725 bytes of data at a density
of about 300 - 500 bytes per square inch.
• It is made less sensitive to scan orientation than other
stacked bar codes through the use of multiple encoding
tables that allow partly read rows to be "stitched" back
together, in memory, from the partial data of several
consecutive scans.
• It not only has error detection but also error
correction that allows a corrupted symbol to still be
completely read.
• PDF417 can encode binary data as well as ASCII text
and can therefore encode sound and pictures.
Error correction is an important requirement of high
density bar codes. Most linear bar codes use check digits
and other features to detect an incorrect read. If a read is
unsuccessful the user can either re-scan the symbol
4. Two Dimensional Bar Code as a Medium
for Transmitting EDI
It is clear from the data capacity of PDF417 that 2-D
bar code could in principle be used as a medium for
transmitting structured business information in a machine
readable form from application to application, that is, as a
medium for EDI. However, the following three question
need to be asked of such a proposal • Does such a process solves any business problem that
conventional EDI does not?
• Does the equipment and software exist to build a cost
effective and robust system?
• Can bar codes printed on cardboard of paper survive
the rigours of practical use?
A research project was undertaken [10] aimed at
answering these three questions. The project consisted of
three investigations:
1. Interviews with materials management and systems
personal at Toyota Motor Corporation Australia and
Ford Australia, both major automotive manufacturers
in Melbourne, Australia, were conducted in mid 1996.
These case studies built on previous ones in the same
companies [12,15] in which the use of EDI and bar
coding in their material replenishment cycles was
extensively documented. These two companies differ
substantially in their approaches to materials
replenishment, the former using a "pull" [16]
discipline and the latter using a "push" discipline.
They also use EDI extensively and are actively
pursuing the Just-In-Time philosophy. The distinction
between push and pull approaches to JIT and their
relationship to EDI is not generally discussed in the
EDI literature, which generally implicitly assumes a
1060-3425/98 $10.00 (c) 1998 IEEE
push replenishment discipline [12]. It was therefore
considered important to investigate the use of bar code
EDI in both contexts because the information
requirements are quite distinct.
2. A prototype system was constructed using PC based
tools to enter, store, retrieve and print delivery dockets
together with the PDF417 encoded version of each,
and to recover and store the delivery docket database
record by scanning the PDF417 symbols on the printed
version of the delivery docket.
3. Tests were performed on the PDF417 symbols to
determine the ability of the medium to withstand
damage and distortion likely to occur in practical use,
and to determine what level of error correction should
be used in practical applications.
The results of the studies are outlined in the following
three sections.
5. The Business Opportunity for Bar Code
EDI
5.1 Ford Australia
The Ford Motor Company of Australia Limited (Ford
Australia), located near Melbourne, Australia, is a
subsidiary of the Ford Motor Company at Dearborn,
USA. Employing 7000 workers, Ford Australia is the
second biggest manufacturing enterprise in Australia.
Ford produces about 125,000 vehicle units per year. It
uses approximately 8000 local parts and 250 imported
parts and has 220 parts suppliers. It is the largest
consumer of locally manufactured parts and it is currently
running an inventory of about 10 days stock (although the
stock level of some components replenished by JIT is
smaller than this) [12,15].
Ford currently requires about 95% of its part suppliers
to send an ASN in advance of the physical shipment,
which is also accompanied by a printed delivery docket.
The ASN pre-loads the receiving system and a Receipts
List, printed from the ASN in the receiving area, is used
to check the physical shipment. The ASN is identified
with the physical shipment via the delivery truck
registration number, which is used as a reference in the
EDI ASN. Discussions with Ford materials management
staff revealed the following problems with their current
system;
• Use of the truck registration number effectively limits
the system to parts that are delivered no more that
once per day, and also caused problems when several
supplier's shipments were consolidated onto one truck.
• Because of Ford's leading position in the Australian
automotive industry and their increasing insistence on
JIT deliveries, many of Ford's suppliers are positioned
less that 10 minutes drive away from the Ford plant.
Ford currently polls their EDI Value Added Network
Service every 10 minutes to retrieve ASN data.
Therefore, especially with parts that are being called
up by JIT, there is no guarantee that the ASN arrives
before the physical shipments, causing delays and
congestion.
• The EDI ASN process is dependent on computers at
the supplier site, the Value Added Network Service
and at Ford all being operational. However, given the
computer dependent nature of the automotive industry
operations, this is generally the case.
The first problem can be solved by using a unique
identifier for the shipments, bar coded on the delivery
docket or cartons. The second problem can only be
solved within the existing framework by polling the
VANS more frequently - and expensive option at a cost
of $A0.50 upwards per call.
In the interview, Ford management considered the use
of a delivery docket with all data bar coded using high
density bar codes a feasible solution to all three
problems. Ideally the delivery docket should be produced
directly by scanning linear bar codes on the actual goods
shipped. They did, however, point out that the ASN
currently served to provide goods-in-transit information
that was useful in the advent of stock-outs. In further
discussion they agreed that this information could
probably be done without as more products went over to
JIT delivery.
In summary, managers at Ford, who were currently
considering the use of bar coding on delivery dockets and
who had also recently become aware of PDF417,
considered that two dimensional bar coded shipment
information would be a solution to problems that the
asynchrony of the EDI ASN information and the actual
shipments created, especially in a JIT delivery
environment.
5.2 Toyota Motor Company Australia
The Toyota Motor Company Australia Limited
(TMCA) is located in Melbourne, Australia and is a
subsidiary of Toyota Motor Corporation (TMC) of Japan.
The company produces around 100,000 vehicle units per
year. TMCA uses about 3000 locally sourced parts and
about 5300 imported parts. It has 120 independent local
parts suppliers, 19 TMCA owned local suppliers, two
overseas Toyota affiliate suppliers and two overseas nonToyota suppliers. It receives about 500 local deliveries a
day and as a result of an extensive Just-In-Time delivery
1060-3425/98 $10.00 (c) 1998 IEEE
initiative it currently carries about 4 hours stock of
locally supplied parts [12,15].
While TMCA uses EDI to transmit Material
Requirements Forecasts to almost all parts suppliers it has
made a deliberate decision not to use EDI at the
operational level. In keeping with the Toyota Production
Systems principles [17] which the company has
rigorously implemented, TMCA uses a "pull" [16]
discipline for replenishments with local suppliers. They
use the Kanban system, popularized by their parent
company, together with a bar coded turnaround delivery
docket. Kanban is a visual pull replenishment control
system that makes use of cards ("Kanbans") which travel
with parts at all times [18]. If a Kanban becomes freed by
the consumption of goods at the production line it
becomes both a signal and an authority to replenish that
item in the quantity with which each Kanban is
associated.
Local parts are delivered directly to the production
line where they are used. As Kanbans are released by
consumption of the parts at the production line, they are
delivered to a Kanban sorting area where they are sorted
electro-mechanically into vendor part number sequence,
using (linear) bar coded data on the Kanban. The sorting
system also produces a delivery docket with a bar coded
delivery number, on behalf of the supplier, and transmits
the expected delivery records to the receiving system.
The Kanbans and the related delivery dockets are picked
up by the vendor's carrier upon the next delivery. Each
vendor delivers parts at least twice a day. The transport
driver must arrive during a pre-assigned delivery time
window, and drop off the present delivery of parts
together with the associated Kanbans and delivery
docket. The delivery docket is scanned by receiving staff
with a bar code reader to recall the expected receipt
information and checked against the goods and the
Kanbans. The parts are then taken to the production line
with their Kanbans to complete the replenishment cycle.
While this system elegantly satisfies Toyota's
information needs within a pull replenishment
framework, it suffers two disadvantages which were
recognized and discussed by the interviewees at Toyota.
• Since the bar code on the Delivery Docket is of the
"licence plate" type, this bar code cannot be used by
the supplier to access data on the delivery docket. It
only serves as a turnaround key to data on TMCA's
systems. Toyota had rejected the idea of sending JIT
call-up transactions sets by EDI to the suppliers on the
grounds that it was not necessary using the Kanban
pull systems and also, with 500 or more transactions
per day, prohibitively expensive. Thus the suppliers do
not obtain machine readable information on call-ups
that can be used to update their own systems.
• A secondary result of the previous problem is that
Toyota receives invoices from suppliers which are
based on data not ultimately derived from Toyota's
own data, as they would be in the conventional "push"
EDI approach. (At the time of the case study, Toyota
was in the process of implementing Evaluated
Receipts System [19] but many suppliers still sent
manual invoices). This leads to discrepancies that must
be resolved by Accounts Payable.
The company that produced the Kanban sorting system
used by Toyota had recently suggested bar coding the
delivery dockets using two dimensional bar codes (of a
proprietary matrix symbol type). The production
management staff interviewed believed that using high
density bar coding to transmit the requirements
information in publicly readable form would solve these
problems and also be in keeping with trends in the
industry for sharing information down the supply chain.
Toyota had been criticized by suppliers in the past in this
regard [15].
To summarize this section, both Ford and Toyota saw
distinct advantages in using high density bar codes as a
means of transmitting shipping information. Within
Ford's push replenishment systems it would solve
problems arising from the asynchronicity and high cost of
the conventional EDI approach. These are the
motivations for bar code EDI usually cited in the
literature [5,7]. In addition, discussions with Toyota
revealed an entirely different opportunity of bar code EDI
which was to send shipping information cheaply in the
opposite direction, from customer to supplier. This
opposite flow direction of information is characteristic of
the difference between push and pull replenishment
disciplines and it is interesting to note that the challenge
of EDI in pull JIT approaches are seldom considered in
the EDI literature [12]. For Toyota bar code EDI
potentially provides a means of sharing information in a
machine readable form with vendors at minimal cost, and
some advantage, to Toyota.
6. Technical Feasibility of Bar Code EDI.
In order to show that the hardware and software exist
to create cost effective and robust bar code EDI systems,
a prototype system was built using PC windows based
tools. This required the selection of the following
development components.
• Bar code scanner. At the time of evaluating the
hardware options (early 1996) only two scanners
supporting PDF417 were available in Australia. The
LS 4800 from Symbol Technologies, which was
selected, is a conventional laser scanner and supports
all commonly used linear bar code symbologies as
1060-3425/98 $10.00 (c) 1998 IEEE
well as PDF417. It has an integral decoder whose
ASCII data output string can be sent directly to the PC
keyboard buffer using a keyboard wedge. When the
scanner detects the start and stop patterns
characteristic of PDF417 in alters the scan pattern
from linear to raster scan. It can fully read a PDF417
symbol in about 1 - 3 seconds. This unit costs about
$A2000. The other option was the Intermec J7010
Hand Held Imager which reads linear, stacked and
matrix symbols using CCD camera technology but was
almost twice the price of the LS 4800.
• Bar code printing software. There are basically two
types of bar code printing packages on the market;
those that allow the user to layout a complete bar code
label and retrieve data for the label from various
databases, and those that create a bar code as a picture
object for use with other windows programs via
Dynamic Data Exchange, DDE. The later type was
most appropriate to this application and B-Coder
(produced by TAL Industries, Philidelphia, PA.) was
chosen. It costs about $A500 and supports all major
linear symbologies and PDF417.
• Printer. PDF417 can be printed by any 300 DPI or
better printer. A NEC Silentwriter Laser printer was
used.
• Database and development environment. Microsoft
Access Version 2.0 was used in this project because of
its support of DDE, its relatively simple use and its
support of picture object types for data base fields.
indicator in the encoded data. As the level of error
correction, and thus the capacity of the bar codes, was
user selected, the overflow logic for bar code creation
had to take account of this level setting using a lookup
table of bar code capacity.
6.1 Delivery Docket Entry Program.
7. The Practicality of Bar Code as a Medium
for EDI
A program was developed that allowed a typical
delivery docket to be entered, stored on a database,
retrieved and printed. The user interface incorporated
standard Microsoft navigation metaphors. As delivery
docket information from the screen buffer was used to
create or update the data base records the data was sent to
the B-coder program in background, using DDE, and the
bar codes were returned as windows metafile pictures for
storage with the delivery docket.
The delivery docket had a fixed header and multiple
line items. The field sizes and layout were derived form
those used by Ford and Toyota and other examples [20].
While both Ford and Toyota required suppliers to send a
single page delivery docket which could easily be
encoded in a single PDF417 symbol, it was thought that,
in the interests of generality and to fully test the bar code
EDI concept, the program should handle delivery dockets
with unlimited line items requiring more that one
PDF417 symbol. When the delivery docket is printed, the
bar codes appear on the last page of the delivery docket
and incorporate a bar code counter and end of file
6.2 Delivery Docket Reading Program
A second program was developed with very similar
user interface and database design to receive and store
shipping information scanned from the bar coded paper
delivery dockets. Thus the contents of the paper delivery
docket could be recovered and scrolled though by the
receiving clerk and actual received quantities could be
entered before updating the database. The main technical
issue was to allow the user to scan the entire delivery
docket, which could have multiple bar codes, with
minimum interaction with the keyboard. The program
can detect out-of-order or incomplete scanning of the bar
codes and display suitable messages, but if the sequence
of scans is correct and complete, no interaction via the
key board is needed.
The prototype development demonstrated that the
tools do exist and interface with each other sufficiently to
make bar code EDI practical on a PC based platform. The
availability of the same tools for mini or mainframe
environments was not investigated, but down loading
data to a PC front end seems a reasonable architecture
anyway.
A number of tests were conducted on the delivery
dockets produced by the program described above to test
to resilience of the systems to physical abuse of the
documents, and also to determine the level of error
correction the user should select given that this requires a
trade-off between tolerance of abuse and data capacity of
the symbols. The abuse tests included • Drenching the paper to simulate rain damage
• Marking the paper with footprints
• Controlled obliteration of a known portion of the
symbols to simulate damage such a staining with ink
blobs
• Crumpling up
• Tearing and taping back together
• Faxing the delivery docket
The detailed test can be found in [10]. It was found
that the PDF417 bar codes were extremely tolerant to
staining and obliteration. At the highest error correction
levels a large amount (about 35%) of the symbol could be
1060-3425/98 $10.00 (c) 1998 IEEE
obliterated and the message still recovered exactly. (Note
that unless the entire message can be reconstructed the
decoder will not signal a good read and transmit data).
This is substantially in accord with the technical claims
of the symbology developers [3]. At the highest error
correction rates the symbol could also withstand tearing
and taping provided that the misalignment was not
greater than about 1-2mm. Larger tear misalignments,
especially in the vertical direction, caused readability
problems. Since using the highest level of error
correction merely halves the capacity of the bar code, in
an environment where few line items are used the highest
error correction can probably be used without causing
more than one bar code to be needed.
However, the readability of PDF417 symbols is greatly
compromised by crumpling and by faxing. Both a
delivery docket crumpled up into a ball and flattened (as
in accidental discarding) and one that had been faxed to
and printed on an ink-jet plain paper fax machine could
not be read at the highest error correction level. The
former is not operationally important but the later could
pose problems in some situations such as resolving
disputes quickly. Presumably, the resolution of the fax
printer is insufficient, and it is speculated that the
crumpling problem arises because the signal processor in
the bar code reader expects to find a spatially regular
clock signal (usually detected by a phase locked loop
[21]) in the bar code pattern, which is destroyed when
portions of the page are seen at slightly different angles.
The susceptibility to wide tears probable has a similar
explanation. At present it is not clear to what extent to
vulnerability to crumpling and tearing is attributable to
the reader design or to the bar code symbology design.
The extent of damage that causes a read failure for
each of the kinds of damage are rather unlikely to occur
in practice and the overall conclusion of these tests was
that PDF417 was a practical and reliable means of
transmitting data. If very high levels of reliability are
required various options for a backup system might be
considered. The conventionally printed delivery docket
itself acts as a backup and generally has a similar layout
to the receiving application screen making manual entry
feasible in this case. Conventional bar coding of products
would facilitate this data entry also. When the bar code
EDI system replaces a conventional EDI system, as it
would at Ford, the existing system in some modified form
could be used as a backup.
8. But is it EDI?
Readers may question whether the proposal presented
here really constitutes EDI or is just an enhancement of
traditional (one dimensional) bar code applications.
Indeed, the idea of "paper based EDI" may to many
appear to be an oxymoron.
From the purely definitional point of view, most
authors [1,13,22] require genuine EDI to have the
following features:
1. The message consist of one or more business
documents
2. The transmission is application to application
3. The data is structured
4. The data structuring is standardised
5. The transmission medium is digital and electronic
(normally speed-of-light)
The 2D bar code method described here clearly
satisfies the first three conditions since it is structured
delivery docket data that is transmitted and the machine
readable nature of bar code allows the possibility of
application to application transmission. Also, the whole
document is encoded in the bar codes rather that simply a
retrieval key as in conventional bar code applications.
Table 1. Typical layered approach to message
standards for conventional EDI and 2D bar code EDI
Layer
Message
formatting
layer
Traditional EDI
EDI standards X.12, EDIFACT
Message
handling
layer
Enveloping
standards - X400
Addressing
standards - X500
Packet switching
standards X.25
Telephone lines
Networks
Message
transport
layer
Physical
layer
2D Bar code
EDI standards X.12, EDIFACT
Application
specific
formats
N/A
PDF417
symbology
standards
Paper
The fourth point needs clarification since EDI
transmissions generally employ several layers of
standardisation. Table 1 shows the typical layed approach
to message standardisation for conventional EDI
conducted over a packet switching network using modern
transmission standards. From the standardisation point of
view, it will be seen that our proposal is to use 2D bar
code as the transport layer. The PDF417 symbology
standard is public domain and so this layers can be seen
to be formatted in a standardised way. Even the
continuation of data over multiple symbols is covered by
a later standard called "Macro PDF417" [3]. Due to the
point to point nature of the paper based transmission,
addressing and enveloping are not significant issues. The
EDI message formatting layer is not affected. While the
1060-3425/98 $10.00 (c) 1998 IEEE
messages encoded in the present experiments were not
formatted using EDI standards, there are clear advantages
for system integration in doing this in a practical system.
This leaves only the medium of transmission
controversial. It is normally assumed that this will be a
conventional speed-of-light telecommunication medium
since these are normally the cheapest and fastest means
of transmitting digital data. However, if we are prepared
to put business requirements ahead of definitional purity,
we can find examples, especially in the operational
domain, where neither the low cost nor speed of
conventional media are of overriding importance. In the
present context of delivery information in JIT
environments, the high cost of frequent telephone polling
of the VANS mitigates the low bulk data transmission
cost of conventional media and bar code printing is
highly competitive. Although there are some advantages
to the receiver of early receipt of the ASN, the speed of
the message transmission is not as important from a
business point of view as synchronisation of messages
with the physical delivery. One could probably find other
operational situations where magnetic media such as
diskettes are more suitable than telephone lines and,
provided that the other defining characteristics of EDI are
present, there seems to no reason, other than doctrinal
purity, not to consider them as suitable media.
[2] T. Pavlidis, J. Swatz, and Y. Wang, “Information Encoding
with Two-Dimensional Bar Codes,” IEEE Computer Magazine,
Vol. 25, No. 6, pp. 18-28, 1992.
9. Conclusion
[10] A. K. C. Yap (1997). The Feasibility of Using Two
Dimensional Bar Codes as a Medium for Electronic Data
Interchange, Unpublished Masters Thesis. Monash University,
Clayton
This paper has reported research designed to test the
feasibility of using two dimensional bar code technology
(specifically PDF417) as a means of delivering shipping
information, in a machine readable form, from the point
of view of organizational feasibility, technical feasibility
and practical feasibility. Case studies indicated that there
was a clear business advantage in using the technology
both in push and pull type replenishment systems. The
technical feasibility was demonstrated by the production
of a practical and robust demonstration system using
inexpensive hardware and PC based software tools.
Finally the method of delivery appears to be sufficiently
robust to physical abuse to be practical. PDF417 appears
to have matured as a standard to the extent where there is
probably no significant danger in committing to this
symbology, and we can expect reports of application of it
in Electronic Commerce contexts to increase in the near
future.
[3] S. Itkin and J. Martell, A PDF417 Primer. Bohemia, NY:
Symbol Technologies, 1992.
[4] T. Seidman, “BC Labels Turn High-Tech,” Distribution,
No. January, pp. 83-84, 1993.
[5] M. David, “2-D or not 2-D Becomes Industry Controversy,”
Automatic I.D. News, No. November, pp. 6, 1995.
[6] J. Piatek, “Automative Industry Recommend 2-D
Standards,” Automatic I.D. News, No. August, pp. 54-56, 1994.
[7] B. McCracken and M. Worthington, “2D Codes Provide
Larger Data Capacity for Automatic Identification
Applications,” I&CS, No. December, pp. 57-64, 1994.
[8] B. McCullouck, “2D Bar-Code Applications in
Construction,” Journal of Construction Engineering and
Management, Vol. 120, No. 4, pp. 739-751, 1994.
[9] J. Martel, “PDF417 Aids EDI in Transportation,” EDI
World, No. December, 1992.
[11] C. K. Harmon and R. Adams, Reading Between the Lines:
An Introduction to Bar Code Technology: Helmers Publishing
Inc., 1990.
[12] R. B. Johnston and R. P. W. Lee, “The Role of Electronic
Commerce Technologies in Just-In-Time Replenishment,” Proc
of Hawaii International Conference on Systems Science, pp.
439-448, Hawaii, 1997.
[13] R. B. Johnston, Electronic Commerce: An Operational
View. Melbourne: Department of Business Systems, 1997.
[14] A. E. Blahut, Theory and Practice of Error Control Codes.
Reading, MA: Addison-Wesley, 1984.
References
[15] R. P. W. Lee (1996). Rationale for Adopting Electronic
Commerce in the Australian Automotive Industry, Unpublished
Masters Thesis. Monash University, Melbourne, Australia
[1] M. A. Emmelhainz, Electronic Data Interchange: A Total
Management View. New York: Van Nostrand, 1990.
[16] A. DeToni, M. Caputo, and A. Vinelli, “Production
Management Techniques: Push-Pull Classification and
1060-3425/98 $10.00 (c) 1998 IEEE
Application Conditions,” International Journal of Operations
and Production Management, Vol. 8, No. 2, pp. 35-51, 1988.
[17] Y. Monden, Toyota Production System. Norcross: Institute
of Industrial Engineers, 1983.
[18] R. J. Schonberger, “The Kanban System,” in Just-In-Time
Manufacture, vol. 13, International Trends in Manufacturing
Technology, C. A. Voss, Ed. London: IFS Ltd. UK, 1987, pp.
59-71.
[19] M. Hammer, “Reengineering Work: Don't Automate,
Obliterate,” Harvard Business Review, Vol. 68, No. 4, pp. 104112, 1990.
[20] A. L. Eliason, Online Business Computer Applications.
New York: Macmillan, 1991.
[21] T. Pavlidis, J. Swartz, and Y. Wang, “Fundamentals of Bar
Code Information Theory,” IEEE Computer Magazine, Vol. 23,
No. 4, pp. 74-86, 1990.
[22] V. A. Leyland, Electronic Data Interchange: A
Management View. London: Pentice Hall, 1993.
1060-3425/98 $10.00 (c) 1998 IEEE