ShipsyKnowledge Base

Carrier Mapping specific settings

Article cbHaG19w · source

Need to understand the mapping related settings done on the Shipsy portal.

Prerequisites (if applicable): Mapping should have been defined.

Instructions:

  1. Navigating 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

  2. 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

  3. Configuring Settings:

    1. 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.

    2. 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.

    3. 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.

    4. Default Status (RTO) - Similar to the forward flow, this setting allows users to specify how unmapped statuses in RTO journeys should be handled.

    5. 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.

    6. 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.

  4. Navigate to Shipsy portal > Setup section > Carrier Partner > Courier Tracking

  5. Under the Courier Tracking page, click on the Settings tab.

  • Terminal Status: A selection can be made to define the terminal status for tracking to be done via API. Since API based tracking is a script based mechanism, it has to end at a specified stage and those are generally terminal status. As a default, we list down all those terminal status so that tracking can be stopped at a defined step. Note that this will not prevent tracking via webhooks as webhooks are sent by third parties and are simply consumed whereas API calls are something done by Shipsy and can be stopped when defined.
  • RTO Triggers: It is important to know when a RTO journey has started so that the system can make necessary changes and at the same time correct mapping can be done. This is also essential for API based tracking as many status can be received at once and status post RTO should be handled accordingly. For example if the RTO trigger is not set and the status received is in_transit for an actual RTO journey consignment, then it should be rendered as rto_in_transit. This is only possible if a RTO trigger is set such that the system has the correct trigger point for RTO journey.
  • Default Status (forward) - When a status is not mapped in Shipsy and is received from the 3PL, then it has to be handled somehow. For such cases, there are 3 options only:
  • Either map that to in_transit which basically means that something is happening and the courier is on the way or map that to an exception since the data received is not known. However, both in_transit and exception may not work for some setup and this is where the third method comes handy which is to map it to the Previous Status received and mapped in Shipsy. This way the journey flow seems consistent and well defined for the end user also.
  • Default Status (RTO): Similar to a forward flow, the handling must be done for RTO flow as well and this is managed here. Note that the value differ here as this is an RTO flow but the intent remains same
  • Ignore Unmapped Status: This setting is turned off by default. When a status from 3PL is not mapped in Shipsy, then it goes to a Default Status as per the settings defined in point 3 and 4. However, sometimes the user just wants to use what is mapped and totally ignore anything else. Upon switching on this feature, anything that is not mapped will be simply ignored by the system and the state of consignment remains as is. It will be like nothing was sent and no change was made. Since, this is enabled, the settings in point 3 and 4 become redundant and hence are removed from settings as seen below:
  • Now, the section on the right would be easier to understand. As seen that everything is mapped to a status in Shipsy like rto_initiated or delivered etc. However, the default tracking shows pretty names for each like RTO Initiated or Delivered. These are systems defined against each status and this section gives an option to define custom names. For example when the status is delivered if you want to show it as “Delivered to customer” then a mapping here would do the trick and others will follow a default mapping. Hence, defining nothing is also fine whereas whatever is defined will be used in all consignments.

Outcome: Users would be able to view all the mapping settings either done through status mapping or NDR mapping.

Was this article helpful?