10.0-CAP26.0 (17.06.2022)

Following improvements were done in the 'Manually create message' wizard (CAPcargo Transport > Common > All Transport orders > Confirmation > Track and Trace > Manually create message):
- Default Package identification code was added to the grid, both in the second & third page of the wizard
- If multiple packages are selected in the second page of the wizard (Select the underlaying data for the message), existing messages for all of them are newly shown in the third page (Check for existing messages). Previously, system showed on the third page only the existing messages for the active record in the second page.

'Optimization factor' (as defined in main TMS parameters) was not respected when calculating the driving distance & time in the 'Calculation transport costs' process. The issue was corrected and the parameter is now used & respected.

With certain combination of transport order dates & rough scheduling parameterization, it can happen that transport leg is scheduled to happen in the past. This is possible for example when 'Backward' rough scheduling strategy is used, and via rough scheduling rules the system can find only date that is in the past. In that case the transport leg is still rough scheduled with the calculated past date, but user is newly informed via Conflict350 ('Scheduling - no valid rough scheduling found for this transport leg') in the conflict management on the transport leg (provided that the Conflict350 is activated on the transport type). _x000D_
When determining whether the transport leg rough scheduling date is in the past, the time zone of the address (of the transport leg point) is respected.

When the tour was previously generated from the default tour (that had some tour sub-contracting activated), then the start date of the resulting tour was wrong (ie. the tour was created with start date of many years in the past). The issue was corrected and the tour start date is now taken again from the default tour planning dialog.

The issue was especially happening when 'Transit scheduling' plan date control was activated on the route/zone, but no valid transit schedule was set up. The issue was corrected and 'Plus days' transport leg parameter is applied in rough scheduling even when no valid transit schedule is found.

The previously released fix (task 89304 'Wrong driving distance & time calculations between tour stops', in release 10.0-CAP25.0) corrected most of the cases, with one (rather hypothetical) exception - when the driving time & distance of the tour was previously calculated in 'kilometres' but the default distance unit was then switched (in main TMS parameters) into 'miles'. Then further re-calculation of previously existing tours was showing the wrong results. The behavior was corrected.

Previously, when departure from tour stop was confirmed (but the 'Driving time and distance' confirmed was still not confirmed), the tour didn't show as departed in GPB gantt screens. The behavior was enhanced and 'departed' visualization of the tour stop in the GPB app is newly following the state of 'Departure' flag of the tour stop.

When performing the 'Release for departure' in GPB 'Resource Dispatching' screen on multiple selected tours, then occasionally the tours failed to refresh automatically (and the refreshing spinning wheel stayed on the screen). The issue was especially noticed on the tours that were submitted to driver app (but could also happen on other tours). Issue was corrected.

Previously, it was possible to perform a sequence optimization even on tours that were already departed. This could lead into unexpected situations on the tour stop structure, especially when some tour stops were already confirmed.
Newly, the sequence optimization can be launched only for the tour which first tour stop is not yet 'Departed'.

The issue was encountered in GPB 'Resource Dispatching', in following special constellation:
- when tour had already several resources (eg. Driver1 & Driver2) and user was selecting the tour for one resource (eg. Driver1), then when user was adding new resource (eg. Truck1) to tour via drag and drop, and was dropping the Truck1 resource to the position of Driver2 tour, then the endless 'loading wheel' was encountered.

The issue was corrected and resource assignment is now refreshed correctly (even in above described special constellation).

The issue was happing only in the GPB 'Tour Dispatching' screen and only in certain constellations.

The performance of initial tour stop detail loading in GPB gantt screen was improved, by removing certain elements from the initial loading into separate background service(s).

Following elements are now not loaded directly during initial tour stop loading (eg. when selecting a tour), but are only loaded later (via background services):
- capacity checks on the tour stops
- work instruction status icon on the tour stops

The issue was experienced for example during the failed delivery registration, where many documenting photos were taken. Then from certain amount of pictures taken, the app started to perform poorly (as more and more app storage was consumed), until it ultimately crashes. Afterwards, the driver app would not start again anymore, until cache and storage was cleared.

This fix improves the handling but doesn't fix all the related issues. Therefore it's not recommended to add more than 1 picture when using the "Skip all remaining activities" process = swiping Depart when unconfirmed activities still remain.

Additionally, to overcome some issues on big tours we have reduced parallel processing in the app (temporary solution), which means that the app UI is blocked by a "Syncing" dialog when the user confirms activities that trigger a sync (=First activity of the tour, and last activity of all tour stops). This adds waiting time of about 30 sec per sync.

This entity was previously to "Driver app" license configuration key, which caused that truck loading app could be run only when 'Driver app' license configuration key was activated. The issue was corrected and mobile app tour composite entity is now linked to 'Mobile app base features', thus it is now possible to set up truck loading app also without driver app license.

Additionally, 'Modules' property was not filled on the 'Mobile app activity feedback' entity (is now correctly set to 'TALTransportSolution'), hence the entity now shows up correctly in the Entity model view.

Previously, when tour was generated from default tour template, all tour activities were considered as 'optional' in the mobile app tours. Which was not according to general mechanism (ie. all tour activities shall be by default considered as 'Mandatory for mobile apps', unless they are configured as 'optional' via instruction activity rules). The issue was corrected.

When working with big tours (hundreds of activities) the app sometimes loses some of the feedbacks (=confirmations/swipes) and the related orders/packages are therefore not confirmed in D365.

Several improvements have been made but it's still not a perfect solution.

To overcome this issue we have reduced parallel processing in the app (temporary solution), which means that the app UI is blocked by a "Syncing" dialog when the user confirms activities that trigger a sync (=First activity of the tour, and last activity of all tour stops). This adds waiting time of about 30 sec per sync.

Previously, when driver was rearranging (and confirming) a custom tour stop sequence in the driver app, this could lead to incomplete tour confirmation in the D365 backend. Especially the driving time & distance confirmation was sometimes missing. The issue was corrected and the custom tour stop sequence is now better reflected in the D365 tour confirmation when processing the feedback from the mobile app.
Additionally, new menuitem 'Show confirmed sequence' was added to tour confirmation form (that is accessible when tour stop sequence was re-arranged in the driver app), to be able to switch between originally foreseen & rearranged tour stop sequence.

Following optional parameters were previously not respected during sequence optimization of the tour:
- 'Respect business hours'
- 'Respect customer wish'

The issue was corrected and both parameters are now reflected in the sequence optimization algorithm.

IMPORTANT: Usage of business opening hours in the sequence optimization algorithm has limitations, it is NOT an optimizer. This is the supported scope:

Simple geographical sequence optimization (ie. when no optional parameters are activated)
- Not considering business opening hours
- Not considering capacities
- Just geography and load/unload rules (load not before unload)

The following additional options are available, with currently clear limitations, see below.
- Respect business hours
- Respect customer wish
- Unload all before load

Sequence optimization with respecting business opening hours / customer wishes
- customer wish is stronger than business opening hour
- it can only shift stops, which in the best case leads to matching business opening hours
- it cannot insert wait activities
- it cannot postpone tours to next days
- it does not handle capacities
- combinations with further requirements (e.g. First unload all, then re-load) can become difficult quickly
- Example: it can solve simple cases such as 1 out of 20 orders should be delivered in the morning, not in the afternoon.
- If no valid solution can be found, it will not optimize and through a warning

Sequence optimization with respecting “First unload all orders before new orders are re-loaded”
- Additionally to the above features, here a prioritization of orders is respected
- Example: Tour has 10 unloads all from same depot, and then some re-loads back to same depot
- Without this option activated, the optimizer would just optimize by geography and mix loads and unloads (of course respecting load before unload PER ORDER)
- With this option activated, the optimizer unloads first all orders to empty the truck, and only then starts recollecting orders back to the depot. This might not be the most optimal geographical sequence

Previously, when changing a country during registration of new address, system (in some parameterization constellation) launched automatically an address geo-coding process, despite no address details were entered yet. The address geo-coding process then failed and user was informed accordingly. The issue was corrected and address geo-coding process is not launched anymore immediately after country change.

Previously, certain email handling in transport module was done via SrsProxy & SysEmailBatch code/classes. Both functionality will be generally deprecated by Microsoft in some future D365 platform release. As a preparation, email handling in transport module was refactored, to stop using above mentioned classes.

Following processes was adjusted:
- Customer invoice printout (when invoice report is sent via email)
- Emailing from GPB app
- Track & Trace emails

Changes were done on the code level, without any impact on the functionality & end user experience.

Data migration task for 88258.

Data migration task restores the previously existing activation of 'Close tour' sub-process, in the new standalone 'Close tour' process (by setting the 'Show process button' state)

Package identification code was previously added to the TMS package only when auto-containerization was used for picking in the warehouse. This was enhanced and package identification code is newly added to the TMS package also for the custom work line and for the packing station. This also allows an integration between warehouse labels and the barcode scanning (in the mobile apps).

The issue was happening especially when tour contained tour stops of transport type (for which no capacity was defined). Then sending of such tour stop to truck loading app failed (which is correct), but the issue was that the sending process stopped entirely (and further tour stops were not processed/sent, even though they have sufficient capacity). In such cases the user was also misleadingly informed that tour will be sent to truck loading app, but it was not.
The issue was corrected and sending of tour to truck loading app is now not stopping upon capacity validation but is processing also further tour stops.