TEST: Difference between revisions

From Calidus HUB
VisualWikitext
mNo edit summary
(#tagtest)
 
(19 intermediate revisions by the same user not shown)
Line 1: Line 1:
<div class="noprint">
= 325145 Device Audit Log Improvements =
{{#vardefine:Client|JGB}}
{{#vardefine:ClientName|JB Global}}
{{#vardefine:System|''CALIDUS'' ePOD}}
{{#vardefine:Doc_Title|Oak Furniture Land Solution Design}}
{{#vardefine:Version|0.5}}
{{#vardefine:Date|17th July 2017}}
{{#vardefine:Reference|344060}}
{{#vardefine:Year|2017}}
</div>
{{Doc_Title
|Client={{#var:ClientName}}
|System={{#var:System}}
|Title={{#var:Doc_Title}}
|Reference=REQ {{#var:Reference}}
|Version={{#var:Version}}
|Date={{#var:Date}}
|Year={{#var:Year}}
}}


<!-- TOC -->
== Requirements ==
<div class="noprint">
* Send the device audit log through a new web service method, rather than through email.
= Introduction  =
* Request that the device send through the audit log by making a setting on the server.
<!-- The introduction will detail the initial requirements supplied by the client -->
* Allow configuration of the audit log:  
This document is the {{#var:Doc_Title}}.
** Per device and default for the system.
 
** What is to be audited (types of audit log messages).
 
** Number of records to store on the audit log.
== Objective  ==
* Admin screen available to OBSL users only, to configure audit logs and request them to be sent (Devices screen).
The primary purpose of this document is to document the requirements gathered from {{#var:ClientName}}, at the following meetings:
* Initial meeting in Swindon - Demo provided with website data.
* Second meeting at Customer reference site (Brett Martin).
* Third meeting - Pre-Sales Workshop with detailed demo
* The document has been amended with feedback from the customer, culminating in a review meeting on 05/07/2017.
 
 
<!-- List all amendments to the requirements here, and reference in final section, e.g. The document also encompasses the follow-up meeting held at X, with Y and Z attending, where the requirements were modified. See the minutes of the meeting referenced as item X in appendix B -->
 
This document has been written in a manner such that it can be approved by non-technical representatives of {{#var:ClientName}} whilst also being of sufficient detail to allow the Functional or Technical Specification phase for this area to begin.
 
 
== Scope and Limitations ==
This document is based on the documentation provided by {{#var:ClientName}}, as well as information gleaned from site visits and workshops with {{#var:ClientName}}.
 
<!-- ANY scope or limitations, bulleted. -->
* The changes will be made in the latest version of the {{#var:System}} system, operating the Android version of the C-ePOD Client application.
* Changes relating to information passed through to {{#var:System}} from external systems (i.e. WMS) 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.
* Modifications are required to the customer systems (WMS) to achieve the functionality described in this document.
* This document specifies changes for Lot Capture. It must be noted that this is ''not'' functionality for Lot Traceability, just the capture of the Lot numbers, to be passed back to the customer's WMS on Radial Deliveries only. None of the OBS systems included in this implementation will display or search for the captured Lot numbers.
* This document specifies Loading and Unloading being performed by warehouse staff, not the drivers. It must be noted that ''CALIDUS'' ePOD is not a replacement for an RF-enabled Warehouse Management/Control system. Existing functionality and creative load building within the customer's systems is being used so that C-ePOD may be used for this purpose, but this is not the primary purpose of the application.
* For Lot traceability, it would normally be expected that this be captured by the WMS and a unique item label produced for that order, identifying the Lot and Product implicitly. An item label has now been provided as part of the process, but this is not linked to the Lot number by the customer's systems.
 
<!-- ANY other systems? e.g. does this link to TTM, WMS, 414, 770, etc? -->
{{ #vardefine: SCR | 0 }}
<!-- NEW PAGE -->
 
= Client Requirements =
Listed below are the proposed processes that will be followed by the operatives using {{#var:System}}. Also shown are the SCRs required for this to be achieved.
 
<!-- Any standard processes should be referenced here and in the references section -->
 
== Operational Overview ==
Established in December 2008, JB Direct is JB Global's in-house delivery company which facilities 95% of deliveries for all of the group's furniture retailers (including Oak Furniture Land).
 
The delivery fleet is made up of 40 7.5 tonne and Luton vans, as well containing 10 articulated lorries which collectively fulfil over 2500 orders every week. With over 95 members of staff, JB Direct covers almost the whole of the UK spanning from Plymouth to Inverness.
 
Deliveries are booked in advance directly with the customer by JB Direct's telephone advisers who will confirm a specific date and a 3 - 4 hour time window for the delivery to take place to ensure maximum convenience for the customer. Delivery is made using a two-man delivery service on all orders using fully trained professional delivery staff, who will contact the customer when they are approximately thirty minutes away to keep the customer fully informed. Additionally, during delivery the drivers will take every item on the order into the property and directly to the requested room of choice by the customer so that all of the heavy lifting is taken care of.
 
 
Main Office Address:
 
JB Global Ltd<br />
DC2<br />
Viscount Way<br />
South Marston Industrial Estate<br />
Swindon<br />
SN3 4TN<br />
 
 
There are 4 main distribution depots:
* Brentwood
* Manchester
* Glasgow
* Swindon
 
 
Contacts:
* Louis Merrett - Project Manager - [email protected]
* Nav Mohammed - Lead Developer working on interface - [email protected]
 
 
OBS Logistics Contacts:
* Barry Preece - Project Manager - [email protected]
* Matt Turner - Sales/Account Manager - [email protected]
* Warren Wright - Sales/''CALIDUS'' VEhub - [email protected]
* Tony Walker - Solution Design - [email protected]
 
 
The core systems for the business are an internally-maintained WMS, utilising PTV DPS for route creation/optimisation, with OBS Logistics' systems as follows:
* ''CALIDUS'' ePOD - execution.
* ''CALIDUS'' VEhub - vehicle checks, accident reports, asset tagging at locations.
* ''CALIDUS'' Portal TTM - transport/order tracking.
 
The operational processes will be:
* Orders are entered into the WMS.
* WMS interfaces the orders to DPS for routing/optimisation.
* When complete, the trips created will be interfaced to C-ePOD.
* ''CALIDUS'' VEhub captures vehicle checks.
* {{#var:System}} executes jobs and captures the actual delivery quantities and signatures.
* Navigation to locations using CoPilot.
* ''CALIDUS'' VEhub used to capture accident reports and/or asset tagging at locations.
* {{#var:System}} updates ''CALIDUS'' Portal's Track and Trace module (TTM) with information for order tracking.
* {{#var:System}} updates WMS with actual quantities and times when jobs are complete or cancelled.
 
 
200 M3 SM10 rugged hand-held Android devices with 1D scanners have been ordered for the operation, along with various accessories. 70 devices are to be held at branches for seasonal peaks. Extra drivers are employed for peak periods.
 
The device supplier will be pre-loading the devices with the mobile applications for C-VEhub, C-ePOD, and CoPilot. JB Global will be ordering the SIM cards for these devices themselves and will install after delivery. Devices will not be delivered with Mobile Device Management software - if this is required, this is expected to be installed by the customer. The C-ePOD application will require configuration to connect to the final Test or Production systems and configure for the site (depot or warehouse) for the device - QR barcodes for Test and Production systems for each Site will be provided to speed this configuration.
 
 
The software will be rolled out as follows:
* ''CALIDUS'' VEhub - Swindon first, then to all depots.
* ''CALIDUS'' ePOD - Swindon first, then to all depots.
* ''CALIDUS'' TTM - configured after C-ePOD go-live at Swindon.
 
The project has a 6-8 week lead time to software delivery, from the point of contract confirmation, which was 26/06/2017.
 
A project plan will be sent to the customer when available, detailing the time-lines of all phases of the project, including the implementation and development phases.
 
 
The operation will expect to execute the following movement types:
* Trunk - unloading only by warehouse staff
* Radial Delivery/Collection
* Loading for Radial Delivery/Collection by warehouse staff
Excluded from C-ePOD execution:
* Supplier drop-shipments into depots
* Collections from suppliers into depots.
However, this is controlled by the loads and jobs sent to C-ePOD from the customer's WMS, so if these transport types are to be controlled through C-ePOD, they can be added through the interface. This solution does not cover these processes, however.
 
 
The customer plans to scan off (unload) consolidated products on trunk deliveries into the depots using C-ePOD. Trunks between depots will not be executed on C-ePOD by the drivers, but will instead by unloaded by warehouse staff in the destination depot. These will be sent on a separate load, under a different Site code (for the warehouse), for execution by the warehouse staff. A unique load will be sent per vehicle per trip. {{Note}} Trunks will ''not'' be loaded by warehouse staff with C-ePOD devices.
 
 
The customer plans to load the delivery items into delivery vehicles at the depot, by means of scanning each job with delivery items (loading) onto the defined vehicle in reverse order. The WMS will send the load for the vehicle through in reverse order to the delivery route, with no jobs consolidated. Loading for radial (delivery/collection) trips will not be executed on C-ePOD by the drivers, but will instead be loaded by warehouse staff in the delivery depot. These will be sent on a separate load, under a different Site code, for execution by the warehouse staff. A unique load will be sent per vehicle per trip and the all the jobs will be present in reverse loading sequence.
 
All warehouse-executed trips (i.e. loading and unloading) will be performed through C-ePOD by warehouse staff on a specific site code for the warehouses associated to the depots. The warehouse staff will have usernames and passwords.
 
 
The customer will user C-ePOD for radial delivery/collection routes, executed by the drivers. The radial (collection/delivery) trip will consist solely of the delivery/collection jobs, and the delivery items required for each job.
 
 
Product is delivered into depots 'drop-shipped' by suppliers directly. These will not be unloaded through C-ePOD.
 
 
== Data Import ==
The integration is being performed by in-house I.T to OBS Logistics' standard XML schema. The interface will use Webservices. The customer has already begun to prototype this import interface.
 
This (and the export interface) requires a mapping exercise with the customer's I.T. team to ensure that the data is being sent as expected and conforming to both the requirements of the implementation and the C-ePOD product.
 
{{SCR|Reference={{#var:Reference}}|SCRNo={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}
|Definition=Interface Mapping
|Link=Appendix A: Table of SCRs and Ballpark Estimates
}}
 
 
In addition, the WMS will also be sending tracking emails (and SMS messages) to the customer using their pre-existing functionality. The link to the ''CALIDUS'' Portal customer tracking gateway will be included in this email. The URL will be built including the reference to the order number, but not the postcode, as in the following example:
    http://[ website ]/Gateway?mod=POR&src=LOTS&sub=tracking&act=find&ref=GS295098"
 
It should be noted that ''CALIDUS'' Portal also includes functionality to achieve this, and may be configured for this at any time.
 
 
The site usually defines the depot, business or the transport group (carrier). It can be set to any value required by the customer. All transactions data (for example, loads and jobs) and standing data (for example, vehicles and uses) belong to a site. A C-ePOD user, on a device or in the Admin screen, can only see data for one site at a time.
 
There will be two Sites per depot in the network:
* One will be for the warehouse operations (i.e. Loading/Unloading trips).
* One will be for the transport operations (i.e. Radial Collection/Delivery trips).
 
The sites contain some configuration that controls how the mobile device operates when completing jobs under these sites.
 
The Warehouse sites will be configured as follows:
* Forced Container and Product Entry disabled.
* Job Arrival disabled.
* Complete jobs out of sequence set to "N - Disabled".
 
The Transport sites will be configured as follows:
* Forced Container and Product Entry disabled.
* Job Arrival enabled.
* Complete jobs out of sequence set to "N - Disabled".
 
 
Loads will be sent to C-ePOD as part of this interface, identifying each unique trip for that vehicle and all the jobs to be completed as part of the load.
 
Trunk unloading jobs will be interfaced on a single load per vehicle per depot, with a single job. The products on this job will be the consolidated values of all the product being trunked. The load will contain at least the following information:
* Site - the destination depot's warehouse
* Load - a unique load reference for the site
* Planned Start and End times.
* Vehicle - the vehicle delivering the load.
 
Radial Collection/Delivery Loading jobs will be interfaced on a single load per vehicle per depot, with all jobs for delivery in reverse delivery sequence. The load will contain at least the following information:
* Site - the loading depot's warehouse
* Load - a unique load reference for the site
* Planned Start and End times.
* Vehicle - the vehicle delivering the load.
 
Radial Collection/Delivery jobs will be interfaced on a single load per vehicle per depot, with all jobs for delivery in delivery sequence. The load will contain at least the following information:
* Site - the delivering/collecting (executing) depot
* Load - a unique load reference for the site
* Planned Start and End times.
* Vehicle - the vehicle delivering the load.
 
{{Note}} The driver executing the load may also be interfaced - this may be applicable for Radial Collection/Delivery loads, but unlikely to be for the warehouse-executed loads (i.e. Loading and Unloading).
 
 
Jobs will be interfaced as part of the loads, indicating the details of the jobs to be complete as part of the loads, and also the sequence on the load.
The details for each job are expected to contain:
* Planned Start (arrival) and End (completion) Date and Time. This is expected to be the recipient's provided delivery window
* Type (Delivery or Collection)
* Order Number (in Job Code)
* Customer Name, Address and Contact information (including email if required)
* Delivery Instructions
 
{{Note}} Loading and Unloading jobs should be interfaced with a loading indicator, for visibility purposes, as follows:
* Loading - Job Type Delivery, Loading Indicator "L".
* Unloading - Job Type Collection, Loading Indicator "U".
 
{{Note}} Sequence must be provided for each job on a load. This is a straight numerical sequence. The values depend on the purpose for the load, as follows:
* Unloading - Set to 1, as there will be only one jobs on the load.
* Loading - set in reverse delivery sequence.
* Radial Delivery/Collection - set in delivery sequence. It is noted that Collection jobs at an address will be sequenced ''before'' the Delivery jobs at that address, for the purpose of emptying out the customer property first.
 
{{Note}} Collections will be interfaced to C-ePOD on the radial trips as separate jobs to any delivery jobs for the same customer. It is noted that the current example POD shows a collection item against a delivery job - this is not expected to be the normal process and must be excluded in the future. Note that these collection jobs will be processed independently, and will require separate processing and signature capture on the mobile device.
 
 
{{Note}} There is a facility to provide an invoice (customer) and delivery (job) address separately in the interface. This is not expected to be required, as it is expected that the customer address will always be the delivery address.
 
 
All jobs will be set with a configuration element known as Job Group - this will define the process to be followed against each job, such as:
* Driver Signature.
* POC/POD document format.
* POC/POD business address and logo.
* Terms and Conditions displayed.
 
These will be agreed as part of the interface meetings. It is expected that there will be job groups as follows:
* Trunk Jobs e.g. "TRUNK" or "UNLOAD"
* Loading Jobs e.g. "LOAD"
* Delivery Jobs e.g. "DEL"
* Collection Jobs e.g. "COL"
 
The Job Group for Radial Deliveries is expected to be configured as follows:
* Customer to sign for goods
* NO Deliver All process
* NO driver signature
* Job Photos (optional)
* Scan at Vehicle (to allow checking, Failed delivery user-defined form entry and final confirmation)
* Pre-Job (Arrival) Terms and Conditions and Signature (optional)
 
The Job Group for Radial Collections is expected to be configured identically to the Radial Delivery jobs. However, this can be changed if desired.
 
The Job Groups for trunk unloading and loading are expected to be configured as follows:
* NO Customer signature
* NO Deliver All process
* NO driver signature
* NO Job Photos
* NO Pre-Job (Arrival) Signature
 
The details of jobs will be interfaced differently depending on the Job Type:
* Trunk Unloading - products will be sent
* Radial Loading and Radial Collection and Delivery - delivery items with unique delivery item IDs (barcoded of delivery labels) will be sent as containers.
 
The products, when sent, will be created on each job created with the details taken from the WMS. The details expected to be received are:
* Product Code - set from the barcode Product ID.
* Description - a truncated version of the description.
* Long Description - the ERP product code (e.g. "OAKMAG001") plus the full description, delimited by a dash.
* The total planned and ordered quantities.
* The Unit volume in Cubic Metres, interfaced in the Item Type (i.e. not total volume).
* The Unit Weight (i.e. not total weight).
{{Note}} OBS Logistics' systems internal product description is 40 in length, whereas the customer's product description appears to be 50 (e.g. "Posture pocket plus supportive 1000 pocket spring". As such, the interface will truncate the description for the standard description field, and include the product code and full description in the long description field.
 
Containers for C-ePOD represent unique delivery items for this operation.
The containers, when sent, will be created on each job created with the details taken from the WMS. The details expected to be received are:
* Container (Item) ID - The delivery label ID
* Package Description - The Product Code (e.g. MAT-PLUS1000MED-SINGLE)
* The Unit volume in Cubic Metres (stored in a CODE_1 field).
* The Unit Weight.
* Description - The full description of the product.
 
Containers (Items) will require Lot capture at Radial Loading and/or Radial Delivery and Collection. The system will be configured for these job types (through the job group) to request the scan of the Lot number after the item is scanned. Note that this Lot capture is configurable per job type and therefore can be changed if required (for example, removed from collections).
 
 
Loads and jobs may be re-sent multiple times - no difference is required in the way that the XML is created. C-ePOD will update the load and the jobs on the load with the new details, provided the load and jobs have not already been completed.
Any jobs not on the re-interfaced load will be deleted. Any products not on the jobs will be deleted.
 
{{Note}} Changes to the items loaded during the processing of executing Radial Loading (i.e. items not loaded) will be reflected back into the WMS from C-ePOD. Note that this should trigger a re-send of the Radial Delivery load at that time to C-ePOD from the WMS, so that the driver is not prompted to deliver items that were never loaded.
 
Loads may be deleted through the interface if no longer desired.
 
 
Certain data is required for configuration of all OBS systems being installed, such as:
* Depots
* Users, including passwords/PINs. In this case this includes:
** Drivers
** Warehouse Operatives (Loaders/Unloaders)
* Vehicles, including Registration, Make and Model
* Trailers (if used)
This information must either be provided in advance or (in the case of C-ePOD) sent to or created as part of the interface to C-ePOD with the Loads and Jobs. The system will be configured to create this standing data from the received import information with basic information. This may then need to be modified (for example, if a new driver is received, it will be created in C-ePOD, but with a default password that should be changed). This will be agreed as part of the interface discussions.
 
 
Users are maintained in C-ePOD at Site level. Therefore there will be different users for the warehousing sites (i.e. loaders/unloaders) as compared to the transport depots (i.e. drivers). Each depot and warehouse will have their own users and passwords.
 
 
== Administration ==
The ''CALIDUS'' ePOD system provides functionality to handle the process of Proof of Delivery electronically. The system aids this process by providing both a management interface (Admin console) and a mobile device application for use in completing jobs, consisting of pick-ups (collections and loading) and drop-offs (deliveries and unloading).
 
The {{#var:System}} Administration console is a web-based application that handles all of the administrative side of the C-ePOD devices.
 
{{Note}} Access to this Admin system is through a web browser, connecting to a provided URL for the system. Access to this URL must be allowed from the Oak Furniture Land network for all users that require it.
 
 
The purpose of the application can be broken down into the following sections:
* To create and maintain users of the ePOD 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 and Vehicles.
* To view the Jobs and Loads created.
* To track progress against the Loads, Jobs, Vehicles and Users.
* To print or email a POD/POC.
 
 
It is assumed that all Loads will be assigned to Vehicles through the WMS import interface.
 
A facility to manually assign Loads to drivers and vehicles is provided for problem-solving purposes.
 
The resource allocation may be managed through the following mechanisms:
* Through the Load, assigning a user directly
* Through the User, selecting from any Pending Load.
 
[[file:REQ_336500_Admin_Users3.png|border|600px]]
[[file:REQ_336500_Admin_Users1.png|border|600px]]
<br />''Assigning a User to Loads''<br />


[[file:REQ_336500_Admin_Load3.png|border|600px]]
[[file:REQ_336500_Admin_Load2.png|border|600px]]
<br />''Assigning Loads to a user''<br />


== Overview of Solution ==
=== Device Audit Log Web Service Method ===
The PDA Audit Log screen will be modified to build a message onto the pending queue, containing all the logged data.


If loads are created without a driver assigned (vehicle will always be assigned through the interface), the driver will be assigned automatically as the driver logs on to the device application and confirms which vehicle they are using.
A new message request will be created for this (AUDIT_LOG).


Structure to be defined, but it is assumed this will follow the structure of the existing XF_AUDIT device table.


A full guide to the use of the system can be found referenced in [[#Appendix A: Table of SCRs and Ballpark Estimates|Appendix A]].
The server PDA web service will be modified to receive this message and save this to a file in a server-side folder. The folder will be defined as a system web configuration parameter. The name to be confirmed, but will likely comprise:
* "AUDIT_LOG_"
* device_id
* date
* time
* ".XML"




== ''CALIDUS'' VEhub ==
=== Request Device Audit Log ===
The ''CALIDUS'' VEhub system will be used in this implementation to:
The EPOD_DEVICE table will be modified to add the following fields:
* Capture Vehicle Checks
* EPD_AUDIT_LOG_REQUESTED_IND - int default 0
* Capture Accident Reports
* EPD_LAST_AUDIT_LOG_REQUESTED_DATE - int default 0
* EPD_LAST_AUDIT_LOG_REQUESTED_TIME - int default 0
* EPD_LAST_AUDIT_LOG_RECEIVED_DATE - int default 0
* EPD_LAST_AUDIT_LOG_RECEIVED_TIME - int default 0
* EPD_LAST_AUDIT_LOG_RECEIVED - nvarchar(100) NULL


{{Note}} ''CALIDUS'' VEhub is already configured for Oak Furniture Land use and is ready to be used. It is likely that this will be rolled out to all depots as soon as possible, with a handover session booked for 05/07/2017. However, note that C-VEhub is not part of this solution design document, and will configured as part of the implementation of this project.
The server PDA web service will be modified to recognise this flag on the following existing web service methods:
* LOGON_REQUEST
* AUTO_UPDATE_REQUEST


Accident reports will be configured after Vehicle Checks have been implemented.
The device will be extracted and, if EPD_AUDIT_LOG_REQUESTED_IND is set to 1, the following additional information will be returned on the message:
* EPD_AUDIT_LOG_REQUESTED_IND - int default 0
* EPD_LAST_AUDIT_LOG_REQUESTED_DATE - int default 0
* EPD_LAST_AUDIT_LOG_REQUESTED_TIME - int default 0


As part of this project, C-VEhub will be created for each depot to access their vehicles and the data entered through the mobile application. C-VEhub Admin access will be provided for every branch.
Structure to be defined, but it is assumed this will follow the structure of the existing EPOD_DEVICE table.


{{Note}} Access to this Admin system is through a web browser, connecting to a provided URL for the system. Access to this URL must be allowed from the Oak Furniture Land network for all users that require it.


The drivers will be provided a user-name and password. The users and their passwords must be configured within C-VEhub. It is recommended that these user-names and passwords match between C-ePOD and C-VEhub.
The device will be modified to check the responses to these messages (including a grace logon) and check the value of the indicator. If the flag is set to 1, the process will check the last requested date and time is different to the last request received. If so, the device will call the same code as the Audit screen i.e. generate a new AUDIT_LOG web service call.


It is expected that the C-VEhub application will be installed for the delivery drivers only - warehouse staff will not require access to this application. However, if this is a task that is performed by the warehouse loaders, this can be provided. This is ''not'' recommended as a reasonable process, however, as the driver is responsible for the safety of the vehicle they will be driving, not the warehouse operatives.


C-VEhub will be configured to send email alerts of every defective vehicle check completed to the defined email addresses for each depot, certainly for user-acceptance testing. This may also be configured when the product moves live.
The server PDA web service AUDIT_LOG method will be modified to extract the device from the message and update the following fields:
* EPD_AUDIT_LOG_REQUESTED_IND - set to 0
* EPD_LAST_AUDIT_LOG_RECEIVED_DATE - set to sysdate
* EPD_LAST_AUDIT_LOG_RECEIVED_TIME - set to systime
* EPD_LAST_AUDIT_LOG_RECEIVED - set to the name of the audit log file created.




== C-ePOD Mobile Device Application ==
=== Device Audit Log Configuration ===
The mobile device application will be used to execute the following types of loads executed by the depot drivers, namely:
{{Note}} This supersedes the Audit Logging configuration on the device.
* Radial Deliveries and Customer Collections


Additionally, this will be used by the warehouse staff to execute the following processes:
The EPOD_DEVICE table will be modified to add the following fields:
* Trunk unloading
* EPD_AUDIT_LOGGING_IND - int, default 0
* Radial Loading
* EPD_AUDIT_LOG_TYPES - nvarchar(MAX) -
The below sections detail the flow of the radial deliveries predominantly, then indicate how these processes will be used to execute other types.
* EPD_AUDIT_LOG_LIMIT - int, default 2000


Defaults for the system will be set to be:
* EPD_AUDIT_LOGGING_IND - 0
* EPD_AUDIT_LOG_TYPES - "{}"
* EPD_AUDIT_LOG_LIMIT - 2000


Note that full details of the use of each process on the mobile device are not included in this solution design, but can be obtained from the user guide, referenced in this document's appendices.
The server PDA web service will be modified for the LOGON_REQUEST method to return the content of the EPD_DEVICE table for the device.




== C-ePOD Mobile Device Login ==
The device will be modified to check the LOGON_RESPONSE message and store the devices flags. The value of EPD_AUDIT_LOG_TYPES will be stored as a JSON object or as a delimited list of areas.  
The application will have a customised style created for Oak Furniture Land, which will include:
* Oak Furniture Land logo at login stage.
* Job List as standard (showing the Job reference, type (collection/delivery), customer name, planned date and time and post code)
* Removal of the ''Has this Delivery been checked'' check box on the Job Details screen.
* Container (Delivery Item) list including Delivery Item ID, Product Code, full description, volume and weight.
* Any reference to "Container" changed to "Item" (i.e. on all labels, pop-up messages and alerts).
* Product list including Product Barcode ID, Product Code, full description, volume and quantity.
* Blank customer signatory at the Customer signature stage.
 
 
{{SCR|Reference={{#var:Reference}}|SCRNo={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}
|Definition=Custom Oak Furniture Mobile Device Styling
|Link=Appendix A: Table of SCRs and Ballpark Estimates
}}
 
The details of the specific styling will be shown in each section following.
 
 
<gallery widths=200px heights=320px perrow=3>
File:REQ_344060_PDA_Login1.png|''Log In''
</gallery><br />
 
The drivers will be provided a user-name and password, and the loads will be allocated to specific vehicles, ensuring that they can complete only the loads required. The users and their passwords must be configured within {{#var:System}}. {{Note}} User IDs that are created automatically as part of the Standing Data creation at Load Import will be available for use, but will have a default password created. This password should be modified before use as a security precaution. It is expected that the user-name and password will be the same for the drivers across ''CALIDUS'' VEhub and ''CALIDUS'' ePOD.
 
 
A driver will log on to a device using the provided user name, password and vehicle. The device will remember the last used User name and Vehicle, but will always require that the password is entered.
 
{{Note}} Vehicle checks will be completed through the ''CALIDUS'' VEhub application and are not integrated into {{#var:System}}. ''CALIDUS'' VEhub is not within the scope of this document. There will be no vehicle checks implemented within ''CALIDUS'' ePOD for Oak Furniture Land processes.
 
 
== Obtain Workload/Job List==
When log on is 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 (and/or vehicle), the device will tell the user that there is no work available. The driver can exit, or try to download again.
 
 
<gallery widths=200px heights=320px perrow=3>
File:REQ_344060_PDA_JobList1.png|''Job List''
</gallery><br />
 
 
The layout of the job list as demonstrated is acceptable to the customer, with one modification. The time will not be displayed on the Job List, through configuration of the style on the device. The defined elements are:
* The order number (Job Code)
* The job type (Collection, Delivery, Loading, Unloading)
* The location (address name)
* The planned start date and time
* The post code from the location
 
The screen will display the status of the jobs on the load through a coloured outline or background, 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 by the driver. It is expected that this will be strongly sequenced by the data imported into C-ePOD, and that the following will be the case:
* For Radial Collection/Delivery loads, the jobs will be sequenced in the order they should be completed. Collections will be displayed separately from the delivery jobs, and expected to be before the delivery job on the Job List. These collection jobs will be processed independently, and will require separate processing and signature capture.
* For Loading loads, the jobs will be sequenced in reverse delivery sequence. All jobs will be Loading jobs.
* For Unloading loads, there will only be one job for all the product to be unloaded.
 
The jobs can be viewed in any sequence by clicking the line of the job - the device will display the Job Details page.
 
The '''Menu''' button can be used here to allow the following options:
*    Refresh Load - Refresh the Load/Worklist from the server, to pick up any updates
*    Show All / Outstanding Jobs - Toggle between showing all or only incomplete jobs.
*    Log Out
*    Change Vehicle
*    Cancel Jobs
There are also some bug-reporting options available on this pop-up menu, which may be asked to be used from time to time by the OBSL or client support staff.
 
 
The system can be configured to control allowing the drivers' ability to complete jobs out of sequence, as follows:
* No re-sequencing of jobs  - this is not allowed by the driver - the jobs must be completed in the order planned, or cancelled if they cannot be completed (see the following for details on cancellation for the business units).
* Confirm re-sequencing allowed - this requests the user to confirm first.
* Always allowed - no confirmation.
It is expected that re-sequencing of jobs will ''not'' be allowed.
 
 
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 if, for example, if quantities have been amended, products added, etc.
 
 
Long-pressing against the line will display some options from a pop-up menu:
* ''Details'' - show the Job Details screen (following).
* ''Cancel'' - the selected job or jobs will be cancelled. The application will display an Exception screen and prompt for entry of a reason code indicating why this job was cancelled.
 
 
== Job Details ==
Selecting a job from the Job List will show the user the job report and customer contact details, on the Job Details screen. The user can back out of the selected Job and view any Job on the list.
 
<gallery widths=200px heights=320px perrow=3>
File:REQ_344060_PDA_JobDetail1.png|''Address & Contact''
File:REQ_344060_PDA_JobDetail2.png|''Instructions''
</gallery><br />
 
The screen has several sections and tabs, showing:
*    The Job Type (Collection, Delivery, Loading, Unloading)
*    The customer details (Customer Code, Name, Address and Postcode)
*    The contact information (Contact name and number)
*    The planned collection/delivery window for the job, including the start and end times.
*    The Instructions for the job
Clicking on the tabs will display the information.
 
The ''Instructions'' tab will show instructions for the job, as well as any additional information passed through for the job.
 
 
{{Note}} The screen allows the driver to contact the customer (through either text or phone) - the application will display appropriate icons to allow the drivers to accomplish this.
 
 
=== 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 Job Cancellation is enabled, it is expected that the application will ''not'' be configured to require a photo, although one can still be taken if required.
 
If a job is confirmed cancelled, the device will show the Job List again with the cancelled job removed from the list.
 
 
== Navigation and Arriving ==
The driver will select '''Start Job''' from the Job Details screen.
 
{{Note}} 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.
 
{{Note}} It is expected that re-sequencing of jobs will ''not'' be allowed for Oak Furniture Land. If a job is attempted to be started, arrived or delivered out of sequence, the user will be told this at this point and will not be allowed to continue.
 
Once started, the device will display a navigation button. Clicking this will start navigation through the installed navigation app. The application will show whatever app is installed on the device to handle navigation, or the Google Maps website if there is none. The app will immediately calculate a route to the destination address.
 
For this implementation, ALK CoPilot navigation is expected to be installed on the mobile devices and will be used for navigation. Note that the functionality regarding navigation is controlled entirely by this application, separate to the ''CALIDUS'' ePOD application - please consult the CoPilot documentation for details as to how this operates and how it may be configured.
 
 
Once arrived at the destination, the driver will switch back to the {{#var:System}} mobile application. For standard Android devices, the app switcher can be used to switch back to the C-ePOD mobile application.
 
The driver will then indicate arrival and start processing the Job by clicking the '''Arrive Job''' button.
 
 
When clicking the button to start, arrive at or deliver the job, the application performs a check whether the job has been changed since it was loaded on the device, to ensure that the latest data is on the device for the job. If there are changes, the driver will be informed and the screen will refresh.
 
The device will move on to the Delivery or Collection process, depending on the job type.
 
 
== Radial Delivery Process ==
The driver process at a delivery point is:
* Arrive at site (recording time of arrival).
* Pre-Job (i.e. post-arrival) Terms and Conditions and Signature (Difficult Delivery Disclaimer) if required.
* Positively confirm delivery of delivery items through scanning of item barcodes.
* Capturing of lot numbers.
* Complete delivery (recording time off site) and capture signature and signatory.
 
 
When the driver has confirmed arrival, the device will display a pre-job signature and disclaimer.
<gallery widths=200px heights=320px perrow=3>
File:REQ_344060_PDA_PreJobSign1.png|''Confirm Pre-job Signature required''
File:REQ_344060_PDA_PreJobSign2.png|''Difficult Delivery Disclaimer''
</gallery><br />
 
This will configured to be optional, so the driver can skip this if not required.
 
The device will then move on to the delivery of the delivery items.
 
 
Radial Deliveries will consist of multiple containers (delivery items).
 
The following are the standard tabs that are expected to be displayed:
<gallery widths=200px heights=320px perrow=3>
File:REQ_344060_PDA_Delivery1.png|''Job Details Tab''
File:REQ_344060_PDA_Delivery2.png|''Job Details Tab - Addresses''
File:REQ_344060_PDA_Delivery3.png|''Containers Tab''
File:REQ_344060_PDA_Delivery4.png|''Notes Tab''
</gallery><br />
 
 
The ''Job Details'' tab has multiple sections:
* Contact information
* Address information - if supplied, both current address and origin address are shown.
* Job Instructions
 
As part of the styling changes, the check-box "Has this delivery been checked?" will be removed from the screen, and "Containers" will be changed to "Items" wherever it is used in the application. Additionally, any reference to "Container" in the app will be changed to "Item" (i.e. on all labels, pop-up messages and alerts).
 
 
Data must be captured against a job if any items have been cancelled, namely:
* Have the delivery team tried to get the item to the room of their choice?
* Is it likely that the item will fit unpacked?
* Is there another solution that we can identify?
* Is the customer aware of the reason this cannot be delivered?
* Reason for Failure
* Return #
* Card #
 
The 4 Y/N questions on the Failed Delivery Check List will be drop-down lists of "Y" and "N", with default values. The Reason for Failure will be a drop-down list of user-defined codes without a default value, that must be selected. The Return and Card Numbers will be required entry.
 
This required data will be configured against as a User-Defined Form (UDF) against the Job Groups that require it (i.e. Collection and Delivery jobs). This will be present on this ''Job Details'' tab for the user to enter.
 
 
From the ''Items'' tab, the device will show a list of the items to be delivered, which will be styled to show only the following elements:
* Delivery Item (Container) ID.
* Product Code
* Full description.
* Volume
* Weight
 
Actions against the items can be activated by long-pressing against the row, and have the following actions:
* ''Deliver''
* ''Deliver Claused''
* ''Cancel''
* ''Info''
* ''Lot Number''
<gallery widths=200px heights=320px perrow=3>
File:REQ_344060_PDA_Delivery5.png|''Container Long-press Pop-up''
File:REQ_344060_PDA_Delivery6.png|''Container Info Pop-up''
</gallery><br />
 
For information on the actions above, see the appropriate following sections.
 
 
When all items 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 items delivered and change this if required. The list will display a border and status to indicate whether the items 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.
 
 
The system will be modified so that the information is only enforced to be captured if the job is marked as amended (i.e. some products have had short delivery). In this case, once all items are confirmed as delivered, the Delivery process will return to the Job Details tab, where a '''Complete''' button will be present to confirm all as delivered. The Failed Delivery Check List items will be seen on this screen.
 
If '''Complete''' is pressed, and the job is amended, the driver will be instructed that the information must be entered. If the job is not amended, the driver will be allowed to skip entry of this information.
 
{{SCR|Reference={{#var:Reference}}|SCRNo={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}
|Definition=Job UDF Required dependent on Job Amended
|Link=Appendix A: Table of SCRs and Ballpark Estimates
}}
 
{{Note}} The Failed delivery check-list will not include photos - if a delivery has any cancelled items, it may still be delivered and a signature captured. This process will then allow the driver to take Job Photos, which can be used to capture any images associated to the failed delivery items.
 
<gallery widths=200px heights=320px perrow=3>
File:REQ_344060_PDA_Delivery9.png|''Failed Delivery Check List and Complete''
</gallery><br />
 
If all the items were fully delivered, or the Failed Delivery information has been fully entered, when the driver clicks  the '''Complete''' button, this screen will close and the user will be directed to the Job Completion process.
 
 
=== Delivering an Item ===
Each deliverable item will be labelled with an Item Label with a barcode in CODE-128 format of a unique numeric item ID.
 
Each item on the list can be confirmed as delivered by either:
* selecting the item from the list and selecting ''Deliver''
* entering the Item ID manually and clicking the '''Deliver''' button.
* scanning the Item ID, using the application '''Scan''' button and camera scanning feature, or using a connected or integral hardware scanner.
If items are entered that are not part of this delivery, the application will issue an error and will not deliver the item.
 
If any user-defined fields are required to be entered against the delivered items, the application will prompt for this information at this stage. If required, the information must be entered before the item is marked as delivered.
 
 
There is a requirement to capture the Lot number portion of the barcode scan and pass this back to the WMS.
 
Additionally, in the instance of a failed scan (container or Lot), the customer would like a facility to take a photo.
 
Both of these requirements will be achieved through configuration of a Container user-defined form (UDF) against the items. This will allow the user, after scanning the Item ID, to enter the Lot number and potentially a photo.
 
<gallery widths=200px heights=320px perrow=3>
File:REQ_344060_PDA_Delivery10.png|''Lot Number Entry''
</gallery><br />
 
This will be prompted as "Lot Number" on the form. The driver will scan the Product Barcode in this field. The form will store the lot extracted from the barcode scanned (with validation).  
 
The product barcode is in GS1 format, and contains:
* 91 - Agreed between suppliers - in this case this is confirmed to be the numeric Product ID, representative of the product code. This is up to 30 characters, but will predominantly be 4 numeric characters.
* 10 - Batch or Lot Number. This is up to 20 characters, but will predominantly be 5 numeric characters.
 
The photo will be present, labelled as "Missing Barcode" and allow as many photos as the driver requires.
 
Both of these items will be optional entry by the driver, and may be skipped.
 
The application will require changes to this UDF functionality for the following purposes:
* Recognise GS1 (UCC/EAN-128) barcodes
* Extract the correct AI (Application Identifier) for the Lot number from the barcode scanned
 
{{SCR|Reference={{#var:Reference}}|SCRNo={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}
|Definition=Container UDF Barcode Extraction Changes
|Link=Appendix A: Table of SCRs and Ballpark Estimates
}}
 
The driver can select to start this UDF page at any time against any Item by pressing the item in the list and selecting ''Lot Number'
 
 
When marked as delivered, the item will be removed from the list.
 
 
== Cancelling an Item ==
If an item cannot be delivered, it can be removed from the list with the pop-up option ''Cancel''. The exception screen will be shown where the driver can enter the reason for the cancellation.
 
<gallery widths=200px heights=320px perrow=3>
File:REQ_344060_PDA_Delivery7.png|''Container Cancellation''
</gallery><br />
 
For clarification, details about the item being cancelled are displayed here.
 
A reason code must be entered by the user for an item to be cancelled.
 
The application will be ''not'' configured so that the driver is required to take a picture associated with this cancellation, but one may be taken if desired, using the provided photo button.
 
 
== Clausing an Item ==
If an item is delivered but customer or user notes are to be captured against the Delivery, it can be delivered from the list with the pop-up option ''Deliver Claused''. Again, the exception screen will be shown where the driver can enter the reason or notes for the claused Delivery.
 
<gallery widths=200px heights=320px perrow=3>
File:REQ_344060_PDA_Delivery8.png|''Container Clausing''
</gallery><br />
 
For clarification, details about the item being cancelled are displayed here.
 
The application can be configured to require:
* Clause reason codes
* Clause comments
 
The application will be ''not'' configured so that the driver is required to take a picture associated with this clausing, but one may be taken if desired, using the provided photo button.
 
 
== Job Completion ==
All jobs will be sent to the {{#var:System}} 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.
 
The device will prompt for Customer Signature for Radial Collections and Deliveries, and for Desk Collections.
<gallery widths=200px heights=320px perrow=3>
File:REQ_344060_PDA_Signature1.png|''Customer Signature and T&Cs''
File:REQ_344060_PDA_Signature2.png|''Customer Signature and Containers''
</gallery><br />
 
The signatory will by configuration be set to be blank and always required entry. 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.
* The quantity of containers being collected/delivered.
 
 
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. These are currently expected to be:
* SIGN TO ACKNOWLEDGE RECEIPT OF GOODS AND NO DAMAGE TO PROPERTY
 
 
If the customer is not in, but the items can still be delivered, the delivery will be completed as normal and the driver will sign PP on behalf of the customer.
 
The list of items delivered will be displayed, allowing the driver to click on each for more information and to allow clause notes and reason codes to be entered, if required.
<gallery widths=200px heights=320px perrow=3>
File:REQ_344060_PDA_Signature3.png|''Item Information and Clausing''
</gallery><br />
 
 
{{Note}} The application can be configured to require driver signature, although this is not expected in this implementation.
 
After signature completion, the mobile device is expected to prompt for photos. This is to capture any images associated with completed or failed deliveries. This photo capture process is expected to be initially configured to be optional, but can be removed or made required.
 
The driver will be able to take as many photos as required, view the captured image or re-take the photos.
 
<gallery widths=200px heights=320px perrow=3>
File:REQ_344060_PDA_JobPhoto1.png|''Job Photo''
</gallery><br />
 
 
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, etc) updated. The updates are sent whenever the driver has a viable data 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. Any completed jobs can be optionally viewed again, by pressing the Menu button and choosing ''Show All Jobs''. The list can be made to show only outstanding jobs again by pressing the Menu button and choosing ''Show Outstanding Jobs''.
 
 
== Post-Load ==
Once all Jobs have been completed, the Load will be marked as completed when the user returns to the Job List screen.
 
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, re-login or log off the system.
 
 
==Radial Collection (Returns) Process==
It is expected that, where planned returns of products are created, these collections will be interfaced to {{#var:system}} as separate Collection jobs and present on the Radial Delivery/Collection loads.
 
The collection process will be almost identical to the Radial Delivery process described above, substituting Collection instead of Delivery. So:
 
The collection will be on the Job List with the radial deliveries, as a separate job, requiring separate confirmation and signature.
 
The driver will start and arrive the job as above.
 
The driver will be prompted to obtain pre-job signatures if required.
 
The collection will follow the same Item barcode scanning process.
 
The driver will have been provided a number of unique collection Item labels at the start of the trip by the warehouse. As the driver collects the products, the driver will apply a collection label and scan it.
 
The application will then prompt for the lot number and potentially photos, in identical fashion to the Delivery process. Again, both of these are optional and may be skipped.
 
The driver can cancel or clause collect in the same way as described in the Radial Delivery process.
 
 
When all items have been confirmed as collected or cancelled, the Collection process will close and the user will be directed to the Job Completion process, which will configured as:
* Customer to sign for the collection. The screen will display the items collected.
* Job Photo will be prompted for but optional.
 
 
== Trunk Unloading Process ==
The trunk unloading loads will be sent to a different (warehouse) site, and assigned to a vehicle.
 
The warehouse operative will sign on to the device, and enter their user and password, identifying the vehicle to be unloaded.
 
The load will be displayed, but in this case there will be only one job, as all product on the vehicle is consolidated onto one load.
 
The user will select the job and will immediately start it - there is no prompt for arrival. Any instructions will be forced to be viewed.
 
 
Trunk Unloading jobs will consist of multiple loose products.
 
The following are the standard tabs that are expected to be displayed:
<gallery widths=200px heights=320px perrow=3>
File:REQ_344060_PDA_Unloading1.png|''Job Details Tab''
File:REQ_344060_PDA_Unloading2.png|''Job Details Tab - Addresses''
File:REQ_344060_PDA_Unloading3.png|''Products Tab''
</gallery><br />
 
 
The ''Job Details'' tab will display as before, but without the failed delivery check-list.
 
 
From the ''Products'' tab, the device will show a list of the products to be delivered, which will be styled to show only the following elements:
*    Product Barcode ID.
*    Product Code and full description.
*    Volume (stored in the Item Type)
*    The planned quantity.
 
Actions against the products can be activated by long-pressing against the row, and have the following actions:
* ''Deliver X''
* ''Change Quantity''
* ''Cancel''
* ''Info''
<gallery widths=200px heights=320px perrow=3>
File:REQ_344060_PDA_Unloading5.png|''Products Long-press Pop-up''
File:REQ_344060_PDA_Unloading6.png|''Product Info Pop-up''
</gallery><br />
 
{{Note}} The system will be configured so that the user may not confirm a line without scanning it. The functions above are for error-correction and should not be used in place of scanning barcodes for the product.
 
 
For information on the actions above, see the appropriate following sections.
 
 
When all products have been confirmed as unloaded or cancelled, the Unloading 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 unloaded and change this if required. The list will display a border and status to indicate whether the products have been unloaded:
* Red - Cancelled
* Amber - Unloaded with an amendment (changed quantity)
* Green - Unloaded in full.
The status and the Planned and Actual quantity will be displayed for confirmation.
 
 
If all the products were fully unloaded without exception, when the driver clicks  the '''Complete''' button, this screen will close and the user will be directed to the Job Completion process, which will not request any signatures or photos, but will instead complete the job and the load.
 
The user can then log out and log in again as a different vehicle to process the next Trunk unloading.
 
 
=== Unloading a Product ===
The standard mechanism of confirmation of the quantity of a product received will be modified for this customer. This will be configurable, and will be expected to be configured for Trunk Unloading only.
 
The unloading of product will be configured so that the driver cannot confirm the quantity by just pressing on the row on the screen - the product code must be scanned or manually entered. This is through existing configuration in the system.
 
A physical hardware scanner (part of the device) or the built-in application scanner (using the camera) may be used to scan the product barcode.
 
The product barcode is in GS1 format, and contains:
* 91 - Agreed between suppliers - in this case this is confirmed to be the numeric Product ID, representative of the product code. This is up to 30 characters, but will predominantly be 4 numeric characters.
* 10 - Batch or Lot Number. This is up to 20 characters, but will predominantly be 5 numeric characters.
 
The application will be modified to be configured to recognise and extract the GS1 data elements from the barcode scan.
 
The Product ID will be used to identify the product line on the product list. The quantity unloaded will be increased by 1.
 
As each item's barcode is scanned, the quantity will be incremented, until the actually unloaded quantity equals the planned amount, at which point the product will be considered to be fully unloaded and the product will be removed from the product list.
 
It is not required that each product is fully scanned before moving to the next, although this is recommended - the driver can scan items from multiple products mixed together, and each line will be incremented by 1 each time they scan the barcode.
 
{{SCR|Reference={{#var:Reference}}|SCRNo={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}
|Definition=Product Quantity Countdown
|Link=Appendix A: Table of SCRs and Ballpark Estimates
}}
 
When all quantity of product that can be found for the job have been scanned, there may be a shortage on some lines. In this case, the driver will use the Change Quantity process (below) to confirm the shortage and enter a reason code.
 
 
=== Changing a Product Quantity ===
The driver can change the quantity by choosing ''Change Quantity'' from the pop-up menu, accessed by long-pressing on the product line - 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.
 
<gallery widths=200px heights=320px perrow=3>
File:REQ_344060_PDA_Unloading7.png|''Exception - Change Product Quantity''
</gallery><br />
 
For clarification, the product code and description and the job and customer are also displayed here.
 
The application will be ''not'' configured so that the driver is required to 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 unloaded and will be removed from the product list.
 
{{Note}} As part of the Product Quantity Countdown change above, the quantity will be defaulted to the amount currently scanned, and will not be allowed to be increased, although it may be decreased.
 
 
=== Cancelling a Product ===
Where a product is not on the vehicle, the driver process will be to cancel the product with the pop-up option ''Cancel'', accessed by long-pressing on the product line.
 
As with quantity change, 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.
 
The application will ''not'' be configured so that the driver is required to take a picture associated with cancellation of products.
 
<!--
=== Commenting a Product ===
This option will call the exception screen to allow the user to enter any comments against this product and optionally take a photo.
 
<gallery widths=200px heights=320px perrow=3>
File:REQ_344060_PDA_Unloading8.png|''Exception - Commenting on a product''
</gallery><br />
 
{{Note}} Reason codes are the operation's to maintain and will be maintained only within C-ePOD.
-->
 
 
== Radial Loading Process ==
The radial loading loads will be sent to a different (warehouse) site, and assigned to a vehicle.
 
The warehouse operative will sign on to the device, and enter their user and password, identifying the vehicle to be loaded.
 
The load will be displayed. There will be multiple jobs on this list, displayed in reverse delivery sequence.
 
The user will select the first job and will immediately start it - there is no prompt for arrival. Any instructions will be forced to be viewed.
 
{{Note}} The user will not be allowed to load the jobs out of sequence.
 
The Radial Loading process will be by Delivery Item (Container) ID, and is functionally identical to the Radial Delivery process, with the only difference being that the device will display "Collection" or "Loading" instead of "Delivery" (and similar words).
 
When the job is complete, the mobile device will not prompt for any signatures or photos. Instead, the process will return to the job list after confirmation that all product is loaded. Note that this configuration can be changed at any time, but is expected to be this way for initial implementation.
 
When the job is complete, the user will continue loading all jobs in the same manner.
 
{{Note}} Changes to quantity at loading will be reflected back into the WMS from C-ePOD. Note that this should trigger a change of quantity onto C-ePOD for the radial delivery load.
 
When all jobs are complete, the entire workload will also be complete. There will be no more work for this vehicle. The warehouse user can then re-login from the prompt, selecting the next vehicle to load.
 
 
== POC/POD Documents ==
Once jobs are completed, then will be confirmed with the C-ePOD server. After this confirmation, a POD/POC report may be produced.
 
All photos taken by the driver during the execution of the job (i.e. at cancellation of product, change quantity of product, job photos) will be displayed in the C-ePOD Admin system for the administrative users to view, but will not be included in the PDF version of the document (generally the version emailed to customers).
 
 
The format attached to the job group is the format that will be produced from the Admin console and displayed for customers when requested through ''CALIDUS'' Portal.
 
 
=== Oak Furniture Land POD/POC ===
The different job types will require different completion reports, although they will look very similar:
* Radial Deliveries - summing the delivery items into product lines, on a POD report.
* Radial Collections - using the POD report above, but displaying Collection instead of Delivery.
* Radial Loading - using the POD report above.
* Trunk Unloading - displaying the product lines themselves, on a POC report.
 
 
The format of the POD note has been prototyped to show capability. The format has been provided and the prototype is shown below:
 
[[file:REQ_344060_POD1.png|border|600px]]
<br />''Prototype Oak Furniture Land POD Format''<br />
 
 
{{SCR|Reference={{#var:Reference}}|SCRNo={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}
|Definition=Oak Furniture Land POD/POC Formats
|Link=Appendix A: Table of SCRs and Ballpark Estimates
}}
 
 
{{Note}} The definition of what data maps to which fields on the POD depends on the mapping of the interface of jobs into {{#var:system}}.
 
 
Page Header, expected to be displayed on every page:
* Company Logo - It is expected that this will be the logo taken from the site.
* "JB DIRECT DELIVERY NOTE" - fixed text, displaying "Collection Note" if the job is a collection.
* "0800 440 2254" - taken from the telephone of the site's address.
 
* DATE - The planned start date, in YYYY-MM-DD format.
* TIME - The planned start and end times, delimited by a dash, in HH:MM format.
* TYPE - The Job Type
* ORDER NUM # - The Job Code
* CUSTOMER/ADDRESS/POSTCODE/TEL1/2/3 - from the job address if present, otherwise the customer address.
* "DELIVERY INSTRUCTIONS" - Fixed text, displaying "COLLECTION INSTRUCTIONS" if the job is a collection. The job instructions are displayed beneath this.
* Failed Delivery checks (1) - taken from user-defined fields against the job.
* DATE - The actual end date, when the signature was obtained.
* TIME - The actual end time, when the signature was obtained.
* PRINT NAME - The signatory, captured by the driver on the device when the customer signs.
* SIGNATURE - the customer's signature.
 
 
Product Details, expected to be shown on every page, expected to show up to 15 products per page. {{Note}} This may need to be reduced to account for the digital nature of the signatures on the POD/POC report):
* QTY - The actual quantity of the product delivered, as confirmed by the driver.
* PRODUCT - the product code and full description, as held in the Long Description field in C-ePOD.
* Kg - the unit weight of the product, multiplied by the delivered quantity.
{{Note}} PCS and CBM columns have been agreed to be present but not populated from this table.
<!--* CBM - the unit volume, as held in the Item type against the product, multiplied by the delivered quantity.
A total line will be displayed, summing the Volume and Weight columns.-->
A total line will be displayed, summing the Weight column.
{{Note}} The POD report will require a modification to this format to group the delivery items by the product code and sum the values.
 
 
Footer, expected to be shown on all pages:
* "SIGN TO ACKNOWLEDGE..." - T&Cs from the completed job, expected to be "SIGN TO ACKNOWLEDGE RECEIPT OF GOODS AND NO DAMAGE TO PROPERTY".
* DATE - The actual end date, when the signature was obtained.
* TIME - The actual end time, when the signature was obtained.
* PRINT NAME - The signatory, captured by the driver on the device when the customer signs.
* SIGNATURE - the customer's signature.
 
* DIFFICULT DELIVERY DISCLAIMER and all text and signature - Taken from the post-job signature and T&Cs. {{Note}} If they are not present (i.e. they were not captured by the driver) then this section will not be present.
 
* Failed Delivery checks (2) - taken from user-defined fields against the job. Consisting of:
** REASON FOR FAILURE
** RETURN #
** CARD #. {{Note}} The TIME and DOOR COLOR will be removed, as it is expected that this will be made redundant through the process of Job Photos if required.
 
 
It has been agreed to keep this format as close as possible to the existing format used by the operation. However, due to the size of digital signatures, some restructuring of the report has taken place in the prototype to accommodate this. These changes must be reviewed and agreed.
 
 
== Data Export ==
When jobs are completed (cancelled or confirmed as delivered, with or without shortages), C-ePOD will be configured to push the updates in OBS XML format to a webservice hosted by the WMS. This will require development by the in-house I.T. staff.
 
This will contains all of the information from the job provided to C-ePOD, and all the captured information from the execution of the job, including (but not limited to):
* Actual dates and times
* Failed Delivery information
* Captured Lot numbers
* Delivered product quantities
* Signatory and Signatures
* Terms & Conditions agreed to
 
C-ePOD will also be configured to email the completed POD or POC to the customer's email address, if provided on the job.
 
However, these automatic emails or exports may be configured or changed at any time.
 
 
== Further Reporting and Queries ==
The {{#var:System}} Admin system allows admin users (i.e. non-PDA users) the ability to access loads, jobs and product details, as mentioned previously.
 
<gallery widths=600px heights=300px perrow=1>
File:REQ_336500_Admin_Load2.png|''Loads''
File:REQ_336500_Admin_Job1.png|''Jobs''
File:REQ_336500_Admin_Containers1.png|''Containers/Products''
</gallery><br />
 
 
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 blue.
 
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
* Load picked up
* Job started
* Job arrived
* Job completed
* Load completed
* Log off
 
<gallery widths=600px heights=300px perrow=1>
File:REQ_336500_Admin_UserTracking1.png|''User Tracking - Activities''
File:REQ_336500_Admin_UserTracking2.png|''User Tracking - Location''
</gallery><br />
 
 
== Track and Trace ==
''CALIDUS'' Portal provides several enquiry and auto-updating screens to allow information to be collated and provided in easy to use formats. The system supports multiple  user-defined groups that control the configuration of a user, allowing the control of data access for various different purposes, for example:
* End customers, tracking their delivery
* Customer Service Queries
* Transport Office
 
 
''CALIDUS'' Portal is kept updated at all times by {{#var:System}} of all states of the loads and jobs, for example:
* The Trip itself.
* The Order itself.
* The sequence of the Order on the Trip
* When an order is in transit.
* When an order is collected and/or delivered.
* When an order is cancelled.
The messages identify any changes to quantities and reasons for these changes at all stages.
 
It is expected that ETAs will be shown on the Portal (except for the Customer Tracking Gateway) - this functionality requires the purchase of a Nokia Maps account. As the system is hosted through OBS, this cost may be part of the hosting agreement.
 
The Portal system will be styled for Oak Furniture Land, specifically the Customer Tracking Gateway screen.
 
{{SCR|Reference={{#var:Reference}}|SCRNo={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}
|Definition=Custom Oak Furniture Land Portal Styling
|Link=Appendix A: Table of SCRs and Ballpark Estimates
}}
 
The core C-Portal TTM module and screens will be used - labels and layout will be configured standard configuration tools through an implementation session immediately following the first site C-ePOD go-live.
 
 
The following is a brief description of functionality available within ''CALIDUS'' Portal that has potential to be used by Oak Furniture Land and their customers if required. This is by no means a full list of all functionality available within ''CALIDUS'' Portal - the user guide (referenced in the Appendices of this document) contains the full details of the available functionality.
 
 
=== Trip/Order Enquiry ===
This screen allows ''CALIDUS'' Portal users to track the status and events held against trips and orders, selecting them through a large variety of parameters.
 
 
==== Order Enquiry ====
[[file:REQ_339867_TTM_OrdEnqParms.png|border|600px]]
<br />''Order Enquiry Parameters''<br />
 
[[file:REQ_339867_TTM_GenEnqParms.png|border]]
<br />''General Enquiry Parameters''<br />
 
 
The enquiry responds with a results table summarising the matched orders:
 
[[file:REQ_339867_TTM_OrdEnqResults1.png|border|600px]]
<br />''Order Enquiry Results''<br />
These results can be expanded for further details of the Trip Stops, and the order can be clicked to drill-down into specific details of the order.
 
This table data can also be exported to XML format in multiple ways:
* '''Manifest''' - Trip/Stop information
* '''Manifest/Order''' - Trip/Stop/Order information
* '''Order''' - Order Header information
* '''Order Detail''' - Order Header / Order Detail information
* '''Order Events''' - Order Header / Event information
 
 
==== Trip Enquiry ====
[[file:REQ_339867_TTM_TripEnqParms.png|border]]
<br />''Trip Enquiry Parameters''<br />
 
[[file:REQ_339867_TTM_TripEnqResults.png|border|600px]]
<br />''Trip Enquiry Results''<br />
These results can be expanded for further details of the Orders, and the order can be clicked to drill-down into specific details of the order.
 
This table data can also be exported to XML format in multiple ways:
* '''Manifest''' - Trip/Stop information
* '''Manifest/Order''' - Trip/Stop/Order information
* '''Order''' - Order Header information
* '''Order Detail''' - Order Header / Order Detail information
 
The screen supports configurable RAG colouration, to highlight trips that are late or incomplete, and ETAs.
 
 
==== Order Details ====
[[file:REQ_339867_TTM_OrderDetail1.png|border|600px]]
<br />''Order Details''<br />
 
Details can be found of the following:
* '''Events''' - the Messages received by the LOTS system via WMS, TMS and other systems.
* '''Info''' - Details of all of the header information stored on the system
* '''Route''' - Details of the trips/stops that the order is currently assigned to.
* '''SO Details''' - the Stock details received from the TMS or WMS.
* '''Reasons''' - Details of the Order level reasons placed against the order.
* '''Map''' - A map of the current location of the order (if co-ordinates have been supplied by an external system). The Mapping page will only be available to groups where the 'Mapping' parameter against the User Group is set to 'Available' and where licensing is available.
* '''Notes''' - Allows the entry of user notes against the order. These are only kept on the Portal system.
* '''Documents'' - Allows the upload/view of documents held in the Portal against the order.
 
[[file:REQ_339867_TTM_OrderDetail2.png|border|600px]]
<br />''Order Event Details''<br />
[[file:REQ_339867_TTM_OrderDetail3.png|border|600px]]
<br />''Order Info Details''<br />
 
 
=== Arrivals/Departures (Order Status) Screen ===
''CALIDUS'' Portal supports several Airport-style screens:
* Arrive/Depart screen
* Order Status screen
Both screens allow for customised parameter entry, and refreshing data at intervals, making them ideal for overhead displays or continuous transport queries. The recommended screen is the Order Status screen.
 
[[file:REQ_339867_TTM_OrderStatus1.png|border|600px]]
<br />''Order Status Screen''<br />
 
The screen allows the user to drill-down or expand on data to get more details, through pop-ups or further details screens.
 
The C-Portal TTM module's Order Status screen can be configured to determine the window for delivery in a +/- number of minutes before the delivery end time. This is accessible from the burger menu on the screen.
 
[[file:REQ_339867_TTM_OrderStatus2.png|border]]
<br />''Order Status Parameters''<br />
 
 
=== Customer (Order) Visibility Screen ===
This screen represents a combination of all the screens above in one place, to simplify access.
 
[[file:REQ_339867_TTM_OrderVis1.png|border|600px]]
<br />''Order Visibility Parameters and results''<br />
 
Similar selection criteria to the Trip/Order Enquiries and Order Status screens can be accessed from the left-hand panel. Results will be shown on the right.
 
When an order is selected, the Order Details page is displayed.
 
[[file:REQ_339867_TTM_OrderVis2.png|border|600px]]
<br />''Order Visibility Details''<br />
 
 
Clicking on each of the icons on the top of the page displays similar information to the other enquiry results screens. This screen also allows the user to maintain CRM-related notes and events.
 
[[file:REQ_339867_TTM_OrderVis3.png|border|600px]]
<br />''Order Visibility CRM Details''<br />
 
 
=== Customer Tracking Gateway ===
On clicking the tracking link from an external system or email, the customer is asked to enter the consignment reference (the customer reference) they have been provided and the post code for the delivery location of the order being checked. Note that the consignment number can be sent through from the calling system, to help the customer obtain their details but post code must always be entered by the customer as a security measure.
 
[[file:REQ_324746_TTM_Gateway_Login.PNG|border|600px]]
<br />''Enter Consignment''<br />
 
The gateway then checks the order on the system, matching the customer reference and post code to the information on the system. The search for the order to be checked is not case-sensitive - the gateway will match the entry if entered in upper or lower case, and the postcode entered can be in any format, with or without spacing. If an order is not found that matches the information entered, the screen will display that no information can be found in a pop-up message.


If a unique order is found, the gateway displays a summary of the information on the order being checked, similar to the following:
{{Note}} This list of all areas is defined as a list of all calls to logAudit or funLogMessage in the mobile device application.


[[file:REQ_324746_TTM_Gateway_Tracking.PNG|border|600px]]
The device will store the log indicator and limit (EPD_AUDIT_LOGGING_IND and EPD_AUDIT_LOG_LIMIT) as new global variables or system properties.
<br />''Consignment Tracking''<br />


The device audit logging process (XF_AUDIT) will be modified to use the limit (EPD_AUDIT_LOG_LIMIT) instead of the fixed limit (2000). If the limit has changed, all messages will be removed from the table.


{{Note}} Only information from the order being checked is displayed on this screen, as well as some information relating to times and execution of the Trip on which this order is being delivered. At no time is any information from any other order (on this trip or otherwise) displayed on this screen.
The device logging process will be modified to check whether the area exists in EPD_AUDIT_LOG_TYPES. If so, and audit logging is enabled (EPD_AUDIT_LOGGING_IND = 1), the device will write the debug message to the audit log.




The screen displays:
=== Devices Maintenance Screen ===
* The Order Status of the order being checked, which may be one of several items, based on how the systems are being used:
The EPOD_DEVICE table will be modified to add the following fields:
** Ordered.
* EPD_NAME - nvarchar(50)
** Out for Delivery.
** Delivered.
** Cancelled
* Last Delivery Sequence - The number of the last stop serviced on the trip that is delivering the order being checked. {{Note}} This is only the stop number, not the full address of the last stop serviced.
* Your Delivery Sequence - The stop on which the order being checked will be delivered. {{Note}} This is only the stop number, not the full order address - this is displayed below.
* Order Reference - The customer's order reference of the order being checked.
* Full Address - The full delivery address of the order being checked.
* Courier - If known, the courier completing the delivery of the order being checked.
* Driver - The full name of the driver completing the trip on which the order being checked is being delivered.


The screen also displays a time-line bar, showing all the statuses the order being checked has passed though. Successfully-completed statuses are coloured green, and the date/time the status was changed (if provided) is displayed under the status on the bar.
EPOD_LISTS and EPOD_LIST_ITEMS records will be created with all logging areas.


{{Note}} This list of all areas is defined as a list of all calls to logAudit or funLogMessage in the mobile device application.


If the order being checked is out for delivery, the screen displays a map showing:
* The last known location of the vehicle making the delivery.
* The customers delivery location
{{Note}} The last known location of the vehicle making the delivery could be the address of another customer receiving a delivery on that trip. However, no address information or labels are shown against the locations displayed in the map and no information is divulged regarding the reason the vehicle is currently at that location.


A new Devices screen will be created to maintain the device table, including the new logging functionality.


If provided to ''CALIDUS'' Portal, this screen can also display the ETA at the location of the order being checked. As part of the implementation, this ETA will be removed from the screen, as requested.
This screen is available to OBSL users only, to configure audit logs and request them to be sent. This screen will not be added to any menus.


This will be created as a new MVC screen. This requires the existing EPOD_DEVICE and EPOD_DEVICE_TYPE DAL classes to be converted to the new models.


If provided to ''CALIDUS'' Portal, this screen can also display the Signatory and Signature on this gateway screen, when the order being checked is marked as Delivered.
The screen will allow work similarly to existing screens, for finding and editing data.  


[[file:REQ_324746_TTM_Gateway_Signature.PNG|border|600px]]
New devices cannot be created from this screen.
<br />''Gateway - Consignment Signature''<br />


The screen will allow searching for devices using the following criteria:
* ''Device ID'' - text box with fuzzy match.
* ''Device Name'' - text box with fuzzy match.
* ''Date Type'' selector, one of:
** ''Last Used''.
** ''Audit Requested''.
** ''Audit Received''.
* ''Date Range'' - a date range from/to, defaulting to the last week.
* ''User'' - textbox.
* ''Site'' - textbox, defaulting to the logged-on site.
* ''Audit Logging'' - a checkbox, defaulting to unchecked.


<!-- MEDIA LANDCSAPE YES -->
The results will be displayed in a jQuery datatable-enabled gridview.
= Appendix A: Table of SCRs and Ballpark Estimates  =
<!-- If there's only one system being discussed here, the system column can be removed.
Ballpark estimates may not be required to be included in this document. If they are, include the column, and note 1. Estimates should be rounded up, and should be produced using the standard mechanism of estimates (i.e. any standard spreadsheet designed to automate the production of estimates). The total line need only be added if the estimates are being produced at this point
The description should be the description from the text in the main sections.
The Notes column can be used for many things: grouping optional changes, showing whether the client or OBS originated the gap, etc. -->


{{ #vardefine: SCR | 0 }}
The columns will be:
{{REQ_SCR_Header}}{{REQ_SCR_Line
* ''Device ID''.
|SCR={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}|System=EPOD|Area=Integration|Description=Interface Mapping|Estimate=2|Notes=2
* ''Device Name''.
}} {{REQ_SCR_Line
* ''Last Used'' (Date/Time).
|SCR={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}|System=EPOD|Area=Device|Description=Custom Oak Furniture Mobile Device Styling |Estimate=1|Notes=2
* ''User''.
}} {{REQ_SCR_Line
* ''Site''.
|SCR={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}|System=EPOD|Area=Device|Description=Job UDF Dependent on Job Amended|Estimate=2.5|Notes=2
}} {{REQ_SCR_Line
|SCR={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}|System=EPOD|Area=Device|Description=Container UDF Barcode Extraction Changes|Estimate=6|Notes=2
}} {{REQ_SCR_Line
|SCR={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}|System=EPOD|Area=Device|Description=Product Quantity Countdown|Estimate=6.5|Notes=2
}} {{REQ_SCR_Line
|SCR={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}|System=EPOD|Area=Reports|Description=Oak Furniture Land POD/POC Format |Estimate=6|Notes=2
}} {{REQ_SCR_Line
|SCR={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}|System=PORTAL|Area=TTM|Description=Custom Oak Furniture Land Portal Styling|Estimate=2|Notes=2
}} {{REQ_SCR_Footer}}


Clicking on a row will display the actions:
* '''Show Audit Logs''' - optional, allowing showing all logs associated to that device ID. This requires opening a folder on the IIS web server for browsing, like the PDAUpdates folder on the server.
* '''Select'''.


Notes:
Pressing '''Select''' shows the details of the device:
# 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.
* ''Device ID'' - read only
# These changes will be delivered as part of the contracted delivery at no additional cost.
* ''Device Name'' - textbox.
<!-- # These changes will be developed as part of the product improvement program internally at OBS Logistics and will be made available when complete. -->
* ''Last Used Date/Time'' - read only
* ''User'' - read only
* ''Site'' - read only
* ''Audit Logging'' section:
** ''Last Requested Date/Time'' - read only
** ''Last Received Date/Time'' - read only
** ''Last Audit Log'' - read only
** ''Enable Audit Logging'' - checkbox.
** ''Audit Log Types'' - a multi-select list. This is disabled if audit logging is disabled. This list will be populated from EPOD_LIST_ITEMS for the requisite list.
** '''Request Audit Log''' button - clicking this button enables the EPD_AUDIT_LOG_REQUESTED_IND field. This button is disabled if the indicator is already 1. This button is disabled if audit logging is disabled on the device.




<!-- MEDIA LANDSCAPE NO -->
A '''Save''' and '''Cancel''' button will also be provided.
{{Doc_Appendix
|Appendix=B
|Estimate=N
|Glossary=EPOD2
|Ref1=[http://172.198.45.54/calidus-assist/EPOD/index.php/UG_291094_EPOD_Admin_User_Guide UG 291094 EPOD Admin User Guide]
|RefV1=4.0
|RefDate1=21/07/2016
|Ref2=[http://172.198.45.54/calidus-assist/EPOD/index.php/UG_291097_EPOD_Client_User_Guide UG 291097 EPOD Client User Guide]
|RefV2=5.0
|RefDate2=23/12/2016
|Ref3=[[FS 291096 Interface with CALIDUS ePOD]]
|RefV3=1.1
|RefDate3=11/01/2017
|Ref4=Portal User Guide - TTM
|RefV4=6.9.20
|RefDate4=14/12/2016
|REQ=0
|EST=0
|FS=0
|TS=0
|DEV=0
|ST=0
|IMP=0
|Client=
|Year=
|FSEST=Y
|Rev1=Louis Merrett
|Rev1Title=Oak Furniture Land Representative
|Rev2=Matt Turner
|Rev2Title=OBS Logistics Representative
}}</div>

Latest revision as of 17:13, 25 April 2019

325145 Device Audit Log Improvements

Requirements

  • Send the device audit log through a new web service method, rather than through email.
  • Request that the device send through the audit log by making a setting on the server.
  • Allow configuration of the audit log:
    • Per device and default for the system.
    • What is to be audited (types of audit log messages).
    • Number of records to store on the audit log.
  • Admin screen available to OBSL users only, to configure audit logs and request them to be sent (Devices screen).


Overview of Solution

Device Audit Log Web Service Method

The PDA Audit Log screen will be modified to build a message onto the pending queue, containing all the logged data.

A new message request will be created for this (AUDIT_LOG).

Structure to be defined, but it is assumed this will follow the structure of the existing XF_AUDIT device table.

The server PDA web service will be modified to receive this message and save this to a file in a server-side folder. The folder will be defined as a system web configuration parameter. The name to be confirmed, but will likely comprise:

  • "AUDIT_LOG_"
  • device_id
  • date
  • time
  • ".XML"


Request Device Audit Log

The EPOD_DEVICE table will be modified to add the following fields:

  • EPD_AUDIT_LOG_REQUESTED_IND - int default 0
  • EPD_LAST_AUDIT_LOG_REQUESTED_DATE - int default 0
  • EPD_LAST_AUDIT_LOG_REQUESTED_TIME - int default 0
  • EPD_LAST_AUDIT_LOG_RECEIVED_DATE - int default 0
  • EPD_LAST_AUDIT_LOG_RECEIVED_TIME - int default 0
  • EPD_LAST_AUDIT_LOG_RECEIVED - nvarchar(100) NULL

The server PDA web service will be modified to recognise this flag on the following existing web service methods:

  • LOGON_REQUEST
  • AUTO_UPDATE_REQUEST

The device will be extracted and, if EPD_AUDIT_LOG_REQUESTED_IND is set to 1, the following additional information will be returned on the message:

  • EPD_AUDIT_LOG_REQUESTED_IND - int default 0
  • EPD_LAST_AUDIT_LOG_REQUESTED_DATE - int default 0
  • EPD_LAST_AUDIT_LOG_REQUESTED_TIME - int default 0

Structure to be defined, but it is assumed this will follow the structure of the existing EPOD_DEVICE table.


The device will be modified to check the responses to these messages (including a grace logon) and check the value of the indicator. If the flag is set to 1, the process will check the last requested date and time is different to the last request received. If so, the device will call the same code as the Audit screen i.e. generate a new AUDIT_LOG web service call.


The server PDA web service AUDIT_LOG method will be modified to extract the device from the message and update the following fields:

  • EPD_AUDIT_LOG_REQUESTED_IND - set to 0
  • EPD_LAST_AUDIT_LOG_RECEIVED_DATE - set to sysdate
  • EPD_LAST_AUDIT_LOG_RECEIVED_TIME - set to systime
  • EPD_LAST_AUDIT_LOG_RECEIVED - set to the name of the audit log file created.


Device Audit Log Configuration

Note Note: This supersedes the Audit Logging configuration on the device.

The EPOD_DEVICE table will be modified to add the following fields:

  • EPD_AUDIT_LOGGING_IND - int, default 0
  • EPD_AUDIT_LOG_TYPES - nvarchar(MAX) -
  • EPD_AUDIT_LOG_LIMIT - int, default 2000

Defaults for the system will be set to be:

  • EPD_AUDIT_LOGGING_IND - 0
  • EPD_AUDIT_LOG_TYPES - "{}"
  • EPD_AUDIT_LOG_LIMIT - 2000

The server PDA web service will be modified for the LOGON_REQUEST method to return the content of the EPD_DEVICE table for the device.


The device will be modified to check the LOGON_RESPONSE message and store the devices flags. The value of EPD_AUDIT_LOG_TYPES will be stored as a JSON object or as a delimited list of areas.

Note Note: This list of all areas is defined as a list of all calls to logAudit or funLogMessage in the mobile device application.

The device will store the log indicator and limit (EPD_AUDIT_LOGGING_IND and EPD_AUDIT_LOG_LIMIT) as new global variables or system properties.

The device audit logging process (XF_AUDIT) will be modified to use the limit (EPD_AUDIT_LOG_LIMIT) instead of the fixed limit (2000). If the limit has changed, all messages will be removed from the table.

The device logging process will be modified to check whether the area exists in EPD_AUDIT_LOG_TYPES. If so, and audit logging is enabled (EPD_AUDIT_LOGGING_IND = 1), the device will write the debug message to the audit log.


Devices Maintenance Screen

The EPOD_DEVICE table will be modified to add the following fields:

  • EPD_NAME - nvarchar(50)

EPOD_LISTS and EPOD_LIST_ITEMS records will be created with all logging areas.

Note Note: This list of all areas is defined as a list of all calls to logAudit or funLogMessage in the mobile device application.


A new Devices screen will be created to maintain the device table, including the new logging functionality.

This screen is available to OBSL users only, to configure audit logs and request them to be sent. This screen will not be added to any menus.

This will be created as a new MVC screen. This requires the existing EPOD_DEVICE and EPOD_DEVICE_TYPE DAL classes to be converted to the new models.

The screen will allow work similarly to existing screens, for finding and editing data.

New devices cannot be created from this screen.

The screen will allow searching for devices using the following criteria:

  • Device ID - text box with fuzzy match.
  • Device Name - text box with fuzzy match.
  • Date Type selector, one of:
    • Last Used.
    • Audit Requested.
    • Audit Received.
  • Date Range - a date range from/to, defaulting to the last week.
  • User - textbox.
  • Site - textbox, defaulting to the logged-on site.
  • Audit Logging - a checkbox, defaulting to unchecked.

The results will be displayed in a jQuery datatable-enabled gridview.

The columns will be:

  • Device ID.
  • Device Name.
  • Last Used (Date/Time).
  • User.
  • Site.

Clicking on a row will display the actions:

  • Show Audit Logs - optional, allowing showing all logs associated to that device ID. This requires opening a folder on the IIS web server for browsing, like the PDAUpdates folder on the server.
  • Select.

Pressing Select shows the details of the device:

  • Device ID - read only
  • Device Name - textbox.
  • Last Used Date/Time - read only
  • User - read only
  • Site - read only
  • Audit Logging section:
    • Last Requested Date/Time - read only
    • Last Received Date/Time - read only
    • Last Audit Log - read only
    • Enable Audit Logging - checkbox.
    • Audit Log Types - a multi-select list. This is disabled if audit logging is disabled. This list will be populated from EPOD_LIST_ITEMS for the requisite list.
    • Request Audit Log button - clicking this button enables the EPD_AUDIT_LOG_REQUESTED_IND field. This button is disabled if the indicator is already 1. This button is disabled if audit logging is disabled on the device.


A Save and Cancel button will also be provided.

Retrieved from ‘https://calidusassist.adcservices.apteancloud.com/calidus-assist/OBS/index.php?title=TEST&oldid=7320’