FS 297001 Prolog EPOD Modifications: Difference between revisions

From Calidus HUB
mNo edit summary
(Changed Site configuration to Job Group configuration)
Line 30: Line 30:
There will be up to 52 containers/products per load.
There will be up to 52 containers/products per load.


There will be 3 sites, allocated to each Depot.
There will be 3 job groups, allocated to each Depot.


== Client Requirement  ==
== Client Requirement  ==
Line 151: Line 151:


===Admin Screens===
===Admin Screens===
The Admin Users will be provided log-ons for each site required - these will be manually created within the Admin system itself.  
The Admin Users will be provided log-ons - these will be manually created within the Admin system itself. Each log-on can be configured to see all Job Groups (Depots) or a selection of job groups only.


These users will be able to view (and create) loads and jobs within the system, as well as view the completion documents for completed jobs, or view images of exceptions on cancelled jobs.
These users will be able to view (and create) loads and jobs within the system, as well as view the completion documents for completed jobs, or view images of exceptions on cancelled jobs.

Revision as of 16:15, 27 February 2012





Aptean Logo.png







PROLOG

Prolog EPOD Modifications


CALIDUS EPOD

24th February 2012 - 0.1
Reference: FS 297001












































Functional Overview

There will be 35 PDA users and 5 Admin users hosted by the Prolog system.

There will be 35 loads per day.

There will be approximately 10 jobs per load.

There will be up to 52 containers/products per load.

There will be 3 job groups, allocated to each Depot.

Client Requirement

The client requires an implementation of the CALIDUS EPOD system, following the functionality as described below.

Solution Overview

Import Data

Import and Export of Jobs and Loads will be through the existing standard Web Services.

An Owner field added to the Job import, to allow the client system to specify the Depot (e.g. Britvic).

The Customer information (i.e. customer code, name address and contact details) will be sent as part of Job, so that this information can be placed on the resulting completion document (POD or POC).

Delivery jobs will be sent with one container record and multiple product records. The container record will be provided with a description of the required pallets and weight (for example, "2 Pallets / 174.0 Kg"). All products associated to the job will be added to this container, detailing the product code, description and quantity.

Collection jobs will have no product or container details, just job instructions detailing the products and quantities to be collected.

Linked Collections and Deliveries (i.e. collecting from a supplier and delivering directly to a customer on the same trip) will be required. In this instance, the jobs will be linked by having the same Job Code on each job.

Additional Standing Data Web Services will be provided to allow the client system to upload Vehicles and Drivers to CALIDUS EPOD. Drivers will be added as PDA users through the WebService interface. If no Site ID is specified against the driver, the user will be created in all available Sites. If a password is not provided, the user will not be added. Vehicles will be added to a specific site.

The Load import includes the Driver assigned to the Load.

Warning Warning: Currently the client system allocates jobs to a Vehicle, not a Driver, whilst CALIDUS EPOD assigns by the User ID (the Driver). In the requirements meeting, did we decide which will be changed, EPOD or Transport system?

Note Note: Inter-warehouse Transfers are not expected to be included in the initial running of the system, as these are currently handled manually. In a future phase (i.e. after go-live of the initial phase), these may be added into the client host system for processing or, alternatively, they will be created manually within CALIDUS EPOD and attached to existing loads.

PDA Log-on

Each Driver will have a PDA with the CALIDUS EPOD system installed and configured on it. The user will log in with a User ID and password provided to them, and a Vehicle ID, chosen from a list.

Vehicle Checks

If the vehicle being used has not been checked recently, the unit will direct the user to complete the Vehicle Checks. The data entry and checks here are configurable within the Admin system. The checks required will be sent to OBS so that they can configure the checks required at this stage.

Metrics

Once a load has been downloaded, the unit will check whether the system requires Current Mileage entry against the load. If so, the unit will request the user to enter the mileage at this point.

Note Note: The user will also be prompted to enter the mileage once all jobs on the load are complete.

The user will then be shown a list all the jobs on the load that has been assigned to the user. The jobs are displayed in the order in which they should be completed. However, the jobs can be completed in any sequence by clicking the line of the job required to to be completed first and then clicking the OK button. The user will then be taken to the Job Details page, which displays the full details of the job being undertaken. The screen has several Tabs, each showing:

  • The Job Type (Collection, Delivery, Service)
  • The customer details (Customer Code, Name, Address and Postcode)
  • The contact information (Contact name and number)
  • The Instructions for the job

From these tabs, the user can:

  • Call the customer by clicking on the Call button.
  • Navigate to the customer's address by clicking on the Navigate button.

Again, here the user can choose which job to complete by using the supplied left and right buttons or start a job with the OK button, when either a Collection or Delivery process will begin.

Note Note: The job can be cancelled at this stage by clicking the Cancel button. The unit will take to the user to an Exception screen and prompt them to enter a reason code explaining why this job was cancelled. See the Exception process for more information.

Collection Process

For collections, the user will be shown instructions for the job, with a list of all required products and quantities to collect.

If the collection is successful with no changes, the user will click the OK button to confirm this and be taken to the Confirmation process.

If nothing can be collected, the user can press the Cancel button here and will be directed to the Exception process.

If there has been a problem with the collection, the user will click the Notes tab and enter details on the adjustment to the collection. Once complete, the user will then press the OK button and be taken to the Confirmation process.

Delivery Process

Deliveries (from Depots to Customers) will be configured to ensure that the PDA unit only requires the user to confirm containers rather than individual products, as follows:

The user will be shown a list of containers only. The description on here will display the number of pallets.

By long-clicking on the container, the user can view a list of all the products in this container.

If all has been delivered successfully, the user will click the Collected button and be taken to the Confirmation process.

If nothing can be delivered, the user can press the Cancel button here and will be directed to the Exception process.

If there has been a problem with the delivery, the user will click the Notes tab and enter details on the adjustment to the delivery. Once complete, the user will then press the OK button and be taken to the Confirmation process.

Deliveries (from a supplier to a customer direct) will not follow this process, as no container or product details will have been provided on the job. The Notes information from the collection will have been automatically updated onto the associated delivery, so the user will be able to see what was collected. The user will be able to confirm the delivery with the OK button, cancel the delivery through the Cancel button and amend the notes as above.

Exception Process

This screen will be displayed if the user is cancelling an entire job, as described in the previous sections.

When cancelling a Job, the user is asked to enter a reason for the cancellation or shortage. These reasons are configurable within the administrative system. These will be generic reasons agreed and mapped to the client host system.

If necessary, the user can capture an image to support this reason, by clicking the Image button. The user can then use the device's camera to capture an image. When complete, the user will exit and will be allowed to view the captured image and add a note to the image to explain.

Once the exception is complete, the user will be returned to the job list, to complete the next job.

Confirmation Process

The expected configuration for both Collections and Deliveries will be that the user will be prompted to sign for the job, then the customer will be asked to sign for this also.

The Name defaults to the customer contact name (if present on the job) and allows the user to change this.

Once completed, The user will be returned to the Job Menu to pick up the next task.

The completed job will be transferred back to the main CALIDUS EPOD system with all the details, signatures and photos.

Once all jobs are completed on that load, the user will be prompted to enter the mileage of the vehicle. This and the starting mileage will be sent back to the main CALIDUS EPOD system and stored against the load.

Export Data

When data is sent back to the server for jobs completed or cancelled, the server will mark this data to be sent automatically on to the client host system. This will be through a regularly scheduled process (i.e. every few minutes). All jobs completed in this manner will be forwarded on to a configured Web Service within the client host system, in the standard CALIDUS EPOD format.

Warning Warning: Is it required to send through the mileage captured against the load as well or is this to be held in EPOD only?

Completion Documents (POD/POC)

This automated process will also create the Completion documents in PDF format and email them to a central email address, configured against the site in CALIDUS EPOD.

A document will be generated for every collection and delivery completed (i.e. not cancelled).

The format for both collections and deliveries will be the same and will match the current documentation.

Warning Warning: Consignment Barcode - is this required?

Warning Warning: What is the data item "SM0425 00000 00113306"?

Warning Warning: The data contained in the barcode is not the number above - what is this?

Data Clear-down

A data clear-down script will be written and scheduled to run on the host server. This will check the job and image data files and clear down any records older than a specific date.

Note Note: If this is hosted at OBS, the responsibility of creating and running this script will be OBS'. If hosted by the client, this will be the responsibility of the client.

Admin Screens

The Admin Users will be provided log-ons - these will be manually created within the Admin system itself. Each log-on can be configured to see all Job Groups (Depots) or a selection of job groups only.

These users will be able to view (and create) loads and jobs within the system, as well as view the completion documents for completed jobs, or view images of exceptions on cancelled jobs.

No changes need to be made within the Administration screen in the CALIDUS EPOD system, as both the entered Notes and advised Owner can be seen when viewing the completion document within the Admin system.

Note Note: Inter-warehouse Transfers are not expected to be included in the initial running of the system, as these are currently handled manually. In a future phase (i.e. after go-live of the initial phase), these may be added into the client host system for processing or, alternatively, they will be created manually within CALIDUS EPOD and attached to existing loads.

Scope

Set-up

Pre-requisites

Menu Structure

Data

Functional Description

Functional Area 1

Appendix A: Document References

A.1 References

Ref NoDocument Title & IDVersionDate
1   


A.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.


A.3 Authorised By


Tony Walker

Consultant
_____________________________

Matt Turner

OBS Representative
_____________________________