10.0-CAP54.0 (08.07.2026)

A new Resource Unavailability tab has been introduced in Resource Screen (RS) to provide detailed information about planned resource unavailability. The tab displays absences and assignments sorted by start date/time, with support for configurable absence colors and automatic text color adjustment for better readability. Data is loaded only when the tab is opened, and already loaded information is reused to avoid unnecessary reloads when the RS context remains unchanged. The tab visibility is automatically adjusted based on the resource availability status and whether dynamic data has been calculated.

Previously, for any driving breaks/combined transport tour lines, the tour report displayed the 'dummy' transport address used to parameterize these kind of tourstops.
Now, the report is aligned with Driver app and GPB to display the actual type of tour stop (driving break, name of ship/rail combined transport to be used).

During order creation, in dynamic load/unload data determination (ie. when "Date initialization load/unload" is set to dynamic, in transport type), the "Next options" button now loads the first available date combinations even for the current empty month (ie. when user scrolls into next month, then returns to current month, which is (after such month change) rendered as empty).
Previously, user had to click onto exact date (to get the available date combinations), now it is enough if user just presses "Next options".

Invoice account change on sales order, purchase order, direct delivery is allowed, if it does not lead to a different transport customer on the transport order. Same behavior as in earlier version of shipment builder.
This improvement is only applied on Shipment builder version 3 (Unified global data model).

A new 'Release to Warehouse – Transport Leg' periodic function has been introduced. This function could already be used by the dispatcher in 'Dispatch Light – Transport Legs' and the GPB 'Transport orders /-legs' to release trading orders assigned to transport legs to the warehouse. Now, this process can be automated.

The following parameter can be defined:
- Plus days: The plus days define how many days in the future transport legs should be released to the warehouse, related to the rough plan date.
- Calendar: The calendar and the +days are used to determine the date by which transport legs must be released to the warehouse. When using the calendar, only working days (marked as ‘Open’) are counted. Without the calendar, all days are counted.

New periodic function is accessible in following path:
- Main menu -> CAPcargo Transport -> Periodic -> Dispatching -> Release to warehouse - Transport leg

The block release to transportation feature was moved from trade order header level to trade order line level. The field Block release to CAPcargo transport is kept on order header level, however, it only serves as a default value for the order lines. The real blocking happens on order line level that can be manually changed by multiselect enabled buttons (Block and Unblock) under the CAPcargo transport button group of the order line.

Bring back file size validation when adding D365 attachments that will be sent to Driver app. These include attachments on work instructions and addresses, if the document type is enabled for Driver app. The maximum allowed file size is 17500000 bytes (~16,8 MB).

Updated the Resource Screen behavior to hide Capacity and Qualification tick boxes along with color fitting indicators when using the 'Manual date' and 'No link' modes. These controls are only relevant for the 'Tour link (Gantt)' mode and are now removed from the view when other modes are selected, preventing users from interacting with inactive options.

CAPcargo lead time calculation: determine transport leg rough plan dates for load and unload without generating transport legs.

This feature integrates the CAPcargo transport order lead time calculation into the Delivery Date Control mechanism for CTP, ATP, and None. Once the delivery date control process completes, the system uses the calculated ship and delivery dates to trigger CAPcargo rough scheduling. The rough scheduling results are then written to the confirmed date fields. Consequently, users can determine the planned loading and unloading dates in transportation without needing to generate transport orders and transport legs.

This functionality is only for Shipment builder version 3 (Unified global data model). And it only supports standalone sales orders.

Code structure of the Carrier portal has been redesigned. In this release (and onwards), the Carrier portal is split into more applications:
- standard product version (ie. ISV, that is to be deployed for most projects that use carrier portal)
- project specific version (ie. CUS, that is to be deployed only to relevant project)

The changes happened entirely on the code level (and in the deployment process), there is no visible impact on the front end user experience.

Previously, the "Arrived" tour stop was shown as green "checked" icon, but "Departed" tour stop was shown only as "Yes". Visualization has been adjusted, "Departed" tour stop is also shown as green "checked" icon.
Additionally, several missing auto refresh actions were added, to ensure that users immediately see impact of their "Has arrived" or "Has departed" actions.

Sometimes changes in dispatching were not reflected in the Driver app tour data, if the change happened while the tour was being exported from D365.

Previously, even though some confirmation existed on the Sender delivery / Receiver pickup transport leg(s), it was still possible to delete transport order from dispatching.
Such action is now blocked, similarly to how it was already done when some confirmation existed on a related tour.

This ancient feature inserted waiting, break and night break activities on a tour, based on opening hours mainly. With the new powerful driver break feature and also optimizer who handles these topics on a much broader horizon, this legacy feature is not needed anymore.

Driver app now does a data synchronization (data exchange with the middleware) when confirming arrival to the last stop of the tour. This is addition to the pre-existing triggers of starting the tour (confirm first activity of the tour), departing from tour stops and completing the tour (confirm last activity of the tour).

Previously, when Dangerous goods were found on Transport legs used in Optimizer dispatching, and the sum of their ADR calculated scores exceeded the corresponding Optimizer threshold parameter, the route calculation already used the hazardous goods HPRN defined on vehicle type (process run with parameter 'Ignore HPRN' = No).
Process was now enhanced so that the same logic applies when parameter 'Ignore HPRN' = Yes (xDiMa direct calculation, instead of HPRN-based). Process now also works the same even when 'Ignore HPRN' = No AND no HPRN is defined on vehicle type (simple HPRN or hazardous goods HPRN).
In case no hazardous goods HPRN is defined on vehicle type, but a simple HPRN is defined, and 'Ignore HPRN' = No, no changes to the current process were done (user is warned that hazardous goods HPRN is missing, and route calculation is based on simple HPRN).

Improve the logic for fetching information about a scanned object to better cover also exception cases (package should not be in this depot), vehicles and depot areas.

Improved map visualization for tours where the same address is used multiple times within the same tour, such as returning to the same depot or visiting the same location more than once. Previously, only the last occurring tour stop number was displayed on the map, which could lead to confusion when multiple stops shared the same address.
With this improvement, repeated locations are now clearly identified by displaying the first occurring tour stop number with an asterisk, indicating that multiple tour stops exist at the same location. When hovering over such a marker, users are informed that multiple tour stops are detected and can open the details view to see all related tour stop numbers. Users can then select a specific stop to view its details and highlight the corresponding tour stop in GS. When a tour stop is selected in GS while the map is open, all stops at the same location are displayed, with the selected stop visually highlighted.

The generic error was replaced with a more specific one in case of losing internet connection. This may help the user in certain cases (ex. too far from wireless range).

Improved the Drag&Drop behavior when planning legs from GPB Order Screen (OS) into tours. Previously, in some scenarios, dropping a leg onto a tour in Level 1 could fail or the drop action could be processed without the leg being removed from the list, requiring users to repeat the operation.
The planning behavior has been improved to ensure legs are consistently added to the selected tour.

Interaction between the Map Screen (MS) and Gantt Screens (GS) was improved by enabling tour selection directly from the tour track. When a user selects a tour track in MS with a left click, the corresponding tour is now automatically selected in the open GS screens (depending on where it was pushed/pulled from), providing a consistent selection behavior similar to selecting tour stops from the map. This improves navigation and makes it easier to identify and work with the selected tour across screens.

Previously, the package dimensions and weight were taken from the container type after the items had been packed and the container closed. However, this process has now changed, with the weight and measurements being taken from the container itself.

Previously, changing an item transport unit combination permanently broke the synchronization of existing transport orders. Consequently, if a released product already in use required a different transport type or unit, a new item had to be created in the system.

Since such a process is not realistic, a new feature was introduced for the item transport unit combination: versioning. The modification of an item transport unit combination record does not actually change the record, but moves the initial record into "history" and generates a new one. This way, it can be ensured that existing transport orders - that use the initial record - can still be synchronized.

Add search functionality to the tour lists in Loading and Unloading screens. All fields that are visible on the tour cards are included in the search.

Goods that are not yet picked in the warehouse are shown in Depot app but can't be loaded yet.

The business hours feature was enhanced with more refined and advanced validations in the area of opening TIMES specified per transport address or [grouped] calendar. It can better be distinguished between open DAYS/DATES and TIMES.
For customers not having used calendars so far, not much is changing. The UI on the transport address is new and less misleading, replacing the yes/no flags per weekday by ‘default/weekday-specific' enum. Further an address can be activated for specific business hours registration or deactivated which means falling back to a calendar. Transferring from the old solution all addresses will be activated, as this was the only option in the previous concept. However, for new addresses (also in the creation wizard) the activation switch is by default OFF, meaning it’s falling back to the regional calendar. But if accurate business hours are available, switch it on and register them.
For customers having used the calendars, read carefully the release letter and ask for more specific documentation to find out, if you need to adapt your setup. It affects mostly customers who:
- use different time windows, even date specific, and mix calendar and transport address opening hours settings.
- largely use calendars per address and might with the new solution simplify the setup and get rid of some calendars.

It is now possible to send tour related free text messages between D365 backend (eg. GPB dispatchers) and carriers.

Key characteristics:
- Sending of messages (and opening message history log) in GPB is done via new context menu options per tour.
- Sending of messages (and opening message history log) in Carrier portal is done via new action buttons per tour.
- Both action buttons on carrier portal can be further customized via portal button configuration.
- Sending of messages happens in the real-time.
- Sent messages are stored with details of sending party/user, and timestamp.
- Sent messages are not editable anymore.
- Once tour has any messages, users are informed via "envelope" icon in tour gantt in GPB (and in tour grid in carrier portal).
- Capture of reading confirmation (and sending of attachments) is not supported.

During Optimizer dispatching, if none of the used resources (from vehicle group or resource combination plan) were available for the entire duration of planning, the process correctly stopped with proper warnings, but also displayed an error confusing to the user (''Cannot edit a record in Optimizer tour plan (TALoptTourPlan). The record has never been selected.'). The error has now been suppressed, no other changes to the process.

A new index has been introduced for the CAPcargo shipment line table to improve the performance of all processes using this table.
This improvement is only applied on Shipment builder version 3 (Unified global data model).

Opening the connected packages form has been improved significantly.
This improvement is only applied on Shipment builder version 3 (Unified global data model).

A new index has been introduced for the CAPcargo direct delivery chain table to improve direct delivery creation performance.
This improvement is only applied on Shipment builder version 3 (Unified global data model).

At transport order synchronization with CAPcargo shipment, the number of times the system recalculates the tour was reduced substantially.
This improvement is only applied on Shipment builder version 3 (Unified global data model).

Enhancements to trade data collection and calculation methods have reduced the Goods management form's loading time.
This improvement is only applied on Shipment builder version 3 (Unified global data model).

Enhancements have been made to the update logic for warehouse work headers and lines when removing not picked shipment lines form tour or transport leg.
This improvement is only applied on Shipment builder version 3 (Unified global data model).

An index was not taken into account by the Reservation status field of the GPB 'Transport orders /-legs' screen.
This improvement is only applied on Shipment builder version 3 (Unified global data model).

Code optimization within the 'Reserve - Transport leg' function has resulted in measurable performance gains.
This improvement is only applied on Shipment builder version 3 (Unified global data model).

The performance of SCM status recalculation at confirming outbound warehouse shipment has been improved.
This improvement is only applied on Shipment builder version 3 (Unified global data model).

Enhancements have been made to the update logic for warehouse work headers and lines during tour deletion.
This improvement is only applied on Shipment builder version 3 (Unified global data model).

Enhancements have been made to the update logic for warehouse work headers and lines when moving tour stops between tours.
This improvement is only applied on Shipment builder version 3 (Unified global data model).

Previously it was possible to create new address only in address management (and during order creation).

Improved Related Resources loading performance in the Resource Screen (RS) by optimizing data retrieval for visible resources only. Large datasets are now processed more efficiently through parallel loading, while smaller datasets are loaded in a single request to avoid unnecessary service calls. Reload behavior has also been optimized to prevent redundant data processing when the RS context remains unchanged.

The tour ordering in the GST Gantt has been updated to ensure a consistent sequence. Tours are now sorted first by tour start date/time and then by Tour ID. Tour end time is no longer considered as part of the sorting criteria. This restores the expected ordering behavior.

New feature that can be used to receive Sender delivery orders and hand out Receiver pickup orders in a depot.
Can be enabled by specific parameter in mobile app user settings.
Confirming the Sender Delivery order automatically confirms the load leg point.
Confirming the Receiver Pickup order automatically confirms the unload leg point.
Tours containing Sender Delivery/Receiver Pickup legs are not handled under this feature.
A default depot area can be defined in Depot setup for unloading Sender Delivery orders.

Following data entities were added:
- TAL Container type mapping (TALshiContainerTypeIntegrationTable)
- TAL SLA mapping (TALshiServiceLevelAgreementMapping)
- TAL Transport delivery term mapping (TALDlvTermMapping)
- TAL Dispatch sector zip codes (TALDispatchSectorZipCode)
- TAL Certificate type (TALCertificateType)

Generally, HPRN's cannot be created taking into account these vehicle type geo service feature layers:
- PTV_SpeedPatterns
- PTV_TruckSpeedPatterns
- PTV_RestrictionZones

Therefore, previously the HPRN creation process had a hard validation, not allowing HPRN creation for vehicle types setup with these layers.
Since some vehicle types could indeed need to be used both in processes needing these geo service feature layers (ex. Distance and time calculation) and HPRN's (sequence optimization, Optimizer dispatching), the validations in the HPRN creation process were softened up, to help user avoid using additional workarounds.
The HPRN creation process is now possible even for vehicle types setup with these geo service feature layers without first removing them, but just warning the user that the HPRN being created does not take into consideration aforementioned layers.

Resolved issue: stackability was not initialized to the transport order line from the transport unit of the transport type.

On subcontracting requests, the "Received price" and "Carrier comment" fields are newly editable in D365 also when subcontracting request is already in status "Released", to allow D365 users to finish the subcontracting request process handling entirely in D365 (ie. without carrier portal).

Previously, moving a tour to a different date/time could temporarily display the tour in its previous time slot due to unsynchronized AOS cache data. The tour is now consistently displayed in the correct time slot after refresh.

Adding the transport order change management for the to dates and time windows of the transfer order line.

When loading goods in vehicles or vehicle compartments the system validates whether coloading restrictions are in place, and prevents loading if violations are found. This feature is heavy for performance, might slow down the system and must be specifically enabled from Transport type if absolutely needed.

The automatic increment/decrement of the quantity fields (while vertical scrolling via mouse) has been suppressed, to ensure that quantity fields are not changed without user realizing it.

The business hours feature was enhanced with more refined and advanced validations in the area of opening TIMES specified per transport address or [grouped] calendar. It can better be distinguished between open DAYS/DATES and TIMES.
For customers not having used calendars so far, not much is changing. The UI on the transport address is new and less misleading, replacing the yes/no flags per weekday by ‘default/weekday-specific' enum. Further an address can be activated for specific business hours registration or deactivated which means falling back to a calendar. Transferring from the old solution all addresses will be activated, as this was the only option in the previous concept. However, for new addresses (also in the creation wizard) the activation switch is by default OFF, meaning it’s falling back to the regional calendar. But if accurate business hours are available, switch it on and register them.
For customers having used the calendars, read carefully the release letter and ask for more specific documentation to find out, if you need to adapt your setup. It affects mostly customers who:
- use different time windows, even date specific, and mix calendar and transport address opening hours settings.
- largely use calendars per address and might with the new solution simplify the setup and get rid of some calendars.

Mandatory data job for #122998, making sure that shipment lines are updated with the current item transport unit combination version.

Mandatory data job for #117936, moving some configuration data to the new data structure:

Day flags (Mon/Tue/Wed/Thu/Fri/Sat/Sun): True/False moved to 'Standard business hours' or 'Weekday specific business hours'
New 'Activate business hours per address' - set to True for existing addresses, as this was the only way in the legacy solution

The issue was that when applying the 'Vehicle type' filter, then previously set pagination number (of the 'Resource' screen) was not reset and was often showing that no "Vehicle type" result was existing (as results were filtered for eg. 5th page, while results were only existing on eg 1-2pages).. Now, the "Resource" pagination number is reset and "Vehicle type" filter starts on 1st page.

Work instruction updates on intercompany sales orders (of an intercompany direct delivery chain) previously generated new work instructions rather than updating existing ones.

Work instruction updates on intercompany direct delivery sales orders previously generated new records rather than modifying the existing work instructions.

The issue was happening in Goods management form, when instead of the confirmed predecessor leg, it was displaying the current (own) tour arrival time.
This is now fixed and now the Goods arrival date in Goods management is displaying the arrival date time from the predecessor leg.

The location ID is generated from a number sequence and should not be edited (by mistake or on purpose) by users creating addresses via the Transport address wizard. The field has been now disabled for editing.

The issue was happing in simple waybill report and also in "consolidated" waybill report. Issue was corrected and dangerous goods data is printed also when waybill report is generated in other languages.

Resolved an issue in the Resource Screen (RS) where drivers were not displayed after clearing the Driver Group filter. The issue occurred when removing a selected Driver Group, causing driver data to remain hidden until the Drivers option was toggled. The behavior has been corrected to ensure the drivers are shown correctly based on the remaining Resource Screen filter criteria after clearing the Driver Group filter.

During order creation, in dynamic load/unload data determination (ie. when "Date initialization load/unload" is set to dynamic, in transport type), it could previously happen that some load/unload date combinations were not offered in the calendar picker, even though they were perfectly valid. The issue was that rough scheduling calculation logic in certain cases did not provide the date sequence in the proper sequence. The issue was corrected, by sorting the response results into sequence (which resolved the original reported issue).

Resolved an issue where legs confirmed through the Cross-Docking form were still displayed in the OS grid. After confirmation, only the leg that remains unconfirmed is now shown in OS, matching the expected behavior and the display in Dispatch Light Transport Legs.

Fixed an issue in GS Level 3 where the manual ETA was displayed incorrectly in the tour stop mouseover popup as a letter with an asterisk instead of the correct time with an asterisk. Also resolved an issue where confirmation information could overlap the manual ETA in the mouseover popup when confirmation data was present.

Previously, tour stop pins were displayed incorrectly and routes were missing when showing Route/Cost Optimization results on the GPB map. The map display has been improved to ensure optimization variations are rendered correctly with the expected stop locations and routes.

Previously, when qualifications (on vehicle or driver) were setup with multiple certificates, only the farthest one in the future was taken into consideration during conflict analysis, even though an earlier one may have fitted the requirement.
The proper certificate for the action date is now identified and used in the decision to display (or not) conflicts 250/255 (missing certificate for vehicle/driver).

If "Switch off detailed scheduling" was enabled on transport type, then process "Generate tour from transport leg" could create tour stops with some orders but without any Load/Unload activities (and therefore 0 orders were indicated per such tour stop).

Fixed an intermittent issue in the GPB Resource Gantt Screen (GSR) where tours could appear duplicated or as ghost entries after changing the selection. The difficult-to-reproduce issue occurred under specific conditions when absences were present within the visible viewport. Improvements were made to the refresh and data handling logic to ensure consistent tour rendering and prevent duplicate tour displays during selection changes.

Previously, when changing the stop sequence of a tour in asynchronous mode, an incorrect error message was displayed when the tour was already released to the depot and LIFO sorting was enabled.
The validation of the new tour stop sequence is now performed before starting the LIFO sorting and other related processing steps, ensuring that the sequence change is validated correctly and the appropriate message is displayed to the user.
This issue had no functional impact and did not block any business process; it only resulted in an incorrect error message during the sequence change operation.

Fixed an issue where moving a resource (via drag&drop) from one tour to another did not correctly update the source tour in GS Level 2. The source tour continued to display the transferred resource because cached Level 2 information was retained. The display now correctly reflects the updated resource information after the transfer.

The fix ensures that, whenever a vehicle is setup with Driver combination logic = Mid-term driver plan, the vehicle/driver combination is properly taken from the mid-term driver plan when selecting the vehicle on the Resources screen also in 'Manual date' mode.

Work instructions added to trade order lines when they had already been released to transportation didn't update the necessary field on the transport leg to indicate in GPB 'Transport orders /-legs' screen that the record has a work instruction.
This improvement is only applied on Shipment builder version 2 (Based on WHSLoadLine).

A problem in CAPcargo's internal tools code (now fixed) caused the opening of some reports via code (instead of UI) to result in a fatal error.

Fixed an issue where the Conflict Analysis (CA) status in GS Level 1 could remain outdated after closing the CA web browser due to unsynchronized AOS cache data. The GS Level 1 now correctly reflects the current CA status after the web browser is closed.

On the Goods management form, it was not indicated on tour order line and shipment line level whether the packing slip was already posted for a non-WHS sales order line based transport order.

In certain scenarios, it was possible to post the packing slip multiple times for non-WHS sales order based transport orders.

Fixed a bug that lead to failed validation of "Rearrange tour stops" if the driver had previously registered unplanned empties (=new spontaneous stop to a depot).

Fixed an issue where resources drag&dropped from the Resource Screen (RS) onto a tour in Gantt Screens (GS) were not correctly displayed in the Planned section of RS. In certain scenarios, after the drag and drop action, the resource information shown in RS did not reflect that the resource was used on the tour. The issue has been corrected to ensure the Planned section displays the correct resource usage information.

Even though the Resource relation field itself accepted trailer ID's as well, only the motor vehicle ID's were displayed in the lookup.
Both motor vehicles and trailers are now visible in this lookup on the Certificate form.

The issue was happening only when all following conditions were met (hence just 'edge' case):
- 'Concurrent subcontracting of transport leg and resource allowed' parameter was set 'True' in main transport parameters
- 'Price calculation split by transport leg subcontracting' flag was set 'True' on Resource subcontracting order
- Transport leg subcontracting order was flagged as "Not statistics relevant'

When all above was met, then Resource subcontracting order was previously not included in revenue/cost statistics calculation (even when it was set as statistics relevant), because its related transport leg subcontracting order was set as 'Not statistics relevant'.
The issue was corrected and Resource subcontracting order now reflects only its own 'Not statistics relevant' flag.

Some enum fields were wrongly defined (since many years) and this caused errors in Microsoft CDSVirtualEntityRefreshBatch.

When 'Disable real-time update of existing work' was turned off, the 'Send update to warehouse' message incorrectly appeared during non-warehouse related dispatching processes. E.g. plan transport leg to tour, unplan transport leg from tour.

Previously, transport order creation within the same intercompany direct delivery chain was inconsistent: requests initiated from the intercompany purchase order failed with an error, whereas those from the sales order processed successfully.

Fix a bug in D365 processing of vehicle claims ("Vehicle damaged") from Driver app. Now the claim is correctly linked to the corresponding truck or trailer.

Previously, the error infolog was in some cases missing and portal showed to user only empty price calculation details screen (as there are no calculation details that could be displayed).

Wrong 'Origin' value in the "Address creation history (Portal log)" record, when user manually adjusted the address details (during new address registration on the portal). The 'Origin' was previously always created as 'Reverse geocoding', even though the user adjusted the address from the "Autocomplete" google proposal. The issue was corrected and origin is now filled either by "Autocomplete" or "Reverse geocoding" values.

Please note: there is no data job provided (to correct the "Origin" values in the "Address creation history (Portal log)" records, as the table is rather internal logging table.

The issue was mostly encountered when in D365 there were more cities for the same ZipCode. Issue was corrected.

Fixed an issue where the Subcontracting Request icon on the tour (GS Level 1) was displayed incorrectly when the request deadline had passed without a confirmed request. The icon is now displayed as grey for subcontracting requests in released or rejected status without confirmation, reflecting the correct request state.

In certain data constellations (ie. when predecessor leg is confirmed), then the current transport leg status in goods management could still show "To be picked by receiver" (but it should show already "Ready for receiver pick-up" status).

Fixed a validation issue, by which changing the current 'From' time value into another value still smaller than 'Till' wrongly triggered the warning '
Time ‘From’ cannot be later than Time ‘Till’!'.