|2020-11||User Story||26038||Customer 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-11||User Story||39329||Customer order management & pricing||
Enhancement of the work instructions
Existing framework of work instructions was greatly enhanced, to cover more entities and processes.
- 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-11||User Story||56698||Customer 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-11||User Story||59731||Customer 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-11||User Story||75718||Customer 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.
- '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-11||User Story||51343||Dispatching & 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-11||User Story||72542||Dispatching & 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-11||User Story||73813||Dispatching & 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-11||User Story||75690||Dispatching & 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-11||User Story||69588||Driver 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-11||User Story||75701||Driver 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.
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.
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.
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.
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-11||User Story||77571||Master 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-11||User Story||76543||Shipment 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-11||Bug||73914||Customer 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-11||Bug||73916||Customer 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-11||Bug||73924||Customer 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-11||Bug||74851||Customer 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-11||Bug||76586||Customer 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-11||Bug||70653||Dispatching & 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-11||Bug||72485||Dispatching & 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-11||Bug||72801||Dispatching & 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-11||Bug||73639||Dispatching & 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-11||Bug||73901||Dispatching & 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-11||Bug||73926||Dispatching & 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-11||Bug||73934||Dispatching & 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-11||Bug||73961||Dispatching & 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-11||Bug||74846||Dispatching & 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-11||Bug||76591||Dispatching & 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-11||Bug||77508||Dispatching & 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-11||Bug||77537||Dispatching & 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-11||Bug||77617||Dispatching & 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.
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.
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.
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.
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.
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.
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-11||Data conversion||73964||Other / 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:
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-11||Issue||77645||Dispatching & 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-11||User Story||56797||Dispatching & 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-11||User Story||67652||Dispatching & 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-11||User Story||73654||Dispatching & 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-11||User Story||73678||Dispatching & 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-11||User Story||73737||Dispatching & 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-11||User Story||73903||Dispatching & 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-11||User Story||73919||Dispatching & 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-11||User Story||78525||Dispatching & 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-11||User Story||77411||Driver 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-11||Bug||72467||Dispatching & 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-11||Bug||73930||Dispatching & 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-11||Bug||74836||Dispatching & 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-11||Bug||74856||Dispatching & 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-11||Bug||75681||Dispatching & 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-11||Bug||76576||Dispatching & 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-11||Bug||77395||Dispatching & 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-11||Bug||77409||Dispatching & 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-11||Bug||77674||Dispatching & 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-11||Bug||78478||Dispatching & 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-11||Bug||78539||Dispatching & 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-11||Issue||78538||Dispatching & 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