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


Download 80.03 Kb.
NameThe emergence of e-Marketplaces has enabled e-business procedures to be available to large numbers of smes (small to medium sized enterprises) who have
A typeDocumentation

Standard Mapping Guide

Between

xCBL 3.5 and ANSI X12 4010





November 2, 2001

Version 1.0

Table of Contents

1Introduction 3
  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.5 (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.5 and the corresponding EDI document respectively, and the second shows the reverse mapping i.e. EDI to xCBL 3.5. These are sister documents to the xCBL 3.0 mapping spreadsheets.

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.

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.5 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 produce 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.5 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.5. 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. Elements that have been added to the xCBL 3.5 messages compared to the xCBL 3.0 are marked in blue for easier identification.

Mappings between xCBL 3.5 and ANSI X12 are available for the following message type:


ANSI X12 4010 Transaction Set

xCBL 3.5 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

Status of this Document

Every attempt has been made to map ANSI X12 transaction set elements to the corresponding xCBL 3.5 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.5 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.

Acknowledgements

The mappings were based on the original xCBL 3.0 mappings. Our thanks go to Jean McInerney for the construction of a macro that greatly simplified this procedure and to all in the Commerce One Derby team that did the final mappings.

Audience

The documents for the standard mappings of the xCBL 3.5 to ANSI X12 4010 are intended for use by developers and integrators of e-Commerce systems.

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.

  • 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/xcbl35/sox/schemas.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;.

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.5 hierarchical element path that is for human viewing. The second file name uses XPath notation to define the xCBL 3.5 path.


Mapping Set

File Name

xCBL 3.5

ANSI X12

Regular Notation

XPath Notation

xCBL 3.5 Order

850

Order_Standard_EDI_Map.xls

XPATH_ Order_Standard_EDI_Map.xls

xCBL 3.5 Order Response

855

OrderResponse_855_Standard_EDI_Map.xls

XPATH_OrderResponse_855_Standard_EDI_Map.xls

xCBL 3.5 Change Order

860

ChangeOrder_Standard_EDI_Map.xls

XPATH_ChangeOrder_Standard_EDI_Map.xls

xCBL 3.5 Order Response

865

OrderResponse_865_Standard_EDI_Map.xls

XPATH_OrderResponse_865_Standard_EDI_Map.xls

xCBL 3.5 Invoice

810

Invoice_Standard_EDI_Map.xls

XPATH_Invoice_Standard_EDI_Map.xls

xCBL 3.5 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.5 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.5 document.

Column Definitions

The following columns exist in each worksheet:

  • Source Data

  • Data Type

  • Occurs

  • Target Path

  • Data Type

  • Occurs

  • Source Data

The source data column defines the full path for elements. Hierarchical levels represent the path. For xCBL 3.5, 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.5 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.5 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.5 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. ) 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.

Data Type

This column designates the data type. For xCBL 3.5, 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).

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

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.

Data Type-Target path

As defined above

Occurs-Target path

As defined above

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.5 and ANSI X12 specified code lists. The xCBL 3.5 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.


Example Forward Mapping


Source Data - xCBL 3.5 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


Example Reverse Mapping


Source Data - 850:X12-4010

Target Path - xCBL 3.5 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


Field Lengths

There was much discussion during the design of xCBL 3.5 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.5 but were not final at the time of this release.
Envelope Mapping Between xCBL 3.5 and ANSI X12

In xCBL 3.5 documents there is no enveloping information as exist in ANSI X12. However to support the mapping of an ANSI X12 document to xCBL 3.5 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.5 document, where ListOfStructuredNote:StructuredNote:NoteID = “ISA”, “GS”, or “ST”, respectively.
Defaults

Whenever it was possible, the mappings provide default values for any mandatory tags in xCBL 3.5 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.5 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

  • Enumerated datatypes (codes) – “Other” with CodedOther field “N/A”, for example


Other

N/A


  • Number datatypes (int, DecimalX_Y) – 0

  • Boolean datatypes – true


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.5 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.
Specific Mapping Information
    1. xCBL 3.5 Order and ANSI X12 4010 – Set ID :850


This mapping is for the original order from a buyer to a supplier.

xCBL 3.5 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.
xCBL 3.5 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.
xCBL 3.5 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.
xCBL 3.5 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.
xCBL 3.5 AdvanceShipmentNotice and ANSI X12 4010 – Set ID :856

The AdvanceShipNotice 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.

Complex Mapping Guide

Some segments and loops in X12 require complex mappings to xCBL. Furthermore, some elements in xCBL are created from multiple X12 elements. In these cases, the mappings are addressed in the Complex Mapping Guide. This guide is intended to provide mapping for both X12 to xCBL and xCBL to X12 for the X12 segments and loops that required complex mappings. The xCBL to X12 portion assumes the xCBL was generated from an X12 document.

These mapping have been made generic, in order to accommodate any documents they may appear in. Because of this, the full path may not be given. If the full path could not be designated, a relative path, such as header or item detail, is provided in brackets ([]).

Codelist Guide

For each codelist that is used in the mapping documents a cross reference is available between the xCBL and X12 codes.

If an X12 code has no corresponding code in xCBL use the code ‘Other’ in the Coded element and the X12 code in the CodedOther element.
Contacts

The site where problems or questions should be sent can be found at:

http://groups.yahoo.com/group/xcbl-discuss/

Share in:

Related:

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 iconAbstract The size of the databases used in today’s enterprises has...

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 iconMicro & small Enterprises which are in continuous production of stores...

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 icon17 years’ experience managing engineering teams large and small (up...

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 iconMinority Business Enterprises Are Encouraged to Respond to this Solicitation

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 iconMinority Business Enterprises Are Encouraged to Respond to this Solicitation

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 iconProfile I am a highly skilled mobile software engineer & consultant...

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 iconSchedule a government Business Enterprises Condensed Supplementary Financial Information 49

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 iconAbstract This thesis explores the governance of transnational partnerships...

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 iconBusiness Formations: Small & Emerging Businesses

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 icon1. The growth of small business in Canada has consistently




forms and shapes


When copying material provide a link © 2017
contacts
filling-form.info
search