Fastlane Courier Allocation
The serviceability of a courier changes dynamically and very frequently. It is not possible to update the serviceability of all couriers in our system on a daily basis. Thus, In case the AWB allocation fails due to any issue it is recommended to skip the courier partner and hop onto the next one which shall be able to successfully generate an AWB.
Note: You need to get in touch with us through Chat Support or KAM to check the feasibility of this in current UC account.
Applicability
Version: All versions (Standard/Professional/Enterprise)
Traceability: All Trace ( None/SKU/Item Level)
Configuration: Fastlane Courier Allocation (Facility Level Configuration)
- Works for Both Forward & Reverse shipment flow handling
| Config Value | Use case |
| OFF | No hopping of any courier , shipments gets stuck by the first courier error itself |
| ON ( For ALL Errors ) | Hopping of Couriers on any error received from any courier side. |
| ON ( For ONLY Pincode Serviceability Errors) | Hopping of Couriers on only serviceability error code “NOT_SERVICEABLE” |
Some of the courier allocation failure reasons are:
-
-
API Failure due to Serviceability error
-
API failure due to other reasons
-
Exhaustion of the AWB pool in the system
-
Feature highlights
- Logic of Hopping still remains on the basis of = SHIPPING Rules defined.
- Hopping shall occur via UI / REST APIs only when a dedicated courier is not selected rather the just CTA of label or label generation api is called upon without shippingProviderCode specification.
- The Application layer of Uniware will read the error codes sent by courier and throw “Serviceability Error”
- This feature will not works for Exchange Courier Allocation.
Error Logs
Through UI:- For last hopped Shipping provider → Show the respective error message received from shipper end as error message on Shipment error tab
Through Export:- Seller can track the error logs with the relevant output columns by export option.
- Export Name: Fastlane Courier Allocation Error Logs
