Skip to Content
Author's profile photo Former Member

Bringing traceability to customers

< The GTNet ecosystem | Varying complexity in traceability systems >

A new customer represents a new challenge; its production must be understood and an infrastructure must be made to allow information about production etc be transported to GTNet in XML files. The GTNet and its surrounding infrastructure is extremely flexible. To tailor the software to a particular company there are two things that must be created:

  • A Traceability Resource Definition [TRD] that describes the kind of objects that move through a company, from reception of raw material at the upstream end, via production, and to shipment of finished products at the downstream end. Such TRDs tend not to change over the lifetime of a production line.
  • Data that is created as the production line is engaged in converting raw materials to finished products. Such data can be generated several times per day, continuously through the lifetime of the production line.

The graphic above shows a typical, although schematic, presentation of a production line. The image represents a simplification; for example there are often multiple chain partners at both the upstream and downstream ends, and production can vary much between companies. Companies can have multiple production lines, but for now we will consider a single production line.

Tracetracker relies on a three step process to integrate companies with GTNet:

  1. We perform a Traceability Readiness Assessment (TRA) to uncover the company’s motivation for traceability, find key company aspects like whether there is an IT department or not, and how traceability is handled by the company’s trading partners
  2. Then we perform a Traceability Survey to document the production line, how production relates to flow of administrative information, how identifiers on incoming shipments are registered and associated with products appearing from the production line, etc.
  3. Based on the traceability survey we can design a TRD that combines the company’s objectives with the activity in the production line, and we can design a solution for export of data from the company to its GTNet domain. This type of solution may exploit the local IT department, or we design a manual routine for (small) businesses lacking the needed IT resources.

Editions and predefined TRDs

Although we stress that all companies are different, we have observed that there are often similarities between the needs and ambitions of different companies. This has helped us develop off-the-shelf solutions that simplify integration. Care has been taken to make these simplifications comply with (legal) requirements that have a strong position in the market. The result is two fixed TRDs that together with a solution with full customer flexibility make up the core of our product offerings. The main packaging of these offerings is as what we call editions. The two fixed ones, Receive only and Advanced are services that companies subscribe to, while the Enterprise edition gives customers full flexibility, allowing them to do their own hosting etc.

  • Receive only is for retailers at the end of chains. They have no need for internal traceability as their only concern is to acknowledge receipt of goods shipped to them. This is required to complete reporting of products’ movements to GTNet.
  • Advanced is for organizations that want to participate in GTNet with a simplified traceability model. The associated TRD is predefined, i.e. the steps through from incoming to outgoing, but the property set can be adjusted (so that a grain elevator does not have to relate to ear-tag-numbers on cattle). Production is collapsed into one step.
  • Enterprise is a solution with full flexibility in the data model, permitting custom design of traceable entities and their properties. While the other editions are hosted by Tracetracker, this edition can be hosted by the customer’s own IT department.
Data model (TRD) Receive_only Advanced Enterprise
RECEIVE_ONLY: fixed X    
FOOD_REGS: fixed + properties   X  
custom: full flexibility     X
Reporting solution   X X
Data access control     X
Trading partner anonymity     X
Third party application support [GQI]     X

The table above highlights differences between these editions.

The SAP Tracetracker alliance

Target customers already have SAP systems. Therefore we can skip the TRA and the Traceability Survey under the assumption that these aspects are embedded in their SAP systems. These customers will most often be “inside” the chains, i.e. having partners both upstream and downstream. Therefore we employ the FOOD_REGS TRD in modelling their traceability, and voila! – we have a shrink-wrapped traceability solution for SAP users. The following expectations of the SAP systems are vital in achieving this:

  • Reception of incoming raw materials and shipment of finished products is already taken care of
  • Internal traceability through process management that links incoming and outgoing goods with internal production steps is already taken care of
  • SAP can be configured to export the needed information as XML


The screenshot above shows key aspects of the FOOD_REGS TRD, a variant of which is used in our “Powered by SAP Netweaver” solution. The middle part called “Production” in the illustration above is removed, and the relationship between incoming and outgoing shipments goes through the customer’s SAP system.
Although the solution is simplified, one may need consultancy for making the traceability solution complete; no grain farmer would like to have her product identified by ear tag number!

Assigned Tags

      Be the first to leave a comment
      You must be Logged on to comment or reply to a post.