10.0-CAP22.1 (30.11.2021)

When deleting a collective order, then previously system asked for confirmation about resetting the tariff level with a dialog "Tariff level will be set to 'Detail' for all lines. Continue?". The dialog was slightly confusing, as it might have been understood that answering "No" will break & undo whole operation (so collective order will not be deleted). Which was in reality not happening as the dialog is related only to tariff level change and regardless whether user answers "Yes" or "No", the collective order is always deleted.

To avoid the misunderstanding, the dialog was reformulated to "Do you want to set the tariff level for all order lines to 'Detail'?".

Periodic tasks 'Contract finding transport order' sometimes failed with an error 'Cannot edit a record in Transport orders (CIRTRASalesTable). Your changes to this table were not saved because another user also changed the table. Click Restore on the Command menu to update the table, and then enter your changes again.'
The issue was especially happening when 'Reset contract for all order' parameter was activated in the properties of the 'Contract finding transport order' periodic task. The issue was corrected.

When the 'Generate/Update tour out of route/zone' was used, tours should have been created/updated depending of which routes were selected in the dialog. The issue was that the selection of route (that was done in the dialog) was ignored and whole original transport leg scope was used. The issue was only happening when 'Generate/Update tour out of route/zone' was manually called from GPB 'Transport orders /-legs' screen. The issue was corrected and the route selection (that is done in the dialog) is now respected.

Previously, it could happen that the end date & time of resource assignment was not calculated correctly after certain dispatching actions. The issue was especially happening when transport order was planned via 'Dispatch directly to new tour' process. The issue was corrected.

The issue was especially happening when a quantity split was existing for transport order (that was created from sales order with some bulk item). Such transport order could not be removed from tour in GPB (and user was wrongly informed that 'Order line XXX cannot be removed because this would cause a quantity split, which is not allowed for an order which is based on a shipment from the trade module'. The issue was previously already corrected for TAL forms, is now also corrected for GPB (and such transport order can now be removed from the tour also in GPB gantt screens).

Following issues were corrected, in the 'Add cleaning activity' dialog:
- some cleaning activity suggestions were sometimes duplicated in the dialog
- in some cases the cleaning activity suggestion was not generated for the truck
- load address was missing in the dialog, hence cleaning activity could not be generated

The issue was especially happening when some driver qualification (without valid certificate) was required by some other resource (eg. truck).

Improvement was achieved by simplification of the code structure, without any negative impact on tour planning functionality.

Scrolling left/right (ie. into the past/future) is now more fluent in the GPB gantt screens. The tours are being loaded onto the screen (via background services), as soon the scrolling action is performed.

The issue was happening only in GPB 'Transport orders /-legs' screen; feature was working correctly in the TAL 'Dispatch light - Transport legs' form.

Historically, before GPB was introduced, when transport leg was split via several quantity splits, it was possible to select which transport legs exactly should be merged together again. Unfortunately this feature was not implemented into GPB, as the 'Merge part deliveries' menuitem was not enabled for transport leg multi-selection.
This task enhances it, it is now possible in GPB 'Transport orders /-legs' screen to use 'Merge part deliveries' menuitem even when several transport legs are multi-selected.

Consequently, the 'Merge part deliveries' menuitem was also enabled in the 'Transport leg' action pane section in TAL 'Dispatch light - Transport legs' form (previously was only accessible in 'Only for internal test purpose' section).

In order to improve performance of the GPB client (and to reduce the overhead of communication management between GPB client & D365 backend), a web service connection caching mechanism was introduced. The same caching mechanism was previously successfully used in certain functionalities in the GPB 'Transport legs /-orders' screen (eg. during paging & filtering of transport orders/legs), was in this task implemented also to other GPB screens.

Mechanism for adjusting the tour start (by drag & drop of the whole tour in both GPB gantt screens) was enhanced, to better cover the scenarios where projects customized the visualization identification of the tour (eg. showing tour id & route id, instead of plain tour id).

Since the introduction of the Edge browser and Webview2 components in GPB in 10.0-CAP20.0 release, projects who are accessing one common central GPB installation via a shared network drive (and/or RemoteApp) experienced white screens as soon as a second user tried to open the GPB application browser windows. The reason for that was that the browser cache was not handling multi simultaneous users correctly. This has been mitigated.
Each user now has a local cache folder per the environment variables, for example: C:\Users\\AppData\Local\GPBWebView2Cache\.

Process of planning transport legs via 'drag & drop' (from GPB 'Transport orders /-legs' screen or from GPB Map screen) into new tour (in GPB 'Tour Dispatching' or 'Resource Dispatching') was sometimes not working correctly. The issues were happening only when following constellation occurred:
- Several transport leg were multi-selected by user
- User was using the advanced method (ie. when holding CTRL key during the 'drag & drop' action).

Then users could experience following wrong behaviour:
- several browser windows were opened (ie. each browser window for each selected transport leg), which resulted into incomplete tours
- tour was created with wrong tour start date
- resources were not allocated properly

All issues were corrected.

When both following conditions are met then the carrying resource information is not anymore shown in driver app (in the Load/Unload activity (in AdditionalInfo2 field)):
- Tour has only one carrying resource with capacity
- No compartments are used in carrying resource assignments on this tour

As in above case, the displaying of carrying information doesn't bring any additional information value and thus was supressed.

In other cases (ie. if more carrying resources with capacity exist on the tour, or if compartments are used), then the carrying resource information is shown in every load/unload activity.

This change impacts only the carrying resource information that is written in the Load/Unload activity. It doesn't impact the "Group per carrying resource" tree structure (where the vehicle is a parent activity of load/unload activities).

When customer wished loading/unloading dates are updated on the transport order, the impacted Mobile app tours are now re-sent automatically to provide up-to-date information in the app to the user.

If the tour stop title (vehicle/trailer name for truck loading app app, address name for driver app) is long enough it could previously overlap the icons for attachments and filters.
The design of the tour stop title was altered, to avoid such overlap even for longer titles.

The issue was especially happening when tour was also submitted to truck loading app.

Previously, user didn't get any feedback after clicking the menuitems 'Send to Driver app' & 'Send to Truck loading app', as the effective creation of mobile app tours (and also the sending to apps) is not done in the real-time. Which was a bit confusing (as user might get an impression that nothing had happened and started clicking the menuitems again etc.) Also when sending to app was not possible, such information would be quite useful.
Hence the menuitems were enhanced to perform several checks when being pressed, to be able to pre-inform user about expected result. Newly, user will receive feedback (via different infologs) when sending (or withdrawing) tours/resources to mobile apps.

Menuitems in both GPB and TAL 'Dispatch light' were enhanced.

Additionally, mobile app status icons (in the tour overview, in the GPB gantt screens (level 1 & level 2)) were a bit enhanced - previous status of 'ExportPending' was renamed to 'Sending…'

Starting from Microsoft update 10.0.19 recurring periodic export tasks often end up in 'Error' during package deployment. Tasks had to be manually set back to 'Waiting', to resume them.

Following settings need to be set, to ensure that periodic tasks recover automatically from this error:
1) Set "Maximum retries: 5" on the Mobile app export jobs. This can be done in the Batch jobs form.
- Make sure that the new form (and not the legacy one) is used. This can be verified in the batch jobs form - the 'Switch to legacy form' menuitem must be visible in the top of the screen (between 'Copy batch job' and 'Options'), above the form action pane.
- Change the batch job status to 'Withhold'
- Click the job to open its details
- Go to Batch task details, General tab page and see the "Maximum retries" field in Administration field group
- Enter "5" in the field
- Change the batch job status back to 'Waiting'
2) Enable feature "Batch reschedule failed recurrent jobs" in Feature Management Workspace

Following issues were corrected in resource data showing in the mobile apps:
- If order was originally not assigned to carrying resource, then split to many carrying resources after being sent to Driver app, the activities were previously not created correctly.
- Compartment info was sometimes not shown in the truck loading app (in tour stop activities).
- Carrying resource info was sometimes not shown in the Additional info 2 (in tour stop activities).
- Quantities from other resource (eg. trailer) were sometimes shown in truck loading app, where only current resource quantities (eg. truck) should be shown.

The barcode scanning in the mobile apps previously failed in the validation, where scanned barcodes are verified against D365 backend. The issue was corrected and the package barcodes are now validated correctly against D365 backend even when carrying resource assignment is done on the package level.

The issue was especially happening when 'Default return address initialization' parameter in mobile app parameters was set to any other value than to 'Return address for failed direct delivery'. The issue was corrected and default return address for direct delivery from tour stop transport address is now always available when creating an unplanned return order in driver app, regardless of the 'Default return address initialization' parameter.

Following elements were removed from the TALContractRelationStaging table, as they are not used in this data entity:
- field 'Location_LocationId'
- field 'LogisticsPostalAddress_ValidFrom'
- relation 'Location'

New data entity 'TAL UN-Number' was added to the system, it is now possible to export/import TMS UN numbers from/to D365.

For PTV xServer there are several additional data available next to the 'usual' map data.
These are called the 'Feature layers'. In this release we have introduced two new feature layers:
- Preferred routes - further described in task 83609
- Truck attributes - these represent the route limitations (eg. truck weight/height limits etc.)

Visualization of feature layers can be activated/deactivated directly in the GPB Map screen (in the bottom part of map control panel).

Data migration task for 85725.

The data job will recalculate the tour activities and resource leg start/end times on all tours that are not in status "Done".
In test systems there can be a large number of such tours, some of them can be many years old.

A large number of open tours means that the job can take a long time to execute.
It's also possible that test systems have some bad/broken data, which can result in errors in the data migration job Infolog. But those errors can be ignored - the job doesn't break any data, the scheduling can just fail if the test system has old tours which already have some data issue.

In production systems, no infolog errors are expected.

Previously, it was possible to specify tariff zone via exact TMS address(es) or TMS address group(s) only when tariff zone type was 'Advanced'. This was not necessary and was enhanced, now it is possible to specify TMS address based tariff zones in both "Advanced" & "Simple" tariff zone types.

New data entity 'TAL Tour activity detail' was added to the system, it is now possible to export activity details of the tour confirmation from D365 (the data entity is allowed only for exporting).

New compiler checks were introduced in Microsoft update 10.0.23, and we needed to make adjustments to solve the errors.

D365 browser window could sometime crash, when user opened the D365-embedded map (that is used for 'Calculation transport costs' visualization). The issue was especially happening when the D365-embedded map was opened and closed several times during the same session.

Please note:
- the issue was related only to D365-embedded map (that is used for 'Calculation transport costs' visualization); the standard GPB Map was not affected.

Previously, in certain constellation it could happen that when assigning resources from GPB Resource screen into GPB gantt screens (via 'drag & drop') then in the tooltip info (where all 'to be assigned' resources are shown) were some resources duplicated. The issue was especially happening when some resource combinations were used (but was happening only in the tooltip info display; the effectively planned resources were not duplicated on the tour, thus the duplicated resource planning did not occurred).

In case the tour has a single order that blocks the 'Release to warehouse' process (e.g. credit limit block or not enough stock) then the tour is not released to warehouse. Which is in general correct & expected.
The issue was that when the 'Release to warehouse' was launched as a scheduled periodic task (via batch tasks), then the whole batch process was set to 'Error' status and therefore did not process any further tours. Such behaviour is not expected and was corrected in this task.
Newly, the elements that cannot be released to warehouse are just skipped and the batch task continues with the next 'Release to warehouse' process (ie. either tour stop or transport leg, depending on the load building scope).

As a consequence, 'Release to warehouse' batch task goes into 'Error' only in case some really unexpected error is encountered.

Previously, when 'Release to warehouse' process was used, either whole quantity of respective item was released to warehouse (ie. when all conditions of 'Release to warehouse' were fulfilled) or the item was not released at all (eg. when some quantity was not available).

This task introduces a process of partial release to warehouse, where those elements (that can be released to warehouse) are released, and the rest is not released. The elements that were not released to warehouse can then be processed either via 'Load line split' process (in Goods management form) or via 'Remove not picked shipment lots' (in TAL shipment form) or they can be released later.

Partial release to warehouse is done via same 'Release to warehouse' menuitems (and scheduled tasks), if activated via parameterization.

Parameterization is done in the 'Trade and Distribution parameters (module overlapping)', in the section 'Shipment builder', in the new field group 'Release to warehouse'.

Newly, it is possible to launch 'Send to Truck loading app' and 'Withdraw from Truck loading app' also per each individual resource (previously this was possible only per all resources of the whole tour).

Key characteristics:
- To distinguish the new 'per resource' feature from previously existing 'per whole tour' feature, the menuitems for new feature are named in the following way:
- 'Send resource to Truck Loading App'
- 'Cancel resource from Truck Loading App'

- Both menutitems are available in following places:
- In GPB 'Resource Dispatching' screen:
- In the 'right mouse click' context menu of the resource leg (in level 2)
- In the 'right mouse click' context menu of the whole tour (in level 1)
- In GPB 'Tour Dispatching' screen:
- In the 'right mouse click' context menu of the resource leg (in level 2)

This feature allows to selectively submit individual resources (eg. for loading) to the truck loading app, while still keep other resources (eg. for loading) not yet submitted to truck loading app (and activate them later).

Follower of the enhancement 85051 (delivered in TMS release 10.0-CAP21.0).

Following work instruction related business cases are now better covered:
- when moving transport orders from one carrying resource to another in Truck loading app
- more reliable handling of cases where one depot is enabled only for one truck loading app flow (eg. either only for 'loading' or only for 'unloading')

In certain complex scenarios, it could happen that transport order/line without carrying resource assignment (which is planned in the tour that has some other order/line already assigned to carrying resource) was still submitted to truck loading app. The issue was happening especially when carrying resource assignment was done on the package level (and in certain combinations of order/lines, package assignment & 'not assignment'). The issue was corrected.

It was previously possible to deactivate the depot for 'Release to depot' while have it still activated for some Truck loading app process. Such parameterization is not supported and the previously existing validation was enhanced, to prevent it.

General rules are:
- It is possible to parameterize the depot for 'Release to depot' without Truck loading app
- the depot can be activated for Truck loading app only when it is also activated for 'Release to depot' process.

Two issues were identified, that could cause mobile app to become unresponsive (and stuck):
- 'grey screen' - when middleware was not reachable (eg. internet connection is not available, or middleware is temporarily stopped), the mobile apps could stuck in grey screen.
- unable to log in - even when correct credentials were re-entered

Both issues did occur if the mobile app (where user was successfully logged in earlier) was launched again when connection to middleware or internet is not available.

Both issues were corrected and both mobile apps now automatically recover (and continue) as soon as the internet connection is available.

In the driver app (that is installed on the device that is running on Android 11), if the user tries to click the arrow icon on the tour stop, message "Can't open Google Maps!" is displayed and map is not opened.