EDI CONCEPTS

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.

EDI And The Business Cycle

A typical Procure to Pay cycle may be as follows:

1. A buyer has a need for merchandise and creates a Request for Quote (RFQ) document.
     Messages: X12-840    EDIFACT-REQUOTE  IDOC- ORDERS01 to ORDERS04

2. The seller responds with a Quote providing the price and other pertinent information as to how the request would be fulfilled.
     Messages: X12-843    EDIFACT-QUOTES   IDOC- ORDERS01 to ORDERS04

3. Upon acceptance of the quote, the buyer sends a purchase order document to the seller requesting goods at quoted prices.
     Messages: X12-850    EDIFACT-ORDERS   IDOC- ORDERS01 to ORDERS04

4. The seller responds acknowledging that the goods can be delivered at the prices specified and in the time frame indicated. A functional acknowledgment transaction may also be sent indicating successful receipt of any EDI transaction without indicating any conditions or details of the business transaction.
     Messages: X12-855    EDIFACT-ORDRSP   IDOC- ORDERS01 to ORDERS04

5. The seller ships the goods and sends a shipping notice providing details regarding the carrier, product identification,dates, and other information about the shipment.
     Messages: X12-856    EDIFACT-DESADV   IDOC- SHPMNT01 to SHPMNT03

6. The seller sends an invoice document, billing the buyer for the goods. There is also an EDI document that allows a combined shipment and billing notice.
     Messages: X12-810    EDIFACT-INVOIC   IDOC- INVOIC01

7. The buyer notifies his bank that payment is to be made (payment order) and uses another form of the same document (remittance advice) to inform the seller that payment is being made.
     Messages: X12 820 EDIFACT-REMADV   IDOC-  PEXR2001 and PEXR2002

Summarize:

Buyer to seller       840 Request For Quotation

Seller to Buyer       843 Response for Request For Quotation

Buyer to seller        850 Purchase Order

Seller to Buyer       855 Purchase Order Acknowledgement

Seller to Buyer       856 Shipment Notice/Manifest

Seller to Buyer       810 Invoice

Buyer to seller        820 Payment order/Remittance Advice

RosettaNet 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)

EDI basic concepts

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 will replace paper documents and second exchange of documents takes place in standard 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
one company has automated a number of business documents like purchase orders and invoices, you may wish to integrate your EDI environment to other business systems. Implementing EDI first time can appear to be daunting challenge for many companies however there are no of ways to which EDI can be implmented across business. For companies that have internal resources to manage EDI infrastructure, EDI can be deployed by installing software which would allow EDI information sent via VAN (value added network) or point to point connection.
VAN are private networks where EDI related information can be exchanged between companies securely. trading partners will require account with EDI VAN provider which simply acts as electronic mail box to both send and receive electronic documents.
In today fast faced business world your business already moving in this direction,customers and suppliers may already approaching you to begin trading information electronically.
So what is document ? A document is any form of communication ,usually paper based sent between two companies
*purchase orders *Invoices * Shippinf Notices etc
EDI replaces human readable , paper or electronic based documents with machine readable, electronically coded documents with EDI sending computer will creates message and receive computer will interpret the message without human involvement.
There are many ways in which EDI environment can be implemented across trading partnet community.Whether you are looking to implement EDI for the first time or expand your EDI infrastructure to support trading partners in other regions in around the world.There are many EDI tools and connectvity options available to suit your needs.