Greene King

- WEBFLEET-ePOD Job Update Interface

CALIDUS EPOD

23rd August 2016 - 1.0
Reference: FS 336015 - SCR-332569-6, SCR-332569-7, SCR332569-8

Functional Overview

Client Requirement

As each job is actioned by the drivers, information on those actions is stored within TomTom WEBFLEET. This information will be pulled back into CALIDUS EPOD and will update the jobs. A new process will be required to complete this. This will be a timed process, running at regular intervals.

Solution Overview

SCR-332569-6:

WEBFLEET-ePOD Job Update Interface.

The process will create a queue to poll for:

Order Completion messages
Order Cancellation messages
Order Started messages
Order Arrived messages

All these messages should include Odometer and Lat/Long co-ordinates.

Each message will be processed and then acknowledged from the queue. The success or failure of processing of the message files received from TomTom will be audited.

It is intended that processing these messages will provide the following information:

Job Status (Completed/Cancelled)
Reason for cancellation if required
Start/Arrival/End Times
Start/Arrival/End Odometer readings

This information will then be used to update the jobs on CALIDUS EPOD.

Note: Jobs that are cancelled on TomTom WEBFLEET devices provide a different interface back into CALIDUS EPOD - this requires prototyping at functional specification stage and may result in increased cost. Reasons entered against a cancelled job are also required. It is expected, however, that the costs in this document will be sufficient to achieve the full interface.

TomTom WEBFLEET non-working time (unplanned breaks) is required to be supported by this project and therefore this interface - if the driver logs non-working time as part of the execution of an order, this will generate a break job in the database, with no planned times or distances. Additionally, this time will be taken away from any travel or working time on any jobs that have actual start, arrival or end times around that unplanned break.

SCR-332569-7:

Update non-working time as a new break

When all jobs on a load are updated to cancelled or completed through this interface, the load will be marked as complete.

An optional change has also been requested to indicate the position at which the driver clicks the Arrive button, so that Greene King can check the location.

SCR-332569-8:

Display location of TomTom Order Arrival.

In order to achieve this, this process will write User Audit records for each message processed from the TomTom files received, for the following information:

Order Started
Order Arrived
Order Completed

This information would then be accessible through the existing CALIDUS EPOD User Audit Admin screen.

Admin User Tracking Screen, showing prototyped TomTom messages

Scope

This document covers 3 changes from the solution design:

336015 SCR-332569-6 WEBFLEET-ePOD Job Update Interface
336016 SCR-332569-8 Display location of TomTom Order Arrival
336017 SCR-332569-7 Update non-working time as a new break

The estimates in Appendix B are the combined values from these 3 changes.

Note: This interface will be written to capture the events related to Orders and start/stop working time only - Geofence breaks will not be captured or created as part of this interface and will NOT debrief the loads and jobs in CALIDUS EPOD.

Note: This interface identifies the Site for WEBFLEET updates by extracting it from the Order Number sent to WEBFLEET. This requires a fixed Job ID length of 10 characters, which is the default when sending orders to WEBFLEET. If the interface is used as described in the solution design, this interface will function automatically with no issues and no manual intervention. If any other mechanism is used to generate the orders in WEBFLEET, or the Job IDs are created at a different length, this update process will not work as described.

Note: This interface identifies driver-generated Breaks through the external (WEBFLEET) vehicle ID in order to find the load that is in progress. Where the same vehicle is in use on multiple sites, this can compromise the interface for generation of breaks.

Note: This document assumes that that the process will be used under conditions where only WEBFLEET is in use, not the full CALIDUS EPOD solution. Under the full CALIDUS EPOD solution, driver-generated breaks on the device will not be processed through this TomTom WEBFLEET interface. The system will then restrict the messages read from WEBFLEET to Order-only messages, rather than all messages. Care must be taken if implementing the full CALIDUS EPOD solution, that the old message queue is deleted after all messages are processed, and that the new message queue for orders is implemented before work starts under the new system.

Note: Drivers Pausing and Starting work will generate new breaks and update in progress jobs. Breaks will not be generated if the driver is already in-progress on a pre-existing break job. Pre-existing break jobs (for example, generated by DiPS) will not be updated or confirmed when the driver pauses or starts work on the WEBFLEET device.

Note: When jobs are consolidated and will be actioned together on the device ((i.e. the linked ID is set to be the same value on multiple jobs), the actual values for work, travel and distance will still be updated on the job. This must be taken into account when producing the Planned Vs Actuals report, so that the values are reported on only one of the consolidated jobs on the load.

Set-up

Pre-requisites

The Sites must be pre-configured by the OBSL implementation team to point to the correct WEBFLEET fleet. This is a requirement of the Breaks solution. This is not configurable by the users. If this is not configured, driver-generated breaks from WEBFLEET will not be processed and added.

Menu Structure

N/A.

Data

For full functionality to be enabled, the CALIDUS EPOD system must be configured for PvA only, through the Site maintenance screen (on the Administration menu), Details tab, System Type setting.

Admin Site Screen, showing prototyped System Type

TomTom WEBFLEET-specific reason codes should be created for the Sites in advance:

"TWCD" - description "TomTom WEBFLEET - Cancelled by Driver".
"TWRD" - description "TomTom WEBFLEET - Rejected by Driver".

These reason codes should be created at Job and Detail level.

Codes Maintenance Screen

Set up the sites for WEBFLEET inbound interface.

New EPOD_XF_CONFIG configurations will be required:

EPL_XF_CONFIG_ID - A new configuration name to be applied to sites that do not have an Export Configuration yet, or the Export Configuration ID of the existing configuration.
EPL_XF_ID - "TO" - TomTom Update
EPL_SOAP_ACTION - ""
EPL_SOAP_NS - "ser"
EPL_SOAP_NS_PREFIX - "http://connect.webfleet.tomtomwork.com/services"
EPL_WEB_USER - "admin"
EPL_WEB_PASSWORD - "Matt3221"
EPL_XF_RECIPIENT - Account - "logistics-obs"
EPL_XF_DESTINATION - "https://soap.business.tomtom.com/v1.28/messagesService"
EPL_XF_MSG_TYPE - API Key - "000fcb2a-6631-477a-b00e-de0505e7c7e3"
EPL_XF_DIRECTION - "I"
EPL_XF_TYPE - "SOAP"

Import/Export Config Screen

This configuration must be added to all of the sites that requires TomTom interfaces for that WEBFLEET fleet. If a site already has a configuration attached to it, a configuration should be added to the same configuration name. Note: This configuration of the interface will bring back all updates from the fleet, regardless of site. However, the interface configuration is required against all sites, so that the parameters may be used to identify to which site the vehicle belongs.

Vehicles must be set up for WEBFLEET, with an external reference matching the object ID in WEBFLEET:

Vehicles Maintenance Screen

WEBFLEET Vehicles Screen

Functional Description

Database/DAL

New fields will be added to the EPOD_JOB table:

EPL_WORK_ACTUAL - number - to hold the value of the Actual Work Time from WEBFLEET in whole numbers of minutes.
EPL_ODO_START - float - to hold the Start Odometer reading from WEBFLEET.
EPL_ODO_END - float - to hold the End Odometer reading from WEBFLEET.

All database packages and the DAL object will be changed to update and retrieve these new fields. Note: It is not necessary to add these fields as search-able items.

Note: The following existing fields will be used to store Actual times and distances in addition to the new field above:

EPL_DISTANCE_ACTUAL - Actual distance travelled. Note: This must be changed to a float type (i.e. capable of storing decimal values).
EPL_DRIVING_TIME - Actual driving time in whole numbers of minutes.

The existing EPOD_LOAD fields EPL_LOAD_DISTANCE_PLANNED and EPL_LOAD_DISTANCE_ACTUAL should be changed to be a float type (i.e. capable of storing decimal values).

Note: As standard, these fields will be added to the standard XML Webservice Import and Export flows. These changes (and all others for the project) have been documented and referenced in Appendix B. The standard XSD files describing the XML in detail will also be updated as part of this project. Note specifically that all fields changed to float type will need to have the type changed to "xsd:float".

A new field will be added to the EPOD_SITE table:

EPL_EXT_FLEET - nvarchar(40) - to hold the value of the WEBFLEET fleet ID.

All database packages and the DAL object will be changed to update and retrieve this new field. Note: It is not necessary to add this field as search-able items.

Note: Indexes are required for the following tables, to improve efficiency of finding applicable vehicles to create breaks:

EPOD_VEHICLE - Index EPV_EXT_IDX as EPL_EXT_REF, EPL_SITE_ID, EPL_VEHICLE_ID.
EPOD_SITE - Index EPS_EXT_IDX as EPL_EXT_FLEET, EPL_SITE_ID.
EPOD_LOAD - Index EPL_VEHICLE_STATUS_IDX as EPL_SITE_ID, EPL_VEHICLE_ID, EPL_STATUS, EPL_LOAD_ID

Auto Import Process

Retrieving messages from WEBFLEET is through the use of message queues, created and accessed through the TomTom WEBFLEET API, referenced in Appendix B.

A request to the created message queue will be made through the webservice method popQueueMessagesExtern.

Before using popQueueMessagesExtern to retrieve outstanding messages, a queue must be created using the createQueueExtern method, using the same message class parameter that is being provided with calls to popQueueMessagesExtern. In this case, the message class is 2 (all messages except tracking messages).

Note: The resulting data set is delivered in the language chosen in the WEBFLEET account and not on the language indicated in the lang parameter.

The structure of the popQueueMessagesExtern method is as follows:

     <ser:popQueueMessagesExtern>
        <aParm>
           <accountName>EPL_XF_RECIPIENT</accountName>
           <userName>EPL_WEB_USER</userName>
           <password>EPL_WEB_PASSWORD</password>
           <apiKey>EPL_XF_MSG_TYPE</apiKey>
        </aParm>
        <gParm>
           <locale>UK</locale>
           <timeZone>Europe_London</timeZone>
        </gParm>
        <msgClass filter="ALL_EXCEPT_POSITION_MESSAGES" />
     </ser:popQueueMessagesExtern>

Note: This document assumes that that the process will be used under conditions where only WEBFLEET is in use, not the full CALIDUS EPOD solution. In this case, the message queue created and used for WEBFLEET messages will require to be filtered for all messages except tracking messages (filter attribute "ALL_EXCEPT_POSITION_MESSAGES"). This attribute is used on all WEBFLEET webservice calls to create, pop and acknowledge messages from that queue. This is only the case when the Site's System Type (EPL_SYSTEM_TYPE) is "PvA". This is only required when creating breaks through WEBFLEET. When the full CALIDUS EPOD system is in use, this will not be the case, and therefore the WEBFLEET messages can be more strictly filtered to only Order-based messages (filter attribute "ORDER_RELATED"). The mcgClass filter attribute on all WEBFLEET message queue methods in this document should be set to "ORDER_RELATED" if the Site's System Type (EPL_SYSTEM_TYPE) is anything except "PvA".

Care must be taken if implementing the full CALIDUS EPOD solution, that the old message queue is deleted after all messages are processed, and that the new message queue for orders is implemented before work starts under the new system.

The response to a popQueueMessagesExtern message is as follows:

     <ns3:popQueueMessagesExternResponse 
           xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
           xmlns:ns3="http://connect.webfleet.tomtomwork.com/services">
        <return>
           <statusCode>9195</statusCode>
           <statusMessage>...Details of the status...</statusMessage>
           <errors>
              <errorInfo objectName="QueueServiceParameter" fieldName="filter">
                 <msg>A value is required</msg>
              </errorInfo>
           </errors>
           <resultSize>0</resultSize>
           <results xsi:nil="true"/>
        </return>
     </ns3:popQueueMessagesExternResponse>

The above response object also shows the result should an error occur. TomTom Responses have been handled before when processing sending orders to WEBFLEET in the Auto Export process (in method EPOD_SYS_EXPORT.TomTomOrdersProcessData). A similar process should be implemented here:

If the status code returned is 0, the message was successful.
If the status code returned is 8011, request limits were reached - in this case treat this as a failure.
If the status code returned is 9303, the message queue request failed - see the following section.
Any other status code returned should be treated as a failure.

If the message queue request failed, it may not be set up yet. This is indicated by the errorInfo/msg tag starting with "WFCQ_E0022". If any other error message is received, write an XF Audit record, indicating "Unable to read from queue" plus the description from the msg tag.

If the queue has not been set up yet, the process should create it at this time. This is through a call to the createQueueExtern webservice method, populated as follows:

     <ser:createQueueExtern>
        <aParm>
           <accountName>EPL_XF_RECIPIENT</accountName>
           <userName>EPL_WEB_USER</userName>
           <password>EPL_WEB_PASSWORD</password>
           <apiKey>EPL_XF_MSG_TYPE</apiKey>
        </aParm>
        <gParm>
           <locale>UK</locale>
           <timeZone>Europe_London</timeZone>
        </gParm>
        <msgClass filter="ALL_EXCEPT_POSITION_MESSAGES" />
     </ser:createQueueExtern>

To call this, simply replace the outer tags of the previous request and resend the SOAP request.

The response object for this call is identical to the response to all other calls, except that the outer tag is createQueueExternResponse. Anything other than "0" (Success) in the status code means a failure to create the queue. In the case of failure, write an XF Audit record, indicating "Creation of queue failed" plus the description from the msg tag.

Note: If the queue is created here, there is no need to continue with the process, as there will be no messages in the queue yet - the process can finish here.

The results tag will contain the results in sub-tags called resultItem. Example files exist for this data returned. The following are example result items for each item that the process will be dealing with:

Starting an Order:

              <resultItem xsi:type="ns4:QueueServiceData" 
                   xmlns:ns4="http://connect.webfleet.tomtomwork.com/transfer/messages">
                 <msgid messageId="54949248423"/>
                 <msgTime>2016-06-20T15:05:06.008Z</msgTime>
                 <msgClass>ORDER</msgClass>
                 <msgType>110000760</msgType>
                 <msgText>Order TW0000000001: started</msgText>
                 <objectNo objectNo="#T009" objectUid="1-44036-9593E0A06"/>
                 <odometer>874543</odometer>
                 <pos>
                    <latitude>53349133</latitude>
                    <longitude>-2852108</longitude>
                    <mapcode xsi:nil="true"/>
                 </pos>
                 <posText>Liverpool</posText>
                 <posParams>town1_name=Liverpool;location_type=67;</posParams>
                 <posTime>2016-06-20T15:05:04Z</posTime>
                 <speed>0</speed>
                 <course>0</course>
                 <direction>1</direction>
                 <status>A</status>
                 <orderNo orderNo="TW0000000001"/>
                 <orderState>241</orderState>
                 <orderType>3</orderType>
                 <orderAddrNo>10151</orderAddrNo>
                 <dtMessageData xsi:nil="true"/>
                 <rllMessageData xsi:nil="true"/>
                 <driverKeyDeviceMessageData xsi:nil="true"/>
              </resultItem>

In progress to an Order:

              <resultItem xsi:type="ns4:QueueServiceData" 
                   xmlns:ns4="http://connect.webfleet.tomtomwork.com/transfer/messages">
                 <msgid messageId="54949319260"/>
                 <msgTime>2016-06-20T15:06:19.388Z</msgTime>
                 <msgClass>ORDER</msgClass>
                 <msgType>110000761</msgType>
                 <msgText>Order TW0000000001: est. arrival 16:24, 11 mi to destination</msgText>
                 <objectNo objectNo="#T009" objectUid="1-44036-9593E0A06"/>
                 <odometer>874543</odometer>
                 <pos>
                    <latitude>53349131</latitude>
                    <longitude>-2852109</longitude>
                    <mapcode xsi:nil="true"/>
                 </pos>
                 <posText>Liverpool</posText>
                 <posParams>town1_name=Liverpool;location_type=67;</posParams>
                 <posTime>2016-06-20T15:06:16Z</posTime>
                 <speed>0</speed>
                 <course>0</course>
                 <direction>1</direction>
                 <status>A</status>
                 <orderNo orderNo="TW0000000001"/>
                 <orderState>241</orderState>
                 <orderType>3</orderType>
                 <eta>2016-06-20T15:24:56Z</eta>
                 <distance>17249</distance>
                 <dtMessageData xsi:nil="true"/>
                 <rllMessageData xsi:nil="true"/>
                 <driverKeyDeviceMessageData xsi:nil="true"/>
              </resultItem>

On and Off a Break:

              <resultItem xsi:type="ns4:QueueServiceData" 
                   xmlns:ns4="http://connect.webfleet.tomtomwork.com/transfer/messages">
                 <msgid messageId="54949851082"/>
                 <msgTime>2016-06-20T15:15:48.686Z</msgTime>
                 <msgClass>DATA</msgClass>
                 <msgType>80000719</msgType>
                 <msgText>John Doe: Pause started</msgText>
                 <objectNo objectNo="#T009" objectUid="1-44036-9593E0A06"/>
                 <driverNo driverNo="44" driverUid="1-44036-4637202118"/>
                 <odometer>874543</odometer>
                 <pndconn>0</pndconn>
                 <tripMode>1</tripMode>
                 <pos>
                    <latitude>53349131</latitude>
                    <longitude>-2852114</longitude>
                    <mapcode xsi:nil="true"/>
                 </pos>
                 <posText>Liverpool</posText>
                 <posParams>town1_name=Liverpool;location_type=67;</posParams>
                 <posTime>2016-06-20T15:14:05Z</posTime>
                 <speed>0</speed>
                 <course>0</course>
                 <direction>1</direction>
                 <status>A</status>
                 <dtMessageData xsi:nil="true"/>
                 <rllMessageData xsi:nil="true"/>
                 <pndWorkingStateMessageData>
                    <workstate>PAUSE</workstate>
                    <sourceDevice>PND</sourceDevice>
                    <eventTime>2016-06-20T15:14:05Z</eventTime>
                 </pndWorkingStateMessageData>
                 <driverKeyDeviceMessageData xsi:nil="true"/>
              </resultItem>
              <resultItem xsi:type="ns4:QueueServiceData" 
                   xmlns:ns4="http://connect.webfleet.tomtomwork.com/transfer/messages">
                 <msgid messageId="54949851641"/>
                 <msgTime>2016-06-20T15:15:49.258Z</msgTime>
                 <msgClass>DATA</msgClass>
                 <msgType>80000719</msgType>
                 <msgText>John Doe: Work started</msgText>
                 <objectNo objectNo="#T009" objectUid="1-44036-9593E0A06"/>
                 <driverNo driverNo="44" driverUid="1-44036-4637202118"/>
                 <odometer>874543</odometer>
                 <tripMode>2</tripMode>
                 <pos>
                    <latitude>53349131</latitude>
                    <longitude>-2852114</longitude>
                    <mapcode xsi:nil="true"/>
                 </pos>
                 <posText>Liverpool</posText>
                 <posParams>town1_name=Liverpool;location_type=67;</posParams>
                 <posTime>2016-06-20T15:14:25Z</posTime>
                 <speed>0</speed>
                 <course>0</course>
                 <direction>1</direction>
                 <status>A</status>
                 <dtMessageData xsi:nil="true"/>
                 <rllMessageData xsi:nil="true"/>
                 <pndWorkingStateMessageData>
                    <workstate>WORKING</workstate>
                    <sourceDevice>PND</sourceDevice>
                    <eventTime>2016-06-20T15:14:25Z</eventTime>
                 </pndWorkingStateMessageData>
                 <driverKeyDeviceMessageData xsi:nil="true"/>
              </resultItem>

Cancellation:

              <resultItem xsi:type="ns4:QueueServiceData" 
                   xmlns:ns4="http://connect.webfleet.tomtomwork.com/transfer/messages">
                 <msgid messageId="54950259474"/>
                 <msgTime>2016-06-20T15:23:18.805Z</msgTime>
                 <msgClass>ORDER</msgClass>
                 <msgType>111100734</msgType>
                 <msgText>Order TW0000000001: cancelled "unexpected cow"</msgText>
                 <objectNo objectNo="#T009" objectUid="1-44036-9593E0A06"/>
                 <odometer>874543</odometer>
                 <pos>
                    <latitude>53349131</latitude>
                    <longitude>-2852117</longitude>
                    <mapcode xsi:nil="true"/>
                 </pos>
                 <posText>Liverpool</posText>
                 <posParams>town1_name=Liverpool;location_type=67;</posParams>
                 <posTime>2016-06-20T15:23:16Z</posTime>
                 <speed>0</speed>
                 <course>0</course>
                 <direction>1</direction>
                 <status>A</status>
                 <orderNo orderNo="TW0000000001"/>
                 <orderState>301</orderState>
                 <orderType>3</orderType>
                 <orderAddrNo>10151</orderAddrNo>
                 <userText>unexpected cow</userText>
                 <dtMessageData xsi:nil="true"/>
                 <rllMessageData xsi:nil="true"/>
                 <driverKeyDeviceMessageData xsi:nil="true"/>
              </resultItem>

Rejection:

              <resultItem xsi:type="ns4:QueueServiceData" 
                   xmlns:ns4="http://connect.webfleet.tomtomwork.com/transfer/messages">
                 <msgid messageId="54950499987"/>
                 <msgTime>2016-06-20T15:27:50.947Z</msgTime>
                 <msgClass>ORDER</msgClass>
                 <msgType>111100731</msgType>
                 <msgText>Order TW0000000002: rejected "rejected by duck"</msgText>
                 <objectNo objectNo="#T009" objectUid="1-44036-9593E0A06"/>
                 <odometer>874543</odometer>
                 <pos>
                    <latitude>53349067</latitude>
                    <longitude>-2852166</longitude>
                    <mapcode xsi:nil="true"/>
                 </pos>
                 <posText>Liverpool</posText>
                 <posParams>town1_name=Liverpool;location_type=67;</posParams>
                 <posTime>2016-06-20T15:27:48Z</posTime>
                 <speed>0</speed>
                 <course>282</course>
                 <direction>7</direction>
                 <status>A</status>
                 <orderNo orderNo="TW0000000002"/>
                 <orderState>302</orderState>
                 <orderType>3</orderType>
                 <orderAddrNo>10151</orderAddrNo>
                 <userText>rejected by duck</userText>
                 <dtMessageData xsi:nil="true"/>
                 <rllMessageData xsi:nil="true"/>
                 <driverKeyDeviceMessageData xsi:nil="true"/>
              </resultItem>

Arrived at Delivery Location:

              <resultItem xsi:type="ns4:QueueServiceData" 
                   xmlns:ns4="http://connect.webfleet.tomtomwork.com/transfer/messages">
                 <msgid messageId="54856914199"/>
                 <msgTime>2016-06-17T14:06:20.409Z</msgTime>
                 <msgClass>ORDER</msgClass>
                 <msgType>110000760</msgType>
                 <msgText>Order 405511: arrived at delivery location</msgText>
                 <objectNo objectNo="#T009" objectUid="1-44036-9593E0A06"/>
                 <odometer>874543</odometer>
                 <pos>
                    <latitude>53349010</latitude>
                    <longitude>-2851930</longitude>
                    <mapcode xsi:nil="true"/>
                 </pos>
                 <posText>Liverpool</posText>
                 <posParams>town1_name=Liverpool;location_type=67;</posParams>
                 <posTime>2016-06-17T14:06:19Z</posTime>
                 <speed>2</speed>
                 <course>0</course>
                 <direction>1</direction>
                 <status>A</status>
                 <orderNo orderNo="405511"/>
                 <orderState>242</orderState>
                 <orderType>3</orderType>
                 <dtMessageData xsi:nil="true"/>
                 <rllMessageData xsi:nil="true"/>
                 <driverKeyDeviceMessageData xsi:nil="true"/>
              </resultItem>

Order Finished:

              <resultItem xsi:type="ns4:QueueServiceData" 
                   xmlns:ns4="http://connect.webfleet.tomtomwork.com/transfer/messages">
                 <msgid messageId="54856918353"/>
                 <msgTime>2016-06-17T14:06:24.714Z</msgTime>
                 <msgClass>ORDER</msgClass>
                 <msgType>110000760</msgType>
                 <msgText>Order 405511: finished</msgText>
                 <objectNo objectNo="#T009" objectUid="1-44036-9593E0A06"/>
                 <odometer>874543</odometer>
                 <pos>
                    <latitude>53349020</latitude>
                    <longitude>-2851940</longitude>
                    <mapcode xsi:nil="true"/>
                 </pos>
                 <posText>Liverpool</posText>
                 <posParams>town1_name=Liverpool;location_type=67;</posParams>
                 <posTime>2016-06-17T14:06:23Z</posTime>
                 <speed>0</speed>
                 <course>0</course>
                 <direction>1</direction>
                 <status>A</status>
                 <orderNo orderNo="405511"/>
                 <orderState>401</orderState>
                 <orderType>3</orderType>
                 <dtMessageData xsi:nil="true"/>
                 <rllMessageData xsi:nil="true"/>
                 <driverKeyDeviceMessageData xsi:nil="true"/>
              </resultItem>

All result items should be processed in sequence, by looping through them.

The tags in this resultItem that are required are as follows:

msgClass - for filtering messages.
msgType - for filtering messages.
objectNo - the vehicle's external (TomTom WEBFLEET) reference.
odometer - the Odometer reading in KM. This may not be present, depending on hardware and configuration.
pos/latitude - the latitude taken at the point of the message being generated, in micro degrees. This may not be present if there is not an adequate GPS signal at the time the message was created.
pos/longitude - the longitude taken at the point of the message being generated, in micro degrees. This may not be present if there is not an adequate GPS signal at the time the message was created.
posTime - the date and time the message was created. ISO 8601-formatted date and time in the UTC timezone, combined representation in the extended format. Example: 2007-12-24T16:00:00Z.
orderNo@orderNo - the unique order number passed to WEBFLEET when the order was created. For CALIDUS EPOD this will the value from External System ID, usually the Site ID and Job ID combined. This differs for consolidated jobs and should be confirmed as to the actual value.
orderState - for filtering messages.
eta - the estimated time of arrival at the location for the order. ISO 8601-formatted date and time in the UTC timezone, combined representation in the extended format. Example: 2007-12-24T16:00:00Z.
pndWorkingStateMessageData/workstate - determines break status.
userText - the text entered when cancelling or rejecting an order on the device.

Note:

A slash (/) in the tag name (e.g. pndWorkingStateMessageData/workstate) indicates that this is a sub-tag of another tag.
An At symbol (@) in the tag name (orderNo@orderNo) indicates that this is an attribute of the named tag.
Tags (and sub-tags) may not exist for each message, so each tag must be extracted and checked individually, or the errors handled when extracting values from tags.
Longitudes and Latitudes are stored in micro-degrees and must be divided by 1,000,000 for storing in CALIDUS EPOD.
Times are in xsd:dateTime format and must be converted. Furthermore, they are in UTC, and must be converted to the local server timezone when storing.

General Processing

Filter (ignore) any messages that are not being processed by this interface. Initially, the list should be filtered for the result msgClass tag values "DATA" and "ORDER" only.
Convert the date/time from the posTime tag in the result.
Convert the ETA date/time from the eta tag in the result, if present.
Convert and validate the ODO reading from the odometer tag in the result, if present.
Convert and validate the GPS location from the pos tag, sub-tags latitude and longitude in the result.

Processing of result records with an order state value:

Filter (ignore) any messages that are not being processed by this interface. Initially, the list should be filtered for the result msgClass tag value "ORDER" and for the following orderState tag values:
- 221 - Pickup order started
- 222 - Arrived at Pickup location
- 241 - Delivery order started
- 242 - Arrived at Delivery location
- 301 - Cancelled
- 302 - Rejected
- 401 - Finished
Get the Job or Jobs (EPOD_JOB) using the extracted Site (EPL_SITE_ID) and External System Reference (EPL_EXTERNAL_SYSTEM_ID) from the orderNo tag attribute value. Note: There can be multiple jobs for the External System Reference.
Stop processing this result record if this job is completed or cancelled (EPL_STATUS = "C" or "X"). Write an Audit record for the job, status "F" - see later for details.
Get the Load (EPOD_LOAD) from the Job's Load ID (EPL_LOAD_ID). Store the Load ID in a list of loads processed from this response.
Stop processing this result record if this load is completed or cancelled (EPL_STATUS = "C" or "X"). Write an Audit record for the job, status "F" - see later for details.
Get the Vehicle (EPOD_VEHICLE) from the Load's Vehicle ID (EPL_VEHICLE_ID).
Set the Vehicle's last position, date and time as follows:
- Set the Last Position (EPL_LAST_POSITION) from the converted values of the result tags latitude and longitude values, concatenated with a comma.
- Set the Last Position Date and time (EPL_LAST_POSITION_DATE and EPL_LAST_POSITION_TIME) from the extracted date and time from the tag posTime value, translated into OBS format.

For order states 221 and 241 (order started):
- Set the Actual Start date and time if not already populated (EPL_START_ACTUAL_DATE and EPL_START_ACTUAL_TIME) from the tag posTime value, translated into OBS format.
- If the System Type (EPL_SYSTEM_TYPE) is "PvA", set the Job or Jobs status (EPL_STATUS) to "I" - In Progress if not already in progress.
- If the job was not already in progress, find any other in-progress jobs against the load and set to status pending (EPL_STATUS set to "P"). If they already have a value in start odometer (EPL_ODO_START), set the distance travelled (EPL_DISTANCE_ACTUAL) to tag odometer value minus the value in the jobs' start odometer and zero the jobs' start odometer value.
- Set the ETA date and time against the Job or Jobs (EPL_ETA_DATE and EPL_ETA_TIME) from the tag eta value, if present, translated into OBS format.
- If present in the incoming result, set the Odometer reading on the Vehicle (EPL_VEHICLE_MILEAGE) to the tag odometer value.
- If present in the incoming result, set the Start Odometer reading on the Job or Jobs (EPL_ODO_START) to the tag odometer value, if not already populated.
- If present in the incoming result, set the ODO start against the Load (EPL_MILEAGE_START) from the tag odometer value, if not already populated.
- Write a User Tracking record for each of the jobs - see below for details.

For order states 222 and 242 (arrived at location):
- Update Arrival date and time against the job or jobs if not already populated (EPL_ARRIVAL_DATE and EPL_ARRIVAL_TIME) from the tag posTime value, translated into OBS format.
- Remove the ETA date and time if present against the Job or Jobs (EPL_ETA_DATE and EPL_ETA_TIME).
- If present in the incoming result, set the distance travelled (EPL_DISTANCE_ACTUAL) to the tag odometer value minus the start odometer value (EPL_ODO_START), plus any value already in the distance travelled.
- If present in the incoming result, set the Odometer reading on the Vehicle (EPL_VEHICLE_MILEAGE) to the tag odometer value.
- Set the driving time (EPL_DRIVING_TIME) from the Arrival time on the job (EPL_ARRIVAL_TIME) minus the Actual Start time on the job (EPL_START_ACTUAL_DATE), plus any value already in this Driving Time field.
- Write a User Tracking record for each of the jobs - see below for details.

For order state 401 (Finished):
- Set the Actual End date and time if not already populated (EPL_END_ACTUAL_DATE and EPL_END_ACTUAL_TIME) from the tag posTime value, translated into OBS format.
- If the System Type (EPL_SYSTEM_TYPE) is "PvA", set the Job or Jobs status (EPL_STATUS) to "C" - Complete if not already complete.
- Remove the ETA date and time if present against the Job or Jobs (EPL_ETA_DATE and EPL_ETA_TIME).
- If present in the incoming result, set the Odometer reading on the Vehicle (EPL_VEHICLE_MILEAGE) to the tag odometer value.
- If present in the incoming result, set the End Odometer reading on the Job to the tag odometer value.
- If not yet populated, set the distance travelled (EPL_DISTANCE_ACTUAL) to the tag odometer value minus the start odometer value (EPL_ODO_START), plus any value already in the distance travelled.
- If the status of the job (EPL_STATUS) is not "I" (In Progress), set the driving time (EPL_DRIVING_TIME) from the Arrival time on the job (EPL_ARRIVAL_TIME) minus the Actual Start time on the job (EPL_START_ACTUAL_DATE), plus any value already in this Driving Time field.
- Set the actual work time (EPL_WORK_ACTUAL) from the Actual End time on the job (EPL_END_ACTUAL_TIME) minus the Arrival time on the job (EPL_ARRIVAL_TIME), plus any value already in this actual work time field.
- If the System Type (EPL_SYSTEM_TYPE) is "PvA", complete all child records for the job or jobs (i.e. Containers, Products, Service Items), by setting the status (EPL_STATUS) to "C" - Complete.
- Write a User Tracking record for each of the jobs - see below for details.

For order status 301 (Cancelled) or order status 302 (Rejected):
- Set the Actual End date and time if not already populated (EPL_END_ACTUAL_DATE and EPL_END_ACTUAL_TIME) from the tag posTime value, translated into OBS format.
- If the System Type (EPL_SYSTEM_TYPE) is "PvA", Set Job or Jobs status (EPL_STATUS) to "X" - Cancelled.
- If the System Type (EPL_SYSTEM_TYPE) is "PvA", Set the Reason Code against the Job or Jobs (EPL_REASON_CODE) to "TWCD" (for order status 301) or "TWRD" (for order status 302).
- Set the User Notes (EPL_USER_NOTES) against the Job or Jobs to be the tag userText value.
- Remove the ETA date and time if present against the Job or Jobs (EPL_ETA_DATE and EPL_ETA_TIME).
- If present in the incoming result, set the Odometer reading on the Vehicle (EPL_VEHICLE_MILEAGE) to the incoming odometer value.
- If not yet populated, set the distance travelled (EPL_DISTANCE_ACTUAL) to the tag odometer value minus the start odometer value (EPL_ODO_START), plus any value already in the distance travelled.
- Set the driving time (EPL_DRIVING_TIME) from the Arrival time on the job (EPL_ARRIVAL_TIME) minus the Actual Start time on the job (EPL_START_ACTUAL_DATE), plus any value already in this Driving Time field.
- Set the actual work time (EPL_WORK_ACTUAL) from the Actual End time on the job (EPL_END_ACTUAL_TIME) minus the Arrival time on the job (EPL_ARRIVAL_TIME), plus any value already in this actual work time field.
- If the System Type (EPL_SYSTEM_TYPE) is "PvA", cancel all child records for the job or jobs (i.e. Containers, Products, Service Items), by setting the status (EPL_STATUS) to "X" - Cancelled.
- Write a User Tracking record for each of the jobs - see below for details.

For order status 301 (Cancelled), 302 (Rejected) and 401 (Complete):
- Check all the jobs on the Load.
  - If the System Type (EPL_SYSTEM_TYPE) is "PvA", if all have been completed or cancelled, set the Load status (EPL_STATUS) to "C" - Complete.
  - If all have been completed or cancelled and if the tag odometer value is present, set the ODO end against the load if not set (EPL_MILEAGE_END) from this incoming value. Set the Actual Distance travelled against the load (EPL_LOAD_DISTANCE_ACTUAL) to be the ODO end (EPL_MILEAGE_END)) minus the ODO start (EPL_MILEAGE_START), if both values are non-zero.

Ignore any other messages than the ones above, if the System Type (EPL_SYSTEM_TYPE) is not "PvA" - breaks will not be processed through this TomTom WEBFLEET interface when the full CALIDUS EPOD system is being run.

Processing of result records without an order state value: These messages are used predominantly to generate breaks indicated by the driver.

Note: Drivers Pausing and Starting work will generate new breaks and update in progress jobs. Breaks will not be generated if the driver is already in-progress on a pre-existing break job. Pre-existing break jobs (for example, generated by DiPS) will not be updated or confirmed when the driver pauses or starts work on the WEBFLEET device.

Filter (ignore) any messages that are not being processed by this interface. Initially, the list should be filtered for tag msgClass value "DATA" and the following message types (extracted from the last 3 digits of the value in the msgType tag):
- 711 - Log-off driver (including tachograph driver card removed) - treat as end of break.
- 712 - Begin of work, driver indicated - treat as end of break.
- 713 - End of work, driver indicated - treat as end of break.
- 714 - Begin of break, driver indicated - treat as start of break.
- 715 - End of break, driver indicated - treat as end of break.
- 716 - Work status change, indicating driver role, old and new work status (applies to all PRO 71xx, 91xx devices when used with identified driver and Remote LINK Working Time). If the tag pndWorkingStateMessageData sub-tag workstate value is "PAUSE", treat as start of break. If the tag pndWorkingStateMessageData sub-tag workstate value is "WORKING", treat as end of break.
- 717 - Work started (driver role and driver name indicated) - treat as end of break.
- 718 - Work ended (driver role and driver name indicated) - treat as end of break.
- 719 - Work time event, indicating driver. If the tag pndWorkingStateMessageData sub-tag workstate value is "PAUSE", treat as start of break. If the tag pndWorkingStateMessageData sub-tag workstate value is "WORKING", treat as end of break.

If treating the message as Start of Break:
- Find the Vehicle(s) (EPOD_VEHICLE) through the External System Reference (EPL_EXT_REF) from tag objectNo attribute value, for sites that match the fleet parameter from the extraction (EPL_XF_RECIPIENT from EPOD_XF_CONFIG).
- Find the load in progress on that Site (EPL_SITE_ID) and vehicle ID (EPL_VEHICLE_ID), for all matching vehicles. If one is not found, do not process this message.
- Find a job (EPOD_JOB) on the load that is a break (either generated by the system or generated by DiPS) that is status In Progress (EPL_STATUS is "I"). If there is one, ignore this message, as a break is already started.
- Find the first job on that load that is not complete i.e. the status (EPL_STATUS) is "P" - Pending - or "I" - In Progress, ordering by the status In Progress (i.e. those jobs should be the first jobs found).
- Create a new break job as follows:
  - EPL_SITE_ID - From the found Load's Site ID
  - EPL_LOAD_ID - From the found Load ID
  - EPL_JOB_ID - Generated
  - EPL_JOB_CODE - "BRK_<EPL_LOAD_ID>_<EPL_SEQUENCE_NO>". The tagged values should be substituted with the found Load ID, and the DIPS column value LINK SEQ NO respectively.
  - EPL_JOB_TYPE - "D"
  - EPL_JOB_GROUP - "OTHER"
  - EPL_JOB_INSTRUCTION - "Driver Break"
  - EPL_START_PLANNED_DATE - from the tag posTime value.
  - EPL_START_PLANNED_TIME - from the tag posTime value.
  - EPL_START_ACTUAL_DATE - from the tag posTime value.
  - EPL_START_ACTUAL_TIME - from the tag posTime value.
  - EPL_ARRIVAL_DATE - from the tag posTime value.
  - EPL_ARRIVAL_TIME - from the tag posTime value.
  - EPL_END_PLANNED_DATE - from the tag posTime value.
  - EPL_END_PLANNED_TIME - from the tag posTime value.
  - EPL_DISTANCE_PLANNED - 0
  - EPL_CUSTOMER_CODE - "BREAK"
  - EPL_CUSTOMER_NAME - "Driver Break " concatenated with the sequence (EPL_SEQUENCE) and the Load ID (EPL_LOAD_ID) from the found job.
  - EPL_ADDRESS_1 - "Driver Break " concatenated with the sequence (EPL_SEQUENCE) and the Load ID (EPL_LOAD_ID) from the found job.
  - EPL_POSTCODE - The postcode from the found job.
  - EPL_SEQUENCE - The sequence from the found job
  - EPL_LOADING_TYPE - Blank
  - EPL_TRAVEL_PLANNED - 0
  - EPL_WORK_PLANNED - 0
  - EPL_LAT - from the tag pos, sub-tag latitude value, converted to degrees.
  - EPL_LONG - from tag pos, sub-tag longitude value, converted to degrees.
  - EPL_LAST_CHANGED_DATE - Now
  - EPL_LAST_CHANGED_TIME - Now
  - EPL_ODO_START - from the tag odometer value, if present.
  - EPL_GENERATED - "Y" - Generated by the driver.
  - EPL_STATUS - "I" - In Progress
- Write a User Tracking record for the Break job created or updated to In Progress, indicating "WEBFLEET - Start of Break" - see below for details.

Note: When the first matching vehicle with an in progress load is found, stop processing any further records.

Note: If no EPOD_XF_CONFOG exists for the site for the WEBFLEET job update for that fleet for that vehicle, ignore the updates.

If treating the message as End of Break:
- Find the Vehicle(s) (EPOD_VEHICLE) through the External System Reference (EPL_EXT_REF) from tag objectNo attribute value, for sites that match the fleet parameter from the extraction (EPL_XF_RECIPIENT from EPOD_XF_CONFIG).
- Find the load in progress on that Site (EPL_SITE_ID) and vehicle ID (EPL_VEHICLE_ID), for all matching vehicles. If one is not found, do not process this message.
- Find a job (EPOD_JOB) on the load that is a driver-generated break that is status In Progress (EPL_STATUS is "I"). If there is not one one, ignore this message.
- If there is one, update it as follows:
  - Set the Actual End date and time (EPL_END_ACTUAL_DATE and EPL_END_ACTUAL_TIME) from the tag posTime value, translated into OBS format.
  - Set the break job's ODO End (EPL_ODO_END) from the tag odometer value if present.
  - Set the break job's status to Complete (EPL_STATUS = "C".
  - Set the Last Changed date and time (EPL_LAST_CHANGED_DATE and EPL_LAST_CHANGED_TIME) to the current server time, in OBS format.
  - Set the driving time (EPL_DRIVING_TIME) from the Arrival time on the job (EPL_ARRIVAL_TIME) minus the Actual Start time on the job (EPL_START_ACTUAL_DATE), plus any value already in this Driving Time field.
  - Set the actual work time (EPL_WORK_ACTUAL) from the Actual End time on the job (EPL_END_ACTUAL_TIME) minus the Arrival time on the job (EPL_ARRIVAL_TIME), plus any value already in this actual work time field.
  - Set the distance travelled (EPL_DISTANCE_ACTUAL) to the tag odometer value minus the start odometer value on the job (EPL_ODO_START), plus any value already in this distance travelled job field.
- If the break job found is a driver-generated break job, find any non-break jobs in progress (EPL_STATUS = "I") on the load. If found, set the distance (EPL_DISTANCE_ACTUAL) and travel time (EPL_DRIVING_TIME) on all the jobs to be the current values minus the values on the break job just updated, plus any value already in these fields. This will then remove the distance and travel that was added to the Break job from the job in progress, for the Planned vs Actual reporting later.
- Write a User Tracking record for the Break job created or updated to In Progress, indicating "WEBFLEET - End of Break" - see below for details.
- Check all the jobs on the Load.
  - If the System Type (EPL_SYSTEM_TYPE) is "PvA", if all have been completed or cancelled, set the Load status (EPL_STATUS) to "C" - Complete.
  - If all have been completed or cancelled and if the tag odometer value is present, set the ODO end against the load if not set (EPL_MILEAGE_END) from this incoming value. Set the Actual Distance travelled against the load (EPL_LOAD_DISTANCE_ACTUAL) to be the ODO end (EPL_MILEAGE_END)) minus the ODO start (EPL_MILEAGE_START), if both values are non-zero.

Note: When the first matching vehicle with an in progress load is found, stop processing any further records.

Note: If no EPOD_XF_CONFOG exists for the site for the WEBFLEET job update for that fleet for that vehicle, ignore the updates.

Note: Any messages in the result that do not match the filtered messages above can be ignored - no audit is required.

Note: When writing order tracking records to EPOD_USER_AUDIT, all of the normal details should be entered. This should be sourced from the Job record being updated unless specified otherwise:

Site ID
User ID - From the Load
Vehicle ID - From the Load
Load ID - From the Load
Job ID
Message Type - dependent on the tag orderState of the result being processed:
- 221 or 241 - "WEBFLEET - Order Started"
- 222 or 242- "WEBFLEET - Order Arrived"
- 301 - "WEBFLEET - Order Cancelled"
- 302 - "WEBFLEET - Order Rejected"
- 401 - "WEBFLEET - Order Complete"
- If this is Blank and the process is treating this as a Start of Break - "WEBFLEET - Start of Break"
- If this is Blank and the process is treating this as an End of Break - "WEBFLEET - End of Break"
GPS Coordinates - from the converted values of the input tag pos, sub-tags latitude and longitude values, concatenated with a comma.
Audit Date - The server date as of the time the record is processed.
Audit Time - The server time as of the time the record is processed.
Job Type
Device Date - extracted date from the tag posTime value, translated into OBS format.
Device Time - extracted time from the tag posTime value, translated into OBS format.

Note: Once messages taken from the queue in this message response are successfully processed, the process must use the webservice method ackQueueMessagesExtern to acknowledge completion of the message transfer to the application. Otherwise, the messages will be kept and returned again during the next call to popQueueMessagesExtern.

Note: In order to prevent this system from being flooded with over-sized responses, the number of messages that will be returned on a single response is limited to 500. This limit can be adjusted per account on request.

The structure of the ackQueueMessagesExtern method is identical to the above Pop message, except for the name, as follows:

     <ser:ackQueueMessagesExtern>
        <aParm>
           <accountName>EPL_XF_RECIPIENT</accountName>
           <userName>EPL_WEB_USER</userName>
           <password>EPL_WEB_PASSWORD</password>
           <apiKey>EPL_XF_MSG_TYPE</apiKey>
        </aParm>
        <gParm>
           <locale>UK</locale>
           <timeZone>Europe_London</timeZone>
        </gParm>
        <msgClass filter="ALL_EXCEPT_POSITION_MESSAGES" />
     </ser:ackQueueMessagesExtern>

Again, the response to this message will be the same as the other WEBFLEET messages, except that the outer tag is ackQueueMessagesExternResponse. Regardless of status, the

Should the value of the tag resultSize be 500, this whole process of retrieving, processing and acknowledging messages should be repeated. This should continue until the result size is less than 500 (i.e. there are no more messages on the queue).

Should there be a problem processing the messages from the queue, an audit record of the row detail and the error code should be created in EPOD_XF_AUDIT_HEADER. Failing a single message does not result in the message failing - these should always be acknowledged. Failures encountered server-side (failures within CALIDUS EPOD should result in not acknowledging the message, so that they may be reprocessed later by re-reading them from the queue.

When writing Audit records for failures and successes, the records should be populated as follows. If not specified, the values should be derived from the job:

Site.
Job Group, if this is an audit related to a job.
Header ID - Generated.
Request Data - If Failure, the resultItem tag and contents.
Request Date - The server date as of the time the record is processed.
Request Time - The server time as of the time the record is processed.
Status - "S" for Success, "F" for Fail, as indicated above when writing the audit record.
Status Description - If Success, "Jobs Updated", else the reason for the failure (e.g. "Load already completed", "Job already cancelled", etc) as indicated above.
Key Value 1 - The Job Code, if this is an audit related to a job.
Key Value 2 - The Job ID, if this is an audit related to a job.

Appendix A: TEST PLAN

Test Script / Scenario Reference	- WEBFLEET-ePOD Job Update Interface	Call Number(s): 336015 - SCR-332569-6, SCR-332569-7, SCR332569-8
Test Script / Scenario Description	Testing all aspects of the WEBFLEET - CALIDUS EPOD Update Interface.	PASS / ISSUES / FAIL
Menu Access	N/A
Pre-requisites	Create 2 loads with jobs configured as per the example Load in the supplied CSV extraction from DiPS.	Tested By:
Test Objective	To test that: jobs are updated with all actual information; Loads are updated correctly; jobs done out of sequence are updated taking into account any intermediate distance and time; driver-generated breaks are created correctly; jobs completed with breaks whilst in progress are updated taking into account any intermediate distance and time.	Date:

Step	Action	Result	Remarks	P/F
1	Cycle 1 - Normal Processing.

1.01	Accept and Start Loading job.	Job updated in C-ePOD - Job In Progress, Actual Start Date/Time updated on Load and Job, Load and Job Start ODO updated.
1.02	Arrive Loading Job.	Job updated in C-ePOD - Arrival Date/Time and End ODO updated, Travel Time and Distance updated.
1.03	Complete Loading Job.	Job updated in C-ePOD - Job Complete, Actual End Date/Time updated, Work Time updated.
1.04	Accept, Start and Complete Delivery Job 1.	Job updated in C-ePOD as before in stages - final result: Job Complete, Actual Start Date/Time, Job Start and End ODO, Arrival Date/Time, Travel Time, Distance, Actual End Date/Time and Work Time updated on Job.
1.05	Reject Delivery Job 2.	Job updated in C-ePOD as before in stages - final result: Job Cancelled, User Notes, Actual Start Date/Time, Job Start and End ODO, Arrival Date/Time, Travel Time, Distance, Actual End Date/Time and Work Time updated on Job.
1.06	Cancel Delivery Job 3.	Job updated in C-ePOD as before in stages - final result: Job Cancelled, User Notes, Actual Start Date/Time, Job Start and End ODO, Arrival Date/Time, Travel Time, Distance, Actual End Date/Time and Work Time updated on Job.
1.07	Complete Break 1.	Job updated in C-ePOD as before in stages - final result: Job Complete, Actual Start Date/Time, Job Start and End ODO, Arrival Date/Time, Travel Time, Distance, Actual End Date/Time and Work Time updated on Job.
1.08	Complete Consolidated Delivery 1.	All Jobs updated in C-ePOD as before in stages - final result: Jobs Complete, Actual Start Date/Time, Job Start and End ODO, Arrival Date/Time, Travel Time, Distance, Actual End Date/Time and Work Time updated on Jobs.
1.09	Cancel Consolidated Delivery 2.	All Jobs updated in C-ePOD as before in stages - final result: Jobs Cancelled, User Notes, Actual Start Date/Time, Job Start and End ODO, Arrival Date/Time, Travel Time, Distance, Actual End Date/Time and Work Time updated on Jobs.
1.10	Complete Break 2 before the next job (out of sequence).	Job updated in C-ePOD as before in stages - final result: Job Complete, Actual Start Date/Time, Job Start and End ODO, Arrival Date/Time, Travel Time, Distance, Actual End Date/Time and Work Time updated on Job.
1.11	Complete Delivery Job 4.	Job updated in C-ePOD as before in stages - final result: Job Complete, Actual Start Date/Time, Job Start and End ODO, Arrival Date/Time, Travel Time, Distance, Actual End Date/Time and Work Time updated on Job.
1.12	Complete Unloading.	Job updated in C-ePOD as before in stages - final result: Job Complete, Actual Start Date/Time, Job Start and End ODO, Arrival Date/Time, Travel Time, Distance, Actual End Date/Time and Work Time updated on Job. Load updated to Complete, End ODO updated. Next Load automatically set to In Progress (not part of this test).

Step	Action	Result	Remarks	P/F
2	Cycle 2 - Out of sequence.

2.01	Complete Loading Job.	Job updated in C-ePOD as before in stages - final result: Job Complete, Actual Start Date/Time, Job Start and End ODO, Arrival Date/Time, Travel Time, Distance, Actual End Date/Time and Work Time updated on Job.
2.02	Start and Drive to Delivery Job 1. Do not Arrive at Job.	Job updated in C-ePOD as before in stages - final result: Job In Progress, Actual Start Date/Time, Job Start ODO updated on Job.
2.03	Start, Arrive and Complete Delivery Job 2 before completing Delivery Job 1.	Job updated in C-ePOD as before in stages - final result: Job Complete, Actual Start Date/Time, Job Start and End ODO, Arrival Date/Time, Travel Time, Distance, Actual End Date/Time and Work Time updated on Job.
2.04	Complete Delivery Job 1.	Job updated in C-ePOD as before in stages - final result: Job Complete, Actual Start Date/Time, Job Start and End ODO, Arrival Date/Time, Travel Time, Distance, Actual End Date/Time and Work Time updated on Job. Distance Travel times take into account the distance and time travelled on the job 2 in between.

Step	Action	Result	Remarks	P/F
3	Cycle 3 - Driver-generated Breaks.
	Continuing from Cycle 2.
3.01	Pause Work.	Creates new break job as specified.
3.02	Start Work.	Updates new break job - Job Complete, Actual Start Date/Time, Job Start and End ODO, Arrival Date/Time, Travel Time, Distance, Actual End Date/Time and Work Time updated on Job.
3.03	Cancel preadvised break job.	Job updated in C-ePOD as before in stages - final result: Job Cancelled, User Notes, Actual Start Date/Time, Job Start and End ODO, Arrival Date/Time, Travel Time, Distance, Actual End Date/Time and Work Time updated on Job.
3.04	Start Consolidated jobs 1.	Job updated in C-ePOD - Job In Progress, Actual Start Date/Time updated on Load and Job, Load and Job Start ODO updated.
3.05	Pause and Start Work.	Creates and updates new break job in stages as before: Job In Progress, Actual Start Date/Time updated on Load and Job, Load and Job Start ODO updated. Updates In-progress Consolidated Jobs 1 wrt Time and Distance taken away for the time and distance taken on the Break.
3.06	Continue Consolidated jobs. Pause and Start Work again.	Creates and updates new break job in stages as before: Job In Progress, Actual Start Date/Time updated on Load and Job, Load and Job Start ODO updated. Updates In-progress Consolidated Jobs 1 wrt Time and Distance taken away for the time and distance taken on the next Break added to the previous break.
3.07	Complete Consolidated Jobs 1.	Jobs updated in C-ePOD as before in stages - final result: Jobs Complete, Actual Start Date/Time, Job Start and End ODO, Arrival Date/Time, Travel Time, Distance, Actual End Date/Time and Work Time updated on Jobs. Distance, Work and Travel times take into account the distance, work and time travelled on the 2 break jobs in between.
3.08	Complete consolidated jobs 2.	Job updated in C-ePOD as before in stages - final result: Job Complete, Actual Start Date/Time, Job Start and End ODO, Arrival Date/Time, Travel Time, Distance, Actual End Date/Time and Work Time updated on Job.
3.09	Start the next job. Pause and Start work, complete job.	Job updated in C-ePOD as before in stages - final result: Job Complete, Actual Start Date/Time, Job Start and End ODO, Arrival Date/Time, Travel Time, Distance, Actual End Date/Time and Work Time updated on Job. Distance, Work and Travel times take into account the distance, work and time travelled on the break job in between.
3.10	Cancel preadvised Break.	Job updated in C-ePOD as before in stages - final result: Job Cancelled, User Notes, Actual Start Date/Time, Job Start and End ODO, Arrival Date/Time, Travel Time, Distance, Actual End Date/Time and Work Time updated on Job.
3.11	Complete Unloading.	Job updated in C-ePOD as before in stages - final result: Job Complete, Actual Start Date/Time, Job Start and End ODO, Arrival Date/Time, Travel Time, Distance, Actual End Date/Time and Work Time updated on Job. Load updated to Complete, End ODO updated.

Appendix B: Quote & Document References

Cost Details
Activity	Estimate No. of Days	No. of Days	Rate per Day (£)	Cost (£ Exc. VAT)
Requirements	0.00	0.00	750	£0.00
Change Request Evaluation	0.00	0.00	750	£0.00
Functional Specification	1.75	1.75	750	£1,312.50
Technical Specification	1.75	1.75	750	£1,312.50
Development	7.25	7.25	750	£5,437.50
Testing and Release	1.50	1.50	750	£1,125.00
Implementation	0.00	0.00	750	£0.00
Project Management	0.50	0.50	750	£375.00

TOTAL	12.75	12.75		£9,562.50

Estimate excludes training, release to live and go live support.

B.1 References

Ref No	Document Title & ID	Version	Date
1	336010/SCR-332569-2 DiPS-ePOD Interface for Load and Order Sequencing	1.0	23/08/2016
2	EPOD Import Mapping	5.1.2	17/06/2016
3	EPOD Export Mapping	5.1.2	17/06/2016
4	obs-eas-DIPS2AXS for PvA.xls	N/A	24/06/2016

B.2 Glossary

Term	Definition
EPOD	Electronic Proof of Delivery. The OBS EPOD system is CALIDUS ePOD.
CALIDUS eSERV	The OBS mobile system to complete Service functionality in the field. This is part of the CALIDUS ePOD system.
PDA	The mobile device on which the C-ePOD system will run in the field. This can be a Phone, EDA or industrial PDA, running Android.
DAL	Data Access Layer. A mechanism for accessing data by the system that is removed from the application, allowing for simplified access and providing protection to the data, as only approved DAL methods can be used to modify it.
GPS	Global Positioning System. A mechanism of retrieving accurate positioning information in the form of Latitude and Longitude (Lat-Long) co-ordinates from a device.
GPRS, 3G, HSDPA, Data Service	All terms referring to mobile device network connectivity, and the speed at which the device connects to the internet.

B.3 Authorised By

Rob Carter	Greene King Representative	_____________________________
Matt Tipping	OBSL Representative	_____________________________

Anonymous

Search

FS 336015 SCR-332569-6 GK PvA WEBFLEET-ePOD Interface

Namespaces

More

Page actions

Contents

Functional Overview

Client Requirement

Solution Overview

Scope

Set-up

Pre-requisites

Menu Structure

Data

Functional Description

Database/DAL

Auto Import Process

Appendix A: TEST PLAN

Appendix B: Quote & Document References

Navigation

Navigation

Translate

Wiki tools

Wiki tools

Anonymous

Search

FS 336015 SCR-332569-6 GK PvA WEBFLEET-ePOD Interface

Functional Overview

Client Requirement

Solution Overview

Scope

Set-up

Pre-requisites

Menu Structure

Data

Functional Description

Database/DAL

Auto Import Process

Appendix A: TEST PLAN

Appendix B: Quote & Document References

Navigation

Wiki tools

Page tools

Categories