UIM Implementation Guide Technical Document

gs1ca.org

UIM Implementation Guide Technical Document

Global Upstream Supply InitiativeUIM Implementation Guide Technical DocumentTABLE OF CONTENTS1. Introduction ........................................................................................................................ 51.1. Purpose ........................................................................................................................................ 51.2. Recommended reading ................................................................................................................. 51.3. Overview....................................................................................................................................... 52. How to apply the GS1 Keys............................................................................................... 62.1. Trade Item Identification................................................................................................................ 62.2. Party Identification......................................................................................................................... 62.3. Logistic Unit Identification.............................................................................................................. 73. How to refer to other documents? .................................................................................... 83.1. How to refer to another GS1 business message(line)? .................................................................. 83.1.1. Referencing a document ...................................................................................................... 83.1.2. Referencing a document line................................................................................................ 83.1.3. Referencing a document or document line ........................................................................... 93.2. How to refer to an external document(line) .................................................................................. 103.2.1. Referencing an external document..................................................................................... 103.2.2. Referencing an external document line .............................................................................. 104. How to use the envelope layers? ..................................................................................... 114.1. Standard Business Document layer............................................................................................. 114.2. Message layer............................................................................................................................. 114.3. Transaction layer......................................................................................................................... 114.3.1. Identification of the Transaction.......................................................................................... 114.4. Command ................................................................................................................................... 124.4.1. Document Command ......................................................................................................... 124.5. Document Layer.......................................................................................................................... 135. Date time and timezone formats ..................................................................................... 146. UN/ECE Code Lists.......................................................................................................... 156.1. MeasurementUnitCodeList .......................................................................................................... 156.2. IncotermCodeList ........................................................................................................................ 156.3. PackagingTypeCode ................................................................................................................... 157. Message Implementation Guides (MIGs) ...................................................................... 16Revision 19 May 2008, Version 2.0 - September 2007 Page 3 of 16


Global Upstream Supply InitiativeUIM Implementation Guide Technical DocumentMessage Component Guides included in this GuideDetail Level Reference ................................................................................................................... 1Document Or Document Line Reference......................................................................................... 4Envelope Layers ............................................................................................................................ 8Logistic Unit Identification .............................................................................................................19Party Identification ........................................................................................................................22Trade Item Identification ...............................................................................................................25Revision 19 May 2008, Version 2.0 - September 2007 Page 4 of 16


Global Upstream Supply InitiativeUIM Implementation Guide Technical Document1. Introduction1.1. PurposeThis is a guide to help companies implementing the Upstream Integration Model (UIM) version 2.2 andthe GS1 eCom XML v2.x.x message standards for electronic communication.The main audience are the implementers of integration projects. The aim is to share best practicesand points to consider during implementation. Therefore this guide is a living document to be updatedwith best practices gained from UIM implementations by companies involved in the Global UpstreamSupply Initiative (GUSI). To keep this guide general it covers the most common practices. However,there might be exceptions per Manufacturer and/or Material Supplier and these need to be addressedand documented separately in their specific projects.1.2. Recommended readingRecommended reading: GS1 XML Technical User Guide for release 2.1.3. OverviewThis guide consists of detailed guidelines and explanations on:GS1 Keys: Explanation on how to include the GS1 keys in the messages.Referencing documents: Explanation on how to refer from one message to another.Envelope layers: Explanation on how to apply the envelope layers of the message.Date Time formats: Explanation on the W3C date time format as used in the GS1 standards.UN/ECE Codelists: Explanation on the UN/ECE codelists for measurement units, packagetypes and Incoterms.MIG Schemas: Explanation on the use of the MIG schemas as implementation tool whenimplementing the GS1 Standard schemas.Revision 19 May 2008, Version 2.0 - September 2007 Page 5 of 16


Global Upstream Supply InitiativeUIM Implementation Guide Technical Document2. How to apply the GS1 Keys2.1. Trade Item IdentificationThe trade item identification always has the following structure:TradeItemIdentificationM 1 .. 1 xsd:sequenceM 1 .. 1 gtinO 0 .. unbounded additionalTradeItemIdentificationM 1 .. 1 xsd:sequenceM 1 .. 1 additionalTradeItemIdentificationValueM 1 .. 1 additionalTradeItemIdentificationTypeThe GTIN (Global Trade Item Number) is a mandatory element. Optionally, one or multiple additionalidentifiers may be specified.In messages where multiple trade item identifications are used, the name of theTradeItemIdentification element is replaced with a more specific name. However, the structure andnames of the underlying elements remain the same.Example:requestedItemIdentificationM 1 .. 1 xsd:sequenceM 1 .. 1 gtinO 0 .. unbounded additionalTradeItemIdentificationM 1 .. 1 xsd:sequenceM 1 .. 1 additionalTradeItemIdentificationValueM 1 .. 1 additionalTradeItemIdentificationTypePoints to considerFor systems / parties that do not (yet) support GTINs any alternate keys can be provided inthe AdditionalTradeItemIdentification element.In situations where no GTIN is yet available a value of ‘00000000000000’ must be used. Thisshould be treated as a temporary solution since it is in violation of the GS1 Standards.2.2. Party IdentificationThe party identification always has the following structure:PartyIdentificationM 1 .. 1 xsd:sequenceM 1 .. 1 glnO 0 .. unbounded additionalPartyIdentificationM 1 .. 1 xsd:sequenceM 1 .. 1 additionalPartyIdentificationValueM 1 .. 1 additionalPartyIdentificationTypeRevision 19 May 2008, Version 2.0 - September 2007 Page 6 of 16


Global Upstream Supply InitiativeUIM Implementation Guide Technical DocumentThe GLN (Global Location Number) is a mandatory element. Optionally multiple additional identifiersmay be specified.In most messages multiple party identifications are used. Therefore the name of thePartyItemIdentification element is usually replaced with a more specific name. However, the structureand names of the underlying elements remain the same.Example:shipFromM 1 .. 1 xsd:sequenceM 1 .. 1 glnO 0 .. unbounded additionalPartyIdentificationM 1 .. 1 xsd:sequenceM 1 .. 1 additionalPartyIdentificationValueM 1 .. 1 additionalPartyIdentificationTypePoints to considerFor systems / parties that do not (yet) support GLNs any alternate keys can be provided in theadditionalPartyIdentification element.In situations where no GLN is yet available a value of ‘0000000000000’ must be used. Thisshould be treated as a temporary solution since it is in violation with the GS1 Standards. Atleast one additional ID must be identified in this exceptional case: Valid for GTIN / GLN2.3. Logistic Unit IdentificationThe logistic unit identification always has the following structure:logisticUnitIdentificationM 1 .. 1 xsd:sequenceM 1 .. 1 serialShipmentContainerCodeM 1 .. 1 xsd:sequenceM 1 .. 1 serialShippingContainerCodeO 0 .. unbounded additionalLogisticUnitIdentificationM 1 .. 1 xsd:sequenceM 1 .. 1 logisticUnitIdentificationThe serialShippingContainerCode (SSCC) is a mandatory element. Optionally multiple additionalidentifiers may be specified.Points to considerFor systems / parties that do not (yet) support SSCCs any alternate keys can be provided inthe additionalLogisticUnitIdentification element.Revision 19 May 2008, Version 2.0 - September 2007 Page 7 of 16


Global Upstream Supply InitiativeUIM Implementation Guide Technical Document3. How to refer to other documents?3.1. How to refer to another GS1 business message(line)?There are three options when referring to another GS1 business message:1. To refer to the document2. To refer to the document line.3. To refer to the either the document or the document line3.1.1. Referencing a documentFor referencing a document we use the following structure:purchaseOrderOcreationDateTimeM 1 .. 1 xsd:sequenceM 1 .. 1 uniqueCreatorIdentificationM 1 .. 1 contentOwnerM 1 .. 1 xsd:sequenceM 1 .. 1 GlnO 0 .. unbounded additionalPartyIdentificationM 1 .. 1 xsd:sequenceM 1 .. 1 additionalPartyIdentificationValueM 1 .. 1 additionalPartyIdentificationTypeIn the example above the reference is to a Purchase Order message. Besides having to specify thedocument ID (uniqueCreatorIdentification) it is also required to specify the party (content owner)responsible for assigning the ID. This ensures an unambiguous link to the message that is beingreferred to.Points to considerUsually the content owner of the referred document is one of the parties in the message, e.g.the buyer or the seller.3.1.2. Referencing a document lineFor referencing a line in the document we use the following structure:Revision 19 May 2008, Version 2.0 - September 2007 Page 8 of 16


Global Upstream Supply InitiativeUIM Implementation Guide Technical DocumentdespatchAdviceLineM required NumberM 1 .. 1 xsd:sequenceO 0 .. 1 documentReferenceOcreationDateTimeM 1 .. 1 xsd:sequenceM 1 .. 1 uniqueCreatorIdentificationM 1 .. 1 contentOwnerM 1 .. 1 xsd:sequenceM 1 .. 1 GlnO 0 .. unbounded additionalPartyIdentificationM 1 .. 1 xsd:sequenceM 1 .. 1 additionalPartyIdentificationValueM 1 .. 1 additionalPartyIdentificationTypeIn the example above the reference is to a Line Item in a Despatch Advice message. This structure isidentical to the previous one, with one addition: the Line Item Number can now be specified as well, byusing the Number element.3.1.3. Referencing a document or document lineIn some cases it is allowed to refer to either the document or the document-line. In that situation weuse the following structure:purchaseOrderM 1 .. 1 xsd:choiceM 1 .. 1 documentReferenceOcreationDateTimeM 1 .. 1 xsd:sequenceM 1 .. 1 uniqueCreatorIdentificationM 1 .. 1 contentOwnerM 1 .. 1 xsd:sequenceM 1 .. 1 glnO 0 .. unbounded additionalPartyIdentificationM 1 .. 1 xsd:sequenceM 1 .. 1 additionalPartyIdentificationValueM 1 .. 1 additionalPartyIdentificationTypeM 1 .. 1 documentLineReferenceM required numberM 1 .. 1 xsd:sequenceO 0 .. 1 documentReferenceOcreationDateTimeM 1 .. 1 xsd:sequenceM 1 .. 1 uniqueCreatorIdentificationM 1 .. 1 contentOwnerM 1 .. 1 xsd:sequenceM 1 .. 1 glnO 0 .. unbounded additionalPartyIdentificationM 1 .. 1 xsd:sequenceM 1 .. 1 additionalPartyIdentificationValueM 1 .. 1 additionalPartyIdentificationTypeIn the example above the reference is to a Purchase Order message or to a line in that message. Thisstructure consists of a choice between structures 1 and 2.Revision 19 May 2008, Version 2.0 - September 2007 Page 9 of 16


Global Upstream Supply InitiativeUIM Implementation Guide Technical DocumentNote: A message component guide is available only for the structure described in paragraph3.1.3 (this guideline encapsulates the other two structures).3.2. How to refer to an external document(line)There are two options when referring to external documents:1. To refer to the document2. To refer to the document line.3.2.1. Referencing an external documentdeliveryNoteM 1 .. 1 xsd:sequenceM 1 .. 1 referenceDateTimeM 1 .. 1 referenceIdentificationIn the example above the reference is to a delivery note.3.2.2. Referencing an external document lineproductCertificationM required NumberM 1 .. 1 xsd:sequenceM 1 .. 1 ReferenceM 1 .. 1 xsd:sequenceM 1 .. 1 referenceDateTimeM 1 .. 1 referenceIdentificationIn the example above the reference is to a specific line in an external Product Certification document.Note: A message component guide is available only for the structure described in paragraph3.2.2 (this guideline encapsulates the other structure)Revision 19 May 2008, Version 2.0 - September 2007 Page 10 of 16


Global Upstream Supply InitiativeUIM Implementation Guide Technical Document4. How to use the envelope layers?Note: A detailed message component guide is available describing the information structure ofthe layers: MIG Envelope Layers.4.1. Standard Business Document layerThe Standard Business Document Header (SBDH) is the UN/CEFACT standard, containinginformation about the routing and processing of the business document. In the EAN.UCC XML 2architecture, the SBDH replaces the Envelope layer used in previous releases of XML standards.The SBDH layer is mandatory and provides essential address information, assuring that a messagewill be delivered from a sender to a receiver. In addition, it identifies the message set that is senttogether with one SBDH as well as the version number of the document or documents contained.Furthermore, the SBDH provides a Business Scope where the business domain within which thetransaction is executing is identified. The Business Scope, describing the complete businessenvironment in which the SBDH and SBD will be processed, provides a basis for determining whichrules are applicable to the transaction.4.2. Message layerThe message layer defines actions that should be performed on the specific document or documentsby the receiving application. Those tasks are defined as commands.Use of this layer allows a reduction in the number of messages needed to perform an efficientexchange of business messages. The same message can be used with different commands. Henceno separate messages like ‘Add Item’, ‘Change Item’, ‘Correct Item’ or ‘Delete Item’ are needed. Thesame ‘Item’ message can be sent with the relevant command, e.g. ‘add’, ‘change’, ‘correct’ or ‘delete’.Besides identification of the message (uniqueCreatorIdentification), the Message layer contains twomain components: transaction and command. Each message sent can contain several transactionsand every transaction can hold multiple commands concerning one or more documents. Commandsare used by a trading partner to instruct the receiving application about an action that should beperformed on a given document.This kind of layered architecture allows greater flexibility of business information exchange.4.3. Transaction layerA transaction provides functionality for submitting multiple commands simultaneously. It allows theusers to process the group of messages together. If one of them fails, a rollback of the succeededmessages will be forced.The Transaction schema contains two main components: identification of the parties that created theset of commands and the one that is the owner of the message content. The second component arethe commands themselves.4.3.1. Identification of the TransactionThe Transaction is identified by the combination of two identifier elements. The first one is the‘uniqueCreatorIdentification’. It is an identifier assigned by the party creating the transaction. Thesecond identifier, the ‘contentOwner’, is the one specifying the assigning party itself.Revision 19 May 2008, Version 2.0 - September 2007 Page 11 of 16


Global Upstream Supply InitiativeUIM Implementation Guide Technical DocumentBoth those identifiers are mandatory, in order to make the Transaction identification really unique.Unlike the previous release of EAN.UCC XML, the Content Owner can only be identified by a GLN andan optional additional identifier. The use of an alternate identifier to identify the Content Owner is nolonger allowed (see the Transaction semantics for more detail).4.4. CommandThe ‘command’ element is a container, where one or multiple commands that form one transactioncan be inserted.Commands are used by a trading partner to instruct the receiving application about an action thatshould be performed on a given document. All commands are transitive and are discarded afterexecuting the task.Some of the actions to be performed are defined by the command itself, while other ones are definedby an attribute of the command.The ‘command’ is an abstract element, extended by the following elements: ‘documentCommand’,‘documentIdentificationCommand’ and ‘linkCommand’, defined in DocumentCommand.xsd,DocumentIdentificationCommand.xsd and LinkCommand.xsd, respectively. As the manufacturercurrently only uses the DocumentCommand, this will be the only extension described below.4.4.1. Document CommandThe Document Command is used to instruct the recipient of that command to perform a particularaction related to the documents within the command. The document in question has to be present.The actions which can be performed on it include ‘Add’, ‘Refresh’ and ‘Delete’.The Document Command is an extension of the abstract Command. It contains two main components:the ‘documentCommandHeader’ and ‘documentCommandOperand’.The ‘documentCommandHeader’ specifies the action that should be performed on the givendocument. Those tasks, defined as the required attribute of the header element, include:ADDCHANGE_BY_REFRESHCORRECTDELETEthe receiving application is instructed to store the document ordocumentsthe receiving application is instructed to update the existing documentor documents, by total replacementthe receiving application is instructed to update the existing documentor documents, by total replacement, skipping certain business specificvalidation rules. The syntactical and content validation rules still apply.This command is used in cases where the specific validation ruleswould otherwise prevent the application from changing data. It can beused only if the correction does not impact the integrity of thecorrected data. Otherwise, the correction should be performed bysending two commands: DELETE (with the old document) and ADD(with the new document) in one transaction.the receiving application is instructed to delete the document ordocumentsThe ‘documentCommandOperand’ contains an abstract element that can be extended by the actualdocument elements, defined in the actual business message schemas. Those are the documentsagainst which one of the actions defined in the header element should be performed like Order orDespatch Notification etc.Revision 19 May 2008, Version 2.0 - September 2007 Page 12 of 16


Global Upstream Supply InitiativeUIM Implementation Guide Technical Document4.5. Document LayerDocument layer contains the actual business documents. In these documents item and partyidentifiers are uses, eg. GLN (for party) and GTIN (for item). Identification of item is only relevant forthe document layer. The use of party identification in the SBDH layer is different than the partyidentification in the document layer (see the proper semantics for details).The body always expects a GLN or GTIN. To model other codes the GLN and/or GTIN is populatedwith zeros where the GLN or GTIN are not available. The actual location and/or item code is than putinto additionalPartyIdentification, and/or additionalTradeItemIdentification.Revision 19 May 2008, Version 2.0 - September 2007 Page 13 of 16


Global Upstream Supply InitiativeUIM Implementation Guide Technical Document5. Date time and timezone formatsThe EAN.UCC date time format is based on the W3C schema primitive for date time. This primitiveallows the inclusion on time zone information.Complete date plus hours and minutes:YYYY-MM-DDThh:mmTZD (eg 1997-07-16T19:20+01:00)Complete date plus hours, minutes and seconds:YYYY-MM-DDThh:mm:ssTZD (eg 1997-07-16T19:20:30+01:00)Complete date plus hours, minutes, seconds and a decimal fraction of a second:where:YYYY-MM-DDThh:mm:ss.sTZD (eg 1997-07-16T19:20:30.45+01:00)YYYY = four-digit yearMM= two-digit month (01=January, etc.)DD = two-digit day of month (01 through 31)hh= two digits of hour (00 through 23) (am/pm NOT allowed)mm = two digits of minute (00 through 59)ss = two digits of second (00 through 59)s= one or more digits representing a decimal fraction of a secondTZD = time zone designator (Z (gmt) or +hh:mm or -hh:mm)Revision 19 May 2008, Version 2.0 - September 2007 Page 14 of 16


Global Upstream Supply InitiativeUIM Implementation Guide Technical Document7. Message Implementation Guides (MIGs)The GS1 eCom XML standard scope covers all of the CPG industry. This includes retailers, logisticservice provides and other players in this supply chain. Because of the wider use of the message set,the standard messages contain parts that are not relevant to support the UIM.To simplify the implementation process within the GUSI community, for every GS1 XML message aUIM Message Implementation Guide (MIG) has been compiled. The MIG depicts the normativemessage implementation of GS1 BMS for use with GUSI UIM. The MIG is a subset and furtherrestriction of the GS1 BMS. The GS1 BMS schemas are still the schema standards that XMLmessages should validate towards. The MIG and associated MIG schema describe the parts that areused how they should be used.The recommendation is to follow GUSI MIG for implementation of the UIM. However, partners candifferentiate from the MIG when a justifiable business reason exists and as long as the change is stillvalid against the GS1 BMS. Any deviation from the MIG must be addressed to the GUSIImplementation Team for evaluation and assessment, changes that bring added value to the wholecommunity will be integrated in next versions of the MIG.Important: All messages must validate against the official GS1 XML message schemas.Revision 19 May 2008, Version 2.0 - September 2007 Page 16 of 16


UIM Message Implementation Guide(MIG)forComponent: Detail Level Referencebased on messageNot applicableBMS Version: 2.1Contents: Message structureDetailed guidelineIssue date: 30-9-2007Version: 2.0 - September 2007Prepared by GS1 Netherlands


Component: Detail Level ReferenceStructure ChartSt Occurrence ElementDetailLevelReferenceM required numberM 1 .. 1 xsd:sequenceM 1 .. 1 referenceM 1 .. 1 xsd:sequenceM 1 .. 1 referenceDateTimeM 1 .. 1 referenceIdentificationSt = Status: M=Mandatory, O=OptionalVersion: 2.0 - September 2007 Issue date: 30-9-2007 Page: 2Prepared by GS1 Netherlands


Component: Detail Level ReferenceGuidelineElements St Occurrence AnnotationsDetailLevelReference M Type: prefix:DetailLevelReferenceTypeDescription: Reference to a line item within a specific external document.Rule: Also see the guide for Component: Detail Level Reference.number M Type: restriction (xsd:nonNegativeInteger)FractionDigits: 0 TotalDigits: 6Use: requiredInclusive: 0 ..Description: Sequence number that identifies the line.xsd:sequence M 1..1reference M 1..1 Type: prefix:ReferenceTypeDescription: Reference to a specific external document.Rule: Also see the guide for Component: Detail Level Reference.xsd:sequence M 1..1referenceDateTime M 1..1 Type: xsd:dateTimeDescription: The date, time or date time related to a referenced document or message.referenceIdentification M 1..1 Type: restriction (xsd:string)Length: 1 .. 80Description:Unique identification of the entity referenced.St = Status: M=Mandatory, O=OptionalVersion: 2.0 - September 2007 Issue date: 30-9-2007 Page: 3Prepared by GS1 Netherlands


UIM Message Implementation Guide(MIG)forComponent: Document or Document Line Referencebased on messageNot applicableBMS Version: 2.1Contents: Message structureDetailed guidelineIssue date: 30-9-2007Version:Prepared by GS1 Netherlands


Component: Document or Document LineReferenceStructure ChartSt Occurrence ElementDocumentOrDocumentLineReferenceM 1 .. 1 xsd:choiceM 1 .. 1 documentReferenceOcreationDateTimeM 1 .. 1 xsd:sequenceM 1 .. 1 uniqueCreatorIdentificationM 1 .. 1 contentOwnerM 1 .. 1 xsd:sequenceM 1 .. 1 glnO 0 .. unbounded additionalPartyIdentificationM 1 .. 1 xsd:sequenceM 1 .. 1 additionalPartyIdentificationValueM 1 .. 1 additionalPartyIdentificationTypeM 1 .. 1 documentLineReferenceM required numberM 1 .. 1 xsd:sequenceO 0 .. 1 documentReferenceOcreationDateTimeM 1 .. 1 xsd:sequenceM 1 .. 1 uniqueCreatorIdentificationM 1 .. 1 contentOwnerM 1 .. 1 xsd:sequenceM 1 .. 1 glnO 0 .. unbounded additionalPartyIdentificationM 1 .. 1 xsd:sequenceM 1 .. 1 additionalPartyIdentificationValueM 1 .. 1 additionalPartyIdentificationTypeSt = Status: M=Mandatory, O=OptionalVersion: 2.0 - September 2007 Issue date: 30-9-2007 Page: 5Prepared by GS1 Netherlands


Component: Document or Document Line ReferenceGuidelineElements St Occurrence AnnotationsDocumentOrDocumentLineReference M Type: prefix:DocumentOrDocumentLineReferenceTypeDescription: Reference to a specific business document, and optionally to a line itemwithin a business document.Rule: Also see the guide for Component: Document Or Document Line Reference.xsd:choice M 1..1documentReference M 1..1 Type: prefix:DocumentReferenceTypeDescription: Reference to another GS1 Business Document.creationDateTime O Type: xsd:dateTimeDescription: Date and time of creation of the referenced document.xsd:sequence M 1..1uniqueCreatorIdentification M 1..1 Type: restriction (xsd:string)Length: 1 .. 80Description: Identification of the referenced business document.contentOwner M 1..1 Type: prefix:PartyIdentificationTypeDescription: Creator of the referenced document.Rule: See also: Component guide for Party IdentificationUsually the party that is referenced as sender of the message.xsd:sequence M 1..1gln M 1..1 Type: prefix:GlobalLocationNumberTypePattern: \d{13}additionalPartyIdentification O 0..unbounded Type: prefix:AdditionalPartyIdentificationTypexsd:sequence M 1..1additionalPartyIdentificationValue M 1..1 Type: xsd:stringadditionalPartyIdentificationType M 1..1 Type: prefix:AdditionalPartyIdentificationListTypedocumentLineReference M 1..1 Type: prefix:DocumentLineReferenceTypeDescription: Reference to a line item within a specific business document.number M Type: restriction (xsd:nonNegativeInteger)FractionDigits: 0 TotalDigits: 6Use: requiredInclusive: 0 ..xsd:sequence M 1..1Description:Sequence number that identifies the line.St = Status: M=Mandatory, O=OptionalVersion: 2.0 - September 2007 Issue date: 30-9-2007 Page: 6Prepared by GS1 Netherlands


Component: Document or Document Line ReferenceGuidelineElements St Occurrence AnnotationsdocumentReference O 0..1 Type: prefix:DocumentReferenceTypeDescription: Reference to another GS1 Business Document.creationDateTime O Type: xsd:dateTimeDescription: Date and time of creation of the referenced document.xsd:sequence M 1..1uniqueCreatorIdentification M 1..1 Type: restriction (xsd:string)Length: 1 .. 80Description: Identification of the referenced business document.contentOwner M 1..1 Type: prefix:PartyIdentificationTypexsd:sequence M 1..1gln M 1..1 Type: prefix:GlobalLocationNumberTypePattern: \d{13}additionalPartyIdentification O 0..unbounded Type: prefix:AdditionalPartyIdentificationTypexsd:sequence M 1..1additionalPartyIdentificationValue M 1..1 Type: xsd:stringadditionalPartyIdentificationType M 1..1 Type: prefix:AdditionalPartyIdentificationListTypeSt = Status: M=Mandatory, O=OptionalVersion: 2.0 - September 2007 Issue date: 30-9-2007 Page: 7Prepared by GS1 Netherlands


UIM Message Implementation Guide(MIG)forComponent: Envelope Layersbased on messageNot applicableBMS Version: n/aContents: Message structureDetailed guidelineIssue date: 30-9-2007Version: 2.0 - September 2007Prepared by GS1 Netherlands


Component: Envelope LayersStructure ChartSt Occurrence ElementStandardBusinessDocumentM 1 .. 1 xsd:sequenceO 0 .. 1 StandardBusinessDocumentHeaderM 1 .. 1 xsd:sequenceM 1 .. 1 HeaderVersionM 1 .. unbounded SenderM 1 .. 1 xsd:sequenceM 1 .. 1 IdentifierOAuthorityM 1 .. unbounded ReceiverM 1 .. 1 xsd:sequenceM 1 .. 1 IdentifierOAuthorityM 1 .. 1 DocumentIdentificationM 1 .. 1 xsd:sequenceM 1 .. 1 StandardM 1 .. 1 TypeVersionM 1 .. 1 InstanceIdentifierM 1 .. 1 TypeO 0 .. 1 MultipleTypeM 1 .. 1 CreationDateAndTimeO 0 .. 1 BusinessScopeM 1 .. 1 xsd:sequenceO 0 .. unbounded ScopeM 1 .. 1 xsd:sequenceM 1 .. 1 ScopeAttributesM 1 .. 1 xsd:sequenceM 1 .. 1 TypeM 1 .. 1 InstanceIdentifierO 0 .. 1 IdentifierO 0 .. unbounded ScopeInformationMBusinessServiceM 1 .. 1 xs:sequenceO 0 .. 1 BusinessServiceNameO 0 .. 1 ServiceTransactionO optional TypeOfServiceTransactionOIsNonRepudiationRequiredOIsAuthenticationRequiredOIsNonRepudiationOfReceiptRequiredOIsIntegrityCheckRequiredOIsApplicationErrorResponseRequestedOTimeToAcknowledgeReceiptOTimeToAcknowledgeAcceptanceOTimeToPerformORecurrenceMCorrelationInformationM 1 .. 1 xs:sequenceO 0 .. 1 RequestingDocumentCreationDateTimeO 0 .. 1 RequestingDocumentInstanceIdentifierO 0 .. 1 ExpectedResponseDateTimeO 0 .. 1 eanucc:messageSt = Status: M=Mandatory, O=OptionalVersion: 2.0 - September 2007 Issue date: 30-9-2007 Page: 9Prepared by GS1 Netherlands


Component: Envelope LayersStructure ChartSt Occurrence ElementM 1 .. 1 xsd:sequenceM 1 .. 1 entityIdentificationM 1 .. 1 xsd:sequenceM 1 .. 1 uniqueCreatorIdentificationM 1 .. 1 contentOwnerM 1 .. 1 xsd:sequenceM 1 .. 1 glnO 0 .. unbounded additionalPartyIdentificationM 1 .. 1 xsd:sequenceM 1 .. 1 additionalPartyIdentificationValueM 1 .. 1 additionalPartyIdentificationTypeM 1 .. 1 eanucc:transactionM 1 .. 1 xsd:sequenceM 1 .. 1 entityIdentificationM 1 .. 1 xsd:sequenceM 1 .. 1 uniqueCreatorIdentificationM 1 .. 1 contentOwnerM 1 .. 1 xsd:sequenceM 1 .. 1 glnO 0 .. unbounded additionalPartyIdentificationM 1 .. 1 xsd:sequenceM 1 .. 1 additionalPartyIdentificationValueM 1 .. 1 additionalPartyIdentificationTypeM 1 .. unbounded commandM 1 .. 1 xsd:sequenceO 0 .. 1 documentCommandM 1 .. 1 xsd:sequenceM 1 .. 1 documentCommandHeaderM required typeM 1 .. 1 xsd:sequenceM 1 .. 1 entityIdentificationM 1 .. 1 xsd:sequenceM 1 .. 1 uniqueCreatorIdentificationM 1 .. 1 contentOwnerM 1 .. 1 xsd:sequenceM 1 .. 1 glnO 0 .. unbounded additionalPartyIdentificationM 1 .. 1 xsd:sequenceM 1 .. 1 additionalPartyIdentificationValueM 1 .. 1 additionalPartyIdentificationTypeM 1 .. 1 documentCommandOperandM 1 .. 1 xsd:sequenceM 1 .. 1 xsd:anySt = Status: M=Mandatory, O=OptionalVersion: 2.0 - September 2007 Issue date: 30-9-2007 Page: 10Prepared by GS1 Netherlands


Component: Envelope LayersGuidelineElements St Occurrence AnnotationsStandardBusinessDocument M Type: StandardBusinessDocumentDescription: This is the root element of the SBDH data structureRule: The 'StandardBusinessDocument' element MUST be used as the root element of all GS1XML messages.xsd:sequence M 1..1StandardBusinessDocumentHeader O 0..1 Type: StandardBusinessDocumentHeaderDescription: The UN/CEFACT standard, containing information about the routing andprocessing of the business document. It also identifies the message setthat is sent together with on SBDH and the version number of thedocument(s) contained.Rule: Header information MUST be provided using the 'StandardBusinessDocumentHeader'element even though the use of this element is optional.xsd:sequence M 1..1HeaderVersion M 1..1 Type: xsd:stringDescription: Version number of the SBDH standard usedRule: The value of the 'HeaderVersion' element MUST be set to '1.0'. This is the version number ofthe standard.Sender M 1..unbounded Type: PartnerDescription: Sender of the message, party representing the organisation which createdthe standard business document.Rule: The 'Sender' tag MUST be used exactly only once with GS1 XML messages, even though itcan occur multiple times. If there is a requirement to use the 'Sender' block more than oncewith GS1 XML standards, such a requirement should be addressed through the use of theGSMP Change Request system.xsd:sequence M 1..1Identifier M 1..1 Type: PartnerIdentificationDescription:Rule:A unique identification key for the Sender partyThe value of the 'Identifier' element of 'PartnerIdentification' type MUST be a GLN. The use ofGLN as the identifier is mandatory with GS1 standards.St = Status: M=Mandatory, O=OptionalVersion: 2.0 - September 2007 Issue date: 30-9-2007 Page: 11Prepared by GS1 Netherlands


Component: Envelope LayersGuidelineElements St Occurrence AnnotationsAuthority O Type: xsd:stringDescription: Authority agency of the identification keyRule: The 'Authority' attribute, although optional, MUST be used and its value MUST be set to'EAN.UCC'.Receiver M 1..unbounded Type: PartnerDescription: Receiver of the message, party representing the organisation that receivesthe standard business document.Rule: The 'Receiver' tag MUST be used exactly only once with GS1 XML messages, even though itcan occur multiple timesxsd:sequence M 1..1Identifier M 1..1 Type: PartnerIdentificationDescription: A unique identification key for the receiving partyRule: The value of the 'Identifier' element of 'PartnerIdentification' type MUST be a GLN. The use ofGLN as the identifier is mandatory with GS1 standards.Authority O Type: xsd:stringDescription: Authority agency of the identification keyRule: The 'Authority' attribute, although optional, MUST be used and its value must be set to'EAN.UCC'. For legacy reasons and to support existing implementations of GS1 XMLstandards, the token 'EAN.UCC' has been used. At a future date when a new major versionof GS1 XML standards will be created (version 3.0) all references to the token 'EAN.UCC'associated with GS1 XML standards and document shall be replaced with the token 'GS1'DocumentIdentification M 1..1 Type: DocumentIdentificationDescription: Identification information for the documentxsd:sequence M 1..1Standard M 1..1 Type: xsd:stringDescription:Rule:The name of the document standard contained in the payloadThe value of the element 'Standard' MUST be set to the value 'EAN.UCC'.St = Status: M=Mandatory, O=OptionalVersion: 2.0 - September 2007 Issue date: 30-9-2007 Page: 12Prepared by GS1 Netherlands


Component: Envelope LayersGuidelineElements St Occurrence AnnotationsTypeVersion M 1..1 Type: xsd:stringDescription: Version information of the document included in the payload of SBDH. Thisis the 'complete' version of the document itself and is different than the'HeaderVersion'.Rule: The value of the element 'TypeVersion' MUST be set the version number of the root schemaof the XML business document contained in the payload of the message. Every GS1standard schema has version information in the 'xsd:version' attribute of the 'xsd:schema'tag of the schema and also in the schema annotation tag.The SBDH specification requires that all documents sent with one header have the sameversion number. To comply with this requirement;Only business documents belonging to the same BMS publication release and having thesame version number MUST be included in the payload if sending more than one documenttype.InstanceIdentifier M 1..1 Type: xsd:stringDescription: Description which contains reference information which uniquely identifiesthis instance of the Standard Business Document (SBD) between the'Sender' and the 'Receiver'. This identifier identifies this document as beingdistinct from others.Type M 1..1 Type: xsd:stringDescription: This element identifies the type of document.Rule: The value of the 'Type' element of 'DocumentIdentification' element MUST be set to the nameof the XML element that defines the root of the business document. This is the name of theglobal XML element declared in the root schema for the business document inconsideration.MultipleType O 0..1 Type: xsd:booleanDescription:Rule:Flag to indicate that there is more than one type of business document inthe payload of the SBDHThe value of the 'MultiType' element of 'DocumentIdentification' element MUST be set to'false' since the use of multiple types within the same SBDH is not allowed within GUSI.St = Status: M=Mandatory, O=OptionalVersion: 2.0 - September 2007 Issue date: 30-9-2007 Page: 13Prepared by GS1 Netherlands


Component: Envelope LayersGuidelineElements St Occurrence AnnotationsCreationDateAndTime M 1..1 Type: xsd:dateTimeDescription: Date and time of the SBDH document creation.Rule: The value of the 'CreationDateAndTime' element MUST be set to the date and time when the'document originating application' or the parser created the document. This value willtypically be populated by the trading partner and will typically differ from the time stampingof the message by the communications software.BusinessScope O 0..1 Type: BusinessScopeDescription: Description of the complete business environment in which the SBDH andSBD will be processed. The business scope provides a basis to determinewhich rules are applicable to the transaction involving the enclosedbusiness documents.xsd:sequence M 1..1Scope O 0..unbounded Type: Scopexsd:sequence M 1..1ScopeAttributes M 1..1xsd:sequence M 1..1Type M 1..1 Type: xsd:stringDescription: Type of business process in which the SBDH and SBD will be processed asspecified by GS1.InstanceIdentifier M 1..1 Type: xsd:stringIdentifier O 0..1 Type: xsd:stringDescription: Identifies the message type. The message type defines the actual use of theschemaScopeInformation O 0..unbounded Type: xsd:anyTypeDescription: This is an abstract element with a substitution group. The element will besubstituted by any one of the other elements that have the samesubstitution group. From the perspective of this implementation guide,these are the elements shown belowBusinessService M Type: BusinessServiceDescription: This element substitutes the element 'ScopeInformation' when usedxs:sequence M 1..1BusinessServiceName O 0..1 Type: xsd:stringSt = Status: M=Mandatory, O=OptionalVersion: 2.0 - September 2007 Issue date: 30-9-2007 Page: 14Prepared by GS1 Netherlands


Component: Envelope LayersGuidelineElements St Occurrence AnnotationsServiceTransaction O 0..1 Type: ServiceTransactionTypeOfServiceTransaction O Type: TypeOfServiceTransactionUse: optionalIsNonRepudiationRequired O Type: xsd:stringIsAuthenticationRequired O Type: xsd:stringIsNonRepudiationOfReceiptRequired O Type: xsd:stringIsIntegrityCheckRequired O Type: xsd:stringIsApplicationErrorResponseRequested O Type: xsd:stringTimeToAcknowledgeReceipt O Type: xsd:stringTimeToAcknowledgeAcceptance O Type: xsd:stringTimeToPerform O Type: xsd:stringRecurrence O Type: xsd:stringCorrelationInformation M Type: CorrelationInformationDescription: Co-relates requesting document information with the responding documentinformationThis element substitutes the element 'ScopeInformation' when usedxs:sequence M 1..1RequestingDocumentCreationDateTime O 0..1 Type: xsd:dateTimeRequestingDocumentInstanceIdentifier O 0..1 Type: xsd:stringExpectedResponseDateTime O 0..1 Type: xsd:dateTimeeanucc:message O 0..1 Type: eanucc:MessageTypexsd:sequence M 1..1entityIdentification M 1..1 Type: eanucc:EntityIdentificationTypexsd:sequence M 1..1uniqueCreatorIdentification M 1..1 Type: restriction (xsd:string)Length: 1 .. 80Description: Unique message identifier assigned by the content owner.contentOwner M 1..1 Type: eanucc:PartyIdentificationTypexsd:sequence M 1..1Description:Rule:Contains the identification of the party that has created the content of themessage.See also: Component guide for Party IdentificationSt = Status: M=Mandatory, O=OptionalVersion: 2.0 - September 2007 Issue date: 30-9-2007 Page: 15Prepared by GS1 Netherlands


Component: Envelope LayersGuidelineElements St Occurrence Annotationsgln M 1..1 Type: eanucc:GlobalLocationNumberTypePattern: \d{13}Description: Identification key for locationsadditionalPartyIdentification O 0..unbounded Type: eanucc:AdditionalPartyIdentificationTypeDescription: An addtional reference to identify a partyxsd:sequence M 1..1additionalPartyIdentificationValue M 1..1 Type: xsd:stringadditionalPartyIdentificationType M 1..1 Type: eanucc:AdditionalPartyIdentificationListTypeRule: Possible types are mentioned in the 'AdditionalPartyIdentificationListType'.eanucc:transaction M 1..1 Type: eanucc:TransactionTypexsd:sequence M 1..1entityIdentification M 1..1 Type: eanucc:EntityIdentificationTypeDescription: unique transaction identifier (in combination with GLN)xsd:sequence M 1..1uniqueCreatorIdentification M 1..1 Type: restriction (xsd:string)Length: 1 .. 80Description: Unique transaction identifier assigned by the content owner.contentOwner M 1..1 Type: eanucc:PartyIdentificationTypeDescription: Contains the identification of the party that has created the content of thetransaction.Rule: See also: Component guide for Party Identificationxsd:sequence M 1..1gln M 1..1 Type: eanucc:GlobalLocationNumberTypePattern: \d{13}Description: Identification key for locationsadditionalPartyIdentification O 0..unbounded Type: eanucc:AdditionalPartyIdentificationTypexsd:sequence M 1..1additionalPartyIdentificationValue M 1..1 Type: xsd:stringadditionalPartyIdentificationType M 1..1 Type: eanucc:AdditionalPartyIdentificationListTypecommand M 1..unbounded Type: eanucc:CommandTypexsd:sequence M 1..1documentCommand O 0..1 Type: eanucc:DocumentCommandTypexsd:sequence M 1..1St = Status: M=Mandatory, O=OptionalVersion: 2.0 - September 2007 Issue date: 30-9-2007 Page: 16Prepared by GS1 Netherlands


Component: Envelope LayersGuidelineElements St Occurrence AnnotationsdocumentCommandHeader M 1..1 Type: eanucc:DocumentCommandHeaderTypetype M Type: eanucc:DocumentCommandListTypeUse: requiredSt = Status: M=Mandatory, O=OptionalDescription: Describes how to process a business documentCode/Description* ADD* CHANGE_BY_REFRESH* CORRECT* DELETExsd:sequence M 1..1entityIdentification M 1..1 Type: eanucc:EntityIdentificationTypexsd:sequence M 1..1uniqueCreatorIdentification M 1..1 Type: restriction (xsd:string)Length: 1 .. 80Description: Unique document command identifier assigned by the content owner.contentOwner M 1..1 Type: eanucc:PartyIdentificationTypeDescription: Contains the identification of the party that has created the content of thebusiness document.Rule: See also: Component guide for Party Identificationxsd:sequence M 1..1gln M 1..1 Type: eanucc:GlobalLocationNumberTypePattern: \d{13}additionalPartyIdentification O 0..unbounded Type: eanucc:AdditionalPartyIdentificationTypexsd:sequence M 1..1additionalPartyIdentificationVal M 1..1 Type: xsd:stringueadditionalPartyIdentificationTyp M 1..1 Type: eanucc:AdditionalPartyIdentificationListTypeedocumentCommandOperand M 1..1 Type: eanucc:DocumentCommandOperandTypeDescription:Contains an abstract element that can be extended by the actual documentelements, defined in the actual business message schemas. Those are thedocuments against which one of the actions defined in the header elementshould be performed. possible documents include e.g. 'Order','DespatchAdvice', ..Version: 2.0 - September 2007 Issue date: 30-9-2007 Page: 17Prepared by GS1 Netherlands


Component: Envelope LayersGuidelineElements St Occurrence Annotationsxsd:sequence M 1..1xsd:any M 1..1 Rule: The actual business document starts here.St = Status: M=Mandatory, O=OptionalVersion: 2.0 - September 2007 Issue date: 30-9-2007 Page: 18Prepared by GS1 Netherlands


UIM Message Implementation Guide(MIG)forComponent: Logistic Unit Identificationbased on messageNot applicableBMS Version: 2.1Contents: Message structureDetailed guidelineIssue date: 30-9-2007Version: 2.0 - September 2007Prepared by GS1 Netherlands


Component: Logistic Unit IdentificationStructure ChartSt Occurrence ElementLogisticUnitIdentificationM 1 .. 1 xsd:sequenceM 1 .. 1 serialShipmentContainerCodeM 1 .. 1 xsd:sequenceM 1 .. 1 serialShippingContainerCodeO 0 .. unbounded additionalLogisticUnitIdentificationM 1 .. 1 xsd:sequenceM 1 .. 1 logisticUnitIdentificationSt = Status: M=Mandatory, O=OptionalVersion: 2.0 - September 2007 Issue date: 30-9-2007 Page: 20Prepared by GS1 Netherlands


Component: Logistic Unit IdentificationGuidelineElements St Occurrence AnnotationsLogisticUnitIdentification M Type: prefix:LogisticUnitIdentificationTypexsd:sequence M 1..1serialShipmentContainerCode M 1..1 Type: prefix:SSCCTypeDescription: A single globally unique serial number which identifies shipping containersor shipping packages.The globally unique identification attached to a shipping container orshipping package and used for logistical and traceability purposes.Rule: See also: Component guide for Logistic Unit Identificationxsd:sequence M 1..1serialShippingContainerCode M 1..1 Type: restriction (xsd:string)Pattern: \d{18}additionalLogisticUnitIdentification O 0..unbounded Type: prefix:AdditionalLogisticUnitIdentificationTypeDescription: Additional (non-SSCC) identification attached to a shipping container orshipping package and used for logistical and traceability purposes.xsd:sequence M 1..1logisticUnitIdentification M 1..1 Type: xsd:stringDescription:A number which identifies shipping containers or shipping packages.St = Status: M=Mandatory, O=OptionalVersion: 2.0 - September 2007 Issue date: 30-9-2007 Page: 21Prepared by GS1 Netherlands


UIM Message Implementation Guide(MIG)forComponent: Party Identificationbased on messageNot applicableBMS Version: 2.1Contents: Message structureDetailed guidelineIssue date: 30-9-2007Version: 2.0 - September 2007Prepared by GS1 Netherlands


Component: Party IdentificationStructure ChartSt Occurrence ElementPartyIdentificationM 1 .. 1 xsd:sequenceM 1 .. 1 glnO 0 .. unbounded additionalPartyIdentificationM 1 .. 1 xsd:sequenceM 1 .. 1 additionalPartyIdentificationValueM 1 .. 1 additionalPartyIdentificationTypeSt = Status: M=Mandatory, O=OptionalVersion: 2.0 - September 2007 Issue date: 30-9-2007 Page: 23Prepared by GS1 Netherlands


Component: Party IdentificationGuidelineElements St Occurrence AnnotationsPartyIdentification M Type: prefix:PartyIdentificationTypeRule: See also: Component guide for Party Identificationxsd:sequence M 1..1gln M 1..1 Type: prefix:GlobalLocationNumberTypePattern: \d{13}Description: The Global Location Number (GLN) is a structured identification of aphysical location, legal or functional entity within an enterprise. The GLN isthe primary party identifier. Each party identified in the trading relationshipmust have a primary party identification.additionalPartyIdentification O 0..unbounded Type: prefix:AdditionalPartyIdentificationTypeDescription:Rule:A party identifier that is in addition to the GLN.If parties decide to allow additional party identifiers they should always include theSUPPLIER_ASSIGNED identifier.xsd:sequence M 1..1additionalPartyIdentificationValue M 1..1 Type: xsd:stringadditionalPartyIdentificationType M 1..1 Type: prefix:AdditionalPartyIdentificationListTypeCode/Description* BUYER_ASSIGNED_IDENTIFIER_FOR_A_PARTY* DEA_DRUG_ENFORCEMENT_AGENCY* DUNS* DUNS_PLUS_FOUR* HIN_CANADIAN_HEALTHCARE_IDENTIFICATION_NUMBER* SCAC* SELLER_ASSIGNED_IDENTIFIER_FOR_A_PARTY* TD_LINK_TRADE_DIMENSIONS* UCC_COMMUNICATION_IDENTIFICATION* UN_LOCATION_CODE* USDA_ESTABLISHMENT_NUMBERSt = Status: M=Mandatory, O=OptionalVersion: 2.0 - September 2007 Issue date: 30-9-2007 Page: 24Prepared by GS1 Netherlands


UIM Message Implementation Guide(MIG)forComponent: Trade Item Identificationbased on messageNot applicableBMS Version: 2.1Contents: Message structureDetailed guidelineIssue date: 30-9-2007Version: 2.0 - September 2007Prepared by GS1 Netherlands


Component: Trade Item IdentificationStructure ChartSt Occurrence ElementTradeItemIdentificationM 1 .. 1 xsd:sequenceM 1 .. 1 gtinO 0 .. unbounded additionalTradeItemIdentificationM 1 .. 1 xsd:sequenceM 1 .. 1 additionalTradeItemIdentificationValueM 1 .. 1 additionalTradeItemIdentificationTypeSt = Status: M=Mandatory, O=OptionalVersion: 2.0 - September 2007 Issue date: 30-9-2007 Page: 26Prepared by GS1 Netherlands


Component: Trade Item IdentificationGuidelineElements St Occurrence AnnotationsTradeItemIdentification M Type: prefix:TradeItemIdentificationTypeDescription: The identification of any item (product or service) upon which there is aneed to retrieve pre-defined information and that may be priced, ordered, orinvoiced at any point in any supply chain.Rule: See also: Component guide for Trade Item Identificationxsd:sequence M 1..1gtin M 1..1 Type: prefix:GlobalTradeItemNumberTypePattern: \d{14}Description: A particular Global trade item Number, a numerical value used to uniquelyidentify a trade item. A trade item is any trade item (trade item or service)upon which there is a need to retrieve pre-defined information and that maybe planned, priced, ordered, delivered and or invoiced at any point in anysupply chain.additionalTradeItemIdentification O 0..unbounded Type: prefix:AdditionalTradeItemIdentificationTypeDescription:Rule:A trade item identification that is in addition to the GTIN.Trading partners should agree beforehand (e.g. in the integration agreement) on whichtypes of additional trade item identifiers they will use.xsd:sequence M 1..1additionalTradeItemIdentificationValue M 1..1 Type: restriction (xsd:string)Length: 1 .. 80additionalTradeItemIdentificationType M 1..1 Type: prefix:AdditionalTradeItemIdentificationListTypeCode/Description* BUYER_ASSIGNED* INDUSTRY_ASSIGNED* SUPPLIER_ASSIGNEDSt = Status: M=Mandatory, O=OptionalVersion: 2.0 - September 2007 Issue date: 30-9-2007 Page: 27Prepared by GS1 Netherlands

More magazines by this user
Similar magazines