REQ 305796 Partnerlink EPOD Solution: Difference between revisions

From Calidus HUB
VisualWikitext
(Added description of general changes)
m (Categorisation of document pages)
 
(11 intermediate revisions 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.1}}
{{#vardefine:Version|0.2}}
{{#vardefine:Date|30th January 2013}}
{{#vardefine:Date|31st January 2013}}
{{#vardefine:Reference|305796}}
{{#vardefine:Reference|305796}}
{{#vardefine:Year|2013}}
{{#vardefine:Year|2013}}
Line 26: Line 27:


== Objective  ==
== Objective  ==
The primary purpose of this document is to document the requirements gathered from {{#var:ClientName}}, at meetings held in the Kinghts of Old offices on 22-24th January, 2012
The primary purpose of this document is to document the requirements gathered from {{#var:ClientName}}, 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 {{#var:ClientName}} whilst also being of sufficient detail to allow the Functional or Technical Specification phase for this area to begin.
This document has been written in a manner such that it can be approved by non-technical representatives of {{#var:ClientName}} whilst also being of sufficient detail to allow the Functional or Technical Specification phase for this area to begin.
Line 33: Line 34:
This document is based on the documentation provided by {{#var:ClientName}}, as referred to in the appendices, as well as information gleaned from site visits and workshops with {{#var:ClientName}}.
This document is based on the documentation provided by {{#var:ClientName}}, as referred to in the appendices, as well as information gleaned from site visits and workshops with {{#var:ClientName}}.
<!-- ANY scope or limitations, bulleted. -->
<!-- ANY scope or limitations, bulleted. -->
*The changes will be made in the latest version of the {{#var:System}} system.
* The changes will be made in the latest version of the {{#var:System}} 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.
{{ #vardefine: SCR | 0 }}
{{ #vardefine: SCR | 0 }}
<!-- NEW PAGE -->  
<!-- NEW PAGE -->  
Line 46: Line 49:
|Definition=Change "Container" to "Pallet" on the device
|Definition=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
* The Android Client Login screen and ''CALIDUS'' TTM will be modified to display the correct Partnerlink logo rather than the OBS logo. {{SCR
|Reference={{#var:Reference}}
|Reference={{#var:Reference}}
|SCRNo={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}
|SCRNo={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}
|Definition=Ensure that the correct Partnerlink logo is displayed on the device.
|Definition=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 ==
== Importing Data ==
Line 57: Line 62:
* Mandata
* Mandata
* Stirling
* 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:
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.
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.
Line 85: Line 90:
<tr><td>EPL_JOB_CODE</td><td>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.</td><td>&nbsp;</td><td>&nbsp;</td></tr>
<tr><td>EPL_JOB_CODE</td><td>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.</td><td>&nbsp;</td><td>&nbsp;</td></tr>
<tr><td>EPL_JOB_TYPE</td><td>D=Delivery, C=Collection, S=Service</td><td>"C" or "D"</td><td>&nbsp;</td></tr>
<tr><td>EPL_JOB_TYPE</td><td>D=Delivery, C=Collection, S=Service</td><td>"C" or "D"</td><td>&nbsp;</td></tr>
<tr><td>EPL_JOB_GROUP</td><td>&nbsp;</td><td>partner code</td><td>&nbsp;</td></tr>
<tr><td>EPL_JOB_GROUP</td><td>&nbsp;</td><td>partner code</td><td>{{Note}} Palletforce jobs must be allocated their own Job Group (e.g. "PF") in order to get their own POD format.</td></tr>
<tr><td>EPL_CUST_REF</td><td>Customer's Order Reference</td><td>Ref2</td><td>&nbsp;</td></tr>
<tr><td>EPL_CUST_REF</td><td>Customer's Order Reference</td><td>Ref2</td><td>&nbsp;</td></tr>
<tr><td>EPL_JOB_INSTRUCTION</td><td>Instructions for the Driver</td><td>Notes1+Notes2</td><td>&nbsp;</td></tr>
<tr><td>EPL_JOB_INSTRUCTION</td><td>Instructions for the Driver</td><td>Notes1+Notes2</td><td>&nbsp;</td></tr>
Line 154: Line 159:
* Customers  
* 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.  
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 {{#var:System}} system will distribute Manifests to the correct users and vehicles, when the user logs on.


== Logging In ==
== 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 {{#var:System}}.
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-1.PNG|border|250px]]
{{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 ==
== 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 {{#var:System}} server, where they can be viewed.


== Job List ==
== Job List ==
This screen shows all the jobs on the load that has been assigned to the driver.
[[File:REQ-305796-2.PNG|border|250px]]
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
{{SCR
|Reference={{#var:Reference}}
|Reference={{#var:Reference}}
Line 165: Line 218:
|Definition=Layout changes to the Job List screen
|Definition=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 {{#var:System}} 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
{{SCR
Line 171: Line 230:
|Definition=Allow force updating of a Load from the Job List screen
|Definition=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-3a.PNG|border|250px]]
[[File:REQ-305796-3b.PNG|border|250px]]
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
{{SCR
Line 178: Line 271:
}}
}}


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
|Reference={{#var:Reference}}
|SCRNo={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}
|Definition=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).
{{#var:System}} 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.


== Job Details ==
{{SCR
{{SCR
|Reference={{#var:Reference}}
|Reference={{#var:Reference}}
|SCRNo={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}
|SCRNo={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}
|Definition=Remove facility to Cancel a Job
|Definition=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 {{#var:System}} 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
{{SCR
|Reference={{#var:Reference}}
|Reference={{#var:Reference}}
|SCRNo={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}
|SCRNo={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}
|Definition=Force viewing of Special Instructions on Starting Job
|Definition=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.
[[File:REQ-305796-4a.PNG|border|250px]]
{{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.
[[File:REQ-305796-4b.PNG|border|250px]]
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 {{#var:System}} 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
{{SCR
|Reference={{#var:Reference}}
|Reference={{#var:Reference}}
|SCRNo={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}
|SCRNo={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}
|Definition=Allow force updating of a Job while in progress
|Definition=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.
[[File:REQ-305796-4c.PNG|border|250px]]
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.


== Delivery ==
{{SCR
{{SCR
|Reference={{#var:Reference}}
|Reference={{#var:Reference}}
|SCRNo={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}
|SCRNo={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}
|Definition=Allow back-out of a job after Arrival
|Definition=Allow Postponement of a job after Arrival
}}
}}


== Collection ==
== Collection ==
{{warning}} Collection with no containers - allow Notes entry at all times.
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 ==
== 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.
[[File:REQ-305796-5.PNG|border|250px]]
The ''Customer Signature'' box defaults to the customer's contact name - as this will not be sent to {{#var:System}}, 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
{{SCR
|Reference={{#var:Reference}}
|Reference={{#var:Reference}}
Line 215: Line 418:
|Definition=Allow Customer to Clause delivery items
|Definition=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) ==
== 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 {{#var:System}}, 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 {{#var:System}}, the device will continue trying to send this at this time.


== Job Completion Documents ==
== 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, {{#var:System}} 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
{{SCR
|Reference={{#var:Reference}}
|Reference={{#var:Reference}}
Line 224: Line 447:
|Definition=Create POD Formats (Generic and Palletforce)
|Definition=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 {{#var:System}} 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 ==
== Exporting Data ==
{{SCR
{{#varSystem}} can be configured to automatically export data out in various formats to external systems. This currently consists of:
|Reference={{#var:Reference}}
* Automatic Emails of Job Completion (POC/POD) documents (on confirmation only)
|SCRNo={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}
* Export in XML format through Web Service or Email of Completion Data
|Definition=Automatically email on cancellation of a job only
This requires significant modification for the Partnerlink implementation as {{#var:System}} will be sending data exports to 4 systems initially, with up to 3 being informed of completion at any one time:
}}
 
{{Note}} {{#var:System}} will be sending data exports to 4 systems initially, with up to 3 being informed of completion at any one time:
* Vigo
* Vigo
* Mandata
* Mandata
Line 260: Line 483:
<tr><td>EPL_CUST_SIGNATORY</td><td>The name of the customer signatory on the job.</td><td>&nbsp;</td><td>&nbsp;</td></tr>
<tr><td>EPL_CUST_SIGNATORY</td><td>The name of the customer signatory on the job.</td><td>&nbsp;</td><td>&nbsp;</td></tr>
<tr><td>EPL_SIGNED_UNCHECKED</td><td>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.</td><td>&nbsp;</td><td>&nbsp;</td></tr>
<tr><td>EPL_SIGNED_UNCHECKED</td><td>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.</td><td>&nbsp;</td><td>&nbsp;</td></tr>
<tr><td>EPL_TNCS</td><td>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.</td><td>&nbsp;</td><td>&nbsp;</td></tr>
<tr><td>EPL_USER_NOTES</td><td>Optional Notes entered by the driver while completing the job.</td><td>&nbsp;</td><td>&nbsp;</td></tr>
<tr><td>'''EPL_TRAILER_ID'''</td><td>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.</td><td>&nbsp;</td><td>&nbsp;</td></tr>
<tr><td>'''EPL_TRAILER_ID'''</td><td>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.</td><td>&nbsp;</td><td>&nbsp;</td></tr>
<tr><td>EPL_LAST_CHANGED_DATE</td><td>&nbsp;</td><td>&nbsp;</td><td>N/A</td></tr>
<tr><td>EPL_LAST_CHANGED_DATE</td><td>&nbsp;</td><td>&nbsp;</td><td>N/A</td></tr>
Line 300: Line 525:
* Order In Progress (to recalculate ETAs)
* Order In Progress (to recalculate ETAs)
* Order Arrived
* 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.
Additional modifications will be made to TTM to allow it to access the POD document through a link. These are specified elsewhere.


Line 307: Line 531:
|SCRNo={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}
|SCRNo={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}
|Definition=Changes to ePOD-TTM interface
|Definition=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
|Reference={{#var:Reference}}
|SCRNo={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}
|Definition=Automatically email on cancellation of a job only
}}
{{Note}} Emails being sent from {{#var:System}} 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 {{#var:System}}, 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
|Reference={{#var:Reference}}
|SCRNo={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}
|Definition=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
|Reference={{#var:Reference}}
|SCRNo={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}
|Definition=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
|Reference={{#var:Reference}}
|SCRNo={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}
|Definition=Add additional search criteria to ''CALIDUS'' TTM
}}
}}


Line 312: Line 580:
This section details functionality requested to be added to the process above, that is not within the scope of the project.
This section details functionality requested to be added to the process above, that is not within the scope of the project.


=== Trailer IDs ==
=== 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
{{SCR
|Reference={{#var:Reference}}
|Reference={{#var:Reference}}
Line 318: Line 587:
|Definition=Trailer ID changes
|Definition=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 {{#var:System}}, 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.


<!-- MEDIA LANDSCAPE YES -->  
<!-- MEDIA LANDSCAPE YES -->


= Appendix A: Table of SCRs and Ballpark Estimates  =
= Appendix A: Table of SCRs =
<!-- If there’s only one system being discussed here, the system column can be removed.
<!-- If there’s only one system being discussed here, the system column can be removed.
Ballpark estimates may not be required to be included in this document. If they are, include the column, and note 1. Estimates should be rounded up, and should be produced using the standard mechanism of estimates (i.e. any standard spreadsheet designed to automate the production of estimates). The total line need only be added if the estimates are being produced at this point
Ballpark estimates may not be required to be included in this document. If they are, include the column, and note 1. Estimates should be rounded up, and should be produced using the standard mechanism of estimates (i.e. any standard spreadsheet designed to automate the production of estimates). The total line need only be added if the estimates are being produced at this point
Line 329: Line 605:


{{ #vardefine: SCR | 0 }}
{{ #vardefine: SCR | 0 }}
{{REQ_SCR_Header}}
{{REQ_SCR_Header}}{{REQ_SCR_Line
|SCR={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}
|System=EPOD
|Area=Client
|Description=Change "Container" to "Pallet" on the device
|Estimate=0
|Notes=
|Days=N
}}
{{REQ_SCR_Line
|SCR={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}
|System=EPOD/TTM
|Area=All
|Description=Ensure that the correct Partnerlink logo is displayed.
|Estimate=0
|Notes=
|Days=N
}}
{{REQ_SCR_Line
|SCR={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}
|System=EPOD
|Area=Client
|Description=Layout changes to the Job List screen
|Estimate=0
|Notes=
|Days=N
}}
{{REQ_SCR_Line
{{REQ_SCR_Line
|SCR={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}
|SCR={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}
|System=System Affected
|System=EPOD
|Area=Area Affected
|Area=Client
|Description=Description of change
|Description=Allow force updating of a Load from the Job List screen
|Estimate=Cost
|Estimate=0
|Notes=Any notes, numerically listed
|Notes=
|Days=N
}}
{{REQ_SCR_Line
|SCR={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}
|System=EPOD
|Area=All
|Description=Resequence Jobs
|Estimate=0
|Notes=
|Days=N
}}
{{REQ_SCR_Line
|SCR={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}
|System=EPOD
|Area=Client
|Description=Force viewing of Special Instructions on Starting Job
|Estimate=0
|Notes=
|Days=N
}}
{{REQ_SCR_Line
|SCR={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}
|System=EPOD
|Area=Client
|Description=Allow force updating of a Job while in progress
|Estimate=0
|Notes=
|Days=N
}}
{{REQ_SCR_Line
|SCR={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}
|System=EPOD
|Area=Client
|Description=Remove facility to Cancel a Job
|Estimate=0
|Notes=
|Days=N
}}
{{REQ_SCR_Line
|SCR={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}
|System=EPOD
|Area=Client
|Description=Change label of Container CODE 1 field to "Spaces"
|Estimate=0
|Notes=
|Days=N
}}
{{REQ_SCR_Line
|SCR={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}
|System=EPOD
|Area=Client
|Description=Allow Postponement of a job after Arrival
|Estimate=0
|Notes=
|Days=N
}}
{{REQ_SCR_Line
|SCR={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}
|System=EPOD
|Area=All
|Description=Allow Customer to Clause delivery items
|Estimate=0
|Notes=
|Days=N
}}
{{REQ_SCR_Line
|SCR={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}
|System=EPOD
|Area=Admin
|Description=Create POD Formats (Generic and Palletforce)
|Estimate=0
|Notes=
|Days=N
}}
{{REQ_SCR_Line
|SCR={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}
|System=EPOD
|Area=Export
|Description=Export POD document as TIFF through the existing Partnerlink processes
|Estimate=0
|Notes=
|Days=N
}}
{{REQ_SCR_Line
|SCR={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}
|System=EPOD
|Area=Export
|Description=Export POD document as TIFF to Palletforce system
|Estimate=0
|Notes=
|Days=N
}}
{{REQ_SCR_Line
|SCR={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}
|System=EPOD/TTM
|Area=I/F
|Description=Changes to ePOD-TTM interface
|Estimate=0
|Notes=
|Days=N
}}
{{REQ_SCR_Line
|SCR={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}
|System=EPOD
|Area=Server
|Description=Automatically email on cancellation of a job only
|Estimate=0
|Notes=
|Days=N
}}
{{REQ_SCR_Line
|SCR={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}
|System=TTM
|Area=Server
|Description=Display and recalculate ETA
|Estimate=0
|Notes=
|Days=N
}}
{{REQ_SCR_Line
|SCR={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}
|System=TTM
|Area=All
|Description=Add Clause functionality to CALIDUS TTM
|Estimate=0
|Notes=
|Days=N
}}
{{REQ_SCR_Line
|SCR={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}
|System=TTM
|Area=Admin
|Description=Add additional search criteria to CALIDUS TTM
|Estimate=0
|Notes=
|Days=N
}}
{{REQ_SCR_Line
|SCR={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}
|System=EPOD/TTM
|Area=All
|Description=Trailer ID changes
|Estimate=0
|Notes=
|Days=N
}}
}}
{{REQ_SCR_Footer}}
{{REQ_SCR_Footer}}


Notes:
<!-- MEDIA LANDSCAPE NO -->
#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.
= Appendix B: Data Setup =
#<Further notes, referenced in the notes column of the grid above>
== 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


<!-- MEDIA LANDSCAPE NO -->  
<!-- NEW PAGE -->  
{{Doc_Appendix
{{Doc_Appendix
|Appendix=B
|Appendix=C
|Estimate=N
|Estimate=N
|Glossary=EPOD
|Glossary=EPOD
|Ref1=Reference1
|Ref1=&nbsp;
|RefV1=0.1
|RefV1=&nbsp;
|RefDate1=01/01/2011
|RefDate1=&nbsp;
|REQ=0
|REQ=0
|EST=0
|EST=0
Line 366: Line 823:
}}</div>  
}}</div>  
[[Category:{{#var:Client}} REQ]]
[[Category:{{#var:Client}} REQ]]
[[Category:{{#var:SystemCode}}]]

Latest revision as of 11:54, 29 November 2019





Aptean Logo.png







Partnerlink

Partnerlink ePOD Solution

CALIDUS ePOD

31st January 2013 - 0.2
Reference: REQ 305796











































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 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 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 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

NameDescriptionExternal FieldNotes
EPL_SITE_IDEPL_SITE_ID: Unique reference of the site that the Load belongs to.Partner CodePartner Code of the partner executing the load.
EPL_LOAD_IDEPL_LOAD_ID: Unique reference of the Load.Manifest_NoThe 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_IDTo be used if a user is predefined as assigned to complete this LOAD.Driver CodeUser to whom load assigned
EPL_VEHICLE_IDTo be used if a vehicle is predefined as assigned to complete this LOAD.Vehicle 
EPL_TRAILER_IDTo 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_JOBSEPOD_JOBS contains a series of EPOD_JOB objects.  

EPOD_JOB

NameDescriptionExternal FieldNotes
EPL_SITE_IDUnique Reference for the Site that the Job belongs topartner codeExpected at this time to be one of "L01" to "L04"
EPL_LOAD_IDUnique Reference for the Load that the Job belongs to. If not provided, defaulted from the enclosing EPOD_LOADManifest_NoFrom the load record.
EPL_JOB_IDUnique reference for the job. If not provided, this will be generated by EPOD Omitted - generated by EPOD
EPL_JOB_CODEExternal 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_TYPED=Delivery, C=Collection, S=Service"C" or "D" 
EPL_JOB_GROUP partner codeNote Note: Palletforce jobs must be allocated their own Job Group (e.g. "PF") in order to get their own POD format.
EPL_CUST_REFCustomer's Order ReferenceRef2 
EPL_JOB_INSTRUCTIONInstructions for the DriverNotes1+Notes2 
EPL_OFFICE_INSTRUCTIONInstructions for Admin staffNotes3+Notes4 
EPL_START_PLANNED_DATE Del_DateIf winroute in use, this can be provided.
EPL_START_PLANNED_TIME TimeMay 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_CUSTOMERThis 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_CODECustomer Code from external system. If not provided, one will be generated from EPL_CUSTOMER_NAMEaccount_code 
EPL_CUSTOMER_NAMEThe Name of the customerDel_NameFor collections, these values would be the Collection values, i.e. Col_Name, Col_post, etc.
EPL_ADDRESS_1 Del_addr1etc
EPL_ADDRESS_2 Del_addr2 
EPL_ADDRESS_3 Del_addr3 
EPL_ADDRESS_4 Del_addr4 
EPL_ADDRESS_5  N/A
EPL_POSTCODE Del_postCol_post
EPL_CONTACTContact 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_TELEPHONEThe Customer's Contact Telephone number  
EPL_EMAILContact Email address. Can be used to automatically send Job Completion documents to the customer.  
EPL_OWNER_NAMECan be used as a display field for documentation(owning) partner codeNeed 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_NUMBERSales Order Reference.Ref3 
EPL_ORDER_DATEDate Order created - defaulted to Now()  
EPL_SALES_CONTACTThe operative who took the order. Can be used as a display field for documentation N/A
EPL_SERVICE_LEVEL  N/A
EPL_SEQUENCEThe 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_IDTo 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_CONTAINERSContains a series of EPOD_CONTAINER objects  
EPOD_PRODUCTSContains a series of EPOD_PRODUCT objects N/A
EPOD_SERVICE  N/A

EPOD_CONTAINER

NameDescriptionExternal FieldNotes
EPL_SITE_ID Partner CodeDefaulted
EPL_JOB_ID  From Job record
EPL_CONTAINER_IDEPL_CONTAINER_ID: The unique identifier for a container.Label_IDActually from the tracking id (an id for each pallet to be delivered).
EPL_SEQUENCEThe sequence in which the containers should be unloaded.  
EPL_CONTAINER_PACKAGE_CODEContainer Type CodeEF/EH/EQ/SF/SH/SQNot required
EPL_CONTAINER_PACKAGE_DESCContainer Type DescriptionEURO FULL, etcNot required
EPL_GROSS_WEIGHTGross weight of the containerKilosNot required, but may be useful?
EPL_DESCRIPTION_LONGLong description of the container  
EPL_CODE_1Additional code field used for any purposeSpacesNumber of spaces taken on the vehicle. Required for documentation.
EPL_CODE_2Additional code field used for any purpose  
EPL_CODE_3Additional code field used for any purpose  
EPOD_PRODUCTSEPOD_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 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.

REQ-305796-1.PNG

Note 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.

REQ-305796-2.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.
SCR 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 SCR-305796-4: Allow force updating of a Load from the Job List screen

Note 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.

REQ-305796-3a.PNG File:REQ-305796-3b.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 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 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 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 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 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 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 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 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.

File:REQ-305796-4a.PNG

Note 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.

File:REQ-305796-4b.PNG

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 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 Note: For the Partnerlink-specific style, the label for the first Code field will be changed to 'Spaces'

SCR 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.

File:REQ-305796-4c.PNG

Once all containers have been delivered, the device will automatically take the driver to the Job Confirmation screen.

Note 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 Note: If resequencing is allowed, the driver will be allowed to select the next pending job for delivery, avoiding the Postponed job.

SCR 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.

REQ-305796-5.PNG

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 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 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 SCR-305796-12: Create POD Formats (Generic and Palletforce)

Note 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

NameDescriptionExternal FieldNotes
EPL_JOB_SIGNATUREThe signature taken from the customer when the job was completed. This is in the form of a Base64-encrypted Jpeg file  
EPL_REASON_CODEIf a job has been cancelled, the reason code entered by the user is held here.  
EPL_LINKED_REASONIf 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_STATUSC- complete, X cancelled  
EPL_PHOTO_IDIf cancelled, a photo may have been taken by the user. If so, this field is populated with a unique ID.  
EPL_PHOTOThe photo taken for the exception. This is in the form of a Base64-encrypted Jpeg file  
EPL_ENG_SIGNATUREThe 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_SEQUENCEThe 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_DATEThe date the user actually chose to start the job. Format: YYYYMMDD  
EPL_START_ACTUAL_TIMEThe time the user actually chose to start the job. Format HHMMSSNN  
EPL_ARRIVED_DATE_TIMEThe date the user indicated they arrived at the destination. Format: YYYYMMDD  
EPL_ARRIVED_DATE_TIMEThe time the user indicated they arrived at the destination. Format HHMMSSNN  
EPL_END_ACTUAL_DATEThe date the user completed or cancelled the job. Format: YYYYMMDD  
EPL_END_ACTUAL_TIMEThe time the user completed or cancelled the job. Format HHMMSSNN  
EPL_JOB_ADDRESSA 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_SIGNATORYThe name of the customer signatory on the job.  
EPL_SIGNED_UNCHECKEDAn 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_TNCSAn 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_NOTESOptional Notes entered by the driver while completing the job.  
EPL_TRAILER_IDTo 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

NameDescriptionExternal FieldNotes
EPL_REASON_CODEIf a job has been cancelled, the reason code entered by the user is held here.  
EPL_LINKED_REASONIf 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_STATUSEPL_STATUS: Status of the current Container. C-Completed, X-Cancelled.  
EPL_PHOTO_IDIf 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_PHOTOThe photo taken for the exception. This is in the form of a Base64-encrypted Jpeg file  
EPL_CUST_COMMENTSOptional 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 SCR-305796-13: Export POD document as TIFF through the existing Partnerlink processes.
SCR 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 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 SCR-305796-16: Automatically email on cancellation of a job only

Note 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 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 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 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 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#SystemAreaDescriptionEstimate (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 NoDocument Title & IDVersionDate
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		_____________________________
Retrieved from ‘https://calidusassist.adcservices.apteancloud.com/calidus-assist/OBS/index.php?title=REQ_305796_Partnerlink_EPOD_Solution&oldid=8168’