Upcoming feature – multiple pictures for proof of delivery

It is soon being released (check your Driver App updates!) a feature improvement that will allow Drivers to take up to 4 pictures as Proof of Delivery. This feature is particularly useful when you have to document the successful delivery of large orders, and not all packages can fit in one picture. In addition to these changes in the Driver App, the pictures will be displayed in the TMS, as part of the Route Stop details, and in the Backoffice, so that planners and support users will be able to check them.

Highlight – accurate route re-estimation

In order to be able to maintain the settings applied to routes during the route planning (e.g. pessimistic/optimistic adjustments of driving times) also when the Routes are produced and re-estimated, we are implementing a solution based on correction factors. Now we are able to compute and store those correction factors per each route. Next step, soon to come, is the development of the application of the correction logic when re-estimating the route.

Improvements and fixes

• [performance] [driver app] We have updated the scanning library which will improve performance of the driver app.
• [data layout] [driver app] Changed rounding of the Route durations displayed in the Driver App in the Bookings Section. Each duration will now be presented as [hh.mm|http://hh.mm]. The value next to the date, where it says “Total” is the sum of the Route duration of all Routes assigned to the Driver in that day.
• [data layout] [collection points] Data on route stops with collections points cleaned up.
• [reliability] [route planning] Route planning now does not group together orders with the same relational ID if they are located more than 100 meters from each other. This is a functional clean-up in anticipation of other upcoming functionality.
• [reliability] [route planning] Added validation errors on invalid route planning rule sets. the rule set cannot be created with a vehicle group having 201 or more stops or more than 1439 minutes (1440 is 24 hours). Now the UI returns a validation error.
• [reliability] [webapp] UI fix that solves a visual bug related to the scenarios in which a user was scrolling the webpage with the filters opened.
• [reliability] [routes] In order to be able to maintain the settings applied to routes during the route planning (e.g. pessimistic/optimistic adjustments of driving times) also when the Routes are produced and re-estimated, we are implementing a solution based on correction factors. Now we are able to compute and store those correction factors per each route. Next step, soon to come, is the development of the application of the correction logic when re-estimating the route.
• [reliability] [routes] We have identified an issue related to an edge case within our route domain where routes without an assigned driver (a driver was initially assigned, but then removed) are triggering null reference exceptions. This issue was causing disruptions in the routing process, and potentially leading to operational delays. The problem has been found and fixed.
• [reliability] [routes] We've identified an edge case issue with the function for getting driver locations. This function was sometimes failing due to null values in the Route data not correctly handled, causing the failed logging of some drivers positions. This issue has been identified and fixed.