FS 356513 Assigning Jobs to Users: Difference between revisions
(v1.0 - Issued after review.) |
m (Minor formatting changes.) |
||
(2 intermediate revisions by the same user not shown) | |||
Line 31: | Line 31: | ||
= FUNCTIONAL OVERVIEW = | = FUNCTIONAL OVERVIEW = | ||
== Client Requirement == | == Client Requirement == | ||
Requirements were gathered from Ben at Rory J Holbrook's site on 20th March 2019. | Requirements were gathered from Ben Williams at Rory J Holbrook's site on 20th March 2019. | ||
The customer requirements break down into the following areas: | The customer requirements break down into the following areas: | ||
Line 204: | Line 204: | ||
* When the user has selected all jobs to assign to a Manifest, they will confirm this with the '''Save''' button. | * When the user has selected all jobs to assign to a Manifest, they will confirm this with the '''Save''' button. | ||
* If the user has selected to create a new Manifest, the screen will create the Manifest for the user. If a pre-existing Manifest is selected, the jobs will be assigned to that Manifest. | * If the user has selected to create a new Manifest, the screen will create the Manifest for the user. If a pre-existing Manifest is selected, the jobs will be assigned to that Manifest. | ||
* The user can return to the jobs screen with the '''Back'' button. | * The user can return to the jobs screen with the '''Back''' button. | ||
Line 235: | Line 235: | ||
* When the user has selected all jobs to de-assign from the Manifest, they will confirm this with the '''Save''' button. | * When the user has selected all jobs to de-assign from the Manifest, they will confirm this with the '''Save''' button. | ||
* The jobs will be de-assigned from that Manifest. | * The jobs will be de-assigned from that Manifest. | ||
* The user can return to the jobs screen with the '''Back'' button. | * The user can return to the jobs screen with the '''Back''' button. | ||
Line 262: | Line 262: | ||
* When the user has selected all jobs to assign to a Manifest, they will confirm this with the '''Save''' button. | * When the user has selected all jobs to assign to a Manifest, they will confirm this with the '''Save''' button. | ||
* If the user has selected to create a new Manifest, the screen will create the Manifest for the user. If a pre-existing Manifest is selected, the jobs will be assigned to that Manifest. | * If the user has selected to create a new Manifest, the screen will create the Manifest for the user. If a pre-existing Manifest is selected, the jobs will be assigned to that Manifest. | ||
* The user can return to the jobs screen with the '''Back'' button. | * The user can return to the jobs screen with the '''Back''' button. | ||
<!-- | <!-- | ||
Line 316: | Line 316: | ||
* The user then uses the screen to sequence or consolidate jobs on the Manifest. This is described in [[FS 340547 PROD-75 Admin Job Assignment Improvements]]. | * The user then uses the screen to sequence or consolidate jobs on the Manifest. This is described in [[FS 340547 PROD-75 Admin Job Assignment Improvements]]. | ||
* When the user has sequenced jobs on the Manifest, they will confirm this with the '''Save''' button. | * When the user has sequenced jobs on the Manifest, they will confirm this with the '''Save''' button. | ||
* The user can return to the jobs screen with the '''Back'' button. | * The user can return to the jobs screen with the '''Back''' button. | ||
Latest revision as of 12:49, 2 August 2019
Rory J Holbrook
Assigning Jobs to Users
Functional Specification
14th May 2019 - 1.0
Reference: FS 356513
Contents
FUNCTIONAL OVERVIEW
Client Requirement
Requirements were gathered from Ben Williams at Rory J Holbrook's site on 20th March 2019.
The customer requirements break down into the following areas:
- Being able to auto-create manifests by assigning to drivers, as jobs are created.
- In the case of creating bulk jobs, the jobs are most commonly assigned to multiple drivers, rather than all assigned to a single driver.
- For job de-assignment, being able to quickly remove (de-assign) a job from a specific driver so that it is available to assign to another driver, in the same way above.
- Sequencing should work using the same (Job) screen.
Solution Overview
Note: Rory J Holbrook has the following terminology:
- Job / Manifest - the work for a driver for a particular day.
- Load - a collection of a full load of material onto a vehicle and delivery to the final point.
For clarity, this document adopts the following terminology:
- Manifest - the work for a driver for a particular day. C-ePOD calls this a "Load".
The Bulk Jobs creation process will be modified so that, when jobs are created, it will show a list of all the jobs (through a Bulk Assign by Users screen), with the facility to assign a driver to each job (through a drop-down list of users). If that driver does not have a Manifest on that date, the Manifest will be automatically created by the system. The user will be able to identify whether to assign the jobs in pairs or in bulk. The process will automatically sequence the jobs on the Manifest.
The system will be modified to identify Manifests by driver (user) and date, in the sequencing and assignment screens. So, the user will not have to select a Manifest and drill-down from the Manifests screen, but instead will be able to use the sequencing and assignment screens directly from the menu (or on another tab in the browser).
When either screen is used like this, the user can select a date and select a driver from a drop-down list of users. The screen will then display any Manifest found (as long as it is not completed). In the job assign screen, if one is not found, the screen will create a new one.
In this way, the user can quickly create Manifests and assign jobs without having to create them first. Sequencing will also be quicker.
Both screens will also be made available as links from the jobs screen, to aid in quickly accessing the processing.
The user will be able to quickly transfer jobs between users, by using the existing assignment screen, finding the first driver and date, selecting the jobs and de-assigning them, then finding the new driver's Manifest and assigning them again.
Scope
The changes will be made in the latest versions of CALIDUS ePOD. The changes will be available only to v4.5 customers.
All screenshots in this document are intended to be representative of the final development. However, some minor changes may occur during development.
Impact
Existing customers will not be adversely affected by these changes, as it is intended that this functionality will be configurable in the system.
CONFIGURATION SET-UP
Pre-requisites
None.
Menu Structure
New menu options will be added to the Tasks menu in CALIDUS ePOD Admin console:
- Job Assignment
- Job Sequencing
Figure 1: Main Menu
Data
In order to operate as described for Rory J Holbrook, the following configuration elements must be checked against the site:
- Assignment After Creation.
- Keep Linked Jobs Together.
- Auto Generate Loads.
Figure 2: Site - Admin Tab
The system will be configured so that the word "Load" is replaced with the word "Job / Manifest", so as to reduce confusion for the customer. This will initially affect the following admin screens:
- Loads, including the menu option.
- Jobs, including creating new jobs and bulk job creation.
- Job Assign.
- Job Sequence.
- The new Bulk Assign by User screen.
Implementation Advice
None.
FUNCTIONAL DESCRIPTION
The administrative user will adopt the following procedures. The system will be changed to allow the users to achieve this as described below.
Note: The descriptions below are specific to Rory J Holbrook requirements. Where necessary, variations of this process are shown underneath.
Creating and Assigning Jobs to Drivers
The process for creating and assigning jobs will be:
- The user will be in the existing Jobs screen.
- They will click the Bulk Entry button.
- They will enter the details of the jobs as they do now, and as described in FS 355304 RJH EPOD Bulk Job Entry.
- When they click Save to create the jobs, the system will display a new Bulk Assign by User screen which will show a list of all jobs created, with the facility to:
- Assign all jobs to one user.
- Assign each job/pair of jobs to a user.
- Assign any number of jobs/pairs of jobs to a user.
- Re-assign jobs to another user.
- The top bar of the new screen displays the following items:
- A Back button for exiting the screen.
- The date for the jobs created, already showing the current date.
- A drop-down list for selection of a driver to assign jobs to.
- A drop-down list of Manifests for that driver.
- An Assign button.
- An Assign All button.
- The user will select a user from the top bar, to indicate to whom they will be assigning jobs.
- The screen displays the first (not yet complete) Manifest matching that driver and date. The current Manifest for that date will be displayed, but the user will have the facility to select any other Manifest for that driver on that day, or even create a new Manifest on that day.
- The user will select jobs to assign to the user by clicking on the jobs in the table.
- When the user clicks a job, the linked job will also be selected. In other words, when selecting to assign jobs, both the collection and the delivery job will be automatically selected.
- Any unassigned jobs that the user selects will be displayed in blue.
- Any jobs already assigned jobs that the user selects will be displayed in red.
- When the user has selected all jobs to assign to a driver's Manifest, they will confirm this with the Assign button - the system will confirm this with the user.
- The system will save the jobs onto the selected Manifests. If required, the system will create new Manifests for the drivers on that day. Any jobs that were already assigned to a Manifest will be moved to the new driver's selected Manifest.
- The jobs that are assigned will display the user and Manifest ID against them, and will be displayed in green.
- To quickly assign all jobs to a single driver, the user can select the driver in the top bar, select the Manifest, then click the Assign All button.
- When the user has finished assigning jobs to drivers, they can return to the jobs screen using the Back button. The jobs are shown on the Jobs screen.
Figure 3: New Bulk Assign by User screen, showing jobs created, having assigned 6 jobs, then selected 2 more (including 2 already assigned) to assign to another user on a new Manifest.
Variations:
- The new job assignment process is optional - the system can be configured so that it does not request jobs to be assigned after creation.
- If jobs are not linked, clicking a job will only select that one job.
- If jobs are linked, but the user only wants one of the linked jobs assigned, clicking one of the selected linked jobs again will de-select only that job.
When saving jobs onto a Manifest, the system will identify the jobs that are assigned to the same driver and sequence them automatically on the driver's Manifest on that day. The system will be configured to do this in the most appropriate way for the operation.
For Rory J Holbrook, the process will sequence the jobs in pairs, controlled by the new Site Admin configuration flag "Keep Linked Jobs Together".
So, if there are 2 pairs of linked collection and delivery jobs created and assigned to the same user, they will have the same collection times and delivery times.
Normally, that would result in the jobs being sequenced as follows:
- Collection of job 1.
- Collection of job 2.
- Delivery of job 1.
- Delivery of job 2.
The system will be configured to sequence the jobs as follows:
- Collection of job 1.
- Delivery of job 1.
- Collection of job 2.
- Delivery of job 2.
Jobs will be sequenced by the earliest collection time, and the delivery job will be added directly after this job.
Variations:
- This sequencing functionality is optional - the system can be configured to use the new or original sequencing.
Assigning Jobs to Drivers (after creation)
The user will assign jobs to drivers during the Bulk job creation process, as described above.
However, it may be required to change jobs assigned to drivers after creation.
The process for quickly assigning jobs to drivers will be:
- The user will be in the existing Jobs screen.
- They will click the Job Assignment button on the top of the screen, or run the screen from the Job Assignment option from the menu. The Job Assignment screen could also be open in another tab within the browser.
- Because the user has not come to the Job Assignment screen from the Manifest screen, this will now allow the user to select which Manifest is being worked on, through a series of parameters.
- The screen will allow the user to select which Manifest is being worked on through a drop-down list of Manifest IDs.
- The user will select the driver and date (which will default to today's date) and click Search.
- The screen displays jobs from the first (not yet complete) Manifest matching that driver and date. The current Manifest for that date will be displayed, but the user will have the facility to select any other Manifest for that driver on that day, or even create a new Manifest if there is not yet a Manifest on that day.
- The user then uses the screen to select and assign jobs to the Manifest. This is described in FS 340547 PROD-75 Admin Job Assignment Improvements.
- When the user clicks a job to assign to a Manifest, the linked job will also be selected. In other words, when selecting to assign jobs, both the collection and the delivery job will be automatically selected.
- When the user has selected all jobs to assign to a Manifest, they will confirm this with the Save button.
- If the user has selected to create a new Manifest, the screen will create the Manifest for the user. If a pre-existing Manifest is selected, the jobs will be assigned to that Manifest.
- The user can return to the jobs screen with the Back button.
Figure 4: "Find Jobs / Manifests" panel, showing criteria and Manifests found. 2 jobs are selected to assign, and 2 to de-assign.
Variations:
- If not automatically creating Manifests, the screen will allow the user to select which Manifest is being worked on through a drop-down list of Manifest IDs.
- If automatically creating Manifests (which is how the system will be set up for Rory J Holbrook), the screen will allow the user to select the driver (through a drop-down list) and select the date, which will default to the current date.
- If jobs are not linked, clicking a job will only select that one job.
- If jobs are linked, but the user only wants one of the linked jobs assigned, clicking one of the selected linked jobs again will de-select only that job.
De-assigning Jobs from Drivers (error correction)
Again, in unexpected circumstances (driver illness, for example), jobs may need to be de-assigned from a driver.
The process for quickly de-assigning jobs will be:
- The user will be in the existing Jobs screen.
- They will click the Job Assignment button on the top of the screen, or run the screen from the Job Assignment option from the menu. The Job Assignment screen could also be open in another tab within the browser.
- Because the user has not come to the Job Assignment screen from the Manifest screen, this will now allow the user to select which Manifest is being worked on, through a series of parameters.
- If not automatically creating Manifests, the screen will allow the user to select which Manifest is being worked on through a drop-down list of Manifest IDs.
- If automatically creating Manifests (which is how the system will be set up for Rory J Holbrook), the screen will allow the user to select the driver (through a drop-down list) and select the date, which will default to the current date.
- The user will select the driver and date (which will default to today's date) and click Search.
- The screen displays jobs from the first (not yet complete) Manifest matching that driver and date. The current Manifest for that date will be displayed, but the user will have the facility to select any other Manifest for that driver on that day.
- The user then uses the screen to select and de-assign jobs from the Manifest. This is described in FS 340547 PROD-75 Admin Job Assignment Improvements.
- When the user clicks a job to de-assign from a Manifest, the linked job will also be selected. In other words, when selecting to de-assign jobs, both the collection and the delivery job will be automatically selected.
- When the user has selected all jobs to de-assign from the Manifest, they will confirm this with the Save button.
- The jobs will be de-assigned from that Manifest.
- The user can return to the jobs screen with the Back button.
Variations:
- If not automatically creating Manifests, the screen will allow the user to select which Manifest is being worked on through a drop-down list of Manifest IDs.
- If automatically creating Manifests (which is how the system will be set up for Rory J Holbrook), the screen will allow the user to select the driver (through a drop-down list) and select the date, which will default to the current date.
- If jobs are not linked, clicking a job will only select that one job.
- If jobs are linked, but the user only wants one of the linked jobs assigned, clicking one of the selected linked jobs again will de-select only that job.
Transferring Jobs between Drivers
A more common error correction in the above case would be to transfer jobs from one driver's Manifest to another driver.
The process for re-assigning jobs will be:
- The user will be in the existing Jobs screen.
- They will click the Job Assignment button on the top of the screen, or run the screen from the Job Assignment option from the menu. The Job Assignment screen could also be open in another tab within the browser.
- Because the user has not come to the Job Assignment screen from the Manifest screen, this will now allow the user to select which Manifest is being worked on, through a series of parameters.
- The user will select the driver and date (which will default to today's date) and click Search.
- The screen displays jobs from the first (not yet complete) Manifest matching that driver and date, or "New Job / Manifest" if there are none, as described earlier.
- The user then uses the screen to select and de-assign jobs from the Manifest, as shown above.
- When the user has selected all jobs to de-assign from the Manifest, they will confirm this with the Save button.
- The jobs will be de-assigned from that Manifest.
- The user will click Find Manifests, select the new driver and date and click Search.
- The screen displays jobs from the first (not yet complete) Manifest matching that driver and date, or "New Job / Manifest" if there are none, as described earlier.
- The user then uses the screen to select and assign jobs to the Manifest, as shown above.
- When the user has selected all jobs to assign to a Manifest, they will confirm this with the Save button.
- If the user has selected to create a new Manifest, the screen will create the Manifest for the user. If a pre-existing Manifest is selected, the jobs will be assigned to that Manifest.
- The user can return to the jobs screen with the Back button.
Re-sequencing Jobs (after creation)
Part of the Bulk Job entry process will be to identify the jobs that are assigned to the same driver and sequence them automatically on the driver's Manifest on that day. The system will be configured to do this in the most appropriate way for the operation. See the previous section for details on this.
For Rory J Holbrook, the process will sequence the jobs in pairs.
If the user needs to change the order of the jobs from this automatic sequence, they will use the existing Job Sequencing screen. However, to ease use of this screen, the jobs screen will have the Job Sequencing button added to the top of the screen. This will also be available from the main menu, and can be opened in a new browser tab.
The process for re-sequencing jobs will be:
- The user will be in the existing Jobs screen.
- They will click the Job Sequencing button on the top of the screen, or run the screen from the Job Sequencing option from the menu. The Job Sequencing screen could also be open in another tab within the browser.
- Because the user has not come to the Job Sequencing screen from the Manifest screen, this will now allow the user to select which Manifest is being worked on, through a series of parameters.
- The user will select the driver and date (which defaults to today's date) and clicks Search.
- The screen displays jobs from the first (not yet complete) Manifest matching that driver and date. The current Manifest for that date will be displayed, but the user will have the facility to select any other Manifest for that driver on that day.
- The user then uses the screen to sequence or consolidate jobs on the Manifest. This is described in FS 340547 PROD-75 Admin Job Assignment Improvements.
- When the user has sequenced jobs on the Manifest, they will confirm this with the Save button.
- The user can return to the jobs screen with the Back button.
Figure 5: Job Sequencing screen with 3 pairs of jobs, in the sequence as created, with new Manifest selection criteria.
Variations:
- If not automatically creating Manifests, the screen will allow the user to select which Manifest is being worked on through a drop-down list of Manifest IDs.
- If automatically creating Manifests (which is how the system will be set up for Rory J Holbrook), the screen will allow the user to select the driver (through a drop-down list) and select the date, which will default to the current date.
TECHNICAL NOTES
Modules Changed
Module Name | Module Type | Notes |
---|---|---|
EPOD_JOB.cs | C# file | Site DAL object |
{Date}_{Time}-4.5.0.7-356513_JobAssignChanges.sql | Database Script | Database and Data modification script. |
RJH_{Date}_{Time}-4.5.0.7-356513_Manifest.sql | Database Script | Data Script to set "Load" to "Manifest". |
Screens/JobAssign | MVC Form | Job Assignment screen. |
Screens/JobSequencing | MVC Form | Job Sequencing screen. |
Screens/BulkAssignByUser | MVC Form | New Bulk Assign by User screen. |
job_details.aspx | Web Form | Job Details screen. |
site_header.aspx | Web Form | Site maintenance screen. |
Table Updates
The following fields will be added to table EPOD_SITE:
Name | Type | Nullable | Default | Storage | Comments |
---|---|---|---|---|---|
EPL_BULK_ASSIGN_IND | smallint | N | 1 | ||
EPL_BULK_LINKED_SEQ_IND | smallint | N | 1 |
Note:
- A database modification script will be required to add the new fields.
- Modifications will be required to the EPOD_SITE DAL object to use these new fields.
- These fields will be added to all stored procedures in the database that require them.
- These fields are not required on the device - the XML export will not include them.
- These fields are not required to be contained within the Export.
- These fields are not required to be used when filtering data for selection.
Developer Notes
Note: All prototypes are available in the specification project folder, for reference.
Admin Menu
A data modification script will be required to add the following screens to the default menu under the Task (TSK) sub-menu, on any already-created menus. The screens will be sequenced to appear under jobs, with all existing Tasks menu items under that having their sequence incremented.
On table EPOD_ADM_MENU_OPTION:
AMO_MENU_TEXT | AMO_CALLED_PROG | AMO_OPTION_HELP |
---|---|---|
Job Assignment | Screens/JobAssign/Index | Find loads and assign jobs. |
Job Sequencing | Screens/JobSequencing/Index | Find loads and sequence jobs. |
On table EPOD_ADM_PROGRAM:
APR_DESCRIPTION | APR_NAME | APR_PROGRAM_TYPE |
---|---|---|
Job Assignment | Screens/JobAssign/Index | MVC |
Job Sequencing | Screens/JobSequencing/Index | MVC |
The icons used on the menu should match the prototype screens (and referenced in APR_IMAGE_FILENAME against the specific screen in EPOD_ADM_PROGRAM). For information, the following FontAwesome icons were used in the prototype:
- Job assignment - fa-plus.
- Job sequencing - fa-sort-numeric-asc.
The font colour is set to rgba(68,191,251,1).
For Rory J Holbrooks only (i.e. through a client-specific data script), the Loads screen will be named the "Jobs / Manifests" screen.
Additionally, this script will pre-set the translation of the word "Load" to "Job / Manifest" throughout the admin system. This will also affect associated terms and messages.
Site Maintenance
The Site Maintenance screen (site_header.aspx) will be modified.
Two new flags will be added to the Admin tab, under the existing "Bulk Job Entry Settings":
- Label "Assignment After Creation", pop-up help "If enabled, after the user creates jobs using the Bulk Job button, the Bulk Assign by User screen will be shown, allowing the user to allocate the jobs to users and create loads, if required.". This is a check box, defaulting to checked. The checked value equates to 1, unchecked to 0, and this value will be saved into EPL_BULK_ASSIGN_IND.
- Label "Keep Linked Jobs Together", pop-up help "If enabled, the new Bulk Assign by User screen will automatically sequence jobs assigned to a load, keeping linked jobs (that are linked by job code) together on the job list.". This is a check box, defaulting to checked. The checked value equates to 1, unchecked to 0, and this value will be saved into EPL_BULK_LINKED_SEQ_IND.
Loads screen
This screen will be checked to ensure that all instances of labels and column headings (and associated terms and messages) use the AppTermsCustomised "Load" label.
Job Details
The Job Details screen (job_details.aspx) will be modified.
This screen will be checked to ensure that all instances of labels and column headings (and associated terms and messages) use the AppTermsCustomised "Load" label.
The screen currently only adds the Job Assign and Job Sequence buttons to the control box if the screen has been called from the Loads screen (i.e. with a querystring key of "EPL_LOAD_ID".
This parameter is stored and passed to the job assign and job sequencing screens and a "load" querystring key when clicked (as achieved in jQuery click functions in this form).
This will be modified to show these buttons at all times. If the querystring key "EPL_LOAD_ID" does not exist, the job assign and job sequencing screens will be called without the querystring i.e. "Screens/JobAssign/Index" or "Screens/JobSequencing/Index")
When the user has completed entry of bulk jobs and saved the results, the screen currently closes the Bulk Job entry pop-up and displays the jobs in the job results table.
The screen will be modified to check the value of the new site flag EPL_BULK_ASSIGN_IND.
If the value is 0, the screen will work as now.
If the flag value is 1, then the screen will call the new Bulk Assign by User screen (Screens/BulkAssignByUser/Index), passing in the values of the base job code, base customer reference and the date for which the jobs were created. Note: "Base" means the value of the field entered by the user, without any sequences appended by the job generation process.
If the site configuration flag EPL_AUTO_GEN_LOAD is enabled, the screen changes the way that jobs are assigned to loads, by attempting to list all loads for all users on all dates, and a list of users without loads. This is a flawed process.
The screen will be modified to work differently.
When searching for jobs, the process will request the user to enter a user ID instead, populated through a drop-down list of all users. Coupled with the facility to enter a specific planned start date (as the screen already does), this will allow the user to see all jobs for that user on that day.
When creating new jobs through the pop-up entry window triggered by the New button, the system attempts to do the same if the flag is set.
This will be changed to provide a drop-down list of user IDs as well as the drop-down list of loads. The Loads DDL should be set to a blank value, and the DDL should be disabled, so that the users can't click on it.
The new user DDL will show all users, plus a default option of "Unassigned".
In order to allocate a job to a load, the user must select a user from the drop-down list and enter a start planned date. Entering or changing either of these will check the value of the user DDL. If this is not set to "Unassigned", this will trigger population of the load drop-down list. This will be populated with all incomplete loads for that user for that planned start date. The loads should be shown in EPL_STATUS sequence (Pending before In Progress), exclude any that are not pending or in progress, then in load planned start date and time sequence. An option of "New Job / Manifest" should be added to the end of the list (using the AppTermsCustomised key "NewLoad") with an asterisk as the value. The one selected should be the one at the top of the list. The loads DDL should then be enabled for the user to click on it.
Blanking the start planned date or changing the user to "Unassigned" should clear the loads DDL and disable it.
When saving the new job, if the loads DDL has a value in it, the job will be allocated to this load.
If this value is as asterisk, then the process should generate a new load, then allocate the job to this new load.
The new load should be created on table EPOD_LOAD with the following values:
Field | Value |
---|---|
EPL_LOAD_ID | Generated as normal. |
EPL_LOAD_START_PLANNED_DATE | the entered job start planned date. |
EPL_LOAD_START_PLANNED_TIME | the entered job start planned time. |
EPL_LOAD_END_PLANNED_DATE | the entered job end planned date if present, otherwise the entered job start planned date. |
EPL_LOAD_END_PLANNED_TIME | the entered job end planned time if present, otherwise the entered job start planned time. |
EPL_LOAD_START_ACTUAL_DATE | 0 |
EPL_LOAD_START_ACTUAL_TIME | 0 |
EPL_LOAD_END_ACTUAL_DATE | 0 |
EPL_LOAD_END_ACTUAL_TIME | 0 |
EPL_LOAD_DISTANCE_PLANNED | 0 |
EPL_LOAD_DISTANCE_ACTUAL | 0 |
EPL_VEHICLE_ID | blank. |
EPL_USER_ID | the entered user ID. |
EPL_STATUS | "P" - Pending. |
EPL_LAST_CHANGED_DATE | current date. |
EPL_LAST_CHANGED_TIME | current time. |
EPL_XFER_FLAG | blank. |
EPL_MILEAGE_START | 0 |
EPL_MILEAGE_END | 0 |
EPL_XFER_TTM_FLAG | blank. |
EPL_UDF_LOAD_START | blank. |
EPL_UDF_LOAD_END | blank. |
EPL_LOAD_INFORMATION | blank. |
EPL_TIMEZONE | blank. |
EPL_TRAILER_ID | blank. |
EPL_ROUTE_CODE | blank. |
Note: This functionality is common to the Job Details screen, the Job Assign screen and the new Bulk Assign by User screen. As such, this should be created as a common function, possibly as a method of the EPOD_LOAD DAL object.
Job Assignment
The Job Assignment screen (Screens/JobAssign/Index) will be modified.
This screen will be checked to ensure that all instances of labels and column headings (and associated terms and messages) use the AppTermsCustomised "Load" label.
The screen can currently only be called with a querystring key of "load", specifying the load ID to display.
The screen will be modified to check whether this has been provided - if so, the screen will operate as now, displaying the load ID in the header, retrieving the jobs on this specified load and displaying them in the results datatable.
If no value is provided, the screen will instead do the following:
- In the header, to the right of the load ID (which will now be blank) will be a Find Job / Manifest button (using an AppTermsCustomised key of "Find Load").
- A search panel will be added below this.
- The results panel will be hidden.
- The Back button will not be visible.
The Find Job / Manifest button will show or hide the search panel using jQuery.
If the site configuration flag EPL_AUTO_GEN_LOAD is set to "Y", the panel will contain the following elements:
- A User drop-down list, populated with all drivers (i.e. PDA users from EPOD_USER), plus a default value "Select a Value".
- A Date text field, populated with the current date. This will use a calendar extender to help the user select dates.
- A loads drop-down list, initially disabled and populated with a blank value.
- A Search button, initially disabled.
- A Clear button.
Triggered by change of value of the date text box or user drop-down list, the screen will check that both contain a non-blank value (i.e. not value "Select a Value" for user and a date). If so, the screen will populate the load DDL with all incomplete loads for that user for that planned start date. The loads should be shown in EPL_STATUS sequence (Pending before In Progress), exclude any that are not pending or in progress, then in load planned start date and time sequence. The load option value should be the load ID. The load option text should be the load ID, plus the translated status in brackets e.g. EPL_LOAD_ID + " (" + TranslateStatus(EPL_STATUS) + ")". An option of "New Job / Manifest" should be added to the end of the list (using the AppTermsCustomised key of "NewLoad") with a value of an asterisk. The one selected should be the one at the top of the list. The loads DDL should then be enabled for the user to click on it, and the Search button will be enabled for the user to click on it.
If not, the load DDL will be populated with a blank value and disabled.
Clearing the "Find Load" panel will reset the criteria in the panel:
- The User DDL will revert to "Select a Value".
- The Date text field will revert to the current date.
- The loads DDL will be disabled and a blank value shown.
- The Search button will be disabled.
If the site configuration flag EPL_AUTO_GEN_LOAD is set to "N", the panel will contain the following elements:
- A Date text field, populated with the current date. This will use a calendar extender to help the user select dates.
- A loads drop-down list, populated as described below.
- A Search button, initially disabled.
- A Clear button.
Triggered by change of value of the date text box and on initial start-up, the screen will check that the date contains a non-blank value. If so, the screen will populate the load DDL with all incomplete loads for that planned start date. The loads should be shown in EPL_STATUS sequence (Pending before In Progress), exclude any that are not pending or in progress, then in load planned start date and time sequence. The load option value should be the load ID. The load option text should be the load ID, plus the translated status in brackets e.g. EPL_LOAD_ID + " (" + TranslateStatus(EPL_STATUS) + ")". The one selected should be the one at the top of the list.
Clearing the "Find Load" panel will reset the criteria in the panel:
- The Date text field will revert to the current date.
In either case, when Search is clicked, the screen will:
- Display the selected load in the header (i.e. to the left of the Find Job / Manifests button.
- Fetch the data for that load and display it in the table.
- Show the results panel
- Hide the Find Loads search panel.
Note: This functionality is common to the Job Assign screen and the Job Sequencing screen. As such, this should be created in one screen with generic id's and copied into the other screen.
The existing Find button will be changed to Find Jobs, but in all ways will work as now.
In the results panel, the selection of jobs should change slightly.
Currently, when a line is clicked, that line should be highlighted (through adding the "selected" class to the row).
This will be changed to also check the value of the site configuration flag EPL_LINKED_C_D. If the value is "Y", the process should look for any job on the list with the same job code value and load id, and also add the "selected" class to that job's row.
Note: This only applies to rows without the "selected" class - if they already have this class, clicking the row will remove the selected class from this row, and should not search for any linked job.
The "To Assign" and "To Deassign" counts should reflect the total count of rows with the "selected" class.
When saving the jobs assigned to a load, if the loads DDL has a value in it, the job will be allocated to this load.
If this value is an asterisk, then the process should generate a new load, and then allocate the job to this new load.
The new load should be created on table EPOD_LOAD with the following values:
Field | Value |
---|---|
EPL_LOAD_ID | Generated as normal. |
EPL_LOAD_START_PLANNED_DATE | the entered job start planned date. |
EPL_LOAD_START_PLANNED_TIME | the entered job start planned time. |
EPL_LOAD_END_PLANNED_DATE | the entered job end planned date if present, otherwise the entered job start planned date. |
EPL_LOAD_END_PLANNED_TIME | the entered job end planned time if present, otherwise the entered job start planned time. |
EPL_LOAD_START_ACTUAL_DATE | 0 |
EPL_LOAD_START_ACTUAL_TIME | 0 |
EPL_LOAD_END_ACTUAL_DATE | 0 |
EPL_LOAD_END_ACTUAL_TIME | 0 |
EPL_LOAD_DISTANCE_PLANNED | 0 |
EPL_LOAD_DISTANCE_ACTUAL | 0 |
EPL_VEHICLE_ID | blank. |
EPL_USER_ID | the entered user ID. |
EPL_STATUS | "P" - Pending. |
EPL_LAST_CHANGED_DATE | current date. |
EPL_LAST_CHANGED_TIME | current time. |
EPL_XFER_FLAG | blank. |
EPL_MILEAGE_START | 0 |
EPL_MILEAGE_END | 0 |
EPL_XFER_TTM_FLAG | blank. |
EPL_UDF_LOAD_START | blank. |
EPL_UDF_LOAD_END | blank. |
EPL_LOAD_INFORMATION | blank. |
EPL_TIMEZONE | blank. |
EPL_TRAILER_ID | blank. |
EPL_ROUTE_CODE | blank. |
Note: This functionality is common to the Job Details screen, the Job Assign screen and the new Bulk Assign by User screen. As such, this should be created as a common function, possibly as a method of the EPOD_LOAD DAL object.
Once created, the Find Load search panel should be updated to:
- Refresh the loads DDL with this new load ID, and ensure that it is selected.
- Refresh the load ID label in the header to this new load ID.
When the user exits the screen using the Back button, this should return to the job details screen, displaying the same jobs as before you left.
Job Sequencing
The Job Sequencing screen (Screens/JobSequencing/Index) will be modified.
This screen will be checked to ensure that all instances of labels and column headings (and associated terms and messages) use the AppTermsCustomised "Load" label.
The screen can currently only be called with a querystring key of "load", specifying the load ID to display.
The screen will be modified to check whether this has been provided - if so, the screen will operate as now, displaying the load ID in the header, retrieving the jobs on this specified load and displaying them in the results datatable.
If no value is provided, the screen will instead do the following:
- In the header, to the right of the load ID (which will now be blank) will be a Find Job / Manifest button (using an AppTermsCustomised key of "FindLoad").
- A search panel will be added below this.
- The results panel will be hidden.
- The Back button will not be visible.
The Find Job / Manifest button will show or hide the search panel using jQuery.
If the site configuration flag EPL_AUTO_GEN_LOAD is set to "Y", the panel will contain the following elements:
- A User drop-down list, populated with all drivers (i.e. PDA users from EPOD_USER), plus a default value "Select a Value".
- A Date text field, populated with the current date. This will use a calendar extender to help the user select dates.
- A loads drop-down list, initially disabled and populated with a blank value.
- A Search button, initially disabled.
- A Clear button.
Triggered by change of value of the date text box or user drop-down list, the screen will check that both contain a non-blank value (i.e. not value "Select a Value" for user and a date). If so, the screen will populate the load DDL with all incomplete loads for that user for that planned start date. The loads should be shown in EPL_STATUS sequence (Pending before In Progress), exclude any that are not pending or in progress, then in load planned start date and time sequence. The load option value should be the load ID. The load option text should be the load ID, plus the translated status in brackets e.g. EPL_LOAD_ID + " (" + TranslateStatus(EPL_STATUS) + ")". The one selected should be the one at the top of the list. The loads DDL should then be enabled for the user to click on it, and the Search button will be enabled for the user to click on it.
If not, the load DDL will be populated with a blank value and disabled.
Clearing the Find Load panel will reset the criteria in the panel:
- The User DDL will revert to "Select a Value".
- The Date text field will revert to the current date.
- The loads DDL will be disabled and a blank value shown.
- The Search button will be disabled.
If the site configuration flag EPL_AUTO_GEN_LOAD is set to "N", the panel will contain the following elements:
- A Date text field, populated with the current date. This will use a calendar extender to help the user select dates.
- A loads drop-down list, populated as described below.
- A Search button, initially disabled.
- A Clear button.
Triggered by change of value of the date text box and on initial start-up, the screen will check that the date contains a non-blank value. If so, the screen will populate the load DDL with all incomplete loads for that planned start date. The loads should be shown in EPL_STATUS sequence (Pending before In Progress), exclude any that are not pending or in progress, then in load planned start date and time sequence. The load option value should be the load ID. The load option text should be the load ID, plus the translated status in brackets e.g. EPL_LOAD_ID + " (" + TranslateStatus(EPL_STATUS) + ")". The one selected should be the one at the top of the list.
Clearing the Find Load panel will reset the criteria in the panel:
- The Date text field will revert to the current date.
In either case, when Search is clicked, the screen will:
- Display the selected load in the header (i.e. to the left of the Find Job / Manifest button.
- Fetch the data for that load and display it in the table.
- Show the results panel
- Hide the Find Loads search panel.
Note: This functionality is common to the Load Assign screen and the Load Sequencing screen. As such, this should be created in one screen with generic id's and copied into the other screen.
The data displayed in this screen will be changed to more closely represent the way the data is displayed on the mobile device.
- Sorting should initially match the device - see assist for details (http://172.198.45.54/calidus-assist/EPOD/index.php/Job_List_Sequence).
- The datatable will allow sorting on the original sequence (the sequence column), with blanks at the end, like the device.
Bulk Assign by User
A MVC new screen will be created, called /Screens/BulkAssignByUser. This screen will be based heavily on the existing Job Assign screen Screens/JobAssign.
As such, this specification will cover the differences.
Note: The labels for fields and columns will be configurable (i.e. AppTermsCustomised).
This screen will be checked to ensure that all instances of labels and column headings (and associated terms and messages) use the AppTermsCustomised "Load" label.
The screen will be called with the following querystring keys:
- JobCode - the base job code.
- CRef - the base customer reference.
- Date - the date for which the jobs were created.
Note: "Base" means the value of the field entered by the user, without any sequences appended by the job generation process.
The new Find Load search panel will not be required in this screen.
The button bar will include the following elements:
- Date - set to the Date querystring key.
- User - a drop-down list populated with PDA users only, and a default option of "Select a Value".
- Load - a drop-down list, initially disabled and populated with a blank value.
- Assign button.
- Assign All button.
- To Assign and Remaining counter labels.
Triggered by change of value of the user drop-down list, the screen will check that the user contains a non-blank value. If so, the screen will populate the load DDL with all incomplete loads for that user on that date. The loads should be shown in EPL_STATUS sequence (Pending before In Progress), exclude any that are not pending or in progress, then in load planned start date and time sequence. The load option value should be the load ID. The load option text should be the load ID, plus the translated status in brackets e.g. EPL_LOAD_ID + " (" + TranslateStatus(EPL_STATUS) + ")". An option of "New Job / Manifest" should be added to the end of the list (using the AppTermsCustomised key of "NewLoad") with a value of an asterisk. The one selected should be the one at the top of the list.
The data retrieved by the screen will be the same as the Job Assign screen, with the addition of a link to the EPOD_LOAD table (to get the assigned user ID) and to the EPOD_USER table (to get the user name). The data will be retrieved matching the values in the querystring:
- EPL_JOB_CODE LIKE JobCode + "%".
- EPL_CUST_REF LIKE CRef + "%".
- EPL_START_PLANNED_DATE = Date
The results table columns displayed are from EPOD_JOB (unless indicated otherwise) and are:
- Load - EPL_LOAD_ID.
- User - EPL_USER_NAME of EPOP_USER.
- Type - EPL_JOB_TYPE.
- Group - EPL_JOB_GROUP.
- Job Code - EPL_JOB_CODE.
- Customer Ref. - EPL_CUST_REF.
- Planned Start - EPL_START_PLANNED_DATE (formatted)
- Planned End - EPL_START_PLANNED_TIME (formatted)
- Customer - EPL_CUSTOMER_NAME of EPOD_CUSTOMER (if this job has no job address) or EPL_NAME of EPOD_JOB_ADDRESS.
- Post Code - EPL_POST_CODE of EPOD_CUSTOMER (if this job has no job address) or of EPOD_JOB_ADDRESS.
All column header labels should be set from AppTermsCustomised keys.
The results table will be a jQuery datatable allowing sorting on all columns.
Like the Job Assign screen, columns will be coloured, although the conditions are different.
- If the job has no load ID and is not selected, no colour, with class "not-assigned-to-load".
- If the job has no load ID and is selected, colour blue (through application of the "selected" class).
- If the job has a load ID, colour green (through application of class "assigned-to-load").
- If the job has a load ID and is selected, colour red (if the class contains both "assigned-to-load" and "selected").
Clicking a row will apply the "selected" class if it doesn't have it, and clicking a row with the "selected" class will remove it.
Clicking a row will also check the value of the site configuration flag EPL_LINKED_C_D. If the value is "Y", the process will look for any job on the list with the same job code value and load id, and also add the "selected" class to that job's row.
Note: This only applies to rows without the "selected" class - if they already have this class, clicking the row will remove the selected class from this row, and should not search for any linked job.
The "To Assign" counter label (id assignedJobsCount) will function as in the Job Assign screen, counting all rows with both "not-assigned-to-load" and "selected" classes.
The "Remaining" counter label (id remainingJobsCount) will count any rows that have a "not-assigned-to-load" class without a "selected" class.
Each counter will update when rows are clicked, and when the screen refreshes.
The Assign button will display a confirmation jQuery dialogue similar to the Job Assign screen's assignSavePopUp dialogue, asking for confirmation:
- title : 'Assign (' + assignCount + ') Jobs ?'
- OK button - submits the selected jobs for assignment.
- Close button - closes the dialogue without action.
The Assign All button will display a confirmation jQuery dialogue similar to the Job Assign screen's assignAddAllPopUp dialogue, asking for confirmation:
- title: 'Assign all jobs (including those already assigned) to the user's selected load?"
- OK button - submits all the jobs for assignment.
- Close button - closes the dialogue without action.
On clicking OK, if the loads DDL has a value in it, the selected jobs (or all jobs) will be allocated to this load.
If this value is as asterisk, then the process should generate a new Manifest, and then allocate the job to this new load.
The new load should be created on table EPOD_LOAD with the following values:
Field | Value |
---|---|
EPL_LOAD_ID | Generated as normal. |
EPL_LOAD_START_PLANNED_DATE | the earliest of the selected jobs' start planned dates. |
EPL_LOAD_START_PLANNED_TIME | the earliest of the selected jobs' start planned times. |
EPL_LOAD_END_PLANNED_DATE | the latest of the selected jobs' end planned dates if present, otherwise the latest of the selected jobs' start planned dates. |
EPL_LOAD_END_PLANNED_TIME | the latest of the selected jobs' end planned time if present, otherwise the latest of the selected jobs' start planned time. |
EPL_LOAD_START_ACTUAL_DATE | 0 |
EPL_LOAD_START_ACTUAL_TIME | 0 |
EPL_LOAD_END_ACTUAL_DATE | 0 |
EPL_LOAD_END_ACTUAL_TIME | 0 |
EPL_LOAD_DISTANCE_PLANNED | 0 |
EPL_LOAD_DISTANCE_ACTUAL | 0 |
EPL_VEHICLE_ID | blank. |
EPL_USER_ID | the selected user ID. |
EPL_STATUS | "P" - Pending. |
EPL_LAST_CHANGED_DATE | current date. |
EPL_LAST_CHANGED_TIME | current time. |
EPL_XFER_FLAG | blank. |
EPL_MILEAGE_START | 0 |
EPL_MILEAGE_END | 0 |
EPL_XFER_TTM_FLAG | blank. |
EPL_UDF_LOAD_START | blank. |
EPL_UDF_LOAD_END | blank. |
EPL_LOAD_INFORMATION | blank. |
EPL_TIMEZONE | blank. |
EPL_TRAILER_ID | blank. |
EPL_ROUTE_CODE | blank. |
Note: This functionality is common to the Job Details screen, the Job Assign screen and the new Bulk Assign by User screen. As such, this should be created as a common function, possibly as a method of the EPOD_LOAD DAL object.
When jobs are assigned to a load, the load may then require sequencing. The process will check the EPOD_SITE flag EPL_BULK_LINKED_SEQ_IND. If set to 1, the process will sequence the jobs in pairs.
So, if there are 2 pairs of linked collection and delivery jobs created and assigned to the same user, they will have the same collection times and delivery times.
Normally, that would result in the jobs being sequenced as follows:
- Collection of job 1.
- Collection of job 2.
- Delivery of job 1.
- Delivery of job 2.
The system will be configured to sequence the jobs as follows:
- Collection of job 1.
- Delivery of job 1.
- Collection of job 2.
- Delivery of job 2.
Jobs will be sequenced by the earliest collection time, and the delivery job will be added directly after this job.
The Back button returns to jobs screen. The jobs screen must show the same jobs, so the SESSION attributes should be set so that the screen does this, through setting the search criteria of the date, job code and customer reference.
If the user attempts to exit before all jobs are assigned (i.e. remainingJobsCount not equal 0) will result in a jQuery alert pop-up, telling the user that they have forgotten to assign jobs, and asking them to confirm before exiting.
- title : 'Not all jobs have been assigned - leave the screen anyway?'
- Stay button - stays in the screen (the default option).
- Exit button - closes the dialogue and exits the screen as described above.
TEST PLAN
Test Script / Scenario Reference | Assigning Jobs to Users | Call Number(s): 356513 |
Test Script / Scenario Description | Testing Job assignment to loads by user. | PASS / ISSUES / FAIL |
Menu Access | Tasks/Jobs, Job Sequencing & Job Assignment | |
Pre-requisites | Ensure that the system is configured to:
| Tested By: |
Test Objective | To test that jobs can be assigned to loads by user in various screens. | Date: |
Step | Action | Result | Remarks | P/F |
1 | Menu | |||
1.01 | Open the menu. | The menu has options "Jobs / Manifests", "Job Assign" and "Job Sequencing". | ||
1.02 | Enter the Jobs / Manifests screen from the menu. | All instances of "load" show as "Jobs / Manifest". |
Step | Action | Result | Remarks | P/F |
2 | Jobs | |||
2.01 | Create a single job and assign to a user without a Manifest on that date. | A new Manifest is created. The job is assigned to the Manifest. | ||
2.02 | Create a single job and assign to a user with a Manifest on that date. | The job is assigned to the Manifest. | ||
2.03 | Create bulk jobs. | The new Bulk Assign by User screen is shown. | ||
2.04 | Select a user with at least one Manifest on that date. | The correct Manifest is shown. | ||
2.05 | Select a job and click Assign. | The job is assigned to the Manifest. | ||
2.06 | Select a different user (without a Manifest). | "New Job / Manifest" will be created. | ||
2.07 | Select a different job and click Assign. | A new Manifest is created. The job is assigned to the Manifest. | ||
2.08 | Select a different user (with a Manifest) and click Assign All. | All jobs are assigned to that Manifest. | ||
2.09 | Click "Job Assign" from the jobs screen. | The Job Assign screen is shown with options to select the user, date and Manifest. | ||
2.10 | Return to jobs. Click "Job Sequencing" from the jobs screen. | The Job Sequencing screen is shown with options to select the user, date and Manifest. |
Step | Action | Result | Remarks | P/F |
3 | Job Assign | |||
3.01 | Enter the job assign screen from the menu and the jobs screen. | All instances of "load" show as "Job / Manifest". | ||
3.02 | Select a user without a Manifest. | New Manifest is shown. | ||
3.03 | Select a job and click "Save". | A new Manifest is created. The job is assigned to the Manifest. | ||
3.04 | Select a user with a Manifest. | The Manifest is shown. | ||
3.05 | Select jobs and click "Save". | The job is assigned to the Manifest. |
Step | Action | Result | Remarks | P/F |
4 | Job Sequencing | |||
4.01 | Enter the job sequencing screen from the menu and the jobs screen. | All instances of "load" show as "Job / Manifest". | ||
4.02 | Select a user without a Manifest. | No Manifest is shown. | ||
4.03 | Select a user with a Manifest. | The Manifest is shown. | ||
4.04 | Resequence and consolidate jobs and click "Save". | The jobs are sequenced on the Manifest. |
APPENDIX A: QUOTE & DOCUMENT HISTORY
Cost Details | ||||
Activity | Estimate No. of Days |
No. of Days | Rate per Day (£) | Cost (£ Exc. VAT) |
Requirements | 0.00 | 0.00 | 850 | £0.00 |
Change Request Evaluation | 0.50 | 0.50 | 850 | £425.00 |
Functional Specification | 3.25 | 3.25 | 850 | £2,762.50 |
Technical Specification | 0.00 | 0.00 | 850 | £0.00 |
Development | 14.00 | 14.00 | 850 | £11,900.00 |
Testing and Release | 3.25 | 3.25 | 850 | £2,762.50 |
Implementation | 0.00 | 0.00 | 850 | £0.00 |
Project Management | 1.00 | 1.00 | 850 | £850.00 |
TOTAL | 22.00 | 22.00 | £18,700.00 |
Estimate excludes training, release to live and go live support. |
References
Ref No | Document Title & ID | Version | Date |
1 | FS 355526 Rory Holbrook POD Notes | 0.2 | 05/03/2019 |
2 | FS 355304 RJH EPOD Bulk Job Entry | 1.0 | 30/01/2019 |
3 | FS 356080 Add Parameters for Additional Data | 0.4 | 07/03/2019 |
4 | FS 340547 PROD-75 Admin Job Assignment Improvements | 0.2 | 24/01/2017 |
Glossary
Term or Acronym | Meaning |
---|---|
General Definitions | |
EPOD | Electronic Proof of Delivery. The OBSL EPOD system is CALIDUS ePOD. This also comprises the basis of the Service Completion system CALIDUS eServ. |
Server | The portion of the CALIDUS ePOD/eServ systems that controls all the data and sends information to and receives updates from the mobile device. |
Mobile Device; PDA | The device used by the driver to perform the jobs. Typically an Android mobile device or tablet. |
Site | The site usually defines the depot, business or the transport group (carrier). It can be set to any value required by the customer. All transactions data (for example, loads and jobs) and standing data (for example, vehicles and uses) belong to a site. An EPOD user, on a device or in the Admin screen, can only see data for one site at a time. |
Load | A single journey for the driver with a set of work attached. A load is identified by a unique load ID. This may also be referred to as a worklist or workload. |
Job | Also Consignment. A single task for the driver as a specific location. This could be the collection of goods or the delivery of goods. Jobs may also be Services (for example, servicing, installing or de-installing a boiler). A job is identified by a unique job ID but can also have other references held against the job (e.g. job code, SO number, customer reference and external reference). |
Job Group | Jobs must be tagged with a Job Group. All jobs tagged with a single job group are processed in the same way. The job group has configuration associated to it to control such items as: POD/POC Report settings; Pre-Job actions (such as signing at a gatehouse); Post-Job actions (such as who signs for the item, are photos required); configurable fields required for entry for the jobs; Terms and Conditions displayed and; driver/user process (such as photos required for cancellation, comments/notes allowed). The job group can be used for any or all Sites, and the configuration against the job group can be different in each site. Job Groups can also be restricted from Admin and Remote users, so that certain users only see jobs for certain groups. |
Container | A generic term for any object that contains the items being collected or delivered. Examples of containers are: Pallet; Package; Carton; Item; Cage. A special container "Loose Products" - see Product below. A container is identified by a container ID which is unique to this physical container. |
Product | A product is any goods that are being collected or delivered where the product has a 'Product Code' which identifies what the product is but which does not uniquely identify each individual item. A product will also have a quantity associated with it to indicate how many items of this 'Product Code' are being collected or delivered. Products can either be processed within a 'Container' or as 'Loose Products' without a 'Container'. |
Owner | The owner of the order that created the job. Typically this is the sales team that took the order and will be responsible for dealing with queries from the customer regarding the status. |
Operator; Executor | The Site (depot or carrier) that is executing the load or loads that are involved in the delivery of the items. |
Item Related Definitions | |
Job Code | A reference associated with a job or job(s). This reference is common to connected jobs, for example this would be the same on both the collection of goods and the associated delivery of the same goods. Typically this would be the transport unique reference. |
SO Number | A reference associated with a job which indicates the "Sales Order Number" this job is associated with. |
Customer Reference | A reference associated with a job which has been provided by and will be recognised by the customer. |
External Reference | A reference associated with a job which does not match any of the existing references, usually because it has been provided by an external system. |
Pallet | An alternative for 'Container'. The term pallet is used when the operation only uses portable platforms as the container for goods. |
Package | An alternative for 'Container'. The term package is used when the operation only uses boxes or wrapping as containers for goods. |
Package Code | A code representing the type of 'Container'. |
Package Desc | A description of the type of 'Container'. |
Product Code | A code which identifies what a product is. |
Item | A generic term for any individual item that can be collected or delivered. An item can represent a 'Container' or a 'Product'. This can also be used as an alternative for 'Container' when the operation only treats the goods as individual items, i.e. not as identifiable products. |
Service Item | An item which will be serviced by a service job. See action 'Service'. |
Issue Life | The time after which an item is no longer fit for purpose. |
Pack Size; Case Quantity | A product may consist of a full quantity of items, inside a pack. The Pack Size (or Case Quantity) defines the amount of this product contained in a single pack. For example, if there are 85 items to deliver, with a pack size of 24, the number of full packs is determined to be 3 (24 * 3, or 72), with the remaining (13) being 'loose' quantity. This is displayed as "3/13" on the mobile application. |
UOM; Item Type | Unit of Measure; The major (case) UOM. This can optionally be displayed on the mobile device when changing product quantities. |
Product Type | A classification of the product being delivered. For example, a company may deliver 7 different mortar products and 80 different concrete slab products. The Product Types may be set to "MORTAR" and "SLABS". This may be used to attach additional configuration, changing the data required when collecting or delivering these product types. |
Status Definitions | |
Status | An indicator of how far through the processing a 'Job', 'Container' or 'Product' has progressed. |
Pending | A status indicating that the processing has not yet started, but is required to be completed. |
In Progress | A status indicating that processing has started but not yet finished. |
Complete | A status indicating that the 'Job', 'Container' or 'Product' has been collected or delivered. |
Complete (Amended) | A status indicating that the 'Job', 'Container' or 'Product' has been collected or delivered but that some changes or amendments have been made. This means that not everything that was planned to be collected or delivered was collected or delivered, some items may have been cancelled or some products may only have had some of the planned quantities collected or delivered. |
Complete (Claused) | A status indicating that the processing has been finished but that a 'Clause' condition has been recorded for this item. |
Claused | See 'Complete (Claused)' and action 'Clause'. |
Cancelled | A status indicating that the processing of this item or job is no longer required. |
Cancelled at Collection | A status indicating that the delivery of a container or product is no longer required because the associated collection of this container or product was cancelled. |
Submitted | An optional status that applies only to a 'Job' and which occurs after the 'Job' has been completed. This indicates that any time and expenses information recorded for the 'Job' has been submitted back to the server and can no longer be altered. |
Action Definitions | |
Start | An action associated with a 'Job' meaning the driver is about to start the processing of this job or jobs. This action will mark the job(s) with a status of 'In Progress'. |
Arrive | A conditional action associated with a 'Job' meaning the driver has arrived at the location the goods should be collected from or delivered to. |
Continue | An action associated with a 'Job' meaning the driver has previously performed the 'Start' and/or 'Arrive' action and has exited the processing screen but is now going to continue the processing. |
Collect | An action associated with a specific 'Container' or a 'Product' meaning the driver has collected the 'Container' or 'Product'. This action will mark the 'Container' or 'Product' with a status of 'Complete' or 'Complete (Amended)'. |
Collect Claused | An action associated with a specific 'Container' or a 'Product' meaning the driver has collected the 'Container' or 'Product' but with a condition under which the collection was accepted. This action will accept the clause condition and then mark the 'Container' or 'Product' with a status of 'Complete (Claused)'. |
Deliver | An action associated with a specific 'Container' or a 'Product' meaning the driver has delivered the 'Container' or 'Product'. This action will mark the 'Container' or 'Product' with a status of 'Complete' or 'Complete (Amended)'. |
Deliver Claused | An action associated with a specific 'Container' or a 'Product' meaning the driver has delivered the 'Container' or 'Product' but with a condition under which the delivery was accepted. This action will accept the clause condition and then mark the 'Container' or 'Product' with a status of 'Complete (Claused)'. |
Clause | An action associated with a specific 'Container' or a 'Product' that has already been collected or delivered meaning the collection or delivery has been accepted with a condition. This action will accept the clause condition and then mark the 'Container' or 'Product' with a status of 'Complete (Claused)'. |
Cancel | An action associated with a 'Job', 'Container' or 'Product' meaning the collection or delivery will not be performed for this 'Job', 'Container' or 'Product'. |
Submit | An optional action which can conditionally be carried out after a 'Job' has been collection or delivered meaning that any/all required expense or time recording for this 'Job' has been completed and can be submitted back to the server. |
Service | A service of a service item or items. Typically, Installation, Deinstallation or Service. The process of a service usually encompasses Pre- and Port-work checks, information gathering and diagnosis and resolution notes. Additional references (MC Refs) may also be captured. |
Actioned | A general term describing completing a job. So, 'Actioned' may be used instead of 'Collected', 'Serviced', 'Delivered'. |
Consolidate | The action of taking several jobs and linking them together, so they are actioned at the same time with one start, arrive and signature. |
Deconsolidate | The action of taking a consolidation of jobs and breaking them down into the component jobs again. |
Job Swap | The action of selecting an existing load not assigned to the user, and picking jobs to transfer onto the user's load. |
Signature Capture | Usually the final action of a job, where the customer's name and signature are entered. |
Other Definitions | |
Reason Code | A code which represents the reason that a job was cancelled or an item was cancelled or claused. |
Vehicle | The vehicle used for transporting the goods. |
Vehicle Checks | Also Defect Checks. A series of questions representing the results of checks intended to ensure the vehicle is in an acceptable condition. |
Metrics Entry | A series of questions to capture information either at the start or end of a 'Load'. |
Driver | The person performing the collections or deliveries; the user of the device/application. |
Engineer | The person performing the services; the user of the device/application. |
Customer | The person/company the goods are being collected from or delivered to. |
Signatory | The name of the person providing a signature. |
T&Cs | Terms and Conditions. The T&Cs are shown when signatures are prompted for. The text of the T&Cs are defined in the system itself. |
Transfer Load | A load select from which to swap jobs to the user's load. |
Base | E.g. 'Return to Base'. Typically the depot from which the driver departed. |
Unplanned Ad Hoc Collection | A collection job that is created by the driver, usually after delivering to a customer. |
Ad Hoc Container Entry/Scanning | The process of adding containers (items) to a job that have not been pre-advised on the job. |
Completion Report | POD, POC, Service/Work Report. |
Load Assignment | The action of assigning a vehicle and/or a driver to a load. |
Job Assignment | The action of putting jobs onto a load. |
Collection/Delivery Windows; Access Windows | Periods of time between which it is acceptable to deliver or collect from that customer. This has limited use in the system, mostly for reporting purposes. |
Location/Map Terms | |
Lat-Longs; GPS Co-ordinates, GPS Position | Latitude and Longitude co-ordinates, specified together as a single entity, identifying the exact position of a location. There are multiple formats - CALIDUS ePOD uses decimal notation, for example "53.3490818,-2.8521498" identifies the OBS Logistics office building in Liverpool. |
GPS | Global Positioning System; the satellite system used to obtain a GPS position, for use with navigation and location positioning. |
Geocode; Reverse Geocode | Geocoding is the process of obtaining lat-longs from an address. Reverse Geocoding is the process obtaining an address from lat-longs. |
Geofence; Geofence Break | A Geofence is a perimeter around a location. A Geofence Break occurs when a device passes through this perimeter on entry or exit from the location. |
Authorised By
Murray Middleton | OBS Project Manager | _____________________________ |
Ben Williams | Rory J Holbrook Transport Manager | _____________________________ |