TopicTitle & DetailsRelease MonthTask typeID
Customer invoicingSmall GUI enhancement of the print invoice/pro-forma dialog: when printing a pro-forma invoice, a 'Print invoice' option is now automatically activated (and disabled for user changes), as disabling a printing doesn't make sense for pro-forma invoices2022-06New feature89210
Customer invoicing
Service level agreement (SLA) is added to customer invoice pool

Service level agreement (SLA) of the orders is newly available in the customer invoice pool and can be used as filtering criteria. Hence it is now possible to selectively launch customer invoicing only for orders that have a specific SLA.
Beside transport order, also part-invoice order is supported.

2022-06New feature89669
Customer order management and pricing
Enhancement of the 'Manually create message' wizard, for transport order track & trace

Following improvements were done in the 'Manually create message' wizard (CAPcargo Transport > Common > All Transport orders > Confirmation > Track and Trace > Manually create message):
- Default Package identification code was added to the grid, both in the second & third page of the wizard
- If multiple packages are selected in the second page of the wizard (Select the underlaying data for the message), existing messages for all of them are newly shown in the third page (Check for existing messages). Previously, system showed on the third page only the existing messages for the active record in the second page.

2022-06New feature89441
Customer order management and pricing
Periodic task for creation of transport order from default order could previously fail in certain situation

The issue was especially happening when periodic task was launched without transport type query criteria (eg. when transport type filter was removed during periodic task set up).

Customer order management and pricing
'Optimization factor' parameter was not respected in 'Calculation transport costs' process

'Optimization factor' (as defined in main TMS parameters) was not respected when calculating the driving distance & time in the 'Calculation transport costs' process. The issue was corrected and the parameter is now used & respected.

Dispatching and confirmation
Improvement of tour delete process, to inform user that some activities are already confirmed

Previously, it was possible to delete a tour that had some activities (but not orders) confirmed, as long as tour was in status 'Dispatching'. This could have happened when tour was released to mobile apps. The weak point was that user was not informed about existence of confirmed activities and tours could get deleted even when they should not.

To improve this mechanism, a new infolog was introduced, to warn user during tour deletion that some activities are already confirmed.

2022-06New feature85752
Dispatching and confirmation
Validate via conflict management, when transport leg date (as calculated via rough scheduling) happens in the past

With certain combination of transport order dates & rough scheduling parameterization, it can happen that transport leg is scheduled to happen in the past. This is possible for example when 'Backward' rough scheduling strategy is used, and via rough scheduling rules the system can find only date that is in the past. In that case the transport leg is still rough scheduled with the calculated past date, but user is newly informed via Conflict350 ('Scheduling - no valid rough scheduling found for this transport leg') in the conflict management on the transport leg (provided that the Conflict350 is activated on the transport type). _x000D_
When determining whether the transport leg rough scheduling date is in the past, the time zone of the address (of the transport leg point) is respected.

2022-06New feature87395
Dispatching and confirmation
Allowing to set up the 'Complete tour execution' process in a way that it closes everything on trade side (ie. shipment synchronization, confirm outbound shipment, packing slip posting), but does not close the transportation side (ie. does not perform the

Key points:
- Previously existing 'Confirm & finalize tour' process was renamed to 'Tour execution (Trade)' as it is focused to 'finalize' trade originating tours (as it contains mainly shipment builder sub-processes). Process now also contains optional sub-process 'Confirm tour(s) directly', to manage whether tour confirmation should be done automatically (or not).
- Previously existing 'Tour confirmation' process shall be used to 'finalize' the pure transportation tours (ie. without shipment builder orders), as it doesn't contain any shipment builder related sub-process. Process now also contains optional sub-process 'Confirm tour(s) directly', to manage whether tour confirmation should be done automatically (or just tour confirmation form should be opened, for manual tour confirmation).
- 'Close tour' was moved into new standalone process, as it makes no sense to activate tour closing sub-process inside both main 'finalize' processes (as several validations are done in tour closing, hence is done typically independently, with some delay)

2022-06New feature88258
Dispatching and confirmation
Wrong tour start date when tour was generated from the default tour (that had some tour sub-contracting activated)

When the tour was previously generated from the default tour (that had some tour sub-contracting activated), then the start date of the resulting tour was wrong (ie. the tour was created with start date of many years in the past). The issue was corrected and the tour start date is now taken again from the default tour planning dialog.

Dispatching and confirmation
Merging of all tour lines didn't work when tour stops were not direct neighbours

Merging of all tours lines (even when tour stops were not direct neighbours) was previously working in the older TMS releases, but was not possible in 10.0-CAP25.0. This task restores the original feature and tour stops can now be merged again even when not being exactly direct neighbours.

Dispatching and confirmation
Transport leg 'Plus days' parameter was sometimes ignored in the rough scheduling of transport legs

The issue was especially happening when 'Transit scheduling' plan date control was activated on the route/zone, but no valid transit schedule was set up. The issue was corrected and 'Plus days' transport leg parameter is applied in rough scheduling even when no valid transit schedule is found.

Dispatching and confirmationPacking slip was previously not generated during 'Confirm and finalize' tour process, when sending via email was specified in print management2022-06Bug88836
Dispatching and confirmationGPB gantt bar extensions for delay/earliness (aka. red or green bar extensions for customer wished date & time) were previously shown in the GPB gantt screens even when the detailed scheduling was deactivated in the transport type2022-06Bug77585
Dispatching and confirmationLong GPB client closing times, when GPB client was launched with wrong Azure Service Bus parameters2022-06Bug88121
Dispatching and confirmation
Wrong driving distance & time calculations between tour stops (happening only in very specific constellation)

The previously released fix (task 89304 'Wrong driving distance & time calculations between tour stops', in release 10.0-CAP25.0) corrected most of the cases, with one (rather hypothetical) exception - when the driving time & distance of the tour was previously calculated in 'kilometres' but the default distance unit was then switched (in main TMS parameters) into 'miles'. Then further re-calculation of previously existing tours was showing the wrong results. The behavior was corrected.

Dispatching and confirmation
Missing refresh of the tour activity and resource assignment section in the GPB gantt screens, after tour deletion

Previously, when tour was deleted in GPB gantt screens, then the tour activities and resource assignments were still shown in the uppert part of GPB gantt screens (ie. in Level 2). The issue was corrected and the tour activity (and resource assignment) section is now automatically refreshed, after the tour deletion.

Dispatching and confirmation
GPB didn't reflect the confirmed departure in tour stop overview

Previously, when departure from tour stop was confirmed (but the 'Driving time and distance' confirmed was still not confirmed), the tour didn't show as departed in GPB gantt screens. The behavior was enhanced and 'departed' visualization of the tour stop in the GPB app is newly following the state of 'Departure' flag of the tour stop.

Dispatching and confirmation
Impossibility to select multiple tours in both GPB gantt screens

Previously, in both GPB gantt screens, the multi selection of tours (eg. selection of several tours, for mass tour 'Release for departure' etc.) was sometimes not possible (ie. the previously selected tours were automatically 'deselected'). Tour selection mechanism was enhanced and is reliable now.

Dispatching and confirmation
Problematic refresh of the tour in GPB 'Resource Dispatching', after performing the 'Release for departure' on multiple selected tours at once

When performing the 'Release for departure' in GPB 'Resource Dispatching' screen on multiple selected tours, then occasionally the tours failed to refresh automatically (and the refreshing spinning wheel stayed on the screen). The issue was especially noticed on the tours that were submitted to driver app (but could also happen on other tours). Issue was corrected.

Dispatching and confirmation
Enhancement of the change of tour start/end address (to better handle the cases where tour start/end already contains some orders)

Processes via which it is possible to change tour start/end address were enhanced, to better handle the situation where tour start/end already contains some orders. When such situation is now encountered, the tour start/end address is changed and the orders are moved into new tour stop (still with the previously existing address).

Following processes were affected:
- Change tour start in D365 'Dispatch light - Tours' when there are orders in tour start
- Change tour end in D365 'Dispatch light - Tours' when there are orders in tour end
- Depot split (tour line) when tour end has orders
- Change tour start/end via GPB

2022-06New feature89281
Dispatching and confirmation
Sequence optimization can be newly launched only until the tour is departed

Previously, it was possible to perform a sequence optimization even on tours that were already departed. This could lead into unexpected situations on the tour stop structure, especially when some tour stops were already confirmed.
Newly, the sequence optimization can be launched only for the tour which first tour stop is not yet 'Departed'.

2022-06New feature89300
Dispatching and confirmation
Performance improvement of the 'Tour routing rule' finder (via which it is possible to insert waypoints to the tour)

The performance improvement was purely technical - by adding a new table index.

2022-06New feature88586
Dispatching and confirmationPerformance improvement of the 'Merge all tour lines' feature on both GPB gantt screens2022-06New feature89037
Dispatching and confirmation
Several enhancement of the sequence optimization process on the tour

1) Performance driven enhancement of the sequence optimization process, to avoid submitting the sequence optimization query to PTV when there is nothing to optimize. Following cases are now validated:
- Tour has only two or three stops
- Tour has four stops and:
- Tour start and second stop have same address, and tour end and third stop have same address
- OR all orders are on second and third stops

When above cases are encountered, then the sequence optimization (ie. query to PTV server) is newly skipped, as it cannot produce any different result on the tour stop structure.

2) The 'Sequence was optimized for tour...' infolog is newly populated only when the tour stop structure was altered via sequence optimization process. (Previously the infolog was shown even when sequence optimization process didn't have any effect on the tour stop structure, which was misleading for the user).

3) Duplicate launch of the driving distance & time calculation is now avoided.
As the driving distance & time calculation is launched automatically as part of sequence optimization process (but can be also activated separately, eg. via 'Automatic distance determination' or via 'Tour distance/time calculation in real-time' main TMS parameters, or via 'Distance and time calculation' parameter in the 'Release for departure' process), the logic was enhanced, to avoid that it is launched several times unnecessarily.

2022-06New feature89078
Dispatching and confirmation
Endless 'loading wheel' could be sometimes encountered in the GPB 'Resource Dispatching' screen (special case)

The issue was encountered in GPB 'Resource Dispatching', in following special constellation:
- when tour had already several resources (eg. Driver1 & Driver2) and user was selecting the tour for one resource (eg. Driver1), then when user was adding new resource (eg. Truck1) to tour via drag and drop, and was dropping the Truck1 resource to the position of Driver2 tour, then the endless 'loading wheel' was encountered.

The issue was corrected and resource assignment is now refreshed correctly (even in above described special constellation).

Dispatching and confirmationAfter sequence optimization was performed on the tour, the tour stop details in GPB gantt screens were not automatically refreshed2022-06Bug89999
Dispatching and confirmation
Tour sometimes disappeared from GPB 'Tour Dispatching' screen, when a resource was removed from the tour

The issue was happing only in the GPB 'Tour Dispatching' screen and only in certain constellations.

Dispatching and confirmationOpening 'Track and Trace status' from GPB 'Resource Dispatching' screen (from context menu of 'Order' tab, on the tour stops) was sometimes not possible2022-06Bug90045
Dispatching and confirmationMissing 'intercompany' status icon in the tour details (in level 1), in GPB 'Resource Dispatching' screen2022-06Bug90055
Dispatching and confirmation
Certain dispatching actions sometimes could not be executed on GPB gantt screens, the D365 browser window was not loaded not correctly (ie. only blank window was opened)

The issue was happening especially for the following dispatching actions:
- Tour stop splitting
- Tour stop depot splitting
- Qualifications opening

Issue was corrected and D365 browser windows are now loaded correctly.

Dispatching and confirmation
Performance improvement of initial tour stop detail loading in GPB gantt screens

The performance of initial tour stop detail loading in GPB gantt screen was improved, by removing certain elements from the initial loading into separate background service(s).

Following elements are now not loaded directly during initial tour stop loading (eg. when selecting a tour), but are only loaded later (via background services):
- capacity checks on the tour stops
- work instruction status icon on the tour stops

2022-06New feature89326
Dispatching and confirmationIn order to mitigate development efforts when release date changes, GPB client main menu now shows only release month (previously the exact release date was shown)2022-06New feature90404
Driver AppMitigating the 'Failed to connect to MSAL' error in driver app, when using the 'Sign in with Microsoft' authentication method2022-06New feature89212
Driver App
Having more than one active tour stop in the driver app

In driver app, in general it is allowed to work always only on exactly one tour stop. In other words, confirmation of arrival on other tour stop should be possible only after departing the current stop. The issue was that via rearranging the tour stop sequence in the driver app, it was previously possible to achieve the constellation where the arrival to new tour stops was confirmed, without departing from previous stop. The validation in driver app was improved, to avoid such constellation.

Driver AppCustom tour stop sequence was sometimes reverted in the driver app without informing the user (missing infolog in driver app)2022-06Bug89559
Driver App Mobile app users could not logout from the mobile apps, when underlying D365 backend application was not available2022-06Bug89631
Driver App
Taking higher amount of pictures during some processes might previously destabilize (and crash) the Driver app

The issue was experienced for example during the failed delivery registration, where many documenting photos were taken. Then from certain amount of pictures taken, the app started to perform poorly (as more and more app storage was consumed), until it ultimately crashes. Afterwards, the driver app would not start again anymore, until cache and storage was cleared.

This fix improves the handling but doesn't fix all the related issues. Therefore it's not recommended to add more than 1 picture when using the "Skip all remaining activities" process = swiping Depart when unconfirmed activities still remain.

Additionally, to overcome some issues on big tours we have reduced parallel processing in the app (temporary solution), which means that the app UI is blocked by a "Syncing" dialog when the user confirms activities that trigger a sync (=First activity of the tour, and last activity of all tour stops). This adds waiting time of about 30 sec per sync.

Driver App
Mobile app export periodic tasks should be recreated after installing new CAPcargo licenses

We have noticed that the mobile app export periodic tasks might fail in some systems after installing 10.0-CAP26.0 release with new licenses. This doesn't happen always or in all systems, and seems to be related to a bug/glitch in D365 Recurring integrations framework (similar issues were experienced also in the past).

As a pre-emptive measure it's recommended to recreate the jobs after installing 10.0-CAP26.0 and the new licenses, by following the instructions in chapter "Recreating the export jobs" of "CAPcargo Mobile apps - Setup instructions for customer systems" document (

Service action can be done by any user with sufficient access rights and knowledge in the Data management module.

Driver App
Wrong license configuration key in mobile app tour composite entity

This entity was previously to "Driver app" license configuration key, which caused that truck loading app could be run only when 'Driver app' license configuration key was activated. The issue was corrected and mobile app tour composite entity is now linked to 'Mobile app base features', thus it is now possible to set up truck loading app also without driver app license.

Additionally, 'Modules' property was not filled on the 'Mobile app activity feedback' entity (is now correctly set to 'TALTransportSolution'), hence the entity now shows up correctly in the Entity model view.

Driver App
Confirmation of 'Wait' activities in driver app was not handled properly

Several issues were identified, in the area of 'Wait' activities handling in the driver app:
- when confirming a 'Wait' activity in the driver app, the original 'Wait' activity was not confirmed in D365 backend (on the tour stop), but a new 'Wait' activity was created.
- skipping a 'Wait' activity confirmation in the driver app also created a new 'Wait' activity in the D365, which then sometimes lead to 'Mobile app activity XYZ already exists' exception and could completely block further processing of feedbacks for the whole tour.

Both issues were corrected, the planned 'Wait' activity (if it exists originally in D365) is newly send to app as 'Other' activity (which is a general type for all activities that don't have any special characteristics on the app side), and 'Wait' activity in driver app is reserved for cases when driver spontaneously reports the unforeseen waiting activity.

Driver App
Missing activities in the driver app, when tour was generated from default tour template

Previously, when tour was generated from default tour template, all tour activities were considered as 'optional' in the mobile app tours. Which was not according to general mechanism (ie. all tour activities shall be by default considered as 'Mandatory for mobile apps', unless they are configured as 'optional' via instruction activity rules). The issue was corrected.

Driver App
Driver app load activity was sometimes marked as deleted

The issue was happening when asynchronous change tracking mode was used (and some stop was split in D365 backend)

Driver App
Missing driver app feedback messages in certain constellations

When working with big tours (hundreds of activities) the app sometimes loses some of the feedbacks (=confirmations/swipes) and the related orders/packages are therefore not confirmed in D365.

Several improvements have been made but it's still not a perfect solution.

To overcome this issue we have reduced parallel processing in the app (temporary solution), which means that the app UI is blocked by a "Syncing" dialog when the user confirms activities that trigger a sync (=First activity of the tour, and last activity of all tour stops). This adds waiting time of about 30 sec per sync.

Driver App
Enabling return order creation also for tour start

In unplanned return order process, new orders were added (planned) to tour stops. But return order creation was not possible for tour start, as D365 backend system had a validation that prevented adding orders to the tour start stop. The behavior was changed and the creation of return order at tour start is now enabled from driver app.

2022-06New feature83210
Driver App
Incomplete confirmation of driver app tours in D365 backend

Previously, when driver was rearranging (and confirming) a custom tour stop sequence in the driver app, this could lead to incomplete tour confirmation in the D365 backend. Especially the driving time & distance confirmation was sometimes missing. The issue was corrected and the custom tour stop sequence is now better reflected in the D365 tour confirmation when processing the feedback from the mobile app.
Additionally, new menuitem 'Show confirmed sequence' was added to tour confirmation form (that is accessible when tour stop sequence was re-arranged in the driver app), to be able to switch between originally foreseen & rearranged tour stop sequence.

Driver App
Enhancement of the mobile app tour clean up & instant message clean up

Following enhancement were done in the mobile app clean up functionality (accessible via 'Clean up Mobile app' form):
- Correction of the clean up infolog, which previously sometimes informed about successful clean up (but no mobile app tours were actually cleaned)
- Mobile app tours with status 'Done' and 'Confirmed' now can be cleaned up via 'Clean up Mobile app' form. (Previously, the clean up was possible only for 'Done' mobile app tours)
- Certain code adjustments, to avoid using obsolete Microsoft methods

2022-06New feature86827
Business hours and customer wished dates were not respected in the sequence optimization of the tour

Following optional parameters were previously not respected during sequence optimization of the tour:
- 'Respect business hours'
- 'Respect customer wish'

The issue was corrected and both parameters are now reflected in the sequence optimization algorithm.

IMPORTANT: Usage of business opening hours in the sequence optimization algorithm has limitations, it is NOT an optimizer. This is the supported scope:

Simple geographical sequence optimization (ie. when no optional parameters are activated)
- Not considering business opening hours
- Not considering capacities
- Just geography and load/unload rules (load not before unload)

The following additional options are available, with currently clear limitations, see below.
- Respect business hours
- Respect customer wish
- Unload all before load

Sequence optimization with respecting business opening hours / customer wishes
- customer wish is stronger than business opening hour
- it can only shift stops, which in the best case leads to matching business opening hours
- it cannot insert wait activities
- it cannot postpone tours to next days
- it does not handle capacities
- combinations with further requirements (e.g. First unload all, then re-load) can become difficult quickly
- Example: it can solve simple cases such as 1 out of 20 orders should be delivered in the morning, not in the afternoon.
- If no valid solution can be found, it will not optimize and through a warning

Sequence optimization with respecting “First unload all orders before new orders are re-loaded”
- Additionally to the above features, here a prioritization of orders is respected
- Example: Tour has 10 unloads all from same depot, and then some re-loads back to same depot
- Without this option activated, the optimizer would just optimize by geography and mix loads and unloads (of course respecting load before unload PER ORDER)
- With this option activated, the optimizer unloads first all orders to empty the truck, and only then starts recollecting orders back to the depot. This might not be the most optimal geographical sequence

Document import 'error' status records are now included in the re-processing (both manually and via periodic task)

Previously, document import was failing when there was no transport order existing in the system yet (which happens if the document attachment is received faster than the actual import transport order process is finished). Then the records in error state could not be reprocessed, unless manually set back. This mechanism was not compatible with fully automated import as that would require that someone has to monitor the queue and has a manual daily task on resetting the status back.
The logic was thus improved and the 'error' status records are newly included in the re-processing (both manually and via periodic task).

Additionally, hard criteria of the periodic task were removed and users can now use a date range (dayrange -7,0) for example to only process records from last 7 days.

2022-06New feature89367
Master data
'Geo services: Geo-coding failed' warning infolog, when changing the country during registration of new address

Previously, when changing a country during registration of new address, system (in some parameterization constellation) launched automatically an address geo-coding process, despite no address details were entered yet. The address geo-coding process then failed and user was informed accordingly. The issue was corrected and address geo-coding process is not launched anymore immediately after country change.

Master dataImpossibility to create new a D365 address, when CAPcargo Transport module is installed (but its license is not valid)2022-06Bug87940
Other / General
Refactoring of email handling

Previously, certain email handling in transport module was done via SrsProxy & SysEmailBatch code/classes. Both functionality will be generally deprecated by Microsoft in some future D365 platform release. As a preparation, email handling in transport module was refactored, to stop using above mentioned classes.

Following processes was adjusted:
- Customer invoice printout (when invoice report is sent via email)
- Emailing from GPB app
- Track & Trace emails

Changes were done on the code level, without any impact on the functionality & end user experience.

2022-06New feature86139
Other / General
New certificate in the ISV licenses for CAPcargo solution - new licenses must be obtained from CAPcargo and installed to all environments with 10.0-CAP26.0 release

ISV licenses are always related to a security certificate. These certificates expire every 3 years, then a new certificate has to be issued. Which happened recently and this means that old ISV licenses from CAPcargo will not work with 10.0-CAP26.0 and newer versions.

CAPcargo provides new licenses to all customers and these licenses must be installed together with this release. Instructions for installing ISV licenses can be found in the CAPcargo installation instructions which is published with every release (CAP_Transport_And_Logistics_10_0-CAP_26_0_Installation_Guide).

If you're using CAPcargo Mobile app features, please note following release letter item:
89806 Mobile app export jobs might fail after installing new CAPcargo licenses - jobs should be recreated

2022-06New feature87093
Other / General
Data migration job - to preserve the previous parameterization of "Close tour".

Data migration task for 88258.

Data migration task restores the previously existing activation of 'Close tour' sub-process, in the new standalone 'Close tour' process (by setting the 'Show process button' state)

2022-06Data conversion89768
Shipment Builder
Deactivation of the TALNameIdx index on the D35 sales line (task only effects projects that use the historical version of shipment builder)

Index TALNameIdx on the D365 sales line was deactivated, as it could cause database synchronization errors when the sales line name was excessively long (ie. more than 1000 characters).

Please note:
- For projects, that are still using historical version of shipment builder (ie. activated via license configuration key 'GUI/Logic old Shipment Builder (based on InventTrans) *** NOT SUPPORTED ANYMORE ***'), the index deactivation will have a negative performance impact on the 'Product name search' on the transport order form. Such projects are advised to either re-implement the index activation in CUS layer, or implement the product search functionality (that is used with the currently supported shipment builder) to the transport order form.

2022-06New feature89694
Shipment Builder
Package identification is newly added to the TMS package also for the custom work line and for the packing station

Package identification code was previously added to the TMS package only when auto-containerization was used for picking in the warehouse. This was enhanced and package identification code is newly added to the TMS package also for the custom work line and for the packing station. This also allows an integration between warehouse labels and the barcode scanning (in the mobile apps).

2022-06New feature89278
Subcontracting/IC order management and pricing
Removal of unused fields in the sub-contracting tour report

Previously, sub-contracting tour report contained fields that were never utilized (eg. transport quantity, transport unit, planning quantities & planning units). As the fields were always empty on the report, their labels were also suppressed.

2022-06New feature88386
Subcontracting/IC order management and pricingCalculation flag was previously not reset on the Tour sub-contracting order (FTL), when resource assignment was changed (eg. resource assignment was changed to serve only a part of the whole tour)2022-06Bug89502
Truck loading App
In certain specific constellation, tour confirmation sometimes could not be finished

The issue was happening only when tour stop split was performed on some tour stop (that was supposed to be released for depot loading, but was not yet released), and the address was changed on the new tour stop to some 'non-depot' address. The tour stop then wrongly kept the 'Open' depot loading status, and such tour stop could not be confirmed (hence also the whole tour confirmation could not be finished). Even further attempts with 'Undo Release to depot' & Release to depot' processes were not helping.
The issue was corrected and 'Release to depot' status is newly reset to 'None' or to 'Open' (depending on the tour stop address).
Additionally, 'Release to depot' and 'Undo Release to depot' processes were enhanced, to ensure that they can correct such situation in the future, if it ever happen again.

Truck loading App
Sending a tour to truck loading app could in some cases previously fail

The issue was happening especially when tour contained tour stops of transport type (for which no capacity was defined). Then sending of such tour stop to truck loading app failed (which is correct), but the issue was that the sending process stopped entirely (and further tour stops were not processed/sent, even though they have sufficient capacity). In such cases the user was also misleadingly informed that tour will be sent to truck loading app, but it was not.
The issue was corrected and sending of tour to truck loading app is now not stopping upon capacity validation but is processing also further tour stops.

Dispatching & confirmation
KNOWN ISSUE: Registration of failed pickup is not possible if backward scheduling and "retry on same transport order" is used

If Transport order uses Backward scheduling, processing of failed pickup fails if retrying on the same transport order.

When trying to report failed pickup (via D365 tour confirmation, but happens also when processing mobile app activity feedback) the process fails with following error message: "Cannot edit a record in Transport legs (CIRTRASalesWay). The operation cannot be completed, since the record was not selected for update. Remember TTSBEGIN/TTSCOMMIT as well as the FORUPDATE clause."

2022-06Known issue90520