Functional Overview
Client Requirement
Solution Overview
Jobs will be received for Collection and Delivery from the following main areas:
- Suppliers
- Customers
- Proctors-operated Warehouses
- 3rd Party Warehouses
The CALIDUS EPOD Customers table will be modified to allow identification of the 4 main types of customer through the use of a new Customer Type field.
The jobs will be updated into the CALIDUS EPOD system through the standard WebService interface.
This job upload will create 3 tasks:
- A Loading job (if the From customer is a Proctors-operated Depot)
- A Collection Job
- A Delivery Job
The Upload system will also identify the Loads onto which jobs are planned, as all planning is completed through the Proctors' ERP system.
There are two types of job:
- Customer/Supplier jobs - jobs that begin or end with a Customer or Supplier.
- Inter-warehouse Transfer - jobs that begin and end from Warehouses
{warning} Is a 3rd-party to Proctors move a transfer?
All jobs will be categorised by the CALIDUS EPOD Job Group into one of the two categories - this will define the paperwork produced by the system when the job is completed.
A new stand-alone Loading process will be written to allow the users within the warehouse to identify the pallets loaded.
The Loading process will allow the user to:
- Identify the user and depot through a log-on procedure.
- Select a job for loading.
- Scan pallets on to the load. These will be scanned from the customers' own labels.
- Complete the load and update the CALIDUS EPOD system.
The Loading job will contain no validation or product entry - just an ad-hoc scanning of containers.
The loading update process within the EPOD server will query the ERP system for details on the quantity for each pallet loaded.
The pallet details will be passed to the delivery job associated to the load/collection, updating the Container and Product details with the Pallet and Product/Quantity details from the ERP system.
Collection jobs from a Proctors-operated warehouse will have no details associated to them - this job will simply be in instruction for a driver to drive to a location (defined by the customer code).
The process for a Collection of this type will simply be to confirm collection through a signature.
Collection jobs from a Customer, Supplier or 3rd party warehouse (i.e. non-Proctors) will have the Product and Quantity created against them (i.e. no containers). The process will be:
- Confirm arrival to customer/supplier/warehouse.
- Scan/Enter/Select Products to be collected.
- Confirm total quantity of the products.
- Once completed, confirm collection through customer/supplier signature.
A Delivery of a non-Proctors job will have only product and quantity details. The process will be:
- Confirm arrival to customer.
- Scan/Enter/Select Products to be delivered.
- Confirm total quantity of the products.
- Once completed, confirm delivery through customer signature.
A Delivery of Proctors job will have container (pallet), product and quantities. The process will be:
- Confirm arrival to customer/depot.
- Scan/Enter/Select pallets being delivered
- Once completed, confirm delivery through customer/depot signature.
Two new POD document formats will be created:
- A Delivery format, configured for use on Customer/Supplier jobs.
- A Transfer format, configured for use on Inter-warehouse Transfers.
In order for these to be created to match the current formats as closely as possible, the CALIDUS EPOD Job Import will be extended to add new fields.
Warning: format for POC from supplier?
CALIDUS EPOD will be set up to allow certain customers to be automatically emailed upon completion of jobs to and from them. When enabled, the format associated to the Job Group will be sent to the Customer's associated email address, if there is one.
Confirmation or cancellation of the final job on a particular reference (i.e. the final delivery of a job) will trigger an automatic update of the ERP system. This will be configurable but is expected to be through an email of the standard EPOD XML job update message.
Scope
Set-up
Pre-requisites
Data
Functional Description
Loading Process
Client
Login
User logs on with:
Customer – Valid Depot customer
Username
Password
Load list
After logon users are presented with a list of loads being dispatched from Customer(Depot), at status Ready for Loading.
As with exceptions a refresh will be sent every X seconds to update this data (only interested in changes or updates)
Load details:
Clicking a load will present the user with the load details.
Here users can either select to begin loading or cancel to return to the previous menu.
If a user select to being loading, a message is sent back to the server advising that loading has begun, updating the status, to prevent other users from loading this load. If the load is already being loaded/ has been updated/ has been removed, the server will respond advising of this.
Loading
The user will be presented with the list of products to be loaded. Clicking a product will allow the user to specify a container either through entry or scanner and a quantity of the product to be assigned to this container.
Once entered a container record will be created and the proportion of the product assigned to this container will be removed from the original product record.
The user will then be directed to the original product list which will be updated to reflect the update.
Once all products have been loaded, the user will be asked to confirm this and the updated load details will be sent back to the server. If there are discrepancies the user will be advised, giving them the option to reenter the products list. If they choose to ignore this the product record on the loose product record will be updated to advise that the actual quantity will be zero.
The user will then be navigated back to the Load List.
Server Modifications
New Login
This will need to be modified to allow for customer to be used instead of site.
The static data download will need to be altered ;
Removing:
- Service Products
- Vehicles
Adding:
XML
<LOGON_REQUEST_LOADING ID="0" SITE="LSM" USER="ADM" PASSWORD="TEST">
<EPL_SITE_ID>LSM</EPL_SITE_ID>
<EPL_USER_ID>ADM</EPL_USER_ID>
<EPL_CUSTOMER_CODE>ADM </EPL_CUSTOMER_CODE>
<EPL_LAST_UPDATE_DATE_TIME>2011-09-09T00:00:00</EPL_LAST_UPDATE_DATE_TIME>
</LOGON_REQUEST_LOAD>
<LOGON_RESPONSE_LOADING ID="0">
<RESULT>ACK</RESULT>
<DATE_TIME>2011-12-12T13:27:06.21325+00:00</DATE_TIME>
<EPOD_SITES>
<EPOD_SITE>..</EPOD_SITE>
</EPOD_SITES>
<EPOD_JOB_GROUPS>
<EPOD_JOB_GROUP>..</EPOD_JOB_GROUP>
</EPOD_JOB_GROUPS>
<EPOD_USERS>
<EPOD_USER>..</EPOD_USER>
</EPOD_USERS>
<EPOD_REASON_CODES>
<EPOD_REASON_CODE>..</EPOD_REASON_CODE>
</EPOD_REASON_CODES>
</LOGON_RESPONSE_LOADING>
Job List
A job list method will need to be added providing a list of current loads.
<LOADING_LIST_REQUEST ID="0" SITE="LSM" USER="ADM" PASSWORD="TEST">
<EPL_SITE_ID>LSM</EPL_SITE_ID>
<EPL_CUSTOMER_CODE>ADM </EPL_CUSTOMER_CODE>
</LOADING_LIST_REQUEST>
<LOADING_LIST_RESPONSE ID="0">
<EPOD_JOBS>
<EPOD_JOB>..</EPOD_JOB>
</EPOD_JOBS>
</LOADING_LIST_RESPONSE>
Job Update
A Job update method will need to be added
<LOADING_UPDATE_REQUEST ID="0" SITE="LSM" USER="ADM" PASSWORD="TEST">
<EPOD_JOB>..</EPOD_JOB>
</LOADING_UPDATE_REQUEST>
<LOADING_UPDATE_RESPONSE ID="0" RESULT="ACK">
</LOADING_UPDATE_REPSONSE>
Auto Export
Process
When Job update messages are recieved by the server and the changes are committed, the Auto Export flag will be checked against the Job Group and Site. If this flag is present the server will load the details of this export (Destination and Type), it will then generate the XML export as per the standard for currently existing exports and attempt to tranfer this to the destination.
If this process if sucessful then a flag on the Job record will be set to Y, and a sucess audit record written. If this fails the flag on the job will be set to N and a record will be written to a audit table with details of the failure. If the file is send sucessfully but a message is recieved from the destination advising of this problem then a audit record will be written and the flag will be set to N.
A timed process will be running to resend any Jobs with the flag of N, again writting audit records based on the result.
Audit records will be written with the following status's S for success, SF for success send but error at the recievers, and F for failure to send. These records will be cleared down once they are older than X.
DB Modifications
EPOD_JOB will require a new field of two characters EPL_EXPORTED, this will be defaulted to "".
EPOD_SITE and EPOD_JOB_GROUP will require a new field EPL_XF_CONFIG which will link to the EPL_XF_CONFIG_ID. If no export is required this will be blank.
A new table EPOD_XF_CONFIG will be created consisting of:
- EPL_XF_CONFIG_ID: A ten character unique field
- EPL_DESCRIPTION
- EPL_XF_TYPE: A ten character field identifying the type of export (SOAP, File, Email)
- EPL_XF_DESTINCATION: A 255 character field identifying the destination of the export
A new table EPOD_XF_AUDIT_HEADER will be created consisting of:
- EPL_HEADER_ID: A unique a autoincrement Id
- EPL_REQUEST_DATA: A max length free text field
- EPL_REQUEST DATE
- EPL_STATUS: Two character status field
A new table EPOD_XF_AUDIT_DETAIL will be created consisting of:
- EPL_HEADER_ID: Foreign key to EPOD_XF_AUDIT_HEADER
- EPL_DETAIL_ID: A unique a autoincrement Id
- EPL_REQUEST_DATE
- EPL_STATUS: Two character status field
Server Modifications
The current EPOD_JOB, EPOD_JOB_GROUPS and EPOD_SITE DAL objects will need to be modified for the new fields.
Three new DAL objects will need to be created for the new tables.
The JOB_UPDATE process within the Message_Process class needs to be modified to utilise the existing Data Service to perform the exports and written audit records. This should be done only once the data recieved from the PDA has been successfully committed.
Admin Modifications
A new screen will be required to setup and config data within EPOD_XF_CONFIG.
EPOD_SITE and EPOD_JOB_GROUP screens will need to be altered with the addition of the EPOD_XF_CONFIG field.
Appendix A: Quote & Document References
| Warning: | Unknown costs for client/year (PROC/2011) |
| Cost Details |
| Activity |
No. of Days |
Rate per Day (£) |
Cost (£ Exc. VAT) |
| Requirements |
0.00 |
0 |
£0.00 |
| Change Request Evaluation |
0.00 |
0 |
£0.00 |
| Functional Specification |
0.00 |
0 |
£0.00 |
| Technical Specification |
0.00 |
0 |
£0.00 |
| Development |
0.00 |
0 |
£0.00 |
| Testing and Release |
0.00 |
0 |
£0.00 |
| Implementation |
0.00 |
0 |
£0.00 |
| Project Management |
First argument to "number_format" must be a number. |
0 |
£First argument to "number_format" must be a number. |
| |
| TOTAL |
First argument to "number_format" must be a number. |
|
£First argument to "number_format" must be a number. |
| Estimate excludes training, release to live and go live support. |
A.1 References
| Ref No | Document Title & ID | Version | Date |
| 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
Matt Turner |
OBS Representative | _____________________________ |
Stephen McCartney |
OBS Representative | _____________________________ |
