Release Letter

Previously the Activity framework allowed to specify activity time (per time class) just for main transport planning unit. This was enhanced - now it is possible to base the activity time calculation also on other transport planning units.

Conflict 465 ("Process - Manual quantity changes on [pre-]dispatched transport leg") was not correctly triggered in Conflict management for following TMS entities:

* Tour stop
* Orders in tour
* Resource leg

This was corrected.

No empty tour is created when user cancels the 'Dispatch in tour' transport leg planning dialog.

Following changes were done in CAP.TMS main parameters:

* 'Status term invoice' main parameter was moved to new field group 'Invoice status' in 'Invoice' section of main CAP.TMS parameters and parameter was renamed to 'Invoicestatus logic'.
* 'Invoice document type transaction' was moved to 'Invoice status' field group in 'Invoice' section of main CAP.TMS parameters and validation was added, to be able to activate 'Invoice document type transactions' only when 'Invoice status logic' is set to 'Advanced'.

Adding a transport leg to tour (that was sub-contracted via LTL parameterized resource) didn't create LTL order automatically. This was enhanced - now when tour is sub-contracted via LTL resource the LTL sub-contracting orders are automatically created for newly added transport legs.

D365 corrections that were needed for GPBapp leg screen to correctly manage conflict status icons on transport legs.

On Goods management form when Shipment lots were removed from Shipment (via Keep or Remove buttons) the form was not automatically refreshed and removed shipment lots were still displayed in the grid. This was corrected, the shipment lots are automatically disappearing from grid once they are removed.

New field 'Conflict status' was added to main grid of 'Dispatch light - Tours' form. Field shows the aggregated conflict status of tour, field can have three statuses/icons (no conflict, has conflict, conflicts are not determined).

Field 'Sequence' was enabled for user changes in staging table of 'TAL Activities' data entity, to allow better handling of various import/update business cases.

Following enhancements were added to the advanced location management form:

* New button "CAPcargo edit coordinate" - allows to manually specify the location geo-coordinates
* New button "CAPcargo Map by coordinate" - shows the location in Bing map, using location geo-coordinates
* "Protect Geo-coordinates" field - if set TRUE then the location geo-coordinates are protected from geo-coding process. Though it is still possible to manually change the geo-coordinates via "CAPcargo edit coordinates"

Having a tour with means of transportation that is timetable linked, it was possible to achieve negative tour times. This was corrected - the tour time cannot be anymore a negative value, it defaults to 00:00.

New "virtual" parameter TALPrimaryAddressIsTransportAddress was added to 3 existing data entities (Customers V3, Vendors V2, Global address book V2). When virtual parameter is TRUE then system creates automatically CAP.TMS address for primary address of customer/vendor/party record that is being imported/updated.
The entities cannot be used to remove transport address from the primary address. So even if the parameter is set to FALSE, it will not delete any data, or remove any associations during import.
In export, TALPrimaryAddressIsTransportAddress parameter is set TRUE if there is a transport address for the primary address of the customer/vendor/party.

Under certain circumstances it could happen that D365 standard free text posting process could post a free text invoice that was created from CAP.TMS (but was not posted yet by CAP.TMS).
We introduced a new flag 'CAPcargo Transport' on free text invoice header to distinguish between 'non TMS free text invoices' & 'CAP.TMS free text invoices'. We also modified D365 standard free text invoice posting processes (=button & batch) to exclude free text invoices that were created by CAP.TMS.

New button 'Invoice transport' was added to action pane on three 'order type' forms:

* Part-invoice order
* Collective part-invoice order
* Collective sub-contracting transport leg (LTL)

Button opens the overview of invoices/credit notes for one focused order. In case there exist just one invoice the overview opens in details view. In case of more invoices/credit notes the overview opens in grid view.

''Synch-Forward' and 'Synch-Backward' status icons were added to sales/purchase/transfer order lines, to show the shipment builder synchronization status of order line. Status icons indicate whether synchronization was successful or not.

For standalone transport orders when packages were created automatically during order creation process, the transport unit on packages was not initialized from transport order line. This was corrected.

When invoice status is switched to 'Advanced' and transport order is directly confirmed, then the invoice status was not updated (still stayed on 'Registered'). After the fix the invoice status is updated automatically even when transport order is directly confirmed under 'Advanced' invoice status mode.

Small GUI optimization of 'Address' section of transport order form (header view). Address related data now takes less screen space and the distance/time details are better structured, easier to read.

Package confirmation during tour confirmation now automatically refreshes the tour stop confirmation status.

In case a tour contained some not synchronized transport order, then during release to warehouse (from tour) the system showed error infolog "Function TALshiTourReleaseToWHS.run has been incorrectly called."
This was corrected and infolog was suppressed.

Several issues in transport order EDI import were corrected:

* During transport order EDI import the system didn't check for existing contact person data on party and always created new contact person data entry, which lead to many duplicities on parties. This was corrected - the system now looks for existing contact person data on party and only creates new in case it is not existing for given party yet.
* The imported phone number was not linked to created transport order, it is corrected now.
* Load / Unload email fields were added to EDI import entities.
* The Load / Unload phone numbers are not anymore created in customer contact information but in address contact information.

It was possible to manually create a transport order with no transport unit but with some transport quantity. This was corrected - now it is possible to enter transport quantity only when transport unit is specified.

Periodic function 'Contract mass update wizard' was using the today's date as criteria when searching for contract version that should be updated. Newly the periodic function uses the 'Valid from' date (that is specified in wizard) as criteria when searching for contract versions that should be updated. This allows to update price agreements even for future date (=for future contract version).

The interpretation of undefined opening hours (00:00-00:00) on transport address was changed in conflict management of transport leg. Previously the 00:00-00:00 was interpreted by conflict management of transport leg as 'always closed', now it is interpreted as 'always open'.

The external codes are not anymore validated in Transport order import/export data entities. The external code handling was moved from data entity level to checking process of imported transport orders.

The following issue/case was fixed:
InterCompany order with 2 order lines
Contract relation with unit "KM" (determination/calculation) & unit "HRS" (determination)
Fix price
2 Header surcharges
3 Tariff surcharges
--> Wrong splitting amongst the 2 order lines

It was possible to remove 'Delivery' purpose from CAP.TMS transport address. This has been corrected - now the system doesn't allow to remove 'Delivery' purpose from CAP.TMS transport address and informs user "The address purpose 'Delivery' cannot be removed from this address, because a CAPcargo Transport address exists, which bases on that role 'Delivery'!"

When defining a route plan on route/zone, it was not possible to select a zip code via lookup, system warned via error infolog 'Error executing code: The field with ID '0' does not exist in table 'LogisticsPostalAddressMap'. This was corrected - system now allows to use a zip code lookup on route plan of route/zone; the error infolog was removed.

During combined loading & unloading at the same tour stop, system sometimes scheduled loading before unloading. Such situation could cause a distortion in tour capacity calculation. Now during combined loading & unloading at the same tour stop system always first schedules the unloading, only afterwards the loading.

The usage of address geo-coordinates was improved in this task, leading to fewer calls of PTV xLocate component. This improves the overal performance of integration with PTV services.

The interpretation of undefined opening hours (00:00-00:00) on transport address was changed in conflict management of transport order. Previously the 00:00-00:00 was interpreted by conflict management of transport order as 'always closed', now it is interpreted as 'always open'.

Data entity "TALVehicleGroupEntityData" was renamed to "TAL Vehicle group", to better describe the content.

After activation of redesigned shipment builder the 'TAL Shipping means calculation rule line' data entity couldn't be used anymore as the data entity was linked to 'old/deactivated' shipment builder configuration key. This was corrected and 'TAL Shipping means calculation rule line' data entity is correctly linked to new/redesigned shipment builder only.

After activation of redesigned shipment builder the 'TAL Item transport unit combination' data entity couldn't be used anymore as the data entity was linked to 'old/deactivated' shipment builder configuration key. This was corrected and 'TAL Item transport unit combination' data entity is correctly linked to new/redesigned shipment builder only.

Data entity for 'TAL Activities' was adjusted, as sometimes import/update via this entity failed. Field 'Closed' was allowed for editing.

In the dialog for "Generate/Update tour out of route/zone" the weekday value was not automatically recalculated after the change of scheduled date. This was corrected - the change of scheduled day now leads to automatic recalculation of the weekday.

Menuitems for "New"and "Delete" were accessible in the xServer parameter form (in TMS main parameters). Both menuitems had no usage, as the system allows exactly just one set of xServer parameters. Hence both menuitems were removed.

During depot split it was posible to multi-select several depots, even though just one depot was effectivelly used/inserted. This was corrected, the multi-select was disabled and user can select only one depot when inserting a depot split on transport leg.

Previously in case when some upgrade data migration jobs were required to be run during CAP.TMS upgrade process, these data jobs must have been launched only via URL (via class runner). Which was not user-friendly and it was impossible to track statuses of these tasks.
This task introduces a simple management form via which it is possible to launch/track status of data migration jobs.

The form is accessible in main menu:
CAPcargo Transport -> Setup -> Data migration -> Data migration jobs

Upon every form opening the system scans for existence of new data migration jobs, and in case some new job is found it is added to the grip overview.
So the expected usage is that after every CAP.TMS code upgrade user checks the data migration job overview and in case new data jobs were delivered with code upgrade these can be launched directly from the management form. So there is no further need to launch data migration jobs via URL/class runner.

New data entity was added, for TALcsiIncident table. It allows to export csiIncident table for further external analysis (eg. in Excel etc).

It was possible to create a part invoice order without specifying a split address. Now the split address is required even when part invoice order is created manually (via transport leg split)

The change/delete of tour activity can be now performed only when tour is in status Dispatching/Released/Confirming.

Known issue ADO 44778 is fixed by this task. Now it is possible to create the transport address directly from "NEW ADDRESS" function, it is not needed anymore to use the "EDIT" address mode.

This fix expects 'D365 Finance and Operation 10.0.5 with Platform update 29' version installed (with KB 4504242).

During transport order EDI import, the planning quantities were converted from transport quantity only when all planning quantities were not specified (=not present in import file). Newly each planning quantity is processed (and potentially converted) separately, that means planning quantity 1 can be in imported and planning quantity 2 can be converted (from transport quantity) etc.

The pro-forma self-billing invoice for 'sub-contracting transport order' could not be generated, system failed with error infolog "A currency to convert from is required to retrieve exchange rate information.", even though there was no reason to apply a currency conversion.

Several issues were corrected in pre-order area, now it is again possible to generate transport orders from pre-orders.

In certain data constellation it was not possibleto remove the last transport order line even though the transport order was in status„Registered“. This was corrected - now it is not possible to remove the lasttransport order line only when transport order is in status “Plannable/Partiallyplanned/Dispatched/Delivered”.

Due to the removed functionality of Resource reservation, the parameterization of 2 process buttons in main TMS parameters was also removed, as obsolete:

* Attach resources
* Resource reservation

Some virtual fields in main TAL parameters were activated during data entity import even though the fields were not existing in import file. This was corrected - now the fields are activated/respected during import only when they really exist in import file. Following fields were affected:

* OneTimeAddress_PartyNumber
* ResourceSwapPlaces_PartyNumber
* UnitOfMeasureDistance_Symbol
* UnitOfMeasureDistanceEmpty_Symbol
* UnitOfMeasureDistanceLoaded_Symbol
* UnitOfMeasureDrops_Symbol

In case an item is enabled only for transportation management (i.e. warehouse management is not enabled on the storage dimension group of the item), then the picking status was limited to only 1 value: 'Goods registered'.

In order to provide a better handling of the only transportation management enabled items, the picking status calculation logic was enhanced to provide 2 additional statuses, when the picking of the item is not done by advanced warehouse management processes.

New statuses:

* 'Picked'
* 'Packing slip posted'

Disclaimers (regarding to the 2 new picking statuses, if item is only transportation management enabled):

* 'Packing slip posted' picking status supports only order type 'Sales order'
* 'Packing slip posted' picking status calculation analyses the status of the sales order line. Hence in case of partial delivery or splitting of the sales order line related load line (and delivering in 2 tours), the 'Packing slip posted' status is only shown if both load lines are delivered or open quantity is cancelled. It is strongly recommended to have 1:1 relation between the sales order line and the load line.

New data entity "TAL Package confirmation" was added to the TMS module, to be able to import/export the TMS package confirmation data.

Entity name: TAL Package confirmation
Staging table: TALPackageTourOrderLineStaging
Target entity: TALPackageTourOrderLineEntity

In certain circumstances it was possible to create a tour with empty tour start date and with unloading tour stop preceding loading tour stop. This was happening in some tour planning methods when combined loading/unloading occurred on same tour stop and detailed scheduling was deactivated on transport type.
The tour planning methods were corrected to not cause such inconsistent data situation.

When there were more migration data jobs existing for the same Job id, only first one was shown in "Data migration jobs" setup overview. This was corrected - now all migration jobs are shown in "Data migration jobs" setup overview.

In certain circumstances the geo-coding mechanism cannot locate provided address details but suggests some similar street name & number.
Previously the "suggest" dialog was focused entirely just on the street name & street number, and also only the street name & number was written back to the address. This could create an incorrect address, having a zip code and a city from original "wished" address but having a street name & number from "suggested" address.
This was corrected - now the "suggest" dialog contains also the zip code and the city, and all these details are then written back to the address.

Performance optimization of "Dispatch in tour" functionality where certain code/logic was used too excessively.

In 'route/zone' definition it was previously possible to manually change the start & end depot address details directly on 'route plan' grid. This was corrected - now the start & end depot address details are locked for manual editing in 'route plan' grid and user can change these only via start & end depot dedicated fields on 'route/zone' itself.

In "Data migration jobs" form the menuitems for "Run job" and "Change status" were available even when there was no migration data job in the main grid. This was corrected - now both buttons are available only when there is at least one migration data job in the main grid. In case of no data job the buttons are disabled/grayed out.

Performance optimization of "Generate/Update tour out of route/zone" functionality where certain code/logic was used too excessively.

In case the inventory quantity of the load line is bigger than the work created quantity, then the "Remove not-picked shipment lot" function didn't perform the load line splitting. This was corrected - now the load line splitting is done even when inventory quantity is bigger than the work created quantity.

Releasing a tour to warehouse could lead to GPB client crash when some errors were encountered in AX2012. This was corrected - now when 'release to warehouse' from tour encounters some AX2012 error, the GPB client is not crashing anymore and the user is informed via error infologs.

In certain circumstances the transport order shipment synchronization (when launched from the tour) could cause a database deadlock. The code was optimized for better performance and to avoid such deadlock.

The current existing configuration key CLXTALshiShipmentBuilder has to be split into 2 configuration keys to distinguish between Data and GUI/Logic. It has to be possible to keep all data of the old shipment builder but switch off GUI elements (Menuitems, form fields) and business logic:

* CLXTALshiShipmentBuilder - this configuration key is related to the GUI/Logic of the old shipment builder and will have to be switched off by customers transiting to the new shipment builder, as old shipment builder is NOT SUPPORTED ANYMORE.
* TALshiShipmentBuilderOldData - this configuration key is related to the Data of the old shipment builder and should be switched on by customers transiting to the new shipment builder.

For further information please see our published "Supply Chain Management" white paper:
https://capcargo.sharepoint.com/:b:/g/EWlv7jOdjXpDlh90TRLhPQkBTW9rg63jhBulK7L7e3bWhg?e=BrqEfB

It is now possible to add project specific buttons to various GPB screens, by simple form parameterization.
Definition of new generic buttons happens in CAPcargo Transport -> Setup -> GPB generic buttons, where following characteristics must be specified:

* GBP screen - on which GPB target screen the buttons should appear
* Object type - defines the content of the button/menuitem. E.g. 'tour' related button will not work correctly if set with 'Object type'=tour order line etc.
* Selection type - defines whether button/menuitem supports multi-selection or records or only single record selection.
* Label - button text. Currently the label is interpreted as 'plain text', it is not possible to use true language specific labels.
* Help - button help text. Currently the label is interpreted as 'plain text', it is not possible to use true language specific labels.
* Menu item type - defines the type of menu item (can be Display/Output/Action)
* Menu item name - menu item itself
* Refresh type - which GPB refresh to trigger once button/menuitem is used (can be Undefined/Full refresh/Web service)

Combinations of 'GBP screen' (and 'Object type') are not validated, following combinations are supported:

*
Gantt screen tour (Tour/Tour stop/Tour order line)
*
Gantt screen resource (Resource assignment)
*
Resource screen (Resource)
*
Legs screen (Transport leg)

The custom filters are then initialized during GPB client opening to following places:

* for Transport orders /-legs screen & both gantt screens - the buttons/menuitems are added to new dedicated 'Generic buttons' tab, on the main button ribbon
* for Resource selection screen - the buttons/menuitems are added between filters and main grid

Supported screens:

*
Transport orders /-legs screen
* Both gantt screens
* Resource selection screen

The map screen is not supported.

Limitations:

*
In general the combinations of fields (and entities) in button definition are not (yet) validated, so parameterization requires a certain knowledge of CAP.TMS functionality.

New infolog message "Field 'Mode of delivery' must be filled in." was added to shipment builder creation process (=when transport order should be generated) to inform user why no transport order was created. As having no "Mode of delivery" on any trade order line typically signifies a missing setup of automatic initialization of "Mode of delivery".

Drag & drop of POI (=gas station, harbor, parking place etc.) to gantt chart was not possible, system didn't add the POI to the tour. This was corrected - now the POI's can be dropped to gantt chart (to level 1 or level 3).

During several processes in CAP.TMS users could encounter a warning infolog "The implicit conversion from date to utcDateTime is not supported."
Following process were affected:

* during logistics postal address management (in expiration date)
* during change of rough scheduling date on transport legs

This was fixed - now the dates are handled correctly in both processes.

Product description (of trade order item) was sometimes not showing correctly on transport order line (tab General) even though the transport order was synchronized with trade order(s).

Two GUI enhancements of customer invoice pool were done:

* form now starts in edit mode (thus it is possible to open the "select" filters directly)
* and the "select" filter form was transformed into more user friendly dialog

Several issues were corrected when drag & drop was performed from map (or from transport leg form) to gantt forms. Now it is possible to create tour via drag and drop, forms are refreshed etc.

The current certificate which is used for signing the TAL license expires 14.12.2019. A new one is needed to be installed, to be able to use CAP.TMS module after 14.12.2019. The installation of new certificate requires also a change in the TAL LicenseCode object in AOT, which is delivered/provided by this this task.

Disclaimer:
The installation of new TAL license is still required, it is not done by this task. This task only contains some code changes that also has to be in place, besides the TAL license.

Transport customer invoice reversals (both order and whole invoice reversal) were enhanced by the functionality of "reason code" classification. When issuing a reversal the user must select a reason code from predefined master data list. Reason code is then stored on invoice reversal (both on header and grid view).
Additionally a new optional parameter "Exclude reversed transport orders from calculation" was introduced to price calculation batches that allows to exclude orders (for which customer invoice reversal was issued) from automated price calculation process, to prevent accidental automated order calculation (and potential automated invoicing).

Enhanced user awareness in overpackage transport leg planning into tour when related transport legs are processed in the background.

In gantt forms the 'Assign carrying resource' menuitem previously existed only as a parameterizable 'Process' tab element. This task introduces 'Assign carrying resource' menuitem also as a standalone 'Dispatching' tab element; menuitem is placed to 'Resources' field group.

Despite the CAP.TMS enhancement (to have up to 5 planning units) the GPB still showed on several places only 3 planning units. This was corrected - now GPB shows correctly 5 planning units (if they are defined/activated).

New functionality was added to the CAP.TMS module via which it is possible to affect when order becomes invoiceable based on status of expected documents/order attachments.

Process is following:

* Per customer/vendor account it is possible to define which document types should be used for TMS orders ("Rule invoice document types"):

* Document type can be set as "Invoicing criterion", which means that TMS order will turn invoiceable only when all "Invoicing criterion" document types are "Received".
* Document type can be set as "Verification required", which means that TMS order will turn invoiceable only when all "Verification required" document types are manually "Verified"
* Transport order based document type can be set as "Invoice attachment", which means that such document will be also attached to TMS customer invoice.

* Expected document types are then automatically created for TMS orders of this customer/vendor (available on TMS order header as "Status invoice documents".
* Attaching an attachment of "Invoicing criterion" document type to TMS order sets automatically "Received" flag.
* For "Verification required" document types the "Verified" flag is to be set manually by user (after the received document is manually checked/verified, as correct and valid).
* "Status invoice documents" (aka document types) are used as an additional criteria when setting TMS orders as invoiceable. So only TMS orders with "Invoicing criterion" document types that are "Received" (and additionally with "Verification required" document types that are "Verified") are admitted for invoicing process.

Example of document types - CMR, Proof of delivery etc.

Disclaimer:
The functionality of "Status invoice documents" expects CAP.TMS module to be in "Advanced" invoice status logic (defined in main TMS parameters, section Invoice, group Common, field group Invoice status, parameter Invoice status logic).
The functionality of "Status invoice document" won't work in "Simple" invoice status logic, as this combination is not supported.

When a new tour was created (in D365 form launched from the GPB) then the GPB resource dispatching screen was sometimes not properly refreshed after closing of the D365 form. This was corrected - now the GPB resource dispatching form is automatically refreshed once the D365 form is closed.

Previously in case when some upgrade data migration jobs were required to be run during CAP.TMS upgrade process, these data jobs must have been launched only via URL (via class runner). Which was not user-friendly and it was impossible to track statuses of these tasks.
This task introduces a simple management form via which it is possible to launch/track status of data migration jobs.

The form is accessible in main menu:
CAPcargo Transport -> Setup -> Data migration -> Data migration jobs

Upon every form opening the system scans for existence of new data migration jobs, and in case some new job is found it is added to the grip overview.
So the expected usage is that after every CAP.TMS code upgrade user checks the data migration job overview and in case new data jobs were delivered with code upgrade these can be launched directly from the management form. So there is no further need to launch data migration jobs via URL/class runner.

Several issues were identified and corrected in shipment builder synchronization process that could in certain constellation lead to:

* failure to delete the transport order line during shipment synchronization, hence causing the transport order line duplicity and detachment of transport order line from shipment building structure
* shipment appears as "synchronized" but in reality is not synchronized
* impossibility to release tours into warehouse

In 'Dispatch light - Transport legs' form it was possible to manually change the SCM status of transport leg. This was corrected - now the SCM status is not editable on transport leg, as the field is entirely managed by system.

Description was added to CAP.TMS periodic tasks, to explain to user the periodic task (=class) content. Users will see the description when setting up the batch journal tasks.

Buttons for 'New' and 'Delete' transport legs were removed in ‘Dispatch light – transport legs’ form, as they could never be used (=were always deactivated in code).

Conflict management status of tour/transport order/leg was sometimes not automatically synchronized with real conflict management data and users had to manually refresh the tour/transport order/transport leg records to see current conflict management status. This was corrected - now the conflict management status of tour/transport order/transport leg is refreshed automatically once the conflict management form is closed.

Due to missing security/role definition, several batch tasks in 'CAPcargo Trade & Distribution' module were only available to users with 'System administrator' role. This was corrected - the batch tasks were properly assigned to CAP.TMS roles, depending on each batch task context. Following roles ware used/enhanced:
T&L Transport clerk
T&L Transport manager
T&L Sales clerk
T&L Purchase clerk
T&L Warehouse worker
Shipment Builder system administrator

The general filter on contract form didn't work, hence it was not possible to search for the specific contract. This was corrected.

Via 'Change rough plan date" functionality in 'GPB Transport orders /-legs' screen it was possible to manually achieve a wrong/invalid sequence of transport leg dates. E.g. unloading should be happening before leading etc. This was corrected - the date validations in "Change rough plan date" dialog were enhanced, to prevent user from saving the wrong/invalid transport leg date sequence.

Start & end addresses were not mandatory on default tour template. This was complicating the tour management process, as CAP.TMS module expects to have always start & end addresses on tour. This was corrected - now the start & end addresses are mandatory on default tour template.

Business case:
Customer has an area in the warehouse, where he stores palletized goods, which already has a container type assigned to the license plate. In this case, the warehouse worker doesn’t want to select a container type on the mobile device, but wants to use the already assigned container type.​
​​
Solution:​
If the to-be-picked goods/license plate already has a container type, it is initialized to the mobile device, but is left open for user change.
If the to-be-picked goods/license plate has no container type, then user has to specify container type in the mobile device.

In certain circumstances it could happen that transport order didn't appear in TMS invoice pool even though all pre-invoicing conditions were fulfilled. Such transport order could not be invoiced and required a special manual 'data correction' support action. The issue in the code has been identified and corrected, such cases should not appear anymore.

When transport order had different invoice account than customer account then such transport orders were not processed by automated periodic function for transport customer invoicing. This was corrected - now periodic customer invoicing function also include such transport orders.

First part of performance optimization of Resource selection form (when resources are being loaded to the screen), to achieve a faster responsiveness of the Resource selection form. The loading of the resource data is newly performed in two waves:

* 1st wave - loading data is reduced to minimum (to allow user continue working with the screen as soon as possible). The user session is still blocked until following data is entirely loaded:

* Resource Available/Planned classification (to be able to position resource into horizontal sections)
* Resource driving distance (to be able to sort by distance inside horizontal sections)

* 2nd wave - the rest of data. User session is unblocked at this stage, so users can continue working while the data is being loaded (via parallel background services). Following data is loaded in the 2nd wave:

* Resource driving time
* Resource Fitting/Non-fitting classification
* Resource details - Overview/Qualifications/Capacity/Cost (only when individual resource is selected)
* Resource Past/Future assignments (only when individual individual resource is selected)

As a consequence the resources are not anymore sorted by "Fitting/Non-Fitting" criteria (but only by the distance criteria), as the "Fitting/Non-Fitting" data is not available in the 1st wave. Users are advised to use the "Fitting" & "Non-Fitting" checkbox filters instead.

In Resource dispatching gantt form it was sometimes not possible to launch tour confirmation even though the tour status was "Released". This was corrected, now the tour status is re-read correctly before launching the tour confirmation.

Conflict analysis form can now be opened also from GPB screens.

In Resource dispatching gantt form it was sometimes not possible to launch tour confirmation even though the tour status was "Released". This was corrected, now the tour status is re-read correctly before launching the tour confirmation.

Recently released self-definable resource icons didn't show correctly on several places in GPB. Following places were enhanced/corrected:

* the 'drag' dialog of resource from RS to GSR/GST
* level 2 of GSR/GST with resource allocation details
* visualization on map

Order collection (when done via batch) in certain constellations didn't respect correctly the order collection rules. This was especially happening when several load/unload based order collection rules were to be applied in the same batch run.

In certain cases the periodic task "Generate/Update tour out of route/zone" was crashing with unhandled error and user was informed via infolog "Due to breaking the over package impact scope, process cannot be executed. %1 legs are missing to fulfill the scope!" and not processing the further transport legs.
The periodic task was enhanced to handle these cases in a better way, informing user (with same infolog") but stepping over the problematic cases and processing further transport legs.

The design of several pre-defined TMS vehicle icons was enhanced, for better readability of the icons in the GPB screens.

In GPB gantt screens the delay (and earliness) of tour is shown by red (and green) visualization of gantt chart. Previously the red & green visualization was based rigidly on difference between detailed scheduling and calculated ETA. For certain business types (especially in FTL logistic, on long tours) this is not sufficient as the tour 'planning' is not done based on detailed scheduling but rather based on experience of dispatchers and on other (rather off system) logic. For these business types the system now allows to determine the delay (and earliness) tour visualization based on difference between calculated ETA and transport order dates (aka 'customer wished dates').
Main parameterization is done on transport type, via new field 'Configuration Gantt bar extension' id Dispatching tab. Possible parameterization:

* None - delay/earliness tour visualization is entirely switched off (=no red & green visualization on tour gantts)
* Delayed/early arrival - delay/earliness tour visualization is switched on and is done based on difference between detailed scheduling and calculated ETA (=this is previously existing logic)
* Deviation to customer wish - delay/earliness tour visualization is switched on and is done based on difference between calculated ETA and customer wish (=this is newly added logic).

For 'Deviation to customer wish' logic there is an additional pre-requisite, system uses transport order unload date as 'customer wish' only when unload date of transport order is marked as 'Show in GPB / Warn at change'.

Key characteristics:

* In the 'Deviation to customer wish' logic the Manual ETA is considered as PLANNING information, not CONFIRMATION information, hence is not leading to red/green delays, but to a different visualization of the bar, i.e. blue frame instead of black frame on main tour gantt chart (in level 1).
* The red & green visualization happens only on tour end (=to signify whether truck/tour ends earlier or later than expected). There is no visualization on tour start, as it is expected that dispatchers plan tour start always as 'fitting' and the visualization of delay on tour start is not needed.
* Also the red & green visualization is not calculated for individual tour stops but only for tour end.
* Additionally new filter 'Early/late customer wish' was added to 'filters' dialog on tour gantt, to allow dispatchers for example to filter the tours that are earlier than 60minutes, or delayed more than 45minutes etc.

New SSRS report for pallet/package label printing was added to the system. It is possible to Print labels from following places:

* from main TMS menu (CAPcargo Transport -> Reports -> Transport order -> Print labels)
* from transport order
* from package management
* from Dispatch light - Tours

Usage of resource id (and resource description) and TMS vehicle id (and vehicle descriptions) in the GPBapp forms was not consistent with the previous GPB releases. This was corrected in the following way:

* in Resource Dispatching gantt form, in main grid, system now displays resource id (and resource description)
* in Resource selection form, in resource filter lookup, system now displays resource id (and resource description)
* in Resource selection form, in main grid, system now displays resource id (and resource description)

In both gantt forms the tour end gantt visualization was in certain parameterization not exactly corresponding with tour end "on mouse over" details. This was corrected, now the tour end is visualized correctly in gantt bars.

It is now possible to upload attachments to TMS orders via EDI import.

In general two basic cases are supported:
1) upload plain 'notes' to D365. In this case the source file has just a text field that is attached to D365 orders as a 'note' type.
2) upload 'files' to D365. In this case the source file is a zip file, with pre-defined structure of files/folders.

Key characteristics:

* Functionality is using document attachments as target in AX side
* New data entity "TAL Imported attachments" was added to the system
* After the files are imported via data entity into D365 (and before the attachment is added to order document attachments), files are pooled into the staging table (CAPcargo Transport -> Inquiries -> Imported attachments).
* Then the batch processes the staging table and attaches files to exact order (ie. into order document management). The batch is available in main menu: (CAPcargo Transport -> Periodic -> Transport order import -> Process imported attachments)
* Especially for 'file' imports there are certain requirements on file (and folder) structure.
* System is using several criteria for determination of which order should be the target for each attachment, and the specification of which criteria is to be used is done in content of the file. Following criteria are supported:

* Transport order id
* Customer account (table/group/all)
* Customer reference
* External document number

Following tour related data entities were restricted for data import purposes:

* CIRTRATour
* CIRTRATourLine
* CIRTRATourOrderLine
* CIRTRATourAction
* CLXTALPackageTourOrderLine
* CLXTALPackageTable

Above listed data entities are available only for exporting from D365. Importing into D365 via these data entities is not officially supported by CAPcargo AG and is disabled.

Data migration job for 54278 task. Removes duplicate migration jobs from other legal entities.

Cross-docking duty was moved from TALWarehouseWorker (T&L Warehouse Worker) role to the new role "T&L Depot clerk", to better manage the security of the cross-docking overview form.

Vehicle filter lookups in both gantt forms were enhanced to allow intelligent fulltext lookup filtering. Dispatchers can now type for example "pe" (without quotes) into vehicle filter field and lookup will filter only vehicles that contain this string in any column (=either in vehicle id or in vehicle description). I.e. for "pe" string lookup will filter records that have "Peugeot" but also "Opel" in any lookup column.

Additionally the column widths in vehicle/resource filter lookups were enhanced to show also longer vehicle/resource ids and vehicle/resource descriptions.

Following enhancements were done for invoicing frequency functionality (both for manual & automated invoicing methods):

* Invoicing frequency (on transport order and on 'part-invoice' order) is now initialized from Contract/Version/Relation, if defined there.
* Invoicing frequency is now treated as hard criteria for order collection, ie. orders with different invoice frequency are not collected (and invoiced) together in the same order collection.
* New filter for invoicing frequency was added to the customer invoice pool opening dialog and to the Invoice automation setup

New data entity for CIRTRAAddressQual table (Address Qualifications), to improve the 'mass' management of the TMS Address.

New data entity for CIRTRAWaitTime table (Waiting time), toimprove the 'mass' management of the TMS Address.

New data entity for CIRTRAHours (Business hours), to improve the 'mass' management of the TMS Address.

Previously the performance of TMS address lookup (when inserting new tour stop on level 3 on gantt forms) was depending on amount of TMS address in the system, sometimes even causing a GPBapp crash (in case of tens thousands of TMS addresses). This was corrected, now system loads only TMS address that can be immediately shown in lookup dialog (and loads other TMS addresses only when scrolling in the lookup dialog further).

Roles for T&L Shipment Builder System Administrator (TALshiShipmentSystemAdministrator) and T&L Warehouse Planner (TALshiWHSPlanner) were depreciated, their content was moved to another roles:

* T&L Shipment Builder System Administrator (TALshiShipmentSystemAdministrator) content was moved to T&L Master Data Management Clerk role
* T&L Warehouse Planner (TALshiWHSPlanner) content was moved to T&L Warehouse Worker role

New data entity for TALgpbVolumeSummaryUnits table (Set up volume summary units for transport orders / -legs), toimprove the 'mass' management of the GPB parameterization.

Data entity for CIRTRAColRouteRoutes (Dispatch sector content) was renamed:

* previously was "TAL Routes/zones in dispatch sectors"
* newly is "TAL Dispatch Sector Route/Zone assignment"

Lookups for default load/unload address on customer account form were enhanced, to match the address lookups as on transport order form.

The structure of package identification (eg. identification type, code, content etc.) was corrected.

Recently introduced enhancement of the visualization of tour early/delay (against the 'customer wish') had unexpected impact on already existing (=historical) tours, on which the early/delay visualization showed that the tours were always early. This was corrected, now the early/delay is displayed correctly even on already existing (=historical) tours.

To be able to combine several packages into an overpackage it is now possible to create a package (overpackage) and set the parent package reference on the sub packages, in the package management form (when launched from main TMS menu).
This additionally provides the overpackage creation for transportation (not only shipment builder based) transport orders. Hence it is possible, using this feature, to guarantee that several transport orders are planned together into a tour (first leg only counts)

Disclaimer: It is possible to break this functionality if users create quantity splits on transport legs (ie. breaking apart the overpackage structure).

In GPB gantt screens the delay (and earliness) of tour is shown by red (and green) visualization of gantt chart. Previously the red & green visualization was based rigidly on difference between detailed scheduling and calculated ETA. For certain business types (especially in FTL logistic, on long tours) this is not sufficient as the tour 'planning' is not done based on detailed scheduling but rather based on experience of dispatchers and on other (rather off system) logic. For these business types the system now allows to determine the delay (and earliness) tour visualization based on difference between calculated ETA and transport order dates (aka 'customer wished dates').
Main parameterization is done on transport type, via new field 'Configuration Gantt bar extension' id Dispatching tab. Possible parameterization:

* None - delay/earliness tour visualization is entirely switched off (=no red & green visualization on tour gantts)
* Delayed/early arrival - delay/earliness tour visualization is switched on and is done based on difference between detailed scheduling and calculated ETA (=this is previously existing logic)
* Deviation to customer wish - delay/earliness tour visualization is switched on and is done based on difference between calculated ETA and customer wish (=this is newly added logic).

For 'Deviation to customer wish' logic there is an additional pre-requisite, system uses transport order unload date as 'customer wish' only when unload date of transport order is marked as 'Show in GPB / Warn at change'.

Key characteristics:

* In the 'Deviation to customer wish' logic the Manual ETA is considered as PLANNING information, not CONFIRMATION information, hence is not leading to red/green delays, but to a different visualization of the bar, i.e. blue frame instead of black frame on main tour gantt chart (in level 1).
* The red & green visualization happens only on tour end (=to signify whether truck/tour ends earlier or later than expected). There is no visualization on tour start, as it is expected that dispatchers plan tour start always as 'fitting' and the visualization of delay on tour start is not needed.
* Also the red & green visualization is not calculated for individual tour stops but only for tour end.
* Additionally new filter 'Early/late customer wish' was added to 'filters' dialog on tour gantt, to allow dispatchers for example to filter the tours that are earlier than 60minutes, or delayed more than 45minutes etc.

When company logo is specified on legal entity, it is now printed also on Intercompany transport invoice.

Capacity check (when legs are to be added to tour) is done based on route's:

* Resource
* Vehicle type
* Default vehicle type of transport type

For latter two the capacity check was not calculated properly. Bug was corrected - now the capacity check during tour planning is calculated in the same way for all the capacity sources.

Transport customer invoice reversals (both order and whole invoice reversal) were enhanced by the functionality of "reason code" classification. When issuing a reversal the user must select a reason code from predefined master data list. Reason code is then stored on invoice reversal (both on header and grid view).
Additionally a new optional parameter "Exclude reversed transport orders from calculation" was introduced to price calculation batches that allows to exclude orders (for which customer invoice reversal was issued) from automated price calculation process, to prevent accidental automated order calculation (and potential automated invoicing).

In gantt forms rescheduling the whole tour in time forwards/backwards (via drag & drop) sometimes didn't automatically re-calculate all planning (and ETA) times & dates in level 3. This was corrected, now the planning (and ETA) values are re-calculated after whole tour drag & drop.

In Tour dispatching gantt form when changing the duration of tour (via drag & drop of tour end point), users sometimes could encounter a stack trace error. This was corrected, now the error is prevented and users can finish the process by 'drop' operation.

In case an item is enabled only for transportation management (i.e. warehouse management is not enabled on the storage dimension group of the item), then the picking status was limited to only 1 value: 'Goods registered'.

In order to provide a better handling of the only transportation management enabled items, the picking status calculation logic was enhanced to provide 2 additional statuses, when the picking of the item is not done by advanced warehouse management processes.

New statuses:

* 'Picked'
* 'Packing slip posted'

Disclaimers (regarding to the 2 new picking statuses, if item is only transportation management enabled):

* 'Packing slip posted' picking status supports only order type 'Sales order'
* 'Packing slip posted' picking status calculation analyses the status of the sales order line. Hence in case of partial delivery or splitting of the sales order line related load line (and delivering in 2 tours), the 'Packing slip posted' status is only shown if both load lines are delivered or open quantity is cancelled. It is strongly recommended to have 1:1 relation between the sales order line and the load line.

Due to performance reasons, the recently released enhancement of visualization of existence of the 'manual ETA' on tour gantts (=via blue highlight around tour gantt bars, part of ADO 39447) had to be suppressed. Now the tours with manual ETA are not anymore highlighted by blue line, dispatchers can still locate such tours via early/late (=green/red) visualization.
Additionally small graphical imperfections were also corrected on tour gantt bars.

It is now possible to add the project specific buttons to various GPB screens, by simple form parameterization.
Definition of new generic buttons happens in CAPcargo Transport -> Setup -> GPB generic buttons, where following characteristics must be specified:

* GBP screen - on which GPB target screen the buttons should appear
* Object type - defines the content of the button/menuitem. E.g. 'tour' related button will not work correctly if set with 'Object type'=tour order line etc.
* Selection type - defines whether button/menuitem supports multi-selection or records or only single record selection.
* Label - button text. Currently the label is interpreted as 'plain text', it is not possible to use true language specific labels.
* Help - button help text. Currently the label is interpreted as 'plain text', it is not possible to use true language specific labels.
* Menu item type - defines the type of menu item (can be Display/Output/Action)
* Menu item name - menu item itself
* Refresh type - which GPB refresh to trigger once button/menuitem is used (can be Undefined/Full refresh/Web service)

Combinations of 'GBP screen' (and 'Object type') are not validated, following combinations are supported:

*
Gantt screen tour (Tour/Tour stop/Tour order line)
*
Gantt screen resource (Resource assignment)
*
Resource screen (Resource)
*
Legs screen (Transport leg)

The custom filters are then initialized during GPB client opening to following places:

* for Transport orders /-legs screen & both gantt screens - the buttons/menuitems are added to new dedicated 'Generic buttons' tab, on the main button ribbon
* for Resource selection screen - the buttons/menuitems are added between filters and main grid

Supported screens:

*
Transport orders /-legs screen
* Both gantt screens
* Resource selection screen

The map screen is not supported.

Limitations:

*
In general the combinations of fields (and entities) in button definition are not (yet) validated, so parameterization requires a certain knowledge of CAP.TMS functionality.
*
For many CAP.TMS menuitems/processes further code adjustment is still needed, these can be done on project specific base.

It is now possible again to define the 'default finance dimensions' on T&L order statistic calculation / Cost accounting categories. The functionality was lost during the AX2012->D365 upgrade.

Changing a package unit manually in the package management form (when opened from transport order form) users could sometimes experience a strange behavior, when package unit (that was selected in the lookup) was not effectively used.

When TAL forms are launched & closed from GPBapp, the GPBapp gantt screens are automatically refreshed. This mechanism was improved in this task, as sometimes not all GPB elements were refreshed entirely.

Data entity for TALUnitOfMeasureConversion table was corrected.

Previously the tour confirmation of parent package (and sub-packages) were two independent processes. Newly when dispatchers are confirming the package (that is linked to some parent package) system identifies such case and asks user "Selected package is part of parent package: %1. Would you like to confirm the whole parent package? “Yes” will confirm all packages of this parent package in the tour stop. “No” will confirm only the selected package."
So now it is possible to confirm the unloading only of first sub-package (and the rest of related sub-packages is confirmed automatically too).

On both gantt forms, it was previously possible to launch a "Show capacity" dialog that showed the resource utilization for each tour stop.
In D365 installation the dialog was previously a D365 dialog (which was not user friendly and was performance lacking), which is newly replaced by GPBapp native dialog.
In AX2012 installation the dialog was already previously a native GPBapp dialog, meaning there is no affect of the task on AX2012 installations.

Several bugs were corrected in the area of the "Package management" dispatching. Packages were not correctly handled during quantity split on the transport leg, packages were not correctly assigned to split off transport legs etc. Also the package management view from transport leg was enhanced to show packages that are related to transport leg only.

Performance enhancement of Resource selection form. Previously the whole Resource selection form data was reloaded after every D365/AX2012 browser form/dialog closing. This was enhanced, now the Resource selection form data is reloaded after D365/AX2012 browser form/dialog closing only when it makes sense (e.g. after Strategic tour routing was performed, after new tour was created etc.)

It is now possible to define (=upload) a vehicle (=truck/trailer) picture to TMS vehicle master data, which is then also shown on Resource selection form in GPBapp.

Followup of 44385 enhancement. In 44385 there was introduced a functionality to calculate transport orders with 'zero' price. This tasks handles the cases when 'zero' price is achieved only by order re-calculation (eg. due to price agreement change).

Index based surcharge is now correctly calculated even when used in the tariff surcharge groups.

It is now possible to open the tour confirmation form when the tour has any other status than "Dispatching". When user tries to open tour confirmation on tour that is still in status "Dispatching" the infolog "Tour confirmation form can only be opened if tour status is higher than "Dispatching"." is populated.

The map control labels (ie. tour airline view, Show resource legs) are now showing correctly in GPB map screen, even in German language version.

The label for "Transport orders /-legs" now shows correctly in GPB start screen, even in German language version.

Packages with registered identification code (eg. barcode) were sometimes not showing on the dedicated Package identification code form.

Several performance related improvements were done in the map component, in process "Show tour on map". This affects the processes that were launched from GPB forms (eg. "Show tour on map") as well as processes that were launched from map form (eg. Pull tracks / Clear tracks).

Transport orders (that have some some Part-invoice order attached) were sometimes still appearing in the transport order invoice pool. This was corrected, now transport orders (that have some some Part-invoice order attached) will not get flag Calculated set TRUE, hence they will not appear in transport order invoice pool.

Sometimes it was not possible to generate a Part-invoice order collection, when a preliminary collection already existed in the system.

Field "Tour Id" was removed from the Invoice automation setup rules as it makes no sense to setup a periodic invoicing task for self-billing against individual tour id.

Transport type parameter "Automatic package creation" is now properly linked to "Package management" license configuration.

The data conversion job transforms the data from previously existing qualifications into the new structure of qualification framework.

Sometimes it was not possible to insert a depot split on transport legs for which some packages were registered. This was happening especially when transport order was already depot split via some cross-docking rule.

To improve the map performance (and to enhance user experience) a resource "stacking/grouping" was introduced to the map component.

Previously in case of several resources being located at exactly the same address, the system listed on map all the resources as individual icons in a box which could take a lot of space since many resources could be at one place.
Newly instead of individual icons (for resources being at the same place) system shows only one summary icon (ie. "pin") with resource count, the individual resource details (and icons) are available only in detailed window after mouse click.

When the "Distance and time calculation" was launched from GST then the driving time & distance was calculated and users were informed by infolog about calculation results. But when the same functionality was launched from GSR then the driving time & distance was calculated but users were not informed by infolog. This was corrected - now the users are informed via infolog regardless whether the process was launched in GST or in GSR.

When the "Close shipment building" functionality was launched on the Resource dispatching screen, it sometimes did not succeed and users were getting an error infolog "The remote server returned an error: (500) Internal Server error." The issue was corrected - the "Close shipment building" functionality works also when launched from Resource dispatching screen.

Newly introduced functionality of opening GST (via "GPB - Tour Dispatching" or "Go to tour (GPB)" options within D365 forms) is not 100% reliable, sometimes the GST is not opened, Functionality works the best when GST screen is already launched.
Also the "Show in GPB" options within D365 are visible even when user does not have a GPB security role.

When route capacity was exceeded on the existing tour (and load/unload address was not yet being served on this tour), then previously "Generate/Update tour out of route/zone" planning process did not automatically create a new tour and transport legs were left unplanned (and user was informed by infolog). This was enhanced and now the "Generate/Update tour out of route/zone" planning process automatically creates a new tour (and allocated transport legs) when the capacity is exceeded on the existing tour (and load/unload address is not yet being served on this tour).

Following points were correct for "View details tour" context option (ie. 'right mouse click' on tour):
* the label shows proper translation in different language mutations
* the label is properly aligned with other labels

Pallet label SSRS report (eg. printout) was enhanced to include also the load & unload address names.

Previously when the "Find and update existing tours" parameter was switched off (in the "Generate/Update tour out of route/zone" dialog) then the resulting tour structure was not correct in certain constellation. Especially when there were more transport legs (belonging to various routes) being planned. This was corrected, now (in such constellation) the system correctly produces one tour per each route.

The 'Cost distance' calculation was corrected in the Resource selection screen.

Several labels were corrected in the 'Transport orders /-legs' screen, to display proper text even in other language mutations.

In some constellations the manually specified ETA figures on the tour stops were not respected during the tour confirmation process. This could lead to incorrect tour duration visualization after/during the tour confirmation (eg. tour 'shrinking'). The issue was corrected - now the manual ETA is respected in the tour confirmation process.
Also the 'Tour activity' update mechanism was enhanced, to respected the manual ETA figures during tour confirmation process.

On several TAL forms it is now possible to open and filter GPBapp directly, either via dedicated button ("Dispatched tour (GPB)" in transport order form/list page, in tour) or via checkbox ("Go to tour (GPB)" in 'Dispatch directly to new tour', 'Direct dispatch (route)', 'Dispatch directly' dialogs). If used then Tour Dispatching form is opened and first tour that holds given transport order/leg is pre-filtered.

Necessary prerequisites:

* GPBapp client has to be already launched (it is enough to have just main client window opened)
* Exactly just one GPBapp client has to launched
* User must have an access to GPB, via security parameterization

The functionality is in a 'pilot' mode, has certain limitation (please check Known issue 58537).

Users were sometimes encountering the "Buffer 'Tour ...' changed by another user!" error infolog when working with the tour in "Tour Dispatching" screen. This often happened when the tour was either directly searched by tour id, or when the tour was focused by "Open in GPB" D365 menuitems, or when the tour was focused by switching from GSR (via "View details in Tour Dispatching").

It may happen that transport orders can not be delivered (e.g. receiver is not present). In these cases, the transport order can be sent back to a predefined location (or to original delivery hub) and a new transport leg is created to be planned by the dispatcher for another delivery attempt. Also, for each failed delivery attempt, the value of a counter – in the transport order header – is increased by one, which can be the base of surcharge calculation.
Additionally the order track & trace (and order status message) functionalities were enhanced, to inform properly about the failed delivery.

The feature is launched by menuitem "Delivery of tour order line failed" in the Functions of tour confirmation form and can be launched only for the last delivery leg.

Previously the CAPcargo transport order could not be cancelled. There existed certain workarounds (eg. defining an own transport type for it and assign transport orders to be cancelled to the respective transport type). But these workarounds were not good enough for most of customer businesses and therefore we introduced a new way of cancelling transport orders.
The idea is that a cancel status (with a reason) can be added to the transport order, to mark a order as cancelled. It also has a certain impact on existing delivery planning - the transport legs (and tours) that are not yet "confirmed" are removed, order is returned back either to original delivery hub or to custom location.

The functionality is launched via "Cancel" menuitem in the transport order form.
The process can be also undone, via "Undo cancellation" menuitem in the transport order form.

Solution limitation:
* Quantity split – A transport order that is split in quantity cannot be cancelled anymore. In this case, the user can e.g. manually change the unloading address of the transport leg.
* Cancellation will not be allowed in case there exists a sub-contracting or intercompany involved for the transport legs that have to be cancelled.
* In case the cancel status will be removed from the transport order (ie. via "Undo cancellation"), there is no automatic update on the related transport legs, so the legs should be handled/reviewed individually and manually

The alignment of 'View details tour' on right mouse click context menu in GST & GSR gantt screens was corrected. The menuitem also now shows the correct translation in other language mutations.

Previously the amount of the decimal places that were shown in the planning unit visualization in GPB 'Transport orders /-legs' screen was not defined, which could lead to an excessive amount of decimal places on the screen (ie. all decimal places were shown). This was corrected - now the GPB 'Transport orders /-legs' screen respects the 'Decimal precision' (ie. a parameter on D365 Unit of measure). Only "non null" decimal places are shown.

The resources selected in GSR in level 1 should not appear again in level 2 of tour details. As the level 2 in GSR should show only an additional resources (ie. excluding the one focused in level 1). This was already temporarily fixed in the past releases, this task introduces a proper fix (ie. with better performance).

The dialog for "Direct dispatch (route)" (on the transport order) and "Generate/Update tour out of route/zone" dialog (on the transport legs) were redesigned, for better user readability.

Also the "Direct dispatch (route)" dialog now shows only the relevant routes (ie. the routes that belong to the transport legs of the selected transport order(s)). Previously all routes were shown in the dialog (ie. even the routes that could not be used for selected transport order(s)).

A new functionality of "resource swap" was introduced to tour planning. The idea is that motor vehicle & driver resources are exchanged between two tours, on selected address, on selected time. Together with resource swap a new tour stops are inserted to both tours (ie. swap location), and new "dock"/"undock" activities are inserted to tour stop (with swap location). Also the tour scheduling is adjusted (to respect the swap time), by inserting a "waiting" activity when necessary.
This allows the dispatchers to operationally optimize the tour planning, by detaching the trailer (with goods) from original truck (that did the goods pick up) to new truck (that will do the goods delivery).

Functionality works in following way:
* Dispatchers should multi-select two tours that should participate in "resource swap"
* Press button "Resource swap" in "Dispatch light - Tours" form
* In "resource swap" dialog select on which position the resource swap should happen (ie. by putting focus on desired tour stop in each tour). The system inserts swap location before the selected tour stop position.
* Define the swap location & swap time in the below grid of "resource swap" dialog
* Confirm the resource swap by "Swap resources" button in the Functions ribbon

Current limitations of the resource swap functionality:
* System does not validate the resource swap time, so users can define any swap time (eg. even in the past). That means that users be careful (and also properly trained) to use some meaningful swap time
* There is no "undo" option of the resource swap. In case the resource swap should be removed, it has to be done manually (ie. remove resources from tours, extend the motor vehicle & driver resource assignments, remove the swap locations).
* Both tours participating in resource swap are not anyhow internally linked together, meaning it is possible to see which tour was swapped with which tour only from the resource allocation level (eg. two consecutive sets of truck&driver were participating on delivery of one trailer).
* The resource swap functionality can be used only in the "Dispatch light - Tours" form, it is not yet accessible in the GPB. But with certain parameterization (and small limitation) it can be already now activated in GPB via "custom/generic" buttons.

In certain constellation the date and time in the header of the gantt did not correspond to the gantt grid, the gantt grid seemed "shifted". This was especially noticeable when the users moved back/forward in time in the gantt. The gantt grid alignment was corrected.

Provides the visualization of fuel locations/products/prices in the map component.
Fuel locations must be activated in the map component screen, by activating the "Gas station" in the "Get address types" lookup, in "Addresses" control.

When 'Message per package' parameter was not activated on the track & trace status message setup (but there were already some criteria specified), then no track & trace status messages were created by the system. This was corrected - track & trace messages are now created even when some criteria is specified but "Message per package" parameter is set FALSE, as such criteria are then ignored.

In Tour & Resource dispatching forms the performance of following filters was improved by removing the duplicate executions:
* Transport type
* Vehicle group
* Dispatch sector

Previously it was possible to launch the conflict analyzer from transport leg level only in GPB 'Transport orders /-legs' screen. This was enhanced - now the menuitem is available also in D365 'Dispatch light - Transport legs' form.

A bug was fixed in the date filtering in the transport order overview which was causing that even some "not fitting" transport orders were sometimes included in the filter result.

Previously the rough scheduling functionality was not working correctly for transport orders with "Strategy rough scheduling = Backward scheduling". This was corrected - now the transport leg dates are correctly calculated even for "Backward scheduling" transport orders.

Previously it was not possible to directly geo-code an address that had already "Geo-coding failed=TRUE". Users had to manually set the "Geo-coding failed=FALSE" and only then it was possible to geo-code the address. This was enhanced, now the geo-coding is possible even on addresses that were already marked as "Geo-coding failed=TRUE".

A follower of 26022 ("New functionality of "resource swap" is introduced to tour planning") feature, new menuitem for Resource swap was added to the GST screen, so it is now possible to launch the resource swap also from the GPB.

New technical framework was added to the D365/TMS which allows the adding of project specific custom fields to GPB OS screen without GPB development. The framework is purely technical, there is no form parameterization, setup etc. Via this framework the developers can add custom fields purely via D365 X++ coding.
For further instructions please contact CAPcargo AG.

On transport order creation dialog some description fields didn't automatically display the value when parent record was selected (eg. selecting a customer account didn't display the customer name etc.).

Following display fields were corrected:
* customer name (from customer account)
* contract/version/relation description (from contract/version/relation)
* transport unit name (from transport unit)

In the address search result dialog, the users could opt to create a new address. But previously this process could not be finished due to a bug in the new address creation dialog. The GUI was corrected - now it is possible to create a new address even from the address search result dialog.

During the address validation process the address suggestions from PTV map component were bypassing standard D365 address detail validation. Eg. the standard D365 address validation was set against D365 city table (and D365 city table didn't contain city 'Winterthur"), the 'Winterthur" address was still saved if suggested by PTV map component. This was corrected - now the address suggestion by PTV map component are validated against D365 standard address details validations.

Previously it was not possible to directly batch geo-code an address that had already "Geo-coding failed=TRUE". Users had to manually set the "Geo-coding failed=FALSE" and only then it was possible to batch geo-code the address. This was enhanced, now the batch default criteria "Geo-coding failed=FALSE" is not anymore a mandatory criteria and can be removed by user.

Performance of the resource "fitting/non-fitting" visualization in the Resource selection form was improved, now only the filtered (ie. visible) resources are reloaded/retested.

This described issue was happening mostly when incorrect parameterization of "Load date range ('From' minus days)" & "Load date range ('To' plus days)" was set up in the GPB parameters.

Following points were corrected:
* New validation was added to GPB parameters setup of "Load date range ('From' minus days)" & "Load date range ('To' plus days)", to ensure that user can setup only a meaningful parameterization
* The handling of both GPB parameter fields was corrected - now these fields correctly extend the "view range" of the gantt and affect how GPB pre-loads the tours into memory. Newly this parameterization is also applied to the current gantt "view range", as the users can change flexibly the "view range" in the gantt itself.

Default "view range" of gantt is still defined on AX Worker (with fallback from main TMS parameters), there no correction was needed.

Recommended usage:
* specify in main TMS parameters the general fallback default "view range" of gantt (via "Plan Date From (+ Days)" & "Plan Date To (+ Days)"
* optionally specify on AX worker the individual default "view range" of gantt (via "Plan Date From (+ Days)" & "Plan Date To (+ Days)"
* optionally specify in GPB parameters the extended range for the tour pre-loading, to provide an instant scrolling of gantt (ie. without data reload) when scrolling into past/future

Important: the GPB parameters should be corrected (ie. "Load date range ('From' minus days)" must be 0 or negative, "Load date range ('To' plus days)" must be 0 or positive), before the release is installed.

Several GUI imperfections were corrected on the 'CAPcargo Transport Address' tab (on standard AX address form), eg. missing fields labels, repetitive field group labels etc.

It is now possible to manage the fuel locations & prices in the TMS module and display them in the map in GPB module.

Key characteristics:

* Setup is done thru a new transport type, which will hold the fuel product definition (eg. transport unit Petrol 95, Diesel Winter etc.)
* In main TMS parameters this transport type must be assigned in a new section Fuel management
* Fuel management is represented by following structure:
* Fuel origin - defines the origin of fuel. Can be linked to a vendor account (for 'Fuel origin type=External'), or to an inventory journal (for 'Fuel origin type=Internal'). Color representation can be also specified (is later used in map visualization in GPB).
* Fuel location - represents a gas station, is linked to certain TMS address & Fuel origin.
* Fuel pump - represents fuel pumps inside the location, must be linked to certain transport unit (ie. fuel product), can be linked also to AX products.
* Fuel prices - prices of each fuel product for each fuel location
* New data entities were added, to be able to import fuel management elements

A new infolog "No settings in Geographical address validation found for country %1." was added to the transport address creation wizard, to inform the user about missing parameterization, so that the user understands why the "Validate" button seems not correcting the entered address details against the map component.

Data entity 'TAL Surcharges contract relation' was enhanced, to be able to import also the fuel index based surcharges. Because in D365 surcharge data model the fuel index value is linked to surcharge via RecId (which cannot be imported via data entities), the data entity was enhanced - now the fuel index value is found dynamically during import process based on fields in import file.

Following fields are required in import file mapping, to be able to import the fuel based surcharges:

* ContractIndexTypeId
* ContractindexValue
* ValidFrom
* ValidTo

The mechanism of transport address deletion was reworked. Previously it was possible to physically delete a transport address also from the global address book locations. This feature was removed - now it is possible to physically delete a transport address only from the transport address form. Users can further decide via dialogs, whether the global address book location should be also physically removed or not (ie. in this case only the transport address is deleted).

Please note: system will physically delete the global address book location only when it is not a primary location (or when it is not used in D365 standard orders).

Previously the customer/vendor/intercompany manual invoice pools were posting all records present in the invoice pool main grid. This was enhanced - now the user has an option to multi select the orders that will be posted. Two existing menuitems in invoice pool were renamed, two new menuitems were added.

The functionality is as follows:
* Post selected - posts only the selected orders in the invoice pool. Multi selection of orders is enabled and is effectively used.
* Post all - posts all orders in the invoice pool, regardless whether orders are selected or not. This represent the previously existing functionality.
* Pro forma invoice (selected) - creates pro forma invoice(s) for selected orders in the invoice pool. Multi selection of orders is enabled and is effectively used.
* Pro forma invoice (all) - creates pro forma invoice(s) for all orders in the invoice pool, regardless whether orders are selected or not. This represent the previously existing functionality.

Additionally it is now also possible in all invoice pools to multi-select more records and remove them from invoice pool at once.

Introducing a possibility to initialize a resource swap date & time based on the map component recommendation, thus it is possible to initiate a resource swap based on more realistic data, entirely in the system.

Following enhancements were introduced:
* New action menuitem "Calculate earliest swap time" was added to the resource swap dialog, when pressed the system proposes the earliest possible time of swap, based on selected tour stops and selected swap address. It uses the map component to calculate the driving time from previous tour stops (of both tours) into selected swap address and initializes the later time into "Time of swap" field.
* New validation has been added to the "Time of swap" field, to ensure that users can perform a resource swap only with some realistic swap date & time. In general it is possible to perform a resource swap with date & time that is later than originally proposed system date & time; to setup a resource swap with earlier date & time is not allowed.
* Additionally it is possible to activate an automatic validation of "Time of swap" entry against calculation from map component - this is done in main TMS parameters (parameter "Automatically validate resource swap time against map component=TRUE", in Geo services section).

It is now possible to perform a tour stop split in both GPB dispatching screens. Functionality of "Split" is available in the "right mouse click" context menu on the tour stop, both in GSR & GST. After pressing the menuitem the user has to select which tour order line should be split into separate transport leg. Newly created transport leg remains in the original tour and can be further processed (eg. removed from tour etc.), separately to the original transport leg.

In certain parameterization constellation the sending of some transport orders to pre-dispatching was not possible, no transport legs were generated and the browser session ultimately timed out. The issue was happening when loading (or unloading) TMS address was linked to a D365 calendar that was set up on another D365 base calendar. The issue was corrected, no the rough scheduling supports also the D365 base calendar linking.

The trigger, when the customer wish extensions (red/green) are displayed, was improved/enhanced:

D365: (where date and time ranges exist since TAL 9.0 release):
The following triggers/settings make the customer wish extension show in GS:
* TransportType.GPBConfigGanttBar = CustWish
* WarnAtChange (Unload) flag on transport order --> not anymore relevant
* If any of the 4 fields (end date of unload date range, start or end time of unload time windows, unload date fixed) is filled, then the system interprets a customer wish being entered. If only the unloadDate [From] is filled without any other range/time/fixed information, it is interpreted as no dedicated customer wish and accordingly the red/green extension in GS is not visualised in order not to spoil the GS.
* If TourStatus isNot Confirmed nor Closed - this is needed, that the green/red extensions disappear once the tour is confirmed/closed. Because if they stay, they overlap the potential next tour (in GSR) which makes the bars not well readable anymore

AX2012 (where no date ranges exist, only time ranges):
The following triggers/settings make the customer wish extension show in GS:
* TransportType.GPBConfigGanttBar = CustWish
* WarnAtChange (Unload) flag on transport order --> not anymore relevant
* If any of the 3 fields (start or end time of unload time windows, unload date fixed) is filled. then the system interprets a customer wish being entered. If only the unloadDate is filled without any other time/fixed information, it is interpreted as no dedicated customer wish and accordingly the red/green extension in GS is not visualised in order not to spoil the GS.
* If TourStatus isNot Confirmed nor Closed - this is needed, that the green/red extensions disappear once the tour is confirmed/closed. Because if they stay, they overlap the potential next tour (in GSR) which makes the bars not well readable anymore

This was especially noticeable when user had to scroll across more columns and then even scroll horizontally. The GUI experience of Resource screen was improved, now the horizontal scroll bar keeps the current position even when users use the vertical scroll bars.

The default setup of CAP.TMS configuration keys was adjusted, to automatically activate only the currently supported CAP.TMS configuration keys. The adjustment only affects the new CAP.TMS installations, does not affect the installation of CAP.TMS upgrades.

The rough scheduling algorithm for the transport leg dates determination was adjusted, following issues were corrected:
* When the main TMS parameter "Respected opening days" was activated, the rough scheduling algorithm sometimes used a date on which the address was closed.
* When no suitable date combination could be determined by rough scheduling algorithm the system uses as fallback the load/unload date of transport order and informs the user via conflict "Scheduling - no valid rough scheduling found for this transport leg" (conflict id 350). In this case the transport leg unload date is still a subject for rough scheduling (and could differ to transport order unload date, for example when some "Default value load-/unload date" rule is set up between transport order addresses).
* In some cases during "backward" scheduling modes the algorithm didn't provide the consistent results (eg. the load/unload dates of the transport legs were sometimes not determined optimally etc.).

Batches for driving time & distance calculation were improved to not crash (when some error is encountered) but loop over the problematic order and continue further. The correction applies to all order types.

Contains GPB additions for new feature of transport order load & unload date ranges. Following functionality was added to the GPB:
* Visualization of "Customer wish" on tour stop (level 2) was adjusted - when the load/unload date range is used, the customer wish (in tour stop boxes) is visualized as "*" and dispatchers have to go to individual tour stop (to flyout for Order details), to see the exact date range. The reason for not visualizing the date range directly on the tour stop is the limited space of tour stop box.

Please note:
* The functionality is available only in GPB for D365FO, functionality is not available in GPB for AX2012.

Contains GPB addition for new feature of transport order load & unload date ranges. Following functionality was added to the GPB:
* Show load/unload date ranges on Transport orders /-legs screen
* Show load/unload date ranges on tour gantts (on tour stop (level 3), in the flyout for order details)

Please note:
* The functionality is available only in GPB for D365FO, functionality is not available in GPB for AX2012.

When no transport type filtering was set up in invoice pool (ie. the default filter for 'transport type = 0' was used), then the part-invoice orders (and collective part-invoice orders) were not showing in the invoice pool grid. The filter interpretation was corrected, now the both order types are shown in invoice pool even when no transport type filter is applied.

In some business cases it might happen that tour is carried out by subcontractors where rates for the freight are calculated as FTL tour sub-contracting. But on the same tour there might be some transport legs that should be priced individually (via LTL transport leg sub-contracting pricing). Dispatching-wise (and pricing-wise) this was already possible in existing TMS functionality but not respected properly in TMS cost / revenue allocation.
Newly the TMS cost / revenue overview allocates the FTL costs only to those transport legs which were not sub-contracted via LTL sub-contracting. The LTL costs are then allocated to its transport legs only, which results into the correct structure in the TMS cost / revenue allocation.

The necessary prerequisite is to allow both FTL & LTL sub-contracting modes in the main TMS parameters (ie. "Subcontracting LTL + FTL allowed=TRUE).

Previously the CAP.TMS solution worked with 2 exact dates on the transport order: the load date and theunload date. This task enhances this functionality, newly it is possible to specify the load and the unload date as ranges. The load/unload range date definition is used mainly for dispatching visualization purposes (on transport legs/tours), to give to dispatchers more flexibility in planing.

Core points of the solution:
* New fields "Load date to" & "Unload date to" were added to the transport order header (and to the transport order/offer/pre-order creation dialogs)
* New fields "Applied on" were added to the transport header, to define whether the time windows are applicable either to the "Load date" or to "Load date to" or to whole range (and ditto for unload date).
* The default order was also enhanced adequately
* Data entities (as well as other EDI related entities) were enhanced to be able to import/update these fields
* New fields were added to the transport leg "Load date", "Load date to", "Unload date", "Unload date to", to show the range requests from transport order header. Fields are filled only for first and last transport leg, can be used for filtering.
* Rough scheduling logic remains based on individual load/unload dates (ie. no date range is used), the definition whether "Load date" or "Load date to" (and ditto for unload dates) should be used for rough scheduling is done via new main TMS parameters "Exact date for forward planning" & "Exact date for backward planning"
* Dispatchers are informed about planning issues on transport leg form via new warning infolog "The rough plan date oftransport order %1 is outside of the requested date range.", is triggered only when "Warning at change" is set on transport order header
* The existing scheduling conflicts 301 & 303 were enhanced to respect the new date range logic, new conflict 304 was introduced

Please note:
* The load/unload date range enhancement can be used only on transport orders that were not created from shipment builder process.

Several labels in GST/GSR screens (in filter dialog) were corrected to show a proper translation in different language mutation.

The performance of the planning a transport leg into tour (when tour is already sub-contracted via "Sub-contracting transport leg (LTL)") was improved.

Visualization of more tours on the map (via "Track view" functionality or when viewing the tour on map from GST/GSR) could lead to high CPU utilization of the client machines. The reason is the moving visualization of the tour (aka. "marching ant" visualization) which is technically quite demanding on CPU power. To improve the work experience for dispatchers, a new switch "Animate tours" was introduced to the map screen, via which it is possible to deactivate the moving visualization and have only the static tour visualization.

The gantt visualization of driving time empty (aka. "black line") in the level 1 of the tour in both dispatching screens was corrected. Previously the "black line" sometimes included also certain activities, now the "black line" visualizes only the amount of driving time without any order.

Previously during transport order cancellation process it was possible to specify a return address regardless of the cancel status. This was corrected, now user can specify the return address only for relevant cancel statuses.

Previously it was possible to cancel a transport order via EDI only when some return address was specified in the EDI message. This was corrected, now the return address is required in EDI message only for relevant cancel statuses.

The functionality of generic buttons in GPB app was enhanced, to cover more multi-selection cases out of the box. Due to the nature of generic buttons it cannot be guaranteed that all multi-selection cases are immediately supported, certain cases might still require a project specific custom development.

The performance of the "Fitting/Non-Fitting" filter (and its visualization) in the Resource selection screen was improved, via code reorganization.

Previously when the contract finding functionality encountered a situation when user should be asked for a decision (eg. tariff level of contract/version/relation differs to already existing tariff level on order line, ditto for posting profile etc.), the 'decision making' dialog was also run during batch process, causing the batch process to skip such orders (as no dialog is allowed during batch processing). This was enhanced, now the 'decision making' dialog is used only in the manual contract finding process; in the batch processing the 'decision making' dialog is suppressed and all proposals are automatically accepted.
This also has a positive effect on price calculation batches as more orders are processed via contract finding batches (as tariff level (and other fields) are automatically applied from contract/version/relation).

A new entity "Compartment" was introduced below the capacity enabled resource (eg. trailer), which serves as an alternative way of resource capacity calculation.

Key characteristics of the enhancement:
- Compartments can be manually created for each capacity enabled resource, either directly in the TMS Vehicle form or from main TMS menu (CAPcargo Transport -> Setup -> Resources -> Compartments).
- For each compartment it is possible to define a capacity, which then can be used to populate a total capacity of the resource (which is then used effectively in tour dispatching). This is done via 'Initialize capacities from compartments' menuitem, on vehicle capacity form.

Currently the system doesn't access the compartments (and its capacity definition) directly from tour dispatching yet (ie. it is not yet possible to plan transport leg directly into individual vehicle compartment, also capacity related conflicts are not yet measured directly against compartment capacity).

The existing logicof the 'Remove from transportation' function on trade order lines had been modified. Previously, assoon as there was an order line related transport order, which did not acceptquantity changes anymore (because it was confirmed/sub-contracted/invoiced or toofar in the transportation/warehouse process), the system cancelled the whole 'Removefrom transportation' process. Therefore, even such order line related transportorders, which would be allowed to be completely deleted, are not removed fromtransportation.

Newly the system applies a “remove what it can” logic. Hence onetransport order which can’t be removed will not abort the whole process. The new logic can be activated in 'Trade and Distribution parameters' form. by new parameter 'Partially remove from transportation'. In case it is activated (set to YES), then the “remove what it can” logic to be applied by the system Otherwise, the existing logic to be used: block the entire process, if any trading order line related transportation entity cannot be removed.

The GUI experience when working in GPB 'Transport orders /-legs' screen is heavily dependent on the amount of filtered transport legs, with larger amount of transport legs (eg. 1000+ legs) the form is starting to struggle. Therefore a new feature of 'paging' mechanism has been introduced to the GPB 'Transport orders /-legs' screen.

Key characteristics of enhancement:
* Newly GPB 'Transport orders /-legs' screen loads by default only a certain amount of records (ie. transport legs). The amount can be defined in main GPB parameters (menuitem name 'Number of loaded records per page').
* The number of the loaded records (compared to total amount of records) is displayed on the right side of GPB 'Transport orders /-legs' screen, above the main grid.
* It is possible to load on demand an entire record set to the grid, by menuitem 'Pre-load' button (in top action pane).
* Scrolling down the grid automatically loads further records automatically.
* Certain grid field filters were removed (load/unload dates, from/till times, number of packages etc.)
* The map pulls only the currently loaded transport legs.

Following functionality still runs over the total amount of records (despite only a fragment might be shown in the grid):
* The total unit calculation field & icon
* The total volume tab
* The 'Generate/Update tour out of route/zone' planning mechanism

Previously there was no validation until which dispatching process step the user can perform a resource swap on the tour. So it was possible to swap resources even on entirely confirmed tours. This was corrected, now the resource swap process respects the general tour dispatching validation (ie. TMS main parameter 'Modification planning blocked from tour status') and even the individual confirmation statuses of each tour stop. So it is still possible to perform a resource swap even on already confirming tours (provided that tour stops after resource swap are not confirmed yet and main TMS parameter 'Modification planning blocked from tour status' is set to 'Confirmed').

When user was trying to delete multiple transport orders with existing packages, the system was asking "Do you want to delete packages" for each multi-selected transport order. The issue was corrected, now the system asks only once and applies the user decision for all selected transport orders that should be deleted.

Functionality of 'Confirm tour(s) directly' was sometimes failing in D365 'Dispatch light - Tours' form. It was happening due to a bug in the code, which enabled 'Confirm tour(s) directly' process only when the accrual posting was activated for tour additional costs in the main TMS parameters. The bug was corrected, now the 'Confirm tour(s) directly' menuitem on D365 'Dispatch light - Tours' form works even without accrual posting of tour additional costs.

To help the user to better understand the source of confirmation values in the tour confirmation form, new display fields for "ETA manual" were added to the tour confirmation form.

Previously the GPB security parameterization was quite limited, user with GPB role had access to all functionalities in GPB. This was improved, following actions were taken:
* Individual privileges were created for every GPB web service operation, originating from GPB. Exception: the passive web services responsible for pulling/viewing data from D365 are grouped into common privileges, per each GPB screen (eg. "GPB - Transport orders /-legs, GPB - Tour Dispatching etc.).
* All these privileges were assigned to "T&L Dispatcher" role and the "T&L Graphical Planning Board User" role has been deprecated and removed.
* Projects can configure their own roles instead of using T&L Dispatcher role if they want to define their own security inside GPB. This can be done either without development (ie. via standard 'Security configuration' mechanism) or by development (as before).

This allows a more granular control, making it possible to grant/deny access to individual functionalities within GPB, via web service privileges.

It is now possible to use transport unit conversion (defined on transport type) even in EDI order import/update process. Previously the transport unit conversion in EDI was temporarily suspended (please see known issue 53246 of TMS 10.0.9.0 release notes).
New option 'Quantity conversion' was added to import process, via which it is possible to define whether (and how) should be the transport unit conversion used in EDI process.

Following options are possible:
- 'None' - the system always uses the planning quantities from EDI message for transport order import/update; the transport unit conversion is never used.
- 'Only when zero' - only the "non zero" planning quantities are imported/updated from the EDI message; the "zero" (or not specified) planning quantities are not imported from EDI message but they are converted from transport unit conversion instead.*
- 'Forced' - the planning quantities from EDI message are ignored and system relies on transport unit conversion instead.*

*General rule (applicable for 'Only when zero' and 'Forced' quantity conversion setup) - the transport unit conversion is applied only when some transport quantity (and some transport unit) is specified in the EDI message. For "zero" transport quantity the quantities from EDI message are still used, as no transport unit conversion is possible.

It was possible to set up (and calculate) the part-invoice orders even when some address was inactive. The issue was corrected, now the part-invoice orders can be created (and calculated) only when transport address is active.

In certain cases it was not possible to merge tour stops in the GPB Tour Dispatching screen, due to 'BOX API can't be used from non-interactive sessions' error. This was especially happening when some merging tour stops had some ETA manually adjusted by dispatchers. The issue was corrected, now in such cases the GPB correctly opens the 'decision making' dialog and dispatchers can decide whether to proceed with the tour stop merging process (and lose the manually specified ETA) or cancel the merging process entirely.

The new features ULD/compartment/carrying resources (66677) will not yet automatically assign the carrying resource in the following specific case:

- Multi-select legs and drag to Gantt-Screen Resource (GSR) onto a white spot, in order to create a new tour for the 'drop-resource' with those 3 legs
- Everything is correctly created, but the legs are not directly assigned to the 'drop-resource' as carrying resource

This will be fixed in release 12, with task 72665

For certain cases the transport leg scheduling process (aka. rough scheduling) failed to finish and the webpage timed out. It was especially happening in following constellation:
- No open date was found for the transport leg date (which was inherited from previous transport leg)
- Transport leg point has a route with 'Plan date control'=None

The issue was encountered not only during the rough scheduling process but also in other processes (which automatically trigger the rough scheduling, eg. depot split insertion etc.).

In certain cases not all packages were removed during the removal of the depot split on transport leg. This happened for example when multiple depot splits were removed at once from the single transport order. The issue was corrected, now the packages are removed in synchronization with the transport leg removal.

Removal of shipment lot from shipment was in some cases not possible, system reported with 'Stack trace: The company does not exist.' The issue was identified and corrected. Following processes were affected:
- Remove from Transportation (a menuitem on trade order line level)
- Remove shipment lot from shipment

The main GPB client executable file was renamed from 'client.exe' to 'GPBclient.exe', for better system maintenance (eg. it is easier now to locate & filter GPB client in the windows event log etc.).

Data migration job for the task 69666 (New feature of shipment lot quantity criteria).
Data job generates the shipment lot quantity criteria for existing records, both on shipment lot quantity and transport order line.

Please note:
The data job should be run even when new commodity feature is not used, to ensure the correct behavior of the shipment builder.

It is now possible to select & copy the tour stop information text (from the 'pop-up' dialog) in the gantt screens, in level 3.

The issue could happen when all following circumstances were met:
- 'Firm automatically' was set TRUE on import process
- 'Invoice status logic' was set to 'Advanced' in the main TMS parameters
- Some 'Status term invoice' was specified on the 'Terms of delivery'

Then due to a bug in the code it could happen that two transport orders were created from one EDI import message during the "Check errors" process on the checked imported order. The issue was corrected, now only one transport order is created.

Tour activity variable calculation did not calculate correctly when set against fifth planning unit. This was happening for example when unloading tour activity was specified as 10min per each m2 (and m2 was a fifth planning unit). The issue was corrected, now the variable calculation of tour activities behaves correctly for all planning units.

Several shipment builder elements (eg. fields/parameters) were incorrectly linked to a new shipment builder configuration key, despite their functionality was related to an old shipment builder functionality only. The assignment of configuration keys was corrected.

Following TMS fields were added to the 'Customer postal addresses' data entity (CustomerPostalAddressEntity):
- 'Protect Geo-coordination'
- 'Geo-coding failed'

Previously the possibility to adjust a resource leg by 'drag & drop' on level 2 was existing only in the 'Tour Dispatching' screen. This was enhanced, now it is possible to adjust a resource leg by 'drag & drop' on level 2 also in the 'Resource Dispatching' screen.

A data migration job for the task 69696 (New feature of 'ULD/Compartment handling').

The data job creates a new ULD compatible structure from previously existing "Carrying resource" assignment (from the tour order lines).

In some the cases the package confirmation did not happen and system reported error "Function TALUnitOfMeasureConverter::newFromConversionParameters has been incorrectly called." This was especially happening when no volume & weigh unit were specified on the package. The issue was corrected, now the volume & weight package units are submitted for conversion only when specified.

New feature of 'Shipment lot quantity criteria' has been added to the system, as a preparation for the future product enhancements (eg. introduction of the commodity entity also to the D365 trading orders). Newly the structure between shipment lot quantity and transport order line is steered via new criteria set (a field that is stored on transport order line and shipment lot quantity).

In the following constellations it could happen, that GPB Gantt screen froze or performed very badly:
- Tour with many orders (50+)
- "Show customer wish deviation" parameter and/or "Cost/Revenue real-time calculation" parameter is switched ON

Either at selecting of any tour, or at simple opening of the Gantt screens, or at full-refresh, the screen would freeze or take very long (several minutes) to load data.

The reason for this was that 'background code workers' did collide with heavy loads and blocked each other, because the configuration of "number of allowed parallel web-service connections" was put to 2 by default. Opening up this configuration allowed GPB to better fire web-services in parallel which solved a big part of the above described issue, meaning the heavy processes can now keep running in the background (e.g. small spinning wheels on icons) while the user can continue working.

However, in Gantt-Screen-Resource (GSR) there could previously still be issues when the parameter "Show customer wish deviation" was switched on and big tours were in the view port. This was corrected in this task and should not happen anymore.

Find more information in the technical installation guide about the "open connection" setting, it's important to follow those instructions carefully, since opening up this configuration too much could lead to other [unknown] issues.
Please note:
The above mentioned parameters (customer wish and cost/revenue) still are heavy processes and are therefore configurable. CAPcargo will be improving those processes in future releases, but still their usage should be carefully considered.

- Customer wish show deviation in Gantt bars
To be switched on only in relevant business; this feature is made for FTL business, where 1 tour equals more or less to 1 order. Only the last unload customer wish can be respected in the visual element of a bar.
- Cost/Revenue real-time calculation
To be carefully considered if real-time calculation is really needed. It's about the red/green icon on the gantt bar indicating profit/loss, which is calculated for all tours immediately (if parameter ON), or only at request (button) per tour (if parameter OFF). The bigger the tours, the heavier the performance impact. - Actually, the recommended best practice is to run that cost/revenue statistics splitting by the foreseen D365 batches in the background, which calculate the tours asynchronously. Dedicated flags on the tour mark, if values on the tour are up-to-date and allow GPB to directly show the red/green icons without any performance impact. Like that only very few tours really need to be calculated in real-time, potentially only the once the dispatcher is currently working on.

Displays the new commodity field on the GPB screens:
- 'Transport orders /-legs' screen - new grey infobox in the right bottom part (in 'Overview' tab)
- both dispatching gantt screens - on order detail section of both dispatching gantt screens (a 'flyout' side 'Orders' panel on the tour stop)

Also enables the visualization of commodities by different color icons in the map component (the color parameterization happens on the transport type).

CAP.TMS release migration jobs update data in all legal entities but the migration job status was managed only in current legal entity. So in other legal entities the migration jobs were still showing status "not run" but in reality the data was already updated. This was corrected - CAP.TMS migration jobs are now shared between legal entities (ie. property SaveDataPerCompany in TALDataMigrationJob table was changed from "Yes" to "No").

Please note:
To avoid the duplicity of migration jobs from other legal entities, the data conversion job in ADO 54278 must be run.

In certain cases the merging of tour stops was not possible, the merging failed with 'BOX API can't be used for non-interactive sessions.' This was especially happening when some Manual ETA was specified for some tour stop. The behavior was corrected, now in case the Manual ETA is specified for some tour stop then during the merging system asks user for decision what should happen to Manual ETA.

New feature of 'Undo tour closing' was added to both dispatching gantt screens, to enable the re-opening of the tour when it had been closed previously.

Previously the GPB client version (eg. 'GPB Version 2.3.5, Dynamics 365, 14.08.2020') was populated from a D365 label file and the same label was reused (and updated) for every GPB release. This could theoretically lead to some version naming discrepancy, as the label file can be technically adjusted/updated by projects even between the official versions. To avoid such discrepancy the GPB client version is newly being hard-coded in every GPB release.

The customer wished date & time visualization on tour stop detail section (in level 3) was sometimes not consistent, the unload wished date & time had an additional logic (of displaying the "*" when more than one order was scheduled for unloading at the same tour stop, with different customer wished date & time). Such additional visualization logic was previously applied only on unload tour stops, now is applied also on the loading tour stops.

Previously the usage of Service (SLA) on D365 trade order entities was not consistent - on some trade order entities the Service (SLA) was on the header, on others just on the line. This task unites the usage of Service (SLA) in the following way, for D365 sales/purchase/transfer order:
- Service (SLA) on trade order header is newly used only for initialization of Service (SLA) to trade order lines
- Additionally the update mechanism has been introduced to trade orders - when user manually changes the Service (SLA) on header, it newly asks whether the Service (SLA) on lines should be also updated
- Service (SLA) on trade order line is effectively used (ie. pushed to transport order).
- As a consequence it is newly the Service (SLA) from trade order lines that is used as the shipment building criteria for transport order creation.
- As a consequence the Service (SLA) of the trade order lines has been added to the shipment builder management logic.

Additionally Service (SLA) has been also added to the TMS tariff surcharges (as a new surcharge criteria). So it is now possible to set up a TMS tariff surcharge per individual Service (SLA), or per 'Service level agreement' group. All TMS order types are supported (ie. transport order, LTL/FTL sub-contracting order, part-invoice order, intercompany order, collective orders etc.)

New validation has been added to the GPB client, to ensure that the GPB client is connected to the supported D365 version only. The validation is launched automatically during GPB client start and warns user when incompatible D365 version is detected.

Newly when the tour stop is being deleted in both dispatching gantt screens (and tour contains some automatically generated strategic tour routing (aka. waypoints)), then the user is asked via a new dialog, to decide whether the existing strategic tour routing should be updated (ie. removed and re-generated for the new tour stop structure) or kept without any changes.

It is now possible to simulate what would be the cost effect if certain transport leg(s) or already planned tour stop(s) would be delivered via external sub-contractors instead of being delivered by internal resources. The feature can be used also for finding the most cost effective sub-contractor for selected transport legs (or tour stops).

Key characteristics of the enhancement:
- New menuitem 'Price simulation' on the 'Transport orders /-legs' top screen action pane, which opens a new D365 window where user has to select for which TMS sub-contractors the price simulation should be launched. The price simulation then calculates the expected costs for each selected TMS sub-contractor over all selected transport legs. Standard* TMS contract finding is used for allocating the best fitting tariff to the selected transport legs (including the driving time & distance calculation and potential currency conversion logic). For the purpose of price simulation the LTL sub-contracting model is used (incl. the automated order collection when more than one transport leg is selected).
- New 'right mouse click' context menuitem 'Price simulation' in tour stop overview in both dispatching gantt screens (in level 3), which launches the process. The price simulation logic (and result) is the same but user has an additional option to simulate the effect on existing default costs of the tour.
- *A small modification of standard TMS contract finding had to be done. Purely for the purpose of price simulation if 'more than one' best fitting tariff is found then system uses one of them randomly & automatically (instead of asking the user for selection).

Please note:
- The result of price simulation is the overview of foreseen costs per each selected TMS sub-contractor, for better decision making. The system doesn't perform the sub-contracting itself (eg. doesn't plan transport legs into tours, doesn't sub-contract the tour etc.). Such actions must be done manually by dispatchers.
- The price simulation result is not stored in the TMS, result is only presented to the user (but process can be re-run again for same or different leg/stop selection).
- Price simulation menuitems are accessible also from the 'Goods management' forms, from both dispatching screens.

Previously to visualize all details of tour stop details users had to manually 'pull up' the horizontal separator of level 3 in gantt screens, as some details were not visible on the screen by default (eg. resource swap icons, GMT time zones etc.). This was enhanced, now the level 3 shows by default all tour stop details.

When user selected some tour in any of both dispatching gantt screens and afterwards opened the Resources screen, the initial visualization of Resources screen was not correct (ie. all resources were visualized already in "Planned" section). To get the correct resource visualization (ie. Available or Planned) user had to re-select the tour while having the Resources screen already open. This was corrected, newly the initial filtering of Resource screen is already correct when screen is opened for the first time.

In gantt screens the conflict ID filter lookup previously showed duplicated conflicts (as the same conflicts could be activated in several transport types). This was enhanced, now the conflict ID lookup contains only unique conflicts across all transport types, sorted by conflict ID.

When planning a transport leg into already sub-contracted tour, the transport leg sub-contracting (LTL) order was sometimes not automatically created in the background. The issue was caused by a bug in ULD transaction creation logic. The issue was corrected, now the system correctly generates ULD transactions only for the newly added transport legs and also creates sub-contracting transport leg (LTL) orders accordingly.

In "Dispatching light - tours" it's possible to create a new record with Alt-N keyboard combination. This way it was possible to skip the standard "Create new tour" dialog, which could lead to an incomplete tour data. The issue was corrected, now the "Create new tour" dialog is populated even when new tours are created via Alt-N.

The parameterization of "Default values load-/unload date" was sometimes not respected during transport leg creation process. This was happening especially when the main TMS parameter "Respect opening days" was set TRUE. The issue was corrected, the "Default values load-/unload date" parameterization is newly taken into account during transport leg creation when no other rough scheduling modes are available, even when TMS parameter "Respect opening" is activated.

Following sub-contracting order related data entities were added to the system:
- TAL Sub-contracting transport leg (LTL)
- TAL Sub-contractor order lines
- TAL Sub-contracting Tour

It is now possible to export TMS sub-contracting orders from D365 (the data entities are allowed only for exporting).

Newly the TAL license expiration datum is accessible also in the "Info about CAP.Transport&Logistics" form, in following main menu path:
CAPcargo Transport –> Setup –> Info about CAP.Transport&Logistics

Previously the automated creation of ULD transactions worked correctly in the 'Resource Dispatching' screen only when an individual single transport leg was planned. In case of transport leg multi-selection, the ULD transactions were not generated. The issue was corrected, the ULD transactions are generated even when multiple transport legs are planned into tour in 'Resource Dispatching' screen.

Configuration keys "Message framework" & "Transport Event Management" were moved from "**Not officially released sub-modules**" section into new dedicated "Transport Event Management" section, as both sub-modules are officially released. It is now possible to set up an outgoing event message per track & trace status change.

The data job will populate the new activity duration field (in seconds) based on the old duration (in minutes).
Additionally the "Fix time" (which was previously a decimal value for minutes) is cleaned/corrected, maximum decimal should be .59.

Any existing values which would be more than 99:59:59 are converted to 99:59:59.

Previously the exact timestamp of the event (ie. when the event occurred) was filled only in certain event messages. This was enhanced, the event timestamp is newly being filled in the messages also for following track and trace events:
- Status311 (Failed pick-up)
- Status430 (Delivered by sender)
- Status436 (Picked up by sender)

Default filter (query) of the "Transport orders /-legs" screen had to be adjusted, to not display the "Sender delivery" and "Receiver pick-up" transport legs which were confirmed directly without a tour.

Following filters were added to the "Transport orders /-legs" screen:
- Receiver pick-up (new grid filter)
- To be delivered by sender (new grid filter)
- To be picked up by receiver (new SCM status filter)
- Ready for receiver pick-up (new SCM status filter)

Additionally a new icons for new Goods planning statuses were introduced.

To improve the performance of both gantt screens, the mechanism of tour refresh was enhanced. Previously the tour refresh was loading the tour entire details at once (ie. user session was blocked until data from all tour levels was loaded). Which, especially for tours with several dozens of tour stops (and order data) could take a significant time. Newly the tour refresh mechanism is split into two parts:
- loading of details for level 1 (ie. tour gantt bar data) and the basic structure of tour stops in level 3
- loading of details for each tour stop in level 3 (ie. tour stop scheduling dates & times, loading & unloading quantities of transport legs). Also newly the details for each tour stop are being loaded independently (ie. in parallel background sessions).

For users the GUI experience of working with both gantt screens should be improved, as the "tour refresh" mechanism is called very frequently - basically after every tour change. One noticeable visual difference is that during tour refresh instead of common "spinning icons" (that were previously shown both for level1 and level3) system now shows the individual "spinning icons" for every tour stop (but user session is unblocked at this moment already).

Following performance driven improvement were done in the 'Transport orders /-legs' screen:
- New "Filter" menuitem was added to the action pane (bellow Refresh & Pre-load), which optionally affects the basic logic of the filters. The menuitem must be enabled in the AX Worker setup (new parameter " Show 'Filter' button in OS", in CAPcargo Transport section, in group "Filter Initialization Dispatching"). Once the Filter button is activated for particular user/worker, then the filters are not immediately applied after every change but are applied only manually (ie. via Filter button). This allows the users to change several filters at once (ie. without any delay) and apply them all at once.
- AND/OR logical operators can now be used in the filter for Quantity, also the sorting of Quantity works more reliably.
- The icon for summing of the selected planning quantity changes into "spinning wheel" when system calculates and the calculation itself doesn't lock the session.
- Filtering/sorting were added to the date & time fields.
- Pre-loaded grid (ie. with all records shown) now doesn't reload after field sorting. This allows the user to do rapid sorting (even with many transport legs) once the grid is fully pre-loaded.
- Load/Unload name filtering was enhanced by options: "Is equal to", "Starts with", Ends with" and "Does not contain".
- ZipCode filtering was enhanced by option "Starts with".

Previously the dispatching activity master data setup could be done only on "hours & minutes" level. This was enhanced, now it is possible to define dispatching activity master data duration also in seconds.

New special transport leg types are introduced, which handle those scenarios, when the shipping of the first or last leg is not managed by the transportation company, but the sender and the receiver. The creation of these so called ‘sender delivery’ and ‘receiver pick-up’ legs can be done manually or automatically at pre-dispatching.

Due to the fact, that these special leg types are mostly not planned into a tour, the Cross-docking form is enhanced to support the direct and detailed confirmation of them. This confirmation process supports the update of confirmed quantities, empties management, package level confirmation and auto-confirmation of counterpart leg points.

Regarding to the ‘sender delivery’ and ‘receiver pick-up’ legs several features were also enhanced:
- Transport leg classification (new classification of "Sender delivery", "Receiver pick-up" was added next to the existing classification of "Pick-up", "Shuttle", "Distribution")
- Goods planning status (new statuses)
- Conflict analyzer (new conflict)
- Track and trace framework (new statuses)
- Cost/revenue calculation (to ignore the special transport legs if not planned into a tour)

Load/unload address names and the load/unload time windows were added to the header section of the transport order line view.

Previously due to the platform change (from AX2012 -> D365) the usage of "External codes" was not working in EDI order import process. This was now enhanced, the "External codes" can be used to map the transport addresses against external codes, per each import process. The administration of external codes is accessible under following main menu path:
CAPcargo Transport -> Setup ->Data export/import -> Administration of external codes

or directly from transport address form, via menuitem "External codes".

Please note:
Only transport addresses are currently enabled for the "External codes", the customer accounts & transport units not yet.

The implementation of tour scheduling mechanism was re-worked, to achieve a better performance. Following processes were affected:
- Manual delete tour line with order
- Delete order from dispatching - empty tour stop
- Deleting of tour
- Deleting the last tour order from tour stop
- Tour stop split
- Manually delete tour activity

The optimization was done on the code architecture level - the functionality of tour scheduling mechanism itself was not altered.

The TMS "Named User License Counts" report was re-worked, to be in line with the current TMS license terms. Previously the report checked the roles setup in the system, newly the report is based on menu items or privileges and provides the information how many TAL full users and how many TAL light users are using the system.

Additionally a new periodic task was introduced, to collect the information about required CAP.Transport&Logistics user licenses.
Main menu path:
CAPcargo Transport –> Periodic –> Licensing –> Named user license count reports processing

Please note:
It is the duty of the customer to be compliant with the CAPcargo license terms. The mentioned report helps to get an overview of the set-up users and their needed licenses, depending on their role/security setup.
In order to get this report filled with data, it’s needed to setup a batch job with a daily recurrence, as described in this white paper.
https://capcargo.sharepoint.com/:b:/g/Ef6s9UBVMulJriUhi5J57_AB7EeeSA9F1un5JJkKAhVMWg?e=x4b1tn

More options are provided for [manual] tour creation in task 73678. It was meant also to provide the option, to manually add a route/zone to a newly-to-be-created tour, in the same manner as it is possible to add/change the route/zone field on an existing tour (serving for filtering of dispatch sectors).

In R13 that option of manually entering route/zone in the tour creation dialog is not working and will lead to an error message in most scenarios. Work-around: Leaving the field empty and fill it once the tour is created.

This will be fixed in release 14 with task 78487

Previously the address detail 'hover the mouse over' dialog (which appears in the map when mouse cursor is placed over some map pin, that is related to some specific address layer type, eg. depots/gas stations/warehouses etc.) was barely readable as too bright grey font color was used. This was enhanced, the font color is now black and clearly readable.

When entering a confirmed value in the tour confirmation and directly click the 'confirmed' checkbox, the entered value is not excepted and jumps back to the original value. Work-around: After entering the value, first save the record manually (Alt-S).

The existing entity (and menuitem) for 'Additional tour stop' was renamed to 'Tour routing - additional stop', to better correspond with the entity usage in the TMS.
Position of menuitem the in main menu:
- CAPcargo Transport -> Setup -> Strategic dispatching -> Tour routing - additional stop

A bug was fixed in the Manual ETA validation that was incorrectly called when not needed. If user tried to confirm arrival on the first tour stop, but the timestamp was later than Manual ETA on any following tour stop, then the confirmation was (incorrectly) blocked.

When GPB transport leg filtering mode was set to manual (via 'Show 'Filter' button in OS' parameter set to TRUE on worker), then the date filters were not respected properly by 'Filter' button in 'Transport orders /-legs' screen. The issue was corrected and the 'Filter' button now applies the date filters correctly in the 'Transport orders /-legs' screen.

Correction of bug in conflict ID 1244 (Qualification - Missing transport address qualification for trailer) which could cause that conflict was not detected in certain cases (but it should).