FAQ
From TraceFood
What is the intended use of TraceCore XML?
"The intended use of TraceCore XML is in the food industry, to exchange traceability information. By traceability information, we mean information keyed to a unique identifier ..." - The TraceCore XML Design Criteria document.
So, you can use the TraceCore XML to code and exchange information keyed to a unique identifier. You cannot use TraceCore XML to code and exchange information keyed to identifiers that do not have referential integrity, nor should you base recordings or traceability on this type of identifiers.
Why is unique identification important when it comes to traceability?
The fundamental principle of unique identification is as follows:
If you want to trace what happens to the entities / trade items / materials between A and B then the unique identifier (or, if you have more, at least one of the sets of unique identifiers) must be linked to entities / trade items / materials that are guaranteed to be kept together from A to B.
How to identify a batch and record information on this entity?
The reference is the GS1 standard, and GTIN+Batch number is what GS1 recommends as identifier if you want to record information on batch level only (middle row of diagram on page 12 in the GS1 guide). This is not the identifier we have chosen to base TraceCore XML documents on; we have chosen the top, right hand corner of the diagram, where SGTIN is the identifier.
Why is it necessary to have so limited application on the identifier of trade units?
Traceability based on unique identifiers and referential integrity is what we are making a standard for; it is what is written in the design criteria for the standard, and it is what was stipulated in the R&D projects where a lot of the development work is funded. The core group of the projects it is referring to has visited dozens of production plants in many different food sectors, and in every single one, without exception, have we seen significant and systematic information loss, especially related to chain traceability (when the product and at least some of the related data is passed on to the next link of the chain). A lot of the data loss is because the currently non-unique, local and "bad" identifiers are not suitable for keying the necessary information to. We do not want to make a standard for automating that mess, nor would we ever get public funding for it. We are making a standard for exchange of traceability information based on unique identifiers and referential integrity precisely so that we, for the companies that want it, can show them how to plug the information leak that they currently have, and to introduce them to the added functionality and value that they can get out of a tighter identification regime. Many companies will, by choice or necessity, live with the old non-unique identifiers. That's OK, but the TraceCore XML standard is not mainly designed for them (although they can probably still use parts of it).
Why is SSCC not recommended to use to identify trade units?
This is a real and practical question for many companies; SSCC is a well-established number series (much more so than SGTIN), and it is tempting to try and build a product traceability system on it. Some of you will find the reply too strict and idealistic, but anyway the suggested reply is below, feel free to comment to Petter Olsen.
"Going from no international standard to SSCC (which this is all about) is a great first step in the right direction. However, SSCC is a code designed for traceability of shipping, not of products (or lots, batches, trade units, or whatever). All our recommended traceability, including TRACE Good Traceability Practice (GTP), is based on marking the trade units with the SGTIN code (Serial GTIN) which contains a code for the originating country, company and product type as well as unique serialization of the instances of the same product. You will never have SSCC on each individual trade unit; you will have it on the pallet or on the container, and that SSCC will (or should) be linked to each SGTIN code of the trade units in the pallet. SSCC is, as mentioned, a good first step (and no doubt fine for the custom authorities), but the many limitations of SSCC means that you cannot base product traceability on it.
- when you ship a pallet with trade units on, you can be quite sure that the trade units will be whole when they reach their destination, but the pallet might have been opened and contents split and joined across new pallets and new SSCCs, so the pallet that is received by your customer might have a different SSCC from the one you sent.
- pallets often have mixed content, so product information cannot in general be linked to the SSCC. GS1 makes it clear that SSCC is for shipment traceability, SGTIN is for trade item traceability.
- when you create the pallet and the SSCC, you can record the identification of each trade item that goes into it. The other way doesn't work; when you create the trade unit and the SGTIN, you have no idea what pallets it will become part of (you might know the first one, but not the subsequent ones)
- some of the information that is often relevant anyway is in the SGTIN code (country, company and product type); the SSCC is "meaningless" and a look-up to decode it is always necessary.
- SGTIN is more robust with respect to missing recordings. If you produce SSCC-identified pallets with SGTIN-identified Trade Units on and the joining and splitting of pallets at the distribution terminal is undocumented (often the case in practise), the SGTIN on the Trade Unit will still provide you with the link to the related product parameters and to the first pallet / SSCC. If, on the other hand, you base your traceability on the SSCC with no unique identification of the Trade Units (typically GTIN and BestBeforeDate only) then you have no chance to find which shipment and pallet the Trade Unit was part of originally."
How to identify this product: a bakery produces a dolly containing 25 trays of bread, each dolly has an SSCC and each tray is identified by GTIN + BestBeforeDate, they can not place an SGTIN on each produced tray?
Simplistically, without taking the whole hierarchy of items into consideration, the basis of a modern traceability system is:
1) Decide on what level you want to trace (single bread, trays, dollys, shipped boxes/cases of bread, whatever) 2) Give items on that level (hopefully globally) unique identifiers so that you have referential integrity for the item identifiers 3) Link all information to the unique identifiers 4) Keep track of and record transformations, which is when your uniquely identified items goes through a process where they are joined together with -, or split up into new items, and as a result of this process gets a new identifier (or, in case of splitting, a set of new identifiers).
The "GS1 Traceability Standard - What you need to know" is clear on what this means in terms of identifiers (page 12 in the guide):
- If you want to record information related to trade units, use GTIN / SGTIN for identification.
- If, for a trade unit, you want to record information on the originating batch _only_, use GTIN + Batch Number (in the bakery example, GTIN+BestBeforeDate)
- If, for a trade unit, you want to record any possible information linked to the trade unit (including environmental parameters or application / transport that only apply to this unit), use SGTIN.
How should a mixed dolly (pallet) containing 25 trays of bread (each dolly has an SSCC and each tray is identified by GTIN + BestBeforeDate) be described?
The problem here is that GTIN + BestBeforeDate is not a unique identifier for the item in question, even when combined with the SSCC. As long as the Logistic Unit (pallet or dolly or whatever) is kept whole, the SSCC is the unique identifier for everything in the Logistic Unit. When the Logistic Unit is opened up, or new Logistic Units are created, for instance by joining and splitting existing Logistic Units to meet customer orders, you lose referential integrity for your (original) SSCC+GTIN+BestBeforeDate.
By "referential integrity" we refer to the fact that a given identifier should uniquely "point" to an item which should only ever be in one place at one time. If you do not have referential integrity, you cannot record any environmental parameters like temperature, humidity, pressure, GPS or similar linked to the identifier, because another item with exactly the same identifier might have a different set of properties entirely. Even worse; if you do not have referential integrity you cannot record transformations, application of items in processes or transportation, because there is no (traceable) way of recording the information "I transformed / used / transported item 12345" because there is another item 12345 somewhere that this is not true for.
Recording and exchanging information linked to an identifier that does not have referential integrity (at least for a given duration) has very limited application, and is not supported by TraceCore XML. The SSCC+GTIN+BestBeforeDate only has referential integrity as long as the items referred to by the SSCC are kept together, in practice while the Logistic Unit is kept unopened. When the Logistic Unit is unopened, the information can be linked to the SSCC directly; the GTIN+BestBeforeDate is not needed.
6 bottles are wrapped together in plastic to make a 6-pack in a mineral water production. 6 6-packs make up a case and finally some numbers of cases make up a pallet. The question is, is it sufficient to have unique identifier on the pallet only, or should they introduce unique identifiers on one of the lower levels in the product hierarchy (cases, 6-packs, individual bottles)?
The answer is that depends on your level of ambition, or more specifically on the scope that you want for your traceability system. To use the terminology above, you want to trace what happen to your entities / trade items / materials between A and B, and A is your own plant, but what or where is B? If B is your distribution terminal, and you don't care what happens to your products after they have been received there then unique ID on the pallet only is fine. If, on the other hand, you want to trace to restaurants and retailers, you have to have unique IDs on the cases, because that's what they receive. If you want to trace to the consumer, or you want to enable the consumer to trace his or her own product (for instance on the internet) you need to have unique IDs on the individual bottles. Note that with GTIN+BestBeforeDate only on the bottles (as in the current system), the consumer can only trace the properties common for the originating batch, but nothing about transportation route or environmental parameters.
Three pallets received at a warehouse from a supplier and two pallets picked from the supplier pallets to two customers. Which entities (pallets or trade item) to trace and how should these be identified to fulfil traceability?
If A is the supplier and B is the warehouse we have no problem; pallets leave A whole and arrive at B whole, so tracing whole pallets is sufficient. If, on the other hand, A is the supplier and B is the customer, then by omitting unique identifiers on the trade items, the supplier has made it impossible to make the traceability available to the customer. It is of course true that the customer will know GTIN and BestBeforeDate of the received product, but that is only information about origin, not about transportation route and environmental parameters; information which a good traceability system should also be able to provide. So, to get that traceability, the 50 trade items in SSCC 1111 would have 50 different identifiers, and in the splitting of SSCC 1111 into 4444 and 5555, you would record the ID of those 45 that went into 4444 and associate the ID-list with that SSCC, so that any information linked to SSCC 4444 (departure time, GPS at time, temperature at time, arrival time, etc.) would be "inherited" by the 45 units on the list.
Why should I give trade items unique identification?
Let's say that the warehouse is an independent company, and that they, for some reason, decide to implement the best traceability system in the world. This would include the work involved in documenting exactly what happened every time they joined and split pallets, so they would have to scan the ID of every trade item that was moved from one pallet to another. This is cumbersome, but doable if the ID is on a bar code; much simpler if it is on a RF-ID tag. The problem now is that by completely omitting any sort of unique identifier on the trade item, the supplier has made it impossible for the warehouse to get this traceability. Imagine if the BestBeforeDate of the units in SSCC 2222 was also 01-03-07; then once the 40 units from 2222 were mixed with the 5 units from 1111 they would be indistinguishable. The point is that even if the warehouse were willing to do the extra work to prevent this mixing from happening, they would be powerless to prevent it; there would be nothing on the items that came from 1111 that distinguished them from 2222. The warehouse could keep the items from 1111 and 2222 apart even after the pallets were opened, but there would be no way to prevent the undocumented mix once the units went into 5555, as printing new labels on trade items is hardly the prerogative of the warehouse. This illustrates why, when we implement traceability in our pilot chains in our R&D projects, our first recommendation is almost always "Give your trade items unique identifiers! It doesn't matter that you do not use them; someone else might, and the cost for you involved in this is negligible; normally just the label printer settings need to be changed.".
The amount of registration that has to be done when splitting single item pallets to customer mix pallets as in the question above would create a huge extra workload, not event taking into account the amount of data that has to be stored. Is this necessary?
The example is very relevant, and it will be comment in detail. We do not dictate uniqueness of all items, but we do say that the standard can only be used to exchange information about those items that are uniquely identified. That is the whole point; that is what we are making a standard for. We are well aware that not all items in the industry are uniquely identified; but we are making a standard for exchanging information about those who are. The reason for this is that a lot of the functionality and the benefits that we want depend on the referential integrity discussed in the previous post.
