View source for SDD 371213 Mondelez EPOD Solution Design Overview

<div class="noprint">
{{#vardefine:Client|MDLZ}}
{{#vardefine:ClientName|Mondelez International}}
{{#vardefine:System|''CALIDUS'' ePOD}}
{{#vardefine:SystemCode|EPOD}}
{{#vardefine:Doc_Title|Mondelez C-ePOD Solution Design Overview}}
{{#vardefine:Version|0.1}}
{{#vardefine:Date|12th March 2020}}
{{#vardefine:Reference|371213}}
{{#vardefine:Year|2020}}
</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}}.


== Objective  ==
The primary purpose of this document is to respond to the ITT from Mondelez, referenced in the appendices.


== Scope and Limitations ==
This document is based on the documentation provided by {{#var:ClientName}}, as referred to in the appendices.

{{ #vardefine: SCR | 0 }}
<!-- NEW PAGE --> 
= Client Requirements =
Listed below are the proposed processes that will be followed by the operatives using {{#var:System}}. 

The current operational process flow has been described in the documents provided by the customer, as referenced in the appendices. 


== Operational Information ==
<!-- Any general information about the operation (site, system, users, customers, limitations) should be listed here -->

Customer contacts:
* Jamie Broughton - Jamie.Broughton@mdlz.com


== Overview of Solution ==
Solution components:
* WMS:
** AutoStore - used at Minworth, Skelmersdale.
** LWS - used at Bicester.
** iNet - internally developed, creates delivery notes, potentially where the link to C-ePOD will originate, to be confirmed.
* ''CALIDUS'' ePOD - Collection/Delivery execution, product delivery, signature capture and POD document production.
* ''CALIDUS'' Portal TTM - Track and Trace module, comprising transport, trusted customer and end customer tracking.
* ''CALIDUS'' Assist - help pages, training, reference and user guides.
* SAP - Mondelez ERP.


The ''CALIDUS'' ePOD system provides functionality to handle the process of Proof of Delivery electronically. The system aids this process by providing both a management interface and a client application for use completing tasks.

The system supports three job types at this point, which encompass the functionality to complete many more tasks with them. You can use the system to complete and record; Deliveries, Collections and Services.

The C-ePOD administration software is a web-based application that handles all of the administrative side of the tasks completed on mobile devices by the C-ePOD mobile device application.

The main purpose of the application (amongst others) is as follows:
* To create and maintain users of the ePOD devices.
* To create and maintain reference data for the system (e.g. Reason Codes, Vehicles, Customers).
* To create Jobs of all types and group them together onto Loads/Workloads, and sequence the jobs appropriately.
* To resource  Loads (to Users and/or Vehicles).
* To view the Jobs and Workloads created.
* To print or email a POD.

The ''CALIDUS'' ePOD mobile app is an Android-based application, that handles all of the operational functionality for the execution of delivery, collection and service calls.

The mobile device application allows users to connect and receive load data, consisting of a load and a series of associated jobs. It provides the functionality to process and complete these jobs electronically in the field. The application allows processing of Services, Collections and Deliveries. The application is reliant on a network connection either GPRS or Wi-Fi to retrieve load data, but is ''not'' reliant on a connection to complete them, as once jobs are complete, data will be stored on the device until the next time the device has a connection and the application is running. Static data (such as site information) will be stored locally - this is downloaded once during the login process, if a connection is present and the data requires updating.


''CALIDUS'' Portal TTM provides several enquiry and auto-updating screens to allow information to be collated and provided in easy to use formats. The system supports multiple user-defined groups that control the configuration of a user, allowing the control of data access for various different purposes, for example:
* End customers.
* Contracts/Owners.
* Customer Service Queries.
* Transport Office.

''CALIDUS'' Portal TTM is kept updated at all times by ''CALIDUS'' ePOD of all states of the loads and jobs, for example:
* The Trip itself.
* The Order itself.
* The sequence of the Order on the Trip
* When an order is in transit.
* When an order is collected and/or delivered.
* When an order is cancelled.


''CALIDUS'' Assist provides help pages, from user guides to technical implementation guides, from simple to advanced, to provide as much information on how to get the best out your ''CALIDUS'' systems implementation and ease the uptake of the ''CALIDUS'' systems and minimize training. 

''CALIDUS'' Assist is based around industry-standard MediaWiki systems and is accessible through a browser either directly from your systems (for example, C-ePOD Admin), through a bookmark in your browser, or on your mobile device.

<gallery widths=600px heights=400px perrow=1>
Image:SDD_371213_Assist.png|''C-Assist C-ePOD page on desktop browser.''
</gallery>

<!-- NEW PAGE --> 
= Solution Detail =
== Interface in ==
Jobs and loads will be interfaced into C-ePOD from the WMS.

C-ePOD supports several standard interfaces, from XML to CSV. Given some of the complexity of the jobs, it is considered likely that the C-ePOD XML formats will be used.

The C-ePOD XML interface import files may be sent to C-ePOD through a flat-file interface or directly sent to a web service endpoint. All details of loads and jobs may be sent through thr interface, as well as the resources and standing data that the operation needs. All resources and standing data may instead be maintained directly within C-ePOD, if the facilities do not exist to maintain this within the existing systems.

Alternatively, OBS Logistics has great experience developing bespoke interfaces for customers, so if the facility doesn't exist to generate these files within the WMS in this format, OBS Logistics can be engaged to develop the interface within C-ePOD and pull the data on request.

It should be noted that a deeper understanding of the WMS capabilities regarding planning orders and trips and interfacing methodologies is required before any decisions can be made regarding the interface structure or content. However, this solution assumes that the orders will be planned onto multiple trips (trunk and radial, loading and unloading) and sent in with all required information to enable the jobs to be assigned and executed through C-ePOD, and tracked through C-Portal TTM. Although 2 WMS systems are in use at the sites, it is currently expected that iNet will be the source of message to ''CALIDUS'' systems.


== Admin Processes ==
Once jobs and loads have been sent into C-ePOD, the loads and jobs can be viewed through the C-ePOD Admin console.

<gallery widths=600px heights=400px perrow=1>
Image:SDD_371213_ADM_Loads.png|''Workloads.''
Image:SDD_371213_ADM_Jobs1.png|''Job details.''
Image:SDD_371213_ADM_Jobs2.png|''Job address.''
Image:SDD_371213_ADM_Jobs3.png|''Pallet information.''
Image:SDD_371213_ADM_Products1.png|''All products.''
Image:SDD_371213_ADM_Products2.png|''Single product details.''
</gallery>

Note that functionality exists within C-ePOD to manually create work loads, assign resource and sequence jobs.

In terms of resourcing, C-ePOD requires trips to be assigned to either a vehicle or to a driver, so that they can be picked up by the mobile device application - drivers aren't allowed to selected their own trips. Jobs can be assigned to either driver or vehicle or even both. 

The C-ePOD admin system links directly to the ''CALIDUS'' Assist help system to help users through using the system and discovering new features. The same is true of the mobile application, and other ''CALIDUS'' systems.

<gallery widths=600px heights=400px perrow=1>
Image:SDD_371213_Assist.png|''CALIDUS Assist for C-ePOD.''
</gallery>


== Mobile Devices ==
The C-ePOD mobile device application runs on Android mobile devices. They can be be tablets, phones, phablets or any other configuration, in landscape or portrait orientation - the mobile device application will display the screens making the best use of the available space and orientation. There is a special tablet mode that can also be used on certain devices, which makes the display make best use of high resolution, large screen space devices like this.


The mobile app supports barcode scanning for most data capture fields, for app configuration and for scanning products and containers. The app supports integrated barcode scanners used as a 'keyboard wedge', and also has an integrated or BlueTooth camera scanner function, where any Android device with a camera can be used to scan a barcode for a field, when this field is configured to capture barcodes.


The style of the application can be modified for Mondelez International if required, although the standard style will display the site logo for the application. Certain screens within the mobile application benefit the users if they are styled to add or remove items from the screen - the areas that will most benefit the operation will be indicated in the individual sections below.

Typically, our customers like to control the downloading of the mobile device application themselves. OBS Logistics can host the mobile application as part of the solution - as long as the Android mobile device allows side-loaded applications, the application can be installed on any device from Android KitKat (4.4) onward.

Typically, we provide QR barcodes to our customers for downloading the app, and for configuring the application to talk to their system. That streamlines the commissioning of new devices and should make the app easily usable for third-parties or substitute carriers.

The app has been built to modern standards - this is not a web page, but a full Android application that sits on the device. The app responds like any other application, so if the user is used to the standard Android features like clicking, swiping, zooming, tabs, switching apps, etc, they will be very comfortable using the C-ePOD mobile app.

The ''CALIDUS'' Assist pages will also be available in a mobile form, meaning that the users can access help at all times through a browser.


<gallery widths=300px heights=420px perrow=2>
Image:SDD_371213_AssistMobile1.png|''C-ePOD Assist on mobile.''
Image:SDD_371213_AssistMobile2.png|''&nbsp;''
</gallery>


== Logging in ==
Once the app is downloaded and configured on the mobile device, the driver can start the app and log in to the app. They are always prompted for a user, password and vehicle.

<gallery widths=300px heights=420px perrow=2>
Image:SDD_371213_EPOD_Login.png|''Styled login.''
</gallery>


== Vehicle checks ==
Once the driver has logged in, the app will check whether the vehicle needs any vehicle checks. These can be configured for the organisation with any number of checks and data entry and support tracking defects and resolution notes within the C-ePOD admin application.

<gallery widths=300px heights=420px perrow=2>
Image:SDD_371213_EPOD_VehicleChecks.png|''Configured vehicle checks.''
</gallery>

These checks need not be enabled.


== Getting a workload ==
At this point, the device will download the next workload assigned to the driver. It is thought at this point that the seal numbers may need to be captured against the trailer.

<gallery widths=300px heights=420px perrow=2>
Image:SDD_371213_EPOD_JobList.png|''List of jobs on the workload.''
Image:SDD_371213_EPOD_LoadStartMetrics.png|''Capturing configurable data at the start of the workload.''
</gallery>

These checks at the start of the load are fully configurable - you can add any number of items here for the driver, including check lists, reminders, ODO readings, etc. They can also be disabled.

The jobs on the workload will be shown on a list like an electronic summary driver manifest. The details that are shown against each job are configurable, so the application can provide the best information to the driver.

Workloads support collection and deliveries, loading and unloading at depots, trunk loads and radial deliveries. For the purposes of this document, we will assume a standard radial delivery.

The driver selects the job from the list to start it.


== Starting Jobs ==
The mobile application will show the details of the selected job from the list in a multi-tabbed display.

<gallery widths=300px heights=420px perrow=2>
Image:SDD_371213_EPOD_JobDetails.png|''Job details.''
</gallery>

At this stage, the driver has not yet departed - they can check the details of the address and any contact information for the customer. If the phone supports it, they can contact the customer (through phone or SMS).

The app will always make sure that any instructions on a job have been viewed by the driver before starting the job.

Once the job is started, the date, time an position are captured and sent on to the ''CALIDUS'' systems, so that you and your customers can see the job in progress. From this point, the app will track the position of the driver and periodically let the ''CALIDUS'' systems know the current location, to that ETAs can be calculated and displayed.

The map button allows the driver to select and start their favourite installed mapping application for navigation to the destination - whatever is installed on the mobile device will start and immediately navigate to the provided address or co-ordinates. 


== Arriving jobs ==
Once the driver has used the navigation app to get to the destination, they can easily return to the C-ePOD mobile app and indicate that they have arrived. The driver will at that point be asked to enter the trailer seal. This can be validated against the expected seal if provided.

<gallery widths=300px heights=420px perrow=2>
Image:SDD_371213_EPOD_JobArrival.png|''Configurable arrival process, capturing Seal information.''
</gallery>

This arrival process can be extended to capture any other data required by the operation, even providing site arrival terms and conditions and driver signature of acceptance if required.

Again, the ''CALIDUS'' core systems are immediately updated with the arrival to the location, and the device will move on to executing the job. 


== Job Details ==
The app will the job details on a multi-tabbed display. 
* General information, extensible with any additional information required by the operation.
* Products - details of all the products being delivered on the job.
* Notes - any driver notes.

The tabs that appear and the layout of the data on the tabs can be configured, especially the products list, to ensure that the most important information is displayed to the driver.

{{Note}} Although this document focusses on delivery, the same application is used for collections, loading and unloading jobs, on trunk and on radial trips. The processes for each of those activities can be configured and modified such that the driver is only asked to complete the stages and data entry as is required on the job at that time. 


The summary job information will be display first, including the driver instructions as a reminder. This will be extended to allow the driver to see the pallet information.

<gallery widths=300px heights=420px perrow=2>
Image:SDD_371213_EPOD_Delivery1.png|''Summary delivery information.''
Image:SDD_371213_EPOD_DeliveryPallets2.png|''Pallet information, with entered data.''
</gallery>


The product tab shows all of the products to be delivered. 

<gallery widths=300px heights=420px perrow=2>
Image:SDD_371213_EPOD_DeliveryProducts1.png|''Configurable list of products.''
Image:SDD_371213_EPOD_DeliveryProducts2.png|''Product actions.''
Image:SDD_371213_EPOD_DeliveryProducts3.png|''Delivered product removed from list.''
Image:SDD_371213_EPOD_DeliveryProductsInfo.png|''Full product information pop-up.''
Image:SDD_371213_EPOD_DeliveryProductsChangeQty.png|''Product exception process.''
</gallery>

The driver can deliver a product by scanning the product code from a barcode, maunally keying the product code or selecting the product from the list. The application will display a pop-up list of actions, where the driver can elect to deliver all, some or none of the product, see more product information, enter some comments or cancel the product delivery altogether.

Any exceptions from the norm of delivering all of the product will start an exception process where the driver can select a reason code for the change, see the quantity (with cases and units displayed if the product requires it) and take photos of the product if required before confirming the change. This can even be extended to allow data capture relating to individual reason codes if needed.

Once all products have been confirmed as delivered, the application will move onto job confirmation.


== Confirmation of job ==
As with other aspects of the mobile application, job confirmation is a configurable process. For end customer deliveries on radial trips, it is expected that the application will request the following:
* Customer signature.
* Driver signature.
* Optional photo capture.

<gallery widths=300px heights=420px perrow=2>
Image:SDD_371213_EPOD_CustSign1.png|''Customer signature with configurable T&Cs.''
Image:SDD_371213_EPOD_CustSign2.png|''Delivered products summary.''
Image:SDD_371213_EPOD_DriverSign.png|''Driver signature.''
Image:SDD_371213_EPOD_JobPhoto1.png|''Job photo.''
Image:SDD_371213_EPOD_JobPhoto2.png|''List of job photos.''
</gallery>


The mobile application supports the customer signature with name (signatory) capture, customisable terms and conditions and a list of all products delivered.

The terms and conditions are expected to consist of a "Signed Unchecked" tick box and customer comments, to enhance the existing offering of reason codes and clauses. Any standard T&Cs can be added as labels for the customer to read before signing.

The driver signature can be configured for data capture and T&Cs as well, although this is not expected to be required.

After that, the app can be configured to ask the driver to take photos of the delivery or be enforced to do so. On that, images are unlimited on the application, and are all stored against the job for viewing later, or even exporting to customers and external document management systems. They can be configured at any point in the application where additional data can be configured.

If the customer is unavailable (or this is an unmanned delivery), the driver can sign alone, in which case at least one photo is required, to prove delivery.


== Job Completion ==
As soon as the driver completes the job, the gathered information is sent back to the ''CALIDUS'' systems (data connection permitting). This tracks amendments and cancellations, with reason and clause codes, as well as actual times.

Once this has arrived, the information is available for viewing within the C-ePOD Admin system.

<gallery widths=600px heights=400px perrow=1>
Image:SDD_371213_ADM_JobComplete1.png|''Completed job information.''
Image:SDD_371213_ADM_JobComplete2.png|''Completed pallet information.''
Image:SDD_371213_ADM_JobComplete3.png|''Completed product information.''
</gallery>

Once all the information has arrived (including all of the photos, if required), this information is available to be reported and exported. 

The reporting system within C-ePOD allows us to perform quick modifications to style and layout to produce reports in customers' own formats.

The POD report can be called off on demand through the Admin system, automatically generated and emailed to end customers or only sent when there are errors or amendments, all configurable within the system. The reports are produced to the screen and/or emailed/sent as PDF or image files.

The report format provided has been prototyped and can be seen below:

<gallery widths=600px heights=800px perrow=1>
Image:SDD_371213_ADM_POD1.png|''Custom POD format as produced from C-ePOD.''
Image:SDD_371213_ADM_POD2.png|''Images as part of POD.''
</gallery>

The format is configurable as to how images are added to the report, whether they are included in exports, emails, etc, so once configured, you will be in control of the data presented to your customers.


The C-ePOD system supports export to many external tracking systems, such as Palletline, Pallex, Fortrack, Hazchem and of course our own C-Portal TTM. It can also be configured for document management systems exports and pushed updates to web services in the C-ePOD XML format. In most cases, these can be configured at the same time. So, there is plenty of scope within the product to export in our dedicated format. 

Alternatively, this information is available on demand, pulled by external systems through other web services methods.

In many cases, OBS Logistics have been approached to write bespoke interfaces, sometimes through EDIFACT gateways, to get information exported to the right final destination. Once we have discovered the requirements in this area, we will be able to include this in the project costs.


== Track and Trace ==
''CALIDUS'' Portal provides several enquiry and auto-updating screens to allow information to be collated and provided in easy to use formats. The system supports multiple  user-defined groups that control the configuration of a user, allowing the control of data access for various different purposes, for example:
* End customers - end customers can access tracking information about a single consignment through a link - no login is required.
* Contracts/Owners - trusted customers and internal staff can access the system through a provided user name and password to get at detailed information. Restrictions on the log-in will ensure that they can only see the data that pertains to them.
* Customer Service Queries - internal staff can access detailed information about consignments from within C-Portal from anywhere, and view, report on and send the information onto the querying party without accessing additional systems. 
* Transport Office - transport staff can use departure boards (and others) to view the now/next transport tasks and prepare pro-actively for them. These views are typically designed for use on large screens or projectors.

''CALIDUS'' Portal is kept updated at all times by {{#var:System}} of all states of the loads and jobs, for example:
* The trip itself.
* The order itself.
* The sequence of the order on the trip
* When an order is in transit.
* When an order is collected and/or delivered.
* When an order is cancelled.
The messages identify any changes to quantities and reasons for these changes at all stages.


The following is a brief description of functionality available within ''CALIDUS'' Portal.


=== Trip/Order Enquiry ===
This screen allows ''CALIDUS'' Portal users to track the status and events held against trips and orders, selecting them through a large variety of parameters.


==== Order Enquiry ====
<gallery widths=600px heights=400px perrow=1>
Image:SDD_371213_TTM_OrdEnqParms.png|''Order Enquiry Parameters.''
</gallery>

To identify the jobs (collection and delivery) that have exceptions (i.e. were not collected/delivered in full), this selection screen allows the user to define the orders to be reported, entering date/time from/to, and selecting delivery exceptions only. 

The enquiry responds with a results table summarising the matched orders:

<gallery widths=600px heights=400px perrow=1>
Image:SDD_371213_TTM_OrdEnqResults1.png|''Order Enquiry Results.''
</gallery>

These results can be expanded for further details of the stops, and the order can be clicked to drill-down into specific details of the order. 


==== Trip Enquiry ====
<gallery widths=600px heights=400px perrow=1>
Image:SDD_371213_TTM_TripEnqParms.png|''Trip Enquiry Parameters.''
Image:SDD_371213_TTM_TripEnqResults.png|''Trip Enquiry Results.''
</gallery>

These results can be expanded for further details of the orders, and the order can be clicked to drill-down into specific details of the order. 

The screen supports configurable RAG colouration, to highlight trips that are late or incomplete, and ETAs.


==== Order Details ====
<gallery widths=600px heights=400px perrow=1>
Image:SDD_371213_TTM_OrderDetail1.png|''Order and Event Details.''
</gallery>

Details can be found of the following:
*	''Events'' - the Messages received by the TTM system.
*	''Info'' - Details of all of the header information stored on the system
*	''Route'' - Details of the trips/stops that the order is currently assigned to, including all trunk and radial trips and stops.
*	''SO Details'' - the product details received.
*	''Reasons'' - Details of the order level reasons placed against the order.
*	''Map'' - A map of the current location of the order (if co-ordinates have been supplied by an external system). The mapping page will only be available to groups where the 'Mapping' parameter against the User Group is set to 'Available' and where licensing is available.
*	''Notes'' - Allows the entry of user notes against the order. These are only kept on the Portal system.
*	''Documents'' - Allows the upload/view of documents held in the Portal against the order. 

<gallery widths=600px heights=200px perrow=1>
Image:SDD_371213_TTM_OrderDetail2.png|''Order Info Details.''
Image:SDD_371213_TTM_OrderDetail3.png|''Order Route Details.''
</gallery>


==== Trip Details ====
<gallery widths=600px heights=400px perrow=1>
Image:SDD_371213_TTM_TripDetail1.png|''Trip Details.''
</gallery>

You can drill down into order details from here.


=== Arrivals/Departures (Order Status) Screen ===
''CALIDUS'' Portal supports several airport-style screens:
* Arrive/Depart screen.
* Order Status screen.
Both screens allow for customised parameter entry, and refreshing data at intervals, making them ideal for overhead displays or continuous transport queries. The recommended screen is the Order Status screen.

<gallery widths=600px heights=400px perrow=1>
Image:SDD_371213_TTM_OrderStatus1.png|''Order Status Screen.''
</gallery>

The screen allows the user to drill-down or expand on data to get more details, through pop-ups or further details screens.

The C-Portal TTM module's Order Status screen can be configured to determine the window for delivery in a +/- number of minutes before the delivery end time. This is accessible from the burger menu on the screen.

<gallery widths=600px heights=400px perrow=1>
Image:SDD_371213_TTM_OrderStatus2.png|''Order Status Parameters.''
</gallery>


=== Customer Tracking Gateway ===
On clicking the tracking link from the external system, the customer is asked to enter the consignment reference (the customer reference) they have been provided and the post code for the delivery location of the order being checked. Note that the consignment number can be sent through from the calling system, to help the customer obtain their details but post code must always be entered by the customer as a security measure.

<gallery widths=300px heights=200px perrow=1>
Image:SDD_371213_TTM_Gateway_Login.png|''Enter Consignment.''
</gallery>

 
The gateway then checks the order on the system, matching the customer reference and post code to the information on the system. The search for the order to be checked is not case-sensitive - the gateway will match the entry if entered in upper or lower case, and the postcode entered can be in any format, with or without spacing. If an order is not found that matches the information entered, the screen will display that no information can be found in a popup message.

If a unique order is found, the gateway displays a summary of the information on the order being checked, similar to the following:

<gallery widths=600px heights=400px perrow=1>
Image:SDD_371213_TTM_Gateway_Tracking.png|''Consignment Tracking.''
</gallery>


{{Note}} Only information from the order being checked is displayed on this screen, as well as some information relating to times and execution of the Trip on which this order is being delivered. At no time is any information from any other order (on this trip or otherwise) displayed on this screen.


The screen displays:
*	The Order Status of the order being checked, which may be one of several items, based on how the systems are being used:
**	Ordered.
**	Loaded.
**	Out for Delivery.
**	Delivered.
**	Cancelled
*	Last Delivery Sequence - The number of the last stop serviced on the trip that is delivering the order being checked. {{Note}} This is only the stop number, not the full address of the last stop serviced.
*	Your Delivery Sequence - The stop on which the order being checked will be delivered. {{Note}} This is only the stop number, not the full order address - this is displayed below.
*	Order Reference - The customer's order reference of the order being checked.
*	Full Address - The full delivery address of the order being checked.
*	Courier - If known, the courier completing the delivery of the order being checked.
*	Driver - The full name of the driver completing the trip on which the order being checked is being delivered.

The screen also displays a time-line bar, showing all the statuses the order being checked has passed though. Successfully-completed statuses are coloured green, and the date/time the status was changed (if provided) is displayed under the status on the bar.


If the order being checked is out for delivery, the screen displays a map showing:
*	The last known location of the vehicle making the delivery. 
*	The customer's delivery location
{{Note}} The last known location of the vehicle making the delivery could be the address of another customer receiving a delivery on that trip. However, no address information or labels are shown against the locations displayed in the map and no information is divulged regarding the reason the vehicle is currently at that location.


If provided to ''CALIDUS'' Portal, this screen can also display the ETA at the location of the order being checked, the signature and a link to view the POD report, when the order being checked is marked as Delivered.


=== TTM Reporting ===
Each enquiry screen allows exporting of data, usually at most of the following levels (depending on the query)

*	'''Trip''' - trip information.
*	'''Trip/Stop''' - trip/stop information.
*	'''Trip/Order''' - trip/stop/order information.
*	'''Order''' - order header information.
*	'''Order Detail''' - order header / order detail information.
*	'''Pallet''' - order pallet information.


<!-- NEW PAGE --> 
{{Doc_Appendix
|Appendix=A
|Estimate=N
|Glossary=EPOD2
|Ref1=Scope of Work.docx
|RefV1=N/A
|RefDate1=N/A
|Ref2=Delivery Process v1.pdf
|RefV2=1.0
|RefDate2=N/A
|Ref3=DN POD Example.pdf
|RefV3=N/A
|RefDate3=N/A
|Ref4=High Level System Flow v1.pdf
|RefV4=1.0
|RefDate4=N/A
|Ref4=Pre-delivery Process v1.pdf
|RefV4=1.0
|RefDate4=N/A
|REQ=0
|EST=0
|FS=0
|TS=0
|DEV=0
|ST=0
|IMP=0
|Client=
|Year=
|FSEST=Y
|Rev1=Warren Wright
|Rev1Title=OBS Representative
|Rev2=Jamie Broughton
|Rev2Title=Customer Project manager
}}</div> 
[[Category:{{#var:Client}} REQ]]
[[Category:{{#var:SystemCode}}]]