|2020-12||User Story||74844||Customer 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-12||User Story||52970||Customer 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-12||User Story||73629||Customer 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-12||User Story||73694||Customer 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-12||User Story||25810||Dispatching & 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-12||User Story||56640||Dispatching & 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-12||User Story||67634||Dispatching & 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).
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-12||User Story||72408||Dispatching & 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-12||User Story||77400||Dispatching & 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-12||User Story||77437||Dispatching & 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.
- 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-12||User Story||77518||Dispatching & 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-12||User Story||78756||Dispatching & 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-12||User Story||78781||Dispatching & 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-12||User Story||76540||Driver 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-12||User Story||76541||Driver 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.
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.
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-12||User Story||64471||Master 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-12||User Story||78809||Master 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-12||User Story||26688||Other / 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-12||User Story||73778||Other / 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-12||User Story||78966||Other / 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-12||User Story||78817||Shipment 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-12||Bug||73633||Customer 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-12||Bug||73683||Customer 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-12||Bug||77416||Customer 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-12||Bug||78747||Customer 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-12||Bug||78838||Customer 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-12||Bug||72628||Dispatching & 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-12||Bug||73692||Dispatching & confirmation||
Several labels were missing in the 'Direct order-to-vehicle dispatching' form
Missing labels were corrected/added.
|2020-12||Bug||73764||Dispatching & 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-12||Bug||78654||Dispatching & 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-12||Bug||78668||Dispatching & 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-12||Bug||78705||Dispatching & 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-12||Bug||78840||Dispatching & 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-12||Bug||79288||Dispatching & 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-12||Bug||79290||Dispatching & 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.
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).
''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.
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)
Default filters were not working on the contract version & relation forms
It was possible to define on worker even the invalid qualifications
Missing validation of transport unit (and planning/tariff units) in several forms
Users could override the address reference when registering a new work instruction template on the TMS address
Correction of two bugs in the area of new compartment registration
Wrong German translation of 'Load' enum value (of the 'Load code' enum)
|2020-12||Bug||78691||Other / General||
TMS Dutch labels were sometimes showing wrong special characters
|2020-12||Bug||79029||Other / General||
''T&L Sales clerk" and "T&L Warehouse worker" security roles required a license type of 'Full user'
|2020-12||Bug||78561||Subcontracting/IC order management & pricing||
Carrying resource was sometimes not updated on the Sub-contracting transport leg (LTL) order line
|2020-12||Data conversion||78808||Master data||
Data migration job for 52970 task - to initialize the 'Setup type' classification on tariff zone header
|2020-12||Data conversion||78720||Other / General||
Data migration job - to fill the empty invoice account on transport orders
|2020-12||User Story||32045||Dispatching & 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-12||User Story||73631||Dispatching & 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-12||User Story||76560||Dispatching & 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-12||User Story||77402||Dispatching & 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-12||User Story||78799||Dispatching & 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-12||User Story||79249||Dispatching & 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-12||Bug||78541||Dispatching & 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-12||Bug||78558||Dispatching & 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-12||Bug||78706||Dispatching & 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-12||Bug||78709||Dispatching & 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-12||Bug||78753||Dispatching & 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-12||Bug||78875||Dispatching & 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-12||Bug||78907||Dispatching & 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-12||Bug||79138||Dispatching & 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-12||Bug||79340||Dispatching & 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.