A Quick Guide to EPCIS Events and How to Use Them

According to GS1, the goal of EPCIS (the Electronic Product Code Information Services) is to enable companies to create and share data. EPCIS does this with events.

Understanding EPCIS events is crucial. Indeed, you may already understand EPCIS events. On the other hand, it is quite possible to use EPCIS events every day and never truly understand their meaning.

If you or your organization wants to understand more about EPCIS events, one way is to read GS1’s EPCIS 1.1 Specification. Fair warning though; this “169-page sleeping pill” can be downright daunting if you don’t have a solid technical, supply chain, or even GS1/EPC Global background. Another way to better understand EPCIS events is to read this post.

Let’s take it from the top: The goal of EPCIS 1.1 is to enable disparate applications to leverage Electronic Product Code (EPC) data by sharing that data. The EPC data is shared within and across enterprise boundaries. Sharing this data enables all participants within an EPCIS 1.1-compliant ecosystem to gain visibility into the status of all EPC “marked” digital or physical items (also known as EPCIS “objects”) within a given business context.

Simply put, EPCIS 1.1 provides a framework that allows trading partners to know the status of a given trade item or conveyance. EPCIS events affect the status of a trade item or conveyance by changing or setting the object’s disposition (its current state, such as sold, expired, recalled, in transit, or active).

The fundamental purpose of all EPCIS events is to provide details on the “What”, “Where”, “When”, and “Why” of items as they move through the supply chain. In EPCIS parlance, these are known as the four dimensions of an EPCIS event:

1.    What: The “What” refers to the objects that participated in the EPCIS event. The term “objects” can refer to digital or physical items. For example these “objects” could be anything from a document to fully loaded rail cars. There are two classifications of objects in EPCIS: Class-Level and Instance-Level. Each will affect the What dimension very differently.

Class-Level – When multiple objects can share the same identifier, that identifier is said to be a Class-Level identifier. Class-Level types are used when it makes little sense to assign a unique identifier to each object of the same classification. This is almost never which can be somewhat confusing.

Let’s use a batch or lot as an example. A single batch/lot will contain multiple objects. In order to maintain an association between the batch/lot and its objects, it makes sense to have a single identifier for each object within the batch/lot.  For example, a single identifier can identify an entire lot of products. Therefore this identifier is considered a Class-Level identifier. Examples of Class-Level identifiers include: LGTINs, GTIN+Lot Number, GTINs without serial numbers, GRAIs without serial numbers and GDTIs without serial numbers.

Instance-Level – An identifier is considered Instance-Level if it is unique to a single object. No two objects can be assigned the same Instance-Level identifier. Unlike the batch/lot example, here the object must be uniquely identified. That object may be a pallet, case, carton, product, document, or other asset. Example encoding types would be SSCC, SGTIN, GTIN AI(01)+(21). Notice the main difference between Class and Instance level is the either presence or absence of a serial number.

I mentioned above that these classifications will affect the What dimension differently in an EPCIS Event.

As a rule, Instance-level identifiers allow EPCIS events to express more detail. This is because it is possible to associate multiple EPCIS events’ What dimension that include the same Instance-Level identifiers. The EPCIS events contain one or more of the same identifiers. Each EPCIS event will affect the disposition of its identifiers differently. Therefore, the What dimension is changed multiple times, leaving a trail of “what” happened to a particular identifier.

At the same time, if multiple EPCIS events contain Class-Level identifiers, then it is not a certainty that the same object participated in all EPCIS events. This is because the EPCIS events could have been different instances of the same Class-Level.

2.    Where: The “Where” refers to where the event took place, and is indicated by an SGLN (Serialized Global Location Number). The SGLN is used as a unique identifier linking the EPCIS event to a location. Details of the location’s information are normally kept in Master Data. The readPoint element of the EPCIS event will indicate a specific place and/or business location (bizLocation) at which the identifier was last seen.

A readPoint can be a barcode scanner on a conveyor belt or a hand-held scanner at a door. It can be anything, but should be more specific than a business location (which, by the way, can be a room, a building, a floor, etc.). A manufacturing plant would be a business location with several readPoints. One way to remember the distinction is to generalize and say that readPoints are doors and business locations are rooms.

3.    When: When did this EPCIS event occur? The When is indicated by an eventTime attribute on the event. Some EPCIS systems will let events be captured without regard to chronological order.  NOTE: Avoid these systems. For example, all identifiers, GTIN, SSCC, GLN, GRAI must be commissioned before they can be “used” within an EPCIS network. Once commissioned, the identifiers can be used for any number of purposes.

If an identifier is used with an eventTime that is before it was commissioned, this could indicate poor or improper EPCIS 1.1 Specification compliance or nefarious activity.

4.    Why: Why did this event occur? For example, to ship product, the product must be commissioned and packed into containers. The containers must then be packed onto pallets and finally, shipped to its destination. Each of these steps in the process can be represented by an EPCIS event.

The Why dimension of an EPCIS event is the Business Step (bizStep). The bizStep tells us “why” an EPCIS event was produced: was it for commissioning, packing, shipping, etc.?  The bizStep can refer to one of the Core Business Vocabulary (CBV) business steps or to a user-defined business step.

The disposition is also part of the Why dimension of an EPCIS event.  Again, an object’s disposition refers to its current state such as sold, expired, recalled, in transit, active, etc. The Core Business Vocabulary (CBV) also defines various dispositions and when they should be used.

Another important part of the Why dimension of an EPCIS Event is the Business Transaction information. The Business Transaction is simply a link to transaction information that provides insight into why the EPCIS event was generated.

Finally, the Source and Destination are part of the Why dimension of an EPCIS event. Source and Destination simply depict a transfer of ownership. 
Analyzing any of the four attributes of an EPCIS Event (bizStep, disposition, Business Transaction, and Source and Destination) will certainly define “why” an EPCIS Event occurred.

In EPCIS 1.1, there is one abstract EPICS event from which the remaining five EPCIS Events are derived. This is the EPCISEvent. It is the base EPCIS event.

All of the following five EPCIS events inherit from the EPCISEvent.
•    Object Event: An EPCIS event used to mark an observation or assertion about an object or objects.
•    Aggregation Event: An EPCIS event used to associate one object or a number of contained objects with their containers. This association is often called aggregation, containment, or packing.
•    Transaction Event: An EPCIS event used to associate or disassociate objects to business transactions.
•    Transformation Event: An EPCIS event used to represent objects that are consumed in one form and produced in another form.
•    Quantity Event: An EPCIS event used to capture a specific quantity of an object. GS1 is now discouraging the use of this core EPCIS event. It advises in the EPCIS 1.1 specification that an ObjectEvent containing one or more QuantityListElements be used instead.

An EPCIS Event Action provides insight into how an object relates to a business transaction within the life cycle of an EPCIS event.
There are three types of EPCIS Event Actions.
•    ADD: The object(s) have been created or added.
•    OBSERVE: The object(s) have not been changed, meaning the object has been not been created, added, destroyed, or removed.
•    DELETE: The object(s) have been removed or destroyed.
The above descriptions of EPCIS event actions are very generic. Each action takes on a different and more concrete meaning depending on which type of EPCIS event it belongs to.

This post has been a tad dry and academic. Nevertheless, knowing the fundamentals of EPCIS events will go a long way during practical application. To wrap up, let’s take a look at a look at EPCIS events in action.

Aggregation EPCIS

Looking at the above example, an Aggregation EPCIS Event is used to pack items into a case and, subsequently, to pack that case onto a pallet. Both events have the same action: ADD. This is because the EPCIS events are making an additive change. Notice also that the ParentID is used to keep the relationship intact between parent and child objects. The case is the parent to the bottles and the pallet is the parent to the case. Simple right? In the above example, both actions represent two EPCIS events. Each EPCIS event will have the What, Where, When, and Why dimensions explained earlier in this post.

EPCIS events are central to EPCIS 1.1. Understanding EPCIS events is critical to understanding not only EPCIS but also track and trace.

In this post we see the tip of the iceberg. There are many other things to learn about EPCIS events. But it is unlikely that you can learn all you need to know by simply reading blog posts or even the EPCIS specification. Experience is the best teacher of EPCIS Events. It is one thing to understand EPCIS Events in the abstract, and quite another to know how EPCIS events leaving your warehouse impact your trading partners.

At the time of this writing, it has been more than 12 years since GS1 released its EPCIS specification. Even so, there is still a lot of misinformation and confusion around EPCIS and EPCIS events.

Practical experience is a great teacher. You can also reach out to vendors like Frequentz to learn more about how EPCIS events are used and how you can benefit from the valuable information these events provide. Here at Frequentz, our staff includes some of the world’s foremost experts on EPCIS. Not only do we understand EPCIS and EPCIS events, we were also instrumental in defining the original EPCIS specification and remain active within GS1.

Please visit again and connect with us anytime at frequentz.com/social or email blog@frequentz.com.

Read more from Chuck Sailer on other GS1 Specifications.

About Chuck Sailer

Chuck Sailer serves as Vice President, IRIS Product Management at Frequentz.  He is an architect, developer and project leader with notable success in designing, developing and implementing all facets of world-class commercial software in a broad range of industries and technologies.  Chuck also blogs about software topics from programming to track, trace and serialization at chucksailer.com.

One Comment

Leave a Comment