10.0-CAP53.0 (13.05.2026)

The issue was especially happening when source trade order was transported in several transport orders/tours - then the trade information (of transport order/tour) was showing trade order details unrelated to transport order/tour.

Previously, whenever user changed some measurement or weight component of a transport order line with associated packages, a dialog would always appear, asking for a user decision regarding taking the changes also to the packages.
Additional parameters have been introduced on the transport type to steer the promotion of measurements and weight changes to packages in case of changes at transport order line level:
- Ask user - dialog appears at every change (same as previously)
- No - no dialog shown to user, changes at transport order line level are not applied to packages
- Yes - no dialog shown to user, changes at transport order line level are applied to packages

Improvements on Work Instruction form:
- Field load/code is moved from tab General to field group Setup up to the header, next to the description
- Label "load code" is replaced with label "Load/Unload"
- Help label is improved so the user can have precise information that they are NOT creating WI per leg when opened from leg, but always just per TRO.

The issue was corrected, claim feedback registration on carrier portal is now possible regardless of worker (of claim order in D365).

In 'User management' screen, the 'View substitution contact' button is now enabled only if some contact person is specified for the customer (and transport type) assignment. As, for each customer/transport type assignment, it is possible to manage substitution contacts only when some main contact is specified.

When editing an existing order (that has transport type set to "Date initialization load/unload=Dynamic"), then loading/unloading day combinations (that are offered in the calendar picker) are newly reflecting the "Service (SLA)". Previously, the "Service (SLA)" was ignored in the calendar picker date calculation, which could lead to selection of invalid loading/unload date combination.

The issue was only happening when transport address was involved. After the address change was submitted to D365, only D365 location reference was updated (but not the transport address id reference). The issue was corrected.

Previously, it was possible to create only "non-transport" addresses via customer portal. This task introduces an enhancement - to create also "transport" addresses via portal.

Key point:
- new parameter "Auto create transport addresses" on customer account (in D365). If activated, CAPcargo transport addresses are automatically created (next to D365 locations). If deactivated, only D365 locations are created.

In companies (that have "Empties exchange" functionality activated in portal parameters), the "Empties exchange" flag appears in the dialogs for new address creation (and management of existing addresses), where users can activate the automatic empties exchange for the address.

Please note:
- if "Empties exchange" is set true during address creation (or editing), then the CAPcargo transport address is established automatically too (as the "Automatic exchange" flag is physically managed in CAPcargo transport address only).

Previously, in portal button configuration, it was only possible to specify exact names (eg. "Copy tr.order"). These were then shown directly 1:1 in the portal (in action button menu), with no possibility of translation to other languages.

This has been enhanced. Instead of specifying the exact button name, it is now possible to set up a reference to transport/portal module label file, which is then rendered on the portal (in action button menu), respecting the label translation.

The reference is set by using a leading character "@", which is followed by Portal ID reference.
So instead of "Copy tr.order" custom name, it is possible to specify for example "@copyOrder". The "copyOrder" then refers to portal module label file (to identify the exact label).

Please note:
- To be able to use transport labels dynamically in the portals, the label itself must be established for the portals (ie. it has to have "Portal ID" reference in the label manager specification). As both web portals only include (ie. "know") only the labels with "Portal ID" filled.

The feature has been implemented both on customer & carrier portal.

In address setup in D365, it is possible (via address format) to specify that for certain countries there should be no individual street number in the D365 (as street number is stored in the street name field directly). Previously, customer portal did not respect such country address format setup, and street number was still required/shown during address registration on the portal.

This has been now enhanced. Street number, if not activated in the country address format in D365, is not required/shown as individual field in the dialogs for new address registration on the portal, and users should specify the street number in the street name field instead.

Also the address connectors from google services were enhanced - if street number is not activated then street number (from google autocomplete response) for these countries is automatically appended to the street name.

Loading time of the transport order page was improved, via better utilization of the API calls (ie. transport type data entity).

Previously, all new attachments from both portals were registered in D365 via same document type (which was specified in portal parameters). This turned to be too rigid and was enhanced.

Portal users now have an option, to specify which document type shall be used, when attaching new documents on the portal. If no document type is selected when adding new attachment - then the default (from portal parameters) is still used as a fallback.

Please note:
- Document types (that should be used on the portals) have to be first activated in D365 (CAPcargo Transport -> Setup -> Web portal -> Portal document types), where new entry for every document type mapping has to be done (with custom document type & name texts, incl. translations).

Feature was introduced both to customer & carrier portal.

In certain specific edge case (ie. simulated only internally), the new address creation process on the portal actually recycled (and updated) some previously existing address in D365, instead of physically creating a new address.
The mechanism lies in the MS data entity "CustomerPostalAddresses" (which is used also for new address creation in the portal), which has some internal logic when create new address (and when to recycle/update the existing). The recycling/update mechanism was suppressed , by better structure of the payload (that is submitted by portal to data entity), without any change to the entity itself in D365.

(portal now allocates new number sequence for location id and includes it in the creation message; previously the location id was empty in the payload - which sometimes triggered the recycling/update mechanism).

Qualifications on Depot app activity (=transport order / package requested qualifications) now includes also Dangerous goods related qualifications.

Improve the "TAL Mobile app users" data entity to support importing Depot app user in a single go. Instead of first importing the user and then the depot(s) where the user works.

Truck loading app has been replaced by Depot app and can no longer be used.

In some constellation when users selected 'No details' visualization, then upon selection some tours length was extended up to the green bar end. On second selection, it got corrected (ie. shrinked). Now the tour is not changed when the user switch between details options.

GPB 'Transport orders /-legs" screen grid is now automatically refreshed after intermodal traffic feature is used and newly created transport legs are shown.

When multiple tours are selected and opened in map screen via button in 'Resource Dispatching' [Tour on map], the first tour stop selected from MS is now also selected in GSR. In lvl3, the tour (that contains the previously selected tour stop from map screen) is shown.

In the following data setup constellation:
Certificate valid from = date in the future (compared with system's today date)
Certificate valid to = blank field (forever valid in the future)
Transaction date = date in the future (compared with system's today date - ex. tour start date, on or after Certificate 'valid from' date)

Conflicts 250/255 (missing certificate for vehicle/driver) were previously wrongly displayed, even though the certificate was valid at the date of transaction.

The Carrying resource assignment form was displaying packages both on the left and right side (not assigned and assigned pane) with the same data for all planning quantities for each package as per Transport order line which could mislead the quantity per package.

For this, four additional columns were introduced on each side pane stating the total values of the TRO line (Total weight, Weight unit, Total volume, Volume unit).

Also the total planning quantities per package were proportionally split so it will give approximate value for the planned quantities assigned to the vehicle/compartment.

When complementing tours using the 'Generate/Update tour out of Route/Zone' (and the ‘Find and update existing tours’ set to True), then the legs (with and without time window assigned) which were added at a later stage were not added to an existing tour, but a new tour was created.
This is now fixed and 'Generate/Update tour out of Route/Zone' (with ‘Find and update existing tours’ set to True) now adds the legs to an existing tour (if corresponding tour already exists).

In GPB 'Transport orders /-legs' screen as well in GPB gantt screens (Orders fly-out tab), the NEM weight was displayed per container and not as a total NEM per Dangerous goods position.
This was fixed so that if multiple Dangerous goods are assigned to an Transport order line, the NEM weight now displays as a total per position.

"From Address-No" was not auto-populated on the "Change cross dock" window when called from header button and was displaying error and function was not executed. Issue is fixed, the Address field is pre-populated and change cross dock via header button works as expected.

'Tour status' filter field is now properly 'remembered' by GST Advanced filter even after form is filled, closed and re-opened.

If parameter "Carrying resource assignment on package level" in Transport type is enabled, so far only the packages were shown in the Carrying resource assignment form. From now on, if the parameter is enabled, also order lines without packages are shown and can be assigned to a resource.

Following enhancements were implemented:
GS lvl 3:
Waypoints automatically inserted in tours via Strategic tour routing rules have a new display
- smaller box, similar to driving breaks
- new icon
- name of city changed from vertical to horizontal display
Map:
- reduced size of tour ant-line on the map during mouse-over (same as regular ant-line, just different highlight color)
- while multiple tours are displayed on map, if user clicks on one of them, clicked tour is highlighted, while all other tour tracks are 50% faded (useful in case of overlapping tracks)
- the same icons introduced in GS lvl 3 for strategic waypoints/driving breaks/combined transport events are displayed on the map, both on the tour track pins, and in the mouse-over
- when such special icons occur on the tour track, the numbering of the tourstop is done as an upperscript to the icon itself (the numbering of the regular tourstops (load/unload/tour start/end) remains the same)
- the tour stops pin size is now connected to the 'Map pin size' parameter (same as already used for the transport legs pin size)

Multiple tour stops cannot be moved when GPB is set to 'sync' mode, as such activity is supported only in 'async' mode. The issue was that user was not properly informed about this limitation (as he/she was allowed to drop multiple tour stops into new sequence even in 'sync' mode, but the sequence was not actually updated). The visualization was improved- when now dragging multiple stops (and GPB is set to 'sync' mode), then the red circle cursor is shown where stops would be moved/dropped.

Dates of the legs were not shown when multiple pins were selected (with CTRL button). Now dates are pulled from the legs and displayed properly on the dialog of the selected pin(s).

Since breaks of multiple kinds (driving breaks, waiting due to changing Means of transport) are using the same 'dummy' Transport address (as set by parameterization), in TAL forms it is not so easy to identify the type of breaks (unlike GPB, where the visualization clearly expresses the purpose of the break tourstop).
Therefore, in both Tour confirmation and in Dispatch Light Tour lines forms, a new column 'Waiting type' was introduced, visible by default.

Several new vehicle/vehicle type icons have been introduced on the topic of rail.
Same functionality and display as existing icons (GPB, Depot app, TAL, Portal).

As part of our performance improvement project we streamlined the Transport event process to be faster. When a tour is released for departure, we don't anymore create two transport events per leg (one per point), instead just one event (for the load point). This change was implemented in CAP49 release.

This makes it twice as fast but can cause issues if a process depends on the "Tour released" event of the Unload point of the transport leg.

The event on the Load point of the transport leg can be used, but this event doesn't contain all necessary information about the unloading. This can cause problems for example when creating a notification message for the customer about an upcoming delivery, using the Status message framework.

To overcome these issues we have improved some existing "Status message calculated values" classes to better support the new situation:
- Destination city
- Destination name
- Destination street
- Destination street no
- Destination zip code

Additionally two new classes have been created to get the full formatted origin or destination address:
- Destination address
- Origin address

The fields “Fuel consumption with trailer” and “Electricity consumption with trailer” were removed from the tour header in order to simplify the handling of actual CO2 consumption values.
The CO2 calculation logic was adjusted accordingly to use a single actual consumption value for the entire tour, regardless of whether the tour was executed with truck-only or truck+trailer combinations.
Additionally, the help texts for the “Fuel consumption” and “Electricity consumption” fields were updated to clarify that these values represent actual total consumption for the whole tour and that values greater than 0 take precedence over default consumption values derived from vehicle, vehicle type, or route.
This change does not affect the same fields on vehicle or vehicle type level.

Many optimizations and improvements have been made in various dispatching processes. The improvements impact mainly GPB but also Dispatch light. Continuation to improvements that were shipped with the CAP49-CAP52 releases.

Improved processes include:
- Find fitting resources for a tour in GPB Resource screen (30% improvement compared to CAP52)
- GPB startup (loading of the GPB home screen, 50% improvement compared to CAP52)
- Conflict analyzer: performance of conflicts that analyze packages within one vehicle compartment (99% improvement of some constellations (from 10-20 minutes to a few seconds))
- Opening the Carrying resource assignment screen (30% improvement)
- Carrying resource assignment: real-time validations of co-loading restrictions (up to 85% improvement)
- Distance and time calculation - small optimizations (better handling of tour resources and truck attributes. Additionally in CAP52 we introduced new "Normal" mode for Distance and time calculation. This can improve the performance 20-40% if "Advanced" mode was previously used.

Disclaimer: the percentages are based on tests in CAPcargo test system. The percentages should be interpreted as rough indications of the relative improvement.
Note examples:
- 50% improvement means "twice as fast", e.g. originally 6 sec, new 3 sec.
- 75% improvement means "4 times as fast", e.g. originally 6 sec, new 1.5 sec.
- 16% improvement means " 1.2 times faster", e.g. originally 6 sec, new 5 sec.

Fixed a regression by which dangerous goods were not properly taken into consideration in the vehicle profile when building a PTV xDiMa request (in case of running sequence optimization with parameter 'Ignore HPRN' = True).

Some SCM status flags were previously visible in OS, but not defined on the Worker GPB filter initialization form.

Goods ready to load status:
- To be delivered by sender
Goods arrival status:
- To be picked up by receiver
- Ready for receiver pick-up

These are now added to corresponding section on Worker>CapCargo Transport>Filter Init Dispatching.
Values set on Worker in these fields are steering the values loaded by default for corresponding flags in OS.

Related resources are preloaded when resource collection is changed or when mode is changed (gantt mode or manual mode, selected tour is changed or manual date time is changed)

Additionally, for selected resources, a new button 'Refresh current' has been added to context menu (ie. right click) for refreshing the static data (static data includes qualifications and capacity) and related resources.
For the last selected resource (shown in detail), it will refresh also the image, cost and overview details.

Please note that 'Refresh current' button reloads only static data - meaning that dynamic data is not reloaded.

In order to be consistent with the data displayed in the CO2 calculation form, some adjustments were made in the input parameters tab when using Actual fuel/electricity stated on Tour. Namely, when using Actual input, we introduced background calculation in order to display the actual consumption for both fuel and electricity.
Also, in the CO2 calculation results both for tour and TRO, the Labels and Help texts for Fuel and Electricity consumption were adjusted to accurately reflect the results received for the CO2 calculation.

Improve performance of exporting Driver app tour data (through D365 Data Migration Framework).
- Overcome suboptimal behavior of Composite entity export in Data Migration Framework: the framework will process same records multiple times but now we prevented CAPcargo business logic from running multiple times for same records
- Grouped Load/Unload activity: don't try to fetch more than 1260 characters into Activity details because the result will anyway be cut after 1260 characters
- Smarter handling of qualification information

This was inadvertently broken in the previous release when enhancements related to driving breaks were deployed, so that even if Distance units expressed in miles were used, the numbers themselves were still shown in km.

Several enhancements were done to the combined transport tour stops introduced in previous release (see ADO 119687):
- 'sandglass' icon was replaced with a boat/rail icon (depending on what was returned by PTV, more user-intuitive)
- the tourstop box now contains additional information:
---- the name of the transport event (ex. VereinaTunnel, Gedser-Rostock)
---- ETA to the entry point of this transport event

- same icon is used also on the map (showing the entry point, not the whole segment covered by this transport event)
- same transport event name is used also in all other locations where it might appear (Dispatch Light Tour lines; Tour confirmation form; Driver app, Carrier Portal)

Fixed an issue in the airline view of the map for tours containing driver breaks or waits (sandglasses).

Previously, for tours containing driver breaks/waits tourstops, the airline connections on the Map were incorrectly routed to the dummy driver break address location, instead of using the actual geo-coordinates defined on the tour line.
The Map airline view now correctly uses the break/wait coordinates from the tour line, ensuring that the displayed route matches the actual tour flow shown in the road view.

Fixed an issue where CO2 calculation for tours with electric vehicles displayed the limitation “The electricity consumption must be specified for electric vehicles” when the DistanceTime calculation mode was set to Normal, even though all required electricity consumption data was correctly sent to PTV.

The limitation is no longer displayed when valid data is provided, ensuring consistent behavior between Normal and Simple DT calculation modes.

Certain processes involving a PTV request (HPRN creation, Optimizer dispatching and sequence optimization while using parameter 'Ignore HPRN' set to True) are now fixed. The complete vehicle profile is now correctly sent to PTV.

In previous release (see ADO 118940), the newly added tour header field 'Preconfigured settings' was correctly re-initialized when any changes to resource fields (add/change/remove resources) was done in Dispatch Light Tour.
The re-init process was now enhanced so that behavior of field (and consequently the result of using function 'Distance and time calculation with driver breaks') is consistent even when the changing of resources is done via GPB processes (drag&drop, etc.)

In certain scenarios, the logic steering the usage of a vehicle profile was different for the Distance/time calculation process (xRoute) vs Sequence optimization (xDima) when HPRN was not used ('Ignore HPRN' = true). Also, in case a trailer was found on the tour header, the vehicle profile used in the mentioned processes was misaligned.

These processes are now enhanced and aligned, so that for both processes the following sequence is applied:
- If a motor vehicle is assigned to the tour header, the vehicle profile is built from the vehicle type of that motor vehicle
- If there is no motor vehicle assigned to the tour, the vehicle profile is built from the vehicle type from corresponding tour header field
- If there is no motor vehicle assigned to the tour and no vehicle type on the corresponding tour header field, the vehicle profile is built from the vehicle type found on the tour's transport type

The terms about vehicles were aligned across the software:
Overall resources (machines, drivers, fork lifts etc) → Resources
General usage of vehicles → Vehicle / Fahrzeug
Specific usage of vehicles → Motor vehicle / Motorfahrzeug and Trailer / Anhänger

Due to the new MS license enforcement, the maintenance of contact master data of drivers is to be found in the CAPcargo tab of the CAPcargo driver form. Available with role 'T&L Resource Clerk D365'.

Following correction were done in 'Mileage history' form:
- Mileage history deletion (or new record creation) is not possible anymore in the 'Milage history' form directly (ie. buttons New and Delete were removed), as these actions are triggered only from the resource legs (ie. from tour confirmation).
- Edit option is available, but only for tours which are in status Confirmed. If tour is in status Done, then editing is not possible.

The functionality of tariff zone groups has been restored to D365 (as previously functional in AX2012).
Among improvements done are following:
- Menu item 'Zone groups' in Tariff - Conditioning and in Grouping was renamed to 'Tariff zone groups'.
- Within the actual form, labels and helptexts were enhanced with the new naming convention
- [Add] and [Delete] buttons were introduced on form. Selection of tariff zone is mandatory on any newly created line
- In Contract relation > Generate contract relations, the naming of values in the Departure/Destination zone type lookups was adjusted from 'Zone group' to 'Tariff zone group'. When 'Tariff zone group' is selected, new contract relations are created for the corresponding tariff zones included in such groups.

Previously, the actual tour header field holding the Optimizer tourplan id was only 10 characters long. When Optimizer tourplan number sequences generating tourplan id's were longer than 10 char, the id was not properly written to the actual tour header field, thus causing issues in the usage of GS lvl1 functions related to Optimizer.

Previously, Optimizer considered a qualification as provided by a resource (vehicle/driver) if it was setup at all, without considering any certificate validity that might be attached to respective qualification.
From now on, Optimizer considers a provided qualification as valid only insofar as there is a valid certificate setup on the qualification for the entire duration of the Optimizer planning horizon.
The validation is done using the same logic used for evaluating provided qualifications when these are setup with certificates in Conflict analysis (to determine whether conflicts 250/255 will be displayed or not).

Current limitation (for Optimizer and Conflict analysis): when more than 1 certificate exists for the same certificate type setup on a qualification, current logic will evaluate the validity of the qualification based on the certificate with the 'valid to' date farthest in the future. This means that the result may be wrong in certain constellations (certificate 1 is valid for transaction date, but certificate 2 already exists in the system with future validity). This will be fixed in a subsequent release.

When no certificate type is setup on qualification, Optimizer continues to consider the qualification as 'always' provided.

"Order deadline finding priorities" field group (in the main transport parameters, section "General" - "Transport order") is now available/shown only when customer portal license configuration is activated.

Previously, the section was shown even when customer portal was not activated (which was confusing, as the underlying functionality is provided only by customer portal configuration key).

In the automatic package creation process on transport orders, the following scenarios were not aligned with the manual package creation process:
- In case of disabled dimensions/weight parameters on transport type: measurement/weight/volume units initialized on packages were taken from General parameters and Volume unit from System unit, instead of Package Management parameters
- In case of enabled dimensions/weight parameters on transport type: measurement/weight units initialized on packages were correctly taken from transport order line, while the volume init was taken from System unit, instead of Package Management parameters

Previously, when transport orders containing a value in the header 'Temperature' field <> None (based on controlling transport type parameter value for this field) were selected on the main transport order grid, the 'Temperature' field column was automatically toggled from 'not visible' to 'visible', based on line selection.
For performance reasons, this column is now hidden by default. When added to the standard view, it is always displayed, even when lines selected in grid do not have this field enabled.
Field can be edited in the grid depending on the default value of corresponding transport type parameter.

Previously, the 'Driver home' option was not available in Address type lookup if the Optimizer config key was switched off. The 'Driver home' option is now available directly under the general config key.

It is not possible to change the Plan ID anymore by simply editing the field, as it is a key field, causing orphaned records if changed.
Change of the resource combination plan ID is still possible via the record info rename function which ensures data Integrity of related records.

The collection address dropdown list on the purchase order line showed all addresses. This is fixed by only showing the vendor related addresses.

Synchronization of a transport order containing partial deliveries failed if any of the deliveries had already been confirmed when another delivery attempted to update the transport order with warehouse data.

Default (ie. pre-created) filters are removed from the shipment line creation periodic functions, offering more flexibility for the users in the configuration of these functions.

The Trade order field of the Order controlling form was migrated to shipment builder version 3.

Mixing multiple non-WHS trade order line related shipment lines in the same transport order line led to issues in filling the confirmed inventory quantity field of the shipment line. This caused problems on the Goods management form and at packing slip posting.
In order to avoid this issue, the non-WHS trade order lines are always in a separate transport order line (like activating the Group per trade order line parameter on the shipment building group).

Wrong packing slip id was added to the shipment line in case the packing slip was posted for the same sales line multiple times.

In certain cases, at the end of the remove from transportation process, incorrect feedback was given to the user. The functionality worked/works as expected but the info message was misleading.

The general TALshiShipmentQtyConverter.run error message is improved with more information about the exact trade order line and the missing information (e.g. inventory quantity is 0, inventory unit is missing, item number is missing, transport type is missing, transport unit is missing, transport quantity is 0).

For certain part delivery cases, at packing slip posting from the CAPcargo tour, the packing slip id was not added to the CAPcargo shipment line.

When the 'Remove not picked shipment line' function removed an entire transport leg from the tour that was already released to warehouse but with no work started, then it did an additional load line split with the entire quantity of the load line. By this, leaving 0 quantity on the initial load line. This is fixed by not doing the additional load line split.

Previously, directly on the trade order line, the system validated whether the unload date is earlier than the load date. This gave the user immediate feedback. Since this validation interfered with date changes in certain intercompany direct delivery scenarios, it has been moved. From this CAPcargo version, if the trade order line is not in transportation, then the date validation only happens at transport order creation. However, if the trade order line is already in transportation, then the validation happens on the fly at date changes (same as initial logic).

So called "Managed configurations" can be used to distribute the Depot app profile files to company devices. The configuration file itself is a pre-existing feature, but until now it worked only by placing a JSON file in a subfolder in the app's installation folder. This kind of file management is always not possible, therefore support for Managed configurations was added.
Please refer to the documentation of your mobile device management solution to learn how to utilize this feature.

See document "CAPcargo Mobile apps - Setup scanners for barcode scanning" for more information about the format of the profile file.

When more than one trailer were assigned to the tour, following processes failed in GPB:
- manual removal of main trailer via lvl 2 context menu (which would automatically trigger the removal of the additional trailer)
- moving the tour from one vehicle to another on the Resource Dispatching screen.

The distance & time values (distance too currently selected tour) shown on resources were not calculated correctly, instead all resources displayed zero values.

This happened when drivers were listed in multiple resource groups.
Now it is possible to un-select drivers from Resource screen drag&drop combinations with motor vehicles while holding down CTRL key.