10.0-CAP55.0 (21.09.2026)

Purpose of the new module: Managing docks, lanes, or ramps in depots and warehouses, and handle the two main processes:
- External subcontractor self-planning (via Carrier Portal)
- Internal dispatching

In the external process the subcontractors or carriers use the portal to select and book their own dock slots. The carrier is responsible for choosing a suitable time slot, within certain constraints set by the depot.
A key criterion is whether a tour requires mandatory advance slot booking at the depot, which is flagged in the system. If required, the carrier must book a slot before arrival. Subcontractors see their tours in the portal, with a flag indicating the need for dock planning. They access a list of available slots, generated based on the tour's loading or unloading duration.

In the internal process, dispatchers assign trucks (both company-owned and subcontracted) to specific docks, managing availability and providing instructions to drivers. This process involves tracking dock availability and scheduling. Dispatchers use the GPB screen to filter and display available docks, then drag and drop docks to tours to create assignments. This process mirrors the assignment of trucks to tours and considers dock qualifications* and capacities*. (*Phase 2, any next release)

The technical foundation for dock planning includes the use of resources, resource assignments, and integration with existing tables such as address areas which can provide qualifications and capacities. 
The docks are treated as resources, similar to vehicles, compartments and drivers. Resource assignments are created for each booking, whether for tours, unavailability (e.g., maintenance), or dock planning.

Filter field 'Customer Group Transport' was added to the dialog for customer invoice pool opening.

Code structure of the Customer portal has been redesigned. In this release (and onwards), the Customer portal is split into more applications:
- standard version (ie. ISV, that is to be deployed for most projects that use customer 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.

Technical update, with no impact on the portal front end GUI.
Both portals were updated, to use the latest recommended MUI version 9.2.0 (which is a tool for general portal visualization).

It is now possible to hide 'Send message to dispatcher' button (in tour action buttons) via portal button configuration.

GUI was improved and order id is now shown even when searching track & trace orders via package barcode.

The dialog for new order creation has been completely reworked (ie. replaced by a new version, with better structured GUI).

Can be used for quick unload confirmation of arrived goods, regardless of the tour where they arrived on. For example there could be a pile of goods that were unloaded from multiple tours, and now it’s possible to confirm them all with this feature, with just one scan per package, without considering the tour in which they have arrived.

Show "Sender delivery tours" (tours that have Sender delivery legs) separately in Depot app unloading screen. New filter "Sender delivery" has been added to the screen to support that. If filter is not set, only normal tours are shown. if filter is set, only Sender delivery tours are shown.

Tour report has been enhanced with details related to Dangerous goods:
- Icons for dangerous goods and limited quantity are shown on the report
- Dangerous goods/ Limited quantity material details are shown separately for each order in the tour stop

Due to a previous PTV limitation in the calculation of driving breaks (see release letter for ADO 110588), when configuring driving breaks on vehicle type, one of the fields 'Max driving time between breaks' or 'Max working time between breaks' was always disabled when the other one's value was >0. This limitation is now solved, so both fields are always enabled and considered, if set to values >0.

Previously, with "Generate/Update tour out of route/zone", legs were planned to a tour, even if the tour was released, or departed. Now, this is improved.
New parameters "Tour status" and "Process for not-planable legs" are introduced.

With this new parameters, there are rules when a leg can be planned to a tour, depending of the status of the tour.
If the tour is in lower status, than the "Tour status" parameters when the legs are planned, then the legs are planned to the existing matching tour. If no matching tour exists, then the a new tour is created.
If the tour is in higher status, than the "Tour status" parameters" when the legs are planned, then the legs are not planned at all, and remains unplanned or a new tour is created.
In the second parameter "Process for not-planable legs", if the parameters is set to "Create new tour" - the legs are planned to a new tour, if, no matching tour exists. If, the parameters is set to "Do not dispatch legs into tours", then the legs are planned to the existing matching tour or the legs remains unplanned.

A new, 'Quick view' was introduced to the Map screen. Similar to Track and Airline views, separate buttons exist to pull tours from GST or GSR in this new view. The tours in displayed in Quick view are similar to Airline view, except without even loading/showing any tourstops. This then makes the display action much faster.
Also, regardless of the view a tour is loaded in (Track, Airline, Quick), rightclicking on the tour gives the user the option to switch from the current view to any of the other views available.

It is now possible to easily expand or collapse the transport leg details section on the Order screen by use of a new toggle button (similar to how it was already possible in GS lvl 3).

Many optimizations and improvements have been made in various dispatching processes. The improvements impact mainly GPB but also Dispatch light.
- Move tour to another resource, or remove resource from tour (30% compared to CAP54)
- Move tour stops from one tour to another (30-50% improvement compared to CAP54)
- Improved prioritization and parallelism when pre-loading tour details in Gantt Screens (to achieve instant display of details when user clicks a tour)
-- When user clicks a tour it's now more likely to be in the cache and therefore more likely to be displayed instantly
- Optimization in updating TMS values to WHS work (Shipment builder) - ignore cancelled works. Depending on the data composition the performance impact can vary from "no impact" to "massive impact" in various dispatching processes.
- Various smaller improvements that impact many dispatching processes but are hard to measure

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.

The legacy and very basic ramp/lane feature was mostly deprecated only earlier. With this task we finally deprecate it entirely, as the new feature "Dock planning" (see also #111243) is released in the same release (CAP55), replacing it with much more powerful functionality.

X++/TMS process, not an app update.

Clean up Driver app tour older than x days, regardless of tour status.

New setting "History limit (days)" has been added to the batch dialog "Clean up Mobile app tours".

If this new field has value 0 (default value), the old tour status range will be used. Otherwise tour status range will be ignored and only the number of days will be used. The day range will be applied against Timestamp field of the Mobile app tour.

The days setting can be used if it's common to have not completed tours for any reason. This is common in test systems but is possible also in production environments.

It's also possible to set up two batches, one for cleaning up recent completed tours, and another one to clean up older tours regardless of status.

X++/TMS process, not an app update.

Don't allow swiping/scanning load activities on a depot stop if "Release to depot" has not been done in D365.

X++/TMS process, not an app update.

Driver app shows "Goods not ready!" activity if some goods have not yet been picked but should be loaded in this tour before departing.

Until now this activity was created only if picking had not been started at all before sending the tour to Driver app. This was enhanced and not it's created if at least one package hasn't been picked yet when the tour is sent to Driver app.

X++/TMS process, not an app update.

In some Driver app features the app must have an online connection to D365. These connectivity checks are now saved to Online check log in D365. Only succesful checks can be stored, unsuccesful ones never reach D365.

With release CAP55, it is necessary to use PTV xServer 2.40.1.
Upgrade was done in order to be able to take advantage of PTV improvements of xServer in the areas of CO2 and toll cost calculation (see also 121948), xRoute behavior/restrictions/improvements in specific scenarios, driver breaks/rest handling (see also 124293), improvements in response in case of combined transportation, as well as infrastructure and platform-related updates.

Additionally, this version contains features to be used in future CAP Product developments.

In case that xServer is hosted on-premise, please ensure that the installation is upgraded to 2.40.1 and the necessary xServer configuration adjustments are done.
In case CAPcargo is hosting the xServer, CAPcargo will take care of moving the already-existing HPRNs while keeping the same url, although generating new HPRNs is highly recommended.

Additional enhancements were done in the area of Distance and time calculation modes (following the initial ones detailed in task 119930 in a previous release):
- The enum 'Normal' 'Mode tour distance/time calculation' has been renamed 'Standard'
- helptext labels of several fields related to distance and time calculation were improved/updated
- the old 'Advanced [deprecated]' mode is not functional anymore, still visible in the lookup just for reference; enum will be removed in a later release
- for best performance, the 'Simple' mode was simplified even more. Regardless of general parameterization, in the 'Simple' mode there will be: - no time consideration; - no use of real time traffic data (PTV_TrafficIncidents layer); - no use of preferred routes; - no use of any geo service feature layers defined on vehicle types; - restriction mode hardcoded to 'Automatic'; - optimization factor hardcoded to 50; - toll cost factor hardcoded to 0.
- the 'Simple' mode was further enhanced to make used of HPRN's defined on the vehicle type (if any). If the 'Simple' mode is to be used, then it is highly recommended to define an HPRN on the corresponding vehicle type.

Previously, it was not possible to skip geocoding when creating certain addresses (ex. invoice addresses, postal boxes, etc.).
This has now been made possible by introducing two new parameters:
- 'CAPcargo geocoding' flag on Address setup>Country/region
- 'CAPcargo geocoding' flag on Address and contact information purpose

These flags are enabled by default (see corresponding data migration job). If at least one of these flags is disabled when creating a particular address, the geocoding is no longer required (geocoordinate values = 0.00).

When multiple vehicle profiles are present on tour (ex: truck, trailer, multiple trucks and trailers), the trailer's speed profile (if trailer defined as resource on tour) will be used for Distance and Time calculation. This replaces the previous more complex logic of attempting to determine by calculation the slower vehicle type and use that one (since legally, a trailer's overall speed should be slower or no faster than a vehicle which could pull such trailer).

Similar logic has been now applied in Optimizer: if a trailer is present in combination with a truck, the trailer's speed profile is used for the DistanceMatrix calculation (if parameter 'Ignore HPRN' = True or no HPRN defined on trailer's vehicle type) or the trailer's HPRN is used for DistanceMatrix calculation (if parameter 'Ignore HPRN' = false).
Warning: Since until now, any HPRN used by Optimizer was defined only on motor vehicles (trucks), it is highly recommended to create HPRN's also for the vehicle types used for trailers, to avoid the slow on-the-fly calculation in case trailers are used. Alternatively, the same HPRN's created for the trucks can also be setup on the trailers.

Previously, when a Distance/Time calculation would need multiple subroute calls (ex. a vehicle of a certain vehicle type/speed profile started a tour, and a vehicle of a different vehicle type/speed profile ended a tour), only one of these xRoute calls was logged in the Geo services log (if logging already enabled via corresponding geo services parameter). This then made it hard to debug/analyze potential issues in calculations when the other subroutes calls were not readily available.
All subroute calls are now logged under the same request/response downloadable file in the geo services log form.

Based on the selection in the 'Plan date control', the 'Weekdays' checkboxes (under 'Schedule') are now set to editable or not editable.

Plan date control 'weekday scheduling' -> All weekdays are editable
Plan date control 'scheduling with warehouse shipping days' -> All weekdays are editable
Plan date control 'transit scheduling '-> Weekdays greyed out / not editable
Plan date control 'None '-> Weekdays greyed out / not editable

For better visualization, the whole 'Schedule' field group was moved after the 'Rough scheduling (transport legs)' field group.

Previously, it was possible to send transport legs to Optimizer dispatching even in the past (past days compared to day of dispatching action, or past time compared to dispatching time in the same day). This could lead to operational discrepancies or impossibilities.
A new flag 'Allow planning in the past' was introduced in Optimizer parameters.
If set to 'Yes', Optimizer would continue to plan as previously.
If set to 'No':
- if rough planning date (coming from the selected legs or manually selected in the dispatching form) is in the past (compared with 'today' = system date), the Optimizer dispatching process would stop with proper warning
- if rough planning date is same as 'today' (= day of dispatching), Optimizer would plan with the latest of the values ' Earliest tour start' or 'Now' + new parameter value 'Planning horizon start offset (minutes)'
- if rough planning date is 'tomorrow' or later, Optimizer would plan as usual, no changes to the process

The Optimizer dispatching form has been visually improved. Fields and parameters are now placed in two dynamic columns, so that user would not have to scroll at all in order to see all of them at a glance. Some labels in Optimizer parameters have also been enhanced.

Warnings for conflicts deprecated a long time ago (ID 200, 205, 210, 215, 220, 225, 230, 235, 305) are no longer displayed when user presses 'Settings create / synchronize' in 'Settings of conflict management.

TMS report "User License Count History" was deprecated.
CAPcargo Transport –> Reports –> Licensing –> User License Count History

These keywords were remnants from AX2012 and have no functional impact in D365. Starting in Microsoft update 10.0.50 these keywords will lead to compiler error, therefore they needed to be removed.

Driven by a new parameter, the transport unit weight is added to the transport order line at transport order creation and update. By this, a more accurate weight is available for transport planning.

Previously, the versioning of the Item transport unit combination only covered the line records. This is extended, meaning that even header-level changes and transport type combination changes on the released product are covered by the versioning logic.

In order to be able to provide multiple potential delivery dates for same time delivery, a new function is introduced on the sales order. By using the function, the system shows the potential same time delivery dates, and calculates the delivery date related shipping date for each order line. The user can update all sales order lines with the same time delivery date and the related shipping date with a click of a button.

When in mode 'No details' or 'Bar extensions mode' in GSR, the dock booking bars upon selection are differently drawn, which can be confusing. The data of the booking transaction are not affected, after changing back to 'All details' mode, all works fine again.

Suggestion: Use dock planning just with 'All details' mode.

Mandatory data job for task 121576, by which the value of field 'Mode tour distance/time calculation' ((Transport parameters > Geo services) will be changed to 'Standard', wherever it was previously set to 'Advanced'.
This ensures that all existing configurations continue to use the supported mode after the deprecation of mode 'Advanced'.

Mandatory data job for task 121576, updating all existing tour headers where the 'Mode tour distance/time calculation' was previously set to 'Advanced' and changes it to 'Standard'. This ensures that all existing tours are migrated to the supported mode following the deprecation of 'Advanced'. The original value of field 'Distance and time values up to date' is not changed on any tour header where the Mode is changed from 'Advanced' to 'Standard'.

The old enum 'Skip transport legs' was changed to 'Skip', in order to be re-used in another lookup as well (Closed address handling). This datajob sets the new enum in lookup if the old 'Skip transport legs' was previously selected.

Mandatory data job for #122250, Newly introduced 'CAPcargo geocoding' flags are set to True, to allow consistent system behavior after update.

This data job fills the voucher id on the CAPcargo shipment lines for warehouse management enabled transfer order lines, essentially ensuring that historical records can reach SCM status "Packing slip posted".

The issue was corrected, when no specific document type is selected - then default fallback (from portal parameters) is applied.

Document reference value is now empties in invoice posting dialog, between customer invoice posting sessions.

Eg. fields were not copied, but they should have been copied to target order.

To complete the initial fixes done in a previous release (see 117540) in the area of Load/Unload scheduling date options (Transport type 'Date initialization load/unload' setup as Dynamic), additional scenarios were identifed and fixed:
- Load date incorrectly suggested in the case of a transport order which would generate a direct transport leg using a route/zone setup with transit scheduling
- Unload date incorrectly suggested in the case of a transport order which would generate multiple transport legs, the last leg using a route/zone setup with transit scheduling.

In the crossdocking rules, under the criteria set Id, a criteria of type 'Unload address' could be set at Table or Group level.
Previously, when the Transport type 'Date initialization load/unload' parameter was set to 'Dynamic', the unload date was still calculated based on the crossdocking rule, as if the unload address on the transport order matched the unload address (or group) set on the crossdocking rule criteria set, even when it didn't.
This was now corrected, so that the dynamic unload date is correctly interpreted, depending on whether there is a match between the unload address on the transport order and the unload address being set on the crossdocking rule criteria set.

When non-TMS addresses were used in various processes (for example, onetime addresses in Transport order creation), error 'No calendar for date defined!' was wrongly triggered, in case no calendar per area was defined to cover that particular address. When no calendar per area is defined, such an address by definition should have been considered open, but instead it looked for a calendar anyways.
Regression was caused by implementation of ADO 117936 (New enhanced business hours logic).
Visible effects of the issue described were spotted in transport order creation, portal order transmission, conflict analysis at order and tour level.

The issues were corrected in new transport order creation dialog.

The issue was only in GUI, the existing temperature code was not physically deleted.

The issue was happening especially when portal order status was changed after editing of order (eg. when order was in status "Created" and changes were committed via "Transmit" button).

The issue was corrected, when no specific document type is selected - then default fallback (from portal parameters) is applied.

Previously it could happen that newly created portal order inherited partially the address of the last previously created portal order. The issue was only happening when first transport order was created with transport address id (being load or unload). Then, if following order was created with "non transport" addresses, it inherited the transport address ids of the previous order. The issue was corrected.

In rare cases, the app would stop with 'Depot app CAPcargo isn't responding' and could only be resolved by clearing app data & cache. This could happen especially if app was left active on the device for a long time (ex. overnight) and then user picked it up to continue work immediately. Such hang-ups are now prevented.

Previously, when at least one driver break existed between tourstops, the strategic tour routing function did not insert any waypoints between those tourstops (based on some valid rule).
This was fixed so that the strategic tour routing function will remove any existing driver breaks, insert strategic waypoints, then run again 'Distance and time calculation with driver breaks' to insert updated driver breaks.
In case of tours of Optimizer origin, if both driver breaks and activities of type 'Wait' (automatically inserted by Optimizer to cover the 'customer wish' scenarios) were present on tour, during strategic tour routing, such 'Wait' activities are removed, to avoid distorting the new calculations on a tour.
If only 'Wait' activities of Optimizer origin were present on a tour while running strategic tour routing, these are not removed even if some strategic waypoints are added to the tour (to be solved in a subsequent release).

The issue was especially happening for "non-transport" addresses, or for sender delivery / receiver pickup addresses.

Previously, when a resource unavailability's duration was shorter than the duration setup on GPB parameter 'Zoom Gantt bar (hrs)', the end of the unavailability displayed in GSR lvl 1 and on tooltip was wrongly shown as interval start + number of hours defined on parameter, instead of actual interval end.
For such short resource unavailabilities, the end of the interval is now correctly displayed, as well as the 'zoomed-in for your convenience' magnifying glass displayed in lvl 1, with tooltip behavior similar to the same feature used on lvl 1 in actual short tours.

Previously, if a driver break address on a tour was identical to a load/unload tour stop, and user would try to update such a tour out of route/zone with additional leg on same load/unload address, action would fail.
The logic was now enhanced to make the difference between tour stops of waiting type 'None' (regular tourstops), and tour stops of other waiting types (ex. 'Driving break').

In some constellations of multi-leg transport with initial deadlines dates being used for the first loading (so called rough scheduling rules), combined with the process of dispatching and un-dispatching the legs to/from a tour, the scheduled dates on the transport legs could be wrong after the removal from a tour. This was fixed.

X++/TMS fix, not an app update.

Fix a bug where in some shipment builder synchronization constellations a transport order was removed from Driver app, but work instructions of that transport order were still shown in the app. Now the process doesn't leave behind orphan work instructions.

Due to limitations in the calculations received from PTV, the hybrid ration was taken into account for CO2 calculations when we use 'Actual' consumption.
This was fixed with the latest update from PTV, and now the calculations are executed (received) appropriately.

In rare constellations of driving break parameterization, running the 'Distance and time calculation with driver breaks' on a tour of Optimizer origin containing already some driving breaks would result in distance and time being written on tour as 0 in the segment adjacent to some driver break, even if not truly 0.

Previously, if user changed the value of tour header field 'Mode tour distance/time calculation' (ex. from 'Standard' to 'Simple'), while the 'Distance and time values up to date' flag was already set to True, this flag was not set back to False, allowing for old/potentially misleading distance and time values on tour header if user did not follow up with a 'Distance and time calculation' action. This flag is not immediately set back to False at any change in the 'Mode tour distance/time calculation' field.

When using the 'Create toll cost' function, the displayed infolog is referring to driving time, but the duration displayed previously (now fixed) was wrongly displayed as for the whole tour, not just driving time.

Certain truck attributes details were missing from the tooltip in the Map screen (when Truck attributes layer was enabled for visualization). The view has been corrected and all details are again properly visible in the tooltip.

Number sequence for Package ID was not visible in Transport parameters.

When a particular day/date was defined as closed on an address (CAPcargo address or other) (via calendar per address, or weekday specific setting, or calendar per area), Optimizer wrongly ignored that setting and attempted to anyways plan the transport leg.
To properly steer the corrected behavior, a new lookup parameter ('Closed address handling') was introduced in Optimizer parameters > Algorithm > Data validation.

When transport legs containing transport orders with packages defined on order lines were used to create tours via Optimizer (in the context of extended coloading restrictions), the resulting carrying resource assignment was not done correctly at package level, potentially affecting proper usage of the Depot app.
This now works correctly, on the overall assumption of the Transport type parameter 'Carrying resource assignment on package level' being set to Yes.

In certain data constellations, after toggling between GS preset day filters (ex. from 1-day view to 3-day view), existing tours were not automatically visible without an additional manual refresh.

Several issues were fixed on the Map Screen related to the opening of the grouped resources on click, closing a table of displayed grouped resources, general visibility.

Re-using the same license plate id during warehouse picking for completely unrelated works was identified as a shared/over package in transportation. This fix ensures that shared/over package is only generated if the orders are packed together in the warehouse.

Sales return order lines are only considered during transport order creation. Afterwards, changes on the order lines are ignored. If the user must apply changes then it can be done via the Create/Update transport order dialog.
This bugfix ensures that users can freely adjust sales return order lines.

The CAPcargo trade order line table is added back to the data sources of the Open sales order lines form. By this, making sure that users can add, filter, and sort by transportation related information.

On the Deliver remainder dialog, if the order line is in transportation, the system indicates how many units of the order line can be removed. This calculation was not correct for direct delivery chains.

Optimized the code responsible for updating transportation information on warehouse work.

Standard warehouse management allows the user to use the Reduce picked quantity function, even if the outbound picking work is only completed till the goods are moved to the packing station. Due to a validation, this was not possible on systems with CAPcargo transport.

The warehouse license plate consolidation function was previously limited to two levels. This has been updated to ensure data successfully synchronizes with transportation even when more than two levels of consolidation are performed.

If the dry volume system unit was different than the volume related planning unit, then the transport order synchronization failed after warehouse picking due to a unit conversion error.

Certain inconsistencies between the direct delivery purchase order and sales order lines led to an error. This bugfix handles those edge cases cleanly to prevent future unhandled exceptions.

Vendor invoice posting was previously blocked if subcontracting order had activated flag 'Carrier portal self-billing confirmation required'. The issue was corrected and 'Carrier portal self-billing confirmation required' is now affecting only vendor self-billing invoice posting.