10.0-CAP51.0 (22.01.2026)

The issue was especially happening when more subcontracting requests (against different carriers) were existing for one tour. Then one subcontracting request was transformed into subcontracting order, but tour was still wrongly showed in the portals of other carriers too.

Moving thru pagination results on 'Tour' and 'Claim management' screens is now faster and more fluent.

Following adjustments were done in claim management area:
- Claim orders that have vendor account (ie. carrier) in the RecipientRef are newly also included in claim management overview, even though they are not related to any tour or subcontracting order
- Carrier filter (and also carrier field) are not anymore shown on the portal, as claims are already listed for the "concerned carrier" (but claim order does not have to be registered per carrier).

Two new calculated values were added for tour released and load/unload finished track and trace statuses:
- Estimated time of delivery
-- use the Arrival (confirmed or ETA) from the delivery tour stop
-- in terms of time, only use the hours and minutes

- Product name and quantity and unit
-- e.g. Product A - 5 pcs, Product B - 15 tons, Product C - 2 bigbags

Correction of previously existing calculated values for tour released and load/unload finished track and trace statuses:
- Driver name
- Driver phone

The issue was only happening when transport order form was opened in 'Show list' mode (with exact transport order id filtered/focused).

The issue was only happening if transport type "Date initialization load/unload" was set to "Dynamic".

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 GUI related (ie. no data corruption) and was happening for certain types of addresses only.

The measurements are now shown in industry standard sequence (ie. Length, Width, Height).

Following issues were corrected in the Dangerous goods area:
- "Combustible goods" flag (specified on material code) was previously not respected on the portal, during dangerous goods creation
- "Quantity per container' field was previously not shown correctly on the portal, for existing orders (with some dangerous goods)

The issue was happening when address components contain certain special characters (eg. ô etc.)

Behavior was improved and entering transport quantity now requires also to have a transport unit.

Previously, in the portal it was possible to create transport order that loads in the past. This is now avoided, the validation happens on the load date (ignoring the potential loading time windows). So register order for loading for today is possible, for loading for yesterday not.

Please note that behavior/validation can be further adjusted, via 'Transport order creation deadline rules'.

Previously, the document attachment upload was following the general order editing rules (which allows to edit order only till certain status). This turned to be too limiting, as sometimes it is needed to upload a document even for orders that are in delivery (or even delivered). The document attachment upload limitation was removed and does not anymore follow the general order editing rules.

Previously, it could happen that duplicate records were created via portal. As portal users, after submitting some new record could still press again the create/submit buttons. If they managed to press buttons repeatedly before the first API calls were completed - this led to duplicate record creation in D365. This is newly avoided - by disabling the create/submit button immediately after being pressed by user for the first time (and by replacing the button by "spinning wheel" button until the API calls are processed).

Issue was happening only when there were some packages for the transport order line. Then, after deletion of transport order line in in the portal, the order line was deleted but linked packages were not deleted. Issue is corrected and packages are now also removed, after deletion of transport order line.

During order creation, change of "Search by" for load address (from "All" to "ID") previously changed also "Search by" for unload address.
The issue was corrected, the "Search by" address parameters are now independent between load & unload.

The issue was especially happening when transport type was 'Date initialization load/unload' was set to 'Dynamic'.

If transport type 'Date initialization load/unload' is set as 'Dynamic' then following was previously possible in the transport order side details pane (in 'editing' mode):
- Manual specification of loading and unloading times (from/till) was possible.
- Manual free specification of load and unload dates was possible.

Both are now blocked, as allowed only when transport type 'Date initialization load/unload' is set to 'Static'.

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.

Via D365 'Address setup" the address management can be set up in a way that address can be created even with zip codes that are not in the D365 zip code table. Such setup was previously ignored by portal (and address creation was possible only when zip code was existing in D365 zip code table). This was enhanced and portal now follows the "Address setup" D365 rules and allows address creation even for not stored zip codes.

Following improvements were done in the "public" address area:

1) Previously, the locations/addresses could be set "public (approved)" only individually, as there was no mass "update" option existing in D365. This was enhanced - it is now possible to filter the transport address screen/grid in D365 (for desired set of addresses) and directly declare all filtered addresses as "Public (approved)".

2) On customer portal, new icon "Search all" was added next to load or unload address field, via which it is possible to type search criteria and search thru all private addresses in the system (regardless of customer account/company etc.). After search is completed, system shows all fitting addresses in the simple dialog, where use can select which address should be used. Such address is then automatically declared as "Public (approved" in the order legal entity and is selected back into order creation dialog. Such address then becomes public and can be normally selected by all other customers, withing the same legal entity.

The "Search all" icon is activated by new parameter "Allow search all addresses" in the portal user customer assignment.

Previously, during order creation, portal users could select from all SLA and from all transport units (of the transport type). This was enhanced - it is now possible to set up on portal user customer assignments following criteria:
- transport unit group id
- SLA group id

If some group is specified for some customer assignment, then portal users can select only SLA (and transport unit) from group members, during transport order creation (for that customer and transport type assignment).

It is now possible to allow the sending of tours to Depot app even to depots where the app is not enabled in the Depot settings (for Load or Unload), but is enabled on tour stop (whether manually or via instruction activity rules, as implemented under 118708 - see separate release letter for description).

Vehicle description is no longer shown, instead vehicle id is shown.

The depot app was enhanced so that also the device native camera could also be used for scanning, in menus like loading/unloading/pick&put.
The camera-switch button on the various screens is visible only when mobile app user parameter 'Scan barcodes with camera' is enabled.

Now loading and unloading a tour in Depot app can be flexibly controlled with the Instruction activity rules. Related settings in Route have been removed. Instruction activity rules contain a rich set of criteria, such as Route, Means of transportation and Transport leg type.

Depot app (loading) and Depot app (unloading) settings in Depot still determine the default behavior of tours. Instruction activity rules can be used to define exceptions and special cases.

Note: When creating instruction activity rules with the new types 'Load/unload in Depot app' or 'Don't load/unload in Depot app', the 'Mandatory for mobile app' flag on form has no impact, as these are not actual activities. These rules only control the Depot app (loading) and Depot app (unloading) fields on the tour stop.

Several functional inconsistencies were fixed in the generation of timestamps for the Resource assignment Start and End fields (ex. it was possible in some cases for End datetime to be earlier than Start datetime).
Additionally, two new fields were added to the Resource assignment 'Start (Filter' and 'End (filter)', and are used to ensure tours would be visible in filters (ex. GPB Gantt viewport), regardless of which of the planned/estimated/confirmed datetime values would be earliest/latest.

Previously, in the Goods management form's header, 2 buttons ('Remove not picked shipment lot' and 'Goods load splitting') were placed under the Splitting group. The Splitting group has now been removed, and these buttons have been moved under the Shipment builder group.

Some fixes/enhancements were done in the area of 'Split off resource (railway) to new tour':
- it is now limited to only splitting off to new tour resources of type 'Trailer'
- previously, in case of using more than one trailer on the tour, if selection to split off resource to new tour was made with the first (main) trailer on tour header, the new tour was created correctly, but the additional trailer resources on the original tour were lost. This was fixed so that, in this case, the next available additional trailer will be promoted on the original tour header to main trailer.

Previously, if user opened in Resource Dispatching the Tour details from the 'View details tour' context menu and changed some resources (add / remove / replace), after closing the web window, the Resource Gantt did not properly refresh to automatically display the changes done; user needed an additional screen refresh to see the changes.

Loading tours (or "Refresh all") on GST took minutes if "GPB Template data access" was used, because of a wrong condition in the data fetching statement.

With the new ‘Driver breaks’ feature, it is now possible to insert driver breaks into existing tours.

The parameterization of driver breaks is done at the level of vehicle type, where either preset or manual configurations can be selected. Note: Abiding by the local driving break laws falls entirely in the responsibility of the user doing such setup.

A major new function (‘Distance and time calculation with driver breaks’) has been added to the GPB which will add these breaks as separate tour stops, visually different from regular tour stops.
A new flag ‘Insert driver breaks’ was also added to the ‘Calculate tour duration’ tab in Transport type > Processes, to help steer the insertion of driver breaks. Note: this flag will be added in later releases to all process buttons enabled to also run Distance and time calculation.

Explanations/Limitations:
- Distance and time calculation with driver breaks evaluates the existing tour in ‘Simple’ mode (regardless of tour header setting for ‘Mode tour distance/time calculation’)
- Currently, driver breaks are inserted only 'on demand' (‘Calculate distance and time with driver breaks’). Possibility to insert driver breaks in automated/background processes will be covered in a later release
- The extra driver break tour stops are using a parameterized TMS address, but the geo-coordination on such stops is actually along the route. Note: these break stops are not actual POI’s (ex. truck parking), but serve only as indications based on pure mathematical calculations. Therefore, a proper interpretation of the break stop's geolocation would be: 'If tour goes according to plan, an optimal driving break should be taken somewhere in this area'.
- Break tour stops are visible in Driver app, can be confirmed by driver similar to any other tour stops.
- Parameterization with Working time between breaks does not take into consideration the time spent at various tour stops (for example, loading/unloading). This will be fixed in a subsequent release. Due to same limitation, the error log regarding maximum travel time may be wrong (even when using driving break presets) in some constellations.
- When running sequence optimization WITH extra parameters requested (ex. respect customer wish): Sequence optimization with breaks already on tour can only properly run if existing driver breaks are first removed (use dedicated GS button).

Previously, the carrying resource assignment was lost (now fixed) in the following constellation:
- Carrying resource assignment was set up to be done at package level
- Carrying resource assignment on the tour was done via Depot app
- Function 'Split off resource (railway) to new tour' was used
- Carrying resource assignments remained on the new tour created, but were lost on the original source tour.

The qualifications requested for Dangerous goods are now displayed in the qualifications form even when called from GPB OS (Manage>Qualifications).

Previously, a tour which was deleted or unselected in Resource Dispatching Gantt (GSR) was still visible in the Details lvl 3 section, until another tour was selected.
This was fixed, so that if a tour is deleted or unselected, lvl 3 would not show any details anymore.

Previously, if no tour was already visible in the Gantt screen when doing drag&drop of a Transport leg into the grid, it looked to the user as if the 'wrong' time zone was displayed. This was due to a faulty GS grid view. If there were no tours shown in the lvl1, the grid was "moved" to the very left and the Y-axis was displayed on the right side, causing the drag&drop of legs to lvl1 look like it is displaying wrong times. The Y-axis is now displayed on the left side even when there are no tours.

Now the start/end address initialization logic considers also Dispatch sector filter of GST (Tour Gantt), as well as the default dispatch sector filter in the worker's settings.

In GSR (Resource Gantt) we don't have a dispatch sector filter, and the initialization is first trying to determine start/end from the vehicle. If not successful it will fall back to the default dispatch sector filter in the worker's settings.

Qualification evaluation was enhanced in cases where a qualification must be fulfilled by vendor OR something else, such as a truck. Previously also vendors who don't fulfill this qualification were considered as fitting for the subcontracting order.

A bug was fixed causing the conflict message “Dangerous goods - Co-loading: Possible special conditions & exceptions, please check the work instructions.” to appear when it was not expected. The issue was that when there is LQ material without Main danger stated in the Dangerous goods data base, it was considered as exclusion for Co-loading and the conflict was populated. This is now fixed and works as expected.

A cleanup batch for transport events has been added in
CAPcargo Transport - Periodic - Track and Trace - Clean up transport events. It's recommended to clean up the events periodically because of big transaction volume in this table.

Up until CAP51 release transport events are always stored, even if the related Track and Trace status is not enabled. This will be streamlined in the future and only events related to the enabled Track and Trace statuses will be stored. The enhancements are currently planned to be released in CAP52 release (id 119082).

Field in Transport parameters - Dispatching tab - Resources - Reservation: Resource assignment calculation mode.

This is a legacy feature that will significantly slow down dispatching processes. The system creates and maintains (start/end times of) resource assignments for each tour activity, instead of one resource assignment for the entire resource leg.

The "Simple" mode has been recommended for many years, and is the default when creating new legal entities.

Automatic time zone determination was broken and didn't work. This bug also affects several processes, including:
- The “Add time zone to addresses” batch process.
- Creation of new addresses, where the time zone was not initialized.
- Actual tour planning, resulting in incorrect time zone information on tour stops.
- Carrier Portal, leading to white screens and crashes.

The fix includes improvements and centralization of timezone determination logic for new and edited addresses. The system will now check for the time zone in the following order:
- Zip code time zone
- State time zone
- Country time zone
- User time zone

Enhancements were also made for editing existing addresses: changing the Zip Code, State, or Country will now correctly reinitialize the time zone.
The “Add time zone to addresses” batch process has been updated as well to follow the same sequence when completing missing time zone data.

New field "Means of transportation" added to "Create new tour" dialog. For timetable linked Means of Transportation, the user is now required to enter end date/time for the tour, which will be scheduled with the normal manual ETA process; meaning the manual tour end is handled via last tour stop and visualized in GPB Gantt. On the tour header, the original [system] plan date remains as plan value.

Today the GST filtering by date (and same in Disp. light - Tours) is too complex and slow, relying on planned, confirmed, estimated datetimes on various tour stops.
We simplify this by adding two new fields to tour header, always containing earliest start datetime (among planned, eta, confirmed) and latest end datetime (among planned, eta, confirmed).

And then we use these fields in the date filter instead of the current complex query.

Populate the new fields.

Populate the new filter fields in Resource assignment table.

UN numbers of the Dangerous goods from the TROs are now displayed in Orders tab in lvl3 on that tour stop.
When we have multiple DGs on a TRO, we sum up and display all UN numbers per TRO separated by comma (,).

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 and CAP50 release.

Improved processes include:
- Filtering tours in GPB 'Tour dispatching' screen
-- 50% improvement compared to CAP50.
-- Additionally fix a bug that caused extremely slow loading times if "GPB template data access was used" (See 119383)

- Filtering transport legs in GPB 'Tour dispatching' screen
-- Improve performance of the dispatch sector filters.

- Multi-select resources in GPB 'Resources' screen
-- 90% improvement when selecting multiple resources by holding down Ctrl button (past/future assignments of the resources are no longer loaded if Ctrl-button is pressed)

- Tour capacity summary (capacity boxes in Gantt screens)
-- Up to 90% improvement in calculation time of capacity boxes in Lvl1
-- Streamlined calculation logic is following criteria is fulfilled:
--- all goods are either loaded and on the first stop or unloaded on the last stop
--- all resources are used throughout the entire tour
--- if vehicles of the tour have differing capacities in different countries, the tour must stay inside one country (doesn't matter if the differing capacity is defined for a country that this tour doesn't visit)
-- If the tour doesn't fulfill the abovementioned criteria, it will fall back to the old slower calculation logic.

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.

For better user experience several simple D365 dialogs within GPB have been replaced by faster GPB dialogs. E.g. 'change addresses', 'change means of transportation', 'change cross-dock depot', etc.)

Vehicle description is no longer shown, instead vehicle id is shown.

The initial CAP50 version of Driver app did not work with CAP43 version of the Driver app middleware. This middleware was used with CAP43-CAP47 releases - of which CAP47 is still supported.

The app update was unintentionally published in Google Play Store in calendar week 47, and the Android APK was published in LCS.

Driver app version CAP50.1 fixes this issue.

Now also unsuccessful attempts of rearranging the tour stops are stored in Online check log, as originally intended. Note: only attempts that reach D365 are logged. If the device is offline and therefore the user is not allowed to rearrange the stops, nothing is written to the log.

If the Means of transportation type of an order or a tour is "Timetable linked", don't allow Distance & Time calculation or Sequence optimization.

The current advanced mode allows to split a tour in several segments and calculate each of the tour segments with different truck attributes, weights, dangerous goods etc. - This allows to have more precise results, especially for special transports where e.g. empty and loaded truck makes a difference which route can be taken. It is constructed by the TAL solution 'overusing' PTV xServer which could not provide this. Downside was performance.

This 'constructed' mode is replaced by a new own PTV xServer "advanced mode" feature which will be simpler to use, with less webservice requests.

A previous limitation for CO2 calculation using electric vehicles was fixed by enhancing the request sent to PTV with a new parameter co2EmissionClassEU, which includes the electric vehicles in the CO2 calculation.
A validation for emissionStandardEU was also implemented: in both Vehicle and Vehicle type forms, if the engine type selected is 'Electric', then the 'Emission class' parameter is automatically set to "Undefined" and disabled for user changes.

Bing maps used to show the Transport address based on the coordinates of the address, not the details in the address form. However, this was broken with some Microsoft changes, and a code enhancement was needed for the feature to resume functionality as previously.

The 'Goods planning status' tab, which contains the grouping 'GPB icon visibility (four different flags) has been moved from previous location in Transport Parameters, to new location in GPB parameters.

This data migration job ensures that the values of the flags contained in the 'Goods planning status' tab in Transport parameters are properly transferred to the new location (GPB parameters), based on changes done in task 117265.

A new field 'Department' has been added to the Optimizer dispatching form.
This field is initialized with the user's department, as defined on Worker (if any), but can be overwritten with any other value available from lookup.
If value is selected in this field, all TMS tours resulting from respective Optimizer dispatching run will have that department value initialized on tour header.
If field is left empty, each TMS tour resulting from respective Optimizer dispatching run will have a department value initialized on tour header as per majority of Transport legs planned in the particular tour (if any).
The existing TMS tour header's department value will not be changed when tour is updated with additional Transport legs by using Optimizer dispatching (regardless of what legs are added).
Tour department is also visible on the Optimizer tour header in the Tour plan form.

Previously, when using automated Optimizer dispatching, some errors related to tourplan generation would only be visible in the batch log, not on the resulting tourplan (if any), and end user may not have the rights to consult the batch log. Consequently, these errors have been brought also to the tourplan log.
In case automated Optimizer dispatching finds no records to process, no error is documented at batch log level and no tourplan is generated.

Error 'The driver operating intervals must be disjoint' was returned by Optimizer as reason for process failure in certain cases (for example, when within the time interval polled for Optimizer planning there were already some tours, which were confirmed much earlier than planned. This, in turn, caused some misinterpretation in the building of the Optimizer xServer request).
The root cause was fixed under 118595.

In the unlikely event that some planning quantities on the Transport leg would be <0 (bad data, regardless of reason), the Optimizer dispatching process will stop and display an error with the orders affected by this issue, so that user will be able to correct the data before continuing.

A new button 'Transport legs not planned' is now added to the Optimizer tour plan form. This opens a new form, where all not planned/not plannable transport legs from an Optimizer tour plan are listed and can be checked for planning issues.
Such reasons for the unplanned Transport legs can be queried for maximum 72 hours from the tourplan creation (retention time is set at the level of PTV xServer).

In case of using the 'Extended coloading restriction' option, depending on the setting used for the Optimizer parameter 'Time (in seconds) to check for job status' and the data complexity of the selection itself, the processing time needed for the Optimizer to return a 'Calculated' tourplan has been improved (10%+).

The values in these Optimizer parameters:
- Driving time regulation
- Working time directive
- Fixed break duration
- Maximum tour duration
- Maximum driving time per tour

are moved by this data job to the corresponding fields on all vehicle types.
Full details of the changes implemented in driving break parameterization are found under 119862.

Previously, function 'Restart all 'in progress' jobs' would trigger endlessly all 'in progress' data points, even historical 'in progress' Optimizer jobs (usually corrupt data points), pinging the data source needlessly. A time horizon of maximum 7 days (from current date) was added to the running of the function, so whether triggered manually or via corresponding batch, it would only go over the data points of the last 7 days.

The new 'Driver breaks' feature for existing TAL tours has been described under 110588. The newly introduced feature gives the user greater flexibility and more options in parameterizing the insertion of driver breaks. Consequently, changes were done to Optimizer to make use of the same parameterization:
- all break-related field have been removed from Optimizer parameters; Optimizer will use new parameterization from vehicle type
- data migration job created (see 113340)
- break-related fields from the resource combination plan form have been removed (no data job)

Explanations/Limitations:
- If vehicles from multiple vehicle types are used in the same Optimizer request, the break parameter from the vehicle type of a 'majority of resources' will be used.
- For tours originating from Optimizer, the driver breaks are still inserted as tourstop addresses identical with previous tourstop. This means that the current limitation on any subsequent simple Distance and time calculation around these break stops still exists (to be aligned with the TAL approach to the break tourstops in a next release). Workaround: when driving break stops exist on a Optimizer tour and recalculation of distance and time calculation needed, run 'Distance and time calculation with driver breaks'.
- the new GS buttons ('Distance and time calculation with driver breaks' and 'Remove driver breaks') will remove any automatically-inserted driver break tourstops, but not yet also activities of type 'Wait' which were automatically inserted on other tourstops by Optimizer (for example, to respect customer wish at load/unload).
- When more than one break occurs between two regular tourstops (ex. long FTL tours), the distance and time may not always (yet) be split correctly in between breaks.

Data migration task for 119066.

Data job populates two new fields if the package is created from the WHS processes.

Must be executed in environments with multiple transportation and/or warehousing companies.

Objects that were deprecated in releases CAP35-CAP41 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.

The cross docking split sequence form was enhanced as follows:
- Depot ID was made mandatory before newly added line can be saved
- Sequence ID field is now visible by default, so that user will know the sequence of the new line as soon as it is created
- As soon as the form is saved, the new line will be displayed in the order of sequence (previously, this happened only after an additional refresh action).

Vendor invoice printing form did not properly 'remember' the print setup configured and used previously.

Previously, the Tour activity button in DispLight Tour was only available to users with system administration rights. This was fixed, so that even users with T&L Dispatcher role would be able to view and use this button.

When the quantity of the order line is updated without impacting the quantity in transportation (total quantity of order line related load lines is untouched) then the shipment builder change analyzer must not identify a transportation relevant update.
Although no quantity change was identified in the scenario above, as a result of the way the code had been written, in certain cases, the non transportation relevant quantity change led to a date update. This is fixed in this version.

When changing the dates on the transfer order header to a future date, then it was not possible to update the transfer order lines if they were already in transportation.

Due to technical challenges, this is solved by a fix that enables the user to do the following workaround:
1) on the first - standard D365 - dialog, do not select the update of any of the fields
2) on the second - CAPcargo - dialog, select which fields must be updated.

The Remove not picked shipment line function behaved inconsistently in terms of unplanning entire transport leg depending on whether a single order or multiple orders were selected on the Goods management form.

Conflict 170 is now migrated to the new version of shipment builder.

Due to an error, deleting shipment lines on the Adjust shipment form was not possible, even if the shipment line fulfilled all the hard and soft criteria.

The Partially remove from transportation parameter was designed to enable the user to remove from transportation what is possible to remove if a trade order line has multiple load lines in separate transport orders. Due to an error, this function did not work, meaning that as soon as any of the transport orders was too far in the process (considering the hard and soft criteria) then none of the transport orders were removed.

When the dedicated parameter to treat WHS purchase order line as a non-WHS purchase order line, the transport order creation was not possible for direct deliveries. This is fixed in this release.

The Calculation transport cost feature is now migrated to the new version of shipment builder.

When splitting off a package from a tour (to move it to another tour), the package related package transaction was not deleted, essentially still linking the package to the initial tour. By this residual transaction, issues emerged in the mobile apps and packing slip posting areas.

Shipment line deletion on the Adjust shipment form did not set off the necessary transport lifecycle status update on the trade order line. The necessary trigger is added to the Adjust shipment form in this version.

In environments with multiple transport and warehousing companies, using the same license plate numbers in the warehousing companies can lead to incorrect shared-/over-package creation. This is fixed by introducing a source company id on the CAPcargo package that determines which warehousing company to search for the elements of the shared-/over-package.

Non-WHS transfer order is not shown when Shipment building area filter is used in GPB Transport orders/-legs screen. GPB filter is fixed.

Incorrectly, the packing slip posting for non-WHS sales order ignored the confirmed quantities in transportation and simply used the plan quantities. This is fixed in this version.

In case the transport order was based on transfer order, the load and unload addresses of the transport order were taken from the from and to warehouses of the transfer order.
This is fixed by taking the load and unload addresses from the relevant warehouse address fields of the transfer order header. Meaning that the from and to warehouse don't have to be changed in order to trigger an address update in transportation.

For some customers using the foreign trade standard D365 functionality, the purchase order line import failed due to a CAPcargo related mapping error. The code has been restructured to not block the import process.

A new option is introduced to release to warehouse from transportation: via the Goods management form.
On the Goods management form, the user can decide which transport order lines - more specifically, the transport order line related sales/transfer order lines - he would like to release to warehouse, select them, and release to warehouse only the selected records. In the upper grid, the transport order lines are visible. In the middle grid, the content of the selected transport order line(s).
Please be aware that similarly to other ways of release to warehouse from CAPcargo Transport, this function respects the Release to warehouse reservation scope parameter of the Trade&Distribution parameters form.

The Confirm & finalize tour label is replaced by the Tour execution (Trade) label everywhere in the CAPcargo product.