- Overview of GS1 EDI Message Architecture
- Benefits
- Overview of GS1 EDI message components
- Batching of business documents
In GS1 MR3 the message architecture for the two main domains: GS1 EDI and GDSN (the architecture currently used by the GDSN is described in the GS1 XML Message Architecture Implementation Guide for release 2.7 and GDSN Operations Manual Release 3.1 for major Release) has been decoupled following requirements of the user community.
Overview of GS1 EDI Message Architecture
The main principle of the GS1 EDI message architecture is separation of two functional components:
- Transport and routing component, containing information about routing and processing of the XML instance document
- Business document component, containing the actual business document or documents, e.g. Order or Invoice. Each message can contain up to 10,000 documents of one type (e.g. ONLY Orders or Invoices).
Both components combined constitute a GS1 XML message, e.g. Order Message or Invoice Message.
The structure of the GS1 EDI message architecture
Benefits
The separation of transport and routing information from the business document allows delivering the message to the right addressee and the correct business application without accessing the content of the business document. The later may be either impractical or impossible, if the document content is encrypted for security reasons.
Allowing for only one document type in the message ensures the correct routing within the company. For example, all the business documents are passed to the financial or ordering systems.
The structure of the Order Message
Overview of GS1 EDI message components
Transport and routing component
GS1 System uses the Standard Business Document Header (SBDH) for routing and processing information in the GS1 XML standard.
The specifications for SBDH have been developed by the UN/CEFACT, the document is available at the GS1 website: https://www.gs1.org/standard-business-document-header-sbdh
The SBDH has been designed to be independent of the specific transport protocol used. Information contained in the SBDH can be used by communication applications to determine routing, whether the transport protocol used is ebMS, AS2, or any other protocol.
Using one common document header enables integration of documents between internal applications, enterprise applications, and business-to-business infrastructure by providing a consistent interface between applications. It allows any application to determine the logical routing requirements and/or the logical processing requirements of a document based on the information contained in the SBDH.
SBDH contains information for communication applications about:
- Document Routing – identifies message sender and receiver; used by message exchange hubs, marketplaces, etc.
- Document Identification – used by the middleware to identify and route the message to the appropriate business application without opening or parsing it
- Document Processing Context – provides parameters for processing the business document in the context of a business choreography exchange and identifies specific guidelines document that has been used as a base for creating the instance document
- Payload – a container for the business document
Detailed guidelines how to implement the SBDH with the GS1 XML standard have been documented separately in the ‘Standard Business Document Header (SBDH) Version 1.3 Technical Implementation Guide”, available at the GS1 website: SBDH v1.3 Technical Implementation Guide
Business document component
The Document contains the business information components, specific for the type of document, i.e. Order, Despatch Advice or Invoice. These documents are fully documented in GS1 Business Message Standards and will not be discussed in this guide. All the documents, however, need to contain certain common information such as document identification, document date, etc.
All the business document types are based on the common ‘DocumentType’ and inherit all the necessary components. This ‘DocumentType’ is defined as abstract, which means that this structure cannot be used in the instance file directly, but it must be extended by a concrete type, such as ‘OrderType’, ‘InvoiceType’, etc.
The abstract ‘DocumentType’ has the following content:
Document component tags
XSD Element / Attribute |
XSD Type |
Occ |
Usage Guidelines |
|---|---|---|---|
| ecom_common:EcomDocumentType | This is a type extending the abstract ‘DocumentType’. All GS1 EDI business documents are based on types extending this type (e.g. DespachAdviceType, OrderType, etc.) | ||
| shared_common:DocumentType | This is an abstract type that cannot be directly instantiated, but must be extended by the concrete type. In case of GS1 EDI documents, it is extended by the ‘EcomDocumentType’. | ||
| creationDateTime | xsd:dateTime | 1..1 | An element used to specify the date and time when the document was created. |
| documentStatusCode | shared_common:DocumentStatusEnumerationType | 1..1 | This element contains an enumeration list of the three possible status values of the document. |
| documentActionCode | shared_common:DocumentActionEnumerationType | 0..1 | This element contains an enumeration list of the three possible action values that can be performed on the business document. |
| documentStructureVersion | xsd:string | 0..1 | Reflects the complete (major and minor) version of the business message schema. E.g. for the Order.xml message, the document structure version reflects the version number of the Order.xsd schema. |
| lastUpdateDateTime | xsd:dateTime | 0..1 | Specifies the date when the document was last updated. |
| revisionNumber | xsd:positiveInteger | 0..1 | Number to be used for identification and referencing of subsequent updates to a business document. |
| extension | shared_common:ExtensionType | 0..1 | See: XML extension element |
| documentEffectiveDate | shared_common:DateOptionalTimeType | 0..1 | Date and time when the document was last updated. |
| avpList | ecom_common:Ecom_AttributeValuePairListType | 0..1 | See: Attribute Value pairs - AVP |
Document component instance example
(TIP: roll your mouse over the code below to see comments)
Batching of business documents
The GS1 message architecture enables batching of business documents – transmitting them as a part of one message – up to 10,000 documents per one message. All documents have to be of the same type, e.g. only Orders or only Invoices. Mixing various types of documents is not allowed and not technically possible with the current design.
Below is an example of an XML instance containing one SBDH and three Business Documents – in this case the Orders:
<order:orderMessage>
<sh:StandardBusinessDocumentHeader>
<!-- STANDARD BUSINESS DOCUMENT HEADER CONTENT-->
</sh:StandardBusinessDocumentHeader>
<order>
<!—FIRST ORDER DOCUMENT CONTENT-->
</order>
<order>
<!—SECOND ORDER DOCUMENT CONTENT-->
</order>
<order>
<!—THIRD ORDER DOCUMENT CONTENT-->
</order>
</order:orderMessage>