FS 294838 Proctor ePOD Modifications
Proctors
Proctors ePOD Modifications
CALIDUS ePOD
09th January 2012 - 0.3
Reference: FS 294838
Contents
Functional Overview
Client Requirement
Solution Overview
Jobs will be received for Collection and Delivery from the following main customer types:
- Suppliers
- Customers
- Proctors-operated Warehouses
- 3rd Party Warehouses
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
Every Collection and Delivery will be specified separately within the interface, with the Product and Quantity specified for all jobs. Linked collections and deliveries will have the same Job ID, but will be distinguished by the Job Type (i.e. Collection, Delivery, Loading).
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/pallets.
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.
Note: If this data is not available at the time of Loading update, the system will check periodically through a regularly-scheduled automatic process.
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/pallets). 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.
If the Delivery has not been updated with the container details from the Loading process, the PDA will check at this time and force the retrieval of this data. If this is not available (either that the PDA cannot connect to retrieve this or the data is unavailable from the ERP system), the user will be offered the ability to scan products and quantities instead.
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. If this update is not successful, there will be a scheduled process that will regularly check and attempt to update when possible.
Scope
Set-up
Pre-requisites
For automatic updates through email and automatic emailing of POD/POC documents, the EPOD server must be configured with access to the customer's Email server.
Menu Structure
Data
Functional Description
- UPLOAD - Add new fields to the Upload process
- UPLOAD - Create Loading task from collection job if required
- UPLOAD - Specify Job Group based on customer type
- CUSTOMERS - Add Customer Type
- CUSTOMERS - Add Auto Email configuration
- New Loading Process
- Allow Loading tasks to be visible/enterable through Admin screens
- LOADING - ERP Direct Connect for Delivery Pallets information
- Pass Collection modifications to associated Deliveries.
- DELIVERY - Force Update to check for Loading details
- Update system to identify Jobs through ID and Type.
- DELIVERY - Container Only Delivery process
- Auto-update Client Systems
- Scheduled Auto-update process
CUSTOMERS - Add Customer Type
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.
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 re-enter 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:
- Customer with type Depot
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>
<DATA>
<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>
</DATA>
</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_RESPONSE>
Auto Export
Process
When Job update messages are received 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 transfer this to the destination.
If this process if successful then a flag on the Job record will be set to Y, and a success 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 successfully but a message is received 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 writing 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 receivers, 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 received from the PDA has been successfully committed.
Admin Modifications
A new screen will be required to set-up and configuration 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 | 5.00 | 0 | £0.00 |
| Technical Specification | 0.00 | 0 | £0.00 |
| Development | 35.00 | 0 | £0.00 |
| Testing and Release | 5.00 | 0 | £0.00 |
| Implementation | 2.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 | _____________________________ |
