Carrier Tracking is one of the most important feature that Shipsy provides as each carrier has its own set of methodology of tracking but the end user is only worried about a single way of identifying the tracking history. This is where the mapping of carrier status is done with Shipsy status such that the view remains uniform and the integration and mapping is handled by Shipsy.

Overtime, this mapping has started to become specific to business needs and hence customization was need of the hour. To do the customization, one must be able to see what has to be done and how it has to be done as well as each carrier has a different way and different terminology.

Introducing Carrier Tracking !!

How do you access Carrier Tracking

Go to the setup section
Click on Courier Partner from the left Panel and then go to “Courier Tracking”

Understanding each section

The Left Panel has list of Couriers that are active for the organization (Setup done in Shipsy). As seen in the image above, the left panel has 5 tiles but only 3 unique carriers. The reason for this is that each carrier has different way to treat tracking which is either via API or via Webhook and that is why we also ensure that each one is treated separately and mapped so as to avoid any discrepancy and provide transparency at the same time. Just below the carrier name the mapping type (API Based or Webhook Based) is visible for reference.

The module is further divided into 3 main sections which are further detailed in the document:

Setting - This is the page to define global level settings for tracking. Base setup is always done.
Status Mapping - This is the default landing section and has the status mapping for the carrier selected
NDR Mapping - Just like tracking status mapping, NDR are also mapped and can be customized as per user requirements

Section 1: Settings

Lets go one by one on each part here starting with the panel on the right as it contains maximum information and is critical as well.

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 ens 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 party and are simply consumed whereas API call is 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 system can do 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 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 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 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 ignore 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 system 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.

Section 2: Status Mapping

There are too many items on this page and each has a very specific and important meaning.

Left Tiles - These are the names of carriers that have been integrated in Shipsy for your organization. If you have not integrated any carrier then nothing will be visible on this screen as you have nothing to do status mapping for. The carriers can be seen multiple times as explained earlier also as the mapping differs for API and Webhook.
Mappings - Every courier account that you define must have a mapping associated to it so that tracking can be done. When a new courier is added, Shipsy automatically creates a default mapping by Shipsy as “Shipsy-<courier name>” and copies it to a new mapping which is associated to your courier account. For any new accounts, this copied mapping is used. This is way to ensure that the system defined mappings even when changed do not impact your mapping. At the same time, only custom mappings are editable and hence the copied one provides you that access.
Upload & Download - Sometimes, the mappings are too many and can’t be added one by one as it becomes a tedious task. For that you can upload and download mappings in bulk. This works for all courier partner and mappings defined in this module. For a specific partner and mapping, this can be done in a different way (will be explained later)
Add - The Plus button is provided so that you can create your own mapping without impacting any other. Creating is also easy since the following options are provided which are self explanatory.
Add New Mapping - For a custom mapping defined, you can even add new status mapping. For example, the carrier introduced something new or custom for your organization, then that can be easily mapped and can be instantly made LIVE. ON clicking this button, the popup opens up as seen in the image.
3PL Status - This is the carrier status which has to be mapped in Shipsy. The field name as seen in image “Status Code” differs in each carrier. This is basically the field name that the carrier passes to Shipsy. The intent here is to understand what the carrier means and easily manage.
RTO Flag - This will only be seen in API based tracking. Some status from carrier remains same as in forward and RTO flow. Thus this flag helps identifying that when RTO journey is in process what should the mapping be. In Webhook, a separate flag is sent by carrier which would be available instead of this flag. Some carriers send totally unique status and for them this will have no meaning. So, the mapping must be done after having an understanding of what and how carrier sends the data.
Shipsy Status - This is a list of status in Shipsy from where you select one status and map it to the carrier status.
Visible to Consignee - This is a flag to identify if the status should be visible on the raven link or not.
External Status - This is same as point 6 in Section 1 and it will overwrite if something is defined there else the functionality is exactly same.
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.

A predefined mapping can be edited as well as deleted from the frontend.

Additionally, on clicking the 3 dots against each custom mapping, you get the following options:

Rename - To rename the mapping and that change will be automatically applicable to the courier accounts where this mapping is provided.
Download - To get the mapping in excel
Delete - To delete the mapping. When you delete, you must select the mapping with which you are replacing this mapping so that the tracking is not impacted for any consignment
Settings - Specific to a courier account only and has limited options. Suppose you do not want to ignore unmapped status for all carriers, then it can be done explicitly for a specific account only.

Section 3: NDR Mapping

Just like status mapping, NDR mapping is also done to ensure correct tracking details. Everything remains the same just like Status Mapping with the only difference of mapping NDR instead of Status from a 3PL to Shipsy.

As seen in the image above, every section, button, dropdown, etc has been designed in a consistent manner to ensure similarity and ease of use.

The only difference is in the Shipsy NDR List where you get a set of NDR defined by Shipsy. However, you can also define your custom NDR in Shipsy in case of a personalized reason. This can be done from: Setup → App Flow Config → Master → Task Failure Reason → Delivery (check box) → Add Reason

Conclusion

This covers everything that can be done on the frontend w.r.t Status and NDR mapping. We are constantly working on providing more enhancements so that the tracking can be streamlined in every way possible.