10.0-CAP41.0 (23.05.2024)

Several validations were added to the process of Optimizer tourplan release:
-- when certain existing tours are modified between the moment they are selected for update with additional Transport Legs via Optimizer dispatching and the moment of the update tourplan release, the update process is stopped and user is warned of the fact that initial tour structure has been modified. Such modifications include deleting from tours Transport legs already planned, or adding manually Transport legs.
--- re-release of a tourplan update is not possible anymore, process correctly stops and user is informed (previously process was not stopped, but resulted in potentially significant errors).

Previously, even if in some constellations, changing of address on tour stop was not allowed (ex. arrival already confirmed on tour stop), the 'Change address' functionality on the tour stop context menu was still available, even though change itself blocked when user confirmed.
Instead, the button is now grayed out, so that user does not need to go anymore through all the steps of changing an address only to realize the action is not allowed.

In very rare data constellations, it was possible to display the tourstart/end date on level 2 tour mouseover as 01.01.01900.

When Transport legs displayed in GBP order screen were already assigned on a tour, the tour ID was displayed on the Transport leg detail box. This tour ID text was now enhanced, so that user can click on it to open respective tour in Tour Gantt screen (same behavior as if user did right click -> Show Tour in Tour gantt).

Previously, the dispatch sector filter in OS/GST only allowed the filtering by a geographical zone defined as a collection of routes as found on transport legs and tours.
This has been enhanced, so that even transport legs/tours which do not have routes could be filtered by using the dispatch sector filter, based on zipcodes found on transport leg points within transport legs/tours.
Thus, the dispatch sector form has also been enhanced to allow also the definition of zipcodes, not just route/zones, to be considered in dispatch sector filtering.
The wizard for zicode generation already in place for route/zone was also brought to the Dispatch sector form, to easily populate the new 'Dispatch sector zipcodes' tab.

The Dispatch sector filter will now display results based on:
-- [OS] Show all transport legs where zip code is defined on the dispatch sector. Furthermore, the dispatch sector was split in two separate filters ('Load dispatch sector' / 'Unload dispatch sector'.
-- [GST] Show any tour which has at least one tourstop address containing a zip code which matches the dispatch sector filter.

Depending on user record selection in GPB screens (no record selected / only one record selected / multiple records selected), some of the functions available on the ribbons did not apply. To make this more user-intuitive, buttons have been disabled so that:
-- if no record is selected, only buttons applicable in case of no selection would be enabled (example: OS screen>Optimizer: Dispatch all / Add all to tours).
-- if only one record is selected, all buttons would be enabled
-- if multiple records were selected, only buttons applicable to multiple record selection would be enabled.

Now it's possible to define geo-coordinates for address areas (such as silos, barns) in D365. Same options are available than on addresses: geo-coding via map, geo-coding via image (=upload a photo that has geo-location in its metadata) or manual input.

If coordinates are set, then a navigation icon/button is shown in the correponding Driver app activity. When clicked, the default map app of the device will be opened, pointing to those coordinates.

A new parameter was added on Activity lines being defined in the 'Activity time per address' tab on the Transport address.
This new parameter, labeled 'Tour stop type' has several values in lookup (All stops / Tour start / Tour end / Tour start & tour end), selection of which determines on which tour stops the particular Activity will be added.
Default value for this parameter is 'All stops' (which was the default behavior of Activity line before introduction of parameter).

Various fields were missing translations in languages other than en-us, due to hardcoded text, instead of proper labeling.

Previously, when user had a certain Transport Type set on the Worker Filter initialization, if transport legs of a different TT than the one on the worker filter were drag&dropped on GS without holding CTRL key, the newly created tour would take the TT from the TrLegs, but would initialize tourstart/end addresses based on parameterization found on the Worker filter TT, instead of the TrLegs TT. Similarly, if transport legs of a different TT than the one on the worker filter were dragged&dropped on GS while holding CTRL key, the 'Create new tour' form would correctly initialize the TT to be used for new tour creation, but wrongly initialize the tourstart/end addresses from the Worker filter TT.
Behavior has been now corrected, so that the TT defined on the Worker Filter initialization would not play a role anymore in the tourstart/end initalization of addresses on new tours.

A new report, labeled 'Proof of Delivery', has been introduced as a new menuitem to the Print section of the Transport Order ribbon.
This report can be parameterized for initialization from new parameters on Customer ('Requests PoD' - this defines whether recipient should get a PoD) and on Transport type (Requests PoD for 'Customer' / 'Load address' / 'Unload address' - defines who should be a recipient of the PoD).
The language of the report is taken from the customer on the transport order.
All 'Requests PoD' flags are placed on Transport order header>Setup tab, as initialized from Customer, respectively Transport type.
Various details of the report layout (logo, lines etc.) can be provided by project consultant, as needed.
New parameter has been introduced in Transport Parameters>Dispatching, labeled 'Recipient name activity', to parameterize activity used to capture the name of the recipient to be displayed on the report.
Report is generated only after entire Transport order is delivered.
The status message setup form Recipient field has also been enhanced with enum values 'Load contact' and 'Unload contact'.

The report can be triggered to be sent as email attachment to the customer/load/unload email address of contact on transport order.

The following new fields have been added to the Vehicle masterdata/Vehicle type/Vehicle wizard forms:
-- Engine type
-- Transmission
-- Fuel type
-- Adblue

Additionally, a 'Cost' summary tab was introduced on Vehicle masterdata/Vehicle type forms, and several fields were assigned to their logical groupings/tabs.
The vehicle creation wizard's 'Technical data' step was also adjusted to mirror the field moves done on aforementioned forms.

Previously, it was possible to change tour stop addresses (including tour start/end addresses) via existing functionalities (GPB>rightclick on tour stop>Change address; GPB>Dispatching>Dispatch>Init tour start/end address; TRO grid>Transport order>Maintain>Change address)) even when some confirmation already existed on the tour stop (ex. Arrival confirmed).
This has now been corrected. Also, the tour start address cannot be changed anymore when tour has been already sent to Driver app.

The following buttons are now utilizing menu items, thus able to be linked to security roles (control of their visibility):
-- Offer to order
-- Address on map
-- Close pre-order
-- Create new packages for all order lines
-- New collective order
-- Conflict analysis
-- Confirm without dispatching
-- Undo confirmation
-- Confirm directly

When user pressed 'Remove cross dock' menuitem (in DispLight TrLegs or in GPB OS), the action was triggered immediately, without further warning. A dialog has now been introduced, asking user "Are you sure you want to remove the cross docking from the selected leg(s)?"

When time windows are used on Transport orders, they are also brought as display methods into the 'Copy order' form. The From/Till fields are now also adjusted to be editable/non-editable, depending on the type of time windows used.

By design, only D365 resources (WrkCtr) existing as CAP vehicles and being part of a CAP vehicle group are supposed to be used in GPB. Like this, we don't need to load too many data of resources which are not relevant for TMS. - This works well in RS, where vehicles are shown by vehicle group.

After a similar issue was fixed in R18, we found, that since R40 in Gantt-Screen-Resource (GSR) also vehicles which are not in a vehicle group are listed again; this is wrong according to the current design. Since GPB does not pre-load the needed master data of such vehicles, dispatching orders to such vehicles (by new function drag&drop from OS to GSR) can lead to corrupt data and unstable situations, due to missing detail data .

Specific example:
By moving a tour from Res 1 to Res2, where Res2 is not in a vehicle-group, it happens, that a resource leg is created without WrkCtrID, because those detail/master data were missing.

When a T&T status message is sent via email, its Sent message status should be set to Sent if the email was sent successfully or Error if it failed. Currently, the Sent message status is Created which is not correct.

This issue doesn't happen in all systems and at this point we haven't been able to identify the cause.

Purpose of this data migration job is to complete the previous release's data migration job on same topic (103523). In previous data migration job, only the Means of Transportation (MoT) on Transport orders was filled in as appropriately. This data migration job considers the Transport legs not dispatched yet in a tour, with MoT blank value, and where the corresponding Transport order does have an MoT.

When geo-coordinating addresses by using batch, the correct logic was used: If PTV response of TOTAL score provides 100% match, then also check the TMS parameters for the single scores of all address elements (zip, city, state, etc). If these single scores are also fulfilled (while also respecting the other parameters like "Min. total score geocoding", "Use best geocoding score" etc.), then classify the address as "fulfilled" (-->Geo-coding failed = False).

When geo-coordinating addresses manually, the second step (checking of TMS parameters for the single scores of all address elements) was skipped.

This could then lead to discrepancies (the same address could not be geo-coordinated by batch, but still doable manually), which was wrong. Manual process was fixed and aligned with batch process.

When Optimizer is able to plan perfectly (so that in the very second when one existing tour ends, the next planned tour begins), the release action of such tourplan from Optimizer would display and log a warning regarding overlapping resources between tours. In this case, there should not be such a warning. Consequently, this is now fixed.

In certain constellations of load/unload/tourstart/tourstop addresses and activities defined on transport address in Waiting time and/or Activity time per address tabs, certain durations were either wrongly interpreted by Optimizer or correctly interpreted (given Optimizer limitations on tourstart/end address activities) but not flagged appropriately to the user. This was now fixed, so that, in case Optimizer is not able to consider in tourplanning an activity duration which is by default inserted on a tourstop by the TMS tour (during tourplan release), a warning is logged with text "Fixed activity time defined on Tour Start/Stop address is not taken into consideration in the optimizer tour. However, the same fixed time is applied on the TMS tour."

In GPB GST, if multiple records are selected, all Id's were properly considered when using custom buttons (ex. custom report printing). In GSR, the same functionality only considered one of the selected records. Behavior was fixed to match GST.

Function 'Change rough plan date' in the GPB Order Screen changed the rough plan date only on the first Transport leg in a selection of multiple legs. This regression has been fixed, so that the rough plan date is properly changed for ALL legs in selection.

In certain sequence of clicks, some tourstop activities generated from instruction activity rules were not immediately visible in GSR/GST when creating a new tour, even though properly generated on tourstop.

In rare constellations, the GPB app would crash with error 'The process was terminated due to an unhandled exception.' A solution to prevent such occurences has been implemented.

"Show tour stop address on map" was not functional anymore in Driver app on devices using TomTom maps after recent version upgrades.

In some constellations tour stops might disappear from the list after the driver had rearranged them. And other stops might lead to "gray screen" when clicked, instead of displaying the tour stop details.

Now the clean-up batch will always remove all "orphan" Mobile app tours (=TMS tour doesn't exist anymore).

In very rare setup constellations, the standard packing slip posting was not properly done automatically for the sales order for the quantity on the purchase order product receipt.

In the Goods management form, the field Number in the Shipment lot details is a hyperlink which, when clicked, should open the related order.
In case the order type is a Sales return order, this hyperlink did not open related order, which was not fixed.

Shipment builder parameterization on Transport type related to changing of load dates on existing shipments was not respected when the date change was done on the transfer order load header (ex. TT parameter = None, but change on header was still allowed). This was fixed and aligned to proper behavior when update done on order line.

Previously, after changing load/unload address on a sales order and updating the corresponding transport order, the message which informed the user about the change wrongly showed the 'changed to' address also in the 'changed from' part of the infolog.

If a postal address is updated from an address suggestion from PTV geo services, the updated address might have wrong data in ZipCodeRecId field. This happens if the selected address suggestion has different zip code than the one that was originally used in the address. Our code which updates the address from the suggstion did not update ZipCodeRecId field, now it does. There's also a data correction job to find and fix existing address data that has this issue.

We believe that it's unlikely that the data issue would impact business processes.

If while using the vehicle creation wizard to create a new vehicle, user adds at least one of the qualifications already existing on the vehicle type, then process fails with error 'Cannot create a record in Vehicle qualifications (CIRTRAVehicleQual). Vehicle: %1. The record already exists.'
Solution implemented was to already display to the user during vehicle creation via Vehicle wizard the qualifications already initialized from Vehicle type, in order to avoid any potential duplicates, which would then lead to aforementioned error.

If at least one qualification was defined both on the vehicle type and on the to-be-copied vehicle linked to that vehicle type, then the 'Copy vehicle' function would fail with error 'Cannot create a record in Vehicle qualifications (CIRTRAVehicleQual). Vehicle: %1. The record already exists.'. This was fixed, so that only the qualifications defined on the to-be-copied vehicle would be written to the new vehicle, with no further initialization of qualifications from the vehicle type.

When sending a Status message, the following sequence for finding the proper email address is implemented:
-- Contact person email with purpose setup on status message
-- If nothing found, then Transport order contact email address
Previously, the first step in this sequence was not respected.

Label 'Order line' was misleading as it was used in "LineId" field of Track&Trace status message template line.
This field is actually used for sorting the lines within a template. Thus, the label has been changed to 'Sequence' (data type of field not changed).

A T&T message was always generated if setup in the T&T message setup, even though it should have been generated only when a substitution record was defined for the particular period.

This is one of the topics of KNOWN ISSUE 104718 (R40).

When a Transport order was subcontracted (directly from TRO, or via direct Transport Leg subcontracting, or via TrLeg subcontracting tour) having multiple lines, and then (at least) one of those lines was deleted, the corresponding line on the subcontracting order was also deleted, but the respective order calculation was not reset. This was now fixed.

Previously, the editing of tour empties on outflow (at address) was not possible during tour confirmation. The issue has been fixed, so that both inflow and outflow fields are now editable on load and unload line.

When using the invoice automation setup wizard to create an invoice automation setup rule on Vendor side, the wizard wrongly created a rule with origin 'Customer', but using the actual Vendor ID in the customer field.

In the package confirmation form within Tour confirmation, the fields for geocoordinates were not editable, with no way to adjust them, if needed.
A new button, labeled 'Correct coordinates', has been introduced in the form header, so that user can manually introduce/correct the values in the two fields. The new function is then disabled after package is confirmed.

When user accessed a subcontracting order detail page, and then tried to refresh it (either by pressing F5 or, in case of page timeout with warning 'Session ended' was displayed, by pressing the 'Start new session' button) ' Error "Error executing code: object does not have method 'args'." was displayed.

The refresh in such cases now takes user correctly back to the Subcontracting order list page.

When multiple tours were selected, conflict analysis was not allowed when triggered from GPB (only from DispTour Light).
Similarly, when release of multiple tours was done via process button, only the conflict analysis result for the first tour in the selection was displayed.
This was now fixed, so that in both cases, conflict analysis can run across multiple tours, and display the results from all tours within the same form.

In some data constellations, the conflict 'Resource - vehicle type not allowed for address' was not properly displayed for all resources involved, even if the vehicle type was correctly setup on the transport address as 'Not accepted vehicle types'.

On Order controlling form, contract/contract version/contract relation can be changed, thus leading to potentially different tariff unit(s). Previously, when such change was made, the tariff unit was not correctly updated on the Transport/Subcontracting order, based on new values of contract/contract version/contract relation. This wrong behavior was now corrected.

The function 'rough scheduling (transport leg)' called on a tour stop is supposed to re-schedule the successor transport legs of this tour stop (if any). Purpose: If this tour is delayed, the successor legs shall be postpone/rescheduled.

The following bug was fixed:
2 legs, +1 day cross dock
- Leg 1: Load 7.2. / Unload 7.2.
- Leg 2: Load 8.2. / Unload 8.2.

Put first let in tour and move tour to 8.2. (tour gets delayed)
Use above mentioned function:
- Leg 1: Load 7.2. / Unload 7.2.
→ Leg (=rough scheduling) not to be updated, as the tour's execution date (=detail scheduling) stores 8.2. => this was wrong, the rough scheduling was overwritten with the detail scheduling
- Leg 2: Load 8.2. / Unload 8.2.
→ to be updated to 8.2., this is the rough scheduling of the successor leg => here all was OK.

Driver creation wizard process cannot be completed if CAPcargo Driver app license is not installed and configuration key enabled.
Known issue will be fixed in R41.1

The new attachment integration (101099) doesn't have the 4 MB filesize limit that the previous integration had. In the previous integration it was not possible to send files larger than 4 MB from D365 to the app. Now this is technically possible, however it's strongly recommended to use smaller file sizes for optimal user experience in the app.

CAP41.0 has been tested with the new PTV Europe City Premium 2024.2H Map material. This allows customers to benefit from the latest available map data in their processes. Your CAPcargo consultant will provide you with the applicable configuration URL to benefit from this map refresh shortly.

Previously in certain scenarios, the browser window opened by user from different GPB functionalities got stuck in status 'Preparing data, please wait...', without any hint that process will not actually continue.

To improve this, a new step has been introduced before the 'Preparing data, please wait...' within the newly opened browser window.
In this initial step, the text "Your request is being processed. If the next phase 'Preparing data' is not displayed within the next 5 seconds, please close this window and try again." is displayed to the user.
An automated refresh is implemented in the background, which should solve most, if not all, cases of potentially 'frozen' browser windows.

However, if this automated refresh still fails, and window continues to display the 'Your request is being processed...' text for several seconds instead of going to the next phase of 'Preparing data...', user can safely conclude that the browser window has become unresponsive, and attempt to open another one.