View source for REQ 312912 Morris EPOD Requirements

<div class="noprint">
{{#vardefine:Client|PORT}}
{{#vardefine:ClientName|Morris Furniture}}
{{#vardefine:System|''CALIDUS'' ePOD}}
{{#vardefine:Doc_Title|Morris Furniture ePOD Requirements}}
{{#vardefine:Version|1.1}}
{{#vardefine:Date|17th March 2014}}
{{#vardefine:Reference|312912}}
{{#vardefine:Year|2013}}
</div>
{{Doc_Title
|Client={{#var:ClientName}}
|System={{#var:System}}
|Title={{#var:Doc_Title}}
|Reference=REQ {{#var:Reference}}
|Version={{#var:Version}}
|Date={{#var:Date}}
|Year={{#var:Year}}
}} 

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

== Objective  ==
The primary purpose of this document is to document the requirements gathered from Morris Furniture during the sales process, and to present an overview of the process that will be followed in and the work required to the {{#var:System}} system.

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 the OBS Logistics Sales team, as well as information gathered at further meetings, at the Andrew Porter site on 25/09/2013 and with Morris Furniture by conference calls on 27/09/2013, 22/10/2013 and 4/11/2013.

Further discussions were held on 14/03/2014 through conference call with all parties, which also clarified the requirements. 


<!-- ANY scope or limitations, bulleted. -->
* The changes will be made in the latest version of the {{#var:System}} system.
* The changes have been specified with the Android PDA client in mind.
* This document covers the processes and change requirements to {{#var:System}} only - it does not cover the functionality or changes to any other system or application, such as Co-Pilot or CALIDUS TTM. This functionality should be specified elsewhere, if needed.
* This project is a sub-project of Andrew Porter, which is referenced heavily here.
<!-- NEW PAGE --> 
= Client Requirements =
== Overview==
Company Name: 
: Andrew Porter Ltd

Business: 
: Furniture Logistics (No containers, loose product delivery)

Address:
: Andrew Porter Ltd 
: Porter House
: Huyton Road
: Adlington
: Chorley
: Lancashire
: PR7 4JR

Tel:
:  01257 482398

Andrew Porter Operational Contacts (In order of project relevance):
* Hayley Ashton - Nominated Project Manager : ashtonh@andrewporterltd.co.uk 
* Ryan Dalton - Ops Manager - DaltonR@andrewporterltd.co.uk
* Henry Worsley - Ops Manager - WorsleyH@andrewporterltd.co.uk 
* Tim Aspey - M.D. - AspeyT@andrewporterltd.co.uk 

There are two separate integrations on this project. No integration methods have been decided, but standard OBSL schema has been proposed. Contacts are listed below:
* Technical/Integration Contacts
** 1st Integration - Andrew Porter Bespoke ERP/TMS
*** Paul McQuillan- Provides software and also maintains servers for Andrew Porter - 07789740090
** 2nd Integration - Specific AP Customer Integration - Morris Furniture Ltd (Microsoft AX System)
*** Desmond Downie - Ops Manager: Desmond.Downie@morrisfurniture.co.uk
*** Stephen Wheeler - Ops Manager: Stephen.Wheeler@morrisfurniture.co.uk  

Products:
* CALIDUS ePOD 
* CALIDUS TTM - with E.T.A’s
* Nokia Maps for use with TTM

* Android PDA Hardware - Still negotiating with Matthew Turner. AP aware of 4 week lead times. OBSL will be installing on hardware regardless of supply.
* Co-Pilot - client still to order
* Device Management Software - Not purchased as yet

Development Agreed:

OBSL have agreed to develop the delivery notes shown in [[#Appendix A: Client Documents|Appendix A]]. All customer formats other than these listed will be variants on the HSL format only, differing only in Logo and T&Cs.

OBSL have agreed to a bespoke development for Enter Load Notes:
* Android Device: 
**	Add Photo ID and Notes fields to database 
**	From Job List, add Notes option to the menu (activated by pressing the Menu button on the device) 
**	If selected, display a Notes Screen 
***	Allows entry of Notes (unlimited text). 
***	Button to take a photo 
***	Button to save and a button to exit. 
**	All data sent back and stored against the Load record. 
*Admin: 
**	Load Screen 
***	Allow filter by whether notes have been entered 
***	On Select of a Load, on pop-up display: 
****	Add Notes field 
****	Add Photo button (if one exists). If pressed, display pop-up of photo. 
* DB/DAL 
**	Add Photo ID and Notes fields to database and DAL. Allow search based on whether Notes field is populated. 
* PDA/Server web services: 
**	Load Update 
*** 	Add Photo ID and Notes 


{{Note}} The hosting of the system is still to be confirmed by the customer. If required, OBS Logistics can host the system and will be providing a quote to do so.

== Data Import ==
There are two back-end systems:
* Andrew Porter ERP/TMS
* Morris Furniture Microsoft AX System
{{#var:System}} will be configured so that there are two sites, one for each of the above. This will ensure that Admin users logging on to one site will see only the jobs for their business.


Drivers and Vehicles will be pre-configured in {{#var:System}} - there is no need to create more interfaces for standing data.


Loads and Jobs (both Service Requests and Deliveries) will be received received from Microsoft AX. This will be through a new configurable flat-file transfer system of a CSV-format file. 

{{SCR|Reference={{#var:Reference}}|SCRNo={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}
|Definition=New configurable FFT Import Mechanism.
|Link=Appendix B: Table of SCRs 
}}


It is expected that the trigger to send the loads would be when all the orders are despatched, and/or through a manual send option within Microsoft AX.

The details of this format are as follows:
*	Data will be quote-enclosed comma-delimited.
*	A header line will be sent for each type of record being sent in the file, mapping a column position to a field name. These lines will be preceded with an indicator in the first column.
*	Detail lines will be sent for each of the following items. The different lines will be identified by the first column, showing the table that this line is mapping to (shown in brackets below):
**	A Line will be sent for the Load (EPOD_LOAD) to be created.
**	A line will be sent per delivery or uplift (EPOD_JOB) on the Load
**	A Line will be sent per Sales Code (EPOD_CONTAINER) on the Job.
**	A Line will be sent per Component (EPOD_PRODUCT) on the Container.
*	Multiple loads can be processed in one file.

Example:

: "H", "EPOD_LOAD", "EPL_SITE_ID", "EPL_LOAD_ID", "EPL_USER_ID", "EPL_VEHICLE_ID"
: "H", "EPOD_JOB", "EPL_SITE_ID", "EPL_LOAD_ID", "EPL_JOB_CODE", "EPL_JOB_TYPE", "EPL_JOB_GROUP", "EPL_CUST_REF", "EPL_START_PLANNED_DATE", "EPL_START_PLANNED_TIME", "EPL_CUSTOMER_CODE", "EPL_CUSTOMER_NAME", "EPL_ADDRESS_1", "EPL_ADDRESS_2", "EPL_ADDRESS_3", "EPL_ADDRESS_4", "EPL_ADDRESS_5", "EPL_POSTCODE", "EPL_CONTACT", "EPL_TELEPHONE", "EPL_ORDER_DATE", "EPL_SALES_CONTACT", "EPL_EXT_REF", "EPL_SO_REF", "EPL_COL_DATE", "EPL_JOB_INSTRUCTION"
: "H", "EPOD_CONTAINER", "EPL_CONTAINER_ID", "EPL_DESCRIPTION_LONG"
: "H", "EPOD_PRODUCT", "EPL_PRODUCT_CODE", "EPL_DESCRIPTION", "EPL_PRODUCT_QTY_PLANNED"
: "EPOD_LOAD", "MORRIS", "030654", "DRIVER"
: "EPOD_JOB", "MORRIS", "030654", "2026835", "D", "MORRIS-D", "8088/55550", "20130816", "09:00", "GRA02", "CJ GRANT", "36/40 WILSON PLACE", "", "EAST KILBRIDE", "", "UK", "G74 4QD", "", "01925 748466", "20130814", "0003", "0306542026835", "", "", ""
: "EPOD_CONTAINER", "01-ORL-665/3", "ORL 5 SLEIGH BED"
: "EPOD_PRODUCT", "01-ORL-665A/3", "ORL 5 BED HEAD/FOOTBOARD", "1"
: "EPOD_PRODUCT", "01-ORL-665B/3", "ORL 5 BED SIDERAILS PACK", "1"
: "EPOD_PRODUCT", "01-ORL-665C/3", "ORL 5 BED SLAT PACK", "1"
: "EPOD_JOB", "MORRIS", "030654", "0303705", "C", "MORRIS-C", "9116", "20130801", "09:00", "ALL006", "GOYT MILL", "GOYT MILL, MARPLE", "STOCKPORT", "", "", "UK", "SK6 7HX", "", "", "20130801", "ANGELA", "0303705", "1198888", "20120831", "QA07: K BARFOOT - UPLIFT PER KEVIN BARFOOT"
: "EPOD_CONTAINER", "03-GRA-520T6", "GRANGE ROLL BACK DINING CHAIR"
: "EPOD_PRODUCT", "03-GRA-520T6", "GRANGE ROLL BACK DINING CHAIR", "2"

{{Note}} Morris Furniture delivers products with multiple sub-products (a Sales code, with multiple components) and products without components. It was agreed that mapping these in the same way is fine, i.e. a container will be created for the Sales code, and a single product line will be created for each product quantity for the Single Products, and multiple product lines will be created for those with multiple components to deliver.

The formats and detailed functional specification and samples of the existing interface and file layouts have be made available to technical representatives of Morris Furniture (Kana) for mapping exercises and external system coding. However, the mapping shown above seems to match the requirements of the customer.


Drivers:
*	May be set by Andrew Porter.
*	May be pre-set or changed in Microsoft AX.
*	May be set or changed after using {{#var:System}} Admin.
So, they may arrive on the interface or they may be blank.

If drivers are on the message and are not in {{#var:System}}, the interface will create them as a skeleton record, with the User ID as the Driver ID sent in, and the Name and Password defaulted, with default access created. 

There are no vehicles in the TMS system, so they will not be sent - jobs will be allocated by the driver and the vehicle will be set to that chosen by the driver when executing the load.

As amendments may be sent through from Microsoft AX, at a Load, job Container or Product level, the interface designed needs to support additions, changes or deletions at any level. The following rules would apply:
*	Any job, container or product that does not already exist for its parent shall be created as new.
*	Any Load that does not already exist shall be created.
*	Any job, container or product that does exist for its parent shall be amended.
*	Any job, container or product that is not updated as part of the inbound file shall be deleted, unless they are in progress, when they shall be cancelled.
*	An empty load (i.e. no jobs after it) shall be deleted, unless the load is in progress, in which case it shall be cancelled.


The sending mechanism is assumed to be FTP. This is dependent on the way the system is hosted. A naming convention will be agreed. It is assumed that Microsoft AX will push the files through.


All jobs will be sent to the {{#var:System}} system with a configuration element known as Job Group - this will define the process to be followed against each job, the terms and conditions displayed, signatures required and completion document produced (i.e. POD or POC/Service Request form). Due to differences between the software solutions, it has been agreed that there will be different Job Groups for each Brand/Job Type combination. As there are 4 brands and 2 job types, this will result in 8 Job Groups. These will be pre-created in {{#var:System}}.

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

<gallery widths=310px heights=400px perrow=3>
File:REQ_312105_1.PNG|Vehicle Checks Sample
</gallery><br />

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}} Vehicle checks must be completed before the user is allowed to continue - there will not be an option to postpone Vehicle Checks.

{{SCR|Reference={{#var:Reference}}|SCRNo={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}
|Definition=Vehicle Checks - no postpone option
|Link=Appendix B: Table of SCRs 
}}


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

<gallery widths=310px heights=400px perrow=3>
File:REQ_312912_2.PNG|Job List
</gallery><br />

The customer has requested a mechanism by which notes can be entered by the user against the Load. This will be accessible from this screen.
* The user will be able to press the Menu button on the device and select Notes from the pop-up menu.
* The device will display a Notes entry form, with unlimited data entry. There will be a button to take a single image, a button to save what has been taken so far, and a button to exit without saving.
* On completion of all jobs on a load, this information will be sent back with the load information.
{{SCR|Reference={{#var:Reference}}|SCRNo={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}
|Definition=Enter Load Notes
|Link=Appendix B: Table of SCRs 
}}


There is also a menu item here that allows the user to force a refresh if their Load from the system (although this happens regularly anyway). If any jobs have been added to a Load while the load is in progress, this refresh (automatic or manual) 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 be exploited to fulfil ad-hoc collections, discovered only when reaching the delivery point.


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

<gallery widths=310px heights=400px perrow=3>
File:REQ_312912_3A.PNG|Job Details (Delivery)
File:REQ_312912_3B.PNG|Job Details (Service Request)
</gallery><br />

When the user has selected their Job, they can choose the Job with the '''Start Job''' button. This will mark the Job as 'In Progress' status.

{{Note}} No re-sequencing of jobs will be allowed - the system will be configured to ensure that the driver is asked to confirm that they are choosing jobs out of the sequence shown on the job list.

The Job Details screen allows the user to contact the customer (through text or phone), or navigate to the customer's address (available only after choosing to start the job). 

A second telephone number is required against the customer and job address information, allowing the user to enter a land or mobile number. The Job Details form will on the device will be modified to display this new number, and to modify the '''SMS''' and '''Call''' buttons to take best advantage of this.

{{SCR|Reference={{#var:Reference}}|SCRNo={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}
|Definition=2nd Customer Contact Number
|Link=Appendix B: Table of SCRs 
}}


{{Note}} The Andrew Porter back-end system supports up to 3 contact numbers - this will be mapped to the 2 numbers specified above, through the interface and through validation in the back-end contact information data entry form.


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 {{#var:System}} will use any installed navigation system that deals with GPS intents. 

Once the user arrives as the destination, they can indicate this and start processing the Job by clicking the '''Arrive Job''' button.


== Delivery/Collection Process ==
All jobs will be sent to the {{#var:System}} system with a configuration element known as Job Group - this will define the process to be followed against each job, the terms and conditions displayed, signatures required and POD document produced.

The following are the standard tabs that are expected to be displayed:
<gallery widths=310px heights=400px perrow=3>
File:REQ_312912_4.PNG|Job Details Tab
File:REQ_312912_5.PNG|Containers Tab
File:REQ_312912_6.PNG|Products Tab
</gallery><br />
{{Note}} There is an optional ''User Notes'' tab that can be displayed, allowing the user to enter any notes against the job before completion. This is expected to be the place where notes will be entered for Service Requests.


The ''Containers'' tab will show that there are a number of Sales Codes to be delivered. Each Sales Code on the list can be confirmed as delivered by either:
* clicking on the item in the list and choosing ''Deliver'' from the pop-up menu
* entering the Sales Code manually and clicking '''Deliver'''
* scanning the Sales Code
When marked as delivered, the device will show a list of the components to be delivered for this Sales Code. For items without components, this screen will still be shown, showing only one component on the list.

Each product on the list can be confirmed as delivered by either:
* clicking on the item in the list and choosing ''Deliver'' from the pop-up menu
* entering the component product code manually and clicking '''Deliver'''
* scanning the component product code
When marked as delivered, the item will be removed from the list.

If more than one of a component product is to be delivered, this will be shown on 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.

If a product can't be found, 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.

If a none of a Sales Code can be found, or it is refused delivery, it can be removed from the list with the pop-up option ''Cancel''. The exception screen will be shown where the driver can enter the reason why.

{{Note}} During this exception process, the user can take an image with a description, if desired.

When all Sales Codes and Components have been confirmed as delivered, the Delivery process will close and the user will be directed to the Job Completion process.


For collections (Service Requests), the process is identical, in that Sales Codes are identified as collected, and the components are confirmed. Any notes against a Service Request can be entered on the User Notes tab.


== Job Completion ==
The Job Completion process consists of a screen displaying the delivered items, any Terms and Conditions, and customer Signature and signatory entry. 
<gallery widths=310px heights=400px perrow=3>
File:REQ_312912_8A.PNG|Customer Signature, with Sales Codes delivered
File:REQ_312912_8B.PNG|Customer Signature, with Components delivered
</gallery><br />

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
* Containers (Sales Codes)
* Products (Components)

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.

For example:
* Delivery T&Cs are likely to be a variation on the following:
: ''PLEASE NOTE THAT THIS ORDER IS SUBJECT TO OUR CONDITIONS OF SALE, AMENDED 1ST FEBRUARY 2008 AND AVAILABLE AT www.morris.co.uk/tandcs.aspx''
: ''CLAIMS FOR LOSS OR DAMAGE TO GOODS MUST BE REPORTED TO US AND THE CARRIER WITHIN 3 DAYS OF DELIVERY''
* Collection T&Cs are currently:
: ''We are sorry you have cause to request after Sales Service, this is our official Uplift document.''
: ''This form shows the exact details given to you but we may bring to your attention that any further damage, which will be noted by our driver, will result in your Credit Note being reduced to cover the cost of the repair.''
: ''Our drivers have been instructed not to uplift and items unless this official document is used. When he refuses to uplift on your own paperwork and not ours, please be advised he has instructions to follow and he is doing his job correctly.''
: ''Please help us to help you achieve the best possible service at all times.''
{{Warning}} Confirmation required as to what actual T&Cs are required to be put before the customer when signing for the collection, if the customer signs at all.


{{Note}} There are configurable processes that require driver signature entry or a job image be taken before confirmation, but it is not expected that this is part of the processes.


Once signatures are completed, the job will then be sent back to the {{#var:System}} 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 send back any load notes and images to the server, and will request an 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 Formats ==
When deliveries are completed, POD documents are available so that they can be provided to the customers or viewed. 

The current formats of these documents are shown in [[#Appendix A: Client Documents|Appendix A]].

{{Note}} The exact customer POD formats that will be used within {{#var:System}} are being confirmed by Stephen Wheeler, conferring with the business.

{{SCR|Reference={{#var:Reference}}|SCRNo={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}
|Definition=POD/POC Document Formats
|Link=Appendix B: Table of SCRs 
}}


'''Delivery Note:'''
* The Logo and address on the header of this note will be set from the Job Group, so different Brands may feature different logos on the resulting paperwork.
* Load/Order No - Load ID, and Job Code
* Invoice To - Not Required
* Delivery To - Job Address
* Account No - Customer ID
* Our Ref Number - Job Code, as above
* Your Ref - Cust Ref
* Delivery Date - Sent in from the back-end system, stored in Order Date in {{#var:System}}
* Time - Removed
* Agent - Keyed in by
* Details:
** Code - For the master line, Container ID, each contained pack is Product Code
** Quantity - Product Qty
** Description - For the master line, Container Description, each contained pack is Product Description
* Signature - Customer Signature
* Print Name - Cust Signatory
* Date Received - Actual End Date

Notes:
* Barcodes on this document are used to aid in manual uploading of POD details into Morris' back-end system. As {{#var:System}} is being modified to export directly into the Arena Document Management System, these barcodes will been removed. However, an interim solution may be required where these barcodes are used for a short period of time. If required, these will be added - to be confirmed.
* Delivery Date - this is actually the Despatch date and the label will change to reflect that. 
* The repeated Delivery Date will be removed.
* Several prototypes exist and have been sent to the client for for confirmation with their customers. The below is a sample of this:

[[file:REQ_312912_POD.PNG|border|600px]]
<br />Delivery format<br />


'''Service Request:'''
Regarding the content:
* The Logo and address on the header of this note will be set from the Job Group, so different Brands may feature different logos on the resulting paperwork.
* "0303705" - Job Code
* Barcodes - To be confirmed whether this should be removed, as with Delivery Note
* Account Address - removed as with Delivery Note
* Uplift Address - Customer Address
* Account No - Customer Code
* Date - Planned Start Date
* Order No - Customer's Reference
* Despatch No - S/O Ref
* Original Delivery Date - Col Date
* Date of Request - Order Date

Items (details taken from Component level EPOD_PRODUCT):
* Item Code - Component Code
* Description - Description plus actual collected quantity

Next Section - user-entered notes (from the User Notes entered against the Job)

Next Section:
* Comments - EPL_JOB_INSTRUCTION
* Reported By - {{Warning}} Possibly fixed data?
* Operator - {{Warning}} Keyed In By
* Replacement Ref No - {{Warning}} Left blank on form

Terms and conditions - Fixed on the format or from the T&Cs for the Job Group {{Warning}} To be confirmed.

There are still some questions requiring answer from Morris Furniture at this time:
* No signatures? I would have both Driver and Customer signatures for this. What does the driver currently request?
* (HW) "C/N 304407 04/09" - I think this is the Credit Note information (plus the stamp, obviously), but if this is something that needs to be on the final documentation produced from CALIDUS ePOD, please let me know.
* Comments - I assume that these are instructions that the driver must see in order to do the collection?
* Reported By - Would this be the customer contact or the person who took the collection request? The actual printed data is "Uplift and Credit/Inspection", which does not seem to match the customer contact. 
* Operator - would this be the driver or or the person who took the collection request?
* Replacement Ref No - Required? If so, what is this? {{Note}} There appears to be no field to store this data. Assuming that this is written in after the collection and therefore should be left blank on the form.
* In both examples, the customer appears to be returning different items than those on the planned collection (according to the hand-written notes) - is this correct? This poses an issue, in that we would have to develop a mechanism of the driver adding products on to the collection (or even starting with a blank collection and entering everything ad-hoc), which I'd rather not get into. If this is an exceptional circumstance, then the user could use the notes field to enter this information.
* The Dates the driver has entered on the handwritten dates don't match up - For order 119888, Jim Kerr signs on 30/08, then a further signature appears for 08/08, despite being planned for 01/08. Very confusing. Any help you can give in understanding the timeline would be appreciated.

Assuming the default from the above questions, plus assuming there is a customer signature, the expected Service Request format is as follows:

[[file:REQ_312912_POC.PNG|border|600px]]
<br />Service Request format<br />


{{Note}} For all formats produced, best efforts will be made to match the produced format to the sample provided, but differences in production and presentation (i.e. Browser, Email, etc) may result in some small differences. Specifically, the signatures will require more space than allowed in the current sample.


== Data Export ==
When jobs have been completed all the job is updated in the {{#var:System}} server, these jobs are then available for exporting to external systems. In this instance, it is necessary to link to an external document management system (Arena) for PODs/POCs to be stored here for automatic or manual uploading. 

There are two possible solutions being considered for this project:
* Full solution - requires an Arena DMS software upgrade
* Interim solution - requires manual printing and scanning of documents

The interim solution will require the POD/POC document formats to include a barcode. This can be achieved, but must be confirmed by the customer.


For the full dolution, the Arena DMS software upgrade is in scope. The reasons for this are:
*	Improvements in UI handling of PDF files
*	Improvements in importing data (generic vs bespoke interface, direct lookup of index data, etc).
*	Quality of PDF greater than TIFF.
*	Typical filesize of scanned docs in Arena DMS is around 40K, PDFs are expected to be around 25K, so file storage benefits.
The upgrade of this system is being handled and costed separately

The existing process is:
*	TMS creates despatch reports, including DNote/Service Request No in a barcode.
*	Nightly run on TMS creates a Code/Index CSV file, including DNote/Service Request No, plus all index files.
*	Barcode contains Load No and Order No - this is unique per brand.

There are 2 document types, and 4 brands, resulting in 8 document types in Arena DMS. 
*	One limitation of the generic Arena DMS V3 upload process is one folder is required per document type - all contained documents are uploaded from there.
*	One limitation of the generic POD/POC export in C-ePOD is that one folder is used for both Collections and Deliveries per job group, although there can be multiple job groups.

Therefore the expected process is:
*	Arena DMS is updated to version 3.
*	A button is added to back-end TMS to send through Loads to {{#var:System}}. 
**	Each Job will have a different Job Group, depending on Brand and Job Type.
**	This will include the "Barcode" value mapped to "EPL_EXT_REF".
**	The TMS will continue to write Code/Index CSV files in the way that it does already.
*	 On completion of jobs (through a batch process running frequently), PDFs will be produced and stored in a remote or local directory, named as "<EPL_EXT_REF>.PDF". Only completed (i.e. non-cancelled) jobs will be exported. The folder will depend on the Job Group, expected to be different for each Brand/Job Type combination (therefore 8 folders).
*	Arena DMS will (through a frequent batch job) pick up these files from these folders. The process will also continue to pick up the code/index information.

This results in no changes to {{#var:System}}


<!-- NEW PAGE --> 
= Appendix A: Client Documents =
== Delivery Note ==
[[File:REQ_312105_DN_4.PNG|600px|border]]
== Service Request ==
[[File:REQ_312912_SR1.PNG|600px|border]]
<!-- MEDIA LANDSCAPE YES --> 
= Appendix B: Table of SCRs =
<!-- If there's only one system being discussed here, the system column can be removed.
Ballpark estimates may not be required to be included in this document. If they are, include the column, and note 1. Estimates should be rounded up, and should be produced using the standard mechanism of estimates (i.e. any standard spreadsheet designed to automate the production of estimates). The total line need only be added if the estimates are being produced at this point
The description should be the description from the text in the main sections. 
The Notes column can be used for many things: grouping optional changes, showing whether the client or OBS originated the gap, etc. -->

{{ #vardefine: SCR | 0 }}
{{REQ_SCR_Header}}{{REQ_SCR_Line|SCR={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}|System=ePOD
|Area=PDA/Admin
|Description=New configurable FFT Import Mechanism
|Estimate={{#expr: 5 }}
|Notes=4
|Days=Y
}}{{REQ_SCR_Line|SCR={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}|System=ePOD
|Area=Admin
|Description=Vehicle Checks - no postpone option
|Estimate={{#expr: 0 }}
|Notes=2
|Days=Y
}}{{REQ_SCR_Line|SCR={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}|System=ePOD
|Area=PDA/Admin
|Description=Enter Load Notes
|Estimate={{#expr: 5*1.4 }}
|Notes=2
|Days=Y
}}{{REQ_SCR_Line|SCR={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}|System=ePOD
|Area=All
|Description=2nd Customer Contact Number
|Estimate={{#expr: 3.75 }}
|Notes=2
|Days=Y
}}{{REQ_SCR_Line|SCR={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}|System=ePOD
|Area=Admin
|Description=POD/POC Document Formats
|Estimate={{#expr: 2.5 }}
|Notes=3
|Days=Y
}} {{REQ_SCR_Footer}}

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 will be completed under the Andrew Porter changes and, as such, are listed here for reference only.
# 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.


<!-- MEDIA LANDSCAPE NO --> 
{{Doc_Appendix
|Appendix=C
|Estimate=N
|Glossary=EPOD
|Ref1=[http://172.198.45.54/calidus-assist/EPOD/index.php/UG_291094_EPOD_Admin_User_Guide UG 291094 EPOD Admin User Guide]
|RefV1=2.0
|RefDate1=4/4/2012
|Ref2=[http://172.198.45.54/calidus-assist/EPOD/index.php/UG_291097_EPOD_Client_User_Guide UG 291097 EPOD Client User Guide]
|RefV2=3.0
|RefDate2=23/4/2013
|Ref3=[[REQ 312105 Andrew Porter ePOD Requirements]]
|RefV3=1.0
|RefDate3=2/10/2013
|REQ=0
|EST=0
|FS=0
|TS=0
|DEV=0
|ST=0
|IMP=0
|Client=
|Year=
|FSEST=N
|Rev1=Julie Taylor
|Rev1Title=OBS Project Manager
|Rev2=____________________(PRINT)
|Rev2Title=Morris Furniture Representative
}}</div> 
[[Category:{{#var:Client}} REQ]]