CAP10.0-30.0 json

Every passenger transport order requires the information about the Passenger. The order taker must define the passenger at the order creation process for passenger transportation otherwise the order cannot be created. The user can also create new passengers in case the passenger does not yet exist in the system.

Since such information was previously not available in the CAPcargo solution, the transport order header was enhanced with new fields to register this data. Furthermore, a new table/form for maintaining passengers was implemented.

Previously, the logic of getting resource past and future assignments was sometimes not performing optimally, which could be noticed especially on the systems with many historical resource assignments. The logic was enhanced, to avoid the loading of all historical resource assignments. Newly, only last 10 (and next nearest 10) resource assignments are loaded.

In case of drivers connected to a vehicle via midterm driver plan setup and/or trailer connected to a vehicle via operational trailer dispatching setup, such driver/trailer dynamic combinations were previously not shown in GPB 'Resources' screen (in Details/Overview/Assigned Resources sections). This was now enhanced.

Driver app and truck loading app are newly translated also into Italian and French language.

To support a better extensibility of the 'Activity request rule' in project customizations, the 'uniqueness' of the current index is not anymore achieved by index property, but is newly achieved via code validation. It is purely a technical change, that doesn't change any process.
In GUI, users can only notice the difference when receiving a different error message (when trying to create activity request rule that would be duplicate of some already existing one).

This batch was and is meant to geocode new addresses (longitude/latitude = 0/0). Addresses which have been already geocoded and are protected or have failed in geocoding are *not* possible to re-geocode with this batch; hence the filter for the above criteria are locked. Reason for this is server load; we need to avoid, that this batch runs [accidentally] over bad addresses over and over again. - To re-geocode addresses use the dedicated form "Geocoding-failed addresses" (menu "Inquiries").
Using this batch with different values for the 4 locked fields (from user cache) risks to nun run properly. Other additional filters can normally be applied by means of the standard query options. - Ensure you run the data migration job #93024 which properly cleans the user cache for this batch.

Refining of geocoding validations and matching quality was introduced:

It is distinguished if the geocoding happens manually with a user interface, or within a process (dispatching, batch etc). If the geocoding ends in a unique and good-quality* result, there is not user interaction needed. The geocoordinates, the validation level, the score result** and the not-failed status are written to the address.

* There is a parameter defining the minimum address match quality score in % (1-100%) to be reached at geocoding in order to qualify for successful geocoding. 0 is interpreted as 100%.
** Total score: For the old addresses in the system, the field is showing 0.00 score, which is not correct but doesn't do any harm as we are not using it in any processes. It serves for filtering and analysis purposes only.

Manual geocoding
Independent of the above parameter, user always gets a choice of possible results (unless there one unique 100% match) with total scores of match quality and can select the correct one. See also above.

The Save button on the address master data launches auto-geocoding. With the new multiple-choice approach, the dialog cannot be opened upon saving automatically, hence the same approach is followed as for geocoding within processes:

Geocoding within processes
The above mentioned parameter is consulted:
if one 100% match found, use it, declare as geocoding successful
Else, count the number of results having a total match score equal/bigger than the parameter
If exactly ONE found → declare as geo-coding successful
Else declare as geo-coding failed

Further, GPB Gantt was enhanced with a function to run geocoding directly for a tour:
A new function in GPB “Geocode tour addresses” finds address which are not geocoded and tries to geocode them directly from dispatching. This should help the user not needing to go via master data. This function uses as well the CAPcargo feature of showing geocoding results to choose if no unique address found, and brings the choice dialog to the user.

In transport address creation wizard, the address selection wizard step was shown even though there were no multiple address candidates to select from, thus there was no reason for such step.
Wizard was improved, now showing the address selection step only when it really makes sense, ie. when more address candidates are detected.

Previously, driver/passenger lookups were reflecting the effectiveness of the employment (ie. worker 'employment start date' and 'employment end date', as specified in the D365 Human resources module). Newly, the driver/passenger lookups are handled as other resource lookups - are reflecting the resource effectiveness (ie. resource 'effective from' and 'effective till', as specified in the D365 Organization administration module).

This functionalityenables simple and user-friendly approach for driver creation. The new wizardleads the user to enter the most important data for the new driver, step bystep. It also creates a resource of type human resource automatically in thebackground.

With this enhancement we enable the customers to configure a first batch of tables for the new Microsoft cross-company data sharing approach
- Duplicate record sharing (DRS) → Duplicating data
- Master company sharing (SRS) → Real sharing of data, one source of truth

Find more information about Microsoft D365 data sharing here: "Cross-company data sharing overview" (https://learn.microsoft.com/en-us/dynamics365/fin-ops-core/dev-itpro/sysadmin/srs-overview)
Cross-company data sharing concept allows you to share company specific master, reference, and setup data across companies within finance and operations deployment.

Two data sharing concepts are available:
- Duplicate record sharing (DRS) is a concept where creating, updating, or deleting of records in for any company in the policy is copied/replicated across all companies in the policy. Updates of fields will also be replicated if selected for sharing in the policy. DRS was the first sharing type made available.
- Master company sharing, also known as single record sharing (SRS), is a concept where a single physical record belonging to a master company is virtually shared across child companies. Create, update, or delete in any company in the policy will update the single records used across all companies. Master company sharing is currently in preview.

With this task we enable the sub-modules transport addresses /-areas and transport types/-units to be shared amongst different legal entities. These are the tables which were enabled for one of the 2 sharing approaches, e.g. DRS (duplicate record sharing):
CIRTRAAddress
CIRTRAAddressDiffDays
CIRTRAAddressGroup
CIRTRAAddressGroupLine
CIRTRAAddressQual
CIRTRAQualification
TALQualificationRequestedFrom
CIRTRAQualRestriction
CIRTRAAddressWMSLoadWeekDays
CIRTRADepot
CIRTRAHours
TALAddressBarcode
TALuldTable
TALuldCapacityTable
TALuldTableQualification
TALuldTableBarCode
TALuldAddressAreaType
TALWorkInstructionTemplate
CIRTRATransType
CIRTRATransTypeGroup
CIRTRATransTypeGroupTable
CIRTRATransUnit
CIRTRATransUnitGroup
CIRTRATransUnitGroupLine
CIRTRATransUnitQual
CIRTRATransUnitTable
CIRTRAVehicleType
TALQualificationDynamicClasses

That will allow the customers to activate sharing and define sharing policies on the mentioned 2 sub-modules . It is very much business depending how sharing shall be setup. By means of sharing policies the customers have the full freedom to configure processes as they request.
Good to know: The sharing policy allows the sharing of individual fields within a record, not the whole record must be shared (as this was the case in AX2012 virtualization). Exception: not-sharing of mandatory foreign key fields is not possible). This gives maximal flexibility and many options to share tables and individual fields, and hence allows defining own business processes.

CAPcargo does not provide prepared sharing policies, we only provide the framework to setup sharing policies and the mentioned activated tables. Hence the responsibility what and how the sharing is setup, lies with customer. CAPcargo is happy to consult and support for individual configuration but cannot be held reliable for wrongly setup data sharing and potential data corruption.

This is a first step of allowing the data sharing with a limited set of tables. We expect to enhance that set of tables as we go on and gather experiences and feedbacks with this new feature.

This feature provides the possibility for the user to copy a transport order/s with swapped load and unload addresses. This enables user to create transport order/s with swapped Load/Unload addresses and Load/Unload dates and date ranges different than definition setup in the Transport parameters form. Additional option is that user can choose whether to copy transport order/s with or without lines, that provides the possibility to copy only transport order header/s with swapped addresses and needed load/unload dates.

So that users now sees which work instructions are to be copied to new orders (and can change them, if required).

With these PTV xServer feature layers it is possible to reflect 2 years statistical data (about different times needed to pass a road segment on different days and times) in the routing & driving time distance calculation.

Feature layers can be activated on the vehicle type, in the 'Geo service features':
- PTV_TruckSpeedPatterns - statistical and time-dependent absolute speeds of road networks for trucks
- PTV_SpeedPatterns - statistical and time-dependent absolute speeds of road networks.

Once activated on the vehicle type, the feature layers are automatically reflected in the PTV xServer interfaces, when the vehicle (of this vehicle type) is used.

Please note:
- Apart from D365 activation, both feature layers must be also installed in the PTV xServer installation

New data entity was created, for export & import projects:
- TAL GPB Parameters

When failed delivery is registered, a new load leg on the failed delivery stop is added to the tour. This leg is added, and later within the same process it is marked as "Failed delivery". If Synchronous change tracking is used, then this leg ends up into "Instruction activity rules" processing and can result in new instruction activities being added to the failed delivery stop. This will cause the failed delivery stop to "reopen" in the app, forcing the user to complete the new activities on that stop before they can start working on other tour stops.

If Asynchronous change tracking is used the system works as expected and no additional activities are created.

CAPcargo recommends customers to use Asynchronous change tracking and therefore the issue should not impact customer systems where the recommendation is followed. Additionally the issue can only happen if such instruction activity rules exist that would create activities on the delivery tour stops for loading.

Data migration task for 92318.

Data migration task populates human resource effectiveness from the worker effectiveness.

The issue was happening when tour stops were absolutely minimized in the tour stop overview in GPB gantt screens (ie. when tour stop overview was zoom out to maximum in level 3), then the work instruction "i" icon was sometimes misbehaving:
- its tooltip overview grid was showing as empty, even though there were some work instruction existing for this tour stop
- upon clicking, the D365 browser window (with work instruction overview) was not opening

The issue was happening when different capacities per tour stop were to be applied (eg. because of vehicles, countries, transport types...).

Mobile app tour clean up periodic task was previously not cleaning any mobile app tours; the issue was introduced by 90618 task (Mobile app tour clean up - enhance stability by limiting the request rate/size (not trying to delete all tours from middleware in one request)), already in 10.0-CAP28.1/CAP29.0. The issue was corrected.

The issue was especially happening when one trade order line was picked in two different works, with different container types.

In some constellations, the batch job "Geocode addresses" does not properly set the flag on the address "geocoding failed" to true, if the geocoding did not find a successful result according to the parametrization. This was fixed. - This did not do further harm in dispatching or operations (geo-coordinates were correctly set to 0/0), other than indicating to the batch next time to re-geocode this address again.

In some constellations, the save button on the 'edit address' form showed wrong infologs. e.g. address was wrong, but an info 'successful geocoding' appeared. Data in the background were correctly stored, also flag "geocoding failed". This was fixed.

In the dialog for dispatch directly transport order into existing tour, it was previously possible to change several tour related fields in the grid (eg. vehicle, trailer, passenger etc.), which would then modify assigned resources, leading into multiple/duplicated resources on the tour. The issue was corrected and the whole tour grid is now locked for editing.

The issue was happening only in the systems with advanced invoice status logic activated in the main TMS parameters. Then the infolog "Transport order XYZ is delivered, cancellation via EDI is not allowed." was shown, even though the transport order was already invoiced. The issue was corrected and the infolog now shows "Transport order XYZ is invoiced, cancellation via EDI is not allowed."