10.0-CAP42.0 (10.07.2024)

Field 'Additional trailer' was added in TAL on vehicle masterdata, tour header fields etc. (all places where 'Trailer' field already existed) in US 97244. Consequently, Optimizer had to be adjusted to take into consideration the additional trailer when dispatching to Optimizer by using Vehicle groups (since this was already implemented much earlier in Resource combination plan).

Since tourstart/end initialization has been enhanced (with US 92553) at the level of Transport type, the unique Optimizer parameterization for tourstart/end initialization has now been removed from tab Algorithm in Optimizer parameters and connected to main tourstart/end parameterization on Transport type.
In this way, Optimizer can now benefit from the possibility of customizing tourstart/end initialization by Transport Type and even default addresses, in case of initialization failure.
Optimizer tours are now fully aligned in this area with tours created by other dispatching processes.

This also means that, in case Optimizer does not find a Tourstart/end initialization value as requested by one level of parametezation (for example: Tour Start = predecessor tour on vehicle masterdata), process of dispatching will no longer stop, but continue looking for a value at the next level of parameterization (ex. Transport type tour start).

Setup warning: In order to avoid discrepancies in Optimizer tour initialization before and after release, please check that the Transport Types used for OPT dispatching are correctly aligned in setup with Optimizer.

Total sum in 'Show totals footer' OS row is now available for the following columns:
-- ADR points
-- Packages
-- Shared packages

The following buttons are now enabled without the need of selection of leg or tour in OS/GS:

OS:
Subcontracting header group --> Direct Subcontracting -->Subcontracting order
Dispatching header group --> Generate/Update tour out of route/zone

GS:
Dispatching header group --> Dispatch--> Generate tour from default tour

Previously, all text visible on mouse-over in information boxes ('bubbles') next to GS tourstops could not be selected/copied.

Since these bubbles contain more than just Work instructions text (which could already be accessed/selected/copied by clicking the bubble to open a separate browser window), including order references, it was now made possible to select and copy (by using keyboard CTRL+C or mouse rightclick+Copy) any text displayed in the info bubble.

The displayed information bubble closes when clicking on the box top right 'x' or when clicking outside the box itself.

A new field, Additional trailer, has been introduced in various forms and connected processes, similar to already existing 'Passenger' field (which was also renamed 'Additional driver').
-- Vehicle masterdata
-- Vehicle creation wizard
-- DispLight Tour
-- Create new tour
-- Default tour
-- Route/zone

The tour start/end initialization process is not impacted by the additional trailer, only the main trailer connected to vehicle can be used as driver of initialization (in case of such TT parameterization). This is similar to additional driver no-init rule.

The resource fields in the tour header (Dispatch light) are now always in sync with GPB for the regular cases (when no more than 1 vehicle/1 trailer/1 additional trailer/1 driver/1 additional driver are planned to tour)

Additional trailer is always dependent on existence of main trailer in combination. Same dependency implemented for additional driver.

GPB enhancements:
GS, level 2:
On mouse-over icon for trailer with 'Additional trailer' role, the Resource text field now contains not just the Resource ID, but also the text 'Additional trailer'. Same was implemented for 'Additional driver'.
GSR, level 1:
On mouse-over tour visualized on GSR from perspective of additional trailer, a new line was added with text 'Resource: Additional trailer'. Same was implemented for 'Additional driver'.
OS:
When resource has trailer+additional trailer, a new icon is displayed on main selection line, showing two trailers.

It has been requested by multiple departments to show trade order identification number in planning, in order to make searching for plannable orders easier. Although this information is available on the Goods management form, but when looking for orders that way is considered too time consuming.

Therefore, if the ‘Single order’ parameter is activated on the shipment building group of CAPcargo shipment based transport orders, then the identification number of the trade order is now taken over by the transport order, added to the Customer reference existing field.

Furthermore, this customer reference is shown directly in the grid of the GPB 'Transport orders /-legs' screen (also for non-shipment builder orders).

Field 'Site' from the Depot form is removed as it was not used anywhere in the code. It was planned to be used for some business processes, but it become obsolete with the latest redesigns.

The resource description was added next to the Resource ID in the resource unavailability form.

Events triggered in a certain order on the subcontracting order related to a particular Transport order did not always properly reset the value of flag 'C/R statistics calculation up-to-date' to false.

The 'Strategic tour routing' was not properly triggered in all constellations, based on general Transport parameters setup:
--Dispatch TRO directly to new tour
--Generate tour from transport leg
--Drag&drop Transport leg directly on GS
--Drag&drop Transport leg on GS while holding CTRL

The 'Strategic tour routing' parameter is now available on the 'Create new tour' form, with default value coming from the general Transport parameter. User is then able to change it manually for a particular transaction.

Two fields related to import attachments in Transport parameters>General>Transport order ('Number of retries' and 'Code') have been placed under a separate grouping, 'Import Attachments'. Also, the field previously labeled 'Code' received a clearer label and helptext ('External code for imported document attachment').

In section 'Qualifications requested', the buttons to add/remove qualifications were named 'New'/'Delete'.
In section 'Qualifications provided', the buttons to add/remove qualifications were named 'Add'/'Remove'.
For UI consistency, all buttons have been aligned to show 'Add'/'Remove'.

The fields 'Effective from' and 'Effective till' are now added to the 'Copy vehicle' form. However, they are not initialized with pre-existing values in these fields from the to-be-copied vehicle, but always blank. Fields are not mandatory. Blank values are interpreted as 'forever'.

With the introduction of the additional trailer (US 97244), the mechanism of finding and handling resources on tour for auto-creation of Tr-Leg subcontracting orders (initially improved in previous release on US 101023) had to be enhanced to include the additional trailer resource in this mechanism.

"Dispatch directly to new tour" process was redesigned and now it uses the "Create new tour" dialog which is used also in other processes where tours are created. The primary driver for this was to unify the handling of initializing tour start/end address, which we had enhanced recently. We decided that we want to unify the tour creation processes in general so that we only one place and process to maintain and test.

We have also rearranged the user interface of "Create new tour" dialog.

Customizations in the old "Dispatch directly to new tour" need to be evaluated and in most cases moved to a different place.

A significant enhancement in the 'Create new tour' form (regardless from where it was triggered) is the on-the-fly initialization of the Tour Start/End addresses directly in the form based on input from user and considering background tourstart/end parameterization (ex. populate vehicle field, the Addresses are re-init based on settings, if any behind that vehicle; same with main trailer/main driver/Transport type). As a result of this, no further initialization of Tour Start/End addresses is considered AFTER user presses OK (which was the case with the old 'Dispatch directly into new tour' form).

The 'Contract reference' field from Transport order lines>Contract tab had previously already been added to rule collective invoice as a parameter, and in TRO invoice pool as a filtering criteria. It was now also added to the 'Create and post invoice batch' dialog form as another filtering criteria for the customer invoice pool transactions.

In the previous versions, the department filter was linked to D365 financial dimension. If the department dimension was used in D365, but financial dimensions not really used in transportation (e.g. the user not assigned to a department), this could lead to issues in GPB filtering.

If department is used in transportation, then often differently than in the rest of the ERP, i.e. with an "own purpose" (e.g. geographically, traffic, type of transport, etc). Therefore we now provide an independent entity 'CAPcargo Department' to be used only for transport purposes, mainly for filtering.

The new CAPcargo department field is available mostly on transaction [header] data (orders, legs, tours...), on template data (default orders/tours, routes...) and on master data 'user/worker' and 'vehicles'. It serves mainly as filter purpose in dispatching (GPB) and is initialized so far only by the user/worker or from template data if defined. - Hence the user/worker can be assigned to [existing logic] D365 standard operation unit (=financial dimension) as e.g. "transport department", but more specifically in the CAPcargo department as e.g. "national transports". If the CAPcargo Department is filled on the user/worker, it is initialized to all filters in CAPcargo Transport.

Note: The existing purpose of financial dimensions in CAPcargo Transport (e.g. initialization and posting on order line level) will stay untouched. Also the advanced framework of initialization rules. - New: the financial dimensions are only used for financial purposes, not filtering anymore.

Data migration task for 107681.

Data migration job updates customer reference on existing shipment-based transport orders.

Data migration task for 107331

Since the Reduction value field on Surcharge Groups form essentially had to be changed (in order to provide the enhancement from whole numbers to numbers with decimals), this data migration takes the existing values in the old field (>0) and populates them to the new field.

When user wants to delete a resource combination plan (for any reasons), first the individual lines of the resource combination plan have to be deleted. If any of these lines have been used at least once in the creation of Optimizer tour plan(s), they cannot be deleted unless the related tour plans are deleted first.
But to identify all tourplans dependent on a resource combination plan can be quite tricky. Thus a new menuitem was introduced: 'Show dependent tour plans'. Clicking this menuitem will display an infolog with all tour plans which are using the selected resource combination plan, as well as a link to open directly the particular tour plan.
This is another tool to assist the user when deleting resource combination plans, which supplements the already-existing periodical function of cleaning up tour plans.

In some constellations, when legs were drag & dropped on resource in GSR lvl1. tour was properly created, but the tour details in lvl3 were not displayed. This was now fixed, tour stops are always loaded and displayed in lvl3 as soon as tour is created.

After a similar issue was fixed in R18, we found, that since R40 in GPB 'Resource Dispatching' screen 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 GPB 'Transport orders /-legs' screen) can lead to corrupt data and unstable situations, due to missing detail data.

The issue is fixed, and currently the resources which are not part of a Vehicle group are not displayed on the Y-axis in GPB 'Resource Dispatching' screen.
If such resource is assigned to a tour in D365, and user search for such tour in GPB 'Resource Dispatching' screen - there will be no results shown.

When a new address was created from the Create sales return order dialog or sales return order header, the address was linked to the legal entity. This is now changed, and the address now is linked to the customer of the sales return order since the goods are collected from a customer related location.

An error was shown at automatic purchase order creation from sales order when sourcing vendor was used without direct delivery (Sourcing vendor field = not empty, Direct delivery field = Stock). This is fixed, so no error message pops up anymore.

Previously, if the vehicle used for dispatching did not have at least one driver defined as part of the driver fixed combination logic, the predecessor tour (if so parameterized) was not used for initialization of tour start.
This was fixed so that the initialization is not dependent anymore on driver setup.

The issue was especially happening when tariff level was changed on the calculated order line (that was part of order collection).

When performing partial quantity split on transport leg (in goods management form), then the volume of the split quantity was evaluated based on the volume calculated from transport unit conversion, even though specific measurements per transport unit were used and displayed on transport order. This leads to wrong and sometimes absurd results (ex. negative values for volume on leg/tour).

In some data setup constellations, when tour start/end parameterization was set to 'Driver home', the home address of the passenger resource was initialized, instead of the main driver home address.

Couple of modification were done on the POD report:
- Only vehicles are displayed on the report, drivers are not needed.
- Package details are now also available on the report.
- Time from Date section is removed, only dates are displayed.
- The local time zone of the delivery is now displayed (and respected).

Previously, when creating a new invoice automation rule via setup wizard or editing an existing invoice automation rule, if user inserted a new financial dimension reference without also selecting a valid value, an unrecognized label ID was displayed.
This was fixed, so that user is properly informed that the reason the process is stopped is because of no/wrong selection in the dimension value of the newly created row.

Following bugs were corrected in subcontracting order area:
- contact person editing
- logical imperfection in part "when all tour order lines are confirmed"

When vehicle is parameterized so that the Driver combination logic = Mid-term driver plan, and in the Mid-term driver plan, both a driver and a passenger are setup for the vehicle, the Passenger ID is not initialized automatically in the 'Create new tour' form or on the Tour header, when the vehicle is entered in corresponding field. The Driver field was correctly initialized, and now the Passenger initialization was also corrected.

Previously, when an activity was defined on an address in the 'Activity time per address' tab, its duration was properly initialized to tour start/end, but then was not properlly removed from the tourstop(s) when the tourstart/end was re-initialized to another address (which did not have such activity defined on address). The reverse process had the same weakness.
Both cases were now fixed.

Dragging one or more transport legs from GPB 'Transport orders /-legs' screen to GPB gantt screens (tour level 1) was not possible *IF* there were already other legs dragged to this tour before. This was a regression in CAP41 release, fixed in GPB hotfix version 10.0-CAP42.1.