UG 281363 New CTMS Execution Screen: Difference between revisions

From Calidus HUB
VisualWikitext
(Created page with "== Solution Overview == A new Execution screen will be created. The screen will allow all of the functionality of the existing Trip Debrief screen, plus modifications to allow ...")
 
 
(14 intermediate revisions by the same user not shown)
Line 1: Line 1:
__NOTOC__
== Solution Overview  ==
== Solution Overview  ==
A new Execution screen will be created.
A new Execution screen will be created.
Line 7: Line 8:
*Driver Exception Handling
*Driver Exception Handling


The screen will be optimised for each trip status, showing the user the necessary data entries for each step, depending on the status of the order.
The screen is optimised for each trip status, showing the user the necessary data entries for each step, depending on the status of the order.


Extensive use of popups will be used to ensure that the entry of the data is a seamless as possible, directing the user to enter the data in as close a way to the operational requirement as possible.
Extensive use of pop-ups are used to ensure that the entry of the data is a seamless as possible, directing the user to enter the data in as close a way to the operational requirement as possible.


An increased auditing level will be added, as well as Load ID visibility, to allow users to see how the new functionality would integrate into the existing process.
An increased auditing level will be added, as well as Load ID visibility, to allow users to see how the new functionality would integrate into the existing process.
Line 15: Line 16:
The styling of the product will approach DHL standards and colour schemes, to show the styling capability of the new product UI.
The styling of the product will approach DHL standards and colour schemes, to show the styling capability of the new product UI.


Efforts have been made to ensure that the system is entirely cross-browser compatible, and touch-screen capable.


Auto-complete - This shows data in the database by matching against the user's entry as they enter it. The functionality provides a seamless lookup system. Note that this is buffered, to prevent unnecessary requests to the database and reduce load.
==Technology==
The Web Application is written using the Visual Studio development environment, utilising the following functionality:
*ASP.NET (for forms design)
*Database access tools (access to any database type, including Oracle)
*C# (for server access)
*JavaScript
*AJAX Tool-kit
*Web Services


Tab blocks - These allow panels of data to be shown or hidden by clicking on the tab required. These blocks help make better use of available screen space
The system has been written accessing a demo database created in Microsoft SQL Server 2008, the design of which is based on the CTMS Trips and Order tables.


Accordion blocks - These allow data to be shown or hidden by clicking on the title bar. These blocks help make better use of available screen space, as an alternative to Tab blocks.
The system is hosted on a Microsoft Windows 2003 server, through IIS 8.


Resizing blocks/data elements - blocks of data are only as big as they need to be, resulting in better use of screen space. Labels and data will resize based on the resolution of the screen, to better support lower-resolution devices. Where the resolution is too low to show all data, scroll-bars are then used, both within panels and for the entire screen.
==UI Features==
'''Auto-complete''' - This shows data in the database by matching against the user's entry as they enter it. The functionality provides a seamless lookup system. Note that this is buffered, to prevent unnecessary requests to the database and reduce load.


Validator Call-outs - these display pop-up bubbles next to data that has failed validation, making it easier to validate and enter whole blocks of data without having to submit data several times. As each validation error is cleared, the call-outs will disappear. Note that the call-outs can be created to link through to further screens (for example, to call a maintenance screen to enter data).
'''Tab blocks''' - These allow panels of data to be shown or hidden by clicking on the tab required. These blocks help make better use of available screen space


Modal Popups - these pop-up screens are used extensively throughout the product. They allow for cleaner entry of data, by expanding and extending the data being entered from the normal screen. They make the entry of data cleaner and easier and enhance readability.
'''Accordion blocks''' - These allow data to be shown or hidden by clicking on the title bar. These blocks help make better use of available screen space, as an alternative to Tab blocks.


Adjustable Grids - Grids of data can be manipulated when using the screen to show only the data required at this stage. Further, the data in the grids can be paged (to save space), sorted (for ease of use), user-definable (manually choosing columns to display) and editable (for direct data entry into the grid).
'''Resizing blocks/data elements''' - blocks of data are only as big as they need to be, resulting in better use of screen space. Labels and data will resize based on the resolution of the screen, to better support lower-resolution devices. Where the resolution is too low to show all data, scroll-bars are then used, both within panels and for the entire screen.


Links - web-based systems make extensive use of links. This allows the systems that use them to interoperate between screens without having to add space-expensive buttons.  
'''Validator Call-outs''' - these display pop-up bubbles next to data that has failed validation, making it easier to validate and enter whole blocks of data without having to submit data several times. As each validation error is cleared, the call-outs will disappear. Note that the call-outs can be created to link through to further screens (for example, to call a maintenance screen to enter data).


Masked Edit Boxes
'''Modal Popups''' - these pop-up screens are used extensively throughout the product. They allow for cleaner entry of data, by expanding and extending the data being entered from the normal screen. They make the entry of data cleaner and easier and enhance readability.


== Scope  ==
'''DragPanel''' - these pop-ups can be dragged around, allowing visibility of the screen behind.
This is a prototype, showing the capability. There is a simplified database in use in the back-end, with demonstration data. It is unlikely that updating data will be required but, where possible, the prototype will incorporate this.
 
'''Adjustable Grids''' - Grids of data can be manipulated when using the screen to show only the data required at this stage. Further, the data in the grids can be paged (to save space), sorted (for ease of use), user-definable (manually choosing columns to display) and editable (for direct data entry into the grid).
 
'''Links''' - web-based systems make extensive use of links. This allows the systems that use them to interoperate between screens without having to add space-expensive buttons.
 
'''Map Links''' - trips can be viewed through Google Maps, showing stops and current position, if available.
 
'''Scrolling Marquee''' - a scrolling marquee is used to show important messages of tasks that need to be actioned. These messages may link to further screens within the system.
 
'''Hover Menu''' - Hover menus are used to display actions required. This saves space, as the options are only displayed when the user hovers over them.
 
'''Tool-tips''' - this is pop-up help that appears when user hover over buttons. This allows individual help text to be placed against each item on the screen, to help beginner users understand their uses.


<!-- NEW PAGE -->
'''Masked Edit Boxes''' - these prevent invalid entry into fields, for example, time are prevented from being entered with invalid times. This is done within the browser and prevents invalid data being submitted to the server, increasing data validation and decreasing server load.


= Set-up =
'''Pop-up Calendar''' - These show a full calendar and can be styled and ranged, to ensure that only valid date information can be entered.


== Pre-requisites  ==
Additional functionality available but not demonstrated here:
*Drag and Drop
*AlwaysVisibleControl
*Animation
*AsyncFileUpload
*CascadingDropDown
*CollapsiblePanel
*ColorPicker
*ComboBox
*ConfirmButton
*DropDown
*DropShadow
*DynamicPopulate
*FilteredTextBox
*ListSearch
*MultiHandleSlider
*MutuallyExclusiveCheckBox
*NumericUpDown
*PagingBulletedList
*PopupControl
*ReorderList
*ResizableControl
*RoundedCorners
*Slider
*SlideShow
*TextBoxWatermark
*ToggleButton


== Menu Structure  ==
Note that there is other functionality that can be added as standard (for example, graphs, charts, images) - this list is simply the standard tool-set available to the UI.


== Data ==
== Scope ==
This is a prototype, showing the capability. There is a simplified database in use in the back-end, with demonstration data. It is unlikely that updating data will be required but, where possible, the prototype will incorporate this.


<!-- NEW PAGE -->  
<!-- NEW PAGE -->  
Line 51: Line 99:
= C-TMS Execution Screen  =
= C-TMS Execution Screen  =
The screen begins by requesting the user to find a trip. This can be through the traditional CTMS mechanism of choosing a schedule and a trip from the drop-down lists provided, or by directly entering a trip in the provided box. Simply typing part of the Trip ID will match all similar trips, which can be selected from the list. This is an example of an Auto-complete entry box.
The screen begins by requesting the user to find a trip. This can be through the traditional CTMS mechanism of choosing a schedule and a trip from the drop-down lists provided, or by directly entering a trip in the provided box. Simply typing part of the Trip ID will match all similar trips, which can be selected from the list. This is an example of an Auto-complete entry box.
[[File:CTMS-UI-1.png|border|600px]]


Once selected (by clicking the provided button), the screen displays the trip details.
Once selected (by clicking the provided button), the screen displays the trip details.
Line 65: Line 115:


The screen makes use of Accordion blocks for the different areas of data (there are 3 panels: data entry, Orders list and Trip Stops list), and Tab blocks for data entry.  
The screen makes use of Accordion blocks for the different areas of data (there are 3 panels: data entry, Orders list and Trip Stops list), and Tab blocks for data entry.  
A scrolling marquee is shown, displaying information on tasks to be actioned - each can be clicked, to take the user to a screen pertaining to the task.


Each status of the Trip is covered below, showing the main features.
Each status of the Trip is covered below, showing the main features.


==Planned==
==Planned==
Example: MAN-00000013
[[File:CTMS-UI-2.png|border|600px]]


A General tab is displayed and open for the Trip, showing general data and allowing the user to enter and view Vehicle and Driver. Drop-down lists are used for these elements. Validation is performed and displayed in-line through Validator Call-outs.  
A General tab is displayed and open for the Trip, showing general data and allowing the user to enter and view Vehicle and Driver. Drop-down lists are used for these elements. Validation is performed and displayed in-line through Validator Call-outs.  


Optionally, the user may enter and view Crew and Instructions information, by clicking on the appropriate button. These are entered and validated through a Modal pop-up screen.
Optionally, the user may enter and view Crew and Instructions information, by clicking on the appropriate button. These are entered and validated through a Modal pop-up screen, allowing dragging of the panels.
 
[[File:CTMS-UI-2a.png|border|600px]]


When a driver and vehicle have been entered, the user will be prompted to change the status to Accepted if required.
When a driver and vehicle have been entered, the user will be prompted to change the status to Accepted if required.
Line 82: Line 139:
Re-plan and Add Stop buttons are available from this point, to call additional screens (not part of prototype).
Re-plan and Add Stop buttons are available from this point, to call additional screens (not part of prototype).


==Accepted==
A View Map button is provided, to show details of the stops on the trip and route planning.
Re-plan and Add Stop links will be available from this point, to call additional screens (not part of prototype).


Entry button to show status of trip, allowing change to next status only.
[[File:CTMS-UI-2c.png|border|600px]]
At this stage, write an audit entry and link to Trip, Driver.


If change to next status, check that the Driver Brief and Despatched Quantities information has been entered - if not, popup validation forcing entry as below (automatically switching between tabs/accordions as necessary.
==Accepted==
Example: MAN-00000012


Accordion display
[[File:CTMS-UI-3.png|border|600px]]
First accordion panel, two tabs, general (from above) then


Driver Brief panel (open)
A Driver Brief panel is displayed and open for the user to confirm key information about the trip, vehicle and driver before the trip begins. The General tab is still visible if required.


Some questions with tick box and entry:
The user is also able to enter the shift start time here. This utilises a masked entry field.
*Keys given to driver
*Advise of route and vehicle
*Advise of TLC drops of Traffic Issues
*Check Driving License
*Enter shift start time - time entry only.
*Ops 13 checks carried out
All are required.


Save button.
The Orders list now displays Despatch quantities, which are required to be entered before the Trip can be set to En Route - they will be prompted to enter these if they haven't already been entered.


User must enter all values.
Despatched quantities can be set from planned using the Planned button. Additionally, each order can be edited or set from planned using the Hover Menu against each grid line. Editing a line will show a pop-up window with the information to enter.
Validation popups if not entered.


Saving this will prompt the user to change the status to En Route.
[[File:CTMS-UI-3a.png|border|600px]]


Accordion Panel (closed) with ability to see order details grid as above, plus Despatched quantities:
Once all data has been entered, the user is able to change the status to En Route by using the button provided.
*Stop
*Load Location
*Stop
*Unload location
*Cust Ref
*Planned and despatched qty, weight and Volume, UOMs together
*Load Number
Despatched quantities must be entered.
 
Button under despatched quantities to allow all to be set to planned quantities (if not already entered).
 
Save button.
 
Panel (not part of accordion) with Grid of Stops under tab panel as above.


==En Route==
==En Route==
Re-plan and Add Stop links will be available from this point, to call additional screens (not part of prototype).
Example: MAN-00000006


Entry button to show status of trip, allowing change to next status only.
[[File:CTMS-UI-4.png|border|600px]]


History link will be available from this point, to call a separate screen with the Trip ID as a parameter.
From this stage forward, a History button is available to show any audit history against the screen .


If change to next status, check that the Order Quantities and Trip Times have all been been entered - if not, popup validation forcing entry as below. Also needs to check that at least a Start and End ODO have been entered.
A Driver ODO panel is displayed and open for the user to enter Date, Time, Odometer, Fuel and Mileage information. All previous tabs are still visible if required. Dates and Times are through masked entry fields, with the date showing  a pop-up calendar control.


At this stage, write an audit entry and link to Trip, Tractor, Driver.
The Orders list now displays Delivered quantities, which are required to be entered before the Trip can be set to Complete - the user will be prompted to enter these if they haven't already been entered.


Accordion display
Delivered quantities can be set from despatched using the Despatch button. Additionally, each order can be edited or set from despatch using the Hover Menu against each grid line. Reason codes and comments will be prompted for if there are any discrepancies.
First accordion panel (closed), three tabs, General, Driver Brief (from above) then:
Driver ODO:
*Grid showing
*Date
*Time
*Type (Start/End/Fuel)
*Mileage
*Fuel Drawn
Save button


Can add records at any time for any type.
The Trip Stop list now includes Actual arrival and depart dates and times, and ETA Dates and Times.
At this stage, write an audit entry and link to Trip, Tractor, Driver.


Second accordion panel (open) with ability to see order details grid as above, plus Delivered quantities:
The Actual Dates and Times can be from planned using the Planned button. Additionally, each stop can be edited or set from planned using the Hover Menu against each grid line. Editing a line will show a pop-up window with the information to enter, and a reason code if required. If orders are being delivered against the stop, a pop-up entry window will be shown to enter the delivered quantities against each order delivered.
*Stop
*Load Location
*Stop
*Unload location
*Cust Ref
*Planned, despatched and Delivered qty, weight and Volume, UOMs together
*Reason Code
*Load Number
Delivered quantities must be entered.
If the delivered quantity entered does not match the Despatched quantities, a Reason code must be entered. Do this through a Popup, allowing entry of reason code and displaying description. A comment box should also be allowed.
A Trip audit should be written if this is the case.


Button under delivered quantities to allow all to be set to despatched quantities (if not already entered).
[[File:CTMS-UI-4a.png|border|600px]]


Panel (not part of accordion) with Grid of Stops under tab panel as above.
ETA dates and times are forecast from outside the CTMS system. If they are available, the screen will display these with RAG-colouration:
Also add:
*If the ETA against a stop is later than the delivery window of any orders associated to that stop, the background is coloured red.
*Actual arrival and depart date and time.
*Otherwise, the background is coloured green.
*ETA arrival date and time.
*Actual Distance - entered
*Actual Time - calculated


Actual arrival and depart date and time and actual distance for each stop can be entered.
The popup menu on a Red-coloured ETA stop pops up a window allowing the user to email all affected customers with their new ETA.
Only the first row's data can be entered initially.


On entry of first stop's actual arrival/depart date and time, check whether delivered quantities entered for all orders to that stop. If not, pop open an entry grid for the orders only, forcing entry of quantities and reason code as above. When entered and saved, update the orders panel above.
[[File:CTMS-UI-4b.png|border|600px]]


Also at this stage, check the arrival time against the delivery window against the orders associated to the stop. If the arrival time is outside the window associated to the order(s), pop up a window showing the orders affected and prompt to enter a reason code as before. This reason should be applied to all affected orders. A Trip Audit should be written if this is the case.
When all quantities and dates have been entered, the user is prompted as to whether they can change the status to Completed. This can be done through the button at the top of the screen.
 
Once first entered, can save - that's OK.
At this stage, write an audit entry and link to Trip, Tractor, Driver.
 
The user can then continue entering against the following stops one by one.
 
ETA dates and times will be forecast from outside the system. If they are available, the system needs to RAG-colour the ETA fields:
*If the ETA against a stop is later than the delivery window of any orders associated to that stop, the background should be coloured red.
*Otherwise, the background should be coloured green.
Furthermore, the following stops should then be checked based on the new calculated ETA depart and planned drive time against the stop, to predict an ETA against these lines. The same check should be performed against these following trips. If any of these further calculated ETAs are outside the delivery window of any orders associated to the stop, the ETA fields should be coloured Amber.
 
Clicking on a Red-coloured ETA field should pop up a window allowing the user to email all affected customers with their new ETA.
 
Button under Actual Dates/Times to set to Planned (if not already set)
 
When all quantities and dates entered, prompt user whether they want to change status to Completed.


==Completed==
==Completed==
Entry button to show status of trip, allowing change to next status only.
Example: MAN-00000001


History link will be available from this point, to call a separate screen with the Trip ID as a parameter.
[[File:CTMS-UI-5.png|border|600px]]


If change to next status, check that the Driver Debrief information has been entered – if not, popup validation forcing entry as below (automatically switching between tabs/accordions/popups as necessary.
A Driver Debrief panel is displayed and open for the user to confirm key information about the trip, vehicle and driver after the trip ends. All other tabs are still visible if required.
At this stage, write an audit entry and link to Trip, Driver.


Accordion display
The user is also able to enter the shift end time here. This utilises a masked entry field.
First accordion panel (open), four tabs, General, Driver Brief, Driver ODO (from above) then:


Driver Debrief tab:
The user is also able to display Driver Discrepancies here, which pops up a window showing all discrepancies (for example, late arrivals, departures, delivered quantity changes) in a grid. A comment can be added per discrepancy.
Checklist of items:
*Ops 13 Carried out
*Defect Found
*Tick Vosa Checked Vehicle
*Update Fleet Compliance Check List
*Button to show Driver Discrepancies
*Checkbox to show discrepancies dealt with
*Shift End Time entry


Save button
[[File:CTMS-UI-5a.png|border|600px]]


Driver Discrepancies pops up a window showing:
When all information has been entered, the user is prompted as to whether they can change the status to Debriefed. This can be done through the button at the top of the screen.
 
All numbered discrepancies (late arrivals, departures, delivered quantity changes) in a grid.
 
A comment should be allowed to be added per discrepancy.
 
Save button
 
When all data entered, ask user whether they want the status to go to Debriefed.


==Debriefed==
==Debriefed==
Example: MAN-00000010


Entry button to show status of trip, allowing change to next status only.
[[File:CTMS-UI-6.png|border|600px]]


History link will be available from this point, to call a separate screen with the Trip ID as a parameter.
The Orders list now displays a POD check, to enter whether PODs have been received for each order.These are required to be checked before the Trip can be set to Confirmed - the user will be prompted to enter these if they haven't already been entered. All PODs can be set as received by using the POD All button.


If change to next status, check that the POD information has been entered – if not, popup validation forcing entry as below (automatically switching between tabs/accordions/popups as necessary.
When all information has been entered, the user is prompted as to whether they can change the status to Confirmed. This can be done through the button at the top of the screen.
At this stage, write an audit entry and link to Trip.
 
Accordion display
 
As above, with Orders panel (shown) allowing entry of POD at end of grid - all other items display only.
 
The POD entry will consist of a series of check boxes against the grid, with a button under to set all as received. If the POD is set, provide a button/icon to view the POD through a popup.
 
 
Trips panel can now be closed as part of the accordion.


==Confirmed==
==Confirmed==
Example: MAN-00000011


History link will be available from this point, to call a separate screen with the Trip ID as a parameter.
[[File:CTMS-UI-7.png|border|600px]]


Accordion display
A Finance panel is displayed and open for the user to enter Payments information. All previous tabs are still visible if required.


As above, but with Finance tab (part of general accordion) shown:
<!-- NEW PAGE -->
Show grand total of payments and button to add new payments.
 
Trips panel closed as part of the accordion.


=Audit Screen=
=Audit Screen=
Audit records are written at one of three levels (Trip, Tractor, Driver) at various stages in the process above.
Example: MAN-00000011
This screen reports on them.


Screen accepts parameters of Trip, Trailer or Driver.
[[File:CTMS-UI-8.png|border|600px]]


For Trip - display all records found.
Audit records will written at one of three levels (Trip, Tractor, Driver) at various stages in the process.
Any others, limit to 20 to a page.
This screen reports on those records.


For Trip, get Audit Type records of Trip for the supplied Trip ID.
The screen allows the user to select through multiple parameters, although only Trip is currently enabled.
For Tractor, get Audit Type records of Tractor for the supplied Tractor ID
For Driver, get Audit Type records of Trip for the supplied Driver.


The page should display the information in the audit record, plus links for whatever other levels this audit record links to.
When selected, the grid displays all audit records associated to that trip.


So, we have the following:
=Load Screen=
 
Example: LOAD5
Audit 1, with information "Driver Briefed" is linked to the Trip ID and the Driver ID


Audit 2, with information "Trip En-Route" is linked to the Trip ID, Tractor ID and Trailer ID.
[[File:CTMS-UI-9.png|border|600px]]


etc.
This screen shows all orders associated to the Load ID passed in or selected from the provided auto-complete list.


If we search for the Trip ID, we will return both audit records.
When selected, the grid displays all orders and trips which are marked against that load.


If we search for the Tractor ID, we will get only audit 2.
The grid is configurable (through the Config button and pop-up) and sortable through the column titles.
 
If the user clicks a link against an audit, call the same screen with the new parameter.
 
There should be a capability to click an audit record and see all the details, showing comments entered against the audit, and an ability to add more comments.
 
=Load Screen=
This screen shows all orders associated to the load ID passed in.

Latest revision as of 17:41, 2 November 2011

Solution Overview

A new Execution screen will be created.

The screen will allow all of the functionality of the existing Trip Debrief screen, plus modifications to allow for:

  • Extended ODO entry
  • Driver Briefing
  • Driver Exception Handling

The screen is optimised for each trip status, showing the user the necessary data entries for each step, depending on the status of the order.

Extensive use of pop-ups are used to ensure that the entry of the data is a seamless as possible, directing the user to enter the data in as close a way to the operational requirement as possible.

An increased auditing level will be added, as well as Load ID visibility, to allow users to see how the new functionality would integrate into the existing process.

The styling of the product will approach DHL standards and colour schemes, to show the styling capability of the new product UI.

Efforts have been made to ensure that the system is entirely cross-browser compatible, and touch-screen capable.

Technology

The Web Application is written using the Visual Studio development environment, utilising the following functionality:

  • ASP.NET (for forms design)
  • Database access tools (access to any database type, including Oracle)
  • C# (for server access)
  • JavaScript
  • AJAX Tool-kit
  • Web Services

The system has been written accessing a demo database created in Microsoft SQL Server 2008, the design of which is based on the CTMS Trips and Order tables.

The system is hosted on a Microsoft Windows 2003 server, through IIS 8.

UI Features

Auto-complete - This shows data in the database by matching against the user's entry as they enter it. The functionality provides a seamless lookup system. Note that this is buffered, to prevent unnecessary requests to the database and reduce load.

Tab blocks - These allow panels of data to be shown or hidden by clicking on the tab required. These blocks help make better use of available screen space

Accordion blocks - These allow data to be shown or hidden by clicking on the title bar. These blocks help make better use of available screen space, as an alternative to Tab blocks.

Resizing blocks/data elements - blocks of data are only as big as they need to be, resulting in better use of screen space. Labels and data will resize based on the resolution of the screen, to better support lower-resolution devices. Where the resolution is too low to show all data, scroll-bars are then used, both within panels and for the entire screen.

Validator Call-outs - these display pop-up bubbles next to data that has failed validation, making it easier to validate and enter whole blocks of data without having to submit data several times. As each validation error is cleared, the call-outs will disappear. Note that the call-outs can be created to link through to further screens (for example, to call a maintenance screen to enter data).

Modal Popups - these pop-up screens are used extensively throughout the product. They allow for cleaner entry of data, by expanding and extending the data being entered from the normal screen. They make the entry of data cleaner and easier and enhance readability.

DragPanel - these pop-ups can be dragged around, allowing visibility of the screen behind.

Adjustable Grids - Grids of data can be manipulated when using the screen to show only the data required at this stage. Further, the data in the grids can be paged (to save space), sorted (for ease of use), user-definable (manually choosing columns to display) and editable (for direct data entry into the grid).

Links - web-based systems make extensive use of links. This allows the systems that use them to interoperate between screens without having to add space-expensive buttons.

Map Links - trips can be viewed through Google Maps, showing stops and current position, if available.

Scrolling Marquee - a scrolling marquee is used to show important messages of tasks that need to be actioned. These messages may link to further screens within the system.

Hover Menu - Hover menus are used to display actions required. This saves space, as the options are only displayed when the user hovers over them.

Tool-tips - this is pop-up help that appears when user hover over buttons. This allows individual help text to be placed against each item on the screen, to help beginner users understand their uses.

Masked Edit Boxes - these prevent invalid entry into fields, for example, time are prevented from being entered with invalid times. This is done within the browser and prevents invalid data being submitted to the server, increasing data validation and decreasing server load.

Pop-up Calendar - These show a full calendar and can be styled and ranged, to ensure that only valid date information can be entered.

Additional functionality available but not demonstrated here:

  • Drag and Drop
  • AlwaysVisibleControl
  • Animation
  • AsyncFileUpload
  • CascadingDropDown
  • CollapsiblePanel
  • ColorPicker
  • ComboBox
  • ConfirmButton
  • DropDown
  • DropShadow
  • DynamicPopulate
  • FilteredTextBox
  • ListSearch
  • MultiHandleSlider
  • MutuallyExclusiveCheckBox
  • NumericUpDown
  • PagingBulletedList
  • PopupControl
  • ReorderList
  • ResizableControl
  • RoundedCorners
  • Slider
  • SlideShow
  • TextBoxWatermark
  • ToggleButton

Note that there is other functionality that can be added as standard (for example, graphs, charts, images) - this list is simply the standard tool-set available to the UI.

Scope

This is a prototype, showing the capability. There is a simplified database in use in the back-end, with demonstration data. It is unlikely that updating data will be required but, where possible, the prototype will incorporate this.


C-TMS Execution Screen

The screen begins by requesting the user to find a trip. This can be through the traditional CTMS mechanism of choosing a schedule and a trip from the drop-down lists provided, or by directly entering a trip in the provided box. Simply typing part of the Trip ID will match all similar trips, which can be selected from the list. This is an example of an Auto-complete entry box.

CTMS-UI-1.png

Once selected (by clicking the provided button), the screen displays the trip details.

The details displayed are relevant to the status of the trip:

  • Planned
  • Accepted
  • En Route
  • Complete
  • Debriefed
  • Confirmed

A top panel is shown to display the current Status of the Trip, allow moving to the next Status, and optionally display an audit history of the trip.

The screen makes use of Accordion blocks for the different areas of data (there are 3 panels: data entry, Orders list and Trip Stops list), and Tab blocks for data entry.

A scrolling marquee is shown, displaying information on tasks to be actioned - each can be clicked, to take the user to a screen pertaining to the task.

Each status of the Trip is covered below, showing the main features.

Planned

Example: MAN-00000013

CTMS-UI-2.png

A General tab is displayed and open for the Trip, showing general data and allowing the user to enter and view Vehicle and Driver. Drop-down lists are used for these elements. Validation is performed and displayed in-line through Validator Call-outs.

Optionally, the user may enter and view Crew and Instructions information, by clicking on the appropriate button. These are entered and validated through a Modal pop-up screen, allowing dragging of the panels.

CTMS-UI-2a.png

When a driver and vehicle have been entered, the user will be prompted to change the status to Accepted if required.

The screen also displays a list of Orders on the Trip. Only the columns required at this stage are shown (for example, no Delivered quantities or POD are displayed at this stage). Note that the grid also shows a link to the Load number associated to the Order - clicking this will allow you to see all orders and trips associated to that load.

A list of Trip stops is shown at the bottom of the screen. Again, all unnecessary columns have been removed, and data cannot be edited at this stage.

Re-plan and Add Stop buttons are available from this point, to call additional screens (not part of prototype).

A View Map button is provided, to show details of the stops on the trip and route planning.

CTMS-UI-2c.png

Accepted

Example: MAN-00000012

CTMS-UI-3.png

A Driver Brief panel is displayed and open for the user to confirm key information about the trip, vehicle and driver before the trip begins. The General tab is still visible if required.

The user is also able to enter the shift start time here. This utilises a masked entry field.

The Orders list now displays Despatch quantities, which are required to be entered before the Trip can be set to En Route - they will be prompted to enter these if they haven't already been entered.

Despatched quantities can be set from planned using the Planned button. Additionally, each order can be edited or set from planned using the Hover Menu against each grid line. Editing a line will show a pop-up window with the information to enter.

CTMS-UI-3a.png

Once all data has been entered, the user is able to change the status to En Route by using the button provided.

En Route

Example: MAN-00000006

CTMS-UI-4.png

From this stage forward, a History button is available to show any audit history against the screen .

A Driver ODO panel is displayed and open for the user to enter Date, Time, Odometer, Fuel and Mileage information. All previous tabs are still visible if required. Dates and Times are through masked entry fields, with the date showing a pop-up calendar control.

The Orders list now displays Delivered quantities, which are required to be entered before the Trip can be set to Complete - the user will be prompted to enter these if they haven't already been entered.

Delivered quantities can be set from despatched using the Despatch button. Additionally, each order can be edited or set from despatch using the Hover Menu against each grid line. Reason codes and comments will be prompted for if there are any discrepancies.

The Trip Stop list now includes Actual arrival and depart dates and times, and ETA Dates and Times.

The Actual Dates and Times can be from planned using the Planned button. Additionally, each stop can be edited or set from planned using the Hover Menu against each grid line. Editing a line will show a pop-up window with the information to enter, and a reason code if required. If orders are being delivered against the stop, a pop-up entry window will be shown to enter the delivered quantities against each order delivered.

CTMS-UI-4a.png

ETA dates and times are forecast from outside the CTMS system. If they are available, the screen will display these with RAG-colouration:

  • If the ETA against a stop is later than the delivery window of any orders associated to that stop, the background is coloured red.
  • Otherwise, the background is coloured green.

The popup menu on a Red-coloured ETA stop pops up a window allowing the user to email all affected customers with their new ETA.

CTMS-UI-4b.png

When all quantities and dates have been entered, the user is prompted as to whether they can change the status to Completed. This can be done through the button at the top of the screen.

Completed

Example: MAN-00000001

CTMS-UI-5.png

A Driver Debrief panel is displayed and open for the user to confirm key information about the trip, vehicle and driver after the trip ends. All other tabs are still visible if required.

The user is also able to enter the shift end time here. This utilises a masked entry field.

The user is also able to display Driver Discrepancies here, which pops up a window showing all discrepancies (for example, late arrivals, departures, delivered quantity changes) in a grid. A comment can be added per discrepancy.

CTMS-UI-5a.png

When all information has been entered, the user is prompted as to whether they can change the status to Debriefed. This can be done through the button at the top of the screen.

Debriefed

Example: MAN-00000010

CTMS-UI-6.png

The Orders list now displays a POD check, to enter whether PODs have been received for each order.These are required to be checked before the Trip can be set to Confirmed - the user will be prompted to enter these if they haven't already been entered. All PODs can be set as received by using the POD All button.

When all information has been entered, the user is prompted as to whether they can change the status to Confirmed. This can be done through the button at the top of the screen.

Confirmed

Example: MAN-00000011

CTMS-UI-7.png

A Finance panel is displayed and open for the user to enter Payments information. All previous tabs are still visible if required.


Audit Screen

Example: MAN-00000011

CTMS-UI-8.png

Audit records will written at one of three levels (Trip, Tractor, Driver) at various stages in the process. This screen reports on those records.

The screen allows the user to select through multiple parameters, although only Trip is currently enabled.

When selected, the grid displays all audit records associated to that trip.

Load Screen

Example: LOAD5

CTMS-UI-9.png

This screen shows all orders associated to the Load ID passed in or selected from the provided auto-complete list.

When selected, the grid displays all orders and trips which are marked against that load.

The grid is configurable (through the Config button and pop-up) and sortable through the column titles.

Retrieved from ‘https://calidusassist.adcservices.apteancloud.com/calidus-assist/OBS/index.php?title=UG_281363_New_CTMS_Execution_Screen&oldid=316’