REQ 305796 Partnerlink EPOD Solution
Partnerlink
Partnerlink ePOD Solution
CALIDUS ePOD
30th January 2013 - 0.1
Reference: REQ 305796
Contents
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".
SCR-305796-1: Change "Container" to "Pallet" on the device - 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.
Importing Data
Note: CALIDUS ePOD will be accepting data imports from 3 systems initially:
- Vigo
- Mandata
- Stirling
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.
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
| SCR-305796-3: | Layout changes to the Job List screen |
| SCR-305796-4: | Allow force updating of a Load from the Job List screen |
| SCR-305796-5: | Resequence Jobs |
Job Details
| SCR-305796-6: | Remove facility to Cancel a Job |
| SCR-305796-7: | Force viewing of Special Instructions on Starting Job |
| SCR-305796-8: | Allow force updating of a Job while in progress |
Delivery
| SCR-305796-9: | Allow back-out of a job after Arrival |
Collection
Warning: Collection with no containers - allow Notes entry at all times.
Job Confirmation
| SCR-305796-10: | Allow Customer to Clause delivery items |
Completion of a Load (Manifest)
Job Completion Documents
| SCR-305796-11: | Create POD Formats (Generic and Palletforce) |
Exporting Data
| SCR-305796-12: | Automatically email on cancellation of a job only |
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. |
| SCR-305796-14: | Export POD document as TIFF to Palletforce system |
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.
| SCR-305796-15: | Changes to ePOD-TTM interface |
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
| SCR-305796-16: | Trailer ID changes |
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 | _____________________________ |
