Distribution

Requirements

The Modernizing Cargo Distribution working group (MCD) has defined the standardized Sales & Booking process to highlight the business and data requirements of Distribution. The current Sales & Booking process is the following:

In addition a specific Cancellation process has been defined:

In this process, the quote request should contain a minimum set of information:

The second step, airline presenting booking options, needs to ensure that the following data are included:

The booking confirmation step ends the Quote & Book process, it should ensure that some data are validated and agreed between the two parties. The data are:

Further discussions with MCD working group members allowed to identify the need to properly track the shipment status and data throughout the shipment lifecycle. Essential shipment data such as Weight can evolve as the Quote & Book process moves forward, the data model and ONE Record specifications need to ensure that this is possible. The group came up with a proposal for a standard shipment lifecycle as depicted below:

This is an example of a typical shipment lifecycle that should help standardize some of the events and milestones that are required on the business side of the Quote & Book process.

Chosen approach in the data model

The chosen approach is on multiple levels to make sure that all requirements are met.

Definition of appropriate objects to reflect Distribution

Four main objects have been defined to represent the Distribution: - Booking Shipment: In the context of Distribution, and only distribution, the BookingShipment is a simplified mix between Piece and Shipment to meet a quote request minial requirements. - Booking Option Request: It refers to the quote request. - Booking Option: A Booking Option is an offer made by a carrier that is supposed to be bookable. - Booking Request: It refers to the booking confirmation request, equivalent to (X)FFR message. - Booking: Used for confirmed bookings, it contains all information that have been agreed between customer and carrier.

Along those two main objects, a few simpler objects are added to ensure that all information are available for the Sales & Booking process. It includes Routing, ScheduledLegs, BookingTimes, BookingSegment, CarrierProduct, Price, Ratings and Ranges.

Ranges are included to address challenges where cargo tendered to Airline has variance versus the booking option request dimension and/or weight.

As the Sales & Booking process may occur before actual operations, we have chosen to allow for some data property at BookingOptionRequest level that are to be used for the sole purpose of the quote request. Thus the expectedCommodity and requestedHandling data properties are used at an early stage to indicate what the forwarder intends to ship. The BookingShipment object, which is still being finalized, is also used for that purpose, with more detailed information on intended shipment.

The expectedCommodity values are to be discussed and decided by the MCD working group, the requestedHandling values shall refer to special handling codes.

ONE Record mechanisms to ensure keeping track of data throughout the lifecycle

Like all Logistic Objects, Shipments can have Events. An Event can record the state of a shipment (e.g. “Quote Requested, Booking requested, etc.) and reflect the lifecycle.

The Audit Trail specified in ONE Record API can be used to recover older versions of the objects based on, for instance, a specific date and time.

Data model

Details of the objects and their data properties can be found in the Ontology file or the Ontology Visualizer. High level overview is presented in the figure above.

API mechanism

Based on the Data Model, a standard API workflow has been designed. The use case shows an interaction between a Customer (Freight Forwarder) and a Carrier where both stakeholders have their own ONE Record servers. Using a 3rd-party service provider would be the same workflow.