REQ 312998 ePOD Requirements
Lomas Distribution
ePOD Requirements
CALIDUS ePOD
19th November 2013 - 0.1
Reference: REQ 312998
Contents
- 1 Introduction
- 2 Client Requirements
- 3 Appendix A: Table of SCRs
- 4 Appendix C: Document References
Introduction
This document is the ePOD Requirements document.
Objective
The primary purpose of this document is to document the requirements gathered from Lomas Distribution during the sales process, and to present an overview of the process that will be followed in and the work required to the CALIDUS ePOD system.
This document has been written in a manner such that it can be approved by non-technical representatives of Lomas Distribution 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 the OBS Logistics Sales team, as well as information gathered at further meetings, specifically at the Lomas site on 12/11/2013.
- The changes will be made in the latest version of the CALIDUS ePOD system.
- The changes have been specified with the Android PDA client in mind.
- This document covers the processes and change requirements to CALIDUS ePOD only - it does not cover the functionality or changes to any other system or application, such as CALIDUS TMS or CALIDUS TTM. This functionality is specified elsewhere.
Client Requirements
Overview
Lomas has up to 50 customers (owners), of which 10 are large contracts, the largest of which is Tarmac/Lafarge. This is one business now, but is seen as 2 contracts within Lomas. Other owners include:
- Violia
- Hanson
- Orgian
- Castle Environmental
- Hope
The business has been active for approximately 20 years, and grown in size from year 1 of 5 vehicles to the current size.
There are several sides of the business:
- Tipper
- Tanker (trailer)
- Disaster Recovery
Resources
The resources are mostly articulated (tractor/trailer):
- 300 trailers
- 215 cabs
- several fixed rigid tippers
- several disaster recovery dedicated vehicles
- 220-250 drivers, all employed by the company.
Each component of the business predominantly keep their own resources (i.e. drivers) due to their skill-sets.
Only 50-100 trailers can be stored at the main Buxton site - there are 4 other storage depots (Car Parks) in Buxton that hold the majority, as well as hubs in the north and London.
Geography
Lomas operates in the UK and UK Islands, Eire and Northern Europe.
There are around 50 supplier collection points across all customers, around 10 of which are quarries for Tarmac.
There are around 1300 delivery points.
Products
Each owner can collect different product types. For example:
- Tarmac:
- Lime
- Cement
- Aggregates
- Hanson:
- Sulphate
- Lime
- Incinerates
Each product type will have their own processes regarding which processes are to be followed.
Products generally come in 3 types:
- Powder
- Liquid
- Aggregate
These can be categorised as follows:
- Bag
- Bulk
- Container
The categories define the resource type associated to the collection/delivery. For example, aggregate can only be picked up by a tipper.
Tarmac collect 8 different bulk product types, 15 different finished product types.
Bulk products can have a UOM associated with them, expected to be Kilo, but could also be Tonne, Litre, etc.
Products are varieties of:
- Ash
- Sand
- Cement
- Lime
- Tyres
- Rubber
- General Waste
- Paper Waste
Jobs and Process
There are approximately 1500 orders per day, or 3000 jobs (collect from point A, deliver to point B).
Typically jobs from different owners are not mixed on the same load.
90% of jobs are loaded onto vehicles the night before, and have been fully planned. The remaining 10% are planned later, with the majority before the trips start, but there are always late-planned jobs of some description. This situation is resolved by getting a user to start a trip but continuing the planning and allocating jobs after the trip has started, and updating the driver whilst in the field. This situation is especially true when tramping (travelling loads over a week or more rather than a day).
The majority of orders are planned as direct deliveries. The processing of each job depends on many factors:
- Location
- Owner
- Product
Environmentally Hazardous and recycling product is collected. In this case, specific documentation is required to legally dispose of the product.
Depending on the type of work being completed and the customer and location, a weight will be captured by a weighbridge, generating a unique weighbridge number with it. This could be on a collection, a delivery or both, depending on the owner, job type and/or location.
Currently the weighbridge process is as follows:
For a collection:
- Driver swipes on arrival
- Tare weight is captured on the way in
- Collect product and signatures as required.
- Driver swipes on departure from the collection point.
- Gross weight is captured.
- A receipt is produced.
- The Weighbridge system exports all the weights captured for the day, collated hourly, via flat file.
Note: This is only for Tarmac.
Inbound Loads are required to be processed. This requires bulk product to be stored at the depot, and then split into multiple deliveries.
Split Loads are required to be processed. In summary:
- Product is collected as normal.
- If the customer agrees to the cost of redelivery on a subsequent day, the driver does not deliver the load and returns this to the hub.
- The product is then planned onto other trips (potentially broken down to several deliveries).
The processing of these Split Loads is similar to inbound orders above.
The operation requires an ability to track Trailers, both by ID and location. This then requires Trailer ID entry.
- Trailer IDs will not be planned onto whole Trips, or individual Jobs on Trips. This is especially true of tramping loads.
- It is the function of the depot guards and the drivers to allocate Trailers appropriately.
- Trailer Type is matched to the Product Type being collected/delivered - a trailer of a specific type must not be used for unsuitable product.
- The last product used by a trailer affects which products it can carry next, if it has not been cleaned in-between. This is referred to as Contaminants.
Trailers may be swapped whilst processing a large worklist (especially whilst tramping). Therefore Trailers must be captured and validated whilst in the field.
The users currently carry around a folder of standard procedures, pro-forma documents, etc. It would be preferred if this can be available on the device.
Documents
There are many different formats of each document type, including:
- Proof of Collection
- Proof of Delivery
- Weighbridge documents
- Environmental Collection/Disposal forms
The amount of paperwork currently collated is expected to continue while CALIDUS ePOD is implemented. It is up to the end customer whether they will accept the purely digitally-created POD, POC or Weighbridge information from the application. It is expected at this time that most will continue with the paperwork as-is.
There are up to 50 customers, each with different takes on very similar documents (POC, POD, Weighbridge, etc). It is not expected that these will all be required to be converted into CALIDUS ePOD. Instead, versions of the required documents will be created based on a consolidated and simplified version of the many current document formats.
Electronic Documents will not be sent to the end customers automatically, although they may be sent to the owners of the jobs.
Data Import
The existing inbound data requirements were discussed. In summary, the inbound files are received in many different formats and by many mechanisms. It is being decided whether TMS will import from the existing databases, or will replicate these imports. It is assumed at this time that TMS will import the data directly, bypassing the existing databases. Regardless, the orders must be accessible for importing into the existing databases as a back-up to CALIDUS TMS. This must include all manually-entered orders. To achieve this, an XML export from TMS will be imported back into the existing databases, which is likely to require Lomas development work. This export can be regularly scheduled.
![]() | SCR-312998-1: | Import of Orders from external sources |
It was suggested that the CALIDUS Portal product's Booking screen may be used for some customers to enter their own bookings and orders direct into CALIDUS TMS rather than using these bespoke imports. This may require an additional CALIDUS Portal screen to be created, to CALIDUS TMS' Bookings rather than to Orders.
![]() | SCR-312998-2: | New Portal Booking Screen |
The configuration of the different customers was discussed, and how this would impact data set-up in CALIDUS TMS. The different customers would require configuration of:
- Process (Signatures, Photos, Weighbridge requirements, etc)
- POD and POC formats.
The mechanism for this in CALIDUS ePOD is to assign each job a Job Group, which will be based on the Customer Group in CALIDUS TMS. It may also be necessary to make this location-aware, if different functionality is required at different destinations, for example.
![]() | SCR-312998-3: | TMS Job Configuration by Job Group |
Jobs will be transferred to CALIDUS ePOD through the standard interface from CALIDUS TMS. This interface will be modified for the functionality required, described in this document. This is expected to be:
- Job Restriction (based on product type being delivered, resources required, etc)
Additionally, the interface will be modified to:
- Auto-create Job Group from Site, defaulting values where necessary. Data can then be created later.
- Remove Jobs from Load if not present on the Load when refreshed from CALIDUS TMS.
- Ensure the Drop Number is passed in Sequence from CALIDUS TMS.
This will ensure the interface operates in the way that is required by the customer in the most seamless manner possible.
![]() | SCR-312998-4: | Modify EPOD Inbound Interface for required new functionality. |
The Weighbridge system exports all the weights captured for the day, collated hourly, via flat file. Note: This is only for Tarmac.
This flat file must be imported into the OBS systems to capture the accurate weights. This must be completed before the delivery leg at the destination. It was noted that this information is most likely required into the CALIDUS ePOD system first. It was undecided whether this information should also be picked up by CALIDUS TMS as well, or whether it could be forwarded by CALIDUS ePOD when received.
The format of this Weighbridge file remains unchanged, and a copy has already been provided to OBS.
Note: When weighbridge information is entered against a collection leg of an order, this information must be passed to the delivery leg.
![]() | SCR-312998-5: | EPOD Import of Weighbridge Data |
![]() | SCR-312998-6: | TMS Import of Weighbridge Data |
Device Configuration
The devices will be configured by OBS for the requirements of the system. This will include:
- Setting up a Google account, common to all devices. This is likely to be [email protected], but will be confirmed at implementation. This can be used for Google Drive, GMail and Play store purposes.
- All required applications installed from the Play market, including the CALIDUS ePOD app and SureLock lock-down applications.
- SureLock will be configured to allow access only to the desired functionality, which at this time includes:
- CALIDUS ePOD, including all Android system functionality required (e.g. Ring-tone Picker)
- Telephony, including common contacts (restricted white-list to be provided)
- SMS (restricted white-list to be provided)
- Email/Gmail - as required
- Play updates, but not the application itself, to prevent unwanted app installation.
- Camera
- Navigation Software (e.g. Maps, CoPilot)
- Google Drive or DropBox (see following)
- Customised background wallpaper
The users currently carry around a folder of standard procedures, pro-forma documents, etc. It would be preferred if this can be available on the device.
The accepted solution would be to use DropBox or Google Drive to complete this. Minimal test have shown that shared files on Google Drive do not allow users who share the file the ability to delete it, which is most preferable. Either application could be used, linked to the existing configured Google email address common across all devices.
PDA Login
The application will haver a customised style created for Lomas, which will include:
- An appropriate colour scheme (red/white)
- The Lomas logo on the login page.
It is possible that drivers will be allocated to individual contracts within CALIDUS TMS, but this should not affect CALIDUS ePOD, as all drivers will be capable of being used within the system. The drivers will be provided a user-name and password, and the loads will be allocated to specific drivers, ensuring that they can complete only the loads required.
A driver logs on to a device using their 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.
Vehicle Checks
When log-in is complete, the device will prompt the driver for the vehicle checks required. These are customer-configurable.
Vehicle checks have been confirmed as required, but the exact format of these checks has not yet been agreed - this will be set up during the Implementation phase of the product. Regardless, the checks will be set up so that they are prompted for each vehicle as the user logs on, and they must be completed before they are allowed to continue with the load.
Note: There are existing formats for vehicle checks, which will be provided so that they can be analysed to determine whether any changes to Vehicle Checks are required.
Note: Vehicle checks must be completed before the user is allowed to continue - there will not be an option to postpone Vehicle Checks.
Obtain Workload/Job List
When vehicle checks are complete, the assigned work-list will be downloaded onto the device, showing all the jobs in sequence on a Job List screen. If no workload has been assigned to the Driver (or tractor), the device will tell the user that there is no work available. The driver can exit, or try to download again.
The screen will display the status of the jobs on the load through a coloured outline, as follows:
- Red - Cancelled
- Green - Completed
- Blue - Completed (with amendments)
- Yellow - In Progress
- None - Pending/Incomplete
This status is displayed prominently in the Job Details screen.
The jobs are displayed in the sequence in which they should be completed, with the first job selected. However, the jobs can be viewed in any sequence by clicking the line of the job you want to complete - the device will display the Job Details page.
The Menu button can be used here to allow the following options:
- Show All / Outstanding Jobs - Toggle between showing all or only incomplete jobs.
- Refresh - Refresh the Load/Worklist
- Settings - Show the Settings screen
90% of jobs are loaded onto vehicles the night before, and have been fully planned. The remaining 10% are planned later, with the majority before the trips start, but there are always late-planned jobs of some description. This situation is resolved by getting a user to start a trip but continuing the planning and allocating jobs after the trip has started. This will update the device in the field. This situation is especially true when tramping.
No re-sequencing of jobs is allowed by the driver - the jobs must be completed in the order planned, or cancelled if they cannot be completed.
If jobs require re-sequencing for good reason, the driver will contact the planning office by phone and will request them to re-plan. When complete, they will refresh their load list using the standard CALIDUS ePOD functionality.
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 5 minute 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 can also be exploited to pick up re-sequenced or amended jobs, as described above.
Jobs can be cancelled by the driver at this time, by long-pressing on the job in the table and choosing Cancel from the pop-up options. The user will be prompted to enter a reason why this job is being cancelled, and optionally take a picture. If a job is confirmed cancelled, the device will show the Job List again with the cancelled job removed from the list.
Note: Cancelled jobs must be released for re-planning in CALIDUS TMS. This may require changes to the system, or specific reason codes to be used.
![]() | SCR-312998-7: | Ensure Cancelled Jobs can be re-planned |
Job Details
Selecting a job from the Job List will show the user the job report and customer contact details (on a Job Details screen). The user can back out of the selected Job and view any Job on the list.
The screen has several Tabs, showing:
- The Job Type (Collection, Delivery, Service)
- The customer details (Customer Code, Name, Address and Postcode)
- The contact information (Contact name and number)
- The Instructions for the job
Clicking on the tabs will display the information.
The screen allows the user to contact the customer (through text or phone. Text and Phone connectivity will be limited by a telephony white-list provided by the customer, so the device may not be allowed to contact this customer. If this is the case, the device will prevent contact and return to the CALIDUS ePOD application.
When the user has selected their Job, they can choose the Job with the Start Job button.
If there have been instructions provided on the Job, the device will switch to the Instructions tab, to force the user to see the instructions before starting.
Note: No re-sequencing of jobs is allowed by the driver - the jobs must be completed in the order planned, or cancelled if they cannot be completed. If the driver attempts to start a job out of sequence, the device will issue an error and will not start the job. If jobs require re-sequencing for good reason, the driver will contact the planning office by phone and will request them to re-plan. When complete, they will refresh their load list using the standard CALIDUS ePOD Load Refresh functionality, described above.
If the load may be started, the device will prompt for Trailer ID, if one has not been provided.
The process will be as follows:
- The depot guards and the driver will allocate an appropriate Trailer. They will use a TMS screen or report to view the available Trailers. This will show last used products. The design of this screen is covered elsewhere.
- The driver must enter the Trailer ID used on the EPOD device, as the first job is started. Trailer ID entry will be blind (i.e. nothing will be suggested) and will be allowed via Keyboard and Barcode entry. It is expected that Trailer IDs will be entered via barcodes.
- It was confirmed that the Trailer IDs generated for the system use the trailer type character at the start (e.g. all Tipper trailer IDs begin with "3").
- If the Trailer Type (found from the first character) does not match the Product Type (which will now be passed to CALIDUS ePOD from CALIDUS TMS), the trailer may not be used. The driver will not be allowed to continue without entering a valid Trailer ID. The trailer types are:
- 00 -
Warning: Di?
- 2 - Taut liners
- 3 - Tippers
- 4 - Flats
- 5 - Tankers
- 6 - Tip Tank
- 8 - Walking Floor
Warning: ? - HIAB?
- 00 -
- The chosen Trailer ID will be passed back to TMS when assigned by the driver to the job.
- Starting each subsequent job will only prompt for trailer ID entry if the trailer in use is unsuitable for the next job. Again, the driver will not be allowed to continue without entering a valid Trailer ID.
- The driver will be allowed to change the Trailer ID manually through a button press on the Job Details screen.
- Contaminants will not be validated on the device, as the device will not have a connection with CALIDUS TMS to validate this. Instead, when CALIDUS TMS is informed of the Trailer ID chosen, it will check the last used product, and will highlight if it believes that there is a potential contamination. This will be alerted in TMS, possibly through an email.
![]() | SCR-312998-8: | Trailer ID entry and Validation |
![]() | SCR-312998-9: | TMS Trailer Tracking |
![]() | SCR-312998-10: | TMS Trailer Contaminant Alerting |
Warning: The following questions are outstanding on this process:
- How will TMS alert, and to whom?
- How will TMS display contaminants?
- What selection criteria is required when displaying the trailers and last used contents?
- How will TMS be made aware of trailer cleaning, and thus the removal of potential contaminants?
When a Job is successfully started, this will take the Job to 'In Progress' status.
Note: Split Loads were discussed. In summary:
- Product is collected as normal.
- If the product may be delivered late and if the end customer agrees to the cost of redelivery on a subsequent day, the driver does not deliver the job, but instead cancels it and returns it to the hub.
- The product is then planned onto other trips (potentially broken down to several deliveries). This will expected to be through either rescheduling the delivery leg of the original order, or completing the original order and then splitting this onto another order for delivery, referencing the original order reference.
To achieve this (and for any other reason why the Job may be cancelled by the driver before arrival), Jobs can be cancelled by the driver at this time by clicking the Cancel Job button. The user will be prompted to enter a reason why this job is being cancelled, and optionally take a picture. If a job is confirmed cancelled, the device will show the Job List again with the cancelled job removed from the list.
The screen allows the user to navigate to the customer's address (available only after choosing to start the job).
The device will use any navigation application installed on the device for this navigation. It is expected that this will be through the Co-Pilot Truck navigation application, although CALIDUS ePOD will use any installed navigation system that deals with GPS intents, as long as that application has been allowed to be used on the device through the SureLock lock-down software.
Once the user arrives as the destination, they can indicate this and start processing the Job by clicking the Arrive Job button.
There is a requirement for Arrival signature - this will be added here, if configured.
![]() | SCR-312998-11: | Arrival Signature |
The system may be configured for Arrival Signature or Driver Signature, through the standard Job Group configuration. A new "Arrival Signatory" field will be required against the job, to allow the user to capture the readable name. This will also need to be reflected with TMS.
The device will show the standard Signature screen (as used when collecting customer or driver signatures at Job Completion stage). The driver will be able to identify the Signatory and collect the signature at this point.
Note: A new "Arrival Signatory" field will be required against the job, to allow the user to capture the readable name. This will also need to be reflected within CALIDUS TMS.
When confirmed complete, the device will move on the the Delivery or Collection process, depending on the job.
Delivery/Collection Process
Note: Although this process is used for the Delivery and the Collection process, this section refers to Delivery for simplicity.
Note: The document pack carried by the drivers (and now accessible on the device) includes some risk assessment pre-checks when collecting or delivering some kinds of products. It was noted that these Pre-work checks could possibly be integrated into the EPOD application in a future phase, if required, although this is not part of the scope of the project.
Although there are many different customers and products being collected and delivered, the process followed against each is similar enough to be covered by the processes described below.
The following are the standard tabs that are expected to be displayed:
Note: There is an optional User Notes tab that can be displayed, allowing the user to enter any notes against the Job before completion.
The device will show a list of the products to be delivered, on the Products tab, showing:
- The Product Code
- The Sequence
- The Description
- Any Customer Reference associated to this product
- The Planned Quantity
- The Item Type
- The Unit Type
Each product on the list can be confirmed as delivered by either:
- long-clicking on the item in the list and choosing Deliver from the pop-up menu
- entering the product code manually and clicking Deliver
- scanning the product code
When marked as delivered, the item will be removed from the list.
The driver can change the quantity by choosing Change Quantity from the pop-up menu - the device will direct them to an exception screen where the quantity can be changed, and a reason code entered as to why the quantity is changed. This will allow decimal entry of quantity, and will display the unit type, for clarification.
![]() | SCR-312998-12: | Product Quantity Entry - Decimal, displaying Unit Type |
If a product can't be found on the vehicle, it can be removed from the list with the pop-up option Cancel. Again, the exception screen will be shown where the driver can enter the reason why.
Note: During this exception process (either quantity change or product cancellation), the user can take an image with a description, if desired.
When all products have been confirmed as delivered, the Delivery process will close and the user will be directed to the Job Completion process.
Job Completion
Note: The Tipper process from Tarmac was confirmed to be similar in process to the tanker processes already discussed, in that the direct deliveries will be handled as a collection, with weighbridge entry, and a delivery.
Note: Environmental waste jobs will require a Driver Signature and a Customer signature, but will not require an Arrival signature. It was confirmed that there is only ever a need for up to 2 signatures per job, so the existing system database need not be affected - the system will be configured to accept Driver Signature OR Arrival Signature, not both.
It was also noted that some customers (e.g. MID UK) may not require customer signature, but may instead use stamping of official documents. In this case, customers like this can have the application configured to either:
- Not require customer signature (requiring paper stamp only and in perpetuity)
- Require customer signature as well as paper stamp.
- Require a photograph taken of the stamped document instead of a signature.
This last option may require a new format of collection/delivery note developing, displaying this as a separate page.
In order to allow for this difference in process, all jobs will be sent to the CALIDUS ePOD 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
- Whether Weighbridge and Weight is required to be manually entered
All of these processes are controlled during Job Completion.
If required, the device will first prompt for Customer Signature.
The signatory will default to the customer contact sent through on the job, but this can be changed. If one is not sent through, the driver will be forced to enter one.
The screen displays several tabs, allowing the user to see:
- Terms and Conditions, plus any check boxes the user is required to confirm. These are configurable.
- The products and quantities collected/delivered.
A new tab will be added here, if this is a Delivery job, and Weight and Weighbridge Number have been entered or captured against the Collection leg of this job's order. If so, the Weight and Weighbridge Number will be displayed in a tab here, labelled as Details
![]() | SCR-312998-13: | New Details tab on Signature screen |
The Terms and Conditions may differ for each customer, but will appear in the same place on the screen (under the signature). Unlimited T&Cs text can be configured, along with 3 potential check-boxes. Samples have been provided, but the actual wording of the T&Cs will be decided upon directly by the client and customer, and may reference a web site page for access to full terms and conditions.
When the signature is entered and confirmed (or if one is not required), the process will check whether Driver Signature is required (expected to be configured this way for Environmental Hazard and/or Recycling jobs).
The signature screen is extremely similar to the Customer Signature, but the Driver name is fixed, and the tabbed area is left blank.
When the signature is entered and confirmed (or if one is not required), the process will check whether Job Photo is required (possibly configured this way for those customers who stamp documents). Note: This is not a recommended process - minimising data storage and paper usage is a goal of CALIDUS ePOD, so this process should be discouraged if possible.
A screen will be displayed allowing the user to take a photograph as confirmation of the job, as well as a comment on the photograph taken. It is expected that, if this is configured, the photograph will be required entry rather than optional (i.e. it cannot be skipped).
When the Job/Document Photo is complete (or if this is not required), the process will check whether Job Metrics are required.
![]() | SCR-312998-14: | Job Metrics |
Note: This is only required to be developed if:
- This is a manual-entry process for some customers
- If this is required after signatures have been captured on a job. If before, this may need to be developed as a new function of the Job Details tab within the Collection/Delivery process.
If configured, this is expected to prompt for
- Weighbridge Number - alpha-numeric entry
- Weight - numeric decimal entry
Note: These items are configurable, but are expected to be required entry (i.e. the cannot be left blank).
Note: When entered against a collection, this information must be passed to the delivery leg, if on this load.
Once the Job Completion process has finished, the job will then be sent back to the CALIDUS ePOD server for completion, where all entered data, signatures and images will be stored and the job marked as complete. The user will be returned to the Job List screen and the Job will be removed from the list.
Post-Load
Once all Jobs have been completed, the Load will be marked as completed when the user returns to the Job List screen - the device will attempt to download a new load for the user and/or vehicle. If one has not been provided, the device will confirm this and allow the user to check again or log off the system.
Report Format
When jobs are completed, completion documents (POCs and/or PODs) are available so that they can be provided to the customers or viewed.
There are up to 50 customers, each with different takes on very similar documents (POC, POD, Weighbridge, etc). It is not expected that these will all be required to be converted into CALIDUS ePOD. Instead, versions of the required documents will be created based on a consolidated and simplified version of the many current document formats.
The required formats are:
- Proof of Collection, plus potential Weighbridge page
- Proof of Delivery, plus potentially one or two Weighbridge pages
- Proof of Collection (Hazardous format), plus potential Weighbridge page
Note: This may require an additional page if Document Photo is being used as confirmation of the completion of a job (see above).
Warning: Scanned copies of sample reports are required for prototypes to be created and passed to Lomas for approval before the specification stage of this project starts.
A scan or digital version of logos in use on these reports will be provided for design purposes.
![]() | SCR-312998-15: | POC/POD Document Formats |
Data Export
When jobs have been completed all the job is updated in the CALIDUS ePOD server, these jobs are then available for exporting to external systems. This is also true of cancelled jobs. All completed and cancelled Jobs will be transferred to CALIDUS TMS through the standard interface. This interface will be modified for the functionality required, described in this document. In addition to the standard fields, this is expected to be:
- Trailer ID
- Job Restriction (based on product type being delivered, resources required, etc)
- Weighbridge Number
- Weight
- Arrival Signatory
- Arrival Signature (in the Driver Signature field, as they are mutually exclusive features)
![]() | SCR-312998-16: | Modify EPOD Outbound Interface for required new functionality. |
This change will also need to be reflected in CALIDUS TMS interface, the database and possibly some screens, so that this data can be viewed.
![]() | SCR-312998-17: | Modify TMS Inbound Interface from EPOD for required new functionality. |
Note: It was noted that confirmation of Inbound orders needs to update TMS Bookings when complete. The assumption is that the Inbound process would also be usable for the first part of a split load. It was noted that TMS would need to store a location against the stored product. This is likely to be manually entered, or will assume a cross-dock location at the originating depot. It may be required that the driver enter a specific reason code for cancellation for any automatic functionality to fire in TMS (e.g. a Split Load reason code). At this time, this is awaiting confirmation. This will be clarified as the full systems architecture and solution is produced.
![]() | SCR-312998-18: | Identify Location against an Inbound Load |
For jobs that have been completed, POD documents may need to be sent to the customer. CALIDUS ePOD does this by checking the job's Email address and, if set and the system is configured to do so, it will send an email through the Lomas's mail server to the customer address specified. If no address is specified, no email will be sent. Note: It is possible to set up an email address against the site, so that all POD documents are emailed to one central place.
Appendix A: Table of SCRs
SCR# | System | Area | Description | Estimate (Days) | Notes |
1 | TMS | Import | Import of Orders from external sources | 21.00 | |
2 | Portal | Screen | New Portal Booking Screen | 7.00 | |
3 | TMS | EPOD I/F | TMS Job Configuration by Job Group | 14.00 | |
4 | ePOD | Import | Modify EPOD Inbound Interface for required new functionality. | 3.50 | |
5 | EPOD | Import | EPOD Import of Weighbridge Data | 7.00 | |
6 | TMS | Import | TMS Import of Weighbridge Data | 7.00 | |
7 | TMS | Database | Ensure Cancelled Jobs can be re-planned | 4.20 | |
8 | ePOD | PDA | Trailer ID entry and Validation | 8.40 | |
9 | TMS | Screen | TMS Trailer Tracking | 4.20 | |
10 | TMS | System | TMS Trailer Contaminant Alerting | 4.20 | |
11 | ePOD | PDA/Server | Arrival Signature | 5.60 | |
12 | ePOD | All | Product Quantity Entry - Decimal, displaying Unit Type | 4.20 | |
13 | ePOD/TMS | All | New Details tab on Signature screen | 1.40 | |
14 | ePOD/TMS | All | Job Metrics | 2.80 | |
15 | ePOD | Admin | POC/POD Document Formats | 7.00 | |
16 | ePOD | Export | Modify EPOD Outbound Interface for required new functionality. | 2.80 | |
17 | TMS | EPOD I/F | Modify TMS Inbound Interface from EPOD for required new functionality | 7.00 | |
18 | TMS | Screen | Identify Location against an Inbound Load | 7.00 |
Notes:
- All ballpark costs in this document are provided as-is, are legally non-binding and subject to raising a formal change request with OBS Logistics.
- These items have no additional charge.
- These items were not part of the original scope of the contract and, if required, will be charged separately.
In addition to the required customer changes noted in this document, the following product changes have been noted.
SCR# | System | Area | Description | Estimate (Days) | Notes |
P1 | ePOD | All | Display choice of Job Code, Job ID, Cust Ref, SO Ref | 3.50 | |
P2 | ePOD | PDA | Start Job - only force display of instructions if there are some | 0.35 | |
P3 | ePOD | PDA | Remove unnecessary items from the Products table in Collection/Delivery | 0.35 |
Notes:
- These items have no additional charge.
Appendix C: Document References
C.1 References
Ref No | Document Title & ID | Version | Date |
1 | UG 291094 EPOD Admin User Guide | 2.0 | 4/4/2012 |
2 | UG 291097 EPOD Client User Guide | 3.0 | 23/4/2013 |
3 | ![]() | 0.1 | 6/11/2013 |
C.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. |
C.3 Authorised By
Julie Scott | OBS Project Manager | _____________________________ |
Lynne Lomas | Lomas Distribution Representative | _____________________________ |