1 Introduction
Consumers and businesses rely on global supply chains to produce a diverse array of high quality, safe goods and services at affordable prices in a socially and environmentally responsible way. Meeting the demands of today’s consumer requires a much finer degree of supply chain visibility than has been typically exposed in the past. Up until now, this granular level of visibility has been seen in the transport and logistics industry, but not much elsewhere. Everyone has tracked a package they have ordered and has been able to see where the shipping process began, all of the stops it took in between, when it is anticipated to reach its destination and its arrival at the intended recipient. Increasingly, organisations, governments and indeed consumers want that same ability for products they purchase, the things they eat and perhaps even electronic records about things they care about.
Visibility data can describe the origin of an object (virtual or physical), each location where it is subject to a business process throughout the supply chain or other process, when those processes took place and what was occurring to that object at each point. Visibility data is the WHAT, WHERE, WHEN and WHY about an object. Capturing and sharing visibility data, either internally or across trading partners provides a view into the history of the manufacture, shipping, receiving and selling processes that allow for a more efficient, affordable and safe supply chain.
Electronic Product Code Information Services (EPCIS) is a GS1 standard that defines a common data model for visibility data and interfaces for capturing and sharing visibility data within an enterprise and across an open supply chain. The goal of EPCIS is to enable disparate applications to create and share visibility event data, both within and across enterprises. Ultimately, this sharing is aimed at enabling users to gain a shared view of physical or digital objects within a relevant business context.
1.1 Intended audience
1.2 Document scope
This guide is intended to provide supply chain stakeholders, including manufacturers, distributors, retailers, logistics providers, solution providers, business process architects, IT departments (developers) and solution providers with an introduction to implementing a visibility system using EPCIS, the Core Business Vocabulary specifically and GS1 standards.
This guide was developed to provide both overview and guidance on getting started with visibility systems using EPCIS. It is not intended to be a detailed, technical industry-specific “how to” guide. Industries including Pharmaceutical, Electronics, Logistics and Food & Agriculture, have developed industry specific implementation guides for EPCIS. This document intends to provide guidance at a basic use or foundational level, allowing those guidelines to layer on their specific industry requirements on top.
2 Overview of EPCIS
The goal of EPCIS is to enable disparate applications to create and share visibility event data, both within and across enterprises. Ultimately, this sharing is aimed at enabling users to gain a shared view of physical or digital objects within a relevant business context.
“Objects” in the context of EPCIS typically refers to physical objects that are identified either at a class or instance level and which are handled in physical handling steps of an overall business process involving one or more organisations. Examples of such physical objects include trade items (products), logistic units, returnable assets, fixed assets, physical documents, etc. “Objects” may also refer to digital objects, also identified at either a class or instance level, which participate in comparable business process steps. Examples of such digital objects include digital trade items (music downloads, electronic books, etc.), digital documents (electronic coupons, etc.), and so forth. Throughout this document the word “object” is used to denote a physical or digital object, identified at a class or instance level, that is the subject of a business process step. EPCIS data consist of “visibility events,” each of which is the record of the completion of a specific business process step acting upon one or more objects.
The EPCIS standard was originally conceived as part of a broader effort to enhance collaboration between trading partners by sharing of detailed information about physical or digital objects. The name EPCIS reflects the origins of this effort in the development of the Electronic Product Code (EPC). It should be noted, however, that EPCIS does not require the use of Electronic Product Codes, nor of Radio-Frequency Identification (RFID) data carriers, and as of EPCIS 1.1 does not even require instance-level identification (for which the Electronic Product Code was originally designed). The EPCIS standard applies to all situations in which visibility event data is to be captured and shared, and the presence of “EPC” within the name is of historical significance only.
2.1 What's in the EPCIS and CBV standards?
2.2 Example of EPCIS Visibility Data
2.3 EPCIS in business applications
2.4 Benefits and business opportunities
2.5 EPCIS Data in relation to other types of data
2.6 How EPCIS fits into a typical IT landscape
2.7 EPCIS and GS1 standards
The EPCIS standard defines:
■ A data model for visibility event data along with an accompanying concrete syntax for visibility data using the eXtensible Markup Language (XML); and
■ Open, standardised interfaces that allow for seamless integration of well-defined services in inter-company environments as well as within companies. There are two interfaces defined in the EPCIS standard:
□ A capture interface through which visibility event data conforming to the EPCIS data model may be delivered from capturing applications to a receiver, typically a persistent repository of EPCIS data; and
□ A query interface through which EPCIS event data may be requested by and delivered to a business application or a trading partner.
Standard interfaces are defined in the EPCIS standard to enable visibility event data to be captured and queried using a defined set of service operations and associated data standards, all combined with appropriate security mechanisms that satisfy the needs of user companies. In many or most cases, this will involve the use of one or more persistent databases of visibility event data, though a direct linkage between capture and query interface could be used for direct application-to-application sharing without persistent databases.
EPCIS is intended to be used in conjunction with the GS1 Core Business Vocabulary (CBV) standard [CBV1.2]. The CBV standard provides definitions of data values that may be used to populate the data structures defined in the EPCIS standard. The use of the standardised vocabulary provided by the CBV standard is critical to interoperability and critical to provide for querying of data by reducing the variation in how different businesses express common intent. Therefore, capturing applications should use the CBV standard to the greatest extent possible in constructing EPCIS data.
EPCIS data is intended to provide information systems with visibility as to where things are (and have been) within the business processes in which those things are handled. The following figure illustrates a simple business process, showing where EPCIS data may be generated.
Figure 2‑1 Simple Business Process Showing Generation of EPCIS Data
This figure illustrates a simple business process in which a trade item is manufactured and shipped to a distribution centre, where it is subsequently received and later shipped to a retail store, where it is received and later moved into the sales area. The entire business process may be viewed as a sequence of individual business steps: product packaging, packing into a shipping container, shipping, receiving, and so on. EPCIS data can provide a detailed record of any or all of these steps. A unit of EPCIS data that describes the completion of one business step is called an EPCIS event, and a collection of EPCIS events provides a detailed picture of a business process over time and place.
For example, a single EPCIS event records the receipt of one shipment at the distribution centre. The information content of this event is organised into four dimensions:
■ What Information about what trade items and/or shipping containers were received
■ When The date and time when receiving occurred, and the local time zone in effect
■ Where The location where the shipment was received, and where the items are expected to be following the event
■ Why Information about the business context, including:
□ The fact that the business step is a receiving operation (as opposed to shipping or some other business step).
□ The fact that the shipment is making normal forward progress through the supply chain (as opposed to being returned).
□ Information about who are the shipping and receiving parties, and the former and current owning parties if different than the shipper and receiver
□ Links to relevant business transaction documents, such as a purchase order, an invoice, a despatch advice (a.k.a. advance ship notice), etc.
Each of the business steps in the process illustrated in the figure could be the source of an EPCIS event. The details of the content of each of those events are different depending on the business step, but all have the same four-dimensional structure.
The power of EPCIS lies in bringing together individual events that are recorded over time and across a complete business process and/or supply chain. Examples of such paradigms include:
■ Finding the most recent EPCIS event for a given object, to learn where it currently is and what state it is in (“tracking”)
■ Assembling a history of events for a given object, to understand its path through an overall business process or supply chain (“tracing”)
■ Analysing a collection of events gathered over time at a particular location or within a particular business process (“analysis”)
■ Comparing the actual status of objects based on a current EPCIS event to what was expected to have happened based on a prior business transaction or a prior EPCIS event (“checking”)
■ Triggering other business processes in real time based on what a freshly captured EPCIS event reveals about the completion of a business step (“automation”)
Below are examples of business applications that can benefit from EPCIS data, along with the paradigm involved. It should be noted, however, that these paradigms are broad generalisations, and in reality a business application may make use of EPCIS data in a variety of ways that combine or step outside paradigms.
Table 2‑1 Example Business Applications and Their Use of EPCIS Data
Each one of these applications could be deployed in one of three modes:
■ Internal: The business process exists within the facilities and is under the control of a single organisation.
■ External, Closed Chain: The business process spans more than one organisation, but all organisations involved are known in advance.
■ External, Open Chain: The business process spans more than one organisation, and the set of organisations involved is not known in advance and changes over time. This mode is typical of large supply chains involving mutual trade.
In all three modes, a key element of solution design is to determine the proper data content of EPCIS events so that the requirements of the business applications are met. In the external modes, an additional consideration is the design of the way that EPCIS events are communicated between the multiple organisations involved (often referred to as the “choreography” in contrast to the “content”).
In the external, open chain mode, the value of EPCIS and CBV being open standards is obvious: when all parties adhere to a standard, it is possible to achieve interoperability and mutual understanding of data even without prior collaboration of the parties on solution design. However, this is just as important in a closed chain or even a strictly internal application—primarily because internal applications tend to become external and closed applications tend to be come open over time. It is therefore important to follow best practices for external, open applications even when designing a closed or purely internal application.
Enhanced visibility offers a number of various benefits at all points in the supply chain in all industries. A record of processes at the point of origin or manufacture, through various distribution points, to the final point of sale to a consumer offers the potential for benefits including:
■ Optimised receiving productivity
■ Improved inventory management
■ Increased pick rates
■ Reduced errors in mispicks and shorts
■ Improved order accuracy and reduces billing errors
■ Better product and location identification throughout track and trace processes
■ Increased operational efficiencies across various business processes
■ Improved preparedness for fast and precise recalls
■ Enhanced consumer protection
■ Better product, allergen, and nutritional information delivered to consumers
EPCIS and the accompanying Core Business Vocabulary provide a technical foundation for capturing and sharing visibility data. It helps answer the questions “where is something and where has something been?” Sharing visibility data in a standard manner offers significant advantages over proprietary solutions. EPCIS allows for sharing of data between various business applications, either internally or between trading partners. EPCIS facilitates real time processing and return of event based data, both streaming (inflow and outflow of events) and complex event processing (match filtering of events). An EPCIS based system supports the demands of the consumer’s growing appetite of more and more product information, including the path the things they are purchasing have travelled.
It is important to note that EPCIS is a set of interface standards, one for capturing the data and one for querying the data. The Core Business Vocabulary provides the business context to the data model prescribed in EPCIS. Many software applications focused on traceability or other business processes that may benefit from visibility data within and across organisation implement EPCIS as a foundation. Indeed, organisations looking to develop a visibility strategy should look for solutions based on this standard.
GS1 standards in the “Share” layer pertain to three categories of data that are shared between end users:
Table 2‑2 Categories of Data in the “Share” Layer of GS1 standards
As the table suggests, visibility data (EPCIS event data) is a new type of data, different in character from either master data or transaction data.
A chief distinguishing characteristic of EPCIS data is that it occurs in much greater volume than either master data or transaction data. Like transaction data (and unlike master data), new visibility data is generated continuously as an organisation conducts more business. But visibility data occurs in greater volume because:
■ Visibility data frequently refers to individual instances of objects, for example trade items identified by the combination of a Global Trade Item Number (GTIN) and a serial number.
■ Even when visibility data refers to objects at the class level, visibility data is generated at more steps within an overall business process. For example, a trade item flowing from manufacturer to retailer may be subject to just a single business transaction (the sale from manufacturer to retailer) but be the subject of several dozen visibility events as it progresses through the manufacturer’s and retailer’s facilities.
■ Visibility data often has historical value for traceability, and so may be retained for longer periods of time than business transaction data.
Visibility data is complementary to transaction data, as some visibility events occur in the absence of business transactions and conversely some business transactions take place without handling of objects. Where the same business process simultaneously yields visibility data and transaction data, they provide complementary data.
Figure 2‑2 Overlap Between Transaction Data and Visibility Data
Examples of all three possibilities:
■ In some cases, a visibility event coincides with a business transaction, so that there may be a piece of transaction data and a piece of visibility event data describing different aspects of the same occurrence. For example, when goods are shipped from a loading dock, there may be a despatch advice (a piece of transaction data that confirms the sender’s intent to deliver specific goods to the receiver) and an EPCIS event with business step “shipping” (a piece of visibility data that confirms the observation of goods leaving the loading dock). Even in such cases, the transaction data and visibility event data may not be in 1:1 correspondence; for example, a single despatch advice may correspond to several visibility events if different parts of the shipment are handled separately.
■ A visibility event may occur with no corresponding business transaction. For example, when a trade item moves from the “back room” storage of a retail store to the sales area where a consumer can purchase it. This is a highly relevant event for purposes of assessing availability of product to consumers but it has no associated business transaction.
■ A business transaction may take place with no corresponding visibility event. For example, when a purchaser sends an “order” message to a supplier, there is a legal interaction, but nothing occurring in the physical world where the ordered products reside (in fact, the ordered products may not even exist when the order is sent).
The following simplified diagram shows how EPCIS fits in to a typical company IT infrastructure.
For the sake of discussion, this picture lumps together as “back-end applications” all of the IT components that process master data and transaction data (as defined in the previous section). The specific legacy components in use will, of course, vary widely from company to company; typical components include Enterprise Resource Planning (ERP) systems, Warehouse Management Systems (WMS), Master Data Management (MDM) systems, etc.
Because visibility data is a new type of data, and as discussed in the previous section visibility data often occurs in far greater quantities, it is common that new IT components are dedicated to the processing of visibility data. These components include:
■ EPCIS Repository: A persistent store for visibility data, including all EPCIS events generated internally within the organisation and whatever EPCIS events are received from trading partners.
■ EPCIS Capture Applications: Software applications deployed at the “edge” of an enterprise—in factories, warehouses, stores, etc—that generate EPCIS events as business process steps are completed.
■ EPCIS Accessing Applications: Software applications at the enterprise level that process EPCIS events to meet enterprise objectives (e.g., the objectives described in Section 2.3 ). An EPCIS accessing application might be a simple connector to a back-end application, or a complex application that carries out some new business task using EPCIS data.
The EPCIS standard defines two interfaces:
■ The EPCIS Capture Interface, by which the EPCIS Capture Applications deliver EPCIS events to an EPCIS Repository (or possibly directly to an EPCIS Accessing Application, in case of real-time processing)
■ The EPCIS Query Interface, by which EPCIS Accessing Applications retrieve previously stored EPCIS event data.
In addition, the following interactions between IT components are typical:
■ Quite often an EPCIS Capture Application receives input from Automatic Identification and Data Capture (AIDC) devices such as bar code scanners and RFID readers (including associated RFID filtering and collection software), especially when the reading of a bar code or RFID tag is the trigger to recognise that a business process step has taken place.
■ An EPCIS Capture Application may interface to one or more back-end applications to obtain relevant business context information, such as product master data or purchase order information about a shipment being received.
■ An EPCIS Accessing Application may interface to one or more back-end applications either to obtain relevant business context information or to deliver new information derived from EPCIS event data (or both).
■ An EPCIS Accessing Application may mediate the exchange of EPCIS data with trading partners.
The GS1 system of standards includes standards to identify, capture, and share information about objects in supply chains. EPCIS fits in as one of the standards in the “share” group, complementing other GS1 data sharing standards for master data and transaction data, as described in Section 2.5 . The standards in the “identify” group provide the identifiers for real-world objects, allowing those objects to be referenced by EPCIS events. The standards in the “capture” group link the physical world to the world of information, and as noted in Section 2.6 they often provide the inputs to EPCIS capture applications.
3 Anatomy of an EPCIS event
The information in an EPCIS event records the essentials of what happened during a step of a business process in which physical or digital objects were handled, expressed via the four dimensions of what, where, when, and why. This section looks in detail at one EPCIS event for a specific business process step to show exactly how those four dimensions are populated. Section 4 goes on to explain how to design an EPCIS for any business process step.
The business process step illustrated in this section is Step V3 from the example process flow described in Section 2.2 . In the overall process, a trade item is manufactured and shipped to the distribution centre of a retailer, which subsequently ships it to a retail store. Step V3 is the step where the trade item is received from the manufacturer at the retailer’s distribution centre. In this example, we will further assume that the trade item is a large consumer product such as a bicycle or a television set; this avoids having to consider complexities such as items packed into cases or cases stacked on a pallet. The shipment in this example consists of a single trade item identified by a GTIN plus serial number.
The EPCIS event for Step V3 includes the following data:
■ The What dimension identifies the product that is received; in this case, using the GTIN and serial number of the product.
■ The When dimension indicates when the receiving operation took place.
■ The Where dimension says where the product was received, namely the distribution centre of the retailer
■ The Why dimension provides the business context. This includes identifying the step of the business process as “receiving,” indicating that the state of the product is that it is progressing normally through the forward supply chain, linking to business transaction documents such as the governing purchase order and invoice, and identifying the parties to the transfer of ownership (i.e., the manufacturer and the retailer).
The following sections discuss the information content of these data dimensions in more detail.
3.1 The What dimension
3.2 The When dimension
3.3 The Where dimension
3.4 The Why dimension
3.5 EPCIS Event types and action
3.6 EPCIS and the Core Business Vocabulary (CBV)
3.7 Putting it together
The What dimension of an EPCIS event identifies the physical or digital objects that were involved in the event. As explained in the GS1 General Specifications and the GS1 Tag Data Standard, trade items are identified using a GTIN, a GTIN plus batch/lot number, or a GTIN plus a serial number. Pallets or logistics units are identified with an SSCC. Other GS1 object identifiers include GDTI for documents, GIAI for individual assets, GRAI for returnable assets, GSRN for services, GCN for coupons, and CPID for components or parts.
In Step V3 of the example, we have a trade item identified by a GTIN plus serial number, also known as a Serialised SGTIN (SGTIN), so the what dimension of the EPCIS event for Step V3 contains the SGTIN of the trade item being received.
The When dimension of an EPCIS event says when the event took place. There are three data elements that are part of this dimension:
■ Event Time: The date and time at which the event took place.
■ Event Time Zone Offset: The time zone in effect at the place and time of the event. This is useful when an application wants to display the event time using the local time; for example, if a package is shipped from California to Brussels, the event time zone offset can be used to display the ship date/time in US Pacific time and the receiving date/time in Central Europe time.
■ Record Time: The date and time when the EPCIS event was recorded into an EPCIS repository. Unlike all other fields in the EPCIS event, the record time is not filled in when the event is captured nor does it describe anything about the business step taking place during the event. Record Time is a bookkeeping mechanism that helps when querying an EPCIS repository; with the record time you can tell whether an event returned from a query is a new event since the time of your last query.
In Step V3 of the example, the Event Time is the date and time when the product was received, and the Event Time Zone Offset records the time zone in effect then and there.
The Where dimension of an EPCIS event captures where the event physically took place and/or where things are following the event.
EPCIS events allow for two location types, readPoint and businessLocation The readPoint is the location where the event took place. The businessLocation is the location where the object(s) is now considered to reside until a subsequent event takes place. Locations may be identified using a GS1 Global Location Number (GLN), a GLN plus an extension, an industry identifier other than GLN or using geo-coordinates.
For example, a box may be scanned as it passes through a door portal. The portal it passes through may be the point in which the event is captured. Someone may be physically standing there reading it through the door, or there may be a door portal reader capturing the event. This would be the readPoint. After the boxes passes through the portal, it now sits in a particular location. This location where the box now sits would be the businessLocation. Locations can be identified at a very fine level of granularity (a specific bin in a specific spot in a warehouse), in which case a GLN plus an extension may be necessary. If a location is described at a more general level (a building), a GLN may suffice. It is important to understand how locations will be identified for the purposes of capturing visibility data.
Note, it is vitally important that the master data about locations are synchronised between internal systems or trading partners so when EPCIS refers to location using a GLN or SGLN, one can be assured that all concerned understand the location in the same way.
In Step V3 of the example, the Read Point is the location where the product was received, which for the purposes of the example we assume to be a specific loading dock door of the Retailer’s D.C., identified by a GLN with extension. The Business Location is the location where the product resides after it is received, which for the purposes of the example we assume to be the Retailer’s D.C. with no specific place within the D.C. identified. The Business Location is in that case identified by a GLN without an extension.
The Why dimension of an EPCIS event describes the business context in which the event took place. It can include any combination of the following data elements:
■ Business Step: identifies what was taking place from a business perspective at the time of the event; that is, what step of a business process was occurring. Examples include “commissioning”, “creating_class_instance”, “inspecting”, “packing”, “picking”, “shipping”, “retail_selling.” The GS1 Core Business Vocabulary (CBV) Standard, discussed further in Section 3.6 , includes a list of standard business step values.
■ Disposition: identifies the business condition subsequent to the event of the physical or digital objects named in the What dimension. Example dispositions include “active”, “in_progress”, “in_transit”, “expired”, “recalled”, “retail_sold” and “stolen.” The GS1 CBV includes a list of standard Disposition values.
■ Business Transaction List: identifies one or more particular business transactions that are relevant to an event. A business transaction is identified by a pair of identifiers: one identifier that says what type of business transaction is referenced, and a second identifier that names the particular business transaction of that type. Examples of business transaction types are purchase order (“po”), bill of lading (“bol”), despatch advice (“desadv”). The GS1 CBV includes a list of standard business transaction type values.
■ Source List and Destination List: is used to provide additional business context when an EPCIS event is part of a business transfer of ownership, responsibility or custody. As with business transactions, a source or destination is identified by a pair of identifiers: the type of the source or destination and an identifier of the source or destination of that type. The GS1 CBV (section 7.4.2) distinguishes three standard source/destination types: “owning_party”, “possessing_party”, “location”.
In Step V3 of the example, the following values might populate the Why dimension of the EPCIS event:
■ Business Step: The business step Receiving defined in the GS1 Core Business Vocabulary.
■ Disposition: The disposition In Progress defined in the GS1 Core Business Vocabulary, indicating that the product is moving normally through the forward supply chain.
■ Business Transaction List: There might be two relevant transactions: the Retailer’s purchase order, and the Manufacturer’s invoice.
■ Source and Destination: The source owning party is the Manufacturer and the destination owning party is the Retailer.
The four dimensions that describe what is happening to an object in the physical or virtual world are captured in one of four types of an “EPCIS Event”. The following is a high level summary of EPCIS event types. For details, see section 7.4 in the EPCIS 1.1 Standard.
■ EPCISEvent: generic base class for all event types.
□ ObjectEvent: represents an event that happened to one or more physical or digital objects. For example shipping or receiving a pallet using the pallet’s SSCC. This is the simplest type of event, as well as the most commonly used.
□ AggregationEvent: represents an event that happened to one or more objects that are physically aggregated together or disaggregated from each other. For example, aggregating cases onto a pallet, or removing cases from a pallet. This is the next most common type of event after ObjectEvent, and these two event types together will cover the vast majority of events in a typical business process.
□ TransformationEvent: represents an event in which input objects are fully or partially consumed and output objects are produced, such that any of the input objects may have contributed to all of the output objects. For example, consider mixing batter and chocolate chips into cookie dough, then baking the dough into a batch of cookies. Once the ingredients are “transformed”, the resulting product is packaged and labelled with an EAN or UPC that represents “consumer package of chocolate chip cookies” and can be scanned at retail.
□ TransactionEvent: represents an event in which one or more objects become associated or disassociated with one or more identified business transactions. For example, linking the pallet and cases of chocolate chip cookies to a commercial invoice.
Each event type (except for TransformationEvent) is also further qualified by the “action”; see Section 4.5 of this guideline for details.
The Core Business Vocabulary (CBV) specifies various vocabulary elements and their values for use in conjunction with the EPCIS standard [EPCIS1.2], which defines mechanisms to exchange information both within and across organisation boundaries. The vocabulary identifiers and definitions are prescribed to ensure that all parties who exchange EPCIS data using the Core Business Vocabulary will have a common understanding of the semantic meaning of that data.
This CBV is intended to provide a basic capability that meets the above goal. In particular, this standard is designed to define vocabularies that are core to the EPCIS abstract data model and are applicable to a broad set of business scenarios common to many industries that have a desire or requirement to share data. It intends to provide a useful set of values and definitions that can be consistently understood by each party in the supply chain.
Additional end user requirements may be addressed by augmenting the vocabulary elements within with additional vocabulary elements defined for a particular industry or a set of users or a single user.
The CBV includes identifier syntax (URI structure) and specific vocabulary element values with their definitions for these Standard Vocabularies:
■ Business step identifiers
■ Disposition identifiers
■ Business transaction types
■ Source/Destination types
■ Error reason identifiers
The CBV provides identifier syntax options for these User Vocabularies:
■ Objects
■ Locations
■ Business transactions
■ Source/Destination identifiers
■ Transformation identifiers
■ Event identifiers
The CBV provides Master Data Attributes and Values for describing Physical Locations, Parties, and Trade Items, including Trade Item master data attributes at the GTIN level, lot level, and instance level.
Putting together the four dimensions of What, Where, When, and Why yields the complete information content of an EPCIS event. The following table summarises the information content of the EPCIS event for Step V3 as discussed above:
Table 3‑1 EPCIS Event Information Content for Step V3 of Example Business Process
Section 4 describes the design process in more detail, showing how this eventually results in EPCIS data conforming to the standard.
4 Designing a Visibility system using EPCIS
Building visibility systems requires both technical understanding of the EPCIS standard and a structured methodology. The following methodology is used to analyse a visibility process from a business perspective regardless of the technology used to capture events. Once a process is fully mapped, visibility events are identified and described. The technical details at the device level are omitted in this guide since we are primarily concerned with the business application of EPCIS data.
The visibility modelling methodology has these steps:
1. Collect visibility goals and requirements
2. Document the business process flows
3. Break each process flow into a series of discrete business steps
4. Decide which business steps require visibility events
5. Model the completion of each step as a visibility event - Understand what information is needed from a business application’s perspective
6. Decide what data fields are to be included in the visibility event
a. Start with standard EPCIS data fields
b. Define extension fields if necessary
7. Determine the vocabularies that populate each data field according to section 7 and 8 of the CBV standard
8. Document the visibility events in a Visibility Data Matrix
We will illustrate these steps using a simple forward logistics example. Later sections of the document describe considerations arising in other scenarios.
4.1 Step 1: Collect Visibility goals and requirements
4.2 Step 2: Document the Business Process flow
4.3 Step 3: Break each process flow into a series of discrete business steps
4.4 Step 4: Decide which business steps require visibility events
4.5 Step 5: Model the completion of each step as a visibility event
4.6 Step 6: Decide what data fields are to be included in the visibility event
4.7 Step 7: Determine the Vocabularies that populate each Data Field
4.8 Step 8: Document the Visibility Events in a Visibility Data Matrix
As more and more requirements are placed on organisations to track and trace the movement of things through the supply chain, it is important to place an emphasis on the overall goals and objectives of deploying a visibility system. “What problem are we trying to solve”?
The goal may be to meet a governmental regulation, or for improving efficiencies in the shipping process, or to ensure a high level of customer service by knowing where something they want is and when it will be delivered to the customer.
Determining the goal and then clearly documenting the requirements to meet the goal is the first step in beginning to think about how to deploy EPCIS. For example, if an organisation is trying to meet a track and trace regulation, it needs to understand what data is required, at which points in the process, where to keep the data, and who and how the data is being sent to another party. Ponce the overall requirements are understood, the detailed process flow and specific data requirements based on EPCIS and the Core Business Vocabulary can be determined.
Let’s take a look at a simplified forward logistic business flow. We will use this business flow in the following sections to illustrate the other steps in the design process.
In this business process we have a manufacturer who is manufacturing goods at his production facility. From the manufacturer’s factory, the goods are then shipped to the retailer’s distribution centre where they are received and stored. From the retailer’s distribution centre the goods are then shipped to the retail store where they are received and sold to the consumer.
Figure 4‑1 Example Business Process Flow
The overall business process flow is as follows:
1. The goods are manufactured and a product is packaged into cases which are in turn packed onto pallets.
2. The products are shipped by truck from the manufacturer’s factory to the retailer’s distribution centre.
3. The products arrive at the retailer’s distribution centre and are received into inventory.
4. The products are shipped from the retailer’s distribution centre by truck to the retail store.
5. The products arrive at the retail store and are received into the stockroom.
6. The products are moved from the stockroom to the sales floor.
7. In the retail store the product will be sold to the consumer.
The process flow of the simplified forward logistics example is shown in the following diagrams. The blue arrows show the flow, and the white rectangles each represent a single step in the process. As time moves from left to right, the horizontal axis also shows the locations involved as the product moves from one location to another.
In this example, there is an aggregation hierarchy where items are packed into cases, cases are packed into pallets, and pallets are loaded onto trucks. In such cases, it is often helpful to use the vertical axis to show at which hierarchy level each step takes place. If a process flow only works at a single level of aggregation, the corresponding diagram might be completely horizontal, or the vertical axis could be used to highlight some other aspect of the flow. At this stage, the idea is to be as clear as possible about the individual steps of the flow.
Not every step in these flow charts will lead to an EPCIS event; that is addressed in the next section.
Figure 4‑2 Forward Logistics Process Flow, Diagram 1 of 2
Figure 4‑3 Forward Logistics Process Flow, Diagram 1 of 2
Not every business step in a business process requires a visibility event. The decision about whether a given business step needs an event is typically a trade-off between what data is valuable to have and what data is feasible to collect.
Questions about what data is valuable to have include:
■ Will having detailed visibility event information about this step of the process provide useful input to some business application?
■ Is information about this step of the process required in order for an application to understand information about another step? For example, if an event at the “shipping” step includes a pallet ID, it might also be necessary to capture an earlier event at the “packing” step so that an application knows the content of the shipped pallet.
■ Is information about this step of the process required by a trading partner or by a government regulation?
Questions about what data is feasible to collect include:
■ Do the physical or digital objects involved in this step of the process have suitable identifiers? If not, is it feasible to give them identifiers?
■ For physical objects, is it feasible to affix the identifiers using a data carrier such as an RFID tag or bar code? If not, will it be possible to capture the identifier some other way?
■ Is it feasible to modify the operational process to include data capture of the visibility event? Considerations here include the cost of the necessary infrastructure (bar code scanners, RFID readers, software, etc.) and the impact on process itself (is additional labour needed, will the process slow down, etc.).
In the example, we will assume that from a business perspective it is essential to know what is shipped and received at each location. In many cases, it is also necessary to have a record of what is “commissioned”; that is, to capture an event each time a new identifier is created. But we will also assume that it is only feasible to capture data at the case and pallet level, not at the item level. We will also assume that the trucks used to move the pallets do not carry identification, and that it would not be feasible to track which trucks are used anyway.
Putting that together, this leads to capturing visibility events at the following steps in the Manufacturer’s portion of the example:
■ V1: Print and apply case label (commissioning – needed so that later steps are understandable)
■ V2: Print the pallet label (commissioning – needed so that later steps are understandable)
■ V3: Pack cases into pallet (needed so that the content of the shipment can be inferred from reading just the pallet identifier)
■ V4: Ship the pallet
These are indicated in the diagram with red circles numbered V1, V2, etc. Other steps in the diagram not carrying circles are steps for which no visibility events are captured.
Figure 4‑4 Forward Logistics Process Flow with Visibility Capture Indicated
Now we begin to design the EPCIS data that will capture what happens in the selected steps of the business process. The first step is to decide what event type best fits the situation at hand, from the list of event types as described in Section 3.5 . The event type will determine the structure of the information in the What dimension of the event.
To choose the event type, consider what physical or digital objects are involved in the event and how they relate to each other. Most often, you will choose one of the following three event types:
■ ObjectEvent: Use this if there were one or more objects involved in your event, and all the objects participated in the event in the same way. This is by far the most common event type.
■ AggregationEvent: Use this if your event involves a physical aggregation involving a “parent” object and one or more “child” objects. An example of an aggregation is 12 items (the “children”) packed into a carton (the “parent”). Other examples of aggregation include cases on a pallet, items in a tote, cartons loaded into a truck, containers loaded onto an ocean vessel, and components installed in an assembly. In all of these examples, each child retains its identity even while aggregated to the parent, and the aggregation is reversible (that is, it may be “disaggregated”).
■ TransformationEvent: Use this if your event is a process in which one or more “input” objects are consumed and one or more “output” objects are produced. Unlike an aggregation, where the children can later be separated from a parent, in a transformation the input objects no longer exist after the event. Examples of transformations include mixing raw materials to create a finished recipe, repackaging items such that the original package no longer exists and a new GTIN labels the new package, and smoking salmon to transform raw fish into smoked fish.
The fourth event type, the TransactionEvent, can be used if your event if a process in which one or more objects are definitively associated with (or disassociated from) one or more business transactions. However, because business transactions can be included in the Why dimension of all the other event types, there is seldom a need to use the TransactionEvent type.
The ObjectEvent and AggregationEvent types have an additional qualifier, the action, which says how the event relates to the lifecycle of the object and the aggregation, respectively. Specifically:
■ For an ObjectEvent the action values are:
□ ADD if the event marks the beginning of the life of the object. No other events for the same objects should precede this one. This is most often used when the business step is “commissioning.”
□ DELETE if the event marks the end of the life of the object. No other events for the same objects should follow this one. This is most often used when the business step is an end-of-life step such as “decommissioning,” “destroying,” or a business step involving sale to a consumer (if there is no possibility to track the object post-sale).
□ OBSERVE in all other cases.
■ For an AggregationEvent the action values are:
□ ADD if children are added to the aggregation during the event; e.g., when packing items into a case.
□ DELETE if children are removed from the aggregation during the event; e.g., when unpacking items from a case.
□ OBSERVE if the parent and children are in a state of aggregation during the event but no children are added or removed.
The TransactionEvent also has an action qualifier; see the EPCIS standard for details. The TransformationEvent does not have an action qualifier.
Here is how event types would be assigned to events V1 through V4 of the example from the previous section:
Table 4‑1 Assignment of Event Types to Business Process Steps in Example Business Process
In the V4 event, there is a choice in how to record the act of shipping the pallet as an EPCIS event. One approach is to use an ObjectEvent (with action OBSERVE) and include only the SSCC of the pallet in the What dimension. This makes the data capture easier, and results in a more compact event, but it means that applications receiving the data will need to consult the V3 event too if they need to infer what cases were on the pallet that was shipped. An alternative approach is to use an AggregationEvent (with action OBSERVE) and include both the SSCC of the pallet (the parent) and the SGTINs of all the cases (the children) in the What dimension. This approach makes sense if it is feasible to know the case SGTINs at the time the pallet is shipped, and if the Manufacturer wishes to be explicit about exactly which cases are on the pallet at that time. Applications receiving V4 would not need to make any inferences using V3 to know what cases are on the pallet.
The V4 example illustrates the subtle choices that sometimes must be made in deciding how to model business processes using EPCIS. To assist in such situations, it is helpful to consult industry sector-specific guidelines that provide standard EPCIS models for business processes commonly arising in those sectors.
Once the basic event types are decided upon, the next task is to decide what data to include in the What, When, Where, and Why dimensions of each event. It is tempting to approach this from the perspective of what information is available to your capturing application, such as what data comes out of an RFID reader or bar code scanner. However, EPCIS data is much more useful if you approach it from the opposite direction, namely from the perspective of a business application consuming the data. The question to ask yourself is: “what information does a business application need to understand what happened during this event?” The business application doesn’t need to know how the data was captured; it needs to know what happened from a business perspective.
A good way to proceed is to consider each of the four data dimensions in turn.
4.6.1 Designing the What Dimension
The What dimension identifies the physical or digital objects involved in the event. The structure of the information in the What dimension depends on the event type:
■ For an ObjectEvent, the What dimension contains a list of objects. All objects participate in the event in the same way.
■ For an AggregationEvent, the What dimension names a specific object as the “parent” and contains a list of other objects as the “children.” (There are two exceptions. If the action is OBSERVE the parent may be omitted, indicating that the children were observed in a state of aggregation but the identity of the parent is unknown. If the action is DELETE the children may be omitted, indicating that all children are disaggregated from the parent.)
■ For a TransformationEvent, the What dimension includes one list of objects that are the inputs to the transformation, and a second list of (different) objects that are the outputs of the transformation. (If a TransformationEvent is connected to other TransformationEvents through the TransformationID, it may omit either the inputs or the outputs; see Section 5.5.2 .)
Besides considering which objects involved the business process step are relevant to the event, you also have to determine how those objects will be named in the event. In EPCIS there are two different ways to refer to an object:
■ Instance-level Identification: If an object has an identifier that is unique to that particular object, it is called instance-level identification. Examples of instance-level identification include a Global Trade Item Number (GTIN) with a serial number (together called a Serialised GTIN, or SGTIN), a Serial Shipping Container Code (SSCC), a Global Returnable Asset Identifier (GRAI) that includes a serial number, and so on.
■ Class-level Identification: If an object has an identifier that is identical to the identifier carried by other, similar objects, it is called class-level identification. Examples of class-level identification include a GTIN plus a batch or lot number (shared by all trade items belonging to the same batch or lot), a GTIN by itself, a GRAI without a serial number, and so on.
Instance-level identification is the most powerful in terms of how EPCIS data can be used by applications, because instance-level identification makes it possible to recognise that an object referenced in one event is the very same object as an object referenced in a prior or subsequent event. On the other hand, assigning instance-level identification to objects is usually a more complex business process than assigning class-level identification.
When class-level identification is used there may be more than one object involved in the event from the same class, so a class-level identifier is usually accompanied by information that specifies the quantity. Including instance-level identification, this results in four ways an object could be identified in the What dimension of an EPCIS event:
Table 4‑2 Class and Instance Level Object Identification
The last case in the table, a class-level identifier with no quantity information, should only be used rarely, when it is impossible to determine the quantity or if the quantity is to be withheld for privacy reasons.
The same EPCIS event might have some objects identified using instance-level identification and others identified using class-level identification. For example, cases identified by GTIN and lot (class-level) could be aggregated to a pallet identified by SSCC (instance-level), or there could be a transformation event where some inputs are raw materials identified by class and quantity, other inputs are identified by GTIN+serial number (instance-level), and the outputs are identified by GTIN+serial number. However, a given object should only be identified one way in an event. For example, if an object event has five SGTINs which are different serial numbers for the same GTIN, the object event should include those five SGTINs but not also include the GTIN as a class-level identifier.
4.6.2 Designing the When Dimension
The When dimension is the most straightforward of the four dimensions. It is required in every event, and always contains two pieces of information:
■ EventTime: The date and time at which the event occurred. This is always expressed in a format that includes a time zone specifier, so that it unambiguously identifies a moment in time.
■ EventTimeZoneOffset: The time zone offset (relative to UTC) that was in effect at the place where the event took place. This allows the EventTime to be displayed to users in the local time where the event happened, if desired.
The correct value to use for these two data elements is usually quite obvious and so there is little design work to be done.
For a business step that takes place over a long interval of time, there may be some question as to whether EventTime should be the moment when the step begins or ends, or some moment in between. Usually, the ending time of the business step is the most appropriate. But as with all EPCIS data design questions, it should be considered from the perspective of a business application consuming the data. If it is important to business applications to know both the starting time and the ending time of a business step, you should consider whether it would be more appropriate to model the process using two EPCIS events, one for the start of the process and one for the end.
Conversely, sometimes there are several different events from a business perspective which are carried out simultaneously or in a way that would make it difficult to assign a different EventTime for each. For example, an automated manufacturing machine might assign SGTINs to twelve products (“commissioning” business step), assign another SGTIN to a case (“commissioning” again), and pack the items into the case (“packing” business step), all at once. It may not be physically all at once, but the EPCIS Capturing Application built into the machine may not have any way to distinguish the times. In such cases it may be appropriate to assign the identical event time to all EPCIS events generated, but if there is a logical sequencing of the events it is usually much better for consuming applications if the event times are slightly altered so that the chronological order is logical. In the items-into-case example, the EPCIS event for “packing” (the aggregation event) should have an event time that is later than the commissioning events, even if it is artificially set to a time only one millisecond later. This allows consuming applications to order the events by their EventTime to arrive at a logical sequence.
4.6.3 Designing the Where Dimension
The Where dimension identifies the physical location of objects in the event. The two data elements in the Where dimension are both optional, but most EPCIS events will include them. The two data elements are:
■ ReadPoint: The ReadPoint identifies where the objects named in the What dimension were at the time of the event; that is, where the event took place.
■ BusinessLocation: The BusinessLocation identifies where the objects named in the What dimension are expected to be following the event, until another event says otherwise.
The names ReadPoint and BusinessLocation can be a little confusing. For example, the ReadPoint could be just as relevant from a business perspective, or more so, than the BusinessLocation, depending on the situation. Instead of trying to read meanings into the names “read point” and “business location”, just remember the definitions: ReadPoint is the location of the objects at the time of the event, BusinessLocation is the location afterwards.
The difference between ReadPoint and BusinessLocation can be visualised by imagining a facility having several rooms connected by doorways, like this:
Imagine that an EPCIS event is captured whenever an object moves through one of the doorways; e.g., by an RFID reader stationed at each door. Imagine an object moves from Room 1 to Room 2 by passing through Door A. In this case, the ReadPoint (the location at the time of the event) is Door A and the BusinessLocation (the location afterward) is Room 2. Note that the object might move around within Room 2 without generating any new EPCIS events, so at the time it moved into Room 2 all we know about where it is afterwards is that it is somewhere within Room 2. If instead the object had moved from Room 1 to Room 2 via Door B the BusinessLocation would still be Room 2 but the ReadPoint would be Door B. On the other hand, if the object later moves in the opposite direction through Door A the ReadPoint would again be Door A but the BusinessLocation would be Room 1.
The reason it is useful to have BusinessLocation is that it helps to answer the question “where is the object right now?” If you happen to ask that question right at the moment an event takes place then the ReadPoint tells you that, but at any other time the BusinessLocation of the most recent event is the best available approximation to location of the object right now. At the same time, ReadPoint is useful because it tells you something about the past: “where was the object when X happened to it?” (where X is described by the Why dimension of the appropriate event).
A key question in designing the Where dimension is to decide at what granularity you will describe location. For example, if an object enters through a loading dock door during a receiving operation, there are several ways you could describe the location of the event (the ReadPoint), listed here from most specific (finest granularity) to least specific (coarsest granularity):
■ “Receiving Dock #5 in Building 2 of the Chicago campus of XYZ company”
■ “The receiving area in Building 2 of the Chicago campus of XYZ company” (specific door not specified)
■ “Building 2 of the Chicago campus of XYZ company” (specific area within Building 2 not specified)
■ “The Chicago campus of XYZ company” (specific building not specified)
■ “XYZ company” (specific location not specified)
Deciding what level of granularity to include in an EPCIS event is a key decision. As with most EPCIS design decisions, it will be a trade-off between what business applications need to make use of the data and what it is feasible to collect when the EPCIS event is captured. For example, distinguishing between different loading dock doors in a building may require more expensive infrastructure than just knowing that an object has entered the building. At the same time, it might not be important for business applications to know what specific door was used. Sometimes, the question of granularity is answered differently in designing EPCIS events as they are captured internally versus how they are shared with trading partners. For example, the ReadPoint might be captured internally at the level of individual loading dock doors, but then redacted to the “building” level when sharing the same event with a trading partner. (See also Section 6.7 .)
It is common for the BusinessLocation to be expressed at a coarser level of granularity than the ReadPoint, simply because an EPCIS capturing application has less certainty about where an object might be following an event compared to where it is at the moment the event takes place. It is also common for ReadPoint to be at the same level of granularity as BusinessLocation when there is no business need to express ReadPoint with any finer precision.
A special case for BusinessLocation occurs when objects are transferred from one location to another, as in shipping followed by receiving. When the object is shipped, the location of the objects following the event is obviously not the location of the shipper. But it is also not the location of the receiver, because it is only after the event captured during receiving that the object is located at the receiver. Therefore, the correct BusinessLocation for the EPCIS event captured at shipping is “unknown” – at the time of shipping, it is unknown where the object will be until the receiving operation takes place. This is expressed in EPCIS by omitting the BusinessLocation data element entirely from the shipping event.
4.6.4 Designing the Why Dimension
The Why dimension explains the business context for the event, and is crucial for business applications to make sense of EPCIS data. All of the data elements in the Why dimension are optional, but almost all EPCIS events will include at least the BusinessStep and BusinessLocation data elements. The other data elements in the Why dimension are included only when they are relevant to the business step being carried out.
The definitions of the data elements in the Why dimension were given in Section 3.4 . Here are design considerations for choosing whether to include each data element, and how to choose the appropriate values.
4.6.4.1 Designing the Business Step
The BusinessStep data element is the most important when it comes to a business application understanding what EPCIS data means. The BusinessStep value is an identifier that says what step of the business process was taking place at the time of the event. Without the business step an application only knows that an object existed at a particular place ant time; with the business step an application knows how that object relates to the overall business. Practically all EPCIS events should have a BusinessStep value. The BusinessStep value usually corresponds to a verb of some kind: shipping, receiving, packing, etc.
In order for business step values to be useful, they must have a meaning that is known in advance to the applications that will see them. For this reason, the value for BusinessStep is always defined by a standard of some kind – a document that maps a given BusinessStep value to an explanation of what the value means and how to interpret the EPCIS event carrying that value. The EPC Core Business Vocabulary (CBV) is one such standard. It is a global standard that defines several dozen business step values that apply to a variety of business steps commonly occurring in supply chain business processes across many industry sectors. Because it is a global, cross-sector standard, using CBV business step values makes an EPCIS event intelligible to the widest set of applications. When a CBV business step value is applicable, it should be used.
Sometimes, however, you may be using EPCIS in a business process that includes a step that does not fit very well with any of the business step values defined in the CBV. In such cases, a different identifier must be used, one that you create yourself for the specific application. There will still be a document that defines the identifier and its meaning – in this case the document is an internal design document rather than a global standard. Specific business step values may also be defined across a group of trading partners, or by a sector-specific standard. However, all such values will result in EPCIS events that can only be understood within the smaller group of organisations that is aware of the narrower standard or design document that defines them. This is a trade-off that must be considered when deciding whether to use the CBV or not.
Section 4.7 describes how to create an identifier not defined in the CBV so as to avoid conflicts.
4.6.4.2 Designing the Disposition
The Disposition value is an identifier that indicates the business condition of the objects following the event. The Disposition value usually corresponds to an adjective that describes the business state of the objects as it relates to the overall business process: in_progress, recalled, damaged, etc.
A key use of the Disposition is to note the difference between normal flow and exceptions. For example, the Core Business Vocabulary (CBV) disposition value “in_progress” indicates objects that are moving normally through the supply chain and “recalled” indicates objects that have been recalled to the manufacturer. Having a Disposition separate from BusinessStep helps model such situations in two ways. One, at the time of an event that is subject to exceptional outcomes, the Disposition can express which outcome occurred. For example, there may be an EPCIS event with BusinessStep “inspecting” (from the CBV) where the outcome of the inspection is either Disposition “in_progress” in the usual case or “recalled” if the inspection discovers the object is subject to recall. Two, the Disposition can continue to indicate the exceptional state even as the objects are subjected to further events. For example, following the “inspecting” step a recalled object might have several EPCIS events with BusinessStep values “shipping” and “receiving” as the object works its way upstream to the manufacturer. Without Disposition these EPCIS events would be difficult to distinguish from ordinary shipping and receiving steps, but with a Disposition value of “recalled” instead of “in_progress” it becomes clear that these events are part of a reverse logistics process.
As with BusinessStep, values of Disposition are only useful if their meaning is known in advance to the applications that will see them. For this reason, all of the comments in Section 4.6.4.1 apply equally to Disposition values.
4.6.4.3 Designing the Business Transaction List
The BusinessTransactionList is a list of references to business transactions – data that are available from other systems besides EPCIS. Examples of a business transaction include: a reference to a specific purchase order, a reference to a specific invoice, and so forth. This information provides business context for an EPCIS event and helps link EPCIS data with other business information systems.
Each business transaction in the BusinessTransactionList consists of a pair of identifiers. The first is the business transaction type identifier, which says what kind of business transaction is being referenced (purchase order, invoice, etc.). The second is the business transaction identifier that references the specific transaction of the specified type.
Business transaction type identifiers are similar to BusinessStep or Disposition values in that they are useful only if their meaning is known in advance to the applications that will see them. For this reason, all of the comments in Section 4.6.4.1 apply equally to business transaction type values. The Core Business Vocabulary defines standard business transaction type identifiers for common business transaction types such as purchase order, invoice, etc.
The second part of a business transaction reference, the business transaction identifier, refers to a specific business transaction. Unlike business step, disposition, or business transaction type values there is not a fixed list of business transaction identifiers – new identifiers are constantly created as new business transactions are created. Typically, a business transaction identifier is generated by some information system other than EPCIS; for example, an invoice number might be created by an Enterprise Resource Planning (ERP) system.
A business transaction identifier must be globally unique in order to be used in an EPCIS event. This is because in processing EPCIS data an application might gather EPCIS events from across the supply chain. In that situation, it is essential that two purchase orders from different parties in the supply chain cannot be confused.
There are two strategies for creating globally unique business transaction identifiers suitable for use in an EPCIS business transaction list. One is for the system creating the business transaction to use a globally unique identifier as the only way it refers to the transaction. For example, an ERP system might natively assign a unique identifier such as a GS1 Global Document Type Identifier (GDTI). If assigned correctly, a GDTI issued by one system will be different than a GDTI generated by any other party’s system. Many legacy systems, however, are not designed to do this – a typical ERP system will simply give each transaction a number like 12345, which is unique within the context of that ERP system but not guaranteed to be unique compared to the numbers generated by another ERP system.
The second strategy for creating a globally unique business transaction identifier is to combine the identifier created by a legacy system with a prefix that makes it globally unique. The EPC Core Business Vocabulary specifies a template that may be used for this purpose which uses the Global Location Number (GLN) of the issuing party. For example, if Company X has a party GLN of 0614141123452 and its ERP system issues purchase order #12345, the corresponding globally unique identifier using the CBV template is:
urn:epcglobal:cbv:bt:0614141123452:12345
The first part of this identifier, urn:epcglobal:cbv:bt:, is a prefix indicating that the CBV’s business transaction identifier template is used. The remaining two components are the GLN and the PO number assigned by the ERP system, respectively. The entire string considered as a single identifier is globally unique, because PO #12345 from any other ERP system would be given a different prefix. (If one company has multiple ERP systems, and there is the possibility that their assigned transaction numbers will collide, a different GLN should be used as the prefix for each system.)
When processing EPCIS data, the entire business transaction identifier, including any prefixes, should be used. For example, to test whether two EPCIS events make reference to the same business transaction, the entire identifier strings should be compared (along with the business transaction type identifiers). However, when relating EPCIS data to legacy system data, it may be necessary to recognise the CBV prefix and parse the identifier to identify which legacy system is referred to and what is the native transaction ID for that system.
4.6.4.4 Designing the Source and Destination Lists
Certain business process steps are part of a process of business transfer where ownership and/or physical possession passes from one party to another. Shipping and receiving are two common examples, but there may be others such as consigning, accepting, returning, intermediate transportation steps, and so on. In such cases it is often useful to include information that identifies both ends of the transfer. For example, in a shipping event it is useful not only to indicate the “ship from” location but also the “ship to” location. It may also be useful to indicate the parties involved at both ends, both from an ownership perspective as well as a physical possession perspective, which may or may not be the same pair of parties. The source and destination lists in an EPCIS event may be used to provide this information. Source and destination information is part of the why dimension of an EPCIS event, as it serves to provide business context.
The source list consists of a list of sources, each of which is a pair consisting of a source type and a source identifier. Likewise, the destination list consists of a list of destinations, each a pair of a destination type and a destination identifier. There are three possible source or destination types defined in the Core Business Vocabulary; each says how to interpret the source or destination identifier that it qualifies:
Table 4‑3 Source/Destination Types Defined in Core Business Vocabulary
The source or destination identifier itself is a globally unique identifier for a party or physical location, depending on the source/destination type. Often this is a GLN (with or without extension) in EPC URI format, but the CBV also specifies other identifiers that could be used.
Any combination of the three source/destination types may be used in either the source list or destination list or both, according to what business context is available. Typically, both a source and a destination of a given type are included.
A complete business transfer typically extends across multiple EPCIS events, often generated by more than one party. For example, a very simple transfer would include one EPCIS event for the shipping step and a second EPCIS event for the receiving step. A more complex transfer might involve separate arriving and accepting steps, for example, or tracks intermediate in-transit steps such as observing a rail carrier or ocean carrier during its passage. All such steps belonging to the same transfer could include source/destination information. When this is the case, the source/destination information is usually the same on all events.
For example, in a transfer of possession from Party A to Party B, both the shipping and receiving EPCIS events could include a source of type “possessing party” for Party A and a destination of type “possessing party” for Party B. The interpretation of the source/destination information on the two events is subtly different. In the shipping event, the source indicates the known possessing party at the origination of the transfer but the destination indicates the intended possessing party at the termination of the transfer. In the receiving event, the destination indicates the known possessing party at the termination of the transfer and the source indicates the believed possessing party at the origination of the transfer.
A source or destination of type “location” may coincide with read point information in the where dimension for certain events. Specifically, the read point in a shipping (or similar) step coincides with the source of type “location,” and the read point in a receiving (or similar) step coincides with the destination of type “location.” In such cases, the information in the source/destination should be consistent with the information in the read point. (It might not be identical if, for example, the read point is reported using a more granular location identifier than the source or destination.)
An EPCIS event that is not part of a business transfer should not include source/destination information.
See Section 5.2 for an example scenario that uses the source/destination list.
4.6.5 Example
Putting together all of the material in this section, let’s illustrate how we would design the EPCIS event for Event V4 of the example from Section 4.4 . In this event, a pallet containing several cases is shipped from the Manufacturer to the Retailer’s Distribution Center.
As noted in Section 4.5 , this event could be represented as an ObjectEvent naming just the pallet, or as an AggregationEvent naming both the pallet and the cases. We will assume the ObjectEvent approach in this illustration.
Table 4‑4 EPCIS Event Information Content for Step V4 of Example From Section 4.4
In the previous step, you determined what you want the data elements of each EPCIS event to say. The next step is to translate the informal description of each data element’s contents into a specific identifier that a computer can understand. The place to start is Sections 7 and 8 of the Core Business Vocabulary.
4.7.1 Vocabularies for the What dimension
In the What dimension, you have references to one or more physical or digital objects. Most of the time, each object will be identified by a GS1 Key. For example, a trade item might be identified by a GTIN (example: 00614141123452) and a serial number (example: 400). In EPCIS, the GTIN plus serial number is represented as a Uniform Resource Identifier (URI) according to the EPC Tag Data Standard. It looks like this:
urn:epc:id:sgtin:0614141.012345.400
The first part of this identifier (urn:epc:id:) indicates that this identifier follows the EPC Tag Data Standard. The next part (sgtin:) says that it is a GTIN plus serial number (SGTIN). The next three parts are the GS1 Company Prefix (0614141), Indicator Digit and Item Reference (012345), and the serial number (400). Note that in the EPC URI, the GS1 Company Prefix is written separately from the other digits of the GTIN and there is no check digit.
The EPC Tag Data Standard, Sections 6 and 7, provides EPC URI syntax for all of the GS1 Keys that can be used in the What dimension of an EPCIS event. Sometimes you need to refer to a physical or digital object in the What dimension but the object is identified using some identification system not supported by the EPC Tag Data Standard. For those situations, the Core Business Vocabulary (Sections 8.2 and 8.3) provides other (non-EPC) URIs that can be used. However, GS1 Keys are preferred whenever possible.
4.7.2 Vocabularies for the Where dimension
The ReadPoint and BusinessLocation data elements in the Where dimension contain identifiers that refer to physical locations. To choose an appropriate identifier, you must first decide how locations will be identified.
The most common way to identify a location is to give it a unique identifier such as a Global Location Number (GLN). A GLN is just an arbitrary number that the owner of a location designates to refer to a specific location. A GLN can be assigned at any level of granularity (see Section 4.6.3 ), and you can even assign a GLN to a fine-grain location such as a room in a building and also assign a different GLN to a coarse-grain location such as the building itself. When this is done, GLNs fall into a hierarchy.
When assigning identifiers to very fine-grain location such as individual loading dock doors or individual bins in a large warehouse, the GLN by itself does not have sufficient capacity. In such situations each location can be assigned a GLN plus a GLN extension. When a GLN+extension is assigned to a fine-grain location, the GLN part is usually the GLN of a coarser-grained containing location, such as the containing building.
As in the What dimension, URI syntax is used in EPCIS for the identifiers in the Where dimension. For example, suppose a location is identified by GLN 0614141111114 and extension 987. In EPCIS, the GLN+extension is represented as a Uniform Resource Identifier (URI) according to the EPC Tag Data Standard. The specific type of URI is called an SGLN, which is capable of representing either a GLN+extension or a GLN without extension. The SGLN for GLN 0614141111114 and extension 987 looks like this:
urn:epc:id:sgln:0614141.11111.978
To represent a GLN without an extension, a single 0 digit is used in place of the extension, like this:
urn:epc:id:sgln:0614141.11111.0
The first part of this identifier (urn:epc:id:) indicates that this identifier follows the EPC Tag Data Standard. The next part (sgln:) says that it is either a GLN or GLN+extension (depending on whether the extension part is 0 or not). The next three parts are the GS1 Company Prefix (0614141), Location Reference (11111), and the extension (or 0 for a plain GLN). Note that in the EPC URI, the GS1 Company Prefix is written separately from the other digits of the GLN and there is no check digit.
Sometimes you need to refer to a physical location in the Where dimension but the location is identified using some identification system not supported by the EPC Tag Data Standard. For those situations, the Core Business Vocabulary (Section 8.4) provides other (non-EPC) URIs that can be used. However, GS1 Keys are preferred whenever possible.
On the other hand, sometimes a location can only be identified by geospatial coordinates—latitude and longitude—rather than by a unique identifier. The most common case for this is as a ReadPoint when tracking a vehicle such as an ocean vessel while in transit, where there are no pre-defined locations that could be identified by GLN on the open ocean but a Global Positioning System receiver is available. In this case, a geospatial URI may be used. It looks like this:
geo:22.300,-118.44
This example denotes the geographic location with latitude 22.300 degrees (north) and longitude 1032 118.44 degrees (west). For more details, see the Core Business Vocabulary Section 8.4.4.
4.7.3 Vocabularies for the Why dimension
The Why dimension of an EPCIS event contains many data elements that require identifiers of various kinds. There are two ways this is done depending on the data element.
4.7.3.1 Standard Vocabulary Elements for the Why dimension
Some data elements in the Why dimension contain names of concepts that all parties in the supply chain must understand in advance. An example is the BusinessStep data element, which contains an identifier representing a concept such as “shipping,” “receiving,” etc. These identifiers are always defined in a standard of some sort, and the most commonly used standard for this purpose is the Core Business Vocabulary.
Section 7.1 of the Core Business Vocabulary defines over 30 different business step values. The full value as it appears in an EPCIS event is a URI, and it looks like this:
urn:epcglobal:cbv:bizstep:shipping
The first part of this identifier (urn:epcglobal:cbv:) indicates that it is defined in the Core Business Vocabulary. The next part (bizstep:) says that it is an identifier from the list of business step values. These two parts are the same for all the business step identifiers defined in the CBV. The remainder is the specific business step.
To select the appropriate business step value, consult the definitions given in the CBV. For example, the CBV defines urn:epcglobal:cbv:bizstep:packing to mean “a specific activity within a business process that includes putting objects into a larger container – usually for shipping. Aggregation of one unit to another typically occurs at this point.”
In some situations, there is no CBV identifier that is appropriate. In this case, you can create your own identifier, but it should still be in URI syntax and use a prefix that is under your control. For most purposes, this means using an HTTP URI that uses your Internet domain name. For example, if you are the Example Corporation with a domain name example.com and you need a new business step for “fiddling,” you could use a URI like this:
http://epcis.example.com/bizstep/fiddling
The fact that this begins with http://epcis.example.com/ means that it will not conflict with a CBV identifier, nor with a private identifier created by any other organisation. If a trade organisation creates a private identifier for a standard it creates, the Internet domain name of the organisation could be used as the root. As noted in Section 4.6.4.1 , if you create a private business step like this you will have to inform trading partners what it means, so this is less interoperable than using one defined in the CBV.
Note that while the above identifier looks like something you might type into a web browser, as far as EPCIS is concerned it is just an identifier for a business step and there does not have to be a web page accessible via that URI. On the other hand, a web page with that URI might be a very good place to provide documentation for humans about what your business step means.
Several other data elements in the Why dimension work the same way; they are summarised below.
Table 4‑5 Examples of Standard Vocabulary Identifiers Defined in Core Business Vocabulary
For all of these data elements, the best choice is to use one of the identifiers defined in the CBV, but if this is not possible a private identifier can be constructed as illustrated above.
4.7.3.2 User Vocabulary Elements for the Why dimension
Some data elements in the Why dimension identify business objects such as business transactions, sources, destinations, and transformation identifiers. For these data elements, the Core Business Vocabulary provides templates that can be used to construct suitable identifiers.
A key consideration here is that identifiers in any dimension of an EPCIS event should be unambiguous. This is especially important when EPCIS events are brought together from across a supply chain. Suppose that the BusinessTransaction data element in an EPCIS event in a shipping step contains a reference to a purchase order. It is not sufficient for the EPCIS event to simply say “PO # 1234” because many companies within the supply chain might issue a purchase order with that same number. In an EPCIS event, a reference to a purchase order must be globally unique.
The Core Business Vocabulary solves this by providing a template for constructing a globally unique identifier. It looks like this:
urn:epcglobal:cbv:bt:0614141111114:1234
The first part (urn:epcglobal:cbv:) says that this is an identifier constructed according to rules found in the CBV. The next part (bt:) says that this is the template for a business transaction (BT). Following this is the GLN (0614141111114) of the party that defines the PO #, and the last part (1234) is the PO # as defined by that party. In this way, if some other party in the supply chain also had a PO numbered 1234, the EPCIS identifier would be different because a different GLN would precede the 1234 in the identifier.
Some large companies have more than one system that generates purchase orders, e.g. a different system for each division of the company, so there is a possibility of having two purchase orders numbered 1234 from the same company. But this is easily handled by using a different GLN to prefix the PO #s of the two systems; e.g., by using the division-level GLN.
This is one of several ways of constructing globally unique business transaction identifiers defined in the CBV (Section 8.5). Another way is to use a GS1 Key such as a GDTI (including serial number). This works if the system that generates the business transaction is already using a GS1 Key as the numbering system. The CBV also shows how to use a private prefix to create business transaction identifiers, though these methods are seldom used.
Advanced use of EPCIS Transformation Events sometimes requires a “Transformation ID” to link together multiple events. Section 8.7 of the CBV describes ways of constructing Transformation IDs, including a GLN-based method similar to the above.
Source and Destination identifiers are described in Section 8.6 of the CBV. Most commonly, these are populated with GLNs, and so SGLN EPC URI format is used just as for location identifiers (Section 4.7.2 ).
4.7.4 Example
Putting together all of the material in this section, here is how the design choices made in Section 4.6 would be finally realised as actual identifiers in the EPCIS event.
Table 4‑6 Example Assignment of Identifiers for EPCIS Event From Section 4.6
You must complete Steps 5 through 7 for every one of the business steps you identified in Step 4. This sounds tedious, but typically you will find there is quite a bit of repetition and so it gets easier after the first three or four events.
When you are all done, summarise the results in a matrix that has a column for each visibility event and a row for each data element in the EPCIS data model. This looks like the tables in the previous section, extended to have a column for each event. A spreadsheet is a good tool to create this matrix.
Here’s what a matrix might look like for events V1 through V4 in our example:
Table 4‑7 Example Visibility Data Matrix
This example matrix shows the event content described in words, as we did in Step 6. It would also be appropriate to include examples showing the specific identifier choices made in Step 7 (omitted here for reasons of space).
The next section provides some further examples of how to design EPCIS events for specific situations.
5 Advanced EPCIS Modelling
5.1 Aggregation/Disaggregation
5.2 Drop Shipment
5.3 Class-Level Tracing
5.4 Instance/Lot Master Data (ILMD)
5.5 Transformation
5.6 Coupons and Vouchers
5.7 Returnable Asset Management Using GRAI
5.8 User/Vendor Extension Elements
5.9 Erroneous events
Many business processes involve creating physical aggregations, where child object are packed into or onto a parent object. An aggregation has the following characteristics:
■ When in a state of aggregation, the parent object and children objects may be assumed to be at the same place at the same time.
■ The parent object and children objects retain their identity while in a state of aggregation. The aggregation may be reversed (disaggregated), so that the original parent and/or children objects are separate. This is in contrast to a transformation, in which inputs are irreversibly converted into outputs having a different identity (see Section 5.5 ).
Examples of commonly occurring aggregations including the following:
Table 5‑1 Examples of Commonly Occurring Aggregations
The examples above all assume the child objects are identified with instance-level identification, but it is also possible to have children identified with class-level identification. The parent, however, must always be identified with an instance-level identifier.
A common reason for tracking aggregations is to allow for inference, in which a business application infers that all aggregated objects are present when only one is observed. For example, in the example from Section 4, the EPCIS event for the shipping step only included the SSCC of the pallet, but the receiver may infer that all of the cases were shipped, too. In making this inference, the receiver is relying on (a) having the EPCIS event for the packing step, in which the aggregation is created; and (b) knowing that there are no disaggregation events between the packing step and the shipping event.
5.1.1 Aggregation and Disaggregation
The Action data element in an EPCIS Aggregation Event says what happened to the aggregation during the event:
Table 5‑2 Action Values for Aggregation Events
To illustrate, here is a business process consisting of five steps:
1. A shipper packs five homogeneous cases (each identified by an SGTIN) onto a pallet (identified by an SSCC).
2. The shipper ships the pallet, only noting the pallet identifier.
3. The receiver receives the pallet and also verifies all of the case identifiers.
4. The receiver unpacks two cases from the pallet.
5. The receiver unpacks the remaining cases from the pallet.
The following table shows the content of the five EPCIS events corresponding to these steps (the When and Where dimensions are omitted for the sake of brevity):
Table 5‑3 Example EPCIS Aggregation Event Information Content
5.1.2 Multiple Levels of Aggregation
Some business processes may involve multiple levels of aggregation; for example, items packed into cases and those cases packed onto a pallet. In such cases, the parents of the inner aggregations are the children of the outer aggregation.
This is modelled in EPCIS, straightforwardly, by having multiple aggregation events, one for each parent at every level. For example, if five items are packed into a case, and three such cases are packed onto a pallet (for a total of 15 items), there will be a total of four aggregation events: three events that aggregate items into cases, and one that aggregates the cases onto a pallet. Here is how that would look, assuming homogeneous cases identified by SGTIN and a pallet identified by SSCC (the When and Where dimensions are omitted for the sake of brevity):
Table 5‑4 Example EPCIS Aggregation Event Information Content for a Two-Level Hierarchy
The Source and Destination data elements in EPCIS events provide detailed information about process steps that are part of a business transfer – the conveyance of ownership and/or possession of objects from one party to another. Each Source or Destination in an EPCIS event carries a type; the CBV defines the following three types that may be used:
Table 5‑5 Source/Destination Types Defined in the Core Business Vocabulary
In the simplest business transfer scenario, the owning party and possessing party are identical at the source and at the destination, and the location is also consistent with those parties. However, more complex scenarios may also be represented.
Consider a “drop shipment” scenario. In this scenario, a pharmaceutical manufacturer M sells product to a wholesaler W who in turn sells the product to a hospital H. Rather than physically warehousing the product, the wholesaler arranges for M to ship directly to H. The wholesaler still retains ownership of the product, however, until a subsequent sale transaction with H takes place.
The following two events show how this scenario can be expressed in EPCIS (the When dimension is omitted for the sake of brevity):
Table 5‑6 EPCIS Event Information Content for Example “Drop Shipment” Scenario
As discussed in Section 4.6.1 , EPCIS allows objects to be identified at the instance level or at the class level. Most of the examples in this guideline, including all of the examples preceding this section, use instance-level identification exclusively. This section describes some of the special considerations that apply when class-level identification is used.
5.3.1 Inherent Limitations of Traceability Using Class-Level Identification
Class-level identification has inherent limitations in comparison to instance-level identification. Instance-level identification makes it possible to determine precisely which EPCIS events refer to a specific object, and therefore whether two EPCIS events at different times refer to the same object. In contrast, class-level identification refers to a class of objects that cannot be differentiated from each other. The impact to class-level traceability systems is that they need to be designed to accommodate ambiguity.
Consider, for example, the following sequence of events using class-level identification:
■ V1: Manufacturer creates 20 new product instances (each identified by GTIN and Lot only)
■ V2: Manufacturer ships 10 product instances to a receiver
■ V3: Manufacturer ships 10 more product instances to the same receiver
■ V4: Receiver receives 10 product instances
The following table shows the content of these EPCIS events:
Table 5‑7 Example EPCIS Event Information Content Using Class-Level Identification.
In this example, it is impossible to know whether the 10 units of GTIN X, Lot 12, received on 25 July in event V4 are the 10 units shipped on 16 July (event V2) or the 10 units shipped on 17 July (event V3). This is not a limitation of EPCIS; it is a fundamental limitation of using class-level identification.
A consequence of this is that common tracking and tracing tasks may be more complex using class-level data. Consider a product recall scenario, where the objective is to determine the current location of all instances of a given lot so that those instances may be removed from the supply chain. If instance-level identification is used, each instance of the lot has a unique serial number that is known from the commissioning business step. The recall application simply has to find the most recent EPCIS event for each instance identifier, and the business location of each event indicates the current location (at least to the extent inferable from EPCIS data). Each instance identifier may appear in more than one EPCIS event, but because a given instance cannot be in two places at once it is the latest event for each instance that gives its current location.
Now consider trying the same strategy with lot-level identification, in a situation where different instances of the same lot may take different paths through the supply chain. Merely finding the latest EPCIS event for that lot does not necessarily locate all of the objects. In the example above, the latest EPCIS event for Lot 12 is Event V4, but that only accounts for 10 of the 20 units. The other 10 units are in still in transit, corresponding to Event V2 or V3. A more complex analysis that attempts to tally the quantities that enter and exit each site is needed in order to identify all of the locations where the lot currently resides.
Applications using class-level identification must consider carefully how the data will be used and what limitations will naturally arise.
5.3.2 Beginning-of-Life Events for Class-Level Identification
When instance-level identification is used, any given instance will have exactly one beginning-of-life event bearing that instance identifier. Such an event is either an Object Event with Action ADD, or a Transformation Event (in which the instance identifier is an output). The business step is Commissioning from the CBV or some more specialised business step from another vocabulary whose semantics are similar to Commissioning.
With class-level identification, there may be many beginning-of-life events bearing the same class identifier, each such event representing the beginning of life for an additional quantity of the class. For example, a manufacturing process may create a pallet’s worth of product each hour and generate an EPCIS event for each pallet manufactured, with all the pallets in one day’s production constituting a single lot. Each hourly EPCIS event represents the beginning of life for the instances produced within that hour.
The CBV defines Commissioning for a class-level identifier to denote the process of associating an identifier not previously used with one or more objects within the class. In other words, Commissioning not only represents the beginning of life for the objects, but also the beginning of life of the identifier. Only one EPCIS event with business step Commissioning should exist for a given identifier.
To handle the case of multiple beginning-of-life events for the same class, the CBV also defines Creating Class Instance as an additional business step type. Unlike Commissioning, Creating Class Instance only implies the beginning of life of the objects, without implying anything about the life of the identifier.
In a situation where the business process is aware when a class level identifier is used for the first time (e.g., when a new lot of a product is initiated), the business step Commissioning may be used for the first EPCIS event that creates instances of the new lot, and Creating Class Instance for any subsequent events that create additional instances of that lot. Sometimes, it may not be feasible or possible to know which EPCIS event is the first use of a class-level identifier; in those cases, Creating Class Instance may be used for all events that create instances of the class.
5.3.3 Class-Level Identification In Aggregation
An Aggregation Event may have children that are identified using class-level identification. The parent, however, must always be identified using instance-level identification.
For example, supposed that homogeneous cases of product are picked to order, shipped, and received, where the cases are only identified with GTIN and Lot. The events might look like this (the When and Where dimensions are omitted for the sake of brevity):
Table 5‑8 EPCIS Event Information Content for Aggregation of Children Identified at Class Level
In this example, the receiver can use the prior aggregation event to infer that the pallet it receives contains 10 units of GTIN X (Lot 12) and 20 units of GTIN Y (Lot 52). Subsequent events might disaggregate product from the pallet, again identifying the specific quantities of the classes that are disaggregated.
It is not permitted to use a class-level identifier to identify the parent of an aggregation. The reason is that inference is only possible if each aggregation has a distinct identity (as represented by the parent identifier), and if inference is not possible then attempting to record the aggregation is of no value.
To illustrate, consider the following scenario in which two different cases, each bearing the same GTIN+lot identifier, are packed with different contents, and then one of those cases is shipped and received:
Table 5‑9 Hypothetical EPCIS Aggregation Event Information Content With Class-Level Parents (not permitted)
The receiver knows it has received one case identified by GTIN P, Lot 111, but it has no way to infer whether the contents of this case are 10 units GTIN X and 20 units GTIN Y, or 20 units GTIN X and 30 units GTIN Z.
The most common situation where both parent and child of an aggregation are identified only at the class level is when items identified by GTIN or GTIN+Lot are packed into a case of fixed composition that is also identified by GTIN or GTIN+Lot, for example, when packing a standard case (bearing case-level GTIN X) of 12 items (each bearing item level GTIN Y). In this situation, GTIN X is specifically allocated to represent a 12-unit case of GTIN Y. The relationship between the two GTINs, including the item count, is expressed in master data.
When this is done, it is not necessary to include an aggregation event showing 12 units of GTIN Y packed into one unit of GTIN X – by definition, every unit of GTIN X contains 12 units of GTIN Y. So while there may be commissioning business steps recorded in EPCIS for both GTIN X and GTIN Y, there will be no aggregation events. If 10 GTIN X cases are shipped, the EPCIS event for the shipment may either specify 10 units of GTIN X (in which case the 120 units of GTIN Y may be inferred from master data), or it may specify 120 units of GTIN Y (in which case the EPCIS data does not indicate whether the items were shipped loose or packed into 12-unit cases).
The above example considers items and cases identified by GTIN only. If the items and cases were identified by GTIN+Lot, then all items in a given case would have to have the same lot number, and that same lot number would also be the lot number of the case. This, indeed, is generally the practice when identifying both items and cases with GTIN+Lot.
(It should also be noted that the original “wrong” example is not allowable under the GTIN Management Standard anyway: if cases do not have fixed composition, they are considered logistic units rather than trade items and so would be identified by SSCC (an instance-level identifier) rather than by GTIN.)
5.3.4 Mixing Instance-Level and Class-Level Identification in the Same Event
It is possible for one EPCIS event to include a mix of both instance-level and class-level identification. For example, a pallet picked to order may include one product identified by SGTIN, another by GTIN+Lot, and a third identified only by GTIN. Here is an example (the When and Where dimensions are omitted for the sake of brevity):
Table 5‑10 EPCIS Aggregation Event Information Content with Children Identified at Both Instance and Class Level
As before, the aggregation event allows the receiver to infer the contents of the pallet, which in this case uses a mix of instance-level and class-level identification.
Mixing of instance-level and class-level identification is particularly common in transformation events arising in manufacturing, where the ingredients in a manufacturing process include “primary” ingredients that are identified at the instance-level and “secondary” ingredients identified only at the class level. For example:
■ Inputs:
□ Tuna loin (each loin is individually serialised and identified by SGTIN – instance-level)
□ Olive oil (identified by GTIN+Lot – class level)
□ Empty can (identified by GTIN, in order to distinguish two possible suppliers of cans)
■ Outputs:
□ Canned tuna (each can identified either at the instance level (SGTIN) or the class level (GTIN+Lot), depending on the business requirement)
It is important to note that when instance-level and class-level identifiers are mixed in the same EPCIS event, each identifier is understood to refer to a different object. The following example is not correct:
Table 5‑11 EPCIS Event Information Content Wrongly Showing Instance and Class Level Identification for the Same Objects
As written, this event implies that six units of GTIN X have been packed onto the pallet: three units that include a serial number, and three more that only give a Lot number. This is probably not what was intended.
If the desire is to indicate the Lot number associated with items identified by GTIN+Serial, only the SGTINs should be included in the event, and the Lot number provided via instance/lot master data on the commissioning event for those serial numbers (see Section 5.4 ).
As explained in Section 7.3.6 of the EPCIS 1.1 standard, Instance/Lot Master Data (ILMD) is data that describes a specific instance of a physical or digital object, or a specific batch/lot of objects that are produced in batches/lots. It is similar to ordinary master data, which also consists of a set of descriptive attributes that provide information about objects. But whereas master data attributes have the same values for a large class of objects, (e.g., for all objects having a given GTIN), the values of ILMD attributes may be different for much smaller groupings of objects (e.g., a single batch or lot), and may be different for each object (i.e., different for each instance).
Conceivably, instance and lot level master data could be communicated between trading partners outside of EPCIS, just as GTIN-level master data may be communicated outside EPCIS using the Global Data Synchronisation Network (GDSN). However, at this time there are no well-established mechanisms for communication of instance or lot level master data. For this reason, EPCIS provides a means to attach instance and lot level master data to the EPCIS event that marks the beginning of life for a new instance.
In the case of objects identified at the instance level, master data for the instance is carried in the commissioning event for that instance, or in a transformation event if the instance is created as the output of a transformation. For example, the following table shows the content of three EPCIS events, including instance-level master data at the commissioning step (the “when” dimension is omitted for brevity):
Table 5‑12 EPCIS Event Information Content Showing Instance/Lot Master Data (ILMD)
Note that when an object is identified at the instance level, its lot number (if any) is a master data attribute of that instance.
In the example above, if the receiver wishes to obtain the master data for the product instance it receives, it queries the manufacturer for the event having the specified SGTIN in the What dimension and having business step Commissioning (from the CBV).
In the XML representation of an EPCIS event, ILMD is expressed using elements defined in XML namespaces other than the EPCIS namespace. The CBV standard defines commonly used master data attributes, using the XML namespace urn:epcglobal:cbv:mda. Those master data attributes have definitions that match definitions used in other GS1 standards including GDSN and GS1 EDI. Other master data attributes may defined in other standards or otherwise agreed to in advance by trading partners; such attributes must have an XML namespace other than the EPCIS or CBV namespaces.
Here is how the V1 event above might look in XML (portions omitted for brevity):
Lot-level master data works the same as instance-level master data. In contrast to instance-level identification, when lot-level identification is used there may be many beginning-of-life events (object or transformation events having business step commissioning or creating-class-instance) for the same lot. The ILMD for that lot may be included in all such beginning-of-life events, with the proviso that the content of the ILMD must be identical for all events pertaining to the same lot. When both commissioning and creating-class-instance business steps are used, it is acceptable to include ILMD only with the commissioning steps.
The EPCIS Transformation Event is used to represent a business process step in which one or more objects are fully or partially consumed as inputs and one or more objects are produced as outputs. The Transformation Event captures the relationship between the inputs and the outputs, namely that any of the inputs may have contributed in some way to each of the outputs.
In contrast to aggregation, a transformation is irreversible. Following the transformation, the inputs that were consumed no longer exist, and the outputs are brand-new objects that did not exist prior to the transformation. In this way, a transformation event functions as the beginning-of-life event for the outputs and as end-of-life for the inputs (unless the inputs are not fully consumed).
Examples of commonly occurring transformations including the following:
Table 5‑13 Examples of Transformation Business Processes
A common reason for tracking transformations is to give business processes an understanding of what inputs might have affected what outputs. For example, if a primal cut of meat coming from a specific ranch is discovered to have bacterial contamination, the transformation event allows this to be traced forward to identify all of the finished meat products that might be affected by the contaminated primal cut. Conversely, if a finished product is discovered to be contaminated, the transformation allows this to be tracked backward to identify all of the ingredients, which then may be traced forward to find additional finished product that might be affected.
5.5.1 Transformation Event Example
Consider the following manufacturing process:
■ Inputs:
□ Tuna loin (each loin is individually serialised and identified by GTIN X plus serial – instance-level)
□ Olive oil (identified by GTIN Y + Lot – class level)
□ Empty can (identified by GTIN Z, in order to distinguish two possible suppliers of cans)
■ Outputs:
□ Canned tuna (identified by GTIN Q + Lot – class level)
Here is a transformation event for one run of this process (the When and Where dimensions are omitted for the sake of brevity):
Table 5‑14 Example EPCIS Transformation Event Information Content
As the transformation is the beginning of life for the outputs, a beginning-of-life business step and disposition are used. In this case, the transformation creates new instances of Lot 999, so Creating Class Instance is used as the business step. If it is known that this event creates Lot 999 for the first time, Commissioning could be used instead.
5.5.2 Long-Running Transformations
Sometimes a transformation runs over a long period of time, in which inputs are added periodically and outputs extracted periodically. For example, a mixing process might consume inputs in several batches over the course of a product run, with outputs withdrawn even as more inputs are added.
A long-running transformation can be modelled with a single EPCIS event that lists all of the inputs and all of the outputs that were involved over the entire interval of time. This raises a question about what event time is appropriate; most often, the time at which the process completed is the appropriate event time to use.
It is not always desirable, however, to model a long-running transformation as a single EPCIS event. This is especially true if some of the output objects are subject to further business steps even before the transformation has completed. For example, consider a process that mixes input ingredients to create cans of paint, where a production run involving the same mixing vat runs continuously for a week. The process may produce cans of paint on Monday, and those cans are shipped on Tuesday, even though more cans from the same vat are extracted on Wednesday and Thursday, with the entire transformation completing on Friday. In this situation, it may be necessary to have an EPCIS event to represent Monday’s production so that the new identifiers for the cans of paint are available to be used in a shipping event generated on Tuesday.
To model such situations, a transformation event may be split into multiple EPCIS events. To maintain the relationship between all inputs and outputs, the multiple transformation events are linked by using a transformation identifier. This is simply a unique identifier that is the same for all EPCIS events belonging to the same transformation (i.e., where there is a relationship between inputs and outputs), and different from the transformation identifier used in other, unrelated events.
The following set of events is equivalent to the transformation of the previous section, plus an added event showing the shipment of the first few cans of tuna to be produced.
Table 5‑15 Example EPCIS Transformation Event Information Content Linked Via Transformation ID
The Core Business Vocabulary provides templates that may be used to construct transformation IDs.
EPCIS is not limited to tracking physical objects. EPCIS may also be used to track digital objects such as digital trade items (music downloads, electronic books, etc.), digital documents (electronic coupons, etc.), and so forth. In most cases, the business processes for digital objects are similar to the processes for physical objects, and the same Core Business Vocabulary business steps and dispositions can be used.
This section illustrates EPCIS applied to digital objects by showing two processes for tracking the lifecycle of a digital coupon. A digital coupon is an offer from a manufacturer or retailer to provide something of value (a cash rebate, a discount, or an additional trade item) to a consumer when the consumer purchases a particular trade item. A particular offer from a manufacturer or retailer may be identified by a Global Coupon Number (GCN), and a particular instance of that offer as issued to and redeemed by a consumer may be identified by a Global Coupon Number with a serial number (SGCN). Master data associated with the GCN may provide details about the offer, such as the GTIN of the required purchase, the amount of the cash rebate, etc. A digital voucher, such as a voucher issued to a consumer by a bottle recycling machine and redeemed by the consumer at point-of-sale, works in a similar manner.
Two processes are illustrated here: a simple process where a coupon is issued by a manufacturer and redeemed by a retailer at point of sale, and a more complex process involving a coupon broker.
Both of these examples are intended to illustrate the general concept of using EPCIS for digital objects. For specific details on how to model coupon processes, see GS1 application standards or local recommendations for this purpose.
5.6.1 Simple Coupon Process
In the simplest coupon process, there are just two steps that require EPCIS events:
■ V1: A customer is issued a digital coupon by a coupon issuer. Typically the coupon issuer is a retailer, but it could also be a manufacturer or a third party. The coupon is often issued to the customer via a mobile application that the customer uses on his device. The coupon’s SGCN is stored with that application for use in the next step. An EPCIS event is generated to indicate that the coupon is now active.
■ V2: The customer redeems the coupon at a point-of-sale terminal during checkout at a retail store (whether brick-and-mortar or online). The point-of-sale application verifies that the coupon is valid and that the conditions of the offer are met; if so, the coupon is redeemed and an EPCIS event generated to indicate that the coupon is no longer active.
These two events are indicated in EPCIS using a business step of commissioning and decommissioning, respectively.
Table 5‑16 Example EPCIS Event Information Content for Simple Digital Coupon Business Process
In the commissioning step (V1), ILMD could be used to record attributes of the coupon such as the associated GTIN, the date range during which the coupon is redeemable, the customer’s loyalty card number, and so on.
Once EPCIS events are captured, EPCIS queries could be used to determine the total number of coupons activated in a given timeframe, the total number of coupons for a given GCN (class level), all SGCNs not yet redeemed (but still valid), the number of redemptions and the time period between coupon activation/redemption, and so on.
5.6.2 Coupon Example With Coupon Broker
The example in the previous section assumes that only two events require tracking in EPCIS: the issuance of the coupon to a customer, and the redemption of the coupon at point of sale. But as in any business process, the process of coupon redemption may be more complex in practice, and it may be useful to model more steps of the process in EPCIS. For example, in a more complex scenario there might be four steps that could be recorded using EPCIS:
■ V1: A coupon issuer (retailer or manufacturer) issues a block of coupons to a coupon distributor (e.g., an Internet application provider specialising in electronic coupons).
■ V2: A customer is issued a digital coupon by the coupon distributor.
■ V3: The customer redeems the coupon at a point-of-sale terminal during checkout at a retail store (whether brick-and-mortar or online).
■ V4: Final settlement takes place between the coupon distributor and the issuer.
As in the previous example, each of these business steps could be modelled as an EPCIS event. In this example, commissioning takes place in V1 when the coupon is issued to the distributor, not when the distributor issues the coupon to the consumer (the latter being more akin to a receiving operation by the consumer). And decommissioning takes place during the final settlement step V4, not when the consumer redeems the coupon.
As the Core Business Vocabulary does not include all of the business step and disposition values that would be needed to model all four of these events, they are not illustrated here. Specific standards or guidelines for coupon tracking may be developed by GS1 in the future.
The main point here is that whether the “what” is a physical object or a digital object, the same analysis and design procedure serves to model a business process using EPCIS.
This section illustrates how EPCIS may be used to capture tracking events for returnable assets, such as pooled pallets or totes. Each returnable asset is identified using a GRAI that includes a unique serial number.
There are two interlocking business processes, one carried out by the party that manages the returnable assets, and one carried out by the users of the assets. The first process is illustrated below.
Table 5‑17 Process Flowchart for Example Returnable Asset Management Business Process
The party that manages the returnable assets may be interested in tracking all nine of the events illustrated above. Here is how they may be modelled in EPCIS. In each case, the What dimension includes the GRAI(s) of the asset(s) involved in that step and the Where dimension contains the appropriate location within the asset manager’s facility. Below, the What, When, and Where dimensions are omitted for the sake of brevity.
Table 5‑18 EPCIS Event Information Content for Returnable Asset Management Business Process (V1 – V4)
Table 5‑19 EPCIS Event Information Content for Returnable Asset Management Business Process (V5 – V9)
Notes on these events:
■ In V3, the disposition and what happens next depends on the result of the inspection:
□ If the condition of the asset is acceptable, the disposition is In Progress (from the CBV) and the next step is V6 (cleaning).
□ If the condition of the asset is unacceptable, the disposition is Damaged (from the CBV) and the next step is V4 (repairing).
■ In V3, the disposition and what happens next depends on the result of the repair attempt:
□ If the asset was successfully repaired, the disposition is In Progress (from the CBV) and the next step is V6 (cleaning).
□ If the asset could not be repaired, the disposition is Damaged (from the CBV) and the next step is V5 (destroying).
■ In V6, there is no CBV business step corresponding to “cleaning,” so this is a situation where a private vocabulary element might be used.
After V9, the empty asset is used by an asset user to move goods through the user’s own supply chain. There are two possibilities for how the returnable asset is used:
■ The user may not be aware of or make any use of the GRAI of the asset at all. In that case, the asset is just a “dumb” pallet or tote, and its GRAI does not enter into any EPCIS events. The user may track products loaded onto the asset using their GTINs, and/or associate an SSCC with the complete logistic load carried by the asset, but either way such use is wholly unrelated to the use of the GRAI by the asset manager.
■ The user may take advantage of the asset’s GRAI and the bar code or RFID data carrier containing it.
The EPCIS data model is designed to include all of the relevant What, When, Where, and Why information a business application needs to understand what happened in a business process step. However, sometimes a business application has information needs that go beyond the data elements defined in the EPCIS standard. To accommodate such situations, EPCIS events may carry user/vendor extension data elements.
A user/vendor extension data element is simply any data element added to an EPCIS event. Most commonly these express additional business context and so can be considered an addition to the Why dimension of an event, but as there are no restrictions on the content of an extension it could pertain to any other dimension as well.
In the XML representation of an EPCIS event, an extension data element is expressed as an XML element whose XML namespaces is something other than the EPCIS namespace. Neither the EPCIS standard nor the CBV standard define any specific extension data elements, so these must either be defined in other standards (e.g., a sector-specific standard or standard promulgated within a trading group) or otherwise agreed to in advance by trading partners.
To illustrate, here is an example of an EPCIS event that has two additional data elements to record the temperature and humidity of the objects, as might be appropriate for an observation made while an item is in transit in a refrigerated container:
Table 5‑20 EPCIS Event Information Content Illustrating User/Vendor Extensions
Here is the XML representation of the above event:
In this example, the two extension elements are in an XML namespace defined by the Example Corporation. The use of the XML namespace not only distinguishes extensions from standard EPCIS data elements, but also ensures that Example Corporation’s extensions will not be confused with extensions of other organisations that may use the same element names.
The following guidelines should be observed in using extension elements:
■ Extension elements must be agreed in advance by trading partners, otherwise they may not be correctly interpreted.
■ EPCIS standard data elements should always be used in preference to extension data elements, as they will be more interoperable.
■ The XML namespace URI used for the extensions should be a URI that is under the control of the organisation defining the extensions. Using an HTTP URI based on the Internet domain name of the defining organisation is a recommended approach.
■ Extension elements should provide information that provides additional data about the event in which they are included. They should not be used to communicate data not related to the event. In particular, data that is properly considered as master data pertaining to an instance-level or lot-level identifier should be carried in the ILMD section of an event, not as an extension element. See Section 5.4 .
■ An extension data element can contain any well-formed XML content, including sub-elements and attributes. However, the EPCIS SimpleEventQuery is only capable of querying extension elements whose values are numbers or strings.
■ The XML element <extension> defined in the EPCIS XML schema should never be used to carry user or vendor extensions. The <extension> element is reserved for use by the EPCIS standard itself, to introduce new data elements in later versions of the EPCIS standard.
■ Applications receiving EPCIS data must not reject an EPCIS event merely because it contains an extension that the application does not recognise. Such extensions should be ignored, or perhaps noted or saved without further interpretation. On the other hand, an extension whose content violates validation criteria established in advance by trading partners may be rejected on that basis.
As explained throughout this guideline, in EPCIS a business process is modelled by breaking it down into a series of steps, and modelling each as an EPCIS event. The net effect is that the collection of all events pertaining to a specific object (a “trace”) should correctly indicate the history and current state of that object, by interpreting the events according to the semantics specified in the EPCIS and CBV standards, and any other relevant vocabulary standards.
Sometimes, it is discovered that an event recorded earlier does not accurately reflect what happened in the real world. However, neither the EPCIS Capture Interface nor the EPCIS Query Interface provides a means by which an application can delete or modify an EPCIS Event. The only way to “retract” or “correct” an EPCIS Event is to generate a subsequent event whose business meaning is to rescind or amend the effect of a prior event. The net effect is that the complete trace (including the new events and all prior events including the incorrect event) accurately reflects the history and current state, as stated in the above principle.
The preferred way to arrive at the additional events is to recognise that the discovery of an erroneous event and its remediation is itself a business process which can be modelled by creating suitable EPCIS events. In most situations, this is done using the same methods discussed in Section 4 .
Example 1: Company X records an EPCIS event asserting that serial numbers 101, 102, and 103 of some product were shipped to Company Y. Company Y receives the shipment and finds serial number 104 in addition to serial numbers 101, 102, 103. In discussion with Company X, it is agreed that serial 104 was indeed shipped and that the shipping event was in error. Remediation: Company X records a new EPCIS event asserting that serial number 104 was shipped, with similar contextual information as the original event.
Example 2: Company X records an EPCIS event asserting that serial numbers 101, 102, and 103 of some product were shipped to Company Y. Company Y receives the shipment and finds only serial numbers 101, 102. In discussion with Company X, it is agreed that serial 103 was not shipped but remains in Company X's inventory. They agree to reverse the billing for the third product. Remediation: Company X records a new EPCIS event asserting that the shipment of serial 103 is voided.
In the first example, the additional event uses the same business vocabulary as the first. In the second example, vocabulary specifically associated with the process of voiding a shipment is used, but it is still “ordinary” EPCIS semantics in the sense that it models the completion of a well-defined business process step. This reflects the reality that the act remediation is itself a business process, and so may be modelled as an EPCIS event.
In some situations, it either is not possible (or is highly undesirable) to remediate the history of an object by creating a new EPCIS event with ordinary semantics.
Example 3: Company X records an EPCIS event to assert that serial number 101 of product X was destroyed. This event is an Object Event with action = DELETE. Later it is discovered that serial 101 is still in storage, not destroyed. An ordinary event cannot be used to amend the history, because the semantics of action DELETE for an Object Event specify that “the objects … should not appear in subsequent events.”
Example 4: Company X records an EPCIS event asserting that several products have been shipped, indicating Purchase Order 123 as a business transaction in the “why” dimension. Company Y receives the products and records a receiving event. Only then it is discovered that the purchase order reference in the shipping event is wrong: it says PO 456 instead of 123. This could be remediated using ordinary EPCIS events by Company X recording a “void shipping” event followed by a “shipping” event with the correct PO #. But this is rather undesirable from the perspective of the overall trace, especially given that there is already a receiving event.
To accommodate such situations, EPCIS includes a mechanism to construct an event whose semantics assert that the assertions made by a prior event are in error. Such an event is termed an “error declaration event.”
The following sections illustrate the various approaches to correcting errors in more detail.
5.9.1 Example 1: Correction using an ordinary event – simple addition
In this example, Company X records an EPCIS event asserting that serial numbers 101, 102, and 103 of some product were shipped to Company Y. Company Y receives the shipment and finds serial number 104 in addition to serial numbers 101, 102, 103. In discussion with Company X, it is agreed that serial 104 was indeed shipped and that the shipping event was in error.
The remediation is that Company X records a new EPCIS event asserting that serial number 104 was shipped, with similar contextual information as the original event.
Both events together look like this:
Table 5‑21 Example of correcting an error by adding an ordinary event with a corrective business step.
5.9.2 Example 2: Correction using an ordinary event – corrective business step
In this example, Company X records an EPCIS event asserting that serial numbers 101, 102, and 103 of some product were shipped to Company Y. Company Y receives the shipment and finds only serial numbers 101, 102. In discussion with Company X, it is agreed that serial number 103 was not shipped but remains in Company X's inventory. They agree to reverse the billing for the third product.
The remediation is that Company X records a new EPCIS event asserting that the shipment of serial 103 is voided. This uses a business step void_shipping which is defined specifically for this purpose. As the new event only refers to serial number 103, it does not affect the shipping event for the other serial numbers 101 and 102, so processing of those serial numbers can continue even before the void_shipping event is received.
Both events together look like this:
Table 5‑22 Example of correcting an error by adding an ordinary event.
Note that the event time, read point, business location, and disposition reflect the process of voiding the shipment: the event time is the date/time the shipment was voided, the business location is the warehouse reflecting the location of serial number 103 after shipmen is voided, and the disposition is “in progress” as it would if serial number 103 had not been shipped. However, the source and destination is the same in the void_shipping event as in the original shipping event, reflecting the context for the voided business transfer.
5.9.3 Example 3: Declaring a prior event to be in error, with no corrective event
In this example, Company X records an EPCIS event to assert that serial number 101 of product X was destroyed. This event is an Object Event with action = DELETE. Later it is discovered that serial 101 is still in storage, not destroyed. An ordinary event cannot be used to amend the history, because the semantics of action DELETE for an Object Event specify that “the objects … should not appear in subsequent events.”
The remediation is to issue an error declaration event. This looks just like the original, erroneous event, but with the addition of an error declaration section.
Both events together look like this:
Table 5‑23 Example of correcting an error by adding an error declaration event.
5.9.4 Example 4: Declaring a prior event to be in error, with a corrective event
Company X records an EPCIS event asserting that several products have been shipped, indicating Purchase Order 123 as a business transaction in the “why” dimension. Company Y receives the products and records a receiving event. Only then it is discovered that the purchase order reference in the shipping event is wrong: it says PO 456 instead of 123. This could be remediated using ordinary EPCIS events by Company X recording a “void shipment” event followed by a “shipping” event with the correct PO #. But this is rather undesirable from the perspective of the overall trace, especially given that there is already a receiving event
The remediation is to issue an error declaration event together with a corrective event. The error declaration looks just like the original, erroneous event, but with the addition of an error declaration section. The corrective event is a corrected version of the original event. Optionally, the corrective event can be given a unique event ID, and referenced from the error declaration event.
All three events together look like this:
Table 5‑24 Example of correcting an error by adding an error declaration event.
5.9.5 Timing of capturing error declaration and corrective events
As the example in Section 5.9.4 illustrates, an error declaration is sometimes accompanied by one or more corrective events. It is important that an EPCIS Accessing Application that receives event data be aware of the error declaration if it sees the corrective event(s), because otherwise the application may see an inconsistency between the original (erroneous) event and the corrective events.
For this reason, it is important that corrective event(s) are not sent to an EPCIS Capture Interface prior to sending the error declaration event. On the other hand, if the error declaration event makes a forward reference to the corrective event(s) using the correctiveEventIDs field, then the corrective events must be known to the EPCIS Capturing Application at the time the error declaration event is generated. The recommended way to address both of these concerns at once is for the error declaration and associated corrective event(s) to be captured at the same time; that is, within the same event list in the document delivered to the EPCIS Capture Interface.
Note that the above considerations are not related to the event time or declaration time fields of the events concerned. The declaration time of the error declaration is the date and time at which the error declaration is made, the event time of the error declaration is identical to the event time of the original erroneous event (usually preceding the declaration time, unless the event time was one of the things that was wrong with the original event), and the event time of the corrective event(s) is the date and time at which the event actually occurred (usually the same as the event time of the original event, unless the event time was one of the things that was wrong with the original event).
5.9.6 Querying for events in the presence of errors and corrections
An error declaration event is constructed by including an ErrorDeclaration section. Specifically, given Event E1, an error declaration event E2 whose effect is to declare the assertions of E1 to be in error is an event structure whose content is identical to E1, but with the ErrorDeclaration element included. For example, the error declaration for the "destroying" event in Example 3 is also an Object Event with action = DELETE, but with the ErrorDeclaration element included. In general, to declare event E to be in error, a new event is recorded that is identical to event E except that the ErrorDeclaration element is also included (and the record time will be different).
There are three reasons why error declaration events in EPCIS are expressed this way. One, an event ID is not required to indicate the erroneous event, which in turn implies it is not necessary to include an event ID on every event to provide for possible error declaration in the future. Event IDs are available to link an error declaration event to a corrective event, but it is never necessary to use event IDs. Two, any EPCIS query that matches an event will also match an error declaration for that event, if it exists. This means that EPCIS Accessing Applications require no special logic to become aware of error declarations, if they exist. Three, if an EPCIS Accessing Application receives an error declaration event and for some reason does not have a copy of the original (erroneous) event, it is not necessary to retrieve the original event as every bit of information in that event is also present in the error declaration event.
6 Sharing EPCIS Data
6.1 Sharing EPCIS Data within a single organisation
6.2 EPCIS Queries
6.3 Query Modes: Pull vs Push
6.4 The EPCIS Query Control Interface
6.5 Choreography Models: Sharing Data across a Supply Chain
6.6 Synchronisation of Master Data
6.7 Redaction of EPCIS Event Data
When EPCIS data is used entirely within one organisation, a typical deployment looks like this:
This picture has the following components:
■ EPCIS Capturing Applications: An EPCIS Capturing Application is software that supervises a business process and creates EPCIS events as steps of that process are completed. EPCIS Capturing Applications quite often interact with the physical world through distributed devices such as bar code scanners, RFID readers, handheld computers, vehicle-mounted terminals, machine controllers, and the like. An EPCIS Capturing Application could also be purely software, especially if the subject of the EPCIS events are digital objects (for example, the digital coupon example in Section 5.6 ). A single enterprise may have many EPCIS Capturing Applications, each capturing EPCIS data from a different business process or in a different physical location.
■ EPCIS Repository: An EPCIS Repository is a persistent store for EPCIS data. The EPCIS Repository stores events generated by EPCIS Capturing Applications and makes those events available for use by EPCIS Accessing Applications (below).
■ EPCIS Accessing Application: An EPCIS Accessing Application is software that consumes EPCIS data as an input in order to carry out some business information function. An EPCIS Accessing Application might respond in real-time to EPCIS events to automate a business process, or it might perform an analytic function using historical EPCIS events previously saved in the repository. In many cases, an EPCIS Accessing Application will interface to a legacy business application that is not prepared to digest EPCIS events directly; in such cases the EPCIS Accessing Application may serve to reduce the data volume to a level that the legacy application can handle.
All deployments of EPCIS include at least one EPCIS Capturing Application and one EPCIS Accessing Application. Many deployments will have several of each; indeed, the power of EPCIS lies in its ability to aggregate data from multiple capturing applications and reuse the data across multiple accessing applications.
It is very common to deploy an EPCIS Repository as a standalone software component whose only function is to receive EPCIS events from capturing applications, store them, and provide them as input to accessing applications. However, in some cases a single software component may provide additional business functions besides storing EPCIS events – in that case, the software component plays both roles of EPCIS Repository and EPCIS Accessing Application. On the other hand, a system that exclusively processes EPCIS data in real time might omit the EPCIS Repository altogether, and route data directly from EPCIS Capture Applications to an EPCIS Accessing Application. As these examples show, EPCIS Capturing Application, EPCIS Repository, and EPCIS Accessing Application are roles that may be played by different software components of a deployed system, and not necessarily individual components themselves.
The EPCIS Standard defines two interfaces that connect the software roles discussed above:
■ EPCIS Capture Interface: The interface by which an EPCIS Capturing Application delivers new EPCIS events to an EPCIS Repository (or directly to an EPCIS Accessing Application, as noted above).
■ EPCIS Query Interface: The interface by which an EPCIS Accessing Application obtains EPCIS data from an EPCIS Repository.
The EPCIS Capture Interface is very simple, as the sole operation provided by that interface is for an EPCIS Capturing Application to post a document containing one or more EPCIS events. The EPCIS Query Interface is more complex, and is explained in the following sections.
EPCIS Accessing Applications obtain EPCIS events from an EPCIS Repository by means of an EPCIS Query. An EPCIS Query is a set of event-matching criteria specified by the application; the EPCIS Repository responds to a query by retrieving all EPCIS events that match the specified criteria.
The EPCIS Standard, Section 8.2.7.1, defines over 40 different criteria that can be used to construct a query for event data. These criteria can be used alone or in combination. Each criterion has a “parameter name” specified in the EPCIS standard, and most take a “parameter value” that further defines how the criterion is to be applied. The following table lists some of the commonly used criteria; see the EPCIS Standard, Section 8.2.7.1, for the complete list:
Table 6‑1 Selected EPCIS Query Criteria
A single query may include more than one criterion, in which case events must match all criteria to be included in the result. For example, a query that includes both the GE_eventTime criterion and the MATCH_epc criterion will match only those events that occur on or after the specified event time and which contain one of the specified instance-level identifiers.
To answer a business question, first the information need must be identified, then analysed to determine what EPCIS events contain the needed information. Then, a suitable EPCIS query can be formulated. The following table illustrates how that would be done for several typical examples.
Table 6‑2 Examples of Business Information Needs and Corresponding EPCIS Query Criteria
An EPCIS query is used to transfer EPCIS events from an EPCIS repository to an application or trading partner that needs those events. There are different ways in which the transfer can be triggered.
■ Pull: This method of transfer involves a request/response pattern. The application or trading partner issues a request to an EPCIS repository containing EPCIS query criteria, and the EPCIS repository responds with the EPCIS events that match the criteria.
■ Push: This method of transfer involves a one-way message: the EPCIS repository simply delivers one or more EPCIS events to an application or trading partner that needs them. There are two variations to this theme:
□ Pre-arrangement: The sending and receiving party have agreed in advance, by some means outside of the scope of the EPCIS standard, what data the receiving party needs and under what conditions. The sending party delivers events when it sees fit based on that prior arrangement.
□ Subscription: The receiving party issues a standing query to the sending party to express an ongoing information need. A standing query includes EPCIS query criteria (just as in the “pull” method) along with description of the conditions that will trigger the delivery of events. These conditions could be a regular schedule (e.g., daily at 3am) or some other triggering event. Each time the triggering condition occurs, the sending party evaluates the query criteria and delivers any new events that match the criteria (new compared to the last time the subscription was triggered).
In both “push” variations, EPCIS events are delivered in a one-way communication from sender to receiver; the difference is that in the pre-arrangement variation the sender is in full control of what data is sent whereas in the subscription variation the receiver gets to express its needs via the standing query. In all method, “push” and “pull”, the sender ultimately has control over what data is sent, as described in Section 6.7 .
In designing an overall business process that involves the flow of EPCIS data, different query modes may be used to meet differing requirements. Generally speaking, “push” methods are often used when there is a recurring predictable need for transfer of EPCIS data, and “pull” methods are used when transfer is needed unpredictably or only on an exception basis. The following table shows examples under which each variation might be appropriate:
Table 6‑3 Example Business Scenarios and Corresponding Likely EPCIS Query Modes
The EPCIS standard provides a standardised interface through which an EPCIS accessing application or trading partner may interact with an EPCIS repository. Through this interface, an application or trading partner may issue a “pull” query, set up a “push” subscription, and more.
The following table summarises the operations available through the interface:
Table 6‑4 EPCIS Query Control Interface Operations
The EPCIS standard defines XML representations for each request and response message that is used in the EPCIS query interface.
When two trading partners share EPCIS information with each other, the flow of information is straightforward: each partner has an established business relationship with the other, and they agree on what data to share and what query mode to use.
The situation is more complex in an ecosystem having many trading partners. Each party may be trading with many others, and each such trading relationship may require the exchange of EPCIS data. Moreover, it may be necessary for one party to share EPCIS data with another party with whom there is not a direct trading relationship; for example, if A sells to B and B sells to C, there may be a need for A and C to share EPCIS data to get a complete picture of the supply chain, even though A and C do not have a direct trading relationship.
A core principle for managing this complexity is to separate content from choreography. What this means is that the content of EPCIS data – the specific business steps that require visibility, the EPCIS events that will used to record the completion of those steps, and the detailed contents of those events – should be designed according to the methods described earlier in this guideline (Sections 3 , 4 , and 5 ). These methods focus on accurately modelling the what, when, where, and why information for each business step. Separately from that, trading partners can decide when and how the data will move from one trading partner to another – this is called the choreography. Choreography decisions include: where will data reside, what will trigger the communication of data from one party to another, will push or pull modes be used, what networking technology will be used, and so forth. By separating content from choreography, the choreography can adapt to changes in the size of the trading ecosystem and evolution of technology, while the design of the EPCIS content stays the same.
There are many possible approaches to choreography. Many of these approaches fall into one of the following three broad categories:
■ Centralised Choreography: In these models, EPCIS events from multiple parties in the supply chain are sent to a shared repository. To get an overall view of the supply chain, it is only necessary to query the shared repository.
■ Distributed Query Choreography: In these models, each party that captures EPCIS data keeps that data in its own repository. When another party needs an overall view of the supply chain, it must locate and query all of the other parties who may have relevant data within their respective repositories.
■ Distributed Push Choreography: In these models, each party that captures EPCIS data keeps that data in its own repository. But rather than waiting for another party to query for that data, the capturing party sends (pushes) its data to other parties in the supply chain who are likely to need that data. Often the push of data follows the same path as the physical or digital objects; e.g. if a Party A ships goods to Party B, it also sends its EPCIS data to Party B.
The following sections illustrate examples of these three approaches in more detail. Throughout these sections, a scenario is illustrated in which Party A ships goods to Party B who ships goods to Party C, and upon receipt Party C would like to examine the upstream EPCIS events from A and B.
Differences between choreography approaches are illustrated through the following four questions:
■ Questions for the producers of EPCIS event data:
□ When does the producer share its EPCIS events to an outside party?
□ Where does the shared data go?
■ Questions for the consumers of EPCIS event data:
□ How are events produced by multiple parties gathered together for analysis?
□ Who does the work of gathering events and performing the analysis?
A given party may act as both a producer and a consumer in the context of different business processes.
6.5.1 Centralised Choreography
The simplest choreography model is one in which there is a single EPCIS repository shared by all supply chain parties.
Figure 6‑1 Centralised Choreography
The centralised choreography model has these characteristics:
Table 6‑5 Characteristics of Centralised Choreography
The centralised approach has the advantage that all events are in one place, simplifying the work of gathering events for analysis. It also provides a natural place to offer shared analytic services.
One disadvantage of the centralised approach is that all supply chain parties must agree to use the same repository service. This may not be feasible for a very large supply chain. A variation on the centralised approach is one in which there may be many shared repositories – this is called a semi-centralised approach. With more than one repository, the data required for a given analysis may not necessarily all reside in one repository. So the semi-centralised approach requires additional features to mitigate this. Some possibilities include:
■ Multiple shared repositories can federate with each other, so that they keep synchronised copies of each other’s data or they forward queries to each other as needed.
■ If queries are limited to gathering events for a single EPC class (e.g., for a single GTIN), repositories can be segregated on that basis. This requires each EPC class to be associated with a specific repository (typically one nominated by the party that commissions the EPC) and registered in some lookup service that maps an EPC class to specific repository. The Object Name Service (ONS) could be used for that purpose. Each downstream party then uses the lookup service to determine which repository to share its data with.
6.5.2 Distributed Push Choreography
In a Distributed Push Choreography approach, each supply chain party keeps the data it captures in its own EPCIS Repository, and also sends a copy of EPCIS events downstream following the flow of the corresponding physical objects. There are no EPCIS queries involved.
Figure 6‑2 Distributed Push Choreography
The distributed push choreography model has these characteristics:
Table 6‑6 Characteristics of Distributed Push Choreography
The distributed push approach has the advantage that the consuming party receives the data it needs in advance; there is no need to query for data later. This makes the method robust in that the consuming party does not need to rely on the availability of any party’s EPCIS service (or of any shared service). A disadvantage of this approach, however, is that events are communicated whether or not the events are ultimately needed; also, the intermediate parties must relay events even if they have no interested in using them.
As described above, the distributed push approach communicates upstream events to downstream parties. It would be possible for events to be communicated in the opposite direction as well, to provide for downstream events to be received by upstream parties.
6.5.3 Distributed Query Choreography
In a Distributed Query Choreography approach, each supply chain party keeps the data it captures in its own EPCIS Repository. Any party that needs another party’s data must query for it.
Figure 6‑3 Distributed Query Choreography
The distributed query choreography model has these characteristics:
Table 6‑7 Characteristics of Distributed Query Choreography
The distributed query approach has the advantage that each party can keep tight control on their data and only delivers data directly to the party that consumes it (the data does not have to be forwarded through any other party). Also, there is no reliance on any shared service.
A challenge in the distributed query approach is discovery: how does the consumer of EPCIS data find the other EPCIS repositories to query? There are several parts to discovery:
■ Determining what other parties have (or may have) data that is relevant to the consumer’s information need.
■ Obtaining a network address of the EPCIS service of each party to be queried.
■ Authenticating and establishing trust with each queried party, so that the queried party will be comfortable authorising access to the data the querying party wants. This may be complicated if the querying party does not have a direct business relationship with the queried party; e.g., if they are more than one step removed from each other in the supply chain.
There are many possible approaches to solving the discovery problem, including:
■ Chain of Custody Token: In this approach, each party in the supply chain sends a short message to the next downstream party in the supply chain containing the network address of its EPCIS service and an authorisation token providing access to EPCIS data pertaining to the specific physical objects being shipped. A party in the middle of the supply chain not only provides its chain of custody token to downstream partners, but also forwards along the tokens it receives from upstream parties. In this way, a downstream party receives tokens that provide access to all upstream parties that have data about the physical objects it receives.
As described, this allows downstream parties to discover upstream data but not the reverse. However, separate tokens could be sent and forwarded upstream to give upstream parties the ability to discover downstream data.
■ Discovery Service: In this approach, a centralised “discovery service” is maintained which acts as an index for the location of all relevant EPCIS data. When a party captures its own EPCIS data, it sends a message to the discovery service containing the network address of its EPCIS service and identifying the physical objects for which it has data. A consuming party can subsequently query the discovery service to find all of the EPCIS services that have relevant data. The information sent to the discovery service may also include authorisation information so that trust may be established when the consuming party queries the producers.
Note that the discovery problem is similar to the problem of distributing EPCIS events themselves, except that the information distributed is a pointer to EPCIS data. From that perspective, a discovery service is a like a centralised model for pointer data, and the chain of custody approach is like the distributed push model for pointer data. A pointer to EPCIS data, however, is less data than EPCIS events themselves, and so there is less data centralised or pushed than there would be in a true centralised or distributed push choreography for EPCIS events.
Data in the what and where dimensions of EPCIS events take the form of globally unique identifiers, for example a Serialised Global Trade Item Number (SGTIN) in the what dimension or a Global Location Number (GLN) in the where dimension. In order to interpret the business meaning of an EPCIS event, a business application typically needs additional descriptive information associated with each identifier. For example, descriptive information for a GTIN might include the name of the product, the brand name, the physical dimensions, and so on. Descriptive information for a GLN might include the street address of the location and its geocoordinates. Such descriptive information is called “master data.”
Compared to EPCIS event data, master data is static. Unlike event data, more master data is not created merely because more business is transacted. Master data is not completely static, however: additional master data may be created due to growth, for example when new products are introduced or new physical locations are built. But in general, a given identifier having a single set of associated master data may be mentioned in many different EPCIS events. For this reason, it is desirable to communicate master data in advance, just one time for each distinct identifier, rather than include master data in every EPCIS event.
There are several ways that master data can be communicated from the creator of an identifier to the other parties who may need the master data. These include:
■ Using a system designed for the efficient communication of master data. Such systems include:
□ The GS1 Global Data Synchronisation Network (GDSN), for both trade item (GTIN) master data and GLN master data
□ The GS1 GLN Registry federation, for more detailed information about GLNs
■ Using the EPCIS Master Data Query as defined in Section 8.2.7.2 of the EPCIS 1.1 standard.
■ Using the Instance/Lot Master Data (ILMD) feature of EPCIS events to carry master data directly within an event. This applies to master data for specific lots of a GTIN or to specific instances (SGTINs or other instance-level identifiers).
■ Using the VocabularyList element of the standard EPCIS Header to carry master data in an EPCIS document.
■ Other means not governed by any GS1 standard.
Of these methods, GDSN and the GLN Registry are fully governed by standards and so offer the greatest degree of interoperability. The EPCIS Master Data Query, the ILMD feature, and the VocabularyList element of the standard EPCIS Header provide a standardised interface for master data, and may be used with the master data attributes defined in the Core Business Vocabulary.
A fundamental principle of EPCIS is that the party who captures EPCIS data owns that data, and is in full control of which other parties may receive it. Therefore, merely because one party queries another party for EPCIS events matching some criteria does not mean that the queried party is obligated to respond with all matching events. Instead, the queried party may choose to restrict what data the querying party receives based on business rules. This is termed “redaction.”
In general, an EPCIS service that is sending data to another party, whether in response to a query or due to some other trigger, may consider the identity of the receiving party and apply business rules to redact the data. The following possibilities for redaction are paraphrased from the EPCIS 1.1 standard, Section 8.2.2
■ The service may refuse to honour the request altogether, by responding with a Security Exception
■ The service may respond with less data than requested. For example, if a querying party presents a query requesting all Object Event instances within a specified time interval, the service knows of 100 matching events, the service may choose to respond with fewer than 100 events (e.g., returning only those events whose EPCs are SGTINs with a company prefix known to be assigned to the querying party).
■ The service may respond with coarser grained information. In particular, when the response to a query includes a location identifier the service may substitute an aggregate location in place of a primitive location (for example, a site-level GLN instead of the SGLN of a particular loading dock).
■ The service may hide information. For example, if a querying party presents a query requesting Object Event instances, the service may choose to delete the bizTransactionList fields in its response. The information returned, however, shall always be well-formed EPCIS events consistent with this specification and industry guidelines. For example, given an AggregationEvent with action equal to ADD, an attempt to hide the parentID field would result in a non-well-formed event, because parentID is required when the action is ADD; in this instance, therefore, either the parentID would have to be included or the entire event would have to be withheld.
■ The service may limit the scope of the query to data that was originally captured by a particular client identity. This allows a single EPCIS service to be partitioned for use by groups of unrelated users whose data should be kept separate (a so-called “multi-tenant” implementation).
An EPCIS implementation is free to determine which if any of these actions to take in processing any query, using any means it chooses. The specification of authorisation rules is outside the scope of the EPCIS standard: the EPCIS standard does not take a position as to how authorisation decisions are taken. Particular implementations of EPCIS may have arbitrarily complex business rules for authorisation.
7 Data Validation and System Interoperability
7.1 Validation of EPCIS events
7.2 Certification program
7.3 Requirements of program certification
7.4 Data validation portal
7.5 Certification of software
The functioning of EPCIS-based visibility systems greatly depends on the data quality of EPCIS events. For this purpose, organisations should apply validation mechanisms. These include technical, content, and integrity validation:
■ Technical validation implies that the EPCIS events conform to the current EPCIS standard from a technical perspective. In other words, events are transmitted in XML format according to the XML schema (XSD) specified in the EPCIS 1.1 standard. For specific use cases involving user or vendor extensions, best practise is to build a XSD covering the extra namespaces and XML elements required for these use cases and consider it for technical validation as well.
■ Content validation requires verification that discrete events make sense from a business perspective. For example, if the process flow in a specific use cases specifies that a pallet packing event should include an SSCC and a quantity of cases described with an LGTIN, then content validation would confirm that the packing event has that structure and not some other structure (which may be syntactically valid, but not appropriate for the specific use case). Additionally, a capture application of an EPCIS might perform semantic checks like date validation, for example to confirm the value of eventTime is not in the future.
■ Integrity validation requires that the visibility system operates end-to-end in the way described by the process map and achieves the desired business results. For example, a requirement could be that it is possible to trace back an item from the goods issue to the receiving process within a location.
Both technical and content validation can usually be accomplished at the very moment EPCIS events are submitted via the EPCIS capture interface. Depending on how important data quality is, an EPCIS repository or capturing application may only accept incoming EPCIS events if they fulfil a predefined set of technical and content validation criteria (and reject them otherwise). Alternatively, incoming events could be accepted as long as they have passed the technical validation, with warnings generated if the content validation has failed.
Integrity validation however can only be accomplished retrospectively, that is, after all events comprising an end-to-end-process have been captured. A business application which consumes visibility event data may apply appropriate rules to deal with invalid event sequences. Amongst other things, it may trigger an alert if a mandatory event to a specific business process does not exists, or it may disregard events which are obvious duplicates or which have no significance.
8 References
[CBV] GS1, “Core Business Vocabulary Standard, Release 1.2,” GS1 Standard, September 2016, http://www.gs1.org/sites/default/files/docs/epc/CBV-Standard-1-2-r-2016-09-29.pdf.
[EPCIS] GS1, “EPC Information Services (EPCIS) Standard, Release 1.2,” GS1 Standard, September 2016, http://www.gs1.org/sites/default/files/docs/epc/EPCIS-Standard-1.2-r-2016-09-29.pdf.
[GenSpecs] GS1, “GS1 General Specifications,” GS1 Standard, January 2016, http://www.gs1.org/docs/barcodes/GS1_General_Specifications.pdf.
[GS1Arch] “The GS1 System Architecture,” GS1 technical document, April 2016, http://www.gs1.org/sites/default/files/docs/architecture/GS1_System_Architecture.pdf.
[TDS] GS1, “EPC Tag Data Standard, Version 1.9,” GS1 Standard, November 2014, http://www.gs1.org/sites/default/files/docs/epc/TDS_1_9_Standard.pdf.
A Appendix: XML Examples
This section provides sample XML for EPCIS events that are displayed in tabular form elsewhere in this guideline. Each XML sample is an EPCISDocument according to the XML schema in Section 9.2 of the EPCIS 1.1 standard. Within each document, events are listed in the same order as left-to-right in the corresponding table.
In many of the tabular examples, one or more EPCIS dimensions are omitted for clarity, and placeholders like “GTIN X” are used instead of actual identifiers. In the XML examples, all such omitted details are included using sample values.
A.1 XML for EPCIS Event in Table 3‑1
A.2 XML for Example in Table 4‑6
A.3 XML for Example in Table 5‑3
A.4 XML for Example in Table 5‑4
A.5 XML for Example in Table 5‑6
A.6 XML for Example from Table 5‑7
A.7 XML for Example from Table 5‑8
A.8 XML for Example from Table 5‑10
A.9 XML for Example from Table 5‑14
A.10 XML for Example from Table 5‑15
A.11 XML for Example from Table 5‑16
A.12 XML for Example in Table 5‑21
A.13 XML for Example in Table 5‑22
A.14 XML for Example in Table 5‑23
A.15 XML for Example in Table 5‑24
9 Contributors to earlier versions
Below is a list of contributors to Version 1.1 of this guideline.
Contributors & Change Log
Contributors
Log of Changes
Useful links:
* PDF version of the EPCIS and CBV Implementation Guideline