(GS1) standards range from pallet identification to data exchange in the blockchain. Which key standards did project participants agree upon? How have they actually been integrated in the blockchain solution? What data do blockchain transactions contain? And how can it be used to feed data into the pallet accounts of participating exchange partners?
In my <link innovation blockchain-blog standards-und-blockchain>first blog post – which I penned during the development phase – I wrote about how beneficial it is to use standards in blockchains. I also outlined which standards we probably needed to use in our pallet exchange field test – and these were actually the ones that we applied! To ensure maximum scalability, interoperability and market acceptance, the consortium agree on using the following basic standards:
o GLN (Global Location Number) to identify the exchange partners
o GRAI (Global Returnable Asset Identifier) to identify the Euro-pallets
o GDTI (Global Document Type Identifier) to identify the pallet notes
o EPCIS and CBV (Core Business Vocabulary) as the data model for the event transactions saved in the blockchain, including standardised terminology
The following image illustrates how these standards were embedded in the digitised pallet note solution. In this context, it is important that all these standards implemented add value to inter-company use cases – irrespective of which data exchange technology is used (blockchain, in our case). For example, the use of standardised keys such as GLN and GDTI would also make sense if the consortium had agreed on a centralised database.
Some readers may not need to know any more than that, but those who want to know how the standards above were actually implemented into the blockchain solution, what data is included in the blockchain transactions and how this data can be used to manage the exchange partners’ pallet accounts are encouraged to read on.
Irrespective of the way companies choose to exchange data with one another – e.g. via EDI, EPCIS or GDSN – it is always critical to identify all relevant business objects in a consistent, standardised manner. Imagine the chaos that would arise if each exchange partner were to identify themselves with their own proprietary key, used their own ID to designate the pallets being exchanged and recorded all this information in a proprietary message structure using company-specific fields and data formats. The time and additional costs spent on mapping and integration would be enormous.
Fortunately, standards already exist so that these inefficiencies can be prevented from occurring in the first place.
For example, a survey conducted at the end of the field test revealed that the majority of participating partners (approximately 55%) were already using the GLN to identify their business partners. The resulting synergy effects are obvious. The GLN provides these partners with a consistent method of administrating master data, managing pallet accounts and triggering the relevant EDI messages (such as an invoice to clear pallets owing), to mention but a few.
Although the remaining 45% of the companies that took part in the survey did not answer the question about using the GLN to identify business partners, they didn’t categorically give a negative response to the question either, meaning that there is still room for improvement. However, respondents also included companies such as IT solution providers, which are not involved in any flow of goods per se and are not, therefore, concerned with the pallet exchange process. Regardless of this, however, all companies participating in the field test were GS1 licensees, which means that they did have the opportunity to use a GLN to identify themselves in a digitalised pallet exchange system.
Many readers will be wondering how blockchain transactions actually looked like. The latter were essentially EPCIS events. Since a typical pallet exchange usually consists of receiving full pallets in exchange for empty pallets (or vice versa), each transaction was broken down into two blockchain transactions – an ‘arriving’ event and a ‘departing’ event. A virtual quantity compensation, i.e. without a physical flow of goods, was mapped as an ‘accepting’ event. The following table provides an overview of the data contained in the blockchain transactions:
Blockchain also ensures the distribution of master data concerning sites and partners – anything less (e.g. a central database) would not have allowed us to achieve proper decentralisation. The design of the master data transactions was based on the EPCIS master data document (one of several ways to exchange master data using EPCIS). It contained the following data for a specific GLN:
Why is this such good news? The consortium was able to make use of established standards for the exchange of both visibility event data as well as master data, which saved a lot of time in terms of technical implementation.
The following standards were especially useful in specifying the blockchain transactions:
The next section discusses how these blockchain transactions could be used to conduct an automated balance calculation based on 100% reliable data.
Exchange partners manage pallet accounts on an ongoing basis. These tell us how many pallets one company owes to another and vice versa. The logic used to determine account balances based on blockchain transactions can be broken down into 3 steps:
Step 1: Select all transactions in which your own GLN is in the Source (e.g. Oetker) and your partner’s GLN (e.g. KV Nagel) is in the Destination. Add together the values specified in the quantity field. Any quantities that were subsequently marked as incorrect through error declaration transactions need to be subtracted.
Step 2: Ditto, the other way round (i.e. Source = GLN KV Nagel, Destination = GLN Oetker)
Step 3: Subtract the sum of step 2 from the sum of step 1 (i.e. ∑1 - ∑2). If the value is positive, your business partner (KV Nagel) owes your company (Oetker) pallets. If the value is negative, the opposite holds true.
Basically, an application needs to go back to the genesis block in order to conduct a reliable balance calculation. (In the event of any uncertainty, this method is a fail-safe way of determining the number of pallets owed).
For the sake of simplicity, exchange partners can also incorporate appropriate software logic into their business applications, for example by recording intermediate balances at the end of a billing period, so that an application does not always have to go back to the genesis block. This also works properly in case error declaration transactions pertaining to exchanges of a previous billing period are stored onto the blockchain – the balance of the next one is immediately updated.
This scenario is the most common one in practice: for instance, a company delivers full pallets to another one, and receives empty pallets in return.
For better understanding, the following graphic illustrates the physical and virtual change of pallet ownership between two organisations including two corrections (thereby, we stick to Oetker and Kraftverkehr Nagel, which actually took part in the field test):
Based on this example, the three steps would be carried out as follows:
Step 1: An application extracts the core information from the blockchain transactions and inserts it into a suitable table – for example, a simplified version of the latter could look like this:
This means that the total number of pallets that Oetker has delivered to KV Nagel is 277 (30+55+45+60+45+15+27). The 20 pallets that were loaded on Oct 3rd were subsequently declared incorrect by means of transaction #7 (e.g. as the pallets turned out to be of poor quality) and cannot be taken into account when calculating the totals.
Step 2: Similar to step 1, just the other way round. The GDTI (labelled as 'A', 'B’, etc. in the graphic above) acts as a link for each exchange process, which consists of the unloading (‘arriving’) and loading (‘departing’) of pallets.
In this instance, the quantity of pallets is 186 (30+40+24+0+50+42). Again, an error declaration transaction (#3) ‘cancels out’ a previous transaction (#2). Only the quantity entered in the correction transaction (#4) is taken into account when calculating the total.
Step 3: The difference between step 1 and 2 is 91 (277-186). Therefore, KV Nagel would owe Oetker 91 pallets in this example. This results in the following account balances:
This principle also works for more complex scenarios, e.g. an exchange between three parties, involving a pallet pooling service provider. This scenario was also included in our project.
The fact that using standards in blockchain projects can bring significant benefit in terms of implementation was not only demonstrated clearly in our field test, but also reflected in the responses to the aforementioned survey. A total of 77.8% of respondents answered to the question ‘How helpful is it to integrate GS1 standards (e.g., identifiers, attributes, data models, interface standards) into your system landscape?’ with 'helpful' or 'very helpful'. None of the participants reported that standards were ‘not very helpful’ or ‘not at all helpful’.
Another important finding from numerous discussions was that it makes no sense – nor is it necessary or efficient – to use blockchain as a data exchange infrastructure for every kind of data. In fact, the opposite is true! In the case of our project, we had a use case for which blockchain technology is a valid candidate. However, project partners never considered it an option to replace their established data exchange technologies such as for electronic invoices (e.g. to offset pallet debts) with a blockchain-based solution.
Therefore, blockchain will most likely complement – rather than replace – established data exchange technologies. With this in mind, blockchain could become a further option in the GS1 data exchange portfolio next to point-to-point data transfer (e.g. EANCOM), centralised databases (e.g. e-commerce platforms) and federated shared databases (e.g. GDSN and GEPIR). The following graphic illustrates the complementary role that blockchain could play in existing IT system landscapes:
Irrespective of the approach chosen, the use of globally applicable IDs, attributes, data formats and data models is of major importance, regardless of whether an application is based on blockchain or not.
GS1 is continuously working on key enablers and elements for future IT systems. Current examples are a modern (JSON-LD) syntax as well as state-of-the-art REST APIs for EPCIS – both predestined for blockchain applications. In addition to these technical aspects, GS1 Germany will be pleased to continue facilitating the design of governance in consortium blockchains.
Are you interested in joining peers in a motivated project team to help shape the future blockchain-based pallet exchange system? Simply get in touch with us – we guarantee exciting discussions, a valuable exchange of ideas and plenty of fun!
GS1 Germany
Comments
No Comments