10.0-CAP27.0 (29.06.2022)

Following improvements were done in the handling of address area on the transport order:
- When creating new order lines, then address areas (on the order line) were previously not initialized from the order header
- When updating address on transport order (via several functionality), then the address areas (on the order line) were not updated from the order header
- Confirm the address area scan activity when last driver app address area scan activity is confirmed
- Barcode scanning activity for address area was sometimes shown in driver app only as optional (but could not be 'swiped away')

The issue was happening especially when 'Loading list' was printed from the tour that was previously released to depot.

The issue was encountered for example when planning transport order directly to new tour (with allocation of some resource, with activation of 'Release tour for departure' option).

The issue affects mostly attachments (eg. work instruction or address attachments).

Some sites load the goods into the vehicle before the driver starts his shift. In this case no detailed loading (ie. package by package) is needed by the driver, but only the confirmation of an aggregated load activity that represents that driver found everything in order. This is to be solved by 'Pre-loading' functionality, that introduces a simplified processing in the driver app and in D365.

Key points:
- Two new criteria ('Valid for transport address' & date range 'Valid from'/'Valid to') were added to the 'Instruction activity rules', that are considered by the system when instruction activities are generated
- New action type 'Pre-loading' was added to 'Instruction activity rules'. Main purpose of the pre-loading action type is to set the 'Pre-loading' flag on the load transport leg point that fulfils the criteria of this rule record. As soon as the 'Pre-loading' flag is set the system is going to calculate with 0 duration for the load activity.
- Pre-loading is interpreted by the system that loading was done before the driver started his tour, moreover, it was done outside of CAP.Transport. Hence no confirmation in expected by the party who performed the pre-loading. Therefore, at departure from a tour stop that contains pre-loading transport leg points, the system automatically performs the confirmation of the pre-loading transport leg related tour order lines and package tour order lines (by taking over the planned quantities 1:1). Furthermore, it also confirms the load activity if it’s not done by the driver app automatically

Additionally, the 'Active' flag ware removed from the 'Instruction activity rules' grid and is now transformed into 'Show only active rules' filter.

Tours with a large number of stops and activities (for example 50 stops, 700 activities) can sometimes suffer from lost/missing feedbacks. This means that some activities (that driver completed in the app) don't appear as completed in D365 backend. And when the driver does logout/login (forcing full data refresh from the middleware), those activities appear as not confirmed in the app, too.

If the driver notices that old & already completed tour reappears as "in progress" in the apps, they should complete all the remaining activities to solve the problem.

When driver reported unplanned return order, and specified such return address that already exists among the upcoming tour stops, the unloading of this return order was previously not handled correctly in the app activities.

When unplanned return order (with packages) is registered in driver app, a return order is created in D365 backend. The issue was that that the planning quantities (and transport quantity) of this order was always 0.

Newly, the conversion (from the package unit to transport unit & planning units) is applied, even when unplanned return order (with packages) is registered in driver app. (Previously, such conversion was already applied, but only when unplanned return order was registered directly in D365 backend)

Depending on the instruction activity setup, it's possible that many rules would provide the same activity on the same tour stop. Certain control mechanism is in place which should prevent creating duplicate activities but it was failing in some situations.

When tour contained both tour stops (with load/unload) and tour stops (without orders), then the sequence optimization aligned into optimized sequence only the tour stops (with load/unload) and the tour stops (without orders) were just added afterwards (ie. close to the end of tour).
The issue was corrected, the sequence optimization now includes also tour stops (without orders) into optimization query to PTV xServer.

New data entity 'TAL Template OS configuration' was added, both for export and import projects.

Track & Trace, Message Framework:
Back in summer 21 we added the leg type as own fields to the leg. Therefore there is no purpose anymore in maintaining a separate criteria type "transport leg type" on the status message criteria, since we just can use the new fields on the legs.

Hence, in the configuration, the transport leg type criteria can be replaced by transport leg fields criteria.

Also the failed delivery/pickup and the sender delivery & receiver pickup are available as fields and can be used and combined with the others.

Therefore we remove the criteria type "Transport leg type" completely. Customers can change their configuration anytime also those with older releases than R26.

Since the new feature exists already since summer 2021 (R20), also customers skipping R26 or R27 can easily change to the better already existing configuration. Therefore there is no need in keeping the old criteria type for 4 more releases. Hence the old criteria type is removed in R27.

Data migration task for 89658.

Data migration task updates the route selection lookups of the existing truck loading tours into new format (ie. route id + route description).

Data migration task for 90332.

Data migration task populates new 'Valid from' & 'Valid to' date range criteria on the 'Instruction activity rules' form, depending on the 'Active' flag, applying the following logic:
- When 'Active' flag was set, the 'Valid from' is populated with earliest system date and 'Valid to' is populated with latest system date
- When 'Active' flag was not set, the 'Valid from' is populated with earliest system date and 'Valid to' is populated with current system date minus 1 day

When creating transport order from trade order (and also when planning load capacity), it is newly possible to reflect the product variant data in the transport unit/quantity calculation.

Key points:
- 'Transport type combination' parameters was added to the product variant
- When available, then the values are taken from:
- Transport type combination
- Total weight per inventory unit
- Product variant specific unit conversion
- When not available (as for example the related license configuration key is not activated, or the feature is not activated):
- If transport type combination on the product variant is not available, then released product is used
- If total weight on the product variant is not available, then the weight is calculated (per inventory unit) from the released product
- If product variant specific conversion is not available, the the product specific unit conversion from the released product is applied

If a newer version of the app has already been installed in the device, following steps should be done before installing CTP 3.2:
- Clear app cache & data
- Uninstall the app