Carrier Tracking Settings

Users can refer to this document to understand how the different settings within the carrier tracking config work.

Instructions

Accessing Carrier Tracking

1. Click on the hamburger menu icon

2. Click on integration setup to expand the dropdown list

3. Select Carrier Partner to navigate to carrier partner setup

4. Click on the Carrier Tracking Tab

Understanding Carrier Tracking

Shipsy's Ops Dashboard simplifies the intricate process of handling carrier tracking for various couriers. The left panel in the Dashboard provides an organised list of active carriers for the organisation, with special consideration for the diverse tracking approaches. Here's an overview of the three key sections within the Carrier Tracking module:

Setting: This section serves as the foundation for configuring global-level settings for tracking. It's the starting point for setting up tracking operations and ensuring that the system is prepared for tracking activities.

Status Mapping: The Status Mapping section is the default landing page for the Carrier Tracking module. Here, you'll find the mapping of tracking statuses for the selected carrier. It's vital for streamlining the tracking experience and ensuring that users can easily comprehend the status of their shipments.

NDR Mapping: Just as tracking status mapping is essential, NDR (Non-Delivery Report) mapping is equally crucial. This section allows for customising NDRs in alignment with specific user requirements. It's a critical component for ensuring that discrepancies and non-delivery scenarios are managed effectively.

Key Considerations:

1. The left panel in the Dashboard displays active couriers, with each carrier treated individually due to distinct tracking methods (API or Webhook) to maintain transparency and prevent discrepancies.

2. Mapping types, whether API-based or Webhook-based, are clearly indicated below the carrier name for quick reference.

3. The module addresses the complexities of tracking statuses, ensuring uniformity, and provides customisation options for NDRs.

4. The Carrier Tracking system is designed to optimise tracking processes, enhance transparency, and offer a seamless experience to users, regardless of the carrier's tracking methods.

Understanding Each Section

Settings

1. Terminal Status in API-Based Tracking: In API-based tracking, defining terminal status is a pivotal step. This mechanism relies on scripts and must conclude at specific stages, typically referred to as terminal status. Shipsy defaults to listing these terminal statuses to halt tracking at a predefined point. It's important to note that this setting applies only to API tracking and doesn't affect webhook tracking. Webhooks are external notifications consumed by Shipsy, and their tracking continues independently. In contrast, API calls, managed by Shipsy, can be stopped at designated terminal statuses. This distinction ensures precise control and management of API-based tracking.

2. RTO Triggers in Tracking: RTO Triggers play a critical role in tracking operations, particularly for Return to Origin (RTO) journeys. Knowing when an RTO journey commences is vital for initiating necessary system adjustments and ensuring accurate mapping. This is especially crucial for API-based tracking, where multiple statuses may be received simultaneously. Without a defined RTO trigger, the system might misinterpret the status of an ongoing RTO journey, potentially causing inaccuracies. For instance, if the RTO trigger is not established, and a status like "in_transit" is received for an actual RTO journey, it may be incorrectly interpreted. However, by setting an RTO trigger, the system can identify the precise point at which an RTO journey starts, allowing for accurate tracking and proper handling of statuses post-RTO initiation. This ensures that tracking and mapping remain consistent and reliable, even in complex scenarios involving RTO journeys.

3. Default Status Handling in Tracking: In tracking operations, dealing with statuses that are not mapped in Shipsy is a common scenario. When such unaccounted-for statuses are received from a third-party logistics provider (3PL), there are three primary options for handling them:

   1. Mapping to "in_transit": This choice signifies that something is in progress, and the courier is en route. It's a generic status that indicates movement.

   2. Mapping to "exception": When the received data is unfamiliar or unidentifiable, mapping it to "exception" is a suitable approach. This status indicates that the system does not have specific knowledge about the received information.

   3. Mapping to the Previous Status: As an alternative, unassigned statuses can be mapped to the previous status that was received and mapped in Shipsy. This approach ensures that the flow of the journey remains consistent and well-defined for end users. It provides a logical and continuous tracking experience, even when dealing with unexpected statuses.

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

5. Ignore Unmapped Status in Tracking: By default, the "Ignore Unmapped Status" setting is turned off. When a status from a third-party logistics provider (3PL) is not mapped within the Shipsy system, it triggers a fallback to a Default Status, as defined in the settings (point 3 and 4). This ensures that the tracking process remains consistent, even for unmapped statuses. However, there are scenarios where users may prefer to only utilise the statuses that have been explicitly mapped and disregard any unmapped ones. In such cases, enabling the "Ignore Unmapped Status" feature provides this capability. When activated, any unmapped status is simply ignored by the system, and the consignment's state remains unchanged. It's as if the unmapped status was never received, and no alterations are made. This feature streamlines tracking by allowing users to focus solely on the statuses that have been specifically mapped, rendering the settings in point 3 and 4 redundant when "Ignore Unmapped Status" is active. The system adheres to user preferences, providing flexibility in managing tracking data.

Status Mapping

1. Left Tiles: These represent the carriers integrated into Shipsy for your organisation. If no carriers have been integrated, this section will be empty because there's no status mapping required. The same carrier may appear multiple times since their mapping can vary based on whether it's an API or Webhook integration.

2. Mappings: When you create a new courier account, it needs a mapping for tracking. Shipsy handles this by generating an initial default mapping called "Shipsy-<courier name>" and associates it with your courier account. Even if system-defined mappings change, this copied mapping remains unchanged to safeguard your settings. Only custom mappings are editable, and the copied one grants you access to make any needed adjustments.

3. Upload/Download: When dealing with a large number of mappings, manually adding them one by one can be time-consuming. To simplify the process, you have the option to upload and download mappings in bulk. This feature is applicable to all courier partners and mappings within this module.

4. Add: The + button is simply to allow users to add their own mappings

5. Add New Mapping: If you need to create a custom mapping for a new status, you can easily do so. For instance, if the carrier introduces a unique or customised status for your organisation, it can be mapped quickly and activated. Simply click the "Add New Mapping" button, and a popup window, as shown in the image, will appear.

6. 3PL Status: This is the carrier's status that needs to be matched in Shipsy. It's the specific name, often called "Status Code," used by the carrier to transmit this information to Shipsy.

7. RTO Flag: The RTO Flag is a feature specific to API-based tracking. It's used when some carrier statuses are the same for both the regular shipment flow and the Return to Origin (RTO) flow. This flag helps the system determine how to map these statuses when an RTO journey is in Progress. In the case of Webhook tracking, carriers provide a separate flag to handle this, making the RTO Flag unnecessary. Some carriers use entirely unique statuses, so the mapping depends on how the carrier sends the data. The key is to adapt the mapping to match each carrier's specific status updates.

8. Shipsy Status: This is a list of status in Shipsy from where you select one status and map it to the carrier status.

9. Visible to Consignee - This is a flag to identify if the status should be visible on the raven link or not.

10. Strategy and Priority: The default Strategy is Exact Match and Priority 1. However, when you want to do a string match kind of scenario, then Partial Match can be done and that is where priority comes into picture.

NDR Mapping

1. NDR mapping, like status mapping, ensures accurate tracking information. It's essentially the same process as status mapping, with the only distinction being that it involves mapping Non-Delivery Reports (NDR) from a third-party logistics provider to Shipsy instead of tracking statuses.