REQ 305796 Partnerlink EPOD Solution: Difference between revisions
(Confirmed System and Area across the list of SCRs) |
m (Categorisation of document pages) |
||
(One intermediate revision by the same user not shown) | |||
Line 3: | Line 3: | ||
{{#vardefine:ClientName|Partnerlink}} | {{#vardefine:ClientName|Partnerlink}} | ||
{{#vardefine:System|''CALIDUS'' ePOD}} | {{#vardefine:System|''CALIDUS'' ePOD}} | ||
{{#vardefine:SystemCode|EPOD}} | |||
{{#vardefine:Doc_Title|Partnerlink ePOD Solution}} | {{#vardefine:Doc_Title|Partnerlink ePOD Solution}} | ||
{{#vardefine:Version|0.2}} | {{#vardefine:Version|0.2}} | ||
Line 787: | Line 788: | ||
<!-- MEDIA LANDSCAPE NO --> | <!-- MEDIA LANDSCAPE NO --> | ||
= Appendix B: Data Setup = | |||
== Reason Codes == | |||
The following reason codes and descriptions will be set up in ''CALIDUS'' ePOD: | |||
*ACCNON - ACCEPTABLE NON-CONFORMANCE | |||
*CUST - CUSTOMER ISSUE | |||
*DRIV - DRIVER ISSUE | |||
*INPU - INPUT ERROR | |||
*MISC - MISCELLANEOUS | |||
*PARTNER - PARTNER ISSUE | |||
*SUBCON - SUNCONTRACTOR ISSUE | |||
*TRAF - TRAFFIC DEPARTMENT ISSUE | |||
*WARE - WAREHOUSE ISSUE | |||
<!-- NEW PAGE --> | |||
{{Doc_Appendix | {{Doc_Appendix | ||
|Appendix= | |Appendix=C | ||
|Estimate=N | |Estimate=N | ||
|Glossary=EPOD | |Glossary=EPOD | ||
Line 808: | Line 823: | ||
}}</div> | }}</div> | ||
[[Category:{{#var:Client}} REQ]] | [[Category:{{#var:Client}} REQ]] | ||
[[Category:{{#var:SystemCode}}]] |
Latest revision as of 11:54, 29 November 2019
Partnerlink
Partnerlink ePOD Solution
CALIDUS ePOD
31st January 2013 - 0.2
Reference: REQ 305796
Contents
- 1 Introduction
- 2 Client Requirements
- 3 Appendix A: Table of SCRs
- 4 Appendix B: Data Setup
- 5 Appendix C: Document References
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 Knights 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 Android Client Login screen and CALIDUS TTM will be modified to display the correct Partnerlink logo rather than the OBS logo.
SCR-305796-2: Ensure that the correct Partnerlink logo is displayed.
This style can be set from the Android devices' Settings screen and will be labelled as "Partnerlink" on the list of styles, and will be set as default in CALIDUS TTM.
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
This screen shows all the jobs on the load that has been assigned to the driver.
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.
![]() | SCR-305796-3: | Layout changes to the Job List screen |
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.
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.
![]() | SCR-305796-5: | Resequence Jobs |
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. Note: The reason codes offered to the driver will be those configured within the system for the cancellation of a job, rather than those relevant to the cancellation of a deliverable item. The Reason Codes will be maintained manually within CALIDUS ePOD by the users.
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.
![]() | SCR-305796-8: | Remove facility to Cancel a Job |
Delivery
If the job type is a Delivery, the driver will be shown this screen. They will be initially presented with the information about the job.
Note: As mentioned previously, the system will be modified to display the word 'Pallet' where the word 'Container is used in the description below.
The screen has several tabs:
- Job Details - this screen displays:
- The Contact Name (initially blank)
- The Contact Telephone
- The Planned Date and Time
- The Special Instructions
- Containers - a list of all containers to be delivered, showing:
- The Container ID
- The UOM Description
- The Status
- The Weight
- A count of any contained products
- An entry box and Deliver button, to manually enter containers.
- A Scan button to scan containers
- Products - this will be changed to not be displayed in this configuration, as there are no products to scan.
- A configurable Notes tab, to allow the user to enter notes about the job.
To mark containers as delivered, the driver can:
- press the Scan button and scan the barcode on the label
- manually enter the container ID in the text box and click the Deliver button.
- press the row on the grid and select Deliver from the pop-up menu.
This will remove the container from the list and mark it as delivered on the device.
To identify a container as not delivered, the driver can press the row on the grid and select Cancel from the pop-up menu. The unit will take the driver to an Exception screen and prompt them to enter a reason code explaining why this container was cancelled. An image can be captured if required. Note: The reason codes offered to the driver will be those configured within the system for the cancellation of a deliverable item, rather than those relevant to the cancellation of a job. The Reason Codes will be maintained manually within CALIDUS ePOD by the Admin users.
The driver is also able to see the either the details of a particular container in a pop-up screen, by pressing the row and selecting Info from the pop-up menu. This displays:
- ID
- Package Code and Description
- Weight
- Multi-use Code fields (1-3).
Note: For the Partnerlink-specific style, the label for the first Code field will be changed to 'Spaces'
![]() | SCR-305796-9: | Change label of Container CODE 1 field to "Spaces" |
The driver also has the option to enter any notes they want on the Notes tab.
Once all containers have been delivered, the device will automatically take the driver to the Job Confirmation screen.
Note: By standard, when Arrival times are in use, once a job is marked as Arrived, the device will:
- not allow the user to exit the Job Details screen without completing or cancelling a job
- if entering the application after a job has been marked as Arrived, forcing the user straight into completing the job.
The partners decided that this restriction would need to be relaxed, as there were instances where the driver may arrive and then be informed that there is a considerable wait at the site.
Therefore the application will be changed to allow it to be configured to add a Postpone button on the Job Details tab. This will request the user to enter a description of why the job is being postponed at this stage. If Cancel is clicked, the driver will be returned to the Delivery screen. If a reason is entered and the user clicks Confirm, the device will mark the order as postponed and inform CALIDUS TTM that the order has been postponed (through a Resequence message, providing the text as a description). The user will be returned to the Job List screen, and the job will be seen as Pending again.
Note: If resequencing is allowed, the driver will be allowed to select the next pending job for delivery, avoiding the Postponed job.
![]() | SCR-305796-10: | Allow Postponement of a job after Arrival |
Collection
The processing of collections on the device is identical to the processing of deliveries.
In summary:
- The driver will select the collection from the Job List.
- The driver can see the Job Details, Containers and Notes tabs.
- The driver can scan, key or touch containers to mark them as collected.
- The driver can cancel the job.
- Once all containers are collected, the driver will be automatically taken to the Job Confirmation screen.
In addition, all changes specified in the delivery process will apply to the collection process:
- The label of CODE 1 will change to "Spaces" when showing container info.
- The collection job may be postponed.
It was noted that some of the partners may not know the items they are collecting when they schedule the job. It os possible for the driver to arrive at the customer's site not knowing what to collect. In this instance, the user will only be able to enter notes in the Notes tab. It is expected that the user will enter the number of pallets collected here.
Job Confirmation
When the driver has confirmed that all the containers have been delivered or collected, the device will display the Job Confirmation screen. This screen controls the confirmation that the job has been completed satisfactorily.
The process can be configured for:
- Customer Signature
- Driver Signature
- Document Photo Capture
It is expected that this will be configured only for Customer signature, for both collections and deliveries.
The Customer Signature box defaults to the customer's contact name - as this will not be sent to CALIDUS ePOD, this will be blank and must be entered by the driver.
To clear the signature, click Clear.
The screen will also display any configured terms and conditions, and up to 3 check boxes for the user to confirm.
The screen contains a tab showing the Containers that were scanned as delivered or collected on the job. The customer may wish to accept the containers, but note that the pallets have some issue that may later be claimed against (i.e. a Clause delivery). This tab will be modified (for deliveries only) to:
- Display against the container whether it has been claused.
- add a button to allow the user to identify claused pallets.
![]() | SCR-305796-11: | Allow Customer to Clause delivery items |
When the button is pressed, the device will display a pop-up screen displaying the details of the pallet selected, a text box to enter the clause text, and an OK and Cancel buttons. If Cancel is pressed, the user will be returned to the Signature screen. If OK is pressed and clause text has been entered, a pop-up message will be displayed that the container has been claused and the signature screen will be refreshed, displaying the claused containers and clearing the signature.
The driver can complete the job by clicking Done. If the signatory and signature have been entered, they will be prompted to confirm that everything is OK with the signature before continuing.
Note: The PDA can also be configured for Document Photo Capture. When configured for this, the PDA will start the Photo Capture dialogue after all signatures have been captured. This can be used to take an image (for example, of a delivery docket) at this point. If this is enabled, the image must be taken.
Once the Signatures are captured, the driver will be returned to the Job List to pick up the next task.
The completed job will be transferred to the main system with all the details, signatures and photos. CALIDUS TTM will be informed of the completion of the job.
Completion of a Load (Manifest)
All jobs on the manifest on the job list will be completed in this manner. As each are actioned (for example, sequenced, started, arrived, completed or cancelled), the device will send messages back to CALIDUS ePOD, to inform CALIDUS TTM, so that the audit information can be displayed.
Once all jobs on a manifest are completed, the device will inform the driver and ask the user if they need to check for more work. If so, the device will check for another manifest assigned to the driver. If one is found, the new manifest will be loaded and displayed on the job list screen. If one is not found, the user can exit or check again.
If there is still data awaiting sending to CALIDUS ePOD, the device will continue trying to send this at this time.
Job Completion Documents
It is expected that the majority of customers will still require paper PODs for the foreseeable future. These documents will continue to be signed by the customer, returned by the driver, and scanned into the existing Partnerlink systems by admin staff.
However, CALIDUS ePOD can produce electronic versions of POD and POC documents if required. In this instance, the partners will require two formats:
- A generic Partnerlink format
- A Palletforce format
![]() | SCR-305796-12: | Create POD Formats (Generic and Palletforce) |
Note: The formats of these POD and POC documents have not yet been designed and as such may drive further change into the CALIDUS ePOD processes. As this becomes known, this will be reflected in this document or later functional specifications.
These Job Completion documents will be visible through CALIDUS TTM and will be exported through this mechanism, as seen in the next section.
Exporting Data
{{#varSystem}} can be configured to automatically export data out in various formats to external systems. This currently consists of:
- Automatic Emails of Job Completion (POC/POD) documents (on confirmation only)
- Export in XML format through Web Service or Email of Completion Data
This requires significant modification for the Partnerlink implementation as 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_TNCS | An XML fragment, displaying the Terms and Conditions agreed to by the customer when signing for the goods. This can also include up to 3 configurable check-boxes that the user may check. | ||
EPL_USER_NOTES | Optional Notes entered by the driver while completing the job. | ||
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
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 |
There is an additional requirement to email a central email address when a job has been cancelled, to keep Partnerlink Admin staff appraised of drivers' decisions.
![]() | SCR-305796-16: | Automatically email on cancellation of a job only |
Note: Emails being sent from CALIDUS ePOD require that the server has connectivity to a mail server. This is normally provided by the client, but is to be confirmed.
Tracking the Jobs
CALIDUS TTM will show all jobs and manifests sent through to be executed. The standard functionality in place regarding enquiries, extracts,departure boards and user configuration is seen to be sufficient to run the operation. The system will also show all audit trails of activity as they happen in the system.
The activity enquiries on orders will be extended in the system to add:
- Resequencing
- Order In Progress
- Order Arrived
It was noted that that the styling of CALIDUS TTM would also require some changes to labels in the system, to closer match the client terminology, for example, "Trip" will be displayed as "Manifest", "Exception" as "Clause".
The system will be configured so that partners can see the jobs that they own (through the Owner parameter) and see and select those partners who are executing a shared job (through the Haulier).
The system calculates and displays ETAs, as follows:
- The original ETA of jobs will be set based on the Planned information sent to CALIDUS ePOD, if provided.
- When an In Progress message is received (when a Job is started), the system will then recalculate all ETAs forwards from that point, by requesting mapping drive times between each stop as they are planned. Each stop will have a minimum unload time associated with it, expected to be half an hour, but this will be configurable.
- A system user can request the latest ETA from the system, which will query the last known position and time of the vehicle, and recalculate the ETA from that position at that time. This will also pass forward to all subsequent jobs on that manifest.
![]() | SCR-305796-17: | Display and recalculate ETA |
The system will ensure that the new functionality for Claused deliveries are seen as Exceptions in TTM, and displayed with the amber colouration. Additionally, the descriptions against the Claused items will be visible in the system
![]() | SCR-305796-18: | Add Clause functionality to CALIDUS TTM |
The existing Order "Enquiry by Client Order No" screen will be modified to allow searching by customer name and Customer PO Code.
![]() | SCR-305796-19: | Add additional search criteria to CALIDUS TTM |
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
It was noted that it would be necessary to track Trailer IDs throughout the process, where the vehicle being used by the driver is a tractor type. Multiple changes must be made to the processes and the system to accommodate this.
![]() | SCR-305796-20: | Trailer ID changes |
It has been determined that this is out of scope of the project, but a description of the processes follow for documentation purposes.
- When an Manifest or a Job is sent to CALIDUS ePOD, it may contain Trailer information. If this is the case, and the vehicle does not already exist, the Vehicle will be updated to show that it requires the entry of Trailers. The generic maintenance of vehicles within the system will also change to allow this flag to be maintained.
- When the Job List is displayed, if there is a trailer associated to the Load, this will be displayed on the screen. If the trailer does not exist on the load but exists on the job, the trailer required to complete the first job will be displayed.
- If neither exist, the driver will be prompted to enter the Trailer used against the Load.
- The driver will have an option of changing the Trailer used at any time.
- Where a trailer has not been defined, the driver's entry will be stored against the job and the load. This will be returned to the CALIDUS TTM and TMS systems for traceability.
It should also be noted that there is a requirement to report this information through CALIDUS TTM, as an attempt to provide some asset tracking to the trailers. It is assumed that the existing data extract is suitable, as it can be imported into Microsoft Excel for processing, and the trailer ID can be queried directly the existing screens.
Appendix A: Table of SCRs
SCR# | System | Area | Description | Estimate (Days) | Notes |
1 | EPOD | Client | Change "Container" to "Pallet" on the device | N/A | |
2 | EPOD/TTM | All | Ensure that the correct Partnerlink logo is displayed. | N/A | |
3 | EPOD | Client | Layout changes to the Job List screen | N/A | |
4 | EPOD | Client | Allow force updating of a Load from the Job List screen | N/A | |
5 | EPOD | All | Resequence Jobs | N/A | |
6 | EPOD | Client | Force viewing of Special Instructions on Starting Job | N/A | |
7 | EPOD | Client | Allow force updating of a Job while in progress | N/A | |
8 | EPOD | Client | Remove facility to Cancel a Job | N/A | |
9 | EPOD | Client | Change label of Container CODE 1 field to "Spaces" | N/A | |
10 | EPOD | Client | Allow Postponement of a job after Arrival | N/A | |
11 | EPOD | All | Allow Customer to Clause delivery items | N/A | |
12 | EPOD | Admin | Create POD Formats (Generic and Palletforce) | N/A | |
13 | EPOD | Export | Export POD document as TIFF through the existing Partnerlink processes | N/A | |
14 | EPOD | Export | Export POD document as TIFF to Palletforce system | N/A | |
15 | EPOD/TTM | I/F | Changes to ePOD-TTM interface | N/A | |
16 | EPOD | Server | Automatically email on cancellation of a job only | N/A | |
17 | TTM | Server | Display and recalculate ETA | N/A | |
18 | TTM | All | Add Clause functionality to CALIDUS TTM | N/A | |
19 | TTM | Admin | Add additional search criteria to CALIDUS TTM | N/A | |
20 | EPOD/TTM | All | Trailer ID changes | N/A |
Appendix B: Data Setup
Reason Codes
The following reason codes and descriptions will be set up in CALIDUS ePOD:
- ACCNON - ACCEPTABLE NON-CONFORMANCE
- CUST - CUSTOMER ISSUE
- DRIV - DRIVER ISSUE
- INPU - INPUT ERROR
- MISC - MISCELLANEOUS
- PARTNER - PARTNER ISSUE
- SUBCON - SUNCONTRACTOR ISSUE
- TRAF - TRAFFIC DEPARTMENT ISSUE
- WARE - WAREHOUSE ISSUE
Appendix C: Document References
C.1 References
Ref No | Document Title & ID | Version | Date |
1 |
C.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. |
C.3 Authorised By
Phil Harding | OBS Project Manager | _____________________________ |