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 companys 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 todays 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 vendors 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-toPoint 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 Walmarts 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 todays companies are even looking to integrate to back office business systems such as Enterprise Resource Planning (ERP) platforms. Many of todays 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 Apples 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 todays 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. Lets 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 buyers computer through a network to the vendors 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 wont 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 todays 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 receivers 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 customers 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 companys 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 companys 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 coordinators 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 committees 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 organisations 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 organisations 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-ordinators 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 organisations 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 providerthe 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 systemnamely the application softwarewhich 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 recipients 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 companys data processing operations than the modernity of the vendors 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 servicea mailboxfor 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 partners 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 companys 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 vendors 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 vendors 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 vendors 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 vendors 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 innetwork 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 paperbased 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 vendors 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 systems 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 its origin. The in-house order processing systems 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 manufacturers 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 X12s 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 hubs 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 partners 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 suppliers EDI systems into its order processing or ERP system as a thorough test for the hubs 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 transactions 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 259 d 815 868 997 e,* Data Status Tracking Error Reporting Immediate Response Cryptographic Service Message Electronic Form Structure Functional Acknowledgment

Product Data 140 * 141 142 143 Product Registration Product Service Claim Response Product Service Claim Product Service Notification

241 d 243 d 244 d 841 e,* 842 e,* 848 * 863 * 864 e,*

Binary Data File Transfer Request for Product Source Information Product Source Information Specifications/Technical Information Nonconformance Report Material Safety Data Sheet Report of Test Results Text Message

Finance 135 139 144 155 d 156 d 190 191 197 d 198 d 199 d 200 201 203 205 d 206 d 207 d 208 d 209 d 215 260 261 b 262 263 264 265 266 810 e,* 811 * Student Loan Application Student Loan Guarantee Result Student Loan Transfer and Status Verification Credit Report Entitlement Payment Recipient Account Inquiry/Response Student Enrollment Verification Student Loan Pre-Claims and Claims Real Estate Title Evidence Loan Verification Information Mortgage Settlement Information Mortgage Credit Report Residential Loan Application Secondary Mortgage Market Investor Report Mortgage Note Real Estate Mortgage Inspection Request Real Estate Mortgage Inspection Result Income Property Appraisal Report Condominium Appraisal Report Motor Carrier Pick-up Manifest Application for Mortgage Insurance Benefits Residential Appraisal Request Residential Appraisal Report Residential Mortgage Insurance Application Response Mortgage Loan Default Status Real Estate Title Insurance Services Order Mortgage Record Change Invoice Consolidated Service Invoice/Statement

812 * 819 820 * 821 822 823 824 e,* 827 828 829 831 833 844 849 872 880

Credit/Debit Adjustment Operating Expense Statement Payment Order/Remittance Advice Financial Information Reporting Customer Account Analysis Lockbox Application Advice Financial Payment Return Order/Return Notice Debit Authorization Payment Cancellation Request Application Control Totals Mortgage Credit Report Order Product Transfer Account Adjustment Response to Product Transfer Account Adjustment Residential Mortgage Insurance Application Grocery Products Invoice

Government 149 d 150 151 152 154 156 d 175 176 * 185 194 d 195 196 * 251 * 280 d 281 d 501 502 d 505 d 506 d 511 * Notice of Tax Adjustment or Assessment Tax Rate Notification Electronic Filing of Tax Return Data Acknowledgment Statistical Government Information Uniform Commercial Code Filing Entitlement Payment Recipient Account Inquiry/Response Court Notice Court Submission Royalty Regulatory Report Grant or Assistance Application Federal Communications Commission (FCC) License Application Contractor Cost Data Reporting Pricing Support Voter Registration Information Elections Results Reporting Vendor Performance Review Solicitation Mailing List Procurement Support Procurement Notice Requisition

517 * 525 d 527 * 536 * 561 * 567 * 568 * 805 * 806 813 826 836 e,* 838 e,* 839 996

Material Obligation Validation Asset Disposition Material Due-In and Receipt Logistics Reassignment Contract Abstract Contract Completion Status Contract Payment Management Report Contract Pricing Proposal Project Schedule Reporting Electronic Filing of Tax Return Data Tax Information Reporting Procurement Notices Trading Partner Profile Project Cost Reporting File Transfer

Materials Management 830 * 846 * 847 853 856 e,* 857 861 * 862 866 867 869 e,* 870 e,* 871 b Planning Schedule With Release Capability Inventory Inquiry/Advice Material Claim Routing and Carrier Instruction Ship Notice/Manifest Shipment and Billing Notice Receiving Advice/Acceptance Certificate Shipping Schedule Production Sequence Product Transfer and Resale Report Order Status Inquiry Order Status Report Component Parts Content

Transportation 104 110 120 121 125 126 Air Shipment Information Air Freight Details and Invoice Vehicle Shipping Order Vehicle Service Multilevel Railcar Load Details Vehicle Application Advice

127 128 129 160 d 161 163 d 204 210 213 214 217 218 250 300 301 303 304 309 310 311 312 313 315 317 319 322 323 324 325 326 350 352 353 354 355 356 357 358

Vehicle Baying Order Dealer Information Vehicle Carrier Rate Update Transportation Automatic Equipment Identification Train Sheet Appointment Schedule Information Motor Carrier Shipment Information Motor Carrier Freight Details and Invoice Motor Carrier Shipment Status Inquiry Transportation Carrier Shipment Status Message Motor Carrier Loading and Route Guide Motor Carrier Tariff Information Purchase Order Shipment Management Document Reservation (Booking Request) (Ocean) Confirmation (Ocean) Booking Cancellation (Ocean) Shipping Instructions U.S. Customs Manifest Freight Receipt and Invoice (Ocean) Canadian Customs Information Arrival Notice (Ocean) Shipment Status Inquiry (Ocean) Status Details (Ocean) Delivery/Pickup Order Terminal Information Terminal Operations and Intermodal Ramp Activity Vessel Schedule and Itinerary (Ocean) Vessel Stow Plan (Ocean) Consolidation of Goods in Container Consignment Summary List U.S. Customs Release Information U.S. Customs Carrier General Order Status U.S. Customs Events Advisory Details U.S. Customs Automated Manifest Archive Status U.S. Customs Manifest Acceptance/Rejection U.S. Customs Permit to Transfer Request U.S. Customs In-Bond Information U.S. Customs Consist Information

361 404 410 412 d 414 417 418 419 420 421 422 423 425 426 429 431 432 433 435 436 b 440 451 452 453 455 456 460 d 463 d 466 468 475 485 486 d 490 492 494 601 602

Carrier Interchange Agreement (Ocean) Rail Carrier Shipment Information Rail Carrier Freight Details And Invoice Trailer/Container Repair Billing Rail Car-hire Settlements Rail Carrier Waybill Interchange Rail Advance Interchange Consist Advance Car Disposition Car Handling Information Estimated Time of Arrival and Car Scheduling Shipper's Car Order Rail Industrial Switch List Rail Waybill Request Rail Revenue Waybill Railroad Retirement Activity Railroad Station Master File Rail Deprescription Railroad Reciprocal Switch File Standard Transportation Commodity Code Master Locomotive Information Shipment Weights Railroad Event Report Railroad Problem Log Inquiry or Advice Railroad Service Commitment Advice Railroad Parameter Trace Registration Railroad Equipment Inquiry or Advice Price Distribution or Response Format Rail Rate Reply Rate Request Rate Docket Journal Log Rail Route File Maintenance Rate making Action Rate Docket Expiration Rate Group Definition Miscellaneous Rates Scale Rate Table Shipper's Export Declaration Transportation Services Tender

622 715 b 753 754 854 858 * 859 * 920 924 925 926 928 * 980 990 998

Intermodal Ramp Activity Intermodal Group Loading Plan Request for Routing Instructions Routing Instructions Shipment Delivery Discrepancy Information Shipment Information Freight Invoice Loss or Damage Claim - General Commodities Loss or Damage Claim - Motor Vehicle Claim Tracer Claim Status Report and Tracer Reply Automotive Inspection Detail Functional Group Totals Response to a Load Tender Set Cancellation

Purchasing 503 * 504 * 816 832 e,* 840 e,* 843 e,* 845 850 e,* 851 * 855 e,* 860 e,* 865 e,* 875 876 Pricing History Clauses and Provisions Organizational Relationships Price/Sales Catalog Request for Quotation Response to Request for Quotation Price Authorization Acknowledgment/Status Purchase Order Asset Schedule Purchase Order Acknowledgment Purchase Order Change Request - Buyer Initiated Purchase Order Change Acknowledgment/Request - Seller Initiated Grocery Products Purchase Order Grocery Products Purchase Order Change

Industry Standards Transition 130 131 146 147 187 d Student Educational Record (Transcript) Student Educational Record (Transcript)Acknowledgment Request for Student Educational Record (Transcript) Response to Request for Student Educational Record (Transcript) Request/Response to Request for Educational Course Catalog

188 b 189 b 193 d

Educational Course Catalog Application for Admission to Educational Institutions Financial Aid Transcript

Distribution & Warehousing 159 b 170 180 * 290 818 852 877 d 878 879 882 883 884 885 886 887 b 888 889 891 893 894 895 896 940 943 944 945 947 Motion Picture Booking Confirmation Revenue Receipts Statement Return Merchandise Authorization and Notification Cooperative Advertising Agreements Commission Sales Report Product Activity Data Manufacturer Coupon Family Code Structure Product Authorization/De-Authorization Price Change Direct Store Delivery Summary Information Market Development Fund Allocation Market Development Fund Settlement Store Characteristics Customer Call Reporting Coupon Notification Item Maintenance Promotion Announcement Deduction Research Report Item Information Request Delivery/Return Base Record Delivery/Return Acknowledgment or Adjustment Product Dimension Maintenance Warehouse Shipping Order Warehouse Stock Transfer Shipment Advice Warehouse Stock Transfer Receipt Advice Warehouse Shipping Advice Warehouse Inventory Adjustment Advice

Insurance 124 148 186 Vehicle Damage Report of Injury, Illness or Incident Laboratory Reporting

253d 255b 256d 268d 270 271 272 273b 275b 276 277 278 362 834 835 837

Data Reporting Requirements Insurance Underwriting Information Services Periodic Annuity Compensation Annuity Account Activity Health Care Eligibility/Benefit Inquiry Health Care Eligibility/Benefit Information Property and Casualty Loss Notification Insurance/Annuity Application Status Patient Information Health Care Claim Status Request Health Care Claim Status Notification Health Care Service Review Information Cargo Insurance Advice of Shipment Benefit Enrollment and Maintenance Health Care Claim Payment/Advice 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 271-A1 276-A1 277-A1 278-A1 278-A3 820-A1 834-A1 835-W1 837-Q1 837-Q2 837-Q3 APERAK AUTHOR AVLREQ AVLRSP BALANC BANSTA BAPLIE BAPLTE BERMAN BMISRM BOPBNK BOPCUS BOPDIR BOPINF BUSCRD CALINF Eligibility, Coverage or Benefit Inquiry Eligibility, Coverage or Benefit Information Health Care Claim Status Request Health Care Claim Status Notification Health Care Services Review -- Request for Review Health Care Services Review -- Response to Request for Review Payment Order/Remittance Advice Benefit Enrollment and Maintenance Health Care Claim Payment/Advice Health Care Claim: Professional Health Care Claim: Dental Health Care Claim: Institutional Application error and acknowledgement message Authorization message Availability request - interactive message Availability response - interactive message Balance message Banking status message Bayplan/stowage plan occupied and empty locations message Bayplan/stowage plan total numbers message Berth management message Bulk marine inspection summary report message Bank transactions and portfolio transactions report message Balance of payment customer transaction report message Direct balance of payment declaration message Balance of payment information from customer message Business credit report message Vessel call information message

CASINT CASRES CHACCO CLASET CNTCND COACSU COARRI CODECO CODENO COEDOR COHAOR COLREQ COMDIS CONAPW CONDPV CONDRA CONDRO CONEST CONITT CONPVA CONQVA CONRPW CONTEN CONWQD COPARN COPAYM COPINO COPRAR COREOR COSTCO COSTOR CREADV CREEXT CREMUL CUSCAR CUSDEC CUSEXP CUSPED

Request for legal administration action in civil proceedings message Legal administration response in civil proceedings message Chart of accounts message Classification information set message Contractual conditions message Commercial account summary message Container discharge/loading report message Container gate-in/gate-out report message Permit expiration/clearance ready notice message Container stock report message Container special handling order message Request for a documentary collection message Commercial dispute message Advice on pending works message Direct payment valuation message Drawing administration message Drawing organisation message Establishment of contract message Invitation to tender message Payment valuation message Quantity valuation message Response of pending works message Tender message Work item q uantity determination messa e Container announcement message Contributions for payment Container pre-notification message Container discharge/loading order message Container release order message Container stuffing/stripping confirmation message Container stuffing/stripping order message Credit advice message Extended credit advice message Multiple credit advice message Customs cargo report message Customs declaration message Customs express consignment declaration message Periodic customs declaration message

CUSREP CUSRES DEBADV DEBMUL DEBREC DELFOR DELJIT DESADV DESTIM DGRECA DIRDEB DIRDEF DMRDEF DMSTAT DOCADV DOCAMA DOCAMI DOCAMR DOCAPP DOCARE DOCINF ENTREC FINCAN FINPAY FINSTA GENRAL GESMES HANMOV ICASRP ICSOLI IFCSUM IFTCCA IFTDGN IFTFCC IFTIAG IFTICL IFTMAN IFTMBC

Customs conveyance report message Customs response message Debit advice message Multiple debit advice message Debts recovery message Delivery schedule message Delivery just in time message Despatch advice message Equipment damage and repair estimate message Dangerous goods recapitulation message Direct debit message Directory definition message Data maintenance request definition message Data maintenance status report/query message Documentary credit advice message Advice of an amendment of a documentary credit message Documentary credit amendment information message Request for an amendment of a documentary credit message Documentary credit application message Response to an amendment of a documentary credit message Documentary credit issuance information message Accounting entries message Financial cancellation message Multiple interbank funds transfer message Financial statement of an account message General purpose message Generic statistical message Cargo/goods handling and movement message Insurance claim assessment and reporting message Insurance claim solicitor's instruction message Forwarding and consolidation summary message Forwarding and transport shipment charge calculation message Dangerous goods notification message International transport freight costs and other charges message Dangerous cargo list message Cargo insurance claims message Arrival notice message Booking confirmation message

IFTMBF IFTMBP IFTMCA IFTMCS IFTMFR IFTMIN IFTRIN IFTSAI IFTSTA IFTSTQ IHCEBI IHCLME IMPDEF INFCON INFENT INSDES INSPRE INSREQ INSRPT INTCHG INVOIC INVRPT IPPOAD IPPOMO ISENDS ITRRPT JAPRES JINFDE JOBAPP JOBCON JOBMOD JOBOFF JUPREQ LEDGER LREACT LRECLM MEDPID MEDPRE

Firm booking message Provisional booking message Consignment advice message Instruction contract status message International Forwarding And Transport Instruction message Forwarding and transport rate information message Forwarding and transport schedule and availability information me International multimodal status report message International multimodal status request message Interactive health insurance eligibility and benefits inquiry and Health care claim or encounter request and response - interactive EDI implementation guide definition message Infrastructure condition message Enterprise accounting information message Instruction to despatch message Insurance premium message Inspection request message Inspection report message Interchange Control Structures Invoice message Inventory report message Insurance policy administration message Motor insurance policy message Intermediary system enablement or disablement message In transit report detail message Job application result message Job information demand message Job application proposal message Job order confirmation message Job order modification message Job order message Justified payment request message Ledger message Life reinsurance activity message Life reinsurance claims message Person identification message Medical prescription message

MEDREQ MEDRPT MEDRUC MEQPOS MOVINS MSCONS ORDCHG ORDERS ORDRSP OSTENQ OSTRPT PARTIN PASREQ PASRSP PAXLST PAYDUC PAYEXT PAYMUL PAYORD PRICAT PRIHIS PROCST PRODAT PRODEX PROINQ PROSRV PROTAP PRPAID QALITY QUOTES RDRMES REBORD RECADV RECALC RECECO RECLAM RECORD REGENT

Medical service request message Medical service report message Medical resource usage and cost message Means of transport and equipment position message Stowage instruction message Metered services consumption report message Purchase order change request message Purchase order message Purchase order response message Order status enquiry message Order status report message Party information message Travel tourism and leisure product application status request - i Travel tourism and leisure product application status response Passenger list message Payroll deductions advice message Extended payment order message Multiple payment order message Payment order message Price/sales catalogue message Pricing history message Project cost reporting message Product data message Product exchange reconciliation message Product inquiry message Product service message Project tasks planning message Insurance premium payment message Quality data message Quote message Raw data reporting message Reinsurance bordereau message Receiving advice message Reinsurance calculation message Credit risk cover message Reinsurance claims message Reinsurance core data message Registration of enterprise message

RELIST REMADV REPREM REQDOC REQOTE RESETT RESMSG RESREQ RESRSP RETACC RETANN RETINS RPCALL SAFHAZ SANCRT SKDREQ SKDUPD SLSFCT SLSRPT SOCADE SSIMOD SSRECH SSREGW STATAC STLRPT SUPCOT SUPMAN SUPRES TANSTA TAXCON TIQREQ TIQRSP TPFREP TSDUPD TUPREQ TUPRSP UTILMD UTILTS

Reinsured objects list message Remittance advice message Reinsurance premium message Request for document message Request for quote message Reinsurance settlement message Reservation message Reservation request - interactive message Reservation response - interactive message Reinsurance technical account message Announcement for returns message Instruction for returns message Repair call message Safety and hazard data message International movement of goods governmental regulatory message Schedule request - interactive message Schedule update - interactive message Sales forecast message Sales data report message Social administration message Modification of identity details message Worker's insurance history message Notification of registration of a worker message Statement of account message Settlement transaction reporting message Superannuation contributions advice message Superannuation maintenance message Supplier response message Tank status report message Tax control message Travel tourism and leisure information inquiry request - interactive Travel tourism and leisure information inquiry response - interactive Terminal performance message Timetable static data update - interactive message Travel, tourism and leisure data update request - interactive message Travel, tourism and leisure data update response - interactive message Utilities master data message Utilities time series message

VATDEC VESDEP WASDIS WKGRDC WKGRRE

Value added tax message Vessel departure message Waste disposal information message Work grant decision message 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 BENREP CREADV DEBADV DELFOR DELINS DELJIT DELORD DESADV EXPINV FINSTA GSVERF IMPINV INVOIC LOCKBX ORDCHG ORDERS ORDRSP PAYEXT PRICAT PROACT QUOTES REMADV REQOTE SHPADV SHPCON SHPMNT BENEFIT1 PEXR2001, PEXR2002 PEXR2001, PEXR2002 DELFOR01 DELFOR01 DELFOR01 ORDERS03, ORDERS04, ORDERS05 DELVRY01, DELVRY02, DELVRY03 (previously: DESADV01) EXPINV01, EXPINV02, EXPINV03 FINSTA01 GSVERF01 IMPINV01 INVOIC01 FINSTA01 ORDERS01, ORDERS02, ORDERS03, ORDERS04, ORDERS05 ORDERS01, ORDERS02, ORDERS03, ORDERS04, ORDERS05 ORDERS01, ORDERS02, ORDERS03, ORDERS04, ORDERS05 PEXR2001, PEXR2002 PRICAT01 PROACT01 ORDERS01, ORDERS02, ORDERS03, ORDERS04, ORDERS05 PEXR2001, PEXR2002 ORDERS01, ORDERS02, ORDERS03, ORDERS04, ORDERS05 SHPMNT03 DELVRY01 SHPMNT01, SHPMNT02, SHPMNT03, SHPMNT04 IDOC Type Description Benefits Participation Benefits Retirement Plan Credit Memo Display Debit Advice Delivery Schedule Forecast Delivery Schedule Just-In-Time Delivery Schedule Delivery Order (Pickup sheet) Delivery Shipping Notification Foreign Trade Billing Document Bank Statement Self-Billing procedure Import Basis IDOC Invoice Lockbox Sales Order Change Purchase Order Change Sales Order Purchase Order Sales Order Confirmation Purchase Order Confirmation Extended Payment Order Price List/Catalog Stock and Sales Data Quotation Payment Advice Inquiry Shipping Notification Shipping Confirmation Shipment Notification

SHPORD TXTRAW

DELVRY01 TXTRAW01, TXTRAW02

Delivery: Dispatch Order Message for free text in SAP office format Delivery: Stock Order

WHSORD DELVRY01

SWIFT message types Message Type 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 Description

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

365Cross 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 AVLHDR BTOHDR PVUHDR CAKHDR CLAHDR CORHDR CREHDR CREADV CUSHDR DEBADV DLCHDR DELHDR DYEHDR GENHDR HSOHDR INVFIL ISSUES LPRHDR PICHDR ORDHDR Acknowledgement Availability Report Book Trade Orders Book Trade Price/Availability Update Claims Acknowledgement Claims Message Complex Order Credit Note Credit Advice Customer Information Debit Advice Delivery Confirmation Delivery Notice Dye Instruction General Communication Home Shopping Orders Invoice Issues Location Planning Report Picking Instruction Purchase Order

PAYORD PRIHDR PROHDR PPRHDR RDAHDR RDBHDR RIFHDR SADHDR SNPSTS SRMHDR SORDET SORDAY SRSHDR RIFHDR UCNHDR UPLHDR UTLHDR

Payment Order Price Information Product Information Product Planning Report Retailer Database Retail B, 1-4 Retailer Database Retail Issues File Stock Adjustment Stock Snapshot Statement & Remittance Details Supply and Returns Details Supply and Returns Summary Supply and Returns Summary Retail Issues File Uplift Confirmation Uplift Instruction 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 MDNs (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 subcommittee 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 todays 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 todays 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 1980s 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 OffShore 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,

NACHAthe governing body of the U.S. ACH Networkadopted 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 worlds leading providers of networking based solutions does not manufacture any of their own equipment. All of Ciscos 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 worlds 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

OEMs 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 orderto-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 industrys 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 companys supply chain and how they must adhere to various industry standards in order to conduct business with them.

One of Europes 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 automakers 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 USs 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 Baosteels global B2B e-commerce strategies. Using GXS Enterprise Gateway and Trading Grid Messaging Service solutions Bsteel provides a unified platform for integrating Baosteels 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 elements 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 microchips 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 banks account processing software would be communicated to the customers 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 UKs 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 certificates 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 organizations critical business processes. Enterprise Resource Planning: Packaged software systems using database technology and a single interface to control all the information related to a companys 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 SAPs 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-bysegment, 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 VANs who link to one anothers 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 RosettaNets 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 RosettaNets global standards. RosettaNet is also represented locally in Europe. Information on RosettaNets 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/#