Wednesday, November 23, 2011

E-Commerce & EDI Basics

1. E-Commerce Basics


1.1. E-Commerce


1.1.1. What is e-commerce?


In its most basic definition, e-commerce means buying and selling on the Internet. E-Commerce is the conducting of business communication and transactions over networks and through computers. As most restrictively defined, electronic commerce is the buying and selling of goods and services, and the transfer of funds, through digital communications. However EC also includes all inter-company and intra-company functions (such as marketing, finance, manufacturing, selling, and negotiation) that enable commerce and use electronic mail, EDI, file transfer, fax, video conferencing, workflow, or interaction with a remote computer. Electronic commerce also includes buying and selling over the World Wide Web and the Internet, electronic funds transfer, smart cards, digital cash (e.g. Mondex), and all other ways of doing business over digital networks. According to the stories and the stock market analysts, it saves people time and money, and at the same time transforms tiny companies in remote locations into global marketing giants.

1.1.2. How is e-commerce conducted?


E-commerce can be divided into a number of categories or models, each with its own set of "specialized" business methods. Who is buying and selling what has determined how buyers and sellers find each other and make the transactions.


1.1.3. Some working models of e-commerce


Every buyer and seller on the Internet falls into a specific category, determined by whom they sell to and/or what they buy. And e-commerce can be divided into a number of categories: business to consumer, business to business, "tool vendor" to business and perhaps even "yard sale" where consumers periodically sell to each other. In this section, we will look at the two big categories of Web transactions: direct-to-consumer and business-to-business.

1.1.3.1. Companies that sell direct-to-consumers


Arguably, the most famous manifestations of e-commerce working models are the consumer-direct supply companies, where, it seems, the sky is the limit. These companies include pre-existing companies and start-ups, such as --

· mega-distributors, like amazon.com and its imitators that resell original publishers products;

· search engine companies, like Yahoo,(now calling themselves "portals") primarily help individuals find anything in the world;

· auction sites, like ebay.com, that aim for the bargain-hunters who will compete with other consumers for specific products and one-time deals;

· manufacturers, like Gateway; and

· financial institutions (banks and day-traders), such as e-trade.com that sell on-line investing and banking services.

1.1.3.2. Companies that sell business-to-business only

The second type of e-commerce model follows more traditional business methods, where pre-qualified buyers do business with pre-qualified sellers. Unlike the direct-to-consumer "upstarts," these companies moved into the on-line marketplace with their existing supply-chain members in a drive to increase productivity and efficiency within the business network.

· It all started with EDI. Manufacturers and government agencieshave been involved in e-commerce for years. They used expensive, private networks, which used standard procedures and formats, known as EDI or electronic data interchange.

· EDI expansion allowed data sharing through "extranets." Some companies, like IBM, GE, Hewlett Packard and others, converted their private networks, standard procedures and formats, as well as pre-certified participants, into Internet-based, controlled-access extranets. Just changing the transaction medium (from paper to electronic) increased efficiency, saved time and made EDI more affordable for all of the participants. These traditional supply-chain members (often called "communities" in e-terms) continue to do business with each other this way.

· Success with extranets opened the floodgates Soon, "outside" manufacturers, distributors and service providers to industry converted existing paper catalogs and price lists to electronic images and posted them on their Web sites. With little more than a phone or fax number to enable the transaction, they followed the e-business leaders into this new era of business.

1.2. EDI: A New Look At An Established Technology


Electronic data interchange still offers significant benefits and opportunities to vendors and enterprise alike. Pressure from new Internet-based entrants is, in fact, only making EDI more competitive.

Electronic data interchange (EDI) is often dismissed as a legacy technology that will inevitably be replaced by Internet-based communications, especially those based on XML. The reality is quite different, however. EDI has served many enterprises’ business-to-business (B2B) transaction communication needs very well for decades, and it remains a mission-critical backbone across many important industry verticals. Moreover, few enterprises are anxious to abandon their investments in EDI — investments that continue to deliver significant return on investment (see “EDI: Mature, Conservative and Valuable,” COM-15-7616).

Despite the emergence of IP-based trading networks, EDI is still used for the majority of application integration projects involving fully digital B2B collaboration among trading partners. Just as important, EDI— despite being an established, mature technology — continues to evolve significantly in response to new enterprise requirements and competitive pressures. For a look at one critical and rapidly evolving area of EDI technology, see “EDI Translators: New Offerings Present New Opportunities,” COM-15-9499.

Competition from XML, IP-based EDI value-added networks (VANs) and emerging transaction delivery networks (TDNs) has increased. However, these competitive entrants have not replaced EDI — at least not altogether — simply because VANs continue to offer enterprises the key benefit their name implies: adding value to network-



based transactions (see “Value-Added Networks: An Updated Overview,” COM-15-9442). Although the new competitive entrants have put pressure on VAN pricing, the traditional VANs continue to offer a viable solution for enterprises that conduct extensive B2B transactions. VANs have established very high expectations among their enterprise clients. Some emerging IP-based solutions offer useful new functionality and competitive pricing, but few can match the depth and breadth of VAN solutions. One of the key reasons for the enduring success of EDI is a high degree of standardization. Emerging XML-based standards organizations, such as RosettaNet, continue to struggle to expand their scope beyond niche deployments. (RosettaNet’s use, for example, is largely confined to one industry vertical: high technology and electronic component manufacturing.)

By contrast, the leading EDI standards —

Accredited Standards Committee (ASC) X12 and United Nations Electronic Data Interchange for Administration, Commerce and Transport (UN/EDIFACT) — continue to evolve to meet the changing and expanding needs of more than a dozen industries.

As a result of these many benefits — both established and potential — EDI continues to present significant opportunities to vendors and enterprises.

Summary: EDI continues to evolve to meet changing enterprise requirements and deliver significant benefits to enterprises — and vendors — across a broad range of industries. Competitive pressure from new market entrants, far from signaling the end of EDI, has only made EDI more attractive in functionality and pricing. Enterprise IT decision makers cannot afford to ignore the enduring importance of EDI.

1.3. Understanding EDI


1.3.1. What Is EDI?


Electronic data interchange (EDI) is commonly defined as the application-to-application transfer of business documents between computers. Many businesses choose EDI as a fast, inexpensive, and safe method of sending purchase orders, invoices, shipping notices, and other frequently used business documents.

EDI is quite different from sending electronic mail messages or sharing files through a network, a modem, or a bulletin board. The straight transfer of computer files requires that the computer applications of both the sender and receiver (referred to as "trading partners") agree upon the format of the document. The sender must use an application that creates a file format identical to your computer application.

When you use EDI, it's not necessary for you and your trading partner to have identical document processing systems. When your trading partner sends a document, the EDI translation software converts the proprietary format into an agreed upon standard. When you receive the document, your EDI translation software automatically changes the standard format into the proprietary format of your document processing software.

1.3.2. EDI: A Comprehensive Definition.


EDI is both a technology and a service model for the trusted exchange by automated electronic means of business documentation between trading partners and between enterprises and government agencies.



Electronic Data Interchange, or EDI, is the electronic exchange of business data. Using a standard format, EDI provides a method of transmitting business data from one computer to another, without the need to re-key data. This electronic link can result in more effective business transactions.

1.4. Golden Rules.


1.4.1. The 1st Golden Rule Of EDI


Most companies “do” EDI, not because they thought it was a good idea, but because they had to. They were forced to comply with the 1st Golden Rule of EDI, which is “The Company that has the gold gets to makes the rules.” When Wal-mart, Sears, or Ford says that the only way their suppliers can become one of their suppliers is if they are EDI capable, their suppliers become EDI capable. The up side is that their suppliers get to keep their best customers. The down side is that they have increased their costs. They now have the expense of two customer order systems – their legacy system and their EDI system – they are doing their customer’s data entry, and they are carrying their customer’s inventory. These companies are only doing what is known as Compliance EDI.

1.4.2. The 2nd Golden Rule Of EDI


Those suppliers who understand the strategic value of EDI are following the 2nd Golden Rule of EDI – “do unto others as they have done unto you.” They are receiving the full benefit of EDI in two ways. First, they have integrated EDI with their business systems – they are not doing rip-and-read EDI. Secondly, they are requiring their suppliers to become EDI ready so they can pass the cost farther down the supply chain. Companies in this category are doing Strategic business.

1.5. EDI History


The early signs of EDI date all the way back to the early 1960s when a few large companies had their major suppliers dial-in and download orders from their computers. Each company had its own format, so suppliers had to program differently for each trading partner.

1.5.1. TDCC Develops The 1ST EDI Standards:


In 1968, the transportation industry recognized that the abundance of paperwork was beginning to present a problem. Transportation companies were forced to process tremendous amounts of paperwork in order to conduct their businesses. The time-consuming nature of this paperwork was slowing the movement and consignment of shipments. The transportation industry decided to correct this problem by organizing a committee, called the Transportation Data Committee (TDCC), to develop standard formats for exchanging business information.

TDCC organized an industry wide program for data standards, message formats, standard codes, communications protocols, and other details that would support the new concept of computer to computer electronic data interchange; and eliminate paperwork altogether. In 1975, TDCC released the first EDI documentation: Rail Transportation Industry Application.

Soon the transportation industry's success spread to other industries. More and more companies began communicating via EDI within their industry. Unfortunately, all the standards that were developed at this time supported only transportation related issues. Soon the question was raised "How can my business enjoy the benefits of EDI too?"



1.5.2. ANSI Charters The ASC X12e


In 1978, The American National Standards Institute (ANSI) used the pioneering work of TDCC and the National Association of Credit Management Credit Research Foundation to charter a committee known as the ASC (Accredited Standard Committee) X12. This committee's main objective was to develop uniform standards for inter-industry electronic interchange of business transactions.

1.5.3. More Industry-Specific Standards


In 1981, the Retail Grocery Industry plunged into the EDI arena with the publication of Arthur D. Little Inc.'s report on "Electronic Data Interchange Grocery Industry Feasibility Report". This report resulted in the formation of the Uniform Communication Standard Program (UCS), which provided industry specific transactions - purchase orders and invoices - for use in the grocery and retail community.

The Public Warehousing Industry created the Warehousing Industry Network Standards (WINS) in 1982, which provided transactions that best suited the needs of their members.

There were many other industries that played a major role in the development of EDI; one notable industry was the Auto Industry Action Group (AIAG), which insisted that by 1988, all U.S. automakers and their suppliers would use the standards that were to be developed by ANSI. Car makers notified their vendors that if they were not able to communicate electronically by that time, they would take their business elsewhere.

1.5.4. ANSI Standards Published


In 1983, ANSI published the first five American National Standards for EDI. Today there are well over 300 additional standards and guidelines in development.

1.5.5. The Development Of International Standards


As users began to conform to the X12 standards, they ran into problems when communicating electronically outside of their national boundaries. International users found that the U.S. standards often did not meet their specialized needs. In 1988, the United Nations chartered UN/EDIFACT (Electronic Data Interchange For Administration, Commerce and Trade) to develop international EDI standards. These standards take the form of United Nations Standard Messages (UNSMs), which are analogous to what ANSI X12 calls Transaction Sets.

EDIFACT has played a significant role in increasing competitiveness as well as helping to remove trade barriers in Europe. This emphasis has led many to believe that EDIFACT is a "European Standard". While many European countries have selected UN/EDIFACT as their EDI standard of choice, this selection is by no means restricted to Europe. Canada, for example, selected UN/EDIFACT as its national EDI standard over 5 years ago.

Users involved in EDI will reap various benefits by adopting this universal EDI standard: overseas expansion, expense control, and the elimination of support for multiple formats. However, in countries where EDI is already well established, particularly the USA, national standards will probably continue to be used for domestic EDI for some time to come.



1.6. Why Would I Use EDI?


1.6.1. Save Time and Money


EDI is a tremendous cost- and time-saving system. Since the transfer of information from computer to computer is automatic, there is no need to rekey information. With no data entry, the chance for error drops to near zero. RJR Nabisco estimates that processing a paper purchase order costs the company $70. Processing an EDI purchase order reduces the cost to a mere 93 cents.

1.6.2. Improve Customer Service


EDI is also a method of improving customer service. The quick transfer of business documents and marked decrease in errors allow you to fill orders faster. KMart and other retailers have implemented a program called Vendor Stock Replenishment (VSR). VSR requires that vendors maintain appropriate inventory levels in all stores. With VSR, you don't risk having the store run out of your product while you wait for a purchase order. You send stock as your EDI system reports it is necessary and automatically bill the client. It cuts days, even weeks, from the order fulfillment cycle and ensures that your product is always on the shelf.

1.6.3. End Repetition


EDI documents are stored in a mailbox. You can look at the documents in your mailbox at any time. If your customer wants a copy of an invoice, instead of calling you they simply check their mailbox. Imagine the time savings from not having to copy and fax/mail copies of invoices or purchase orders.

1.6.4. Expand Your Customer Base


Many large manufacturers and retailers are ordering their suppliers to institute an EDI program. When evaluating a new product to carry or a new supplier to use, the ability to do EDI is a big plus. Keep in mind, too, that these same companies tend to stop doing business with suppliers who don't comply with EDI. There are other uses for EDI as well. Universities use EDI to exchange transcripts quickly. Auto manufacturers use EDI to transmit large, complex engineering designs created on specialized computers. Large multinational firms use EDI to communicate between locations.

1.6.5. Improves Data Accuracy


You can eliminate the need to re-enter data from paper documents and thus prevent potential data entry errors. It is estimated to be one-tenth the cost of handling its paper equivalent.

1.6.6. Reduces Technical Complexity


With EDI, companies use standardized data formats to exchange documents. EDI allows companies using different systems to achieve computer-to-computer electronic exchange of business documents.

1.6.7. Lowers Personnel Needs


EDI can help companies reduce the need for personnel involved in paper business transaction processing.

1.6.8. Accelerates Information Exchange


The lead-time between start and completion of order processing is greatly reduced. By timeout scheduling companies can plan production more accurately and thus reduce stock inventories.



1.6.9. Bottom line


· Improves data accuracy.

· Reduces technical complexity.

· Lowers personnel needs.

· Accelerates information exchange.

· Improved trading partner relationships.

· Improved intra-company flow of data.

· Improved planning and processing.

1.7. EDI Business Process Model





· The extract of data from the institution's database.

· The formatting of the data into the EDI standard format.

· The encryption of the data for security purposes.

· The transmission of the data through the chosen communication medium to the trading partner.

· The decryption of the data on receipt.

· The translation of the data from the EDI format to plain flat file format.

· The upload of the data into the trading partner's database.

· The acknowledgement of receipt, which follows the process in the reverse direction.

1.8. What Is EDI Not?


· EDI uses existing technology, but is not itself a technology.

· EDI mapping standards provide a way to map pre-existing data elements in a standard way;

they do not dictate what those elements must be or what form they must take.



1.9. EDI Business Process Cycle





1.10. Overview Of EDI Process


EDI transmits machine-readable data between trading partners’ computers. For example, the buying company generates the transactions in its purchasing system, as it always has. However, instead of using purchase order data to develop the traditional paper transaction, it passes the data through application link software called an EDI translator that maps it into a standard machine-readable EDI data format. That data is then transmitted to the seller’s site, where it is passed through the sellers’ application link, which maps it to the internal format expected by the sellers order entry application. Order entry processes the data just as it would any incoming purchase orders.

1.11. What is the most common EDI cycle?


· Customer transmits EDI 850 (purchase order).

· Supplier transmits EDI 997 (functional acknowledgement).

· Supplier transmits EDI 856 (advance ship notice).

· Customer transmits EDI 997 (functional acknowledgement).

· Supplier transmits EDI 810 (electronic invoice).

· Customer transmits EDI 997 (functional acknowledgement).

· Customer transmits EFT (electronic funds transfer).

· Payment.



1.12. Components Of EDI System.


· EDI Standards.

· Application Systems.

· EDI Gateway.

· Communication Network.

1.12.1. EDI Gateway.


The purposes of an EDI Gateway are to convert application system data into a standard format and to send messages to and receive messages from trading partners. A typical EDI Gateway consists of a hardware platform and EDI translation software.

· Hardware: Requires a host system (e.g., a personal computer, midrange computer or mainframe computer) and communications equipment (e.g., modems and communications lines).

· EDI Translation Software: Specialized software required by each trading partner that performs three basic functions:

    1. Mapping: Reformats outgoing data from an organization-specific file format to a standard EDI format for electronic processing and reformats incoming data from a standard EDI format to an organization-specific file format that can be processed by the business application systems.
    2. Translating: Adds standard enveloping and delimiter protocols to the mapped data to permit the EDI message to be routed properly to the designated trading partner.
    3. Communicating: The process that sends an EDI message to a trading partner via a communication network.

1.12.2. Communication Network.


A communication network is used in EDI to electronically transmit standard business documents between trading partners. Each communication network is typically used by a number of business entities, and often linked to other networks to enable them to transfer EDI messages to each other. There are several options available for transmitting EDI documents:

Direct Connect: Organizations may communicate EDI messages by providing direct connects to their systems for their trading partners. In this instance, a trading partner would dial directly into an organization's EDI gateway and transmit their EDI transactions.

Value Added Networks (VANS): A third party network, known as a value added network or VAN, serves as an intermediary between trading partners. A VAN is an electronic service provider that receives, stores, and transmits EDI and other electronic messages. VANS support multiple types of communications hardware and software configurations, thereby reducing an organization's burden to establish individual computer connections with each one of it's trading partners.

Once the file has been put into a structured format, it is transmitted by one of several communication methods directly to the intended receiver or to a third party network. The third-party network, called a Value Added Network (VAN), provides a service much like a post office. The VAN receives the transmitted documents and places these documents into an electronic mailbox for the receiving party to pick up. By dialing into the network, the receiving party can access its mailbox and retrieve the transmitted documents.

EDI Thorough VANS






EDI Thorough Web




When a company as big as Wal-Mart talks, everybody listens. When the retailer announced in September that it would do electronic data interchange (EDI) with suppliers over the Web instead of using value-added networks (VAN), it was a signal that EDI over the Web is ready for heavy-duty corporate use after years of development.

Driven by the prospect of saving thousands of dollars a month, more and more trading partners are sending EDI messages over the Internet -- the closest thing in networking to a free lunch -- rather than over third-party network services, according to vendors and analysts.

Although such a move can pay for itself in as little as two months, it requires customers to do some of the work the VAN used to do, such as making sure the proper person is notified if a purchase order or invoice doesn't get through. However, if customers can cost-effectively become their own VANs and choose the right Web EDI tools, the savings can be compelling.

Of course, it has been possible to do EDI transactions over the Web for years. But it often meant installing software from the same vendor at both ends of the transaction, something that's hard to do for thousands of trading partners, many of which are small businesses. But over the past year, two things have greatly boosted acceptance of EDI over the Web.

1.12.3. EDI Standards


EDI Standards And Initiatives

There are several EDI standards that have been around for many years. But as the Internet took hold, new techniques for implementing EDI developed in groups and consortiums such as the W3C (World Wide Web Consortium), Commerce-Net, Rosetta Net, and Open Buying on the Internet (OBI). The Web sites for these organizations are listed on the related entries page.

New EDI standards are currently under development. Some examples are described here.

ANSI ASC X12 (American National Standards-X12)

X12 is a standard that defines many different types of documents, including air shipments, student loan applications, injury and illness reports, and shipment and billing notices. The ANSI (American National Standards Institute) assigned responsibility for development of EDI standards to the ASC (Accredited Standards Committee) X12 organization in 1979. X12 has roots in work done in the shipping industry by the TDCC (Transportation Data Coordinating Committee) and work done in the food distribution industry by the UCC (Uniform Code Council).

In 1979, the American National Standards Institute (ANSI) chartered a new committee called the Accredited Standards Committee (ASC) X12 to develop uniform standards for cross-industry electronic communications. The committee established the ANSI ASC X12 standard, which is referred as X12 standard normally, provides guidelines and rules for EDI on how the data should be structured, what documents should be transmitted electronically, what information should be included in each document, what sequence the information should follow, what form of codes, identification numbers should be used, and so on.

The X12 standard defined a set of documents, which is referred as transaction sets, for a wide range of business transaction forms. Each transaction set is given a numeric code that is similar to the way in most of the paper forms where form numbers are assigned. For example, the transaction set 850 is referred to the purchase order, 810 is assigned to the invoice, and so on. For each of the transaction set, there is a document that defined the specification of that transaction set.

UN/EDIFACT

UN/EDIFACT (United Nations/Electronic Data Interchange for Administration Commerce and Transport) is an international set of EDI standards that are published by the United Nations Trade Data Interchange Directory (UNTDID). The standards include syntax rules and implementation guidelines; message design guidelines, directory sets defining messages, data elements, and code sets, among other definitions. It is built upon X12 and TDI (Trade Data Interchange), the latter being a generic EDI standard used in Europe.



Open-EDI

The ISO (International Standards Organization) and IEC (International Electrical Committee) are developing an EDI reference model under a joint committee called Open-EDI. The goal of Open-EDI is to allow electronic transactions among "multiple autonomous organizations" that may or may not have any prior business relationships. In other words, businesses should be able to establish trading partners over networks like the Internet upon first contact and without any pre-agreement, assuming trust systems are in place.

1.13. X12 Message Structure


ISA / GS Segments.

The purpose of the Interchange Control Structure is to define the control structures for the electronic interchange of one or more encoded transactions including the EDI encoded transactions of ASC- X12. This standard provides the interchange envelope of a header segment (ISA) and trailer segment (IEA) for the electronic interchange through a data transmission, and it provides a structure to acknowledge the receipt and processing of this envelope. These header and trailer segments envelope one or more functional groups, demarcated by the GS/GE envelope, and perform the following functions:

• Define the data element separators and data segment terminators

• Identify the sender and receiver

• Provide control information for the interchange, and

• Allow for authorization and security information.

The interchange header is transmitted first, followed by any optional interchange-related control segments, followed by the data in functional groups, with the interchange trailer following the data. The Interchange Control Header (ISA) sets the actual values of the data element separator and the segment terminator for this interchange. The character (usually an unprintable character) used to separate the data elements in the ISA segment is the character that will be used to separate the data elements in all segments, which follow the ISA segment until an occurrence of the IEA segment is encountered.






Table 1 shows an example of some common documents and their corresponding transaction set numbers and specification numbers.

Transaction SetDocument TitleSpecification No.
850Purchase OrderX12.1
810InvoiceX12.2
840Request for QuotationX12.7
843Response for RFQX12.8
855P.O. AcknowledgementX12.9
856Ship NoticeX12.10
861Receiving AdviceX12.12
830Planning ScheduleX12.14



Table 1: List of some X12 Common Documents (Source: Margaret: 1990)

Inside each document or transaction set, the X12 standard classifies each line of information into data segments. And for each segment, it further defines the format of each data element. Figure 3 illustrates the correspondence between a paper document and the components of an EDI standard.

X12 Interchange Control Enveloping Structure.

1. Authorization Information Qualifier.

2. Authorization Element.

3. Security Information Qualifier.

4. Security Information.

5. Interchange ID Qualifier.

6. Interchange Sender ID.

7. Interchange ID Qualifier.

8. Interchange Receiver ID.

9. Interchange Date.

10. Interchange Time.

11. Interchange Control Standards Identifier.

12. Interchange Control Version Number.

13. Interchange Control Number.

14. Acknowledgment Requested.

15. Usage Indicator.

16. Component Element Separator.

Sample:

ISA*00**00**ZZ*PARTNERID*08*MAERSKLOG*010920*07 16*U*00200*000007209*0*P*

X12 Functional Group Header.

1. Functional Identifier Code

2. Application Sender's Code

3. Application Receiver's Code

4. Date

5. Time

6. Group Control Number

7. Responsible Agency Code

8. Version ID

Sample:

GS*QO*PARTNERID*MAERSKLOG*20010920*2221*745*X*004010.

X12 Transaction Set Header.

1. Transaction Set Identifier Code.

2. Transaction Set Control Number.

Sample:

ST*315*000032888.

Figure 3: EDI Terminology (Source: Margaret: 1990)

Therefore, a typical X12 transaction set will include three parts of specifications, which are transaction set standards, segment directory, and data element dictionary. All together with these specifications, the X12 standard provided a flexible and generic EDI standard for organizations and trading partners to establish sessions and exchange information together under a compromised scheme.

1.14. EDIFACT


· EDIFACT stands for EDI for administration, commerce and transportation.

· It has been introduced by the UN center for the facilitation of administration, commerce and

transportation (UN/CEFACT) in the mid 1980s.

· Older European EDI standards such as TRADACOM, GENCOD, SEDAS and ODETTE have

all migrated to EDIFACT.

· EDIFACT has furthermore become an international standard as ANSI has stopped all work on

X12 since 1997 and X12 systems are migrating to EDIFACT.

1.14.1. EDIFACT Message Structure


1.14.2. EDIFACT: Structure

· EDIFACT Interchanges consist of messages, which are in turn composed of data

segments.

· The segments themselves consist of data elements.

1.14.3. EDIFACT Interchange Header Fields

1. Syntax Identifier

2. Interchange Sender

3. Interchange Recipient.

4. Date/Time of Preparation.

5. Interchange Control Reference.

6. Recipient's Reference, Password.

7. Application Reference.

8. Processing Priority code.

9. Acknowledgment Request.

10.Communication Agreement Identification.

11.Test Indicator.

1.14.4. EDIFACT Functional Group Header Fields


1. Functional Group Identifier

2. Application Sender's Identification

3. Application Recipient Identification

4. Date/Time of Preparation

5. Functional Group Reference Number

6. Controlling Agency

7. Message Version

8. Application Password.

1.14.5. EDIFACT Message Header Fields


1. Message Reference Number

2. Message Identifier

3. Common Access Reference

4. Status of the Transfer.

1.14.6. EDIFACT: Message Syntax


UNB+UNOA:1+6464:XX+1141:XX+BEN0273’

UNH+000001+ORDERS: 2:932:UN’

BGM+220+AC6464’

DTM+4:20000305:102’

NAD+BY+6464326::91’

NAD+SU+1149646::91’

UNS+D’

LIN+1++PT-1073-R:VP’

QTY+21:1600’

LIN+1++PT-1073-S:VP’

QTY+21:1200’

UNT+13+000001’

UNH

….

UNT

UNZ+1+BEN0273’

1.15. EDI Message Components


A complete ANSI ASC X12 EDI electronic exchange between trading partners occurs in basic units called messages, or transaction sets. A transaction set may represent a single business document(e.g. a purchase order or an invoice) or a single transaction set may contain multiple occurrences of a business document, as in the case of health care claims.(A Health Care Claim transaction set (837)may include many claims for the same provider.)

Over time the business community has arrived at series of standardized transaction formats to cover a wide range of business communication needs. Each transaction set has been defined with an extensive set of data elements required for a unique business document, with specified formats and sequences for each data element. Combinations of related data elements are built up into segments or logically related groups of data. All of the related segments for a transaction are then grouped together, and are preceded by a transaction header and followed by a transaction trailer record. If the transaction contains more than one transaction (many purchase orders sent to one vendor) several transaction groups would be preceded by another type of record, referred to as a functional group header, and would be followed by a function group trailer. Functional groups are included in interchanges, which envelops the entire transmission and includes all of the data sent to one trading partner. Here's a brief description of each of these terms:

· Data Element - Data elements are the smallest unit of information in an EDI message and represent a single unit of information (e.g., unit price, item description).A data element definition will describe:

1. The type of data (numeric, alphanumeric, date, time).

2. The minimum and maximum length allowed.

3. Code or conditional values that must be observed with the particular type of data.

· Data Segments - Data segments consist of strings of related data elements in a specific order. For example, an address segment may consist of city, state and zip code data elements. Each segment is preceded by a unique two to three character Segment ID, which identifies the nature of the data included in the segment. Each data element is separated one from another by a special character called a data element delimiter. The end of a segment is punctuated by another special character called a segment terminator. A city/state/zip address segment might look like this:

N4*Columbus*OH*43215~

N4 is the segment identifier that tells the translation software that the segment contains city/state/zip information. The special character "*" separates each of the unique data elements, and the special character "~" designates the end of the segment.

A segment definition for a specific transaction set will identify:

1. All mandatory data elements.

2. Any optional or conditional data elements.

3. The required sequence of data elements within the segment.

4. The maximum number of occurrences of the segment.

Transaction Sets - A transaction set, consists of logically related data segments in a specific order. Transaction sets are bounded by mandatory header and trailer segments. (The Segment ID for the Transaction Set Header is "ST" and the Segment ID for the Transaction Set Trailer is "SE"). For each transaction set, complete documentation is available to specifically define the information is required. A transaction set definition set will identify:

    1. The segments to be used in the message.
    2. The required sequence of the segments.
    3. Which segments are mandatory and which are optional.
    4. The number of times a segment may be repeated.

Functional Groups - A functional group is a group of similar transaction sets. Functional groups are also bounded by special header and trailer segments. (The Segment ID for the Functional Group Header is "GS" and the Segment ID for the Functional Group Trailer is "GE").

Interchanges - An interchange is a complete EDI message from one trading partner to another that can include multiple functional groups and transaction sets. Interchanges are enveloped within interchange control segments, which specify, among other things, the sender and receiver of the interchange identified by their respective electronic addresses. (The Segment ID for the Interchange Control Header is "ISA" and the Segment ID for the Interchange Control Trailer is"IEA").

The entire transmission can be viewed as a group of envelopes, with each transaction set enclosed in a transaction set envelope, all of the transaction sets of the same type enclosed in a functional group "envelope," and all functional groups enclosed within an interchange "envelope" that contains all of the electronic address information needed to reach the trading partner.

Here is a graphical representation of the components of a standard EDI electronic message:



1.16. Inbound And Outbound Messages:


Technical level :


Defined by the three record types compatible with the IDoc interface:

Control record.

Data record.

Status record.



Business level :

Defined by the segments of an IDoc. Segments are structures used to interpret field SDATA in the data record.

1.17. What Is The Link Between EDI And Profits?


EDI the toolEDI the featuresEDI the benefits
Shared forecasts Inventory turns increase Cut costs!
Transaction automation Reduced labor Cut costs!
Integration with systems Fewer errors, rework,

less paper
Cut costs!
Electronic payments Better cash flow Cut costs!
Shared sales and

inventory data
Improved availability Increase sales!
Integration and high

speed data transfer
Access to quality

information
Increase sales!
Transaction automation People add value Increase sales!

1.18 Disadvantages Of EDI

Too Many Standards

There are too many standards bodies developing standard documents formats for EDI. For example your company may be following the X12 standard format, while your trading partner follows the EDIFACT standard format.

Changing Standards

Each year, most standards bodies publish revisions to the standards. This poses a problem to EDI users. You may be using one version of the standard while your trading partners are still using older versions.

EDI Is Too Expensive

Some companies are only doing business with others who use EDI. If a company wants to do business with these organizations, they have to implement an EDI program. This expense may be very costly for small companies.

Limit Your Trading Partners

Some large companies tend to stop doing business with companies who don't comply with EDI. For example Wal Mart is only doing business with other companies that use EDI. The result of this is a limited group of people you can do business with.

Tuesday, August 30, 2011

Sunday, August 21, 2011

EDI X12 vs UN/EDIFACT



The table below highlights the difference between the EDI X12 standard and EDIFACT standard.



Topic


ANSI X12


UN/EDIFACT


Application


- Mostly  used in U.S and North America


- Mostly used in Europe and Asia


Terminologies Equivalence 


- Transaction Sets


- Messages


     - Loops


    - Groups


     - Terminators


    - Separators


Interchange

Header/Trailer Segments


 - ISA/IEA


- UNB/UNZ


Group

Header/Trailer Segments


 - GS/GE


- UNG/UNE (optional)


Transaction Set, (Message) 
Header/Trailer Segments


 - ST/SE


- UNH/UNT


Separators Specification Segment 


 - None


-  UNA (optional)


Commonly used Terminators, (Separators)


Segment


~


'


Element


*


+


Composite


>


:


Release Indicator 


 - Not supported


- Supported


    Composite Elements


     - Rarely used


    - Commonly Used


Acknowledgment 


 - TA1 and 997


- CONTRL


Binary support


 - BIN, BDS segments


-  ISO 9735-8 - Associated data in EDI


? Security


 - ASC X12.58 - Security Structures



-  ISO 9735-5 - Security rules for batch EDI (authenticity,
integrity and non-repudiation of origin)
-  ISO 9735-6 - Secure authentication and acknowledgement
message (message type - AUTACK)
-  ISO 9735-7 - Security rules for batch EDI
(confidentiality)
-  ISO 9735-9 - Security key and certificate management
message (message type - KEYMAN)






The main difference between EDIFACT and X12 are

1.EDIFACT uses composite data elements
2.Looping and nesting procedures are different
3.There are 6 data elements types are defined in ANSI X12 while only three are
defined in EDIFACT
4.There is no provision in EDIFACT for optional fields
5.EDIFACT allows for two levels of syntax
6.And ofcourse the message structure in both
standards is different for different messages.






RosettaNet message format

RosettaNet:
Founded in 1998, RosettaNet is an independent, self-funded, non-profit consortium dedicated to the development of XML-based standard electronic commerce interfaces to align the processes between supply chain partners on a global basis


ELEMENTS OF ROSETTANET
Partner Interface Processes (PIPs)
A messaging system

Partner Interface Processes
· The sequence of steps required to execute an atomic business process between two supply chain partners
· Contain nonproprietary business processes
· Stand as discrete units of work that can be attached and built into other PIPs to achieve a larger business outcome
· Clusters and Segments
PIPs are designed to fit into seven Clusters, representing the core business processes or backbone of the trading network. Each Cluster is broken down into Segments -- cross-enterprise processes involving more than one type of trading partner. Within each Segment are individual PIPs

Few Important Points to NOTE

· More than 100 PIPs grouped into clusters and then to segments
· For example, Cluster 3 is Order Management and Segment 3A in this cluster is about Quote and Order Entry
· As an example of the PIPs in this segment PIP3A4: Manage Purchase Order

PIP 3A4: Manage Purchase Order
· Buyer creates a Purchase Order and sends it to the Seller
· Seller receives the Purchase Order and returns a Purchase Order Acceptance
· The Buyer determines success or failure based on message content

Example: PIP3A4 – Request Purchase Order
§ Cluster 3: Order Management
§ Segment 3A: Quote & Order Entry
§ 4th PIP

Doing Business through RosettaNet
· In order to do electronic business within the RosettaNet framework, there are a number of steps the partners have to go through
· First, the supply chain partners come together and analyze their common inter-company business scenarios (i.e., public processes), that is, how they interact to do business with each other, which documents they exchange and in what sequence
· Then they re-engineer these processes to define the electronic processes to be implemented within the scope of the RosettaNet Framework
· An electronic business process includes both the interactions between partner companies, and the private processes within the company
· RosettaNet provides guidelines only for PIPs which are the public part of the inter-company processes

Necessary to differentiate
· Public Business Processes: The process among the trading partners
· RosettaNet defines and fixes Public Business Processes in terms of PIPs
· Private Business Processes: The business processes internal to the company

Public Business Process


An Example
· Consider, for example, a scenario where a buyer requests the price and availability of some products from a seller (PIP3A2)
· After receiving the response, the buyer initiates a Purchase Order Request (PIP3A4)
· The seller, on the other hand, after acknowledging the Purchase Order Request, sends an invoice notification (PIP3C3) to the buyer
· The seller sends a transportation request (PIP3B1) to the shipper (There is a third party in this scenario, which is a shipper)
· The shipper, after shipment of the goods, sends the status of the shipment (PIP3B3)
· When buyer receives the shipment, it sends a shipment receipt notification (PIP4B2) to the seller.
· Finally, the seller prepares a billing statement and notifies the buyer (PIP3C5)

RosettaNet Messaging Structure
· Execution of PIPs involves exchanging messages between the parties, and RosettaNet provides a Business Message structure for this purpose
· RosettaNet business messages (also termed as action or service messages) consist of a message header and a message body
· Both the header and the body are complete, valid XML documents
· The header and the body are encoded within a multipart/Related MIME message

RosettaNet Messaging
· The message content is specified in individual PIPs
· Each PIP has one or more "actions" that are described by means of an individual DTD or schema
· RosettaNet Implementation Framework (RNIF) specifies and provides for a consistent mechanism to digitally sign and/or encrypt all RosettaNet messages (as needed), independent of the transfer protocol, PIP and the specific business document being exchanged
· It also specifies a reliable messaging mechanism based on "Acknowledgements"

RosettaNet Transport
· The PIP business message is encapsulated into a RosettaNet protocol message termed as "RosettaNet Object”
· The RosettaNet Object is composed of
· a version and content length header,
· content comprising a business action message, and
· a digital signature length followed by a digital signature trailer
· "RosettaNet Object” is encapsulated into a message of HTTP protocol and send as a as a direct HTTP message

The RosettaNet Business Message
Business Messages

TREE STRUCTURE FROM MESSAGE GUIDELINE

1 Preamble
2 |-- standardName.GlobalAdministeringAuthorityCode
3 |-- standardVersion.VersionIdentifier

1 Delivery Header
2 |à isSecureTransportRequired.AffirmationIndicator
3 |à messageDateTime.DateTimeStamp
4 |à messageReceiverIdentification.PartnerIdentification
5 | |à domain.FreeFormText
6 | |à GlobalBusinessIdentifier
7 | |à locationID.Value
8 |à messageSenderIdentification.PartnerIdentification
9 | |à domain.FreeFormText
1 | |à GlobalBusinessIdentifier
1 | |à locationID.Value
1 |à messageTrackingID.InstanceIdentifier

1 ServiceHeader
2 |à ProcessControl
3 | |à ActivityControl
4 | | |à BusinessActivityIdentifier
5 | | |à MessageControl
6 | | | |à fromRole.GlobalPartnerRoleClassificationCode
7 | | | |à fromService.GlobalBusinessServiceCode
8 | | | |à inReplyTo.ActionControl
9 | | | | |à ActionIdentity
10 | | | | | |à GlobalBusinessActionCode
11 | | | | | |à messageStandard.FreeFormText
12 | | | | | |à standardVersion.VersionIdentifier
13 | | | | |à messageTrackingID.InstanceIdentifier
14 | | | |à Manifest
15 | | | | |à Attachment
16 | | | | | |à description.FreeFormText
17 | | | | | |à GlobalMimeTypeQualifierCode
18 | | | | | |à UniversalResourceIdentifier
19 | | | | |à numberOfAttachments.CountableAmount
20 | | | | |à ServiceContentControl
21 | | | | | |à Choice
22 | | | | | | |à ActionIdentity
23 | | | | | | | |à GlobalBusinessActionCode
24 | | | | | | | |à messageStandard.FreeFormText
25 | | | | | | | |à standardVersion.VersionIdentifier
26 | | | | | | |à SignalIdentity
27 | | | | | | | |à GlobalBusinessSignalCode
28 | | | | | | | |à VersionIdentifier
29 | | | |à toRole.GlobalPartnerRoleClassificationCode
30 | | | |à toService.GlobalBusinessServiceCode
31 | |à GlobalUsageCode
32 | |à partnerDefinedPIPPayloadBindingId.Proprietary ReferenceIdentifier
33 | |à pipCode.GlobalProcessIndicatorCode
34 | |à pipInstanceId.InstanceIdentifier
35 | |à pipVersion.VersionIdentifier
36 | |à QualityOfServiceSpecification
37 | | |à QualityOfServiceElement
38 | | | |à QualityOfServiceClassificationCode
39 | | | |à Value
40 | |à Choice
41 | |à KnownInitiatingPartner
42 | | | |à PartnerIdentification
43 | | | | |à domain.FreeFormText
44 | | | | |à GlobalBusinessIdentifier
45 | | | | |à locationID.Value
46 | |à UnknownInitiatingPartner
47 | | | |à PartnerIdentification
48 | | | | |à domain.FreeFormText
49 | | | | |à GlobalBusinessIdentifier
50 | | | | |à locationID.Value
51 | | | |à UniformResourceLocator

Payload Components


The payload part of the RosettaNet Business Message comprises the Service Content
(which is either an action message or a signal message) and zero or more OPTIONAL
attachments.
The payload is the actual business content that the Service Header describes or
identifies. The Service Header format is fixed and independent of payload. The
Service Content part of the payload (i.e., the action message or signal message)
changes based on the specific business content being exchanged, which depends on
the PIP type and instance. The attachments are also dynamic per instance of the
business message as should be expected

· Service Content
· Handling Attachments
· Referring to Attachments from within Service Content
· Shipping Non-RosettaNet Service Content in the Payload

GIS & RosettaNet
To configure trading partner information to implement RosettaNet, you must:
1. Create a trading profile for your organization and each of your trading partners. The trading profile enables you to define how you want to:
Build and parse RosettaNet message data.
Define message security and transport protocols.
2. Depending on contractual requirements agreed upon by you and your trading partner, you then create the following types of contracts:
For each RosettaNet Partner Interface Processes™ (PIP) you plan to exchange. For example, if the company is initiating and responding to PIP 3A4, you must create a contract to initiate PIP 3A4 and one to respond to PIP 3A4.

When setting up trading profiles in, you must perform the following tasks:
1. Create an identity record for your organization, indicating your organization as the base identity.
2. Create an identity record for each of your trading partners.
3. Create the following records in order to complete the trading profiles for your organization and each of your trading partners:
Transport, Document exchange, Delivery channel, Packaging, Profile
To create a contract:
1. From the Administration menu, select Trading Partner > Contracts.