FS 332681 EPOD Multiple Images: Difference between revisions

From Calidus HUB
VisualWikitext
(v0.1 - Initial draft.)
 
m (Mino)
Line 544: Line 544:
|Appendix=B
|Appendix=B
|Estimate=Y
|Estimate=Y
|Glossary=WCS
|Glossary=EPOD
|Ref1=Reference1
|Ref1=Reference1
|RefV1=0.1
|RefV1=0.1

Revision as of 17:38, 15 February 2016





Aptean Logo.png







OBS Logistics

EPOD Multiple Images

CALIDUS EPOD

15th February 2016 - 0.1
Reference: FS 332681











































Functional Overview

Client Requirement

Barker & Stonehouse Requirements

Image capture for the following reasons:

  • Digital Image of Full Item Taken
  • Digital Image of Fault Taken
  • Digital Image of Repair Taken
  • Image Of ID Number and ID Number Logged


Manheim Requirements

  • Photos against defect checks against collected/delivered vehicles (containers).


Product Requirement

  • Display multiple photos against jobs/containers/products in Admin
  • Allow Multiple photos to be taken at Exceptions (Job/Container/Product Cancellation and Product Quantity Change) and Job Photo.
  • Allow multiple photos to be taken during Vehicle Checks.
  • Allow multiple photos to be taken during any UDF.
  • Allow UDF at successful collection/delivery of a container, optional or required.
  • Allow UDF at successful collection/delivery of a product, optional or required.
  • Photo comment entry should be optional in some cases.


Solution Overview

The changes required would be as follows:

  • Support multiple photos in the database and the server
  • Add multiple photos to exception processing in the mobile device
  • Add multiple photos to job photo processing on the mobile device
  • Display multiple photos in Admin at Job, Container, Product and Service
  • Display all UDF in Admin for Job, Container and Product
  • Add an ability to take a single photo to a UDF field
  • Add an ability to take multiple photos to the UDF form in general.
  • UDF will be implemented against Containers and Products.
  • UDF will be allowed to be specified as optional entry as a whole. This attribute will be supported only at Container and Product UDF, and can be accessed through the Action menu popup against the Product or Container.
  • The photo process will be amended to support the optional entry of a comment against a photo, to support the following processes:
    • Exception Photo - required comments, as now
    • Job Photo - required comments, as now
    • Photo against UDF item - Photo itself can be optional or required, no comment required.
    • Multiple Ad Hoc Photos against UDF in general - Taking a photo is always optional, comment can be optional or required.

Note Note: It is assumed that no flags (Site or Job Group) are required to control this functionality.


The process for Barker & Stonehouse will be as follows:

The requirement is to take 4 photos:

  • Digital Image of Full Item Taken
  • Digital Image of Fault Taken
  • Digital Image of Repair Taken
  • Image Of ID Number and ID Number Logged

Services already include significant UDF portions at the following stages:

  • Prework (generally site checks)
  • Info (general information about the service item)
  • Postwork (generally service checks)
  • Diagnosis (fixes taken)

Any one of these UDF elements could include a photo item for each of the required photo's specifically, plus an option to take as many Ad Hoc photos in addition to the required items above.


The process for Manheim will be as follows:

Container UDF configuration will be added to the configuration for Manheim, requiring the 6 requested vehicle checks. These checks will allow a single photo to be taken against them (but will not be required to be taken). Additionally, the UDF configured for this will allow the user to take any number of photos in addition to the ones taken against the items.


The following scenarios will also be supported in the following manner:

  • Delivery driver does various collections or deliveries at pallet (container) level. It is necessary for him to take several photos of a pallet if the customer has refused the pallet.
    • The changes to Exception processing when cancelling a container will allow the entry of any number of photos.
  • It is necessary to take multiple photos if the the driver/customer accepts the pallet but wants to take pictures of some defect or successful delivery of the container in situ. There is no need to take a picture on every pallet (container). Comments may be required or not.
    • An optional UDF configuration will be added to the Container process, which allows entry of any number of photos. This will not prompt the driver for the UDF when a container is scanned or marked as delivered - it will only prompt for photos when the driver selects the UDF Option (labelled as per the configuration) on the container Actions pop-up dialogue. The UDF Photos item may be configured to make the photo comments required or optional.
  • Delivery driver does various collections or deliveries at loose product level. It is necessary for him to take multiple photos of a loose product if the customer has refused the loose product.
    • The changes to Exception processing when cancelling or changing the quantity of a product will allow the entry of any number of photos.
  • It is also necessary to take multiple photos if the driver/customer accepts the loose product but wants to take pictures of some defect or successful delivery of the product. There is no need to take a picture on every product. Comments may be required or not.
    • An optional UDF configuration will be added to the Product process, which allows entry of any number of photos. This will not prompt the driver for the UDF when a product is scanned or marked as delivered - it will only prompt for photos when the driver selects the UDF Option (labelled as per the configuration) on the product Actions pop-up dialogue. The UDF Photos item may be configured to make the photo comments required or optional.
  • Delivery driver needs to take multiple photos of a cancelled job.
    • The changes to Exception processing when cancelling a job will allow the entry of any number of photos.
  • Delivery driver wants to take multiple photos per job to capture photos of delivery documentation.
    • The changes to Job Photo processing will allow the entry of any number of photos.
  • Delivery driver has delivered and installed and room full of furniture and wants to take multiple photos per job to capture photos of the installed furniture in situ.
    • The changes to Job Photo processing will allow the entry of any number of photos.
  • Delivery driver delivers an a container/and or loose product and needs to record some additional delivery checks on the item. He needs to record a single photo against an area of the item, but also multiple photos of the item itself.
    • Required UDF configurations will be added to the container and products process. This will require the entry of an Item photo, and also allow entry of any number of additional photos. The driver will always be prompted to enter this information when confirming the container or product as delivered, or when changing the quantity of a product.
  • A service engineer services an item and needs to record some checks on the item. He needs to record a single photo against a area/check of the item, but also multiple photos of the item itself.
    • UDF configuration will be added against the service (at one of the points already supported, most likely Postwork or diagnosis). This will require the entry of an Item photo, and also allow entry of any number of additional photos.
  • A service engineer completes a job with multiple items and needs to record general multiple photos of the completed job.
    • The changes to Job Photo processing will allow the entry of any number of photos.
  • A service engineer completes a risk assessment and needs to record multiple checks on that risk assessment. He needs to record a single photo against a check, but also multiple general photos of the item itself.
    • A UDF configuration will be added against the Prework section of the service. This will require the entry of an Item photo, and also allow entry of any number of additional photos.


Scope

Set-up

Pre-requisites

Menu Structure

Data

Functional Description

Database/DAL

Amend table EPOD_PHOTO

  • Add the following fields:
    • EPL_SITE_ID
    • EPL_IMAGE_TYPE - up to 10 characters - see definition below
    • EPL_KEYVAL_1 - up to 40 characters
    • EPL_KEYVAL_2 - up to 40 characters
    • EPL_KEYVAL_3 - up to 40 characters, allowing null.
    • EPL_KEYVAL_4 - up to 40 characters, allowing null.
    • EPL_KEYVAL_5 - up to 40 characters, allowing null.

Indexes should be added, but the primary key should remain EPL_PHOTO_ID

  • Index 1 - - repeating index
    • EPL_SITE_ID
    • EPL_IMAGE_TYPE - up to 10 characters - see definition below
    • EPL_KEYVAL_1
    • EPL_KEYVAL_2
    • EPL_KEYVAL_3
    • EPL_KEYVAL_4
    • EPL_KEYVAL_5
  • Index 2 - repeating index
    • EPL_SITE_ID
    • EPL_KEYVAL_1
    • EPL_KEYVAL_2
    • EPL_KEYVAL_3
    • EPL_KEYVAL_4
    • EPL_KEYVAL_5


EPL_IMAGE_TYPE may have the following values initially, but should not be restricted:

  • J - Job
  • C - Container
  • P - Product
  • VC - Vehicle Checks
  • S - Service
  • SI - Service Item
  • JU - Job UDF
  • JU1 - Alternate Job UDF
  • JU2 - Alternate Job UDF
  • JU3 - Alternate Job UDF
  • CU - Container UDF
  • PU - Product UDF
  • SPR - Service Item Prework UDF
  • SPO - Service Item Postwork UDF
  • SIU - Service Item Info UDF
  • SDU - Service Item Diagnosis UDF
  • VU - Vehicle Checks UDF


Webservices

The XML structure for the message will be modified from the device as follows: 

<PHOTO_REQUEST ...>
   <EPL_SITE_ID></EPL_SITE_ID>
   <EPL_KEYVAL_1></EPL_KEYVAL_1>
   <EPL_KEYVAL_2></EPL_KEYVAL_2>
   <EPL_KEYVAL_3></EPL_KEYVAL_3>
   <EPL_KEYVAL_4></EPL_KEYVAL_4>
   <EPL_KEYVAL_5></EPL_KEYVAL_5>
   <EPL_PHOTO></EPL_PHOTO>
   <EPL_DESCRIPTION></EPL_DESCRIPTION>
   <EPL_PHOTO_TYPE>J|C|P|S|VC|JU|JU1|JU2|JU3|CU|PU|SIU|SPR|SPO|SDU|VU</EPL_PHOTO_TYPE>
   <EPL_PACKET></EPL_PACKET> - only if message sent in chunks
   <EPL_PACKET_TOTAL></EPL_PACKET_TOTAL> - only if message sent in chunks
   <REQUEST_TIME_DATE></REQUEST_TIME_DATE>
</PHOTO_REQUEST>

Note Note: The fields not used for a specific photo type will not be sent. For example, a Job UDF photo will send:

  • EPL_SITE_ID
  • EPL_JOB_ID in EPL_KEYVAL_1
  • EPL_UDF_ITEM in EPL_KEYVAL_2

The remaining key fields will not be in the XML.

The message processor should be changed to save the items directly into the required fields. Details of how these are populated are in the Mobile Device Webservices section of this document.


Archive Routines

The archive routines will need to be modified to clear down photos in the way that it does now, but linking to them through the new index.

Note Note: UDF images can be cleared down when the item they are associated to is cleared. So, when clearing jobs, all photos associated to that job of all types may be deleted.

Note Note: Vehicle Check images should be cleared when Vehicle Checks are removed.


Admin

To achieve:

  • Add UDF to each screen that requires it.
  • Display multiple photos if created (through a gallery)
  • Display multiple photos against UDF objects
  • UDF config screen changes
  • Vehicle Check config screen changes

Load screen

Add a section to show Load Start/End Metrics against the load. This should be shown when selecting a load from the table. If present, there should be a button to view photos against items that have a photo.

Note Note: This UDF Viewing code can be extremely generic and will be used in multiple places in the Admin system.


Job Screen

Add a section to show Job Details UDF against the job. This should be shown when selecting a job from the table. If present, there should be a button to view photos against items that have a photo.

The existing Images/Photos button against a job title when selecting the job should be modified to select all photos against a job and allow viewing of all of them through a carousel-style selection.

Note Note: This multiple image viewing code can be extremely generic and will be used in multiple places in the Admin system.


Container/Products Screen

Add a section to show Container UDF against the container. This should be shown when selecting a container from the table. If present, there should be a button to view photos against items that have a photo.

The existing Images/Photos button against a container title when selecting the container should be modified to select all photos against a container and allow viewing of all of them through a carousel-style selection.


Add a section to show product UDF against the product. This should be shown when selecting a product from the table. If present, there should be a button to view photos against items that have a photo.

The existing Images/Photos button against a product title when selecting the product should be modified to select all photos against a product and allow viewing of all of them through a carousel-style selection.


Services Screen

All existing sections showing UDF for the services should be modified to allow viewing photos against fields in the UDF. This is for:

  • Prework
  • Service Info
  • Diagnosis
  • Postwork


UDF config screen

The screen will allow specification of an OPTIONAL attribute against the FORM tag. This should default to not being present. This should only be allowed if configuring Container or Product UDF.


The screen will allow the configuration of an Action tag against fields. This will allowed against the following Types:

  • X/X2 - all items within the field will allow a single photo.
  • B/TSC -
  • T/N/A
  • DDL


A new field type "P" will be added. This is for ad hoc photos. The only tags that may be specified against a photo tag are:

  • Action - comment required or not


Vehicle Check config screen

The screen will allow the configuration of an Action tag against questions. This will allowed against the following Types:

  • X/X2 - all items within the field will allow a single photo.
  • B/TSC -
  • T/N/A
  • DDL

A new field type "P" will be added. This is for ad hoc photos. The only tags that may be specified against a photo tag are:

  • Action - comment required or not


Device

All functions that save photos need to now pass the photo type required on that photo. This will be through the use of the new saveImage method against he PhotoBar object.


Database/DAL

Database changes to EPL_PHOTO as in the server.

PDA_PHOTO changes to:

  • add the new fields as per the changes to the Server.
  • save the images with the key values.

The PDA_PHOTO object should be modified to instantiate the object through a passed recordset, to improve efficiency.


A new SelectAllPhotos function will be created to retrieve all photos associated to a job or vehicle checks, based on parameters passed to the function.

For Job photos, this should get photos that match the Site and Job as the first 2 key values, where the photo type is not "VC". All photos should then be sent.

For Vehicle Check photos, this should get photos that match the Site, Vehicle and Date/Time as the key values, where the photo type is "VC".

This procedure should create PDA_PHOTO objects for all of the found records, returning in an array.


Vehicle Checks

The Vehicle Checks function must be changed to support the same level of changes as the new UDF Images functionality. Also, the photos taken in this way must be saved when completing vehicle checks.


PhotoBar

The PhotoBar object in styling.js requires changing to achieve the following:

  • Create a bar for multiple photos
  • Horizontal or vertical layout
  • Comment optional or not
  • Usable within a single line for UDF.

The changes will be as follows:

A new _layout property will be added to the object (defaulting to 'horizontal'), and this will be used to decide whether new photos are added to the right of the first photo ('horizontal'), in-line ('single') or pop-up ('popup').

The Photo Bar will be modified to be part of a containing view.

The horizontal layout will be used by the Job Photo and Exception screens. The first photo object will appear at 60% of the width of the containing view, which will be set as horizontal scrolling.

When a photo is taken, the photo bar will act as now, but will add a second photo view to the containing view. A custom property of the view will be set to count the number of photo objects.

When a photo is deleted, if this is the only photo object (using the new count property above), the photo object will be removed after the normal actions are completed.


The in-line layout will be used by the Ad Hoc Photos field type in UDF and Vehicle Checks. This will be for a multiple photos and will be set to be 100% of the width of the containing view, which will not set to be vertical scrolling. The height of the view should be made shorter, so as to maximise space on UDF. Note: No comments will be allowed for photos taken in in-line view.

When a photo is taken, the photo bar will act as now, but will add a second photo view to the containing view (under the first). A custom property of the view will be set to count the number of photo objects.

When a photo is deleted, if this is the only photo object (using the new count property above), the photo object will be removed after the normal actions are completed.


The Pop-up layout will be used by all field types in UDF and Vehicle Checks except Ad Hoc Photo. This will be for a single photo, displaying only the icon to take a photo with no other contents shown. The view should be the size of the existing Barcode action icon shown in UDF at the moment. There is no scrolling on this view.

When the object is clicked, if this object has no photo, the user should be allowed to take one. When taken, the image should change to the view icon. When clicked, pop-up options should be shown for the photo, allowing the actions that the photo object already allows (i.e. View, Take New Photo, Delete). This is probably most easily achieved through enabling all the other icons that would normally be enabled and visible, growing the containing view to 100% of the form that called it, and changing the photo object to 60% width and 10% of the height of the containing view, positioned at the top and left of the original containing view.

Clicking anywhere on the expanded containing view should reverse this process.

Clicking Delete should reverse this process in addition to the current normal actions, as well as reverting to the Take Photo icon.

Clicking View should reverse this process.


A new _commentRequired property will be added to the object, defaulting to true. If false, the object will not enforce entry of a comment against a photo when validating the photos. This should be automatically disabled for Pop-Up layout.


A new method to the PhotoBar object (saveImages) will be created to save photos, which can be called by the calling screen or process. This process will loop through all photo objects in the photo bar and calling a new method saveImage, which will create the PDA_PHOTO object and update them to the database. Note: This method of saving photos will replace the existing method used in Job Photo and Cancellation.


Creation of UDF and Vehicle Checks

To achieve the following:

  • Photo against all field types and items if requested, required or optional
  • Ad Hoc Photos type to be added
  • Tag to control comments against photos (or new types?)
  • Form Attribute to control whether the UDF is required or optional.


Photos against UDF/Vehicle Check Fields

The Action tag will be supported against all field types.

If set to P (Photo), this will allow photos to be taken against this item.

Fields with Photo Actions will put a PhotoBar object of layout "popup" on the field. This will put a small Photo icon in the designated space on the item.

Clicking this will take a photo through the photo bar.

Clicking after taking a photo will offer a pop-up allowing view, delete or retake options.

Only 1 photo may be taken for pop-up layout.

Comments will automatically not be required for these photos attached to fields.


Saving Photos from UDF objects

Note: This does not apply to Vehicle Checks.

The UDF object (created in style.createUDFields2) will be modified to contains a list of the photo objects created.

The process of getting the results of a UDF object (method getResult) will be modified to save all photos at this time. PDA_PHOTO objects will be created for each photo in the Photos collection and saved.


Ad Hoc Photos

A new UDF item will be supported for type P - photos.

A PhotoBar object will be added of layout 'inline'.

Clicking this will take a photo through the photo bar. When confirmed taken, this will change to a field allowing entry of the comment and with Retake, View and Delete icons. Also, another photo object will be added below this to take another photo.

Validation will check the Action tag against the field - if C, comments are required and must be entered.


UDF Optional

A new OPTIONAL attribute will be added to the UDF FORM tag.

If set, any place that enforces entry of UDF (e.g. Container and Product UDF) will check this first. If optional, this will not be forced to be entered, although it may be entered at any time through the container or product action popup.


Webservices

Currently, when processing the completion of a job (through JobUpdateRequest(s)), the process sends photos associated to the job being processed with ProcessPhotos. This procedure should be changed to retrieve the photos through the Site and Job, using the new function SelectAllPhotos, passing parameters as specified to request all job-level photos. This will pick up all photos from the job, Job UDF, Service UDF, Service Items UDF, Container, Container UDF, Product and Product UDF and return an array of photo objects.

As this will return several photos, this process should loop through the array and call PhotoUploadRequest as now.


Currently when processing the completion of vehicle checks through VehicleCheckRequest, the process sends associated photos by checking an array of photo IDs passed into the procedure.

This procedure will be changed to create the PDA_PHOTO objects in the new method, then send them to the server using the ProcessPhotos procedure changed above.


The PhotoUploadRequest function will also change to build the XML in the new structure, as follows: 

<PHOTO_REQUEST ...>
   <EPL_SITE_ID></EPL_SITE_ID>
   <EPL_KEYVAL_1></EPL_KEYVAL_1>
   <EPL_KEYVAL_2></EPL_KEYVAL_2>
   <EPL_KEYVAL_3></EPL_KEYVAL_3>
   <EPL_KEYVAL_4></EPL_KEYVAL_4>
   <EPL_KEYVAL_5></EPL_KEYVAL_5>
   <EPL_PHOTO></EPL_PHOTO>
   <EPL_DESCRIPTION></EPL_DESCRIPTION>
   <EPL_PHOTO_TYPE>J|C|P|S|VC|JU|JU1|JU2|JU3|CU|PU|SIU|SPR|SPO|SDU|VU</EPL_PHOTO_TYPE>
   <EPL_PACKET></EPL_PACKET> - only if message sent in chunks
   <EPL_PACKET_TOTAL></EPL_PACKET_TOTAL> - only if message sent in chunks
   <REQUEST_TIME_DATE></REQUEST_TIME_DATE>
</PHOTO_REQUEST>

Note Note: The fields not used for a specific photo type will not be sent. For example, a Job UDF photo will send:

  • EPL_SITE_ID
  • EPL_JOB_ID in EPL_KEYVAL_1
  • EPL_UDF_ITEM in EPL_KEYVAL_2

The remaining key fields will not be in the XML.

The key values should be populated as follows:

Photo Type/
Keyval		 J C P S VC
1 EPL_JOB_ID EPL_JOB_ID EPL_JOB_ID EPL_JOB_ID EPL_VEHICLE_ID
2 N/A EPL_CONTAINER_ID EPL_CONTAINER_ID EPL_SERVICE_ID EPL_VC_DATE_TIME
3 N/A N/A EPL_PRODUCT_ID N/A N/A
4 N/A N/A EPL_SEQUENCE N/A N/A
5 N/A N/A N/A N/A N/A
Photo Type/
Keyval		 JU/1/2/3 CU PU SIU/SPR
/SPO/SDU		 VU
1 EPL_JOB_ID EPL_JOB_ID EPL_JOB_ID EPL_JOB_ID EPL_VEHICLE_ID
2 EPL_UDF_ITEM EPL_CONTAINER_ID EPL_CONTAINER_ID EPL_SERVICE_ID EPL_VC_DATE_TIME
3 N/A EPL_UDF_ITEM EPL_PRODUCT_ID EPL_UDF_ITEM EPL_UDF_ITEM
4 N/A N/A EPL_SEQUENCE N/A N/A
5 N/A N/A EPL_UDF_ITEM N/A N/A

Note Note: EPL_SITE_ID and EPL_PHOTO_TYPE will be populated on all records.


Exception

The screen uses the photobar now. This will be amended to add the Horizontal layout to the call, which should result in the photobar allowing multiple photos, due to the development against that object. This should also set the comment to required.


The existing method of saving photos in this screen will change to simply call the savePhotos method of the PhotoBar object.


Job Photo

The screen uses the photobar now. This will be amended to add the Horizontal layout to the call, which should result in the photobar allowing multiple photos, due to the development against that object. This should also set the comment to required.


The existing method of saving photos in this screen will change to simply call the savePhotos method of the PhotoBar object.


Collection/Delivery Processing

A Container UDF Pop-up screen should be created to enter the required UDF. The Container process will be changed to enforce entry of Container UDF before collection/delivery of an item, if the form is not OPTIONAL. This will show the UDF pop-up screen regardless of whether the information has been entered already.

The Container Action pop-up should have a facility to enter the container UDF, with a title taken from the UDF configuration.

Validation against delivery of each container should enforce entry of UDF, or the item may not be marked as complete.

Cancellation of an already-completed container should blank the container UDF.

Completion of an already cancelled container should enforce entry of UDF, as if it was being entered for the first time.


A product UDF Pop-up screen should be created to enter the required UDF. The product process will be changed to enforce entry of product UDF before delivery of an item, if the form is not OPTIONAL. This will show the UDF pop-up screen regardless of whether the information has been entered already.

The Product Action pop-up should have a facility to enter the product UDF, with a title taken from the UDF configuration.

Validation against delivery of each product should enforce entry of UDF, or the item may not be marked as complete.

Cancellation of an already-completed product should blank the product UDF.

Completion of an already cancelled product should enforce entry of UDF, as if it was being entered for the first time.


Appendix A: TEST PLAN

Test Script / Scenario ReferenceEPOD Multiple ImagesCall Number(s): 332681
Test Script / Scenario Descriptiondescription of what is to be achievedPASS / ISSUES / FAIL
Menu AccessWhere on the menus the item can be found 
Pre-requisitesThe prerequisites of the testTested By:
 
Test ObjectiveThe details of what each group of tests is to achieveDate:
 



Step Action Result Remarks P/F
1 Area being tested in this cycle      
  Any notes or prerequisites for the tests following.      
1.01 The actions to follow The expected result    
1.02 The actions to follow The expected result    
1.03 The actions to follow The expected result    


Appendix B: Quote & Document References

Cost Details
Activity Estimate
No. of Days		 No. of Days Rate per Day (£) Cost (£ Exc. VAT)
Requirements 0.00 0.00 0 £0.00
Change Request Evaluation 0.00 0.00 0 £0.00
Functional Specification 6.25 6.25 0 £0.00
Technical Specification 0.00 0.00 0 £0.00
Development 28.25 28.25 0 £0.00
Testing and Release 5.25 5.25 0 £0.00
Implementation 0.00 0.00 0 £0.00
Project Management 2.25 2.25 0 £0.00
 
TOTAL 42.00 42.00   £0.00
Estimate excludes training, release to live and go live support.

B.1 References

Ref NoDocument Title & IDVersionDate
1Reference10.101/01/2011


B.2 Glossary

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


B.3 Authorised By


Murray Middleton
OBS Development Manager		_____________________________
Retrieved from ‘https://calidusassist.adcservices.apteancloud.com/calidus-assist/OBS/index.php?title=FS_332681_EPOD_Multiple_Images&oldid=2853’