ONeCSD - Simplifying digital interactions
Inspiring slide from official IATA ONE Record team
Adding the QR code to the screening order
Confirming the screening
Download for paper and stamping lovers
Printing for paper and stamping lovers

The problem your project solves, including which ONE Record challenge(s) are addressed

For any export shipment, cargo must be screened before loading. A substantial amount of freight forwarders finish the Airwaybill and create a screening order to an external agent to secure the cargo at the same time. Usually, the security screening happens after the AWB is created. The freight forwarder triggers and controls the process, which is then performed by a trucker bringing freight and papers to a 3rd screening party. The screening party adds documents about the screening result but due to time pressure in air freight, a lot of freight forwarders do not update the security information of the shipment. Instead, the AWB and security confirmation on paper is delivered directly to the departure airport. This is a cumbersome, unreliable process where a lot of paperwork is involved. Our project aims to streamline this process and address it at the source of the responsibility: The forwarder.

The project got inspired by a slide from official IATA ONE Record team about the eCSD process. Additional we know some of our SME forwarder customers are struggling with 3rd party security screening and the Consignment Security Declaration (CSD).

We are addressing challenges 1 and 6

Challenge 1 rationale (Special cargo validation): We address the special case where unsecure freight leaves the export agent’s warehouse and is screened by a 3rd party on its way to the departure terminal, without any redelivery to the export agent. This requires special handling and validation because 3rd screening parties have no contract and no data exchange with the airline nor the GHA. Today, security documents arrive on paper, sometimes even as a stamped paper Airwaybill copy rather than a CSD document. Our solution aims to digitalize the process and to provide the security declaration directly via ONE Record, thus reducing waiting times and eliminating manual entry at GHA.

Challenge 6 rationale (Open): We use the ONE Record API to digitalize the process.

Your solution and what it does

ONeCSD enables screening providers to digitalize their paper process - without adding any new technology or data exchange on the screening providers side (or even make them participating in ONE Record). ONeCSD features to digitalize and update an ONE Record based Waybill with a security screening result - just by using a internet connected smartphone or pad.

As a special goodie we intentionally did not develop an App to eliminate another potential hurdle and we also showed that technically not even a login is required to at all (eliminating another potential hurdle).

How did you build it?

To closes the gap between a ONE Record shared airwaybill and paper CSD, we created a webservice running on behalf of the forwarder, which has read and write access to all relevant data, especially the ONE Record server of the forwarder.

The connection between the ONeCSD server and the screening provider is established about a dedicated URL coded in a QR code, which is added on the screening order PDF/Print, which is generated by the forwarder.

The key here is the webservice is already running on behalf of the forwarder who is owning the Waybill. Every ONE Record forwarder server runs it’s own ONeCSD webservice instance with it's own URL. And since the webservice in charge is linked to the ONE Record server of the responsible forwarder, it can directly access and update the Waybill, which got created before by the forwarder already previously.

As a result the AWB is updated in real time as the screening information is saved.

Technically our GitHub project can by choice provide a deployable docker file or provide a runnable Springboot Jar file (see README.txt).

What are you proud of?

Usually in this scenario the freight is directly trucked from screening provider to the airport with the screening result on paper, but without updating the electronic Waybill: We are proud of digitalizing a process with ONE Record in a scenario considered to not being solvable in traditional CargoIMP/CargoXML.

We are happy being able to solve some technical problems we stumbled into when using the provided AWS hosted NE:ONE servers while updating the ONE Record Waybill with the Security Declaration.

What is next step for your solution and how will you take that step?

We might consider adding access restrictions (legitimation via domain/mail validation of the screening provider) although they are technically not necessary to make it work.
Adding parameters to configure the linked and assigned ONE Record server and credentials for the token request service