Release No.TypeIDTopicTitle & Details
TAL 10.0-CAP2.0User Story25780Customer invoicing
Finance dimensions were added to invoice automation rule definition


It is now possible to use finance dimensions in the definition of the invoice automation rule. This allows to setup up an automated invoicing rule per certain finance dimension value.

TAL 10.0-CAP2.0User Story44010Customer order management & pricing
Small GUI optimization of 'Address' section of transport order form (header view)


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.

TAL 10.0-CAP2.0User Story43139Dispatching & confirmation
Two optional parameters were added to periodic function for 'Generate/Update tour out of route/zone'


Two optional parameters were added to periodic function for 'Generate/Update tour out of route/zone':

* Find and update existing tours (Yes/No)
* Mode (None/Rough planning/Ignore rough planning)

These optional parameters were existing when 'Generate/Update tour out of route/zone' was launched from transport legs, but were missing in periodic function dialog.

TAL 10.0-CAP2.0User Story47503Dispatching & confirmation
New field 'Conflict status' field was added to main grid of 'Dispatch light - Tours' form


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).

TAL 10.0-CAP2.0User Story50506Dispatching & confirmation
Enhancement of Activity framework, to enable usage of all transport planning units for activity time definition


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.

TAL 10.0-CAP2.0User Story31938Integrations
The external codes are not anymore validated in Transport order import/export data entities


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.

TAL 10.0-CAP2.0User Story46476Integrations
In transport order EDI import it is now possible to import also packages and package content


Data entity 'TAL Transport order import' was enhanced by option to import also packages (and package content) together with transport order.

TAL 10.0-CAP2.0User Story39339Master data
Periodic function 'Contract mass update wizard' can be used for update of contract versions that are not yet active today


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).

TAL 10.0-CAP2.0User Story47386Master data
Several geo-coordinate enhancements were added to advanced location management form


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"

TAL 10.0-CAP2.0User Story45105Other / General
New button 'Invoice transport' was added to action pane on three 'order type' forms


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.

TAL 10.0-CAP2.0User Story44785Shipment Builder
''Synch-Forward' and 'Synch-Backward' status icons were added to sales/purchase/transfer order lines


''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.

TAL 10.0-CAP2.0User Story45674Shipment Builder
New periodic function for CSI Incident log clean up


New periodic function was introduced via which it is possible to clean CSI Incident logging table. User can define "n" days in past for which the CSI Incident log should be preserved and the rest is deleted.

Path: CAPcargo Trade & Distribution -> Periodic -> CSI Incident cleanup

TAL 10.0-CAP2.0User Story48450Subcontracting/IC order management & pricing
Automatic creation of LTL transport leg sub-contracting orders for newly added transport legs into tour


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.

TAL 10.0-CAP2.0Bug45604Customer invoicing
D365 standard free text posting process could interfere with CAP.TMS invoice posting process


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.

TAL 10.0-CAP2.0Bug34338Customer order management & pricing
Part-invoice order lines could be manually added/deleted even when invoice split was done by transport leg


Addition/deletion of part-invoice orders lines is now disabled when part-invoice order was created via 'by transport leg' method.

TAL 10.0-CAP2.0Bug40384Customer order management & pricing
Correction of product filter on transport order form


Product filter on transport order form now works as expected - filters transport orders that contain selected product.

TAL 10.0-CAP2.0Bug42086Customer order management & pricing
Transport unit is not a mandatory for transport quantity specification


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.

TAL 10.0-CAP2.0Bug42935Customer order management & pricing
Standalone transport order with packages couldn't be manually deleted


It is now possible to manually delete a transport order (that was not created via shipment builder) even when it contains some packages.

TAL 10.0-CAP2.0Bug42939Customer order management & pricing
Several contact related issues were corrected in transport order EDI import process


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.

TAL 10.0-CAP2.0Bug44337Customer order management & pricing
Under 'Advanced' invoice status mode the direct transport order confirmation could lead to wrong invoice status


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.

TAL 10.0-CAP2.0Bug49351Customer order management & pricing
Changing a customer account on transport order could lead to address loss on transport order


The issue was happening only when there were no default load/unload addresses defined on customer account. Then when changing a customer account on transport order the system asks via dialog whether addresses should also be updated.
If user decided to update the addresses then address on transport order were lost/deleted (as no default address were found on customer account).
This was fixed - the existing load/unload addresses on transport order are preserved when customer account is being changed (and new customer doesn't have any default load/unload address specified).

TAL 10.0-CAP2.0Bug37131Dispatching & confirmation
Undefined opening hours parameterization on address (00:00-00:00) was always triggering conflict "Business hours - address closed" in transport leg conflict management


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'.

TAL 10.0-CAP2.0Bug42981Dispatching & confirmation
Missing 'conflicts not determined' icon on tour order form


Tour order form now correctly shows a dedicated icon when dispatching conflicts are not determined.

TAL 10.0-CAP2.0Bug43007Dispatching & confirmation
Error messaging at release to warehouse from tour (when transport order is not synchronized) was improved


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.

TAL 10.0-CAP2.0Bug43910Dispatching & confirmation
No tour stop refresh in tour confirmation after package confirmation


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

TAL 10.0-CAP2.0Bug44542Dispatching & confirmation
For standalone transport orders the transport unit on packages was not initialized when packages were created automatically during order creation


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.

TAL 10.0-CAP2.0Bug44555Dispatching & confirmation
Dialog for 'Means of transportation' change was not validated against master data


When changing the 'means of transportation' in GPBapp transport order/leg screen, users could type any value to D365 dialog. This was fixed - dialog field is now validated against master data so users must use some existing 'means of transportation'.

TAL 10.0-CAP2.0Bug44965Dispatching & confirmation
''Dispatch light - Transport legs' grid still showed the transport leg despite leg was already dispatched in tour


After planning a leg into existing tour via 'Dispatch to tour' in 'Dispatch light - Transport legs' form, the leg main grid is automatically refreshed now.

TAL 10.0-CAP2.0Bug45373Dispatching & confirmation
Tour confirmation form is now opened in 'view only' mode, for tours in status 'Done'


Previously it was possible to change tour confirmation data even for tours that were in status 'Done'. Now for such tours the the tour confirmation forms opens in 'view only' mode, so that it is not possible to change confirmation data anymore.

TAL 10.0-CAP2.0Bug46491Dispatching & confirmation
Tour with timetable linked means of transportation could lead to invalid tour time (=negative tour duration)


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.

TAL 10.0-CAP2.0Bug47343Dispatching & confirmation
User is better informed when the quanity split creation for shipment builder transport orders is prevented


User is informed with better/new infologs when dispatching actions (in Goods management & when moving order to different tour) would lead to quantity split on transport leg (which is forbidden for transport orders that were created via shipment builder).

TAL 10.0-CAP2.0Bug47547Dispatching & confirmation
Dispatch light - Transport legs form doesn't display order legs when opened directly from transport order if date filter criteria are not met.


When 'Dispatch light - Transport leg' form was launched directly from Transport order form it could happen that form didn't show any leg. The reason was the automatic initialization of default date filters on Dispatch light - Transport leg form.
Now when Dispatch light - Transport leg form is launched directly from Transport order form there are no default date filters initialized.

TAL 10.0-CAP2.0Bug47581Dispatching & confirmation
Goods management form didn't refresh automatically after buttons Keep/Remove were used


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.

TAL 10.0-CAP2.0Bug48410Dispatching & confirmation
The conflict icons on GBPapp transport leg screen were sometimes not showing correct statuses


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

TAL 10.0-CAP2.0Bug48448Dispatching & confirmation
Load/unload times from transport order were populated to all transport legs


Previously load/unload times from transport order were populated to all transport legs of this order, even to legs that were inserted via depot/address split. This was corrected, the load/unload times from transport order are populated only to first/last transport leg.

TAL 10.0-CAP2.0Bug49488Dispatching & confirmation
Cancellation of transport leg planning via 'Dispatch in tour' dialog creates a new empty tour.


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

TAL 10.0-CAP2.0Bug49539Dispatching & confirmation
Transport type (table/group/all) prioritization on Route/Zone was not respected when just one transport leg point was assigned to Route/Zone


Transport type and Service level agreement (table/group/all) prioritization on Route/Zone was correctly respected only when both transport leg points were in the Route/Zone. Now the transport type prioritization is respected even when just one transport leg point is in Route/Zone.

TAL 10.0-CAP2.0Bug49548Dispatching & confirmation
Conflict 465 ("Process - Manual quantity changes on [pre-]dispatched transport leg") was not triggered for some business cases


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.

TAL 10.0-CAP2.0Bug46472Integrations
3 existing data entities were enhanced to be allow automatic creation of CAP.TMS addresses during data import


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.

TAL 10.0-CAP2.0Bug47424Integrations
Missing field 'Index ID' in 'TAL Surcharge type' data entity


Surcharge type 'Index ID' field was added to Surcharge type data entity (TAL Surcharge type), to be able to import/update/export the 'index based' surcharge types entirely.

TAL 10.0-CAP2.0Bug47430Integrations
Field 'Sequence' was disabled for user changes in staging table of 'TAL Activities' data entity


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.

TAL 10.0-CAP2.0Bug48366Integrations
Duplicate address geo-coding when importing transport order via EDI


When transport order (with some TMS addresses) was imported via EDI then the address geo-coding was performed twice. This was corrected, now the geo-coding is performed only once even for imported transport orders that contain some TMS address.

TAL 10.0-CAP2.0Bug49643Integrations
After shipment builder redesign the 'TAL SCM mapping table' data entity couldn't be used anymore


After activation of redesigned shipment builder the 'TAL SCM mapping table' 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 SCM mapping table' data entity is correctly linked to new/redesigned shipment builder only.

TAL 10.0-CAP2.0Bug44314Master data
German label correction on Route/Zone form


Some GUI elements on Route/Zone form were corrected in German language translation.

TAL 10.0-CAP2.0Bug44372Master data
Tariff surcharge criteria could be specified even without surcharge type


On contract version/relation and on tariff surcharge group the surcharge criteria can now be saved only when there exist some surcharge type.

TAL 10.0-CAP2.0Bug48519Master data
GUI changes in CAP.TMS main paremeters


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'.

TAL 10.0-CAP2.0Bug43946Shipment Builder
On sales order the 'Product transportation' button was enabled even when there were no transportation entities exising


On sales order the 'Product transportation' button was enabled even when sales order was only released, ie. without shipment lots/shipments/transport order. This was corrected - the button is now enabled only when there is some transport order existing.

TAL 10.0-CAP2.0Bug48508Shipment Builder
Changes of source orders were wrongly logged in transport company, which lead to issues in transport order synchronization


In cross company setup, a change of source order (in trading company) was logged wrongly in transport company. This caused issues in transport order synchronization. After the fix, the system logs the changes of source orders directly in trading company.

TAL 10.0-CAP2.0Bug25540Subcontracting/IC order management & pricing
InterCompany order: Wrong amount split if > 1 order line and fix price and tariff unit = KM


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

TAL 10.0-CAP2.0Bug37172Subcontracting/IC order management & pricing
Contract/Version/Relation lookups on sub-contracting tour order had different design than other order types


The design of lookups for Contract/Version/Relation on Sub-contracting order was changed, to match the lookup design on other order types.

TAL 10.0-CAP2.0Bug47433Subcontracting/IC order management & pricing
Sub-contracting transport leg (LTL) order is now better referenced in order view


On order view of 'Sub-contracting transport leg (LTL)' form, system was showing the Transport order id in list overview. This was corrected and system now shows the Sub-contracting transport leg (LTL) id.

TAL 10.0-CAP2.0Issue51179Master data
Geo-coding after address editing throws an error if geo-coding is activated through PTV-xserver


The following processes throw an error if geo-coding is activated through PTV-xserver

* Edit transport address, change ZIP code and click button CAPcargo Geo-coding
* Edit transport address, change Country/Region, ZIP/postal code and Street, then click button Save
* Edit CAPcargo wrong addresses form, click button ‘CAPcargo edit coordinate’, change ZIP/postal code and Street, then click button OK

Further, answering YES on the geo-coding dialog "Similar address found, want to change to this?" --> removed the street field instead of filling it

TAL 10.0-CAP3.0User Story45685Integrations
New data entity was added, for TALcsiIncident table


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

TAL 10.0-CAP3.0User Story50655Integrations
Better usage of address geo-coordinates in PTV xLocate integration


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.

TAL 10.0-CAP3.0User Story47406Other / General
New management form for handling of data migration jobs in TAL releases


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.

TAL 10.0-CAP3.0User Story49429Other / General
Enhancement of CAP.TMS periodic functions for better compatibility with D365 sequenced batch job task framework


In the release 10.0-CAP1.1 we enhanced all CAP.TMS periodic functions so that they can be set up also as D365 sequenced batch job tasks.
This task contains few small (rather technical) enhancements for cleaner user experience.

TAL 10.0-CAP3.0Bug45608Customer invoicing
In certain cases it was not possible to create a customer invoice reversal (aka. credit note) due to wrong validation


In certain cases it was not possible to create a customer invoice reversal (aka. credit note) as the system failed with warning infolog "Reversal not possible! There exist surcharges to order %1 which are currently posted in invoice %2. Please reverse this invoice first".
The issue was corrected by improving the reversal/credit note validation to fail with such warning infolog only when there really exist some third-party surcharges that are posted in some other invoice.

TAL 10.0-CAP3.0Bug45598Customer order management & pricing
Part invoice order could be created even without specifying a split address


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)

TAL 10.0-CAP3.0Bug48424Customer order management & pricing
It was possible to delete last transport order line even thought the order was already planned in tour


Under certain circumstances it was possible to delete last transport order line even thought the order was already planned in the tour. This lead to unexpected data situation as transport order was in status "dispatched" but had no order line but still kept the transport legs that were assigned in tour.
This was corrected - now it is possible to remove last order line of transport order only when order is in status 'registered'.

TAL 10.0-CAP3.0Bug50572Customer order management & pricing
Undefined opening hours parameterization on address (00:00-00:00) was always triggering conflict "Business hours - address closed" in transport order conflict management


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'.

TAL 10.0-CAP3.0Bug45011Dispatching & confirmation
''View details' of transport unit in goods management form was not working


In goods management form the 'View details' of transport unit was corrected.

TAL 10.0-CAP3.0Bug45383Dispatching & confirmation
Tour activity could be changed/deleted even when tour was in status Confirmed (or Done)


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

TAL 10.0-CAP3.0Bug48469Dispatching & confirmation
During depot split it was posible to multi-select several depots


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.

TAL 10.0-CAP3.0Bug48470Dispatching & confirmation
Enabling more search fields in the dialog for depot/address split on transport leg form


In the dialog for selecting a depot/address (during depot/address split on transport leg), the search/filter options were limited. This was enhanced - users can now search/filter also via depot/address description.

TAL 10.0-CAP3.0Bug49331Dispatching & confirmation
In the dialog for "Generate/Update tour out of route/zone" the weekday value was not automatically recalculated after change of scheduled date


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.

TAL 10.0-CAP3.0Bug50755Dispatching & confirmation
During combined loading & unloading at the same tour stop, system sometimes scheduled loading before unloading


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.

TAL 10.0-CAP3.0Bug41185Integrations
During transport order EDI import the planning quantities were processed as "whole set", either all (or none) were imported/converted


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.

TAL 10.0-CAP3.0Bug48496Integrations
2 bugs were corrected in transport order EDI import


Following two bugs in transport order EDI process were corrected:
1) under advanced invoice status it was possible to import a transport order even without 'status term invoice'. This was corrected - now the transport order without 'status term invoice' is validated (and held) already in checked imported order
2) during transport order EDI the delivery term was not initialized from customer account.

TAL 10.0-CAP3.0Bug49608Integrations
Data entity for 'TAL Activities' was adjusted, as sometimes import/update via this entity failed


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

TAL 10.0-CAP3.0Bug49645Integrations
After shipment builder redesign the 'TAL Transport type combination' data entity couldn't be used anymore


After activation of redesigned shipment builder the 'TAL Transport type 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 Transport type combination' data entity is correctly linked to new/redesigned shipment builder only.

TAL 10.0-CAP3.0Bug49647Integrations
After shipment builder redesign the 'TAL Item transport unit combination' data entity couldn't be used anymore


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.

TAL 10.0-CAP3.0Bug49649Integrations
After shipment builder redesign the 'TAL Shipping means calculation rule' data entity couldn't be used anymore


After activation of redesigned shipment builder the 'TAL Shipping means calculation rule' 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' data entity is correctly linked to new/redesigned shipment builder only.

TAL 10.0-CAP3.0Bug49651Integrations
After shipment builder redesign the 'TAL Shipping means calculation rule line' data entity couldn't be used anymore


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.

TAL 10.0-CAP3.0Bug49653Integrations
After shipment builder redesign the 'TAL Shipment building group' data entity couldn't be used anymore


After activation of redesigned shipment builder the 'TAL Shipment building group' 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 Shipment building group' data entity is correctly linked to new/redesigned shipment builder only.

TAL 10.0-CAP3.0Bug49682Integrations
Data entity "TALVehicleGroupEntityData" was renamed to "TAL Vehicle group"


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


TAL 10.0-CAP3.0Bug49684Integrations
Data entity "TAL Vehicle group" was renamed to "TAL Vehicle group assignment"


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

TAL 10.0-CAP3.0Bug50616Integrations
The creation of CAP.TMS addresses via data entities failed for certain data constellations


In ADO 46472 a new functionality was introduced that enabled the creation of CAP.TMS addresses via several data entities. For exact mechanism please see release notes of ADO 46472.
This task delivers several fixes for related data entities.

TAL 10.0-CAP3.0Bug51203Integrations
Street name could be lost during geo-coding of address


In certain data constellation during address geo-coding system asks "The map found a similar street... Do you want to overwrite yours...?" Answering "Yes" could lead to loss of street name. This was corrected - now the street name is actualized from geo-coding proposal.

TAL 10.0-CAP3.0Bug39535Master data
Unit conversion could not be opened from Contract/Version/Relation forms


It was not possible to open Unit conversion form from Contract/Version/Relation forms, system failed with error infolog "Object reference not set to an instance of an object."

TAL 10.0-CAP3.0Bug44776Master data
Fix of known issue "Direct creation of CAP transport address from D365 address CREATION not possible"


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).

TAL 10.0-CAP3.0Bug46490Master data
Missing validation of 'departure zone' and 'destination zone' in tour routing rule setup


Due to the missing validation of 'departure zone' and 'destination zone' in tour routing rule it was possible to setup a rule against entities that were not existing in CAP.TMS. This was corrected - now the validation ensures that user can use only existing entities in 'departure zone' and 'destination zone'.

TAL 10.0-CAP3.0Bug50671Master data
Transport type could be deleted even though it was used in some transactions


Under certain circumstances it was possible to delete a transport type despite it was used in some transport order. This was enhanced - now the transport type "delete" button is disabled when transport type is used in some transport order.

TAL 10.0-CAP3.0Bug50889Master data
Zip code lookup in route plan defintion (on route/zone master data) was not working correctly


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.

TAL 10.0-CAP3.0Bug50990Master data
Adding a transport unit to transport type sometimes failed with warning 'Field "Transport type" must be filled in.'


When user tried to add new transport unit to new transport type (that was not yet saved), it resulted in blocking warning 'Field "Transport type" must be filled in.' This was corrected - now the user can add new transport unit only when transport type is created & saved.

TAL 10.0-CAP3.0Bug51045Master data
''Delivery' purpose could be be removed from CAP.TMS transport address


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'!"

TAL 10.0-CAP3.0Bug45596Other / General
Third-party surcharges were listed in invoice pool even though the surcharges were marked as "inactive"


Third-party surcharges were listed in invoice pool even though the surcharges were marked as "inactive". All order types were affected - customer/vendor/intercompany surcharges. As per now the inactive third party surcharges are not showing anymore in invoice pools.

TAL 10.0-CAP3.0Bug48473Other / General
Menuitems for "New" and "Delete" were accessible in the xServer parameter form (in TMS main parameters)


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.

TAL 10.0-CAP3.0Bug44531Shipment Builder
''View details' of sales order in goods management form sometimes didn't open the correct sales order


In goods management form the 'View details' of source order was enhanced to open the correct sales order, provided user has sufficient access rights. When user has insufficient access rights then the 'View details' of source order is disabled.

TAL 10.0-CAP3.0Bug39518Subcontracting/IC invoicing
The pro-forma self-billing invoice for 'sub-contracting transport order' could not be generated


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.

TAL 10.0-CAP3.0Bug50759Subcontracting/IC order management & pricing
Driver's default cost (aka 'Standard cost driver') as defined on vehicle was never used in cost & revenue statistics


Driver's default cost (aka 'Standard cost driver') as defined on vehicle was never used in cost & revenue statistics calculation. Now the driver's default cost is used in cost & revenue statistics calculation when no costs are provided via Sub-contracting Tour order.

TAL 10.0-CAP4.0User Story25572Customer invoicing
Enhancement of "Status invoice documents" (aka Document management for invoicing) to TMS order types


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.

TAL 10.0-CAP4.0User Story45606Customer invoicing
Transport customer invoice reversal enhancement - mandatory classification via "Reason code"


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).

TAL 10.0-CAP4.0User Story49453Customer order management & pricing
Warning infolog "Comparing a numerical value with extensible enum 'Extensible Enumeration(enum name)' will yield unexpected results." was sometimes encountered by users in several processes


During several processes in CAP.TMS users could encounter a warning infolog "Comparing a numerical value with extensible enum 'Extensible Enumeration(enum name)' will yield unexpected results."
At least following process were affected:

* Transport order create dialog, in "Use existing address", when switching between various record type
* In transport type form, when creating new transport type

This was fixed - now the code behaves correctly and infolog is not encountered.

TAL 10.0-CAP4.0User Story49466Customer order management & pricing
Warning infolog "The implicit conversion from date to utcDateTime is not supported." was sometimes encountered by users in several processes


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.

TAL 10.0-CAP4.0User Story51248Dispatching & confirmation
Performance optimization of "Generate/Update tour out of route/zone" functionality


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

TAL 10.0-CAP4.0User Story51346Dispatching & confirmation
Performance optimization of "Dispatch in tour" functionality


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

TAL 10.0-CAP4.0User Story51458Dispatching & confirmation
Tab Vendor in tour confirmation form was redesigned and enhanced (to store start & end mileage of resource assignment)


This enhancement re-introduces the functionality to be able to specify the start & end mileage on resource assignment in tour.
As a part of solution the tab Vendor (In tour confirmation form) was redesigned.
Previously the tab Vendor contained only the FTL tour sub-contracting aspect of the tour.
Newly the tab Vendor is renamed into Resources/Vendor and contains the information about resource assignment on tour as well as FTL tour sub-contracting aspect of the tour. New fields for start & end mileage were added to the tab Resource/Vendor.

TAL 10.0-CAP4.0User Story50874Integrations
Data entity "Customers V3" was enhanced to allow creation of TMS addresses from customer delivery address


Data entity "Customers V3" was enhanced by field "TALDeliveryAddressIsTransportAddress" to allow creation of TMS addresses from customer delivery address import.

TAL 10.0-CAP4.0User Story51430Integrations
New data entity "TAL Packages" was added to the TMS module, to be able to import/export the TMS package header table


New data entity "TAL Packages" was added to the TMS module, to be able to import/export the TMS package header table.

Entity name: TAL Packages
Staging table: TALPackageTableStaging
Target entity: TALPackageTableEntity

TAL 10.0-CAP4.0User Story51433Integrations
New data entity "TAL Package confirmation" was added to the TMS module, to be able to import/export the TMS package confirmation data


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

TAL 10.0-CAP4.0User Story51348Master data
System now stores and shows on logistics postal address the geo-coordinate detail level


New field "Level of validation" was added to logistics postal address, to show on which level of details were the geo-coordinates obtained.
"Level of validation" field can have following values:

*
COUNTRY 0 [Country level] - the candidate was found on countrylevel.
*
STATE 1 [State level] - the candidate was found on state level.
*
EXTPOSTCODE 2 [Global ZIP level] - the candidate was found on globalpostcode level.
*
CITY 3 [City level] - the candidate was found on city level.
*
CITY2 4 [City>district level] - the candidate was found on citydistrict level.
*
POSTCODE 5 [ZIP level] - the candidate was found on postcodelevel.
*
STREET 6 [Street level] - the candidate was found on streetlevel.
*
HNRSECTION 7 [House# section level] - the candidate was found on house numbersection level. The address candidate does not contain an exact house number.
*
HNRLINK 8 [House# link level] - the candidate was found on house numberlink level.
*
HNRINTERPOLATED 9 [House# interpolated level] - the candidate was found on house numberlevel, the house number was interpolated.
*
HNREXACT 10 [House# exact level] - the candidate was found on house numberlevel, the data contained the exact house number.
*
INTERSECTION 11 [Hose# intersection] - the candidate was found on intersectionlevel, the result data is an intersection.
*
MANUALLYDEFINED 50 - A user manually defined the geo location. It is considered as most accurate information possible.

Levels 0-11 are used for geo-coordinates obtained from map component.
Level 50 is reserved for manually specified/adjusted geo-coordinates.

Examples:
"Level of validation=Street" means that address geo-coordinates were obtained from map component, on street name level. So even when address would have some street number, this is not reflected in geo-coordinates.

TAL 10.0-CAP4.0User Story51493Master data
Removal of 2 obsolete resource related process buttons in main TMS parameters


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

TAL 10.0-CAP4.0User Story47408Other / General
New certificate for TAL license (current expires 14.12.2019)


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.

TAL 10.0-CAP4.0User Story50852Shipment Builder
New infolog message "Field 'Mode of delivery' must be filled in." was added to shipment builder creation process


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".

TAL 10.0-CAP4.0User Story51060Shipment Builder
Split of configuration key CLXTALshiShipmentBuilder into two new configuration keys, for customers transiting to the new shipment builder


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

TAL 10.0-CAP4.0User Story51146Shipment Builder
The transport order shipment synchronization (when launched from the tour) sometimes caused a database deadlock


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.

TAL 10.0-CAP4.0User Story51442Shipment Builder
New two picking statuses for items enabled on for transportation management (but not for warehouse management)


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.

TAL 10.0-CAP4.0Bug44403Customer order management & pricing
Two issues were fixed in area of tariff quantity update and usage of confirmed quantity on transport order


Following issues were fixed in area of tariff quantity update and usage of confirmed quantity on transport order, that could lead to unexpected price calculation results:

* The tariff quantity update mechanism was sometimes not working correctly unless the button 'Use confirmed quantity" was pressed
* Wrong tariff unit was used in "Use confirmed quantity" functionality on transport order header

TAL 10.0-CAP4.0Bug45680Customer order management & pricing
Validation of quantity update on transport order line was moved from transport order level to transport order line level


Previously it was not possible to change the quantities on transport order line as soon as quantity split exists for any transport leg. Even when the transport leg (with quantity split) didn't even contain the transport order line.
This was enhanced - now it is not possible to change the quantities on transport order line only when the quantity split exists for transport legs that contains this transport order line.

TAL 10.0-CAP4.0Bug48441Customer order management & pricing
Two GUI enhancements in customer invoice pool


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

TAL 10.0-CAP4.0Bug49508Customer order management & pricing
Cancellation of 'Direct dispatch (route)' transport order planning process didn't remove the transport legs


When the user tried to plan transport order into tour via 'Direct dispatch (route)' but cancelled the operation, the system didn't cancel the whole process entirely (i.e. transport legs were not removed) and transport order was hence in status 'plannable'.
Now after the cancellation the system cancels the whole process (incl. transport legs) and transport order is hence in status 'registered'.

TAL 10.0-CAP4.0Bug51154Customer order management & pricing
Removing a Part invoice order from collection was sometimes not possible


Removing a Part invoice order from collection could fail in some cases, with ttsBegin/ttsCommit error. The code has been enhanced to not encounter this error.

TAL 10.0-CAP4.0Bug51323Customer order management & pricing
Field Rough plan date on Transport leg points form was editable


In "Transport leg points" form it was possible to manually change a "Rough plan date" field. This was corrected - the field is now not editable. It is possible to change Rough plan date manually only in GPB, without GPB the field can be updated only by some process.

TAL 10.0-CAP4.0Bug51482Customer order management & pricing
Error in transport order functionality "Delete order from dispatching"


Removing of transport order from dispatching process (via "Delete order from dispatching") was sometimes failing with "Function Global::int642int has been incorrectly called" error. The code was corrected.

TAL 10.0-CAP4.0Bug51614Customer order management & pricing
Last transport order line could not be removed even though order is in status 'Registered'


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”.

TAL 10.0-CAP4.0Bug51755Customer order management & pricing
It was not possible to generate a transport order from pre-order


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

TAL 10.0-CAP4.0Bug43207Dispatching & confirmation
New infolog in 'Dispatch in tour' process when automatically adding also related overpackages


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

TAL 10.0-CAP4.0Bug48458Dispatching & confirmation
In conflict management form it was not possible to open shipment details even though the conflict was shipment related


On shipment related conflicts (in conflictmanagement form), the menuitem for “CAPcargo shipment” was sometimes disabledeven though the conflict was shipment related. The enable/disable behavior ofmenuitem was corrected.

TAL 10.0-CAP4.0Bug51404Dispatching & confirmation
Empty tour start date and unloading before loading


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.

TAL 10.0-CAP4.0Bug48434Integrations
Status message framework didn't work in D365, no messages were produced/sent


Status message framework didn't work in D365 as it was based on AIF functionality (which was deprecated in D365). The status message framework was redesigned and is now working again. The event based logic is triggered via Business Event, additionally there is a new data entity to support also recurringintegrations.

TAL 10.0-CAP4.0Bug51476Integrations
Wrong handling of virtual fields in TAL Parameters data entity


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

TAL 10.0-CAP4.0Bug51245Master data
Several issues were corrected in "CAPcargo wrong addresses" form


Following issues were fixed in "CAPcargo wrong addresses" form:
1) Editing of address didn't happen on selected address but on first address in the grid
2) Missing automatic refresh on changed address in the form
3) In some data constellations the system still created a new 'active' address version

TAL 10.0-CAP4.0Bug51318Master data
It was possible to change route start & end addresses directly on 'route plan' grid


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.

TAL 10.0-CAP4.0Bug51354Master data
Using a street name suggestion from map component (during geo-coding) could create an incorrect address


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.

TAL 10.0-CAP4.0Bug51286Other / General
In "Data migration jobs" form the menuitems for "Run job" and "Change status" were available even when there was no migration data job existing


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.

TAL 10.0-CAP4.0Bug51386Other / General
When more migration data jobs exists for the same Job id, only first one was shown in "Data migration jobs" setup overview


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.

TAL 10.0-CAP4.0Bug48542Shipment Builder
Missing 'product description' on transport order lines (shipment builder related)


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).

TAL 10.0-CAP4.0Bug51031Shipment Builder
Automated tour update (as last step of shipment building process) was not working properly; system never re-used already existing (and suitable) tour for new transport legs


When "Generate/Update tour out of route/zone" was used as a last step of shipment builder process then system always created new tour for every transport leg; the existing tours (even though entirely suitable) were not reused/updated. This was corrected - in shipment building process now the system first searches for some existing suitable tour before creating a new tour.

TAL 10.0-CAP4.0Bug51189Shipment Builder
Inventory quantity on load line was not reduced during sales load line splitting, in case inventory unit is different than sales unit


When load line splitting was done on a load line that has inventory unit different than the sales unit, then only sales quantity of the load line was correctly reduced but inventory quantity was not reduced. This was corrected - now also the inventory quantity on the load line is reduced.

TAL 10.0-CAP4.0Bug51192Shipment Builder
Remove not-picked shipment lot didn't reduce the load line quantity in case no work was existing


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.

TAL 10.0-CAP4.0Bug51250Shipment Builder
The quantity reduction on sales order line was not possible in some cases


The quantity reduction on sales order line was in certain cases not possible due to a bug in inventory unit conversion. This was corrected - the quantity reduction on sales order line is possible now even when inventory unit is used.

TAL 10.0-CAP4.0Bug51396Shipment Builder
Open transport order from purchase order didn't work in cross-company setup, no transport order was found/opened


On purchase order header the menuitem "Transport order" didn't open the transport order in case the transport order was created in different legal entity than the purchase order. This was fixed - now the button "Transport order" works correctly even in case of cross-company transport order.

TAL 10.0-CAP4.0Bug51435Shipment Builder
Cost allocation to purchase order line was sometimes failing with error "Cannot edit a record in Purchase order versions.."


Functionality of "Split back transportation costs / revenues to shipment lots" was failing in case the purchase order had some problematic data constellation in its versioning. This was corrected - now the "Split back transportation costs / revenues to shipment lots" functionality works correctly even for purchase orders that have some versioning issues.

TAL 10.0-CAP4.0Data conversion51361Dispatching & confirmation
Conflict management form: Shipment ID was not assigned to the shipment based conflicts


A data migration job for task 48458 (In conflict management form it was not possible to open shipment details even though the conflict was shipment related).

The data migration job fills the reference field Shipment Id on existing shipment related conflicts.

TAL 10.0-CAP4.0Data conversion51666Integrations
Track and Trace Status message: copy email status data to new table


A data migration job for task 48434 (Status message framework didn't work in D365, no messages were produced/sent).

The data migration job copies email status data from outbound message table to the a new table to exclude it from data entity's tracking.

GPB 2.2.0User Story25814Dispatching & confirmation
New menuitem 'Strategic tour routing' was added to gantt forms


New menuitem 'Strategic tour routing' was added to gantt forms, to 'Dispatching' tab, to 'Dispatch' menuitem group. Via this menuitem it is possible to regenerate 'Tour routing rules' (aka 'waypoints') for the whole tour.

GPB 2.2.0User Story25849Dispatching & confirmation
GPB was still displaying 3 planning units even though 5 planning units were defined/specified in CAP.TMS


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).

GPB 2.2.0User Story39447Dispatching & confirmation
Enhancement of tour delay/earliness visualization in gantt charts (aka. red & green tour bars)


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.

GPB 2.2.0User Story40353Dispatching & confirmation
In gantt forms the 'Assign carrying resource' menuitem now exists also as a standalone 'Dispatching' tab element


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.

GPB 2.2.0User Story50687Dispatching & confirmation
Performance improvement of Resource selection screen


Performance of Resource selection screen was improved (a new index on vehicle group table was added and some obsolete code was removed).

GPB 2.2.0User Story50951Dispatching & confirmation
New framework for generic/customized buttons in GPB


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.

GPB 2.2.0User Story51134Dispatching & confirmation
New framework for generic/customized filters in GPB


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

* GBP screen - on which GPB target screen the filter should appear
* Table name - which table holds the filter field
* Field name - which field should be used as filter criteria
* Label - name of filter. Currently the label is interpreted as 'plain text', it is not possible to use true language specific labels.
* Class name & Method name - only applicable for 'string' based fields. Optionally it is possible to define a class & method from where should GPB populate the lookup values.

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

* for Transport orders /-legs screen - the filters are added directly to the filter section above main gantt grid
* for both gantt screens - the filters are added to tab 'Maintain to the "Filter" menuitem group, to the list of all filters (new dedicated filter group on the right edge of filter form)


Following filter field data types are supported:

* Integer (whole number)
* Decimal number
* String (text)
* Enum
* Boolean (Yes/No)

The 'Datetime' filter field data type is not supported.

Supported screens:

*
Transport orders /-legs form
* Both gantt forms
* Resource selection forms

The map screen is not supported.

Limitations:

* Only single selection is supported in the filter fields

GPB 2.2.0User Story51494Dispatching & confirmation
''Resource reservation' and 'Attach resource' menuitems were removed from GPB gantt screens, as obsolete


Following menuitems were removed from GPB gantt screens:

* Resource reservation (reason: related feature was deprecated in ADO 23736)

* Attach resource (reason: a leftover from AX2012 times, not needed anymore since differently handled in GPB)

GPB 2.2.0Bug49542Customer order management & pricing
Drag & drop of POI from map into gantt (level 1 or level 3) was not possible


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).

GPB 2.2.0Bug16350Dispatching & confirmation
For transport orders with no transport unit (and no planning quantities) the transport legs point pin on map was distorted (=cut)


Map visualization of transport leg with no transport unit (and no planning quantities) was corrected. Previously the transport leg point pin was distorted (=cut), now the pin displays in full.

GPB 2.2.0Bug41155Dispatching & confirmation
When opening an AX2012 form throws an error, then further GPB actions that would open any AX2012 form failed


Thus bug was encountered only when GPB was used with AX2012 client, bug was not happening when GPB was used with D365 client.
When some error is encountered during opening of some AX2012 form from GPB then any further GPB action (that would lead to opening of any AX2012 form, even completely different AX2012 form) is blocked. The only workaround was to restart AX2012 client. This was corrected - now if some error is encountered when opening AX2012 it is still possible to open another AX2012 forms even without AX2012 client restart.

GPB 2.2.0Bug47501Dispatching & confirmation
The activity sequence determination on tour stop was changed


The sequence of activities on tour stop was previously determined by 'Activity id', now the sequence is determined by 'Sequence id').

GPB 2.2.0Bug47520Dispatching & confirmation
Creation of tour via drag & drop (from map or from transport leg form) was sometimes not possible


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.

GPB 2.2.0Bug51169Dispatching & confirmation
GPB client was crashing when the 'release to warehouse' from tour encountered some errors in AX2012


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.

GPB 2.2.0Bug51299Dispatching & confirmation
''View details transport order' functionality on gantt chart (level 3) sometimes showed entirely wrong order details


Opening transport order details from gantt chart (on level 3, via 'Viewdetails transport order') showed sometimes wrong details of transport order, e.g. wrong address, wrong transport unit & quantity etc. This was corrected - now the system shows the details of correct transport order.

GPB 2.2.0Issue52732Dispatching & confirmation
GPB GSR: button for 'Strategic tour routing' works only for users with 'System administrator' role


D365 GSR: the menuitem for "Strategic tour routing" can be used only by users with 'system administrator' role. For other users the menuitem fails with error "The remote server returned an error: (401) Unauthorized."

TAL 10.0-CAP5.0User Story25840Customer order management & pricing
Allow to calculate transportation order with 'zero' price


Under certain parameterization it is now possible to calculate (and invoice) transportation orders with "zero" price.

Feature is activated by following parameterization:

* In main TMS parameters the feature has to be activated, via main parameter "Allow null calculation" = TRUE
* The TMS price agreement (=contract scaling price matrix on contract/version/relation), that will be used for order pricing, has to have a valid suitable price matrix line with "zero" variable unit & fix price component

If both above conditions are fulfilled then the order will be successfully calculated with 'zero' price. Such transportation order will be then normally processed also via invoicing process and will appear on invoice report.

Orders with 'zero' price can be used for example for registration of 'free' re-deliveries (after 1st delivery failed due to reasons not caused by customer fault), or for marketing models/campaigns (for new customers) etc.

TAL 10.0-CAP5.0User Story52773Customer order management & pricing
New field 'Time/distance calculation failed' on order types (and tours), to improve the performance of interface with PTV map component


When the driving time/distance calculation on an order (or tour) does not succeed because of any reason (e.g. no street available, truck attributes cannot be fulfilled etc), then the driving time/distance process would just not fill-in driving time/distance, but does not "remember", that this order could not be calculated. Hence at the next attempt, the process will try again (and again fail). This could have a greater impact especially when the driving time/distance is calculated via a periodic task.
To avoid unnecessary calls of driving time/distance calculation requests to PTV map component, we introduced a new checkbox field "Time/distance calculation failed", on following places:

* Transport order header
* Tour header
* Sub-contracting transport leg (LTL) order header
* Intercompany order header
* Part-invoice order header

"Time/distance calculation failed" flag is entirely managed by system, it is not enabled for user changes. System sets the flag:

*
TRUE - when driving time/distance calculation fails (i.e. driving time and distance = 0)
*
FALSE - when driving time/distance calculation succeeds (i.e. driving time and distance > 0)

Once the "Time/distance calculation failed" flag is set TRUE then such order/tour is automatically excluded from further driving time/distance calculation periodic tasks. It is still possible to launch driving time/distance calculation manually via dedicated menuitems, for error correction & re-calculation.

TAL 10.0-CAP5.0User Story26686Dispatching & confirmation
New cross-docking form


This task introduces a new overview tool which enables the cross-dockingmanager to get an overview of the inbound/outbound transport legs in/out of hiscross-docking depot. The overview is a passive tool (=view only), it is notforeseen to make any active actions via this tool.

New form is located in main menu:
CAPcargo Transport -> Common -> Cross-docking -> Cross-docking

Cross-docking form utilizes two different 'modes/views':

* Depot overview - for depot managers, to have an overview of the inbound/outbound transport legs in/out his depot, per date range.
* Cross-docking overview - to have an overview of goods that are present (or were present, or are foreseen to be) inside a depot in one single point in time


Both 'modes' have various filters, which can be used further to narrow (or extend) the selection. It is also possible to sum up the transport leg volume totals, either in single planning unit or per each involved route/zone.

TAL 10.0-CAP5.0User Story51649Dispatching & confirmation
Several GUI adjustments of Dispatch light - Transport legs & Tour forms


Following GUI adjustments of Dispatch light Transport legs & Tours forms were done, to help user getting better & more consistent form experience.

On 'Dispatch light - Transport legs' form:

* Menuitem section "Controlling" was renamed to "Manage"
* "Package management" and "Connected packages" menuitems were moved into "Manage" section


On 'Dispatch light - Tours' form:

* Menuitem section "Controlling" was renamed to "Manage"
* "Package management", "Connected packages" and "Tour orders" menuitems were moved into "Manage" section
* Now empty 'Maintain' group was removed
* Menuitem section "Shipment" was moved, is now placed between "Manage" and "Print"

TAL 10.0-CAP5.0User Story51767Dispatching & confirmation
Performance enhancement of "Delete order from dispatching" on transport order form


Performance enhancement of "Delete order from dispatching" on transport order form. Now the process of removal of transport order from dispatching should be faster, with same functionality as before.

TAL 10.0-CAP5.0User Story51652Other / General
Adding description to CAP.TMS periodic tasks, for better management of batch journalization tasks


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.

TAL 10.0-CAP5.0User Story52974Other / General
New management form for handling of data migration jobs in TAL releases


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.

TAL 10.0-CAP5.0User Story39432Shipment Builder
During warehouse picking process the existing container type (on license plate) is newly respected/used


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.

TAL 10.0-CAP5.0User Story51215Shipment Builder
New field "Load line qty" was added to the Shipment lot section of the Shipment form


Previously in the Shipment lot section of the CAPcargo Shipment form, two fields were displayed in the grid - the inventory quantity (in inventory unit) and the unit (of the load line). Since the unit of the load line is not always necessarily the same as the inventory unit, it was sometimes confusing, as the quantity didn't correspond to the displayed unit.
Therefore a new field "Quantity" was added to the Shipment lot section of the Shipment form, to display also the quantity of the load line.

​Previous field structure:​
- Inventory quantity​
- Unit

New field structure:
- Inventory quantity
- Quantity
- Unit

Hence the "Quantity" now corresponds to "Unit", and "Inventory quantity" corresponds to "Inventory unit" (the inventory unit is not displayed directly on Shipment lot section).

TAL 10.0-CAP5.0Bug25672Customer invoicing
Automated periodic function for transport customer invoicing didn't include the transport orders that have different invoice account than customer account


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.

TAL 10.0-CAP5.0Bug25968Customer invoicing
Orders not appearing in invoice pool


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.

TAL 10.0-CAP5.0Bug41997Customer order management & pricing
Missing lookup & validation for packing unit during manual package creation


When packages were being created manually (via dedicated menuitems & dialog) then in 'creation' dialog the packing unit field was only a plain string field, without lookup, without validation. So it was possible to specify a packing unit that doesn't exist in master data. This was corrected - a selection lookup was added to the packing unit field in dialog and field is validated against master data.

TAL 10.0-CAP5.0Bug49636Customer order management & pricing
Contract version lookup on various order type lines was always using order load date as the date validity criteria


Contract version lookup on various order type lines was always using order load date as the date validity criteria. This was corrected - now the service provision date (as specified in main TMS parameters) is used as date validity criteria in contract version lookups on order type lines.

TAL 10.0-CAP5.0Bug51288Customer order management & pricing
Contract finding algorithm didn't handle correctly the 'tariff zone' geographical definitions on contract relation


Several 'tariff zone' based issues were corrected in the contract finding algorithm. Eg. when contract relation was defined via tariff zone (that was specified via zipcode only), then contract finding didn't consider such contract relation in case the address on transport order contained also a state details. The contract finding algorithm evaluated the tariff zones (on contract relation) as whole 'set' (=combination of country/state/county/zip code/city") and did compare with same set on load/unload address. And only when both 'sets' exactly matched, then contract relation was evaluated as "fitting". This was corrected - now the contract finding evaluates the validity of tariff zones on individual 'elements' (=zip code vs zip code, city vs city), instead of comparing the whole 'sets'.

TAL 10.0-CAP5.0Bug51491Customer order management & pricing
GUI adjustment - buttons for 'New' and 'Delete' were removed in ‘Dispatch light – transport legs’ form


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).

TAL 10.0-CAP5.0Bug42897Dispatching & confirmation
Start & end address were not mandatory on default tour template


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.

TAL 10.0-CAP5.0Bug47509Dispatching & confirmation
Wrong/invalid rough plan date sequence of transport legs


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.

TAL 10.0-CAP5.0Bug49408Dispatching & confirmation
In certain cases the periodic task "Generate/Update tour out of route/zone" was crashing with unhandled error


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.

TAL 10.0-CAP5.0Bug51257Dispatching & confirmation
Conflict management status of tour/transport order/transport leg was sometimes not automatically synchronized with real conflict management data


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.

TAL 10.0-CAP5.0Bug52617Dispatching & confirmation
In 'Dispatch light - Transport legs' form it was possible to manually change the SCM status of transport leg


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.

TAL 10.0-CAP5.0Bug44407Integrations
Bug in address creation, when performed directly in EDI process (in 'Checked imported order' form)


The creation of address directly in EDI process (in 'Checked imported order' form) was not possible, the "+" icon for new address creation was failing. The user could 'correct' the addresses in EDI process only by selecting some already existing addresses. This was corrected - now user can also create (and use) new address directly in EDI process.

TAL 10.0-CAP5.0Bug52771Integrations
Duplicated transport orders from one imported order (in EDI order import process)


Under certain circumstances in EDI order import process it was possible to generate multiple transport orders out of one single imported order. This happened during the validation of checked imported order (or during transport order creation), when "Firm automatically" parameter was activated in EDI import process. The issue was corrected - now each imported order can create only one transport order.

TAL 10.0-CAP5.0Bug49438Master data
The general filter on contract form didn't work/filter the records


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

TAL 10.0-CAP5.0Bug50613Shipment Builder
Several batch tasks in 'CAP.Trade & Distribution' module were only available to users with 'System administrator' role


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

TAL 10.0-CAP5.0Bug52772Shipment Builder
Correction of several issues in shipment builder synchronization process


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

TAL 10.0-CAP5.0Issue53246Integrations
Temporary suspension/deactivatation of 'Reset existing planning quantities" dialog (for activation of transport unit conversion) in EDI import order process


During EDI process (in 'Checked imported order' from) the dialog for 'Reset existing planning quantities' (to activate the transport unit conversion) was not performing according to original product design/expectation. Thus the dialog for 'Reset existing planning quantities" was temporarily suspended/deactivated in this release, to be further redesigned.

GPB 2.2.2Bug53259Dispatching & confirmation
Incorrect refresh of the GPB resource dispatching


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.

TAL 10.0-CAP6.0User Story52818Customer invoicing
Transport customer invoice reversal enhancement - mandatory classification via "Reason code"


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).

TAL 10.0-CAP6.0User Story53028Customer invoicing
Several customer related filters were added to the "Create and post invoice batch" periodic function


Following customer related filters were added to the "Create and post invoice batch" periodic function, to enable more detailed setup of the automated customer invoicing process:

* Customer validity (Table/Group/All)
* Currency
* Order origin
* Load/Unload address
* Customer reference
* Transport type
* Contract/Version/Relation
* Invoicing frequency

TAL 10.0-CAP6.0User Story54158Customer invoicing
Filter enhancement on customer invoice pool opening dialog


New filter for transport type was added to the customer invoice pool opening dialog. It will help the user experience and also the performance of the customer invoice pool opening dialog. Also the customer account filter is now disabled when the customer group filter is applied.

TAL 10.0-CAP6.0User Story25935Customer order management & pricing
Automatic creation of Part-invoice orders


Previously the Part-invoice orders could be created only by manual pressing of buttons on Transport order form.
This task introduces an automated Part-invoice order creation; it is possible to create Part-invoice orders automatically (=without user interaction) in following processes:
1) During transport order creation from EDI imports
2) As a result of transport order price calculation batches
3) As a result of transport order manual price calculation

Ad 1)
This is achieved by new checkbox parameter "Do not create Part-invoice orders" on transport order import process. The parameter is by default set FALSE, that means that by default part-invoice orders are created automatically. Users can still deactivate it by setting "Do not create Part-invoice orders" parameter to TRUE.

Ad 2)
This is achieved by new checkbox parameter "Do not create Part-invoice orders" on transport order price calculation batches. The parameter is by default set FALSE, that means that by default part-invoice orders are created automatically. Users can still deactivate it by setting "Do not create Part-invoice orders" parameter to TRUE.

Ad 3)
This is achieved by enhancement of transport order manual price calculation button/process.

TAL 10.0-CAP6.0User Story52834Customer order management & pricing
"New" quick button for transport order creation was added to transport order form


To be in line with standard D365 order form controls (eg. sales order etc.) we introduced a "New" quick button for transport order creation to top header control ribbon. Menuitem opens transport order creation form.

TAL 10.0-CAP6.0User Story53034Customer order management & pricing
Functionality of manual creation of overpackage structure across different transport orders


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).

TAL 10.0-CAP6.0User Story54155Customer order management & pricing
Several enhancement of the invoicing frequency functionality on transport order and 'part-invoice' order


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

TAL 10.0-CAP6.0User Story25713Dispatching & confirmation
Enhancement of the qualification framework


Previously existing framework for qualifications was redesigned & enhanced.

Changes:

* TMS Address can newly act also as qualification provider. So it is now possible to setup a qualification that the transport order should be loaded/unloaded only at addresses that provide the qualification.
* TMS Vehicle can newly act also as qualification requester. So it is now possible to setup a qualification that the vehicle should be driven only by drivers that provide the qualification.
* Qualifications were removed from AX Resource entity. For vehicles the qualification directly on TMS Vehicle should be used, for drivers the qualification directly on D365 Worker should be used.
* It is newly possible to define on qualification itself against whom is the qualification aimed

* static conditions - qualification can be requested against Motor vehicle / Trailer / Driver / Transport orders. Set up of multiple target requested conditions is possible.
* dynamic conditions - allows to custom code a specific qualification conditioning (ie. exact D365 code class). The framework doesn't provide any predefined classes out of the box, these would have to be custom coded for specific project needs.

* Several new conflict were added to conflict management, to cover the extended qualification structure.
* Qualification overview form (launched from transport order form, from transport address, from vehicle, from tour etc.) were reworked, to cover the extended qualification structure.

Please note:

* To handle the previous qualification structure a migration job 25693 must be run.
* GPB is not fully updated for new qualification framework, please see Known issue 56684.

TAL 10.0-CAP6.0User Story51152Dispatching & confirmation
Confirmation of parent package can now confirm also all related sub-packages


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).

TAL 10.0-CAP6.0User Story54471Dispatching & confirmation
Enhancement of tour delay/earliness visualization in gantt charts (aka. red & green tour bars)


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.

TAL 10.0-CAP6.0User Story55432Dispatching & confirmation
Enhancement of the tour stop depot split functionality, it is now possible also to adjust the tour end address from the depot address


During the tour stop depot split it is now possible to also update the tour end address accordingly. This is done via new checkbox "Adjust tour end" on the tour stop depot split dialog. When checked then the tour stop end address is updated from the depot split address, but only if there are no orders being unloaded on tour end stop.

TAL 10.0-CAP6.0User Story56576Dispatching & confirmation
Menuitems for strategic tour routing were removed from D365 'Dispatch light - Tours' form


Menuitems for strategic tour routing were removed from D365 'Dispatch light - Tours' form, as such functionality belongs to the advanced tour management tools which are supported only in GPB.

TAL 10.0-CAP6.0User Story52821Integrations
Status message framework didn't work in D365, no messages were produced/sent


Status message framework didn't work in D365 as it was based on AIF functionality (which was deprecated in D365). The status message framework was redesigned and is now working again. The event based logic is triggered via Business Event, additionally there is a new data entity to support also recurringintegrations.

TAL 10.0-CAP6.0User Story53258Integrations
New data entity for TALgpbVolumeSummaryUnits table (Set up volume summary units for transport orders / -legs)


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

TAL 10.0-CAP6.0User Story53321Integrations
New data entity for CIRTRAHours (Business hours)


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

TAL 10.0-CAP6.0User Story53324Integrations
New data entity for CIRTRAAddressWMSLoadWeekDays table (Warehouse shipping days)


New data entity for CIRTRAAddressWMSLoadWeekDays table (Warehouse shipping days), toimprove the 'mass' management of the TMS Address.

TAL 10.0-CAP6.0User Story53326Integrations
New data entity for CIRTRAWaitTime table (Waiting time)


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

TAL 10.0-CAP6.0User Story53328Integrations
New data entity for TALAddressEmptiesSetup table (Address empties setup)


New data entity for TALAddressEmptiesSetup table (Address empties setup), toimprove the 'mass' management of the TMS Address.

TAL 10.0-CAP6.0User Story53330Integrations
New data entity for CIRTRAAddressQual table (Address Qualifications)


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

TAL 10.0-CAP6.0User Story54303Integrations
Several tour related transaction data entities are restricted only for export from D365


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.

TAL 10.0-CAP6.0User Story54359Integrations
Functionality to upload document attachment to orders (via EDI)


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

TAL 10.0-CAP6.0User Story54261Master data
Depreciated fields TALConfirmed & TALArrived on CIRTRATourOrderLine table


TALConfirmed & TALArrived fields were removed from CIRTRATourOrderLine table, as they were not effectively used in CAP.TMS module.

TAL 10.0-CAP6.0User Story55318Master data
Depreciated fields on TMS vehicle (and vehicle type) table, related to vehicle utilization


5 fields for "Max. % Utilization" were removed from the vehicle (and vehicle type) table, as not longer supported by CAP.TMS.

TAL 10.0-CAP6.0User Story53264Other / General
Deprecate roles T&L Shipment Builder System Administrator (TALshiShipmentSystemAdministrator) and T&L Warehouse Planner (TALshiWHSPlanner)


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

TAL 10.0-CAP6.0User Story54275Other / General
New role "T&L Depot clerk" was added to CAP.TMS module, to better manage the security of the cross-docking overview form


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.

TAL 10.0-CAP6.0User Story54451Other / General
Possibility to print pallet/package label from different TMS entities


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

TAL 10.0-CAP6.0User Story42011Shipment Builder
Packing slip posting (from tour) can now include also the 'not stocked' products


Previously the packing slip posting (from tour) only worked, when the Quantity parameter (on the dialog) was Picked. However, in such case the 'not stocked' products (which are obviously not in a warehouse work) were never posted.
Therefore, we had to support the 'Picked quantity and not stocked products' option as well. When this value is selected on the Packing slip posting dialog, then beside the items (which are in TMS packages) the system posts the packing slip for all the service items, which are in the packages of related sales order.

TAL 10.0-CAP6.0User Story52713Shipment Builder
New two picking statuses for items enabled on for transportation management (but not for warehouse management)


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.

TAL 10.0-CAP6.0User Story25794Subcontracting/IC invoicing
Depreciated filter criteria "Tour Id" was removed from the Invoice automation setup vendor rules


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.

TAL 10.0-CAP6.0Bug25950Customer invoicing
Transport orders (with Part-invoice order) were sometimes still appearing in transport order invoice pool


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.

TAL 10.0-CAP6.0Bug44383Customer invoicing
TMS invoice posting process could sometimes cause a database deadlock


TMS invoice posting process could sometimes cause a database deadlock, especially when invoicing was done via several periodic batch tasks (and some collective order was involved). The bug was corrected and also infologs were enhanced, to better inform about the result (and encountered errors).

TAL 10.0-CAP6.0Bug53244Customer invoicing
Automated periodic function for transport customer invoicing didn't include the transport orders that have different invoice account than customer account


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.

TAL 10.0-CAP6.0Bug25511Customer order management & pricing
''Open for' fields on transport order header didn't respect the entire address opening hours definition


On transport order header, in section 'date', the system shows in 'open for' fields how long is load/unload address opened for requested load/unload time slots. Previously the "open for" fields took into account only the first set of address opening hours (=morning slot). Now the "open for" fields uses also the second set of address opening hours (=afternoon slot).

TAL 10.0-CAP6.0Bug25812Customer order management & pricing
Update conflict in Part-invoice order collection, when preliminary collection already exists


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

TAL 10.0-CAP6.0Bug34340Customer order management & pricing
"Order confirmation" and in "Undo confirmation" on transport order could sometimes reset invoice status on already invoiced transport orders


In certain (quite special) constellations the "Order confirmation" and "Undo confirmation" (on Transport order header) could reset back the order invoice status from “Invoiced” either to "Invoiceable" or even to "Registered". This was happening only when main TMS parameter for "Invoice status logic" was set to "Advanced" and some special "Status term invoice" rule was applied. Bug was corrected - both processes don't anymore change the order invoice status when transport order is invoiced.

TAL 10.0-CAP6.0Bug42003Customer order management & pricing
Form 'Package identification code' sometimes doesn't show any details despite the packages (with barcode) were existing for transport order


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

TAL 10.0-CAP6.0Bug43020Customer order management & pricing
Searching for package directly from TMS main menu sometimes failed with stack trace error


Searching for the package directly from TMS main menu sometimes failed with a stack trace error. This was corrected and the search for packaged from main TMS menu works correctly.

TAL 10.0-CAP6.0Bug44374Customer order management & pricing
When index based surcharge was used in tariff surcharge groups then the resulting surcharge calculation didn't respect the 'index base' logic


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

TAL 10.0-CAP6.0Bug44385Customer order management & pricing
Re-calculation of transport order by 'zero' price was not possible


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).

TAL 10.0-CAP6.0Bug44410Customer order management & pricing
Delete of Part-invoice orders was not possible when Part-invoice order form was opened directly from main TMS menu


Now it is possible to delete Part-invoice orders even when form opened directly from main TMS menu.

TAL 10.0-CAP6.0Bug51264Customer order management & pricing
Small redesign of transport offer creation form


Several bugs were fixed in transport offer creation form; the form design was also enhanced for better user usability.

TAL 10.0-CAP6.0Bug51467Customer order management & pricing
Bug in package unit change in the package management form


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.

TAL 10.0-CAP6.0Bug51470Customer order management & pricing
It was possible to change some fields on transport order header even when transport order was already invoiced


Fields are locked for user changes on invoiced transport order.

TAL 10.0-CAP6.0Bug51791Customer order management & pricing
Code redesign of the emailing component of the order status message framework


Communication component (that is responsible for sending emails) of the order status message framework was redesigned, to re-use existing D365 standard components. It also solves certain issues with document attachment emailing.

TAL 10.0-CAP6.0Bug52971Customer order management & pricing
Duplicated form control menuitems on "Intermodal traffic" when form was opened from transport order


Duplicated form control menuitems were removed from "Intermodal traffic" form.

TAL 10.0-CAP6.0Bug53158Customer order management & pricing
Deletion of transport order line didn't automatically delete the 'position linked' order line packages


When transport order line was delete, the related 'position linked' order line packages were not treated (=stayed in the system). This is corrected now - the deletion of transport order line also deletes 'position linked' order line packages.

TAL 10.0-CAP6.0Bug53159Customer order management & pricing
The package identification structure was not reliable, especially when multiple packages were assigned to individual transport order lines.


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

TAL 10.0-CAP6.0Bug53173Customer order management & pricing
''One time' tariff zones were not respected during contract finding


The 'one time' tariff zones (defined directly on Contract Relation) are again correctly respected as contract finding criteria.

TAL 10.0-CAP6.0Bug55379Customer order management & pricing
Missing "Add" & "Remove" buttons for surcharge criteria, on surcharge group form


On surcharge group form, due to missing buttons for "Add" & "Remove" the surcharge criteria could be added/removed only via keyboard shortcut. This was corrected - surcharge criteria rules can be added/removed via dedicated buttons.

TAL 10.0-CAP6.0Bug55408Customer order management & pricing
Order collection (when done via batch) in certain constellations didn't respect correctly the order collection rules


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.

TAL 10.0-CAP6.0Bug25518Dispatching & confirmation
Sometimes it was not possible to insert a depot split on transport legs that already had some packages registered


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.

TAL 10.0-CAP6.0Bug25657Dispatching & confirmation
Several fixes in Default tour area (related to driving time & distance calculation)


Several issues were corrected in Default tour area (related to driving time & distance calculation).
1) The driving time & distance calculation (when launched on Default tour template) was sometimes not correctly saved to Default tour template
2) It is possible to launch driving time & distance calculation on the tour (that we generated out of Default tour).

TAL 10.0-CAP6.0Bug39335Dispatching & confirmation
The batch for transport leg generation didn't validate the existence of transport order line


Now the batch for transport leg generation has the same validation as manual process of transport order pre-dispatching (ie. the batch will not process transport orders with no transport order line).

TAL 10.0-CAP6.0Bug48426Dispatching & confirmation
Package management handling in dispatching process was not consistent


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.

TAL 10.0-CAP6.0Bug52829Dispatching & confirmation
Capacity check in tour planning is not consistent for Vehicle type and Default vehicle type of transport type


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.

TAL 10.0-CAP6.0Bug53217Dispatching & confirmation
Duplicated packages on transport legs after quantity quantity split of transport legs


When performing a quantity split on transport legs, the package structure was in some cases duplicated. This was corrected - now system asks user which packages should be kept/split-off during quantity split operation and respects user decision.

TAL 10.0-CAP6.0Bug53295Dispatching & confirmation
Transport leg day duration was not respecting the "Default values load-/unload date" rule


The "Default values load-/unload date" parameterization was not respected during transport leg generation process. This was corrected - now it is possible again to specify the transport leg duration via "Default values load-/unload date" setup, provided the duration is not defined via other tools (eg. Transit scheduling etc.)

TAL 10.0-CAP6.0Bug54418Dispatching & confirmation
System informs dispatcher once tour has been successfully released by new infolog


A new infolog has been added to the system which informs dispatcher that tour has be successfully released.

TAL 10.0-CAP6.0Bug54459Dispatching & confirmation
Wrong sequence of tour stops after sequence optimization was launched


Bugfixing of the sequence optimization of tour stops which was sometimes producing a sub-optimal result, especially on tours that were created from default tour templates.

TAL 10.0-CAP6.0Bug55332Dispatching & confirmation
In certain cases the periodic task "Generate/Update tour out of route/zone" was crashing with unhandled error


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.

TAL 10.0-CAP6.0Bug56570Dispatching & confirmation
Tour confirmation was sometimes not possible even though tour was in status "Released"


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.

TAL 10.0-CAP6.0Bug51227Integrations
Data entity for TALServiceLevelAgreement table sometimes failed with error "Field 'Criteria type' cannot be updated"


Data entity for TALServiceLevelAgreement table sometimes failed with error "Field 'Criteria type' cannot be updated". This was corrected by removal of 'Criteria type' mapping; the 'Criteria type' is now determined automatically from 'Criteria ID'.

TAL 10.0-CAP6.0Bug51238Integrations
Bug in data entity for TALUnitOfMeasureConversion table, the import sometimes failed with 'File Import not possible' error


Data entity for TALUnitOfMeasureConversion table was corrected.

TAL 10.0-CAP6.0Bug53238Integrations
Data entity for CIRTRAColRouteRoutes (Dispatch sector content) was renamed


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"

TAL 10.0-CAP6.0Bug54431Integrations
"Owner company" and "Check status" filters on the "Checked imported order" form were not performing reliably


Bugfixing of the "Owner company" and "Check status" filters on the "Checked imported order" form in transport order EDI; both filters now work correctly.

TAL 10.0-CAP6.0Bug53201Master data
Default load/unload address lookup enhancement on customer account form


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

TAL 10.0-CAP6.0Bug53310Master data
It was not possible to create a Default tour template, system showed only stack trace error


Creation of the Default tour (either manually or via "Duplicate default tour" function) was not possible due to some code error. Bug was corrected - the default tour template can be now created (or copied).

To remove the corrupted default tour templates a migration job from ADO 56524 should be run.

TAL 10.0-CAP6.0Bug25729Other / General
Parameter "Automatic package creation" was showing in the transport type form even thought the "Package management" license configuration was deactivated


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

TAL 10.0-CAP6.0Bug51664Other / General
It was not possible to define the 'default finance dimensions' on T&L order statistic calculation / Cost accounting categories


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.

TAL 10.0-CAP6.0Bug53339Other / General
Minor GUI label terminology unification for Part-invoice orders (was previously called "Invoice split")


Existing "Part invoice" related labels for menuitems in main TMS menu were adjusted.

Previously:
"Invoice split - preliminary"
"Invoice split - definitive"

Now is:
"Part-invoice orders - preliminary"
"Part-invoice orders - definitive"

TAL 10.0-CAP6.0Bug54278Other / General
CAP.TMS data migration jobs were sometimes showing in other legal entities as "not run" but in fact the data was already processed/corrected


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").

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

TAL 10.0-CAP6.0Bug54289Other / General
Bug in data migration jobs, when the execution dialog shows wrong caption in some cases


Sometimes when running some CAP.TMS release data migration job, the migration job dialog name and description showed data from the previously executed data migration job. This was corrected - the dialog data is now cleared before new data migration job execution setup is started.

TAL 10.0-CAP6.0Bug52802Shipment Builder
Enabling 'None' value in 'Splitting base' parameter in 'Trade and Distribution (module overlapping)" parameters


Originally the 'Splitting base' parameter in 'Trade and Distribution (module overlapping)" parameters was a mandatory setup, even though it makes sense only to a certain business cases. New parameter value "None" was introduced (and is the default parameter value), to be activated only when it is really needed.

TAL 10.0-CAP6.0Bug54406Shipment Builder
Trade forms could not be opened when new shipment builder config key is switched off


It was not possible to open the trade order forms (=Sales/Purchase/Transfer order) when new Shipment builder configuration keys was switched off; users were facing an error infolog "You are not authorized to access table 'Scheduling information...'". This was corrected, now trade order forms can be opened even when new Shipment builder configuration key is switched off, as the access validation logic was moved from form level to individual form detail sections (='Scheduling information group').

TAL 10.0-CAP6.0Bug25778Subcontracting/IC invoicing
Vendor 'Payment' hold code blocked the vendor invoicing


When a vendor was set to hold code 'Payment', than no invoice could be posted against the vendor. This was corrected, vendor invoicing is blocked only when the vendor hold code is 'All' or 'Invoice'.

TAL 10.0-CAP6.0Bug25798Subcontracting/IC invoicing
Manually changed invoice reference was not respested during vendor invoice journal posting


When the pre-generated invoice reference was manually changed in vendor invoice journal, it was not respected during vendor invoice journal posting.

TAL 10.0-CAP6.0Bug52936Subcontracting/IC invoicing
Legal entity logo was not printed on Intercompany transport invoice


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

TAL 10.0-CAP6.0Bug50553Subcontracting/IC order management & pricing
Contact person handling on Intercompany order was not consistent


Several bugs were corrected in the area of the "Contact person" handling on Intercompany order. Sometimes the contact persons were not showing in the fields/lookups, or were showing from from wrong legal entity etc.

TAL 10.0-CAP6.0Data conversion25693Other / General
Data migration job for 25713 task


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

TAL 10.0-CAP6.0Data conversion54283Other / General
Data migration job for removing duplicate migration jobs from other legal entities


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

TAL 10.0-CAP6.0Data conversion54310Other / General
Data migration job for 53310 task


The data migration job removes/deletes orphaned default tour lines (ie. which are not related to any default tour order header).

TAL 10.0-CAP6.0Data conversion56524Other / General
Data migration job for ADO 53310 task


The data migration job removes/deletes orphaned default tour lines (ie. which are not related to any default tour order header).

GPB 2.2.3User Story44765Dispatching & confirmation
Ability to specify a vehicle picture and visualize it in Resource selection form


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.

GPB 2.2.3User Story44829Dispatching & confirmation
Adding a possiblity to specify an individual icons for TMS vehicles


It is now possible to assign a pre-defined icon to every TMS vehicle, which is then visualized in GPBapp to help dispatchers getting a graphical overview which resources they are working with. It is possible to select from a pre-defined list of 33 icons that are provided by the CAP.TMS module. The vehicle icons are then automatically visualized in the Resource selection form (in resource main grid overview) and in both gantt forms (on resource assignment on level 2).

If a specific icon is not selected for some TMS vehicle then default hardcoded icon for vehicle type is used as a fall-back (=previously existing functionality).

Additionally it is possible to see all icons in new dedicated simple overview form:
CAPcargo Transport -> Setup -> Resources -> Icons

GPB 2.2.3User Story47479Dispatching & confirmation
Improvement of rendering performance of both gantt forms


Via code optimization the rendering performance of gantt bars was improved in both gantt forms. Impact should be noticeable especially when high amount of tours is being loaded to the gantt forms.

GPB 2.2.3User Story50580Dispatching & confirmation
Redesign of "Show capacity" dialog on both gantt forms (effecting only D365 installations)


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.

GPB 2.2.3User Story51353Dispatching & confirmation
Improvement of gantt forms automated refresh when TAL forms are launched & closed


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.

GPB 2.2.3User Story52633Dispatching & confirmation
Due to performance reasons, the blue highlight of tours (with manual ETA) was removed


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.

GPB 2.2.3User Story52685Dispatching & confirmation
Performance redesign of Resource selection, to achieve faster responsiveness of the screen - 1st part


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.


GPB 2.2.3User Story53043Dispatching & confirmation
Adding the possibility to open & filter GPBapp directly from several TAL forms


On several TAL forms (e.g. transport order form, dialog for 'Dispatch directly to new tour' etc.) it is now possible to open and filter GPBapp directly, either via dedicated button ("Dispatched tour (GPB)" in transport order form/list page) or via checkbox ("Go to tour (GPB)" in 'Dispatch directly to new tour' dialog). 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)
* User must have an access to GPB, via security parameterization


GPB 2.2.3User Story54239Dispatching & confirmation
Addition of intelligent fulltext search in vehicle lookups in both gantt forms


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.

GPB 2.2.3User Story54341Dispatching & confirmation
New button "Delete strategic tour routing" was added to both gantt forms


New button "Delete strategic tour routing" was added to both gantt forms (to button group Dispatch), via which dispatchers can now delete all pre-generated tour routing stops (aka. tour waypoints). Button is enabled only for the single tour selection and is disabled either when tour reaches status "Released" or "Confirming", based on main TMS parameter "Modification planning blocked from tour status".

GPB 2.2.3User Story54426Dispatching & confirmation
Correction of resource vs vehicle usage in Resource Dispatching & Resource selection forms


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)

GPB 2.2.3Bug44193Dispatching & confirmation
Worker's default Depot filter was not automatically applied in the Tour dispatching gantt form


When some default Depot filter was specified on the Worker, it was not respected/used when the Tour dispatching gantt form was opened. This was was corrected, now Worker's default Depot filter is initialized and applied during the Tour dispatching gantt form opening.


GPB 2.2.3Bug45581Dispatching & confirmation
Performance enhancement of Resource selection form, whole form data was reloaded too excesivelly


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.)


GPB 2.2.3Bug50998Dispatching & confirmation
Direct tour confirmation could lead to zero confirmed values


Confirming a tour via 'Confirm tour(s) directly' could lead to zero confirmed values and to a quantity change conflict even when the TMS main parameter "Initialise confirmed values from planned values" is set to TRUE.
This was corrected, the confirmation values are now initialized from planned values, if activated in main TMS parameters.

GPB 2.2.3Bug52761Dispatching & confirmation
Dragging a tour end was sometimes causing a stack trace error in Tour dispatching gantt form


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.

GPB 2.2.3Bug52769Dispatching & confirmation
Customer wish delay/early calculation on “on mouse over” details showed reliable figures only when “delay/early calculation was less than one day


Customer wish 'delay/early' calculation on 'on mouse over' details showed reliable figures only when 'delay/early' calculation was less than one day, as for example for delay of 1day 11hours 30min the 'one mouse over' details showed only "11:30". This was corrected, now the 'delay/early' calculation includes also day figures, showing for example "35:30" for delay of 1day 11hours 30min.

GPB 2.2.3Bug52795Dispatching & confirmation
The tour planning (and ETA) values were sometimes not automatically recalculated after whole tour rescheduling (via drag & drop)


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.


GPB 2.2.3Bug53133Dispatching & confirmation
Historical tours were displayed always as 'early', once enhancement for showing tour early/delay was activated (ADO 39447)


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.

GPB 2.2.3Bug53304Dispatching & confirmation
Performance of TMS address lookup (when inserting new tour stop on level 3 on gantt forms) was enhanced


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).

GPB 2.2.3Bug54327Dispatching & confirmation
Tour confirmation was sometimes not possible even though tour was in status "Released"


Tour confirmation was sometimes not possible even though tour was in status "Released"

GPB 2.2.3Bug54409Dispatching & confirmation
Tour end was sometimes not correctly visualizated in gantt bar


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.


GPB 2.3.0User Story1534Dispatching & confirmation
New functionality of map clustering


To improve the map performance (and to enhance user experience) a "clustering" was introduced to the map component.

In the background the map is separated into different clusters (aka. tiles) and the resource/order/tour icons inside the same cluster are not displayed individually/separately but are grouped together into summary icon (with element count).
Zooming closer into the map then reveals individual/separate icons, as the icons are not anymore located inside the same cluster.



GPB 2.3.0User Story1724Dispatching & confirmation
New map functionality of resource stacking/grouping


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.



GPB 2.3.0User Story34362Dispatching & confirmation
Performance improvements of map process "Show tour on map"


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).


GPB 2.3.0User Story44000Dispatching & confirmation
Validation of menuitem for Tour confirmation was enhanced


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.

GPB 2.3.0User Story51466Dispatching & confirmation
Small GUI reorganization of GST/GSR header menuitems/groups


To unite the dispatchers experience the following changes were done to main header menuitem ribbon in various GPB screens:

OS screen:

* Section "Controlling" was renamed to "Manage"
* "Show on map" menuitem was moved from "Geo services" section to "Dispatching" section
* "Geo services" group was removed
* Menuitems for "Goods management"/"Package management"/"Connected packages" were moved from "Shipment" group to "Manage" group
* "Dispatching" group was renamed to "Change owner"

GSR & GST screens:

* Section "Controlling" was renamed to "Manage"
* Section "Shipment" was moved one position left (ie. between "Manage" and "Print")
* New menuitems for "Package management" and "Connected packages" were added to "Manage" section



GPB 2.3.0User Story52627Dispatching & confirmation
New framework for generic/customized buttons in GPB (D365)


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.



GPB 2.3.0User Story52629Dispatching & confirmation
New framework for generic/customized filters in GPB (D365)


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

* GBP screen - on which GPB target screen the filter should appear
* Table name - which table holds the filter field
* Field name - which field should be used as filter criteria
* Label - name of filter. Currently the label is interpreted as 'plain text', it is not possible to use true language specific labels.
* Class name & Method name - only applicable for 'string' based fields. Optionally it is possible to define a class & method from where should GPB populate the lookup values.

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

* for Transport orders /-legs screen - the filters are added directly to the filter section above main gantt grid
* for both gantt screens - the filters are added to tab 'Maintain to the "Filter" menuitem group, to the list of all filters (new dedicated filter group on the right edge of filter form)


Following filter field data types are supported:

* Integer (whole number)
* Decimal number
* String (text)
* Enum
* Boolean (Yes/No)

The 'Datetime' filter field data type is not supported.

Supported screens:

*
Transport orders /-legs form
* Both gantt forms
* Resource selection forms

The map screen is not supported.

Limitations:

* Only single selection is supported in the filter fields
* For manyCAP.TMS tables/fields further code adjustment is still needed, these canbe done on project specific base.


GPB 2.3.0User Story52719Dispatching & confirmation
Driver picture feature


It is now possible to upload a driver picture to a Worker, which is then automatically shown in GPB Resource selection form (in resource details bottom section).

GPB 2.3.0User Story53022Dispatching & confirmation
Enhancement of tour delay/earliness visualization in gantt charts (aka. red & green tour bars)


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.


GPB 2.3.0User Story53261Dispatching & confirmation
Code/logic unification of quantity view on cross-docking form (TAL & GPB)


Followup of 26686 enhancement, which unifies the code so that the same code/logic (for summarized view of transport leg quantities) is used both for D365 & GPB.

GPB 2.3.0User Story56443Dispatching & confirmation
Correction of resource vs vehicle usage in Resource Dispatching & Resource selection forms


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)


GPB 2.3.0User Story56581Dispatching & confirmation
Performance redesign of Resource selection form in area of fitting/non-fitting resource availability calculation/visualization - 1st part


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.



GPB 2.3.0Bug42907Dispatching & confirmation
In German language version the label for "Transport orders /-legs" was distorted in GPB start screen


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

GPB 2.3.0Bug42941Dispatching & confirmation
Some labels in GPB were displayed in English language only, even though the GPB was launched in different language


Some labels in GPB were displayed in English language only, even though the GPB was launched in different language
This was corrected, the GPB labels should be displayed correctly in selected language.

GPB 2.3.0Bug42942Dispatching & confirmation
Several map control labels were distorted in German language version of GPB map screen


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


GPB 2.3.0Bug55304Dispatching & confirmation
Performance enhancement of Resource selection form, whole form data was reloaded too excessively - followup


A followup of 45581 task, which improves the "intelligence" of the automated refresh of the Resource selection form.

GPB 2.3.0Bug55314Dispatching & confirmation
Some vehicle icons were hard to recognize in the GPB screens


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

GPB 2.3.0Bug55434Dispatching & confirmation
Self-definable resource icons didn't show on several places in GPB


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


GPB 2.3.0Bug55511Dispatching & confirmation
Dedicated refresh button (on GSR/GST) sometimes didn't load all tours


Bug was fixed in the dedicated refresh button (on GSR/GST) which was causing that in (very special) constellations the GPB didn't load all tours to the gantt grid.

GPB 2.3.0Bug56430Dispatching & confirmation
Tour confirmation was sometimes not possible even though tour was in status "Released"


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.

GPB 2.3.0Bug56461Dispatching & confirmation
Error when conflict analysis form was opened from GPB screens


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

GPB 2.3.0Issue56684Dispatching & confirmation
KNOWN ISSUE: RS screen is not fully updated for new qualification framework


RS screen is not fully updated for new qualification framework, the green/red (fitting/non-fitting) side mini bars on resources do not reflect the new qualification framework.

TAL 10.0-CAP7.0User Story43145Customer order management & pricing
GUI redesign of "Direct dispatch (route)" & "Generate/Update tour out of route/zone" dialogs


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)).

TAL 10.0-CAP7.0User Story51775Customer order management & pricing
Several GUI enhancement of the 'Pre-order' functionality


Following enhancements were done for 'pre-order' functionality:
* New dedicated button 'Pre-order' was added to the transport order form, to directly create a pre-order.
* The "Order from pre-order" dialog was redesigned, for better user readability. Eg. the excessive menuitem groups were transformed into tabpages etc.
* The "Cancel" button on "Order from pre-order" dialog was renamed to "Close".

TAL 10.0-CAP7.0User Story54390Customer order management & pricing
Possibility to cancel a transport order


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

TAL 10.0-CAP7.0User Story56572Customer order management & pricing
Possibility to send a track & trace status messages per package


Previously the track and trace status message framework operated on the transport order, transport leg and tour order line level. This feature was improved with an additional, deeper level: packages. Hence a separate track and trace status message can generated for each package.

Prerequisite parameterization:

* Parameter "Message per package" has to be activated on the status message setup (CAPcargo Transport -> Setup -> Track and Trace -> Status message setup

Also the status message template (and the status message criteria) forms were enhanced to be able to send status messages only for certain package transactions/identifications etc.

TAL 10.0-CAP7.0User Story26022Dispatching & confirmation
New functionality of "resource swap" is introduced to tour planning


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.

TAL 10.0-CAP7.0User Story54449Dispatching & confirmation
New feature of "Failed delivery" is introduced to tour confirmation


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.

TAL 10.0-CAP7.0User Story57629Dispatching & confirmation
Enhancement of the capacity route/tour planning process, to create new tour when capacity limit of previous tour (of same route) was reached


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).

TAL 10.0-CAP7.0Bug56717Customer order management & pricing
Load & unload address names were not printed on the pallet label

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

TAL 10.0-CAP7.0Bug44061Dispatching & confirmation
Button "Edit" was removed from "Sub-contracting transport leg (LTL)" form (when called from GST/GSR) as obsolete


Button "Edit" was removed from "Sub-contracting transport leg (LTL)" form (when called from GST/GSR) as obsolete, as the form already starts in "edit" mode by default and further attempts to press button had some negative side effects.

TAL 10.0-CAP7.0Bug56479Dispatching & confirmation
In some constellations the manually specified ETA figures on tour stops were not respected during tour confirmation


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.

TAL 10.0-CAP7.0Bug56638Dispatching & confirmation
"Generate/Update tour out of route/zone" functionality (when used with parameter "Find and update existing tours"=FALSE) was in certain cases not planning all transport legs into tours


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.

TAL 10.0-CAP7.0Bug56736Dispatching & confirmation
The loading date (and time) of successor transport legs was initialized from the transport order header load date (and time)


When the transport legs were automatically split (via 'Cross docking rule') then the loading date & time on successor transport legs were populated from transport order header load date & time. This was corrected - the loading date & time of transport leg is initialized from transport order header load date & time only on the first transport leg.

TAL 10.0-CAP7.0Bug57606Dispatching & confirmation
Correction of the "View details tour" context option in GST & GSR


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

TAL 10.0-CAP7.0Bug58503Dispatching & confirmation
In several forms the transport unit id was concatenated, showing only first 10 characters of transport unit id (despite the transport unit id can have 20 characters)


Previously on several forms only the first 10 characters of transport unit id were shown. Eg. in tour confirmation, in conflict manager etc. This was corrected - now the full transport unit id is shown on these forms (ie. maximum of 20 characters).

GPB 2.3.1User Story41146Dispatching & confirmation
Performance improvement of the 'Pick-up', 'Shuttle', 'Distribution' & 'Direct' filters in the GPB 'Transport orders /-legs" screen


The filtering performance of the 'Pick-up', 'Shuttle', 'Distribution' & 'Direct' filters in the GPB 'Transport orders /-legs" screen was improved. Now all four checkboxes filters the transport leg grid without the need of the new database query, hence their performance is greatly improved.

GPB 2.3.1User Story55473Dispatching & confirmation
GPBapp was crashing when custom security role was restricting the GPB access to certain functionality/process


It was not possible to restrict an access to certain processes in GPB (ie. via custom roles/privileges/etc.) as the GPBapp was crashing in result. The security role/privilege handling in GPBapp was enhanced (ie. it is not crashing anymore) but only informs the user that the certain process/menuitem cannot be used due to the security restriction.

GPB 2.3.1User Story55618Dispatching & confirmation
Adding the possibility to open & filter GPBapp directly from several TAL forms


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).

GPB 2.3.1User Story56619Dispatching & confirmation
Driver's picture was displayed in GPB Resource selection screen only for users with "Purchasing agent" and "Sales clerk" security roles


Driver's picture was displayed in GPB Resource selection screen only for users with "Purchasing agent" and "Sales clerk" security roles. This was corrected - now the functionality of driver's picture require only GPB security role.

GPB 2.3.1User Story56536Dispatching & confirmation
Possibility to print a pallet label also from the GPB screens


Previously it was possible to print a pallet label only from D365 forms. This task introduces the option to print a pallet label also from GPB.
Now it is possible to set up a 'generic/custom' button for the pallet label printout on following GPB screens:
* 'Transport orders /legs' screen
* 'Resource dispatching' screen
* 'Tour dispatching' screen

GPB 2.3.1User Story56687Dispatching & confirmation
Log GPBapp errors in standard windows even viewer


Introducing a functionality to log GPBapp activities in standard windows event viewer, to be able to track (and investigate) GPBapp behavior (and client crashes).

GPB 2.3.1User Story58613Dispatching & confirmation
Informing user if login to GPB fails


If login to GPB application fails user is now informed via infolog.

GPB 2.3.1Issue58537Dispatching & confirmation
Newly introduced functionality of opening GST (and focusing of tour) from D365 forms is not 100% reliable


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.

GPB 2.3.1Bug50645Dispatching & confirmation
The resources selected in GSR in level 1 should not appear again in level 2 of tour details


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).

GPB 2.3.1Bug50994Dispatching & confirmation
In certain constellation it was not possible to a plan transport leg into GSR tour via drag and drop


When GSR was opened from GST (via "View details in Resource Dispatching") than adding a transport leg into GSR tour (via drag and drop) sometimes ended with the error infolog "Object reference not set to an instance of an object.". The issue was fixed and error infolog is not appearing anymore.

GPB 2.3.1Bug51272Dispatching & confirmation
Number of decimal places in planning unit visualization in GPB 'Transport orders /-legs' screen is now respecting the decimal precision parameter on D365 Unit.


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.

GPB 2.3.1Bug52611Dispatching & confirmation
Wrong alignment of menuitem 'View details tour' on the right mouse click context menu in GST & GSR gantt screens


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.

GPB 2.3.1Bug52765Dispatching & confirmation
GST screen was crashing when cross-reloading the tour GST->GSR->GST


When switching from GST into GSR (via 'View details in Resource dispatching') and then switching back to GST (via 'View details in Tour dispatching') the GST screen crashed. This was corrected, the GST screen crashing should not occur when changing the tour view between GST & GSR.

GPB 2.3.1Bug54438Dispatching & confirmation
When extending the tour duration (eg. via 'drag and drop' of tour end) the process was sometimes ending with warning infolog


When extending the tour duration (eg. via 'drag and drop' of tour end) the process was sometimes ending with "Function CLXTALrpActionBase.save has been incorrectly called." warning infolog. The code was corrected - the warning infolog is not populated anymore.

GPB 2.3.1Bug55296Dispatching & confirmation
In certain specific constellation the 'delay/early arrival' tour visualization was not accurate in GSR


When transport type was set to "Configuration Gantt bar extension=Delayed/early arrival" and "Switch off detailed scheduling=TRUE" then the delay/arrival visualization in GSR tour gantt was sometimes inaccurate. This was especially happening when several resources were assigned to the tour but not all of resources were assigned for the whole duration of the tour.

GPB 2.3.1Bug55325Dispatching & confirmation
Error infolog "Buffer 'Tour ...' changed by another user!" when working with tour in GST


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").

GPB 2.3.1Bug56452Dispatching & confirmation
Name of driver was concatenated in the GPB Resource selection form


Previously only the first 20 characters of the driver's name were shown in the Resource selection screen. This was corrected - now the whole driver's name is displayed.

GPB 2.3.1Bug56551Dispatching & confirmation
Several labels in 'Transport orders /-legs' screen were displayed correctly only in the 'en-us' language


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

GPB 2.3.1Bug56578Dispatching & confirmation
Incorrect calculation of the 'Cost distance' in the Resource selection screen


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

GPB 2.3.1Bug57619Dispatching & confirmation
GPB screens were not opening in certain constellations


In certain constellation the opening of GPB screens was not possible. This was happening especially when a the custom generic filters/menuitems labels were contain some non-standard characters.
The error handling of the GPB screens was enhanced, to inform user about encountered issues.

GPB 2.3.1Bug58608Dispatching & confirmation
Several functionality was failing in GSR when GSR was opened from GST (via 'View details in Resource dispatching')


When the GSR was opened from the GST (via 'View details in Resource dispatching') then some functionality in the GSR was failing (eg. D365 forms were not opening, processes were failing etc.). This was corrected - now the tour is properly focused in the GSR, once opened from GST (via 'View details in Resource dispatching').

GPB 2.3.1Bug58610Dispatching & confirmation
Closing of the shipment building process was sometimes not possible on 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.

GPB 2.3.1Bug58615Dispatching & confirmation
No result infolog was populated to users when "Distance and time calculation" was launched in GSR


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.

TAL 10.0-CAP8.0User Story39343Customer invoicing
New consistency validation in customer invoice posting process


New validation was added to the customer invoice posting process, to ensure that the invoice (that is posted in D365 general ledger) is consistent with the TMS module. Several criteria are checked during the validation and in case the consistency validation fails then user is informed via error "Invoice for account '%1' cannot be created!". It is recommended to retry the invoice posting again, as it might be that the invoice inconsistency is due to some standard D365 general platform issue. Only repeatedly failed invoice posting cases should be individually analyzed.

TAL 10.0-CAP8.0User Story45585Customer invoicing
Introducing an option to selectively post the orders in the TMS invoice pools


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.

TAL 10.0-CAP8.0User Story52941Customer invoicing
Feature of delayed batch posting from the manual customer invoice pool was deprecated


The technical solution of the customer invoice pool posting was enhanced, to avoid the blocked records in case the customer invoice pool posting fails to finish.
As a consequence this task removes the feature of delayed (ie. batch) posting from the manual customer invoice pool.
The automatic batch posting (ie. via 'Invoice automation setup") is preserved/not affected and should be used instead.

TAL 10.0-CAP8.0User Story51462Customer order management & pricing
New feature of adding/removal of packages even when transport order is already in dispatching


Previously the package creation/deletion was possible only when transport order was in status "Registered". This was enhanced - now the package creation/deletion is possible even when transport order is already submitted to dispatching.
New packages can be created/deleted in package management form, from transport order/transport leg/tour order levels.

Certain limitations still apply:
* The creation of new packages for transport orders/legs (for which some quantity split exists on transport legs) is currently not yet supported. The creation of new packages for transport orders/legs (for which some address split exists on transport legs) is supported.
* The creation & deletion of packages in tour confirmation form is currently not yet supported. If needed this can be done in tour form (on tour order level), even for tours that are being confirmed.
* The confirmation of packages (that are not linked to individual transport order lines but to transport order header only) from tour level is currently not yet supported.

TAL 10.0-CAP8.0User Story55301Customer order management & pricing
New feature of tariff surcharge per transport order cancel status code


New criterion of "Cancel status" (with Table/All logic) was added to the tariff surcharge criteria, to enable the setup of the automated tariff surcharges per transport order cancel status code.

TAL 10.0-CAP8.0User Story31961Dispatching & confirmation
More precise resource swap date & time determination


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).

TAL 10.0-CAP8.0User Story53174Dispatching & confirmation
Performance improvement of the planning a transport leg into tour


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

TAL 10.0-CAP8.0User Story58886Dispatching & confirmation
Adding a conflict analyzer menuitem to the 'Dispatch light - Transport legs' form


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.

TAL 10.0-CAP8.0User Story54403Integrations
New feature of transport order update via EDI


Previously it was possible only to import new transport orders via EDI. This was enhanced - now it is possible (via EDI) also to update (previously imported) transport order.

Following use cases are supported:
* Change load/unload date/time
* Change load/unload address
* Update quantities (transport quantity/planning quantity)
* Add packages (including barcode identification) and content lines

Key characteristics:
* New field "Import type" in EDI framework, to distinguish between "create" and "update" EDI messages
* New menuitem group "Change date/time" on transport order, for manual order changes. This can be used also on regular transport orders (ie. not only on transport orders imported via EDI)
* New menuitem "Change logs transport order", to store the logs for changed dates/addresses of orders already in planning. Logging is activated on transport type (parameters"Capture date/time changes", "Capture address changes")
* New fields "Date last update" & "Time last update" on transport order
* Four new "Update allowed" parameters on import process, to activate/deactivate updating of addresses & dates/times
* Two new conflicts "Change customer wish" & "Change load/unload address" in conflict management, to inform dispatchers about performed order update
Disclaimer/limitations:
* Via EDI function it ispossible to only update an already existing imported order, the deletion of an(imported) order is not supported.
* EDI function has no check oforder update version, e.g. to prevent an update being processed while itsalready superseded by another update.
* Customers who want to usethe ‘EDI update function’ must provide a unique combination for the ‘customeraccount’, ‘import group’ and ‘external sales ID’ in the import file (pertransport order). If such combination cannot be provided the system will beunable to retrieve the unique reference to the original imported order andresult in an error.
* Updating an order via EDI doesn’thave its own Track&Trace status; the existing Track&Trace status ‘Orderimported’ covers only the order import (ie. order creation via import).

Important:
existing projects (who would like to continue using "Create" feature) must add "Import type" to data import project and specify fixed value of "1" (ie. Create). As by default the "Import type" has value of "0", in which case the transport orders will not be imported.

TAL 10.0-CAP8.0User Story56644Integrations
GUI redesign of the 'Checked imported order' form


''Checked imported order' form was redesigned, to match the GUI of the of 'Imported transport orders' form.

TAL 10.0-CAP8.0User Story53037Master data
New feature of fuel price management was added to the TMS


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

TAL 10.0-CAP8.0User Story58625Master data
It is now possible to directly geo-code an address even though the previous geo-coding had failed


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".

TAL 10.0-CAP8.0Bug28053Customer order management & pricing
Change of customer account on transport order was sometimes not possible


Change of the customer account on the transport order was sometimes not possible due to a bug in update mechanism of the status invoice documents. This was corrected - the status invoice documents are now updated according to the invoice document rules of the new customer account.

TAL 10.0-CAP8.0Bug54196Customer order management & pricing
Adding a package to the existing overpackage on transport order that is already dispatched in some tour could in some cases produce a "not supported" data structure


When adding a package to the existing over package (with some other packages) on the transport order that is already dispatched in some tour (which is different than the tour that is holding the transport order of the other packages) could cause a "not supported" data structure. This was enhanced - now users are stopped via error infolog "Due to breaking the over package impact scope, process cannot be executed. As the transport order %1 is already in the tour (that is different than tour which contains other over package elements) or is directly confirmed without the dispatching."

TAL 10.0-CAP8.0Bug55477Customer order management & pricing
On several forms the address search field became a mandatory once used for searching the address


Previously when the address search field was once used, it become a mandatory field until the form was closed. This was corrected, the address search field is never a mandatory field.

TAL 10.0-CAP8.0Bug56598Customer order management & pricing
Several description fields on transport order creation dialog form were not displayed correctly


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)

TAL 10.0-CAP8.0Bug57628Customer order management & pricing
Rough scheduling could not be automatically updated when 'Change address' or 'Change date/time' functionality was used on transport order form


In 'Change address' or 'Change date/time' dialogs in transport order forms users can opt for automated "Run rough scheduling" recalculation but no rough scheduling was actually performed. This was corrected - the rough scheduling is recalculated when user selects "Run rough scheduling=TRUE" in the dialogs of 'Change address' or 'Change date/time' menuitems on transport order form.

TAL 10.0-CAP8.0Bug58652Customer order management & pricing
Customer account could not be changed on transport order when order was already delivered


Previously it was sometimes not possible to change a customer account on the transport order that was already delivered. This was corrected - now the customer can be changed even on the delivered transport orders.

TAL 10.0-CAP8.0Bug58728Customer order management & pricing
Filtering via load (or unload) date in the transport order overview sometimes showed also transport orders which were not fitting the defined date filter range


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.

TAL 10.0-CAP8.0Bug58910Customer order management & pricing
''Default values load-/unload date' parameterization was not respected during rough scheduling (after load/unload address change)


When users were changing load (or unload) address either in transport order form or on transport leg forms, the 'Default values load-/unload date' parameterization was not respected when users opt for rough scheduling re-calculation (ie. "Run rough scheduling (transport legs) = TRUE") in the address change dialog.

TAL 10.0-CAP8.0Bug58918Customer order management & pricing
No track & trace status messages were generated by the system in certain cases


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.

TAL 10.0-CAP8.0Bug63039Customer order management & pricing
Removing excessive "Cancel statuses transport order" index elements


Previously the "Cancel statuses transport order" had three field in the main table index:
* Cancel status
* Transportation process
* Invoice

Later two fields were removed from the index, as they made no sense. So the "Cancel statuses transport order" has now only the "Cancel status" field in the index.

Important:
if users already created more than one Cancel statuses with same id, the duplicates must be removed before this TAL version can be installed.

TAL 10.0-CAP8.0Bug58663Dispatching & confirmation
Rough scheduling functionality was not working correctly for "Backward scheduling" transport orders


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.

TAL 10.0-CAP8.0Bug58694Dispatching & confirmation
In some constellations the manually specified ETA figure on tour end stop was not respected after the undo of the tour confirmation


In some constellations the manually specified ETA figure on the tour stops was not respected during the undo of the tour confirmation process. This could lead to incorrect tour duration visualization (eg. tour 'shrinking'). The issue was corrected - now the manual ETA is respected in the undo of the tour confirmation process even when defined on the last tour end stop.

TAL 10.0-CAP8.0Bug60552Dispatching & confirmation
''Generate/update tour out of route/zone' planning process worked only when "Show all routes" was not used


Previously the 'Show all routes' option on the 'Generate/update tour out of route/zone' dialog made the planning process entirely failing (ie. transport legs were not planned into existing our, new tours were not created etc.). This was corrected - now the 'Generate/update tour out of route/zone' functionality works correctly even when user switches the 'Show all routes' option in the planning dialog.

TAL 10.0-CAP8.0Bug51661Integrations
Data entity 'TAL Surcharges contract relation' was enhanced, to be able to import also the fuel index based surcharges


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

TAL 10.0-CAP8.0Bug58585Integrations
''Load date fixed' and 'Unload date fixed' address flags were added to transport order import framework


Previously the 'Load date fixed' and 'Unload date fixed' address flags were existing only on the transport order form but were not included in the transport order import framework. This was enhanced - both flags were added to the 'Imported transport orders', 'Checked imported orders' and also to relevant transport order data entities.

TAL 10.0-CAP8.0Bug63074Integrations
Package unit field discrepancy between 'Checked imported order' form and transport order form


Previously, in the package management of the 'Checked imported order' form, the package unit was just a freetext string field, without any validation. This could lead into issues later in the process - as it didn't correspond to the field handling on the transport order. This was corrected - the package unit in the package management of the 'Checked imported order' form is now a lookup field and is validated against package unit master table.

TAL 10.0-CAP8.0Bug51325Master data
The deletion of transport address (as part of deletion of global address book location) was sometimes not successful


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).

TAL 10.0-CAP8.0Bug52853Master data
"Validity" check during the transport order creation seems not working


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.

TAL 10.0-CAP8.0Bug53196Master data
Minor GUI correction of the 'CAPcargo Transport Address' tab (on standard AX address form)


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.

TAL 10.0-CAP8.0Bug55456Master data
It is now possible to directly batch geo-code an addresses even though the previous geo-coding had failed


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.

TAL 10.0-CAP8.0Bug55462Master data
Enhancement of the address spelling validation mechanism against PTV map component


Previously the address was validated against PTV map component only on the level of street name spelling. This was enhanced - now also the spelling of the city & zip code is validated against PTV map component.

TAL 10.0-CAP8.0Bug55464Master data
Address suggestion from PTV map component was bypassing the standard D365 address detail validation


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.

TAL 10.0-CAP8.0Bug55480Master data
New address creation was not possible from the address search result dialog


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.

GPB 2.3.2User Story2016Dispatching & confirmation
Feature of splitting the whole tour via certain depot was deprecated and removed


Feature of splitting the whole tour via certain depot was removed, as it led to the loss of existing tourID (ie. existing tour was physically deleted and new two tours were created). Such behavior proved to be unusable and confusing to dispatchers.
Dispatchers should use the tour stop 'Depot split' feature instead, which is available on the 'right mouse click' context menu on the individual tour stop.

GPB 2.3.2User Story11416Dispatching & confirmation
New feature of tour stop split was added to the GPB dispatching gantt screens


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.

GPB 2.3.2User Story54452Dispatching & confirmation
Performance optimization of resource "fitting/non-fitting" visualization in Resource selection form


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.

GPB 2.3.2User Story57588Dispatching & confirmation
New framework for adding project specific custom fields to 'Transport orders /-leg' screen


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.

GPB 2.3.2User Story57631Dispatching & confirmation
Enabling resource swap feature also in "Tour Dispatching" screen in GPB


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.

GPB 2.3.2User Story58730Dispatching & confirmation
New feature of transport order update via EDI - GPB additions


GPB part of the 54403 enhancement.

Two new menuitems were added to the GST & GSR:
* Confirm address change - when pressed it accepts all 'address change' based conflicts on the selected tour
* Confirm date/time change - when pressed it accepts all 'day/time change' based conflicts on the selected tour

Additionally the visualization of the tour stops was enhanced (ie. on level 3), to show via "red triangle" icons whether the tour stop has any 'address change' or 'day/time change' based conflict. The "red triangle" icons occur either next to address name (for 'address change' based conflicts) or in front of the detail scheduling dates (for 'day/time change' based conflicts). Additional details are available on the 'on mouse over/hoover on" infobox.

GPB 2.3.2User Story63022Dispatching & confirmation
GPB addition for the new feature of fuel management


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.

GPB 2.3.2Bug48530Dispatching & confirmation
In certain cases it was not understandable to user why some transport leg could not be planned into tour


When the transport leg (of the transport order that is part of over package) is attempted to be planned into tour (which does not contain the rest of over package transport legs) the user is newly informed by infolog "Due to breaking the over package impact scope, process cannot be executed. %1 legs are missing to fulfill the scope!", to understand better why the transport leg was not planned into the tour.

GPB 2.3.2Bug52767Dispatching & confirmation
GPB client was sometimes crashing when switching between GST->GSR->GST on selected tour


When switching between GST & GSR screens (via "View details in Resource dispatching” & "View details in Resource dispatching”) the GPB client was sometimes crashing. This was corrected - now the GPB client doesn't crash, regardless of from which gantt screen the switching was initiated.

GPB 2.3.2Bug54338Dispatching & confirmation
In certain cases when scrolling of gantt into past/future the tours were loaded onto screen with some delay


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.

GPB 2.3.2Bug56504Dispatching & confirmation
Inconsistency in GSR/GST tour filtering, in some cases the tour gantts were duplicated


The resource/tour filtering in GST & GSR was reworked.

Following corrections were applied (ie. new behavior is described):
* when tour is searched directly via tour id - main filters are ignored; for GSR only checkbox "Truck", "Trailer", "Driver" filters are applied.
* when tour is filtered from counterpart gantt screen (via "View details in 'Resource Dispatching'" & "View details in 'Tour Dispatching'") - only checkbox "Truck", "Trailer", "Driver" filters are applied; main filters are ignored.
* when gantt is entirely refreshed via dedicated menuitem - all main filters (and for GSR also checkbox "Truck", "Trailer", "Driver" filters) are applied.

GPB 2.3.2Bug58902Dispatching & confirmation
Transport leg could not be planned into tour via "drag & drop" from map


In some cases the planning of the transport leg into the tour (from the map via drag & drop) was sometimes not working correctly. The issue was corrected, now the transport leg planning (via drag & drop) is possible again.

GPB 2.3.2Bug58905Dispatching & confirmation
Performance improvement of several filters on Tour & Resource dispatching forms


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

GPB 2.3.2Bug63045Dispatching & confirmation
Gantt grid sometimes didn't match the gantt header date & time


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.

TAL 10.0-CAP9.0User Story58822Customer order management & pricing
New feature of transport order load & unload date ranges


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.

TAL 10.0-CAP9.0User Story58889Customer order management & pricing
Enhancement of the Track & Trace status message criteria - adding 3 new conditions


The Track & Trace status message criteria were enhanced, following entities can be newly used as criteria conditions:
* Customer group (TAL)
* Transport type group
* SLA group

The previously existing Customer group criteria was renamed to "Customer group (D365)", so that system supports both grouping types - the TAL customer groups as well as the D365 standard customer groups.

TAL 10.0-CAP9.0User Story53174Dispatching & confirmation
Performance improvement of the planning a transport leg into tour


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

TAL 10.0-CAP9.0User Story63149Dispatching & confirmation
New feature of return goods handling


Return goods can be available for pickup at the customer address without having it registered as a transport order.
The solution idea is that return packages are pre-generated in the system (as TMS default order, for each customer location, incl. packages) and customer receives the provided package labels upfront.
In the moment when some return goods need to be registered for pickup at customer location, the driver registers such return package. Then dispatchers in the tour confirmation form can register a return order (for these return goods packages) which in the background generates transport order (from original default order that contains the return packages) and the transport order is planned automatically into the same tour (to capture the return of goods from customer location). Used return packages are automatically de-linked from the original default order and re-linked to newly created transport order (for returned goods).

The package labels for returns contains following information (and can be printed from package management of the default order):
* Unique SSCC label ID
* Pickup address (ie. from which customer location)
* Delivery address (ie. where returns should be transported)

TAL 10.0-CAP9.0User Story50578Integrations
CAP.TMS newly supports the PTV xServer version 1.30


Due to PTV official discontinuation of xServer 1.24, the CAP.TMS doesn't support this version anymore. For the projects using the PTV map components it is advised to upgrade to some newer xServer version. The CAP.TMS release 10.0.9.0 was tested on PTV xServer version 1.30.

TAL 10.0-CAP9.0User Story63015Integrations
New feature of order cancellation via EDI


It is now possible to cancel a transport order also via EDI update mechanism.

New fields were added to the transport order EDI data entities:
* Cancel status
* Reason code
* Return address (transportaddress ID)

All these 3 fields can be either defaulted on import process, or imported with the EDI message via data entities. The default values from import process are applied when EDI message doesn't contain these fields but its import type is "Cancel".

The existing field "Import type" was enhanced in EDI entities, now contains also a "Cancel" value.

The cancellation of order via EDI re-uses the existing functionality of order cancellation (ie. same as pressing menuitem "Cancel" on transport order form).

It is possible to cancel order via EDI only if order was not yet directly invoiced or no transport leg was yet dispatched into tour. In case some transport leg is already planned in some tour, the EDI process will not cancel such order automatically and the EDI message will stuck in Checked imported order form (with error code). In order to process with cancellation users must first un-plan all leg(s) from tour(s) manually.

Please note:
* The cancellation of transport order via EDI does not physically delete a transport order, it just sets a transport order as cancelled.
* Undoing of the order cancellation can happen only in CAP.TMS, the option to undo the order cancellation via EDI is not supported.

TAL 10.0-CAP9.0User Story63510Other / General
De-activation of not supported CAP.TMS configuration keys in new CAP.TMS installations


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.

TAL 10.0-CAP9.0User Story58891Subcontracting/IC order management & pricing
Enhancement of the TMS cost / revenue allocation for tours with mixed sub-contracting modes


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).

TAL 10.0-CAP9.0Bug63036Customer invoicing
In certain cases the part-invoice orders didn't appear in invoice pool


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.

TAL 10.0-CAP9.0Bug25568Dispatching & confirmation
Dispatching conflict "Business hours - address closed" was sometimes being triggered even though the address was not closed


The functionality of dispatching conflict "Business hours - address closed" (conflict id 500) was enhanced, to correctly handle the situations when the UTC time shift (on the transport leg load/unload date) lead also to a different date.

TAL 10.0-CAP9.0Bug57616Dispatching & confirmation
Delete of tour stop that was participating in resource swap was failing with some technical error


When users tried to delete the tour stop (that was participating in the resource swap) then the resource swap tour stop deletion failed with following error infolog:
@TRA3973 @TRA3974
Function TALgpbGanttTour::deleteTourStop has been incorrectly called.

The error handling in tour stop deletion was improved, now users are informed with proper error infolog:
The tour stop is used as start or end by the resource '%1'!
Tour line cannot be deleted!

TAL 10.0-CAP9.0Bug63364Dispatching & confirmation
Performing a part delivery on the tour sometimes failed with error


When the part delivery was performed on the tour, the "split-off" transport leg was correctly unplanned from the tour but the unplanning of the underlying "split-off" packages sometimes failed with the error "Cannot edit a record in Package confirmation (CLXTALPackageTourOrderLine). The record has never been selected.". The issue was corrected, now the underlying packages follow the transport leg even when part delivery is performed on the tour (in "Goods management" form).

TAL 10.0-CAP9.0Bug63457Dispatching & confirmation
Confirmation of tour/tour stop/tour order line didn't automatically confirm the underlying packages


The tour confirmation process was enhanced, now the packages are automatically confirmed even when user confirms the whole tour (or tour stop, or tour order line).

TAL 10.0-CAP9.0Bug63487Dispatching & confirmation
Several corrections in rough scheduling algorithm for transport leg date determination


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.).

TAL 10.0-CAP9.0Bug64615Dispatching & confirmation
In certain parameterization constellation the sending of some transport orders to pre-dispatching was not possible


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.

TAL 10.0-CAP9.0Bug63433Other / General
Batch for driving time & distance calculation was sometimes crashing when some error was encountered


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.

TAL 10.0-CAP9.0Data conversion63509Other / General
Data job for new feature of transport order load & unload date ranges, needs to be launched also by projects who use the shipment builder


The data job to update the transport order/leg structure for existing transport orders that are in dispatching (and were not delivered yet). The data job does the following actions:
* Fills the new date ranges on first/last transport legs
* Sets on transport orders (that were created from shipment builder process) the the "Load time window applied on" and "Unload time window applied on" parameters to "Entire date range"

Please note:
* This data job must be launched even by projects who use the shipment builder (despite these projects cannot actually benefit from the new date range enhancement), to ensure that shipment builder related transport legs behave correctly in dispatching process.

GPB 2.3.3User Story54444Dispatching & confirmation
Enhancement of the vehicle/resource filters in all gantt screens


The vehicle/resource filters were not consistent in the GPB screens. In some screens it was possible to filter only via resource, in others only via vehicle. This was enhanced - now both vehicle & resource filters are present in relevant GPB screens.

Following GPB screens were enhanced:
* Tour Dispatching
* Resource Dispatching
* Resources

GPB 2.3.3User Story63267Dispatching & confirmation
GBP addition for new feature of transport order load & unload date ranges (only D365FO GPBapp)


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.

GPB 2.3.3User Story63292Dispatching & confirmation
Code improvement of how the tour stops are being created/inserted


The code logic was improved, to achieve better stability & performance when tour stops are being created/inserted.

GPB 2.3.3User Story63337Dispatching & confirmation
GBP addition for new feature of transport order load & unload date ranges (only D365FO GPBapp)


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.

GPB 2.3.3User Story63516Dispatching & confirmation
Adding a vertical scroll bar to GPB infologs


In some cases the infologs produced by GPB could be quite long (eg. during "Complete tour execution" process etc.). Previously users could not read the whole infolog as the infolog text didn't fit into infolog dialog. This was enhanced, now for longer infolog texts the infolog dialog contains a vertical scroll bar, so that users can scroll & read the whole infolog text.

GPB 2.3.3User Story63550Dispatching & confirmation
GS: Improvment of customer wish visualisation (red/green extension)


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

GPB 2.3.3User Story63575Dispatching & confirmation
Function deprecated: the 'fly out' Qualifications right side panel on the gantt screens


The 'fly out' Qualifications right side panel on the gantt screens was removed as deprecated - users should use instead the more powerful action menuitem Qualifications (located in gantt screens in top action ribbon, in the "Dispatching" section, in the "Resources" menuitem group).

GPB 2.3.3Bug18006Dispatching & confirmation
Visualization of driving time empty (aka. "black line") in the level 1 of the tour was sometimes not consistent


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.

GPB 2.3.3Bug45369Dispatching & confirmation
High CPU utilization when visualizing tours on map


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.

GPB 2.3.3Bug56544Dispatching & confirmation
Several labels were not showing proper language translation in GST/GSR screens


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

GPB 2.3.3Bug63512Dispatching & confirmation
Deletion of multiple resource assignments from the tour (in 'one by one' action sequence) sometimes failed with an error


The code was corrected, now the deletion of multiple resource assignments from the tour (in 'one by one' action sequence) doesn't fail with an error anymore.

Additionally the feature of "Goto Tour Main Table" from resource assignment (ie. in level 2) was removed as deprecated, as there exist the same feature already on the tour itself (ie. in level 1).

GPB 2.3.3Bug63514Dispatching & confirmation
In Resource screen the horizontal scroll bar was automatically reset to default position (ie. to the left) when users tried to use vertical scroll bars


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.

TAL 10.0-CAP10.0User Story44357Customer invoicing
New feature of mass printing of TMS invoices


New feature of mass printing of TMS invoices were added to the system. The menuitem accessible from main menu:
CAPcargo Transport -> Periodic -> Invoice automation -> Print transport invoices

In mass printing dialog users can define further criteria, to define the scope for the TMS invoice printing. The destination of the printout (eg. printer, email etc.) can be defined via standard D365 print management.

TAL 10.0-CAP10.0User Story42081Customer order management & pricing
Improvement of package management performance


Package management performance was improved, via optimization of the table indexes.

TAL 10.0-CAP10.0User Story61367Customer order management & pricing
New feature of 'Scheduled part-delivery' was added to the system


A new 'Scheduled part-delivery' tool was introduced, whichenables the user to define on which dates what part of the transport order has to betransported, then the tool itself executes the transport leg splitting in the background.

The 'Scheduled part-delivery' form isaccessible from the transport order and from the transport order list page, viaa new menuitem 'Scheduled part-delivery' in the Dispatching button group. The new menuitem is only enabled ifthe order is in Registered status and is not shipment builder based and does not contain any packages.
On the 'Scheduled part-delivery' form, user first defines in the header which vehicle types (for truck & for trailer) are foreseen to be used. System then calculates the total available resource capacity for the specified planningunit.
Then in the upper grid user creates desired part-delivery structure (which is at the end used as a base for transport leg creation process). Each part-delivery record is defined by a quantity (in the specified planning unit).
User can also specify individual unload date & unload time for every part-delivery record. If no date/time is specified then system will use the unload date/time from transport order header.
Once the desired part-delivery structure is achieved (in the upper grid), it must be pre-calculated (via "Pre-calculate' menuitem). If the resulting structure (in the lower grid) is according to user expectation, user can finish the process by pressing the 'Split' button. Once 'Split' button is pressed, system generates transport legs from selected transport order, respecting the part-delivery structure (incl. unload dates/times/quantities). The transport order is then immediately available in dispatching (ie. transport order status is changed to 'Plannable').

Please note:
The feature of 'Scheduled part-delivery' is available only for transport orders that were not created from D365 trad orders (via shipment builder).

TAL 10.0-CAP10.0User Story67670Customer order management & pricing
Transport order cancellation process adjustment (allow to specify return address only when it can be effectively used)


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.

TAL 10.0-CAP10.0User Story51047Dispatching & confirmation
Performance improvement of the tour deletion process


The performance of the tour deletion process was improved, via code redesign. The performance optimization will be especially noticeable during the deletion of large tours (eg. with 20+ tours stops, with many packages etc.). The optimization affects the tour deletion both in D365 'Dispatch light - Tours' and GPB gantt screens.

TAL 10.0-CAP10.0User Story55483Dispatching & confirmation
Usage of D365 email templates for Tour report SSRS


Previously it was not possible to define a custom email subject text for Tour report SSRS. This was enhanced by adjusting of Tour report SSRS to use the standard D365 email template feature, where email subject can be defined.

Key characteristics of the enhancement:
- A new transport parameter "E-Mail template Tour report" was introduced to main TMS parameters - defines a default D365 email template for the Tour report SSRS.
- A new parameter "E-mail template" was introduced to printing dialog for Tour report - is initialized from main TMS parameters but can be altered by users for individual creation of Tour report SSRS.
- In the selected D365 email template create a record where subject email text is defined. Following placeholders can be used:
- %ResourceName% - is replaced by driver resource name (if specified on the tour), or by truck resource name (if specified on the tour) or by vendor name (a fallback for LTL sub-contracting order). In above mentioned sequence.
- %TourPlannedEndDate% - is replaced by planned tour end date.
- The Tour report SSRS then generates the email subject from D365 email template (only for email print destination).

TAL 10.0-CAP10.0User Story56719Dispatching & confirmation
New 'ETA manual' fields were added the to the tour confirmation form


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.

TAL 10.0-CAP10.0User Story63599Dispatching & confirmation
New feature of 'Vehicle capacity per country' was added to the system


As the vehicle capacity utilization can be different, depending on the local country legislation, a new feature of 'Vehicle capacity per country' was introduced to the system.
When user is defining a capacity for the vehicle/vehicle type, it is now possible to define for which country is the capacity definition valid. When no country is selected then the vehicle capacity is considered as 'valid for all countries'. The vehicle capacity checks through out the module were adjusted, to first apply the country specific capacity definition and only when no such are defined then system goes for capacity 'valid for all countries'. Existing capacity related conflicts were adjusted, to respect this logic too.
As it can happen that transport leg (carried by vehicle) passes thru more countries, then whenever a capacity calculation is executed by the system, it considers all the countries (that are involved in the transportation process) and defines the capacity record to be used by a minimum logic.

TAL 10.0-CAP10.0User Story53013Integrations
Enhancement of the import/update of transport order via EDI (fix of Known issue 53246)


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.

TAL 10.0-CAP10.0User Story64542Master data
New feature of "Compartments", to extend the capacity definition of the TMS resources (phase 1)


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).

TAL 10.0-CAP10.0User Story63601Shipment Builder
Enhancement of the 'Remove from transportation' function on the trade order lines


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.

TAL 10.0-CAP10.0Bug44393Customer order management & pricing
It was possible to set up (and calculate) the part-invoice orders even when some address was inactive


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.

TAL 10.0-CAP10.0Bug57670Customer order management & pricing
Transport order invoice lines were sometimes not keeping a correct reference to source entity


In certain cases it could happen that transport order invoice lines (ie. CIRTRACustInvoiceLine records) were not having a proper reference to original order line record. This was especially happening for transport order header surcharges (when being split into individual order line finance dimensions, for invoicing purposes); their invoice lines were sometimes not referencing to any order line. This was corrected, now the transport order invoice line referencing is checked (and if needed it is automatically corrected) during price calculation.

TAL 10.0-CAP10.0Bug59729Customer order management & pricing
Excessive usage of "Do you want to delete packages" on multi-selected Transport order deletion


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.

TAL 10.0-CAP10.0Bug64506Customer order management & pricing
Batch for 'Generate transport orders from default orders' required a transport type filter


When trying to generate transport orders from default orders via batch, the batch job did run successfully only when some transport type filter was defined during batch preparation. When no transport type filter was defined, the batch task failed with error. This was corrected, now the transport orders can be generated via batch from the default orders even when there is no transport type filter specified during batch preparation.

TAL 10.0-CAP10.0Bug65540Customer order management & pricing
Suppressing the 'decision making' dialog for overwriting the existing data on the order lines, when contract finding is run via batch


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).

TAL 10.0-CAP10.0Bug66723Customer order management & pricing
Performance improvement of transport distance table


The performance of the transport distance table was improved, via optimization of the table index.

TAL 10.0-CAP10.0Bug67620Customer order management & pricing
Price calculation menuitem on transport order form was sometimes not active


The reason for price calculation menuitem being not active on transport order form was that at least one of addresses on transport order was set inactive. The issue was corrected, now the price calculation menuitem is active even when some of addresses are set inactive, instead the user is informed via infolog, to understand better why the price calculation cannot be performed.

TAL 10.0-CAP10.0Bug58541Dispatching & confirmation
Functionality of 'Confirm tour(s) directly' was sometimes failing in D365 'Dispatch light - Tours' form


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.

TAL 10.0-CAP10.0Bug63051Dispatching & confirmation
It was possible to perform a resource swap even on entirely confirmed tours


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').

TAL 10.0-CAP10.0Bug65657Dispatching & confirmation
Quantity split of transport leg was sometimes failing in case of several quantity splits in the row


In case the transport leg needed to be split more than once via quantity split, sometimes only the first quantity split was performed successfully. Further quantity splits were in some cases failing, especially when the transport order was also split via some depot. The splitting mechanism was improved, the combination of quantity & depot splitting of the transport legs acts consistently even for multiple splitting in the row.

TAL 10.0-CAP10.0Bug67585Integrations
Cancellation of transport order via EDI was possible only when some return address was included in EDI message


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.

TAL 10.0-CAP10.0Bug54294Subcontracting/IC invoicing
It was possible to set up the automated sub-contractor invoicing process even for sub-contracting orders of invoice type 'Vendor invoice'


It was possible to set up the automated sub-contractor invoicing process even for sub-contracting orders of invoice type 'Vendor invoice'. Such sub-contracting orders were not processed by automated invoicing, as the automated sub-contractor invoicing is supported only for sub-contracting orders of invoice type 'Self-billing'. The issue was corrected, the 'Invoice type' field was removed from set up of automated invoicing process.

GPB 2.3.4User Story55470Dispatching & confirmation
Reorganization of GPB security parameterization, depreciation of 'T&L Graphical Planning Board User' role


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.

GPB 2.3.4User Story63393Dispatching & confirmation
Performance driven redesign of the GPB 'Transport orders /-legs' screen, introduction of the 'paging' mechanism


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

GPB 2.3.4User Story64689Dispatching & confirmation
New feature of 'Vehicle capacity per country' was added to the system - GPB addition


GPB addition for the 63599 enhancement. New field 'Country' was added to the capacity tab on GPB Resource screen, to visualize for which country is the vehicle capacity defined.

GPB 2.3.4User Story65674Dispatching & confirmation
Performance improvement of the "Fitting/Non-Fitting" logic in the GPB Resource selection screen


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

GPB 2.3.4Issue67776Dispatching & confirmation
KNOWN ISSUE: Currently only the 1st filter definition works correctly in the column filters in the GPB 'Transport orders /-legs' screen


Known issue of the new feature 'Performance driven redesign of the GPB 'Transport orders /-legs' screen, introduction of the 'paging' mechanism' (introduced by 63393 task).
In general it is possible to set up additional filters on several columns in the GPB 'Transport orders /-legs' screen.
Currently only the 1st filter definition works properly in the column filter dialog, the 2nd filter definition is faulty and should not be used in the current GPB release.

GPB 2.3.4Bug43887Dispatching & confirmation
The merging of tour stops in the GPB Tour Dispatching screen was sometimes not possible


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.

GPB 2.3.4Bug59719Dispatching & confirmation
When the transport legs were manually rescheduled on "Transport orders /-legs" screen, the new transport leg dates were shown only after the grid was manually refreshed


The main grid of "Transport orders /-legs" screen is now automatically refreshed when the transport leg dates are changed as a a result of "Rough scheduling (transport legs)" functionality.

GPB 2.3.4Bug63387Dispatching & confirmation
Background processes in GPB screens sometimes failed to finish


The background processes (eg. for refreshing the resources in the Resource selection tour upon tour change in one of the gantt screens, when Resource selection form is actively linked to gantt dispatching screen) was sometimes not performing reliably. This was for example happening when user changed the focus to different tour before the background process for resource refresh was finished for previously selected tour. The issue was corrected, now the background processes correctly recognize the focus change of the source and restart again for newly set focus.

GPB 2.3.4Bug66628Dispatching & confirmation
Several fixes for the customer wish calculation/visualization in the GPB gantt screens


Following issues were corrected, in the calculation/visualization of customer wish earliness/delay in the GPB gantt screens:
* when more than one transport order is being unloaded at the same tour stop, then system now shows * placeholder sign in the tour stop overview (level 3), as more than one customer wished date & time can occur. For exact value of customer wished unload date & time, dispatcher must switch to tour order line detail grid.
* the customer wished unload date & time column in the tour stop overview (level 3) is only shown when some customer wished date & time is defined in the transport order.
* the earliness/delay calculation & visualization of customer wish is newly applied in GPB dispatching gantt screens only when there is no driving distance between customer unload and tour end. The validation runs against the driving time on the tour stop where customer unload happens.
So when the tour is not ending on the same location as customer unload (ie. there exist some driving time after the order was unloaded at customer location), then the earliness/delay visualization (and calculation) of customer wish is suppressed, as it is not supported.

GPB 2.3.4Bug66704Dispatching & confirmation
In certain cases the generic buttons in the GPB app didn't correctly process the multi selection of records


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.

TAL 10.0-CAP11.0User Story69604Customer order management & pricing
New feature of commodity entity (only 'non shipment builder' transport orders)


New feature of "Commodity" has been added to the TMS system. It basically represents an additional level of details on the transport order line, to better support the commodity related business cases. Commodity can enhance (or even replace) the transport unit. So it is for example possible to have a transport order with transport unit "BAG" (with commodity "Grain organic") and another transport order with transport unit "BAG" (with commodity "Wheat"). Or even without any transport unit (eg. when commodity is transported in bulk).

Key characteristics:
- Commodity structure definition is done in new form accessible from main menu "CAPcargo Transport ->Setup -> Commodities"
- Commodity structure is hierarchical, each element can be valid for table/group/all customers (with a date validity)
- New 'Commodity' field on transport order line (and also on many places where transport order line is presented, eg. transport order creation dialog, transport leg points, tour orders, tour confirmation, goods management, default order line, LTL sub-contracting order line, intercompany order line, GPB etc.)
- On transport type a different color (for each commodity visualization on the map) can be specified
- Transport order EDI flow was updated to allow the import (and update) of the commodity on transport order line

Usage of commodity:
- informational - extends (or replaces) the transport unit
- qualifications - as the commodity can be setup as a qualification requester, further usages are possible:
- conflicts - new commodity related conflicts were introduced (conflict id 1260 - 1264)
- restriction for combined loading - certain commodities should not be transported together in the same resource

Please note:
in current release the commodities can be used only in the transport orders that were not generated from the D365 trading order entities.

TAL 10.0-CAP11.0User Story65649Dispatching & confirmation
New feature of transport price simulation has been added to both dispatching gantt screens


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.

TAL 10.0-CAP11.0User Story66677Dispatching & confirmation
New feature of 'ULD/Compartment handling' (replaces the previous carrying resource feature)


New ways of carrying resource assignment are introduced. The carrying resource assignment form allows the user to have a tour stop level overview about orders to be assigned to carrying resources and about orders, which are already assigned to them. Moreover, the assignment itself can be also done on the form with the consideration of combined loading restrictions. The new form is prepared to 2 levels of carrying resource assignment: tour order and package level.

On the other hand, if prior the planning of the orders, resources are already assigned to the tour, then carrying resource assignment can be executed directly in GPB, via dragging and dropping the transport leg on the resource of the tour.

Key points:
- The definition whether the carrying resource assignment is managed on tour order level (or newly on package level) is done via new parameter 'Carrying resource assignment on package level', on transport type.
- The new carrying resource functionality can be accessed in following places (both TAL and both GPB dispatching gantt screens):
- Menuitem 'Carrying resource assignment' in the GPB top action bar (in menuitem group 'Resources') - launches the process for the whole tour (eg. for all loading/unloading tour stops)
- Menuitem 'Carrying resource assignment' in the GPB 'right mouse click' context menu of the tour stop (level 3) - launches the process just for individual loading/unloading tour stop
- Menuitem 'Assign carrying resource' in the GPB top action bar - assigns the carrying resource for the whole tour (eg. for all loading/unloading tour stops)
- The existing carrying resource assignments are also shown in the tour order level (when opened either from 'Dispatch light - Tours' or from GPB screens)
- After activation of the relevant configuration key the previous functionality of carrying resource (on tour orders) becomes replaced by new ULD/Compartment handling functionality (which requires usage of GPB).
**IMPORTANT NOTE ABOUT CONFIGURATION KEY**
In order to use the new feature ULD/Compartment handling and/or the redesigned existing feature "assign carrying resource/compartment to tour orders", the configuration key "Compartment handling (ULD)" under "**Not officially released sub-modules**" has to be switched on. - The feature will be officially released in the next release R12, since minor last details/improvements are still open. But the main functionality is available and can be tested.

Please note:
- The unofficial config keys are by default switched off. This does though not harm the data migration job of the carrying resource (see 69700) which shall be executed at installation of this release 11.
- The new carrying resource (aka. ULD/Compartment handling) functionality can be used only from GPB. The TAL 'Dispatching light - Tours' form can be used only for visualization of already existing carrying resource assignment but not for its creation.

TAL 10.0-CAP11.0User Story67740Integrations
Enhancement of the track & trace event and message framework


The track & trace event and message framework was enhanced, following functionality was added:
- Introduction of message configuration group Id - the track & trace status setup is newly referenced by unique configuration group id. Additionally a new configuration table has been introduced that links the customer & service (SLA) & message configuration group id.
- Package level events - newly the confirmation of a package (eg. a package scan) triggers an individual track & trace event. Previously the trigger happened only on the whole transport leg level which triggered track & trace events also for other (ie. not currently confirming) packages.
- Package scan events overview - new package scan event overview was added to the system, users can see also the related track & trace event statuses.
- New 'Address group' track & trace event message criteria - newly the track & trace event messages can be set also per address group (previously the setup was possible only on individual address level)
- 'External address codes' can be newly included in the outbound status messages - previously the message contained only internal address id, which was not too useful in the external receiving systems.
- 'External track & trace status Id' and 'External track & trace status name' can be newly included in the outbound messages.
- Enhancement of the event date/time usage in the status outbound messages - previously certain types of the status outbound message contained only the registration date/time of the event (ie. the date/time event was registered in D365) but not the original date/time of the event (ie. the date/time the event really happened, prior to D365 registration). This was improved, system now includes the event original date/time in all event messages (for which such information is available in the D365/TMS).

TAL 10.0-CAP11.0User Story70639Integrations
Enhancement of the 'Customer postal addresses' data entity


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

TAL 10.0-CAP11.0User Story70643Integrations
Enhancement of the 'Party postal address V2' data entity


Following TMS fields were added to the 'Party postal address V2' data entity (DirPartyLocationPostalAddressV2Entity):
- 'Protect Geo-coordination'
- 'Geo-coding failed'

TAL 10.0-CAP11.0User Story69602Other / General
CAP.TMS data migration jobs were sometimes showing in other legal entities as "not run" but in fact the data was already processed/corrected


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.

TAL 10.0-CAP11.0User Story67541Shipment Builder
Enhancement of the Service (SLA)


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.)

TAL 10.0-CAP11.0User Story69666Shipment Builder
New feature of shipment lot quantity criteria


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).

TAL 10.0-CAP11.0Bug70696Customer order management & pricing
Under certain circumstances the EDI import process could create 2 transport orders from 1 EDI import message


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.

TAL 10.0-CAP11.0Bug70700Customer order management & pricing
Under certain parameterization no barcode was printed on the package label


Previously when no package identification type was defined in the main TMS parameters then no barcode was printed on package label (even though the package had some barcode specified). This was enhanced, now when no package identification type is defined in the main TMS parameters then the system prints first found barcode of the package.

TAL 10.0-CAP11.0Bug67767Dispatching & confirmation
Inconsistency in the visualization of customer wished date & time on tour stop stops (level 3)


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.

TAL 10.0-CAP11.0Bug67802Dispatching & confirmation
Inconsistency in the adding of new packages when transport order is already planned in some tour


New packages (which were created by the increase of transport quantity on transport order that was already planned in some tour) were not automatically accessible on the tour. The behavior was corrected, now the new packages are accessible on the tour regardless whether they have been created directly (ie. added on transport order) or indirectly (ie. via the transport quantity change).

TAL 10.0-CAP11.0Bug69687Dispatching & confirmation
Package confirmation sometimes failed with error


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.

TAL 10.0-CAP11.0Bug70672Dispatching & confirmation
In certain cases the transport leg was created with empty date (or the date was set to 1900)


The issue was encountered especially in following constellation:
- Main TMS parameter for 'Respect opening days' was set TRUE
- Main TMS parameter for 'Max. future planning (number of days)' was not specified (ie. was set to 'zero')

Then for some cases the rough scheduling algorithm could not determine the suitable transport leg date. The issue was corrected, newly when no suitable transport leg can be found during rough scheduling then the system uses the date from transport order as a fallback.
Additionally a new validation has been added to the save of main TMS parameters, to inform the user that the above constellation was encountered and to advise either to specify some 'Max. future planning (number of days)' or to deactivate the 'Respect opening days' parameter.

TAL 10.0-CAP11.0Bug70688Dispatching & confirmation
Tour activity variable calculation did not calculate correctly for planning unit 5


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.

TAL 10.0-CAP11.0Bug72315Dispatching & confirmation
Change of tour stop sequence (via drag & drop) was sometimes not possible in both dispatching gantt screens


In certain cases it was not possible to change the sequence of the tour stops via drag & drop in the level 3 of dispatching gantt screens. The issue was corrected, now the change of the tour stop sequence is blocked only when it makes no sense (eg. move unload before load, move confirmed tour stop etc.)

TAL 10.0-CAP11.0Bug72378Dispatching & confirmation
Order package structure could get inconsistent after certain dispatcher actions


The order package structure could get inconsistent after certain dispatcher actions. This was especially happening when a whole order line split has been performed (via 'Keep' or 'Remove' menuitems in goods management forms) on transport leg that belong to the transport order which was already geographically split (ie. had some depot splits). The behavior was corrected, now the package structure is consistent after quantity & geographical split actions.

TAL 10.0-CAP11.0Bug72507Dispatching & confirmation
Wrong column name in the 'Dispatch light - Transport legs' form


In the 'Dispatch light - Transport legs' form one of the column names was wrong. The label was corrected, now instead of 'Temporary' the column name is 'Order quantity'.

TAL 10.0-CAP11.0Bug72519Dispatching & confirmation
Package structure could get inconsistent after certain dispatcher actions


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.

TAL 10.0-CAP11.0Bug72625Dispatching & confirmation
Issue with frozen transport leg scheduling (aka. rough scheduling) in certain constellations


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.).

TAL 10.0-CAP11.0Bug69707Integrations
Transport type (provided in EDI import file) was sometimes not respected during transport order import process


When some default transport type was specified on the TMS import group then the transport type (that was provided in EDI import file) was ignored. The behavior was corrected, the default transport type (specified on TMS import group) is used only when no transport type is provided in EDI message.

TAL 10.0-CAP11.0Bug70663Shipment Builder
Some shipment builder related elements (eg. fields/parameters) didn't have any usage in the current shipment builder process


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.

TAL 10.0-CAP11.0Bug72436Shipment Builder
In certain cases it was not possible to remove shipment lot from shipment


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

TAL 10.0-CAP11.0Bug69499Subcontracting/IC invoicing
''Post selected' feature was not working properly in vendor invoice pool, when launched from vendor invoice journal


Previously the 'Post selected' feature in vendor invoice pool (when launched from vendor invoice journal) posted all records in the grid. This behavior was corrected, now the 'Post selected' post only the selected records.

TAL 10.0-CAP11.0Bug68634Subcontracting/IC order management & pricing
Transport quantity on 'Sub-contracting transport leg (LTL)' order was sometimes not displayed correctly


This was especially happening when some quantity split was performed on the original transport order line, then on LTL order line the system displayed the original (ie. not split) transport quantity. The issue was corrected, now the system respects the quantity split and shows only the corresponding transport quantity on the LTL order line.

TAL 10.0-CAP11.0Data conversion69700Integrations
ULD/Compartment handling: creates a new ULD/Compartment handling compatible structure from previous 'Carrying resource' assignment data


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).

TAL 10.0-CAP11.0Data conversion72343Integrations
Data migration job for the task 69666 (New feature of shipment lot quantity criteria)


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.

TAL 10.0-CAP11.0Issue72661Dispatching & confirmation
KNOWN ISSUE: ULD transactions of carrying resource not automatically split at part-delivery


The new features ULD/compartment/carrying resources (66677) will not yet automatically split the transactions in the part-delivery process.

Example:
- 10 PAL in tour, assigned to truck A
- Split load into 6 and 4 PAL
- The ULD assignment (transaction table) stays on 10 --> The user has to adjust it manually to 6

This will be fixed in release 12 with task 72662

TAL 10.0-CAP11.0Issue72664Dispatching & confirmation
KNOWN ISSUE: ULD transactions of carrying resource not automatically created in GPB when multi-selected legs are dropped in GSR for new tour


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

GPB 2.3.5User Story42965Dispatching & confirmation
New dispatching feature - generate 1 tour from several 'multi-selected' transport legs


Previously when user selected several transport legs in 'Transport orders /-legs' screen and did 'drag & drop' them to unused space of the dispatching gantt screens, then the system created several tours (each with one transport order). This was enhanced, now the system creates one tour for all selected transport legs. During the 'drop' action the user can specify some further details of the new tour (eg. exact tour start date & time, allocate resources, activate the 'Sequence optimization' or 'Respect business hours' logic etc.)
Additionally the system is newly using the 'Route/Zone' of the transport legs for initialization of several fields in the new tour (eg. tour start date & time, tour start & end address, transport type, resource initialization etc.). In case when the selected transport legs belong to different 'Routes/Zones', then system is using for initialization the 'Route/Zone' that is specified in the 'drop' action dialog.

Please note:
- When the 'drop' action happens to unused space in the 'Resource Dispatching' screen then the tour is created for the resource depending on the 'drop' position.
- The same dialog is newly used also for the manual new tour creation (ie, via "New tour" menuitem in both dispatching screeens), hence it is possible to initialize fields from 'Route/Zone' for the new tours that are created also by this method.
- In case the previous functionality is needed (ie. create individual tours from selected transport legs) the user can still use the 'Generate tour from transport leg' planning method.

GPB 2.3.5User Story64467Dispatching & confirmation
New 'ship' and 'aircraft' resource icons were added to the system


Several 'ship' and 'aircraft' resource icons were added to the system, for better visualization of alternative resource types. The parameterization happens in the TMS vehicle details, where user can select from 10 new vehicle icons.

GPB 2.3.5User Story64596Dispatching & confirmation
Better visualization of tour stop details in the level 3 in gantt 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.

GPB 2.3.5User Story64598Dispatching & confirmation
GUI improvement of the gantt screens (horizontal scrolling bar is wider)


When not all tour stops can be visualized in the level 3 of gantt screens (eg. in case of higher count of tour stops), the horizontal scrolling bar is presented to the user. Previously the horizontal scrolling bar was quite thin and users reported some difficulties when using it. The horizontal scrolling bar was improved - is wider now.

GPB 2.3.5User Story65759Dispatching & confirmation
Enhancement of the tour stop delete, when tour contains some automatically generated strategic tour routing (aka. waypoints)


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.

GPB 2.3.5User Story66722Dispatching & confirmation
New validation of the GPB client, to ensure the compatibility match with the D365 version


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.

GPB 2.3.5User Story67806Dispatching & confirmation
GPB client version is newly hard-coded, instead of being populated from D365 label file


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.

GPB 2.3.5User Story68653Dispatching & confirmation
New feature of 'Undo tour closing' was added to both dispatching gantt screens


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.

GPB 2.3.5User Story69607Dispatching & confirmation
GPB addition for the task 69604 (New feature of commodity entity (only 'non shipment builder' transport orders))


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).

GPB 2.3.5User Story69619Dispatching & confirmation
Performance improvement of tour visualization in both dispatching gantt screens


The performance of the visualization of tour gantt was improved in both dispatching gantt screens, by optimization of the code responsible for the customer wish "early/delay" visualization.

GPB 2.3.5User Story69696Dispatching & confirmation
GPB additions for the task 66677 (New feature of 'ULD/Compartment handling' (replaces the previous carrying resource feature))


Adds the new 'ULD/Compartment handling' also to the GPB screens. For more details please see release description of task 66677.

GPB 2.3.5User Story70690Dispatching & confirmation
Enhancement of the SCM status 'on mouse over' pop-up descriptions in both dispatching gantt screens


The SCM status 'on mouse over' pop-up descriptions were enhanced in both dispatching gantt screens. Previously the 'on mouse over' SCM status descriptions showed for example 'Detailed planned', newly the description shows 'Detailed planned: Predecessor leg planned into a tour and detailed scheduled, but tour not yet released.'

GPB 2.3.5User Story72388Dispatching & confirmation
GPB client executable file was renamed from 'client.exe' to 'GPBclient.exe'


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.).

GPB 2.3.5Bug42078Dispatching & confirmation
Duplicate conflicts in the conflict ID filter lookup in gantt screens


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.

GPB 2.3.5Bug63007Dispatching & confirmation
When Resources screen was opened for the first time, all resources were sometimes shown as 'Planned' even though some of them were still not planned


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.

GPB 2.3.5Bug65725Dispatching & confirmation
Wrong visualization of resource capacity in Resources screen


Previously the visualization of resource capacity in Resources screen (ie. in 'Capacity' tab page of resource details) was not too reliable. Following issues were corrected:
- Duplicated visualization of 3rd planning unit (and planning quantity)
- 5th planning unit (and planning quantity) was missing entirely

GPB 2.3.5Bug66743Dispatching & confirmation
The 'dotted' air line visualization of the counterpart transport leg points was sometimes misbehaving on the map screen


On the map screen (with some transport legs loaded), when the user clicks on some leg point then the map connects the leg point with its counterpart leg point via the "dotted" air line. Previously this mechanism was working properly only when user clicked on the unload leg point. The behavior was corrected, now the "dotted" air lines visualizes both transport leg points even when user clicks on the load leg point.

GPB 2.3.5Bug69554Dispatching & confirmation
In certain cases the merging of tour stops was not possible


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.

GPB 2.3.5Bug69592Dispatching & confirmation
Not accurate visualization of customer wish 'early/delay' (in level 1) in certain cases


The visualization of customer wish 'early/delay' in level 1 tour gantt bars (aka. the red/green bars) was in certain cases not accurate, as the earliness/delay was visualized even when more transport orders (with different customer wished dates) were unloaded at the same tour stop. The behavior was corrected, newly the customer wish 'early/delay' is visualized only when there is exactly one transport order being unloaded.

GPB 2.3.5Bug69628Dispatching & confirmation
GPB performance & freezing improvements in Gantt (for certain constellations)


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.

GPB 2.3.5Bug69631Dispatching & confirmation
Deletion of strategic tour routing was not possible in 'Resource Dispatching' screen


Previously the deletion of strategic tour routing in 'Resource Dispatching' screen was not possible, the functionality was failing with an error. The issue was corrected, now the deletion of strategic tour routing is possible from both gantt screens.

GPB 2.3.5Bug69669Dispatching & confirmation
The visualization of customer wish 'early/delay' didn't respect the main GPB parameter


Even though deactivated in the main GPB parameters (ie. 'Show customer wish' parameter was set to FALSE) the customer wished date was still visualized in tour stop details (in level 3 of dispatching gantt screens). The issue was corrected, now the customer wished date respects the main GPB parameter 'Show customer wish'.

GPB 2.3.5Bug69751Dispatching & confirmation
No possibility to adjust the resource leg by 'drag & drop' in the 'Resource Dispatching' screen


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.

GPB 2.3.5Bug69758Dispatching & confirmation
In certain cases the 'Complete tour execution' functionality in dispatching gantt screens ended in stack trace error


In certain cases the 'Complete tour execution' functionality in dispatching gantt screens ended in stack trace error. This was especially happening when the print destination of packing slip was set to 'screen' (via print management). The behavior was adjusted, now the packing slip printing to screen is not supported via print management during complete tour execution but can be triggered manually after the complete tour execution.

GPB 2.3.5Bug72297Dispatching & confirmation
No possibility to select & copy the tour stop information text from the 'pop-up' dialog in the gantt screens


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

GPB 2.3.5Bug72429Dispatching & confirmation
Correction of several issues in the map screen


Several issues were corrected in the map screen:
- all transport legs were visualized on the map screen, despite only single transport leg was pushed from 'Transport orders /-legs' screen
- switching between transport legs in the 'Transport orders /-legs' screen automatically visualized the air line of the transport leg even though the transport legs were not pulled from the 'Transport orders /-legs' screen

GPB 2.3.5Bug72564Dispatching & confirmation
No tour information icons after filtering the exact tour id


When the user searched the exact tour id in the gantt screens, the resulting tour gantt bar was displayed without additioinal information icons (eg. sub-contracting icon, tours status icon, driver assignment icon etc.). The issue was corrected, now the tour information icons are visualized in the gantt bar even when exact tour id is searched & filtered.

2020-09User Story25509Dispatching & confirmation
Performance optimization of the tour scheduling mechanism


Previously in some processes the tour scheduling mechanism was called too excessively, as it was called per process element. As part of general performance optimization, this was enhanced - newly the tour scheduling mechanism is called once per individual process.

Following planning methods were affected/enhanced:
- Generate tour from transport leg
- Generate/Update tour out of route/zone
- Dispatch directly to new tour
- Manual create of new tour

2020-09User Story25521Dispatching & confirmation
Optimization of the tour scheduling mechanism


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.

2020-09User Story25975Dispatching & confirmation
Performance optimization of "Generate/Update tour out of route/zone"


During "Generate/Update tour out of route/zone" planning method the system can also calculate driving time & distance (if activated in main TMS parameters via "Tour distance/time calculation in real-time"). Previously such driving time & distance calculation happened individually after addition of every tour stop in the tour. Which, especially in the case of mass transport leg planning via "Generate/Update tour out of route/zone", could lead to sub-optimal performance. This was enhanced, now the driving time & distance calculation is performed only once - when all transport legs are added to the tour.

2020-09User Story49407Dispatching & confirmation
Optimization of the "Generate/Update tour out of route/zone" dispatching method


The implementation of "Generate/Update tour out of route/zone" was re-worked, to achieve a better performance especially in mass transport leg planning. The optimization was done on the code architecture level - the functionality of "Generate/Update tour out of route/zone" mechanism itself was not altered.

Important, please note:
- Users must delete their usage data for class TALGenerateTourFromRouteController before they can launch "Generate/Update tour out of route/zone" again. If the usage date for this class is not cleared, the class will not work
- Additionally if some periodic task for "Generate/Update tour out of route/zone" is set up in the system, this periodic task must be deleted (and recreated). Otherwise the periodic task will start failing with error "TALGenerateTourFromRouteController - Invalid query".

2020-09User Story55356Dispatching & confirmation
New feature: customer pick up at depot & customer delivery into depot


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)

2020-09User Story43951Integrations
Enabling the usage of "External codes" for transport addresses in the EDI order import process


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.

2020-09User Story72541Integrations
Enhancement of the track and trace status messages (manual sending of event messages)


This enhancement introduces a possibility of a manual sending of the track and trace event status messages. The functionality can be launched via menuitem "Manually create message" in the "Confirmation" action pane of the transport order form, users can then in the wizard select which event message should be generated/sent.

Please note:
- The menuitem "Manually create message" was existing already in previous release(s) but did not produce a reliable result. This task officially releases this functionality.

2020-09User Story72544Integrations
Enhancement of the track and trace status messages (adding the exact timestamp into more event messages)


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)

2020-09User Story72545Integrations
Correction of duplicate event message generation for certain track and trace statuses


For certain track and trace statutes the system previously sometimes created (and sent) a duplicate event message. This was especially happening for following track and trace statuses:
- Status420 (Load/unload finished)
- Status425 (Load/Unload package finished)

The issue was corrected and duplicate event messages should not occur anymore.

2020-09User Story72654Integrations
Release of the "Message framework" & "Transport Event Management" functionality


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.

2020-09User Story73697Integrations
New data entities for sub-contracting orders


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).

2020-09User Story73702Integrations
New data entity: TAL Revenue and cost splitting


New data entity "TAL Revenue and cost splitting" was added to the system, it is now possible to export TMS cost & revenue statistics from D365 (the data entity is allowed only for exporting).

2020-09User Story67545Master data
Enhancement of the dispatching activity setup


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.

2020-09User Story18702Other / General
Re-work of the "Named User License Counts" licensing report


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

2020-09User Story72652Other / General
Removal of configuration key "Compartment handling (ULD)" from "**Not officially released sub-modules**" section


The configuration key "Compartment handling (ULD)" was removed from "**Not officially released sub-modules**" configuration key section. The feature "Compartment handling (ULD) is officially released and generally available without any dedicated configuration key.

2020-09User Story73620Other / General
Display of TAL license expiration in "Info about CAP.Transport&Logistics" form


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

2020-09User Story67651Shipment Builder
New feature: D365 sales return order is newly supported by the shipment builder


A new entity is involved in the shipment builder feature, the sales return order. Via this new shipment building area the user is enabled to create CAPcargo shipment and transport order from sales orders of type Returned order.
To respect the characteristics of the sales return order, the related CAPcargo functionality differs from the other trading order types. It provides more flexibility at creation and more options for manual adjustment both at creation and during updates. Hence the necessary modifications of the order, that have to happen after the transportation is finished when the goods are received, are allowed and have no impact on the (at this point) already historical transportation data.
On the other hand, the price of such flexibility was that instead of the general order line – load line – shipment lot relation, a new link had to be established on the order header. This also means, that there is always a 1:1 relation between the sales return order header and the CAPcargo shipment / transport order. Furthermore, the lines of the sales return order are only considered by a limited number of processes (e.g. CAPcargo shipment lot quantity record creation when the CAPcargo shipment is generated).

The sales return order based transport orders are integrated into the CAPcargo solution. Information bridges and flows are created – at least when it makes sense for such inbound process – between trade and transportation even when the trading order is a sales return order.

However, some functions are not handled yet:
- packing slip posting: current way of packing slip posting from tour is based on TMS packages, which are not available for sales return orders
- split transport cost/revenue to shipment lot: no golden rule whether miscellaneous charges shall be added to sales return order header or to the everchanging sales return order lines

2020-09Bug50984Customer order management & pricing
Small GUI enhancement of the header section of the transport order line view


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

2020-09Bug72662Dispatching & confirmation
Change management of the carrying resource ULD transactions


Previously introduced ULD transactions (for carrying resource assignment) were lacking a proper update mechanism, which is being corrected by this task. Following update cases are newly being covered:
- When transport order line quantity is adjusted while ULD transaction for this transport order line exists
- When resource assignment on tour is changed (ie. removed) while ULD transaction for this resource exists

In general the following update mechanism is applied:
- The existing ULD transactions are automatically updated when the structure is entirely clear. Eg. when only one ULD transaction exists for the transport order line.
- When the ULD (and transport order line) relation is not entirely clear then the ULD transactions are not automatically updated (but are removed instead, together with removal of carrying resource assignment from the tour order lines) and user is informed accordingly via a new infolog. Eg. when one transport order line is carried by several resources (ie. more ULD transactions exist for the transport order line), or when transport order line was split (via quantity split) during the dispatching process.

The update mechanism is activated automatically, no additional parameterization is needed.

2020-09Bug73665Dispatching & confirmation
Wrong detection of conflict ID 245 (Qualification - restriction for combined loading of address is disobeyed) in some cases


The qualification based conflict ID 245 (Qualification - restriction for combined loading of address is disobeyed) was sometimes being detected by conflict analyzer even when it shouldn't. The issue was corrected, now the conflict ID 245 is detected only when (ie. both conditions must be fulfilled):
- not allowed combination of qualifications is being loaded on single address
- all tour orders are assigned to same carrying resource OR some carrying resource assignment is missing

2020-09Bug73704Dispatching & confirmation
"Default values load-/unload date" parameterization was sometimes not respected during pre-dispatching process


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.

2020-09Bug73707Dispatching & confirmation
Transport leg rough scheduling process was sometimes scheduling an unload on the day when address is closed


TMS address parameterization of "Default business hours" was sometimes not respected during the rough scheduling process. This was especially happening when transport leg points were using a mix of "Default business hours" & "Differing business hours" setup. The issue was corrected, the "Default business hours" are now correctly respected during rough scheduling process, when main TMS parameter "Respect opening days" is activated.

2020-09Bug73742Dispatching & confirmation
"Create new tour" dialog could be avoided by creation of tour via ALT-N keyboard combination


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.

2020-09Bug73759Dispatching & confirmation
Inconsistency in package confirmation when confirming individual packages in tour confirmation


In the tour confirmation form previously there was a certain inconsistency in the package confirmation process, the result was not exactly the same when the confirmation happened from the order level or from the package level. The processes were aligned, now both lead to the same result.

2020-09Bug60541Integrations
Update of the data entity "TAL Trade and Distribution parameter"


Following fields were added to the "TAL Trade and Distribution parameter" data entity:
- Load template ID
- Changing warehouse is allowed

Fields were previously not existing in the data entity, though were accessible in the "Trade and Distribution parameters (module overlapping)" form.

2020-09Bug68655Subcontracting/IC invoicing
Invoice automation flag "Calculate orders first" didn't work properly for Tour sub-contracting orders and for Tour additional costs


Previously the invoice automation flag "Calculate orders first" worked correctly only for Transport leg sub-contracting (LTL) orders, it didn't work properly for Tour sub-contracting orders and for Tour additional costs. This was corrected, now the invoice automation flag "Calculate orders first" calculates all sub-contracting elements.

2020-09Bug73826Subcontracting/IC invoicing
Sub-contracting transport leg (LTL) order was sometimes not created automatically when transport leg was planned into tour which was already sub-contracted


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.

2020-09Data conversion73619Integrations
Data migration job for the task 67651 (New feature: AX Sales return order is supported in the shipment builder)


Data migration job populates the "Shipment building area" field on existing transport orders and transport legs. The shipment building area is an internal field, it is not shown on the forms. Field stores the information whether transport order was generated via shipment building process (and from which D365 trade order type) and is used internally by TMS for several purposes (eg. filtering, queries etc.)
For end user the field can be useful when setting up some advanced filters, or can be added individually to the forms via form personalization.

2020-09Data conversion72638Master data
Data migration job for task 67545 (Enhancement of the dispatching activity setup)


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.

2020-09User Story67743Dispatching & confirmation
Performance improvement of the 'Transport orders /-legs' screen


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".

2020-09User Story69621Dispatching & confirmation
GPB performance driven redesign of the tour refresh in "Resource Dispatching" & "Tour Dispatching" screens


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).

2020-09User Story72474Dispatching & confirmation
New feature: customer pick up at depot & customer delivery into depot - GPB additions


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.

2020-09Bug51261Dispatching & confirmation
Manually specified resource allocation was sometimes not respected when creating a new tour


In the dialog for new tour creation, it is possible to affect the resource assignment for the new tour. But previously the resources manually assigned in this tour creation dialog were in some cases not respected and system just used the fixed resource combination. This was corrected, now system allocates to tour the resources that are specified in the tour creation dialog.

2020-09Bug69748Dispatching & confirmation
Duplicate refresh of level 2 when viewing a tour in GSR (from GST) and viceversa


When switching the tour views between 'Resource Dispatching' and 'Tour Dispatching' screens the level 2 was sometimes refreshed twice. The issue was corrected, now the refresh of level 2 happens only once.

2020-09Bug72695Dispatching & confirmation
ULD transactions were not created automatically when several orders were planned into tour in 'Resource Dispatching' screen


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.

2020-09Issue73943Dispatching & confirmation
KNOWN ISSUE: On the "Transport orders /-legs" screen the menuitem "Remove part delivery" does not work


Via "Remove part delivery" it was possible to physically delete a part delivery transport leg. In current GPB release the menuitem unfortunately works only for users with "System administrator" security role; for users without "System administrator" security role the menuitem doesn't work (ie. button does nothing).
As a temporary workaround - when needed please use the same menuitem "Remove part delivery" on the D365 "Dispatch light - Transport legs" form, there the functionality works correctly.

The issue be fixed in release 10.0.13.0, by task 73930.

Please note:
- The merging of part delivery is not anyhow affected and works correctly in "Transport orders /-legs" screen, the issue is affecting only the removal of part delivery.

2020-11User Story26038Customer order management & pricing
Enhancement of the contract finding & price calculation periodic tasks (all order types)


Previously whenever the user interaction would be requested during contract finding and/or price calculation periodic tasks, then batch process did cancel for this order and proceeded to next order. As user interactions (eg. dialog for overwriting the existing order values by values from the tariffs etc.) are generally not allowed in periodic tasks (which by nature run on the server side, where no user interaction is possible). This mechanism was altered in following way:
- If running as periodic task (ie. batch), the system newly assumes 'Yes' answer to all 'Re-initializing of existing values' questions/dialogs.

Hence the order is not skipped but is processed by periodic tasks (as all values from tariffs are automatically accepted to overwrite the existing values on the order/line).

In specific (very rare) business cases it is possible that different tariffs (used on order line) should initialize/update one order header field by different values (eg. two order lines, each with different tariff that should initialize different 'Rule order collection' to order header), then system uses any of available values. To inform the user about such case a new infolog was added to the periodic task log.

Example of infolog: Out of 2 order lines there were different possible initialization values found for the header field 'CollectionRuleId'. Since not unique and the function called in batch mode (where no user interaction possible), the system initialized the following value: 'SameLoadDate'.

2020-11User Story39329Customer order management & pricing
Enhancement of the work instructions


Existing framework of work instructions was greatly enhanced, to cover more entities and processes.

Key points:
- Introducing work instructions to the TMS Address, which serve as a template for work instruction transactions (that are generated for individual orders)
- Introducing work instructions to D365 trade orders
- Allowing work instructions also for the cross-company business cases (where D365 trade order is in different legal entity than its transport order)
- Introducing a work instruction per tour stop
- Allowing to see work instructions also from the transport legs
- Enhancing work instructions to be used also for Driver App

2020-11User Story56698Customer order management & pricing
Additional logic for 'Use confirmed quantity' parameterization on the tariffs


Previously on tariffs it was possible to activate the usage of confirmed quantity (either from load or from unload) for each tariff quantity calculation. But the feature was limited (either don't use confirmed values at all, or always initialize from confirmed loading quantity, or always initialize from confirmed loading quantity). This was enhanced, now it is possible to further define the usage of the confirmed quantity in more details. New additional parameter 'Confirmed quantity - usage' was added to the tariffs, for each planning unit, with following values:
- None - no additional logic is activated (ie. system either doesn't use the confirmed quantity at all, or always uses the confirmed load or unload quantity).
- Greater - system uses confirmed load (or unload) quantity but only if it is greater than the planned quantity.
- Smaller - system uses confirmed load (or unload) quantity but only if it is smaller than the planned quantity.

All three values still respect the 'Use confirmed quantity' existing parameter.

2020-11User Story59731Customer order management & pricing
Enable the multi-select deletion of the order packages


Previously, in the package management form, it was possible to delete only one single transport order package at once, as the package grid was not enabled for multi-selection. This was enhanced, now it is possible to select multiple packages and delete them at once.
As a consequence of enabling the multi-selection in the package management form, other action menuitems were also adjusted on the form (as for some the multi-selection makes no sense).

2020-11User Story75718Customer order management & pricing
Enhancement of the 'item name' in the package management content, enabling the 'item name' also for standalone transport orders


Previously, in the package management, the item name (in the package content) was only shown when the transport order was originating from D365 trade order (as it was just a display of name from the item/release product). But as TMS supports the usage of package content also for standalone transport orders (ie. that are not originating from D365 trade order), for these cases the field was always empty. This was enhanced and system supports now also the item name (in package content) for standalone transport orders. As a consequence several places needed to be updated accordingly.

Key points:
- 'Item name' was added to the package content EDI composite data entity (both for header package entity and as line package)
- 'Item name' was added to the package content EDI standalone data entity
- 'Item name' was added to the 'Imported transport orders' (and also to 'Checked imported orders')
- 'Item name' was added to the package management content (called from for example transport order, but also other places)
- The display of 'item name' in the package management content was removed, replaced either by display the name from item/released product (for shipment builder cases) or by showing the real imported value (for standalone transport orders).

2020-11User Story51343Dispatching & confirmation
Performance enhancement of the tour confirmation process


The tour confirmation process code logic was improved, to achieve a better user experience. Optimization was done by a code reorganization, as several methods/checks were run too excessively (and in duplicity).

2020-11User Story72542Dispatching & confirmation
Track and Trace: Validation of status message sequence


A validation ensures, that status messages are only sent, if a pre-configured sequence is ensured, e.g. unloading confirmation is not sent before loading confirmation, even though the confirmation data might appear/enter to the back end system in the wrong sequence.
This feature will continue to evolve and improve in later releases.

2020-11User Story73813Dispatching & confirmation
Print item name in loading/unloading list for sales return orders


Previously the SSRS report for loading/unloading list contained the item name but the field was not filled in case of sales return order. This was enhanced and item name is printed in the SSRS reports even for sales return orders.

2020-11User Story75690Dispatching & confirmation
Unification of activity confirmation (ie. swipe off) for activities of type 'Information' in the Driver app


Activities of type 'Information' were previously not possible to confirm in the Driver app. There was no checkbox and the user was not expected / allowed to confirm them. However with the new swipe-based confirmation process in the Driver app (instead of clicking the checkbox) it was unintuitive that these activities couldn't be swiped off the screen. Therefore this was enhanced, the activities of type 'Information' can be now also confirmed (ie. swiped off). The confirmation data / feedback flows back to D365 just like with other activities, but currently doesn't trigger any business logic.

2020-11User Story69588Driver App
Enhancement of the Driver app activity (new rule framework for dynamic activity setup)


Several enhancements of the Driver app (and TMS module), to support following processes:
- New rule framework to provide light 'Instruction' activities - in this release Picture and Signature
- Dynamic activity setup based on Customer, Transport type, SLA
- Tour activity has now new Category field:
- Dispatching (the traditional activities)
- Instruction (from the new framework)
- Execution (from Driver app)

2020-11User Story75701Driver App
Improvement of the internal reference linking between Driver app activity & TMS tour activity


In certain constellation it could happen that the Driver app activity loses it's reference link to TMS tour activity. This could endanger the processing of the confirmation data (feedback) from the Driver app back into the TMS. The reference linking mechanism was thus enhanced by an additional logic, to establish the reference linking (at least for main activities) in case it is not existing.

2020-11User Story67576Integrations
Update transport order (via EDI) is now possible even when original transport order contained external order line numbering


Update transport order (via EDI) was not possible when original transport order (that was imported by EDI) contained external order line numbering. The reason for such behavior was that external order line numbers were discarded during EDI import, as were replaced by TMS standard order line numbering (eg. 10, 20 etc.). This task enhances the EDI logic, the external order line numbers are not anymore discarded but are newly saved on the transport order line (and are used as 'find' criteria for EDI update messages.

Please note:
The important consequence of original limitation is that projects are not able to 'update' multi line transport orders via EDI, if original 'create' message was imported before this task. This is inevitable because before this task the external line numbers from EDI messages were lost during imports, hence the 'update' message cannot find which line to update. And this cannot be covered even by data job. The single line transport orders will be ok, as these are covered via special mechanism.

2020-11User Story73834Integrations
Enabling the usage of 'External codes' in the EDI order import process (for customers & transport units)


Previously due to the platform change (from AX2012 -> D365) the usage of 'External codes' was not working in EDI order import process. This was later enhanced, by enabling the usage of 'External codes' for transport addresses. This tasks enables also the remaining elements - customers & transport units.
So 'External codes' can now be used to map also the customers/transport units 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 from individual customer/transport unit forms.

2020-11User Story73894Integrations
Enhancement of the timestamp of trace & trace status event messages


Previously in the track & trace status event message framework the timestamp for some fields was based on trigger date (of transport leg), which was not sufficient as the timestamp contained only the date component. The logic was enhanced, now the timestamps in the track & trace status event messages also contains a time component.

Please note: for certain statuses the system doesn't have such date & time information available hence a special logic was implemented. These are following:
- Status311 - for timestamps of 'Failed pick-up' messages the system now uses the tour activity confirmation date/time of the LOAD activity of that tour stop where the pickup failed
- Status315 - for timestamps of 'Failed delivery' messages the system now uses the tour activity confirmation date/time of the UNLOAD activity of that tour stop where the pickup failed
- Status430 - for timestamps of 'Delivered by sender' messages the system now uses the tour activity confirmation date/time of the UNLOAD activity of that tour stop where the shipment was delivered by the sender
- Status433 - for timestamps of 'Ready for pick-up by receiver' messages the system now uses the tour activity confirmation date/time of the UNLOAD activity of that tour stop where the shipment is ready for pick-up by the receiver
- Status436 - for timestamps of 'Picked up by receiver' messages the system now uses the tour activity confirmation date/time of the LOAD activity of that tour stop where the shipment was picked up by the receiver

2020-11User Story77571Master data
Renaming the 'Additional tour stop' to 'Tour routing - additional stop'


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

2020-11User Story76543Shipment Builder
New feature: splitting of transport order line per trade order line


A new boolean parameter 'Group per trading order line' was added to the Shipment building group form.
Its logic is following - when the system generates or synchronizes such a transport order, which ‘Group per trading order line’ parameter is activated on the related shipment building group, then the transport order lines shall not only be grouped by the transport unit, but also by the trading order line.
The logic shall be applied on such shipment building areas, that use the line level link between trade and transport (sales, purchase, transfer). On the other hand, the trading order line grouping shall ignore such shipment building areas, that use header level link between trade and transport (sales return order).

2020-11Bug73914Customer order management & pricing
Missing 'checked' OK icon for certain track & trace transport order statuses


In the transport order track & trace status overview it could previously happen that some track & trace status had a timestamp (showing when status was reached) but the status was actually not marked by 'checked' OK icon. This was encountered for example in the 'Ready for pick-up by receiver' status. The behavior was improved and 'checked' OK icon appears correctly when certain track & trace status is fulfilled/reached.

2020-11Bug73916Customer order management & pricing
Wrong infolog 'One or more successor legs were already confirmed' during package confirmation in cross-docking form


In certain parameterization the system warned via infolog 'One or more successor legs were already confirmed' during package confirmation (in the cross-docking form) even though no successor transport legs were actually confirmed. The issue was happening only when parameter 'Promote confirmed quantity to successor planning leg' was activated on the transport type. The issue was corrected and the infolog appears only when it should.

2020-11Bug73924Customer order management & pricing
Missing package unload confirmation, in certain business cases (eg. pickup by receiver)


In certain special business cases (eg. pickup by receiver, package confirmation done on cross-docking form) the confirmation of package unloading did not automatically happen after the package loading was confirmed. The issue was corrected, the confirmation of package loading now also confirms the package unloading in case the transport leg is of type 'no dispatching' and 'receiver pickup'.

2020-11Bug74851Customer order management & pricing
''Concerned vehicle' lookup could not be opened in the Claim Management form


In the Claim Management form the 'Concerned vehicle' lookup was not working, instead of opening the vehicle dropdown the system threw 'Error executing code: Wrong type of argument for conversion function' error. The issue was corrected and 'Concerned vehicle' dropdown opens correctly now.

2020-11Bug76586Customer order management & pricing
Track & trace order statuses 'Delivered by sender' & 'Picked up by receiver' were sometimes registered on wrong transport legs


It certain constellation it could happen that some transport order track & trace statuses were registered on wrong transport legs. The following statuses were corrected:
- Delivered by sender - should be registered on the unload transport leg point (Status430)
- Picked up by receiver - should be registered on the load transport leg point (Status436)

2020-11Bug70653Dispatching & confirmation
Several GUI label corrections in the qualification related forms


Following GUI label corrections were done in the qualification related forms:
- In the tour qualification form the 'Available' field group was renamed to 'Qualifications provided' and the 'Request' field group was renamed to 'Qualifications requested'
- The help labels for qualification validity checkboxes were reworked in the qualification setup form, to better explain the purpose

2020-11Bug72485Dispatching & confirmation
During the removal of not picked shipment lots the system sometimes performed a quantity split


In a certain cases, during removal of not picked shipment lots from the transport leg/tour (from Goods management), the system performed a quantity split of a transport leg. This was especially happening when transport leg contained both entirely not picked and partially picked load lines. The issue was corrected, now the system does not create a quantity split anymore but just removes the not picked shipment lots from shipment.

2020-11Bug72801Dispatching & confirmation
Planning of greater amount of new tour stops into exactly same position in the tour stop sequence could lead to incorrect tour stop structure


When planning a greater amount of new tour stops into exactly same position in the tour could lead to incorrect tour stop sequence. The issue was caused by a limitation in the tour stop sorting mechanism - the system could insert only cca. 35 new tour stops into the same position, the further tour stops were inserted into wrong position. The issue was corrected and the limitation is avoided.

2020-11Bug73639Dispatching & confirmation
D365 trade order details were shown in Driver app only when trade order and transport order were in the same legal entity


Clicking on the load/unload activity in the Driver app opens a new window where further additional details are displayed - eg. from transport order, from original D365 trade order etc. The issue was that the D365 trade order details were displayed only when D365 trade order was in the same legal entity as the transport order. This was corrected, now the D365 trade order details are displayed in the Driver app even when legal entities (of transport order & trade order) differ.

2020-11Bug73901Dispatching & confirmation
Discrepancy in the tour confirmation process - sometimes tour stops were confirmed even though the underlying tour orders were not confirmed


In the tour confirmation process it was possible to achieve a situation when tour stop was confirmed but the underlying elements (eg. tour orders) were not confirmed. The behavior was corrected (by introducing new validation and update mechanism), to ensure that the tour stop is confirmed only when all underlying elements (eg. activities, tour orders) are also confirmed.

2020-11Bug73926Dispatching & confirmation
Duplicate transport leg confirmation, in certain business cases (eg. pickup by receiver, cross-docking form)


In certain special business cases (eg. pickup by receiver, confirmation done on cross-docking form) the 'Confirm transport leg directly' menuitem was available even when the transport legs were already confirmed. The issue was corrected, the menuitem is now not accessible (ie. greyed out) when transport leg is already confirmed.

2020-11Bug73934Dispatching & confirmation
Assignment of carrying resource to transport leg sub-contracting orders was not possible in certain cases


The carrying resource assignment on the tour sometimes didn't fill the carrying resource on transport leg sub-contracting orders and users were facing with an error infolog. The issue was corrected and carrying resource is now assigned also to transport leg sub-contracting orders (if tour & sub-contracting structure allows it).

2020-11Bug73961Dispatching & confirmation
Unification of the legal entity referencing in the Driver app


Previously the legal entity references in Driver app were not handled consistently, in some cases the legal entity was stored in upper case, in some cases in lower case. This was united, the legal entity is newly stored always in upper case in the Driver app tables.

2020-11Bug74846Dispatching & confirmation
Deletion of tour stop on the tour was sometimes not possible


In certain cases the deletion of tour stop from the tour was not possible, the deletion failed with stack trace error. This was especially happening when some resource was already allocated to the tour. The issue was corrected, the tour stop can be deleted unless some resource is starting/ending on the tour stop, or unless some further restrictions are encountered (eg. tour stop is already confirmed etc.)

2020-11Bug76591Dispatching & confirmation
Correction of conflict ID 1244 (Qualification - Missing transport address qualification for trailer)


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).

2020-11Bug77508Dispatching & confirmation
Blocking error in the confirmation of arrival on first tour stop, in tour confirmation


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.

2020-11Bug77537Dispatching & confirmation
Missing load/unload activities for transport orders that were added after the tour was sent to Driver app


Under certain parameterization when adding a new transport order to existing tour stop (of the tour that was already submitted to Driver app), the new load/unload activities were not created. This was especially happening when 'Asynchronous change tracking' Driver app update mechanism was used (ie. TMS main parameters, tab Dispatching, section Tour, parameter 'Change tracking mode' = Asynchronous). The issue was corrected, now the load/unload activities in the Driver app are generated correctly for additionally added transport orders in both change tracking modes.

2020-11Bug77617Dispatching & confirmation
Discrepancy between quantity (of confirmed packages) and the confirmed order quantity, in the tour confirmation process


Previously the transport order quantity related confirmation fields (eg. confirmed transport quantity, confirmed planning quantities) were directly editable in the tour confirmation form even when the transport order had some packages registered. This was corrected, the transport order quantity related confirmation fields are newly editable only when no packages are defined for the transport order. Explanation - in the confirmation process the quantity of transport order (with package management) is actually defined by the confirmed packages. So transport order with package management should be confirmed also via package confirmation only, which then automatically manages also the transport order confirmation quantity fields.

2020-11Bug73907Driver App
Missing Driver app activity link to TMS tour stop when new order was added in TMS to tour (that was already accepted by driver in Driver app)


When adding a new order in TMS to the tour (that was already accepted by driver in Driver app), the newly generated Load activity in the Driver app were lacking the reference to the tour stop. This issue was corrected and the Driver app activities reference to tour stop is established (and maintained) even for these cases.

2020-11Bug74832Driver App
Visualization of the removed tour stops was not optimal in the Driver app


The removal of a tour stop (in D365) on a tour that was already submitted to Driver app was not handled correctly by the change tracking batch job which lead to strange visualization in the Driver app. The issue was corrected, deleted tour stops do not anymore appear in the Driver app.

2020-11Bug73818Integrations
Missing message configuration id on the packages (in track & trace even status message framework)


Previously the message configuration id (used in track & trace event status messages) was inherited only to the transport order but not to its packages. This caused a certain issues when track & trace event messages were later populated for packages. The issue was corrected and the message configuration id is now initialized also to the packages.

2020-11Bug76570Shipment Builder
TMS related menuitems were always enabled in the sales return order list page


On the sales return order list page, the TMS related menuitems (eg. Transport order, CAPcargo Shipments etc.) were always enabled, even when there were no underlying TMS entities existing. This was corrected, the TMS related menuitems on sales return order list page are now enabled only when underlying TMS entities exist.

2020-11Bug76577Shipment Builder
Planning units were sometimes missing in 'Create/Updated transport order' dialog for sales return orders


When using the 'Create/Update transport order' process for sales return orders, the planning units was previously displayed in the 'Create/Update transport order' dialog only when 'Create' process was used (ie. when transport order was being created). In the 'Update' process (ie. when transport order was already existing), the planning units were missing/empty. This was corrected, the planning units are now displayed in the 'Create/Update transport order' dialog for sales return orders in both processes.

2020-11Data conversion76545Integrations
Data migration job for the task 76543 (New feature: splitting of transport order line per trade order line)


The data migration job populates new fields on shipment lot qty and on transport order lines, for existing transactions. Is needed for the new feature of the transport lines splitting per trade order line, to have a correct data structure even for existing transactions.

2020-11Data conversion73964Other / General
Data migration job - to transform the legal entity references for active tours in Driver app to upper case


Data migration job for 73661.

Data migration job updates legal entity references (ie. 'TourCompanyId') to upper case in following tables:
- TALdraTour
- TALdraTourLine
- TALdraTourActivity
- TALdraTourActivityDetails
- TALdraReasonCode

All Driver app tours that are related to an active TAL tours (Released or Confirming) will be re-sent to middleware (Export pending is set to Yes).

2020-11Issue77645Dispatching & confirmation
KNOWN ISSUE: Tour order confirmation does not respect new value in 'Confirmed Qty' unless the record is manually saved first


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).

2020-11User Story56797Dispatching & confirmation
Columns in 'Transport order /-legs' screen are now adjustable & resizable per user


User personalization of GUI elements in 'Transport orders /-legs' screen (eg. column sequence & width) is newly saved per each user, allowing the user to have a constant work experience with GPB.
Column personalization is automatically saved during 'Transport orders /-legs' screen closing.

2020-11User Story67652Dispatching & confirmation
Two shipment builder related enhancements on the 'Transport orders /-legs' screen


Two shipment builder related features were added to the 'Transport orders /-legs' screen:
- Sales return order lines related product description is newly shown in the 'Transport orders /-legs' screen, in the same way as for the other trading order lines (ie. in the 'Products' field box in the 'Overview' tab).
- New filter 'Shipment building area' was added to the same screen, to be able to filter the transport legs via trade order origin (eg. Sales orders, Purchase orders, Transfer orders, non shipment builder orders). Filter supports the multi selection, eg. it is possible to filter sales & purchase order transport legs etc.

2020-11User Story73654Dispatching & confirmation
Enabling work instructions in 'Transport orders /-legs' screen and in both gantt screen tour stops


GPB addition for the 39329 enhancement. Following points were added to the GPB app:
- In both gantt screens - introducing a work instruction per tour stop (accessible in the 'right mouse click' context menu on tour stop)
- In 'Transport orders /-legs' screen - allowing to see work instructions also from the transport legs (can be activated via 'generic buttons' parameterization, by calling a display menuitem 'CIRWMSWorkInstructionTransportLegs' or 'TALWorkInstructionPopupTransportLegs')

2020-11User Story73678Dispatching & confirmation
Enhancement of the new tour creation mechanism


Several enhancements were done in the mechanism of how start/end tour address is determined in the process of creation of a new tour:
- Create new tour manually - the start/end tour address is initialized either from active dispatch sector filter, or from AX Worker parameterization, or from TMS main parameters (as a fallback)
- Create new tour by drag & drop from 'Transport orders /-legs' screen - the start/end tour address is initialized either from active dispatch sector filter (of the 'Transport orders /-legs' screen), or from AX Worker parameterization, or from TMS main parameters (as a fallback)

2020-11User Story73737Dispatching & confirmation
Enhancement of the filters in the 'Transport orders /-legs' screen


Filters in the 'Transport orders /-legs' screen were enhanced, it is newly possible to select by checkbox individual record(s) in the filter dialogs. Multiple selection of individual records is also supported.

2020-11User Story73903Dispatching & confirmation
Editing a tour in GST/GSR newly opens directly the header details view of the 'Dispatch light - tours' screen


Editing a tour in GST/GSR newly opens the header detail view of the 'Dispatch light - tours' screen where users can directly edit the tour details. Previously editing a tour opened only the main grid overview of the tour and users had to switch to header detail view manually.

2020-11User Story73919Dispatching & confirmation
Performance driven enhancement of the of the tour creation logic in the 'Resource Dispatching' screen


The code (which is responsible for the tour creation in the 'Resource Dispatching' screen) was enhanced, for better performance. The enhancement affects several planning methods:
- Drag and drop of transport leg from 'Transport orders /-legs' screen into 'Resource Dispatching' gantt unused space
- Drag and drop of transport leg from map into 'Resource Dispatching' gantt unused space
- Manual creation of the tour in 'Resource Dispatching' screen

2020-11User Story78525Dispatching & confirmation
Two new languages were added to the GPB app


From now on the GPB app includes and supports also the 'de' and 'de-at' languages.

2020-11User Story77411Driver App
Enhancement of the transport activities, new activity types & activity category feature


New categorization feature was added to the transport activities. Each activity now belongs to a certain category. The categories are defined by activity action type and have a different usage in TMS. Following categories were established:
- Dispatching --> contains all previous activities (ie. activity types), used for scheduling in tour dispatching process
- Instruction --> used for informational purposes only, mainly for the Driver app. Contains 4 new activity types - Picture, Signature, Barcode scan (address), Barcode scan (address area). These are not respected in scheduling in tour planning process, are used only to inform about needed activity in Driver app.
- Execution --> used for registering new activities (typically 'out in the field', by the driver). These are used normally for scheduling in tour dispatching process, even though usually only with confirmed values.

Important (for projects who use Driver app):
- Entity list must be refreshed
- The 'TAL Driver app activity feedback' entity inside the corresponding data project must be removed and added again
- These must be done before Driver app middleware is updated to match the new TAL version
- Driver app middleware must be updated before Picture activities are created in TAL

2020-11Bug72467Dispatching & confirmation
Rearranging of tour stops (via drag & drop in gantt screens) was not possible in certain cases


The bug prevented dispatchers from rearranging tour stops in some scenarios - especially (but not only) when the tour stops were not confirmed in the originally planned order. The issue was corrected by enhancement of the drag & drop validation.

2020-11Bug73930Dispatching & confirmation
''Remove part delivery' functionality in 'Transport orders /-legs' screen does not anymore require 'System administrator' security role


Previously the 'Remove part delivery' functionality on 'Transport orders /-legs' screen worked only for users with 'System administration' security role. The issue was corrected, the 'Remove part delivery' can be now used also by users without 'System administration' security role.

2020-11Bug74836Dispatching & confirmation
GPB app client couldn't connect when network connection was routed thru proxy server


Previously the GPB app client in certain network constellation didn't manage to connect to base D365 application. This was especially happening when the connection was routed thru a proxy server.
The GPB app default configuration was enhanced to use the 'signed-in' user’s credentials for proxy authentication. This setting only has impact if the outbound connections are routed through a proxy.

2020-11Bug74856Dispatching & confirmation
Planning the loading after the unloading via drag & drop in the gantt screens


In gantt screens in level 3 it was previously sometimes possible to drag & drop the tour stop (with loading) to position after the tour stop (with unloading). The issue was happening only in gantt screen GUI, the 'wrong' tour stop sequence was actually not saved into database (and was reset back after the GUI was refreshed). The issue was corrected by improving a validation of tour stop sequence management engine, now already the 'drop' action is validated and user is informed via error infolog 'Tour line moving at that position not possible!'.

2020-11Bug75681Dispatching & confirmation
Stack trace error when changing the unload address in 'Transport orders /-legs' screen in certain cases


Menuitem 'Change unload address' on 'Transport orders /-legs' screen in some cases didn't work correctly, users were facing a stack trace error. The behavior was corrected.

2020-11Bug76576Dispatching & confirmation
Several tour related actions were either failing without proper error infolog or were not failing (but tour was not automatically refreshed)


Following tour related actions were improved/corrected:
- Confirm tour directly - missing auto refresh of tour (level 1) when action was successful, missing error infolog when action was not successful
- Close tour - missing auto refresh of tour (level 1) when action was successful
- Undo tour closing - missing auto refresh of tour (level 1) when action was successful

2020-11Bug77395Dispatching & confirmation
Missing labels in the several filter dropdowns in 'Tour Dispatching' screen


Several labels were missing in the filter dropdowns in 'Tour Dispatching' where instead of label the filter dropdown just showed @???. The issue was corrected and proper labels are now displayed. Following filters were affected:
- Early/late arrival
- Early/late customer wish

2020-11Bug77409Dispatching & confirmation
Date filters were not applied during manual filtering in 'Transport orders /-legs' screen


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.

2020-11Bug77674Dispatching & confirmation
The total count of filtered records in 'Transport orders /-legs' screen sometimes was not precise


In certain filter constellations the total count of filtered records in 'Transport orders /-legs' screen sometimes produced unreliable results. The issue was corrected, the total count now corresponds to the filter result.

2020-11Bug78478Dispatching & confirmation
Wrong readability of the address detail 'hover the mouse over' dialog in the map


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.

2020-11Bug78539Dispatching & confirmation
Tour stop overview in both gantt screens (aka. level3) was sometimes not automatically refreshed after certain dispatching actions


After certain dispatching actions in both gantt screen, the tour stop overview (aka. level 3) was sometimes not automatically refreshed and had to be refreshed manually. Following automated tour stop refresh mechanisms were added:
- in 'Tour Dispatching' screen, when transport order was removed from some tour stop
- in 'Resource Dispatching' screen, when Manual ETA was specified by user (via 'pencil' icon on tour stop)
- in 'Resource Dispatching' screen, when tour stop was split (via 'Split' action, in 'right mouse click' content dialog)
- in 'Resource Dispatching' screen, when whole tour was deleted

2020-11Issue78538Dispatching & confirmation
KNOWN ISSUE: Manual tour creation, adding Route/Zone not working


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

2020-12User Story74844Customer invoicing
Posting profile initialization after price calculation not anymore contract finding; impact on manual overwriting


In earlier versions, the posting profile was initialized after the contract finding and BEFORE the price calculation. In manual mode (button price calculation) this makes no big difference, but in batch mode it is important to understand, since the posting profile will only be filled after the [2nd] batch "price calculation". The reason for this change was dependency in inter-company scenarios where orders can be invoiced within sister companies and therefore the posting profile can only be found/validated at the end of the whole calculation process where all order lines were treated first.

One consequence is, that if the posting profile is manually overwritten BEFORE the price calculation has happened (order calc flag = FALSE), the system would overwrite this manual entry again with the init value from the contract. Hence, in case the user wants to have one order differently posted into the ledger, he has to change the posting profile AFTER the price calculation.

2020-12User Story52970Customer order management & pricing
Performance driven enhancement of the contract finding algorithm, in area of tariff zone processing


Performance driven enhancement of the contract finding algorithm, in area of tariff zone processing. Previously, when contract relation was geographically defined via tariff zone, the contract finding performance might suffer as it had to do extensive checks (as some tariff zone might contain quite complex setup - using wildcards, zipcode ranges, excluding certain addresses (or zipcodes) etc). To improve the contract finding performance (and to still benefit from the flexibility of the complex case setup) following enhancements were developed:
- Tariff zone header newly defines whether tariff zone is a simple (or complex) setup. This is done via 'Setup type' flag on the tariff zone header.
- The contract finding then internally reflects the parameterization, without negative performance impact.

2020-12User Story73629Customer order management & pricing
New feature: Silo handling


By introducing the address area entity below the transport address, dedicated locations of the address can be defined in the system. The following characteristics can be defined for the areas: capacities in different transport types, identification codes and types, type of the area (e.g. silo, barn, building), qualifications.
To use the address area in the transportation, first it has to be defined on the transport order line (loading area for the load address and unloading area for the unload address). This can be done manually, by copying transport order, by generating transport order from default order or by the import process. On the other hand, on shipment builder side, by default only the sales return order is supported as the origin of the loading/unloading address area.
During the planning and dispatching process, the address areas are visualized (both in GPB and D365). Furthermore, since they are completely involved in the qualification framework, the system raises conflicts, whenever an incompatibility is identified between the address area and the motoric vehicle / trailer / driver / transport order / transport unit / commodity / transport address / address area.
A new calculation base is implemented, that support all order types: tour stop. By using this calculation base in the price calculation, surcharge can be added, that is based on the number of tour stops, that are related to the order.
A new parameter field is introduced for the surcharges: reduction value. This new parameter supports only such surcharges, that are multiplying the surcharge value based on a calculation base. The intention with the new parameter is, to enable the user to reduce the base quantity (calculated from calculation base) with a predefined value.

2020-12User Story73694Customer order management & pricing
Small GUI enhancement - new infologs when changing the 'driving time & distance' based tariff quantity on order lines


On various order types, when a contract requires the time/distance tariff quantities (and tariff level on order line is 'simple' or 'collect'), the system does not read the time/distance values from the tariff quantity fields on the order line, but reads them from dedicated fields on the order header (or on the collective order header). This was sometimes confusing to user, as he/she changed the driving time or distance in tariff quantity on the order line but it was not effectively used in the price calculation (as the tariff level was 'simple' or 'collect'). This was enhanced by adding two new infologs, when user tries to change driving time & distance tariff quantities on the order line but the tariff level is 'simple' or 'collect', he/she is now informed that such change won't be reflected in the price calculation.

2020-12User Story25810Dispatching & confirmation
New infolog to inform user that Sub-contracting tour order (FTL) was automatically created


Unlike to automatic creation of Sub-contracting transport leg order (LTL) (where user is properly informed by infolog), the automatic creation of Sub-contracting tour order (FTL) didn't previously inform the user anyhow. This was enhanced by this task, now when Sub-contracting tour order (FTL) is created automatically in the background (for example as a consequence of assigning a sub-contracted resource to the tour) the user is informed via new infolog.

2020-12User Story56640Dispatching & confirmation
Redesign of two package related forms, to follow the new package data structure


Following two package related forms were redesigned, to follow the new package data structure:
- 'Package confirmation' form (launched from the tour confirmation form)
- 'Confirmation status' form (launched from the transport order form, from the confirmation action pane, from 'Track and Trace' menuitem group)

Previously both forms were based on temporary table (that had to built upon every form opening), newly both forms read directly from the package date structure (from package tour order lines).

2020-12User Story67634Dispatching & confirmation
Performance optimization of the dispatching process (track & trace event status message asynchronous creation and processing)


Performance optimization of the dispatching process, when transport orders with many packages are being planned into tours (and later confirmed) and system is set up to generate track & trace status messages. Previously the dispatching process was not performing optimally in such business cases, as the track & trace event status messages were generated in the synchronous mode (ie. the dispatching process was waiting till all track & trace status messages were generated). The core of the performance optimization was to introduce an option to create track & trace event status messages in the dispatching process in the asynchronous mode (ie. the track & trace event message creation is not blocking the dispatching process, as it is detached from the dispatching process).

Key characteristics of the enhancement:
- New main TMS dispatching parameter 'Create status messages' was introduced, which defines whether track & trace event messages should be processed in synchronous (ie. previous functionality) or asynchronous (ie. new functionality) mode
- New periodic task 'Create status messages' was introduced (main menu path CAPcargo Transport -> Periodic -> Track and Trace -> Create status messages) which creates the track & trace event status messages if asynchronous mode is used
- New status field 'T&T message status' was added to the events, to support the asynchronous mode. Status field can get two main values - either 'Pending' (ie. event was not yet processed by batch, message is not yet created) or 'Processed' (ie. event was processed by batch, message is either created (or put to waiting queue) depending on sequence validation). In synchronous mode the 'Pending' state is skipped. There exist a third status value 'No message needed' which is used in cases when no messages are needed for the event (due to the system setup).

Important:
Once the 'Create status message' mode is switched to asynchronous, then to ensure that the messages are created/sent, new TMS periodic task 'Create status messages' has to be set up.

2020-12User Story72408Dispatching & confirmation
New feature: Failed pickup


By the introduction of the failed pickup feature, the user is enabled to register such loading attempts, when the entire or part of the planned quantity couldn’t be picked up. Furthermore, the registration of the attempt activates further business processes depending on the failed pickup scenario.
6 failed pickup scenarios are supported:
- Full failed without retry: pickup of the entire order is failed, no new attempt (neither via new order nor via new transport leg) can be created automatically
- Full failed with retry under the same order: pickup of the entire order is failed, new attempt can be registered automatically. New attempt shall use the same references as the original order
- Full failed with retry under a new order: pickup of the entire order is failed, new attempt can be registered automatically. New attempt shall be created under a new transport order
- Partial failed without retry: pickup of the order is partially failed, no new attempt (neither via new order nor via new transport leg) can be created automatically for the remaining quantity
- Partial failed with retry under the same order: pickup of the order is partially failed, new attempt has to be registered automatically. New attempt shall use the same references as the original order, only the planned pickup quantity is less
- Partial failed with retry under a new order: pickup of the order is partially failed, new attempt has to be registered automatically. Picking up the remaining quantity has to happen under a new transport order

Besides doing the necessary adjustments on order and transport leg levels when a failed pickup attempt is registered, all 6 scenarios support track and trace event status messages. Moreover, the cost of failed pickup can be generated for all 6 cases.

2020-12User Story77400Dispatching & confirmation
New conflicts were added to conflict analyser, to support the process of manual planning into compartments


The new process of manual planning into compartments can be used only in the GPB (from both gantt screens), the enhancement is described in the 77402 GPB task.

In D365 following several new conflicts were added to conflict analyser, to support the new compartment planning:
- Conflict ID 170 (Resource – mixing items (released products) in a compartment is not allowed)
- Conflict ID 171 (Resource – mixing commodities in a compartment is not allowed)
- Conflict ID 172 (Resource – mixing transport order lines in a compartment is not allowed)
- Conflict ID 180 (Resource – unequal weight distribution between truck and trailer)
- Conflict ID 610 (Capacity – not enough compartment capacity)

The existing conflict ID 245 (Qualification - restriction for combined loading of address is disobeyed) was enhanced to respect the planning into compartments.

2020-12User Story77437Dispatching & confirmation
Performance driven enhancement of tour dispatching (introducing a simple mode of resource assignment structure)


Enhancement of the resource leg/resource assignment structure, to improve the performance of the tour dispatching. Previously, the resource assignment structure on the tour was 'one resource assignment per each activity of the resource leg', which in case of dozens of activities (for one resource leg) could have a negative performance impact (as all these resource assignments had to be created/read/updated etc.). To improve the performance a new parameter 'Resource assignment calculation mode' was introduced to the main TMS parameters.

Possible values/modes:
- Detail - represents previous functionality of 'one resource assignment per each activity of the resource leg'
- Simple - new (simpler but better performing) functionality of 'one resource assignment per each resource leg'

For existing projects the default value of the 'Resource assignment calculation mode' is 'Detail' to preserve the previous behavior (but can be changed into 'Simple' mode by manual intervention/decision)
For new projects the default value of the 'Resource assignment calculation mode' will be set to 'Simple'.

2020-12User Story77518Dispatching & confirmation
Two scheduling menuitems were added to the tour confirmation form


Two scheduling menuitems 'Rough scheduling (transport legs)' and 'Rough scheduling (tour)' were added to the tour confirmation form. These menuitems were previously available in AX2012 old Dispatching form, but were not migrated to D365.
Menuitems are newly available in tour confirmation process, will be also added to the GPB gantt screens in future releases (ie. for dispatching process). Menuitems in the tour confirmation allow to manually re-calculate the rough scheduling for successor transport legs (that either belong to the same transport order or for all transport legs in the tour). Menuitems represent the manual scheduling update option, the automated scheduling update option is still available (and is recommended more) - it is activated by main TMS parameter 'Reschedule at tour confirmation'.

2020-12User Story78756Dispatching & confirmation
GUI enhancement of the 'Qualifications' overview form (adding the qualification counts to all tab headers)


''Qualifications' overview form (which shows the summary of all detected qualifications for certain entity, eg. tour) was enhanced, to show the qualification counts on all tab headers, so users immediately see for which source there was some qualification detected (and for which not), without having to open each individual tab.

'Qualifications' overview is launched from following places:
- 'Transport order' form
- GPB gantt screens

2020-12User Story78781Dispatching & confirmation
The functionality of 'auto pop-up' of work instructions on the tour was depreciated


In the historical releases long time ago (when the dispatching was done entirely in AX, as no GPB was existing yet), the work instruction feature included the "auto pop-up" functionality, which was automatically popping up an information dialog (with work instructions) whenever the dispatcher opened the tour. The same information dialog could be triggered manually (by "pop-up" menuitems). Then, with the arrival of GPB this feature was unfortunately lost, due to the technology difference. This tasks removes these "pop-up" menuitems (and related parameterization) as depreciated.

2020-12User Story76540Driver App
Enhancement of the TMS address and transport order - introducing a barcode scanning for address area (eg. shelf)


TMS address was enhanced to allow the specification of address area (eg. shelf), incl. the definition of a barcode (which will identify the address area). Address area specification was also added to the transport order header (both for load & unload address) to be able to define from/to which address area (eg. shelf) the goods should be loaded/unloaded.
New activity was added to the driver app, that allows the drivers to scan (or type in manually) the address area barcode in location, which is validated against address area master data barcode in TMS.

Additionally the data entities (for transport order import and export) were enhanced, to include the address area fields.

2020-12User Story76541Driver App
Enhancement of the TMS address - introducing a barcode scanning


TMS address was enhanced to allow the specification of a barcode (which will identify the address).
New activity was added to the driver app, that allows the drivers to scan (or type in manually) the address barcode in location, which is validated against TMS address master data barcode.

2020-12User Story78584Integrations
Redesign of Track & Trace status message sequence validation


The sequence handling of the Track & trace event status messages was re-worked, to be able to deliver the event status messages in the chronological sequence (even though the events were not registered chronologically in D365). The sequence was previously managed via static sequence parameterization (on message group), newly the sequence is determined dynamically - by the structure of the tour confirmation. So when new message is created, system newly checks whether predecessor event is confirmed - if yes then message can be sent out, if not then message is not sent out but is put to the waiting queue.
The whole sequence handling logic is activated by 'Sequence validation' parameter on the message group.

Important:
When 'Sequence validation' is activated, the in order to ensure that waiting event status messages get active when predecessor event is confirmed, a new periodic task must be set up, under following path: CAPcargo Transport -> Periodic -> Track and Trace -> Process messages in waiting status (Seq.Val.)

2020-12User Story64471Master data
Infolog improvement when TMS address is deleted


When the TMS address is deleted and user chooses also to delete the linked D365 address, user is then informed via two infologs about the deletion result (ie. one infolog for the TMS address deletion, second infolog for D365 address deletion). Previously both infologs contained only the details of TMS address. Newly the D365 address deletion infolog contains the D365 address details (eg. address name, city (and location id)).

2020-12User Story78809Master data
GUI enhancement of the 'Administration external code' form


Two small enhancement were done in the 'Administration external code' form:
- 'Customer name' column was added to the 'Customer' fasttab grid (previously the grid contained only 'Customer account', which is a field generated from number sequence, with very limited information value)
- Fasttab 'Client' was renamed to 'Customer', to be consistent with other D365/TMS forms

2020-12User Story26688Other / General
Removal of the main TMS service parameter 'Search service level agreement at order creation'


The main TMS parameter 'Search service level agreement at order creation' (located in the Services section) was removed as obsolete. The parameter only activated the default initialization of the same parameter 'Search service level agreement at order creation' that is located in the transport type (which effectively activates the 'Search service level agreement at order creation' functionality). As the transport type creation is a setup task, it doesn't need any parameterization for default field initialization. The transport type parameter 'Search service level agreement at order creation' is thus newly initialized as "false" and main TMS parameter 'Search service level agreement at order creation' is removed.

2020-12User Story73778Other / General
New report "User License Count History" was added to the system


New TMS report "User License Count History" was added to the system. The report populates the historical daily count of following license types:
- Operations Licenses
- Team Members Licenses
- Activity Licenses

Main menu path:
CAPcargo Transport –> Reports –> Licensing –> User License Count History

2020-12User Story78966Other / General
Removal of the empty role 'T&L Warehouse Planner"


In previous versions the security configuration of the role 'T&L Warehouse Planner' was merged into 'T&L Warehouse Worker' role but the 'T&L Warehouse Planner' was not physically deleted. This is corrected by this task, the 'T&L Warehouse Planner' security role (which is empty) was also removed.

2020-12User Story78817Shipment Builder
Small GUI label enhancement in the TMS shipment form


Previously, in the TMS shipment form, the loading/unload time windows were a bit confusing, as the same 'Time' label was reused several times. This was enhanced, fields are now labelled as 'From' or 'Till', including the proper help text.

2020-12Bug73633Customer order management & pricing
Failing to specify some mandatory fields during transport order creation could lead to the loss of transport order


Failing to specify some mandatory field (eg. load/unload address) in the transport order create dialog could lead to the loss of transport order (that is being created). The issue was happening because certain validations for mandatory field were triggered only after the dialog (for new order creation) was closed and thus all previously entered data were lost. This was enhanced, the validations for mandatory fields are now triggered already in the dialog for new order creation, hence the users can still correct the missing/wrong fields during the transport order creation process.

2020-12Bug73683Customer order management & pricing
Empty invoice account on the transport order


Previously, it was possible to have a transport order without an invoice account. As the invoice account is mandatory for the invoicing process, it becomes newly a mandatory field already in the transport order.

2020-12Bug77416Customer order management & pricing
Surcharge amounts in the order calculation were sometimes shown without decimals


In certain constellations the surcharge related amounts were shown in the order header totals (and in price calculation details) without decimal places. The issue was happening only on the form/display level; the real database values (which were used for invoicing) were correct. The issue was corrected, the surcharges are now displayed with correct decimal places.

2020-12Bug78747Customer order management & pricing
Transport orders without load/unload address


Under certain circumstance it was possible to delete a load (or unload) address from the transport order, which caused an inconsistency and could lead to unforeseen consequences (as these orders could also be sent to dispatching). This was happening when users were trying to change load/unload address (via dedicated menuitems on the transport order form) but didn't specify any address in the "Change load/unload address" dialogs. The issue was corrected, the address is now mandatory in the "Change load/unload address" dialogs.

2020-12Bug78838Customer order management & pricing
When creating a new sales return order, it was not possible to select a shipping address from the global address book


Previously, when registering a new sales return order, the shipping address validation was done in a way that it prevented the selection of the shipping address from the global address book in the sales return order creation dialog. The issue was corrected and the validation of shipping address was moved to the dialog closing, to allow the shipping address selection (from global address book).

2020-12Bug72628Dispatching & confirmation
Conflict analysis sometimes didn't open in several TMS forms


Previously, when there were no conflicts detected for certain elements (eg. transport legs etc.) then the conflict analysis overview form didn't open. This was confusing as users were getting impression that the conflict analysis menuitem doesn't work.
Also the behavior of conflict analysis menuitem was not entirely consistent across TMS forms, as sometimes the conflict analysis overview actually was opened (but the overview was empty).
This was enhanced - by introducing an additional infolog "No conflicts detected." and by unification of menuitem behavior in all TMS forms.

The behavior is following:
- When Conflict analysis menuitem is pressed and no conflicts are detected/existing, then the conflict analysis overview is not opened and user is informed via new infolog.
- When Conflict analysis menuitem is pressed and some conflicts are detected/existing, then the conflict analysis overview is opened.

2020-12Bug73692Dispatching & confirmation
Several labels were missing in the 'Direct order-to-vehicle dispatching' form


Missing labels were corrected/added.

2020-12Bug73764Dispatching & confirmation
Undo of the package confirmation was not respected correctly in some TMS processes


Previously the undo of the package confirmation (when performed in the tour confirmation form) sometimes didn't reset the package confirmation, causing certain issues in several processes (which were wrongly treating the packages as "fully confirmed"). The issue was corrected.

2020-12Bug78654Dispatching & confirmation
Price simulation on tour sometimes failed with stack trace error


In certain cases the price simulation functionality on the tour didn't finish correctly but ended with stack trace error. This was especially happening when the price simulation was launched with activated parameter 'Simulate effect on existing tour costs'. The issue was corrected and stack trace error is avoided.

2020-12Bug78668Dispatching & confirmation
Conflict analyser error 'Object reference not set to instance of an object' on some TMS installations


In certain TMS installations it could happen that the conflict analyser correctly detected the conflicts but also threw an error 'Object reference not set to instance of an object'. The issue was happening only for certain combinations of license configuration keys.
The conflict analyser form was enhanced, to correctly show the conflict references even when 'Shipment builder (based on WHSLoadLine)' license configuration key is not activated.

2020-12Bug78705Dispatching & confirmation
Conflicts 301 & 303 were wrongly triggered for some dispatching cases


For certain dispatching cases, it could happen that the conflict analysis reported Conflict 301 or 303 even when there was no reason for such conflicts. The issue was happening especially when transport order was split into several transport legs (as the conflict analyser validated even the loading/unloading of the depot leg points). The issue was corrected and both 301 & 303 conflicts are triggered only on the transport leg points that representing the original transport order load/unload.

2020-12Bug78840Dispatching & confirmation
Work instructions of the sales return orders were previously not shown on transport legs & tours


Work instructions of the sales return orders were previously not shown in the work instruction overviews of the transport leg & tours. The issue was corrected and work instructions of the sales return orders are now included when work instruction overview is launched from transport leg & tours.

2020-12Bug79288Dispatching & confirmation
During transport order cancellation (when triggered from the failed delivery) a wrong final leg could have been deleted


During the transport order cancellation (when triggered from the failed delivery), in certain situations the final delivery transport leg is physically removed. A potential weakness was identified in the responsible code, which could lead to a deletion of the final transport leg (of different quantity path). This could happen for example when the transport leg was split into two delivery quantity paths, and only the one path was registered for failed delivery. The code was enhanced and the system removes only the last transport leg of the same quantity path.

2020-12Bug79290Dispatching & confirmation
Change of order confirmation quantity was sometimes not possible in the tour confirmation form


The possibility to change the order confirmation quantity in the tour confirmation form is managed via package structure. When transport order contains some packages then its confirmation quantity cannot be directly changed (ie. confirmation quantity fields are locked), as the confirmation quantities are defined by the confirmation on the package level.
The issue was that the field locking mechanism was not working correctly in certain business cases, especially when several transport orders (with & without packages) were planned into the same tour/tour stop. The field locking mechanism was corrected - it respects now only the package structure of the active transport order.

2020-12Bug69704Integrations
Transport order with address (with some unregistered zipcode) failed to import


Previously, when some transport order contained an address with a zipcode (that was not previously registered in D365 zipcode table), then the order import failed already during the import into D365 and such orders were not admitted into Imported (and Checked imported) order tables. This was enhanced, now the import process itself doesn't validate the existence of the zipcode (against the D365 zipcode table) and such orders are admitted into Imported transport orders and the validation is applied only during error checking process in the Checked imported order form, where users see such failed cases and correct them (either by registering a new zipcode into D365 zipcode master data table, or by selecting some other valid zipcode).

2020-12Bug78536Integrations
''Send message' parameterization was available in the 'Parameter Track and Trace status' form even when the messaging feature was not activated


The 'Send message' parameterization was available in the 'Parameter Track and Trace status' form even when the main feature configuration key 'Message framework' was not activated. The issue was corrected and the 'Send message' parameterization is available only when 'Message framework' configuration key is activated.

2020-12Bug72350Master data
Copy of the vehicle (that was not linked to D365 resource) created an supported resource structure


Previously, it was possible to copy a vehicle (that was not linked to D365 resource). The result was an unsupported resource structure (ie. some resource was automatically created for the copied vehicle, but resource was not showing in the D365 Resource form). As the vehicle (without a link to D365 resource) cannot be actively used in the TMS, we have also disabled the copy feature. So the copying of the vehicle is newly allowed only for complete vehicles (ie. that are linked to some D365 resource)

2020-12Bug72609Master data
Default filters were not working on the contract version & relation forms

2020-12Bug73607Master data
It was possible to define on worker even the invalid qualifications

2020-12Bug78712Master data
Missing validation of transport unit (and planning/tariff units) in several forms

2020-12Bug78874Master data
Users could override the address reference when registering a new work instruction template on the TMS address

2020-12Bug79009Master data
Correction of two bugs in the area of new compartment registration

2020-12Bug79038Master data
Wrong German translation of 'Load' enum value (of the 'Load code' enum)

2020-12Bug78691Other / General
TMS Dutch labels were sometimes showing wrong special characters

2020-12Bug79029Other / General
''T&L Sales clerk" and "T&L Warehouse worker" security roles required a license type of 'Full user'

2020-12Bug78561Subcontracting/IC order management & pricing
Carrying resource was sometimes not updated on the Sub-contracting transport leg (LTL) order line

2020-12Data conversion78808Master data
Data migration job for 52970 task - to initialize the 'Setup type' classification on tariff zone header

2020-12Data conversion78720Other / General
Data migration job - to fill the empty invoice account on transport orders

2020-12User Story32045Dispatching & confirmation
Default date (of the 'Manual date' mode in 'Resources' screen) is now initialized to today's date


When switching the 'Resources' screen to 'Manual date' mode, the default date was previously initialized to '01-01-0001'. The initialization mechanism was enhanced, the default date is now initialized to today's date.

2020-12User Story73631Dispatching & confirmation
GPB addition of the 73629 task (Silo handling)


GPB was enhanced in the way to support the new feature of silo handling.
Following enhancements were added to the GPB:
- Visualization of address area details in the 'Transport orders /-legs' screen
- Visualization of address area details in the both gantt screenc, incl. new icon the tour stop box

2020-12User Story76560Dispatching & confirmation
Two search/filter related enhancements of the 'Transport orders /-legs' screen


Following points were improved, in the 'Transport orders /-legs' screen:
- The full-text search (launched by CTRL+F) newly searches through the whole filtered scope (previously the search was performed only in the filter scope that was currently loaded in the grid). So now it is possible to search even for results (that are occurring for example in the 3rd filter screen) already from the 1st filter screen.
- Closing (and re-opening) the load/unload date filter dialog now remembers the original date scope, so it is possible to activate/deactivate additional individual date filtering without performing the full refresh of the 'Transport orders /-legs' screen.

2020-12User Story77402Dispatching & confirmation
Enhancement of the carrying resource assignment form, to support the manual planning into compartments


Previously, via carrying resource assignment form (launched from both gantt GPB screens), it was possible to plan orders into individual carrying resources. The carrying resource assignment form was enhanced, to newly allow the planning of orders into individual compartments of the carrying resource.

Key characteristics of the compartment level assignment:
- Scope of the displayed records is always the tour stop.
- All compartments are shown, that have capacity record defined in the transport type of the tour stop.
- Multiselect is enabled (to allow the planning of one order into multiple compartments, and to allow the planning of multiple orders into one compartment (or even into many compartments).
- Assignment records are shown on compartment level (right side grid) if compartment level assignment happened
- New capacity utilization menuitem was introduces (launched from context menu of tour stop), which shows the capacity utilization per compartment.

2020-12User Story78799Dispatching & confirmation
Performance optimization of filtering in the 'Transport orders /-legs' screen


The filtering in the 'Transport orders /-legs' screen was in previous releases enhanced by 'paging' feature - when more records are to be filtered then the result is loaded to the screen in different sets (aka. 'pages'). The user is informed that for example only 20 records (out of total 98 records) are loaded/displayed. There were some performance issues detected in this mechanism - with greater amount of 'total' records the loading time (even for first set/page) was rising. The filtering mechanism was enhanced, by splitting the 'total' record count processing into separate background service (which is loaded independently in the background, not slowing down the user experience). Users can experience better performing filtering in the 'Transport orders /-legs' screen and can newly observe that the 'loaded' record count (eg. 20) is displayed in the first step (incl. the showing the 20 records in the grid), while the 'total' record count is calculated with some delay (via background service).

2020-12User Story79249Dispatching & confirmation
''Shipment building area' was added to the D365 Worker default filters


Default filters (on the D365 Worker) were enhanced, to newly contain also the default filter for the 'Shipment building area'. Once 'Shipment building area' default filter is specified, it is then initialized to the 'Transport orders /-legs' screen.

2020-12Bug78541Dispatching & confirmation
Loss of resource assignment after 'drag and drop' of multi-selected resources in the 'Resource Dispatching' screen


Previously, it was allowed to select multiple resource assignments (ie. gantt bars) in the 'Resource Dispatching' screen and do the mass tour re-planning (by 'drag and drop') into different date & time. This was causing an issue in certain cases as the same 'drag and drop' action is used for resource change (ie. 'drag and drop' of gantt bar from one resource into another). To avoid such issue the 'drag and drop' of multiple(!) resource assignments is newly blocked in the 'Resource Dispatching' screen entirely. When dispatchers need to re-plan multiple tours, it has to be done one by one.

2020-12Bug78558Dispatching & confirmation
Menuitem to print a pallet docket report was added to the GPB screens


Previously it was possible to print a pallet docket report only from the D365 'Dispatch light - Tours' form, the menuitem was entirely missing in the GPB. The menuitem "Pallet docket" was added to both GPB gantt screens, hence the users do not need to switch anymore to D365 for the pallet docket report creation.

2020-12Bug78706Dispatching & confirmation
In the 'Resource Dispatching" the tour gantt bar was sometimes not automatically refreshed after certain dispatching actions


After certain dispatching actions the tour gantt bar was sometimes not automatically refreshed in the 'Resource Dispatching' screen. The issue was happening for example when dispatchers manually removed the Manual ETA from the individual tour stop. The issue was corrected and tour gantt bar is now automatically refreshed in the 'Resource Dispatching' screen.

2020-12Bug78709Dispatching & confirmation
Graphical visualization of the capacity on the tour stop was sometimes not correct


The capacity visualization on the tour stop (aka. vertical capacity bar) was not working correctly in certain cases. The issue was happening only in the vertical capacity bar visualization; the 'hover the mouse over' of the capacity utilization percentage (eg. 83%) was correct, as well as the 'hover the mouse over' capacity utilization dialog with details. The issue was corrected, the vertical capacity bar on the tour stop shows the correct visualization now.

2020-12Bug78753Dispatching & confirmation
In several dispatching processes the tour was sometimes not automatically focused/selected in the 'Tour Dispatching' GPB screen


Several issues were corrected in the tour creation processes:
- Previously, in certain cases, the newly created tour was not automatically focused/selected in the 'Tour Dispatching' screen. This was especially happening when the new tour didn't fit into active filters on the 'Tour Dispatching' screen. The issue was corrected, now the newly tour is always focused/selected in the 'Tour Dispatching' screen even when it doesn't fit into active filters.
- The menuitem 'GPB - Tour Dispatching' (for opening a tour in GPB, from D365 'Dispatch light - Tours' form) was only available to users with 'System administrator' role.
- On several dispatching processes (and dialogs) for adding transport order/legs into tour, the checkbox "Go to tour (GPB)" previously didn't sometimes focused/selected the tour in 'Tour Dispatching' GPB screen.

2020-12Bug78875Dispatching & confirmation
Sales return order transport legs were sometimes not shown in the 'Transport orders /-legs' screen


Sales return order transport legs were sometimes not shown in the 'Transport orders /-legs' screen. This was especially happening when a certain default filter combination was specified on the D365 worker (which was linked to the D365 user). The issue was corrected and sales return order transport legs are shown in the 'Transport orders /-legs' even for users that have some default filters specified on the D365 worker.

2020-12Bug78907Dispatching & confirmation
Wrong label additions in the column titles of the generic fields in the 'Transport orders /-legs' screen


When some custom/generic field was added to the 'Transport orders /-legs' screen, its label got a suffix (with the field count).
So adding a 'Leg reference' & 'Leg note' to the custom/generic fields resulted into ''Leg reference1' & 'Leg note2' in the column titles in the 'Transport orders /-legs' screen. The issue was corrected and field count suffix was supressed.

2020-12Bug79138Dispatching & confirmation
Tour stop details were sometimes not loaded after changing the tour start (by 'drag and drop' of the whole tour) in 'Resource Dispatching' screen


When changing the tour start (by 'drag and drop' of the whole tour) in 'Resource Dispatching' screen, the tour stop details (aka. level 3) were sometimes not loaded and users just saw the 'Loading data' spinning icon. The issue was corrected, the tour stop details are now loaded properly after the 'drag and drop' of the tour, even on the 'Resource Dispatching' screen.

2020-12Bug79340Dispatching & confirmation
Message history could not be opened from the tour stop details (in both gantt screens)


The 'View message history' functionality (which can be launched from the 'right mouse click' context menu of the tour stop detail, in both gantt screens) previously always failed to open. The issue was corrected and the form opens properly now.

2021-02User Story57668Customer invoicing
New validation to prevent duplicate customer invoicing


New validation was added to the customer invoicing process, to avoid (rather hypothetical) cases of duplicate invoicing, which could theoretically happen when several automated customer invoicing periodic tasks were run against the same transport order scope, on several batch servers.
New validation checks whether invoice already exists for transport order (and if so then the duplicate invoicing is not done). The validation is by default active but can be deactivated in main TMS parameters (in section 'Invoice', flag 'Deactivate customer invoicing corrupt data check').

2021-02User Story77456Customer invoicing
''Invoice responsible company' is newly a mandatory field, on transport order & part-invoice order, when intercompany is activated


As the field 'Invoice responsible company' is crucial for intercompany invoicing, the field is filled (and updated) on relevant order types automatically by the system, when intercompany configuration key is activated. The issue previously was that the field value could be manually deleted by user in the forms, which caused problems later during invoice posting. Newly, on the applications with intercompany configuration key activated, the 'Invoice responsible company' field is treated as mandatory and cannot be cleared.

2021-02User Story77654Customer invoicing
New feature 'Customer self-billing' was added


With this task a support for customer self-billing process is introduced in CAPcargo Transport. This is sometimes also referred to as ‘Recipient Created Tax Invoices (RCTI)' or ‘Gutschriftverfahren’ (in German language).
In this business process it’s the customer who sends the transportation company the billing proposal for a transport invoice instead of the transport company sending the customer the transport invoice. With the help of a data entity the billing proposal can be imported. After that it can be automatically matched against transport orders and the calculated amounts are verified against the billing proposal values. When the billing proposal has been completely matched an invoice is created with only the transport orders that were on the billing proposal.

2021-02User Story65756Customer order management & pricing
Rule order collection is newly initialized already in the contract finding process


Previously the initialization of 'Rule order collection' from tariffs to order header happened only during the price calculation process, hence the initial price calculation was a mandatory prerequisite for the order collection. To improve an order collection performance (as such initial price calculation is not effectively needed, it is only needed for 'Rule order collection' initialization), the 'Rule order collection' is newly initialized to order header already during the contract finding process (as one the last steps of the contract finding).

This allows to skip the initial price calculation step in the fully automated collection process, so the following periodic task structure is sufficient:
- Contract finding task (initializes 'Rule order collection' to order header)
- Order collection task (forms the order collection, based on previously initialized 'Rule order collection')
- Price calculation task (calculates the price of the transport order)

2021-02User Story72455Customer order management & pricing
New track & trace status: 'Failed pick-up'


As the 'failed delivery' process already had its own track & trace status, the status for 'failed pick-up' (Status312 'Failed pick-up') was also added to the track & trace framework.

2021-02User Story73676Customer order management & pricing
Additional/alternative source for order driving distance & time calculation


Previously, on transport order (and on other order types) it was possible to calculate the driving distance & time only from the PTV map component. This was enhanced - now it is possible to determine the driving distance & time either from the map component or from internal distance table or from the combination of both. The parameterization of which method shall be used is done on the transport type, in new section 'Distance and time calculation'.
The functionality can help in the projects where nonstandard addresses are used (ie. that cannot be calculated by the map component), or some custom negotiated driving distances & times are used (ie. that differs to the map component data).

This task also removes the “Default Distance Determination”functionality (which could calculate the driving distance & time from the internal distance table during transport order creation) as depreciated.

Limitation:
The enhancement can be used only for the calculation of driving distance & time on various order types; it cannot be used for the calculation of driving distance & time on the tour between tour stop (there still the map component is the only source, beside the manual entry).

2021-02User Story77511Customer order management & pricing
Several GUI enhancements of the 'Re-initializing of existing values' dialog, in the contract finding process


In the contract finding process, when tariffs shall initialize some fields to the order header (but these fields already have a different value in the order header), a 'Re-initializing of existing values' dialog (aka. 'decision making' dialog) is invoked where user has to select which fields shall be initialized/overwritten on transport order and which not. GUI of the dialog was improved, in following way:
- 'Update' flag was moved to the third column
- The record 'hiding' mechanism was improved (ie. when user selects a value from one order line, only other order lines (with the same field) are hidden).
- Whole dialog grid was horizontally expanded, for better grid readability

2021-02User Story78624Customer order management & pricing
Change of quantity was not possible on transport order line in certain scenarios


When trying to change quantity on transport order line (where some other transport order line of the same order already had a quantity split on its transport legs) then the change of quantity failed with error 'Action not allowed! Order is already [partially] in a tour which is already released or confirmed.'. The issue was corrected and the error is shown only when the quantity change happens on the transport order line that already has some quantity split on its transport legs.

2021-02User Story78942Customer order management & pricing
''Distance and time calculation' can be newly used also for multiple selected orders


Previously it was possible to launch 'Distance and time calculation' only for single selected order. This task enables the multiselect of the orders, allowing users to calculate driving distance and time for multiple orders at once.

Following forms were enhanced:
- All transport orders
- Cross-company transport orders
- Transport pre-orders
- Part-invoice orders
- Intercompany order

2021-02User Story78948Customer order management & pricing
Deprecate feature 'Transport order header linked packages'


Feature 'Transport order header linked packages' (which was previously existing in the transport order) was removed as obsolete. Feature had several weaknesses (these packages couldn't be displayed in the transport leg forms when transport order had more lines; also were not respected properly in the quantity split dispatching scenarios; couldn't be used for ULD processing; had certain issues in the package tour confirmation etc.).
As the functionality was not used in the productive TAL applications, it was deprecated and removed.
From now on, it is only possible to handle packages that have a clear reference to some transport order line.

2021-02User Story78992Customer order management & pricing
GUI enhancement of the filtering sidebars in 'Checked imported order' & 'Imported transport order' forms


Previously the filtering sidebars in the 'Checked imported order' & 'Imported transport order' forms were slightly distorted (eg. showing too much information, the spacing between orders was suboptimal etc.). This task unifies both filtering sidebars in both EDI forms. Now both filtering sidebars have the same GUI as on transport order form.

2021-02User Story79041Customer order management & pricing
Conflict management was enhanced to Conflict analysis, in the Resource assignment form


Previously, on Resource assignment form (that can be launched form transport order form) a menuitem Conflict management just opened the overview of previously detected conflicts. The menuitem was transformed (and renamed) into Conflict analysis, so once clicked it newly also automatically performs the conflict analysis (to detect the new conflicts and to retest previously detected conflicts).

2021-02User Story79100Customer order management & pricing
New warning infolog when posting profile is not suitable for the current customer/vendor account


When posting profile is being determined (eg. during price calculation etc.) system newly reports when some posting profile was found (but discarded) because it was not suitable for current customer/vendor account. Newly, the user is informed about such cases via warning 'The found posting profile XYZ has no valid lines for Customer-Vendor-ABC' (where the XYZ shows the exact posting profile and Customer-Vendor-ABC shows the exact customer or vendor account).

2021-02User Story79563Customer order management & pricing
Deprecate field 'Order closed with issue' on transport order header


Field 'Order closed with issue' (which was previously existing in the transport order header and in the dialog for manual status message creation) was removed as obsolete. Field was not actively used in the TAL functionality (was only a GUI fragment of some project specific development that was not admitted into TAL).

2021-02User Story79986Customer order management & pricing
Removal of unit conversion from the tariff surcharge criteria logic


Via tariff surcharge criteria it is possible to define when the tariff surcharges should be applied during price calculation, eg. when planning quantity is over 10 load meters etc. Previously, system also applied the unit conversion, when testing the surcharge criteria. So if the planning quantity on transport order was for example defined in square meters (and there was a conversion rule defined between square meters and load meters), then such tariff surcharge could get applied.
This caused quite confusion as it was not easily understandable why the tariff surcharge (with certain unit criteria) was applied when the amount of the same unit was not sufficient on the order line (but the tariff surcharge was applied because thru the conversion rule the sufficient amount was converted from some other unit). Hence the conversion logic was supressed when the price calculation checks for tariff surcharge criteria.

2021-02User Story48477Dispatching & confirmation
Performance improvement of the transport leg & tour planning engine (when transport legs are planned into tours / removed from tours)


Several performance driven code enhancements were done to the engine that is responsible for planning of transport legs into tour and for removal of transport legs from the tour. The functionality itself should stay the same, just with better performance.

2021-02User Story54299Dispatching & confirmation
Performance enhancement of the GPB 'Resources' screen


Several performance related optimizations were done on the GPB 'Resources' screen, to improve the users GUI experience when working with the screen. The optimizations were done in the code structure (and in underlying technology) level, without functionality change of the 'Resources' screen.

2021-02User Story64611Dispatching & confirmation
Small visual enhancement in GPB, when tours (which are overlapping for individual resource) are delayed


In GPB 'Resource Dispatching' screen, when the tours are delayed, a 'red bar' visualization is shown in the gantt. But in case when more tours (which were overlapping for individual resource) were delayed, the 'red bar' visualization was hardly visible/readable, due to the visualization of the overlapping tours. This was enhanced and the delay of the overlapping tours is newly highlighted by an additional red line.

2021-02User Story67715Dispatching & confirmation
Enhancement of the customer wish 'early/late' visualization in GPB gantt screens (respect address business opening hours)


The visualization of customer wish 'early/delay' in level 1 tour gantt bars, (aka. the red/green bars) could previously give only a rough overview when no customer wished timeslot was specified on the transport order header (ie. customer wish was specified only on the 'date' level, but not on the 'hours:minutes' level), as no exact 'wished' time was known.
The visualization (and the 'early/delay' determination) was enhanced in this task, newly the system takes into account also the business opening hours of the unload address, but only when no exact customer wish timeslot is specified on transport order header. When determining the business opening hours the system uses the usual 'hierarchical' structure (ie. opening hours can be defined on the TMS address itself, or on address calendar, or on country calendar etc.) and uses the latest opening hours timeslot on the address for customer wished day).
For the cases when customer wish is specified on the unload address of the transport order header with maximum details (ie. including the 'hours:minutes' timeslot, then these are still used (and business opening hours on address are ignored).
This allows better precision in the 'early/late' tour visualization in tour gantt screens when customer wish is defined only on the 'date' level.

2021-02User Story72786Dispatching & confirmation
Missing confirmation dialog in GPB 'Resource Dispatching' screen, when merging tour stops that have some manual ETA specified


In GPB 'Tour Dispatching' screen, when merging tour stops that have some manual ETA specified, a confirmation dialog is shown where user has to confirm that the merge of tour stops shall really happen (as the merging will delete the existing manual ETA). But in 'Resource dispatching' screen such confirmation dialog was previously missing (and the tour stops were immediately merged, with manual ETA being deleted). This task enhances the 'Resource Dispatching' screen, to populate the same confirmation dialog (as is already existing in the 'Tour Dispatching' screen).

2021-02User Story76529Dispatching & confirmation
New feature: cleaning framework and truck loading history


A new framework isintroduced, that is responsible for warning the user when, where and which carryingresource needs to be cleaned. Furthermore, based on the mode of the cleaning,additional costs can be added to the tour.

Prerequisites of using thecleaning determination logic are:
- the setup of the cleaningtype, that defines the way of cleaning and the efficiency of it
- the setup of the cleaningmatrix, that contains the rules which determine what type of cleaning is necessaryif a certain commodity was carried by the vehicle/compartment prior the currentload

The aim of the logic is todetermine what type of cleaning has to be done before loading goods intovehicle or compartment. This cleaning type is returned on the one hand to theconflict management (where it triggers a conflict), on the other hand to anew form, that gives information to the user about the necessity of cleaningand provides a semi-automatic way of inserting cleaning activity/activities.
Regardless of which tool is used,the goal is to insert cleaning activity/activities with the right cleaningtype into existing or new cleaning specific tour stops. Such activities are notonly the indicators for the driver (that cleaning has to be done at pre-definedlocations), but they are also used for the creation of tour additional costsautomatically at the confirmation of the cleaning activity.

As an overview for the useralso a new form is introduced, the Truck loading history. Via this form, thesystem grants always up-to-date information for the user, what activitieshappened with which vehicle. It depends on a new parameter of the activitymaster data, whether the activity is shown in the Truck loading history.

2021-02User Story77611Dispatching & confirmation
ETA of tour stop is not anymore overwritten by its confirmed date & time


When confirming date/time of a tour stop in the tour confirmation, the system re-schedules the successor tour stops ETA, which is correct and important. But the system also re-scheduled the ETA of current confirmed tour stop by overwriting it by the confirmed value. This was not entirely needed and it caused that the original ETA of current tour stop was lost, hence this logic was removed. Newly, the confirmation of date/time only re-schedules the successor tour stops ETA, but the current tour stop ETA is not updated (ie. is preserved).

2021-02User Story77641Dispatching & confirmation
Tour confirmation enhancement: the order confirmation is not anymore done via 'Confirmed' checkboxes but via dedicated menuitems


The order confirmation (in tour confirmation form) is not anymore done via 'Confirmed' checkboxes but newly via dedicated menuitems 'Confirm' and 'Undo confirmation'. The reason for such change was that several issues/limitations were related to the confirmation via checkboxes (eg. the change of the confirmation quantity was sometimes reset when the checkbox 'Confirmed' was used; the order confirmation shall differ when orders with (or without) packages are confirmed etc.).

2021-02User Story77643Dispatching & confirmation
Enhancement of the tour confirmation process, when the confirmation happens on the package level


Previously the tour confirmation (via package confirmation) was possible but the feature was lacking in certain aspects, especially in the area of how confirmed quantities were handled/updated on the tour order line from the package confirmation. Depending on the package data users could for example experience the loss of confirmed weight (or volume) quantity, or it was not clear why certain confirmed quantity was updated (as some conversion rules were applied etc.). The package confirmation mechanism was thus re-worked and following key logic is now applied, for the tours/orders that contain some packages:
- Package confirmation now updates the confirmed transport quantity (by the count of confirmed packages, when the last package is processed/confirmed). The confirming transport quantity is locked for manual editing (as it is managed by the package confirmation)
- Package confirmation now updates the confirmed weigh (and volume) based quantity (by the summing of data from the packages, when the last package is processed/confirmed), but only if such weight (or volume) data is available on all packages that are being confirmed. Otherwise (eg. when some weight or volume data is not available on some confirmed package), then the confirmed quantity is not updated. Users still can manually adjust the confirming quantity, as the fields are editable.

2021-02User Story77657Dispatching & confirmation
Improvement of the activity category handling in both GPB gantt screens


A follower of task 77411 (Enhancement of the transport activities, new activity types & activity category feature), that was released in previous release GPB 2.3.7 (with TAL 10.0-CAP14.0).

Following enhancements were added in this task:
- Previously introduced activity 'Category' field (and also a new 'Mandatory for Driver app' field) are now also displayed in both GPB gantt screens (in level 3, in the activity overview 'slide in' side window)
- Activity visualization in both GPB gantt screens (in level 2, in the activity overview section) newly only activities of type Dispatching or Execution are shown. As only these do affect the duration of the tour.

For more details about activity category feature please see the release letter of the task 77411 (Enhancement of the transport activities, new activity types & activity category feature), that was released in previous release GPB 2.3.7 (with TAL 10.0-CAP14.0).

2021-02User Story78508Dispatching & confirmation
Manual ETA specification is newly also shown in the GPB 'Transport orders /-legs' screen


In GPB, in 'Transport order /-legs' screen, in tour stop overview, the GPB displays the entire transport leg structure, ie. also the transport legs that are already planned in some tour. The detailed scheduling of such transport legs could have been already adjusted via Manual ETA specification on the tour, but such information was previously not anyhow reflected in the transport leg structure overview. This was enhanced, the Manual ETA specification is newly also visualized (by green font color & icon) in the transport leg structure overview in the 'Transport order /-legs' screen.

2021-02User Story78581Dispatching & confirmation
TAL infolog 'No conflicts detected.' was replaced by GPB native infolog, in GPB conflict analysis menuitems


Previously released task 72628 (Conflict analysis sometimes didn't open in several TMS forms) enhanced the behavior of the conflict analysis menuitems in TAL dispatching screens, showing a new infolog 'No conflicts detected.' when no conflicts were detected by conflict analysis.
Having a TAL infolog is certainly sufficient for TAL forms but is not sufficient for GBP screens (as the user would have to wait for TAL browser window to open, just to learn that there were no conflicts detected). So for GPB processes the TAL infolog was replaced by a native GPB infolog (that is displayed instantly).

For more details about the infolog logic in the conflict analysis please see the release letter of task 72628 (in TAL release 10.0-CAP14.0)

2021-02User Story78644Dispatching & confirmation
Better distinguishing of confirmed 'Sender delivery' transport legs in the goods planning status overview


Previously, the identification of 'Sender delivery' transport legs (that were confirmed) was confusing in the goods planning status overviews (especially in the transport leg planning & cross-docking forms), as these legs were previously treated as common transport legs (with goods planning statuses of 'Roughly planned'). This was enhanced and following goods planning status logic is newly applied:
- When the 'sender delivery' leg is confirmed and is not in the tour - it gets goods planning status 'Arrived'
- When the 'sender delivery' leg is confirmed and is in the tour - it gets goods planning status 'Unloaded'

2021-02User Story78782Dispatching & confirmation
The functionality of 'auto pop-up' of work instructions on the tour was depreciated (GPB)


Previously released task 78781 (The functionality of 'auto pop-up' of work instructions on the tour was depreciated) removed the menuitems for 'auto pop-up' of work instructions from TAL forms. This task also removes the 'auto pop-up' menuitem from the GPB gantt screens.
For more details about depreciated 'auto pop-up' functionality please see the release letter of task 78781 (in TAL release 10.0-CAP14.0)

2021-02User Story79119Dispatching & confirmation
Allow to bypass in GPB the initial TAL compatibility check


When launching the GPB, the GPB client automatically checks whether some compatible TAL version is installed. The compatibility check was previously mandatory, ie. GPB client could be launched only with the TAL compatible version only. For various (mostly test) purposes it is sometimes needed to bypass such validation, hence a new parameter in the GPB config file was introduced. For more details please see the installation guidelines document.

Please note:
- Bypassing the TAL compatibility check was introduced for maintenance & support purposes, must not be done on the productive applications, as it might lead into unforeseen GPB behavior, possibly even to data corruption.

2021-02User Story79188Dispatching & confirmation
Performance improvement of the initial opening of both GPB gantt screens


Previously the initial opening of both GPB gantt screens could be less performing, especially when higher count of resources and tours had to be loaded at once. The responsible code was enhanced in this task, to achieve quicker gantt screen opening. The optimization was done purely on the code structure level, besides the performance improvement it leads to no functionality difference.

2021-02User Story79390Dispatching & confirmation
Performance driven enhancement of the GPB, newly only one background service is used for maintenance of the refresh of the dispatching entities


Previously there were two background services that were responsible for maintaining the automated refreshing of the entities in GPB (eg. tours, transport legs, resources etc). To improve the general GUI experience with all GPB screens, both background services were merged into one.

2021-02User Story79569Dispatching & confirmation
Transport order and transport leg can be blocked / put on hold by means of reason code


Transport order and transport leg can be blocked by indicating a reason code:
- Blocking TRO: TRO cannot be pre-dispatched
- Blocking transport leg: Leg cannot be dispatched in tour

Indicating a reason code allows to define why an order or leg should be put on hold. Possible reasons: Awaiting new date/time slot from customer, or any other documents, or even credit limit issues.

2021-02User Story79611Dispatching & confirmation
Automatic release of tour to WHS


A new periodic function 'Release to warehouse – Tour' was introduced, which can be used to release trading orders assigned to tour to warehouse.

The following parameter can be defined:
- Tour plus days: Defines for how many days in the future – related to the tour start –tours should be released to warehouse.
- Calendar: The defined calendar controls which dates should be taken into account for the tour start date to select tours that are to be released to warehouse. Only the dates marked as ‘Open’ will be used. If no calendar is specified, all dates are used.

New periodic function is accessible in following path:
- Main menu -> CAPcargo Transport -> Periodic -> Dispatching -> Release to warehouse - Tour

Additionally, a new 'Release to warehouse' menuitem has been added, to following places:
- to GPB (to action pane on both gantt screens, in menuitem group Shipment)
- to 'Dispatch light - Tours' form (to menuitem group Shipment)

via which it is newly possible to release multiple tours to warehouse at the same time. The function can also be run in batch processing mode.

2021-02User Story79638Dispatching & confirmation
New target for work instructions: tour stop


By enhancing the transport address related work instruction template, the user is enabled to define such address specific instructions, that are initialized to the tour stop during the tour stop creation.

2021-02User Story79730Dispatching & confirmation
Two new languages were added to the GPB app


From now on the GPB app includes and supports also the 'en-gb' and 'en-au' languages.

2021-02User Story79732Other / General
Two new languages were added to the TAL


From now on the TAL includes and supports also the 'en-gb' and 'en-au' languages.

2021-02User Story64567Driver App
Enhancement of the activity configuration framework (Package scan mandatory / error with reason code)


To avoid the need to individualize the validation for scanning, a generic solution is introduced, to set Driver app activities mandatory or optional:
- Mandatory activities can only be cancelled/skipped with entering a reason code and optionally some description.
- Optional activities can be cancelled/skipped without entering a reason code, but with the option to add a description.

This configuration is possible for each driver activity type, being previously mostly initialized from TAL tour activities; additionally, it is possible to define whether the package scanning is optional or mandatory for the 'load' and 'unload' activities.
Special driver activities “Start working…”, “Arrived” and “Depart” are still hard-coded and not subject of this configuration. They are always mandatory.

Key characteristics:
- The configuration happens in the 'Instruction activity rules' (accessible in main menu path under:
main menu -> CAPcargo Transport -> Setup -> Dispatching -> Instruction activity rules
- New option 'Barcode scan required (package)' was added to the Activity type. This allows to set up rule(s) for activity being mandatory (or not), to be applied for all customers (or some), to be applied during loading (or unloading, or both) etc.

2021-02User Story64571Driver App
Introducing an option in Driver app, to 'not confirm' (ie. skip) certain activities


To avoid the need to individualize the processes for all potential failed activities, a generic solution is introduced to 'not-confirm' an activity and add a reason code telling why.
Instead of confirming (ie. swiping off) an activity, the driver newly has an option (per activity and per tour stop (serving as multi-select of all activities on this tour stop)), to skip (ie. not-confirm) one or several activities. By doing so, the app asks the driver for a reason code which has to be selected from a list.

Before Failed activity can be used in Driver app, following pre-requisites are needed in D365:
- At least one transport order cancellation reason code for process "None" must be set up (it is used to fail activities other than load / unload)
- At least one transport order cancellation reason code for process "Failed delivery" must be set up
- At least one transport order cancellation reason code for process "Failed pickup" must be set up
- Doublecheck that these reason codes are shown in Driver app reason code form (main menu -> CAPcargo Transport -> Inquiries -> Driver app -> Driver app reason code
- If not, click "Settings refresh / synchronize" button
- The Driver app reason codes are expected to stay in sync with transport order cancellation reason codes. But if some transport order cancellation reason codes were created in the system before Driver app was activated, then they must be synchronized using "Settings refresh / synchronize" button.

2021-02User Story72354Driver App
Failed delivery process from Driver App


The failed deliveryprocess can be launched from Driver App which automatically handles ordercancelling or potential re-attempting of delivery. Retry of delivery is possible within the sametransport order.
Further, automatic re-scheduling or blocking of new transport leg or new transport order is possible. For that a new function on transport order and transport leg was introduced, where an order or a leg can be blocked by indicating a reason code:
- Blocking TRO: TRO cannot be pre-dispatched
- Blocking transport leg: Leg cannot be dispatched in tour

By means of order import update, new appointment/wish dates forre-attempts can be imported and automatically updated in dispatching. Further,there is some configuration for potential automatic unblocking of theorder/leg.

2021-02User Story72460Driver App
Failed pickup process from Driver App


The failed pickupprocess can be launched from Driver App which automatically handles ordercancelling or potential re-attempting of pickup. Retry of pickup is possiblewithin the same transport order (keeping all the references) or with a newtransport order.
Further, automaticre-scheduling or blocking of new transport leg or new transport order ispossible. For that a new function on transport order and transport leg wasintroduced, where an order or a leg can be blocked by indicating a reason code:
- Blocking TRO: TRO cannot be pre-dispatched
- Blocking transport leg: Leg cannot be dispatched in tour

By means of order import update, new appointment/wish dates for re-attempts can be imported and automatically updated in dispatching. Further, there is some configuration for potential automatic unblocking of the order/leg.

2021-02User Story78964Driver App
Timestamp of the driver's approval is now visualized in GPB tour details in the time zone of the tour start address


In gantt screens in tour details (in level 2) the GPB displays the approval status (and the timestamp) from the Driver app. The logic was enhanced and GPB now also respects the potential time zone shift, applying the same time zone as on the tour start address.

2021-02User Story79588Driver App
The main checkbox parameter 'Driver must accept the tour' was replaced by more flexible 'Driver acceptance before tour start' enum


By introducing the ‘Driver acceptance before tour start’ parameter, a new configuration option is provided. Hence besides the previously existing 2 options (driver accepts/rejects tour, tour is automatically accepted by driver), a third option is added: driver acknowledges tour. In this case rejecting the tour is not possible in the Driver app, but only 1 icon (=accept) is shown on the tour tile.
Furthermore, the new parameter does not only replace the previous ‘Driver must accept tour’ general TMS parameter, but it is introduced on the carrier/vendor as well. So more sophisticated configuration is possible for the external drivers.

2021-02User Story79933Driver App
Attaching a picture in the Driver app when reporting a failed activity or a failed barcode scan


It is newly possible to attach a picture in the Driver app when reporting a failed activity or a failed barcode scan.
These pictures are attached to TAL (either to package tour order lines, or to tour order lines, or to tour activity), depending on where captured in the Driver app.

Prerequisite parameterization:
- Define the 'Document type for failed activity' and 'Document type for failed barcode scan' in the main TMS parameters (in section 'Document management') - to specify which document type shall be used for both cases

If parameters are empty, attachments are still handled/attached to TAL but using "first document type for files" that system can find.

Additional new parameterization:
- 'Document type for claim' was added to the main TMS parameters (in section 'Document management') - previously the "first document type for files" that system could find was used when attaching the claims to TAL

2021-02User Story80007Driver App
New inquiry forms 'Review Driver app issues' & 'Review Driver app issues (tour line)' were added to the tour confirmation form


New inquiry forms 'Review Driver app issues' & 'Review Driver app issues (tour line)' were added to the tour confirmation form, to show more information about Driver app tours that might exist for the tour & tour stop, eg. to show the failed activities, missing barcode scans etc.

2021-02User Story80229Driver App
Driver App: new app features with CAP.Transport&Logistics 10.0-CAP15.0


Following enhancement were added to the Driver app in this release:
- Skip activity and provide a reason code (for example failed pickup, failed delivery)
- Skip mandatory barcode scan and provide a reason code

2021-02User Story74878Integrations
Document import framework: new target table "Tours"


The document import framework has been extended with the target table tours. After uploading the file via the data management workspace against the existing entity "TAL Imported attachments" it is now possible to attach notes and documents against the tour table. As unique identifier the Tour ID must be specified during the upload.

2021-02User Story79383Integrations
New feature 'Generic message content' in the Message framework


Message framework was enhanced with a more flexible way of configuring the message content in status message setup.
It is now also possible in an easy way for customers to implement new content (as customization), as well for the product to easily provide further data (when requested).

To achieve this we will provide a possibility to implement a dedicated X++ interface, and those classes shall be selectable finally in the message template configuration.

Key characteristics:
- The message template content configuration happens in 'Status message template' form (main menu -> CAPcargo Transport -> Setup -> Track and Trace -> Status message template)
- 4 default content definition classes are provided, these are accessible in 'Status message calculated values' form (main menu -> CAPcargo Transport -> Setup -> Track and Trace -> Status message calculated values):
- Transport address (leg)
- Failed delivery reason (leg)
- Failed pickup reason (leg)
- Transport type

2021-02User Story79307Other / General
''T&L Sales clerk' and 'T&L Warehouse worker' security roles newly have read access to more tour elements


As needed for several business processes, the security roles 'T&L Sales clerk' and 'T&L Warehouse worker' newly gains a read access to several tour elements, eg. orders in tour etc. Read only access was achieved by assigning a duty 'View tour orders' to both security roles.

2021-02User Story80095Other / General
Adjustment of the security parameterization for 'Release tour/leg to warehouse' functionality (duty 'Release to warehouse')


To reduce the need for Full user TAL license amount, an access to 'Release tour/leg to warehouse' functionality has been removed from the 'T&L Warehouse worker' security role, as the 'T&L Warehouse worker' security role requires only Light user TAL license.
On the other hand the security role 'T&L Dispatcher' gained access to 'Release tour/leg to warehouse' functionality, as the 'T&L Dispatcher' security role already requires Full user TAL license.

2021-02User Story77606Shipment Builder
Connect container structure to shipment builder


This feature enables the shipment builder to support the automatic containerization process.
At container closing, the shipment builder entities will be updated based on the available information of the container / container type.
At transport order synchronization, the system creates 1 CAPcargo package per container. The volume and weight of the packages are retrieved from the container type and items.
In case a container gets reopened, the related packages will be deleted and the related shipment builder entities get updated.
Multi-level containerization is not fully supported with this feature. The shipment builder can handle multi-level container but only the most outer container (=container level 0) will be considered for transport and plan quantity calculations.

Please note (info for existing customers):
- The parameter “Flexible volume dimensions” on container types has to be set to YES in order to make it work as today.

2021-02User Story78721Subcontracting/IC invoicing
Change of the posting profile on the vendor orders doesn't anymore invalidate the previously existing price calculation


Previously, on vendor order types, when changing the posting profile manually on the order (that was previously calculated), the order price calculation was invalidated (ie. 'Calculated' flag was reset to FALSE). As a consequence, the price calculation had to be performed again, to have order calculated. Such behavior was different to the customer order types (where change of posting profile doesn't reset the price calculation).
The behavior on vendor order types was enhanced, to follow the same logic as on the customer order types.

2021-02User Story79605Subcontracting/IC invoicing
Enhancement of the vendor invoice posting process, to manually specify the vendor invoice number


Vendorinvoice posting process was enhanced, to optionally populate also the invoice number(on all vendor invoice journal lines), if specified in the vendor invoice poolposting dialog (in new field 'Vendor invoice').
Additionally both vendor invoicing flows (vendor invoice & vendor self-billing) were adjusted, so that each invoicing flow newly uses a separate dedicated number sequence. Previously both invoicing flows shared one number sequence (parameterized under 'Vendor invoice' in main TMS parameters), which was newly renamed to 'Vendor self-billing invoice' (and serves now only for the self-billing posting purposes). New number sequence parameterization for 'Vendor invoice' was added to the main TMS parameterization, for the vendor invoice posting purposes.

Please note:
- the new number sequence parameterization for 'Vendor invoice' is by default empty and has to be manually specified in the main TMS parameters, by projects that use this functionality.

2021-02Bug78616Customer invoicing
During the invoice reversal of the transport order system sometimes asked for print destination settings even though no printing of reversal/credit note was activated


The issue was corrected, now the system asks for print destination details only when printing of reversal/credit note is activated in the reversal dialog.

2021-02Bug79305Customer invoicing
Custom invoice layouts couldn't be used when generating TMS customer invoice


Via print management, it is possible to define a custom layout of the TMS customer invoice. The issue was that such custom invoice layout was ignored and standard default TMS customer invoice layout was always used. The issue was corrected and custom invoice layout is now used when it is defined and activated in the print management.

2021-02Bug43122Customer order management & pricing
Overuse of the package ID number sequence


Previously, the package (that was manually created by user) did skip a number in the package ID number sequence. The issue was corrected and the package ID number sequence is allocated correctly even for manually created packages.

2021-02Bug49411Customer order management & pricing
''Over package' scope could get broken in certain order management scenarios


''Over package' scope (ie. several packages are linked to the same package parent id) should be processed (ie. planned into tour, removed from from tour) as a whole, to avoid that part of the over package is planned into tour and part not (or part is planned in the different tour etc.). The issue was that in certain order management scenarios the 'over package' scope could get broken. This was happening especially when the packages of two transport orders were linked to the same parent package id (ie. 'over package' scope across different transport orders) and one of the transport orders was removed from dispatching (either via menuitem 'Delete order from dispatching' on non-shipment builder transport order; or via menuitem 'Remove from transportation' on trade order lines). The issue was corrected and such transport order is not anymore removed from dispatching (if it would break the 'over package' scope) and user is informed via error infolog.

2021-02Bug78472Customer order management & pricing
Missing time stamps for certain track & trace statuses


Previously, time stamps were missing for following track & trace statuses:
* (Status430) - Delivered by sender
* (Status436) - Picked up by receiver

The issue was corrected and both track & trace statuses are now properly marked by time stamp when the status was reached.

2021-02Bug79190Customer order management & pricing
Newly created address was not visible in the return sales order creation dialog


Previously when creating a new shipping address (via address creation wizard in the return sales order creation dialog), the shipping address on the return sales order dialog was not automatically updated. The issue was corrected, the details of newly created address are immediately visible on the return sales order creation dialog, once address creation wizard is closed.

2021-02Bug79400Customer order management & pricing
The change of the values in header section of the transport order line view was sometimes not saved (ie. lost)


The change of the values in header section of the transport order line view was sometimes not saved (ie. lost). This was happening when header section changes were not manually saved and user continued to change the line section values (eg. transport quantity). Then the line section values (eg. transport quantity) were successfully saved but header section values were just reloaded from database, without saving the changes first. The issue was corrected and header section changes are also first saved, before the automated reload happens.

2021-02Bug44167Dispatching & confirmation
Several issues were corrected in the transport leg related forms


Following issues were corrected in the 'Dispatch light - Transport legs' screen:
- Only first few records/transport legs showed the correct planning quantity (in the right info section). The rest transport legs showed zero planning quantity
- Some fields were directly editable (eg. planning quantity or conflict state)
- When new fields were added to the grid (via form personalization) then sometimes the new fields were immediately opened for user changes

Following issues were corrected in the 'Transport leg points' form (which can be launched from transport order form):
- Some fields were not displayed correctly for the second transport leg point record (eg. address ID was missing on unload leg point)
- Some fields were directly editable (eg. planning quantity, transport leg type checkboxes)

2021-02Bug64544Dispatching & confirmation
Docking/undocking icons were sometimes not shown in the tour stop overview in both GPB gantt screens


When the docking (or undocking) activity occurs on the tour stop, the tour stop is highlighted by the small icon below the tour stop overview (aka. in level 3), in both GPB gantt screens. The issue was that the visualization of these icons was not reliable - sometimes the icons were shown, sometimes not, sometimes the icons disappeared when changing the focus between the tours etc. The visualization is now corrected.

2021-02Bug77414Dispatching & confirmation
Conflict visualization on the tour was not automatically refreshed when conflict analysis was done automatically during the tour release


The conflict visualization on tour was not automatically refreshed when conflict analysis was done automatically during the tour release, so dispatchers didn't have accurate information about the detected conflicts. The issue was corrected and the conflict visualization on tour is refreshed after the tour release, in both gantt screens.

2021-02Bug77588Dispatching & confirmation
Duplicated gantt grid refresh in certain scenarios when dispatchers rearranged the tour stop sequence (via drag and drop)


Previously, when rearranging the tour stops (via drag and drop in GPB gantt screens) in certain constellations the GPB performed a duplicate grid refresh. The issue was corrected and the gantt grid is now refreshed only once after rearranging the tour stop sequence.

2021-02Bug78643Dispatching & confirmation
Goods planning status 'To be picked up by receiver' was sometimes showing on transport legs even on non-receiver business cases


Goods planning status 'To be picked up by receiver' was sometimes showing on transport legs even on non-receiver business cases. This was especially happening after the removal of depot split from transport legs. The issue was corrected and the proper goods planning status 'Ready for collection' is shown on transport legs.

2021-02Bug78879Dispatching & confirmation
Several menuitems were not accessible in the forms for users without 'System administrator' security role


Following menuitems were accessible in the forms only for users with 'System administrator' security role:

In 'Dispatch light - Transport legs' form:
- Sync transport order
- Dispatch in tour
- Release to warehouse

In tour confirmation form:
- Revoke package conf. (complete tour line)

In global address book address detail form:
- CAPcargo edit coordinate

Issues were corrected, menuitems don't anymore require 'System administrator' security role.

2021-02Bug79244Dispatching & confirmation
Duplicated packages after a failed delivery registration


Process of registration of a failed delivery could in some cases lead to the corrupted data in transport leg & tour structure. The visual impact to user is that the packages get duplicated after performing the failed delivery but in fact the problem was caused by corrupted data in the transport leg & tour structure. The issue was fixed and the failed delivery process behaves correctly now.

2021-02Bug79286Dispatching & confirmation
Confirmed tour quantity sometimes failed to update the planning quantity on the successor transport legs


In certain data constellation, confirmed tour quantity sometimes didn't update the quantity on the successor transport leg. This was only happening on successor transport legs which were not yet planned into any tour and which were not directly succeeding (ie. there was at least one depot split between the tour stop that is being confirmed and the successor transport leg). The issue was a regression of task from the TAL 10.0-CAP9.0 release, which was realized only recently and is fixed now.

2021-02Bug79365Dispatching & confirmation
Missing address name dropdown, in the dialog of 'Change unload address' menuitem, in the 'Dispatching light - Transport legs' form


Previously, in the 'Dispatching light - Transport legs' form, in the dialog of 'Change unload address' menuitem, the address name dropdown worked correctly only for users with 'System administrator' security role. The issue was corrected and address name dropdown now opens correctly even for users without 'System administrator' security role.

2021-02Bug79367Dispatching & confirmation
Tour details (in level 2) in GPB gantt screens were not refreshed correctly in some cases, so the traces of tour were still visible on the screen (in level 2) even when tour was removed from the gantt


The issue was happening for example when dispatchers changed the owner company, then tour disappeared from the main gantt grid but the tour details (aka. level 2) were still left visible in the gantt screens. The issue was corrected, the section with tour details (level 2) is now automatically refreshed when the main gantt grid is refreshed.

2021-02Bug79680Dispatching & confirmation
GUI enhancement of the visualization of the generic buttons on the GPB Resources screen


Previously the generic buttons on the GPB Resources screen got graphically distorted once pressed. The issue was corrected.
Also the general compatibility of the generic buttons in Resource screen was improved, to cover more business cases.

2021-02Bug79737Dispatching & confirmation
Wrong activity status after certain dispatching actions


Certain dispatching actions can lead to the copy of activity (for example from existing tour stop to new tour stop). The issue was that the activities were copied also including the activity status. This was happening for example when a failed delivery was performed on a tour that already had some unload activities with status 'in progress' (and user didn't decide for transport order cancellation). Then the new tour stops were generated and their activities inherited the 'in progress' status. The issue was corrected, now the activities are copied but their confirmation status is reset.

2021-02Bug80123Dispatching & confirmation
Quantity split on transport leg failed with generic error in some complex dispatching cases


Splitting a transport leg (via quantity split) on certain complex dispatching cases could fail with generic error 'Cannot create a record in Orders in Tour (CIRTRATourOrderLine). Order: TO-123456. The record already exists.'. This was especially happening when 'Promote confirmed quantity to successor planning leg' feature was activated in the transport type parameterization. The issue was simulated on certain complex (and rather hypothetical) dispatching case where several quantity splits were combined with several depot splits, together with different confirmed quantities in the tour confirmation. The issue was corrected and quantity split mechanism was improved to cover such case.

2021-02Bug80236Dispatching & confirmation
Selected transport leg is sometimes unselected in GPB 'Transport orders /-legs' screen when full grid refresh is triggered


In GPB 'Transport orders /-legs' screen, when full grid refresh was triggered (for example by performing a depot split), then previously selected transport leg got sometimes unselected. This was especially happening when more transport legs were filtered than could fit onto one screen. The issue was corrected and selection of transport leg is now preserved even after the full grid refresh.

2021-02Bug80306Dispatching & confirmation
Failed pickup: Wrong scheduling in some constellation


It could happen that the 2nd attempt to re-pickup was wrongly scheduled. It is supposed to be scheduled at least +1 day after the failed pickup attempt, maybe later depending on the opening dates and route scheduling. The bug was, that this scheduling was not properly respected and it even could happen that the re-pickup date (load of 2nd attempt) was after the unload date of the 2nd attempt. - This was fixed.

2021-02Bug79478Master data
Address lookup in the fuel location setup showed wrong address name (or no address name at all)


When creating a new fuel location, the transport address lookup was showing wrong address names (or no address names at all), when lookup filtering option 'All' was used. The issue was corrected and the fuel location address lookup now shows correct address names.

2021-02Bug79907Master data
Address area couldn't be deleted


Previously it was not possible to delete an address area (either from transport address or directly in the main menu in address area setup); the delete action failed with error 'Field Vehicle must be filled in.'. The issue was corrected and address area can be deleted.

2021-02Bug78755Other / General
Specifying 'miles' as PTV 'Distance unit' didn't calculate the driving distance in miles, but still in kilometres


When the 'Distance unit' was specified as 'miles' (in the Geo services in main TMS parameters) then such parameterization was previously not respected (as system requested the PTV map component still for result in kilometres). The issue was corrected, and system now supports also the driving distance calculation in miles.

Please note:
- When switching the PTV 'Distance unit' to 'miles' (in the Geo services in main TMS parameters) then also the 'Distance' (and 'Distance (empty)' & 'Distance (loaded)') in the main TMS parameters must be specified in units that have a 'System of units' classification as 'United States customary units', in order to get correct result in miles.

2021-02Bug76568Shipment Builder
Display of TMS scheduling information (on D365 trade order lines) was not following the 'Modes of delivery' parameterization


On 'Modes of delivery' it is possible to define whether TMS scheduling information (that is available as 'CAPcargo scheduling information' on D365 trade order lines) shall be shown either for load part, or for unload part, or for both. The issue was that the 'Modes of delivery' parameterization was ignored and CAPcargo scheduling information was shown always for load & unload parts. The issue was corrected and the setup on 'Modes of delivery' is now respected.

2021-02Bug78682Shipment Builder
Wrong warning in certain cases when trade order line cannot be removed from transportation


When a trade order line cannot be removed from transportation (because of transport order being too far in the process) the system in certain cases showed wrong warning. This was especially happening when 'Partially remove from transportation' parameter was activated in the CAPcargo Trade & Distribution main parameters.
Previously the system showed the warning 'Order line SO-123456 / 1.00 has been partially removed from transportation.', which was wrong, as the order line was not removed from transportation.
The warning was corrected, now it properly informs the user that 'The order line SO-123456 / 1.00 cannot be removed from transportation! The linked transport order is already too far in the dispatching process (Parameter settings, tour release/confirmation, sub-contracting etc.) or has been manually part-delivered.
SO-123456 order id, 1.00 line id wasn't removed from transportation.'

2021-02Bug80099Shipment Builder
Function 'Remove from transportation' on trade order lines didn't work correctly when only shipment lots were existing


By menuitem 'Remove from transportation' (accessible on trade order lines) it is possible to remove TMS shipment lots, remove TMS shipments, remove transport order/legs etc. The issue was that the menuitem performed correctly only when TMS shipment lots were assigned to some TMS shipment. The issue was corrected, now the menuitem 'Remove from transportation' removes TMS shipment lots even when they are not assigned to any TMS shipments.

2021-02Bug68657Subcontracting/IC invoicing
Third party LTL transport leg sub-contracting tariff surcharges were in certain constellation not processed during automated vendor invoicing


In vendor invoice automation process, it is possible to setup a rule that orders gets also calculated (via 'Calculate orders first' parameter). The issue was that the price calculation (when launched as part of automated invoicing process) didn't calculate the third party LTL transport leg sub-contracting tariff surcharges, which were in result also not invoiced. The issue was corrected and such third party surcharges are now correctly processed (ie. calculated & invoiced) when 'Calculate orders first' parameter is used in automated invoicing rules.

2021-02Bug78968Subcontracting/IC order management & pricing
Re-calculation of FTL sub-contracting tour order sometimes didn't happen correctly


Re-calculation of FTL sub-contracting tour order (which was previously already calculated) sometimes didn't happen correctly. The FTL order seemed calculated by new tariff quantity (as the 'Calculated' flag was checked), but the order totals were still showing the old (now obsolete) price. The issue was fixed and the order totals are calculated correctly even after the re-calculation of previously calculated order.

2021-02Data conversion78583Master data
Data migration job for task 77654 (Customer self-billing), to update transport order / default order


Data migration job for task 77654 (Customer self-billing) to have existing transport order (and default order) transactions compatible with the new feature of customer self-billing.

2021-02Data conversion78587Master data
Data migration job for task 77654 (Customer self-billing), to update customer account


Data migration job for task 77654 (Customer self-billing) to have existing customer accounts compatible with the new feature of customer self-billing.

2021-02Data conversion78593Master data
Data migration job for task 77654 (Customer self-billing), to update customer invoices


Data migration job for task 77654 (Customer self-billing) to have existing customer invoices compatible with the new feature of customer self-billing.

2021-02Data conversion79346Master data
Data migration job for the task 76529 (New feature: cleaning framework and truck loading history)


The data migration job populates new field 'Level' on Activity time class table by value 'None' on all existing time class records.

2021-02Data conversion79347Master data
Data migration job for the task 76529 (New feature: cleaning framework and truck loading history)


The data migration job populates new field 'Level' on 'Activity Time per Address' table (on the transport address) by value 'None' on all existing 'Activity Time per Address' records.

2021-02Data conversion79608Master data
Data migration job for the task 79588 ('Driver acceptance before tour start' enhancement)


The data migration job populates the new parameter 'Driver acceptance before tour start' from the old parameter 'Driver must accept the tour', in the main TMS parameters.

2021-02Issue80231Dispatching & confirmation
KNOWN ISSUES or missing functionality in the area of failed pickup and failed delivery


The entire process of failed pickup and failed delivery has been redesigned and fully integrated to the Driver App. The main features are available and successfully tested. The following issues/topics are not yet implemented:
- [79333] Special case which is not fully nor partialy failed pickup
If a transport order consists of 2 order lines and one of them fails entirely in picking up, then this is currently not properly covered. From an order perspective it is a partial failure (which currently focuses on splitting off quantities from an order line), and from a practical perspective is fully failing an entire "position", but full failure will fail the complete order currently. - Concept and implementation to be enhanced in a future release.
- [79143] Unload list report
The unload list still prints the "dummy/zero-qty/pre-confirmed" unload point from the failed pickup leg. Should be suppressed for better UX.
- [80424] Partially failed delivery not available in TAL yet, only fully failed delivery.
The Driver App allows though partial failure for load and unload, hence would support partial failed delivery, but cannot be handled then by TAL. - Concept and implementation to be enhanced in a future release.
- [80241] Multiple partially failed pickup with different reason codes not supported
Driver App supports to fail pickup of every single package and enter as well for each a different reason code. In TAL that process is grouped and only one reason code per failure can be handled. - Concept and implementation to be enhanced in a future release.
- [80243] Partially failed pickup not supported for order from shipment builder
In TAL we don't support partially failed pick-up (= quantity split) for transport orders originating from trade module (shipment builder) because the splitting of records would lead to unclear references in the WH module. However, the app itself cannot validate this yet and hence would allow a partial failure of pickup, which would lead to an error in TAL. In reality this would not be a very realistic scenario, since pick-up happens in the own warehouse. If there are some issues they should be solved before driver has to load them

2021-02Issue80270Dispatching & confirmation
KNOWN ISSUE: Special case "Depot split after removed/reduced part-delivery" promotes wrong quantities


If a transport order (e.g. 10 PAL) is part-delivered, i.e. split into 2 legs (e.g. 8 PAL & 2 PAL), then we have the option to end one path, for example, if the customer decides to not need the transportation of the 2 PAL anymore. With the function "remove part delivery" this is achieved.

If now, the dispatcher decides to ship the remaining 8 PAL via a hub, he can perform a depot split. Here the issue happens, the successor leg (Depot to Receiver) initiates the quantity of 10 PAL instead of 8 PAL.

This issue will be fixed asap in a next release with #80232.

2021-02Issue80312Dispatching & confirmation
KNOWN ISSUE: Failed pickup: Retry within same order schedules the confirmed/failed leg points


After failed pickup a 2nd retry can happen within the same transport order. This will create a 2nd leg while the first leg will be put to "failed" and "confirmed":
- 1st leg A-A, 0 qty, failed, confirmed
- 2nd leg A-B, x qty, open to dispatch

The depot split function reschedules all the legs, instead of only the 2nd leg (because first is already confirmed). Depending on the setup (e.g. route weekday scheduling indicates closed on the confirmed date - which would be quite rare), then the scheduler could update the planning dates of the first leg to a later date, which is wrong. However, the confirm date is not touched and since the leg is anyway already confirmed, these potentially wrong planning dates will appear nowhere in the planning process. Also track & trace is not affected, since that bases also on [correct] confirm dates.

Will be fixed with ADO 80311.