Mapping Specific Settings

Owned by eknoor.singh (Unlicensed)
Nov 07, 2023
2 min read

Using this document, users can understand the mapping related settings done on the Shipsy portal.

Instructions

Navigate to Carrier Tracking

  1. Click on the hamburger menu icon

  2. Click on integration setup to expand drop down list

  3. Select Carrier Partner

  4. Navigate to Carrier Tracking sub tab

Navigate to Settings

  1. After being redirected to Carrier Tracking, user will by default land on the status mapping sub tab

  2. Click on settings to navigate to the settings sub tab

Configuration Settings

Terminal Status

This setting allows users to define the terminal status for tracking via API. Terminal status is the stage at which the tracking process ends using API. This is crucial because API-based tracking is script-based and must conclude at a specific step. By default, the system lists terminal status to stop tracking at a defined stage. Note that this does not affect tracking via webhooks, as webhooks are sent by third parties and are consumed without restrictions.

RTO Triggers

This setting is important for recognizing when a Return to Origin (RTO) journey has commenced. It enables the system to make necessary adjustments and ensures correct mapping of statuses, especially in API-based tracking. RTO journeys may involve multiple statuses received at once, and setting an RTO trigger allows the system to handle these statuses correctly. For instance, if the RTO trigger is not set, and the status "in_transit" is received for an actual RTO journey consignment, it can be rendered as "rto_in_transit." This setting ensures that the system identifies the trigger point for RTO journeys accurately.

Default Status (Forward)

When a status is not mapped in Shipsy and is received from the 3PL, users need to determine how it will be handled. There are three options:

  1. Map it to "in_transit," indicating that the courier is en route.

  2. Map it to "exception" if the received data is unknown.

  3. Map it to the previously received and mapped status in Shipsy. This approach provides a consistent and well-defined journey flow for the end user.

Default Status (RTO)

Similar to the forward flow, this setting allows users to specify how unmapped statuses in RTO journeys should be handled.

Ignore Unmapped Status

By default, this setting is turned off. When it's off and a status from the 3PL is not mapped in Shipsy, the system follows the rules defined in the Default Status settings (points c and d). However, if you enable this feature, any unmapped status will be ignored, and the consignment's state will remain unchanged. It's as if the status was never sent, making the settings in points c and d redundant.

Custom Status Names

On the left section of the page, users can define custom names for various statuses. These custom names will be used in place of the system-defined status names. For instance, if a user wants to display "Delivered to customer" instead of "Delivered" for a specific status, they can define this mapping here. If they choose not to define anything, the default system-defined names will be used for all consignments.