10.0-CAP40.0 (27.03.2024)

When existing parameter 'Use real time traffic data' is set to True, the Distance and time calculation infolog will additionally show any delay provided by PTV which exceeds the number of seconds parameterized in new parameter 'Traffic delay' (Transport parameters>Geo services>xServer parameter>Main).

The usability of Geo services log form has been improved. Additionally a cleanup batch has been added to clean up old logs.

Note: the logging should be enabled only temporarily for troubleshooting purposes.

The user is now able to partially release a tourplan. A new button was introduced on the Tour plan form >Tour headers section, so that user would be able to select one or more of the optimizer tours contained in a specific tourplan and release only those.
When one or more (but not all) optimizer tours in a tourplan are released in this way, the tourplan status becomes 'Partially released'.
This partial release works both on tourplans created from initial Optimizer dispatching or from updating of existing tours.
When parameters 'Auto create TMS tours' and/or 'Auto update TMS tours' are true during Optimizer dispatching, the entire tourplan will continue to be released.

If even one of the addresses on Transport legs sent to Optimizer for dispatching had missing geocoordinates, the dispatching process would be stopped. To prevent this, a new Optimizer parameter was introduced in the Algorithm tab, labeled 'Missing geocoordinate tolerance'.
Three enums are available, and based on selection, the following Optimizer dispatching behavior can be expected:
-- Abort (default value) - process stops if even one address is not geocoordinated. User is informed via infolog regarding faulty address(es)
-- Skip legs - process continues, but Transport leg(s) containing faulty address(es) are skipped from dispatching altogether. User is informed via infolog regarding faulty address(es) and ID of skipped Transport legs.
-- Send all - this enum is available only when Optimization provider = Generic. In this case, all Transport legs are sent to Optimizer for export. User is informed via infolog regarding faulty address(es)

The fields related to overall KPI details on imported tourplans done with Generic provider have been fixed to sum up imported KPI values on the individual tourplan lines.

When releasing tourplans imported by using Generic Optimizer provider, it is generally assumed that the structure of the tourplan is correct. However, a basic check was introduced so that during release, system would check whether the tourplan is consistent in the pairing of leg points (for every load leg point defined in import, there is also a corresponding unload leg point and viceversa). If any inconsistency is detected, it is flagged to the user by stopping the process for that particular tour and pointing out the exact leg point missing via infolog.

When running updates to existing TMS tours by adding Transport Legs to them (Optimization provider = PTV xTour), some of the existing tours may have been assigned additional legs, others may not (depending on parameterization, etc). It was quite difficult to quickly identify which tours did get additional legs. To make this easier, those tours which got at least one additional leg assigned now have in the syntax of the Internal optimizer tour ID (in the OPT tourplan) included the actual TMS tour ID + '-opt_tour_id-' before the actual Internal optimizer tour ID returned by PTV.

Following enhancements were made in the GPB depot filter, when 'Empty' filter option is selected from the Depot dropdown menu:
- GPB 'Transport orders /-legs' screen: 'Empty' filter means that GPB will filter the legs where the Load depot and Unload depot are both transport addresses.
- GPB 'Tour Dispatching' screen: 'Empty' filter means that start tour stop and end tour stop are both transport addresses, not depots.
- GPB 'Resource Dispatching' screen: depot filter stays untouched, it filters by vehicle depot, so here 'Empty' means vehicles which don't have depot set in the Vehicle setup.

continuation of 101979 (from R39).

Vehicle group and driver group were added in the data access template framework.
- Driver groups and Vehicle groups are added in the data access setup form for GPB.
- Empty filter option is not available for Driver groups and Vehicle groups in GPB 'Resource Dispatching" and GPB "Resources" screens, but is available as filter option in GPB 'Tour Dispatching' screen, since here it means tours without vehicles or drivers.
- Previously it was not possible to have filter by driver group and vehicle group and vehicle and driver, once one of these filters was set, the other one was accordingly disabled. Now the filters are enabled and the user can filter by driver group and vehicle group filter, and these combined work with OR condition.
- The Vehicle and Driver dropdowns are filtered based on the allowed/selected vehicle groups/driver groups accordingly, so in the Vehicle dropdown now the user can select only the vehicles from the allowed/selected vehicle groups, same applies for Driver dropdown based on allowed/selected Driver groups. If a Vehicle/Driver is selected and the user changes the selected Vehicle group/Driver group and the Vehicle/Driver is not in the newly selected Vehicle group/Driver group, the Driver/Vehicle selection is cleared.

Order references related specifically to the load and unload addresses are also visible on corresponding tour stops in the GPB gantt screens (and on the corresponding leg in GPB 'Transport orders /-legs' screen).

Load and unload references are shown on the mouse-over on the "i" icon, displaying the them with origin references.

Relevant for customers who don´t use CAPcargo middleware and apps but use the Mobile app D365 integrations with their own app(s).

New fields in Mobile app tour line (TALdraTourLineEntity) - all new fields used in Appointment handling functionality (101335):
- CANDOAPPOINTMENT (0/1)
- APPOINTMENTNAME1-5 (5 string fields)
- APPOINTMENTPHONE1-5 (5 string fields)
- APPOINTMENTTIMETYPE (0: None, 1: Time window, 2: Fixed time)
- APPOINTMENTBOOKINGCODE (text)
- APPOINTMENTBOOKINGCODENEEDED (0/1)
- APPOINTMENTREMARKS (text)
- APPOINTMENTTEXTNEEDED (0/1)

New fields in Mobile app tour activity (TALdraTourActivityEntity):
- BLOCKCHANGES (0: Always, 1: Until signature, 2: Until departure) - used in Correction functionality 100403
- SIGNATUREID (string) - used in Correction functionality 100403
- ENDDATETIME (dateTime) - scheduling information for the activity

New fields in Mobile app activity feedback (TALdraTourActivityFeedbackEntity):
- REFERENCE2 (string) - used in Appointment handling functionality (101335)
- REFERENCE3 (string) - used in Appointment handling functionality (101335)

Note: this feature is in preview and there are known issues which will be fixed in an upcoming CAP release.

Driver can adjust already confirmed activities (only specific activity types) until signature or departure.

Previously, the transportation information that is moved to the temporary work transaction (for work breaks), work header, and work line were related to the pickup tour. The tour that is related to the warehouse where the goods are picked.
In terms of goods cross-docking case – certain amendments had to been done that changes this logic (use delivery information instead of pickup information), however, these amendments do not cover all the warehouse requirements. Therefore, further changes were needed: both the pickup and delivery information have to be moved to the warehouse.

Key points:
Warehouse information (on the work header and work line) were split into pickup and delivery information for the following fields:
- tour
- unloading sequence
- vehicle
- vehicle type

The first (no longer supported) version CAPcargo Shipment builder includes custom fields in InventTrans table. A small enhancement was needed to handle these fields also in Microsoft´s Inventory transactions archival feature. Without this enhancement it was not possible to activate the standard archival feature.

These CAPcargo fields are enabled only if configuration key "Data of Shipment builder (Based on InventTrans)" is enabled. If this configuration key is not enabled, then this enhancement has no functional impact.

In certain data constellations, due to the new tour start/end initialization feature (introduced with 92553 in Release 39), the tour creation via drag&drop of Transport legs on resource empty space in GSR took an unacceptable amount of time, compared with other constellations. This was fixed, so that in identical parameterization, the time needed to perform the same action would be similar.

If Customer account is changed, the system would open a dialog asking whether the Load/Unload address should be re-initialized. This has been expanded and another option is added asking the user whether the Contact information should be re-initialized as well. This new dialog also appears if the Load/Unload address is changed.

- If Customer account is changed and "Update contact information" is selected: then the contact information (Contact, Contact name, Primary Phone, Secondary Phone, Email) will be cleared and re-initialized from the default contact person of the newly selected Customer account party if any is found.

- If Customer account is changed and "Update contact information" is NOT selected: then the Contact field will be cleared (since contact persons are now directly tied to the Customer parties and can only be used for their respective party) but the remaining Contact information will be unchanged.

- If Customer account is changed and "Update load/unload address" and "Update contact information" are both selected: then the Load/Unload addresses will be cleared and re-initialized from the Customer account and the Load/Unload contact information will be cleared as well and re-initialized from the default contact person of the Load/Unload address party if any is found.

- If Customer account is changed and "Update load/unload address" is selected and "Update contact information" is NOT selected: then the Load/Unload addresses will be cleared and re-initialized from the Customer account. And the Contact field for the Load/Unload addresses will be cleared but the remaining Contact information will be unchanged.

- If Customer account is changed and "Update load/unload address" and "Update contact information" are both NOT selected: then the Contact person for the customer will be cleared but the remaining Contact information as well as the Load/Unload address and contact information will be unchanged.

- If Load/Unload address is changed and "Update contact information" is selected: then similarly the contact information for the Load/Unload address will be cleared and re-initialized from the default contact person of the Load/Unload address party if any is found.

- If Load/Unload address is changed and "Update contact information" is NOT selected: then the Contact field will cleared for the Load/Unload address but the remaining Contact information will be unchanged.

The following enhancements are done on Subcontracting order/ Header view:
Fast tabs are rearranged and new one 'Dates' is added:
- General
- Addresses
- Dates
- Contract
- Financial dimensions
- Transport order
- Tour

Following fields in the tab Dates are added and renamed:
- Load/Unload dates fields from the Address tab --> Renamed to Rough scheduled date (load) and Rough scheduled date (unload)
- Distance/Time group from the Address tab are moved to Dates tab
- New fields called: Detail planning date/time (Load) and Detail planning date/time (Unload) are added.

Two new fields added which are showing "Total weight" (below the two weight fields) and "Total volume" (below the three volume fields) in Create new package form.

CAPcargo objects were removed from following standard D365 security roles or duties:
- HcmWorkerMaintain
- InventTransferMaintain
- MCRSearchMaintain
- PurchOrderMaintain
- SalesOrderMaintain
- SalesQuotationToSalesOrderProcessEnable
- smmContactsMaintain

To avoid 2-step configuration (Driver creation wizard and Mobile apps user for this driver), a new step will be added to the existing Driver wizard (Step 7), where “Mobile app user” can be configured for the driver being created via the wizard.

This new step will be available only if CAPcargo Mobile apps are used (=corresponding licenses have been installed and configuration keys have been enabled).

Empties parameterization per planning unit (in the transport type) has been deprecated/removed. Empties parameterization is only possible per transport unit (in the transport type).

For the newest modes of subcontracting orders implemented ('TrLeg subcontracting without tour' and 'TRO subcontracting'), there are some Known Issues:
--Cost from 'Direct subcontracting TrLeg (without tour)' subcontracting order is not visible in 'Statistics cost/revenue split (posted)' form - to be fixed in next release (#104621)
--Deleting a line from a Transport order which is directly subcontracted does not properly delete the corresponding line from the subcontracting order - to be fixed in next release (#ADO 104675)
--Deleting a line from a Transport order which is either directly subcontracted or subcontracted via TrLeg subcontracting, does not set 'Calculated' flag to 'false' on the corresponding TRO/TrLeg subcontracting order - to be fixed in next release (#ADO 104697)

The old 'transport order direct subcontracting' is replaced by the refactored subcontracting (harmonized with resource and tr-leg subcontracting). Subcontracting of transport order without need of tour dispatching using the new 'leg direct subcontracting' (without tour) in the background. Will fulfill all the requirements of direct transport order subcontracting, but additionally also offer confirmation of data and track & trace, such as an own proper subcontracting order, same data source as the harmonized transport leg and resource subcontracting.

Also subcontracting default values on default orders will be removed and deprecated from the default order.

Customization data & code: It’s strongly recommended to synchronize with CAPcargo project team about the needed action points on such customizations.

No data migration is provided. The old subcontracting fields on transport order we mark as legacy and keep them in the system, to not lose data if somebody really needed once some old data.

Data migration task for 100536.

Data migration task updates parameterization of background color (of column fields) for GPB 'Transport orders /-legs' screen from 'black' to 'white'. In case some other color was already specified in the parameters - then this color is preserved.

In Optimizer dispatching, customer wish was not consistently respected for usage of the various combinations of Load/Unload Date From/To with Load/Unload parameter 'Applied on', especially visible when changing Optimizer mode to 'Ignore rough planning' during dispatching.

When Transport legs were exported to Optimizer using a Generic provider, the legs sent would be marked with GPB OS flag '[Sent to] Optimizer' even in some cases when process would stop and legs would not be really sent (example: when legs contained non-geocoded addresses).
This was changed, so that only the Transport Legs really associated with a Optimizer tourplan (Generic provider) would be marked as 'Sent to Optimizer'.

If actual tours were created via Optimizer dispatching processes by using resource combination with certain validity, and then user tried to update those tours with extra transport legs via Optimizer and update the planning date to another one than originally used, it was possible to actually move tours to a date for which there was no validity defined in the original resource combination plan.
This was fixed, so that, if at least one of the TMS tours selected for update are related to a resource for which there is no validity defined in the resource combination plan for the new roughplan date, the process would be stopped with proper warning.

Resolved an issue where SLA and Temperature fields would appear blank after refreshing the leg when Goods Management form gets closed. The SLA and Temperature fields in OS grid now correctly retain their data and background/text color, ensuring accurate tracking of service level agreements and temperature.

The user experience is enhanced as the Qualifications tab is now hidden (in GPB 'Transport orders /-legs' screen) automatically when the 'Check qualifications' option is disabled in GPB parameters.

When selecting multiple tours in GPB 'Resource Dispatching' screen and performing distance/time calculation, after the result is returned, one of the selected tours was correctly displayed, while others had the loading wheel on (even though process is done).

If the Synchronous change tracking is used, the user was able to click many times quickly on the "Send to Driver app" button and the multiple identical Driver app tours were created.

Since this process can take even several seconds, then there are many processes running in parallel, the "Send to Driver app" button is disabled during this process running. The button is enabled again once the process is done.

When running conflict analysis (from dedicated button) on tour in GPB gantt screens, additional processes were also triggered (processes from Process button). It is fixed and only conflict analysis main process is called.

When registering a "General incident" in the driver app (claim which is not related to orders or vehicles), the user must choose a reason code. Previously, the lookup contained only reason code id, not the description of the reason code. For all other claim types it worked correctly. The issue was corrected.

The issue was especially happening when driver resource leg length was adjusted after the tour has been sent to driver app.

When Transport order was subcontracted as TRO/TrLeg subco without tour, and user attempted change of date or time directly on TRO (while no confirmation was yet done on subcontracting order(s)), a dialog would appear with text: "Customer invoiced Do you want to launch that action?" The text relating to 'Customer invoiced' was a remnant from old TRO subcontracting feature, and did not have any effect on the date/time change functionality. This dialog has been cleaned up.

Previously there were two fields for Tour start time in "Create new tour" form. One was supposed to show the start time in user time zone, the other in timezone of the tour start address.
These fields were not working together nicely. The "Tour start in user timezone" field has been removed and only "Tour start (local)" remains (and has been fixed).

In Create new tour dialog, if a Route/Zone is selected, and the user clicks "Init from Route/Zone" the tour date was decreased by one day. This happened only if the selected route/zone did not have a tour start time defined (it was 00:00).

For determination of service provision date during price calculation, subcontracting orders of type 'Resource' were incorrectly affected by same setup of same parameter as the subcontracting orders of type 'Tr-Leg'. This led to impossibility of contract finding in some setup constellations. This was now fixed, and service provision date for subcontracting orders of type 'Resource' now depends on setup for parameter 'Service provision date tour' (Transport parameters>Pricing - Contract finding>Service provision date).

When setting up qualifications, a certain criteria can be specified (in the 'details' grid). When more criteria were defined on the same line (eg. Motor Vehicle, Trailer), then previously these were handled as 'and' conditions (meaning that qualification had to be provided by both Motor Vehicle AND Trailer, otherwise conflict is raised in conflict management). Newly, such multiple criteria are treated as 'or' conditions (meaning that qualification had to be provided either by Motor Vehicle OR by Trailer).

Cost coming from Subcontracting order without tour was not displayed in the Cost/Revenue form on Transport order.
This has been fixed, and additional changes were made (to acomodate also the new subcontracting order of type 'TRO subcontracting' - see more details on ADO 33597):

Cost origin enum 'from tour' has been renamed 'from dispatching' and includes all costs related to:
-- Resource subcontracting order
-- TrLeg subcontracting order
-- TrLeg direct subcontracting (without tour)
-- Tour additional cost
-- Resource cost

Cost origin enum 'from transport order' has been adjusted to include all costs related to:
-- Transport order additional cost
-- TRO direct subcontracting

Previously, when creating transport orders from imported orders, the 'Means of transport' was initialized always from the transport type, even if 'Means of transport' was imported (and was different from the one specified on transport type). The issue was corrected, 'Means of transport' is newly initialized from transport type only when not provided by import file.

The grouping 'Overview' in Work instructions form on Transport address (containing fields 'Name' an 'Work order description') was not visible by default anymore. This was now fixed.

Previously, the contact person load/unload lookups were showing the contact person of the customer/vendor account. Which was wrong and is fixed under this task; only contact persons of load/unload address can be assigned as load/unload contact persons.

In the following constellations, the measurements per transport units were not properly initialized, but now fixed:
- When transport unit is marked as "default" on Transport type
-- (a) on TRO create wizard
-- (b) when adding lines manually to transport order

- When transport orders are imported

Following issues were corrected, in the area of package creation & maintain:
- Initialization of default package unit (from transport unit setup) when adding new packages to existing order) was not working; system previously initialized only from default package unit (from main TMS parameters)
- Adding a new package previously sometimes did not update the order line planning qty
- Deletion of package was previously not updating the order line planning qty

The issue was only happening when "Tariff quantity initialization status" fields should have been initialized from contract version or contract relation. Previously, only contract itself was used as initialization source and contract version & relation initialization rules were ignored.