10.0-CAP38.0 (29.11.2023)

New classification of 'CO2 Emission class' has been added to the vehicle type and also to the individual vehicle record. As per PTV interface, 5 CO2 emission classes are supported, where 1 is the fallback for all vehicles not fitting to 2 -5. The higher the CO2 emission class, the higher the reduction of the toll costs.

Additionally, a new value 'EEV' has been added to 'Emission class' classification, as it was previously missing (both in vehicle type and also in individual vehicle record).

In order to be consistent with the initialization of other technical data from vehicle type to vehicle during new vehicle creation or changing of vehicle type on vehicle, the range initially defined on vehicle type is initialized to vehicle. Afterwards, user can still customize the range on each individual vehicle.

Not all information/warning/error messages generated by Optimizer dispatch process were properly written to the tourplan log. This is now fixed.

A new grouping, named "Parameters" was added to the Optimizer tourplan Tour planning Details summary tab.
This grouping stores the relevant parameters defined by user in the Optimizer dispatch form:
- for Optimizer provider = Generic
> vehicle group
> resource combination plan
> planning mode and date
> number of selected transport legs (for dispatching, regardless of how many were actually planned or not in tours)

- for Optimizer provider = PTV xTour
> vehicle group
> resource combination plan
> planning mode and date
> target function optimizer
> calculation mode + string
> ignore HPRN
> number of selected transport legs (for dispatching, regardless of how many were actually planned or not in tours)

The vehicle group/resource combination plan ID's are stored with the assumption that their setup was valid at the moment of generating the particular tourplan. As a limitation, if user generates a tourplan with a certain resource combination plan (for example), then makes changes to the resource combination plan (adds vehicles, changes validity dates, breaks etc.) and then uses it to generate another tourplan, on both these tourplans the same resource combination ID will be stored, even though its details were effectively different from one run to another.
Additionally, if user then attempts to add new legs to existing TMS tours created with a particular resource combination plan, the correct vehicles will be used (Optimizer will respect the resource combination plan initially used and the vehicle(s) with proper row numbers), but using the latest resource combination plan line details.

On Tour PLan>Tour headers, the resource combination plan ID and row numbers are also stored (if used) in new separate columns.

"No. additional stops" field is moved under config key "Register additional stops". If the config key is ON, the field is visible in the grid in TAL and GPB OS. The feature "Register additional stops" though is not officially released and will soon be deprecated.

Following issues were corrected:
- On part of the columns (not all) the width could not be widened/adjusted
- The columns that can't be widened, can only be shortened (reduced) in size, but afterwards the divider line between the columns is no longer active (and the column width is fixed, until full refresh, or restart of the screen

When resizing GPB gantt screens/windows to smaller size, some GUI elements could previously get overlapped with each other. The behavior was especially happening to dedicated filters (above main gantt grid). GUI screen element handling was improved, to avoid such overlaps.

Following enhancements were done in the dialog (that is opened when launching 'Backward calculate tour start' in GPB gantt screens):
- the previously existing D365 dialog (where dispatcher should enter/confirm the calculation parameters) was replaced by GPB dialog, to achieve more fluent user experience (and to preserve original selection of tour stop)
- separate picker for 'time' (previously, one common picker was used both for date & time)

Vehicles or drivers are supposed to be in a vehicle or driver group to be available for GPB dispatching. Resources not being in such a group are not available in RS or in any filter lookups. However, if a non-grouped resource is still assigned to a tour (e.g. via dispatch light or tour-create-dialog or any other [inevitable] none-GPB process), the functionality though is not restricted, all processes work fine. The following limitations were removed:
- In Gantt level 2 (upper part) the resource bar shows a "?" as icon for this resource instead of the proper icon
- In Gantt Resource such a resource leg was not visible; in Gantt Tour it was

It´s now possible to set up "Activity additional text" for Signature activity. This will be displayed in Driver app on the signature screen. The text can be a disclaimer or statement which the customer or driver acknowledges with their signature. It´s possible to set up translations for the text. The app will show the translation in customer language, based on orders that are handled on the tour stop.

Improve error handling in Mobile app change tracking / Mobile app tour creation process: the process is now able to continue even if too big or corrupted attachments exist. Maximum supported size for Mobile app attachments is currently 4 MB.

If manually estimated time of arrival (aka 'manual ETA') is specified on the tour stop, it can now be also visualized also in the driver app. Prerequisite: feature has to be activated in transport type, via parameter 'Display Manual ETA on Tour Stop'.

Note: this feature is in preview and there are known issues which will be fixed in an upcoming CAP release.

It´s now possible to set up "Checklist" activities via Instruction activity rules. In the app they show up on a separate checklist screen which is displayed when the user swipes/scans a load/unload activity. Checklists can be related to transport order, transport order line or package.

Supported activity types for checklist are:
- Input - Checkbox
- Input - Freetext
- Input - Number with decimals
- Input - Number without decimals

The description of checklist activities is taken from activity master data setup in D365. It´s also now possible to link Instruction activity rule to specific activity setup - until now it was a fixed 1:1 relation. With the new approach it´s for example possible to set up many Checkbox activities with different descriptions.

Known issues:
- Many problems with barcode scanning. It´s not recommended to use this feature with packages / barcodes at this point.

The shipment builder (bridge between D365 trade orders and CAP transport order) is being redesigned in several phases. In R38, the 4rd phase is included which contains following functionality/improvements:
- Adapt Delivery Window logic
- Quantity split - Load line splitting
- Loading/Unloading list report
- Synchronization of transport orders in direct delivery chain

The redesign is not yet fully completed (as at least one phase will be still published in some future release), hence is not yet officially released/supported).

It's linked to a license configuration key which is not allowed to activate in productive environments. CAPcargo rejects all responsibility for using it in production.

The optimization was done purely on the code structure level, without any impact on the functionality. Internal tests showed improvement up to 15%, depending on the complexity of the received orders.

Objects that are used with the old subcontracting feature have now been marked as deprecated in code and in "Changes in public APIs" document. This helps customer development team to detect customizations that need to be adjusted to fit the new subcontracting module.

See CAPcargo installation instructions for more information about the code and data migration into the new subcontracting feature.

Batch job "Checked imported order clean up" has been deprecated. It did not work correctly, and will be replaced by a new cleanup which removes "Imported orders" and "Checked imported orders" - see 100242.

Several freetext reference fields were added on Transport order:

On Transport Order header:
- Customer reference [existing] - printed on invoice
- Customer reference invoice - printed on invoice
- External WMS reference
- Sender reference
- Loading reference - printed on tour report
- Receiver reference
- Unloading reference - printed on tour report

On Transport Order line(s):
- Contract reference - printed on invoice

Contract reference was added on contract/-version/-relation, from where it is initialized on Transport Order.
Customer reference invoice was added to the Default order header.
Customer reference invoice was added as a Header criteria on Rule collective invoice.
Contract reference was added as a Line criteria on Rule collective invoice.
Customer reference invoice and Contract reference were added as grid filters in Customer invoicing pool.
Contract reference was added as filter criteria in Customer invoicing pool.

Copy Transport Order function was enhanced.
Customer invoicing process was enhanced with a new field "Document" - printed on invoice.

This enhanced feature set will replace the not-officially released sub-module "Order reference management", a beta framework for dynamic references. Will be deprecated in one of the next releases.

Batch job "Checked imported order clean up" has been deprecated. It did not work correctly, and will be replaced by a new cleanup which removes "Imported orders" and "Checked imported orders" - see 100242.

Issue was corrected in the following way:
- Failed address geo-coding does not anymore crash the EDI import process, the problematic record is just skipped (and EDI batch continues over)
- New 'Skip automatic geo-coding' parameter was added to import group, to be able to disable whole address geo-coding during EDI order import

When exporting tourplans by using incremental push only as default refresh type, all tourplan statuses were changes to "Exported", regardless of Optimizer provider or whether initial status was in fact "Ready for export" or something different.
To solve this, two new elements were added to the data entity which can be used for filtering tours in the export project:
- Optimizer provider
- tour plan status

By properly configuring these additional fields, only the intended tourplans are both exported and have their status be changed to "Exported".

Tour start/end parameters "First load address in tour"/"Last unload address in tour" were not respected in the process of adding new legs to existing tours by Optimizer dispatching, causing errors or suboptimal results. This has been fixed.

When planning drivers by using midterm driver plan as an option for driver combination on vehicle, the Optimizer was limited at considering only the date of a particular driver for availability in the proces of dispatching, not the time of day itself. This has been partially fixed, for the case when on a particular day, one vehicle ends a driver assignment at a particular time or starts a driver assignment at a particular time (though not yet for the case when both events happen on the same vehicle in the same day).

The issue was observed when making resource related changes (eg. specifying new vehicle icons, or assigning new tours to resources etc.). Then, 'Refresh all' was sometimes not reflecting these changes.

Previously, it could happen that attachments were not sent out from D365 to Driver app. The issue was happening only on certain systems/installations and was related to incompatible .dll component combination.

Previously, when a purchase order was re-approved via workflow, a new load and load line was created for the purchase order line, causing a discrepancy between purchase order line / inventory transaction quantity and load line quantity. The issue was corrected.

In case the "Pre-defined time windows" were enabled, there was an issue with the shipment builder criteria. Users could get different results depending on their language settings. This was not correct as it could lead to removing of shipment lots from shipments. The issue was corrected.

The issue was happening only when load/unload date were changed on the trade order headers. Then, the validation was not applied. The issue was corrected and newly also the change of header date fields is validated.

Following main menu queries were affected (and are now corrected):
- 'Sub-contracting transport leg with document handling issues'
- 'Sub-contracting tour with document handling issues'

On a tour executed with Tr-leg subcontracted resources, in case of a failed delivery (triggered from driver app during tour confirmation while Transport Parameters>Dispatching>Tour>Subcontracting>Auto subcontracting order creation at failed delivery = true), the system correctly created on same tour another leg to return the failed delivery to depot, but failed to create the corresponding Tr-Leg (LTL) order for that leg at the same time. This has been fixed only for the new (harmonized) subcontracting world.

Important:
In case of mobile app custom implementation (either Driver app or Truck loading app), the change of integration schema has to be reflected in the custom implementation, to ensure that mobile app continue working even after the upgrade to 10.0-CAP38.0.

New Mobile app activity types
- Checkbox (36) - User can answer a yes/no question by ticking (or not ticking) a checkbox
- Number without decimals (37) - User must enter a number, no decimal value (vs. existing decimal input - 33).

New fields in Mobile app tour activity (TALdraTourActivityEntity):
- CHECKLISTID (sting)
-- Used to distinguish activities for the new Checklist functionality (96214). Contains ActivityId of the checklist "base" activity. Checklist base activity contains CHECKLISTID that points to the activity´s own ACTIVITYID

- CHECKLISTSEQUENCE (integer)
-- Used for sorting activities on the new checklist screen