FS 355526 Rory Holbrook POD Notes
Rory J Holbrook
Rory Holbrook POD Notes
Functional Specification
4th March 2019 - 0.1
Reference: FS 355526
Contents
FUNCTIONAL OVERVIEW
Client Requirement
Ben provides samples of the 3 Delivery Notes currently in use. Depending on analysis of Job Groups we are expecting to consolidate this to 2 POD notes, one with Last Load information - one without - and the use of an OBS standard format. Potential changes to update Configurable POC Note to include UDF weighbridge reference data.
Sample TASCC Grain Note:
Sample Conveyance Note:
Sample General Delivery Note:
Solution Overview
It has been since discussed and decided that general deliveries will continue off-system at this time.
2 new reports will be created:
- RJH Grain
- RJH Conveyance
When assigned to the appropriate job groups and with the correct user-defined forms (UDF) configuration, this will produce the correct output from the jobs.
In order to achieve these reports, developments are required to the CALIDUS ePOD configurable report format and to the Admin console to support:
- Last 3 Jobs reporting, including details from the jobs and products.
- Customer Parameters.
Customer Parameters development has been specified elsewhere.
Last 3 jobs functionality is specified as part of this change, although this has been determined to be product development.
Scope
Warning:
Note: In both cases, the reports have used the FORS Silver logo, not the bronze logo (as seen in the samples), as the FORS website confirms that RJ Holbrook is now at the silver level.
Impact
Warning: Outstanding questions:
- Does the EWC Code directly match to the waste check-boxes? I have assumed so.
- If not, then I can change the collection to request EWC code separately.
- EWC code for Utilities/Unsegregated waste?
- Multiple EWC codes may be captured per collection?
- In both PODs, I have used the FORS Silver logo, not the bronze logo, as the FORS website confirmed that RJH is now at the silver level. Confirmation required.
- Confirm whether grain collection customer signature is required
CONFIGURATION SET-UP
Pre-requisites
None.
Menu Structure
None.
Data
Jobs are defined by the job group:
- GRAIN
- GRAIN-DEL
- CONVEYANCE
- CONVEYANCE-DEL
The jobs groups must include the following configuration:
- GRAIN
- POD Note Format: "RJH Grain".
- POC Note Format: "RJH Grain".
- GRAIN-DEL
- Customer Signature enabled.
- POD Note Format: "RJH Grain".
- POC Note Format: "RJH Grain".
- CONVEYANCE
- Driver Signature enabled.
- Customer Signature enabled.
- POD Note Format: "RJH Conveyance".
- POC Note Format: "RJH Conveyance".
- CONVEYANCE-DEL
- Customer Signature enabled.
- POD Note Format: "RJH Conveyance".
- POC Note Format: "RJH Conveyance".
Terms and Conditions must be created for Grain Deliveries. These can be defined against the GRAIN-DEL job group or created as UDF.
Grain Delivery jobs request the following job UDF:
- Weighbridge Number - a required numeric entry box.
- Weighbridge Weight - a required numeric entry box.
- Cleaning - a drop-down list defaulting to "Swept"
Load Start metrics will be required to request
- Trailer ID - a required data-bound field that will update the Load and Job trailer IDs.
- Vehicle Type - a required drop-down list of whatever vehicle types are required.
Conveyance Collection jobs request the following job UDF:
- WAF No - a required text entry box
- Waste Description, comprising:
- A multi-check box
- An "Other" text entry box.
Customer Parameters must be configured and entered against the customers to appear on the report. The following 3 customer parameters are required:
- CARRIER_LICENSE
- SIC_CODE
- OPERATOR
These are required on the following customer records.
- CARRIER_LICENSE - entered against the Site customer record as the carrier license, and entered against the delivery customer as the disposal license number.
- SIC_CODE - entered against the collection customer.
- OPERATOR - entered against the delivery customer.
UDF has been prototyped for all of these and must be assigned to the appropriate job group.
Implementation Advice
Warning:
FUNCTIONAL DESCRIPTION
Grain Process and POD Note
The process for grain collections/deliveries is as follows:
- Jobs created in pairs - select the job group for the task.
- Each job must have a product and quantity.
- When jobs are assigned to the loads, the trailer id is entered if known. Multiple pairs of jobs can be assigned to the same load.
- At Load Start the driver will confirm or enter the trailer ID and vehicle type - each job completed will be stamped with this trailer ID. If the vehicle is fixed (not tractor), enter the vehicle reg instead.
- Start the collection job, navigate and arrive.
- Collect the product and confirm the product on the collection to full quantity (in tonnes).
- Obtain signature (if required?)
- Start the delivery job, navigate and arrive.
- Deliver the product and confirm the quantity (in tonnes).
- Clean the vehicle and capture the cleaning information.
- Capture the weighbridge ticket number and weight.
- Complete the job.
- Capture the signature.
When jobs are created and completed following these processes, the POD report may be produced.
The POD note has been prototyped as below:
POD Notes:
General:
- One line (the first found) of products will be shown, showing the description.
- The quantity of product is as entered/confirmed by the user, whilst the weight is as captured from the weighbridge weight.
- The POD note will be generated showing the last 3 products based on the trailer that was entered. This has required product development to achieve.
Page Header:
- RHS, FORS and FTA logos are embedded in the report.
- A site address (a customer record with the Site ID as the customer code) must be created for each site.
- Title "RORY J. HOLBROOK" is taken from the site customer name.
- "HAULAGE, TIPPER & PLANT HIRE" is fixed text in the report.
- The site address is taken from the site customer address
- As only 2 telephone numbers may be defined against a customer, the telephones numbers are largely hard-coded.
- "Consignment Note" is taken from the Job Code.
- "Date Raised" is taken from the actual start date.
- "Weighbridge Ticket No." is taken from the delivery job UDF field.
Initial Header:
- Collect From will utilise the Job Address of the collection job, if there is one, otherwise use the address of the Collection Customer.
- Deliver To will utilise the Job Address of the delivery job, if there is one, otherwise use the address of the Delivery Customer.
- Charge To will utilise the address of the Delivery Customer address.
- "COLLECT FROM"/"TIME/DATE IN" is taken from the collection job actual start date and time.
- "COLLECT FROM"/"TIME/DATE OUT" is taken from the collection job actual end date and time.
- "DELIVER TO"/"TIME/DATE IN" is taken from the delivery job actual start date and time.
- "DELIVER TO"/"TIME/DATE OUT" is taken from the delivery job actual end date and time.
- "VEHICLE REG. NO." is taken from the load's assigned vehicle.
- "DESCRIPTION OF GOODS" is taken from the description of the first product found on the job.
- "QUANTITY" is taken from the actual quantity of the first product found on the job.
- "WEIGHT" is taken from the delivery job UDF field.
Detail section: None (included in Initial Header section above).
Final Footer:
- "LAST 3 LOADS"/"1" is taken from the description of the first product found on the last collection job completed on this trailer.
- "CLEANED"/"1" is taken from the UDF field description of the last delivery job completed on this trailer.
- "LAST 3 LOADS"/"2" is taken from the description of the first product found on the next to last collection job completed on this trailer.
- "CLEANED"/"2" is taken from the UDF field description of the next to last delivery job completed on this trailer.
- "LAST 3 LOADS"/"3" is taken from the description of the first product found on the third last collection job completed on this trailer.
- "CLEANED"/"3" is taken from the UDF field description of the third last delivery job completed on this trailer.
Page Footer:
- "The above goods..." is taken from the terms and conditions configured against the delivery job.
- "Print Name" is taken from the customer signatory of the delivery job.
- "Signature" is taken from the signature of the delivery job.
- "Date" is taken from the actual end date of the delivery job.
- "Goods are accepted..." is fixed text in the report.
Conveyance Process and POD Note
The process for Conveyance collections/deliveries is as follows:
- Jobs created in pairs - select the job group for the task.
- Each job will have no products.
- When jobs are assigned to the loads, the trailer id is entered if known. Multiple pairs of jobs can be assigned to the same load.
- At Load Start the driver will confirm or enter the trailer ID and vehicle type - each job completed will be stamped with this trailer ID. If the vehicle is fixed (not tractor), enter the vehicle reg instead.
- Start the collection job, navigate and arrive.
- Enter the WAF No, tick the Waste boxes to record what was collected or enter other (including the EWC code).
- Obtain customer signature.
- Driver sign for collection.
- Start the delivery job, navigate and arrive.
- Complete the job.
- Capture the customer signature.
Note: This conveyance process does not use products - it uses UDF on the collection ONLY to capture what was picked up.
Note: It is possible that we could change that to assign the UDF against a product, and ask the driver to confirm the product collected, then enter the UDF against the product.
Warning: The real issue here is that UDF is NOT passed forward to a linked job, so the delivery will not be updated showing the driver what has been collected.
There is no other way of achieving this however.
Warning: Confirmation required of "Utilities/Unsegregated Waste" EWC code.
When jobs are created and completed following these processes, the POD report may be produced.
The POD note has been prototyped as below:
POD Notes:
- SIC code, Carrier License/License No and Operator are required to be defined as customer parameters.
- The final section of the header (comprising the Driver Signature, Vehicle Reg No, Vehicle Type, EWC Code, Customer Signature and Name has been redesigned to make the best use of the available space.
- The Waste Description section has been redesigned to include the EWC Code.
Page Header:
- "TICKET No" is taken from the Job Code.
- RHS and FORS logos are embedded in the report.
- A site address (a customer record with the Site ID as the customer code) must be created for each site.
- Title "RORY J. HOLBROOK" is taken from the site customer name.
- "HAULAGE, TIPPER & PLANT HIRE" is fixed text in the report.
- "Registered Office" is taken from the site customer address.
- "Carrier License" is taken from the Site Customer parameter "CARRIER_LICENSE".
- "Issued By" is fixed text in the report.
- "WAF No" is taken from the collection job UDF field.
- As only 2 telephone numbers may be defined against a customer, the telephones numbers are largely hard-coded.
- "Email" is taken from the site customer email address.
- "www.roryholbrook.com" is taken from the site customer contact.
- "Date" is taken from the actual start date of the collection job.
- "Time" is taken from the actual start time of the collection job.
Initial Header:
- "Customer Name"/"Customer Address" will utilise the address of the Delivery Customer address.
- "SIC Code" is taken from the Collection customer parameter "SIC_CODE".
- "Driver's Name" is taken from the load's assigned driver.
- "Collection Address" will utilise the Job Address of the collection job, if there is one, otherwise use the address of the Collection Customer.
- "Driver Signature" is taken from the collection job's driver signature.
- "Vehicle Reg No" is taken from the load's assigned vehicle.
- "Vehicle Type" is taken from the Load Metrics UDF field.
- "Customer Signature" is taken from the customer signature of the collection job.
- "Print Name" is taken from customer signatory of the collection job.
- "Waste Description" is taken from the collection job's UDF field "WASTE".
Detail section: None (included in Initial Header section above).
Final Footer:
- "Site Name"/"Site Address" will utilise the Job Address of the delivery job, if there is one, otherwise use the address of the Delivery Customer.
- "Operator" is taken from the delivery customer parameter "OPERATOR".
- "License No" is taken from the delivery customer parameter "CARRIER_LICENSE".
- "Issued By" is fixed text in the report.
- "Print Name" is taken from customer signatory of the delivery job.
- "Signature" is taken from the customer signature of the delivery job.
Note: colour copy footer information is not required or printed.
TECHNICAL NOTES
Modules Changed
Module Name | Module Type | Notes |
---|---|---|
1 | 2 | 3 |
Table Updates
Name | Type | Nullable | Default | Storage | Comments |
---|---|---|---|---|---|
1 | 2 | 3 | 4 | 5 | 6 |
Developer Notes
Last X Jobs
Information for the last jobs completed on the trailer are available through the following 'table' names:
* LXJ_JOB_1 - the collection job object for the first job (nearest to date that this job was completed). This object includes all details {containers, products, etc) * LXJ_JOB_2 * LXJ_JOB_3 - the collection job object for the third job (furthest of the 3 away from the date this job was completed). * LXJ_DELIVERY_JOB_1 - the delivery job linked to LXJ_JOB_1 by Job Code * LXJ_DELIVERY_JOB_2 * LXJ_DELIVERY_JOB_3 * LXJ_PRODUCT_1 - the first product on LXJ_JOB_1 * LXJ_PRODUCT_2 * LXJ_PRODUCT_3
In order for this to be used, the jobs MUST have trailer ID entered against them, either set in Admin, or entered by the user against e load (through Load Start Metrics) and inherited onto the jobs.
The data can be accessed in exactly the same way as any other field on any other table. For example, accessing a UDF Field on the 2nd delivery job is as follows:
- [LXJ_DELIVERY_JOB_2.EPOD_UDF_JOBDETS.CLEANING]
A list will be created of the last 3 jobs for that trailer, consisting of a class (LinkedJobs) of:
- The collection job EPOD_JOB_LXJ_COLLECTION.
- The associated delivery job EPOD_JOB_LXJ_DELIVERY.
A LastJob class will be created to store the results of the last 3 collection jobs found for that trailer, storing:
- The Load ID EPL_LOAD_ID.
- The Job ID EPL_JOB_ID.
- The Job Code EPL_JOB_CODE.
A GetLastXJobs method will be created, to get the last 3 collection jobs run on this trailer.
The method will be passed the job ID and a database connection.
The process will run the stored procedure EPOD_JOB_SELECT_LAST_3_COLLECTIONS2 passing parameters:
- EPL_SITE_ID
- EPL_JOB_ID
This will return (up to) the last 3 jobs for the trailer set on that job.
The method will loop through the result and store the load, job ID and job code in a LastJob class object and add this to a LastXCollections list.
The method will loop through this list and for each will retrieve:
- the collection job DAL object, through the Site ID and Job ID.
- the associated delivery job DAL object, through the Site ID, Job Code, Job Type (Delivery) and load ID.
These will be stored in a new LinkedJobs object, and added to the list lstLastXJobs
The process will fill this to exactly 3 rows if there are less than 3 returned.
The existing method GetDataForReport will be modified to call GetLastXJobs after getting all other data.
The existing method replaceDataTags will be modified to recognise the following data table names and translate them to an existing DAL object:
- LXJ_JOB_1 - the collection job object for the first job (nearest to date that this job was completed). This object includes all details )containers, products, etc). In this case, the data object oDalObj will be populated with lstLastXJobs[0].EPOD_JOB_LXJ_COLLECTION.
- LXJ_JOB_2 - In this case, the data object oDalObj will be populated with lstLastXJobs[1].EPOD_JOB_LXJ_COLLECTION.
- LXJ_JOB_3 - the collection job object for the third job (furthest of the 3 away from the date this job was completed). In this case, the data object oDalObj will be populated with lstLastXJobs[2].EPOD_JOB_LXJ_COLLECTION.
- LXJ_DELIVERY_JOB_1 - the delivery job linked to LXJ_JOB_1 by Job Code. In this case, the data object oDalObj will be populated with lstLastXJobs[0].EPOD_JOB_LXJ_DELIVERY.
- LXJ_DELIVERY_JOB_2 - In this case, the data object oDalObj will be populated with lstLastXJobs[1].EPOD_JOB_LXJ_DELIVERY.
- LXJ_DELIVERY_JOB_3 - In this case, the data object oDalObj will be populated with lstLastXJobs[2].EPOD_JOB_LXJ_DELIVERY.
- LXJ_PRODUCT_1 - the first product on LXJ_JOB_1. In this case, the data object oDalObj will be populated with lstLastXJobs[0].EPOD_JOB_LXJ_COLLECTION.EPOD_CONTAINERS[0].EPOD_PRODUCTS[0].
- LXJ_PRODUCT_2 - In this case, the data object oDalObj will be populated with lstLastXJobs[0].EPOD_JOB_LXJ_COLLECTION.EPOD_CONTAINERS[0].EPOD_PRODUCTS[0].
- LXJ_PRODUCT_3 - In this case, the data object oDalObj will be populated with lstLastXJobs[0].EPOD_JOB_LXJ_COLLECTION.EPOD_CONTAINERS[0].EPOD_PRODUCTS[0].
POD Design Notes
When accessing Last 3 Jobs information, they should be accessed as per the following example:
- [LXJ_DELIVERY_JOB_2.EPOD_UDF_JOBDETS.CLEANING]
When utilising customer parameters, they should be accessed as per the following example:
- [EPOD_COLLECTION_CUSTOMER.EPOD_ADM_PARAMETER_VALUES.SIC_CODE]
The actual parameter accessed depends on the parameter data configured as available for a customer and the parameters entered per customer.
The Waste Description section must be styled through the new UDF Fields classes.
TEST PLAN
Test Script / Scenario Reference | Rory Holbrook POD Notes | Call Number(s): 355526 |
Test Script / Scenario Description | description of what is to be achieved | PASS / ISSUES / FAIL |
Menu Access | Where on the menus the item can be found | |
Pre-requisites | The prerequisites of the test | Tested By: |
Test Objective | The details of what each group of tests is to achieve | Date: |
Step | Action | Result | Remarks | P/F |
1 | Area being tested in this cycle | |||
Any notes or prerequisites for the tests following. | ||||
1.01 | The actions to follow | The expected result | ||
1.02 | The actions to follow | The expected result | ||
1.03 | The actions to follow | The expected result |
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.00 | 0.00 | 850 | £0.00 |
Functional Specification | 0.00 | 0.00 | 850 | £0.00 |
Technical Specification | 0.00 | 0.00 | 850 | £0.00 |
Development | 0.00 | 0.00 | 850 | £0.00 |
Testing and Release | 0.00 | 0.00 | 850 | £0.00 |
Implementation | 0.00 | 0.00 | 850 | £0.00 |
Project Management | 0.00 | 0.00 | 850 | £0.00 |
TOTAL | 0.00 | 0.00 | £0.00 |
Estimate excludes training, release to live and go live support. |
References
Ref No | Document Title & ID | Version | Date |
1 | Reference1 | 0.1 | 26/02/2019 |
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
Rev1 | Murray Middleton | _____________________________ |
Rev2 | Customer Representative | _____________________________ |