uim implementation guide - gs1 canada implementation guide... · 2010. 4. 16. · 3 and 4.4) and...

Global Upstream Supply Initiative UIM Implementation Guide Demand and Supply Signals

Revision 19 May 2008, Version 2.0 - September 2007 of 13

UIM Implementation Guide Demand and Supply Signals

Version 2.0 - September 2007

Revision 19 May 2008

Issued with the support of



Document Summary

Document Item Current Value

Document Title UIM Implementation Guide Demand and Supply Signals

Version Version 2.0 - September 2007

Current Document Issue Revision 19 May 2008

Status Approved

Editor GS1 Nederland

Acknowledgements

This document was made possible by the support and contribution of members of the GCI GUSI Implementation Team; their leadership and willingness to share their learnings has enabled this guideline. GCI would like to thank the project team members, who willingly shared their experience and examples, as well as the GS1 experts, who advised on the correct implementation of the GS1 Standards and provided essential support in editing the guideline.

Contributors

Accenture Nestlé

Alcan Novozymes

Crown NSpyre / TIE

Groupe Danone PipeChain

Firmenich Procter & Gamble

GCI Sara Lee

GS1 Nederland Symrise

Henkel KGaA Tetra Pak

Intelligent Solutions Unilever

Log of Changes

Date of Change Changed By Summary of Change

19 May 2008 CJ Errata

Disclaimer

“Whilst every effort has been made to ensure that the guidelines to use the GUSI UIM and GS1 standards contained in the document are correct, GCI, GS1 and any other party involved in the creation of the document HEREBY STATE that the document is provided without warranty, either expressed or implied, of accuracy or fitness for purpose, AND HEREBY DISCLAIM any liability, direct or indirect, for damages or loss relating to the use of the document. The document may be modified, subject to developments in technology, changes to the standards, or new legal requirements.“



TABLE OF CONTENTS

1. Introduction ........................................................................................................................ 5 1.1. Purpose ........................................................................................................................................ 5 1.2. Recommended reading ................................................................................................................. 5 1.3. Overview....................................................................................................................................... 5

2. General rules....................................................................................................................... 6 2.1. Parties and roles ........................................................................................................................... 6

3. Process – Traditional Order Management ...................................................................... 7 3.1. Introduction ................................................................................................................................... 7 3.2. To document beforehand in the integration agreement .................................................................. 7 3.3. Rules applying to all transactions .................................................................................................. 8 3.4. Rules applying to the Supplier Inventory transaction...................................................................... 8 3.5. Rules applying to the Net Requirements transaction...................................................................... 8 3.6. Rules applying to the Purchase Order transaction ......................................................................... 8 3.7. Rules applying to the Purchase Order Confirmation transaction..................................................... 8 3.8. Handling exceptions in the Traditional Order Management process ............................................... 8

4. Process – SMI ................................................................................................................... 10 4.1. To document beforehand in the integration agreement ................................................................ 10 4.2. Rules applying to all transactions ................................................................................................ 12 4.3. Rules applying to the Replenishment Forecast transaction .......................................................... 12 4.4. Rules applying to the Delivery Plan transaction ........................................................................... 13 4.5. Rules applying when forecast and inventory are communicated separately.................................. 13



MIGs included in this Guide Consumption Forecast.................................................................................................................... 1

Delivery Plan .................................................................................................................................12

Manufacturer / Supplier Inventory .................................................................................................23

Net Requirements .........................................................................................................................33

Net Requirements Confirmation ....................................................................................................45

Purchase Order ............................................................................................................................50

Purchase Order Confirmation .......................................................................................................68

Replenishment Forecast ................................................................................................................72



1. Introduction

1.1. Purpose This is a guide to help companies implementing the Upstream Integration Model (UIM) version 2.2 and the 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 practices and points to consider during implementation. Therefore this guide is a living document to be updated with best practices gained from UIM implementations by companies involved in the Global Upstream Supply 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 addressed and documented separately in their specific projects.

The guide has been structured based on the following hierarchy:

� Business Process = a group of coherent business transactions, a business function (e.g. SMI)

� Transaction = an interaction between two parties, based on a business message, as described in the UIM model (e.g. Replenishment Forecast)

� Message = an electronic data interchange (EDI) message (e.g. Replenishment Request)

The same Business Messages can be used in multiple transactions. Therefore separate message implementation guides have been created for each transaction.

1.2. Recommended reading Recommended reading:

� Upstream Integration Model, specifically the section on Demand and Supply Signals (chapters 3 and 4.4) and the mapping of UIM transactions to GS1 Standards (chapter 5).

� We recommend that programmers and people responsible for technical side of the implementation also read the UIM Implementation Guide - Technical Document

1.3. Overview This guide consists of implementation instructions for two main processes:

1. Traditional Order Management process

2. Supplier Managed Inventory process

For each of the processes we describe the rules as well as the recommendations as agreed upon by the GUSI Implementation team.



2. General rules

2.1. Parties and roles The two main parties involved are the Manufacturer and Supplier. They must agree which organization entities they will assign to the various roles in the processes. The following roles need to be addressed:

Table 2-1 Roles in the Demand and Supply processes

Role Remarks

Buyer Often the business unit / HQ of the Manufacturer.

Seller Often the business unit / HQ of the Supplier.

Ship From Ship From is the location of the Supplier from where goods are to be delivered.

Ship To Ship To is the location of the Manufacturer where goods are to be delivered.

Inventory Location Used to denote the final destination of the goods. This can be an internal warehouse but also a silo for example.

Used in the Inventory transaction to report about the actual location where the goods are stored.

Inventory Sub Location Only used in the inventory report, provides a way to further detail the location of the goods.

Inventory Reporting Party Party reporting about the inventory. Can be either the Material Supplier (supplier inventory transaction) or the Manufacturer (manufacturer inventory transaction).

Inventory Report-to Party Party to whom the inventory is reported. Can be either the Material Supplier (manufacturer inventory transaction) or the Manufacturer (supplier inventory transaction).



3. Process – Traditional Order Management Figure 3-1 Traditional Order Management Process

Key process steps– Scenario A:Key process steps– Scenario A:

Manufacturer Supplier

Optional

Scope / Purpose:

• Communicate specific delivery quantities and timings based on the material reqts of the manufacturer

II. Generate Purchase OrderAND / OR

Net Requirements

I. Integrate in ERP system;Calculate Material Requirements

VI. Resolve exceptions

IV. Plan Supply & Identify exceptions

Can Orderbe fulfilled?

V. Generate Purchase OrderConfirmation

V. Retrieve Exception

Yes

No


I. Retrieve Supplier Inventory

IntegrationAgreement

DataAlignment

PurchaseConditions

Demand& SupplySignals

Despatch,Receipt &Consumption

FinancialSettlement

Common

Supplier Inventory

Purchase Order

VI. Integrate in ERP system

Italic

Net RequirementsIII. Plan Production

Optional

Purchase Order Confirmation

[Source: Upstream Integration Model]

3.1. Introduction

Note: Known issues that are not supported (contact GUSI work group for information):

□ Exchange of Item Master Data outside the regular item transaction is not supported.

□ Ordering of packaging materials in product families (needed in the case of co-printing) is not supported.

□ Product variants are not supported. When GTINs are not in place, some extra information is required to manage product variants in the transaction.

□ Prices per base quantity (prices expressed in a unit multiple, e.g. per 100 pieces) are not supported.

3.2. To document beforehand in the integration agre ement 1. Manufacturer and Supplier must agree beforehand whether they will use the Purchase Order

Confirmation. If they decide to do so it must be used as a positive confirmation stating the acceptance of the order. If the Manufacturer and Supplier agree not to use the Purchase Order Confirmation, then they must agree on a process to communicate the acceptance of the purchase order.



2. Manufacturer and Supplier must agree on a process to communicate the non-acceptance, changes and cancellations of the purchase order.

Note: Within the order-driven TOM Process multiple different processes can be covered, such as: a. make to order, b. deliver from stock, c. synchronised planning, etc depending on the business needs. In all of these processes the firm commitment is the Purchase Order.

3.3. Rules applying to all transactions 1. One transaction can only contain one Ship-To location.

3.4. Rules applying to the Supplier Inventory trans action 1. The Supplier Inventory transaction should only contain information related to one inventory

location (site). Information concerning another location should be sent in a separate transaction.

3.5. Rules applying to the Net Requirements transac tion No rules defined.

3.6. Rules applying to the Purchase Order transacti on 1. Multiple delivery dates per item are allowed.

2. Only one Ship-To location is allowed per Order. Although Ship-To Locations need to be specified at line item level, they must be identical for all lines.

3.7. Rules applying to the Purchase Order Confirmat ion transaction 1. Where there is agreement, the Supplier can (optionally) send a Purchase Order Confirmation.

2. Where there is disagreement, the Supplier must react via the agreed process.

Note: Communicating deviations from the Purchase Order is currently not supported in the Purchase Order Confirmation.

3.8. Handling exceptions in the Traditional Order M anagement process 1. The Supplier will react via the agreed process if he disagrees with a received Purchase Order.

After resolution of the disagreement the Manufacturer must send a new Purchase Order transaction, with a change indicator, using the same number as per the original purchase order. The new Purchase Order should include all order lines both unchanged and changed in order to reflect the most up-to-date state of the order.

2. Cancelling an order line is done by including the line item with a zero quantity. In case of subsequent order changes only new cancelled lines should be included, previously cancelled lines should be omitted.

3. Optional, if stated in the integration agreement: the Supplier can cancel the entire order by sending a new Purchase Order transaction, with a change indicator, using the same number as per the original purchase order, and with zero quantities for all line items.



4. Optional, if stated in the integration agreement: if there is a Purchase Order Change the Manufacturer must send a new order confirmation to confirm the acceptance of the changed order.

Figure 3-2 Exception handling



4. Process – SMI Figure 4-1 SMI Process


Scope / Purpose:

• Communicate specific delivery quantities and timings based on the material requirements of a manufacturer

Key process steps:

I. Retrieve Manufacturer InventoryAND/OR

Consumption Forecast ORReplenishment Forecast


III. Plan Supply

I. Integrate in ERP system &Calculate ManufacturerMaterial Requirements

IntegrationAgreement

DataAlignment

PurchaseConditions

Demand& SupplySignals

Despatch,Receipt &Consumption

FinancialSettlement

Manufacturer Inventory

Replenishment Forecast(instead of Inv. and C.Forecas)

Delivery PlanV. Integrate in ERP system

OptionalItalic

II. Plan Production

Consumption Forecast

[Source: Upstream Integration Model]

4.1. To document beforehand in the integration agre ement 1. Forecast quantity – the Manufacturer and Supplier must agree what units of measure will be used

in the SMI process. This must be specified per trade item group.

2. Forecast horizon length - the Manufacturer and Supplier must agree on the length of the forecast horizon.

3. Forecast horizon buckets - the Manufacturer and Supplier must agree on the bucket sizes within the forecast horizon.

4. If multiple horizons / bucket sizes are used simultaneously the bucket dates should not overlap each other. E.g. 14 days horizon sent in daily buckets and a one year horizon sent in weekly buckets - where the start of the weekly horizon is within the daily horizon. A situation such as this requires hypothetical calculations on the overlapping or partial period. Should this option become necessary, then the more detailed (e.g. daily) time buckets must completely replace the less detailed (e.g. weekly) time buckets and specify the date/time from which the latter starts to apply.

5. Forecast update frequency - the Manufacturer and Supplier must agree on how frequently the forecast is updated (e.g. daily, weekly, etc) and specify the end time the information will be available at the Supplier.



6. Commitment period - the Manufacturer and Supplier must agree on the maximum period for which the Manufacturer financially commits itself for the forecast (stock at the Manufacturer's plant and Supplier included + planned fixed production + any planned production tolerance at the Supplier). Always mention if the safety stocks are in- or excluded. There could also be individual agreements for different trade item groups.

7. Commitment period (supplier materials) - the Manufacturer and Supplier must agree on the period for which the Manufacturer commits itself to the forecast for the material needed by the Supplier exclusively for the Manufacturer.

8. Safety Stock in the relationship - safety stock (or minimum stock) at the Supplier and/or Manufacturer defined as a time period and/or as a fixed quantity. Mention the location of the safety stock if the stock is stored at an external warehouse.

9. Maximum Stock at the Manufacturer – maximum stock defined as the quantity and/or time per trade item, or quantity per group of trade item, that the Supplier is allowed to replenish at the warehouse of the Manufacturer.

10. Delivery plan frequency - weekly or daily frequency. Mention the frequency and day/time when the Supplier publishes the delivery plans.

11. Delivery plan covering period - how long should the delivery plan cover the forecast from the Manufacturer and mention which period is fixed, if any.

12. Delivery window - the period free for the Supplier to deliver or the fixed day and/or time. If not relevant or not agreed, it is good to mention the opening hours of the warehouse at the Manufacturer.

13. Consignment Stock – under the consignment process, a consumption report must be send from the Manufacturer to the Supplier on an agreed timing (recommended to be aligned with the billing period). Quantity confirmation is agreed by both parties before the invoice is issued.

Points to consider

� Forecast and inventory information accuracy - the Manufacturer and Supplier must review the level of accuracy and agree on the targeted minimum level of accuracy of the inventory and forecast information.

� Safety Stock tolerance – in order to avoid cost inefficient production and/or despatch, the Supplier and Manufacturer may agree to adopt a tolerance in reference to the safety stock level.

� Production lead-time - time (in days / weeks) needed from the start of production at the Supplier to the finished goods warehouse of the Supplier. To be considered when setting the commitment period.

� Production fixed at the Supplier - time between freezing of the production plan and the actual start of production (i.e.: the deadline for change in quantity for planned production at the Supplier). Point to consider when setting the commitment period.

� Delivery plan frequency – for a short period of time and for trust building measure, the Manufacturer may wish to confirm the Supplier's delivery plan and, if so, at what day/time and how.

� Delivery lead-time - time needed for making the delivery (days or hours) from finished stock at the Supplier to the warehouse of the Manufacturer. Point to consider when setting the commitment period.

� Forecast phasing - use when a change of design or a specification of a new material code is issued and will be used in the forecast. This new material should be shown X weeks before the actual start of using the material (depending on the agreed commitment period and/or lead-time of the new design). Agree a standard procedure on how to handle design changes.



For example: the Manufacturer communicates a design change to the Supplier via a written form and mentions if it concerns a ‘fixed’ or a ‘smooth’ changeover. The Supplier informs the Manufacturer in cases where the planning of a ‘smooth’ or ‘fixed’ design change is not in line with the forecast phasing. The Manufacturer then has to adjust the change-over date in the forecast

� Standard design change lead-time - mention the weeks needed for preparing artworks, print-proofs, cromalins and cylinders starting at the receipt of the artwork by the Supplier until the first delivery. The check of print-proofs / cromalins by the Manufacturer should be included. Define each step in the process and link a timeframe to this

� Urgent design change lead-time - the same as the standard lead-time, but only used in urgent situations. Mention how many times per year this ‘urgency’ can be used, to make sure it will be seen as an exception and not as the standard

� Holding period (permanent obsolete) - how long should the Supplier keep obsolete material on stock before the stock can be invoiced or destroyed.

� Holding period (temporary obsolete) - how long should the Supplier keep temporary obsolete material on stock before the stock can be invoiced or destroyed.

� Storage of obsolete designs - how long should the Supplier keep films, stamps, cylinders etc on stock before asking approval for destruction to the Manufacturer.

Note: Areas such as payment, performance measurements, confidentiality, quality rules and claims may well be covered in the commercial contract agreed between the Manufacturer and Supplier. If so, there is probably no need to reference them in the Integration Agreement.

4.2. Rules applying to all transactions 1. The Manufacturer should make sure that the Consumption Forecast and the Manufacturer

Inventory are well synchronised. This means, for example, that a Consumption Forecast line item which is produced/finished should have the raw material inventory downgraded, or when inventory is downgraded at the start of a Consumption Forecast line item, the Consumption Forecast line item should not exist anymore, etc.

4.3. Rules applying to the Replenishment Forecast t ransaction

1. The inventory figure includes safety stock at the Manufacturer sites and should contain the amount that is still blocked for Quality Inspection. Any rejected stock should not be included in this inventory. The Supplier must use a purge mechanism in which all inventory figures are set to zero before the new inventory transaction is loaded.

2. No zero quantity-related forecasts / requirements will be sent. This implies that requirements sent in a previous transaction are not valid anymore in the new transaction and need to be removed from the Supplier system first (purge mechanism). Best practice is to remove all requirements for a Manufacturer site prior to loading the new transaction. The Supplier must use a purge mechanism in which all inventory figures are set to zero before the new inventory transaction is loaded.

3. Inventory levels for replenished items are always sent, including zero quantities.



4.4. Rules applying to the Delivery Plan transactio n 1. The Manufacturer must use a purge mechanism in which all delivery plan figures are set to zero

before the new Delivery Plan is loaded.

2. The Delivery Plan must include in-transit deliveries. This means that as long as there is no Receipt Notification or confirmation for receiving the delivery at the Manufacturer site, it should appear as a delivery. In-transit quantities should be fixed and not changeable because of changed requirements.

3. Delivery Plan figures should reflect the real estimated delivery. Subsequent forecast data for a material should take account of any rounding up amounts in earlier deliveries.

Note: The contract number is the same number as the one that is going to be used in the Despatch Notification. It is a number generated by the Manufacturer. A Delivery Plan can include more than one contract number.

4.5. Rules applying when forecast and inventory are communicated separately All rules mentioned before apply. Additional rules are:

1. The Manufacturer Inventory and Consumption Forecast messages must be sent at the same time. This also applies when the forecast data does not show any variation compared to the previous transaction.

Important: This alternate procedure should only be used in case of technical barriers to sending the Replenishment Forecast which combines Inventory and Replenishment Forecast.

UIM Message Implementation Guide(MIG)

for

Transaction: Consumption Forecast

based on message

Prepared by GS1 Netherlands

Issue date: 30-9-2007Version: 2.0 - September 2007

Contents: Message structureDetailed guideline

Goods RequirementsBMS Version: 2.1


Structure Chart

Version: 2.0 - September 2007 Issue date: 30-9-2007 Page: 2Prepared by GS1 Netherlands

St = Status: M=Mandatory, O=Optional

St Occurrence Element

plan:goodsRequirementsM required creationDateTimeM required documentStatusM required goodsRequirementsTypeM required structureTypeM 1 .. 1 xsd:sequenceM 1 .. 1 documentStructureVersionM 1 .. 1 xsd:sequenceM 1 .. 1 versionIdentificationM 1 .. 1 xsd:sequenceM 1 .. 1 goodsRequirementsIdentificationM 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 buyerM 1 .. 1 xsd:sequenceM 1 .. 1 glnO 0 .. unbounded additionalPartyIdentificationM 1 .. 1 xsd:sequenceM 1 .. 1 additionalPartyIdentificationValueM 1 .. 1 additionalPartyIdentificationTypeM 1 .. 1 sellerM 1 .. 1 xsd:sequenceM 1 .. 1 glnO 0 .. unbounded additionalPartyIdentificationM 1 .. 1 xsd:sequenceM 1 .. 1 additionalPartyIdentificationValueM 1 .. 1 additionalPartyIdentificationTypeO 0 .. 1 goodsRequirementsPlannerM 1 .. 1 xsd:sequenceO 0 .. unbounded communicationChannelM required communicationChannelCodeM required communicationNumberM 1 .. 1 personOrDepartmentNameM 1 .. 1 xsd:sequenceM 1 .. unbounded descriptionM 1 .. 1 xsd:sequenceM 1 .. 1 languageM 1 .. 1 xsd:sequenceM 1 .. 1 languageISOCodeM 1 .. 1 textM 1 .. unbounded goodsRequirementsItemLocationInformationM 1 .. 1 xsd:sequenceM 1 .. 1 tradeItemIdentification


Structure Chart




M 1 .. 1 xsd:sequenceM 1 .. 1 gtinO 0 .. unbounded additionalTradeItemIdentificationM 1 .. 1 xsd:sequenceM 1 .. 1 additionalTradeItemIdentificationValueM 1 .. 1 additionalTradeItemIdentificationTypeM 1 .. 1 shipToM 1 .. 1 xsd:sequenceM 1 .. 1 glnO 0 .. unbounded additionalPartyIdentificationM 1 .. 1 xsd:sequenceM 1 .. 1 additionalPartyIdentificationValueM 1 .. 1 additionalPartyIdentificationTypeO 0 .. 1 shipFromM 1 .. 1 xsd:sequenceM 1 .. 1 glnO 0 .. unbounded additionalPartyIdentificationM 1 .. 1 xsd:sequenceM 1 .. 1 additionalPartyIdentificationValueM 1 .. 1 additionalPartyIdentificationTypeO 0 .. 1 inventoryLocationM 1 .. 1 xsd:sequenceM 1 .. 1 glnO 0 .. unbounded additionalPartyIdentificationM 1 .. 1 xsd:sequenceM 1 .. 1 additionalPartyIdentificationValueM 1 .. 1 additionalPartyIdentificationTypeM 1 .. unbounded goodsRequirementsLineItemM required numberM required timeBucketSizeM 1 .. 1 xsd:sequenceM 1 .. 1 requiredQuantityM 1 .. 1 xsd:sequenceM 1 .. 1 valueO 0 .. 1 unitOfMeasureM 1 .. 1 xsd:sequenceM 1 .. 1 measurementUnitCodeValueM 1 .. 1 requirementsPeriodM 1 .. 1 xsd:choiceM 1 .. 1 timePeriodM required beginDateM required endDateM 1 .. 1 dateTimePeriodM required beginDateTimeM required endDateTimeO 0 .. 1 purchaseConditionsM 1 .. 1 xsd:choiceM 1 .. 1 documentLineReferenceM required numberM 1 .. 1 xsd:sequence


Structure Chart




M 1 .. 1 documentReferenceO creationDateTimeM 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 additionalPartyIdentificationType


Guideline

Elements St Occurrence Annotations



plan:goodsRequirements M Type: plan:GoodsRequirementsType

Description: Contains the Goods Requirements from the buyer to t he seller for giventrade items and locations for specific time periods .

creationDateTime M Type: xsd:dateTimeUse: required

Description: This is the date the message was created. This date is recommended touse as technical information.

documentStatus M Type: eanucc:DocumentStatusListTypeUse: required

Description: Indicates if the document is a copy, an original or a change.Rule: Use: "ORIGINAL" Exception: When the message is a resend with changes use: "REPLACE".

Do not use "COPY".Code/Description

* ORIGINAL* REPLACE

goodsRequirementsType M Type: plan:GoodsRequirementsTypeListTypeUse: required

Description: Specifies the origin and type of the demand.Rule: For the Consumption Forecast use "GROSS_REQUIREMENTS"Code/Description

* GROSS_REQUIREMENTSstructureType M Type: eanucc:StructureTypeListType

Use: required

Description: Contains the type of grouping and sequence of the b usiness document.Rule: Default is "ITEM_BY_LOCATION". This field has no effect on the message stucture, it

informs only on the reporting logic applied by the sending party.Code/Description

* ITEM_BY_LOCATION For each location all items that are stored at that location arespecified.

* LOCATION_BY_ITEM For each item all locations were the item is stored arespecified.

xsd:sequence M 1..1


Guideline




documentStructureVersion M 1..1 Type: eanucc:VersionType

Description: Contains the version of the message standard on whi ch the content of themessage was based.

Rule: Optional in BMS, mandatory in MIG. Contains the BMS version number.xsd:sequence M 1..1

versionIdentification M 1..1 Type: xsd:stringRule: Currently value '2.1' should be used.

xsd:sequence M 1..1goodsRequirementsIdentification M 1..1 Type: eanucc:EntityIdentificationType

Description: Contains the Goods Requirements number assigned by the content owner.xsd:sequence M 1..1

uniqueCreatorIdentification M 1..1 Type: restriction (xsd:string)Length: 1 .. 80

contentOwner M 1..1 Type: eanucc:PartyIdentificationType

Description: The owner of the payload of the message.Rule: See also: Component guide for Party Identification

Usually the party that is referenced as sender of the message.xsd:sequence M 1..1

gln M 1..1 Type: eanucc:GlobalLocationNumberTypePattern: \d{13}

additionalPartyIdentification O 0..unbounded Type: eanucc:AdditionalPartyIdentificationTypexsd:sequence M 1..1

additionalPartyIdentificationValue M 1..1 Type: xsd:stringadditionalPartyIdentificationType M 1..1 Type: eanucc:AdditionalPartyIdentificationListType

buyer M 1..1 Type: eanucc:PartyIdentificationType

Description: Contains the identification of the party that is bu ying the goods.Rule: See also: Component guide for Party Identification

xsd:sequence M 1..1gln M 1..1 Type: eanucc:GlobalLocationNumberType

Pattern: \d{13}additionalPartyIdentification O 0..unbounded Type: eanucc:AdditionalPartyIdentificationType

xsd:sequence M 1..1additionalPartyIdentificationValue M 1..1 Type: xsd:string


Guideline




additionalPartyIdentificationType M 1..1 Type: eanucc:AdditionalPartyIdentificationListTypeseller M 1..1 Type: eanucc:PartyIdentificationType

Description: Contains the identification of the party that is se lling the goods.Rule: See also: Component guide for Party Identification



xsd:sequence M 1..1additionalPartyIdentificationValue M 1..1 Type: xsd:stringadditionalPartyIdentificationType M 1..1 Type: eanucc:AdditionalPartyIdentificationListType

goodsRequirementsPlanner O 0..1 Type: eanucc:ContactType

Description: Contains the name or ID of the person or department responsible for theplanning at the buyer side.

xsd:sequence M 1..1communicationChannel O 0..unbounded Type: eanucc:CommunicationChannelType

communicationChannelCode M Type: eanucc:CommunicationChannelCodeListTypeUse: requiredCode/Description

* EMAIL* TELEFAX* TELEPHONE* WEBSITE

communicationNumber M Type: restriction (xsd:string)Length: 1 .. 70Use: required

personOrDepartmentName M 1..1 Type: eanucc:MultiDescriptionType

Description: Name of department or person to be contacted.xsd:sequence M 1..1

description M 1..unbounded Type: eanucc:DescriptionTypexsd:sequence M 1..1

language M 1..1 Type: eanucc:ISO639_CodeTypexsd:sequence M 1..1


Guideline




languageISOCode M 1..1 Type: restriction (xsd:string)Length: 1 .. 3

text M 1..1 Type: restriction (xsd:string)Length: 1 .. 70

goodsRequirementsItemLocationInformation M 1..unbounded Type: plan:GoodsRequirementsItemLocationInformationType

Description: Contains the Goods Requirements for given trade ite ms and locations forspecific time periods.

xsd:sequence M 1..1tradeItemIdentification M 1..1 Type: eanucc:TradeItemIdentificationType

Description: Contains the identification of the item for which t he goods requirementsare specified.

Rule: See also: Component guide for Trade Item Identificationxsd:sequence M 1..1

gtin M 1..1 Type: eanucc:GlobalTradeItemNumberTypePattern: \d{14}

additionalTradeItemIdentification O 0..unbounded Type: eanucc:AdditionalTradeItemIdentificationTypexsd:sequence M 1..1

additionalTradeItemIdentificationValue M 1..1 Type: restriction (xsd:string)Length: 1 .. 80

additionalTradeItemIdentificationType M 1..1 Type: eanucc:AdditionalTradeItemIdentificationListTypeshipTo M 1..1 Type: eanucc:PartyIdentificationType

Description: Contains the identification of the location whereto the required goods willbe delivered.

Rule: See also: Component guide for Party Identificationxsd:sequence M 1..1





Guideline




shipFrom O 0..1 Type: eanucc:PartyIdentificationType

Description: Contains the identification of the location wherefr om the required goodswill be delivered.





inventoryLocation O 0..1 Type: eanucc:PartyIdentificationType

Description: Identification of the physical place at the receivi ng side where the items areto be stored.

Rule: See also: Component guide for Party Identification

Used to report at a more detailed level of granulary, e.g. plant, building, silo, tank.xsd:sequence M 1..1




goodsRequirementsLineItem M 1..unbounded Type: plan:GoodsRequirementsLineItemType

Description: Contains the required quantities per time bucket.number M Type: restriction (xsd:nonNegativeInteger)

FractionDigits: 0 TotalDigits: 6Use: requiredInclusive: 0 ..

Description: Sequence number that identifies the line.timeBucketSize M Type: plan:BucketSizeTypeCodeListType

Use: required

Description: Contains a code describing the size of the requirem ents period.


Guideline




Code/Description* DAY* MONTH* QUARTER* UNSPECIFIED* WEEK* YEAR

xsd:sequence M 1..1requiredQuantity M 1..1 Type: eanucc:QuantityType

Description: The number of units required.xsd:sequence M 1..1

value M 1..1 Type: xsd:floatunitOfMeasure O 0..1 Type: eanucc:MeasurementUnitCodeType

xsd:sequence M 1..1measurementUnitCodeValue M 1..1 Type: restriction (xsd:string)

Length: 1 .. 3requirementsPeriod M 1..1 Type: eanucc:TimeOrDateTimePeriodType

Description: Contains the start and end dates and optionally sta rt and end times of thetime bucket.

xsd:choice M 1..1timePeriod M 1..1 Type: eanucc:TimePeriodType

beginDate M Type: xsd:dateUse: required

endDate M Type: xsd:dateUse: required

dateTimePeriod M 1..1 Type: eanucc:DateTimePeriodTypebeginDateTime M Type: xsd:dateTime

Use: requiredendDateTime M Type: xsd:dateTime

Use: requiredpurchaseConditions O 0..1 Type: eanucc:DocumentOrDocumentLineReferenceType

Description: Contains a reference to the commercial agreement un der which the goodsare supplied.

Rule: Also see the guide for Component: Document Or Document Line Reference.


Guideline




xsd:choice M 1..1documentLineReference M 1..1 Type: eanucc:DocumentLineReferenceType

number M Type: restriction (xsd:nonNegativeInteger)FractionDigits: 0 TotalDigits: 6Use: requiredInclusive: 0 ..

xsd:sequence M 1..1documentReference M 1..1 Type: eanucc:DocumentReferenceType

Rule: Optional in BMS, mandatory in GUSI MIG. If a reference to purchase conditions is made the

document reference number MUST be specified.creationDateTime O Type: xsd:dateTimexsd:sequence M 1..1


contentOwner M 1..1 Type: eanucc:PartyIdentificationTypexsd:sequence M 1..1





for

Transaction: Delivery Plan

based on message




Replenishment ProposalBMS Version: 2.1


Structure Chart




plan:replenishmentProposalM required creationDateTimeM required documentStatusM required replenishmentProposalDocumentTypeM required structureTypeM 1 .. 1 xsd:sequenceM 1 .. 1 documentStructureVersionM 1 .. 1 xsd:sequenceM 1 .. 1 versionIdentificationM 1 .. 1 xsd:sequenceM 1 .. 1 replenishmentProposalIdentificationM 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 sellerM 1 .. 1 xsd:sequenceM 1 .. 1 glnO 0 .. unbounded additionalPartyIdentificationM 1 .. 1 xsd:sequenceM 1 .. 1 additionalPartyIdentificationValueM 1 .. 1 additionalPartyIdentificationTypeM 1 .. 1 buyerM 1 .. 1 xsd:sequenceM 1 .. 1 glnO 0 .. unbounded additionalPartyIdentificationM 1 .. 1 xsd:sequenceM 1 .. 1 additionalPartyIdentificationValueM 1 .. 1 additionalPartyIdentificationTypeO 0 .. 1 materialRequirementsPlannerM 1 .. 1 xsd:sequenceO 0 .. unbounded communicationChannelM required communicationChannelCodeM required communicationNumberM 1 .. 1 personOrDepartmentNameM 1 .. 1 xsd:sequenceM 1 .. unbounded descriptionM 1 .. 1 xsd:sequenceM 1 .. 1 languageM 1 .. 1 xsd:sequenceM 1 .. 1 languageISOCodeM 1 .. 1 textM 1 .. unbounded replenishmentProposalItemLocationInformationM 1 .. 1 xsd:sequenceM 1 .. 1 tradeItemIdentification


Structure Chart




M 1 .. 1 xsd:sequenceM 1 .. 1 gtinO 0 .. unbounded additionalTradeItemIdentificationM 1 .. 1 xsd:sequenceM 1 .. 1 additionalTradeItemIdentificationValueM 1 .. 1 additionalTradeItemIdentificationTypeM 1 .. 1 shipToM 1 .. 1 xsd:sequenceM 1 .. 1 glnO 0 .. unbounded additionalPartyIdentificationM 1 .. 1 xsd:sequenceM 1 .. 1 additionalPartyIdentificationValueM 1 .. 1 additionalPartyIdentificationTypeO 0 .. 1 shipFromM 1 .. 1 xsd:sequenceM 1 .. 1 glnO 0 .. unbounded additionalPartyIdentificationM 1 .. 1 xsd:sequenceM 1 .. 1 additionalPartyIdentificationValueM 1 .. 1 additionalPartyIdentificationTypeO 0 .. 1 inventoryLocationM 1 .. 1 xsd:sequenceM 1 .. 1 glnO 0 .. unbounded additionalPartyIdentificationM 1 .. 1 xsd:sequenceM 1 .. 1 additionalPartyIdentificationValueM 1 .. 1 additionalPartyIdentificationTypeM 1 .. unbounded replenishmentProposalLineItemM required numberM required timeBucketSizeM 1 .. 1 xsd:sequenceM 1 .. 1 proposedQuantityM 1 .. 1 xsd:sequenceM 1 .. 1 valueO 0 .. 1 unitOfMeasureM 1 .. 1 xsd:sequenceM 1 .. 1 measurementUnitCodeValueM 1 .. 1 periodOfReplenishmentM 1 .. 1 xsd:choiceM 1 .. 1 timePeriodM required beginDateM required endDateM 1 .. 1 dateTimePeriodM required beginDateTimeM required endDateTimeM 1 .. 1 purchaseConditionsM 1 .. 1 xsd:choiceM 1 .. 1 documentLineReferenceM required numberM 1 .. 1 xsd:sequence


Structure Chart




M 1 .. 1 documentReferenceO creationDateTimeM 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 additionalPartyIdentificationTypeO 0 .. unbounded proposedQuantitySpecificationM 1 .. 1 xsd:sequenceM 1 .. 1 quantitySpecificationTypeM 1 .. 1 specificQuantityM 1 .. 1 xsd:sequenceM 1 .. 1 valueO 0 .. 1 unitOfMeasureM 1 .. 1 xsd:sequenceM 1 .. 1 measurementUnitCodeValue


Guideline




plan:replenishmentProposal M Type: plan:ReplenishmentProposalType

Description: Contains the seller delivery or production plan for the buyer for given tradeitems and locations for specific time periods.






* ORIGINAL* REPLACE

replenishmentProposalDocumentType M Type: plan:ReplenishmentProposalDocumentTypeListTypeUse: required

Description: Contains the type of replenishment plan; production or delivery.Rule: For this transaction use "DELIVERY_PLAN"Code/Description

* DELIVERY_PLANstructureType M Type: eanucc:StructureTypeListType

Use: required


informs only on the reporting logic applied by the sending party.

Please note that the contents of this field do not affect the structure of the message.Code/Description



xsd:sequence M 1..1


Guideline








xsd:sequence M 1..1replenishmentProposalIdentification M 1..1 Type: eanucc:EntityIdentificationType

Description: Contains the Replenishment Proposal number assigned by the contentowner.

xsd:sequence M 1..1uniqueCreatorIdentification M 1..1 Type: restriction (xsd:string)

Length: 1 .. 80contentOwner M 1..1 Type: eanucc:PartyIdentificationType






seller M 1..1 Type: eanucc:PartyIdentificationType




xsd:sequence M 1..1


Guideline










materialRequirementsPlanner O 0..1 Type: eanucc:ContactType



communicationChannelCode M Type: eanucc:CommunicationChannelCodeListTypeUse: required


personOrDepartmentName M 1..1 Type: eanucc:MultiDescriptionTypexsd:sequence M 1..1






Guideline




replenishmentProposalItemLocationInformation M 1..unbounded Type: plan:ReplenishmentProposalItemLocationInformationType

Description: Contains the replenishment plan for given trade ite ms and locations forspecific time periods.


Description: The identification of any item (product or service) upon which there is aneed to retrieve pre-defined information and that m ay be priced, ordered, orinvoiced at any point in any supply chain.















Guideline














replenishmentProposalLineItem M 1..unbounded Type: plan:ReplenishmentProposalLineItemType

Description: Contains the planned quantities per time bucket.number M Type: restriction (xsd:nonNegativeInteger)



Use: required

Description: Contains a code describing the size of the planning period.Code/Description

* DAY* MONTH* QUARTER* UNSPECIFIED* WEEK


Guideline




Code/Description* YEAR

xsd:sequence M 1..1proposedQuantity M 1..1 Type: eanucc:QuantityType

Description: The number of units planned to be replenished.xsd:sequence M 1..1



Length: 1 .. 3periodOfReplenishment M 1..1 Type: eanucc:TimeOrDateTimePeriodType







Use: requiredpurchaseConditions M 1..1 Type: eanucc:DocumentOrDocumentLineReferenceType


Rule: Also see the guide for Component: Document Or Document Line Reference.xsd:choice M 1..1

documentLineReference M 1..1 Type: eanucc:DocumentLineReferenceType


Guideline













proposedQuantitySpecification O 0..unbounded Type: eanucc:QuantitySpecificationType

Description: Contains additional quantity information for the ti me bucket. Example: InTransit, Produced.

xsd:sequence M 1..1quantitySpecificationType M 1..1 Type: eanucc:QuantityIdentificationListType

Code/Description* IN_TRANSIT* TO_BE_DESPATCHED

specificQuantity M 1..1 Type: eanucc:QuantityTypexsd:sequence M 1..1



Length: 1 .. 3


for

Transaction: Manufacturer Inventory & SupplierInventory

based on message




Inventory Activity Or Inventory StatusBMS Version: 2.1


Structure Chart




deliver:inventoryActivityOrInventoryStatusM required creationDateTimeM required documentStatusM 1 .. 1 xsd:sequenceM 1 .. 1 documentStructureVersionM 1 .. 1 xsd:sequenceM 1 .. 1 versionIdentificationM 1 .. 1 xsd:sequenceM 1 .. 1 inventoryActivityOrInventoryStatusIdentificationM 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 beginDateTimeM 1 .. 1 inventoryDocumentTypeM 1 .. 1 structureTypeM 1 .. 1 inventoryReportingPartyM 1 .. 1 xsd:sequenceM 1 .. 1 glnO 0 .. unbounded additionalPartyIdentificationM 1 .. 1 xsd:sequenceM 1 .. 1 additionalPartyIdentificationValueM 1 .. 1 additionalPartyIdentificationTypeM 1 .. 1 inventoryReportToPartyM 1 .. 1 xsd:sequenceM 1 .. 1 glnO 0 .. unbounded additionalPartyIdentificationM 1 .. 1 xsd:sequenceM 1 .. 1 additionalPartyIdentificationValueM 1 .. 1 additionalPartyIdentificationTypeM 1 .. unbounded inventoryItemLocationInformationM 1 .. 1 xsd:sequenceM 1 .. 1 tradeItemIdentificationM 1 .. 1 xsd:sequenceM 1 .. 1 gtinO 0 .. unbounded additionalTradeItemIdentificationM 1 .. 1 xsd:sequenceM 1 .. 1 additionalTradeItemIdentificationValueM 1 .. 1 additionalTradeItemIdentificationTypeM 1 .. 1 inventoryLocationM 1 .. 1 xsd:sequenceM 1 .. 1 glnO 0 .. unbounded additionalPartyIdentificationM 1 .. 1 xsd:sequence


Structure Chart




M 1 .. 1 additionalPartyIdentificationValueM 1 .. 1 additionalPartyIdentificationTypeM 1 .. 1 xsd:choiceM 1 .. unbounded inventoryStatusLineItemM required numberO inventoryDateTimeM 1 .. 1 xsd:sequenceO 0 .. 1 inventorySublocationM 1 .. 1 xsd:sequenceM 1 .. 1 glnO 0 .. unbounded additionalPartyIdentificationM 1 .. 1 xsd:sequenceM 1 .. 1 additionalPartyIdentificationValueM 1 .. 1 additionalPartyIdentificationTypeO 0 .. 1 logisticUnitIdentificationM 1 .. 1 xsd:sequenceM 1 .. 1 serialShipmentContainerCodeM 1 .. 1 xsd:sequenceM 1 .. 1 serialShippingContainerCodeO 0 .. unbounded additionalLogisticUnitIdentificationM 1 .. 1 xsd:sequenceM 1 .. 1 logisticUnitIdentificationM 1 .. unbounded inventoryStatusQuantitySpecificationM required inventoryStatusTypeM 1 .. 1 xsd:sequenceM 1 .. 1 quantityOfUnitsM 1 .. 1 xsd:sequenceM 1 .. 1 valueO 0 .. 1 unitOfMeasureM 1 .. 1 xsd:sequenceM 1 .. 1 measurementUnitCodeValueO 0 .. 1 transactionalItemDataM 1 .. 1 xsd:sequenceO 0 .. 1 batchNumberO 0 .. 1 bestBeforeDateO 0 .. 1 countryOfOriginM 1 .. 1 xsd:sequenceM 1 .. 1 countryISOCodeO 0 .. 1 itemExpirationDateO 0 .. 1 lotNumberO 0 .. 1 productionDateO 0 .. 1 productQualityIndicationM 1 .. 1 xsd:sequenceM 1 .. 1 valueO 0 .. 1 unitOfMeasureM 1 .. 1 xsd:sequenceM 1 .. 1 measurementUnitCodeValue

Transaction: Manufacturer Inventory & Supplier Inven tory

Guideline


Version: Issue date: 30-9-2007 Page: 26Prepared by GS1 Netherlands


deliver:inventoryActivityOrInventoryStatus M Type: deliver:InventoryActivityOrInventoryStatusType

Description: Provides the Inventory Activity or Inventory Status information.Rule: Material Supplier Inventory versus Manufacturer Inventory refers to the direction of the

information flow, not to the ownership of inventory.creationDateTime M Type: xsd:dateTime

Use: required





* ORIGINAL* REPLACE

xsd:sequence M 1..1documentStructureVersion M 1..1 Type: eanucc:VersionType




xsd:sequence M 1..1inventoryActivityOrInventoryStatusIdentification M 1..1 Type: eanucc:EntityIdentificationType

Description: Contains the Inventory Activity or Inventory Status number assigned by thecontent owner.


Length: 1 .. 80


Guideline










beginDateTime M 1..1 Type: xsd:dateTime

Description: Represents the overall begin date and time for the inventory status for allthe line items.

inventoryDocumentType M 1..1 Type: deliver:InventoryDocumentTypeListType

Description: Inventory Document type describes the type of inven tory informationcontained in the document: Inventory Activity infor mation or InventoryStatus information.

Rule: in the UIM guide only Inventory Status information is allowed.Code/Description

* INVENTORY_STATUSstructureType M 1..1 Type: eanucc:StructureTypeListType

Description: The structure format of the Inventory Activity Or I nventory Status message.Rule: Please note that the contents of this field do not affect the structure of the message.Code/Description



inventoryReportingParty M 1..1 Type: eanucc:PartyIdentificationType

Description: The identification of the party reporting about the inventory.Rule: See also: Component guide for Party Identification

xsd:sequence M 1..1


Guideline







inventoryReportToParty M 1..1 Type: eanucc:PartyIdentificationType

Description: The identification of the party to which the invent ory is being reported.Rule: See also: Component guide for Party Identification




inventoryItemLocationInformation M 1..unbounded Type: deliver:InventoryItemLocationInformationType

Description: Location where the items are stored.xsd:sequence M 1..1

tradeItemIdentification M 1..1 Type: eanucc:TradeItemIdentificationType

Description: Identification of the inventory item.Rule: See also: Component guide for Trade Item Identification

xsd:sequence M 1..1gtin M 1..1 Type: eanucc:GlobalTradeItemNumberType

Pattern: \d{14}additionalTradeItemIdentification O 0..unbounded Type: eanucc:AdditionalTradeItemIdentificationType

xsd:sequence M 1..1additionalTradeItemIdentificationValue M 1..1 Type: restriction (xsd:string)

Length: 1 .. 80additionalTradeItemIdentificationType M 1..1 Type: eanucc:AdditionalTradeItemIdentificationListType

inventoryLocation M 1..1 Type: eanucc:PartyIdentificationType

Description: The party identification for the place where items are stored.Rule: See also: Component guide for Party Identification


Guideline







xsd:choice M 1..1 Rule: IMPORTANT: The element inventoryActivityLineItem has been omitted since only

inventoryStatusLineItems are used in the UIM Guide.inventoryStatusLineItem M 1..unbounded Type: eanucc:InventoryStatusLineItemType

Description: Information specifying the inventory status of a sp ecific trade item at aspecific location at a specific point in time.


Description: Sequence number that identifies the line.inventoryDateTime O Type: xsd:dateTime

Description: Date and time the inventory for this line item was assessed. If this is notprovided the beginDateTime provided at the business document levelrepresents the inventoryDateTime.

xsd:sequence M 1..1inventorySublocation O 0..1 Type: eanucc:PartyIdentificationType

Description: Detailed identification of the location at which th e goods are stored.Rule: See also: Component guide for Party Identification





Guideline




logisticUnitIdentification O 0..1 Type: eanucc:LogisticUnitIdentificationType

Description: Detailed identification of the logistic unit that c ontains the goods.Rule: See also: Component guide for Logistic Unit Identification

xsd:sequence M 1..1serialShipmentContainerCode M 1..1 Type: eanucc:SSCCType

xsd:sequence M 1..1serialShippingContainerCode M 1..1 Type: restriction (xsd:string)

Pattern: \d{18}additionalLogisticUnitIdentification O 0..unbounded Type: eanucc:AdditionalLogisticUnitIdentificationType

xsd:sequence M 1..1logisticUnitIdentification M 1..1 Type: xsd:string

inventoryStatusQuantitySpecification M 1..unbounded Type: eanucc:InventoryStatusQuantitySpecificationType

Description: Information about the stored goods per inventory st atus.inventoryStatusType M Type: eanucc:InventoryStatusListType

Use: required

Description: Code specifying the status of the goods.Code/Description

* MAXIMUM_STOCK Maximum stock target quantity in storage location in order totrigger action if this is exceeded

* MINIMUM_STOCK Minimum stock target quantity in storage location in order totrigger actions if this is exceeded. To share dynamically so asto allow dynamic adjustment of safety stock.

* ON_HAND The total quantity of all inventory directly available for sales orproduction.

* ON_HOLD The total quantity of non-shippable or non-saleable inventoryin a warehouse or warehouse location. This status istemporary. This is product that has quality questioned as anexception, i.e. not regular inspection but due to an exceptionalevent such as infestation or damage to warehouse.

* QUARANTINED Status of product that has been produced, but has not yetcleared quality /performance testing and is therefore notavailable for transport or sale. I.e. this stock has beenreceived at manufacturer location and is going through aregular process of Quality Checking before being released asON_HAND.


Guideline




xsd:sequence M 1..1quantityOfUnits M 1..1 Type: eanucc:QuantityType

Description: Quantity of goods with the specified status.xsd:sequence M 1..1



Length: 1 .. 3transactionalItemData O 0..1 Type: eanucc:TransactionalItemDataType

Description: Extended attributes describing the characteristics and history of the goods.xsd:sequence M 1..1

batchNumber O 0..1 Type: xsd:string

Description: A batch unites products or items that have undergon e or are groupedtogether to undergo the same transformation process , not necessarily aproduction process.

Rule: Number assigned by the seller of the goods (inventory reporting party)bestBeforeDate O 0..1 Type: xsd:date

Description: Ideal consumption or best effective use date of a p roduct.countryOfOrigin O 0..1 Type: eanucc:ISO3166_1CodeType

Description: Country from which the goods are supplied.xsd:sequence M 1..1

countryISOCode M 1..1 Type: restriction (xsd:string)Length: 1 .. 3

itemExpirationDate O 0..1 Type: xsd:date

Description: The maximum durability of an item CCYY-MM-DD.lotNumber O 0..1 Type: xsd:string

Description: A lot unites product or items that have undergone t he same productionprocess. The lot code is the number assigned to an given (unique)production lot. It links the product or item with a ll relevant informationrelated to its production.

Rule: The vendor lot number as defined by the manufacturer of the sold goods.


Guideline




productionDate O 0..1 Type: xsd:date

Description: The date that the product was produced.productQualityIndication O 0..1 Type: eanucc:QuantityType

Description: Number used to indicate the quality of a specific b atch of products.Optionally a Unit of Measure can be specified, whic h means that thenumber is expressed per unit. Example: 100 GRM mean s 100 per gram.

xsd:sequence M 1..1value M 1..1 Type: xsd:floatunitOfMeasure O 0..1 Type: eanucc:MeasurementUnitCodeType


Length: 1 .. 3


for

Transaction: Net Requirements

based on message


Issue date: 30-9-2007Version:


Goods RequirementsBMS Version:


Structure Chart




plan:goodsRequirementsM required creationDateTimeM required documentStatusM required goodsRequirementsTypeM required structureTypeM 1 .. 1 xsd:sequenceM 1 .. 1 documentStructureVersionM 1 .. 1 xsd:sequenceM 1 .. 1 versionIdentificationM 1 .. 1 xsd:sequenceM 1 .. 1 goodsRequirementsIdentificationM 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 buyerM 1 .. 1 xsd:sequenceM 1 .. 1 glnO 0 .. unbounded additionalPartyIdentificationM 1 .. 1 xsd:sequenceM 1 .. 1 additionalPartyIdentificationValueM 1 .. 1 additionalPartyIdentificationTypeM 1 .. 1 sellerM 1 .. 1 xsd:sequenceM 1 .. 1 glnO 0 .. unbounded additionalPartyIdentificationM 1 .. 1 xsd:sequenceM 1 .. 1 additionalPartyIdentificationValueM 1 .. 1 additionalPartyIdentificationTypeO 0 .. 1 goodsRequirementsPlannerM 1 .. 1 xsd:sequenceO 0 .. unbounded communicationChannelM required communicationChannelCodeM required communicationNumberM 1 .. 1 personOrDepartmentNameM 1 .. 1 xsd:sequenceM 1 .. unbounded descriptionM 1 .. 1 xsd:sequenceM 1 .. 1 languageM 1 .. 1 xsd:sequenceM 1 .. 1 languageISOCodeM 1 .. 1 textM 1 .. unbounded goodsRequirementsItemLocationInformationM 1 .. 1 xsd:sequenceM 1 .. 1 tradeItemIdentification


Structure Chart




M 1 .. 1 xsd:sequenceM 1 .. 1 gtinO 0 .. unbounded additionalTradeItemIdentificationM 1 .. 1 xsd:sequenceM 1 .. 1 additionalTradeItemIdentificationValueM 1 .. 1 additionalTradeItemIdentificationTypeM 1 .. 1 shipToM 1 .. 1 xsd:sequenceM 1 .. 1 glnO 0 .. unbounded additionalPartyIdentificationM 1 .. 1 xsd:sequenceM 1 .. 1 additionalPartyIdentificationValueM 1 .. 1 additionalPartyIdentificationTypeO 0 .. 1 shipFromM 1 .. 1 xsd:sequenceM 1 .. 1 glnO 0 .. unbounded additionalPartyIdentificationM 1 .. 1 xsd:sequenceM 1 .. 1 additionalPartyIdentificationValueM 1 .. 1 additionalPartyIdentificationTypeO 0 .. 1 inventoryLocationM 1 .. 1 xsd:sequenceM 1 .. 1 glnO 0 .. unbounded additionalPartyIdentificationM 1 .. 1 xsd:sequenceM 1 .. 1 additionalPartyIdentificationValueM 1 .. 1 additionalPartyIdentificationTypeM 1 .. unbounded goodsRequirementsLineItemM required numberM required timeBucketSizeM 1 .. 1 xsd:sequenceM 1 .. 1 requiredQuantityM 1 .. 1 xsd:sequenceM 1 .. 1 valueO 0 .. 1 unitOfMeasureM 1 .. 1 xsd:sequenceM 1 .. 1 measurementUnitCodeValueM 1 .. 1 requirementsPeriodM 1 .. 1 xsd:choiceM 1 .. 1 timePeriodM required beginDateM required endDateM 1 .. 1 dateTimePeriodM required beginDateTimeM required endDateTimeO 0 .. 1 purchaseConditionsM 1 .. 1 xsd:choiceM 1 .. 1 documentLineReferenceM required numberM 1 .. 1 xsd:sequence


Structure Chart




M 1 .. 1 documentReferenceO creationDateTimeM 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 additionalPartyIdentificationTypeO 0 .. 1 requiredQuantitySpecificationM 1 .. 1 xsd:sequenceM 1 .. 1 quantitySpecificationTypeM 1 .. 1 specificQuantityM 1 .. 1 xsd:sequenceM 1 .. 1 valueO 0 .. 1 unitOfMeasureM 1 .. 1 xsd:sequenceM 1 .. 1 measurementUnitCodeValue


Guideline




plan:goodsRequirements M Type: plan:GoodsRequirementsType

Description: Contains the Goods Requirements from the buyer to t he seller for giventrade items and locations for specific time periods .






* ORIGINAL* REPLACE

goodsRequirementsType M Type: plan:GoodsRequirementsTypeListTypeUse: required

Description: Specifies the origin and type of the demand.Rule: Use NET_REQUIREMENTS.Code/Description

* NET_REQUIREMENTSstructureType M Type: eanucc:StructureTypeListType

Use: required






xsd:sequence M 1..1


Guideline








xsd:sequence M 1..1goodsRequirementsIdentification M 1..1 Type: eanucc:EntityIdentificationType

Description: Contains the Goods Requirements number assigned by the content owner.xsd:sequence M 1..1












xsd:sequence M 1..1additionalPartyIdentificationValue M 1..1 Type: xsd:string


Guideline




additionalPartyIdentificationType M 1..1 Type: eanucc:AdditionalPartyIdentificationListTypeseller M 1..1 Type: eanucc:PartyIdentificationType





goodsRequirementsPlanner O 0..1 Type: eanucc:ContactType











Guideline






goodsRequirementsItemLocationInformation M 1..unbounded Type: plan:GoodsRequirementsItemLocationInformationType

Description: Contains the Goods Requirements for given trade ite ms and locations forspecific time periods.


Description: Contains the identification of the item for which t he goods requirementsare specified.












Guideline

















goodsRequirementsLineItem M 1..unbounded Type: plan:GoodsRequirementsLineItemType




Use: required

Description: Contains a code describing the size of the requirem ents period.


Guideline




Code/Description* DAY* MONTH* QUARTER* UNSPECIFIED* WEEK* YEAR












Use: requiredpurchaseConditions O 0..1 Type: eanucc:DocumentOrDocumentLineReferenceType


Rule: Also see the guide for Component: Document Or Document Line Reference.


Guideline














requiredQuantitySpecification O 0..1 Type: eanucc:QuantitySpecificationType

Description: Contains the cumulative quantity already received f or the current timebucket.

xsd:sequence M 1..1quantitySpecificationType M 1..1 Type: eanucc:QuantityIdentificationListType

Code/Description* RECEIVED

specificQuantity M 1..1 Type: eanucc:QuantityTypexsd:sequence M 1..1


xsd:sequence M 1..1


Guideline




measurementUnitCodeValue M 1..1 Type: restriction (xsd:string)Length: 1 .. 3


for

Transaction: Net Requirements Confirmation

based on message




Goods Requirements ResponseBMS Version: 2.1


Structure Chart




plan:goodsRequirementsResponseM required creationDateTimeM required documentStatusM 1 .. 1 xsd:sequenceM 1 .. 1 documentStructureVersionM 1 .. 1 xsd:sequenceM 1 .. 1 versionIdentificationM 1 .. 1 xsd:sequenceM 1 .. 1 goodsRequirementsResponseIdentificationM 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 goodsRequirementsO creationDateTimeM 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 buyerM 1 .. 1 xsd:sequenceM 1 .. 1 glnO 0 .. unbounded additionalPartyIdentificationM 1 .. 1 xsd:sequenceM 1 .. 1 additionalPartyIdentificationValueM 1 .. 1 additionalPartyIdentificationTypeM 1 .. 1 sellerM 1 .. 1 xsd:sequenceM 1 .. 1 glnO 0 .. unbounded additionalPartyIdentificationM 1 .. 1 xsd:sequenceM 1 .. 1 additionalPartyIdentificationValueM 1 .. 1 additionalPartyIdentificationType


Guideline




plan:goodsRequirementsResponse M Type: plan:GoodsRequirementsResponseType

Description: Contains the response to the goods requirements mes sage.creationDateTime M Type: xsd:dateTime

Use: required





* ORIGINAL* REPLACE





xsd:sequence M 1..1goodsRequirementsResponseIdentification M 1..1 Type: eanucc:EntityIdentificationType

Description: Contains the Goods Requirements Response number ass igned by thecontent owner.




Usually the party that is referenced as sender of the message.


Guideline







goodsRequirements M 1..1 Type: eanucc:DocumentReferenceType

Description: Contains the reference to the goods requirements me ssage.creationDateTime O Type: xsd:dateTimexsd:sequence M 1..1














Guideline








for

Transaction: Purchase Order

based on message




Multi Shipment OrderBMS Version: 2.1.1


Structure Chart




order:multiShipmentOrderO lastUpdateDateM required creationDateTimeM required documentStatusM 1 .. 1 xsd:sequenceM 1 .. 1 documentStructureVersionM 1 .. 1 xsd:sequenceM 1 .. 1 versionIdentificationM 1 .. 1 xsd:sequenceM 1 .. 1 orderIdentificationM 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 orderPartyInformationM 1 .. 1 xsd:sequenceM 1 .. 1 sellerM 1 .. 1 xsd:sequenceM 1 .. 1 glnO 0 .. unbounded additionalPartyIdentificationM 1 .. 1 xsd:sequenceM 1 .. 1 additionalPartyIdentificationValueM 1 .. 1 additionalPartyIdentificationTypeO 0 .. 1 billToM 1 .. 1 xsd:sequenceM 1 .. 1 glnO 0 .. unbounded additionalPartyIdentificationM 1 .. 1 xsd:sequenceM 1 .. 1 additionalPartyIdentificationValueM 1 .. 1 additionalPartyIdentificationTypeM 1 .. 1 buyerM 1 .. 1 xsd:sequenceM 1 .. 1 glnO 0 .. unbounded additionalPartyIdentificationM 1 .. 1 xsd:sequenceM 1 .. 1 additionalPartyIdentificationValueM 1 .. 1 additionalPartyIdentificationTypeO 0 .. 1 goodsRequirementsPlannerM 1 .. 1 xsd:sequenceO 0 .. unbounded communicationChannelM required communicationChannelCodeM required communicationNumberM 1 .. 1 personOrDepartmentNameM 1 .. 1 xsd:sequenceM description


Structure Chart




1 .. unboundedM 1 .. 1 xsd:sequenceM 1 .. 1 languageM 1 .. 1 xsd:sequenceM 1 .. 1 languageISOCodeM 1 .. 1 textM 1 .. 1 orderLogisticalInformationM 1 .. 1 xsd:sequenceM 1 .. 1 xsd:choiceM 1 .. 1 shipFromLogisticsM 1 .. 1 xsd:sequenceM 1 .. 1 shipFromM 1 .. 1 xsd:sequenceM 1 .. 1 glnO 0 .. unbounded additionalPartyIdentificationM 1 .. 1 xsd:sequenceM 1 .. 1 additionalPartyIdentificationValueM 1 .. 1 additionalPartyIdentificationTypeM 1 .. 1 orderLogisticalDateGroupM 1 .. 1 xsd:choiceM 1 .. 1 requestedDeliveryDateRangeM 1 .. 1 xsd:sequenceM 1 .. 1 earliestDateM 1 .. 1 latestDateO 0 .. 1 earliestTimeO 0 .. 1 latestTimeO 0 .. 1 currencyExchangeRateInformationM 1 .. 1 xsd:sequenceM 1 .. 1 currencyConversionFromM 1 .. 1 xsd:sequenceM 1 .. 1 currencyISOCodeM 1 .. 1 currencyConversionToM 1 .. 1 xsd:sequenceM 1 .. 1 currencyISOCodeM 1 .. 1 exchangeRateO 0 .. 1 exchangeRateDateO 0 .. unbounded paymentTermsM required paymentTermsTypeM required paymentTermsEventM 1 .. 1 xsd:sequenceO 0 .. unbounded discountPaymentM required discountTypeM 1 .. 1 xsd:sequenceO 0 .. 1 discountDescriptionM 1 .. 1 xsd:sequenceM 1 .. unbounded descriptionM 1 .. 1 xsd:sequenceM 1 .. 1 languageM 1 .. 1 xsd:sequenceM


Structure Chart




1 .. 1 languageISOCodeM 1 .. 1 textM 1 .. 1 paymentTimePeriodM 1 .. 1 xsd:choiceM 1 .. 1 timePeriodDueM required timePeriodM 1 .. 1 xsd:sequenceM 1 .. 1 valueM 1 .. 1 dayOfMonthDueM 1 .. 1 dateO 0 .. 1 discountAmountM 1 .. 1 xsd:sequenceM 1 .. 1 currencyCodeM 1 .. 1 xsd:sequenceM 1 .. 1 currencyISOCodeM 1 .. 1 monetaryAmountO 0 .. 1 discountPercentM 1 .. unbounded multiShipmentOrderLineItemM required numberM 1 .. 1 xsd:sequenceM 1 .. 1 requestedQuantityM 1 .. 1 xsd:sequenceM 1 .. 1 valueO 0 .. 1 unitOfMeasureM 1 .. 1 xsd:sequenceM 1 .. 1 measurementUnitCodeValueO 0 .. 1 shipmentTransportationInformationO transportationMethodTypeM 1 .. 1 xsd:sequenceO 0 .. 1 carrierM 1 .. 1 xsd:sequenceM 1 .. 1 glnO 0 .. unbounded additionalPartyIdentificationM 1 .. 1 xsd:sequenceM 1 .. 1 additionalPartyIdentificationValueM 1 .. 1 additionalPartyIdentificationTypeO 0 .. 1 netPriceM 1 .. 1 xsd:sequenceM 1 .. unbounded amountM 1 .. 1 xsd:sequenceM 1 .. 1 currencyCodeM 1 .. 1 xsd:sequenceM 1 .. 1 currencyISOCodeM 1 .. 1 monetaryAmountO 0 .. 1 netAmountM 1 .. 1 xsd:sequenceM 1 .. unbounded amountM 1 .. 1 xsd:sequenceM 1 .. 1 currencyCodeM xsd:sequence


Structure Chart




1 .. 1M 1 .. 1 currencyISOCodeM 1 .. 1 monetaryAmountM 1 .. 1 tradeItemIdentificationM 1 .. 1 xsd:sequenceM 1 .. 1 gtinO 0 .. unbounded additionalTradeItemIdentificationM 1 .. 1 xsd:sequenceM 1 .. 1 additionalTradeItemIdentificationValueM 1 .. 1 additionalTradeItemIdentificationTypeM 1 .. 1 xsd:sequenceO 0 .. 1 materialSpecificationM 1 .. 1 xsd:sequenceM 1 .. 1 referenceDateTimeM 1 .. 1 referenceIdentificationO 0 .. 1 purchaseConditionsM 1 .. 1 xsd:choiceM 1 .. 1 documentLineReferenceM required numberM 1 .. 1 xsd:sequenceM 1 .. 1 documentReferenceO creationDateTimeM 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 additionalPartyIdentificationTypeO 0 .. unbounded shipmentDetailM 1 .. 1 xsd:sequenceM 1 .. 1 requestedQuantityM 1 .. 1 xsd:sequenceM 1 .. 1 valueO 0 .. 1 unitOfMeasureM 1 .. 1 xsd:sequenceM 1 .. 1 measurementUnitCodeValueM 1 .. 1 shipToM 1 .. 1 xsd:sequenceM 1 .. 1 glnO 0 .. unbounded additionalPartyIdentificationM 1 .. 1 xsd:sequenceM 1 .. 1 additionalPartyIdentificationValueM 1 .. 1 additionalPartyIdentificationTypeO 0 .. 1 inventoryLocationM 1 .. 1 xsd:sequenceM 1 .. 1 glnO 0 .. unbounded additionalPartyIdentification


Structure Chart




M 1 .. 1 xsd:sequenceM 1 .. 1 additionalPartyIdentificationValueM 1 .. 1 additionalPartyIdentificationTypeO 0 .. 1 orderLogisticalDateGroupM 1 .. 1 xsd:choiceM 1 .. 1 requestedDeliveryDateRangeM 1 .. 1 xsd:sequenceM 1 .. 1 earliestDateM 1 .. 1 latestDateO 0 .. 1 earliestTimeO 0 .. 1 latestTime


Guideline




order:multiShipmentOrder M Type: order:MultiShipmentOrderType

Description: The Multi Shipment Order provides the ability for a buyer to order variablequanti-ties of trade items/services shipped from an d to multiple locationsusing one business message

lastUpdateDate O Type: xsd:date

Description: The last update date for the specific document.Rule: Mandatory in case of an order change. In this case in the creationDate the original order

date must be given, and in the lastUpdateDate the date of the order change must be

supplied.creationDateTime M Type: xsd:dateTime

Use: required





* ORIGINAL* REPLACE



Rule: Optional in BMS, mandatory in MIG. The document structure version contains the version of

the release version of the BMS.xsd:sequence M 1..1

versionIdentification M 1..1 Type: xsd:stringRule: Currently value '2.1.1' should be used.

xsd:sequence M 1..1orderIdentification M 1..1 Type: eanucc:EntityIdentificationType

Description: Contains the Multi Shipment Order number assigned b y the content owner.


Guideline











orderPartyInformation M 1..1 Type: order:OrderPartyInformationType

Description: Contains the information related with the parties i nvolved in the orderprocess.

xsd:sequence M 1..1seller M 1..1 Type: eanucc:PartyIdentificationType

Description: Identifies the party which sells products or servic es to a buyer.Rule: See also: Component guide for Party Identification




billTo O 0..1 Type: eanucc:PartyIdentificationType

Description: Identifies the party which receives invoice.Rule: See also: Component guide for Party Identification


Pattern: \d{13}


Guideline







Description: Identifies the party to which products or services is sold.Rule: See also: Component guide for Party Identification




goodsRequirementsPlanner O 0..1 Type: eanucc:ContactTypexsd:sequence M 1..1

communicationChannel O 0..unbounded Type: eanucc:CommunicationChannelTypecommunicationChannelCode M Type: eanucc:CommunicationChannelCodeListType

Use: requiredCode/Description

* EMAIL* TELEFAX* TELEPHONE








Guideline





orderLogisticalInformation M 1..1 Type: order:OrderLogisticalInformationType

Description: Contains the information related with the dates and destinations of thegoods or services.

xsd:sequence M 1..1xsd:choice M 1..1

shipFromLogistics M 1..1 Type: order:ShipFromLogisticsType

Description: Allows the identification of shipping details where the goods or servicesmust be shipped from.

xsd:sequence M 1..1shipFrom M 1..1 Type: eanucc:PartyIdentificationType

Description: Identifies the origin location where the goods will be shipped.Rule: See also: Component guide for Party Identification

If no ship from location is available use the seller identifiation.xsd:sequence M 1..1




orderLogisticalDateGroup M 1..1 Type: order:OrderLogisticalDateGroupType

Description: Contains the choices to select various types of dat es or date rangesassociated to the order.

xsd:choice M 1..1requestedDeliveryDateRange M 1..1 Type: order:LogisticalDateRangeType

Description: Provides the earliest and latest date ranges and th e optional times onwhich the goods are requested to be delivered.

Rule: Altough the expectation is that the delivery date will be included at line level, this is a

mandatory element in the standard.xsd:sequence M 1..1

earliestDate M 1..1 Type: xsd:date


Guideline




latestDate M 1..1 Type: xsd:dateearliestTime O 0..1 Type: xsd:timelatestTime O 0..1 Type: xsd:time

currencyExchangeRateInformation O 0..1 Type: eanucc:CurrencyExchangeRateInformationType

Description: Rate at which one currency may be converted into an other. Generally, oneunit of the home currency is expressed in terms of another currency. Forexample, a North American bank may quote the exchan ge rate between thedollar and the Euro as the number of dollars needed to buy one Euro.

Rule: Mandatory in case of self billing.xsd:sequence M 1..1

currencyConversionFrom M 1..1 Type: eanucc:ISO4217_CodeTypexsd:sequence M 1..1

currencyISOCode M 1..1 Type: restriction (xsd:string)Length: 1 .. 3

currencyConversionTo M 1..1 Type: eanucc:ISO4217_CodeTypexsd:sequence M 1..1


exchangeRate M 1..1 Type: xsd:floatexchangeRateDate O 0..1 Type: xsd:date

paymentTerms O 0..unbounded Type: eanucc:PaymentTermsType

Description: Contains the information related with the parties i nvolved in the orderprocess.

paymentTermsType M Type: eanucc:PaymentTermsTypeListTypeUse: requiredCode/Description

* BASIC_DISCOUNT_OFFERED* BASIC_NET* DEFERRED* DISCOUNT* DISCOUNT_AFTER_DEDUCTING_FREI

GHT* DISCOUNT_NOT_APPLICABLE* ELECTIVE* END_OF_MONTH


Guideline




Code/Description* EXTENDED* FIXED_DATE* INSTANT* MIXED* NO_CHARGE* PAYMENT_BY_INSTALLMENT* PREVIOUSLY_AGREED_UPON* PROXIMO* VALUTA

paymentTermsEvent M Type: eanucc:PaymentTermsEventListTypeUse: requiredCode/Description

* AFTER_DATE_OF_DELIVERY* ANTICIPATED_DELIVERY_DATE* DATE_INVOICE_RECEIVED* DATE_OF_DELIVERY_TO_SITE* DATE_OF_INVOICE* DATE_OF_SHIPMENT_AS_EVIDENCE

D_BY_TRANSPORT_DOCUMENTS* EFFECTIVE_DATE* INVOICE_TRANSMISSION_DATE* RECEIPT_OF_GOODS

xsd:sequence M 1..1discountPayment O 0..unbounded Type: eanucc:DiscountPaymentType

Description: This class is used to describe the amount for a dis counted payment. Zeroor more discounts may be specified using this class . The dis-count amountis expressed as a percent and is based on the numbe r of days by which thepayment must be made to earn the discount. For each discount, a timeperiod is required to specify the percent discount earned.

discountType M Type: restriction (xsd:string)Length: 1 .. 80Use: required

Description: A code that specifies the type of payment discount.xsd:sequence M 1..1


Guideline




discountDescription O 0..1 Type: eanucc:MultiDescriptionType

Description: A text field describing the discount.xsd:sequence M 1..1





paymentTimePeriod M 1..1 Type: eanucc:PaymentTimePeriodTypexsd:choice M 1..1

timePeriodDue M 1..1 Type: eanucc:TimePeriodDueType

Description: The payment time period in which the payment become s due is expressedas a numeric value.

timePeriod M Type: eanucc:TimePeriodListTypeUse: required

xsd:sequence M 1..1value M 1..1 Type: xsd:nonNegativeInteger

FractionDigits: 0 TotalDigits:Inclusive: 0 ..

dayOfMonthDue M 1..1 Type: xsd:integerFractionDigits: 0 TotalDigits:

Description: The time at which a payment is due, expressed as a day of the month.date M 1..1 Type: xsd:date

Description: The time at which a payment is due, expressed as a date.discountAmount O 0..1 Type: eanucc:AmountType

xsd:sequence M 1..1currencyCode M 1..1 Type: eanucc:ISO4217_CodeType

xsd:sequence M 1..1currencyISOCode M 1..1 Type: restriction (xsd:string)

Length: 1 .. 3monetaryAmount M 1..1 Type: xsd:float


Guideline




discountPercent O 0..1 Type: eanucc:PercentageTypeFractionDigits: 2 TotalDigits: 5

multiShipmentOrderLineItem M 1..unbounded Type: order:MultiShipmentOrderLineItemType

Description: Specify the information related to each line item. Multi Shipment Order willcontain one or more line items.


Description: Sequence number that identifies the line.xsd:sequence M 1..1

requestedQuantity M 1..1 Type: eanucc:QuantityType

Description: The quantity which has been requested.xsd:sequence M 1..1



Length: 1 .. 3shipmentTransportationInformation O 0..1 Type: eanucc:ShipmentTransportationInformationType

Description: Contains the identification of the carrier and mode associated with thetransportation of the goods or services

transportationMethodType O Type: eanucc:TransportationMethodTypeCodeListType

Description: Code specifying the name of a mode of transport.Code/Description

* AIR* INLAND_WATERWAY* LESS_THAN_TRUCK_LOAD* MOTOR_TRUCKLOAD* OCEAN* RAIL

xsd:sequence M 1..1


Guideline




carrier O 0..1 Type: eanucc:PartyIdentificationType

Description: Allows to specify the carrier to be used for the sh ipment.Rule: See also: Component guide for Party Identification




netPrice O 0..1 Type: eanucc:MultiAmountType

Description: Identifies the net price of one trade item.xsd:sequence M 1..1

amount M 1..unbounded Type: eanucc:AmountTypexsd:sequence M 1..1

currencyCode M 1..1 Type: eanucc:ISO4217_CodeTypexsd:sequence M 1..1


monetaryAmount M 1..1 Type: xsd:floatnetAmount O 0..1 Type: eanucc:MultiAmountType

Description: Identifies the total net line amount: the requested quantity multiplied by thenet price.

xsd:sequence M 1..1amount M 1..unbounded Type: eanucc:AmountType

xsd:sequence M 1..1currencyCode M 1..1 Type: eanucc:ISO4217_CodeType

xsd:sequence M 1..1currencyISOCode M 1..1 Type: restriction (xsd:string)

Length: 1 .. 3monetaryAmount M 1..1 Type: xsd:float


Guideline




tradeItemIdentification M 1..1 Type: eanucc:TradeItemIdentificationType

Description: Identifies the Trade Item with the Global Trade Ite m Number associated tothe Simple Order Line Item.





additionalTradeItemIdentificationType M 1..1 Type: eanucc:AdditionalTradeItemIdentificationListTypexsd:sequence M 1..1

materialSpecification O 0..1 Type: eanucc:ReferenceType

Description: A reference to a material specification.Rule: Also see the guide for Component: Detail Level Reference.

xsd:sequence M 1..1referenceDateTime M 1..1 Type: xsd:dateTimereferenceIdentification M 1..1 Type: restriction (xsd:string)

Length: 1 .. 80purchaseConditions O 0..1 Type: eanucc:DocumentOrDocumentLineReferenceType

Description: A reference to the purchase conditions.Rule: Also see the guide for Component: Document Or Document Line Reference.





document reference number MUST be specified.creationDateTime O Type: xsd:dateTime


Guideline









shipmentDetail O 0..unbounded Type: order:ShipmentDetailType

Description: Allows the identification of various shipping detai ls by line item.xsd:sequence M 1..1

requestedQuantity M 1..1 Type: eanucc:QuantityTypexsd:sequence M 1..1



Length: 1 .. 3shipTo M 1..1 Type: eanucc:PartyIdentificationType

Description: The location destination to which goods will be shi pped.Rule: See also: Component guide for Party Identification

Optional in BMS, mandatory in MIG. If shipment detail is used the Ship To location is

mandatory.xsd:sequence M 1..1





Guideline





Description: The location where the goods are stored.Rule: See also: Component guide for Party Identification




orderLogisticalDateGroup O 0..1 Type: order:OrderLogisticalDateGroupType

Description: The date/time on which the goods are requested, to be delivered, pickup orshipped.

xsd:choice M 1..1requestedDeliveryDateRange M 1..1 Type: order:LogisticalDateRangeType

Description: Provides the earliest and latest date ranges and th e optional times onwhich the goods are requested to be delivered.

xsd:sequence M 1..1earliestDate M 1..1 Type: xsd:datelatestDate M 1..1 Type: xsd:dateearliestTime O 0..1 Type: xsd:timelatestTime O 0..1 Type: xsd:time


for

Transaction: Purchase Order Confirmation

based on message




Order ResponseBMS Version: 2.1


Structure Chart




order:orderResponseM required creationDateTimeM required responseStatusTypeM 1 .. 1 xsd:sequenceM 1 .. 1 responseIdentificationM 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 responseToOriginalDocumentM required referenceDocumentTypeM required referenceIdentificationO referenceDateTimeM 1 .. 1 xsd:sequenceM 1 .. 1 buyerM 1 .. 1 xsd:sequenceM 1 .. 1 glnO 0 .. unbounded additionalPartyIdentificationM 1 .. 1 xsd:sequenceM 1 .. 1 additionalPartyIdentificationValueM 1 .. 1 additionalPartyIdentificationTypeM 1 .. 1 sellerM 1 .. 1 xsd:sequenceM 1 .. 1 glnO 0 .. unbounded additionalPartyIdentificationM 1 .. 1 xsd:sequenceM 1 .. 1 additionalPartyIdentificationValueM 1 .. 1 additionalPartyIdentificationType


Guideline




order:orderResponse M Type: order:OrderResponseType

Description: Provides the ability for a supplier to respond to a n order previously sent bythe buyer.


Description: The date and time the response document was created .responseStatusType M Type: eanucc:ResponseStatusListType

Use: required

Description: Unique type of response to a document referenced.Code/Description

* ACCEPTED* REJECTED

xsd:sequence M 1..1responseIdentification M 1..1 Type: eanucc:EntityIdentificationType

Description: Contains the Order Response number assigned by the content owner.xsd:sequence M 1..1








responseToOriginalDocument M 1..1 Type: eanucc:ReferenceDocumentType

Description: Contains the identification and date of the origina l Purchase Orderreferenced.


Guideline




referenceDocumentType M Type: restriction (xsd:integer)FractionDigits: 0 TotalDigits: 4Use: requiredRule: Default value 35 represents the Order message and is taken from the EntityType codelist.

referenceIdentification M Type: xsd:stringUse: required

referenceDateTime O Type: xsd:dateTimexsd:sequence M 1..1


Description: Identifies the Party to which merchandise is sold.Rule: See also: Component guide for Party Identification





Description: Identifies the party, which sells products or servi ces to a buyer.Rule: See also: Component guide for Party Identification





for

Transaction: Replenishment Forecast

based on message




Replenishment RequestBMS Version: 2.1


Structure Chart




plan:replenishmentRequestM required creationDateTimeM required documentStatusM required replenishmentRequestDocumentTypeM required structureTypeM 1 .. 1 xsd:sequenceM 1 .. 1 documentStructureVersionM 1 .. 1 xsd:sequenceM 1 .. 1 versionIdentificationM 1 .. 1 xsd:sequenceM 1 .. 1 replenishmentRequestIdentificationM 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 sellerM 1 .. 1 xsd:sequenceM 1 .. 1 glnO 0 .. unbounded additionalPartyIdentificationM 1 .. 1 xsd:sequenceM 1 .. 1 additionalPartyIdentificationValueM 1 .. 1 additionalPartyIdentificationTypeM 1 .. 1 buyerM 1 .. 1 xsd:sequenceM 1 .. 1 glnO 0 .. unbounded additionalPartyIdentificationM 1 .. 1 xsd:sequenceM 1 .. 1 additionalPartyIdentificationValueM 1 .. 1 additionalPartyIdentificationTypeO 0 .. 1 materialRequirementsPlannerM 1 .. 1 xsd:sequenceO 0 .. unbounded communicationChannelM required communicationChannelCodeM required communicationNumberM 1 .. 1 personOrDepartmentNameM 1 .. 1 xsd:sequenceM 1 .. unbounded descriptionM 1 .. 1 xsd:sequenceM 1 .. 1 languageM 1 .. 1 xsd:sequenceM 1 .. 1 languageISOCodeM 1 .. 1 textM 1 .. unbounded replenishmentRequestItemLocationInformationM 1 .. 1 xsd:sequenceM 1 .. 1 tradeItemIdentification


Structure Chart




M 1 .. 1 xsd:sequenceM 1 .. 1 gtinO 0 .. unbounded additionalTradeItemIdentificationM 1 .. 1 xsd:sequenceM 1 .. 1 additionalTradeItemIdentificationValueM 1 .. 1 additionalTradeItemIdentificationTypeM 1 .. 1 shipToM 1 .. 1 xsd:sequenceM 1 .. 1 glnO 0 .. unbounded additionalPartyIdentificationM 1 .. 1 xsd:sequenceM 1 .. 1 additionalPartyIdentificationValueM 1 .. 1 additionalPartyIdentificationTypeO 0 .. 1 shipFromM 1 .. 1 xsd:sequenceM 1 .. 1 glnO 0 .. unbounded additionalPartyIdentificationM 1 .. 1 xsd:sequenceM 1 .. 1 additionalPartyIdentificationValueM 1 .. 1 additionalPartyIdentificationTypeM 1 .. 1 inventoryLocationM 1 .. 1 xsd:sequenceM 1 .. 1 glnO 0 .. unbounded additionalPartyIdentificationM 1 .. 1 xsd:sequenceM 1 .. 1 additionalPartyIdentificationValueM 1 .. 1 additionalPartyIdentificationTypeM 1 .. unbounded replenishmentRequestRequirementsLineItemM required numberM required timeBucketSizeM 1 .. 1 xsd:sequenceM 1 .. 1 requiredQuantityM 1 .. 1 xsd:sequenceM 1 .. 1 valueO 0 .. 1 unitOfMeasureM 1 .. 1 xsd:sequenceM 1 .. 1 measurementUnitCodeValueM 1 .. 1 requirementsPeriodM 1 .. 1 xsd:choiceM 1 .. 1 timePeriodM required beginDateM required endDateM 1 .. 1 dateTimePeriodM required beginDateTimeM required endDateTimeO 0 .. 1 purchaseConditionsM 1 .. 1 xsd:choiceM 1 .. 1 documentLineReferenceM required numberM 1 .. 1 xsd:sequence


Structure Chart




M 1 .. 1 documentReferenceO creationDateTimeM 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 xsd:sequenceM 1 .. 1 replenishmentRequestInventoryStatusLineItemM required numberM 1 .. 1 xsd:sequenceM 1 .. unbounded inventoryStatusQuantitySpecificationM required inventoryStatusTypeM 1 .. 1 xsd:sequenceM 1 .. 1 quantityOfUnitsM 1 .. 1 xsd:sequenceM 1 .. 1 valueO 0 .. 1 unitOfMeasureM 1 .. 1 xsd:sequenceM 1 .. 1 measurementUnitCodeValue


Guideline




plan:replenishmentRequest M Type: plan:ReplenishmentRequestType

Description: Contains the material requirements and inventory st atus information fromthe buyer to the seller for given trade items and l ocations for specific timeperiods.






* ORIGINAL* REPLACE

replenishmentRequestDocumentType M Type: plan:ReplenishmentRequestDocumentTypeListTypeUse: required

Description: Specifies the origin and type of the demand, actual s or forecast (optionallyincluding inventory information).

Rule: For the Replenishment Forecast transaction use

"GROSS_REQUIREMENTS_AND_INVENTORY".Code/Description

* GROSS_REQUIREMENTS_AND_INVENTORY

structureType M Type: eanucc:StructureTypeListTypeUse: required






Guideline




Code/Description* LOCATION_BY_ITEM For each item all locations were the item is stored are

specified.xsd:sequence M 1..1





xsd:sequence M 1..1replenishmentRequestIdentification M 1..1 Type: eanucc:EntityIdentificationType

Description: Contains the Replenishment Request number assigned by the contentowner.










xsd:sequence M 1..1


Guideline












materialRequirementsPlanner O 0..1 Type: eanucc:ContactType









Guideline








replenishmentRequestItemLocationInformation M 1..unbounded Type: plan:ReplenishmentRequestItemLocationInformationType

Description: Contains the material requirements for given trade items and locations forspecific time periods.


Description: Contains the identification of the item for which t he replenishment requestis specified.










additionalPartyIdentificationValue M 1..1 Type: xsd:string


Guideline




additionalPartyIdentificationType M 1..1 Type: eanucc:AdditionalPartyIdentificationListTypeshipFrom O 0..1 Type: eanucc:PartyIdentificationType






inventoryLocation M 1..1 Type: eanucc:PartyIdentificationType







replenishmentRequestRequirementsLineItem M 1..unbounded Type: plan:ReplenishmentRequestRequirementsLineItemType



Description: Sequence number that identifies the line.


Guideline




timeBucketSize M Type: plan:BucketSizeTypeCodeListTypeUse: required

Description: Contains a code describing the size of the requirem ents period.Code/Description

* DAY* MONTH* QUARTER* UNSPECIFIED* WEEK* YEAR












Use: required


Guideline




purchaseConditions O 0..1 Type: eanucc:DocumentOrDocumentLineReferenceType


Rule: Also see the guide for Component: Document Or Document Line Reference.xsd:choice M 1..1

documentLineReference M 1..1 Type: eanucc:DocumentLineReferenceTypenumber M Type: restriction (xsd:nonNegativeInteger)










xsd:sequence M 1..1


Guideline




replenishmentRequestInventoryStatusLineItem M 1..1 Type: plan:ReplenishmentRequestInventoryStatusLineItemType

Description: Contains the inventory quantities.Rule: Max occurrence is unbounded in BMS, has been limited to 1 in the MIG. Different inventory

statuses for the same item / location should be stated in the

inventoryStatusQuantitySpecification element.

When using the separate Manufacturer Inventory transaction a more detailed inventory

status report is available, including logistic unit id., inventory sublocation, batch number,

expiry date, etc.number M Type: restriction (xsd:nonNegativeInteger)


Description: Sequence number that identifies the line.xsd:sequence M 1..1

inventoryStatusQuantitySpecification M 1..unbounded Type: eanucc:InventoryStatusQuantitySpecificationType

Description: Information about the stored goods per inventory st atus.inventoryStatusType M Type: eanucc:InventoryStatusListType

Use: required

Description: Code specifying the status of the goods.Code/Description

* MAXIMUM_STOCK Maximum stock target quantity in storage location in order totrigger action if this is exceeded

* MINIMUM_STOCK Minimum stock target quantity in storage location in order totrigger actions if this is exceeded. To share dynamically so asto allow dynamic adjustment of safety stock.

* ON_HAND The total quantity of all inventory directly available for sales orproduction.

* ON_HOLD The total quantity of non-shippable or non-saleable inventoryin a warehouse or warehouse location. This status istemporary. This is product that has quality questioned as anexception, i.e. not regular inspection but due to an exceptionalevent such as infestation or damage to warehouse.

* QUARANTINED Status of product that has been produced, but has not yetcleared quality /performance testing and is therefore not


Guideline




Code/Descriptionavailable for transport or sale. I.e. this stock has beenreceived at manufacturer location and is going through aregular process of Quality Checking before being released asON_HAND.

xsd:sequence M 1..1quantityOfUnits M 1..1 Type: eanucc:QuantityType

Description: Quantity of goods with the specified status.xsd:sequence M 1..1



Length: 1 .. 3

uim implementation guide - gs1 canada implementation guide... · 2010. 4. 16. · 3 and 4.4) and...

Documents