10.0-CAP44.0 (20.11.2024)

PTV xServer 1 was launched in the market in 2006 and its technologically is now at the end of its product life cycle. It has been replaced by new technology PTV xServer 2 which has been available within CAPcargo solution for a couple of years already.

According to CAPcargo support life cycle, xServer 1 was supported until and inclusive release CAP29 which was supported until March 2023. This was announced in April 2022 and now with CAP44 finally the removal of the code has taken place. CAPcargo keeps investing and maintaining all our GIS features with xSever2.

Note about the feature "Validation in geocoding": There are different/better validation options for xServer 2, hence the old ones which were only for xServer1 can be removed → Menu "Geographical address validation", data records with empty values in field "Level of validation". - There is also a data migration job cleaning up some background data structure (ID 110871).

New option 'Map profile' was added to "xServer parameters", it is now possible to specify exact map profile that is used for map rendering/visualization.
Following profiles are available:
- Amber
- Backmarble
- CAPcargo
- Default
- Classic
- Gravelpit
- Sandbox
- Silica
- Silkysand

When having the 'Map profile' empty, then the 'CAPcargo' profile is applied (as in previous TMS releases). The 'CAPcargo' map profile is based on 'Default' profile, with some adjustments for preferred route visualization (to show them in green colors).

Please note:
Specifying a different 'Map profile' in xServer parameters will also change the visualization of preferred routes (these will start showing in blue colors, as this is the default preferred route visualization by PTV). To have the preferred route visualization keeping the green color even in other selected map profiles - a certain configuration change is needed (ie. xml files with profile specification needs to be manually adjusted).

In addition to Requested qualifications of transport orders and addresses, the driver can now also see information about Provided qualifications and Disqualifications of addresses and address areas.

Security roles for T&L Sales clerk and T&L Purchase clerk were adjusted so that they would only be allowed to visualize Commodity masterdata (not allowed to create, modify and delete commodities or commodity hierarchies).

Date filtering on the substitution contact form previously showed only "current date effective" substitutions. This was quite limiting and was adjusted - date filtering now includes also the upcoming substitutions.

Due to several new features and accumulated fields on the transport order, the UI needed to get streamlined. The GUI of a standard product especially for a very relevant form like the transport order can never met all wishes, for example it cannot bring all fields to the order line grid; it shall serve a clean UI providing a good, and not-overloaded overview. With the power of D365 customizations, each form can easily be adjusted to meet customer specific requirements.

This task implemented the following layout adjustments:

On TRO create wizard/Order line tab:
- new grouping 'TRANSPORT UNIT' was created, containing now 'Transport quantity', 'Transport unit', 'Stackability', 'Commodity' fields
- renamed grouping 'MEASUREMENTS PER TRANSPORT UNIT' to 'MEASUREMENTS'
- renamed grouping 'WEIGHT PER TRANSPORT UNIT' to 'WEIGHTS'
- planning unit fields were removed. Instead, the units were dynamically added to the labels of the Planning qty fields
- transport unit description field was removed

On Transport Order/Lines view/Line details tab:
- subtab 'General' was renamed 'Quantities'
- field 'Transport unit' was added under the field 'Transport quantity' (removed from Transport quantity label)
- field 'Transport unit description' was reduced to a rectangle with only 2 visible lines (actual char length not changed)
- renamed grouping 'MEASUREMENTS PER TRANSPORT UNIT' to 'MEASUREMENTS'
- renamed grouping 'WEIGHT PER TRANSPORT UNIT' to 'WEIGHTS'
- grouping 'Commodity' was moved next to the new 'Transport unit' grouping
- subtab 'Setup' was renamed 'General'
- ADR Yes/No flag was removed from 'Dangerous goods' grouping. The grouping itself was moved to new tab 'General'
- grouping 'Goods value' was moved to new tab 'General'
- new grouping 'Packages' was created under new tab 'General'. Fields 'No. of packages', 'No. of shared packages' and 'No. of future packages' were removed from Transport order lines grid into this new grouping
- grouping 'Product description' was moved to new tab 'General'

On Transport Order/Lines view/Transport order lines grid:
- fields 'No. of packages', 'No. of shared packages' and 'No. of future packages' were removed from Transport order lines grid into new grouping 'PACKAGES' in subtab 'General' in Line details tab
- new 'Empties' flag was created. This flag is false (not ticked) if the sum of all Empties qty fields on the order lines = 0, otherwise true (ticked)
- 'Unit empties 1' and 'Empties qty' fields were removed (displayed already under 'Quantities' subtab in Line details tab)

On Transport type:
- text adjusted for clarity on several field labels and helptext
- grouping 'QUANTITY CHANGE CAPTURING' was eliminated and flag 'Capture quantity changes' was moved under grouping 'CHANGE CAPTURING'

In DispLight Tour, there is only one tour header field for each resource role: vehicle, trailer, additional trailer, driver, additional driver. These are populated with the first resources fulfilling that role which are added to the tour (see also release letter for ADO 109132).
However, on the tour itself, many more resources can possibly exist (added via Drag&Drop of resources in GBP, resource swap processes etc.). Since in DispLight Tour these fields are limited to only displaying one value, information can be potentially confusing to user. Therefore, the labels of these fields have been enhanced with the dynamic addition of an asterisk.
The presence of an asterisk in the label itself indicates to the user that, even though in the respective field, he/she sees only one resource, on the tour there are actually more than one resources of that type OR the resource of that type is covering less than the scope of the entire tour.
The helptext label has also been enhanced to explain the presence of the asterisk and to point the user toward GPB to get the complete picture of all resources on that tour.

In the 'Create new tour' form, the 'Strategic tour routing' flag was previously added (default value taken from Transport parameters>Dispatching>Strategic tour routing processes>Transport order direct dispatch).

But when user planned a Transport order into an existing tour, this flag was not visible in the dispatching form, and the behavior related to the 'Strategic tour routing' was always based on the default Transport parameter value, without giving the user possibility to change it manually (as doable when dispatching to new tour).

The 'Strategic tour routing' flag was now added to the 'Dispatch directly' form.

Previously, even if a user was not allowed to see any menu item in a tab group on the Transport order ribbon, this tab still appeared as blank.
This was fixed, so that a user would only see the tab groups where user was allowed to see at least one menuitem.

With the deprecation of the 'automatic initialization of Manual ETA' feature (see ADO 109497), the manual ETA fields from the 'Create new tour' form are no longer automatically initialized with any data. However, depending on data setup, they are still available for user manual setup:
- 'Tour start' - always visible/editable
- 'Tour end' - visible/editable only when Transport Type setup allows for usage of manual ETA
- 'Load' - visible/editable only when load address is different than tour start address
- 'Unload' - visible/editable only when unload address is different than tour end address

When the 'Create new tour' form is opened by drag&dropping multiple Transport Legs on GS:
- 'Tour start' - always visible/editable
- 'Tour end' - visible/editable only when Transport Type setup allows for usage of manual ETA
- 'Load' - visible/editable only when load address is the same on all selected transport legs and different than tour start address
- 'Unload' - visible/editable only when unload address is the same on all selected transport legs and different than tour end address

A basic telemetry feature is being introduced. In order for telemetry data to be accessible to CAP, both:
- new configuration key 'Telemetry'
- new 'Telemetry' parameter in Transport Parameters
have to be enabled.

CAPcargo only tracks basic information, specifically only the forms and processes being manually accessed in the environment where telemetry is enabled. This information can be filtered by users, but all user data is anonymized. All data is used for the purpose of improving quality and performance of various forms and processes.

With this release, the old subcontracting codebase (LTL/FTL subcontracting) is removed and not accessible anymore.
Any subcontracting-related data/parameterization not properly migrated by using the subcontracting harmonization migration job BEFORE updating environments with this release, will be lost.

If you install CAP44 release before doing the data migration to the new subcontracting data model, you will lose your subcontracting data!!!

Previously, it was only possible to define a 'default' transport unit on any Transport type.
A new field 'Default qty' was now created on the Transport unit line in the Transport type form. When a transport unit is defined as 'default' (checkbox is marked as true), the new 'default qty' field becomes editable and user can adjust quantity (optional).
This default quantity is then automatically populated in the following forms at the same time with initialization of the default transport unit:
- Transport Order create form
- Transport Offer create form
- Transport Pre-order create form
- Transport order line > Add line

Address area qualifications are now implemented in the Qualifications overview form (regardless from where this was accessed: Transport Order grid, Transport Legs Screen, Gantt Screen) as a separate own group "Address area'.
This new group is displayed in both sections 'QUALIFICATIONS PROVIDED' and 'QUALIFICATIONS REQUESTED', using the same pattern already existing in the 'Address' group.
Beside the address area ID, qualification ID and qualification description, an additional 'Description' field was added, containing the address area name, followed by the name of the address itself which contains this address area, as well as address city. A similar description field was added in the 'Address' qualifications group (address name + city).

Delayed Company Context Update in Filter Dropdowns Across Screens

After switching the company in the GPB start screen, the filter dropdown values of vehicle/driver [groups] in Gantt-Screen (GS), Resource-Screen (RS), and Transport Orders/Leg-Screen (OS) may continue to display values from the previously selected company.

This behavior is primarily observed in TEST and PROD environments with multiple AOS servers, where each AOS instance maintains its own cache. This cache does not immediately reflect updates from other instances, causing a delay in propagating the new company context across all instances. This issue does not occur in DEV environments, as DEV typically operates with a single AOS instance, where cache updates are immediate.

A workaround is available using the "Reload Filter Contents" button. If outdated values appear in the dropdowns, users can manually reload the filter contents to refresh the data. If reloading does not work immediately, waiting briefly and retrying should allow the updated values to display correctly.

A long-term solution to enforce more consistent cache synchronization across multiple AOS instances is under evaluation and it is planned to be fixed in any next release (ID 103550).

Data migration task for 107681 (that was released already in 10.0-CAP42.0), but for Shipment builder V3.

Data migration job updates customer reference on existing shipment-based transport orders.

Previously, toll cost surcharge calculation (both when toll cost surcharges were created as additional tour costs and as tariff surcharges) considered only the first value returned by the map per each toll country, instead of the sum of all relevant toll legs. This was most obvious when the map would return multiple values >0 for the same country (separate values for separate legs).
This was fixed so that the toll cost surcharge per each country now sums up ALL the values returned by the map for that specific country.

In some rare constellations of data, Optimizer may not be able to return any plan due to this error 'The driver operating intervals must be disjoint.'. In such case, user should check again which resource is causing the issue and address it before trying to dispatch again via Optimizer.
In case this error is triggered, the Optimizer tourplan log now also contains an error line describing which main resource has caused this issue, to help user quickly identify the root cause of the process-stopping error (bad or corrupt data, or abnormal overlapping resource assignments).

The issue was especially noticeable on last tour stops, where capacity utilization bars were showing that there is still something loaded on the truck (while truck was empty).

Previously, when user would try to create a tour by selecting a TrLeg and drag&dropping it on GSR on a resource other than a motor vehicle (ex. trailer, driver), error 'Resource is not a motor vehicle' would be displayed. The process wrongly assumed that the resource on which the Transport leg is dropped is a motor vehicle, and this was now fixed.

Sometimes, a web browser window opened from some GS function (ex. 'Generate tour from default tour') would keep refreshing itself, confusing users and making it impossible to finish the action.

Previously, if user triggered the Conflict analysis on a selected tour (from tour context menu or from process button), and while the process was running (orange spinning wheel on lvl1 and lvl3), user selected another tour in the Gantt screen, the conflict analysis would stop, error 'Object reference not set to an instance of an object' displayed and the spinning orange wheel persist on initial tour until the next GS full refresh.
This was fixed so that, even if tour selection is changed, the Conflict analysis of the initial tour is finished and if needed, the conflict form is displayed.

Previously, when user would drag&drop a tour from one resource to another on the Gantt screen, sometimes the error: 'Cannot edit a record in Tour (CirtraTour). An update conflict occured due to another process deleting the record or changing one or more fields in the record.' would appear, and both the initial and the final resources would be removed from the tour header (confusing the user, who could even lose the tour visually).

In the GS filter form, when user selected multiple vehicle groups from the lookup, and then multiple vehicles from those vehicle groups from corresponding vehicle lookup, after pressing Ok, the Gantt form would show the selected values. But then, when re-opening the filter form, only the vehicles from the first selected vehicle group were still shown as 'selected' in the vehicle lookup (as if the lookup 'forgot' the other selection(s)).
A similar behavior was present when selecting from lookups a combination of driver groups and drivers.

Behavior was fixed, so that the Filter form now 'remembers' the initial filter combination on all lookups.

Previously, when a user would drag&drop a tour not only from one resource to another, but also to another point in time, the displayed result would sometimes show as if the tour did not move, unless a hard Gantt refresh was done, to view the actual change.
The visual update is now properly done, so that user can see the result of any move without having to refresh the whole Gantt.

Previously, selected/marked transport legs visualization got distorted after zooming in/out in the GPB Map.

Previously, when updating existing TMS tours by adding additional Transport legs via Optimizer dispatching, the visual update of tours on the Gantt screen was not done properly when triggered by the Optimizer update dialog. Tours in lvl 1 would not always 'move' or 'update' visually according to new start datetime.

We have noticed that the mobile app export periodic tasks might fail in some systems after installing 10.0-CAP44.0 release with new licenses. This doesn't happen always or in all systems, and seems to be related to a bug/glitch in D365 Recurring integrations framework (similar issues happened also last time when the certificate was renewed in CAP26 release).

As a pre-emptive measure it's recommended to recreate the jobs after installing 10.0-CAP44.0 and the new licenses, by following the instructions in chapter "Recreating the export jobs" of "CAPcargo Mobile apps - Setup instructions for customer systems" document (https://capcargo.sharepoint.com/:b:/g/ETRVn3bCRRZMnmXMWox9A30BL7OAIGq7xwcccz-Tn7KXNQ?e=Z6W2xg).

It's important to do this immediately after installing CAP44 release in production systems to minimize risk for interruptions in Driver app functionality.

CAPcargo IT team can handle it, but technically it can be done by any user with sufficient access rights and knowledge in the Data management module.

The cleanup batch for Mobile app instant messages (chat messages) did not work. It did not clean up anything. This has now been fixed.

The issue impacted only instant messages that were not related to any Mobile app tour. Messages related to Mobile app tours were cleaned up by Mobile app tour cleanup batch.

The Mobile app change tracking batch is responsible for creating and updating Mobile app tours based on changes in dispatching. We have improved handling of database deadlock situations which can sometimes occur when many processes are trying to update same records simultaneously.

Previously, even though the 'Determine cleaning type' action on tour correctly found a matching cleaning activity, the creation itself of the cleaning activity on tour would fail.

Cancelling the printout of self-billing vendor pro-forma invoice was previously causing unsupported data constellation of underlying subcontracting order (as the temporary pro-forma voucher id was not removed from the sub-contracting order). The issue was corrected and the pro-forma voucher id is removed from subcontracting orders if the process is cancelled.

Previously, when at least one of the addresses on the Transport Leg was not geocoded, or multiple lines of different transport units existed on underlying Transport order, when user attempted to do a Goods Management Partial delivery, an unusual error 'Error executing code: The field with ID '0' does not exist in table CIRTRALineTariffMap' was displayed, and partial delivery split was not possible.

The issue was only happening when tour start (or tour end) stop contained some transport orders.

When the stackability criteria on the Transport unit was set to 'Stackable' (see Transport type>Transport unit setup), two scenarios did not work properly (now fixed):
- when a transport unit conversion was setup only for " 'Stackable' = Yes", the creation of a new line on an existing Transport order resulted in planning quantities initialized with 0 values
- when a transport unit conversion was setup for both " 'Stackable' = Yes" AND " 'Stackable' = No", the creation of a new line on an existing Transport order resulted in planning quantities being initialized with values from the " 'Stackable'=No" conversion, instead of the " 'Stackable'= Yes" conversion.

Previously, the 'Unavailable from' and 'Unavailable till' fields on the Resource unavailability form were not mandatory.
This could lead to undesirable behavior (creation of 'forever' lines - no beginning, no end, or both), making them difficult to find, display and filter by.
The fields are now mandatory when creating a new resource unavailability. When future date is not yet clear, user can still add some general date, which can later be edited and re-posted.

Previously, when copying a transport order (that had some "Dangerous goods/ADR" specification), the copied orders was created with data issues. This was corrected, the copied order now does not inherit any "Dangerous goods/ADR" specification and user is informed via new infolog (that "Dangerous goods/ADR" data were not copied and have to be manually re-entered, if desired).