Overview
A recent issue was identified where a static route message was received with critical data missing — all customer details were stripped off, and the "Ship Via" field was marked as undefined. This caused significant confusion in downstream processing and delivery scheduling.
Issue Description
Upon inspection, it was found that the service type in the message payload was incorrectly marked as OTR (Over The Road), whereas it should have reflected the final leg of the delivery, which is COUR (Courier). The incorrect service type resulted in improper route processing, as the system failed to recognize the actual delivery method.
Findings
The core of the problem was traced to the logic determining the service type. In static routing scenarios, the last lane of the route is crucial for determining how the shipment will be delivered to the consignee. Since the final delivery is handled by a small van or similar vehicle, the service type must be COUR. However, in this case, the payload was erroneously carrying OTR, leading to the stripping of customer data and an undefined shipping method.
Issue Resolution
To address this, a change was made in the code logic to ensure that the last stop in a static route is always assigned "COUR" as the service type in the payload. This accurately reflects the nature of the delivery, especially when a truck is not suitable for the final destination.
Conclusion
With this code logic update, static route messages will now correctly show the last leg of the journey as COUR, ensuring proper handling of deliveries that require smaller vehicles. This fix also restores the integrity of the customer data and the "Ship Via" field, reducing the risk of delivery errors and improving overall operational efficiency.
Was this article helpful?
That’s Great!
Thank you for your feedback
Sorry! We couldn't be helpful
Thank you for your feedback
Feedback sent
We appreciate your effort and will try to fix the article