Business Requirements Document For - GS1
Business Requirements Document DATA SYNCHRONIZATION DATA MODEL FOR TRADE ITEM (DATA DEFINITION) 1 2 3 Business Requirements Group (BRG) 4 5 6 Business Requirement Document For 7 8 9 10 Data Synchronization Data Model for Trade Item (Data Definition) 11 12 13 Version 7.7.1 14 15 May 24, 2005 16 17 18 COPYRIGHT 2005, GS1 Version 7.7.1 Page 0 of 195
Business Requirements Document DATA SYNCHRONIZATION DATA MODEL FOR TRADE ITEM (DATA DEFINITION) 19 DOCUMENT HISTORY 20 21 22 Document Number: Document Version: Document Issue Date 23 24 Document Title Owner Status 25 26 Date of Change Version 7.7.1 7.7.1 May 23, 2005 Document Summary EAN UCC – Business Requirements Document For Data Synchronization Data Model for Trade Item – (Data Definition) Align Data BRG Grant Kille - Co-Chair -Julia Holden – Vice Chair Vic Hansen –Co-Chair-Olivier Mouton –Vice Chair UCC - Jeggert@uc-council.org UCC – Mschneider@uc-council.org For ITRGapproval – BRG Approved Document Change History Log Reason for Summary of Change Change February 17, 2001 X.0 Messaging Architecture February 28, 2001 2.0.1 April 27, 2001 2.0.4 Common Data Item Rpt Added the Item Containment May 8, 2001 3.1 Comments at Vote June 5, 2001 4.1 Meeting in Orlando May 9, 2002 5.0 May 10, 2002 V0.6.0 UCC work group meeting and submittal to Align Data BRG (Item Task Group) Models upgraded to match text changes CCR # Documentation to support the Core Item Business Process and to reflect the UCC UML methodology standards Edited the Common data item report. Item Containment is described and has models but no attribute lists Approved BRD with the title of “Core Item & Extension of Relationship Dependent Data to Enable Trade” (This document input to approved July 2001 Business Message Standard – Simpl eb) See section 4.4 Change Summary that was documented on change request 01-000009 XXXXX BRD format was upgraded to GSMP standards. Changed title of the document to “Core Item & Extension of Cross industry Data” Class diagrams in the BRD were upgraded to reflect the text changes made in V0.5.0 01-000011 01-000064 01-000065 01-000009 COPYRIGHT 2005, GS1 Version 7.7.1 Page 1 of 195
Business Requirements Document DATA SYNCHRONIZATION DATA MODEL FOR TRADE ITEM (DATA DEFINITION) July 19, 2002 V0.6.1 August 12, 2002 V0.6.2 Sept. 11, 2002 V0.6.3 Oct. 10, 2002 V0.6.4 Oct. 22, 2002 V7.0 Nov. 21, 2002 V7.1 March 14, 2003 V7.2 April 9, 2003 V7.2.1 Model Harmonization Errata Changes May 5, 2003 V7.2.2 Errata Changes June 4, 2003 V7.3 Errata Changes June 7, 2004 V 7.4 Incorporation of Item Regional Attributes July 19, 2004 V 7.5 December 15, 2004 V 7.6 April 4, 2005 V 7.7 May 24, 2005 V 7.7.1 Added the code list into section 4.8.1 Added Appendix E: Trade Item Implementation Feedback Feedback from 1.3.1 BRD vs. XML . Errata - Update of Trade Item Classification 27 28 29 30 31 Approvals Name Change to Section 3.0 Change to Section 3.0. Add Section 5.0 Merged updates Implementation Section incorporated Merged updates Merged updates Models upgraded Implementation Section upgraded Models upgraded, Text upgraded, Attributes grouped to reflect UML. 02-000065 Combined GCI and UCC standards work. Changes to data dictionary. Updates made to text from Item Project Team. Updates made to text from Item Project Team. Updates made to text from Item Project Team Updates made to text based on comments resulting from Public Review by Align BRG. Changes to document agreed by project team. Version 7.2 Model Harmonization Summary Reference separate document titled “TRADE ITEM – CORE AND EXTENSION – V. 7.2.1- Errata Change Summary Table on Appendix A – Attribute Variations checked to match the attribute conditions in the text. Incorporates Errata resulting from ITRG’s review. Changed Trading Partner Neutral Information Model to eliminate Is Item Green Dot. Additional code list added to section 4.8.1 Incorporated Trade Item Implementation Feedback 03-000082 04-000035 04-000044 Changed to GDSN Trade Item Classification. Removed remaining references to alternate party and item identifiers. Corrected formatting issues. Title Signature Date COPYRIGHT 2005, GS1 Version 7.7.1 Page 2 of 195
Business Requirements Document DATA SYNCHRONIZATION DATA MODEL FOR TRADE ITEM (DATA DEFINITION) 32 33 34 TABLE OF CONTENTS 35 36 FOREWORD. 5 37 1.0 BUSINESS OPPORTUNITY:.5 38 39 40 41 1.1 PROBLEM STATEMENT:.5 1.2 AUDIENCE: .5 1.3 REFERENCES: .5 1.4 ACKNOWLEDGEMENTS:.7 42 2.0 PROCESS VIEW – GENERAL REQUIREMENTS:.8 43 2.1 USE CASE SCENARIO:.8 44 45 46 47 48 49 50 2.1.1 BUSINESS OPPORTUNITY/PROBLEM STATEMENT .9 2.1.2 ACTORS.9 2.1.3 PRECONDITIONS .10 2.1.4 PROCESS START .10 2.1.5 PROCESS END .10 2.1.6 POST CONDITIONS .10 2.1.7 PROCESS ACTIVITIES .10 51 3.0 LOGICAL VIEW.10 52 3.1 DEFINITION OF CONDITIONS .11 53 54 55 56 57 58 59 60 61 62 63 64 65 MASTER DATA/TRANSACTIONAL DATA – .11 MASTER DATA ALIGNMENT .11 CORE ATTRIBUTES: .11 EXTENSION ATTRIBUTES: .11 TRADING PARTNER NEUTRAL/TRADING PARTNER DEPENDENT.12 MARKET GROUP .12 TARGET MARKET COUNTRY CODE .13 TARGET MARKET SUB-COUNTRY CODE .13 GLOBAL/GLOBAL-LOCAL/LOCAL .13 HOW DOES THE GLOBAL/GLOBAL-LOCAL/LOCAL CONDITION, AND TARGET MARKET VALUE INTERACT TO AFFECT ATTRIBUTE VALUES? .14 TRADE ITEM .15 PARTY 15 66 PRODUCT HIERARCHY REFERENCE LEVEL .15 COPYRIGHT 2005, GS1 Version 7.7.1 Page 3 of 195
Business Requirements Document DATA SYNCHRONIZATION DATA MODEL FOR TRADE ITEM (DATA DEFINITION) 67 COMMON VALUE TO ALL PRODUCT HIERARCHY . 15 68 3.2 TRADE ITEM: .17 69 3.3 TRADE ITEM IDENTIFICATION: .20 70 3.4 GDSN TRADE ITEM CLASSIFICATION: .22 71 3.5 TRADE ITEM INFORMATION:.28 72 3.6 TRADING PARTNER NEUTRAL TRADE ITEM INFORMATION:. 38 73 3.7 TRADE ITEM TAX INFORMATION: .125 74 3.8 FMCG (FAST MOVING CONSUMER GOODS) – INDUSTRY SPECIFIC:. 128 75 4.0 IMPLEMENTATION CONSIDERATIONS AND CONCERNS .132 76 KEY DATA ATTRIBUTES .134 77 4.1 PRODUCT HIERARCHY .135 78 GTIN HIERARCHY .135 79 ITEM CONTAINMENT:.148 80 4.2 PRODUCT CLASSIFICATION .148 81 4.3 PRODUCT ORIENTATION.149 82 4.4 LANGUAGE (REFERENCE APPENDIX 13 AND APPENDIX 17) . 149 83 4.5 CURRENCY (REFERENCE APPENDIX 12).149 84 4.6 UNIT OF MEASURE (REFERENCE APPENDIX 14).150 85 4.7 PRODUCT DESCRIPTION.150 86 4.8 CODE LISTS.151 87 4.8.1 CODE LISTS .151 88 4.9 RELATIONSHIP TO GLOBAL DATA SYNCHRONIZATION PROCESS.178 89 APPENDIX A: ATTRIBUTE VARIATIONS .181 90 91 APPENDIX B ATTRIBUTE ASSOCIATION BY TRADE ITEM HIERARCHY LEVEL FOR DATA SYNCHRONIZATION.188 92 APPENDIX C ATTRIBUTES MANDATORY FOR DATA SYNCHRONIZATION. 198 93 APPENDIX D: TRADE ITEM IMPLEMENTATION FEEDBACK.199 94 COPYRIGHT 2005, GS1 Version 7.7.1 Page 4 of 195
Business Requirements Document DATA SYNCHRONIZATION DATA MODEL FOR TRADE ITEM (DATA DEFINITION) 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 FOREWORD “Implementation of this Item standard requires adherence to the business rules contained in this document in addition to adherence to the technical schema as it is designed. In order to enable reusability and commonality across the EAN.UCC Business Message Standards, a common library has been developed to support the technical implementation of the EAN.UCC standards into XML schemas resulting in standardized data types and field sizes. As a result, the schema will accommodate the data types and field sizes as defined in this standard, however, the schema does not enforce any specific field sizes as defined by the business requirements.” 1.0 Business Opportunity: Item is the second message in the trade process following the Party message. Item elements are the mandatory attributes needed to align the item information between trading partners. These attributes in combination ensure the uniqueness of the data set associated with a GTIN. The use, definition, and relevance of these attributes is the same for ALL EAN.UCC industries. Following the Item attributes is an extension of cross industry. These are data attributes that may be required in conducting commerce between partners for the trade of an item or service. These attributes are relevant to more than one industry. The definition of these attributes must be the same for all industries. 1.1 Problem Statement: Item and the extension of the cross industry data processes include communicating the data elements necessary to support the core business requirements in the global trading environment. The Party and Item process are mandatory in the completion of the price, purchase order, invoice, etc. messages that follow in the global trade process. 1.2 Audience: The audience of the standards would be any participant in the global supply chain. This would include retailers, manufacturers, service providers and other third parties. 1.3 References: The legacy: the Global Data Alignment System (GDAS) “ELECTRONIC CATALOGUES EAN RECOMMENDATIONS COMMON SET OF DATA” (June 1998-June 1999) “GLOBAL DATA ALIGNMENT – GCI – DRAFT” (21 Jan. 2000 – 24 July 2000) GLOBAL DATA DICTIONARY- Item Data Model – General Overview, Version 1, Global Commerce Initiative, Global Data Dictionary Group, March 31, 2002 COPYRIGHT 2005, GS1 Version 7.7.1 Page 5 of 195
Business Requirements Document DATA SYNCHRONIZATION DATA MODEL FOR TRADE ITEM (DATA DEFINITION) 143 144 EAN.UCC Business Message Standards Version 1.0, July 2001 145 Core Party Business Requirements Document, Version 6.0 of May 10, 2002 146 147 Core Item and Extension of Trading Partner Neutral Data, Version 0.6.0 of May 10, 2002 148 EAN.UCC Global Business Model (Process and Data), October 1999 149 Java Framework for SIMPL-EDI Requirements Specification, April 2000 150 Simple eb(electronic business), March 2000 151 152 BPAWG Model of the International Supply Chain Domain (interim report), January 2000 153 Change Requests: 01-000009, 01-000010, 01-000064, 01-000065. 154 Change Request 02-00065 155 156 157 158 GSMP –Technical Steering Team, Policy Paper “Policy on the use of identification keys in standards and recommendations developed in GSMP”, January 2003 159 160 161 162 163 Note: The following text was extracted from a letter sent to the Align Data BRG on March 31, 2003: “Due to the timing of this policy paper and the dialogue going on within the user community regarding how it will affect the standards, the Executive Management Team decided that the policy would be implemented in version 2.0 of the standards, which should be published in 2004.” 164 165 Additionally, the existing Electronic Data Interchange messages in widespread use were mined for their business content. 166 UCS 888 Item Maintenance 167 VICS EDI 832 Price Sales Catalog 168 I/C EDI 832 Price Sales Catalog 169 EANCOM PRICAT 170 Acknowledgement is also due to the work going on in the XML environment. 171 ebXML/SOAP 172 eCo Framework (Common Business Library) 173 Rosettanet 174 175 W3C COPYRIGHT 2005, GS1 Version 7.7.1 Page 6 of 195
Business Requirements Document DATA SYNCHRONIZATION DATA MODEL FOR TRADE ITEM (DATA DEFINITION) 176 177 178 179 1.4 Acknowledgements: Members of the Item Project Team as of October 17, 2002 Buckley, Greg Costello, Aidan Funk, Jim Geyer, Terrie Gore, Harshal Harris, Mike Hawkins, Bruce Iwicka, Ewa Kasper, Sascha Kille, Grant Laskero, Nancy Laur, Rita Lerch, Hanjörg Licul, Ed Lockhead, Sean Merulla, Mike Moise, Michael Mouton, Olivier Ngo, Aileen Panaccio, Robert (Co-chair) Pottier, Natascha (Co-chair) Sadiwnyk, Mike Schneck, Joy Sheldon, Emma Spooner, Karen Vacval, Milan Walton, Mike Warde, Nadim Watt, Anna (Co-chair) Wasielewski, David Zielinski , Felix Pepsi-Cola USA QRS SC Johnson Sears Roebuck & Company E-centre-UK Vialink Wal-Mart EAN International EAN Germany, CCG WWRE Sears Roebuck & Company ECCC, Canada Metro AG, Germany Transora UCCNet Wegmans Nestle Carrefour, France Nestle Procter & Gamble EAN Germany, CCG ECCC, Canada General Mills UDEX Kraft Foods Vista CPG UDEX Equadis Cadbury/Schweppes Connective Commerce The Coca Cola Company Eggert, Jack Ryu, John Schneider, Maria Steck, Terry EAN.UCC, BRG Manager EAN.UCC, Business Process Modeler EAN.UCC, Project Team Manager EAN.UCC, Database Support 180 COPYRIGHT 2005, GS1 Version 7.7.1 Page 7 of 195
Business Requirements Document DATA SYNCHRONIZATION DATA MODEL FOR TRADE ITEM (DATA DEFINITION) 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 2.0 Process View – General Requirements: The buyer and seller must make contact and set up a business relationship before trade can proceed. This is a prerequisite to all of the other steps. This initial contact can be made in many different ways. Following the establishment of the trading agreement the parties must exchange their basic business data such as trading partner names, addresses, locations, item attributes, price lists, contracts and trading partner agreements. Specifically, the Core Item message follows the Core Party message in the data alignment process. This process creates a common understanding between the trading parties which can be used as a resource throughout the trading process. 2.1 Use Case Scenario: There is only one scenario in the Item data communication process as described in problem statement of section 1.1. Item data alignment is the process of communicating the core item and cross industry data elements following the establishment of a business relationship between suppier, buyer or third party. COPYRIGHT 2005, GS1 Version 7.7.1 Page 8 of 195
Business Requirements Document DATA SYNCHRONIZATION DATA MODEL FOR TRADE ITEM (DATA DEFINITION) Buyer Seller Align D ata - Party Align D ata - Item and Price O rder D espatch Advice Invoice 199 200 201 202 2.1.1 Business Opportunity/Problem Statement 203 204 205 206 207 208 209 210 The objective of this document is to elaborate the Data Synchronization Data Model for Trade Item (hereafter referred to as ‘Data Sync Trade Item’) business process in enough detail to support the construction of standards. It is assumed that the players, both seller and buyer, have established a business understanding of the trading partner relationship. The challenge is to provide the core elements necessary to complete all supply chain processes without duplicates. 211 212 213 214 The two general players in the Data Sync Trade Item business process are the "seller" and the "buyer". Depending on the specific nature of the relationship other players may have a role, such as a Third Party. The graphic flow below pictures the core sequence of messages, and is expanded to account for additional scenarios. 2.1.2 Actors COPYRIGHT 2005, GS1 Version 7.7.1 Page 9 of 195
Business Requirements Document DATA SYNCHRONIZATION DATA MODEL FOR TRADE ITEM (DATA DEFINITION) 215 216 Actor’s Name Seller Buyer Third Party 217 218 Description Manufacturer or supplier of the item. Retailer or distributor of the item Other parties that somehow influence the item and may include creation, distribution, publication, and/or maintenance of the item. Buyer Seller X X X X Third Party X X X 2.1.3 Preconditions 219 220 221 222 223 224 The Data Sync Trade Item business process begins when the parties decide to do business together. The next step is for the buyer to communicate the Party organizational information to the seller. The seller provides his Party organizational information to buyer. Other data alignment follows such as item and price attributes. 225 226 227 The start-state of the Data Sync Trade Item business process begins during the initial discussions between the trading partners and the need to exchange item information. 228 229 2.1.5 Process End 230 231 232 233 Once the Data Sync Trade Item business message has been accepted by both the seller and buyer, then data alignment has been achieved. This process can be an ongoing process as item business information changes or new parties are added. The process of trading goods and services can now occur. 234 235 2.1.6 Post Conditions 236 237 238 239 240 241 242 243 244 245 246 2.1.4 Process Start The end-state of the Data Sync Trade Item business process occurs when the parties have achieved Party and Item data alignment. 2.1.7 Process Activities Step Actor Activity Step # All All preconditions have been met. 1 Seller Communicates item data. 2 Buyer Receives item data. 3 Buyer Applies item data or notifies the seller of any errors in the data. 4 See the work completed by the data synchronization project team for a detailed view of data communication. 3.0 Logical View The Data Sync Trade Item messages include the item’s unique identification, descriptions, and characteristics. COPYRIGHT 2005, GS1 Version 7.7.1 Page 10 of 195
Business Requirements Document DATA SYNCHRONIZATION DATA MODEL FOR TRADE ITEM (DATA DEFINITION) 247 248 249 250 251 252 253 254 255 256 257 258 259 260 261 262 263 264 265 266 267 268 269 270 271 272 273 274 275 276 277 278 279 280 281 282 283 284 285 286 287 288 289 290 291 292 293 3.1 Definition of Conditions To help with the implementation of this data model, several key definitions are listed below. Master Data/Transactional Data – Master data is considered to be that set of data that describes the specifications and structure of each item and party involved in the supply chain processes. The uniqueness of the data associated with a trade item is given only by the GTIN. This data is static, not dependent on a transaction. Transactional data is that set of data that can only be determined during a business transaction, i.e., plan, sell, buy, and deliver cycle. (E.g. actual amount of cases delivered). NOTE – this data model only includes master data Master Data Alignment Master Data Alignment is the process of timely distribution of accurate Master Data from one partner to others and the correct use of this data. Such synchronization and use of Master Data leads to more accurate business transactions and therefore reinforces the efficiency of the supply chain operations. Successful Master Data Alignment is achieved via the use of EAN.UCC coding specifications throughout the supply chain, communication of all changes and new information between trading partners and use of the information exchanged in subsequent transactions. Master Data Alignment relies on EAN.UCC specifications concerning the Unique Identification of Items, GTIN and Parties GLN. Core attributes: An attribute whose definition is common across all Industries Core attributes are common across all geographies. I.e. ALL Target Markets These attributes do not necessary need to be maintained by the Registry. Core attributes CANNOT be relationship dependant. They are trading partner neutral only Extension attributes: An extension is an attribute that is relevant to one or more industries (not all EAN.UCC Industries) The definition of an extension attribute is common to all Industries who use the attribute. Each Industry is responsible for determining the extension attributes that are relevant to their Industry. New extension attributes may be submitted/requested for a specific Industry as necessary. COPYRIGHT 2005, GS1 Version 7.7.1 Page 11 of 195
Business Requirements Document DATA SYNCHRONIZATION DATA MODEL FOR TRADE ITEM (DATA DEFINITION) 294 295 296 297 298 299 300 301 302 303 304 305 306 307 308 309 310 311 312 313 314 315 316 317 318 319 320 321 322 323 324 325 326 327 328 329 330 331 332 333 334 335 336 337 338 339 340 341 342 The conditions of extension attributes can vary by each industry. E.g. Mandatory/Optional, Global/Local, Trading Partner Neutral/Relationship Dependent, and Common to all Hierarchy levels. Industry user groups should be developed in concert with the EAN.UCC GSMP Process, to determine their relevant extension attributes and the conditions associated with those attributes. Process user groups such as CPFR and local (target market) extensions. Trading Partner Neutral/Trading Partner Dependent Values for an attribute can vary depending on the relationship with the party receiving the data. The Trading Partner Neutral/Trading Partner Dependent status indicates this rule. The condition Trading Partner Neutral is applied to any attribute whose value is independent on a buyer and seller relationship. An attribute, which has the condition Trading Partner Neutral, can have only one set of values . The condition Trading Partner Dependent is applied to any attribute whose value is dependent on a buyer and seller relationship. An attribute, which has the condition Trading Partner Dependent, can have only one set of values per GLN of Party Receiving Data. These are attributes whose value is dependent on a specific point-to-point agreement between a buyer and a seller. An attribute which has the condition Trading Partner Neutral & Trading Partner Dependent, can have only one set of values for the Trading Partner Neutral value AND one set of values per GLN of Party Receiving Data Multiple Values allowed: This condition is used to indicate that multiple values can be submitted for a trade item. E.g. multiple types of packaging on a trade item e.g. plastic, cardboard etc Where there is a need to express multiple measures, these are handled through indicating the attribute type as ‘Measurement’. Both the value and UOM can be repeated, and must be used together. See section 4.6 on Unit of Measure in the implementation consideration and concerns. Where there is a need to express multiple language versions, these are handled through indicating the attribute type as ‘Text Description’. See section 4.4 on Language in the implementation consideration and concerns. Market Group A Market Group is used to identify a proprietary group of data recipients. It is normally determined by the information provider although it can also be COPYRIGHT 2005, GS1 Version 7.7.1 Page 12 of 195
Business Requirements Document DATA SYNCHRONIZATION DATA MODEL FOR TRADE ITEM (DATA DEFINITION) 343 344 345 346 347 348 349 350 351 352 353 354 355 356 357 358 359 360 361 362 363 364 365 366 367 368 369 370 371 372 373 374 375 376 377 378 379 380 381 382 383 384 385 386 387 388 389 390 391 created by buyers and third parties. This group is used and developed by the information provider to control del publication of data to a specific group of customers. This should not be confused with Target Market. Target Market Country Code The purpose of the target market country code is to organize master data to meet the requirements of specific geographies The purpose of this field is to explain where a manufacturer is intending to sell its product(s) to a buyer. It does not control where the buyer can resell the product (s) to the end consumer. It is the country, (the geopolitical area) where the product is to be sold and available for publication in an Item Catalog. Target Market Country Code in relationship to Master Data, can be Trading Partner Neutral only. A Target Market Country Code is not used to control Distribution or Consumer Market Area geographies. E.g. product available for shipment from a single Distribution Center. Target Market Sub-Country Code A sub-country code level used to address/comply with a “law making” requirement associated with a country. The number of sub-country codes will vary by each country. These will match with the legislation requirements of each country. (Local bottle deposit tax laws, State and country taxes) Not all countries will have sub-country codes. A sub-country code must be associated with a Target Market Country Code. It cannot stand-alone. Global/Global-Local/Local All attributes are impacted by their geo-political relevance. This condition can be used by information providers as they build data models. With this information, they can limit the attributes communicated to those relevant for that geography. A global attribute indicates that the attribute is relevant for business cases around the world, and can only have a single value throughout the world. (E.g. GTIN) A global/local attribute indicates that the field is relevant for business cases around the world, that its definition is the same around the world, but may have a different value depending on the geography. (E.g. VAT tax values, 1.00 in France, 1.05 in Belgium) A local attribute is only relevant in certain geographical areas, and the values may change based on where the product is offered for sale. (E.g. green dot – only relevant in certain European countries) COPYRIGHT 2005, GS1 Version 7.7.1 Page 13 of 195
Business Requirements Document DATA SYNCHRONIZATION DATA MODEL FOR TRADE ITEM (DATA DEFINITION) 392 393 394 395 396 397 398 399 400 401 402 403 404 405 406 407 408 409 410 411 412 413 414 415 416 417 418 419 420 421 422 423 424 425 426 427 428 429 430 431 432 433 434 435 436 437 438 439 440 How does the Global/Global-Local/Local condition, and Target Market value interact to affect attribute values? An attribute, which has the condition ‘Global’, can have only one global value (except where there are multiple values allowed). An attribute which has the condition Global / Local can have one value per Target Market specified (except where there are multiple values allowed). A Global/Local attribute indicates that the field is relevant for business cases around the world, that its definition is the same around the world, but may have a different value depending on the geography. (E.g. the attribute - VAT tax values are relevant globally, but the actual value, 1.00 in France, 1.05 in Belgium varies by country) As long as the attribute values apply consistently to the GTIN, GLN, TM combination the values are repeatable. Example: GTINa GLNa TMa b,
20 DOCUMENT HISTORY 21 22 Document Number: 7.7.1 Document Version: 7.7.1 Document Issue Date May 23, 2005 23 24 Document Summary Document Title EAN UCC - Business Requirements Document For Data Synchronization Data Model for Trade Item - (Data Definition) Owner Align Data BRG Grant Kille - Co-Chair -Julia Holden - Vice Chair
Foodstuffs GS1 NPC Supplier Guidelines Version 2.2 Page 4 of 28 GS1 PRODUCTFLOW / NPC PROCESSES As a supplier to Foodstuffs you will need to: Register for GS1 ProductFlow and work with GS1 to achieve GS1 Product Flow Certified status. Foodstuffs will then "activate" your company in the Foodstuffs eXchange to be a ProductFlow user.
healthcare industry through local support initiatives like GS1 Healthcare US in the United States. About GS1 Healthcare US GS1 Healthcare US is an industry group that focuses on driving the adoption and implementation of GS1 Standards in the healthcare industry in the United States to help improve patient safety and supply chain efficiency.
industry through local support initiatives like GS1 Healthcare US in the United States. ABOUT GS1 HEALTHCARE US GS1 Healthcare US is an industry group that focuses on driving the adoption and implementation of GS1 Standards in the healthcare industry in the United States to improve patient safety and supply chain efficiency.
GS1 , under its IP Policy, seeks to avoid uncertainty regarding intellectual property claims by requiring the participants in the Work Group that developed this GS1 AIDC Fresh Foods Sold at Point -of-Sale Implementation Guideline to agree to grant to GS1 members a royalty-free licence or a RAND licence to Necessary Claims, as that term is defined in the GS1
Bruksanvisning för bilstereo . Bruksanvisning for bilstereo . Instrukcja obsługi samochodowego odtwarzacza stereo . Operating Instructions for Car Stereo . 610-104 . SV . Bruksanvisning i original
The TJX Companies EDI GS1-128 Carton Labels June 2015 1 The TJX Companies, Inc. GS1-128 Carton Label Requirements Contacts: edi-asn-inquiry@tjx.com . Serial Shipping Container Code. The TJX Companies EDI GS1-128 Carton Labels June 2015 3 ZONE DETAILS Zone Description Information Height / Width
Disclaimer 5 GS1 , under its IP Policy, seeks to avoid uncertainty regarding intellectual property claims by requiring the participants in 6 the Work Group that developed this Core Business Vocabulary Standard to agree to grant to GS1 members a royalty- 7 free licence or a RAND licence to Necessary Claims, as that term is defined in the GS1 IP Policy. . Furthermore, attention
4. GS1 2D Data matrix The 2D Data Matrix should be in accordance with the GS1 guideline [2], ISO/IEC 15415 [10] & ANSI x3.182 [12]. 5. GS1 1D Barcode If applied, the 1D barcode should be displayed below the 2D Data matrix. The bar code should be in accordance with GS1 specification [1], ANSI X3.182 [12] & ISO/IEC 15416 [11]. 6.
