Introduction
This document is the Partnerlink ePOD Solution document.
Objective
The primary purpose of this document is to document the requirements gathered from Partnerlink, at meetings held in the Kinghts of Old offices on 22-24th January, 2012
This document has been written in a manner such that it can be approved by non-technical representatives of Partnerlink 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 Partnerlink, as referred to in the appendices, as well as information gleaned from site visits and workshops with Partnerlink.
- The changes will be made in the latest version of the CALIDUS ePOD system.
- All changes described to the PDA client will be made to the Android client only.
- Although it is possible to distribute the Android client through the existing Google Play market, it is assumed that all devices will be pre-installed with the latest Android client manually.
Client Requirements
Listed below are the proposed processes that will be followed by the operatives using CALIDUS ePOD. Also shown are the changes required for this to be achieved.
General Changes
A number of changes have been requested to the general styling of all areas of the system - the details are shown here:
- A Partnerlink-specific style will be created within the CALIDUS ePOD Android Client, for Partnerlink use. This will be modified so that all displays (labels, warnings and errors) within the application will show the word "Pallet" instead of "Container".
- The Login screen will also be modified to display the Partnerlink logo rather than the OBS logo.
 | SCR-305796-2: | Ensure that the correct Partnerlink logo is displayed on the device. |
This style can be set from the devices Settings screen and will be labelled as "Partnerlink" on the list of styles.
Importing Data
Note: CALIDUS ePOD will be accepting data imports from 3 systems initially:
The exact formats of the data uploads from the various systems are still being decided. However, there is a requirement that certain data items are passed into the system:
A basic list of all the fields in the interface for Load (Manifest) and Job follows. A full spreadsheet of all the import flows and fields containing all the limitations on length and defaulted values is provided separately and issued to all TMS suppliers.
EPOD_LOAD
| Name | Description | External Field | Notes |
| EPL_SITE_ID | EPL_SITE_ID: Unique reference of the site that the Load belongs to. | Partner Code | Partner Code of the partner executing the load. |
| EPL_LOAD_ID | EPL_LOAD_ID: Unique reference of the Load. | Manifest_No | The manifest number or Consolidated Manifest No |
| EPL_LOAD_START_PLANNED_DATE | | | These times will be defaulted by the EPOD system to the earliest and latest dates and times against the jobs provided, unless this information can be provided by the TMS |
| EPL_LOAD_START_PLANNED_TIME | | | No times will be provided for jobs. Therefore ETA will only start to be shown after the first job is started. |
| EPL_LOAD_END_PLANNED_DATE | | | As above |
| EPL_LOAD_END_PLANNED_TIME | | | As above |
| EPL_LOAD_DISTANCE_PLANNED | | | N/A |
| EPL_USER_ID | To be used if a user is predefined as assigned to complete this LOAD. | Driver Code | User to whom load assigned |
| EPL_VEHICLE_ID | To be used if a vehicle is predefined as assigned to complete this LOAD. | Vehicle | |
| EPL_TRAILER_ID | To be used if the vehicle above is a Tractor unit, and requires a trailer ID. This can be left blank to have this entered by the driver on demand. | ? | Provided if the vehicle requires a trailer ID and one is known. Otherwise left blank. |
| EPOD_JOBS | EPOD_JOBS contains a series of EPOD_JOB objects. | | |
EPOD_JOB
| Name | Description | External Field | Notes |
| EPL_SITE_ID | Unique Reference for the Site that the Job belongs to | partner code | Expected at this time to be one of "L01" to "L04" |
| EPL_LOAD_ID | Unique Reference for the Load that the Job belongs to. If not provided, defaulted from the enclosing EPOD_LOAD | Manifest_No | From the load record. |
| EPL_JOB_ID | Unique reference for the job. If not provided, this will be generated by EPOD | | Omitted - generated by EPOD |
| EPL_JOB_CODE | External reference for the Job. This element can be used to link a collection and delivery together under the same reference. So, if an order is being collected at A and delivered at B, there are 2 jobs, each with a unique Job ID, but with the same Job Code. Optionally, EPOD will keep the Delivery leg of a linked job updated with the information captured from the collection. | | |
| EPL_JOB_TYPE | D=Delivery, C=Collection, S=Service | "C" or "D" | |
| EPL_JOB_GROUP | | partner code | |
| EPL_CUST_REF | Customer's Order Reference | Ref2 | |
| EPL_JOB_INSTRUCTION | Instructions for the Driver | Notes1+Notes2 | |
| EPL_OFFICE_INSTRUCTION | Instructions for Admin staff | Notes3+Notes4 | |
| EPL_START_PLANNED_DATE | | Del_Date | If winroute in use, this can be provided. |
| EPL_START_PLANNED_TIME | | Time | May be defaulted to a time based on SLA. May be omitted. |
| EPL_END_PLANNED_DATE | | | N/A |
| EPL_END_PLANNED_TIME | | | N/A |
| EPL_DISTANCE_PLANNED | | | N/A |
| EPOD_CUSTOMER | This tag may be used to specify a Customer separately. If this is used, and the address and contact information on the job below is different, the EPOD system will create a Job Address specifically for this job, whilst maintaining the Customer information separately, as an Invoice address.
Note that this will happen if the Customer has been created previously either through another Job, another Customer Tag in a Job or a Customer Tag alone. | | N/A |
| EPL_CUSTOMER_CODE | Customer Code from external system. If not provided, one will be generated from EPL_CUSTOMER_NAME | account_code | |
| EPL_CUSTOMER_NAME | The Name of the customer | Del_Name | For collections, these values would be the Collection values, i.e. Col_Name, Col_post, etc. |
| EPL_ADDRESS_1 | | Del_addr1 | etc |
| EPL_ADDRESS_2 | | Del_addr2 | |
| EPL_ADDRESS_3 | | Del_addr3 | |
| EPL_ADDRESS_4 | | Del_addr4 | |
| EPL_ADDRESS_5 | | | N/A |
| EPL_POSTCODE | | Del_post | Col_post |
| EPL_CONTACT | Contact on site for the job. Can be changed at Job completion. | "" | This field is always to be sent blank, to force the users to enter a contact on the PDA client. |
| EPL_TELEPHONE | The Customer's Contact Telephone number | | |
| EPL_EMAIL | Contact Email address. Can be used to automatically send Job Completion documents to the customer. | | |
| EPL_OWNER_NAME | Can be used as a display field for documentation | (owning) partner code | Need to set this as the partner that owns the job (i.e. a JobShare job) rather than the partner who is executing the job. |
| EPL_SO_NUMBER | Sales Order Reference. | Ref3 | |
| EPL_ORDER_DATE | Date Order created - defaulted to Now() | | |
| EPL_SALES_CONTACT | The operative who took the order. Can be used as a display field for documentation | | N/A |
| EPL_SERVICE_LEVEL | | | N/A |
| EPL_SEQUENCE | The sequence in which the jobs are to be completed. If this is not provided, the system will allocate the jobs in the sequence in which they were provided in this interface i.e. first is "0001", second is "0002", etc. | | This is to be set by the TMS or defaulted by EPOD |
| EPL_TRAILER_ID | To be used if the vehicle being used to fulfil the job is a Tractor unit, and requires a trailer ID. This can be left blank to have this entered by the driver on demand. | | May be sent, if the vehicle requires a trailer ID and this is known at the time that the job is sent. |
| EPOD_CONTAINERS | Contains a series of EPOD_CONTAINER objects | | |
| EPOD_PRODUCTS | Contains a series of EPOD_PRODUCT objects | | N/A |
| EPOD_SERVICE | | | N/A |
EPOD_CONTAINER
| Name | Description | External Field | Notes |
| EPL_SITE_ID | | Partner Code | Defaulted |
| EPL_JOB_ID | | | From Job record |
| EPL_CONTAINER_ID | EPL_CONTAINER_ID: The unique identifier for a container. | Label_ID | Actually from the tracking id (an id for each pallet to be delivered). |
| EPL_SEQUENCE | The sequence in which the containers should be unloaded. | | |
| EPL_CONTAINER_PACKAGE_CODE | Container Type Code | EF/EH/EQ/SF/SH/SQ | Not required |
| EPL_CONTAINER_PACKAGE_DESC | Container Type Description | EURO FULL, etc | Not required |
| EPL_GROSS_WEIGHT | Gross weight of the container | Kilos | Not required, but may be useful? |
| EPL_DESCRIPTION_LONG | Long description of the container | | |
| EPL_CODE_1 | Additional code field used for any purpose | Spaces | Number of spaces taken on the vehicle. Required for documentation. |
| EPL_CODE_2 | Additional code field used for any purpose | | |
| EPL_CODE_3 | Additional code field used for any purpose | | |
| EPOD_PRODUCTS | EPOD_PRODUCTS contains a series of EPOD_PRODUCT objects associated to the container. | | Not used |
Notes:
- Jobs with planned start dates and times should be sent through on the message.
- Jobs without planned start dates and times, but with a service level agreement against them i.e. AM or PM deliveries, should have the time defaulted appropriately. For example:
- AM - set to 11:59
- PM - set to 16:59
- Jobs without any planned start times or service level agreements should leave the time unset (i.e. blank).
- The jobs should be sent through in the order in which they should be completed. The Sequence field should be sent with a numeric padded value as described in the description.
- Loads and the contained jobs will be sent as one message. Multiple loads can be built into one XML message structure.
- XSDs for validating the XML structure will be provided.
- At this time, it is unknown whether this is a complete list of changes. This document will be modified and re-issued if required.
Items above in bold are additional items, and the system will be modified to accept these new items.
Note: It is not deemed necessary at this time to map interfaces from the TMSs for Standing Data, as it was agreed that this would be maintained separately and manually within CALIDUS ePOD. Those flows are:
- Vehicles
- Reason Codes (used when cancelling jobs or pallets)
- Users (Drivers)
- Customers
The system will be configured to automatically create the Vehicles and Users with very basic information based off the received values in the Load and Job messages. Customers will be created as part of the information received through the Job messages.
At this stage, it is assumed that all Jobs have been grouped onto Manifests, and these have been assigned to a User and Vehicle. If required, a Trailer may already have been assigned.
The CALIDUS ePOD system will distribute Manifests to the correct users and vehicles, when the user logs on.
Logging In
The user will be provided a user ID and password. The user id will be the driver id assigned within the TMS systems. The password will be allocated to the user and both will be manually set up in advance in CALIDUS ePOD.
Upon logging in, the user will be prompted to enter the User ID, Vehicle and Password that they have been provided with. If there is any error regarding the values entered, the application will inform the user of the error. A pop-up keyboard will be displayed for entry of the details.
File:REQ-305796-X.PNG
Note: If the device has never been configured before, a configuration screen will be displayed. It is however expected that the device will be configured in advance.
If the user has a data connection, the unit will download all of the latest configuration data from the server, and a load to be completed. The load acquired will match the User and Vehicle entered.
If no load has been assigned to the user and vehicle, the unit will display a message and ask the user to recheck.
If a Load has been assigned, the user will be directed to the Job List screen, shown below.
Vehicle Checks
It is possible to configure the system so that vehicle checks are required to be completed after login, at the point that the load is found.
It is expected for the initial delivery phase that this will be disabled across the system. It is further expected that the Knights of Old partner will not require any vehicle check functionality in the future, as this will be managed by a separate application. Other partners will confirm their future requirements separately.
The frequency, type of questions, the text and entry type of the Vehicle Check process is completely user-definable through the EPOD Admin system. The configuration of the Vehicle Check process is sent to the EPOD Client when the user logs on.
When the user logs on, the unit will check the vehicle last check date to see if the interval (in days) between checks has been exceeded. If this is the case, the Vehicle Check will begin.
Each question configured will be displayed in sequence and the user will be prompted with response fields.
There are 4 types of answers allowed:
- Numeric - the user will be prompted to enter a number only as the response , for example, What is the current Mileage?
- Text - The user will be prompted to enter a text response.
- Boolean - The user is prompted to enter a yes or no response, for example, Does the Windscreen have any cracks?
- Option - The user will be prompted with a number of text boxes that must be checked.
The user is allowed to skip any questions that are not marked as required.
Upon completion of the checks, the answers to the checks and the Vehicle, User and Site IDs are transferred back to the CALIDUS ePOD server, where they can be viewed.
Job List
This screen shows all the jobs on the load that has been assigned to the driver.
File:REQ-305796-X.PNG
The screen displays a grid displaying details of each pending job. This will be modified for the bespoke styling as follows:
- Customer Name will be added to the top line
- Drop Sequence will be added to the left of the row, in large font.
- The time element will be doubled in size
- The date element will have the year removed.
- The product count will be removed.
The jobs are displayed in the sequence in which they should be completed, with the first job selected. Selecting any job will take the user to the Job Details screen, which displays more information on the job.
Clicking Exit here will exit the driver from the CALIDUS ePOD Client application, after confirming this is what they want to do.
It is to be noted that some of the partners require a facility of allowing jobs to be resequenced, whereas others require that this be done by the TMS admin staff. In the latter instance, it may be necessary for the user to force an update of this Job List screen from the server, rather than wait for a timed automatic update to be initiated. In this case, an option will be provided to the user to refresh the load at this time.
| SCR-305796-4: | Allow force updating of a Load from the Job List screen |
Note: This refresh must leave all completed and cancelled jobs on the device for viewing by the driver.
This screen has the facility to display all jobs at all statuses (Completed, Cancelled, Pending) - the driver can click the 'Show All Jobs button and the device will display the jobs, indicating the status as follows:
- The "In Progress" job will be displayed with a Yellow background
- "Complete" jobs will be displayed with a Green background.
- "Cancelled" jobs will be displayed with a Red background.
- "Complete (Amended)" jobs will be displayed with a blue background.
Job Details
This screen displays full details of the job being undertaken.
This screen will be displayed regardless of job type. The translated job type will be displayed on the top (i.e. COLLECTION, DELIVERY), along with the status (PENDING, COMPLETE, CANCELLED, COMPLETE AMENDED). The descriptive job code, as configured by the system, will be displayed in here as well.
File:REQ-305796-X.PNG
File:REQ-305796-X.PNG
The screen has several Tabs:
- Address & Contact:
- Customer Name
- Customer Address
- Contact - this will be blank initially, until the job is complete, when it will display the customer signatory.
- Contact Telephone
- Date and Time
- Instructions - any special instructions for the job.
The driver can click on the tabs to see the information contained.
From these tabs, the driver can:
- Call the customer by clicking on the Call button. This will start the device dialler, with the contact number already entered. Note: This option will only be available if there is a contact telephone number, and will not dial the number if the device's SIM is data only.
- Text the customer. This will start the text application on the device, with the contact telephone number entered and the job code added to the text initially. Note: This option will only be available if there is a contact telephone number.
- Navigate to the customer's address by clicking on the Map button. This will start the chosen navigation software on the device, passing the customer's address.
The driver can accept and start the job using the Start Job button.
It is to be noted that some of the partners require a facility of allowing jobs to be resequenced, whereas others require that this be done by the TMS admin staff. Therefore the application will be modified to allow configuration of this resequence process. A flag will be added that will allow the following:
- Disabled - in this instance, if the user presses the Start Job button, and the job is not the lowest sequence of all pending jobs on the load, the device will issue an error, stating that the job cannot be started out of sequence. On clearing the error, the user will be returned to the Job Details screen.
- Simple - in this instance, if the user presses the Start Job button, and the job is not the lowest sequence of all pending jobs on the load, the device will issue an option to the user, stating that the job is about to be completed out of sequence, requesting the user to confirm. If Cancel is chosen, the user will be returned to the Job Details screen. If Confirm is chosen, the device will allow the job to be started, but will inform the CALIDUS TTM system that the user completed the job out of sequence.
- Free - in this instance, the driver will be allowed to select any job to start. It will not be audited.
Note: If the job is at any status other than "Pending" or "In Progress", the device will display an error informing them that the job can't be started again.
The partners require the users to be forced to view the Special Instructions before starting a job. The application will be changed to force this, through configuration. If this is the case, and if the job is allowed to be started by the device, the device will check to see whether the Special Instructions tab has yet been viewed. If not, the device will display a pop-up message that these must be viewed before starting the job, and force the tab to be displayed.
| SCR-305796-6: | Force viewing of Special Instructions on Starting Job |
If the job is allowed to be started by the device, the job will be marked as In Progress on the device and in the CALIDUS TTM system. The device will also attempt to check the details of the job with the system, to see if anything has changed at this time that affects the completion of the job (instructions or address may have have changed, for example).
CALIDUS ePOD can be configured to require Arrival Times to be captured. If this is the case, the Start Job button will change label to 'Arrived'. If the user clicks Arrived, the CALIDUS TTM system will be informed.
If the user has arrived, or the system is not configured for arrival times, the user will be taken to the Collection or Delivery screens, depending on the job type.
It is to be noted that some of the partners will be configured to require resequencing of jobs to be done by the TMS admin staff. In this instance, it may be necessary for the user to force an update of the job from the server, rather than wait for a timed automatic update to be initiated. In this case, an option will be provided to the user to refresh the load at this time.
| SCR-305796-7: | Allow force updating of a Job while in progress |
If the driver wishes to cancel the job, they can press the Cancel button. The unit will take the driver to an Exception screen and prompt them to enter a reason code explaining why this job was cancelled. An image can be captured if required.
This cancellation process is not desired by some of the partners, so the application will be amended to control whether Job Cancellation is allowed at this stage.
Delivery
Collection
Warning: Collection with no containers - allow Notes entry at all times.
Job Confirmation
Completion of a Load (Manifest)
Job Completion Documents
Exporting Data
Note: CALIDUS ePOD will be sending data exports to 4 systems initially, with up to 3 being informed of completion at any one time:
- Vigo
- Mandata
- Stirling
- Palletforce
The exact formats and methodologies of the data exports from the various systems are still being decided. However, there is a requirement that certain data items are passed out of the system. The following tables show the additional data the system exports.
EPOD_JOB
| Name | Description | External Field | Notes |
| EPL_JOB_SIGNATURE | The signature taken from the customer when the job was completed. This is in the form of a Base64-encrypted Jpeg file | | |
| EPL_REASON_CODE | If a job has been cancelled, the reason code entered by the user is held here. | | |
| EPL_LINKED_REASON | If the job is a delivery, and a collection of the same load with the same EPL_JOB_CODE is cancelled, this delivery will be cancelled, and this field will be set to "Y" | | N/A |
| EPL_STATUS | C- complete, X cancelled | | |
| EPL_PHOTO_ID | If cancelled, a photo may have been taken by the user. If so, this field is populated with a unique ID. | | |
| EPL_PHOTO | The photo taken for the exception. This is in the form of a Base64-encrypted Jpeg file | | |
| EPL_ENG_SIGNATURE | The signature taken from the driver/engineer when the job was completed, if required. This is in the form of a Base64-encrypted Jpeg file | | |
| EPL_SEQUENCE | The sequence of the job. This could be the sequence sent on Import, a pre-defined sequence (if one was not provided) or a user-changed value (if enabled) | | |
| EPL_START_ACTUAL_DATE | The date the user actually chose to start the job. Format: YYYYMMDD | | |
| EPL_START_ACTUAL_TIME | The time the user actually chose to start the job. Format HHMMSSNN | | |
| EPL_ARRIVED_DATE_TIME | The date the user indicated they arrived at the destination. Format: YYYYMMDD | | |
| EPL_ARRIVED_DATE_TIME | The time the user indicated they arrived at the destination. Format HHMMSSNN | | |
| EPL_END_ACTUAL_DATE | The date the user completed or cancelled the job. Format: YYYYMMDD | | |
| EPL_END_ACTUAL_TIME | The time the user completed or cancelled the job. Format HHMMSSNN | | |
| EPL_JOB_ADDRESS | A flag indicating whether this is a default Customer Address or a specific address for this job alone. | | N/A |
| EPL_INVOICED | | | N/A |
| EPL_CUST_SIGNATORY | The name of the customer signatory on the job. | | |
| EPL_SIGNED_UNCHECKED | An indication whether the customer signed for the goods without checking them first. Note that this field can be used for any check-box entry, as this is configurable. | | |
| EPL_TRAILER_ID | To be used if the vehicle being used to fulfil the job is a Tractor unit, and a trailer ID has been entered by the user. | | |
| EPL_LAST_CHANGED_DATE | | | N/A |
| EPL_LAST_CHANGED_TIME | | | N/A |
EPOD_CONTAINER
| Name | Description | External Field | Notes |
| EPL_REASON_CODE | If a job has been cancelled, the reason code entered by the user is held here. | | |
| EPL_LINKED_REASON | If the job is a delivery, and a collection of this container on the same load with the same EPL_JOB_CODE is cancelled, this container will be cancelled, and this field will be set to "Y" | | |
| EPL_STATUS | EPL_STATUS: Status of the current Container. C-Completed, X-Cancelled. | | |
| EPL_PHOTO_ID | If cancelled, or received with a clause, a photo may have been taken by the user. If so, this field is populated with a unique ID. | | |
| EPL_PHOTO | The photo taken for the exception. This is in the form of a Base64-encrypted Jpeg file | | |
| EPL_CUST_COMMENTS | Optional entry by the user, indicating whether the customer has identified an issue with the received item (a claused receipt). If present, the customer may have requested an image, which would be contained in EPL_PHOTO. | | |
| EPL_LAST_CHANGED_DATE | | | N/A |
| EPL_LAST_CHANGED_TIME | | | N/A |
Items above in bold are additional items, and the system will be modified to export these new items.
Additionally, the system will be required to export the POD/POC documents automatically in TIFF format. This will also be required for the Palletforce system.
| SCR-305796-13: | Export POD document as TIFF through the existing Partnerlink processes. |
The system will also be required to act as a data source for the CALIDUS TTM system. This will require all imported data and all updated and completed data to be exported. This will be through the existing ePOD-TTM interface, as described elsewhere.
However, there will also be amendments to this interface to allow for the specific functionality described in this document, namely:
- Resequencing
- Order In Progress (to recalculate ETAs)
- Order Arrived
- Warning: any others?
Additional modifications will be made to TTM to allow it to access the POD document through a link. These are specified elsewhere.
Out of Scope Changes
This section details functionality requested to be added to the process above, that is not within the scope of the project.
Trailer IDs
Appendix A: Table of SCRs and Ballpark Estimates
| SCR# | System | Area | Description | Estimate (Days) | Notes |
| 1 |
System Affected |
Area Affected |
Description of change |
First argument to "number_format" must be a number. |
Any notes, numerically listed |
Notes:
- Any high level ballpark estimates for development are based on the basic information provided and are subject to detailed design and creation of an SCR.
- <Further notes, referenced in the notes column of the grid above>
Appendix B: Document References
B.1 References
| Ref No | Document Title & ID | Version | Date |
| 1 | Reference1 | 0.1 | 01/01/2011 |
B.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.
|
B.3 Authorised By
Phil Harding |
OBS Project Manager | _____________________________ |
