REQ 312912 Morris EPOD Requirements: Difference between revisions

From Calidus HUB
VisualWikitext
(v1.1 - Document changes from conference call with customer on 14/03/2014)
m (Minor format change)
 
Line 63: Line 63:


Andrew Porter Operational Contacts (In order of project relevance):
Andrew Porter Operational Contacts (In order of project relevance):
* Hayley Ashton –  Nominated Project Manager : [email protected]  
* Hayley Ashton - Nominated Project Manager : [email protected]  
* Ryan Dalton – Ops Manager - [email protected]
* Ryan Dalton - Ops Manager - [email protected]
* Henry Worsley – Ops Manager - [email protected]  
* Henry Worsley - Ops Manager - [email protected]  
* Tim Aspey – M.D. - [email protected]  
* Tim Aspey - M.D. - [email protected]  


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:
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
* Technical/Integration Contacts
** 1st Integration – Andrew Porter Bespoke ERP/TMS
** 1st Integration - Andrew Porter Bespoke ERP/TMS
*** Paul McQuillan- Provides software and also maintains servers for Andrew Porter – 07789740090
*** Paul McQuillan- Provides software and also maintains servers for Andrew Porter - 07789740090
** 2nd Integration – Specific AP Customer Integration – Morris Furniture Ltd (Microsoft AX System)
** 2nd Integration - Specific AP Customer Integration - Morris Furniture Ltd (Microsoft AX System)
*** Desmond Downie – Ops Manager: [email protected]
*** Desmond Downie - Ops Manager: [email protected]
*** Stephen Wheeler – Ops Manager: [email protected]   
*** Stephen Wheeler - Ops Manager: [email protected]   


Products:
Products:
* CALIDUS ePOD  
* CALIDUS ePOD  
* CALIDUS TTM – with E.T.A’s
* CALIDUS TTM - with E.T.A’s
* Nokia Maps for use with TTM
* 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.
* 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
* Co-Pilot - client still to order
* Device Management Software – Not purchased as yet
* Device Management Software - Not purchased as yet


Development Agreed:
Development Agreed:

Latest revision as of 14:25, 17 March 2014





Aptean Logo.png







Morris Furniture

Morris Furniture ePOD Requirements

CALIDUS ePOD

17th March 2014 - 1.1
Reference: REQ 312912











































Introduction

This document is the Morris Furniture ePOD Requirements 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 CALIDUS ePOD system.

This document has been written in a manner such that it can be approved by non-technical representatives of Morris Furniture 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.


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

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):

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)

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

CALIDUS ePOD 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 CALIDUS ePOD - 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 SCR-312912-1: New configurable FFT Import Mechanism.


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 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 CALIDUS ePOD Admin.

So, they may arrive on the interface or they may be blank.

If drivers are on the message and are not in CALIDUS ePOD, 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 CALIDUS ePOD 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 CALIDUS ePOD.

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.

  • Vehicle Checks Sample

    Vehicle Checks Sample


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

SCR SCR-312912-2: Vehicle Checks - no postpone option


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.

  • Job List

    Job List


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 SCR-312912-3: Enter Load Notes


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.

  • Job Details (Delivery)

    Job Details (Delivery)

  • Job Details (Service Request)

    Job Details (Service Request)


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 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 SCR-312912-4: 2nd Customer Contact Number


Note 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 CALIDUS ePOD 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 CALIDUS ePOD 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:

  • Job Details Tab

    Job Details Tab

  • Containers Tab

    Containers Tab

  • Products Tab

    Products Tab


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

  • Customer Signature, with Sales Codes delivered

    Customer Signature, with Sales Codes delivered

  • Customer Signature, with Components delivered

    Customer Signature, with Components delivered


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

Note Note: The exact customer POD formats that will be used within CALIDUS ePOD are being confirmed by Stephen Wheeler, conferring with the business.

SCR SCR-312912-5: POD/POC Document Formats


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 CALIDUS ePOD
  • 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 CALIDUS ePOD 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:

REQ 312912 POD.PNG
Delivery format


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 Warning: Possibly fixed data?
  • Operator - Warning Warning: Keyed In By
  • Replacement Ref No - Warning Warning: Left blank on form

Terms and conditions - Fixed on the format or from the T&Cs for the Job Group Warning 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 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:

REQ 312912 POC.PNG
Service Request format


Note 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 CALIDUS ePOD 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 CALIDUS ePOD.
    • 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 CALIDUS ePOD


Appendix A: Client Documents

Delivery Note

REQ 312105 DN 4.PNG

Service Request

REQ 312912 SR1.PNG

Appendix B: Table of SCRs

SCR#SystemAreaDescriptionEstimate (Days)Notes
1 ePOD PDA/Admin New configurable FFT Import Mechanism  5.00  4
2 ePOD Admin Vehicle Checks - no postpone option  0.00  2
3 ePOD PDA/Admin Enter Load Notes  7.00  2
4 ePOD All 2nd Customer Contact Number  3.75  2
5 ePOD Admin POD/POC Document Formats  2.50  3


Notes:

  1. 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.
  2. These items will be completed under the Andrew Porter changes and, as such, are listed here for reference only.
  3. These items have no additional charge.
  4. These items were not part of the original scope of the contract and, if required, will be charged separately.


Appendix C: Document References

C.1 References

Ref NoDocument Title & IDVersionDate
1UG 291094 EPOD Admin User Guide2.04/4/2012
2UG 291097 EPOD Client User Guide3.023/4/2013
3REQ 312105 Andrew Porter ePOD Requirements1.02/10/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 Taylor
OBS Project Manager		_____________________________

____________________(PRINT)
Morris Furniture Representative		_____________________________
Retrieved from ‘https://calidusassist.adcservices.apteancloud.com/calidus-assist/OBS/index.php?title=REQ_312912_Morris_EPOD_Requirements&oldid=1468’