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: 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
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.
Amend the following field:
- EPL_DESCRIPTION - unlimited length.
Indexes should be added, but the primary key should remain EPL_PHOTO_ID, which should be autogenerated.
- 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
All existing procedures for EPOD_PHOTO should be modified with the above field changes in mind. Specifically, the EPL_DESCRIPTION parameter for EPL_DESCRIPTION should change to unlimited length, as well as adding all the new fields.
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: 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: 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: 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: 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: The description of the photos can now be extremely long, and the screen layout should be aware of that, with the ability to display the whole description, either immediately or on-demand (rollover).
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 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.
Note: As part of this change, the 40-character restriction of the comment should be removed.
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
The exiting REQUIRED attribute will be checked on the UDF FORM tag.
If this attribute is present, any place that enforces entry of UDF (e.g. Container and Product UDF) will check this first. If this is not set or set to N, this will not be forced to be entered, although it may be entered at any time through the container or product action popup, which should still be present.
So, if UDF is present against the container or product, the Popup action should be added. However, at collection or delivery of the product or container, the process should not force the UDF to be entered, and the blank values should not be saved.
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: 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: 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 Reference | EPOD Multiple Images | Call Number(s): 332681 |
| Test Script / Scenario Description | description of what is to be achieved | PASS / ISSUES / FAIL |
| Menu Access | Where on the menus the item can be found | |
| Pre-requisites | The prerequisites of the test | Tested By:
|
| Test Objective | The details of what each group of tests is to achieve | Date:
|
| 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 No | Document Title & ID | Version | Date |
| 1 | Reference1 | 0.1 | 01/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 | _____________________________ |
