10.0-CAP52.0 (18.03.2026)

This was fixed, so that the transport order grid jumps now to the last record in the list after clearing any existing filter.

Previously, it was not possible to import the DepartmentID field with transport orders.
This field is now added to the TAL Transport order header import entity.

The issue was happing due to wrong dropdown code validation, when setting up certain 'Criteria relation' combinations.

Previously, when transport quantity was reduced on the transport order line, the excessive packages were not removed (but user was only warned). Newly, system can automatically remove such excessive packages, after reducing the transport qty.

Key point:
- Mechanism has to be activated via "Remove package(s) at transport qty reduction" parameter on the transport type. This can be activated only when "Automatic package creation" is activated.

When this feature (sender delivery/receiver pickup transport legs) was introduced, by definition the load/unload address on the transport order could not be changed (manually via transport order grid function or by EDI import update). The blocking mechanism for changing load/unload address was inadvertently extended to the changing of load/unload dates.
This was corrected, so that even on orders with sender delivery/receiver pickup legs, load/unload date change is now possible both manually (transport order grid function) or via EDI import update.

Previously it could happen that during order creation user could select even "Service (SLA)" that was not valid for the customer account (or transport type) of the transport order. This was improved and user now can select only from "Service (SLA)" that are valid for the transport order.

Translation of the "Container type" is respected in D365 and also on the customer portal.

The Empties handling was enhanced by introducing new fields for empties per transport unit. In this way, the user can affect not just the total amount of empties on transport order, but even directly the per unit empties.
Also, a new grouping for Total weight was introduced, for quicker visualization of weight totals, not just at per unit level.
Both of these enhancements can be toggled on/off via specific parameterization under Transport type > Order management > Order entry.

Previously, the 'dynamic' unload date (based on Transport type setting) was wrongly calculated when a criteria set on the crossdock rule/split sequence was configured at the 'group' level. This affected several criteria types: SLA, Load address, Transport type, Customer, Delivery terms.

The 'City' determination algorithm could fail during validation, depending on the sequence of zip code records (in D365). The issue was corrected and sequence of zipcode records doesn't matter anymore.

Saving of changed address did not fail, but after screen reload - the old address was still shown.

Via "Overwrite found address details" option, it is possible to adjust address detail, during address creation on the portal. The issue was that most of the address details fields were not enabled for user changes. The issue was corrected.

This was done so that users are aware which addresses are transport addresses, when transforming "private" addresses into "public (approved)" addresses, during new order creation.

Additionally, new validation was introduced to dynamic calendar picker (to ensure that users cannot select load date that is earlier than today).

Previously, the price calculation details were shown just on the main screen, without possibility to close/go back.

Additionally, the surcharge sections (in price calculation details) are now dynamic - are only shown if order has some surcharges.

The issue was happening when plan unit (for weight) was configured on different position (than position 2).

When transport type has "Date initialization load/unload" set to "Dynamic", then during order creation on the portal, users can only select allowed load/unload date combinations via calendar dropdown. Previous performance was a bit lacking and was therefore improved. Newly, the calendar dropdown loads combinations only for predefined amount of days, and after scrolling to next month only when user selects the date. The effective date selection (ie. writing the dates back to order creation dialog) was thus reworked - and is happening now only after clicking on dedicated "Confirm" button.

The issue was only happening in certain data configuration - where no number value was provided by D365 (eg, from conversion, for planning quantity determination) and portal didn't handle such constellation correctly.
('NaN' = 'not a number')

Time windows were added to following places:
- new order creation dialog
- side details pane (for editing of existing order)

So it is now clear, in which D365 company is the customer account of the contacts.

Previously, some date (and time) fields on the customer portal were not respecting the 'Date, time, and number format' configuration of the portal user. So, for example, dates were shown in 'en-US' format even though the configuration of the portal user was set to use the 'de-CH' format.

Previously, all transport units were shown in the transport unit dropdown (ie. regardless of customer account validity), which could cause order creation to fail - as invalid transport unit could have been selected. The transport unit dropdown has been enhanced, to show only valid transport units.
Additionally, transport unit description (and translation) has been added to order creation dialog, and also to side details pane (ie. when editing an order).

Issue was happening only when transport type 'Date initialization load/unload' was set to 'Dynamic'.

Search for a specific activity in the list. The search sees the text that is already visible in the activity cards on this screen such as barcode.

The search doesn't cover the additional information that is displayed in the activity details screen when clicking an activity. This is because the search runs locally in the app (offering fast performance), and the additional information is not known to the app until the user clicks a specific activity and that activity is fetched from D365.

If the user attempts to load or unload goods but doesn't succeed (for example: qualifications not fulfilled) the activity gets a red "x" icon. The failed items can be filtered by the filter in the top right corner of the screen. The icon is cleared once the issue is solved and the loading or unloading succeeds.

New "Info" feature, available through own icon on the home screen. The user can scan any barcode and get information about the item or object.

The generic truck and trailer icons in Loading and Unloading processes have been replaced with vehicle type icons from D365.

Working in conjunction with the new features added with 119876, when using Depot app to confirm load/unload of orders/packages, two new features have been implemented:
- 'Automatically confirm tour start/end activity' - new instruction activity rule, which, when enabled, confirms the tour start/end activity as soon as all the packages have been confirmed via Depot app on corresponding tour stops. Rule sets the value of corresponding flag found on tour line details. Flag can be toggled True/False from 'Address' lvl3 flyout tab in GS.
- 'Distance/time confirmed' flag in tour line confirmation is set as soon as any package is confirmed via Depot app on the next tour line (unless already set by other process, for example: manually of via Driver app).

This ensures that all tourlines, when properly setup, are fully confirmed even when load/unload is only processed via Depot app (no further manual intervention).

New features added in conjunction with usage of the Depot app:
- 'Remove not loaded orders' function, previously available in GPB under Dispatching>Dispatch grouping, has been moved under Tour confirmation > Functions and also split into 'Remove not loaded orders (Tour)' and 'Remove not loaded orders (Tour line)'.
A new flag was also added to the mobile app user to enable/disable this 'Remove not loaded orders' function in the Depot app. When enabled, a new action button becomes available in the Depot app tour loading, removing all not-yet-confirmed orders/packages (added to new Transport leg) from current tour.
- 'Automatic departure confirmation' - new instruction activity rule, which, when enabled, sets the 'Departed' flag on the tour line to True as soon as all packages/orders have been confirmed via Depot app (load/unload). Rule sets the value of corresponding flag found on tour line details. Flag can be toggled True/False from 'Address' lvl3 flyout tab in GS.

Previously, the filter field in the Vehicle type form was filtering records in the vehicle tab of the vehicle type form, instead of vehicle type records.

The issue was only happening when tour stops were in different time zones (than UTC) and was caused by not applying the time zone recalculation for filter determination.

Previously, when the Blocked column was not included in the grid, refreshing the grid caused blocked transport legs to lose their red color and appear black. The correct red color was only restored when using the Refresh current option.
Now, blocked legs retain their red color correctly after a full grid refresh, even if the Blocked column is not visible in the grid.

Previously, the deadline time in the subcontracting request tooltip on GPB gantt screens (level 1) did not respect the user’s preferred time zone, resulting in incorrect times being displayed.
Now the tooltip correctly shows the deadline time according to the user’s preferred time zone.

Even though the infolog correctly said 'kilometers', the number displayed for the distance in the toll cost calculation infolog was the equivalent of meters.

Previously, it was not possible to move (by using Drag&drop from GS lvl 2) a tour's additional driver to another tour. This is now improved, so that, when the move is made, if the receiving tour had no previous driver, the newly added driver becomes the main driver; otherwise it is assigned as additional driver.

In GPB gantt screens, it could happen that tours/resource assignments with a manual ETA could disappear when scrolling horizontally the viewport. The previously added fields on Tour and Resource Assignment headers, used for filtering, now also include manual ETA in their calculation, ensuring correct min start and max end values in the filter datetime fields in the headers.

Data migration jobs need to be run to correct the filter fields in Tour and Resource Assignment tables:
- Recalculate start/end datetime filter fields in Tour table (including manual ETA)
- Recalculate start/end datetime filter fields in Resource Assignment table (including manual ETA)

Previously, on tours for which the Scheduler had not been run, when Backward calculate tour start (on a tour stop) was triggered, the popup window in GPB showed empty dates. Now, for these tours, the process first runs the scheduling ensuring the dates are correctly initialized.

When using the 'GPB - Resource dispatching' menu item from the transport order grid (to show the resource assignment/s), the GPB 'Resource Dispatching' screen opened and displayed the resource assignment in both Level 1 and Level 3. However, the resource assignment was not automatically selected, and all 'Resource Dispatching' menu items remained disabled. Users had to click on the Level 1 manually to select it and enable the menu items.
Now resource assignments shown via 'GPB - Resource dispatching' button are automatically selected in gantt grid, and all relevant menu items are immediately available, eliminating the need for an extra click.

Fixed an issue where CO2 results were incorrectly distributed across tour legs. Identical legs (same load/unload and weight) could receive different CO2 values, while total tour CO2 remained correct. CO2 calculation per leg is now consistent, ensuring identical legs return identical results.

Fixed an issue where the emission class was incorrectly taken from Vehicle Type (fleet) instead of the selected Vehicle when using vehicle-based consumption data. The correct emission data source is now consistently applied in CO₂ calculation requests to PTV.

Emission class values are now displayed in the Vehicle form (CO2 tab), CO2 calculation form, and included in the data entity. This ensures full transparency of input and output values used in the calculation.

Previously, if planning legs in an existing tour failed (dragging and dropping a leg from OS to Level 1 GST), the error message was not shown in GPB.

Now, if the drop is allowed, the error messages are correctly displayed when planning legs fails, ensuring users receive feedback in GPB.

When Transport type parameter 'Carrying resource assignment on package level' was set to Yes, and some carrying resource assignments were done (either in preplanning stage or via Depot app while loading), the 'Remove not loaded orders' action either removed or un-assigned the carrying resource assignment.

Previously, the 'Auto assign carrying resource' function did not properly assign packages to carrying resources, even though the infolog confirmed the action.

When launching a web browser (D365 form) from GPB the browser displayed "An unexpected client error has occurred", instead of navigating to the expected form.
This issue started happening in all CAPcargo versions after Microsoft changed something in the standard D365 solution. Therefore this fix is published for all still supported CAPcargo versions.

The error is now enhanced, so that user clearly understands that process failed and tour was not created.

This column is now pre-calculated for transport legs during pre-dispatching and other processes that create or merge transport legs. The pre-calculation is done if new GPB parameter "Show work instruction indicator in OS grid" is enabled.
A data migration job will automatically enable this parameter and calculate the work instruction column for all not yet confirmed transport legs, if this field is present in any GPB OS column template.

If user tries to sign-in with a user who does not have the minimum role needed for GPB (T&L Dispatcher), then the app displays a message and does not crash anymore. User is nicely informed that she/he is not authorized to access the application.

In general, the qualification criteria can be specified for example in the way that qualification shall be fulfilled by truck OR trailer. When just truck (with fitting qualification) was assigned to a tour, but no trailer was planned, then such qualification request was previously never fulfilled (as no trailer provided it).
Newly, the "OR" condition is evaluated only when there exists a qualification provider that could fulfil it.

A new field ('Preconfigured settings') was added to the tour header. This is initialized with the preconfigured setting coming from Vehicle / Vehicle type / Transport type on tour.
If initialized value is = None, then field is disabled for further changes.
If initialized value is <> None, field value can be changed to another value, except for None, which will then be considered for the next Distance and time calculation with driver breaks for the tour.

The 'Insert driver breaks' flag, previously introduced only as part of the 'Calculate tour duration' Transport type process button, has now been added also to:
- processes 'Release to depot' and 'Release for departure' (as dependent on the 'Distance and time calculation' flag)
- periodical function CAPcargo Transport > Periodic > Dispatching > Distance and time calculation

Track & trace event status message (for released tour) was previously created even after "Set tour status back to "Released"" was performed. Such behavior was suppressed.

Previously, the checkboxes on the Resources screen grid were positioned to the right of the labels, which was inconsistent with the left-side placement on other screens (Orders, Gantt).

When the driver breaks feature was first introduced (see 110588), one of the described limitations was that parameterization with working time between breaks did not take into consideration the time spent at various tour stops (for example, loading/unloading), which could potentially lead to wrong break scheduling in some constellations.
The service time (sum of all activity durations) on each tourstop is now added to the xRoute request for the distance and time calculation with driver breaks, thus correcting the initial limitation.

CO2 calculation is now validated against missing fuel consumption data.
If no data is available from Tour, Route, Vehicle, or Vehicle Type, the calculation is aborted and an error message is shown instead of generating an empty result.

Fixed an issue where dangerous goods (ADR) were evaluated using incorrect values, leading to inconsistent routing behavior depending on tour structure. ADR data is now correctly applied based on the transported load between stops, ensuring consistent inclusion of hazardous goods in route requests and accurate routing results.

Automatic screen refresh was not performed after GPB generic buttons were used, even though the screen refresh was configured (via "Refresh type").

Two issues fixed with this task:
1. Show/Hide activities (far right in the filter group in GPB gantt screens) – Previously when selected to Hide activities, the activities in lvl2 were hidden, but only half bar.
This is now fixed and if we select to hide activities, it will hide the whole bar in lvl2.
2. Previously when we selected level of details “No details” and “Bar extensions”, the tours that had early/late arrival (green/red extension bars on tour), some of the red/green bars were not hidden, tour lengths were changed when selected, and part of the red/green bar is visible in the grid background.
This is now fixed and the tours that have early/late arrival (green/red extension bars on tour) are properly displayed when we select level of details “No details” and “Bar extensions”.

Previously the text/label was always translated on client side (GPB). Now it can accept translated text. This is also useful if using CUS labels for generic button.

Previously transport events were created and stored in the system even if the corresponding Track and Trace status was not enabled (Active). This caused performance overhead and unnecessary data accumulation.
Now the transport event data is created only for active Track and Trace statuses.
Additionally a cleanup batch will be introduced in 119095.

The issue was encountered when conflict 500 address opening hours was active and the tour contained such conflict. Tour release was not possible because of this error when conflict analysis was configured as part of the tour release process.

To be consistent with the naming of other process button and the title of the browser window which opened when pressing this button, its label was changed from 'Confirm & finalize tour' to 'Tour execution (Trade)'.

Resolved an issue in GPB 'Transport orders /-legs' grid where filtering on 'Reservation status' field (from a related table) returned incorrect results and distinct values in the intelligent filter for this column when paging was active.

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-CAP51 releases.

Improved processes include:
- Filtering tours in GPB 'Resource dispatching' screen (50-60% improvement compared to CAP51)
- Filtering tours in GPB 'Tour dispatching' screen (Improvements and optimizations)
- Selecting tours in GPB 'Tour dispatching' and GPB 'Resource dispatching' screens (The details of all visible tours are now fetched in the background, often resulting in immediate data loading when selecting a tour)
- Filtering transport legs in GPB 'Transport orders / legs' screen (50% performance improvement compared to CAP51)
- Adding resources to tour (10-15% improvement compared to CAP51)
- Sending transport legs to Optimizer: waiting time until the Optimizer dialog opens (Up to 300% improvement compared to CAP51)
- Time&distance calculation (Improvements and optimizations)
- Generate tour out of route/zone (batch) (Improvements and optimizations)

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.

More improvements will be introduced in upcoming releases.

If "Has work instructions" field is used in GPB OS (exists in any GPB OS column template), this job will make updates that are necessary for displaying correct data in the Order screen.
- Enable new GPB parameter "Show work instruction indicator in OS"
- Calculate new "Has work instructions" field for all not-yet-confirmed transport legs in the system

Fixed an issue where the Y-axis in the GPB 'Tour Dispatching' screen was incorrectly positioned when opening a tour from D365. The layout is now properly aligned, ensuring correct display of tours and resources.

The columns "Danger label" and "Classification code" are added in the Orders flyout tab in the GPB gantt screens. This information is needed for dispatching process and can be easily viewed in the tab.

Remove CAPcargo logic for "Buffer changed by another process" which interrupted many dispatching processed in GPB. The logic was analyzed, and deemed unnecessary in most situations so we removed it from almost all processes. Most of the removal was done in CAP52 release but some parts still remained and have been removed now.

Previously, "Work instruction" button in OS was showing all work instructions of the order, now the button displays only the work instructions associated with the specific transport leg.

The issue was encountered at least via following steps:
- Transport leg with two order lines. Confirm unloading one of the order lines (transport leg status was already set "Confirmed")
- Transport leg with one order line. Confirm the unloading, then undo confirmation (transport leg status was still set "Confirmed")

Previously, on OS startup, the grid ignored sorting during initial load. As a result, when scrolling to the next page, orders that originally belonged to page 2 could appear again on page 1, causing duplicates.
Sorting is now applied correctly after the control finishes loading, ensuring that orders appear on the correct pages and duplicates are prevented.

Previously, the Work instruction icon on transport legs grid was not always refreshed after inserting or removing a cross-dock. Now, the Work instruction icon updates correctly after inserting or removing a cross-dock, ensuring accurate display for all legs.

Fixed an issue where Simple and Advanced tour modes displayed incorrect (00:00) time values between certain tour stops despite valid distances. Distance and time calculation is now consistent across all modes, ensuring accurate duration values for all tour stops.

Fixed regression from performance improvements in CAP50. Carrying resource assignment - Loaded here checkbox throws an error "Illegal types in operation on {} and {}."

The 'Address type' dropdown was missing in the 'Insert tour stop' window due to a regression from CAP51.
The 'Address type' dropdown has now been reintroduced in the 'Insert tour stop' window.

In some constellations a load/unload activity would get confirmed if the driver scanned an unknown barcode.

Driver app application code has been refactored with the goal of better stability and maintainability and easier implementation of new features. Because of these big changes Driver app CAP52 is first released to a private preview with selected customers. General availability will follow later.

Additional safety mechanism has been implemented to secure the middleware APIs from unauthorized users. Because of this change, older Driver app versions than CAP52 can't connect to the CAP52 middleware. Using Driver app with higher middleware versions than the app version is not supported and has not been supported in the past.

CAP52 Driver app works with older still supported middleware versions.

Note: this feature can't and won't be enabled on middlewares where CAPcargo Truck loading app is still used, because the old Truck loading app must still be able to communicate with CAP52 middleware.

The inquiry menu in the tour details screen now contain only unplanned empties that the driver registered. Planned empties are shown in the activities of the tour stops.

When "One load/unload per tour stop" feature is used, the driver will have "grouped" load/unload activities that represent all the goods that must be loaded/unloaded on a tour stop.
Until now those grouped activities could only be confirmed by swiping. Now it's also possible to scan a package barcode to confirm that activity. For example if the grouped load / unload activity represents 50 packages that must be loaded / unloaded on the tour stop, the driver can scan any one of them to confirm the activity.

Additionally the "Must scan package barcode" feature now impacts also the grouped load / unload activities. But only if new Mobile app parameter "Respect 'Barcode scan required (package)' for grouped activities" is enabled. This parameter was introduced to prevent changing the behavior of existing systems and their setup when installing CAP52 release.

The field 'Mode tour distance/time calculation' (Transport parameters > Geo services) has now a new enum value 'Normal'. Purpose of this new value is to replace both existing values 'Simple' and 'Advanced', as the more complete/flexible alternative.

With one exception (multiple vehicles using different speed profiles are defined on the same tour), in this 'Normal' mode only one request is sent to PTV instead of multiple requests (as was the case with the 'Advanced' mode), which can lead to significant performance gains in Distance and time calculation noticeable in tours with many tourstops.

It is highly recommended to switch as soon as possible to this new mode.
The 'Simple' and 'Advanced' modes will be supported only until CAP53.
For deprecation details, see also the feature deprecation list.

A new global parameter 'Time consideration' has been added in Transport parameters > Geo services, to control how time-dependent restrictions and conditions are evaluated during time and distance calculation, with several options:
- time not considered (fastest, calculation ignores all time-dependent effects)
- snapshot time (use the tour start as single time reference to be used for the entire calculation)
- exact time (most precise, but potentially slower; fully respecting exact time per each driving segment)
Routing requests are now dynamically adjusted based on the selected option.

Previously, on certain routes, which contained a change of the means of transport:
(examples:
- road - rail - road (Lötschberg tunnel in Switzerland)
- road - ship - road (Calais-Dover crossing of the English channel)),
the driving time and distance could not be properly calculated and displayed between the tourstops.
To reflect such change of the means of transport in the map response, a new tourstop was introduced ('sandglass' icon), geo-coordinated at the start of that special route segment. The average duration returned by the map for that particular segment on a different means of transport is defined as a Waiting activity on this tourstop. The TMS address placeholder for this new tourstop is the same dummy address setup for driver breaks.
In the scenarios where such tourstop appears on the route, it is displayed after the calculation of time and distance (with or without driver breaks).

Limitation: this new tourstop is not automatically displayed on tours generated from Optimizer for such special routes, even though the distance and time calculated includes the change in the means of transport.

The field "Parent" was previously set as 'view only' in the data entity 'TALCommodityTable'. Field has been newly opened for editing, also via data entities.

Field 'Timetable linked' is now deprecated and no longer visible on form 'Means of transport type'. The functionality of that field is now replaced by the logic that any Means of transport other than Road will behave as if it is timetable linked (excluded from tour scheduling and geo services).

One of the limitations described in release CAP51 in 119862 (Enhance Optimizer parameterization of driver breaks) is now fixed in this task. When more than one break (driving break or daily rest) occurs consecutively between two regular tourstops (ex. long FTL tours), the distance is now linearly split between breaks.

Together with the deprecation of 'Timetable linked' field from Means of transport type (see 119076), transport legs validation algorithm in Optimizer had to be enhanced to only allow processing of legs with a predefined Means of transport = Road. Legs with unknown means of transport (blank) will be considered in the same way as those set for 'Road'.

Previously, when all queried resources for Optimizer dispatching were unavailable, the process correctly stopped, but the status of the resulting tourplan remained 'Calculating'.
In this scenario, it is now correctly set to 'Error', pointing user to the log for more explanations.

Previously, the tour start/end fields on resource combination plan lines were always initialized as 'None' when line was first created.
A new logic was introduced, so that:
- if the vehicle added to a resource combination plan line has the tour start (or end, or both) <> None (setup on vehicle itself), then the resource combination plan line fields are also initialized with the values from vehicle
- if the trailer added to a resource combination plan line has the tour start (or end, or both) <> None (setup on trailer itself) AND no initialization of the resource combination plan line tour start/end fields was already done from the vehicle, then the resource combination plan line fields are also initialized with the values from trailer
- no initialization of these fields is done from additional trailer or drivers

It is now possible to add multiple lines at once to a resource combination plan. The new button opens up a form where user can filter vehicles by depot, introduce a 'Valid from/to' interval for all newly created lines, as well as allow the initialization of additional resources already defined in a fixed combination with the selected vehicles.

All pre-existing validations still apply (for example, no overlapping validity periods).

It is now possible to create a copy of a selected resource combination plan by just providing another unique ID and the number of days by which to offset the dates on the newly created resource combination plan.

On a TMS tour generated from an Optimizer tourplan, 'Wait' activities might be inserted automatically to match the Optimizer tour (for example, early arrival at a tourstop where customer wish time for load/unload has to be respected).
When removing driver breaks (using the corresponding menuitem or directly 'Distance and time calculation with driver breaks'), these Optimizer-generated 'Wait' activities are removed at the same time with the breaks (if any), to avoid a potentially distorted view of the tour due to such activities while the breaks have been removed. The user is then responsible to make sure that customer wish is still respected and planned for.

In the 'Means of transport type' form, it was previously possible to create lines with 'Means of transport' = None. The creation of such means of transport is however meaningless, and validation was added to the line to prevent this.

This was previously missing from the Sequence optimization tab in Transport parameters, thus making it impossible for user to control the default behavior when sequence optimization was triggered.

In certain constellations (combination of running batches and manual intervention on imported records), it was possible to create more than one transport order from the same checked imported order record.
This has been improved for checked imported orders of all types (create/update/cancel).

This issue is not related to CAPcargo solution, but it's documented here for general awareness.

When updating or creating contact details (email, phone...) on All customers form, the system starts creating "Customer hierarchy" even though it should not.

- If number sequence for "Customer hierarchy ID" (Retail and Commerce - Headquarters setup - Parameters - Commerce shared parameters) has not been set up, error message "Wrong use of function" is shown on the screen. The changes to the contact information are saved so this is just a cosmetic issue.
- If number sequence for "Customer hierarchy" has been set up (the number sequence is part of that feature), the system consumes number(s) from that sequence, even though no new customer hierarchy is created.
CAPcargo has reported the issue to Microsoft.
A workaround to get rid of the error message is to set up the number sequence for "Customer hierarchy ID".

Update 02.04.2026: Microsoft has indicated that the issue has been fixed as 1102353 in a quality update for 10.0.47, build number 10.0.2527.43.

Objects that were deprecated in release CAP48 have now been permanently removed from CAPcargo codebase.
These objects were documented in "CAP_Transport_And_Logistics_Changes_in_public_APIs.xlsx" that is shipped with each CAPcargo release.

This is a regular periodic 'cleaning' task, to remove previously announced deprecated features.
For further information please refer to CAPcargo lifecycle support documentation.

Data migration task for 120029.

Data migration task recalculate start/end datetime filter fields in Tour table (including manual ETA).

Data migration task for 120029.

Data migration task recalculates start/end datetime filter fields in Resource Assignment table (including manual ETA).

In this new grouping, the following parameters were added:
- 'Automatic package creation' (moved from previous location under the Transport type Dispatching tab)
- 'Remove package(s) at transport qty reduction' (newly introduced in CAP52 - see notes for 119462)

Data migration task for 120383.

Since the Yes/No parameter of the backward synchronization is replaced by a 3 option parameter (None/Synchronous/Asynchronous), a data migration job is delivered to set the new parameter based on the old one.

Shared package functionality did not work on transport order line level if shipment building parameter group by commodity or address area or trade order line was activated.

The "Create packing slip button" in GPB Gantt screens, used in CAPcargo Shipment builder, was broken in a regression that was introduced in CAP51 release.

Synchronous backward synchronization to update the transport load and unload date and time and transport lifecycle status on the trade order line has a negative impact on performance if a lot of records have to be updated at the same time. Therefore, an alternative, asynchronous approach is introduced that operates with a new periodic function.
Furthermore, a new button is added to the trade order to update the transport load and unload date and time and transport lifecycle status fields. This way the user can immediately see the latest information even when asynchronous mode is used.

Updating transfer order lines from header has previously always thrown an error. A temporary fix is introduced that uses 2 dialogs. In order to update the fields on the transfer order line, on the first standard D365 dialog, all fields must be set to No, and on the second CAPcargo dialog, the parameters that are related to the fields that must be updated have to be set to Yes.

From this release, the Remove from transportation trade order line feature also handles not warehouse management enabled order lines. If a non-WHS order line is split into multiple deliveries then the part deliveries (shipment lines) that could be manually deleted via the Adjust shipment form - because both hard (e.g. transport confirmation) and soft (e.g. transport type parameter) criteria allow it - can be removed via the Remove from transportation button.
The new logic is driven by a new parameter in the Trade&Distribution parameters form.

If a transport originates from trade module (sales/purchase/transfer order), the calculated CO2e emissions are split back to the trade orders considering the entire supply chain of the goods.

Due to a technical limitation in the shipment line creation periodic functions, they had to be split into WHS and non-WHS functions. When this CAPcargo version is installed, it is recommended to replace the shipment line creation batches with the new periodic functions.