|TAL 10.0-CAP7.00||User Story||43145||Customer order management & pricing|
GUI redesign of "Direct dispatch (route)" & "Generate/Update tour out of route/zone" dialogs
The dialog for "Direct dispatch (route)" (on the transport order) and "Generate/Update tour out of route/zone" dialog (on the transport legs) were redesigned, for better user readability.
Also the "Direct dispatch (route)" dialog now shows only the relevant routes (ie. the routes that belong to the transport legs of the selected transport order(s)). Previously all routes were shown in the dialog (ie. even the routes that could not be used for selected transport order(s)).
|TAL 10.0-CAP7.00||User Story||51775||Customer order management & pricing|
Several GUI enhancement of the 'Pre-order' functionality
Following enhancements were done for 'pre-order' functionality:
* New dedicated button 'Pre-order' was added to the transport order form, to directly create a pre-order.
* The "Order from pre-order" dialog was redesigned, for better user readability. Eg. the excessive menuitem groups were transformed into tabpages etc.
* The "Cancel" button on "Order from pre-order" dialog was renamed to "Close".
|TAL 10.0-CAP7.00||User Story||54390||Customer order management & pricing|
Possibility to cancel a transport order
Previously the CAPcargo transport order could not be cancelled. There existed certain workarounds (eg. defining an own transport type for it and assign transport orders to be cancelled to the respective transport type). But these workarounds were not good enough for most of customer businesses and therefore we introduced a new way of cancelling transport orders.
The idea is that a cancel status (with a reason) can be added to the transport order, to mark a order as cancelled. It also has a certain impact on existing delivery planning - the transport legs (and tours) that are not yet "confirmed" are removed, order is returned back either to original delivery hub or to custom location.
The functionality is launched via "Cancel" menuitem in the transport order form.
The process can be also undone, via "Undo cancellation" menuitem in the transport order form.
* Quantity split – A transport order that is split in quantity cannot be cancelled anymore. In this case, the user can e.g. manually change the unloading address of the transport leg.
* Cancellation will not be allowed in case there exists a sub-contracting or intercompany involved for the transport legs that have to be cancelled.
* In case the cancel status will be removed from the transport order (ie. via "Undo cancellation"), there is no automatic update on the related transport legs, so the legs should be handled/reviewed individually and manually
|TAL 10.0-CAP7.00||User Story||56572||Customer order management & pricing|
Possibility to send a track & trace status messages per package
Previously the track and trace status message framework operated on the transport order, transport leg and tour order line level. This feature was improved with an additional, deeper level: packages. Hence a separate track and trace status message can generated for each package.
* Parameter "Message per package" has to be activated on the status message setup (CAPcargo Transport -> Setup -> Track and Trace -> Status message setup
Also the status message template (and the status message criteria) forms were enhanced to be able to send status messages only for certain package transactions/identifications etc.
|TAL 10.0-CAP7.00||User Story||26022||Dispatching & confirmation|
New functionality of "resource swap" is introduced to tour planning
A new functionality of "resource swap" was introduced to tour planning. The idea is that motor vehicle & driver resources are exchanged between two tours, on selected address, on selected time. Together with resource swap a new tour stops are inserted to both tours (ie. swap location), and new "dock"/"undock" activities are inserted to tour stop (with swap location). Also the tour scheduling is adjusted (to respect the swap time), by inserting a "waiting" activity when necessary.
This allows the dispatchers to operationally optimize the tour planning, by detaching the trailer (with goods) from original truck (that did the goods pick up) to new truck (that will do the goods delivery).
Functionality works in following way:
* Dispatchers should multi-select two tours that should participate in "resource swap"
* Press button "Resource swap" in "Dispatch light - Tours" form
* In "resource swap" dialog select on which position the resource swap should happen (ie. by putting focus on desired tour stop in each tour). The system inserts swap location before the selected tour stop position.
* Define the swap location & swap time in the below grid of "resource swap" dialog
* Confirm the resource swap by "Swap resources" button in the Functions ribbon
Current limitations of the resource swap functionality:
* System does not validate the resource swap time, so users can define any swap time (eg. even in the past). That means that users be careful (and also properly trained) to use some meaningful swap time
* There is no "undo" option of the resource swap. In case the resource swap should be removed, it has to be done manually (ie. remove resources from tours, extend the motor vehicle & driver resource assignments, remove the swap locations).
* Both tours participating in resource swap are not anyhow internally linked together, meaning it is possible to see which tour was swapped with which tour only from the resource allocation level (eg. two consecutive sets of truck&driver were participating on delivery of one trailer).
* The resource swap functionality can be used only in the "Dispatch light - Tours" form, it is not yet accessible in the GPB. But with certain parameterization (and small limitation) it can be already now activated in GPB via "custom/generic" buttons.
|TAL 10.0-CAP7.00||User Story||54449||Dispatching & confirmation|
New feature of "Failed delivery" is introduced to tour confirmation
It may happen that transport orders can not be delivered (e.g. receiver is not present). In these cases, the transport order can be sent back to a predefined location (or to original delivery hub) and a new transport leg is created to be planned by the dispatcher for another delivery attempt. Also, for each failed delivery attempt, the value of a counter – in the transport order header – is increased by one, which can be the base of surcharge calculation.
Additionally the order track & trace (and order status message) functionalities were enhanced, to inform properly about the failed delivery.
The feature is launched by menuitem "Delivery of tour order line failed" in the Functions of tour confirmation form and can be launched only for the last delivery leg.
|TAL 10.0-CAP7.00||User Story||57629||Dispatching & confirmation|
Enhancement of the capacity route/tour planning process, to create new tour when capacity limit of previous tour (of same route) was reached
When route capacity was exceeded on the existing tour (and load/unload address was not yet being served on this tour), then previously "Generate/Update tour out of route/zone" planning process did not automatically create a new tour and transport legs were left unplanned (and user was informed by infolog). This was enhanced and now the "Generate/Update tour out of route/zone" planning process automatically creates a new tour (and allocated transport legs) when the capacity is exceeded on the existing tour (and load/unload address is not yet being served on this tour).
|TAL 10.0-CAP7.00||Bug||56717||Customer order management & pricing|
Load & unload address names were not printed on the pallet label
Pallet label SSRS report (eg. printout) was enhanced to include also the load & unload address names.
|TAL 10.0-CAP7.00||Bug||44061||Dispatching & confirmation|
Button "Edit" was removed from "Sub-contracting transport leg (LTL)" form (when called from GST/GSR) as obsolete
Button "Edit" was removed from "Sub-contracting transport leg (LTL)" form (when called from GST/GSR) as obsolete, as the form already starts in "edit" mode by default and further attempts to press button had some negative side effects.
|TAL 10.0-CAP7.00||Bug||56479||Dispatching & confirmation|
In some constellations the manually specified ETA figures on tour stops were not respected during tour confirmation
In some constellations the manually specified ETA figures on the tour stops were not respected during the tour confirmation process. This could lead to incorrect tour duration visualization after/during the tour confirmation (eg. tour 'shrinking'). The issue was corrected - now the manual ETA is respected in the tour confirmation process.
Also the 'Tour activity' update mechanism was enhanced, to respected the manual ETA figures during tour confirmation process.
|TAL 10.0-CAP7.00||Bug||56638||Dispatching & confirmation|
"Generate/Update tour out of route/zone" functionality (when used with parameter "Find and update existing tours"=FALSE) was in certain cases not planning all transport legs into tours
Previously when the "Find and update existing tours" parameter was switched off (in the "Generate/Update tour out of route/zone" dialog) then the resulting tour structure was not correct in certain constellation. Especially when there were more transport legs (belonging to various routes) being planned. This was corrected, now (in such constellation) the system correctly produces one tour per each route.
|TAL 10.0-CAP7.00||Bug||56736||Dispatching & confirmation|
The loading date (and time) of successor transport legs was initialized from the transport order header load date (and time)
When the transport legs were automatically split (via 'Cross docking rule') then the loading date & time on successor transport legs were populated from transport order header load date & time. This was corrected - the loading date & time of transport leg is initialized from transport order header load date & time only on the first transport leg.
|TAL 10.0-CAP7.00||Bug||57606||Dispatching & confirmation|
Correction of the "View details tour" context option in GST & GSR
Following points were correct for "View details tour" context option (ie. 'right mouse click' on tour):
* the label shows proper translation in different language mutations
* the label is properly aligned with other labels
|TAL 10.0-CAP7.00||Bug||58503||Dispatching & confirmation|
In several forms the transport unit id was concatenated, showing only first 10 characters of transport unit id (despite the transport unit id can have 20 characters)
Previously on several forms only the first 10 characters of transport unit id were shown. Eg. in tour confirmation, in conflict manager etc. This was corrected - now the full transport unit id is shown on these forms (ie. maximum of 20 characters).