10.0-CAP37.0 (04.10.2023)

Previously, 'Preferred route type' visualization on map was not optimal, when PTV xServer 2 was used. Route types were thicker and having different colors (comparing to PTV xServer 1). The visualization was improved.

The content data file generated when dispatching via Optimizer provider Generic has been enhanced to contain several elements, such as qualifications (requested, provided), disqualifications, maximum driving time on tour, maximum tour duration.

When generating a json string from Optimizer dispatching by using the Generic provider, all exported addresses now contain the opening hours defined in TMS.

In addition to the regular Load and Unload, Transport Orders can be defined to have one or more additional stops (by using the "Register additional stops" function on TRO). However, such 'special' transport orders cannot be handled by Optimizer due to their particular structure. Thus, when legs belonging to such transport orders are selected for dispatching via Optimizer, a warning is shown to the user showing the user the orders which contain such additional stops and will NOT be considered for optimization processes. All other legs will be processed as usual.

Previously the GPB application code was not signed with a certificate. This could lead to a warning that the publisher of the program can´t be verified.

Now the code is signed, certificate issuer is DigiCert. If a system administrator wants to allow only trusted programs to be executed, they should add DigiCert as a trusted certificate authority.

If a system administrator wants to specifically allow only the certificate that was used to sign GPB, please contact CAPcargo for more information.

This task introduces the TMS Address ID of the leg to be shown in GPB order grid. Two new fields have been added:
- Load address ID (of the leg)
- Unload address ID (of the leg)

This can help to identify addresses better. In a later release also the original load address ID and destination address ID will be shown on the leg screen for even more flexibility in filtering.

Previously, when dispatcher was changing tour stop sequence via drag & drop, then each 'drop' action triggered full update of tour/tour stop. Which could be quite performance and user demanding, especially when change of sequence of several tour stops in some long tour was needed.

Therefore a new enhancement was introduced, after each 'drop' action the full update is not triggered (and changed sequence is stored only locally in the browser session). And only when dispatcher finally confirms that he/she is done with 'drag & drop' sequence changes (ie. by confirming the 'Ok' in the new dialog 'Accept tour line changes?'), only then the full tour & tour stop update is performed.

Please note: until the 'Ok' button is pressed, all changed tour stop sequence is not yet committed to D365 backend system (so is lost if 'Ok' button is not pressed).

Default company filter is still initialized from D365 user options, but dispatchers can now change the company filter directly in GPB client welcome screen. Selected company is then applied to all GPB screens.

Please note: changing the company in GPB will also change the default company on the user options in D365.

It´s now possible to configure custom identity provider via OIDC (Open ID Connect). The implementation was developed and tested with one provider only and has not tested with other providers and configurations.

There is a standard Microsoft synchronization for direct delivery chains, that not only validates - and if needed synchronizes - the updated field (e.g. contract id) between the elements of the chain, but it also validates all fields - and if necessary synchronizes between the elements of the chain even though the fields haven't been updated by the user (e.g. dates).

Since some function/process can change the dates on an element of the direct delivery chain, the date synchronization - between the elements of the chains - is then triggered which ultimately triggers the CAPcargo validation of date changes. Because it's a direct delivery chain that is already in transportation, the CAPcargo validation previously blocked the synchronization/update, which was leading to the error.

To overcome such limitation, new parameter 'Allow out of sync dates for direct delivery' was introduced to 'Trade and Distribution parameters'.
If parameter is activated, then instead of the validation (that previously blocked the user) a new warning is shown: if the standard validation/synchronization leads to transportation relevant date change (either the load and/or the unload date is updated to a different date that is on the transport order) then the user is warned but transportation is still not synchronized. It is the user's responsibility to either recreate the transport order or inform transportation team.

Following data entities were enhanced, to contain delivery date & time window related fields:
- TAL Time Window
- TAL General Parameter Entity (TAL Trade and Distribution parameter)
- TAL Parameter Entity
- TAL Route Time Window Table Entity
- TAL SLA Time Window

New unique index relies on migration jobs of 10.0-CAP33.0 release, which is the reason why new index is being introduced only in 10.0-CAP37.0 release (as all projects/customers following supported release life cycle will have 10.0-CAP33.0 release (or any later) already installed)

Existing 'multi-source sub-contracting' (one data source for each sub-contracting type) is replaced by new 'centralized sub-contracting' (one new central data source 'sub-contracting order' for the different sub-co types FTL & LTL). The big changes are in the background, in the data model, which is all seamlessly migrated.

The functionality in its basics stays the same, no new features. For the end-user there are only few changes like adjusted UI and reports (see extract of changes below). The labelling was adjusted, as the wording "FTL-" and "LTL-subcontracting always lead to confusions. Example: "Why do I have to use LTL-SC if I have a full truck business where I want to get billed by order in the tour?" - Or "why do I have to use FTL-SC if I'm in parcel/LTL business but want to subcontract a ready-planned tour entirely to a subcontractor paying by time/distance or flat?"

→ 'LTL-subcontracting' was renamed to 'Transport leg subcontracting'
→ 'FTL-subcontracting' was renamed to 'Resource subcontracting'
[→ There will follow 'Order subcontracting'] → see also 1)
[→ There will possibly follow 'Tour subcontracting']

Like this, not the business is driving the way of subcontracting, but the agreement with the carrier.

With this new centralized subcontracting order of different types, new features can be added easier, like adding new sources of subcontracting, handling requests for subcontracting, and mainly also providing the new CAPcargo carrier portal in its first CTP version in R37.

Some [minor] changes:
- The new subcontracting order form got a new field "subcontracting mode", which helps to differentiate between 'Tr-leg subcontracting' and 'Resource subcontracting' (and other types in future)
- The old FTL order structure (header only) got changed into the same header/line structure of ex-LTL. The new 'Resource subcontracting' order has by definition exactly one order line and accordingly gets a permanent "Detail" tariff level. Transport qty and commodity are usually secondary when an entire resource is subcontracted, therefore these fields are empty except if there is exactly one TRO in the truck, as in typical FTL business; then these additional goods information are shown.
- The description field of ex-FTL header was added to the new subcontracting order header, hence now also available for 'Tr-leg subcontracting'
- Invoice pool gets a new filter (the subcontracting mode) to help differentiate between the new 'Tr-leg subcontracting' and 'Resource subcontracting'
- The old menuitem "LTO-order calculation overview" from ribbon pointing to the original transport order was removed (can be viewed by jumping to the TRO)
- Planning and contract tab in line view were improved to show all units and quantities
- Parameterization has consequentially changed (for example, for invoice document types, order origin has changed from 2 different values (LTL/FTL) to only 1 value (Subcontracting order)
- The manual [header and line] surcharges calculation mechanism (what is the base if tariff- *and* manual *percent* surcharges co-exist) has been updated for the new "Resource subcontracting" orders to be consistent and aligned with all other order types, such as the "Tr-leg subcontracting" and the "customer transport order". Therefore, in some unlikely setup constellations, the results of calculations could potentially be different than in the past (legacy) subcontracting world.

Note: The Intercompany (IC) order structure was not changed, as this was originally already built with one centralized order table. The labelling in IC also is not changed, even though words LTL/FTL are still used there throughout the IC module.
________________
See also #100961 for the data migration description, also pointing to a detailed instruction description.
See also #88450 for the old feature deprecation description

1) Transport order direct-subcontracting is not yet replaced, will follow in any next release, using the transport-leg-without-tour subcontracting approach, which also yet is to be implemented as new feature.

A redesigned subcontracting feature was published in CAP.Transport&Logistics 10.0-CAP37.0. The old feature is deprecated and will be removed in the future. All customers who use subcontracting must migrate existing orders and customizations to the new world.

The data migration must be done before installing CAP.Transport&Logistics 10.0-CAP41.0. CAPcargo does not guarantee successful migration if it´s not done by this deadline. Data loss is possible if the migration is not done by this deadline.

It´s essential to follow CAPcargo instructions in order to minimize issues with the transition to the new subcontracting feature.
The instructions can be found in chapter 4 of CAPcargo installation instructions, which are shipped with the release.

Main disclaimers, see also above mentioned instructions:
- Theperformance of the data migration has not been tested with big order volumes(as of CAP37 release date). We have tested internally with about 3000 orders,for which the migration took 4-5 minutes. We don´t know whether the throughputtime scales linearly or not when the number of orders increases.
- It´sstrongly recommended to involve CAPcargo developer(s) and consultant(s) in thecode and data migration process
________________
See also #84785 for the new/replacing functionality description
See also #88450 for the old feature deprecation description

With the introduction of the Optimization provider parameter, when field selection was <> PTV xTour, the PTV-related parameters were supposed to be all hidden from UI, since not relevant for user. However, some of them were still visible. This has been fixed.

The graphical flag "Optimizer" in GPB OS was introduced to show user whether any of the tranport legs sent to Optimizer were successfully sent and processed by the Optimizer into a tourplan at least once (saying nothing regarding planning those legs in an actual TMS tour).
This flag, however, did not work at all in the case of using Optimization provider = Generic.
Enhancement has been made so that the Optimizer 'wheel' would be shown on Transport legs in OS as soon as any leg was sent to Optimizer by using Optimization provider = Generic, regardless of actual result of further processing.

In GPB 'Tour Dispatching' screen, following issues were corrected (issues were especially happening when Route/Zone was changed on existing tour):
- date focus was sometimes lost (ie. view point was automatically shifted and different tours were shown)
- date filtering sometimes started to misbehave (ie. date filters were not respected anymore)

The issue was especially noticeable when tour contained higher amount of tour stops (eg 20+).

The issue was especially encountered when dispatcher Worker employment assignments was transferred to another D365 company. Then some filter defaults (eg. Depot) could became not valid anymore for new D365 company. Previously, if such constellation was encountered, no data was shown in GPB screens.

Initialization of filters was thus improved, newly all filter defaults (stored on Worker) are automatically validated (whether defaults are applicable for selected company), and if not - then the individual filter initialization is skipped (and user is informed via new infolog message).

Issue was especially happening when multiple containers were used for packing in one trade order.

The issue was happening only when transport type 'Shipment builder end process' parameter was set to 'Creation of transport orders'.

IMPORTANT: Subcontracting data migration should not be run until a hotfix release has been released, solving the issue described below.

Some entries in tables related to order calculation and invoicing were not updated correctly in some cases.

There are some issues with data references in new manually created surcharges and invoicing leading to wrong displays and invoice status.