10.0-CAP39.0 (02.02.2024)

Primarily meant to be used with Driver app.
Now coordinates from the Driver app confirmation are stored on various tour confirmation tables, such as Tour stop, Orders on tour, Package confirmation, Empties. Button "View on map" has been added on Tour confirmation form to show the confirmed location on the map.

In particular data constellations (multiple loadings at one or more depots, short distances to unloadings, limited vehicle capacities etc.), Optimizer tourplans done via provider PTV xTour contained tours with one or more returns to one or more depots for reloads within same tour. Since some business cases do not allow for reloads, but just one 'run' per tour, a new parameter "Suppress reload at depot" was introduced.

Default value is false, which means default behavior is to allow for reloads (if at all possible), as until now. When parameter is true, reload is not allowed at the 'same' depot within same tour. Loading at multiple depots 'once' in a tour is still possible.

For flexibility and consistency, this parameter was also introduced in the Optimizer dispatching form as well as the tourplan parameters section.

All Optimizer menuitems which were previously available in the separate CAPCargo Optimizer 'module' have been integrated in the CAPCargo Transport module. These menuitems continue to be visible and functional insofar as at least the 'CAPCargo Optimizer - base features' configuration key is enabled.

There are now separate Optimizer groupings under Common, Inquiries, Periodic and Setup sections in CAPCargo Transport module, while the CAPCargo Optimizer module has been removed altogether from the D365 tree structure.

In the Distance Matrix details form, not all existing fields showed data consistently. This was checked and fixed.
Additionally, one new field was introduced, 'Routing type'. This field returns the PTV response regarding the type of algorithm used to calculated distances in a certain Distance Matrix, depending on whether any of the addresses used for DiMa creation were 'outside' of the HPRN defined for a particular vehicle type. In such a case, PTV performs a very fast, conventional, computation of 'airline' distances, in order to provide an initial calculation and not stop the overall process.

A new intermediate Optimizer tourplan status is introduced, named "Releasing". This can be especially helpful to inform the user regarding long-running tourplan release processes. This status is displayed while a particular tourplan has already been Released (either by manually pressing the "Release tourplan" button or by having activated the "Auto create TMS tours" parameter on the tourplan), but TMS tour creation process is not yet finished.
While status "Releasing" is displayed, buttons "Release tourplan" and "Delete tourplan" are now disabled.

In case transport legs containing addresses from more than one timezone were being dispatched via Optimizer, a warning was given to the user to this fact. The warning was a bit confusing. The text of the warning was thus updated and the timezone field was also added to the Parameters section of the tourplan.

Following GUI adjustments were done in the Workers form:
- 'Template OS configuration' was moved from 'Filter Initialization Dispatching' to 'GPB Parameters' section
- 'GPB filter template' was moved from 'Filter Initialization Dispatching' to 'GPB Parameters' section
- Field groups were added to 'GPB Parameters' section

Previously, it was possible - during tour creation - to specify long description of the tour. But only first 50 characters were actually saved into database, thus the exceeding descriptions were lost. To unite the behavior, dialogs/screens for creation of new tour were adjusted, to also allow only 50 character for tour description.

Personalize and simplify the view and data access in GPB screens, for the user [group] to focus and limit to his relevant data only.

A dynamic filter template approach allows the dispatchers to see only data for specific depots or dispatch sectors.
Individual filter content configuration can be setup, allowing to define which values from a master table (e.g. which depots) can be accessed and which not. This template can be assigned to the user; even more, with individual security roles setting, it could be defined, that the user himself cannot change his settings.

The user will only be able to select amongst those valid filter lookup elements, not from all elements. Additionally it can be configured, if the user also shall see "empty depot/dispatch sector" records: If activated, the user can also see records without depot / dispatch sector involvement. I.e. the user can also see direct transports or transports to other depots / dispatch sectors.

Note: Above latter point is still weak and will be improved in a next release, in a way user still can see direct transports but not other transports to not-allowed depots / dispatch sectors, if "show empty" is activated. - If parameter is deactivated, the user can only see records, where the allowed depot / dispatch sector is part of, i.e. no direct transports.

Further more, it is planned to enhance the feature with more criteria, next to the depot and dispatch sector: Vehicle group and driver group.

Disclaimer:
This feature only applies to GPB not to dispatch light or any none-GPB process.
It is not to be compared with D365 standard 'Extensible Data Security (XDS) framework'.
Hence this feature is no technical data base access control tool, i.e. when jumping from GPB to a D365 form and navigate further there, this will not be blocked.

Important:
In case of mobile app custom implementation (either Driver app or Truck loading app), the change of integration schema has to be reflected in the custom implementation, to ensure that mobile app continue working even after the upgrade to 10.0-CAP39.0.

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

Removed field in Mobile app tour line (TALdraTourLineEntity):
- EMAIL - this field has been documented as obsolete for quite some time already, but it´s removed in CAP39. It should actually be removed from the data project mapping before installing CAP39

New fields in Mobile app tour activity (TALdraTourActivityEntity) (all related to 100087 Driver app - Show summary on signature)
- CHECKLISTLEVEL (integer)
- CUSTREF (string)
- CUSTREF2 (string)
- SIGNATUREID

Show summary of loaded or unloaded goods and other activities on the Signature screen in Driver app. Several (but not all) activity types in D365 can be enabled to be shown on the summary. Additionally an Instruction activity rule for "Summary page at signature" must be set up.

There was an issue in interpreting resource availability for Optimizer. If previous assignment ended 06:59:59, the system interpreted this as "resource is available starting 06:59:59", but in case the resource is available only 07:00:00. The issue caused overlapping resource assignments, as well as strange start times for tours.

Several labels were corrected in the subcontracting order area, to use consistent terminology. Eg. FTL/LTL based labels were renamed to better fit new harmonized terminology of "Resource subcontracting" & "Transport leg subcontracting" (usually abbreviated to "Tr-leg subcontracting").

In this task the handling of the empties is being improved. Newly, on transport type master data, up to three empties units (and its quantities) can be specified that are linked to a transport unit.

These empties units (and qty) are then also initialized to transport order line, where it can be also individually adjusted. The empties data (from transport order line) are then also used as a base for empties transactions (in tour confirmation),
This gives on opportunity to see (and actively maintain) empties data already from the order creation.

Obsolete objects which were deprecated in CAP27-CAP34 releases were removed. This is a regular periodic 'cleaning' task, to remove previously announced deprecated features.

For further information please refer to CAPcargo lifecycle support documentation.

Previously, several subcontracting pricing parameters (ie. 'Sub-contractor inherits tariff qty', 'Search only in depending contracts', 'Not statistics relevant') were shown twice on the contract relation form. This was corrected and only one set of subcontracting parameters is not visible.

This feature brings greater flexibility in parameterization of tour start and end initialization.

Important! Data migration job (ADO ID 92911) has to be run followed by thoughtful review of parameterization of new fields across Transport Types before resuming productive activities.

Following changes are introduced:

Section 'Default values tour' from Transport Parameters>Dispatching>Tour summary tab has been moved entirely to the Transport Type>Dispatching summary tab.
Enum value 'To predecessor tour' from old Transport Type parameter for tour initalization mode was deprecated.

The tour initialization section on Transport type has been replaced with two separate sections, 'Tour start' and 'Tour end'.
The old tour initialization mode field has been replaced by two separate fields 'Tour start' in TourStart section, and 'Tour End' in TourEnd section.

New enum values in TourStart field:
- None
- Vehicle depot
- Driver home
- Predecessor tour (replaces 'from predecessor tour')
- First load address in tour

New enum values in TourEnd field:
- None
- Vehicle depot
- Driver home
- Last unload address in tour

Old Truck/trailer field in Tour initialization mode was replaced with two separate independent modes: one for TourStart, another one for TourEnd. Consequently, the tour start and end can be independently initialized either from motor vehicle or trailer parameterization, in conjunction with values selected in TourStart/End fields.

Existing fields "Predecessor tour (days)" and "Data to be promoted" are now in relation to Tour start value 'Predecessor tour'.

These Tour Start/End init values have been implemented at several levels, and thus initialization logic is from deepest to most generic level: Midterm driver plan/Vehicle masterdata/Transport type.
For example, if a tour is created for a vehicle+driver combination, system will first check whether such combination exists and valid at the tourstart datetime on midterm driver plan. If so, then if any Tour start/end parameterization exists on the specific line other than None, it will be used to initialize Tour start/end. If nothing found or not valid, next parameterization check will be done at the vehicle masterdata level. If nothing found or not valid there either, same check will be done at Transport Type level.
If value 'None' is selected at TT level, attempt will be made to initialize tourstart/end from default values Tour start/end addresses (newly moved on TT from Transport parameters). If these address fields are empty, no further initialization will be attempted, and existing tourstart/end will not be changed.

The 'Create new tour' dialog has been enhanced with two new initialization buttons:
- Init from driver (home)
- Init from predecessor tour
Also, Tourstart datetime init value is now taken from each individual TT set of parameters ("Tour start date (+days)" and "Start time"), not the generic Transport Parameter anymore.

GPB:
Two new buttons were added in GS>Dispatching>Dispatch lookup:
- Init tour start address
- Init tour end address
Pressing these buttons will trigger the re-initialization of selected tour according to resource parameterization found on the tour at respective moment.

At new tour creation (whether by manual dispatching of Transport order into new tour OR at Create new tour in DispLight Tour/GPB), manual change of Tour Start/End addresses overrides the built-in initialization process from aforementioned parameters for the initial tour creation. However, these addresses might still be changed (depending on parameterization) in further actions on tour (example: moving tour to another resource with different parameterization, pressing the new GPB tour init buttons etc.)

Sometimes a gap might appear between tour stops in the tour details screen. No stops are hidden, but there is a space between some stops. The gap disappears when scrolling the tour stop list. There´s no functional impact.

If the driver has provided payment amount in the "Payment on delivery" activity, and then swipes the activity, the area underneath the activity appears red, indicating that swiping is not allowed. But it can still be swiped and the activity can be confirmed.

The tour start/end address initialization is largely enhanced in feature 92553, and with this, the existing one option to initialize the tour start address/time from a tour TO its predecessor tour end address/time is removed (parameter on transport type). The much more common feature, to initialize the tour start address/time FROM the predecessor tour is kept and enhanced.

There is no replacement of this old feature and no migration to a new feature. If customers used this or even enhanced it by CUS modification, please contact CAPcargo.

Data migration task for 100157.

As previously only one empties unit (and one quantity) could be parameterized on transport unit (in a transport type), while newly each transport unit can hold up to 3 empties units (and quantities), the data migration job was created. Data migration task populates 1st empties unit (and 1st empties quantity) on transport types/transport units, where some empties parameterization was previously activated.

Please note: only empties parameterization of transport unit is processed/migrated; the empties parameterization of individual planning units is ignored/not migrated. The empties parameterization of individual planning units is nevertheless still used as additional base for empties transactions (in tour confirmation), until the empties on planning units is deprecated (in some future release).

Long-running Optimizer tourplan calculations may yield this error in case of a mismatch between the xServer client timeout parameter in Transport Parameters>Geo services>xServer parameter AND the overall timeout setup on actual xServer and its proxy. The helptext of the xServer client timeout parameter has been improved.

Optimizer-related menuitems were missing from GPB Tr-Leg screen unless Optimizer PTV xServer configuration key was enabled. This was problematic, since using Generic Optimizer provider does not need any xServer related functionality, and it was thus fixed.

When user would change the planning mode from "Rough planning" to "Ignore rough planning" and consequently change the planning date from the initial date coming from selected legs to another date, this manually selected date would revert to the original date if on the same form, user would then change the calculation mode from whichever default value was initialized to another value. This was now fixed, so that the date defined manually would not be reset without specific manual intervention on that field.

Handling of certain exceptions was only generic: message 'The remote server returned an error: (500) Internal Server Error.' was shown to user, which made it difficult to pinpoint the source of the issue. The generic error has now been enhanced to show more technical details (D365 stack trace) regarding the actual process which triggered the process stop.

If users get unexpected error messages when using GPB, they should send those error messages to CAPcargo for further analysis.

The issue was especially encountered when planning transport orders/legs (with some customer wished dates) via multiselect in GPB 'Transport orders /-legs' screen.

This issue was related related to having instruction activity rule(s) with level "Per tour stop or address area" and having order lines without address area in the tour. If in such situation a driver would report a failed pickup, those instruction activities on the failed pickup tour stop might get removed / cancelled during instruction activity recalculation.

When taking multiple pictures with "Picture" activity, different document types were used in D365 for storing the attachments. The first one was correctly stored using Document type from "Picture" activity, others were using default document type.

Following issues were correctly in the area of shipment builder redesign:
- transport order synchronization button doesn't work in GPB gantt screens
- synchronization log after picking is missing

Please note: the issues were only happening when license configuration key 'Shipment builder' was activated in **Not officially released sub-modules**

When the new harmonized sub subcontracting structure is activated, the calculation and invoicing of 'Subcontracting Tr-leg' did not work if general transport parameter 'Service provision date Tr-leg subcontracting' was set to one of these values:
- [leg] load date
- [leg] unload date

This was fixed. (Any other value of the parameter were working normally).

Note: With new feature 'Direct subcontracting (without tour) - #80325) the following values of the above mentioned parameters cannot work by design, because there is no tour:
- tour start date -> if set so, the system automatically applies the value '[leg] load date'
- tour expected end date -> if set so, the system automatically applies the value '[leg] unload date'

When creating a new collective order from Transport Order, error "Field 'Total time'(= -82142) can only contain positive numbers." was sometimes displayed. This was now fixec.

In certain process constellation in the subcontracting order, a triggered infolog displayed text from the new subcontracting world only for the first tariff unit, while for subsequent tariff units it still triggered text from legacy subcontracting. This was now fixed.

The empties transactions were generated as 'unbalanced' even when 'Automatic exchange' was activated on transport address.

At the time of upgrade, there may be some transport orders without any predefined 'Means of transport' (if, for example, imported as such).
Under the new setup of means of transport on every transport type (feature brought with #92553), in case there is a specific means of transport defined on transport type, the transport legs from such transport orders may not in all cases be plannable in tours, due to differing means on transport on leg vs tour.
This will be solved in R40 with a data migration job which will initialize the means of transport on all transport orders from transport type setup.

Meanwhile, possible workarounds:
- manual update of means of transport on transport orders (that are still in 'Registered' status at the moment of upgrade)
- bulk update of means of transport on transport orders directly in grid (feature available in D365 starting with product version 38)

CAPcargo consultants can provide further guidance.
This known issue is valid only for transport orders existing in the system at the moment of update. Any transport orders created after upgrade will always have a means of transport, if either imported or default selected on transport type.