AEL Solutions

AEL CALIDUS ePOD/eServ Solution Design

CALIDUS ePOD/eServ

12th September 2016 - 0.4
Reference: REQ 335787

Introduction

This document is the AEL CALIDUS ePOD/eServ Solution Design.

Objective

The primary purpose of this document is to document the requirements gathered from AEL Solutions, on 10/05/2015 at the AEL Solutions Reading office.

This document has been written in a manner such that it can be approved by non-technical representatives of AEL Solutions 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 AEL Solutions, as referred to in the appendices, as well as information gleaned from site visits and workshops with AEL Solutions.

The changes will be made in the latest version of the CALIDUS ePOD/eServ system, operating the Android version of the ePOD Client application.
Changes relating to information passed through to CALIDUS ePOD/eServ from external systems (i.e. NAV) are subject to analysis and design, which may affect the other changes in this document or generate other work if the process described within this document cannot be followed by the external system.

Client Requirements

Listed below are the proposed processes that will be followed by the operatives using CALIDUS ePOD/eServ. Also shown are the SCRs required for this to be achieved.

Operational Overview

AEL Solutions is regarded as the UK's leading provider of commercial outdoor furniture and accessories for cafes, bars, pubs, hotels and other leisure, hospitality and catering locations.

General information gathered from sales meetings:

PDA users should not be able to re-sequence jobs.
PDA users should be able view all products that have been delivered and, if required, make changes before the signature is captured.
Customer and driver signatures are required for all jobs (deliveries, collections and services).
When capturing the signature the signatory should not be populated (i.e. must be entered).
For photographs:
- A job photo is required for each delivery or collection job.
- A photo is required for each service item.
Job groups can be simplified to just two, one for deliveries and one for services.
Products will use the long description (to allow descriptions over 40 characters).
There are 2 depots, Sheffield and Reading in this operation.

Devices

TomTom devices with Android operating system. There are no TomTom Link or ECO+ devices fitted to the vehicles.

Project:

A trial/parallel run on ePOD in the field will commence in November and December.

General System Overview

The core systems are NAV and CALIDUS ePOD/eServ.

In2Grate will be contracted for NAV support, and are expecting to upgrade to 2016 NAV from 2009 after the next financial end i.e. 1st December.

The process is as follows:

Jobs are received into NAV.
Jobs are assigned to trips/workloads within NAV.
Trips/workloads will be assigned to users within NAV.
Trips/workloads and associated jobs are interfaced from NAV to the ePOD Admin system.
Trips/workloads can be assigned to users within the ePOD Admin system.
When requesting work each PDA will be sent a trip/workload along with all associated jobs.
The jobs on a trip/workload will be processed on the device, when complete (providing connectivity allows) the ePOD Admin system will be updated. Completed jobs will be interfaced from the ePOD Admin system to the NAV system.

Data Import

The export of data is configurable in CALIDUS ePOD/eServ and is dependent on the version of NAV implemented.

For the old version (Navision), it is expected that all files (inbound to and outbound from CALIDUS ePOD/eServ) will be transferred using an FTP method.

For the new version (NAV2016), it is expected that all files inbound to CALIDUS ePOD/eServ) will be transferred using the CALIDUS ePOD/eServ Webservices. All files outbound will be pushed to a webservice hosted by NAV2016.

Regardless of NAV version, the content of the files and messages will be in OBS XML format.

Jobs and Loads in CALIDUS ePOD/eServ are organised into Sites. The operation has multiple depots (Sheffield and Reading) and the systems can be configured to separate the jobs by this site for execution. It is expected however that there will be be only one site in this implementation, for simplicity.

All jobs of any type will be sent to the CALIDUS ePOD/eServ system with a configuration element known as Job Group - this will define the process to be followed against each job, such as:

Driver/Customer Signature.
POC/POD document format.
POC/POD business address and logo.
Terms and Conditions displayed.

The Job Groups will be defined and agreed in advance between the back-end software providers and OBS Logistics.

It is expected that there will need to be at least three Job Group configurations:

Deliveries
Collections
Services

Note: Any collections could use the deliveries job group or could optionally have a separate collections job group.

If Job Groups are sent to CALIDUS ePOD/eServ that have not been created in advance, the interface will create them as a skeleton record, defaulting the configuration.

The exact confirmation of the Job Group configuration will be decided at implementation stage. Some details of this is covered in the Administration Setup section.

The Jobs and Trips/Workloads themselves will be interfaced with the data required to complete the jobs. This will be mapped outside of this document.

Details for each trip/workload will include:

A unique Workload reference to the trip/workload.
Optionally, the user or vehicle this load is assigned to. It is expected to be assigned to the user rather than the vehicle.

Note: The jobs will all be part of one site, and the jobs can and should be placed on the same work load if the operation requires this - there is no need to separate Service and Collection/Delivery jobs.

Details for each Delivery job include:

The Load ID this job is associated with.
- The job code for the job, this is the unique reference for each job.
- The customer reference for the job.
- The SO reference
The job type (D for delivery or C for collection).
The job group.
The Customer A/C number.
The Sales Person.
The Order Raised date.
Any job instructions (to include both generic instructions for the customer and any instructions specific to this job).
Product Information to include:
- Product Code
- Product Description - These are to be sent as the long description, allowing descriptions over 40 characters to be used (a shorter description of up to 40 characters can optionally be sent as the standard description).
- Product quantities regarding Ordered and Planned Delivered quantities are required.

Note: Delivery instructions are provided from several sources (specific instructions against the job and/or standing instructions for the customer e.g. "Ring 1hr before arrival"). These instructions should be concatenated in NAV and sent in the Instructions shown above. The application will ensure that these instructions are read before starting a job.

Details for each Service job include:

The Load ID this job is associated with.
The references for the job, expected to include:
- The job code for the job, this is the unique reference for each job.
- The customer reference for the job.
- Service Item ID, if service items are specified. This is a unique system-generated ID.
The job type (S for service).
The job group.
The Customer A/C number.
Any job instructions (to include both generic instructions for the customer and any instructions specific to this job).
An Owner must be specified against each job. It is expected that this will be the same for all jobs and will be agreed during the mapping exercise.
Service Items may be included if these are known, if included these will include:
- Service ID
- Reason for visit (Optional)
- Serial number
- Service product group (e.g. AWNING, UMBRELLA, PLAY, OTHER).

There are additional interfaces to CALIDUS ePOD/eServ in order to keep standing data in line within the system, for example:

Drivers - used to allocate loads to drivers
Vehicles - used to allocate loads to tractors/trailers/vehicles
Reason Codes - used when exceptions are encountered (cancelling jobs, containers, products, changing quantity)

Note: Routes (Loads) must be allocated to a driver and/or vehicle for them to be picked up by the devices. If this cannot be achieved by NAV, then the CALIDUS ePOD/eServ Admin system (Load or User screens) may be used to manually allocate drivers to loads.

Note: There are agency staff and hire vehicles. These may be created as general agency users and vehicles, or can be added in NAV or CALIDUS ePOD/eServ when brought into the operation. The process of adding users and vehicles in CALIDUS ePOD/eServ is simple in the Administration screens and should be covered in training. Regardless, the interface should create the users and vehicles sent to CALIDUS ePOD/eServ from NAV when the jobs are received, if these have not been seen before. If this is the case, they will need amending in the CALIDUS ePOD/eServ Administration system, so confirm the password for the user.

Note: Reason codes are the operation's to maintain and can be complex. They should be normalised between NAV and CALIDUS ePOD/eServ. Reason codes can help in reporting and categorising exceptions (e.g quantity change, job cancellation) in NAV. Narrative responses are virtually impossible to group by narrative reasons e.g. "Late arrival" vs "Arrived Late" vs "ARRIVED LATE". Regardless, the system will be configured to allow this.

Administration

The CALIDUS ePOD/eServ system provides functionality to handle the process of Proof of Delivery and Service electronically. The system aids this process by providing both a management interface and a client application for use completing tasks. The system supports three job types at this point which encompass the functionality to complete many more tasks with them. At this point the system can be used to complete and record; Deliveries, Collections and Services.

The CALIDUS ePOD/eServ administration software is a web-based application that handles all of the administrative side of the mobile devices.

The purpose of the application can be broken down into the following sections:

To create and maintain users of the mobile devices.
To create and maintain reference data for the system (e.g. Reason Codes, Vehicles, Customers).
To create Jobs of all types and group them together onto Loads.
To assign Loads to Users.
To view the Jobs and Loads created.
To print or email a POD or Service Report.

Note: If loads are not assigned to Drivers or Vehicles through the NAV interface, CALIDUS ePOD/eServ provides a facility to manually assign Loads to drivers, through the following mechanisms:

Through the Load, assigning a user directly
Through the User, selecting from any Pending Load.

Assigning a User to Loads

Assigning Loads to a user

Vehicles will be assigned automatically as the driver logs on to the device application and confirms which vehicle they are using.

Standing Data (i.e. Vehicles, Reason Codes, Users) may be uploaded in mass through the appropriate maintenance screens - XLS templates may be downloaded from the screens

A full guide to the use of the system can be found referenced in Appendix A.

Administration Setup

The administration system includes the setup of standing data which controls the way the Administration web application and the device's Android application function.

This section will list some of the require setup options identified from discussion with AEL.

1. Disable job resequencing option.

On the Site Maintenance page, within the PDA tab, there is a 'Resequencing Options' field. This should be set to 'N - Disabled' in order to disable the resequencing of jobs, forcing the user to process the jobs in the sequence provided.

2. Enable product comments.

Product comments can be enabled for jobs belonging to a job group within the job group maintenance page. On the PDA tab if the 'Product Comments' checkbox is checked the comments option will be available.

3. Job Details UDF for Service Jobs.

Job details UDF will be required for the job group being used for service jobs only (i.e. not for delivery jobs). This UDF should consist of a single required numeric field labelled as 'Number of Engineers'.

4. Service Information UDF.

Service information UDF will be required for selected service product groups.

For the AWNING group this should consist of two optional numeric fields labelled as 'Length' and 'Projection'.

For the UMBRELLA group this should consist of two optional text fields labelled as 'Size' and 'Heat & Light'.

No service information UDF is required for the remaining service product groups (PLAY and OTHER).

5. Service Diagnosis UDF.

Service information UDF will be required for all service product groups. This will include a single photo-bar question which will be set as required (i.e. user must take at least one photo).

6. Require driver and customer signatures for delivery/collection jobs.

7. Require job completion photo for delivery/collection jobs.

8. Service job UDF to require entry of a number of engineers.

9. Service Diagnosis UDF to require capture of at least one photo for each service item.

PDA Login

The application will have a customised style created for AEL, which will include:

A blue colour scheme
The logo on the login page.
Job list configuration to show:
- The job code
- The job type (Delivery, Collection or Service)
- The customer name (shown in a larger font in the centre of the row)
- Planned date/time
- Postcode
Delivery (or collection) product list configuration to show:
- Product code
- Product description (using the long description)
- Product quantity (showing planned quantity for incomplete products or actual and planned quantities for complete products)
Service item configuration to show:
- Group
- Make
- Serial number
- Reason for visit

SCR-335787-1:

Create customer-specific style on device.

Login

The drivers will be provided a user-name and password, and the loads will be allocated to specific drivers and vehicles, ensuring that they can complete only the loads required. The users and their passwords must be configured within CALIDUS ePOD/eServ.

A driver logs on to a device entering their provided user name and password and selecting the vehicle from a drop-down list. The device will remember the last used User name and Vehicle, but will always require that the password is entered.

Note: Vehicle Checks within CALIDUS ePOD/eServ are not required and so will not be configured.

Obtain Workload/Job List

When vehicle checks are complete, the assigned work-list will be downloaded onto the device, showing all the jobs in sequence on a Job List screen. If no workload has been assigned to the Driver (or vehicle), the device will tell the user that there is no work available. The driver can exit, or try to download again.

Once a Load has been downloaded to the device, the device will display the details of the load in a Job List.

Job List

The list of the jobs on this load will show the following:

Job Reference - configured to be the Job Code
Job Type - Collection, Delivery or Service
Customer Name - Shown in a larger font in the centre of the row.
Planned Date/Time - Shown in the format DD/MM/YYYY hh:mm.
Postcode - The postcode associated with the job.

The screen will display the status of the jobs on the load through a coloured outline, as follows:

Red - Cancelled
Green - Completed
Blue - Completed (with amendments)
Yellow - In Progress
None - Pending/Incomplete

Note that this status is also displayed prominently in the Job Details screen (following).

The jobs are displayed in the sequence in which they should be completed, with the first job selected. However, the jobs can be viewed in any sequence by clicking the line of the job - the device will display the Job Details screen.

The Menu button can be used here to allow the following options:

Show All / Outstanding Jobs - Toggle between showing all or only incomplete jobs.
Refresh - Refresh the Load/Work-list
Consolidate or Deconsolidate groups of jobs

The system will be configured to not allow re-sequencing of jobs - the jobs must be completed in the order planned, or cancelled if they cannot be completed.

If any jobs have been added to a Load while the load is in progress, the Refresh option (which also is timed to happen on a regular interval) will get the details of the new job and add it to the job list, showing the user a summary of the job(s) added. This functionality will also pick up any amendments to the jobs, for example, if quantities have been amended or products have been added/removed. This can also be triggered by long-pressing against the label showing the load identifier on the screen. If this refresh picks up changes to existing jobs or new jobs the job list changes to show a list of the affected jobs along with an Accept Updates button which will return the user to the standard job list.

Jobs can be cancelled by the driver at this time, by long-pressing on the job in the table and choosing Cancel from the pop-up options. The user will be prompted to enter a reason why this job is being cancelled, and optionally take a picture. If a job is confirmed cancelled, the device will show the Job List again with the cancelled job removed from the list.

The driver may choose to consolidate collection or delivery jobs together, to process them together for speed. This is available through several options on the device, allowing:

Manual consolidation, by selecting all jobs to be consolidated individually, accessible through the Consolidate menu option.
To group single jobs with other consolidations, through the Create Group option accessed when long-pressing against a job or consolidated group.

Additionally, jobs may already be consolidated together when the load was created - this is not expected to be the case for jobs received from NAV.

Note: Service jobs may not be consolidated.

When consolidated jobs are present, a single line is shown summarising the information from all the jobs (i.e. total number of consignments, etc). These can be seen in more details when completing the job (see later in this document).

The driver also has access to several functions to deconsolidate consolidated groups of jobs:

Singly, by selecting the job to split out, through the Deconsolidate menu option.
Breaking the entire group back to single jobs, through the Break Group option accessed when long-pressing against a consolidated group.

Note: This functionality can be disabled if not required.

Job Details

Selecting a job from the Job List will show the user the job report and customer contact details (on a Job Details screen). The user can back out of the selected Job and view any Job on the list.

Job Details - Address and Contact
Instructions

The screen has several Tabs, showing:

The Job Type (Collection, Delivery, Service)
The customer details (Customer Code, Name, Address and Postcode)
The contact information (Contact name and number)
The Instructions for the job

Clicking on the tabs will display the information.

If the jobs are consolidated, the < and > buttons can be used to move between the all the consolidated jobs, to see any specific details. The Instructions tab will show all instructions for all the jobs, as well as any additional information passed through for the job.

The screen will be changed so the call and SMS icons are not included on devices such as the TomTom PRO as the device does not have a call or SMS facility.

SCR-335787-2:

Prevent call and SMS options on device with no telephone

Cancelling a Job

The driver can cancel jobs by clicking the Cancel Job button on the job detail screen.

This will call the cancellation screen where the user will be prompted to enter a reason why this job is being cancelled. The cancellation screen also allows the user to take a picture.

Note: Whether or not a picture is required for a job cancellation is controlled by the 'Image Required for Cancellations' setting against the job group for the job. If this is set to 'All' or 'Job Only' then a picture must be taken to cancel a job, otherwise the picture is optional.

If a job is confirmed cancelled, the device will show the Job List again with the cancelled job removed from the list.

Note: This job cancellation screen can also be called from the job list.

Starting a Job

When the user has selected their Job, they can choose the Job with the Start Job button.

Delivery instructions are provided from several sources (specific instructions against the job and/or standing instructions for the customer e.g. "Ring 1hr before arrival"). These instructions should be concatenated in NAV and sent in the Instructions shown above. If there have been instructions provided on the Job and the driver has not already switched to this tab to view the instructions, the device will switch to the Instructions tab, to force the user to see the instructions before starting.

The disabling of the resequencing option means that, if the job is not the next outstanding job, an error will be issued preventing the job from being started.

When clicking this button to start or arrive at the job, the application normally performs a check whether the job has been changed since it was loaded on the device. As it has been confirmed that there will never be modifications of a load after it has been loaded and interfaced to CALIDUS ePOD/eServ, this check will be configured to be disabled on the device.

When a Job is successfully started, this will take the Job to 'In Progress' status, at this point the 'Start Job' button will change to an 'Arrive Job' button and the navigation icon is shown. When the navigation icon is clicked on the device will use a navigation application installed on the device to navigate to the destination. This will be through the TomTom navigation application for TomTom devices and Google navigation for any other device. The destination address will be entered in the device and will allow immediate navigation to the address.

Job Details - Arrive button

Once arrived at the destination, the driver should switch back to the CALIDUS ePOD/eServ mobile application. This can be through the 'All apps' icon on the home screen or through a configured short-cut on the task bar. The driver can then indicate arrival and start processing the Job by clicking the Arrive Job button. When the job is confirmed as Arrived, the device will move on to the Delivery, Collection or Service process, depending on the job type.

Delivery Process

Deliveries will consist of multiple loose products.

The following are the standard tabs that are expected to be displayed:

Job Details Tab
Job Details Tab - Addresses
Products Tab
Notes Tab

The Job Details tab has multiple sections:

Contact information
Address information - if supplied, both current address and origin address are shown.
Job Instructions

Note: A Deliver All button may be configured here for marking all products as delivered and moving to Job Completion stage, skipping all scanning of products. It is expected that this will be disabled at the beginning of the implementation, and may be enabled if required at a later date.

The Products tab will display a list of the product to be delivered, showing:

The Product Code
The full Description
The Planned Quantity

If this is a consolidated job, the list will show all products required to be delivered on all jobs, including an indication of which order this product is for. Note: If the same product is present on two jobs consolidated together, the product will appear twice, to allow accurate recording of quantity delivered.

Actions against the products can be activated by long-pressing against the row, and have the following actions:

Deliver X
Change Quantity
Comments
Cancel
Info

Products Long-press Pop-up
Product Info Pop-up

For information on the actions above, see the appropriate following sections.

When all containers and products have been confirmed as delivered or cancelled, the Delivery process will return to the Job Details tab, where a Complete button will be displayed, to complete the job. It is then possible to review the list of products delivered and change this if required. The list will display a border and status to indicate whether the products have been delivered:

Red - Cancelled
Amber - Delivered with an amendment (changed quantity)
Green - Delivered in full.

The status and the Planned and Actual quantity will be displayed for confirmation.

It was requested during the Discovery day to evaluate the facility of marking the scanned items as they are scanned, rather than removing them from the screen on initial scan. This is an optional change and may be completed at additional cost.

SCR-335787-3:

Mark scanned products as they are scanned instead of removing them.

When the driver has confirmed that everything is complete and clicked the Complete button, this screen will close and the user will be directed to the Job Completion process.

Delivering a Product

Each product on the list can be confirmed as delivered by either:

long-clicking on the item in the list and choosing Deliver X from the pop-up menu. Note: This option can be removed by configuration if not required.
entering the product code manually and clicking Deliver X from the pop-up menu.
scanning the product code and clicking Deliver X from the pop-up menu.
clicking the Deliver All button.

When marked as delivered, the item will be removed from the list.

Changing a Product Quantity

The driver can change the quantity by choosing Change Quantity from the pop-up menu - the device will direct them to an exception screen where the quantity can be changed, and a reason code entered as to why the quantity is changed.

Exception - Change Product Quantity

For clarification, the product code and description will also be displayed here.

The user will also be able to optionally take a picture associated with this change of quantity.

If zero is entered as the new quantity, the application will cancel the product and remove it from the product list. If the quantity is changed (and is not set to zero), the product will be marked as having the quantity entered delivered and will be removed from the product list.

Cancelling a Product

If a product can't be delivered, it can be removed from the list with the pop-up option Cancel. Again, the exception screen will be shown where the driver can enter the reason for the cancellation.

The user will also be able to optionally take a picture associated with this cancellation.

Note: Whether or not a picture is required for a product cancellation is controlled by the 'Image Required for Cancellations' setting against the job group for the job. If this is set to 'All' or 'Detail Only' then a picture must be taken to cancel a product, otherwise the picture is optional.

Commenting a Product

The enabling of the product comments will mean the product options will also include a Comments option.

This option will call the exception screen to allow the user to enter any comments against this product and optionally take a photo.

Note: Reason codes are the operation's to maintain and can be complex. They should be normalised between NAV and CALIDUS ePOD/eServ. Reason codes can help in reporting and categorising exceptions in NAV. Narrative responses such as this Product Comment are virtually impossible to group by narrative reasons e.g. "Late arrival" vs "Arrived Late" vs "ARRIVED LATE". Regardless, the system will be configured to allow this.

The system will be modified to require a reason code to be specified if the quantity has been changed.

SCR-335787-4:

Require Reason Code when entering Product Comments and Changing Quantity.

Service Process

The service is an evaluation and service. When the installer reaches the customer, they may not know how many items and of which type are going to be serviced. NAV may not know and cannot send this information.

Therefore a service job may or may not already have service items attached. The system will require modification to handle this.

The following are the standard tabs that are expected to be displayed:

Job Details Tab
Information Tab
Products Tab
Diagnosis Tab

Note: There is an optional User Notes tab that can be displayed, allowing the user to enter any notes against the Job before completion.

If no service items have been sent to the device, only the Job Details tab will be visible initially.

The Job Details tab has multiple sections:

Contact information.
Address information - if supplied, both current address and origin address are shown.
Job Instructions.
Any job details UDF applicable to this job. The UDF setup will mean that, for jobs within the services job group, this will show a single numeric question labelled as 'Number of Engineers'.
A button for cancelling the entire service job - this uses the standard job cancellation process.
A new button, labelled Create Items, which will be used to create a new service items.

When the new Create Items button is clicked the application will prompt the user for a group (via a drop-down list) and a number of items. Once these have been entered and confirmed the application will create the requested number of service items using the selected group against this service job.

SCR-335787-5:

Allow empty service jobs and creation of service items.

Create Item pop-up
Create Item - Groups

This button may be used multiple times to generate multiple service items of each group. Once some service items have been created, the additional tabs will be made visible.

When a Service Job consists of multiple serviceable items, the number of items is indicated in the header of the Information tab. 2 buttons are provided to move between the service items, which will refresh the screen before continuing.

Note: It was noted in the Discovery day that the process of entering Service Item information can be obscure. The flow of processing service items is predominantly left to right.

Select the Item being serviced using the navigation buttons.
Enter the Information tab details.
Enter the parts used or required on the Products tab.
Enter the report and comments and take any photos on the Diagnosis tab.
Complete the job using the button on this tab - the device will return to the Information tab, selecting the next item available automatically.

The data validation will be improved to ensure that data will be validated where appropriate when moving between tabs.

Additional Validation

SCR-335787-6:

Improve service item process flow and validation.

The Information tab will show the following for a single service item:

Group - This will show the group set against this service item and can be changed via a drop-down list. This is expected to be a list of "AWNING", "UMBRELLA", "PLAY" and "OTHER". This is a function of the service parts configured in NAV or CALIDUS ePOD/eServ and can be extended through the addition of other service parts.
Make/Model - This will show the make set against this service item and can be changed via a drop-down list. This is a function of the service parts configured in NAV or CALIDUS ePOD/eServ and can be extended through the addition of other service parts. If none are configured, none will be prompted for or required. If this is changed on this screen, this will pre-filter the Products tab for searching for parts for the service.

SCR-335787-7:

Information Model change should change the Products and Other Products search screens automatically.

Serial No - This will accept a serial number, if one has been set this field will initially be set to the pre-advised value.
Reason for Visit - This field shows the reason for the visit for this service item. If a reason has not already been set this will allow the user to select one via a drop-down list. If the reason has already been set then this will be a display only field, the user will not be able to change the value.

SCR-335787-8:

Allow service reason for visit to be read only.

Any service information UDF questions setup for the selected group. The service information UDF setup is expected to show questions for the AWNING group (for length & projection) and the UMBRELLA group (for size and heat & light).

Note: Permission to Work is a process that will almost certainly be removed from the operation before implementation. If not, it is likely that the process will remain paper-driver. During the Discovery day, OBSL demonstrated capability with the current system to prompt for Permission to Work both before and after completion of an item, through the use of Pre- and Post-work checks. This may be required for new contracts in the future, so this capability may be more fully evaluated when/if this should become a requirement. It is not part of the required process at this time.

The Products tab can be used to record the products that have been used on, or are required for, a service item. This includes:

Drop-down lists for models and products to allow a product to be selected.
An Installed button to add the selected product to the installed products.
A Required button to add the selected product to the required products.
A product list showing the installed or required products for this service item.

An Other button will be added through the customer style which allows access to the Product Search / Other Product screen.

Search Products screen
Other Products screen

This screen allows the user to:

- Allows the user to search for products from a partial product code or description and add the selected product to the installed or required products.
- Add stock for a stock code that is not included in the existing service products to the installed products.

This screen will be modified to allow the user to select Required or Used, through buttons on the screen.

SCR-335787-9:

Add Required button to Other Products screen.

Note: This screen allows the use of 'Vehicle/Own Stock', whereby vehicles can be maintained with their own level of stock for immediate use. This feature can vastly reduce the list of products and make it easier to search. AEL do not currently maintain Vehicle Stock in NAV. The intention for the future is for this to be maintained, and updated/stock checked every month.

The Diagnosis tab includes:

A comments text area that can be used to record any comments specific to this service item.
A 'Misuse' checkbox.
Any service diagnosis UDF setup for the selected group. The service information UDF setup is expected to comprise of a single photo-bar question which will allow multiple photos to be taken and require at least one photo to be taken.

As part of the change for Creating Service Items, the service will not automatically be completed on completion of the last service item - instead, the user will be offered the facility to create more items, by being returned to the Job Details tab. If all items have been completed, the user will be able to complete the service as a whole by clicking the provided Complete button. The user will be taken to the Job Completion process.

Job Completion

All jobs will be sent to the CALIDUS ePOD/eServ system with a configuration element known as Job Group - this will define the process to be followed against each job, configuring the following items:

The Terms and Conditions displayed
Customer Signature required
Driver Signature required
Completion document format

All of these processes are controlled during Job Completion.

Note: At this time, the expectation is that the configuration will require the Customer and Driver to sign for all jobs (collection and delivery of goods and Services). This can be changed on a per job type or per job group basis.

The device will prompt for Customer Signature.

Signature and T&Cs
Products

Note: The signatory will be blanked - the driver will be forced to enter one.

The screen displays several tabs, allowing the user to see:

Terms and Conditions, plus any data entry the user is required to confirm. These are configurable.
The quantity of products being collected/delivered.
If this is a consolidated group of jobs, a further tab will display the Job references.

The Terms and Conditions are configurable, but will appear in the same place on the screen (under or to the right of the signature). Unlimited T&Cs text can be configured, along with check-boxes and data entry. This may be configured at any time and is expected to be finalised during implementation.

Once the customer signature is confirmed, the application will request entry of the Driver signature. This is similar to the Customer signature except:

The Signatory is defaulted from the configured Driver name and cannot be changed. Note: Agency drivers are in use. They will sign with their own name, although the signatory may display e.g. "AGENCY 1" if general agency users IDs are used.
Terms and Conditions will be different (or not present).

Driver Signature

The process will prompt for photos after completion of the signatures for Deliveries - the application will ensure that at least one photo is taken.

Job Photo

As each job (or group of jobs) is completed, the information is updated back to the system, with all information captured on the device (actual times, quantities, signatures, images, updated email address, etc) updated. The updates are sent whenever the driver has an internet connection, and may be delayed until that time.

The user will be returned to the Job List screen and the completed Job will be removed from the list.

Post-Load

Once all Jobs have been completed, the Load will be marked as completed when the user returns to the Job List screen.

Once complete, the device will attempt to download a new load for the user and/or vehicle. If one has not been provided, the device will confirm this and allow the user to check again or log off the system.

POC/POD/Service Report Documents

Once jobs are complete, the facility exists within CALIDUS ePOD/eServ to produce custom POD and Service Reports. This is accessible through the Administration console, and may also be automatically emailed.

The current POD and Service Report formats have been provided as a sample and have been prototyped as part of this design. The following sections show the prototype formats and a description of what is expected to be on each report.

SCR-335787-10:

POD Note And Service Report Formats.

Note: The information shown here is to aid in mapping the data from the NAV system, and as such may change during this mapping, depending on the fields used in NAV for this data, and the availability of the data.

Note: Where fields on the reports are unclear, these have been identified by the Warning: icon and require confirmation before functional specification stage begins.

POD Note

Sample POD Format

Header:

Header with Logo: Fixed
"DELIVERY NOTE": Fixed based on the job type - for collections, this will say "COLLECTION NOTE".

Deliver To:

The Job or Customer address, including Contact Name and Telephone Number(s)

Order Information:

Sales Person: EPL_SALES_CONTACT
Order Raised: EPL_ORDER_DATE
Your Reference: EPL_CUST_REF
A&E Order Number: EPL_SO_NUMBER
A&E Delivery Number: EPL_JOB_CODE
Customer A/C No: EPL_CUSTOMER_CODE
Delivery Date: EPL_END_ACTUAL_DATE

Product List:

Product Code: EPL_PRODUCT_CODE
Product Description: EPL_DESCRIPTION_LONG
Qty: EPL_PRODUCT_QTY_ACTUAL
Follow: EPL_PRODUCT_QTY_PLANNED - EPL_PRODUCT_QTY_ACTUAL.

Footer:

RECEIVED BY: Will be "RETURNED BY" for collections
Signature: EPL_JOB_SIGNATURE
PRINT NAME: EPL_CUST_SIGNATORY
Time: EPL_END_ACTUAL_TIME
Date: EPL_END_ACTUAL_DATE
RECEIVED BY: Will be "RETURNED BY" for collections
Signature: EPL_ENG_SIGNATURE
PRINT NAME: EPL_USER_NAME of the driver.
Time: EPL_END_ACTUAL_TIME

Page Footer:

"Commercial garden...": Fixed
"9 Craddock Road...": Built from the Site address.

The POD produced will expect to be paginated to accommodate the quantity of products on a single delivery job. It is expected that the format will be able to accommodate at least 27 lines per page. It is expected that all headers and footers will be produced on all subsequent pages.

No images are required to be shown on the POD note, whether they are taken on the device or not.

Note: Collection jobs will produce this format, but will replace the text 'Delivery' (and similar) with the text 'Collection'. If an additional Collection note format is required that exceeds this stated change, additional modifications may be required that may increase the cost of this change, or an additional change may be raised with OBS Logistics for a new POC format.

Service Report

Sample Service Report Format

A single page will be produced per item serviced on the service job.

Header:

Header with Logo: Fixed
"SERVICE REPORT": Fixed
No.: This is a Sales order associated to the service in NAV. This will be populated from EPL_SO_REF ( an optional sales order reference) if present, or EPL_JOB_CODE (the main external NAV reference for the service). The mapping of this data into C-ePOD is dependent on the NAV version being used, and the development of the interface for AEL.

Address/Header 1:

The Job or Customer address, including Telephone Number(s)
Group: Removed - not required.
Pronett Print Needed: Removed - not required.
Permit to work needed: Removed - not required.
Time Started: EPL_ARRIVAL_TIME of the job - same on all pages.
Time Finished: EPL_END_ACTUAL_TIME - same on all pages.
Number of Engineers: As entered in User-defined Fields (UDF) - same on all pages.

Make/Model Information: Different for each service item, entered against the service item.

"Awning": EPL_SERVICE_GROUP
Make: EPL_SYSTEM_TYPE
Length/Projection: As entered in User-defined Fields (UDF). This information may be different per Make/Model.
Serial No: EPL_CODE_1

Service Details:

Drawings/Report Attached: Removed - not required.
Photos Taken: Removed - not required.
Notes/Fault: EPL_DIAGNOSIS_NARRATIVE
Report: As entered in User-defined Fields (UDF).
Parts Used: Entered by user, taken from EPOD_SERVICE_PRODUCT, type "I"
Parts Required: Entered by user, taken from EPOD_SERVICE_PRODUCT, type "R"
- Code: EPL_PRODUCT_CODE
- Description: EPL_DESCRIPTION
- Qty: EPL_QUANTITY

Footer:

"I can confirm..." - From the T&Cs associated to a Service.
Customer's Signature: EPL_JOB_SIGNATURE
Print: EPL_CUST_SIGNATORY
Engineer's Signature: EPL_ENG_SIGNATURE
Print: EPL_USER_NAME of the driver.
Date: EPL_END_ACTUAL_DATE

Data Export

The export of data is configurable in CALIDUS ePOD/eServ and is dependent on the version of NAV implemented.

For the old version (Navision), it is expected that all files (inbound to and outbound from CALIDUS ePOD/eServ) will be transferred using an FTP method.

For the new version (NAV2016), it is expected that all files inbound to CALIDUS ePOD/eServ) will be transferred using the CALIDUS ePOD/eServ Webservices. All files outbound will be pushed to a webservice hosted by NAV2016.

Regardless of NAV version, the content of the files and messages will be in OBS XML format.

When jobs have been completed all the job is updated in the CALIDUS ePOD/eServ server, these jobs are then available for exporting to external systems. This is also true of cancelled jobs. All completed and cancelled Jobs may be transferred to NAV through the standard interface. This is a pushed update, sent at a configurable interval, usually every 5 minutes.

There are no expected changes to the existing export format or methodology. The expected mapping and NAV functionality to control the sending and receiving of messages is not covered in this document. It should be noted however:

Once the job is completed, this will be sent back to the CALIDUS ePOD/eServ server and on to NAV in near-real time, depending on connectivity. These will be processed in NAV.
Exceptions to jobs (i.e. not 100% delivered) should absolutely not automatically update - they must be run through a validation process by a NAV user and accepted.
The processing is a function of NAV. This information will be forwarded to the NAV team to provide information and ensure the mapping is done correctly.
100% completed jobs should automatically complete in NAV.
Functionality related to these updates is absolutely dependent on the version of NAV in use. It is expected that the Navision system in use will not be able to support all these functions, but that these will be supported in NAV2016.

For jobs that have been completed, POD documents and Service Reports may be configured to be sent to the customer. In this case, the jobs that require this would have the email address populated when the job is sent to . As part of the export, any jobs with this email address will be automatically sent with a PDF attachment of the POD report, if configured for this. Multiple recipients may be supported through the use of comma- or semicolon-delimited lists of emails addresses (the exact delimiter is based on the email server defined for the system's use).

Automatic emails may also be sent to a central email address if required. This may be configured at any time.

Further Reporting and Queries

The CALIDUS ePOD/eServ Admin system allows admin users (i.e. non-PDA users) the ability to access loads, jobs and product details, as mentioned previously.

Loads
Jobs
Products

When jobs are being processed, the status of the jobs and loads changes to show progress:

Pending - not yet assigned to a driver.
Assigned - Assigned to a driver, but not yet started. This is highlighted grey.
In Progress - Started by the driver. This is highlighted yellow.
Complete - Complete by the driver - This is highlighted green.
Cancelled - Job cancelled by the driver. This is highlighted red.
Complete (With Amendments) - job completed, but not exactly as planned. This is also highlighted green.

POD/POC reports and full product details can be accessed from this screen.

User activity may also be accessed, to show auditing of messages from the user, for example:

Log on
Vehicle defect checks complete
Load picked up
Job started
Job arrived
Job completed
Load completed
Log off

User Tracking - Activities
User Tracking - Location

Appendix A: Table of SCRs and Ballpark Estimates

SCR#	System	Area	Description	Estimate (Days)	Notes
1	Device	Look and Feel	Create customer-specific style on device.	1.25
2	Device	Telephony	Prevent call and SMS options on device with no telephone.	1.00	⁵
3	Device	Delivery	Mark scanned products as they are scanned instead of removing them.	4.75	³
4	Device	Exception	Require Reason Code when entering Product Comments and Changing Quantity.	1.25
5	All	Services	Allow empty service jobs and creation of service items.	11.00	⁴
6	All	Services	Improve service item process flow and validation.	1.00	⁵
7	All	Services	Information Model change should change the Products and Other Products search screens automatically.	1.00	⁵
8	Device	Services	Allow service reason for visit to be read only.	1.00	⁵
9	Admin	Services	Add Required button to Other Products screen.	2.25
10	Admin	Reports	POD Note And Service Report Formats.	7.25

Notes:

Any high level ballpark estimates for development are based on the basic information provided and are subject to detailed design and creation of an SCR.
Unless noted otherwise, these changes are included in contract.
Optional change at additional cost.
Required change at additional cost.
Product Changes funded by OBS Logistics

Appendix B: Document References

B.1 References

Ref No	Document Title & ID	Version	Date
1	UG 291094 EPOD Admin User Guide	3.0	16/10/2014
2	UG 291097 EPOD Client User Guide	4.0	16/10/2014

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

Kate Byrne	AEL Solutions	_____________________________
Matt Turner	OBS Logistics	_____________________________

Anonymous

Search

REQ 335787 AEL Requirements