View source for SDD 357982 BRC McMahon C-ePOD Solution Design

<div class="noprint">
{{#vardefine:Client|BRC}}
{{#vardefine:ClientName|BRC McMahon}}
{{#vardefine:System|''CALIDUS'' ePOD}}
{{#vardefine:SystemCode|EPOD}}
{{#vardefine:Doc_Title|BRC McMahon C-ePOD Solution Design}}
{{#vardefine:Version|0.1}}
{{#vardefine:Date|15th June 2020}}
{{#vardefine:Reference|357982}}
{{#vardefine:Year|2020}}
{{#vardefine:Type|SDD}}
{{ #vardefine: Figure | 0 }}{{ #vardefine: Example | 0 }}
<!--
Sample Xref:
{{Xref
|Type=Figure
|Num={{ #vardefineecho: Figure| {{ #expr: {{ #var: Figure}} + 1 }} }}
|Text=Data Upload - Import screen.}}
-->
</div>
{{Doc_TitleNew
|Client={{#var:ClientName}}
|System={{#var:System}}
|Title={{#var:Doc_Title}}
|Reference={{#var:Type|SDD}} {{#var:Reference}}
|Version={{#var:Version}}
|Date={{#var:Date}}
|Year={{#var:Year}}
|Type={{#var:Type|SDD}}
}} 

<!-- TOC --> 
<div class="noprint">
= Introduction  =
<!-- The introduction will detail the initial requirements supplied by the client -->
This document is the {{#var:Doc_Title}}.

== Objective  ==
The primary purpose of this document is to document the requirements gathered from {{#var:ClientName}} through the sales process.

This document has been written in a manner such that it can be approved by non-technical representatives of {{#var:ClientName}} whilst also being of sufficient detail to allow the Functional or Technical Specification phase for this area to begin.


== Scope and Limitations ==
This document is based on the documentation provided by {{#var:ClientName}}, as well as information gleaned from site visits and workshops with {{#var:ClientName}}.

* The changes will be made in the latest version of the {{#var:System}} system.
* Changes relating to information passed through to {{#var:System}} 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.

{{ #vardefine: SCR | 0 }}
<!-- NEW PAGE --> 
= 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.


<!-- NEW PAGE --> 
= 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|Reference={{#var:Reference}}|SCRNo={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}
|Definition=Bundle Interface and Storage
|Link=Appendix A: Table of SCRs and Ballpark Estimates
}}

{{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|Reference={{#var:Reference}}|SCRNo={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}
|Definition=Bundle Device Lookup Interface
|Link=Appendix A: Table of SCRs and Ballpark Estimates
}}


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|Reference={{#var:Reference}}|SCRNo={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}
|Definition=Bundle Cleardown Process
|Link=Appendix A: Table of SCRs and Ballpark Estimates
}}


{{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|Reference={{#var:Reference}}|SCRNo={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}
|Definition=Maintain Bundle Levels
|Link=Appendix A: Table of SCRs and Ballpark Estimates
}}

{{SCR|Reference={{#var:Reference}}|SCRNo={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}
|Definition=Track Bundle Usage
|Link=Appendix A: Table of SCRs and Ballpark Estimates
}}


== 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|Reference={{#var:Reference}}|SCRNo={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}
|Definition=Bespoke Exchequer Orders Interface
|Link=Appendix A: Table of SCRs and Ballpark Estimates
}}

{{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|Reference={{#var:Reference}}|SCRNo={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}
|Definition=Identify Bundled Products
|Link=Appendix A: Table of SCRs and Ballpark Estimates
}}


=== 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|Reference={{#var:Reference}}|SCRNo={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}
|Definition=Bundle ID Scan Process
|Link=Appendix A: Table of SCRs and Ballpark Estimates
}}

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|Reference={{#var:Reference}}|SCRNo={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}
|Definition=Update EPOD Bundle Quantities
|Link=Appendix A: Table of SCRs and Ballpark Estimates
}}

{{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|Reference={{#var:Reference}}|SCRNo={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}
|Definition=Bespoke EPOD Pick (POC) Report Format
|Link=Appendix A: Table of SCRs and Ballpark Estimates
}}

{{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|Reference={{#var:Reference}}|SCRNo={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}
|Definition=Bespoke EPOD POD Report Format
|Link=Appendix A: Table of SCRs and Ballpark Estimates
}}


== 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.


<!-- MEDIA LANDSCAPE YES --> 
= Appendix A: Table of SCRs and Ballpark Estimates  =
{{ #vardefine: SCR | 0 }}
{{REQ_SCR_Header}}
{{REQ_SCR_Line
|SCR={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}
|System=EPOD
|Area=Integration
|Description=Bundle Interface and Storage
|Estimate=11.5
|Notes=
}}
{{REQ_SCR_Line
|SCR={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}
|System=EPOD
|Area=Integration
|Description=Bundle Device Lookup Interface
|Estimate=5.5
|Notes=
}}
{{REQ_SCR_Line
|SCR={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}
|System=EPOD
|Area=Server
|Description=Bundle Cleardown Process
|Estimate=2.5
|Notes=
}}
{{REQ_SCR_Line
|SCR={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}
|System=EPOD
|Area=Admin
|Description=Maintain Bundle Levels (Optional)
|Estimate=4.0
|Notes=2
}}
{{REQ_SCR_Line
|SCR={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}
|System=EPOD
|Area=Admin
|Description=Track Bundle Usage (Optional)
|Estimate=7.5
|Notes=2
}}
{{REQ_SCR_Line
|SCR={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}
|System=EPOD
|Area=Integration
|Description=Bespoke Exchequer Orders Interface (Optional)
|Estimate=10.0
|Notes=2
}}
{{REQ_SCR_Line
|SCR={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}
|System=EPOD
|Area=Interface
|Description=Identify Bundled Products (Optional)
|Estimate=4.5
|Notes=2
}}
{{REQ_SCR_Line
|SCR={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}
|System=EPOD
|Area=Device
|Description=Bundle ID Scan Process
|Estimate=6.5
|Notes=
}}
{{REQ_SCR_Line
|SCR={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}
|System=EPOD
|Area=Server
|Description=Update EPOD Bundle Quantities (Optional)
|Estimate=2.0
|Notes=2
}}
{{REQ_SCR_Line
|SCR={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}
|System=EPOD
|Area=Reports
|Description=Bespoke EPOD Pick (POC) Report Format (Optional)
|Estimate=5.0
|Notes=2
}}
{{REQ_SCR_Line
|SCR={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}
|System=EPOD
|Area=Reports
|Description=Bespoke EPOD POD Report Format
|Estimate=1.5
|Notes=
}}
{{REQ_SCR_Footer}}

{{Note|
#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.
}}

<!-- MEDIA LANDSCAPE NO --> 
{{Doc_Appendix
|Appendix=B
|Estimate=N
|Glossary=EPOD2
|Ref1=&nbsp;
|RefV1=&nbsp;
|RefDate1=&nbsp;
|REQ=0
|EST=0
|FS=0
|TS=0
|DEV=0
|ST=0
|IMP=0
|Client=
|Year=
|FSEST=Y
|Rev1=David Lohan
|Rev1Title=BRC McMahon Representative
|Rev2=Matt Turner
|Rev2Title=OBS Logistics Representative
}}</div> 
[[Category:{{#var:Client}} {{#var:Type|REQ}}]]
[[Category:{{#var:SystemCode}}]]