10.0-CAP28.0 (29.08.2022)

Invoice surcharges were previously not included in the SSRS dataprovider for the transport invoice (TALCustInvoice).
Invoice surcharges are now included in the report dataprovider. This means for customers who are using external reporting tools or own report designs now have the data available to show the invoice surcharge values. The standard SSRS invoice report template TALCustInvoice will be adjusted in a successor release.

The issue was especially happening when "Automatic package creation" was deactivated on the transport type.

Feature allows to set up a periodic task for direct confirmation of transport orders (ie. confirmation without dispatching)

Button loads (and highlights) all related resource legs of a single selected transport order in GPB Resource Dispatching screen. Not related tours can be shown (or hidden) depending on a new filter 'Show all resources". All tours – highlighted or not highlighted – can still be selected, changed etc. (ie. the highlighted tours are not anyhow “locked” etc.)

This allows to get a complete overview of resources that participate on the transport order, regardless of amount of the tours.

Following issues were corrected, in the area of default tours:
- Tours could not be generated from default tours, when some "non-transport" address was used as default tour start or end
- Wrong sequence could be achieved on default tour template (SUB stop could get after END stop)
- Missing default tour header auto-refresh, after some change was done on the default tour line

Previously, the transport type (from main TMS parameters) was applied.

When launching 'Release for departure' for more selected tours in the GPB gantt screens, then the processing sometimes didn't finish (and users were getting only never ending 'loading wheel' icon). The issue was especially encountered when 'Print Unloading list at tour release' was activated on the transport type. The issue was corrected.

Previously, on 'Dispatch light - Transport legs' form, it could happen that user specified grid filtering/grouping was lost (ie. reset to default) after 'Dispatch in tour' was used. The issue was corrected user specified grid filtering/grouping is now preserved even after 'Dispatch in tour' is used.

Previously, when creating new tour manually, the tour was created with default start time (from main transport parameters) even though user specifically set the tour to start at midnight (ie. at 00:00). The issue was corrected and user's tour start specification is newly respected.

The previous logic of having dummy records in TALuldTransactionTable for the better calculation of cleaning needs was based on performance ideas, but turns out to be disturbing for all other processes which depend on the ULD transactions. These "Auto-allocated" ULD transactions are not "real" carrying resource assignments (though being stored in the same TALuldTransactionTable), hence they were moved into a separate table. The cleaning logic reads them from new dedicated table almost in the same performance, as in previous release.

Following issues were corrected in the the area of tour sequence optimization:
- Improvement of tour sequence optimization warning & error infologs, to provide more details about address where some issue was encountered. For comparison: previously sequence optimization reported for example just "Address is closed!", and it was not understandable which address was was closed.
- 'Non-transport addresses' are newly considered as nonstop open (ie. 24/7), as no business hours specification is possible. For comparison: previously such addresses were wrongly treated as "never open", thus leading into "Address is closed!" infologs.

Pickup of return orders in mobile apps always requires to have a separate activity for them. So even if "one load/unload per tour stop" is used, separate activities are created for loading of the return orders. The issue was that the quantity of return order pickup was duplicated, once in the dedicated loading activity for return order pickup (which is correct), but was also included in the grouped loading activity (which was not correct).

Correction of known issue 90733 of release 10.0-CAP27.0.

Pictures/photos attached by user in driver app should now consume less disk space in the mobile device. The improvement was achieved by applying image compression and avoiding the duplicated attachments (that were being created when using 'Skip all remaining activities' in the mobile app).

When changing relevant information on the transport leg or on the tour stop (such as the date), the previously existing 'pre-loading' activities are newly re-calculated (via instruction activity rules), in order to respect their validity.
- For unplanned leg: Relevant date = rough scheduling date
- For planned leg: Relevant date = tour stop plan date (ie. detail scheduling date)

Please note:
Previously to this advanced activity configuration (ie. where rules like pre-loading are automatically initialized and applied), there was a more basic version of pre-loading flag initialization on the transport leg. This basic rule (default value of pre-loading flag defined on cross-docking rules) is replaced within this task by the new advanced instruction activity rule framework.

Several new features of PTV xServer2 were incorporated into transport module, to improve the existing dispatching processes and better support handling of larger tours (e.g. with 50+ tour stops).
Release 10.0-CAP29.0 was tested with PTV xServer 2.26 (which is thus recommended for general usage).

1) Usage of HPRN - several processes in transport module can newly benefit from HPRN feature of PTV xServer2 (aka. High Performing Routing Network). The idea of HPRN is to use a pre-calculated matrix of driving times & distances (for exact vehicle profile, further referred as DIMA), instead of 'on-the-fly' calculations in the PTV xServer (which are much more performance demanding). Once set up, the HPRN is then automatically used in tour sequence optimization process (and will be also used in the 'to be introduced' Optimizer module).
Prerequisite parameterization:
- Set HPRNId on vehicle type (which will be used to establishes a link between TMS vehicle type and vehicle profile of the HPRN/DIMA)
- Create HPRN (for certain vehicle type & area)
- 'Transport Parameters' -> 'Geo services' -> 'xServer parameter' -> 'Create HPRN'
- Setup xData service endpoint:
- 'Transport Parameters' -> 'Geo services' -> 'xServer parameter' -> 'xData endpoint'

Please note: the HPRN creation is quite performance demanding (due to huge amount records that needs to be pre-calculated) and can lead to higher loads of xServer. So should be carefully tested/observed before using it on productive installations.

2) Feature layers
- Per vehicle type: feature layers are activated on individual vehicle type (ie. 'Truck attributes'). Once activated, the feature layers will used for the vehicle type:
- 'Vehicle type' -> 'Setup' -> 'Geo service features'
- Truck attribute (was hardcoded in previous TMS versions, is now optional, via this parameter)
- General: feature layer 'Traffic incidents' contains information about temporary road closings (eg. constructions) as well as traffic information (traffic jams, accidents) and more. Activation of 'Traffic incidents' feature layer is done in main transport parameters:
- 'Transport Parameters' -> 'Geo services' -> 'xServer parameter' -> 'Use real time traffic data'

3) Only the parameterization of vehicle type is newly respected for xServer API. It is still possible to set up parameters directly on individual vehicle (eg. for evidence), but these are not anymore used in xServer API calls.
- Data migration jobs are provided:
- 'Truck attributes' are generated for all vehicle types
- Ensure that values have content on the needed fields on vehicle type (dimension/weight/emission class)
- Job reads from vehicles in case vehicle type fields are empty

For more information also read 91547 (Time/distance calculation with 2 new modes → Simple vs Advanced) and 91559 (Vehicle type: Total permitted weight)

The field “Total permitted weight” on vehicle type(used to be called 'Registered toll cost weight' and was only relevant for toll cost calculation) has become very important as it is used more prominently for tour sequence-/ tour optimization algorithms, but also for driving time/distance calculation respecting weight, truck attributes and hazardous goods.

Hence it's though important to have that field filled on all vehicle types.

Please note:
The truck attributes and weight information on the vehicle itself is not respected by the above mentioned processes, but only the values from the vehicle type.

Data migration task for 86841.

Data migration task activates the 'Truck attributes' feature layer on all vehicle types, to provide the same experience for existing projects (as in previous TMS releases the truck attributes were always used).

Following CAPcargo license reports were sometimes not working in customer environments - instead error message "Unable to find the report design TALuserLicenseCountReport.TALuserLicenseReport" was displayed.
- Named User License Counts
- User License Counts History

Step 13 of Chapter 2.3 of the CAPcargo solution installation instructions has been enhanced, instructing the user to add also "Reports" folder under CAPcargoTALConfiguration package to the source control after installing the CAPcargo solution.

Following action menuitems (on the 'Product transportation status' form) were previously available only to users (with system administrator security role):
- Fix load date
- Fix delivery date
- Undo load date fixing
- Undo delivery date fixing

The issue was corrected and the menuitems do not require the 'system administrator' security role anymore.

Following enhancements of container type mapping & instruction activity rules were introduced:
- The container type mapping is used to map container types of one legal entity with transport types / transport units of the same or a different legal entity.
- Pack by directive unit activated: In this case the transport type / transport unit combination is linked to a D365 unit of measure since the container created via a container build template activated for this option has also a D365 unit of measure as container type.
- Pack by directive unit deactivated: In this case the transport type / transport unit combination is linked to a container type.
- One load/unload activity per transport order line: if this activity type is setup for a specific transport type / transport unit combination only one single load/unload activity gets created per same transport order line.In case of using packages, the user only needs to scan one barcode to confirm all packages linked to this activity.

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