SDD 357982 BRC McMahon C-ePOD Solution Design
BRC McMahon
BRC McMahon C-ePOD Solution Design
Solution Design
15th June 2020 - 0.1
Reference: SDD 357982
Contents
Introduction
This document is the BRC McMahon C-ePOD Solution Design.
Objective
The primary purpose of this document is to document the requirements gathered from BRC McMahon through the sales process.
This document has been written in a manner such that it can be approved by non-technical representatives of BRC McMahon 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 BRC McMahon, as well as information gleaned from site visits and workshops with BRC McMahon.
- The changes will be made in the latest version of the CALIDUS ePOD system.
- Changes relating to information passed through to CALIDUS ePOD from external systems (i.e. Exchequer and Mapex) are subject to analysis and design, which may affect the other changes in this document or generate other work if the process described within this document cannot be followed by the external system.
- Modifications may be required to the customer systems to achieve the functionality described in this document.
Client Requirements
BRC McMahon currently use 2 systems they are proposing will interface into C-ePOD:
- Exchequer – https://www.exchequer.ie/ - Business Management/Accounting software which has details of the Customers and Sales Orders.
- Mapex - http://www.emapex.com/index.php/en/ - Manufacture of raw goods and Production Control.
Currently these 2 systems don’t integrate with each other.
Provided information:
- Proposed Outline document
- Product info spreadsheet.
There are much more than 50,000 bundles.
These bundles are comprised of:
- raw material items (which they process but they also sometimes resell unprocessed),
- finished goods (mesh usually),
- subcomponents of mesh (for example straight bars, which they sometimes sell),
- other products (such as rebar which they buy and sell unprocessed).
They expect all the Sales Order details to be fired across from Exchequer and site to add this to a Forklift for Picking onto a Trailer and then assign to a Driver to continue Load.
However the issue is with the scanning of the Product – the product would usually have a Production bundle barcode which isn’t visible in Exchequer so doesn’t exist on the Sales order - Exchequer only holds the Product Id.
The Production system Mapex can send C-ePOD product information on a regular basis with information of the Bundles and the Product ID once they come out of production.
They would like the scan against the bundle to be verification they have picked the correct product and to store this against the ePOD Product.
This would mean that C-ePOD imports a bundle file with both the Bundle id and the Product Id and then cross reference the Product from the Bundle as they scan the item to confirm that product pick.
They have provided their current CSV format, CSV is preferred method but can work with XML and webservices.
Overview of Solution
Customer Systems
Exchequer creates orders.
Mapex creates and stores bundles.
Bundle Interface
It will be necessary for EPOD to store the Bundle information, in order to store the quantity per bundle and the bundle identifier.
Note: This will be required in EPOD, as the suggested interface from Mapex is not a webservice, and therefore the EPOD device cannot look it up on demand.
![]() | SCR-357982-1: | Bundle Interface and Storage |
Note: It is expected that this interface should only send through Bundles that are active i.e. that have been created since a specified date and time. This will reduce the time required to process the information.
A new internal webservice method will be created to look up the bundle information from the device.
![]() | SCR-357982-2: | Bundle Device Lookup Interface |
Furthermore, a process will be written as part of the standard system clear-down processes to delete bundle information from the system where the quantity has been used by the warehouse user picking/loading process, to reduce the amount of information in the system.
![]() | SCR-357982-3: | Bundle Cleardown Process |
Note: These developments do not include:
- a facility to manage the bundles and quantity levels within the Admin system.
- a facility to view the jobs on which bundles were picked within the Admin system.
If this is required, then this will require additional development.
![]() | SCR-357982-4: | Maintain Bundle Levels |
![]() | SCR-357982-5: | Track Bundle Usage |
Pick/Load Orders Process
Interface
Exchequer will create jobs for the initial loading/picking of the goods and send them to EPOD. This will be in the standard OBS XML format.
Note: If this cannot be matched (as the customer has indicated a preference for a flat-file CSV interface), then a bespoke interface will need to be created to upload the orders.
![]() | SCR-357982-6: | Bespoke Exchequer Orders Interface |
Note: It is expected that this interface would also be used for delivery orders if required, so that only one interface is developed for the customer. This is referenced in that section.
Regardless, it is expected that the EPOD system will need to be modified to identify picks that are expected from Bundles rather than raw or single finished stock. This information will be passed into the system in an existing field against the product, and the EPOD system will be modified to check this for specific values.
![]() | SCR-357982-7: | Identify Bundled Products |
Load Assignment
EPOD Admin users will allocate those jobs to pickers/loaders (warehouse staff). It is likely that this will be grouped by the vehicle being loaded. This is dependent on the information interfaced on the original orders.
Warning: Confirmation required of this process.
It is not expected that there will be any required changes to the EPOD system for the user to effectively plan these orders onto picking workloads.
Pick/Load Process
Warehouse staff will pick/load the goods.
The warehouse users will log onto the device, identifying the vehicle being picked for.
C-ePOD will provide the information as to what is required to be picked. The jobs will be per order, in the sequence as sent (or identified in the interface or the Admin system).
The user will select a job and start it, and will be shown details of the job, including any instructions provided and a list of the products to be picked.
The user will scan a bundle or product code.
Currently the C-ePOD device checks the scanned or entered item against the pre-advised product ID. This will be modified to look up the bundle ID instead, and act differently if this is the case.
![]() | SCR-357982-8: | Bundle ID Scan Process |
The C-ePOD device will be changed on scanning barcodes or entering product IDs to check the product for a match. If one is not found, the application will be configured to check the system for the Bundle ID through a new interface (as specified above).
The device will use the information provided back to the user to find the product code based on the bundle scanned.
The device will display the bundle ID and the remaining quantity, and will request the user to enter the product quantity picked.
The process will check the quantity against the quantity to be picked (which by configuration may be set to never be exceeded) and against the bundle quantity.
If the bundle quantity is exceeded, the user will be required to confirm this.
The device will reduce the amount required for this identified product by this amount entered, and store the bundle ID picked from and quantity picked.
The user will continue picking until all products quantities are picked. At any time, the user can identify that there is no more product, with a reason code and comment if required), reducing the quantity that will be delivered.
When all products are picked, the user will complete that order pick.
As and when the user confirms an order is completed picking, the order will be sent back to the C-ePOD server, which will store that information, including the bundle and quantity information. The process will also record the quantity of each bundle remaining.
![]() | SCR-357982-9: | Update EPOD Bundle Quantities |
Note: If tracking Bundle usage, additional information will be written to track this at that time.
Warning: This process assumes that all picked product is through Bundle IDs. There are many types of product picked:
- Bundled stock
- Raw stock
- Finished stock
If this is necessary to have a different picking process, then the Bundled product must be identified on the picking jobs. This has been identified above in the change labelled "Identify Bundled Products".
Completion
When the orders are complete, these jobs will be sent back to Exchequer confirmed as picked and loaded. This JOB level message will include any bundle or product information and will also include the vehicle against the picked goods (through a separate final LOAD message).
This information will be sent out in the standard EPOD XML message formats.
Note: It is not expected that there will be an interface update sent to Mapex for the bundles. Therefore Mapex will not be updated with any bundles that were used in this process, nor with the quantity. If this is required, a Mapex update interface will be required. It is addumed that, if this is the case, then the Mapex system can use the same standard OBS JOB update interface format as described above.
C-ePOD can be modified to produce a POD note in a bespoke format, just for the confirmation of picking if required. This is as yet undefined.
![]() | SCR-357982-10: | Bespoke EPOD Pick (POC) Report Format |
Note: This is likely required to include the Bundle IDs and quantities. The generic reporting process will have to be modified to extract this information and display it accordingly. This is likely to create reports that cannot be effectively paginated.
Warning: This is not recommended.
Delivery Orders Process
Interface
Exchequer will then send the delivery orders through. This will be in the standard OBS XML format.
Note: If this cannot be matched, then a bespoke interface will need to be created to upload the orders, referenced above as "Bespoke Exchequer Orders Interface".
This will create a load for the day for the vehicle, and a job for the delivery of each of the orders on that vehicle for that day.
The delivery load must reference the initial loading load ID, which was sent back from EPOD in the initial picking job update.
It is expected that the bundles and quantities picked on those bundles will be interfaced to the C-ePOD system, and that this will be the item scanned for delivery, along with a confirmation of the quantity.
Warning: This process assumes that all products are in bundles and the bundle ID is retained with the stock to be delivered. If this is not the case, then the jobs can be interfaced with a total quantity of product to be delivered. In this case, the Bundle IDs will not be visible on the delivery notes.
Load Assignment
EPOD Admin users will then assign these jobs to the appropriate driver. Note: As long as the vehicle is stamped against the delivery loads created, the drivers themselves need not be assigned, as the C-ePOD mobile device will pick up loads assigned to a vehicle without the driver and record the driver who picked up the load.
It is not expected that there will be any required changes to the EPOD system for the user to effectively plan these orders onto picking workloads.
Delivery Process
The drivers will use EPOD to deliver the goods.
Note: The information the driver enters for confirmation of delivery of a job depends entirely on the information passed to C-ePOD on the delivery job i.e. product or bundle (or both).
The drivers will log onto the device, identifying the vehicle that the driver is delivering.
C-ePOD will provide the information as to what is required to be delivered. The jobs will be per order, in the sequence as sent (or identified in the interface or the Admin system).
The user will select a job and start it, and will be shown details of the job, including any instructions provided.
The user can then use the Navigate button to get driving instructions to the address, and click the Arrive button when arrived at the job.
The device will display a list of the products to be delivered.
The user will scan or enter a bundle or product code (depending on the job details provided). The user can also select products for delivery by selecting the product/bundle on the device's screen.
The user will then be asked to confirm the full quantity delivered of that product/bundle, or can change the quantity (with a valid reason code and some optional comments.
The user will continue picking until all products quantities are delivered.
When all products are confirmed as delivered, the user will complete that delivery.
The device will then proceed to customer confirmation of the delivery, which can be configured to include:
- Customer signature and identification of claused delivery)
- Driver signature
- Multiple photo capture, for confirmation or for paper document capture.
The driver may also have the option to complete an unmanned location delivery, and will be asked to sign on half of the customer and take a photo to confirm this.
As and when the user confirms an order is completed delivery, the order will be sent back to the C-ePOD server, which will store that information, including the bundle and quantity information. The process will also record the quantity of each bundle remaining.
Completion
When completed, delivered orders will be sent back to the Exchequer system confirmed as delivered.
This information will be sent out in the standard EPOD XML message formats.
C-ePOD will be modified to produce a POD note in a bespoke format, as yet undefined.
![]() | SCR-357982-11: | Bespoke EPOD POD Report Format |
Track and Trace
The CALIDUS Portal system will show details of the history of the jobs through the loads created, for picking/loading (if required) and delivery.
This includes a full audit trail of the orders at each point (initial creation, picking/loading and delivery).
The order details shown in the portal system will include the product and quantity but not the bundle information.
The Portal system will be updated when the orders are confirmed as picked or delivered, usually within a few minutes.
Appendix A: Table of SCRs and Ballpark Estimates
SCR# | System | Area | Description | Estimate (Days) | Notes |
1 | EPOD | Integration | Bundle Interface and Storage | 11.50 | |
2 | EPOD | Integration | Bundle Device Lookup Interface | 5.50 | |
3 | EPOD | Server | Bundle Cleardown Process | 2.50 | |
4 | EPOD | Admin | Maintain Bundle Levels (Optional) | 4.00 | 2 |
5 | EPOD | Admin | Track Bundle Usage (Optional) | 7.50 | 2 |
6 | EPOD | Integration | Bespoke Exchequer Orders Interface (Optional) | 10.00 | 2 |
7 | EPOD | Interface | Identify Bundled Products (Optional) | 4.50 | 2 |
8 | EPOD | Device | Bundle ID Scan Process | 6.50 | |
9 | EPOD | Server | Update EPOD Bundle Quantities (Optional) | 2.00 | 2 |
10 | EPOD | Reports | Bespoke EPOD Pick (POC) Report Format (Optional) | 5.00 | 2 |
11 | EPOD | Reports | Bespoke EPOD POD Report Format | 1.50 |

- Any high level ballpark estimates for development are based on the basic information provided and are subject to detailed design and creation of an SCR.
- This change is optional.
Appendix B: Document References
B.1 References
Ref No | Document Title & ID | Version | Date |
1 |
B.2 Glossary
Term or Acronym | Meaning |
---|---|
General Definitions | |
EPOD | Electronic Proof of Delivery. The OBSL EPOD system is CALIDUS ePOD. This also comprises the basis of the Service Completion system CALIDUS eServ. |
Server | The portion of the CALIDUS ePOD/eServ systems that controls all the data and sends information to and receives updates from the mobile device. |
Mobile Device; PDA | The device used by the driver to perform the jobs. Typically an Android mobile device or tablet. |
Site | The site usually defines the depot, business or the transport group (carrier). It can be set to any value required by the customer. All transactions data (for example, loads and jobs) and standing data (for example, vehicles and uses) belong to a site. An EPOD user, on a device or in the Admin screen, can only see data for one site at a time. |
Load | A single journey for the driver with a set of work attached. A load is identified by a unique load ID. This may also be referred to as a worklist or workload. |
Job | Also Consignment. A single task for the driver as a specific location. This could be the collection of goods or the delivery of goods. Jobs may also be Services (for example, servicing, installing or de-installing a boiler). A job is identified by a unique job ID but can also have other references held against the job (e.g. job code, SO number, customer reference and external reference). |
Job Group | Jobs must be tagged with a Job Group. All jobs tagged with a single job group are processed in the same way. The job group has configuration associated to it to control such items as: POD/POC Report settings; Pre-Job actions (such as signing at a gatehouse); Post-Job actions (such as who signs for the item, are photos required); configurable fields required for entry for the jobs; Terms and Conditions displayed and; driver/user process (such as photos required for cancellation, comments/notes allowed). The job group can be used for any or all Sites, and the configuration against the job group can be different in each site. Job Groups can also be restricted from Admin and Remote users, so that certain users only see jobs for certain groups. |
Container | A generic term for any object that contains the items being collected or delivered. Examples of containers are: Pallet; Package; Carton; Item; Cage. A special container "Loose Products" - see Product below. A container is identified by a container ID which is unique to this physical container. |
Product | A product is any goods that are being collected or delivered where the product has a 'Product Code' which identifies what the product is but which does not uniquely identify each individual item. A product will also have a quantity associated with it to indicate how many items of this 'Product Code' are being collected or delivered. Products can either be processed within a 'Container' or as 'Loose Products' without a 'Container'. |
Owner | The owner of the order that created the job. Typically this is the sales team that took the order and will be responsible for dealing with queries from the customer regarding the status. |
Operator; Executor | The Site (depot or carrier) that is executing the load or loads that are involved in the delivery of the items. |
Item Related Definitions | |
Job Code | A reference associated with a job or job(s). This reference is common to connected jobs, for example this would be the same on both the collection of goods and the associated delivery of the same goods. Typically this would be the transport unique reference. |
SO Number | A reference associated with a job which indicates the "Sales Order Number" this job is associated with. |
Customer Reference | A reference associated with a job which has been provided by and will be recognised by the customer. |
External Reference | A reference associated with a job which does not match any of the existing references, usually because it has been provided by an external system. |
Pallet | An alternative for 'Container'. The term pallet is used when the operation only uses portable platforms as the container for goods. |
Package | An alternative for 'Container'. The term package is used when the operation only uses boxes or wrapping as containers for goods. |
Package Code | A code representing the type of 'Container'. |
Package Desc | A description of the type of 'Container'. |
Product Code | A code which identifies what a product is. |
Item | A generic term for any individual item that can be collected or delivered. An item can represent a 'Container' or a 'Product'. This can also be used as an alternative for 'Container' when the operation only treats the goods as individual items, i.e. not as identifiable products. |
Service Item | An item which will be serviced by a service job. See action 'Service'. |
Issue Life | The time after which an item is no longer fit for purpose. |
Pack Size; Case Quantity | A product may consist of a full quantity of items, inside a pack. The Pack Size (or Case Quantity) defines the amount of this product contained in a single pack. For example, if there are 85 items to deliver, with a pack size of 24, the number of full packs is determined to be 3 (24 * 3, or 72), with the remaining (13) being 'loose' quantity. This is displayed as "3/13" on the mobile application. |
UOM; Item Type | Unit of Measure; The major (case) UOM. This can optionally be displayed on the mobile device when changing product quantities. |
Product Type | A classification of the product being delivered. For example, a company may deliver 7 different mortar products and 80 different concrete slab products. The Product Types may be set to "MORTAR" and "SLABS". This may be used to attach additional configuration, changing the data required when collecting or delivering these product types. |
Status Definitions | |
Status | An indicator of how far through the processing a 'Job', 'Container' or 'Product' has progressed. |
Pending | A status indicating that the processing has not yet started, but is required to be completed. |
In Progress | A status indicating that processing has started but not yet finished. |
Complete | A status indicating that the 'Job', 'Container' or 'Product' has been collected or delivered. |
Complete (Amended) | A status indicating that the 'Job', 'Container' or 'Product' has been collected or delivered but that some changes or amendments have been made. This means that not everything that was planned to be collected or delivered was collected or delivered, some items may have been cancelled or some products may only have had some of the planned quantities collected or delivered. |
Complete (Claused) | A status indicating that the processing has been finished but that a 'Clause' condition has been recorded for this item. |
Claused | See 'Complete (Claused)' and action 'Clause'. |
Cancelled | A status indicating that the processing of this item or job is no longer required. |
Cancelled at Collection | A status indicating that the delivery of a container or product is no longer required because the associated collection of this container or product was cancelled. |
Submitted | An optional status that applies only to a 'Job' and which occurs after the 'Job' has been completed. This indicates that any time and expenses information recorded for the 'Job' has been submitted back to the server and can no longer be altered. |
Action Definitions | |
Start | An action associated with a 'Job' meaning the driver is about to start the processing of this job or jobs. This action will mark the job(s) with a status of 'In Progress'. |
Arrive | A conditional action associated with a 'Job' meaning the driver has arrived at the location the goods should be collected from or delivered to. |
Continue | An action associated with a 'Job' meaning the driver has previously performed the 'Start' and/or 'Arrive' action and has exited the processing screen but is now going to continue the processing. |
Collect | An action associated with a specific 'Container' or a 'Product' meaning the driver has collected the 'Container' or 'Product'. This action will mark the 'Container' or 'Product' with a status of 'Complete' or 'Complete (Amended)'. |
Collect Claused | An action associated with a specific 'Container' or a 'Product' meaning the driver has collected the 'Container' or 'Product' but with a condition under which the collection was accepted. This action will accept the clause condition and then mark the 'Container' or 'Product' with a status of 'Complete (Claused)'. |
Deliver | An action associated with a specific 'Container' or a 'Product' meaning the driver has delivered the 'Container' or 'Product'. This action will mark the 'Container' or 'Product' with a status of 'Complete' or 'Complete (Amended)'. |
Deliver Claused | An action associated with a specific 'Container' or a 'Product' meaning the driver has delivered the 'Container' or 'Product' but with a condition under which the delivery was accepted. This action will accept the clause condition and then mark the 'Container' or 'Product' with a status of 'Complete (Claused)'. |
Clause | An action associated with a specific 'Container' or a 'Product' that has already been collected or delivered meaning the collection or delivery has been accepted with a condition. This action will accept the clause condition and then mark the 'Container' or 'Product' with a status of 'Complete (Claused)'. |
Cancel | An action associated with a 'Job', 'Container' or 'Product' meaning the collection or delivery will not be performed for this 'Job', 'Container' or 'Product'. |
Submit | An optional action which can conditionally be carried out after a 'Job' has been collection or delivered meaning that any/all required expense or time recording for this 'Job' has been completed and can be submitted back to the server. |
Service | A service of a service item or items. Typically, Installation, Deinstallation or Service. The process of a service usually encompasses Pre- and Port-work checks, information gathering and diagnosis and resolution notes. Additional references (MC Refs) may also be captured. |
Actioned | A general term describing completing a job. So, 'Actioned' may be used instead of 'Collected', 'Serviced', 'Delivered'. |
Consolidate | The action of taking several jobs and linking them together, so they are actioned at the same time with one start, arrive and signature. |
Deconsolidate | The action of taking a consolidation of jobs and breaking them down into the component jobs again. |
Job Swap | The action of selecting an existing load not assigned to the user, and picking jobs to transfer onto the user's load. |
Signature Capture | Usually the final action of a job, where the customer's name and signature are entered. |
Other Definitions | |
Reason Code | A code which represents the reason that a job was cancelled or an item was cancelled or claused. |
Vehicle | The vehicle used for transporting the goods. |
Vehicle Checks | Also Defect Checks. A series of questions representing the results of checks intended to ensure the vehicle is in an acceptable condition. |
Metrics Entry | A series of questions to capture information either at the start or end of a 'Load'. |
Driver | The person performing the collections or deliveries; the user of the device/application. |
Engineer | The person performing the services; the user of the device/application. |
Customer | The person/company the goods are being collected from or delivered to. |
Signatory | The name of the person providing a signature. |
T&Cs | Terms and Conditions. The T&Cs are shown when signatures are prompted for. The text of the T&Cs are defined in the system itself. |
Transfer Load | A load select from which to swap jobs to the user's load. |
Base | E.g. 'Return to Base'. Typically the depot from which the driver departed. |
Unplanned Ad Hoc Collection | A collection job that is created by the driver, usually after delivering to a customer. |
Ad Hoc Container Entry/Scanning | The process of adding containers (items) to a job that have not been pre-advised on the job. |
Completion Report | POD, POC, Service/Work Report. |
Load Assignment | The action of assigning a vehicle and/or a driver to a load. |
Job Assignment | The action of putting jobs onto a load. |
Collection/Delivery Windows; Access Windows | Periods of time between which it is acceptable to deliver or collect from that customer. This has limited use in the system, mostly for reporting purposes. |
Location/Map Terms | |
Lat-Longs; GPS Co-ordinates, GPS Position | Latitude and Longitude co-ordinates, specified together as a single entity, identifying the exact position of a location. There are multiple formats - CALIDUS ePOD uses decimal notation, for example "53.3490818,-2.8521498" identifies the OBS Logistics office building in Liverpool. |
GPS | Global Positioning System; the satellite system used to obtain a GPS position, for use with navigation and location positioning. |
Geocode; Reverse Geocode | Geocoding is the process of obtaining lat-longs from an address. Reverse Geocoding is the process obtaining an address from lat-longs. |
Geofence; Geofence Break | A Geofence is a perimeter around a location. A Geofence Break occurs when a device passes through this perimeter on entry or exit from the location. |
B.3 Authorised By
David Lohan | BRC McMahon Representative | _____________________________ |
Matt Turner | OBS Logistics Representative | _____________________________ |