Standard Mapping Guide
Between
xCBL 3.0 and ANSI X12 4010 

April 12, 2001
Version 1.0

Table of Contents
1	Introduction	4
2	Background	4
3	Status of this Document	5
4	Acknowledgements	5
5	Audience	5
6	Pre-Requisites	6
7	References	6
8	Use of Mapping Spread Sheets	6
8.1	Column Definitions	7
8.1.1	Source Data	7
8.1.2	Data Type	9
8.1.3	Occurs	9
8.1.4	Target Path	9
8.1.5	Data Type-Target path	9
8.1.6	Occurs-Target path	9
8.1.7	Mapping Comments	9
8.2	Example Forward Mapping	10
8.3	Example Reverse Mapping	10
8.4	Field Lengths	10
8.5	Envelope Mapping Between xCBL 3.0 and ANSI X12	11
8.6	Defaults	11
8.7	Required Elements – Quick Reference Guide	12
8.8	Complex Mapping Guide	12
8.9	Specific Mapping Information	12
8.9.1	xCBL 3.0 Order and ANSI X12 4010 – Set ID :850	12
8.9.2	xCBL 3.0 OrderResponse and ANSI X12 4010 – Set ID :855	12
8.9.3	xCBL 3.0 ChangeOrder and ANSI X12 4010 – Set ID :860	13
8.9.4	xCBL 3.0 OrderResponse and ANSI X12 4010 – Set ID :865	13
8.9.5	xCBL 3.0 Invoice and ANSI X12 4010 – Set ID :810	14
8.9.6	xCBL 3.0 AdvanceShipmentNotice and ANSI X12 4010 – Set ID :856	14
8.10	Contacts	14

1	Introduction
The emergence of e-Marketplaces has enabled e-business procedures to be available to large numbers of SMEs (small to medium sized enterprises) who have previously been denied the opportunities and benefits of electronic trading. Many large companies who are using EDI for their electronic trading with a limited number of trading partners are enthusiastically embracing this method of e-business that allows them to reach all potential trading partners regardless of size or geographical location.
Engineering and development staff members within companies deploying trade exchanges will need to map existing systems to the new systems they are implementing.  These standard generic mappings have been prepared to aid this work.
The Standard mapping of the Commerce One xCBL 3.0 (XML Common Business Library) documents to EDI have been created in the form of Excel spreadsheets. For each document, the spreadsheet contains two worksheets, one where the source and target are xCBL 3.0 and the corresponding EDI document respectively, and the second shows the reverse mapping i.e. EDI to xCBL 3.0.
This guide gives instructions on how to use the spreadsheet along with background information on the intent and function of the mappings. Subsections, on a per document basis, contain notes specific to the document mappings.
The mapping spreadsheet and user guide are downloadable from www.xCBL.org. It is not currently planned to provide viewable file formats of the mapping spreadsheet on the website.
2	Background
ANSI X12 is the most common EDI syntax in use in the United States; the equivalent outside of the United States is UN/EDIFACT.  
Mapping ANSI X12 documents to the Commerce One xCBL 3.0 documents will provide a framework that is consistent across companies and exchanges.
The ANSI X12 transaction sets are generic to allow electronic trading across all industries. For this reason the messages are  large, therefore when implementing ANSI X12 each industry will produced a sub-set of the original message to be used in a customized way.  A company will have an Implementation Guide (IG) that explains the use of the subset.  This guide defines how each and every segment and position is used.  This varies across industries and even within industries. 
The spreadsheets provide generic mapping between an xCBL 3.0 document and the corresponding ANSI X12 4010 document set.  No EDI segments or XML elements within the source transaction set are deleted.  Although these are generic mapping guides not all of the segments available in the ANSI X12 4010 document set are supported in xCBL 3.0.  The purpose of the mapping spreadsheets is to provide a basis for specific maps to be develop between trading partners or within specific trading communities.
Mappings between xCBL 3.0 and ANSI X12 are available for the following message type:

ANSI X12  4010 Transaction Set	xCBL 3.0 Document	
850  Purchase Order	Order	
855 Purchase Order Acknowledgement	OrderResponse	
860 Purchase Order Change Request	ChangeOrder	
865 Purchase Order Change Acknowledgement/ Request	OrderResponse	
810 Invoice	Invoice	
856 Ship Notice/Manifest	AdvanceShipmentNotice	
3	Status of this Document
Every attempt has been made to map ANSI X12 transaction set elements to the corresponding xCBL 3.0 document elements and visa-versa.  The mappings are based on known use cases. Given the breadth of the ANSI X12 transaction sets and the xCBL 3.0 documents not all elements have been identified with a corresponding map and it is possible that identified mappings may not be completely correct.  As anomalies or inconsistencies are found, this document may be updated on a periodic basis.
Commerce One expressly disclaims any and all warranties regarding this document and associated mappings. This documents and associated mappings are provided "as is" without any express or implied warranty.
4	Acknowledgements
The mappings were created with assistance from Sterling Commerce and GE Xchange Service.
5	Audience
The documents for the standard mappings of the xCBL 3.0 to ANSI X12 4010 are intended for use by developers and integrators of e-Commerce systems.  
6	Pre-Requisites
This guide assumes that developers and integrators of e-Commerce systems:
•	have a working knowledge of the Extensible Markup Language (XML), the XML Developer’s Kit Professional package (XDK Pro), and the Schema for Object-Oriented XML (SOX).
•	have a working knowledge of the ANSI X12.
7	References
XML Common Business Library (xCBL) can be found at: http://www.xcbl.org
Information regarding ANSI X12-4010 transaction sets can be found at http://www.disa.org. Please note publications are available at a cost .The xCBL schemata’s are written in SOX format.  More information about SOX can be found at: http://www.xcbl.org/xcbl30/xcbl30soxschemas.html.  Familiarity with SOX is optional.  The current version of SOX is described in the SOX 2.0 specification.  The specification documents can be found at: http://www.w3c.org/TR/REC-xml or http://www.w3c.org/TR/NOTE-SOX 
The current version of XML is described in the XML 1.0 specification; XML information is available on many different websites.  The guide authority is the w3c, this is the standards body that designates what specification is to be used globally across the web.  Their website for the 1.0 specification is: http://www.w3c.org;.
8	Use of Mapping Spread Sheets 
The following table identifies the Excel spreadsheet files with the associated mappings. There are two formats used to define the mapping.  The first, referred to as “Regular”, uses a notation to define the xCBL 3.0 hierarchical element path that is for human viewing.  The second file name uses XPath notation to define the xCBL 3.0 path.

Mapping Set	File Name	
xCBL 3.0 	ANSI X12	Regular Notation	XPath Notation	
xCBL 3.0 Order 	850	Order_Standard_EDI_Map.xls	XPATH_ Order_Standard_EDI_Map.xls	
xCBL 3.0 Order Response	855	OrderResponse_855_Standard_EDI_Map.xls	XPATH_OrderResponse_855_Standard_EDI_Map.xls	
xCBL 3.0  Change Order	860	ChangeOrder_Standard_EDI_Map.xls	XPATH_ChangeOrder_Standard_EDI_Map.xls	
xCBL 3.0 Order Response	865	OrderResponse_865_Standard_EDI_Map.xls	XPATH_OrderResponse_865_Standard_EDI_Map.xls	
xCBL 3.0 Invoice	810	Invoice_Standard_EDI_Map.xls	XPATH_Invoice_Standard_EDI_Map.xls	
xCBL 3.0 AdvanceShipment Notice	856	ASN_Standard_EDI_Map.xls	XPATH_ASN_Standard_EDI_Map.xls	

Each file contains a forward and reverse mapping defined in two worksheets. The forward mapping is the translation of a specified xCBL 3.0 document to the corresponding ANSI X12 4010 Transaction Set, the reverse mapping is the translation of ANSI X12 4010 Transaction Set to the corresponding xCBL 3.0 document.
8.1	Column Definitions
The following columns exist in each worksheet:
•	Source Data 
•	Data Type
•	Occurs
•	Target Path
•	Data Type
•	Occurs
8.1.1	Source Data
The source data column defines the full path for elements.  Hierarchical levels represent the path.  For xCBL 3.0, the path is given in “Regular” notation and XPath notation based on the file selected. The elements are listed in the order of use.
Full Path — Regular Notation 
The forward mapping worksheet contains xCBL 3.0 elements as the source, listed in order of use.  The hierarchical levels are shown using the colon “:” between elements. 
 For example: Order:OrderHeader:OrderNumber:BuyerOrderNumber: 
This shows that the BuyerOrderNumber is contained within the OrderNumber, which is contained within the OrderHeader, which is contained within the Order. Order is the xCBL 3.0 document name.
If the path ends in (C): this denotes that the data type is a code list.  If the path ends in an @ it is an attribute.
If the column contains the value [CONT] this indicates that the source data results in mapping to more than one target element. This is often occurs when the target requires a qualifier code.
Full Path—XPath notation
For XPath notation, a “/” is used to separate the hierarchical levels in xCBL 3.0 and an additional levels are added based on how the SOX schema is used.  In cases where an element is defined with a type that is another element (e.g. <element type ="Party" name="BuyerParty"/>) an additional “/” is included along with the element type name.
For example, the following in “Regular” notation:
Order:OrderHeader:OrderParty:BuyerParty:NameAddress:POBox:POBoxPostalCode(@):
becomes
Order/OrderHeader/OrderParty/BuyerParty/Party/NameAddress/POBox/@POBoxPostalCode
in XPath notation. In this case POBoxPostalCode is an attribute of POBox as indicated by the “@”.
For the XPath notation, if the element is a code list, the “Data Type” column will indicate such.
Full Path – ANSI X12
The path notation for an ANSI X12 element is as follows:
Set:H_D_S:Loop_ID:Pos:Seg:ElePosition:DataEle  (there are probably standard names for these fields)
where:
Set = the ANSI X12 Transaction Set
H_D_S  = Section indicator (H, D or S depending if the segment is for the Header, Detail or Summary Section).
Loop_ID = the identification of the loop the segment is contained in, if any.
Pos = the position number of the segment within the appropriate Section.
Seg = the segment name
ElePosition = the position of the element within the segment
DataEle= the data element within the segment
Example:
850:H::020:BEG:03:324
This shows the data element 324 is the third element within the BEG segment, which is at position 020 in the header (H) section of the 850 Order message.  In this example, the element is not contained within a loop as indicated by the double colons (“::”).
If the path ends in (C): this denotes that the data type is a code list.
8.1.2	Data Type
This column designates the data type. For xCBL 3.0, intrinsic data types are in lower case, other data types are shown in camel case. For ANSI X12, the first part denotes the type of content (AN = alphanumeric) the second denotes the field size (1,22 = minimum and maximum field length). 
8.1.3	Occurs 
This column, designates the optionally and the repetition
1..1  = mandatory only one occurrence
0..1 = optional only one occurrence
1..n = mandatory one or many
0..n = optional or many
8.1.4	Target Path
The columns in the Target Path are the same as for the Source Path and have the same definitions.  Additionally, the Target Path may contain and [NA] or a [NOT USED].
If the path is shown as [NA] then this denotes that this is a container element and does not directly contain data but contains other elements. Therefore there is no direct mapping.
If the path is shown as [NOT USED] then this element does contain data but there is no direct mapping available in the target.
8.1.5	Data Type-Target path
As defined above 
8.1.6	Occurs-Target path
As defined above
8.1.7	Mapping Comments
This column contains specific mapping instructions relating to the source and target. 
•	Default values are denoted by the word Value followed by the constant value contained within apostrophes.
•	Xref is an instruction to action a cross reference between the xCBL 3.0 and ANSI X12 specified code lists. The xCBL 3.0 lists are a combination of ANSI X12, UN/EDIFACT and published ISO codelists.
A separate table is available for the cross-referencing of the codes To download or view visit www.xcbl.org and select the Standard Mapping Guide page.
•	Map if - map only if the specified condition is true. 

8.2	Example Forward Mapping

Source Data -  xCBL 3.0 Order 
	Target Path - 850:X12-4010		
Full Path	Data Type	 Occurs	Full Path	Data Type	Occurs	Mapping Comments	
Example: Order:OrderHeader:OrderNumber:BuyerOrderNumber:	string	1..1	850:H::020:BEG:03:324:	AN,1,22	1..1	Map	

8.3	Example Reverse Mapping

Source Data - 850:X12-4010	Target Path - xCBL 3.0 Order
		
Full Path	Data Type	Occurs	Full Path	Data Type	Occurs	Mapping Comments	
850:H::020:BEG:03:324:	AN,1,22	1..1	Order:OrderHeader:OrderNumber:BuyerOrderNumber:	string	1..1	Map 	

8.4	Field Lengths
There was much discussion the design of xCBL 3.0 about the restriction of field lengths to support interoperability. The following ideas were suggested:
•	Adopt a common standard - UN/EDIFACT, ANSI X12, or similar - as a guide in limiting the lengths of fields. 
•	Use a series of breakpoints that coincide with the retrieval and storage capabilities of common relational systems. This would result in very generous, but still limited, field lengths. 
•	Have no limits. Just as XML does not limit lengths the way positional syntax does, schemas should not limit field lengths (except in the most obvious cases, such as numeric types like prices). 
It was decided not to limit field lengths. This decision is based on the idea that trading communities would identify their own needs in terms of interoperability, legacy system requirements, application support, etc. Creators and maintainers of applications and portals must decide on a policy in this area and then document it for the members of their community. Both UN/EDIFACT and ANSI X12 provide useful guidelines, based on legacy requirements.
Additionally, some emerging standards (ebXML and IFX, to name but two) will probably be making their own recommendations in these areas. These recommendations will be of great importance in the design of future versions of xCBL 3.0 but were not final at the time of this release.

8.5	Envelope Mapping Between xCBL 3.0 and ANSI X12
In xCBL 3.0 documents there is no enveloping information as exist in ANSI X12.  However to support the mapping of an ANSI X12 document to xCBL 3.0 and then back to ANSI X12, the ISA, GS, an ST segments should be mapped in their entirety to the ListOfStructuredNote:StructuredNote:GeneralNote element in the header of the xCBL 3.0 document, where ListOfStructuredNote:StructuredNote:NoteID = “ISA”, “GS”, or “ST”, respectively. 

8.6	Defaults
Whenever it was possible, the mappings provided default values for any mandatory tags in xCBL 3.0 that may not be available in ANSI X12.  However, it is very difficult to provided defaults for every possible scenario.  As such, it will be necessary for the user of these maps to analyze the xCBL 3.0 elements being used, in order to determine what fields should be defaulted.
For instance, if the Identifier element is being used to simply hold a stand-alone id, then Agency:AgencyCoded must be defaulted, since it is not available.   Whenever possible, it is best to make a logical default, however, if one is not available, the following general guidelines are suggested for defaulting certain types:
•	String datatypes – empty tags, for example <Name1/>
•	Enumerated datatypes (codes) – “Other” with CodedOther field “N/A”, for example 
<PurposeCoded>Other</PurposeCoded>
<PurposeCodedOther>N/A</PurposeCodedOther>
•	Number datatypes (int, DecimalX_Y) – 0
•	Boolean datatypes – true

8.7	Required Elements – Quick Reference Guide
A quick reference guide to all required elements is provided to assist the developers and integrators. The guide will list all of the xCBL 3.0 elements in column A of the spreadsheet, column B will contain only those elements that are required when the element in column A is used. Hyperlinks have been added to the elements in column B to enable the user to drill down to the last required field.
To download the Required Elements – Quick Reference Guide, visit www.xcbl.org and select the Standard Mapping Guide page.

8.8	Complex Mapping Guide
There are certain areas in the standard mapping documents that require further descriptions outside of the mapping spreadsheets. This has been accomplished by providing a separate spreadsheet that just concentrates on these specific areas.
To download the Complex Mapping Guide, visit www.xcbl.org and select the Standard Mapping Guide page.

8.9	Specific Mapping Information
8.9.1	xCBL 3.0 Order and ANSI X12 4010 – Set ID :850
This mapping is for the original order from a buyer to a supplier.
8.9.2	xCBL 3.0 OrderResponse and ANSI X12 4010 – Set ID :855
The OrderResponse is used as the acknowledgement of an order from a supplier to the buyer.
If the entire order is to be accepted or rejected then only the mandatory elements in the header need to be sent. 
When header and detail information is to be returned then all the data is mapped to OrderHeaderChanges element and OrderResponse:OrderResponseDetail:ListOfOrderResponseItemDetail:OrderResponseItemDetail:ItemDetailChanges: respectively regardless of whether the data has changed or not. 
The summary information will be mapped to OrderResponseSummary:RevisedOrderSummary: element. 

8.9.3	xCBL 3.0 ChangeOrder and ANSI X12 4010 – Set ID :860
The ChangeOrder can be used by the buyer to request a change to a previously submitted Purchase Order.  Suppliers can accept or reject the changed order using the order response document.
If only the information relating to the header section is to be changed, then only the header section needs to be sent in the message. Depending on the mutual agreement between the trading partners (buyer and supplier) only the information that has changed can be sent, or all information can be sent. The message allows for both scenarios.
If only the detail section of the message has changes, the header section needs to be sent but with a minimum amount of data in it. Depending on the mutual agreement between the trading partners (buyer and supplier) only the information that has changed can be sent, or all information can be sent. The message allows for both scenarios.
When header and detail information is to be returned then all the data is mapped to ChangeOrderHeader:OrderHeaderChanges element and ChangeOrderDetail:ListOfChangeOrderItemDetail:ChangeOrderItemDetail:ItemDetailChanges: respectively regardless of whether the data has changed or not. 
The summary information will be mapped to ChangeOrderSummary:RevisedOrderSummary: element. 

8.9.4	xCBL 3.0 OrderResponse and ANSI X12 4010 – Set ID :865
The OrderResponse is used to convey acceptance or rejection of changes to a previously submitted purchase order (ChangeOrder).
If the entire changed order is to be accepted or rejected then only the mandatory elements in the header need to be sent. 
When header and detail information is to be returned then all the data is mapped to OrderHeaderChanges element and OrderResponse:OrderResponseDetail: ListOfOrderResponseItemDetail:OrderResponseItemDetail:ItemDetailChanges: respectively regardless of whether the data has changed or not. 
The summary information will be mapped to OrderResponseSummary:RevisedOrderSummary: element. 

8.9.5	xCBL 3.0 Invoice and ANSI X12 4010 – Set ID :810
The Invoice can be used to provide for customary and established business /industry practice relative to the billing for goods and services provided.
The invoice may refer to goods or services from more than one order. These orders are always between the same buyer and seller.

8.9.6	xCBL 3.0 AdvanceShipmentNotice and ANSI X12 4010 – Set ID :856
The AdvanceShipmentNotice can be used to provide for customary and established business /industry practice relative to the billing for goods and services provided.
The sender of this transaction is the organization responsible for detailing and communicating the contents of a shipment, or shipments, to one or more receivers of the transaction set, generally the supplier. The receiver of this transaction set can be any organization having an interest in the contents of a shipment or information about the contents of a shipment (generally the buyer).
This mapping set can be used for single or multiple orders. The advance shipment notice can be used for planning or serve as a notice of shipment in progress.
This mapping is to a specific implementation of the Voluntary Inter-Industry Commerce Standard for the ASN Pick and Pack scenario.
The VICS implementation does not use the hazardous elements contained within the 856 transaction set. A separate document is available at www.xcbl.org on the Standard Mapping Guide page for this specific mapping.

8.10	Contacts
The site where problems or questions should be sent can be found at:
http://groups.yahoo.com/group/xcbl-discuss/