REQ 312018 Bag It Up EPOD Requirements
Bag It Up
Bag It Up ePOD Requirements
CALIDUS ePOD
1st October 2013 - 0.3
Reference: REQ 312018
Contents
Introduction
This document is the Bag It Up ePOD Requirements document.
Objective
The primary purpose of this document is to document the requirements gathered from Bag It Up during the sales process, and to present an overview of the process that will be followed in and the work required to the CALIDUS ePOD system.
This document has been written in a manner such that it can be approved by non-technical representatives of Bag It Up whilst also being of sufficient detail to allow the Functional or Technical Specification phase for this area to begin.
Scope and Limitations
This document is based on the documentation provided by the OBS Logistics Sales team.
- The changes will be made in the latest version of the CALIDUS ePOD system.
- The changes have been specified with the Android PDA client in mind.
Client Requirements
Overview
Website: http://biugroup.co.uk/
Bag It Up recycle clothes from banks left at Supermarkets.
They require an ePOD solution to record the bags collected from the bins and the weights etc.
They will be using an existing back office solution to send jobs into ePOD and receive job information back.
There are approximately 15 vehicles, of which some (around 2) are Loader Cranes.
Log in:
Username as standard
Password will be 4 digit Numeric
Vehicle Checks
The client wants to do a vehicle check at the start of a load and record any defects at the finish of a load. Some of the information on the load will have to come from load metrics.
There are two examples of a daily vehicle check configured at vehicle level. Please attached form (Trip Sheet) and Loader crane.
Anything marked 'Office' on the form will be on the report but not be populated by ePOD.
Bank Defects will come from a variety of container cancellations and clausing through the standard process. Obviously, these forms will only be available at the end of a load.
Load and Job Processes
There are four main Job types that apply to each collection, delivery and require different pieces of data to be collected. The BIU system will indicate which job group should be applied to each job.
Job Type 1 - Standard Planned Collection of Recycled clothing from Supermarket banks
- Choose collection job
- Review job as normal and confirm arrival. Co-Pilot has not been purchased yet but is on the table.
- Containers will represent banks. Client will click on or scan each container to confirm how many bags have been collected. If container is so damaged that no bags will be collected,the container can be cancelled using the existing cancellation process. If the bank is damaged but bags can still be collected then the container should be claused. A claused container will still need a picture.
- Default qty for product in container is 0. User must choose change qty to indicate how many bags have been collected. No reason code should be entered at this stage.
- No signature is required
- At the end of a load that contains these collections, the user must enter weighbridge ticket no (up to five numeric digits) and weight (up to five numeric digits)
- No paperwork created for these deliveries. But all completed information must be exported to BIU systems
Example load - 20 collections and 1 delivery to drop off bags at weighbridge/recycling point
Job Type 2 - Planned Collection then enter weighbridge ticket information from on-board weigh system
- As above, job type 1, but at the end of collection before signature, the user must enter weighbridge ticket no and weight.
- Driver and Customer signatures are required
- Proof of Collection paperwork created for these deliveries.
Example load - 20 Collections or a mixed load with Job type 1
Job Type 3 - Ad - Hoc collection - Bank collection
- These are simply an ad-hoc job type 1 - no signature or collection note is required.
Job Type 4 - Ad - Hoc collection - Bag only collection
- As job type 3. User must answer the following:
- Material - Free text entry
- No of bags
- No signatures required
- No POC paperwork created.
Data Import
Loads and Jobs will be received received from the existing back-end system, including any standing data. The mechanism will be through the existing CALIDUS ePOD web services, using the existing XML formats. These will be made available to the customer for mapping exercises and external system coding. It is not expected that any changes will be required to the CALIDUS ePOD web services, other than related to any new functionality specified here.
The jobs will be grouped in types by use of the Job Group field on the interface. That will indicate the configuration of that particular job. So, the Collection jobs will be grouped into the 3 main Job types, and the delivery job will have it's own group.
PDA Login
A driver logs on to a device using their provided user name, password and vehicle.
The device client will be modified to allow a new customer style, which will ensure that the password entered is numeric only, as this is required by the customer.
Vehicle Checks
Vehicle Checks Sample
When log-in is complete, the device will prompt the driver for the vehicle checks required. These are customer-configurable, but are expected to contain:
- All Daily driver checks - these are required entry
- Loader Checks - these checks will be optional, as only some of the vehicles in the fleet are Loader Cranes.
Vehicle checks must be completed before the user is allowed to continue - there will not be an option to postpone Vehicle Checks.
Note: It is not deemed necessary to have different vehicle checks for different vehicle types, as the Loader Crane checks seemed similar to a guidelines document regarding optional checks than an enforced checking routing. However, if this was the case, then several further developments would be required within CALIDUS ePOD, including:
- Vehicle Types
- Vehicle Checks associated to Vehicle Types
Estimates have been provided for the work in Appendix B.
Obtain Workload
When vehicle checks are complete, the assigned work-list will be downloaded onto the device, showing all the jobs in sequence on a Job List screen.
The device will at this point prompt the user for Load Metrics, requiring only an ODO reading at this point.
Load Metrics
Note: All Metrics entered will be configurable in the CALIDUS ePOD. Initially this configuration will be completed by OBS staff, with product developments allowing customer configuration of this in the future.
Job List / Job Details
Selecting a job from the Job List will show the user the job report and customer contact details (on a Job Details screen). The user can back out of the selected Job and view any Job on the list.
When the user has selected their Job, they can choose the Job with the Start Job button. This will mark the Job as 'In Progress' status.
Note: It is system configurable whether the user is allowed to start Jobs out of the sequence on the Job List, or whether they will simply be warned on any issues.
The Job Details screen allows the user to contact the customer (through text or phone), or navigate to the customer's address (available only after choosing to start the job).
The device will use any navigation application installed on the device for this navigation.
Once the user arrives as the destination, they can indicate this and start processing the Job by clicking Arrive Job button.
Note: All process up to and including the engineer starting and arriving at the job are generic and described in detail in the user guides, as referenced in the appendices.
Note: The system as described here requires Fuel Drawn to be optionally entered as part of the Post-Load Metrics. If this is not suitable, then a more complex mechanism of allowing the user to use a menu item to record all Fuel Drawn events with ODO readings would need to be added to the Job List or Job Details screen. This would require further developments, including:
- Refuel ad-hoc action from Job List
- Load Export to combine Pre and Post vehicle checks and Refuel information.
Estimates have been provided for the work in Appendix B.
Collection Process
All jobs will be sent to the CALIDUS ePOD system with a configuration element known as Job Group - this will define the jobs into one of the 4 categories below.
The following are the standard tabs that are expected to be displayed, on some or all of the jobs.
Job Details Tab
Products Tab
Pop-up Actions
Note: There is an optional User Notes tab that can be displayed, allowing the user to enter any notes against the job before completion.
Type 1
Job Type 1 - Standard Planned Collection of Recycled clothing from Supermarket banks.
The Job Details tab will always be displayed, showing the customer contact information and any instructions on the Job.
A Products or Containers tab will be displayed - this will be labelled as 'Banks' for the BIU style. Each line will be a Bank to be processed (either collected or cancelled). The user will click on or scan each bank and will be prompted to confirm how many bags have been collected, through a pop-up quantity entry.
If the bank is so damaged that no bags will be collected, the collection from the bank can be cancelled by long-pressing on the line and choosing Cancel from the pop-up menu. The user will be prompted for a reason code and can optionally take an image of the bank.
If the bank is damaged but bags can still be collected, then the user can reflect this before entering the quantity by long-pressing and choosing the Clause option. This will pop open a similar screen to cancellation, but no reason code will be prompted for. The user will be able to enter some notes and take an image. The user will also be able to confirm the quantity at this time, or use the existing quantity entry process (clicking the line) after entering the description.
The default quantity for for the number of bags required for collection will be zero.
Once all detail has been entered, the user will be immediately taken to a Job Completion process, described below.
Type 2
Job Type 2 - Planned Collection then enter weighbridge ticket information from on board weigh system
The Job Details tab will always be displayed, showing the customer contact information and any instructions on the Job. Added to this tab will be an entry for Weighbridge Number and Weight. These will be validated as follows:
- Weighbridge Number - text, required entry
- Weight - numeric only, required entry
A Products or Containers tab will be displayed - this will be labelled as 'Banks' for the BIU style. Each line will be a Bank to be processed (either collected or cancelled). The user will click on or scan each bank and will be prompted to confirm how many bags have been collected, through a pop-up quantity entry.
If the bank is so damaged that no bags will be collected, the collection from the bank can be cancelled by long-pressing on the line and choosing Cancel from the pop-up menu. The user will be prompted for a reason code and can optionally take an image of the bank.
If the bank is damaged but bags can still be collected, then the user can reflect this before entering the quantity by long-pressing and choosing the Clause option. This will pop open a similar screen to cancellation, but no reason code will be prompted for. The user will be able to enter some notes and take an image. The user will also be able to confirm the quantity at this time, or use the existing quantity entry process (clicking the line) after entering the description.
The default quantity for for the number of bags required for collection will be zero.
Once all detail has been entered, the user will be immediately taken to a Job Completion process, described below.
Type 3
Job Type 3 - Ad-Hoc collection - Bank collection
Although this is an ad-hoc collection, that simply means that this job was not part of a scheduled pick-up round, but instead the customer called up and reported the bank full. The job is then added as normal to a round and sent to the driver as a normal type 1 job.
For all intents and purposes, these jobs will be marked as job type 1.
Type 4
Job Type 4 - Ad-Hoc collection - Bag only collection
The Job Details tab will always be displayed, showing the customer contact information and any instructions on the Job. Added to this tab will be an entry box for:
- Material - Free text entry
- No of bags - numeric-only entry
Note: Material could be presented to the user as a drop-down list, if the client can provide a list of the typical ones used. This may make it easier for the user to select the materials, but would not allow free-text entry.
A Done button will also be shown, allowing the user to complete this job, once all the fields have been entered.
No products or container tabs will be displayed.
Once all detail has been entered and the Done button clicked, the user will be immediately taken to a Job Completion process, described below.
Job Completion
The Job Completion process consists of any or all of the following depending on the Job Group configuration:
- Customer Signature
- Driver Signature
- Job Photo
Note: The specification assumes that jobs that are weighed with on-board weighing equipment will have the Weighbridge Number and Weight entered as part of the Job Details tab above. However, if this is required after signatures this will require a new feature adding, if configured for this:
- Job Metrics
Signature
New: Job Metrics (similar to Load Metrics)
If required, the process will display a pop-up similar to the Load Metrics screen, requiring the user to enter:
- ODO - numeric only, required entry
- Weighbridge Number - text, required entry
- Weight - numeric only, required entry
Note: The Metrics fields prompted for will be configurable.
Estimates have been provided for the work in Appendix B.
The different Job Types will require different configurations, as shown:
- Type 1 - No Signatures
- Type 2 - Driver and Customer signatures
- Type 3 - N/A
- Type 4 - No signatures
The user will be prompted to enter Customer signature and the signatory, if required. This screen also displays a summary of what has been collected and any configurable Terms and Conditions.
After this is completed, the user will be prompted to enter Driver signature, if required.
Note: After these have been completed, the system can be configured to require the user to take a Job Image.
Regardless of whether any of these optional items have been entered, the job will then be sent back to the CALIDUS ePOD server for completion, where all entered data, signatures, metrics and images will be stored and the job marked as complete. The user will be returned to the Job list screen, and the Job will be removed from the list.
Delivery Process
It is confirmed that all loads will be directed to a Weighbridge station for final weighing. This will be achieved by a final deliver job added to the Job list. This is optional and dependent on the existing back-end system. The user will be able to select this job and process the directions to the Weighbridge station.
The Delivery screens on the PDA client are largely identical to the Collection job type 4, but without the additional fields on the Job Details tab.
This job will not contain any details of what it to be taken to the depot - it will simply allow navigation to the depot and confirmation that the final delivery is complete, through a Done button against the Job Details tab on the delivery screens. No signatures will be required.
Post-Load
Once all Jobs have been completed, the load will be marked as completed when the user returns to the Job List screen. This will at this point prompt for Load Metrics again.
Load Metrics - Post
The screen will prompt for:
- ODO - numeric only, required entry
- Weighbridge Number - text, required entry
- Weight - numeric only, required entry
- Defects - text, optional entry
- Fuel Drawn - numeric only, optional entry
Note: Fuel Drawn has been added here as a optional element, in preference to developing a new Fuel action driven from the Job List (see section Job List / Job Details for details of this). However, if this more complex change is required, Fuel Drawn can be removed from this Load Metrics screen.
After these are completed (and details have been sent back to the CALIDUS ePOD server, the system will then prompt the user to complete Vehicle Checks again. The details prompted during these checks will be identical to those prompted before the start of the Load.
It was noted against the Trip Sheet that the driver must sign a declaration that the information on the sheet is correct. It is expected that the use of individual user-names and passwords will render this manual requirement redundant. However, if required, this would need to be added to the Post-Load process at this point, by showing a variant of the Job Signature screen, with Terms and Conditions set to the Driver's Declaration.
Estimates have been provided for the work in Appendix B
Once all these processes have been completed, the device will attempt to download a new load for the user and vehicle. If one has not been provided, the device will confirm this and allow the user to check again or log off the system.
Report Format
When collections are completed, some job types will require a POC document be provided to the customers.
This format will be configurable against the Job Group for the individual job types. It is not necessary (but is recommended) that a POC and POD format is set against all Job types, even if they are not to be automatically emailed to the customers on completion of the job. Other job types and the deliveries can use a standard format.
The format of this document is shown in Appendix A. Note: The POC document format shown here has been confirmed as out of date - this is being redesigned by the customer and will be provided at a later date. It has been confirmed that the redesign will not add any further entry fields to the process. The existing format has been used for the purposes of this document.
The various elements on the form will be mapped as follows:
- Number - External Collection ID (Job Code)
- Date - Actual End Date
- BIU Vehicle Reg. No - Driver's Vehicle Registration
- Site - Customer's Name and Address
- Textile Banks - only populated if this is a Type 3 Job
- No. of banks serviced - As entered
- Weight - From Job Metrics
- Weighbridge ticket no. - From Job Metrics
- Other - only populated if this is a Type 4 Job
- Materials - As entered
- Bags/Sacks/Boxes - As entered
- Weight - From Job Metrics
- Weighbridge ticket no. - From Job Metrics
- Authorisation
- BIU Group Signature - Driver Signature
- Name - Driver Name
- Signed on behalf of Site - Customer Signature
- Name - Signatory
Note: Best efforts will be made to match the produced format to the sample provided, but differences in production and presentation (i.e. Browser, Email, etc) may result in some small differences. Specifically, the signatures will require more space than allowed in the current sample.
No other reports are seen to be required to be produced from CALIDUS ePOD - all data required is exported to the existing back-end server and the reports are expected to be produced from that system (i.e. the Trip sheet). However, if this is necessary, then several further changes may need to be completed, including:
- Vehicle Checks linked to Loads
- Vehicle Checks Report
- Trip Report from Load Admin screen
Estimates have been provided for the work in Appendix B.
Data Export
When jobs have been completed all the job is updated in the CALIDUS ePOD server, these jobs are then available for exporting to external systems. The standard interface allows for the jobs to be exported to a web service, folder or FTP server in standard XML format. This format, and mapping documents, are available and will be issued after development has been agreed and specified, as the developments contained within this document may result in changes to the XSD.
The standard Job XML format is expected to include:
- All Job data imported
- Actual Start, Arrival and End dates and Times
- All Field data entered by the users when completing the jobs
- All Signatures and signatory information
- All Images taken against the Job or Banks
- All Job Metrics (if required)
- All banks serviced, along with clause and status information.
This information will be sent for any completed or cancelled job, collection or delivery.
Note: Any claused or cancelled products should be identified as Bank Defects in the back-end system.
For jobs that have been completed, POC documents may need to be sent to the customer for certain job types. CALIDUS ePOD does this by checking the job's Email address and, if set and the system is configured to do so, it will send an email through the Bag It Up mail server to the customer address specified. If no address is specified, no email will be sent.
Note: If the customer email mechanism described above is not applicable (for example, if the email address against the customer cannot be blocked for type 1 and 2 jobs on import), then this may need to be replaced with an Export Configuration mechanism defined at Job Group level. Once already exists, but does not allow Email as an option, so this would have to be modified, as follows:
- Configurable POD Export - add email export
Estimates have been provided for the work in Appendix B.
Currently, the system does not export Vehicle Check information - it is expected that the export processes, both automatic and requested through a web service, will need to be modified to allow this. All completed vehicle checks would be exported to destination specified in the configuration, which could be set up for the system as a whole or for particular Job Groups only.
Once all Load information is complete (the Load Metrics and, if required, the Driver's Declaration), a Load export is sent from . This will include:
- All Load data imported
- Actual Start, Arrival and End dates and Times
- All Load Metrics (Pre and Post)
- Driver Declaration and Signature (optional development)
Note: This automatic export of completion information need not be pushed from the system - it can be requested through a web service connection as required by the back-end system.
Note: If all the Trip Sheet information is to be sent together on the same message (i.e. combining the vehicle checks and Load messages together), significant further development would be required, including:
- Vehicle Checks linked to Loads
- Load Export to combine Pre and Post vehicle checks and Refuel information.
- Interface Import and Export changes
Estimates have been provided for the work in Appendix B.
Appendix A: Client Documents
Loader Crane
Trip Sheet
POC Format
Appendix B: Table of SCRs
| SCR# | System | Area | Description | Estimate (Days) | Notes |
| 1 | ePOD | PDA/Admin | Customer Style (including logo, specific labels and numeric-only password). | 1.75 | |
| 2 | ePOD | PDA/Server | Job Details UDF fields against Job Group/Collection plus Done button (For collection types 2, 4 and delivery). | 3.50 | |
| 3 | ePOD | PDA | Vehicle Checks required entry. | 2.10 | 2 |
| 4 | ePOD | PDA/Server | Add Weight/Weighbridge/Defects against Load Metrics at end only (UDF). | 3.50 | |
| 5 | ePOD | All | Clausing (for Bank Defect) from Product screen, with images. | 4.20 | |
| 6 | ePOD | PDA | Product Quantity Entry if required quantity is 0. | 1.40 | |
| 7 | ePOD | Export | Vehicle Checks Auto-Export. | 3.50 | |
| 8 | ePOD | Admin | POC Report format. | 1.40 | |
| 9 | ePOD | PDA | Customer Signature not required. | 2.80 | 2 |
| 10 | ePOD | Admin | Remove Container/Product tabs if there aren't any. | 2.10 | 2 |
Notes:
- All ballpark costs in this document are provided as-is, are legally non-binding and subject to raising a formal change request with OBS Logistics.
- These are product modifications
Note: During the analysis process the following changes were discussed but marked as not-required:
| SCR# | System | Area | Description | Estimate (Days) | Notes |
| 11 | ePOD | All | Driver Declaration - Signature against Load when complete (for Vehicle Checks) or against Vehicle Checks | 0.00 | |
| 12 | ePOD | PDA/Server | Vehicle Checks linked to Loads | 4.20 | |
| 13 | ePOD | PDA | Vehicle Checks at end of load | 2.10 | |
| 14 | ePOD | All | Refuel ad-hoc action from Job List | 7.00 | |
| 15 | ePOD | PDA/Server | Job Metrics with Weight/Weighbridge entry (UDF). | 3.50 | |
| 16 | ePOD | Admin | Vehicle Checks Report | 2.10 | |
| 17 | ePOD | Admin | Trip Report from Load Admin screen | 4.20 | |
| 18 | ePOD | Export | Load Export to combine Pre and Post vehicle checks and Refuel information. | 1.40 | |
| 19 | ePOD | Export | Configurable POD Export - add email export | 2.10 | 2 |
| 20 | ePOD | All | Vehicle Types | 2.80 | |
| 21 | ePOD | All | Vehicle Checks associated to Vehicle Types | 7.00 | |
| 22 | ePOD | Import/Export | Interface Import and Export changes | 4.20 |
Notes:
- All estimates in this section are seen to be outside the scope of the delivery - they are provided as indicators of external cost for additional phased deliveries.
- These are product modifications
Appendix C: Document References
C.1 References
| Ref No | Document Title & ID | Version | Date |
| 1 | UG 291094 EPOD Admin User Guide | 2.0 | 4/4/2012 |
| 2 | UG 291097 EPOD Client User Guide | 3.0 | 23/4/2013 |
C.2 Glossary
| Term | Definition |
|---|---|
| EPOD | Electronic Proof of Delivery. The OBS EPOD system is CALIDUS ePOD. |
| CALIDUS eSERV | The OBS mobile system to complete Service functionality in the field. This is part of the CALIDUS ePOD system. |
| PDA | The mobile device on which the C-ePOD system will run in the field. This can be a Phone, EDA or industrial PDA, running Android. |
| DAL | Data Access Layer. A mechanism for accessing data by the system that is removed from the application, allowing for simplified access and providing protection to the data, as only approved DAL methods can be used to modify it. |
| GPS | Global Positioning System. A mechanism of retrieving accurate positioning information in the form of Latitude and Longitude (Lat-Long) co-ordinates from a device. |
| GPRS, 3G, HSDPA, Data Service | All terms referring to mobile device network connectivity, and the speed at which the device connects to the internet. |
C.3 Authorised By
Matt Turner | OBS Account Manager | _____________________________ |
Client Representative | _____________________________ |
