Complete EDI Material

EDI BASIS

Electronic Data Interchange, or EDI, is the computer-to-computer exchange between two companies of standard business

documents in electronic format. There are two key elements in basic EDI; First, electronic documents replace paper

documents. Second, the exchange of documents takes place in a standardised format. Using these two basic concepts, any

business can enter the world of EDI and begin taking advantage of the speed and economy of electronic commerce. This site

will help you figure out the options available to you and what steps you need to take to implement EDI.

WHAT IS EDI.?

Electronic Data Interchange, or EDI, is not a new technology and in fact has been around since the late 1960s. While EDI has

benefited enormously from advances in technology, eg the introduction of the internet, EDI is not technology dependant. There

are preferred ways to implement EDI in a company, but there are many approaches to choose from. The approach chosen

should be driven by a company’s business needs, not a particular implementation or technology.

In its simplest form, EDI is the computer to computer exchange, between two companies, of standard business documents in

electronic format. There are two key elements in basic EDI. First, electronic documents replace paper based ones. Second, the

exchange of documents takes place in a standardised format. Using these two basic concepts, any business can enter the

world of EDI and begin taking advantage of the speed and economy of electronic commerce, or e-Commerce.

In today’s fast-paced business world, your business may already be moving in this direction, customers or suppliers may

already be approaching you to begin trading information electronically. For the newcomer to EDI, it may seem a very confusing

subject area.

So what is a document? A document is any form of communication, usually paper based, sent between two companies,

examples include:

Purchase Orders

Invoices

Shipping Notices

Export / Import Notices

Carrier to carrier waybills

Funds transfer

Design specifications

Health insurance claims

EDI is essentially a data processing concept which is independent of communication protocols or transmission media. EDI is a

logical outgrowth of the standard computerisation going on within companies over the last few decades. With EDI, the type of

electronic communication between departments within a company can now easily be extended to reach out to other companies

or trading partners.

EDI replaces human readable, paper or electronic based documents with machine readable, electronically coded documents.

With EDI, the sending computer creates the message and the receiving computer interprets the message without any human

involvement at all.

Before learning about what makes up an EDI system and how to implement one, it is important to look at an example that

highlights some of the key differences between traditional paper document transactions and EDI. One of the first places where

many companies implement EDI is in the exchange of a purchase order, (PO). In the traditional method of processing a

purchase order, a buyer or purchasing agent will go through a fairly standard procedure to create a purchase order, consisting

of the following steps:

A buyer reviews data from an inventory or planning system

The buyer enters data into a screen in the purchasing system to create a PO

The buyer waits for the PO to be printed, usually on a special form

After the PO is printed, the buyer mails it to the vendor

The vendor receives the PO and posts it in their order entry system

The buyer calls the vendor periodically to determine if the PO has been received and processed

When you add up the internal processing time required by the sender and receiver, and then add a couple of days in the mail,

this process normally takes between three and five days. This assumes first that both the sender and receiver handled the PO

quickly and that at every point along the way there were no errors in transcribing data from a form to a system.

Now consider the same document exchange when a company places its purchase orders electronically using EDI:

The buyer reviews the data and creates the PO, but does not print it

EDI software creates an electronic version of the PO and transmits it automatically to the sender within minutes

The vendor’s order entry system receives the PO and updates the system immediately upon receipt

What took up to five days with paper and the postal system has just taken less than one hour. By eliminating the paper

handling from most of the stages of the process, EDI has the potential to transform a traditional paper based process to look

like this:

The major benefits of implementing EDI within your business are discussed in more detail in the ‘Benefits of EDI’ section of this

Microsite but in summary EDI can help improve speed and accuracy of transactions, reduce costs and it provides improved

flexibility when interacting on a daily basis with your trading partners or customers. To find out how to implement an EDI

system, please choose the ‘Implementing EDI’ button from the menu above.

TYPES OF EDI

There are many different ways in which an EDI environment can be implemented across a trading partner community. Whether

you are looking to implement EDI for the first time or expand your EDI infrastructure to support trading partners in other regions

around the world, there are a multitude of EDI tools and connectivity options available to suit your technical capabilities and

budget constraints.

Once a company has automated a number of business documents such as Purchase Orders or Invoices, you may wish to

integrate your EDI environment to other business systems. For example you may wish to populate an EDI document by

extracting information from an accounting system or allow externally sourced information to enter an ERP system. Either way

you will need to ensure that you have the correct technology and skills in place to achieve this.

Implementing EDI for the first time can appear to be a daunting challenge for many companies however there are a number of

ways in which EDI can be implemented across a business. For companies that have internal resources to manage an EDI

infrastructure, EDI can be deployed by installing software which would then allow EDI information to be sent via a Value Added

Network (VAN) or a point to point connection. For those companies that have no internal EDI resources then outsourcing the

management of an EDI infrastructure or using web based EDI tools could be the preferred route to take.

This section of EDI Basics highlights some of the ways in which EDI tools can be deployed across a business. Please select

one of the menu options to the left to find out more.

Types of EDI

EDI via VAN

EDI via VPN

EDI via P2P

EDI Software

EDI Outsourcing

Web EDI

Mobile EDI

EDI via AS2

EDI via VAN

Value Added Networks, VANs, are private networks where EDI related information can be exchanged between companies

securely. Trading partners will typically require an account with an EDI VAN provider which simply acts as an electronic mail

box to both send and receive electronic documents. The sender connects with the VAN and sends its EDI transactions to the

recipient's mailbox where they are stored. The sender then disconnects from the service. Then, at some point that is

convenient, the recipient can connect to the network and receive those transactions from their mailbox. Most VANs offer an

alerting service which informs the sender when messages have been sent successfully and informs the recipients when a new

EDI message has arrived in their mailbox.

In addition to looking after the transmission and receiving of EDI messages, VAN providers offer a number of other value

added services including, managing outsourced EDI, community or trading partner enablement and other services which allow

companies to integrate back office systems seamlessly. VANs have traditionally been favoured for EDI transmission because

of their security and their additional features such as

Offer a mailbox service; trading partners dial into a VAN via a network access point and use a file transfer protocol to send

EDI messages to the VAN. The VAN automatically routes the message to the receiving partner's mailbox and the

trading partner dials into the VAN and retrieves the message

Act as trusted third parties by inspecting and authenticating the EDI messages and verifying the identity of trading partners

depositing and accessing them

Take responsibility for providing an audit trail of all EDI transactions and for tracking / recording the trail of a message

Send email notifications to partners that EDI messages have been deposited in their mailboxes

Offer an extensive range of other services, for example, data backup, recovery, document mapping and other outsourced

services

EDI via VPN

A Virtual Private Network (VPN) utilises public telecommunications networks to conduct private data communications. Most

VPN implementations use the internet as the public infrastructure and a variety of specialised protocols to support private

communications through the internet. VPNs tend to follow a client/server approach whereby VPN clients authenticate users,

encrypt data and otherwise manage sessions with VPN servers utilising a technique called tunnelling. The session between

two users can only be conducted once the tunnel has been opened up between the two users concerned.

VPN Clients and Servers are typically used in the following three scenarios-

To support remote access to an intranet

To support connections between multiple intranets within the same organisation

To join networks between two organisations, forming an extranet

The main benefit of a VPN is the lower cost needed to support this technology compared to alternatives like traditional leased

lines or remote access servers. VPN users typically interact with simple graphical client programs. These applications support

creating tunnels, setting configuration parameters, and connecting to and disconnecting from the VPN server. VPN solutions

utilize several different network protocols including PPTP, L2TP, IPsec, and SOCKS. VPN servers can also connect directly to

other VPN servers. A VPN server-to-server connection extends the intranet or extranet to span multiple networks.

From an EDI perspective VPN related connections are ideal for smaller size companies who wish to connect to trading

partners via a single internet connection. Many companies have invested in a single internet connection that is used by all of

the PCs on a network. In the case of GXS, VPN software can be installed on a single PC that is connected directly to the

internet, or on a PC that is connected to a company network of a network or PCs can be connected via VPN software that is

placed on the firewall of the company. These are illustrated below, connected to GXS Trading Grid Messaging Service.

EDI via P2P

Point-to-Point EDI communications have been used by companies for many years. Quite often a company will use Point-to-

Point communications as an alternative to the traditional Value Added Network provider. In fact before the internet, many

companies would establish their own private networks using standard communication protocols over a telephone line.

One of the earliest and most successful adopters of the Point-to-Point type EDI solution was Walmart. Vendors would dial into

Walmart’s SNA network via a bisynchronous modem. As and when the vendor had something to send, the call is made and the

data is then transmitted. When dial-up links are used the senders will typically batch up their transactions and at a certain point

make the connection and send through the entire batch of data. The dial up approach is cheaper when the amount of data is

low and infrequent. An expensive leased line can be more cost effective if the amount of transactions is high and fairly constant

throughout the day. Point to Point connections do not provide the transaction visibility, reporting or traceability that a Value

Added Network provider can offer.

Establishing point to point connections use to be a labour intensive process for companies such as Walmart. They had to take

on the responsibility of on-boarding their suppliers and ensuring they had the correct communications infrastructure, eg high

speed modems, to be able to send information through to them.

Since the introduction of the internet, Walmart decided to retain their own point to point connection with suppliers, but this time

using the AS2 communication protocol across the internet. Walmart has helped drive the adoption of the AS2 communication

protocol, especially across the retail industry. For companies that do not have the resources to onboard suppliers then a Value

Added Network provider such as GXS can offer an outsourced AS2 service. This outsourced service will still be a point to point

connection but GXS would do all the work behind the scenes to ensure that a company such as Walmart received the

information across an AS2 connection. Further information can be found in the EDI via AS2 section shown in the left hand

menu.

EDI SOFTWARE

For companies who prefer to retain control of their EDI environment, rather than outsourcing the management of their EDI

infrastructure or using hosted EDI solutions, implementing EDI software on a network of PCs behind a company firewall will be

the preferred option to take.

Implementing EDI software assumes that a company has the correct internal resources to be able to implement the EDI

software and maintain on an ongoing basis. Implementing EDI software will require resources that can understand how to map

between different document types, how to on board or connect to trading partners and possibly provide integration to other

business applications such as accounting packages or ERP software.

Once the software has been installed then the IT resources will be required to maintain the EDI software on an ongoing basis,

this will include upgrading the software environment as and when required.

Many companies, especially smaller sized businesses, may not have the internal IT resources to manage their own EDI

environment and for this reason they will choose to use hosted or Software as a Service based EDI offerings instead.

EDI OUTSOURCING

Implementing and managing an EDI platform can be a daunting challenge for many companies. Irrespective of whether a

company is small or large, managing an EDI infrastructure requires access to resources with a broad range of different skill

sets. For example for most EDI implementations you will need access to resources who can develop maps, on-board trading

partners around the world or simply implement new communication protocols. Many of today’s companies are even looking to

integrate to back office business systems such as Enterprise Resource Planning (ERP) platforms. Many of today’s companies

simply do not have the internal resources to undertake this type of work.

EDI outsourcing provides a way for a company to use external resources to manage an EDI environment on a day to day

basis. A company could choose to outsource part of an EDI process such as on-boarding a group of trading partners or they

could decide to outsource the management of the entire EDI process. Either way, EDI outsourcing provides an efficient way to

reduce costs and allow the company to focus on manufacturing goods or delivering business services rather than have the day

to day worry of managing a B2B platform. EDI outsourcing allows resources to be applied to an EDI project on a flexible and

scalable basis so as a project grows so the EDI implementation and infrastructure management resource can grow in parallel.

EDI outsourcing allows companies to utilise skilled people, implement best practice processes and deploy the latest

technologies across a business.

People - Skilled people with both technical and business expertise who can support and deliver a B2B program that

meets current and future business objectives

Processes - Best-practice processes for implementing or extending the use of B2B e-commerce in an organisation,

managing a B2B program on an ongoing basis, and quickly and easily bringing new trading partners onto a B2B

network

Technology - The comprehensive infrastructure needed to exchange EDI transactions with partners, translate

business documents between any of the many EDI e-commerce standards now in use, and provide reporting and

visibility into B2B processes and networks

For further information about EDI Outsourcing download a white paper here or alternatively visit our Managed Services

Microsite.

WEB EDI

Web EDI, or conducting EDI through an internet web browser, is the simplest form of EDI that can be undertaken by two

companies. Internet web browsers are available on nearly every PC and so long as a company has access to the internet then

they can trade electronically with potentially any company in the world.

Web EDI works by replicating the contents of a paper based document on to a web page. The web page or form will typically

contain a number of boxes where users can enter information and a company logo may be included on the form as well. Once

the relevant information has been entered to the form, the information is automatically converted into an EDI message and is

then sent securely via a number of popular communication protocols such as File Transfer Protocol Secure (FTPS), Hyper

Text Transport Protocol Secure (HTTPS) and AS2.

Rolling out a web EDI solution helps to ensure maximum participation from potentially all trading partners across a supply

chain. This is especially important when trying to work with suppliers located in countries with limited ICT or EDI skills, for

example China or India. Companies are not required to install any EDI software on their PCs and there are no concerns with

having to maintain a complex EDI environment on an ongoing basis.

Web EDI tools have seen significant adoption levels in emerging markets such as China and India where EDI implementation

and management skills are very scarce. Web EDI allows a company to interact with its suppliers in these regions without

having to worry about implementing a complex EDI infrastructure. The Internet, as with VAN providers, uses its own

communications protocols to ensure that EDI documents are transmitted securely. The most popular protocols are File

Transfer Protocol Secure (FTPS), Hyper Text Transport Protocol Secure (HTTPS), and AS2.

In its simplest form, web EDI allows small to medium-sized businesses to receive, turn around, create and manage electronic

documents using just a web browser. This service seamlessly transforms your data into EDI format and transmits it to your

trading partner. Simple pre-populated forms enable businesses to communicate and comply with their trading partners'

requirements using built-in business rules. Using a friendly web-based interface, EDI transactions can be received, edited and

sent as easily as an email. You will also be able to receive EDI documents and send EDI invoices and shipping documents

with no software to install. All you require is an Internet connection. WebEDI has the added advantages that it is accessible

anywhere in the world and you do not need a dedicated IT person to manage any software installation.

Even though VANs offer a very secure and reliable service to companies wishing to trade electronically, the Internet is making

EDI more available to all. This is especially important in the emerging markets where IT awareness and infrastructure are very

limited. WebEDI is traditionally based around the "hub and spoke'"model, with major trading partners or Application Service

Providers (ASPs) being the hubs and smaller partners being the spokes.

Hubs or ASPs implement EDI using email or virtual mailboxes

Trading partners can send EDI messages directly to a web-enabled EDI messaging site, via the hub. EDI messages are

simply sent using a web browser

Systems that are currently being developed will enable EDI messages to be displayed in a web browser and directed via

open standard XML, directly into the user's accounts system

WebEDI-based users can interact with VANs without incurring the costs of setting up a dedicated VAN connection

MOBILE EDI

EDI systems have been in use for over forty years and until recently users have needed access to either a private network

such as Value Added Network or the internet in order to send and receive EDI related business documents.

EDI infrastructures are complex and many software applications used across these networks were never designed with the

mobile user in mind. Would EDI users really want to use a mobile device for completing a purchase order or invoice whilst out

of the office or would they prefer to use a mobile device to check on the status of a delivery to a supplier, review the

performance of a logistics partner by way of a number of graphical charts or simply communicate with a trading partner

community in the same way that many of us use mobile phones to provide status updates to social networking sites such as

Facebook and Twitter.

In addition to identifying where mobile devices can be used across an EDI infrastructure, the other reason for limited adoption

of mobile EDI applications has really been down to the devices themselves. The quality and size of the screen of most devices

has been relatively poor until the Apple iPhone and RIM Blackberry devices were introduced on to the market. The Blackberry

remains the most popular mobile device of many corporate IT departments but the latest 3G version of Apple’s iPhone could

lead to an increased adoption of EDI/B2B applications for this platform.

In fact these mobile devices have transformed the way in which users interact with their enterprises whilst on the move and

some companies are just starting to launch applications to help mobilise their supply chains. Applications have already been

launched to allow the mobile enterprise user to get access to an ERP or CRM system on the move so why not have the option

of getting access to an EDI platform as well?

There is a growing industry for developing software applications or ‘apps’ for downloading on to these mobile devices and

Apple, as of 2010, certainly has the largest app store in the mobile device industry. It will only be a matter of time before you

can download a supply chain or EDI related app from a private or corporate app store. Each visitor to the corporate app store

would be able to install apps according to their role and function within the business.

Further information about the uses for mobile EDI applications will be added to this section of EDI Basics as it becomes

available.

EDI via AS2

Many people often refer to AS2 as a type of EDI, when in fact AS2 is actually a communication protocol used to exchange EDI

documents. In the retail sector, the use of AS2 has become almost synonymous with Walmart who insist that all their suppliers

around the world must communicate with them using AS2.

AS2 is one of the most popular methods for transporting data securely and reliably over the Internet. An implementation of AS2

essentially involves two computers-a client and server-communicating with each other over the Internet. AS2 creates an

envelope for a message which is then sent securely, via the use of digital certificates and encryption, over the Internet. The US

retailer Wal*mart is a good example of a company who uses AS2 on a point-to-point basis to communicate to each and every

one of its suppliers. Further information about AS2 is discussed in a white paper which can be found in the resource area of

this microsite.

For many companies, large or small, implementing an EDI system can be a long and complicated process. Larger companies

will have extensive IT resources who manage both the software applications and the hardware, e.g., computers and network,

which are used within the company. The larger company will also want to integrate their EDI system to back-office systems in

order to try and establish a seamless trading environment for its internal users and external trading partners. For the smaller

company, implementing EDI can appear to be a complex process, especially when all they want to do is exchange purchase

order information with their customers.

In order to allow the smaller companies to trade with their customers without the need to implement a dedicated EDI solution, it

is possible to use a hosted AS2 service offered by a VAN provider such as GXS. The diagram below illustrates the differences

between trying to implement AS2 yourself, shown on the left, and outsourcing your AS2 connection to an external vendor,

shown on the right.

The outsourced AS2 option hosted by GXS offers many advantages over implementing a dedicated service:

Suppliers comply with AS2 mandates without adding infrastructure, expense and expertise

Connect the way they prefer

NO AS2 software, hardware, firewalls, special skills, etc. needed

GXS does all the AS2 work

Exchange of AS2 set up information

Provide testing between your company and your AS2 trading partner

Access to a help desk to resolve issues

Real-time document exchange

Optional translation services

Often lower cost than implementing direct AS2 when considering the total cost of ownership and risk-avoidance

If your company decides to use an outsourced AS2 service from GXS, you will have access to trading partners around the

world. GXS has developed a global B2B infrastructure platform, Trading Grid®, which enables the real time flow of information

between companies regardless of technical capability, standards preferences, spoken language or geographic location.

By combining the security and best practices of traditional e-commerce networks with the agility and responsiveness of the

Internet, GXS Trading Grid offers significant speed and cost advantages over traditional, do-it-yourself B2B integration

solutions.

In addition to AS2, GXS offers an extensive range of EDI outsourcing services, data mapping and translation, infrastructure

management and community enablement. B2B outsourcing is becoming an important issue for many companies, especially to

help reduce costs, improve infrastructure management and improve overall business efficiency. For further information about

AS2 vist www.as2basics.co.uk.

BENEFITS OF EDI

Replacing paper documents with electronic ones will not necessarily require changing the way your company does business.

Replacing a paper based purchase order with an electronic one will provide several obvious benefits. It will also have an

impact on the way you order your supplies. It will mean replacing your current paper system with a very different way of doing

business.

Since changing the way your company conducts business is not a task you will undertake casually, you might wonder at this

point why you should upset processes and procedures that work well. In today’s global economy, every business faces

constant pressures to improve the quality of its products or service, while at the same time tightly controlling or reducing costs.

While IT has helped to automate or streamline internal processes, in many businesses the external process of exchanging

information with customers and suppliers still lag far behind the internal procedures. The need for speed and accuracy in these

external processes is becoming ever more critical.

NEED FOR SPEED

Speed, whether in the increased velocity of moving products from design to the market place, or in the rapid response of a

supplier to customer demands, is vital to success. Increased speed can benefit a business in several ways:

Shorten lead times for product enhancement or new product delivery. The market advantage of months or even weeks

can have a major impact on profitability.

Do more with less, Staff reductions, commonplace in many businesses, require that fewer people accomplish more

work. Handling exchange of data electronically may be critical to survival, giving employees the tools to be more

productive while reducing overhead.

Reduced delivery cycle times mean reduced lead times and lowered inventory carrying costs.

NEED FOR ACCURACY

Accuracy in the exchange of business documents is always important. The traditional paper document exchange requires

information transfer through transcription or data entry and any such information transfer will introduce errors into the process.

Increases in speed are often difficult to attain because of the need to avoid transcription errors. As speed increases, so does

the likelihood of introducing errors into the process. Advantages gained by increases in speed may be easily offset by the high

cost of error correction.

There are several obvious cost savings that will result from increased accuracy of information transferred to suppliers and

customers.

Increased customer satisfaction

Reduced overhead required either to detect or to reprocess erroneous documents

Reduced costs to expedite goods or services that are late or lost

ADVANTAGES OF EDI

EDI is the tool that can enable businesses to achieve dramatic increases in speed, while they realise at the same time the

benefits of improved accuracy in the transfer of critical information. Documents transferred directly from computer to computer

move in orders of magnitude more quickly than paper documents, with no loss of accuracy.

As paper documents have been replaced with electronic transactions, it is easy to maintain electronic logs or audit trails of

document handling activity. From this, businesses gain a substantial increase in the ability to track status and measure

performance throughout the entire process.

Let’s take a closer look at some of the benefits of the example mentioned previously regarding POs to highlight the advantages

of the electronic process over the traditional paper process.

The process takes seconds or minutes instead of days

The PO goes from the buyer’s computer through a network to the vendor’s computer with no human intervention at all.

There is no need to copy of transcribe the PO upon receipt, eliminating the possibility of data entry error

The electronic document has not been handled by any mailroom staff, postal or delivery service or data entry staff. It

will not wait in any in-basket waiting for collection and it won’t have to wait while staff are on the phone

The buyer receives rapid confirmation of PO receipt

These facts can translate directly into cost savings resulting from reduced cycle times, reduced overheads and improved

accuracy. In today’s business environment, companies cannot afford to ignore these benefits.

EDI Provides Speed

Using EDI will provide specific and measurable increases in the speed of document transfer, with accompanying decreases in

document cycle time.

Sending an electronic message across the country or around the world requires only seconds or minutes as opposed

to days. Such transmissions typically occur at over 1000 characters per second

Data is available immediately for use in internal applications. Data, once received, needs only to be translated

internally into the specific format required by the receiver’s application software, and it is immediately ready for use

Reduced business cycle times provide a competitive edge in any business

EDI Improves Accuracy

Electronic transfer of data eliminates the need for copying data from one paper document to another, or for keying the data into

a business application screen. Every time data is transferred, there is opportunity for error to be introduced to the process. In

the typical manual purchase order, a person enters or copies information from the paper form at least once. With EDI,

improved accuracy is obtained in several different ways.

Electronic data is usually derived from a database, where data has been subject to prior validation

Electronic documents are transferred accurately regardless of size. If transmission of a large document is not

successful, users can invoke re-transmission procedures rapidly

Even if several different parties process the electronic document, with each party adding data to the existing

document, none has the ability to alter previously entered information

EDI Reduces Costs

Your company may obtain a variety of cost reductions as a result of implementing EDI. These reductions can include both cost

savings and cost avoidance. These points summarise just a few of the more general types of savings you can expect:

Reduction of overhead costs, eliminating human handling in such areas as mailroom sorting and circulation, clerical

document preparation and data entry. Upon implementing EDI, costs for paper, envelopes and mailing materials

decrease as well as those for telephone and courier services used to support transmission of orders and paper

documents. Additionally storage space for paper and supplies is freed thus reducing costs still further

Substantial cost savings can result from reduced error rates, these savings include those such as labour costs

normally used to search for errors, and in lowered expediting costs

Reduction of inventory costs through shortening order processing and delivery cycles, and generally lowering inventory

levels. As goods can be delivered more quickly the buying company need not order new products as often and can

lower or eliminate its level of inventory safety stock. Lowered inventory levels also results in corresponding reductions

in carrying costs. Inventory costs can, in some businesses, account for as much as 90 percent of total product cost, so

even modest reductions in this area can result in dramatic savings

If a company can receive an electronic invoice in a timely manner, the buyer can take advantage of discount terms,

effectively paying less for the product. The seller, in turn, can receive payments sooner, improving its cash position

and allowing it to pay less for its supplies by taking advantage of discount terms

EDI Improves Operational Efficiency

In addition to improving speed, cost and accuracy, EDI can impact the business in a number of other ways, improving

operational efficiencies and tightening relationships with your trading community.

Improved Trading Partner Relationships. In order to successfully transmit, interpret and process transmissions

automatically, much trading partner co-operation and analysis are required. The party that originates the data depends

on the sender to provide accurate and timely data. Thus it is important for both parties to agree on business

procedures, data requirements, and usage, communication methods, operational windows and testing schedules prior

to implementing EDI. By receiving more accurate and complete data and by eliminating keyed entry errors on the

receiving end, suppliers can ensure accurate and timely shipments to their customers while reducing the expenses of

returned shipments of incorrect products. The higher level of customer service tends to attract new customers and

increase the volume of existing customer orders

Increasing awareness of data throughout the business cycle. Significant use of EDI gives an organisation visibility

outside of its ‘four walls’. Although EDI is not a reporting tool, a thorough implementation of EDI makes everyone

aware of abilities to monitor the customer’s customer, track vendor or transportation carrier performance, better

understand product availability from vendors and distinguish among activities by distributors and customers

Improved planning and processing. In an electronic environment, rapid receipt of accurate and complete business

transactions is the norm. Suppliers can process orders quicker and shipments can be scheduled accordingly, while the

manufacturer can anticipate quicker receipt of goods and schedule manufacturing tasks accordingly

Finally, EDI can improve cash flow. As more of a company’s applications are integrated into EDI, its cash flow will

improve due to overall efficiencies that EDI provides. This enables managers to plan cash flow more precisely by

receiving and making payments sooner, thus allowing them to take advantage of net discounts

IMPLEMENT EDI

Implementing an EDI system across a company and group of associated trading partners can be a complex activity to try and

manage. This section of the EDI Basics Microsite highlights the various stages involved with implementing an EDI solution

within your business and looks at areas such as organising an EDI development project, strategic analysis, development,

piloting and finally deploying the EDI solution. Please review each step by selecting the appropriate button to the left.

Step 1 - Develop the organisational structure for managing the EDI system

In order to implement an EDI system it is important to have a dedicated person or team to manage the implementation process

and liase with outside providers of EDI solutions

Step 2 - Undertake a strategic review of the business

Once an EDI co-ordinator has been appointed then a strategic review of the business should be undertaken to see which

areas of the business will benefit from implementing the EDI solution first.

Step 3 - Developing an EDI Solution to meet the needs of the business

Once a specific process within the business has been targeted for automation via EDI, an EDI network provider and associated

software needs to be chosen for implementation

Step 4 - Integrating with other business systems across the company

In addition to automating one part of a business process there may be a requirement to utilise information held in other

business systems within the company. Integrating with other back office systems can provide significant downstream cost and

efficiency benefits.

Step 5 – Undertake mapping / data analysis of internal business processes

To ensure the smooth flow of information between internal applications and trading partners, documents need to be ‘mapped’

or linked to allow the information to be transmitted efficiently across a network.

Step 6 - Establishing a pilot project with selected trading partners

Once the basic EDI system has been implemented it is important to run a trial process to see how the system performs when

trading with a small number of partners.

Step 7 - Deployment of the EDI system amongst trading partners

Once the trial project has been successful then the next stage is to ramp or recruit all the required trading partners to the new

automated EDI process. This enablement of the trading partners is regarded as the final stage to implementing an EDI system.

STEP1

Many companies that have successfully deployed EDI, hire an EDI coordinator to manage all day to day aspects of their EDI

program. Whether a company hires someone with EDI experience or develops that experience in-house depends on the scope

of its EDI project and the nature of the company’s culture. Large organisations planning large integrated EDI projects require a

team of people dedicated to EDI. For example, in addition to the EDI coordinator these organisations may need two or three

Management Information System (MIS) people with full-time responsibility for EDI. MIS staff should be divided to handle two

separate but related issues. On one hand staff must work on the cost benefit analysis and manage implementation of the

system within the organisation, including education and training. On the other hand, MIS staff must evaluate software and

network options and must manage the integration to internal systems. Staff in other functional areas of the business would also

need to participate in EDI implementation. One of the EDI coordinator’s first tasks would be to determine the number of people

required to run the project efficiently.

Successful organisations have ensured that EDI develops in a way that meets the business needs by forming an EDI steering

committee. Headed by the EDI coordinator, the steering committee typically consists of department heads which may include

purchasing and sales, the Director of MIS, and members in advisory roles such as legal. One of the committee’s first tasks is to

agree upon the primary area of the organisation that should become the target of its first EDI application.

Obtain Organisational Support

One of the initial and most important steps to implementing an EDI solution is to obtain the support and commitment of top

management. The budget required to implement an EDI solution can be quite large and so it is important for both small and

large companies to have full company backing before implementation begins. In addition to agreeing on financial

commitments, the steering committee will have to get the support of all department heads in the business as the EDI solution

will impact all areas of the business.

If a positive case for EDI is to be made, then it is the job of the EDI coordinator to sell it; first to top management, then to

functional managers, and finally to all affected employees. EDI has the potential to radically change business practices and few

people accept change readily. EDI needs support throughout the organisation to provide maximum benefits. Top management

support is critical to eliminating the departmental barriers that a total EDI effort is likely to encounter. In order to gain that

support, the cost benefits analysis must be solid. Top management must understand how EDI will pay for itself and support key

company strategies.

The support of functional managers is also critical because their areas of the business will be directly affected by the EDI

system. Including functional managers on the EDI committee goes a long way towards gaining their support. They then have a

stake in a successful outcome. As with top management, the way in which the cost benefit analysis addresses the business of

each department is critical, as is the way it addresses administrative issues such as accounting, audit and legal.

Finally, line employees themselves must understand EDI, as it is likely to affect their jobs. Many employees distrust EDI for

fear that it will eliminate their jobs. However, it may allow them to resolve problems. In many ways the initial stages of an EDI

project are more about building teams and support, than about designing and deploying technology.

STEP 2

The areas of an organisation that would most benefit from EDI deployment will vary by organisation. Many large companies

have started implementing EDI within their purchasing departments as a way to decrease the costs of processing purchase

orders received from suppliers. Manufacturers have found that materials release documents make a good starting point for

EDI, as they can use EDI to support just in time manufacturing strategies. Conversely supplying companies have often found

that sales order processing is the initial area of EDI focus because their major customers want to send purchase orders

electronically. Accounts payable is also a profitable area of EDI focus for organisations that receive or send large amounts of

invoices.

In order to select a specific area, the EDI steering committee may direct the EDI co-ordinator to conduct an EDI survey of the

organisation’s customers and suppliers. It is of little use building an EDI system in an area that cannot be supported by either

large number of trading partners or a small number of high volume trading partners. Companies in the buying position often

have the clout to require EDI of their trading partners as a condition of doing business, which is why purchasing is often the

first focus of large organisation’s EDI efforts.

Undertaking an EDI Survey or Cost / Benefit Analysis

The EDI co-ordinator is also responsible for undertaking a cost benefit analysis for EDI. The cost benefit analysis further

identifies the most likely corporate applications for EDI deployment and defines their priority for development. However the cost

benefit analysis should be short enough to maintain momentum towards EDI completion. The analysis includes a description of

the present systems in each functional area and a determination of the likely ways EDI can improve those systems. The issue

and receipt of each type of business document is based on a system of human and machine procedures, all of which should

be documented and analysed in terms of EDI efficiencies. Consultants often recommend that organisations undertake an EDI

study with an eye towards improving existing processes, not just automating them. This may make an EDI system more

expensive, particularly in terms of system development and employee training, but it also provides greater financial return in

the long run.

In order to determine the prospective areas within an organisation to begin EDI, one should consider the following;

The number of vendors or customers involved in a particular business cycle

The amount of paperwork associated with a business cycle

The amount of time it takes to complete a business cycle

The term business cycle refers to the entire set of processes and documents required to complete a transaction. A typical

business cycle includes purchase order receipt, purchase order acknowledgement, producing the picking list, sending the

shipping notice and invoice and finally receipt of payment. Further questions need to also be considered :

Can EDI eliminate redundant steps in the business cycle?

Can it eliminate redundant entry of data?

Can it reduce clerical effort?

Can it reduce the need to carry inventory?

Can EDI improve relationships with trading partners?

Can it improve customer service by speeding the delivery of goods?

Can EDI support larger business strategies, such as just-in-time manufacturing?

Positive answers to such questions will help to highlight strong EDI opportunities within the business.

Conducting an effective cost benefit analysis requires a thorough understanding of EDI and how it works. It is often advisable

for an organisation to call in an EDI consultant. A good EDI consultant should have experience with more types of EDI systems

than even the most experienced EDI co-ordinators. This knowledge and experience can be invaluable in making sure an

organisation gets the most value from its EDI investment. Only when EDI is deployed as a stop gap measure, to retain a

customer for example, is EDI a trivial investment. Wise managers will not budget EDI as such. A solid analysis of a large

organisations’ EDI opportunities and payback may cost up to $100k for a large and sophisticated system. An EDI pilot program

may cost a large company between $1Million and $2Million for computer and telecommunications hardware, EDI software,

integration staff time, training and outside consulting. Moving from a pilot phase to production phase can cost another $1Million

to $2Million.

Smaller organisations that can use EDI software running on PCs can expect a much smaller investment. Recent internet based

e-Commerce systems may be cost effective. Hardware, software, and installation of a VAN-based system on a PC runs about

$3K to $5K for standalone EDI. Such systems may keep a customer, but they provide no more operational improvements than

a fax machine. If the PC system is integrated into a much larger computer system, investment increases by at least another

$5K however you begin to open up the system to further uses within the company. For example the inbound transactions, such

as purchase orders move directly into the in-house system.

Few EDI systems pay for themselves because of savings in postage, paper documents, and fewer clerical personnel.

Reductions in inventory and increases in working capital add to the main financial benefits of implementing an EDI system.

Other benefits include faster order cycles, fewer returns resulting from more accurate orders, increased staff productivity and

improved relations with trading partners. These benefits are discussed further in the Benefits of EDI section of this Microsite.

The EDI team asks the accounting department to help develop an accurate projection over a three to five year time period.

Summary of EDI Survey

The EDI co-ordinator’s report on the EDI analysis should provide the basis for a final decision on EDI, its best immediate uses

within the organisation and the best means of deploying the technology. The report should be financially oriented and allow

management to make an informed decision. Like most system audits, the report should include the following elements;

Scope of the project

Description of strengths and weaknesses of existing systems

Recommended system alternative and its capability to strengthen the company

Reference to alternatives considered but not selected

Financial data on recommended and rejected approaches

Timing of system development and funds needed

List of personnel required to develop and implement the system

Implementation schedule

For a smaller or reactive organisation, such information may not be required.

High Level Systems Analysis

In terms of information systems , the EDI analysis must consider existing requirements and EDI needs, this may consider:

The type of data that the current system requires

Which data is required by the trading partners but unavailable from the existing system

The data required by EDI standards

If the existing information system does not contain all of the data required by the trading partners, for instance the cost of

modifying the system to include that data, must be included in the analysis.

The organisation’s existing telecommunications environment must also be evaluated. Many organisations opt to transmit EDI

data through third party value added networks (VANs) rather than construct their own data networks for EDI. The internet also

offers a cost effective and viable alternative. Document capacities gathered during the analysis phase of business processes

should be stated in terms of required network capacities.

Once system capacities and needs have been determined, the analysis can examine different system options.

Does the volume of anticipated EDI traffic require a mainframe approach or will a PC system suffice?

Can the internal network handle EDI traffic?

Will it be more cost effective to manage network connections with individual trading partners or to make a single

connection with a VAN?

How much programming is required to ensure that internal systems contain the data required by trading partners and EDI

standards?

How much programming work is required to integrate the EDI system with internal applications?

The answers to these types of questions lead to a number of different system specifications being derived.

STEP 3

Once an EDI solution has been selected and approved by the EDI steering committee the EDI project then shifts to the

development phase. An EDI capable system may be viewed in five pieces.

The first piece is the telecommunications medium, usually a Value Added Network (VAN)or more recently the Internet. The

second, third and fourth pieces may be purchased together or separately.

The second piece is the telecommunications software which is not specific to EDI. On a PC, for example, this software has the

same functionality as MS Windows dial-up networking.

The third piece is usually a package licensed from an EDI software company or VAN provider—the EDI translator. In the case

of an incoming material release for automotive parts, the function of this piece of the EDI system is to interpret the EDI

information from the X12 format into a format more readily usable by in house systems. In addition to this primary function, an

EDI translation package may have several sub systems, including the handling of the EDI envelope, document

management/audit trails, compliance checking, and generation of a functional acknowledgement. The functional

acknowledgement is roughly equivalent to the postal service return receipt to confirm delivery.

The fourth piece, the interface, takes the final step in the translation or reformatting of the information. In the case of an

inbound material release, it takes the information in the format produced by the EDI translator and then reformats to produce

the format needed by the in-house system—namely the application software—which forms the fifth piece of the EDI system.

Selection of the EDI Network and Software

In its simplest form there are two main types of EDI network communication methods: those that rely on point-to-point

communications and those that use value added networks.

Point-to-Point Communications take place when lines are established using standard communication protocols

between trading partners. The connection can be set up as a leased line, which is paid for on a monthly basis and is

readily available for electronic data interchange, or as a dial-up line where the communication or information transfer is

established in a way similar to a telephone call. A dial-up link allows senders to batch transactions and make

connections to send at certain points. A dial-up link is a more cost-effective approach when the amount of transmitted

data is low.

Value Added Networks (VANs)—This is the most widely used method. Point-to- point lines frequently present a

scheduling problem to trading partners. Often, it is not convenient for the receiver to get transactions when the sender

chooses to transmit them. The solution to this problem is a VAN that provides a store and forward mailbox service. The

sender connects with the VAN and sends its EDI transactions to the recipient’s mailbox where they are stored. The

sender then disconnects from the service. When it is convenient, the recipient can connect to the network and receive

those transactions from their mailbox. With this approach, both sending and receiving parties must use the same EDI

standard transactions.

During the development phase, the selected system is broken into tasks for further study. The EDI team must select EDI

software and possibly network providers. Neither is a trivial task. The success of the EDI system will depend on the quality of

the software and network and the support provided by the vendors. Vendors can provide a great deal of useful technical advice

when implementing an EDI system, therefore it is very important to select the correct one.

Choosing an EDI network service (VAN) may be more closely related to the company’s data processing operations than the

modernity of the vendor’s technology. A value added network is a third party link in the EDI communications system that

provides the translation software service and the temporary transaction storage service—a mailbox—for trading partners.

Rather than sending data directly to trading partners, companies usually prefer to send it to the network, which routes data into

the appropriate trading partner’s electronic mailbox. Mailboxes hold EDI documents until the receiving partner asks for them

and many will send the recipients a message alerting them to incoming documents. Trading partners then dial into the network

and retrieve transaction sets from each other. Companies are thus relieved from maintaining connections with all trading

partners and scheduling transmissions individually.

One important factor to consider is"reach"—the number of the organisation's trading partners connected to the network. The

network may well be the least expensive portion of EDI conversion costs. It is impossible to make general recommendations of

one vendor over another. Ultimately the decision is really based upon which vendor suits the company’s particular business

needs. There are several criteria which organisations should consider when evaluating vendors. Before discussing these

services with a vendor a company needs to outline its trading partners and their EDI networks. If all or most of their trading

partners are using one particular network, the choice may be very simple, but not necessarily definitive.

First, determine how much a VAN is expected to do. Then, determine how much each VAN is actually willing to do. Most

networks promise turnkey services, but each vendor starts turning the key at different points in the implementation process.

Larger buyers seeking to bring smaller suppliers online will need a VAN willing to contact, educate, assist and train suppliers,

as well as to conduct tests, when their systems are in place. If this degree of service is required, it is a good idea to verify the

availability of the service and any charge for it.

An organisation could broaden its customer base by choosing a VAN entrenched in its own industry, and use EDI to establish

new trading partners relationships within that particular industry sector. Trade associations are excellent sources for

information about EDI activity within a particular vertical industry. They deal with the maintenance of standards as they apply to

a particular industry. In fulfilling this role they act as a sounding board for users’ problems and concerns and can be very

helpful to novice users.

Secondly, another important criteria is a vendor’s pricing structure. For example, some vendors charge a separate fee ( in

addition to the kilo character transmitted charge) for each document sent. In the transportation industry, transactions carry a

much greater time value and tend to be more frequent, therefore a document charge can add a sizable amount. In other

industries, the time value of transactions may be lower and transactions less frequent, making a document charge less

significant.

Pricing structures will vary from vendor to vendor. Users must thoroughly understand their transaction patterns, such as

frequency, volume, document size, time of day of transmission, etc., as these will all affect the pricing structure. Once the

patterns have been established the next step is to price out an extended example for each vendor under consideration. Users

must also be aware of any hidden charges, such as minimum record lengths. Some vendors specify record length of 128 or

512 characters. For instance, by sending 10 documents containing 10 characters, a user would incur a charge for 1280 or

5120 characters. Multiplied by a large monthly volume the difference becomes substantial.

Thirdly, consideration should be given to the vendor’s vast array of value added services, namely consulting and trading

partner liaison services. EDI network vendors offer varying degrees of handholding during the implementation and support

phase of an EDI project. This is a very important consideration, especially with medium-sized organisations that may not have

the internal staff to dedicate to the EDI effort.

Finally, a fourth criteria for evaluation is the vendor’s involvement and influence in trade associations and EDI standards

groups. Their participation is one indication of their long-term commitment to providing EDI services.

A related criteria is the vendor’s credibility in the market place. Many firms have entered the market in the past decade and

consolidation within the industry is inevitable. As rates drop and interconnect surcharges disappear, value added services will

become a differentiating factor. Vendors that have strong financial backing to respond to evolving customer demands will

survive such a shake out. In the meantime, users must continue to voice their needs and concerns and choose the vendor that

appears most willing to meet those needs.

Network service providers traditionally come from three backgrounds: time sharing / information retrieval services, public data

network providers and / or EDI service bureaus. Each category possesses advantages and restrictions for EDI services.

Vendors entering the EDI market from a time sharing background generally offer a number of value added services, such as

translation software packages, access to third party databases, database capture of trading information, audit reports and

historical activity summaries, and archiving services.

Vendors with a public data network orientation are traditionally viewed as data movers and have extensive experience

operating large packet switched networks. Users typically find it easy to work with these EDI network vendors, although they

may not provide as wide a range of extra services. While these companies do not supply EDI translation software, they do

provide long lists of certified software packages from third party developers. Also, these networks offer less extensive in-

network translation services.

Most public data network vendors are recent entrants into the EDI arena. Furthermore, users can expect to see more

newcomers in this category from network providers and hardware vendors. Although these companies are new to EDI, their

entrance into the market is not trivial. They are armed with impressive network expertise and financial resources. In addition,

their alliances with experienced EDI software / service providers can compensate for their lack of EDI experience. Networks

also offer one stop shopping for EDI clients. They will provide everything a customer needs to set up an EDI system, software,

translation, consultation, education, record keeping, reporting of EDI transactions to clients, and electronic mailboxes. Sending

EDI documents through a third party (VAN) may cost more out of pocket, but the services and support provides enhanced VAN

performance, thus making them very popular among trading partners today.

Legal & Audit Requirement

EDI affects the way an organisation conducts business and processes transactions. It may also require changes to

organisational policies. As the system is designed, auditors should review specifications to makes sure existing company

controls are maintained. As an electronic system, document storage, archiving and data recovery are vastly different to paper-

based systems the same holds true for the types of audit trails that are available. Auditors must be able to understand and

approve the new procedures that EDI requires.

Legal considerations also play a role. Although lawyers agree that EDI transmissions are as binding as paper documents,

problems are likely to arise if legal issues are not addressed. For instance, EDI transmissions do not contain the customary

terms and conventions that proper paper documents contain. Instead, companies sign EDI documents, which specify that

existing terms and conditions are in effect for EDI transmissions. Legal counsel should review, draft and approve such

agreements.

STEP 4

Once the software and network have been selected, work can begin on the actual system configuration. Again, vendors can

provide extensive help in setting up their respective pieces of the system. The internal portion requires the most attention from

the EDI staff assigned to the project.

How an EDI system is designed and developed depends on the amount of custom work an organisation plans to expend. A

turnkey EDI system running on a PC requires little development beyond the vendor’s recommendations. A large scale EDI

system that integrates EDI with other corporate applications and serves several departments requires a great deal of internal

programming and data routing.

For most EDI systems, the greatest development task is integrating EDI systems with existing corporate applications. Data

required by trading partners and EDI standards must be "mapped" onto data contained in existing systems. Software must be

designed and developed to take the file output of an internal application and move it in to and out of the EDI software. The

greatest cost of an EDI system can lie in developing software for integration purposes. Prototyping methodologies, where

system prototypes are developed before systems are actually coded, and Computer Aided Software Engineering (CASE) tools

help to streamline system development. Integration usually consists of three key activities:

The data analysis portion of mapping

Mapping via the EDI software

Development of any custom interface programs or user exits

Before integrating to a licensed package, the EDI team should ask whether steps 2 and 3 have already been done by the

software development firm. This could impact whether they will be able to integrate to your back-office systems without the

need for further development costs.

STEP 5

Whether your company is integrating with a licensed package or a custom inhouse system, it is always wise to begin data

analysis at the ultimate destination. If, for example, the first planned transaction is the inbound purchase order, the EDI team

begins with analysis of the order processing system’s requirements. For this portion of the project the team must include the

person most knowledgeable of the application.

To begin the data analysis , the EDI team compares the structure of the data at the ultimate destination with the structure of

the original data. An in-house order processing system might have header records and detail records. The major groups of

‘records’ in the original purchase order in the X12 format are header, detail and trailer. An outbound invoice in X12 has similar

major groups of ‘records’ :header, detail and trailer. However the invoice may originate in an accounts receivable system that

has shipment header, shipment detail , order header, order detail and a customer master file.

Once the structures have been compared, the analysis moves to each field required at the ultimate destination. Most fields that

are required by most order processing systems are present in most X12 based Purchase Orders (Pos), although they may

have different field names. If a required field appears to be missing, it may be made available by building a cross reference file.

For example, customer number is not usually sent (or even known) by the customer. It may be built into a cross-reference by

EDI Sender ID.

Once each field has been found , its destination content and format need to be compared carefully with it’s origin. The in-house

order processing system’s field for customer department may be a 4-position numeric. The department number is an example

of a secondary key needing special attention. Additional examples are store number, service provider ID, carrier code, name,

product code etc. Surprisingly, primary keys usually need less attention, since MIS departments have learned to honour the

primary keys of their trading partners. Examples of primary keys are:

Customer PO

PRO Number

Invoice Number

Bill of Lading Number

Claim Number

If industry wide codes exist, they will greatly facilitate the use of EDI. If the application is using an industrywide code in a

minimal way, the time of EDI development may be the time to fully adopt such a code. An example of minimal adoption is a

Drug Enforcement Agency (DEA) number used by pharmaceutical manufacturer as a customer cross-reference. The building

of a cross reference is an ongoing, effort intensive, error prone process. It may be erroneously viewed as a responsibility of the

EDI team and may be a high pressure, high profile activity when any imperfections stops a pharmaceutical order or charge

back. It is a pharmaceutical industry best practice to use the DEA number as the customer number itself. Other examples of

valuable industry wide numbers are Dun and Bradstreet (DUNS), Standard Carrier Alpha Code (SCAC), the Health Industry

Number (HIN), Universal Product Code (UPC) and National Drug Code (NDC).

Mapping, Defining to the EDI Software

Once the data analysis portion of the mapping is complete, the ‘map’ is defined to the EDI translation software. Unless a

‘budget priced’ EDI package was licensed (for a quick implementation) the package will allow the EDI co-ordinator to define the

map. The map may be likened to a database definition. When the EDI co-ordinator ‘maps’, the EDI software stores the map,

usually in tabular form. Later, when a transaction comes into the translation portion of the EDI package, it uses the map to

determine where each incoming field goes and whether to re-format.

The ‘mappers’ that are more user friendly tend to be less robust, software developers intend for mappers to be capable of

being used by user-oriented EDI co-ordinators. Yet the developers also want the mappers to be capable of doing every thing

possible to avoid custom interfaces.

Developing Custom Interfaces

EDI interfaces occasionally require logic that is beyond the capabilities of the most robust EDI mappers. The somewhat

complex structure of the accounts receivable databases, might call for a selection or pre-processing program. This program

could build outbound header , detail, and trailer records for example, a structure similar in nature to X12.

Logic to convert particular fields may be viewed with suspicion, for example is it wise to remove the DUNS prefix from a

WALMART store number?, Is it wise to extract the size of a garment from positions 7 through 12 of the manufacturer’s

‘intelligent’ product code? Occasionally a field conversion may be necessary. Such conversion may be done in a pre or post

processing program or in a user exit callable by the EDI program. An example is conversion of a date in century, month, year,

day format to X12’s YYMMDD format.

Also viewed with suspicion would be custom edits per trading partner, for example it is not the responsibility of an outbound

EDI interface or translator to avoid JCPenney freight charges. Rejection of such charges by Penney quickly comes to the

attention of the EDI co-ordinator, but should be addressed further upstream. If a ware house is incorrectly submitting charges,

the warehouse software must have additional edits put into it.

STEP 6

Once an organisation has developed and tested its EDI system to the best of its ability, further system tests are conducted in

pilot with specific trading partners. The EDI pilot is critical. It allows an organisation to refine its own system and if all goes well,

provides the first look at how EDI will make the organisation more efficient. Organisations should set up a pilot project with a

small number of trading partners. The organisations with the most EDI experience make the best pilot partners. To be

successful, the pilot must focus on one primary EDI application such as simple purchase orders.

In practice, organisations will already have completed limited testing of the system. VANs conduct tests as they connect

organisations to their systems. Organisations transmit data to the VANs, which then ensure that the transmissions are reliable.

A similar sequence of events occurs with pilot partners. First begin transmitting documents to the pilot partners, which evaluate

the transmissions to make sure the pilots can process them accurately. Pilot partners then return data for testing.

As each of these tests are completed successfully, the pilot begins to send for real orders on real time tables, which tests the

capability of the system to respond to daily business processes. Paper transactions are not eliminated, however, until both

trading partners are completely satisfied that the EDI system is performing as well as or better than existing processes. Once

that agreement has been reached , trading partners then agree upon a timetable for eliminating paper transactions in parallel

from several weeks to several months depending on the complexity of the EDI system.

Pilot project results must then be analysed from an internal perspective to answer the following questions:

Can the EDI system maintain adequate control?

Does the system appear to provide the benefits projected in the original EDI study?

Will the system handle anticipated EDI traffic?

Are internal users satisfied with the result?

At some organisations the pilot stage of EDI never really ends, rather than move EDI out in to the broad base of trading

partners, it remains a rather isolated system, handling only high-volume trading partners. The final step in EDI implementation

is extending EDI capabilities out to smaller and smaller trading partners, for example adding a web form / portal capability and

to a greater number of business documents and processes.

STEP 7

When extending an EDI system to the rest of the trading partners, many large buying organisations put together EDI education

and training programmes for their suppliers. VANs have also taken a lead by providing support to their customers in getting

trading partners online. These programs, sometimes called ramping suppliers or community enablement, are seen as a key

process to deploying an EDI system successfully amongst trading partners in a supply chain.

Hub and Spoke Supply Chain Model

Under the hub and spoke approach, the large customer, the hub, moves its EDI program out to its suppliers, the spokes. The

amount of hand holding that large organisations undertake to suppliers varies, as does the amount of leeway they give

suppliers. In many instances, suppliers receive the message that EDI is a requirement for continuing the business relationship.

As is the case for any change, suppliers may be reluctant to begin EDI, The hub must overcome this inertia or resistance by

describing the effect of EDI on the business relationship and by overcoming possible objections. Suppliers may fear the

unknown. Possible objections may include:

Belief, sometimes correct, that the setup costs may be substantial

Assumption that the license fees for EDI software may be of the same order of magnitude as those of the order processing

systems

Budget or cash flow concerns

Other MIS related priorities, eg network or PC upgrades

MIS workload and planning cycles

Scarcity of consultants or employment candidates with EDI experience

Establishing a Trading Partners Conference

Providing EDI education and help are two ways for an organisation to increase the number of trading partners and the speed

with which a given trading partner complies. These two factors increase the return of the hub’s EDI investment. Education

tends to overcome trading partner resistance to EDI and the more trading partners that conduct business by EDI, the greater

the savings. Whether a large organisation plans to provide EDI education itself or contract with a VAN is another decision for

the EDI co-ordinator.

If the hub is a purchasing organisation, it may host supplier conferences to explain their EDI program to suppliers. Suppliers

learn about the benefits of EDI and their options for getting on the system. Tips for a successful supplier conference are as

follows:

The invitation comes from a high level business person (not technical) known to the suppliers

The conference should be opened by the high level person, and they should be able to relate to the suppliers and the

business objectives

Suppliers should be told that any speakers from EDI networks and software companies will be educating and not selling

The requirements of the suppliers should be clear and concise, including what is expected and by when

If for some reason a company is unable to hold a suppliers conference, may be due to geographically dispersed suppliers in

different countries then companies could adopt one of the following approaches:

Introductory chapters in booklets that had formerly been devoted to format guidelines

Increased staffing and performance of EDI telephone support groups

VAN and other enabling services

The U.S federally supported Electronic Commerce Resource Centres (ECRCs)

EDI training companies.

Testing the EDI System

Leading hubs and VANS in the late 1990s reduced effort for rapid , large scale implementations. The first reduction takes the

form of a test procedure. Prior to testing a written procedure of 1 or 2 pages explains to the trading partners what to expect.

During testing they serve as checklists for trading partners and hub or VAN test personnel. Use of such procedures allows hub

or VAN personnel to be trained on specific procedures rather than broad EDI standards and concepts. Thus new hub or VAN

personnel may have little need for the formerly required years of EDI experience. In addition to procedures, Hub or VAN

testers use tools. Some hubs and VANs automatically retrieve generic purchase order data and apply the trading partner’s

receiver ID. Others set a flag in the supplier database that copies production purchase orders.

If the Hub chooses to outsource testing to a VAN or service provider, the hub must realise that it can only outsource a portion.

This is because the VAN or service bureau uses generic data, generic ship to and product codes for example. Thus the tests

are tests of the trading partners’ EDI systems only. Testing of the accuracy and business meaning of hub data is a task for the

hub itself. For example, it is production data that must move through the supplier’s EDI systems into its order processing or

ERP system as a thorough test for the hub’s product data files.

Phased Implementation of the First Transaction

Implementation with a broad base of suppliers may take a phased approach. The organisation decides how many new trading

partners it can handle at once and then works through the same procedures it used during the pilot test. Timetables for dual

testing and dual operations should be specified and strictly followed. Selection of groups of new trading partners is done

according to the objectives of EDI. If the objective is to reduce inventory, high dollar trading partners take priority. If the

objective is to reduce processing , as in accounts payable, then high paper volume trading partners are the ones to implement

first.

Additional Transactions

Once the first transaction has been implemented with a significant percentage of its trading partners, the next transaction is

selected and viewed as a separate project. It has some surprising characteristics. Technical members of the first transaction’s

EDI team may be free to work on the second transaction much sooner than the team members involved in implementation and

deployment. The second transaction usually needs to interface to a different application. Thus, there is considerable technical

effort.

The second transaction usually needs to involve a different user department. Thus, it has the analysis, motivation, and

education challenges first. One organisation question is,’When is it best to free the EDI co-ordinator from the first transaction?’.

The second transaction may or may not involve the same trading partner community. If it is the same, then the pilot and

deployment will be simpler but not necessarily trivial. Some of the trading partners may have assumed that the EDI

requirement had been complete and permanently met.

EDI RESOURCES

This section of the EDI Microsite contains a number of resources which may help you to get a better understanding of EDI, the

technology used, the types of documents exchanged, industry standards in use and a number of downloadable tutorials and

white papers. Please select one of the options to the left.

DOCUMENTS STANDARDS

ANSI ASC X12 – In 1979, the American National Standards Institute (ANSI) chartered the Accredited Standards Committee

(ASC) X12 to develop uniform standards for inter-industry electronic exchange of business transactions, namely electronic

data interchange. ANSI X12 was originally conceived to support companies across different industry sectors in North America

however today there are more than 300,000 companies worldwide using X12 EDI standards in daily business transactions.

ASC X12 also contributes to UN/EDIFACT messages that are used widely outside of the United States.

Further information about ANSI X12 can be found here »

Further information about the ANSI X12 document types can be found here»

EANCOM – This standard was originally conceived in 1987 by the EAN General Assembly and was to be developed on the

then emerging international UN/EDIFACT standard. The EANCOM messages, maintained by GS1, are more detailed in nature

compared to the TRADACOMS message set. EANCOM was originally developed for the retail sector and has subsequently

grown to become the most widely used UN/EDIFACT subset and is now found in a variety of other industry sectors such as

healthcare, construction and publishing.

Further information about EANCOM can be found here»

UN/EDIFACT – United Nations/Electronic Data Interchange for Administration, Commerce and Transport is the international

standard that was developed by the United Nations. The work of maintenance and further development of this standard is done

through the United Nations Centre for Trade Facilitation and Electronic Business (UN/CEFACT) under the UN Economic

Commission for Europe. The EDIFACT standard provides a set of syntax rules to structure, an interactive exchange protocol

and provides a set of standard messages which allow multi-country and multi-industry exchange of electronic business

documents. EDIFACT is widely used across Europe, mainly due to the fact that many companies adopted it very early on.

EDIFACT has seen some adoption in the ASPAC region however there are currently more XML based standards being used in

this particular region today.

Further information about EDIFACT can be found here »

Further information about the EDIFACT document types can be found here»

HIPAA – The Health Insurance Portability and Accountability Act was enacted by the U.S congress in 1996. A key component

of HIPAA is the establishment of national standards for electronic health care transactions and national identifiers for providers,

health insurance plans and employers. The standards are meant to improve the efficiency and effectiveness of the North

American health care system by encouraging the widespread use of EDI in the U.S health care system. The HIPAA EDI

transaction sets are based on X12 and the key message types are described below.

Further information about HIPAA can be found here »

Further information about the HIPAA document types can be found here »

ODETTE – The Organisation for Data Exchange by Tele Transmission in Europe is a group that represents the interests of the

automotive industry in Europe. They are the equivalent of the Automotive Industry Action Group (AIAG) in North America. The

organization develops tools and recommendations that improve the flow of goods, services product data and business

information across the whole automotive value chain. ODETTE has been responsible for developing communications

standards such as OFTP and OFTP2.0, constant improvement processes such as Materials Management Operations

Guideline / Logistics Evaluation (MMOG/LE) and automotive specific document standards as defined via the link below.

Further information about ODETTE can be found here »

Further information about the ODETTE document types can be found here»

RosettaNet – This consists of a consortium of major computer, consumer electronics, semi-conductor manufacturers,

telecommunications and logistics companies working together to create and implement industry wide, open e-business

process standards. These standards form a common e-business language, aligning processes between supply chain partners

on a global basis. The RosettaNet document standard is based on XML and defines message guidelines, business processes

interface and implementation frameworks for interactions between companies. Using RosettaNet Partner Interface Processes

(PIPs), trading partners of all sizes can connect electronically to process transactions and move information within their

extended supply chains. Further information about RosettaNet PIP documents can be found from the link below.

Further information about RosettaNet can be found here »

Further information about the RosettaNet document types can be found here »

SWIFT – The Society of Worldwide Interbank Financial Telecommunication was formed in 1973 and is headquartered in

Brussels. SWIFT operates a worldwide financial messaging network which exchanges messages between banks and financial

institutions. SWIFT also markets software and services to financial institutions, much of it for use on the SWIFTNet Network.

SWIFTNet is the infrastructure used to exchange these documents and FIN, InterAct and FileAct are used to encode the

SWIFT documents for transmission. The majority of interbank messages use the SWIFT network. As of November 2008,

SWIFT linked 8740 financial institutions across 209 countries. The SWIFT document standard is split into four areas,

Payments, Trade Services, Securities and Trading.

Further information about SWIFT can be found here »

Further information about the SWIFT document types can be found here»

Tradacoms – This is an early standard for EDI and was primarily used in the UK retail sector. It was originally introduced in

1982 as an implementation of the UN/GTDI syntax, one of the precursors of EDIFACT and was maintained and extended by

the UK Article Numbering Association, now called GS1 UK. The standard is more or less obsolescent since the development of

it effectively ceased in 1995 in favour of the EDIFACT EANCOM subsets. Despite this it has proved durable and the majority of

the retail EDI traffic in the UK still uses it today.

Further information about Tradacoms can be found here »

Further information about the Tradacoms document types can be found here»

VDA – This organization develops standards and best practices to serve the needs of companies within the German

automotive industry. The VDA has developed over thirty messages to meet the need of companies such as VW, Audi, Bosch,

Continental and Daimler AG. Further information about these messages can be found via the link below.

Further information about VDA can be found here »

Further information about the VDA document types can be found here»

VICS – The Voluntary Inter-industry Commerce Standard is used by the general merchandise retail industry across North

America. It is a subset of the ANSI ASC X12 national standard. VICS EDI is being utilized by thousands of companies,

department and speciality retail stores, mass merchandisers and their respective suppliers. In 1988 GS1 US became the

management and administrative body for VICS EDI. GS1 US also manages the ASC X12 derived Uniform Communication

Standard (UCS) for the grocery industry and Industrial/Commercial Standard (I/C) for the industrial sector.

Further information about VICS can be found here »

Further information about the VICS document types can be found here »

Further information about the UCS and I/C standards can be found here»

ANSI message types

Communications and Controls

242 Data Status Tracking

259 d Error Reporting Immediate Response

815 Cryptographic Service Message

868 Electronic Form Structure

997 e,* Functional Acknowledgment

Product Data

140 * Product Registration

141 Product Service Claim Response

142 Product Service Claim

143 Product Service Notification

241 d Binary Data File Transfer

243 d Request for Product Source Information

244 d Product Source Information

841 e,* Specifications/Technical Information

842 e,* Nonconformance Report

848 * Material Safety Data Sheet

863 * Report of Test Results

864 e,* Text Message

Finance

135 Student Loan Application

139 Student Loan Guarantee Result

144 Student Loan Transfer and Status Verification

155 d Credit Report

156 d Entitlement Payment Recipient Account Inquiry/Response

190 Student Enrollment Verification

191 Student Loan Pre-Claims and Claims

197 d Real Estate Title Evidence

198 d Loan Verification Information

199 d Mortgage Settlement Information

200 Mortgage Credit Report

201 Residential Loan Application

203 Secondary Mortgage Market Investor Report

205 d Mortgage Note

206 d Real Estate Mortgage Inspection Request

207 d Real Estate Mortgage Inspection Result

208 d Income Property Appraisal Report

209 d Condominium Appraisal Report

215 Motor Carrier Pick-up Manifest

260 Application for Mortgage Insurance Benefits

261 b Residential Appraisal Request

262 Residential Appraisal Report

263 Residential Mortgage Insurance Application Response

264 Mortgage Loan Default Status

265 Real Estate Title Insurance Services Order

266 Mortgage Record Change

810 e,* Invoice

811 * Consolidated Service Invoice/Statement

812 * Credit/Debit Adjustment

819 Operating Expense Statement

820 * Payment Order/Remittance Advice

821 Financial Information Reporting

822 Customer Account Analysis

823 Lockbox

824 e,* Application Advice

827 Financial Payment Return Order/Return Notice

828 Debit Authorization

829 Payment Cancellation Request

831 Application Control Totals

833 Mortgage Credit Report Order

844 Product Transfer Account Adjustment

849 Response to Product Transfer Account Adjustment

872 Residential Mortgage Insurance Application

880 Grocery Products Invoice

Government

149 d Notice of Tax Adjustment or Assessment

150 Tax Rate Notification

151 Electronic Filing of Tax Return Data Acknowledgment

152 Statistical Government Information

154 Uniform Commercial Code Filing

156 d Entitlement Payment Recipient Account Inquiry/Response

175 Court Notice

176 * Court Submission

185 Royalty Regulatory Report

194 d Grant or Assistance Application

195 Federal Communications Commission (FCC) License Application

196 * Contractor Cost Data Reporting

251 * Pricing Support

280 d Voter Registration Information

281 d Elections Results Reporting

501 Vendor Performance Review

502 d Solicitation Mailing List

505 d Procurement Support

506 d Procurement Notice

511 * Requisition

517 * Material Obligation Validation

525 d Asset Disposition

527 * Material Due-In and Receipt

536 * Logistics Reassignment

561 * Contract Abstract

567 * Contract Completion Status

568 * Contract Payment Management Report

805 * Contract Pricing Proposal

806 Project Schedule Reporting

813 Electronic Filing of Tax Return Data

826 Tax Information Reporting

836 e,* Procurement Notices

838 e,* Trading Partner Profile

839 Project Cost Reporting

996 File Transfer

Materials Management

830 * Planning Schedule With Release Capability

846 * Inventory Inquiry/Advice

847 Material Claim

853 Routing and Carrier Instruction

856 e,* Ship Notice/Manifest

857 Shipment and Billing Notice

861 * Receiving Advice/Acceptance Certificate

862 Shipping Schedule

866 Production Sequence

867 Product Transfer and Resale Report

869 e,* Order Status Inquiry

870 e,* Order Status Report

871 b Component Parts Content

Transportation

104 Air Shipment Information

110 Air Freight Details and Invoice

120 Vehicle Shipping Order

121 Vehicle Service

125 Multilevel Railcar Load Details

126 Vehicle Application Advice

127 Vehicle Baying Order

128 Dealer Information

129 Vehicle Carrier Rate Update

160 d Transportation Automatic Equipment Identification

161 Train Sheet

163 d Appointment Schedule Information

204 Motor Carrier Shipment Information

210 Motor Carrier Freight Details and Invoice

213 Motor Carrier Shipment Status Inquiry

214 Transportation Carrier Shipment Status Message

217 Motor Carrier Loading and Route Guide

218 Motor Carrier Tariff Information

250 Purchase Order Shipment Management Document

300 Reservation (Booking Request) (Ocean)

301 Confirmation (Ocean)

303 Booking Cancellation (Ocean)

304 Shipping Instructions

309 U.S. Customs Manifest

310 Freight Receipt and Invoice (Ocean)

311 Canadian Customs Information

312 Arrival Notice (Ocean)

313 Shipment Status Inquiry (Ocean)

315 Status Details (Ocean)

317 Delivery/Pickup Order

319 Terminal Information

322 Terminal Operations and Intermodal Ramp Activity

323 Vessel Schedule and Itinerary (Ocean)

324 Vessel Stow Plan (Ocean)

325 Consolidation of Goods in Container

326 Consignment Summary List

350 U.S. Customs Release Information

352 U.S. Customs Carrier General Order Status

353 U.S. Customs Events Advisory Details

354 U.S. Customs Automated Manifest Archive Status

355 U.S. Customs Manifest Acceptance/Rejection

356 U.S. Customs Permit to Transfer Request

357 U.S. Customs In-Bond Information

358 U.S. Customs Consist Information

361 Carrier Interchange Agreement (Ocean)

404 Rail Carrier Shipment Information

410 Rail Carrier Freight Details And Invoice

412 d Trailer/Container Repair Billing

414 Rail Car-hire Settlements

417 Rail Carrier Waybill Interchange

418 Rail Advance Interchange Consist

419 Advance Car Disposition

420 Car Handling Information

421 Estimated Time of Arrival and Car Scheduling

422 Shipper's Car Order

423 Rail Industrial Switch List

425 Rail Waybill Request

426 Rail Revenue Waybill

429 Railroad Retirement Activity

431 Railroad Station Master File

432 Rail Deprescription

433 Railroad Reciprocal Switch File

435 Standard Transportation Commodity Code Master

436 b Locomotive Information

440 Shipment Weights

451 Railroad Event Report

452 Railroad Problem Log Inquiry or Advice

453 Railroad Service Commitment Advice

455 Railroad Parameter Trace Registration

456 Railroad Equipment Inquiry or Advice

460 d Price Distribution or Response Format

463 d Rail Rate Reply

466 Rate Request

468 Rate Docket Journal Log

475 Rail Route File Maintenance

485 Rate making Action

486 d Rate Docket Expiration

490 Rate Group Definition

492 Miscellaneous Rates

494 Scale Rate Table

601 Shipper's Export Declaration

602 Transportation Services Tender

622 Intermodal Ramp Activity

715 b Intermodal Group Loading Plan

753 Request for Routing Instructions

754 Routing Instructions

854 Shipment Delivery Discrepancy Information

858 * Shipment Information

859 * Freight Invoice

920 Loss or Damage Claim - General Commodities

924 Loss or Damage Claim - Motor Vehicle

925 Claim Tracer

926 Claim Status Report and Tracer Reply

928 * Automotive Inspection Detail

980 Functional Group Totals

990 Response to a Load Tender

998 Set Cancellation

Purchasing

503 * Pricing History

504 * Clauses and Provisions

816 Organizational Relationships

832 e,* Price/Sales Catalog

840 e,* Request for Quotation

843 e,* Response to Request for Quotation

845 Price Authorization Acknowledgment/Status

850 e,* Purchase Order

851 * Asset Schedule

855 e,* Purchase Order Acknowledgment

860 e,* Purchase Order Change Request - Buyer Initiated

865 e,* Purchase Order Change Acknowledgment/Request - Seller Initiated

875 Grocery Products Purchase Order

876 Grocery Products Purchase Order Change

Industry Standards Transition

130 Student Educational Record (Transcript)

131 Student Educational Record (Transcript)Acknowledgment

146 Request for Student Educational Record (Transcript)

147 Response to Request for Student Educational Record (Transcript)

187 d Request/Response to Request for Educational Course Catalog

188 b Educational Course Catalog

189 b Application for Admission to Educational Institutions

193 d Financial Aid Transcript

Distribution & Warehousing

159 b Motion Picture Booking Confirmation

170 Revenue Receipts Statement

180 * Return Merchandise Authorization and Notification

290 Cooperative Advertising Agreements

818 Commission Sales Report

852 Product Activity Data

877 d Manufacturer Coupon Family Code Structure

878 Product Authorization/De-Authorization

879 Price Change

882 Direct Store Delivery Summary Information

883 Market Development Fund Allocation

884 Market Development Fund Settlement

885 Store Characteristics

886 Customer Call Reporting

887 b Coupon Notification

888 Item Maintenance

889 Promotion Announcement

891 Deduction Research Report

893 Item Information Request

894 Delivery/Return Base Record

895 Delivery/Return Acknowledgment or Adjustment

896 Product Dimension Maintenance

940 Warehouse Shipping Order

943 Warehouse Stock Transfer Shipment Advice

944 Warehouse Stock Transfer Receipt Advice

945 Warehouse Shipping Advice

947 Warehouse Inventory Adjustment Advice

Insurance

124 Vehicle Damage

148 Report of Injury, Illness or Incident

186 Laboratory Reporting

253d Data Reporting Requirements

255b Insurance Underwriting Information Services

256d Periodic Annuity Compensation

268d Annuity Account Activity

270 Health Care Eligibility/Benefit Inquiry

271 Health Care Eligibility/Benefit Information

272 Property and Casualty Loss Notification

273b Insurance/Annuity Application Status

275b Patient Information

276 Health Care Claim Status Request

277 Health Care Claim Status Notification

278 Health Care Service Review Information

362 Cargo Insurance Advice of Shipment

834 Benefit Enrollment and Maintenance

835 Health Care Claim Payment/Advice

837 Health Care Claim

EANCOM message types

EANCOM provides a logical sequence of messages used in business. Trading companies agree together on messages

adapted to their needs. Standard messages available in EANCOM can be divided into the following categories, Master Data,

Commercial Transactions, Report & Planning and Transporter.

The messages available in the EANCOM® standard cover the functions required to effect a complete trade transaction:

the messages which enable the trade transaction to take place, e.g. price catalogue, purchase order, invoice, etc;

the messages used to instruct transport services to move the goods;

the messages used in settlement of the trade transactions through the banking system.

The flows and trading partners catered for in EANCOM can be simply represented as follows:

The business messages available in EANCOM can be divided into the following categories:

Master Data Messages

These contain data which rarely changes (product measurements, names and addresses,...) :

The Party Information message : is used to identify all the locations (EAN location numbers : name, address, contact

persons, financial accounts,...) associated to subsequent commercial transactions and their related operational

information.

The Product Information messages : provide parties with information containing the descriptive, logistical and

financial details of a product or a service.

Commercial Transactions Messages

These cover the general trading cycle from quotation request to remittance advice :

The Quotation messages contain all details relevant to the supply of the goods or services requested by the potential

buyer (terms of delivery, payment terms, price, allowances and charges,...).

The Purchase Order set of messages relates to the ordering process from a proposed order, subsequent changes

and the eventual order confirmation (relevant quantities, dates, location of delivery,...).

The Transport and Logistics messages provide information related to the despatch transport and receipt of

previously ordered products.

The Invoice and Remittance Advice messages relate to the payment of the goods supplied. The buyer can

automatically reconcile the suppliers invoice using the product receipt information.

Report and Planning Messages

These messages include general trading reports which allow partners to plan for the future. They enable trading partners to

exchange precious information in order to understand each others' requirements. They provide valuable and up-to-date reports

and forecasts concerning delivery, sales and stocks and enable the partners involved to plan their activities and marketing

strategies.

Syntax and Service Report message may be sent by the receiver of any EDIFACT message to acknowledge or

refuse an interchange, functional group or message.

General Message may be used to send data for which there is no specific standard message.

What are the benefits of EANCOM?

In EDI, it is essential to unambiguously identify the products or services as well as the parties associated with the transaction.

Coding the information exchanged in EDI is essential for automatic processing.

In EANCOM messages, each product defined in its widest sense is identified by a unique EAN standard article number and

each party is identified by a unique EAN location number. Use of the EAN standards in EDI provides the following significant

benefits :

Uses a Standard Numbering Convention - EAN identification numbers are unique and recognised world-wide. Use

of EAN standard numbers means trading partners do not have to maintain complex cross-references for each trading

partner's internal codes.

Standard Messages are simple and accurate - The unambiguous coding of products and locations greatly simplifies

EDI messages, reducing transmission costs and facilitating processing.

Multi-Industry Standard - The non-significant characteristic of the EAN numbers allows any item to be identified and

consequently any business, regardless of its activity, can use EANCOM.

International - EANCOM messages are used world-wide. The international network of EAN Numbering Organisations,

covering more than 80 countries, provides EANCOM support in their local language to an increasing number of user

companies world-wide.

Maintenance and Support - EAN and its Numbering Organisations are strategically committed to maintain and further

develop EANCOM. Representatives from various industries have established several project teams with the objective

of analysing specific issues and developing business oriented solutions.

EDIFACT message types

270-A1 Eligibility, Coverage or Benefit Inquiry

271-A1 Eligibility, Coverage or Benefit Information

276-A1 Health Care Claim Status Request

277-A1 Health Care Claim Status Notification

278-A1 Health Care Services Review -- Request for Review

278-A3 Health Care Services Review -- Response to Request for Review

820-A1 Payment Order/Remittance Advice

834-A1 Benefit Enrollment and Maintenance

835-W1 Health Care Claim Payment/Advice

837-Q1 Health Care Claim: Professional

837-Q2 Health Care Claim: Dental

837-Q3 Health Care Claim: Institutional

APERAK Application error and acknowledgement message

AUTHOR Authorization message

AVLREQ Availability request - interactive message

AVLRSP Availability response - interactive message

BALANC Balance message

BANSTA Banking status message

BAPLIE Bayplan/stowage plan occupied and empty locations message

BAPLTE Bayplan/stowage plan total numbers message

BERMAN Berth management message

BMISRM Bulk marine inspection summary report message

BOPBNK Bank transactions and portfolio transactions report message

BOPCUS Balance of payment customer transaction report message

BOPDIR Direct balance of payment declaration message

BOPINF Balance of payment information from customer message

BUSCRD Business credit report message

CALINF Vessel call information message

CASINT Request for legal administration action in civil proceedings message

CASRES Legal administration response in civil proceedings message

CHACCO Chart of accounts message

CLASET Classification information set message

CNTCND Contractual conditions message

COACSU Commercial account summary message

COARRI Container discharge/loading report message

CODECO Container gate-in/gate-out report message

CODENO Permit expiration/clearance ready notice message

COEDOR Container stock report message

COHAOR Container special handling order message

COLREQ Request for a documentary collection message

COMDIS Commercial dispute message

CONAPW Advice on pending works message

CONDPV Direct payment valuation message

CONDRA Drawing administration message

CONDRO Drawing organisation message

CONEST Establishment of contract message

CONITT Invitation to tender message

CONPVA Payment valuation message

CONQVA Quantity valuation message

CONRPW Response of pending works message

CONTEN Tender message

CONWQD Work item q uantity determination messa e

COPARN Container announcement message

COPAYM Contributions for payment

COPINO Container pre-notification message

COPRAR Container discharge/loading order message

COREOR Container release order message

COSTCO Container stuffing/stripping confirmation message

COSTOR Container stuffing/stripping order message

CREADV Credit advice message

CREEXT Extended credit advice message

CREMUL Multiple credit advice message

CUSCAR Customs cargo report message

CUSDEC Customs declaration message

CUSEXP Customs express consignment declaration message

CUSPED Periodic customs declaration message

CUSREP Customs conveyance report message

CUSRES Customs response message

DEBADV Debit advice message

DEBMUL Multiple debit advice message

DEBREC Debts recovery message

DELFOR Delivery schedule message

DELJIT Delivery just in time message

DESADV Despatch advice message

DESTIM Equipment damage and repair estimate message

DGRECA Dangerous goods recapitulation message

DIRDEB Direct debit message

DIRDEF Directory definition message

DMRDEF Data maintenance request definition message

DMSTAT Data maintenance status report/query message

DOCADV Documentary credit advice message

DOCAMA Advice of an amendment of a documentary credit message

DOCAMI Documentary credit amendment information message

DOCAMR Request for an amendment of a documentary credit message

DOCAPP Documentary credit application message

DOCARE Response to an amendment of a documentary credit message

DOCINF Documentary credit issuance information message

ENTREC Accounting entries message

FINCAN Financial cancellation message

FINPAY Multiple interbank funds transfer message

FINSTA Financial statement of an account message

GENRAL General purpose message

GESMES Generic statistical message

HANMOV Cargo/goods handling and movement message

ICASRP Insurance claim assessment and reporting message

ICSOLI Insurance claim solicitor's instruction message

IFCSUM Forwarding and consolidation summary message

IFTCCA Forwarding and transport shipment charge calculation message

IFTDGN Dangerous goods notification message

IFTFCC International transport freight costs and other charges message

IFTIAG Dangerous cargo list message

IFTICL Cargo insurance claims message

IFTMAN Arrival notice message

IFTMBC Booking confirmation message

IFTMBF Firm booking message

IFTMBP Provisional booking message

IFTMCA Consignment advice message

IFTMCS Instruction contract status message

IFTMFR International Forwarding And Transport

IFTMIN Instruction message

IFTRIN Forwarding and transport rate information message

IFTSAI Forwarding and transport schedule and availability information me

IFTSTA International multimodal status report message

IFTSTQ International multimodal status request message

IHCEBI Interactive health insurance eligibility and benefits inquiry and

IHCLME Health care claim or encounter request and response - interactive

IMPDEF EDI implementation guide definition message

INFCON Infrastructure condition message

INFENT Enterprise accounting information message

INSDES Instruction to despatch message

INSPRE Insurance premium message

INSREQ Inspection request message

INSRPT Inspection report message

INTCHG Interchange Control Structures

INVOIC Invoice message

INVRPT Inventory report message

IPPOAD Insurance policy administration message

IPPOMO Motor insurance policy message

ISENDS Intermediary system enablement or disablement message

ITRRPT In transit report detail message

JAPRES Job application result message

JINFDE Job information demand message

JOBAPP Job application proposal message

JOBCON Job order confirmation message

JOBMOD Job order modification message

JOBOFF Job order message

JUPREQ Justified payment request message

LEDGER Ledger message

LREACT Life reinsurance activity message

LRECLM Life reinsurance claims message

MEDPID Person identification message

MEDPRE Medical prescription message

MEDREQ Medical service request message

MEDRPT Medical service report message

MEDRUC Medical resource usage and cost message

MEQPOS Means of transport and equipment position message

MOVINS Stowage instruction message

MSCONS Metered services consumption report message

ORDCHG Purchase order change request message

ORDERS Purchase order message

ORDRSP Purchase order response message

OSTENQ Order status enquiry message

OSTRPT Order status report message

PARTIN Party information message

PASREQ Travel tourism and leisure product application status request - i

PASRSP Travel tourism and leisure product application status response -

PAXLST Passenger list message

PAYDUC Payroll deductions advice message

PAYEXT Extended payment order message

PAYMUL Multiple payment order message

PAYORD Payment order message

PRICAT Price/sales catalogue message

PRIHIS Pricing history message

PROCST Project cost reporting message

PRODAT Product data message

PRODEX Product exchange reconciliation message

PROINQ Product inquiry message

PROSRV Product service message

PROTAP Project tasks planning message

PRPAID Insurance premium payment message

QALITY Quality data message

QUOTES Quote message

RDRMES Raw data reporting message

REBORD Reinsurance bordereau message

RECADV Receiving advice message

RECALC Reinsurance calculation message

RECECO Credit risk cover message

RECLAM Reinsurance claims message

RECORD Reinsurance core data message

REGENT Registration of enterprise message

RELIST Reinsured objects list message

REMADV Remittance advice message

REPREM Reinsurance premium message

REQDOC Request for document message

REQOTE Request for quote message

RESETT Reinsurance settlement message

RESMSG Reservation message

RESREQ Reservation request - interactive message

RESRSP Reservation response - interactive message

RETACC Reinsurance technical account message

RETANN Announcement for returns message

RETINS Instruction for returns message

RPCALL Repair call message

SAFHAZ Safety and hazard data message

SANCRT International movement of goods governmental regulatory message

SKDREQ Schedule request - interactive message

SKDUPD Schedule update - interactive message

SLSFCT Sales forecast message

SLSRPT Sales data report message

SOCADE Social administration message

SSIMOD Modification of identity details message

SSRECH Worker's insurance history message

SSREGW Notification of registration of a worker message

STATAC Statement of account message

STLRPT Settlement transaction reporting message

SUPCOT Superannuation contributions advice message

SUPMAN Superannuation maintenance message

SUPRES Supplier response message

TANSTA Tank status report message

TAXCON Tax control message

TIQREQ Travel tourism and leisure information inquiry request - interactive

TIQRSP Travel tourism and leisure information inquiry response - interactive

TPFREP Terminal performance message

TSDUPD Timetable static data update - interactive message

TUPREQ Travel, tourism and leisure data update request - interactive message

TUPRSP Travel, tourism and leisure data update response - interactive message

UTILMD Utilities master data message

UTILTS Utilities time series message

VATDEC Value added tax message

VESDEP Vessel departure message

WASDIS Waste disposal information message

WKGRDC Work grant decision message

WKGRRE Work grant request message

HIPPA message types

EDI Health Care Claim Transaction set (837) is used to submit health care claim billing information, encounter information, or

both, except for retail pharmacy claims (see EDI Retail Pharmacy Claim Transaction). It can be sent from providers of health

care services to payers, either directly or via intermediary billers and claims clearinghouses. It can also be used to transmit

health care claims and billing payment information between payers with different payment responsibilities where coordination

of benefits is required or between payers and regulatory agencies to monitor the rendering, billing, and/or payment of health

care services within a specific health care/insurance industry segment.

For example, a state mental health agency may mandate all healthcare claims, Providers and health plans who trade

professional (medical) health care claims electronically must use the 837 Health Care Claim: Professional standard to send in

claims. As there are many different business applications for the Health Care claim, there can be slight derivations to cover off

claims involving unique claims such as for Institutions, Professionals, Chiropractors, and Dentists etc.

EDI Retail Pharmacy Claim Transaction (NCPDP Telecommunications Standard version 5.1) is used to submit retail

pharmacy claims to payers by health care professionals who dispense medications, either directly or via intermediary billers

and claims clearinghouses. It can also be used to transmit claims for retail pharmacy services and billing payment information

between payers with different payment responsibilities where coordination of benefits is required or between payers and

regulatory agencies to monitor the rendering, billing, and/or payment of retail pharmacy services within the pharmacy health

care/insurance industry segment.

EDI Health Care Claim Payment/Advice Transaction Set (835) can be used to make a payment, send an Explanation of

Benefits (EOB) remittance advice, or make a payment and send an EOB remittance advice only from a health insurer to a

health care provider either directly or via a financial institution.

EDI Benefit Enrollment and Maintenance Set (834) can be used by employers, unions, government agencies, associations

or insurance agencies to enroll members to a payer. The payer is a healthcare organization that pays claims, administers

insurance or benefit or product. Examples of payers include an insurance company, health care professional (HMO), preferred

provider organization (PPO), government agency (Medicaid, Medicare etc.) or any organization that may be contracted by one

of these former groups.

EDI Payroll Deducted and other group Premium Payment for Insurance Products (820) is a transaction set which can be

used to make a premium payment for insurance products. It can be used to order a financial institution to make a payment to a

payee.

EDI Health Care Eligibility/Benefit Inquiry (270) is used to inquire about the health care benefits and eligibility associated

with a subscriber or dependent.

EDI Health Care Eligibility/Benefit Response (271) is used to respond to a request inquire about the health care benefits

and eligibility associated with a subscriber or dependent.

EDI Health Care Claim Status Request (276) This transaction set can be used by a provider, recipient of health care

products or services or their authorized agent to request the status of a health care claim.

EDI Health Care Claim Status Notification (277) This transaction set can be used by a health care payer or authorized agent

to notify a provider, recipient or authorized agent regarding the status of a health care claim or encounter, or to request

additional information from the provider regarding a health care claim or encounter. This transaction set is not intended to

replace the Health Care Claim Payment/Advice Transaction Set (835) and therefore, is not used for account payment posting.

The notification is at a summary or service line detail level. The notification may be solicited or unsolicited.

EDI Health Care Service Review Information (278) This transaction set can be used to transmit health care service

information, such as subscriber, patient, demographic, diagnosis or treatment data for the purpose of request for review,

certification, notification or reporting the outcome of a health care services review.

EDI Functional Acknowledgement Transaction Set (997) this transaction set can be used to define the control structures for

a set of acknowledgments to indicate the results of the syntactical analysis of the electronically encoded documents. Although

it is not specifically named in the HIPAA Legislation or Final Rule, it is necessary for X12 transaction set processing . The

encoded documents are the transaction sets, which are grouped in functional groups, used in defining transactions for

business data interchange. This standard does not cover the semantic meaning of the information encoded in the transaction

sets.

ODETTE message types

DELINS - Delivery Forecast / Delivery

EXHAND - For Delivery Schedule Exception Handling

CALDEL - JIT Delivery

SYNCRO – Sequenced Delivery

KANBAN - KANBAN Delivery

FORDIS - 'Ready for Despatch' Advice

AVIEXP - Despatch Advice

INVOIC – Invoice

STOACT - Inventory Report

TRINAD - Forwarding Instruction

CONSUM - Consignment Consolidation

ORDERR - Purchase Order

ORDCHG - Order Change

REPORD - Order Response

PRILST - Price List Based

REMADV - Remittance Advice

STATAC - Account Statement

Oracle ecommerce gateway standards

ADVO - Application Advice

ASNI - Ship Notice and Manifest

CATI - Price and Sales Catalog

CDMO - Credit Memo/Debit Memo

GASNO - Ship Notice and Manifest

GPOI - Purchase Order (for Process Manufacturing)

GPOAO - Purchase Order Acknowledgement (for Process Manufacturing)

INI - Invoice

MVSTO - Movement Statistics

POI - Purchase Order

POCI - Purchase Order Change

POAO - Purchase Order Acknowledgement

POCAO - Purchase Order Acknowledgement

PSQI - Production Sequence

PYO - Payment Order

RRQI - Response to Request for Quotation

SBNI - Shipment and Billing Notice

SPSI - Planning Schedule - Inbound

SPSO - Planning Schedule – Outbound

SSSI - Shipping Schedule - Inbound

SSSO - Shipping Schedule – Outbound

ROSEttaNET PIP message type

3A1 - Request Quote

3A2 - Request Price and Availability

3A3 - Request Shopping Cart Transfer

3A4 - Request Purchase Order

3A5 - Query Order Status

3A6 - Distribute Order Status

3A7 - Notify of Purchase Order Update

3A8 - Request Purchase Order Change

3A9 - Request Purchase Order Cancellation

3A10 - Notify of Quote Acknowledgement

3A13 - Notify of Purchase Order Information

3A14 - Distribute Planned Order

3B1 - Distribute Transportation Projection

3B2 - Notify of Advance Shipment

3B3 - Distribute Shipment Status

3B4 - Query Shipment Status

3B5 - Request Shipment Change

3B6 - Notify of Shipments Tendered

3B11 - Notify of Shipping Order

3B12 - Request Shipping Order

3B13 - Notify of Shipping Order Confirmation

3B14 - Request Shipping Order Cancellation

3B18 - Notify of Shipment Documentation

3C1 - Return Product

3C2 - Request Financing Approval

3C3 - Notify of Invoice

3C4 - Notify of Invoice Reject

3C5 - Notify of Billing Statement

3C6 - Notify of Remittance Advice

3C7 - Notify of Self-Billing Invoice

SAP message type

Message

Type

IDOC Type Description

BENREP BENEFIT1 Benefits Participation

Benefits Retirement Plan

CREADV PEXR2001, PEXR2002 Credit Memo Display

DEBADV PEXR2001, PEXR2002 Debit Advice

DELFOR DELFOR01 Delivery Schedule

DELINS DELFOR01 Forecast Delivery Schedule

DELJIT DELFOR01 Just-In-Time Delivery Schedule

DELORD ORDERS03, ORDERS04, ORDERS05 Delivery Order (Pickup sheet)

DESADV DELVRY01, DELVRY02, DELVRY03 (previously:

DESADV01)

Delivery Shipping Notification

EXPINV EXPINV01, EXPINV02, EXPINV03 Foreign Trade Billing Document

FINSTA FINSTA01 Bank Statement

GSVERF GSVERF01 Self-Billing procedure

IMPINV IMPINV01 Import Basis IDOC

INVOIC INVOIC01 Invoice

LOCKBX FINSTA01 Lockbox

ORDCHG ORDERS01, ORDERS02, ORDERS03,

ORDERS04, ORDERS05

Sales Order Change

Purchase Order Change

ORDERS ORDERS01, ORDERS02, ORDERS03,

ORDERS04, ORDERS05

Sales Order

Purchase Order

ORDRSP ORDERS01, ORDERS02, ORDERS03,

ORDERS04, ORDERS05

Sales Order Confirmation

Purchase Order Confirmation

PAYEXT PEXR2001, PEXR2002 Extended Payment Order

PRICAT PRICAT01 Price List/Catalog

PROACT PROACT01 Stock and Sales Data

QUOTES ORDERS01, ORDERS02, ORDERS03,

ORDERS04, ORDERS05

Quotation

REMADV PEXR2001, PEXR2002 Payment Advice

REQOTE ORDERS01, ORDERS02, ORDERS03,

ORDERS04, ORDERS05

Inquiry

SHPADV SHPMNT03 Shipping Notification

SHPCON DELVRY01 Shipping Confirmation

SHPMNT SHPMNT01, SHPMNT02, SHPMNT03,

SHPMNT04

Shipment Notification

SHPORD DELVRY01 Delivery: Dispatch Order

TXTRAW TXTRAW01, TXTRAW02 Message for free text in SAP office

format

WHSORD DELVRY01 Delivery: Stock Order

SWIFT message types

Message Type Description

Customer Payments & Checks

101Request for Transfer

102 / 102+ Multiple Customer Credit Transfer

103 / 103+ / 103 REMIT Single Customer Credit Transfer

104Direct Debit and Request for Debit Transfer Message

105EDIFACT Envelope

106EDIFACT Envelope

107General Direct Message

110Advice of Cheque(s)

111Request for Stop Payment of a Cheque

112Status of a Request for Stop Payment of a Cheque

121Multiple Interbank Funds Transfer

Treasury Markets--Foreign Exchange, Money Markets & Derivatives

300Foreign Exchange Confirmation

303Forex/Currency Option Allocation Instruction

304Advice/Instruction of a 3rd Party Deal

305Foreign Currency Option Confirmation

306Foreign Currency Option Confirmation

307Advice/Instruction of a 3rd Party FX Deal

308Instruction for a Gross/Net Settlement of 3rd Party FX deals

320Fixed Loan/Deposit Confirmation

321Instruction to Settle a 3rd Party Loan /Deposit

330Call/Notice (Loan/Deposit Confirmation)

340Forward Rate Agreement Confirmation

341Forward Rate Agreement Settlement Confirmation

350Advice of Loan/Deposit Interest Payment

360Single Currency Interest Rate Derivative Confirmation

361Cross Currency Interest Rate Swap Confirmation

362Interest Rate Reset/Advice of Payment

364Single Currency Interest Rate Derivative Confirmation

365

Cross Currency Interest Rate Swap Termination/Recouponing

Confirmation

380Foreign Exchange Order

381Foreign Exchange Order Confirmation

Documentary Credits & Guarantees

700Issue of Documentary Credit

701Issue of Documentary Credit

705Pre-Advice of a Documentary Credit

707Amendment to a Documentary Credit

710Advice of a 3rd Bank's Documentary Credit

711Advice of a 3rd Bank's Documentary Credit

720Transfer of a Documentary Credit

721Transfer of a Documentary Credit

730Acknowledgement

732Advice of Discharge

734Advice of Refusal

740Authorisation to Reimburse

742Re-imbursement Claim

747Amendment to an Authorisation to Reimburse

750Advice of Discrepancy

752Authorization to Pay, Accept or Negotiate

754Advice of Payment/Acceptance/Negotiations

756Advice of Re-imbursement or Payment

760Guarantee/Standby LC

767Guarantee/ Standby LC Amendment

768Acknowledgement of a Guarantee/ Standby LC Message

769Advice of Reduction or Release

Cash Management & Customer Status

900Confirmation of Debit

910Confirmation of Credit

920Request Message

935Rate Change Advice

940Customer Statement Message

941Balance Report

942Interim Transaction Report

950Statement Message

960Request for Service Initiation Message

961Initiation Response Message

962Key Service Message

963Key Acknowledgement Message

964Error Message

965Error in Key Service Message

966Discontinue Service Message

967Discontinuation Acknowledgement Message

970Netting Statement

971Netting Balance Report

972Netting Interim Statement

973Netting Request Statement

985Status Enquiry

986Status Report

TRADACOM message type

Application Reference Message type

ACKHDR Acknowledgement

AVLHDR Availability Report

BTOHDR Book Trade Orders

PVUHDR Book Trade Price/Availability Update

CAKHDR Claims Acknowledgement

CLAHDR Claims Message

CORHDR Complex Order

CREHDR Credit Note

CREADV Credit Advice

CUSHDR Customer Information

DEBADV Debit Advice

DLCHDR Delivery Confirmation

DELHDR Delivery Notice

DYEHDR Dye Instruction

GENHDR General Communication

HSOHDR Home Shopping Orders

INVFIL Invoice

ISSUES Issues

LPRHDR Location Planning Report

PICHDR Picking Instruction

ORDHDR Purchase Order

PAYORD Payment Order

PRIHDR Price Information

PROHDR Product Information

PPRHDR Product Planning Report

RDAHDR Retailer Database

RDBHDR Retail B, 1-4 Retailer Database

RIFHDR Retail Issues File

SADHDR Stock Adjustment

SNPSTS Stock Snapshot

SRMHDR Statement & Remittance Details

SORDET Supply and Returns Details

SORDAY Supply and Returns Summary

SRSHDR Supply and Returns Summary

RIFHDR Retail Issues File

UCNHDR Uplift Confirmation

UPLHDR Uplift Instruction

UTLHDR Utility Bill

VDA message types

4902 - Transport Label Barcode-enabled incl. VDA 4913

4905 - Call off

4905/2 - Call off - Delivery Instruction (Odette Message DELINS)

4906 - Invoice

4907 - Remittance Advice

4908 - Credit Advice

4911 - Prices

4912 - Delivery Note incl. VDA 4913

4913 - Delivery Note

4914 - Odette specification for file transfer

4915 - Detailed Call Off (JIT)

4916 - Call Off Just-in-sequence

4918 - Vehicle Identification and Transport Data

4919 - Vehicle Arrival and Departure Notification

4920 - Forwarding Instruction

4921 - Delivery Data

4922 - Forwarding Instruction incl. VDA 4913

4923 - Enquiry (Odette Message ENQIRY)

4924 - Offer/Quotation (Odette Message OFFERR)

4925 - Purchase Order

4926 - Acknowledgement of Order (Odette Message REPORD)

4927 - Equipment Statement and Equipment Movement

4929 - Delivery Note (Odette Message AVIEXP)

4932 - Invoice (Odette-Nachricht INVOIC)

4951 - Engineering Data Message (ENGDAT)

4970 - Delivery Forecast

4971 - Collection Order

4972 - Dispatch Note ex Works/Plant

4973 - Vehicle Arrival

4974 - Vehicle Departure

4975 - Change / Information Note

4976 - Change / Information Confirmation

4977 - Damage Note

4978 - Repair Start / End Note

4979 - Ready for Dispatch Note

4980 - Loading Instructions

EDI messaging protocols

AS1: Applicability Statement (AS) 1 was developed by the IETF (Internet Engineering Task Force) to implement secure and

reliable messaging over SMTP and S/MIME. It was the first AS protocol to be developed and uses signing, encryption and

MDN conventions. (MDN refers to Message Disposition Notifications or the ability to provide “Return Receipts”). As with any

AS file transfer, AS1 file transfers typically require both sides of the exchange to trade SSL certificates and specific “trading

partner" names before any transfers can take place.

AS2: Applicability Statement (AS) 2 uses the same signing, encryption, and MDN conventions used in the original AS1

protocol. AS2 messages are usually sent across the internet using the HTTP or HTTPS protocol. AS2 has been widely

deployed as a point to point connectivity method. AS2 offers many advantages over standard HTTP, including increased

verification, and security achieved through the use of receipts and digital signatures. AS2 transactions and acknowledgements

also occur in real-time, increasing the efficiency of document exchanges. The U.S company Walmart was one of the first

companies to help drive the adoption of AS2 across the retail sector.

AS3: Applicability Statement (AS) 3 was developed by the IETF to implement secure and reliable messaging over FTP. AS3 is

based upon the secure version of the FTP protocol, rather than HTTP. AS3 transport is S/MIME over FTP and operates a

client/server model like FTP, as opposed to the peer-to-peer approach used by AS2. AS3 also uses MDN’s (receipt

notifications) like AS2. AS3 is a push/pull protocol and the client side AS3 does not require a listener to be always aware of

inbound traffic (whereas AS2 always requires a persistent connection for the listener). AS3 may be especially well suited for

banking and other industries where there are heavy investments in FTP scripting, applications and security.

AS4: Applicability Statement (AS) 4 offers secure B2B document exchange using web services and was developed by the sub-

committee of the OASIS ebXML messaging services technical committee. AS4 is still in its draft definition format. The AS4

profile provides the market place with an entry level solution that allows companies to begin utilizing their internal SOA based

platforms for external B2B messaging while at the same time taking on some of the more complicated aspects of web services.

The European Aerospace industry is proposing to use AS4 as its communication standard for sending ebXML related B2B

documents between trading partners. Further information about AS4 can be found on the Drummond Group site, here.

ebMS: ebXML Messaging Service offers a secure and reliable SOAP/Web Services based packaging, routing and transport

protocol as defined by the ebXML specifications. The ebMS is an open standard and as such is communication protocol

neutral although the most common underlying protocols are HTTP and SMTP. ebMS essentially offers a way to exchange

ebXML based B2B documents between different business applications using SOAP/Web services.

FTP: File Transfer Protocol is a standard network protocol used to exchange and manipulate files over a TCP/IP based

network such as the internet. FTP is built on a client-server architecture and utilises separate control and data connections

between the client and server applications. FTP is also often used as an application component to automatically transfer files

for internal functions within programs. FTP can be used with user-based password authentication or with anonymous user

access.

FTPS: File Transfer Secure Protocol is an extension of FTP which adds support for the Transport Layer Security (TLS) and the

Secure Sockets Layer (SSL) cryptographic protocols. FTPS should not be confused with SFTP, an incompatible secure file

transfer subsystem for the Secure Shell (SSH) protocol. It is also different from Secure FTP, the practice of tunneling FTP

through an SSH connection

HTTP: HyperText Transfer Protocol is used to request and transmit files, especially web pages and web page components,

over the internet or other computer networks. In HTTP, web browsers typically act as clients, while an application running on

the computer hosting the web site acts as a server. HTTP is typically implemented across TCP/IP however it can be

implemented on top of any other protocol on the internet, or on other networks.

HTTPS: HyperText Transfer Protocol Secure is a combination of the Hypertext Transfer Protocol with the SSL/TLS protocol to

provide encryption and secure identification of the server. HTTPS connections are often used for payment type transactions

across the internet and for the exchange of sensitive information between corporate business systems.

OFTP: Odette File Transfer Protocol was developed to offer a standard communication platform for the European automotive

industry and has been in use since the mid-1980s. OFTP has also seen adoption across the retail, white goods,

manufacturing, government, transport, insurance and banking industries to name but a few. The OFTP protocol is very simple

to use, consisting of only fourteen commands. The protocol is extremely efficient, allowing large transmission windows to be

utilized whilst incorporating file restart, data compression and security. OFTP has been designed to allow companies to

communicate easily via point to point connections.

OFTP 2.0: Odette File Transfer Protocol version 2.0 is the latest version of the OFTP standard and has been designed from

the outset to be used across the internet. OFTP2 offers a number of benefits over OFTP including data compression,

exchange of digital certificates (to improve security of transmissions) between trading partners, it allows the handling of very

large files (over 500Gb) and offers support for additional character sets such as Chinese and Japanese. To date, OFTP has

mainly been used in Europe however as OFTP2 has been designed to operate across the internet it can help trading partners

connect to one another all over the world. Many automotive manufacturers in Europe have been running OFTP2 pilot projects

since 2008 and it is expected to be widely deployed across production projects during 2010.

SFTP: Secure File Transfer Protocol is a network protocol that provides file access, file transfer and file management

functionality over any reliable data stream. It was designed as an extension to the Secure Shell protocol (SSH) version 2.0 to

provide secure file transfer capability, but it is also intended to be usable with other protocols as well. SFTP can be used in a

number of different applications such as secure transfer over Transport Layer Security (TLS) and transfer of management

information within VPN applications. This protocol assumes that it is run over a secure channel, such as SSH, that the server

has already authenticated the client and that the identity of the client user is available to the protocol.

EDI by Industry

EDI is used across many different industry sectors, from manufacturing to retail, financial services to transportation, EDI is

applied to address many different business processes and industry challenges. However each industry has a common set of

goals with respect to how EDI is implemented, namely to automate manual paper based processes.

Over the last forty years numerous industry specific document and communication standards have evolved, industry specific

associations and work groups have been established and many private networks have been set up to meet the demands of

companies looking to provide tighter integration to their supply chains.

The following links will provide a high level overview of how EDI is applied across each industry sector and discuss the more

important EDI documents in use today. Each industry page will also highlight relevant industry associations,

document/communication standards and private networks that exist within each industry sector.

Automotive

High Tech

Financial Services

EDI for Automotive Industry

EDI has been in use across the automotive industry for over forty years. The smooth running of today’s car production lines

rely on the seamless exchange of business documents between the car manufacturers and their supply chain. Many of the

business processes used in the manufacture of today’s cars were developed from a production system devised by Toyota in

Japan. A number of best practices were developed around the ‘Toyota Production System’, for example Just-In-Time and Lean

Manufacturing. JIT and Lean Manufacturing processes are central to the smooth running of many production lines around the

world and EDI provides a fast and efficient way to transfer business documents in order to support these types of

manufacturing processes. Providing visibility of inventory levels and notification of when shipments are due to arrive at the

production line are critical to making JIT and Lean manufacturing processes a success.

The global nature of the automotive industry means that it is important for car manufacturers to be able to onboard their

suppliers as quickly as possible, no matter where they may be based around the World. Many car manufacturers have

established a manufacturing presence in for example Eastern Europe, Brazil and China and it is important to ensure that

suppliers located in these regions are able to exchange EDI documents as smoothly as possible. ICT skills across low cost or

emerging markets are traditionally very low therefore the car manufacturers must ensure that they can provide simple to use

EDI tools that allow even the smallest suppliers to be able to trade electronically.

Due to the global nature of the automotive industry, there are numerous communications and document standards in use

today, along with a number of regional specific EDI networks. The structure of the automotive supply chain and a description of

the communication protocols and document standards used are described below.

Supply Chain Structure

The automotive industry has a ‘tiered’ supply chain structure which is best illustrated by way of the diagram shown below.

Upstream from the car manufacturer or OEM are the Tier 1 suppliers, these companies will typically supply some of the largest

components or sub-systems for the cars, for example a suspension assembly or gearbox. Moving downstream the Tier 2

suppliers typically provide components to the Tier 1 suppliers and these could for example be pump units, electric motors or

bearing assemblies. Then further downstream you have the Tier 3-x suppliers who will provide the Tier 2 suppliers with

anything from brackets, seals through to machined components etc.

As the Tier1 suppliers are the most important to the car manufacturers they will typically have a plant close to the car

manufacturers to support Just-In-Time type production processes. Tier2 – x suppliers could be based anywhere in the world

and many companies in this particular sector have established a manufacturing presence in low cost countries around the

world, for example China and India. In addition to the tiered suppliers there are also raw material providers such as the steel

manufacturers who will provide sheet products directly to the car manufacturers.

Downstream from the OEMs the third party logistics (3PL) providers will distribute finished vehicles to storage compounds and

vehicle distribution hubs located around the world. These will then get shipped to the dealer networks as and when required.

Communication Protocols Used

The automotive industry uses a number of standard communication protocols such as FTP, but in Europe the main

communication protocol is use today is OFTP, Odette File Transfer Protocol. OFTP has been used across the European

automotive industry since the mid 1980’s and most of the car manufacturers are using this protocol to communicate with their

trading partner community. With the introduction of the internet many car manufacturers have been working with the Odette

organisation to try and bring the OFTP standard up to date and a new release called OFTP v2.0 was introduced to the

automotive market in 2010. This new version of OFTP has been designed from the outset to be used across the internet and it

offers secure exchange of documents using encryption and the exchange of digital certificates. OFTP2 also allows large files

such as Computer Aided Design files to be exchanged with ease. Exchange of CAD files is a common problem within the

automotive industry due to the sensitive nature and large size of the files being transferred.

Document Standards Used

In addition to the more traditional EDI documents such as ANSI X12 and EDIFACT, a number of regional standards have been

used to support the car manufacturers in Europe. For example, in France the Odette standard is used quite widely among car

manufacturers such as PSA Peugeot Citroen and in Germany the VDA organisation has written a set of document standards to

suit BMW, Daimler AG and VW Group. The use of webEDI solutions is common across the automotive industry as it allows

small trading partners to exchange business documents with the car manufacturers. To avoid car manufacturers establishing

webEDI portals, each having a different look and feel, the Odette organisation in Europe has developed a standard for how the

webEDI forms should be laid out on a web page. Odette Forms Version 2 is the current standard is use today and webEDI

solution providers typically have to be certified against this forms standard before their solution is homologated by the Odette

organisation.

Industry Associations

The automotive industry is served by a number of industry associations. These associations are tasked with providing

standards for how automotive companies exchange information electronically with each other. Due to global expansion in

recent years, the industry associations around the world are starting to work more closely with each other to allow the

automotive companies to setup new plants and onboard new trading partners as quickly as possible.

The automotive industry associations are located in the main manufacturing hubs around the world, for example North

America, Europe and Japan. They actively work to get the automotive companies in their respective regions to become

members of their associations and to contribute to the various working groups and projects that are undertaken. Typical

projects include Materials Management Operations Guideline and Logistics Evaluation (MMOG/LE), OFTP2, Materials Off-

Shore Sourcing (MOSS) project. The work of the industry associations provides the ideal environment to beta test these

projects before they are deployed in production across the automotive industry.

Some of the main industry associations include Odette which serves the European automotive industry. Within this group the

VDA organisation serves the requirements of the automotive companies based in Germany and Galia serves the automotive

companies in France. The Automotive Industry Action group (AIAG) serves the North American automotive industry and the

Japanese Automotive Manufacturers Association (JAMA) serves the Japanese automotive industry.

Industry Specific Networks

In addition to the traditional EDI VAN providers, the automotive industry is served by a number of regional private networks.

The most popular networks are the American Network eXchange (ANX), European Network eXchange (ENX) and the

Japanese Network eXchange (JNX). These networks provide a very secure method of exchanging information across an

automotive community and in Europe for example ENX is used to provide the quick exchange of engineering design or

Computer Aided Design files. Even though the networks were originally developed to service the regional requirements of the

automotive companies, their global expansion has meant that there has been a need to provide connectivity to these individual

networks. GXS provides interconnectivity between the various private networks allowing the automotive companies to

exchange information seamlessly across the world.

EDI for Financial service industry

The success of the financial services industry relies on its ability to process payables and receivables, as well as manage

investments and loans on behalf of its customers both retail and wholesale. For years many of these processes were manual

and paper intensive. However, the introduction of EDI has allowed the financial services industry to automate many of the

transactions required to transmit payment and remittance data from one party to another.

As a result of the economic upheaval of the past few years, the world has come to recognise and appreciate the

interdependent nature of the global financial infrastructure. The financial supply chain has become a reality for global business

as buyers from one geography rely on goods from suppliers based in other regions that utilise different currencies and are

governed by different regulations. EDI provides not only a low cost alternative to traditional paper-based payment

methodologies but also enables organisations to realise faster, more accurate and more flexible payment structures in the

course of doing business.

EDI enables the full alignment of the financial supply chain with the movements of the physical supply chain. A fully automated

financial supply chain enables the seamless, accurate and timely exchange of financial documents between buyers, suppliers

and their financial institutions. With EDI an organisation can electronically transfers funds from one bank account to another

designated bank account or counterparty. Electronic payments are processed to allow organisations to have access to funds

more quickly and with fewer exceptions or delays due to human error.

Due to the global nature of the financial services industry, there are numerous communications and document standards in use

today, along with a number of regional specific EDI networks. The structure of the financial supply chain and a description of

the communication protocols and document standards used are described below.

Supply Chain Structure

All industries utilise some version of a supply chain to track the flow of goods and services it uses and produces. The financial

services industry is no different. Financial transactions are an integral component of the physical supply chain. By connecting

trading partners from order placement to settlement, the financial supply chain carries the flow of financial information and

money in the direction opposite to the flow of goods and services.

The financial supply chain is one that is closely aligned with and triggered by processes in the physical supply chain as

demonstrated by the diagram shown below. Financial supply chain services include transactions related to purchase order

processing, Letter of Credit, open account management, pre & post shipping financing, reconciliation, invoice presentment,

dispute management, foreign exchange and insurance management.

Buying firms initiate the process when they begin to source materials and/or finished goods from suppliers within their supply

chain. Financial institutions may help advise the buyer on issues related to credit and financing. Once an order is placed the

financial institution may provide partial payment against the negotiated terms or supply an approved letter of credit to show the

supplier that the buyer has the means to pay once production begins. Once the goods are produced and shipped, the financial

institution may help insure the goods and upon receipt settle the account according to the terms of the contract. The financial

institution may also help the buyer to forecast cash flow based on cash management services it may provide to the buyer. The

financial institution may also help to reconcile disputes, validate data related to the goods and finally release funds and

remittance detail.

Communication Protocols Used

EDI is widely used by the financial services industry for electronic funds transfer (EFT) between financial institutions, which

facilitates such common transactions as the direct deposit of payroll cheques by employers, the direct debit of consumer

accounts, and the electronic payment of government taxes by businesses. With the increasing emphasis on security, the

financial services industry has added a number of secure communication protocols to use along with the more common ones

used for other industries. While many organizations utilise FTP and FTPs, others in use in the financial services industry

include AS1, AS2 and AS3, HTTP, HTTPs as well as ebXML for varying parts of their organisation. However, others rely on

other protocols to enable both domestic and international transactions for payments, cash, trade and securities. The

predominant communications platform for financial transactions between financial institutions is SWIFTnet.

Financial Information eXchange (FIX) protocol is an electronic communications protocol initiated in 1992 for international

real-time exchange of information related to the securities transactions and markets. In Europe, specifically in France and

Germany, EBICS is gaining in acceptance as the transmission protocol for business-to-bank communication using the XML

format which supports the Single Euro Payments Area (SEPA) initiative to standardise clearing protocols in the interbank

networks.

Document Standards Used

In addition to traditional EDI documents such as ANSI X12 and UNI/EDIFACT, the most popular standards for treasury, cash

management and payments are ISO XML, SAP iDocs, ORACLE, BAI, NACHA and ROSETTANET. With the rise in XML-

based standards, organisations such as RosettaNet, a non-profit consortium aimed at establishing standard processes for the

sharing of business information are becoming more common in the financial services space due to their usage by participants

in the physical supply chain. The RosettaNet standard defines message guidelines, business processes interface and

implementation frameworks for interactions between companies usually in the supply chain area, but also manufacturing,

product and material data and service processes. However, the Society for Worldwide Interbank Financial Telecommunication

(SWIFT) is the dominant standard by which financial data is exchanged worldwide. SWIFT is a member-owned cooperative

that includes more than 9,000 banking organisations, securities institutions and corporate customers in approximately 209

countries around the globe.

Standards are a core element of SWIFT's services and are designed to enable communication and collaboration between

banks and their corporate customers. SWIFT provides standards for multiple business transactions including payments, trade

services, securities and corporate actions. The most common SWIFT message standards are MT and MX.

Industry Associations

Due to the economic meltdown, the industry organisations that help automate, standardise and centralise financial data are

more widely known than ever. A number of industry associations that cover the standards, communication protocols, formats

and architectural structure used to exchange information electronically between financial institutions as well as between the

financial institutions and their corporate clients. Among the most recognised organisations are those that develop and oversee

standards. Standards organisations are responsible for associations used around the world. Some of the most widely known

standards organisations include SWIFT, ISO, NACHA, BIAN and TWIST. The International Organisation for Standardisation

(ISO), is an international-standard-setting body composed of representatives from various national standards organisations.

Founded on 23 February 1947, the organisation promulgates worldwide proprietary industrial and commercial standards. It has

its headquarters in Geneva, Switzerland.

NACHA is a national, not-for-profit organisation that develops operating rules and business practices for electronic payments.

Members of this organisation define the rules covering the Automated Clearing House (ACH) network in the United States.

While NACHA has largely set the standards for electronic payments for business-to-business transactions in the United States,

there are numerous global variants including NACHA has largely set the standards for electronic payments.

The Transaction Workflow Innovation Standards Team (TWIST) is another industry group designed to close the gap between

the physical and financial supply chain. By helping to rationalise financial industry standards, TWIST advocates open

standards for the creation of user-driven, non-proprietary and internally consistent XML-based standards for the financial

supply chain. TWIST standards help to automate business process and information flows where multiple parties have to

interact and synchronise their business processes.

In addition to standards organisations, there are some organisations such as the Banking Industry Architecture Network (BIAN)

that focus on accelerating the adoption of Service Oriented Architecture (SOA) in the banking industry by promoting

convergence towards a common services landscape and the adoption of semantic standards to ease integration.

Industry Specific Networks

The financial services industry has long utilised industry specific networks to exchange data in a secure fashion. The industry

standard is largely regarded as the SWIFT network. With more than 9,000 member banks and financial institutions, the Society

for Worldwide Interbank Financial Telecommunication (SWIFT) is the most widely used network for exchanging financial data.

In addition to SWIFT, however, many banks and corporates also use some variation of the ACH network.

Automated Clearing House (ACH) is an electronic network for financial transactions that originated in the United States. There

are similar clearing and settlement systems for electronic payments including state and regional networks such as the

Wisconsin Automated Clearing House Association (WACHA) and the Mid-Atlantic Clearing House Association (MACHA) as

well as global variations such as the Bankers' Automated Clearing Services (BACS) and Clearing House Automated Payment

System (CHAPS) in the United Kingdom, scheme for the electronic processing of financial transactions, the Pan-European

Automated Clearing House (PE-ACH) which is an ACH that is able to settle SEPA compliant credit transfers and direct debits

across the Eurozone. In Japan the Zengin system is just one of three clearinghouses, operated by the Japanese Bankers

Association to handle domestic fund transfers. China also has three clearing systems which are: The Electronic Interbank

System (EIS), Electronic Funds Transfer System (EFT), and the Local Clearing House (LCH).

Even though all of these networks were developed and customized to meet regional requirements, in September 2009,

NACHA—the governing body of the U.S. ACH Network—adopted new rules for international ACH transactions (IAT) to

facilitate easier cross-border transactions. IAT may be the first step towards global ACH as envisioned by some of the largest

global banks.

EDI for High Tech Industry

EDI has been in use across the high tech industry for many years. The high tech value chain has become very complex with

many high tech companies relying on external partners to help design and manufacture their products. Due to the nature of the

high tech industry there has been a desire to try and exchange business transactions electronically, more so than many other

industry sectors.

The high tech industry is very consumer driven which has meant that high tech supply chains have had to become flexible to

changing consumer demands. There has also been an increasing demand for introducing Vendor Managed Inventory systems

to ensure that retailers have the correct levels of inventory to support for example new product launches or seasonal

fluctuations in consumer demand. For this reason inventory visibility across retail networks and multi modal logistics networks

is important for both the high tech companies and their trading partner community.

As with companies in the automotive industry, many high tech companies have globalised their operations to take advantage

of low cost suppliers in many of the emerging markets around the world. This has meant that the high tech manufacturing

companies have had to ensure that they can trade electronically with suppliers in any country around the world, even those

with limited ICT related skills. The provision of simple to use, quick to deploy and easy to maintain EDI tools is very important

for high tech companies.

Supply Chain Structure

The high tech industry has the most complex supply chain structure of any industry sector. Whereas the automotive industry

for example has a tiered and fairly logical structure, the high tech industry is very matrix structured by comparison. The industry

relies on the use of many outsourced design consultancy and contract manufacturers, known as Electronics Manufacturing

Service companies. To give you an idea of how prevalent contract manufacturing has become within the high tech industry,

Cisco one of the world’s leading providers of networking based solutions does not manufacture any of their own equipment. All

of Cisco’s products are manufactured by outside contractors. So you could say that Cisco has become a ‘branded integrator’,

responsible for the design and marketing of their products, but the actual manufacture of their goods is handled by external

EMS providers. This model is common across many high tech companies now including one of the world’s leading high tech

consumer brands, Apple.

In order to try and explain how the high tech supply chain is structured, the following diagram illustrates the key players across

both the supply and demand chain. On the supply side there are the fabless semiconductor manufacturers, these companies

will typically design the semiconductor chips but will then outsource the manufacture of the chips themselves to a specialist

chip manufacturer such as Global Foundries who in turn will source their materials from the raw material providers. Once the

chips or other electronic components are manufactured they will be distributed to a number of strategically located distribution

hubs so that they can ship the components to the EMS or contract manufacturers as and when required. Meanwhile on the

demand side of the chain the OEMs such as Dell, HP and Cisco work in partnership with a number of contract manufacturers

such as Celestica, Flextronics and Jabil. These contract manufacturers will be responsible for either designing the entire

product, to which the OEM would simply apply their logo or they will build a number of sub-systems that make up the final

product. It is not unusual for an OEM to work with many different contract manufacturers in order to manufacture one product.

Once these products are manufactured they are shipped via specialist high tech distributors such as Avnet and Arrow to the

OEM’s storage and distribution facilities before finally being forwarded to retailers or resellers. The diagram below illustrates

both inventory and information flows across the high tech value chain.

Being able to exchange business documents across a relatively complex and fast moving supply and demand chain is

important to the smooth running of these high tech operations. Due to the number of contract manufacturers, design partners,

logistics partners and retailers etc that are involved across this value chain, (across geographically dispersed plants and

offices), means that it is important to work with an EDI or B2B vendor that can support a complex and global value chain such

as this.

Document Standards Used

In addition to the more common standards such as ANSI X12 and EDIFACT the high tech industry has had some success with

trying to develop an industry standard based around XML. At the height of the dotcom boom in the early 2000s a number of

new XML standards were developed to meet the needs of companies working across the high tech industry. RosettaNet is the

most popular XML standard in use today however it tends to be used in parallel with the more established EDI document

standards such as ANSI X12 and EDIFACT. RosettaNet has developed XML standards to cover the procure-to-pay and order-

to-cash process spectrum. Partner Interface Processes (PIPS) are the XML based documents that form the basis of the

RosettaNet standard. RosettaNet is a subsidiary of GS1 US and has around 500 members worldwide.

Another standard that has been successfully deployed across the high tech is the Open Applications Group Integration

Specification (OAGIS). Developed by the Open Applications Group, OAGIS is an effort to provide a canonical business

language for information integration. It uses XML as the common way of defining business messages and for identifying

business processes that allow businesses and business applications to communicate with each other. OAGIS is one of the

most complete set of XML business messages currently available, but it also accommodates the additional requirements of

specific industries by partnering with various vertical industry groups.

Industry Associations

Over the past few years the high tech industry has been served by a number of industry associations. EDIFICE is the leading

high tech industry association in Europe and they have been supporting the development of B2B standards and working

practices for nearly twenty five years. This particular association runs four plenary sessions per year, in different locations

around Europe, and each of the member companies has an opportunity to sponsor a plenary session. Leading high tech

companies such as Microsoft, ST Micros, Cisco, Sun Microsystems and Motorola are all members of EDIFICE. The

convergence of the automotive and high tech supply chains has led to the signing of a memorandum of understanding

between the automotive industry’s Odette organisation and EDIFICE. It is hoped that this new partnership will help to develop

new B2B standards across both industries.

Following the success of EDIFICE, a sister organisation has been established to service the needs of the high tech companies

in the Far East. AsiaB2B was established in 2009 and serves the same purpose as EDIFICE in Europe, that is to develop new

best practices for exchanging B2B documents across high tech companies in the Asia Pacific region.

In North America, one of the most active industry associations serving the high tech industry has been the Computer

Technology Industry Association, COMPTIA.

EDI AT WORK

This section of the microsite highlights a number of companies that have successfully deployed EDI solutions from GXS. The

first section highlights how small to medium-sized companies have taken the first steps to implementing an EDI solution. The

following case studies illustrate how EDI has allowed these companies to begin trading electronically with their respective

customers and highlights the business benefits gained.

As a fresh produce importer, grower and food ingredient supplier, J.O. Sims serves major retailers, fresh produce markets and

food manufacturers. The U.K. company needed a system that would automatically handle orders, but that would be easy to

learn and use.

Download »

A specialty tools and equipment manufacturer responded to a customer's request for EDI, and found even more advantages in

its own operations.

Download »

Monarch Towel Company

Monarch Towel Company is a robe and towel distributor based in New Jersey that offers robes, towels and slippers that

combine exacting manufacturing with high-quality materials designed primarily for hotel use. Using Trading Grid Messaging

Service, Monarch Towel Company was able to go international by serving as a logistics warehouse for a Brazilian factory.

Download »

Organic Farm Foods

With a policy of ongoing investment in IT, and constant focus on ways to cut costs and improve efficiency across the supply

chain, U.K. based Organic Farm Foods is a pioneer in technology initiatives within the fresh produce industry.

Download »

G.H Meiser

Like other smaller companies, this manufacturer of precision gauges found its customers increasingly interested in receiving

documents via EDI, yet each customer had unique requirements.

Download »

The following case studies focus on companies who are more global in nature; they illustrate how they have successfully

deployed EDI to allow them to manage their supply chains around the world. The case studies also highlight the benefits of

integrating with back-office systems to provide a truly integrated EDI system. Even though some of these case studies show

how complex EDI systems can become, it is important for the smaller companies to understand how they might fit into a large

global company’s supply chain and how they must adhere to various industry standards in order to conduct business with

them.

One of Europe’s leading consumer electronic retailers, Dixons sought a means to improve communications, speed processes

and increase efficiency in its dealings with suppliers.

Download »

Even though the automaker’s large suppliers were using EDI, it would take weeks to process some orders because small

suppliers still relied on paper. Chrysler needed an inexpensive EDI solution for small, low-volume suppliers.

Download »

FedEx Corp., the premier global provider of transportation, e-commerce and supply chain management services, chose GXS

to support more than 100 million electronic transactions and deliver nearly five million shipments every day.

Download »

This global leader in photography, imaging and scanning was searching for a solution that could provide a complete B2B

integration solution combining services with fully SAP-certified products.

Download »

Liz Claiborne apparel and accessories are available at more than 22,000 different retail locations throughout the world.

Whether supplier or customer, large or small, local or international, Liz Claiborne must communicate seamlessly with all its

trading partners and maintain agility to continuously add new partners to its supply chain.

Download »

Wholly owned by the UK Government, Royal Mail has annual sales in excess of eight billion pounds and delivers some 82

million items to 27 million addresses each day. Integrated communications from GXS are key to its success.

Download »

WH Smith is one of the UK's largest retailers, with 543 high street stores and 203 retail units in 129 airports and train stations.

WH Smith introduced GXS Managed Services because it helped increase the speed at which the business could operate,

streamlining and enhancing services in a number of operational areas.

Download »

JC Penney Company Inc.

One of the US’s largest department store, drugstore and catalogue retailers, JC Penney turned to GXS to enable the retailer to

track shipments using scanning technology, label shipments with barcodes, and send Advance Ship Notices (ASNs).

Download »

Bsteel

Bsteel is the IT business unit of Shanghai-based Baosteel Group, the largest iron and steel producer in China. They deploy

and manage Baosteel’s global B2B e-commerce strategies. Using GXS Enterprise Gateway and Trading Grid Messaging

Service solutions Bsteel provides a unified platform for integrating Baosteel’s internal business units, customers and suppliers

around the world to support data gathering, translation and integration into their forecast to payment supply chain execution.

Download »

A

Abstract Data Type: a mechanism provided by Extensible Markup Language schemas to force

substitution for a particular element type. When an element or type is declared to be ‘abstract’ it cannot

be used in an instance document. A member of that element’s substitution group must appear in the

instance document.

Accredited Standards Committee X12: The group authorised by the American National Standards

Institute to develop and maintain the EDI Standards used primarily in the United States. (See also: ANSI;

ANSI ASC-X12; American National Standards Institute).

Acknowledgement: In the global data synchronization process, this is an Extensible Markup Language

response to a command returned to the originator. Every command needs a response. Acknowledgement

messages are standardised and may contain the following information: confirmation of messag e receipt,

success/failure of processing for syntax and content, or reason code for each type of failure.

ACH: Automated Clearing House.

Active Tag: A class of RFID tag that contains a power source, such as a battery, to power the

microchip’s circuitry. Active tags transmit a signal to a reader and can be read from 100feet or more.

Advance Shipping Notice (ASN): An electronic version of a printed packing slip that tells a buyer that

goods have been shipped, how they have been packed items and the estimated arrival time. Also

referred to as a Delivery Notice or Dispatch Advice.

AES: Advanced Encryption Standard. One of a number of standards for securing data during

transmission by encrypting it.

American National Standards Institute (ANSI): The national standards body for the United States.

ANSI, through its accredited standards committees, keeps the standards for all applications of technology

and mechanics for U.S. Industry. Business documents in the U.S are often referred to by their ANSI code

such as 850 (PO), 810 (Invoice) and 856 (ASN).

ANA: Article Number Association, an association of businesses set up to facilitate standardisation across

the supply chain.

ANSI ASC X12: American National Standards Institute, Accredited Standards Committee X12, which

comprises government and industry members who create EDI standards for submission to ANSI for

approval and dissemination.

ANX: The IP-based network for the US automotive industry.

AANX: The IP-based network for the Australian automotive industry.

Application Acknowledgment: A transaction set whose purpose is to return a response to a transaction

set that has been received and processed in an application program. For example, the Purchase Order

Acknowledgment transaction is used to respond to the Purchase Order transaction with content such as

whether the receiver can fulfil the order and if it can be done on time.

Application Advice: A transaction set that accepts, rejects or identifies errors in the content of any

transaction set beyond normal syntax checks.

Application Interface Software: Software that imports and exports data between in-house applications

and the translation software.

AS1: Applicability Statement (AS) 1. A protocol developed by the IETF to implement secure and reliable

messaging over SMTP.

AS2: Applicability Statement (AS) 2. A newer protocol developed by the IETF to implement secure and

reliable messaging over HTTP. Allows data to be sent over the Internet using the HTTP protocol.

AS3: Applicability Statement (AS) 3. The most recent protocol developed by the IETF to implement

secure and reliable messaging over FTP.

AS4: Applicability Statement (AS) 4. Offers secure B2B document exchange using web services. AS4

was developed by the sub-committee of the OASIS ebXML.

ASN: See Advance Ship Notice.

Asynchronous: A communication technique by which each character is sent bit-serially and is

surrounded by start and stop bits used to indicate character borders.

Attribute: A term used to describe a characteristic of an item. An attribute would hold a value to describe

a characteristic such as pack height, length or width.

Audit trail: A computerised or manual record of transactions.

Authentication: A mechanism that allows the receiver of an electronic transmission to verify the sender

and the integrity of the content of the transmission through the use of an electronic "key" or algorithm

shared by the trading partners. The algorithm is sometimes referred to as an electronic or digital

signature.

« back to top

B

BAI: A Financial Services Group responsible for defining the Cash Management Balance Reporting

Specifications. BAI1 and subsequently BAI2 were defined as the basis for agreement between a bank

and its corporate customer on how data from the bank’s account processing software would be

communicated to the customer’s account processing software.

Bar Code: An array of' rectangular marks and spaces in a predetermined pattern. Usually used for

automatic product or shipment identification.

Batch Control Totals: Ensures that batch processing has been performed correctly by comparing output

to currency or quantity totals, record or document counts, or hash totals.

Batch Processing: The processing of computer information after it has accumulated in one group or

batch.

Baud: The rate at which the signal changes when data is transmitted. It is often the same as the number

of bits per second.

Bill of Lading: A document that is used by a vendor and a freight carrier that describes the freight

classification of the goods being shipped by the vendor.

Binary: A system of numerical notation in which only the values of 0 and 1 are used.

Bisynchronous: A communication protocol whereby messages are sent as blocks of characters. The

blocks of data are checked for completeness and accuracy by the receiving computer.

Business Document: A set of information components that are interchanged as part of a business

activity.

Business Process: A set of related activities that, when correctly performed, will satisfy an explicit

business goal.

Business Process Modelling: Also called ‘as is’ modelling, a component of the RosettaNet concept

development used to identify the elements of a business process and create a clearly defined model of

trading partner interfaces as they exist today.

Business to Business: The practice of buying and selling between companies through the use of

electronic transactions.

Business to Business Integration: The secured coordination of business information among companies

and their information

« back to top

C

CEDI: The Common EDI Forum, which has developed a set of message implementation guidelines for

the UK’s grocery industry.

CEFACT: Also known as UN/CEFACT. The United Nations Centre for Trade Facilitation and Electronic

Business.

CONTRL: A message which is the EDIFACT equivalent of the Functional Acknowledgement (FA).

CPFR: Collaborative Planning, Forecasting and Replenishment. An industry initiative focused on

improving the partnership between manufacturers and distributors/retailers through shared information.

Classifier: A term used to describe how items such as products are grouped.

Clearing House: A third party used for centralising the sending and receiving of electronic messages or

documents between trading partners. Messages/documents are held by the third party until the receiver is

available to receive them.

Communications: The means of electronically linking two computers to exchange information.

Communication Software: Programs that allow computers to communicate through modems. Some are

capable of automatic communications, such as auto-dial and auto-answer.

Compliance Checking: Checking process used to ensure that a transmission complies with ANSI X12

syntax rules (US).

Conditional (C): A data element requirement designator that indicates that the presence of a specified

data element is dependent on the value or presence of other data elements in the segment. The condition

must be stated and must be able to be computer-processed.

Confirmation: A notification that the transmission has been received by the intended receiver. [See also

Functional acknowledgment].

Consumer Packaged Goods: Consumer packaged goods are consumable goods such as food,

beverages, footwear, and apparel, tobacco, and cleaning products.

Continuous Replenishment Program: The concept of continuous supply of goods between supplier

and trading partner based on automated exchange of current demand, inventory, and stock management

information, within the framework of an agreed supply policy. The aim of continuous replenishment is to

achieve a responsive and precise flow of product to the store with minimum stock holding and handling.

Control Envelope: Used to validate the receipt of correct and complete data.

Control Number: Also known as reference number. An identification number used to distinguish a

standard data element (data element identifier) or a standard segment (segment identifier).

Control Segment: A control segment that has the same structure as a data segment but is used for

transferring control information for grouping data segments.

Control Structure: The beginning and end (header and trailer) segments for entities in EDI.

Control Validation: Confirmation that information within the control segments is correct.

« back to top

D

Data Element: One or more data items, forming a unit or piece of information as defined in the data

dictionary of a system of EDI Standards, and contained in an EDI message or transaction set. The term

"data element" is often abbreviated as "DE" followed immediately by the data element number (i.e., data

element 128 would be abbreviated as DE128) in some texts.

Data Element, Composite: Two or more related data items separated by a delimiter character, grouped

together to form a unit or piece of information as defined in the data dictionary of a system of EDI

Standards, and contained in an EDI message or transaction set.

Data Segment: Intermediate unit of information in a message. A segment consists of a pre-defined set of

functionally related data elements which are identified by sequential position within the set.

Data Segment Directory: Publication that shows the format of all segments in the standard.

Data Synchronisation: Data synchronisation is the electronic transfer of standardised product and

location information between trading partners and the continuous synchronisation of that data over time.

Data pool: a GDSN-compliant mechanism for trading partners to share and synchronize data. As well as

storing product data, a data pool provides the necessary functions and workflow to communicate with the

GLOBALRegistry and with other data pools.

Decryption: The translation of scrambled or secretly coded data at the receiving end of an encrypted

transmission (See also Encryption).

Dedicated Line: A point-to-point line in a data communication system between two computer devices

that is always connected.

Default Settings: Instructions to a computer, automatically establishing standard configurations at the

time of logon. They eliminate the need to reconfigure at each sitting.

DELFOR: Delivery Forecast message.

Delivery Notice: European term for an ASN.

Delimiters: Integral part of the transferred data stream, they consist of two levels of separators and a

terminator. Delimiters are specified in the interchange header. From highest to lowest level, the

separators and terminator are:- segment terminator, data element separator, and component element

separator (used only in EDIFACT).

Delivery Trailer Manifest: A list of shipments contained on a less-than-truckload trailer ready for

delivery. The list includes information relevant to the delivery of the shipments loaded in the trailer, such

as pro number, equipment identification and date available.

DELJIT: Delivery Just in Time message.

DES: Data Encryption Standard. One of a number of standards for securing data during transmission by

encrypting it.

DESADV: Despatch Advice Message.

Digital Certificate: A computer based record or electronic message issued by an entity that (1) identifies

the entity issuing it; (2) names or identifies a certificate holder; (3) contains the public key of the certificate

holder; (4) identifies the certificate’s validity period and (5) is digitally signed by the entity issuing it.

Digital Signature: An electronic signature that can be used to authenticate the identity of the sender of a

message and via the encrypted document digest, to ensure that the original content of the data that has

been sent is unchanged.

Direct Connect EDI: A form of EDI which does rely on an intermediary, see point-to-point.

DISA: Data Interchange Standards Association. The trade organisation that acts as secretariat for ANSI

ASC X12 and the Pan-American EDIFACT Board in the United States.

Download: The process of receiving data from another computer at a remote site onto the computer

under the control of the operator.

DSD: Direct Store Delivery. The practice of delivering product directly to store and notifying the store of

the delivery electronically rather than by paper.

DSS: Decision Support System. Software designed to assist in decision-making by providing analytical

programs and data available on mainframes by linking computers to mainframes.

DSTU: Draft Standard for Trial Use. A standard approved by the ANSI ASC X12 committee prior to full

approval by ANSI.

DUNS number: Dun & Bradstreet identification number often used in EDI transmissions.

« back to top

E

EAI: Enterprise Application Integration. A term used to describe software tools that support integrating

applications across a company or enterprise.

EAN: International Article Numbering Association.

EANCOM: A subset of EDIFACT messages, developed by GS1, to allow trading partners to exchange

commercial documents in a simple, accurate and cost effective manner.

ebMS. ebXML Messaging Services. The secure, reliable method of transmitting electronic data defined

as part of the ebXML specifications. It can use a variety of low level transmission protocols including

HTTP and SMTP.

ebXML: A standard for an e-business framework that enables enterprises of any size, in any location to

meet and conduct business electronically. Developed under the auspices of OASIS and UN/CEFACT

EDI: See Electronic Data Interchange.

EDI Translation: The conversion of application data to and from a standard format.

EDI Translator: Computer software used to perform the conversion of application data to and from a

standard. Usually licensed rather than developed in-house. May have subsystems for mapping, auditing,

and document management.

EDIFACT: Electronic Data Interchange For Administration, Commerce and Transport. The international

EDI Standard as developed through the United Nations.

EDIFICE: B2B industry group in high tech and electronics industries in Europe. Also EDIFACT EDI

standard subset for those industries.

EDI over the Internet: A protocol for exchange of information in a decentralized, distributed environment

designed by the Internet Engineering Task Force. Originally developed to transmit Electronic Data

Interchange via email over the Internet. Applicability Statement 1, the first version, used Simple Mail

Transport Protocol as the transport protocol, bouncing direction to get to the end connection. Applicability

Statement 2, the current version, uses Hypertext Transport Protocol to build a tunnel to the recipient

address, establishes the connection, and then sends the information in a secured environment assuring

the sender of receipt.

EFT (Electronic funds transfer): Electronic payment in which funds are transferred between bank

accounts at different financial institutions.

EIAJ: Japanese EDI standard.

Electronic Commerce: Conducting business between computers through the use of digital exchange.

Electronic Data Interchange (EDI): The computer-to-computer transfer of business transaction

information using standard, industry-accepted message formats.

Electronic Mail: The process of sending, receiving, storing, and/or forwarding messages in digital form

via telecommunication.

Element: The smallest item of information in the standard.

Element Delimiter: Single character delimiter; follows the segment identifier and each data element in a

segment except the last.

Element Reference Number: The number that identifies each element from the segment diagram with

its corresponding definition in the data dictionary.

E-Mail: The standard abbreviation for Electronic Mail.

Encryption: The process of transforming clear text (data in its original form) into cipher text (the output of

a cryptographic algorithm) for security or privacy.

End-User: Anyone who uses a computer system or its output.

Envelope: The combination of header, trailer, and sometimes other control segments, that define the

start and end of an individual EDI message.

Enterprise Application Integration: The use of middleware to integrate the application programs,

databases, and legacy systems involved in an organization’s critical business processes.

Enterprise Resource Planning: Packaged software systems using database technology and a single

interface to control all the information related to a company’s business, including customer, product,

employee, and financial data.

ENX: The IP-based network for the European automotive industry.

EPC: Electronic product code. A 96-bit number whose format is governed by EPCglobal, a subsidiary of

the GS1 standards body. Each RFID tag will contain a unique EPC.

EPCglobal: A subsidiary of the EAN.UCC international standards body which governs the format of

EPCs.

Evaluated Receipts Settlement: Method for initiating payment to a supplier that replaces the invoice.

Used primarily in the auto industry. First the price is agreed upon by a blanket or other purchase order.

Next, a material release tells the supplier the quantity to deliver. An advance ship notice confirms the

quantity actually being delivered, and payment is triggered upon receipt.

Event-Driven EDI: Applications and translator exchanging message sets as soon as they are created or

received.

eXtensible Markup Language: Extensible Markup Language is designed to improve the functionality of

the Web by providing more flexible and adaptable information identification. It is called extensible

because it is not a fixed format like Hypertext Markup Language (a single, predefined markup language).

Instead, Extensible Markup Language is actually a metalanguage (a language for describing other

languages) that allows individuals to customize markup languages for limitless different types of

documents. Extensible Markup Language can do this because it is written in Standard Generalized

Markup Language, the international standard metalanguage for text markup systems.

« back to top

F

File: A collection of related records treated as a basic unit of storage in a computer system.

File, flat: A computer file where all the information is run together in a single character string.

File Structure: The format into which a file is arranged by the computer, so that the information it

contains can be retrieved on demand.

FIN: The SWIFT FIN is a message transfer based store and forward system. FIN is the main messaging

mechanism used today on SWIFTNet and is used by corporates for liquidity and risk management

purposes

FTP: File Transfer Protocol. A standard method of transmitting files from one computer to another over

the internet.

Functional Acknowledgement: A transaction set transmitted by the receiver of an EDI transmission to

the sender, indicating the receipt and syntactical acceptability of a message. It does not provide

acknowledgement of the content of the message, just that the message has been successfully received

and interpreted.Often abbreviated and referred to as “FA”.

Functional Group: A collection of related transaction sets. Beginning (GS) and ending (GE) segments

are used to envelop a complete functional group.

Functional Group Segments (GS/GE): These segments identify a specific functional group of

documents such as purchase orders.

« back to top

G

Galia: French automotive industry body.

Gateway: The interconnection between public or private networks, allowing the transmission of

documents in EDI format across multiple networks.

GCI: Global Commerce Initiative. A global industry user group which identifies issues hindering supply

chain performance and suggests potential global solutions for data, messages, processes and associated

requirements which it can offer to standards bodies such as GS1 for adoption.

GDD: Global Data Dictionary: a GS1 standard which allows all the potential attributes of an item to be

defined. These attributes may include size, brand information, logistical information, etc.

GDS: Global Data Synchronisation.

GDSN: Global Data Synchronisation Network. Provides a framework that allows all datapools to

interoperate and share data seamlessly.

GLN: A Global Location Number (GLN) is a unique number that is assigned to locations to enable them

to be identified uniquely worldwide. These global location numbers can be used to identify any legal,

physical and functional locations. Global locations numbers are reference keys to computer files where

information about the company or location can be found. The GLNs replace the names and addresses of

locations and are particularly useful when automating processes; they allow computers to route

information to the correct destination with no manual involvement. GLNs must be used when identifying

locations and trading partners within Electronic Data Interchange (EDI) business messages and data

pools, and they can also be used in bar codes to identify a physical location or to provide relevant

information for delivery or invoicing purposes.

GLOBAL Registry: A central service which holds pointers to data held in local datapools, provides an

index for companies looking for product data held in local datapools and ensures datapools are fully

compliant with GS1 standards.

Global Company Identifier: RosettaNet-branded term for the Data Universal Numbering System. The

Global Company Identifier is the RosettaNet object and Data Universal Numbering System is the

specified solution.

Global Data Dictionary: The repository of definitions and attributes of all data elements used within GS1

Business Message Standards.

GPC: Global Product Classification: a standard way of categorising products that provides a way to link

different company classification systems and offers a common language for collaborative business

processes.

GS1: A worldwide network of standards bodies and service providers which develops global supply chain

standards and solutions used by over one million companies for bar coding, electronic business

messaging, data synchronisation and through the EPCglobal Network, radio frequency identification.

GRN: Goods Received Note. A document raised by a customer receiving goods to confirm what has

been received, so that invoices may be approved for payment.

GSMP: Global Standards Management Process. The governing body for the development of global data

synchronisation standards within the GS1 framework. Open to industry participants and solution

providers, the GSMP provides the process for developing business requirements and global standards for

technical implementations.

GTIN: Global Trade Item Number. A unique identifier for each product.

« back to top

H

Hardware: The physical parts of a computer system, such as the central processing unit, tape drives,

disk drives, modem, etc.

Header: The specific segment that, in simplest terms, tells the receiving computer where an individual

EDI message starts.

HIPPA: Health Insurance Portability and Accountability Act, established by the U.S Congress in 1996

HL7: A standard for the healthcare industry.

HTTP: HyperText Transfer Protocol. A protocol used to request and transmit files, especially web pages

and web page components, over the internet or other computer network.

HTTPS: HyperText Transfer Protocol Secure is a combination of the Hypertext Transfer Protocol with the

SSL/TLS protocol to provide encryption and secure identification of the server.

Hub: EDI term for a company that initiates a B2B program with its trading partners, usually a buyer. See

also Spoke.

« back to top

I

IDEA: International Data Exchange Association. Organisation based in Brussels that promotes the global

expansion of EDI.

IDOC: stands for intermediate document, is a standard data structure for electronic data interchange

between application programs written for the popular SAP business system or between an SAP

application and an external program. IDOCs serve as the vehicle for data transfer in SAP’s Application

Link Enabling (ALE) system.

ID System (EPC Tags and readers): The ID System is a component of the EPCglobal Network that

consists of EPC tags and readers. EPC tags are radio frequency identification devices that consist of a

microchip and an antenna attached to a substrate. The Electronic Product Code is stored on this tag,

which is applied to cases, pallets, and/or items. EPC tags communicate their Electronic Product Codes to

EPC readers using radio frequency identification. EPC readers communicate with EPC tags via radio

waves and deliver information to local business information systems using EPC Middleware.

IETF: See Internet Engineering Task Force.

Implementation Guide: A publication listing EDI messages that are in use in a particular industry or

application. It indicates how the information in those messages should be presented on a segment-by-

segment, and data-element-by-data-element basis, including which segments and data elements are

needed, which are not and what code values will be expected in the application of that particular

message.

Industry Specific: Useful to only one particular group of companies grouped together by a common area

of endeavor. In EDI it refers to the ability of an EDI Standard to be used by only one industry.

Interactive EDI: Two applications exchanging EDI directly within a preprogrammed context.

Interchange: The exchange of information from one company to another. A group of transaction sets

sent from one sender to one receiver at one time.

Interchange Format: A specific data layout that defines a structured business document. The

interchange format specifies the sequence, representation, and grouping of granular data elements, and

may describe each element in terms of data type, options, cardinality, size, and valid values.

Interchange Control Header: The data segment that indicates and identifies the beginning of an

interchange.

Interchange Control Trailer: The data segment that indicates the end of an interchange.

Interchange Envelope: Specific data transmission information in the header and trailer segments,

representing an exchange between a single sender/receiver combination, ISA/IEA-approved.

Interconnect: Two VAN’s who link to one another’s address.

Internet Engineering Task Force: A large open international community of network designers,

operators, vendors, and researchers concerned with the evolution of the internet architecture and the

smooth operation of the internet.

Invoice: A request for payment that communicates to a buyer the specific items, price, and quantities

delivered that must be paid for by the buyer. Payment terms will usually accompany the billing

information.

ISO: International Standards Organisation. An international organisation, working with the United Nations,

that maintains the standards for all applications of technology and mechanics for global industry.

« back to top

J

JIT: Just In Time. A technique of managing inventory pioneered in Japan, under which materials are

delivered by suppliers to a manufacturer as they are needed for production, rather than for storage or

inventory.

JNX: The IP-based network for the Japanese automotive industry.

« back to top

K

KNX: The IP-based network for the Korean automotive industry.

« back to top

M

Mailbag: ANSI-defined standard for interconnects between VAN (EDI) addresses.

Mailbox: A file storage area within a computer, usually one used by a Network Service Provider, where

information is placed until it can be retrieved by the intended receiver.

Manifest: A document from the vendor who is shipping goods to a customer that describes where the

goods will arrive. Multiple destinations may be included.

Mapping: The act of determining what pieces of information in the company's database should be placed

into each data element of an EDI message or transaction set, or in reverse, what data elements of an EDI

message or transaction set should be placed into the company's database.

Message: A block of information in EDI. making up a business transaction, or part of a business

transaction.

Message Header: The service segment starting and uniquely identifying a message.

Message Structured Diagram: The graphic display of the layout of a message.

Message Switching: The routing of a direct transfer message between computers through the services

of a third-party service provider.

Message Trailer: The service segment ending a message.

Message Type: An identified and structured set of data elements covering the requirements for a

specified type of transaction, e.g., an invoice.

Message Standards: The system of syntax, data elements, segments and messages (transaction sets)

with which EDI will be conducted.

Modem: Abbreviated form of Modulator/Demodulator. The electronic device that connects the computer

to a telephone line to allow communications.

« back to top

N

NAK: A form of negative acknowledgment of an error detection in the transmission.

Network Management: Identifies fault, accounting, configuration, security, and performance

management.

National Standards Body: The organisation in a country that is tasked with keeping the standards for all

applications of technology and mechanics for the industry of that country.

Network: An electronic communications system that links computers together to allow EDI to take place.

Network Service Provider: A company that maintains a network and offers its services and capabilities

to others for a fee.

Notification of Shipment: A transaction set that advises of the delivery schedule and provides a

description of the shipment.

« back to top

O

OASIS: Organisation for the Advancement of Structured Information Standards. A not-for-profit global

consortium that drives the development, convergence and adoption of e-business standards.

Object: Any entity about which we store data and the operations to manipulate that data.

ODETTE: Organisation for Data Exchange Through Teletransmission in Europe. Refers to both the

European automotive industry body and the EDIFACT EDI standard subset for that industry.

OFTP: ODETTE File Transfer Protocol. The messaging protocol for the European automotive industry.

OFTP v2.0: An update on the OFTP protocol which has been designed from the outset to be used over

the internet. OFTP v2.0 offers a number of benefits over OFTP including data compression, exchange of

digital certificates and large file transmission between trading partners.

OSI: Open Systems Interconnect. Structure based on seven-layer model developed by ISO, which will

allow different computer manufacturers' machines to communicate with one another.

Open Network: A network with which outside parties can communicate.

« back to top

P

Paperwork: The documents that have been traditionally used to convey information in a business

transaction.

Payment Terms: Also called Terms of Sale. Refers to the agreement of payment of invoice between

supply-side trading partner and demand-side trading partner, e.g., Net 30 indicates that the invoice is to

be paid within 30 days.

PIDX: XML document schema used in the Energy industry.

Pilot: The process of testing a part of the final system as a gauge to determine the viability of a concept

prior to implementing the system for full production.

Pilot Project: A project conducted between two or more EDI trading partners to test the viability of a

proposed EDI System.

PIP: Partner Interface Processes. RosettaNet PIPs define business processes between trading partners

via XML-based dialogs.

PIP Blueprint: A business model that specifies how Partner Roles (buyer, seller, assembler, catalogue

publisher, etc.) interactively perform interface activities that collaboratively achieve a business objective.

The PIP Blueprint document includes narrative and diagrams.

PIP Choreography: The exchange sequence of Partner Interface Process messages specified using

Business Process Specification Schema.

PIP Design and Development Process: A structured process that describes the work and steps

required to create a PIP Specification based upon requirements as detailed in the Specification

Requirement Document.

PIP in Production: Two trading partners using a RosettaNet Partner Interface Process as the business

process interface for a live transaction (not in pilot or testing).

PIP Interchange Model: The structure of the exchanged information between trading partners in a

specific context; content structure described using either Unified Modelling Language or Extensible

Markup Language schemas.

PIP Protocols: Technical interface diagrams that visually describe and define the PIP Blueprint.

PIP Specification: Detailed document that provides a definitive description of a system for the purpose of

developing or validating the system

Platform: The type of computer system being used.

Point-to-Point: Refers to a type of communication whereby messages are sent directly from one trading

partner to another without the use of a VAN.

Proprietary Standard: An industry/company-specific data format developed by a company for

transmission of data to and from its trading partners. Proprietary formats do not comply with the ASC X12

series of standards.

Proprietary Ordering System: An industry company-specific system that allows a supplier to provide

order entry capabilities to its customers.

Protocol: Communication standards that determine message content and format, enabling uniformity of

transmissions.

Protocol Conversion: The process of allowing two systems with different protocols to communicate.

Purchase Order: A document issued by a buyer to a seller that details the terms of sale under which the

buyer will purchase the seller's goods.

Purchase Order Acknowledgment: Confirmation to the buyer that the supplier will be filling the

purchase order as requested.

« back to top

Q

Qualifier: Part of an EDI address.

« back to top

R

Ramp: A program of activity to electronically enable a group of trading partners to send and receive

documents in agreed formats.

Receiver: The party to whom the EDI message or transaction set is transmitted.

Receiving Advice Transaction: A transaction set that includes the quantity, description and condition of

the product received.

Registry: A mechanism whereby relevant repository items, and metadata about them, can be registered

so that a pointer to their location, and all their metadata, can be retrieved as a result of a query.

Repository: A location or set of distributed locations which hold the data (such as that associated with a

product), pointed at by a registry, and from where the data can be retrieved.

RFID: Radio Frequency Identification. A technology that allows data held on a microchip to be broadcast

using a wireless transmitter. Data from the RFID chip can be read even when the chip is not in line of

sight.

RosettaNet: A non-profit consortium dedicated to the collaborative development and rapid deployment of

open, business process standards that align processes within the global trading network. More than 700

multinational and regional companies in the high technology, logistics, and adjacent industries, as well as

solution providers, participate in RosettaNet’s strategic standards and services development. Fortune

1000 companies worldwide have implemented RosettaNet business process standards. RosettaNet is a

subsidiary of GS1 US. To date, the consortium has established several regional affiliate organizations – in

Australia, China, Japan, Korea, Malaysia, Philippines, Singapore, Taiwan, and Thailand – giving a voice

to various business economies seeking to adopt and influence RosettaNet’s global standards. RosettaNet

is also represented locally in Europe. Information on RosettaNet’s worldwide activities, including a

complete list of member companies and participating organizations, is available at www.RosettaNet.org.

« back to top

S

Secure FTP: see SFTP.

Segment: A part of an EDI message or transaction set, made up of a number of related data elements

separated by a delimiter, conveying a part of the business transaction being made.

Segment Code: A code that uniquely identifies each segment as specified in a segment directory.

Segment Delimiter Character: Marks the end of a variable-length segment.

Segment Diagram: The schematic that depicts the format and composition of a segment.

Segment Directory: A listing of the segments unique to the specific system of EDI Standards being

used, and usually part of the data dictionary.

Segment Hierarchy: The order of occurrence of segments within a transaction set.

Segment Identifier: A predefined code that identifies the segment.

Segment Name: A name that identifies the segment.

Segment Qualifier: A data element that gives the segment a specific meaning.

Segment Specifications: Distinct attributes of a segment, including structure and content.

Segment Tag: A composite data element, in which the first component data element contains a code that

uniquely identifies a segment as specified in the relevant segment directory. Additional component data

elements can be conditionally used to indicate the hierarchical level and nesting relationship in a

message and the incidence of a segment's repetition [EDIFACT].

Segment Terminator: A special character that indicates the end of a segment

Selfbilling: Customers can generate the invoice themselves and remit payment electronically via EDI.

Seller: The party in a business transaction who sells goods or services to a buyer for good and valuable

consideration.

Sender: The party who transmits the EDI messages.

Sequence Table: A portion of a standard that indicates the possible segments, their sequence, and their

attributes for each area of a transaction set.

SFTP: Simple File Transfer Protocol. A network protocol that provides file transfer and manipulation

functionality over any reliable data stream. It is typically used with the SSH-2 protocol to provide secure

file transfer. (See also SSH).

Shipment Notification: An EDI transaction sent by the shipper of material to the receiver advising that

the shipment has been sent, and providing details such as manifest, PO number, estimated time of

arrival, carrier, etc.

Simple data elements: A data element containing a single value.

SMTP: Simple Mail Transfer Protocol. The protocol that is most commonly used for transferring email

between servers over the internet.

SOAP: Simple Object Access Protocol. A lightweight XML based protocol for exchanging structured

information in a de-centralised, distributed environment, defined by the W3C.

Software: The programs residing on disk, tape, or other storage media used by the computer to

accomplish its tasks.

Spoke: EDI term that refers to a trading partner, usually a supplier to a buyer company (known as a

Hub).

SSH: Secure Shell. A set of standards and an associated network protocol that allows a secure channel

to be established between a local and remote computer.

Standards: Something established for use as a rule or basis of comparison. In the context of EDI, this

usually refers to the system of message standards that are in use between trading partners.

Standards Body: A committee, usually made up of representatives of the users of a given Standard, and

either accepted by industry or charged by a government to maintain the Standards in question.

Standards, Proprietary: Those systems of EDI messages that are developed by the trading partners

themselves for a specific application, and do not fit in any of the systems of Standards developed by any

of the accepted Standards Bodies around the world.

Standards, Public: Those systems of EDI messages that are prepared and published by or through the

accepted Standards Bodies around the world.

Store and Forward: A type of messaging service that allows an EDI transmission to be forwarded when

convenient to the sender and transmitted immediately to the recipient.

Store and Retrieve: Usually used in conjunction with a mail box system; provides for the storage of a

message transmission until the intended receiver accesses the system and retrieves the message.

Supply Chain: A sequence of events, which may include conversion, movement or placement, which

adds value to goods, products, or services.

Syntax: The system for arranging data elements and segments within an EDI message or transaction

set, as dictated by the Message or Transaction Set Standards being used.

« back to top

T

Tag: The unique identifier used with segment and data elements.

TCP/IP: Network protocol for the internet.

TDCC: Transportation Data Coordinating Committee. This is the original EDI organisation for the United

States. Through its efforts, the first EDI Standards were developed, published, and maintained. It is now

EDIA, and has become the national EDI user group for the United States.

TDI: Trading Data Interchange. Abbreviation for EDI common in Europe.

Third-party: A party other than the sender or retriever, such as a Network Service Provider, or software

developer providing goods or services, in this case in support of the transmission of Information in EDI

other than the sender or receiver.

Tradacoms: UK EDI standard developed by GS1 (when GS1 was a different entity called ANA).

Trading Partner: The entity with which EDI is carried on. This may be either the sender or the receiver of

information in EDI.

Trading Partner Agreement: In RosettaNet, Trading Partner Agreements contain the general contract

terms and conditions, participant roles (buyers, sellers), communication and security protocols, and

business processes (valid actions, sequencing rules, etc.). Extensible Markup Language-based Trading

Partner Agreement documents capture the essential information upon which trading partners must agree

in order for their applications and business processes to communicate.

Trailer: The specific segment that in simplest terms, tells the receiving computer where an Individual EDI

message ends.

Transaction Level Acknowledgment: Acknowledgment of receipt and totality of data in a transmission

of a functional group or individual transaction set.

Transaction Set: A block of information in EDI, making up a business transaction or part of a business

transaction. Outside North America, this is normally called a message.

Transaction set ID: An identifier that uniquely identifies the transaction set. This identifier is the first data

element of the transaction set header segment.

Transaction Set Diagram: A graphic presentation in a valid transaction that specifies the sequence of

segment order.

Transaction Set Header Area: Contains segment information pertinent to the total transaction set.

Transaction Set Header Segment: Signifies the beginning of a transaction set.

Transaction Set Level: The processing of a transaction set, including sending and receiving.

Transaction Set Line Item Area: Encompasses the actual business transaction set and includes

information, such as quantities, descriptions and prices.

Transaction Set Standards: The system of syntax, data elements, segments, and transaction sets

(messages) with which EDI will be conducted

Transaction Set Summary Area: Contains control information and other data that relate to the total

transaction.

Transaction Set Trailer Segment: Signifies the end of a transaction set.

Translation: The process of converting information to and from EDI standard formats.

Translator: A program used to convert information from flat file to EDI format, or from EDI format to flat

file.

Transmission Acknowledgment: The acknowledgment that a total transmission was received with no

error detected.

Transmission Group: A collection of one or more functional groups. Also known as an Interchange.

« back to top

U

UCC: The Uniform Code Council. The organisation that oversees the standards for product identification

and related electronic communications. The UCC oversaw the Universal Product Code (UPC) in the

United States – now superseded by GTINs – as well as Uniform Communication Standards (UCS) for EDI

in the grocery industry and Warehouse Information Network Standards (WINS) in the warehousing and

transportation industry.

UCS: A subset of the ANSI X12 EDI standard.

UDDI: Universal Description, Discovery, and Integration. It is an XML-based registry for businesses

worldwide to list themselves on the internet.

UN/CEFACT: The United Nations Centre for Trade Facilitation and Electronic Business. It supports

activities dedicated to improving the ability of business, trade and administrative organisations to

exchange products and services effectively.

User: An entity, either an individual or a company, who utilises a computer or system of standards for a

specific purpose like EDI.

User Group: An organisation of individuals and/or companies who come together to deal with the needs

of those who wish to employ a technique or technology in a unified manner. User groups are discussion

organisations.

« back to top

V

Validation: The process of determining that compliance standards have been met by a particular

document in an EDI transmission.

Value-Added Network: Often abbreviated as VAN, a third-party entity which handles the electronic

exchange of information between subscribers to its services. Services provided by VANs include

electronic mailboxing of EDI transmissions, protocol and speed conversion, and EDI record keeping for

audit tracking.

VAN: See Value-Added Network.

Variable-Length File: A file with segments containing data elements that can vary between minimum

and maximum requirements, but which have no set fixed length. A data element delimiter is required to

mark the end of the element and a segment delimiter character is needed to mark the end of the

segment.

VDA: German EDI data standard in the automotive industry.

Vendor Managed Inventory (VMI): A system of inventory replenishment in which the vendor accepts

responsibility for maintaining customer's inventory levels of the vendor's products by monitoring POS and

inventory information sent by the customer. This is usually automated through EDI to achieve as smooth

a flow of replenishment as possible.

Version/Release: Identifies the publication of the standard being used for the generation or the

interpretation of data in the X12 standard format.

VICS: Voluntary Inter-industry Commerce Solutions Association - A not-for-profit association with a

mission to take a global leadership role in the development of business guidelines and specifications;

facilitating implementation through education and measurement, resulting in the improvement of the retail

supply chain efficiency and effectiveness, which meet or exceed customer and consumer expectations.

GS1 US is the secretariat to the Voluntary Inter-industry Commerce Solutions Association.

VPN: Virtual Private Network.

« back to top

W

W3C: The usual abbreviation for the World Wide Web Consortium.

Web-EDI: A generic term for the transmitting of structured business messages over the internet. This

may include solutions such as a logon to a portal and inputting commercial transactional information into

a form on a website using an internet browser. This method requires an element of manual intervention.

Web Services: A standard means of interoperating between different software applications, running on a

variety of platforms and/or frameworks, over the Internet.

Web Services Interoperability: An open industry organisation chartered to promote Web Services

interoperability across platforms, operating systems, and programming languages. The organization

works across the industry and standards organizations to respond to customer needs by providing

guidance, best practices, and resources for developing Web Services solutions.

WINS: Warehouse Information Network Standards. A set of EDI standards for warehousing and

distribution. WINS is a subset of the ANSI X12 national standard.

World Wide Web Consortium: the body that defines standards (such as HTTP) for the internet.

WSDL: Web Services description language.

« back to top

X

X25: Network protocol, still widely used.

X400: Early email system popular in Europe.

X500: Directory services standard of the CCITT.

XML: The usual abbreviation for Extensible Markup Language - an open standard for describing data

defined by the World Wide Web Consortium (W3C).

http://www.edibasics.co.uk/edi-resources/messaging-protocols/#