10.0-CAP50.0 (19.11.2025)

A screen "paging" has been introduced to claim management screen, to better handle the filtering of larger amounts of claim orders.

Additionally, the carrier name on claim order is populated from the 'Recipient reference' of claim order.

Following improvements were done to subcontracting request process:
- If some subcontracting request direct release is not possible (after "OK & Release" button is pressed, in subcontracting request creation dialog), user is newly informed which requests could not be released
- Multiple same carrier subcontracting requests against one tour were not possible, as previously assigned carriers were not shown in the subcontracting request creation dialog. This was enhanced in the following way - for rejected/cancelled/closed subcontracting requests, its carrier now appears again in subcontracting request (on left grid) and can be further reuse for subcontracting request creation. This allow to add additional subcontracting requests for carriers who previously rejected (eg because price was too low etc.)
- 'Price calculation' button behavior was adjusted in carrier portal, to only get the calculation data (previously, the price calculation could be launched from the carrier portal, which was not foreseen).
- 'Price calculation' button behavior was adjusted in carrier portal, to be disabled in following cases:
--- subcontracting order (or request) is created with "Invoice=No". As for such cases the invoicing & pricing is not foreseen.
--- subcontracting order (or request) is created with "Invoice=Yes", but price calculation is not yet existing

Screen filters on carrier portal were improved, newly orders (and tours) that anyhow intersect with the filters (ie. load date/start date, unload date/end date, or both) are included in the filter result.

Automated data refresh has been added to following actions:
- Setting tour as departed
- Direct tour confirmation (1:1)

Previously, only claims (that had some worker assigned) were shown in the portal. The issue was corrected and claims are shown in the portal regardless of the worker assignment.

Previously such case was not supported, as validation was always applied, to prevent it.

New parameter "Mixing of LQ in package not permitted" has been added to Hazardous material regulation, to be able to deactivate such validation.

Amount of records shown in the workspace tile previously did not correspond to the amount of records once tile was opened.

The issue was caused by not clearing the "Block part delivery" order line flag during copying of order.

When Transport Type parameter 'Date initialization load/unload' = Dynamic AND a route/zone used on a Transport leg was setup for 'Transit scheduling', the TRO function 'Load/Unload scheduling date options' did not properly identify the Unload date based on transit days.
This was now fixed, so that whenever pickup or distribution legs are initialized from routes with transit scheduling, the dates are properly considered by the 'Load/Unload scheduling date options'.
The issue is still present on direct or delivery legs initialized from routes with transit scheduling. This will be fixed in the next release.

Previous info message "Geocoding for address 'XY, Location ID: , Address name: (RecId0)" was misleading when creating one time address (as it gave impression that address was not created). The info message was replaced by a better fitting one.

In dangerous goods dialog, the "NEM (kg)" field was previously sometimes saved with extra 0 in front of the number itself (eg. "010" was saved instead of "10"). The issue was corrected.

Following issues were corrected:
1) Empties were not previously not recalculated after transport quantity change, in order creation dialog
2) following dangerous goods values were handled wrongly when creating dangerous goods on the portal:
- 'Main danger'
- 'Side danger 3'
- 'PackCode'
- 'Additional description'
- changing of material code previously did not reset 'NEM weight' & "NOS technical description" to defaults

As these screens have usually different needs (than order management), the default filters on these screens are not anymore initialized from the default filters on the portal user.
Newly, both screens are now launched with empty date filter (and sorted newest on the top), with default pagination. To ensure that only last xx records are loaded from D365.

Screen filters on customer portal were improved, newly orders that anyhow intersect with the filters (ie. load date, unload date or both) are included in the filter result.

Both customer & carrier portal were enhanced.

Technical update, with no impact on the current GUI.

Both portals were updated, to use the latest recommended MUI version (which is a tool for general portal visualization).

As a preparation for removing the "System user" security role from the service portal user, the SSRS reports were adjusted to not require "System user" security role anymore.

In dangerous goods dialog, the "ADR unit" specification was reworked from "dropdown" style into "button" style.
Previously, the "dropdown" style had 3 values (None, Kilogram, Liter), which was replaced by 2 buttons (for Kilogram or Liters).

On order header, the "Created by" field now shows the portal user, who created the portal order.
For "non-portal" orders, the "Created by" is empty (which is the same behavior as in D365).

Transport unit description has been added to order line detail dialog (in side details pane).
During order line creation, it is possible to override the default transport unit description, which is then save to D365.

Please note: new transport order creation dialog was not enhanced in this release, there the transport unit description is not yet present (and only default one is saved into D365).

The "Trade order information" data/section is shown only when transport order was created via shipment builder (ie. has some trade order data).

Different OIDC authentication providers require different authentication response types. Previously, the response type for OIDC authentication was hardcoded to "code" response type. Newly, the OIDC authenticator connector response type is defined via new Azure environment variable RESPONSE_TYPE.

Possible values of RESPONSE_TYPE variable:
- code
- id_token

Which value should be used - depends on custom OIDC provider implementation/setup.

Both customer portal & carrier portal were adapted.

Please note:
The RESPONSE_TYPE affects only the custom OIDC auth method. The MS authentication is always with "id_token" regardless of RESPONSE_TYPE.

Summary fields (for planning quantities) were moved to the bottom of the dialog and position of several other fields were also adjusted, to better follow the dialog field & process flow.

Additionally, an info message for successful offer creation was corrected (previously the info message related to "order").

Dialog for new order creation on the customer portal newly respect the transport unit conversion rules (ie. rules for initialization plan quantities from transport unit & transport quantity).

Please note:
- The usage of transport unit conversion rules on the portal must be activated by setting a new parameter "Conversion on portal" on the transport unit (in transport type)

Previously, after certain record creation, user could still press "Save" button, which could lead to duplicate record creation. This has been improved and "Save" buttons are not available anymore, once pressed. Following cases were covered:
- new order creation
- new dangerous goods creation

Previously, when an error occurred after clicking "Create" or "Create & Transmit" on the Transport Order form (e.g., due to validation or business rule conflict in D365 etc.), the order creation failed and user was informed by generic error message, and dialog was closed (thus terminating the order creation completely).

Newly, in such cases, the user is returned back to the order dialog, so that he/she could correct the data and "Create" or "Create & Transmit" again.

Following issues were corrected:
- In new order creation dialog, the address contact details were previously not reinitialized when changing the address
- Creation of new contact persons (in new order dialog) was sometimes not possible, as the "Save to address book" icons were not accessible
- Default load/unload contact details were previously not initialized in order creation dialog
- When clearing out the address, the existing contact details were not cleared

Usage of "Enter" keyboard key for order/record creation was suppressed.

The 'env' url (publicly accessible via eg. "www.portalexample.com/env") previously contained several sensitive information. These were removed.

In dialog for new order line creation, "Stackability" field was previously not treated as mandatory, even though stackability setup on transport unit was set to "User must decide".

In Loading process the user can specify a vehicle or compartment where the goods are loaded. In Unloading process the user can specify depot area where the goods are unloaded.

These existing processes have been improved:
- The lookup for target vehicle / location is empty by default, to avoid accidentally using the default value of the lookup
- If the lookup has only one value it will be selected by default
- It's now possible to select values in the lookup by scanning the barcode of the related vehicle, compartment or depot area.

The OIDC login process has been refactored. It's no longer using Firebase technology but a native Android library. The refactored version is incompatible with old middleware versions, therefore CAP50 Depot app should be used only with CAP50 middleware.

In addition to "sad beep", the app will now vibrate the device when the user scans a "bad" (unknown, unexpected, not fitting) barcode. This will help users notice the issue even in noisy environments.

In recent Android versions the user can control app languages separately for different apps, instead of all apps showing in operating system language.
This feature requires support from the apps, and it has now been implemented in Depot app.

This task improves performance and resource usage related to Distinct values in the grid filter panes, in GPB 'Transport orders -/legs' screen

Previously, when changing or applying templates, all grid columns were sent through the web service for retrieving the distinct values for the column, even those currently not visible in the GPB 'Transport orders -/legs' grid.
Although this occurred in the background and did not directly impact user-perceived performance, it resulted in unnecessary data processing and resource consumption. The update ensures that only the required grid columns are processed and transmitted.

In CAP43 a feature "GPB Gantt: Show green 'too-early' bar expansion at early tour start" was introduced.

This feature is now disconnected from Gantt Screen date filtering because it doubled the loading time of tours if any transport type in the legal entity had "Visualize early tour start" set to Yes. The gantt bar extension is still shown but it has no impact in the date filter anymore.

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

Improved processes include:
- Clicking from one tour to another tour in Gantt Screen - Implement caching: now the tour is displayed instantly if it was already loaded earlier, and the tour hasn't changed
- Distance and time calculation: improve the D365 part of the process - up to 17% improvement in the entire process(*)
- Create tour by drag&drop orders(s) from Order screen to Gantt screen - 40% improvement compared to CAP49. 65-70% improvement compared to CAP48
- Generate tour from transport leg - 70% improvement compared to CAP49. 80% improvement compared to CAP48
- Add order to tour - 50% improvement compared to CAP49
- Moving orders/stops from one tour to another - 25-30% improvement compared to CAP49. 35-40% improvement compared to CAP48
- Moving stops to new sequence in a tour - No improvement compared to CAP49. 40% improvement compared to CAP48
- Removing resources from tour - No improvement compared to CAP49. 40% improvement compared to CAP48
- Automatic creation of subcontracting order (when creating a tour or assigning resource to a tour) - 75-90% performance improvement in the subcontracting related part of the process
- Conflict analyzer (opening Conflict management form) - Significant improvement, but depends on the types of conflict that are used in the system
- Conflict analyzer (closing Conflict management form) - Significant improvement, but depends on the types of conflict that are used in the system
- Close a D365 dialog that was opened from GPB - If the dialog was closed with Cancel button we no longer do data refresh in GPB
- "Confirm tour completely" has been optimized
- "Set tour back to released" has been optimized
- Loading orders in Order screen - Minor improvements. And in CAP49 the performance of "Has dangerous goods" column was increased significantly, improving the legs loading time 50%
- Loading tours in Resource Gantt - 50% improvement if "Visualize early tour start" is enabled on any transport type in the legal entity. See also 118244 "'Visualize early tour start' - don't consider in GS date filtering"
- Multi-select tours and show on map: 70% improvement(**)

(*) Most of the process is spent in the PTV geo server. Performance of this part depends greatly on the needed features. Especially 'Preferred routes' and 'Traffic incidents' have a big impact in the execution time.

(**) This is achieved by not running the tour routing again, instead we use a stored result. This works without issues in our testing, but if it causes unexpected issues it can be disabled by adding this key to the GPB config file:


Disclaimer: the percentages are based on tests in CAPcargo test system. Automatic distance and time calculation was disabled in the tests. Shipment builder was not used. New feature "Deferred calculation" (115357) was used when measuring CAP50. Results in customer systems can vary based on environment sizing, data constellation, system load etc.. 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.

Dangerous goods/ADR icons were sometimes not correct, on the tour stops for waypoints.

In a certain setup constellation, Tour confirmation of Load by using the Depot app was able to generate and display a negative duration value of the Load activity. This did not affect the general dispatching process or data accuracy, but confusing to users as to source of negative value.

The issue was especially happening after certain inactivity time (eg. over lunch time), then the next re-login (to open some D365 dialog from GPB) was previously sometimes stuck in 'Your request is being processed..' window.

Following corrections were done in GPB, in area of Subcontracting request processing:
- It was possible to add tour stop to tour that has active subcontracting requests
- Label correction on several places (previously labels for "subcontracting order" were used; were replaced by labels for "subcontracting request")
- Adding error labels when adding/removing resources on tour that has active subcontracting requests
- Subcontracting request status icon (in GPB, in tour gantt box) was sometimes not correctly updated, after certain action (eg. when subcontracting order was generated - the icon sometimes still showed "Ready for subcontracting" etc.)

Such action is not supported (and user was/is informed accordingly). But the issue was that such drag&dropped tour stop was visually disappearing, and was re-appearing only after screen refresh.

Without applying any GS templates on Transport type, in GST level 1, the tour ID is shown on both left side and right side of the tour rectangle. This was now fixed, so that on the right side, the start/end address is displayed (similar to how it is also displayed in GSR level 1).

The conflict was working correctly only when 'Resource Id' was the same as 'Vehicle Id' and the same as 'Asset Id'. In other cases, the conflict 140 was not triggered (even when it should).

When Route/zone was setup as Plan date control = Transit scheduling and a transit schedule active with plus days >0, the TRO Load/Unload scheduling date options function did not properly take into consideration the unload date from the transit schedule, but showed the same as the load date.

Correction of functionality described in 96320 ("New independent CAPcargo Department table and filter"), published in release CAP42.0.

Initialization rules for department process were not working correctly in the following places:
- Tour creation (show field on tour creation dialog), for tour out of route. Newly initializes department from route; if empty then fallback to default (from worker)
- Subcontracting order creation, for "non-tour" subcontracting orders

Further, the initialization for drag&drop of multiple order legs [with potentially different departments] to tour was improved, using the department of the majority of the selected transport legs for the tour.

The parameter value was ignored and system acted as if the parameter was always activated.

Previously, the conflict 2015 "Dangerous goods - maximum LQ weight exceeded" was calculated over all dangerous goods (of a single package), regardless to the material code structure. Which is not correct and was adjusted. Now, the conflict 2015 "Dangerous goods - maximum LQ weight exceeded" is triggered when maximum LQ weight "per material code" is exceeded.

Following dispatching conflict were not triggered, when vehicle requested a qualification (which was not provided by the driver):
- 1233 Qualification - missing driver qualification for motor vehicle
- 1243 Qualification - missing driver qualification for trailer

Correction in finding the vehicle NEM limit if products of different classification codes in tour: Find the SMALLEST limit amongst all classifications codes.
Improvements in conflict handling and threshold calculations, mainly for edge cases.

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.

When a tour stop was split in various scenarios (ex. resource was drag&dropped on a tour (in Gantt screen) which had tourstart/end AND load/unload in the same tourstop and re-initialization of the tourstart/end led to the split of the tour stop), infolog 'Order lines were moved to new tour stop in tour' was shown. This was rather confusing to users as to what exactly happened technically. Thus, the following changes were implemented:
- when orders are moved to other tours, a different label is used for infolog
- when tour stop is split manually within a tour, same infolog is shown, label text was improved
- when tour stop is split automatically within a tour during "Change tour start/end address?" or "Init tour start/end address from resource": infolog not displayed anymore

"Block changes" setting and "Depot App (Loading/Unloading)" checkboxes in GPB gantt screens (in address details side pane) could be previously used only by users with system administrator role.

If the legal entity had no dangerous goods transactions (=at least one transport order that has dangerous goods in it) then the tour stop address name and other address information were not shown in the Graphical Planning Board Gantt Screens.

Certain types of dangerous goods coloading restrictions can be allowed, but the system shows a work instruction to the dispatcher so they can consider the situation in planning. Initially this was implemented in the work instruction framework as a tour stop work instruction. This was not sustainable for performance reasons, requiring the system to evaluate the co-loading restrictions in real time for tour stops.

To maintain good performance the solution was refactored and now the work instruction is shown only in the Conflict management form on the corresponding conflict. New button "Work instructions" has been added to Conflict management form, and it can be clicked on conflict of type "Dangerous goods - Co-loading: Possible special conditions, please check the work instructions."

New conflicts have been created and processes adjusted so that, if a D365 division is linked to a CAP qualification, it would be respected in all CAP TMS processes (conflict analysis, qualification pre-match in GPB OS, visibility in Transport order Qualification Overview, Optimizer etc.)
Warning: For systems where qualifications were already created and assigned to Dangerous goods in forms 'Hazardous material classification code' and 'Danger label', a manual update of new flag 'Valid for dangerous goods' is recommended (no data migration job). This does not affect any functionality except for the visibility of these qualifications in the lookups on the aforementioned forms.

Remove CAPcargo logic for "Buffer changed by another process" which interrupted many dispatching processed in GPB. The logic was analyzed, and deemed unnecessary in most situations so we removed it from almost all processes.

Tour activity scheduler makes sure that the duration of activities is taken into account in the tour duration (driving time + activity time). Normally the scheduler runs whenever a tour is created or orders or stops are added or removed. These are the most common triggers but it's not a complete list. The scheduling adds overhead and waiting time to these operations.

Now it's possible to skip the scheduling and run it only later when scheduling result is really needed. When the feature is enabled, tours that are waiting for scheduling are visualized with a purple bar on the left side of the tour bar in Gantt screens. Various triggers such as Release for departure, Distance and time calculation, Sequence optimization and refreshing the tour will run the scheduler. Additionally a tour can be scheduled manually by clicking an icon in the purple bar. All visible tours (where scheduling is pending) can be scheduled via "Run scheduler" button.

Once the tour has been released to departure it will always return to real time scheduling mode and all updates on it will automatically run the scheduler.

The feature can be enabled via new field "Deferred calculation" in the worker settings (tab "GPB parameters"). Users can see this setting also in Gantt Screen, next to the detail selector, but it can be modified only in D365. We recommend this feature to all users, but like all features it should be evaluated first in a test system.
This feature can't be used together with "Tour cost/revenue statistics calculation in real time". Validations prevent enabling both features at the same time.

Flags for “CO2 calculation values up-to-date” are set to TRUE both on transport order and on tour even though the CO2 calculation resulted in 0 values due to bad setup. This is now improved and flags are updated only when there is a correct CO2 calculation.

Previously, most D365 forms triggered from GPB menuitems were open in a medium-sized browser window. This has been now enhanced, so that all browser windows would open directly in maximized (full-screen) mode.

Added better handling for situations where new orders are added to the tour while the stops are being rearranged. If stops were added or removed, the user is notified about this, and the system places new stops automatically next to tour start (loading stops) or tour end (unloading stops).

The terminology in Empties exchange has been adjusted:
- Inflow has been renamed to Unload.
- Outflow has been renamed to Load.

Also translations in supported languages have been adjusted.

The feature has been redesigned to use an online integration with D365. Changes from the driver will change the tour sequence also in D365. In the old version the driver's changes were local in the app but not visible in D365.

Because of the online integration this feature can be used only if the device can connect to D365 (no offline support).

The new feature must be launched by a new menu button "Rearrange stops" in the tour details screen. Rearranging happens on a separate screen instead of the tour details screen like before. Note that the feature will keep working the old way if D365 and the middleware still has an older version than CAP50.

In previous versions the app could show summary of loaded and unloaded goods on each tour stop. These summaries can now be displayed also on the tour level (Open tours screen) to display the loaded goods on the first stop and unloaded goods on the last stop.

The feature is configured on Transport type in D365.

In order to fulfill Google Play Store requirements, many Driver app technical components were updated. This should have no impact in the app user experience, expect for minor cosmetic changes.

Uploading photos from the user's device has been refactored to match Google's latest policies. The process is still the same but the photo selection process is visually different.

Resolve some edge cases where a Driver app tour that was deleted in D365 could still end up in the middleware, requiring CAPcargo IT team to clean it up from there.

Now the description (not id) of the vehicle is shown for both truck and the trailer. In previous versions the app displayed truck description and trailer id.

In addition to the description the app is displaying the license plate number of the vehicles (no changes in this part, just mentioned for completeness).

A known issue in Microsoft Dynamics F&O can lead to wrong license information to be shown for CAPcargo security roles. This issue is not caused by CAPcargo solution. The issue can be tracked in Power Platform Admin Center: https://admin.powerplatform.microsoft.com/support/knownissues/5855824

Issue ID 5855824: License usage and role data issues
Product: Dynamics 365 Finance
Created on: 11/15/2025 11:22 AM EET

Problem: License usage summaries display incorrect data, show unrelated AOT names, and no longer include group information for selected roles.
Workaround: This issue is being investigated.

Impact for CAPcargo roles: The following 2 roles are not accepted with team member licenses, even though they clearly should:
- T&L Accounts Receivable Clerk
- T&L Portal Service User

With this release it is necessary to use PTV xServer 2.38.
Upgrade was done primarily to solve a critical security vulnerability discovered in previous versions.
Additionally, this version contains features which will be used for future CAP Product developments.

In case that xServer is hosted on-premise, please ensure that the installation is upgraded to 2.38 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.

City / street names can be shown by activation of "Show map style" switch (directly in the satellite map) in "Geo-coding via map".

Following improvements were done for 'CustomerV3' data entity:
- transport address ids (for loading and unloading) are newly automatically populated from 'TALLoadLocationID' and 'TALUnloadLocationID' (if these are provided)
- two recid fields 'CLXTALLoadPostalAddress' and 'CLXTALUnloadPostalAddress' were hidden in the data entity, as these are internal technical fields

New data entity 'TAL Transport order logging' was added to the system, it is now possible to export transport order logs from D365 (the data entity is allowed only for exporting).

Previously, it was possible to use the data entities Commodity translation V2 and Commodity hierarchy translation V2 to export and insert descriptions and translations, but not update them. The data entities are now enhanced to also handle updates.

Additionally, a time zone can be newly initialized also from the State. The new initialization hierarchy is "ZipCode->State->Country", while previously it was only "ZipCode->Country".

Previously, in the Instruction activity rules form, when parameter 'Show only active rules' was set to False, only the lines with a blank 'Valid from' field were shown, instead of all existing lines.

Finance dimension mandatory rules are part of project specific customization, should not be exposed in standard product unless related license configuration key is activated. The issue was corrected and field section is now not shown anymore.

If xServer cloud token was set in the source system, then in the destination system receiving a database copy of the source system (for ex. UAT receiving from PROD env), the geo services would not be functional anymore and the xServer parameter form inaccessible, due to specific encryption errors.

To solve this, the 'Clear xServer cloud token' button was brought directly on Transport parameters > Geo services form. If encryption error appears, pressing this button should clear the encryption error and allow access to xServer parameter form as well as functionality of geo services.

In a particular constellation setup (manual driving break, customer wish on load/unload, circumstantial distance/time between driving break and next load/unload, arrival too early at the tourstop etc/), the 'Waiting' activity was not properly inserted during TMS tour creation resulting from an Optimizer dispatching run.
This was now fixed. However, the 'Waiting' activity could still be wrongly placed 'after' the Load/Unload activity, depending on the Sequence in which the 'Waiting' is setup in the Activities form. Recommendation in this case is to move the 'Waiting' activity higher up in the sequence compared to Load/Unload/Checking goods.

A new periodical function has been introduced in the Optimizer area ('Automate Tr-leg dispatching into new tours') to support the routine automatic dispatching via Optimizer (ex. same route/zone Transport legs, same Transport type, same vehicle type, every day at the same time).
Records can be filtered by various criteria, including dynamic date ranges (plus days).
Optimizer dispatching by batch is available only for use with vehicle groups.
Function is available only for creating new tours, not for updating existing tours with additional Transport legs.
The manual Optimizer dispatching form and functionality remains untouched.

The Optimizer codebase was reviewed and adjusted, to follow best practices and allow for future code extensions.
No UI/UX changes were done, only technical redesign.
All functionalities remained the same.

Tab 'Integration' in Optimizer parameters was moved above tab 'Times management' in Optimizer Parameters, for a more logical top-down process flow. Functionalities related to these tabs are not affected.

Previously, the Optimizer 'heartbeat' mechanism (based on the 'Re-start all 'in-progress' jobs', to make sure that in-progress Optimizer runs are still retrieved even in case of system malfunction) was based on tour plan ID, which was enough, since there was only one xTour iteration for each individual Optimizer run.
With the implementation of the extended coloading algorithm, several xTour iterations may run for the same tourplan ID. This means that the Optimizer 'heartbeat' mechanism had to be tweaked to consider the Optimizer job ID, instead of the tourplan ID.
No change needed in parameterization because of this enhancement. However, based on testing and experience, users may need to adjust the balance between the recurrence of the ''Re-start all 'in-progress' jobs' batch and the Optimizer parameter>Integration>Setup>Time (in seconds) to check for json status, to avoid both excessive PTV requests for status and unnecessary waiting time before starting the next xTour iteration.

Sometimes, dispatching activities ('Load/Unload' and 'Checking goods') were not created in TMS tours when additional Transport legs would be added to them via Optimizer dispatching.

Data migration task for 116528.

This data job is necessary because of the enhancements in the CAPcargo packing slip posting feature. It sets the parameters, so the packing slip posting is done the same way as in the pre-CAP50 versions.

Data migration task for 116528.

This data job is necessary because of the enhancements in the CAPcargo packing slip posting feature. It fills the packing slip id on the CAPcargo shipment lines which is used in the updated packing slip posting logic.

Data migration task for 116989.

In the previous release, Norwegian texts were accidentally shipped inside Danish translation files.
This only impacted D365 UI and Driver app translations. Nevertheless, it is now fixed.

The possibility to copy/paste details from OS grids has now been applied also to GS grids (Activities/Orders) and RS grids (Qualification/Capacity).

A known issues has been identified in the package split off functionality of shipment builder v3: during the split off of the package(s) the link is not properly broken between the split off package(s) and the initial transport leg. Meaning that the same package is connected to both the initial and the new transport legs.
This data constellation causes problems in multiple processes:
- packing slip posting from the tour of the initial transport leg will post the packing slip also for the split off package(s)
- the split off package will appear in the mobile apps of the tour of the initial transport leg and the tour of the new transport leg

(The package split off feature allows the user to move part of the transport leg related packages to a new transport leg. Essentially, doing multiple deliveries for the same transport order.)

This issue exist since at least CAP47 and will be fixed in CAP51.

New additional features are introduced for the packing slip posting function from the CAPcargo tour.
1) New main parameter whether the packing slip has to be posted also for the not stocked items of the sales order together with the stocked warehouse management enabled items. This can be also defined directly on the packing slip posting dialog. (Previously, the packing slip was always posted for the not stocked items.)
2) Packing slip posting for the not warehouse management enabled items. Since in this case, CAPcargo package does not exist with the exact quantities, for the packing slip posting, the CAPcargo confirmed transport quantity is used. If necessary, unit conversion is applied.

Depending on the time zone of the user, the deadline shown on the subcontracting request form was wrongly offset compared to the deadline set in the initial subcontracting request creation process.
This was now fixed, so that the deadline shown everywhere is the same, based on user time zone settings.

In the case of subcontracting orders of type 'Tour subcontracting', the 'Calculated' flag has been fixed so that it would be reset to False when user makes changes on the quantities on the underlying transport order. In this way, there is a clear indication that some quantity were changed (after the subcontracting order successful price calculation), and calculation is no longer valid.

Previously, the deadline field in the subcontracting request creation form was initialized in exactly the number of +days (coming from corresponding Portal parameter) added to the exact user time. Also, the format of the time part of the field was hh:mm:ss.
The format is now simplified to only show hours and minutes (hh:mm) and the initialization is done by adding the number of + days only to the hour of the user time. For example, if user time at the moment of subcontracting request creation is 10:23:53 AM, the subcontracting request deadline time part will be 10:00 AM.

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.