10.0-CAP35.0 (07.05.2023)

The "Close roads" geo services feature has been enabled to have effect on the distance and time calculation not just on tour, but also on transport order, subcontracting LTL and FTL orders.
For the transport order distance and time calculation:
- will be taken into consideration the transport type (of the transport order) and the vehicle type defined on it
- if either transport type or vehicle type will be defined on a valid "close roads" geometry plan, distance and time calculation will take the geographical restrictions into consideration.

For subcontracting LTL order:
- if the tour defined on LTL order has resources, it will check for geometry plans based on the vehicle type coming from the resources
- if no resources present, it will take the vehicle type from the tour header
- if tour header vehicle type is empty, it will take it from transport type

For subcontracting tour (FTL) order:
- similar to LTL, but look at resource legs first.

Certain labels and helptexts were improved in the Optimizer jobs form.
Also, the Optimizer Id was lenghtened from 40 to 60 characters, as the process of updating TMS tours with additional legs via Optimizer makes the optimizer Id longer.

Optimizer can now take into account any vehicle type that would be defined on a transport address as "not accepted vehicle types". For the moment, only the vehicle types coming from the truck (vehicle) are taken into consideration. Vehicle types coming from trailers will be fixed in a subsequent release.

A new parameter "Ignore HPRN" has been introduced in Optimizer parameters, with default value False.
For fast calculations of distances between addresses used on legs sent to Optimizer, High Performance Routing Networks are pre-calculated and defined on vehicle types. However, these are not mandatory. The system is able to calculated all distances "on-the-fly", with most accurate information available from the Map at the moment of calculation, but at the cost of significant less speed of calculation.
This can happen automatically, if no HPRN is defined on a particular vehicle type, or if user toggles this new parameter to True (either on Optimizer parameters, or on the Optimizer dispatching form).
When no HPRN is used in calculations, then also any geometry plans ("close roads") defined and valid in Transport parameters are taken into consideration.
Warning: due to longer period of time needed to process the request, it is advised to NOT close the GPB window used for Optimizer dispatching until response has been received in the tourplan form. Otherwise, tourplan might remain 'stuck' in Calculating status.
This is a known issue and will be fixed in a subsequent release.

When clicking "Delete tour plan" button, instead of directly deleting the selected tourplan, a dialog was added to ask for confirmation of the delete action.

The "Delete tour plan" function has been adjusted to support deleting multiple selected tourplan records at the same time.
The tour plan form has also been adjusted to allow multi-selection.
When multi-selecting records, only the delete function is available.

One extra column "HPRN usage" was added to the "Tour plan" and "Distance Matrices Information" forms. In this way, the user can quickly identify whether any optimizer tour was created by using a DistanceMatrix which used an HPRN to be created (process faster, but less accurate), or which was created on-the-fly during the dispatching process (process slower but more accurate).

Based on experience from productive usage of mobile apps, the 'express' parts of the processing of online check (for unknown barcode) are newly deactivated by default. As, on certain configurations, these could cause database deadlocks and other issues.
If 'express' parts are needed by some projects, these can be manually activated via new parameter "'Express export' in online check" (in Mobile app parameters).

If many users work on the same Truck loading app tour, they don´t get each others´ feedbacks when the app syncs with the middleware. This means that activities that were confirmed by others still appear as not confirmed.

The reason is that app-middleware sync doesn´t understand that the tour has changed just because there´s new feedback. The first idea was to temporarily solve it by marking the confirmed activities as changed in D365 and re-export the tour when we have feedback from multiple users. Unfortunately this did not make the activities go away in the app. A rougher workaround was implement: if we have feedback from many users (in Truck loading app tour), CANCEL (=Deleted:Yes) all activities when processing the confirmation / feedback from the app.

Following exceptions will not be cancelled:
- Start loading / start unloading
- Loading completed / unloading completed
- ULD Info (used for parent activities of carrying resource information in some cases)

Downsides of this approach:
- the data must still travel from middleware to D365 and back before others can get the new feedbacks from other users.
- Completed activities will completely disappear from the app, they can´t be seen even by changing the filter in the top right of the screen.
- "This barcode has been already scanned" check doesn´t recognize cancelled activities
- The package and unit counters display wrong information because it rightfully excludes cancelled activities. Each cancelled (in this case: completed) activity will not appear in the counter anymore.
- Counter in the tour list shows [completed/total]
- Counters in the tour details show [completed/open] per unit
- And for both counters the completed=cancelled activities will not be considered in the completed/open/total

Please note:
The approach introduced in this task is only a temporary workaround, the issue itself will be resolved properly in the future by handling the app-middleware integrations differently.

The current fields 'customer wish load from/till' and customer wish unload from/till' were renamed to 'requested load date from/till' and 'requested unload date from/till'. - In the order screen (OS) all sorts of transport legs are shown, not only "customer pickup legs and delivery legs"; on those typically a customer wish can exist and there the naming makes sense. But on other legs (being in the same grid), like cross-docking legs, these 'wish' fields could also be used as requested slots which is to be considered in the planning. But for depot arrivals or departures the naming 'customer wish' is confusing.

This task has no functional enhancement/impact, it's just about changing the labels.

It is now possible to plan each selected transport leg into new separate tour, when creating tours via drag & drop (from GPB 'Transport orders /-legs' screen into gantt screens). It is achieved by pressing (and holding) Alt-key when drag & dropping of legs onto GPB gantt screens.
Additionally, new flag 'Create 1 tour per transport leg' was introduced to the dialog (which is triggered by Ctrl-key, when drag & dropping of legs onto GPB gantt screens) to have a better transparency of the result (ie. whether legs will be planned into 1 new tour, or into separate new tours).

Please note:
- the combination of both Alt-Ctrl-keys is not supported, either Alt or Ctrl should be used

Performance improvement is especially noticeable when higher amount of transport legs (eg. 400+ unplanned transport legs) is to be loaded into GPB Map screen.

'Cross dock split' function was previously accessible in both GPB gantt screens only via 'right mouse click context menu' on tour stops.

Previously, only new drivers & vehicles were reloaded.

Previously, the warning was triggered also for empties transactions of 'Movement type = Exchange/IOU', which was a bit confusing (as the empties identification parameters are needed only for 'Transfer' movement types).

Reducing the change tracking records (related to shipment lot & shipment) that are being pushed to mobile apps, to include only relevant changes for the mobile apps.

Newly, all push notifications (that were sent with a Mobile app tour, such as "Tour ABC has been assigned to you.", "Tour ABC has been updated.") are saved in the history and are accessible in new dedicated form 'Push notification log'.
Previously, only one last push notification was saved/accessible.

'Push notification log' form can be opened from Driver app tour & Truck Loading App tour forms only.

To be able to better register the history, the creation of push notifications was refactored to use a more centralized logic.

In case the backward planning is activated, then when the user manually changes the rough plan dates of a transport leg, the new dates are now written back to the sales lines confirmed date fields.

In order to improve the synchronization performance, 3 new fields were introduced to the Package line level:
- Order number
- trade order number
- Line number
- trade line number
- Product
- product name

If any of related package lines doesn't have all these values filled, the system will use the previous logic.

All 3 fields are also shown in the package information details screen, in the driver app.

Until now, work instructions with load code 'None' were shown only on pickup and delivery legs.
This has been changed and now they´re shown on all load/unload points (shuttle legs, unloading of pickup leg, loading of delivery leg).

Previously, the final SCM status for transfer order lines in CAPcargo transport was 'Warehouse works finished', while for sales order lines the final SCM status was 'Packing slip posted'. This turned to be confusing for the warehouse, especially when there are packing slip posted sales lines in the tour (SCM status 'Packing slip posted') and completely picked transfer order lines in the same tour (SCM status 'Warehouse work finished'), then - because a minimum logic is applied - the SCM status on the tour is 'Warehouse work finished'. So warehouse doesn't know - at least not easily from the tour overview - whether the sales order lines are successfully packing slip posted or not.

This weakness was solved by introducing a SCM status 'Packing slip posted' also for transfer order lines. Differently to sales order lines, the 'Packing slip posted' status on the transfer order lines is reached when they are shipped.

New parameter 'Disable customer wish calculation' was added to mobile app parameters. If parameter is activated then no customer wish information is calculated on Driver app tour stops. This can be used to improve performance of mobile app tour export integrations in high volume scenarios (large number of tours with large number of stops being updated/re-exported constantly).

Additional validations were added to the Resource combination plan, so that the usage of driver or passenger would be crosschecked on other lines of same resource combination plan, to avoid possible overlap.

In certain constellations of data setups, the adding of addditional legs to TMS tours via Optimizer dispatching may not function as expected.
This may include behaviors such as:
- tour start and first load are at same location, but the tourstops are still displayed separately.
- process stops with error "Pickup location of order A is located at location B, but the stop location is location C".
- process stops with error "A vehicle location of the input tour does not match the specified vehicle location of the used vehicle. Please check the vehicle location of the used vehicle."

However, when the existing TMS tour is successfully updated with additional legs, the results are accurate and trustworthy.

'Planned arrival time' should be shown on each stop in the tour stop list in Driver app, unless the driver rearranges the stops (in that case it gets hidden).

In CTP4.0 this mechanism got reversed (which is wrong), showing 'Planned arrival time' on tour stops only after driver rearranges the stops.

Issue will be fixed in CTP4.1 only.

When marking Transport Legs as preloaded, Optimizer still took into consideration the fixed part of the loading activity, thus artificially using time on tour for loading activity.
This was fixed so that:
- in case all legs sent to Optimizer are non-preloaded, both the fixed and variable activity time of loading is taken into consideration
- in case all legs sent to Optimizer are preloaded and there are no legs also unloading at same location as preloading, both the fixed and variable activity time of loading are counted as 0
- in case legs sent to Optimizer are a mix of preloaded and non-preloaded legs and there are no legs also unloading at same location as preloading, the fixed activity time of loading is added on the tourstop, and the variable time of loading is added only for the non-preloaded legs
- in case legs sent to Optimizer are a mix of preloaded and non-preloaded legs and there are some legs also unloading at same location as preloading, the greatest value between the fixed activity time of loading and fixed activity time of unloading is added on the tourstop, and the variable time of loading is added only for the non-preloaded legs

Depending on how Optimizer groups the loadings together (based on capacity, time etc.), there might still appear differences i activity time between OPT tourplans and actual TMS tours. This cannot be avoided 100%, because all legs are sent upfront to PTV for planning, and upfront it is not known whether the preloaded legs will be planned together without any non-preloaded legs at the same time or not, or whether some unloading at same location would be planned at the same time with loading.

When the same vehicle was used multiple times in the same resource combination plan, the tour start/end location defined by tour start/end parameter was taken from the first line (instance) containing this vehicle on the resource combination plan and applied to all tours generated for this vehicle. This has been corrected.

In case of selecting legs of incompatible transport types to be sent to Optimizer dispatching, the process correctly stops and flags the issue. However, in the same step, an unclear error was shown to the user. This has now been fixed.

Previously, under certain specific constellation in Truck loading app, it was possible to mark the tour as 'Completed' before completing all activities, bypassing the logic that is usually triggered when Loading completed or Unloading completed activity is swiped.

Previously, when transport order was planned into tour (via drag & drop from GPB 'Transport orders /-legs' screen into 'Resource Dispatching' screen), the driver was not automatically assigned to the tour if the 'Driver combination logic = Mid-term driver plan' rule was configured on the truck.

Issue was happening only when GPB gantt screen was in "1 Day" or "3 Days' viewing mode; the behavior was correct in "1 Week" viewing mode.

When dropping new transport legs on a tour (which is already sub-contracted via transport leg sub-contracting (LTL)), the invoice account of the new LTL sub-contracting orders is newly determined from the invoice account of existing transport leg sub-contracting (LTL) order. Previously, invoice account was determined from the vendor account, which could have lead into inconsistent sub-contracting structure.

The issue was occurring since 10.0-CAP34.0 release, and was corrected by this task.

The issue was corrected and release to warehouse now does not try to process the sales return orders (and purchase orders).

When creating a new transport order manually, on the new transport order creation dialog, the 'Load/Unload date fixed' fields were previously disabled by default (and were enable for user changes when some transport type was selected, much further down in the creation dialog).

This is now enhanced, and 'Load/Unload date fixed' fields can be set regardless of the transport type.
Please note: 'Load/Unload date fixed' fields are still depending on the 'Load/Unload date to' specification (and can be set only when no 'Load/Unload date to' is specified).

In checked imported orders, the alert definition was previously limited (as alerts could be created only against 'Error log' table). This was corrected, and it is now possible to set alerts against 'Checked imported order' table again.

Following improvements were introduced on the GPB gantt screen, when performing a tour stop drag & drop actions (withing the same tour, or between two tours):
- When performing a sequence change of tour stops (via 'drag & drop' within the same tour) the original selection and focus of the dragged tour stop is now kept (so user doesn't have to search for it)
- When tour stop is dragged and dropped to another tour (in main tour gantt overview), the selection and focus now stays on the original tour (from where the stop was dragged). In tour stop overview section, the system now selects the one previous tour stop (ie. the last previous in the position from which the tour stop was moved out of the tour). Previously, the selection & focus was done on the target tour (and on its first tour stop).
- When there are multiple stops in tour stop overview and there is a scrollbar which indicated that not all of them are visualized (since not fitting onto the screen), when trying to drop the stop on the right/left side when getting to the edge, the scroll now happens automatically. Previously, it was possible to change the sequence only within the visualized range of the stops in the screen.