10.0-CAP32.0 (02.03.2023)

With this release it is necessary to use PTV xServer 2.28.

Please note:
- In case that PTV xServer is hosted by CAPcargo, then only redirection to new xServer 2.28 urls is needed (which is to be coordinated with project responsible CAPcargo consultant).
- In case that PTV xServer is hosted on-premise, please ensure that the installation is upgraded to 2.28 (together with 2.28 API) and that necessary xServer configuration adjustments are done, in case the premium features are to be used.

See as well: https://xserver2-test.cloud.ptvgroup.com/dashboard/Default.htm?#TechnicalConcepts/Tour%20Planning/DSC_Optimization_Premium.htm

Previously, the background interaction with PTV xServer (ie. requests and responses) was not easily accessible, the logs were available only in the PTV xServer management console. This was improved and requests & responses are newly accessible also directly in D365.

Key characteristics:
- Logging has to be enabled for each xServer component in main TMS parameters (in 'Geo services' section, in xServer parameter, in new section 'Geo service log'
- Log is accessible in CAPcargo Transport Menu ->Inquiries -> Geo services log
- Log can be downloaded via 'Download content data' in 'Geo services log' form

Please note:
- The logging of PTV xServer requests & responses (in D365) should be enabled only temporarily (eg. for troubleshooting); it is not intended to be enabled (and to keep logging all the requests/responses) for longer time. As the logging can produce quite significant amount of data that could have negative performance impact on D365 database.

Previously, recently introduced vehicle / driver unavailability was by default directly not visible in the GPB 'Resource Dispatching' screen, and users had to use the dedicated filter 'Resource unavailability', to actually visualize one single unavailability type (aka. one 'Reason for resource unavailability'). This turned out to be not so useful, as it was rather expected to visualize more unavailability types (or just filter on single one). Hence it was improved.

Key characteristics:
- New checkbox 'Driver shift' was added to the 'Reasons for resource unavailability', to be able to specify which unavailability reason(s) represent the driver shifts.
- New dedicated checkbox filter 'Driver shift' was added to the GPB 'Resource Dispatching' screen (by default the filter is not set), to be able to filter on all driver shifts (ie. on all 'Reasons for resource unavailability' that have 'Driver shift' activated).
- The default filtering of GPB 'Resource Dispatching' was altered, to initially show also all unavailabilities that are not the 'Driver shift'.

Previously, when some (error) feedback was received from PTV xServer calls, these were just shown on the screen as so called 'stack trace' errors. Such behavior was not user friendly and was quite confusing, as 'stack trace' errors in D365 usually represent some unhandled errors.

Behavior was thus improved, and (error) feedback from PTV xServer calls is now presented in better formatted way, in two parts:
- Main error message is shown directly on the screen, in a nicer formatted way
- In the message details side section, more technical error descriptions are available

Previously, the tour parameter 'Driver can rearrange tour stops' was always initialized as 'No', and the parameter activation was entirely manual, for every tour. This task introduces an automation option - to initialize the parameter value from master data (ie. either from transport type and/or from driver app user).

Key characteristics:
- New activation parameters:
- In Transport type: 'Driver can rearrange tour stops'
- In Mobile app user: 'Driver can rearrange tour stops'
- When tour is created, system checks the transport type parameter. If it is set to 'Always yes', it will set the field 'Driver can rearrange tour stops' on tour to 'Yes'
- When driver (ie. driver app user) is added to tour, system checks the transport type parameter. If it is set to 'Use driver setting', then the field 'Driver can rearrange tour stops' is re-initialized from the driver
- If more drivers are added, system always re-initializes from the newly added driver. This is the simplest solution.
- Removing driver does not trigger any changes or initialization
- The effective usage in driver app stays unchanged - depending on 'Driver can rearrange tour stops' tour parameter, drivers can (or cannot) adjust the tour stop sequence in the driver app​

The shipment builder (bridge between D365 trade orders and CAP transport order) is being redesigned in several phases. In R32, the first phase is included which contains only basic functionality and hence is not yet officially released/supported.
It's linked to a license configuration key which is not allowed to activate in productive environments. CAPcargo rejects all responsibility for using it in production.

Various improvements on driver app tour activity translations in Dutch language.

On the customer master data, default load and unload transport addresses were previously switched (ie. first address was unload, second was load), which was prone to parameterization errors, as on other places (eg. on transport order header etc.) the visualization sequence was always: load -> unload.
Now, the default transport addresses on customer master data are switched to usual logic: load -> unload.

Data migration task for 94685.

Data migration task deletes the orphaned price calculations (ie. price calculations without reference to an order line), for all order types.

The issue was only happening when some driver group and vehicle group was created with exactly same name.

The issue was especially happening when 'One load/unload per transport order line' instruction activity rule was activated only for load tour stops, and when multiple transport order lines (and packages) were being unloaded on the same tour stop. Then the sequence of activities on tour stop was sometimes wrong in driver app (eg. duplicate sequence numbers were reported, unload activities were displayed after tour end activity etc.). The issue was corrected.

The issue was happening especially when 'One load/unload activity per transport order line' was activated in instruction activity rules, but no barcode scanning rule was set. Then no barcode scanning activity was shown in the driver app, but such loading activity also could not be anyhow confirmed. The issue was corrected and loading/unloading activities (with no barcode scanning activity rule) can be now confirmed by simply swiping off.

Following issues were corrected, in the bulk & non-WHS direct delivery shipment builder area:
- Deliver remainder validation for transfer order was previously more strict, than corresponding validation on sales order. In case of a sales order, the deliver remainder function can be used when a single sales line is in 2 transport legs, and one of the transport legs is already too far in the transportation process from change management perspective (transport type parameter, tour confirmation). The only prerequisite of using it is that the user has to delete the shipment lot quantity, so there is an open quantity that can be used for reducing the inventory transaction.
However, for transfer orders, the previously existing validation did not allow such handling, ie. the delivery remainder functionality could not be used when a single transfer order line was in 2 transport legs, and one of the transport legs was already too far in the transportation process from change management perspective (transport type parameter, tour confirmation). This is now improved, and same delivery remainder functionality can be used across trade orders.
- 'Available to remove' quantity was previously not calculated correctly, when updating remaining quantity on transfer order
- Viewing the order details via 'Order number' reference in CAPcargo Shipment form (in line view) sometimes did not open the correct order (but opened just an empty source order form)

Previously, it was not possible to generate toll costs for the tour, as no tour additional costs were created (even though all necessary parameterization was in place). The issue was corrected.

When setting up instruction activity rule 'One load/unload per transport order line' there was sometimes a validation error shown:

Transport type 'X' uses 'Carrying resource assignment on package level', which is not compatible with 'One load/unload activity per transport order line'!

The issue was that validation check had a flaw and validation message could have been encountered even when setting up instruction activity rule for entirely different transport type (eg. for transport type 'Y'). The issue was corrected.

Additionally, a small GUI imperfection was also corrected - when setting up instruction activity rule 'One load/unload per transport order line', then 'Position' condition is mandatory (but to be able to specify a 'Position' condition, user first had to deselect 'Per tour stop' level condition (and reselect it again)). The issue was corrected, and 'Position' condition is now selectable immediately when setting up the instruction activity rule 'One load/unload per transport order line'.

In case an order was calculated and the user then changed contract, contract version, contract relation or tariff level on an order line, then the calculation flag was simply reset to false. But the order line related order calculation stayed in the system. In the next price calculation process, a new order calculation was created, but the previous (and now obsolete) old order calculation was still existing without any reference to an order line anymore (ie. orphaned order calculation). While such orphaned order calculations did not do any harm (as they were simply ignored), they should not exist.
The issue was corrected by not only resetting calculation flag (when user is changing contract, contract version, contract relation or tariff level on an order line), but also physically deletion of such order line related calculation.
The issue was corrected for all order types.