10.0-CAP31.0 (25.01.2023)

'Early/late arrival' and 'Early/late customer wish' filters were previously available only in GPB 'Tour Dispatching' screen, now are available in both GPB gantt screens.

Filter logic in GPB 'Tour Dispatching' screen is similar, the only difference is that filters take into account the delay of tour stop (where the resource assignment ends), instead of tour end delay.

The format of the date/time in GPB is now applied from D365 settings of the user (User options --> Preferences --> Language and country/region preferences --> Date, time, and number format). If the date/time format is not set there, then the format is applied from the selected language.

Please note that even that the field says 'Date, time and number format' in D365, only date and time format is applied in GPB.

Previously, the activity description in Driver app was static on all activities (ie. either 'Description' or 'Language text' of the TMS activity was used). This task introduces a dynamic activity description, where newly also information about the planned duration of the activity is shown (for certain activities).

Following activity types were enhanced:
- Driving time breaks
- Wait
- Idle time

So instead of "Driving break", driver app users will now see for example "Driving break 15 min", ditto for activity types 'Idle time'.

The 'Wait' activity type is handled a bit differently, there instead of "Waiting" drivers will see for example "Waiting until 14:00".

As there is currently no parameterization possible (to specify which activities shall go to driver app, or to truck loading app, or to both), many activities were sent to both mobile apps. Which, especially in truck loading app, was quite confusing as user was faced with activities that were not too related to his/her work. To improve the situation (and to limit activities that are sent to truck loading app), following rule was adopted (until some more intelligent configurable solution is in place):
- If the tour stop is enabled for truck loading app (loading / unloading), then only 'Load/Unload/Checking goods' activities are sent to truck loading app, but nothing else. All other activities go to to driver app.

Now, the 'Merge part deliveries' can be used also when transport legs have more than one order line.

Transport unit description was added to the tour report (and also to the loading/unloading list reports). Previously these reports contained only transport unit id.

New data entity was added, both for export and import projects:
- TAL Certificate

The function 'CAPcargo correct address' (existing already on geocoding-failed form) was implemented also to the main manage-address form.
This function corrects a selected address WITHOUT creating a new version of the address and without marking the address [and related orders] as expired; hence it can be used if there was an error/typing mistake on any of the address fields. - On the other hand, the standard 'edit' function creates a new version of the address if any address field is changed and marks the previous address version as expired [same for existing orders]; this is supposed to be used when the address really changes (ie. at relocation for example).

Further it was fixed, that the standard address-change feature (creating new address version) is not compromised by the CAPcargo features in the following scenario:

An address was "corrected" (i.e. not leading to a new address version) by a CAPcargo feature (e.g. geo-coding choose best match on map). Then after that - without closing the form - any address field was edited. It would be expected, that a new address version is created, but it was not. If the same thing was done after re-opening the address, all would work well.

Previously it was possible to create a resource only with amount of axles from 2 till 12. Now also a 1 axle option is possible.

Previously introduced bugfix 25668 (Multiple same surcharge types in the tariff surcharge definition, released in 10.0-CAP25.0) turned out to be too limiting, as it became impossible to setup the same surcharge type multiple time (but each time with different price for different range criteria). This task is removing the 25668 fix, hence it is again possible to setup one surcharge type multiple time on Contract/Version/Relation (or in the surcharge group), and again only first effective surcharge type is applied in the price calculation.

Further enhancement in this area is foreseen in 10.0-CAP32.0 (in task 93484), to introduce more intelligent validation.

Following license configuration keys were added (under 'CAPcargo Transport and Logistics -> Geo Information System (GIS)):
- 'Use real time traffic data'
- 'Speed patterns'

The two new configuration keys are disabled by default and must be separately enabled if these features are needed.

Please note:
- Further parameterization/configuration/licensing might be needed, in order to start using both features

The mechanism for adding orders/legs into tours was improved, to ensure that existing tour stops (with same address) are rather re-used, instead of creating a new tour stop. This mechanism was existing already in previous versions, but several cases were reported (where the re-using of tour stop did not happen).

This is a Microsoft framework issue that happens in onebox (cloud hosted or locally hosted) environments that have been created before D365 10.0.24 version was published. Those environments have SQL Server 2016 and starting from D365 10.0.30 incremental exports with recurring data jobs are not working anymore.

Incremental exports are used in following CAPcargo Mobile app integrations:
- Mobile app users
- Mobile app reason codes

Onebox environments are usually used for development, but sometimes also for testing. Onebox environments that are used with CAPcargo Mobile apps are impacted by this issue.

This issue doesn´t impact actual Microsoft managed test (=sandbox Tier2 and above) or productive environments

The only fix to this issue is to deploy a new environment using a newer environment template (D365 10.0.24 or newer) that comes with SQL Server 2019.

It´s possible to work around this issue by not using incremental push for Mobile app users and Reason codes, but a full push instead. This way all users and reason codes are exported each time the integration job runs. This adds some overhead to the integrations, and also increases staging table data usage.

When requested, CAPcargo can make this setup change when configuring the new Mobile app version in a customer system.

Symptoms of the issue:
Mobile app user and Mobile app reason code recurring data jobs show "Processed with error" in the execution history. And in the details you´ll see error message: "SysIntegrationActivityBatchTask-run. Results. Cannot execute the required database operation.
The SQL database has issued an error.

Object Server DynamicsAXBatchManagement:
[Microsoft][ODBC Driver 17 for SQL Server][SQL Server]'DISABLE_BATCH_MODE_ADAPTIVE_JOINS' is not a valid hint."

In Release 31.0 the structure of the contact information of transport orders was modified, more specifically the contact of customer, contact of load address and contact of unload address. The purpose is to replace the 'Contact information' field [only reference to master data] from all the three data sets by three new [physical] fields: Contact name, Phone 1 and Phone 2, keeping other existing [physical] fields Email and URL. - However, in release 31.0, the 'Contact information' reference field is not removed yet, just announced deprecated and put invisible in the UI.
We have introduced a data migration job (#93927) which adjusts the data structure of the transport order to the new structure. This is a preparation for the deprecation of the 'Contact information' reference field in the future, i.e. R35.
As part of this new feature, the TAL transport order header data entity, which is part of the composite data entity TAL transport order import, has been adjusted to the new data structure and contains the new fields. It is important to note that if you want to use the old files for importing transport order contact information, you will not have that information visible in UI anymore although it will still import. It will be deprecated in the future (R35), which means that your files for importing of transport orders would latest fail after R35 or higher is installed.
CAPcargo strongly recommends - before taking R31 in production -, to adjusted the order import files to the new structure in order to have all the contact information visible and correctly imported.

Hint to composite data entities (order import):
When refreshing the data entity list, sometimes the mapping of the child data entities belonging to a composite data entity is not re-generated and there might be some fields which are missing. This can can leads to unsuccessful importing of files.
Solution: Navigate to Data management > Data entities, find the composite data entity and go to its child entities.
Select the child data entity and click on Modify target mapping > Mapping details > Generate mapping. This will regenerate the mapping from scratch and the new fields should be part of the mapping.
When importing a composite data entity, always check the mapping in the project - both mapping details and mapping visualization. They should contain the new fields in both target and source columns.

Also, it’s important to make a distinction between the child entity and regular data entity. The regular data entity (for example TALTransportOrderHeaderImportEntity) is child entity of TALTransportOrderImportCompositeEntity). The mapping of the first one can be different than the child entity part of the composite entity, so they both need to be regenerated.

Newly, only the sequence of subsequent activities is incremented (ie. sequence of activities that are after the 'Wait' activity).

The issue was happening only when transport order was split via quantity split.

Previously (ie. in older GPB versions), when tour was visualized on the GPB map (via 'pushing' from GPB gantt screens) then the selecting of tour stop on the map would also select & highlight the tour stop in the source GPB gantt screen. This feature was later lost, due to internal GPB interface changes. This task restores back the functionality.

If the failed pickup/delivery was registered via driver app, and it was done for an order that had packages and many lines, following issues might have been encountered:
- Failed pickup fails completely
- Failed delivery runs correctly but unexpected error messages are shown

The issue was caused by missing validation in order import process. The issue was solved by adding new validation to shipment lot creation process, to ensure that goods receipt date is always later than the shipping date.

The issues was happening especially when parameter 'Tour distance/time calculation in real-time' was activated in the main TMS parameters and the tour was created via 'drag & drop' from several transport orders/legs. Then the driving time & distance calculation was performed individually (ie. after every leg was added into tour). The issue was corrected, the driving time & distance calculation is now launched only after the last transport leg is added to the tour.

The following issue was found in R31.0, it has existed since R23.0, and was fixed by this task.
If you have an order (any order type) with more than one "calculation-packages", meaning several order lines with different contracts/-version/-relation and/or different tariff levels, and some data changed which lead to recalculation, then it can happen, that too many "calculation-packages" are removed and not properly re-created. In worst case, this could lead to too less amounts being invoiced.

For order lines with the same contracts/-version/-relation and tariff level or for orders with only one order line, the risk does not exist.

The issue was corrected and does not happen anymore.

The issue was happening only on configuration where PTV xServer2 was installed without toll cost feature. Then the tour related calls of various PTV xServer2 services (eg. calculation of driving distance & time) were failing even though the 'Toll cost' license configuration key was deactivated in D365.
The issue was corrected and toll costs are included in the PTV service calls only when the related license configuration key is activated.

The issue was only happening when 'Amounts include sales tax' parameter was deactivated on the vendor invoice journal template. The issue was affecting only the pro-forma process, the posting into general ledger account was then correct.

Advanced and more intelligent geocoding validation has been introduced in CAP29.0. Since then, a 2-folded address geocoding validation is in place, whereas in xServer1 only 1 validation was available:
- Address level validation (available in xServer1 and xServer2) → defines the expected accuracy of an address (e.g. "must have at least street")
- Address match quality in % (xServer2 only) → intelligently rates the founds results according to its address details.

Since introduction of the 2nd component, in some constellations component 1 is not respected anymore.
Example: An address provides no street, but otherwise is accurate (zip/city found). Validation #2 returns no problem, but #1 should return a problem (if set accordingly), which currently does not work in this combination, validation #1 is ignored. This part is fixed.

If licence configuration key 'Advanced truck attributes' is not activated, then the xServer2 processes do not provide reliable results, as the vehicle technical data (eg. lenght, width, height, number of axles etc.) and speed profile data are not submitted to xServer2. On the frontend, users could experience for example unprecise results of driving distance & time calculation, unreliable tour visualization etc.

The following 3 CAPcargo T&L security roles only require a 'Light User' license, and accordingly have limited rights. They are used by CAP.Trade&Distribution. (See also whitepaper CAPcargo_SecurityRoles_D365.pdf)
- T&L Sales Clerk
- T&L Purchase Clerk
- T&L Warehouse Worker

The roles can be found in the system under system administration - security configuration. By selecting the role and clicking "View permissions" you can see the detailed rights.

The Light User license role 'T&L Purchase Clerk' had too many rights (CAPcargo transport address creation), which was accordingly corrected and aligned with the 'T&L Sales Clerk' and 'T&L Warehouse Worker'.

The 'Remove/Keep' functionality in goods management form (accessible from GPB screens) previously sometimes didn't split quantities into legs correctly.
Depending on how many lines were in the transport order, and how many were selected before Keep/Remove functionality was used, multiple transport legs could have been created instead of an extra single leg with multiple lines.
With the corrected logic, only one transport leg is created with multiple lines.