|2020-09||User Story||25509||Dispatching & 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-09||User Story||25521||Dispatching & 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-09||User Story||25975||Dispatching & 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-09||User Story||49407||Dispatching & 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-09||User Story||55356||Dispatching & 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)
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".
Only transport addresses are currently enabled for the "External codes", the customer accounts & transport units not yet.
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.
- 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.
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)
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.
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.
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).
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-09||User Story||67545||Master 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-09||User Story||18702||Other / 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
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.
|2020-09||User Story||72652||Other / 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-09||User Story||73620||Other / 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-09||User Story||67651||Shipment 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-09||Bug||50984||Customer 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-09||Bug||72662||Dispatching & 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-09||Bug||73665||Dispatching & 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-09||Bug||73704||Dispatching & 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-09||Bug||73707||Dispatching & 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-09||Bug||73742||Dispatching & 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-09||Bug||73759||Dispatching & 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.
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.
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.
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.
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-09||Data conversion||72638||Master 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-09||User Story||67743||Dispatching & 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-09||User Story||69621||Dispatching & 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-09||User Story||72474||Dispatching & 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-09||Bug||51261||Dispatching & 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-09||Bug||69748||Dispatching & 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-09||Bug||72695||Dispatching & 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-09||Issue||73943||Dispatching & 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.
- 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.