Making packages talk
Putting data required for correct handling on the box in a globally standardised way independent of Sender, Carrier or Receiver
In e-Commerce the flow of a package is nearly always Business-to-Business-to-Consumer. The Consumer orders something on-line. The e-Merchant (Seller) then sends the ordered items in a package (or packages) to the Consumer (Buyer). This package may then be carried by multiple different transporters (postal and/or non-postal). Ultimately, the package may then be delivered to the location of the Consumers choice (often the home).
Currently, each transporter needs to receive a data-set in advance of the package being handed over to him/her. In general, each transporter will have its own requirements related to structure of the data set (and contents). All too often, each transporter also insists on their own format for the label affixed to the package (leading to relabelling along the journey of the package). *Moreover, each transporter may insist on using its own (proprietary) identifier for the package. * This creates a lot of confusion when communicating about the progress of delivery of the goods ordered transported in the package/s.
The sending e-Merchant as well as the Consumer (hopefully receiving the package and the goods s/he ordered) both desire to be able to consistently track where the Goods Sold/Bought are. Because of the issues mentioned above, it is difficult for the e-Merchant to provide the Consumer with that tracking information (because the transporters involved have troubles providing the necessary feedback about the package). Furthermore, the **proprietary information exchanges as well as the relabelling adds (unnecessary) cost and time ** to the end-to-end process of transporting the package from Seller to Buyer. This affects the transporters mostly, but also the Seller and Buyer, because the transporters will include those additional costs into their charges one way or another. The Scan4Transport standard provides a globally standardised way to include structured data into a 2D barcode.That enables any party reading the 2D barcode structured according to the standard to correctly interpret the data encoded in the 2D barcode regardless of the party that created the 2D barcode (according to the standard).
- As a minimum, it would be good to show that the 2D barcodes can act as “fall-back” for lack of prior information exchanges. So reading a barcode and correctly interpreting the contents (and showing this in a screen (mobile phone or browser) to a user.
- The user, should then be able to access the latest/additional information from a remote application (via the Web) based on the above mentioned standards. This may be a basic display on a Web-browser or retrieval via an API and showing that within a self-built App on the Mobile Device.
- The third “layer” would be that the operator may log an Event with a remote application (e.g., confirmation of delivery, hand-over to next transporter). This may be done via a Web-browser, an API directly to the remote Application and/or posting the Event to an EPCIS application (as described in the UN/CEFACT standard Integrated Track and Trace for Multi-Modal Transportation as a good way to easily exchange Event-Information among disparate systems).
It would be fantastic if more than one hacking team would work on this challenge and each one would focus on (parts of) the above scenario to show that a package carrying the same label with the same 2D barcode may easily be processed by different software. That would prove interoperability of these standards. The Hackathon may also provide valuable learnings related to shortcomings in the standards (e.g., ambiguity in how to interpret them when converting them into software implementations.