Return Trips

Definitions

A forward Trip is a standard journey from a source to a destination. Also simply called a trip. In most cases, a Forward Trip is a trip with a vehicle loaded with the consignor's cargo destined to deliver at the consignee’s shipping address.

A return trip is a journey back from a destination.

A round trip is a journey from origin to destination and back from destination to origin.

This page is a work in progress concept. Feedbacks are welcome. Do not implement this yet.

Organisation

Name

 

Name

 

Mohit Shukla

Author

Krishan Mishra

Reviewer/Approver

Siddhartha Srivastava

Reviewer/Approver

Mayur Aggarwal

Reviewer/Approver

Amardeep Chougale

CC

 

Solution Definition

A simple return trip is implemented by orchestrating trip creation and maintenance inside the Freight Tiger Integration & Orchestration Layer. For this purpose, Itinerary - Multi Leg Trips is used.

A return trip can be created as a Multi-Leg trip with 2 legs.

  1. First leg: Source to destination

  2. Second leg: destination to source

Creation of a return trip

To create a round trip, call Add Trip Itinerary API from the source system (SAP, ERP, etc). For details of data to be passed refer to Add Trip Itinerary API and Create Trip API.

Categorising trips into a forward/return journey

Trips can be categorised using custom_fields field in the trip payload.

{ "lrnumber": "LR123", "loading": {}, "unloading": {}, "custom_fields": { "tripCategory": "RETURN TRIP" }, }

Reporting & Analytics as per Return Trip tag

During reporting an analytics return trips can be filtered out using the field trip.custom_fields.tripCategory.

Reports for measuring TAT, transit times etc can be configured by including or excluding return trips as needed.

Waypoints

Same or different waypoints can be given for forward and return trips.

Knowing if the vehicle is returning as desired

Assuming that waypoints are correctly configured alerts will be triggered for route deviation, long stoppage, etc. Refer https://freighttiger.gitlab.io/api-docs/?file=./api-docs/alert-webhooks.yaml . Required actions can be taken on alerts.

Future Roadmap

  1. The return trip functionality will be retrofitted in FT Core at a later point in time. Then, the use of the orchestration layer to achieve this can be discontinued. The customer insights that we get from this implementation will be used as feedback for defining a more nuanced feature in FT Core, when that happens.

  2. Indent, bidding, ePOD can be enabled for return trips. But this will be taken up later once the shippers start to create return trips as described in this document. Currently, we keep this out of scope.

Future Product Requirements

Note: Following requirement will only be available when full-fledged product will be developed. This page describes the minimum viable feature to get started and does not aim to cater to all fine grained requirements as listed below.

  1. Show forward and return journeys in a map view with different colour coordinates. This will help the user to visualise the movement and understand the exceptions, especially with our existing trail feature.

  2. Three new columns to be added in the underlying report. Overall Trip TAT ( Forward + Return), Forward TAT ( currently shown as transit TAT) and Return TAT.

  3. Way-points play an important role in the feature. Few minor enhancements around this -

    1. Custom configurations

      1. Different geo-fences can be configured. Capability to customise the shape as well

      2. Alerts basis time spent inside the way-point, entry and exit.

    2. Last mile configurations for return trips. This feature will be extremely helpful in planning the next load for the plant

  4. Share the return( basis last mile configurations) vehicle details to Yard/SAP for Indenting or even FT’s indent module

  5. Ability to automate/schedule hourly reports to get the below details

    1. Vehicles reached the destinations and unloading completed

    2. Vehicles in last mile

    3. Vehicles entered the plant’s geo-fence

 


Usecases

Use case 1 - Container Movement between Port & Plant

The vehicle has to go from port to plant and then from plant to port.

  • Ports will be added in master data as known locations (optionally)

  • Origin in MPMD API will be port

  • Stop 1 will be plant

  • Stop 2 will be the port (same as above)

  • Plant ID will be the same for both legs of the trip (port-to-plant and plant-to-port).

  • trip categories:

    • "tripCategory": "EMPTY CONTAINER" for leg 1

    • "tripCategory": "LOADED CONTAINER" for leg 2

  • All custom fields (especially "tripCategory") must be part of reports and dashboards for data filtering. Note: this needs to be implemented in Looker.

Use case 2 - Manual Creation of Return Trips

  1. Forward journey trip is created manually on FT UI

  2. Auto closure of trips on Geo-Fence entry or exit. This needs to be configured in Lego.

  3. tripevent.completed webhook will call Create Return Trip API in the orchestration layer (to be developed)

  4. trip categories:

    • "tripCategory": "RETURN JOURNEY" for return trips. (will be done via API)

Question: How do we enable different views for different legs of trips?

For example the return trip is used for planning of loading function and thus plant users would like to view it separately and filter it based on ETA

2. For manual creation, how do we ensure it is done only for Coke Company and not for any other companies on FT platform

 

Solution Implementation

Following Orchestration Layer APIs will be created:

API Name

Description

API Name

Description

Add Round Trip

payload will be similar to MPMD. The API will call MPMD to create a 2 leg itinerary. A to B and B to A

Add Return Trip

Input: Trip ID (lr_number)

Will call Add Trip API to create a return trip using the data of the trip id passed as input

This API will create the return trip (origin and destination will be opposite of the forward trip). Following fields in this trip will use the same data as the forward trip and the rest of the fields will be ignored

  1. vehicle number, driver name, driver numbers, cleaner numbers

  2. location source, portable tracker id

  3. plant code

    1. waypoints, route, transporter

Webhook Implementation

tripevent.completed webhook will be caught and will call Add Return Trip API in the orchestration layer (to be developed)

 

Post your questions in the comment box to get answers from the experts who watch this page.

For engineering support: visit FT Support