U S E R A N D C O N F I G U R A T I O N G U I D E Mobile ... · U S E R A N D C O N F I G U R A T I...

The Descartes Systems Group Inc. | T SX : DSG | NAS DAQ : DSGX | 120 Randall Drive, Waterloo, Ontario, N2V 1C6, Canada

Toll Free 800.419.8495 | Int‘l 519.746.8110 | [email protected] | www.descartes.com

CONFIDENTIAL AND PROPRIETARY TO THE DESCARTES SYSTEMS GROUP INC. AND ITS AFFILIATES

Mobile Resource Management

Business Intelligence Database

February 2018

U S E R A N D C O N F I G U R A T I O N G U I D E


Mobile Resource Management Business Intelligence Database


Toll Free 800.419.8495 | Int‘l 519.746.8110 | [email protected] | www.descartes.com 2


© 2018 The Descartes Systems Group Inc. All rights reserved.

Information in this document is subject to change without notice. The Descartes Systems Group Inc. and its affiliates and

subsidiaries (“Descartes”) make no warranties, express or implied, in respect of this document or its contents.

Complying with all applicable copyright laws is the responsibility of the user. Without limiting the rights under copyright, no

part of this document may be reproduced, stored in or introduced into a retrieval system, or transmitted in any form or by

any means (electronic, mechanical, photocopying, recording, or otherwise), or for any purpose, without the express written

permission of The Descartes Systems Group Inc..

Descartes may have patents, patent applications, trademarks, copyrights, or other intellectual property rights covering

subject matter in this document. Except as expressly provided in any written license agreement from Descartes, the

furnishing of this document does not give you any license to these patents, trademarks, copyrights, or other intellectual

property.

Descartes Transportation Manager, Descartes Route Planner, Descartes Global Logistics Network (Descartes GLN),

Descartes Wireless Global Logistics Network, Descartes wGLN, Descartes, the phrase “Helping Customers Deliver,” and the

Descartes logo are either registered trademarks or trademarks of Descartes and/or its affiliates or subsidiaries.

Windows, Windows Server, Internet Explorer and SQL Server are either registered trademarks or trademarks of Microsoft

Corporation in the United States and/or other countries.

Google Chrome is a trademark of Google Inc. in the United States and/or other countries.

Intel Core and Intel Xeon are either registered trademarks or trademarks of Intel Corporation in the United States and/or

other countries.

The names of other actual companies and products mentioned herein may be the trademarks of their respective owners.


The Descartes Systems Group Inc.

120 Randall Drive

Waterloo, Ontario Canada, N2V 1C6

Phone: 519-746-8110

Internet: http://www.descartes.com

Customer Support

In North America: 1-877-786-9339

Outside North America: +800 -7866-3390

e-mail: [email protected]

http://www.descartes.com/







Table of Contents Document Conventions ..................................................................................................................... 5

1 Introduction ................................................................................................. 6 1.1 Document Purpose................................................................................................................. 6

1.2 Intended Audience ................................................................................................................. 6

2 Requirements .............................................................................................. 7 2.1 Server Software/Hardware ..................................................................................................... 7

2.1.1 LNOS Reporting Servers ................................................................................................. 7

2.1.2 Database Server (DB, SQL) ............................................................................................ 7

2.2 Client Hardware/Software ...................................................................................................... 8

2.2.1 Browser Configuration .................................................................................................... 8

2.3 SQL Installation Requirements ............................................................................................... 9

2.3.1 Memory Configuration .................................................................................................... 9

2.3.2 Disk Configuration .......................................................................................................... 9

3 Solution Overview ....................................................................................... 9 3.1 Summary ............................................................................................................................... 9

3.2 Terminology......................................................................................................................... 10

3.2.1 Entities ......................................................................................................................... 10

3.3 Workflow ............................................................................................................................. 11

3.3.1 Identifying Data to Extract ........................................................................................... 11

3.3.2 Data Extraction for Reporting ....................................................................................... 12

3.3.3 Loading the Data for Reporting .................................................................................... 12

3.4 Reporting ............................................................................................................................. 12

3.4.1 Descartes Reporting Services ....................................................................................... 12

3.4.2 Reporting without Descartes Reporting Services ........................................................... 12

4 Configuration & Maintenance ................................................................... 13 4.1 Dispatch System Database Configuration ............................................................................. 13

4.1.1 BIStaging.BISysValue ................................................................................................... 13

4.1.2 BIStaging.FWBIUdfExtractionList (Descartes Route Planner Only) ................................. 13

4.1.3 BIStaging.BITimePeriods .............................................................................................. 14

4.1.4 Customizable Columns.................................................................................................. 14

4.1.5 Staging Procedure ........................................................................................................ 15

4.2 Reporting Database Configuration Tables ............................................................................. 16

4.2.1 Config.BIProducts......................................................................................................... 16

4.2.2 Config.BIProductsConfig ............................................................................................... 16

4.2.3 Config.BISysValue ........................................................................................................ 17







4.2.4 Loading Procedure ....................................................................................................... 18

5 Database Components .............................................................................. 19 5.1 Databases and Schemas ...................................................................................................... 19

5.1.1 Dispatching Database ................................................................................................... 19

5.1.2 MRM BI Database ......................................................................................................... 19

5.2 Formatters (Staging, Loading).............................................................................................. 20

6 Advanced Configuration and Administration ........................................... 20 6.1 Partitioned Views ................................................................................................................. 20

6.2 Internal Tables and Schema Build/Checks ............................................................................ 20

6.3 Custom Reporting Guidelines ............................................................................................... 21

6.4 Logging Tables .................................................................................................................... 22

6.4.1 Staging/Import Session logs ......................................................................................... 22

6.4.2 Information log ............................................................................................................ 24

6.5 Purging Procedures .............................................................................................................. 26

6.5.1 Staging Data ................................................................................................................ 26

6.5.2 Reporting data ............................................................................................................. 27

6.6 Indexing “Internal” Tables ................................................................................................... 27

6.7 Debugging ........................................................................................................................... 27

6.7.1 Debug Logging Levels .................................................................................................. 27

6.7.2 Custom Error Message ID’s .......................................................................................... 29

7 Appendix .................................................................................................... 30 7.1 Memory Configuration Guidelines ......................................................................................... 30

7.2 Inline Table-Valued Function (TVF) ...................................................................................... 32

7.3 Report Types ....................................................................................................................... 35

7.3.1 Route-centric Reports ................................................................................................... 35

7.3.2 Jobs-centric Reports ..................................................................................................... 50

7.3.3 Geocode Information.................................................................................................... 56

8 Document Management ............................................................................ 60 8.1 Document Control Table ...................................................................................................... 60







Document Conventions

This document uses the following conventions:

• Names of windows, frames, dialogs, menus, list boxes, and lists begin with

uppercase and are bolded. (Tools menu, Save button)

• Key combinations that you press appear in mixed case. If the keys are joined by a plus sign (+), press and hold the first key simultaneously with the remaining keys (for example, CTRL+ALT+DEL).

• Text that you type appears in Courier New font. (Enter USERID in the login

field.)

• Cross-references to other documents, or to sections within the current document, appear in underlined italics. (See Saving a File for details.)

• Italics are used for emphasis throughout this document.

Note— Information important to a particular task or function is introduced with the note format and icon.

Tip— Information that may make completing a task easier, but isn’t essential to the task, is introduced with the tip format and icon.

Warning— This warning format indicates information that you need to

pay particular attention to. Ignoring information presented as a warning could lead to damage and unexpected results. Disregarding information presented as a warning may result in damage to your software or data.







1 Introduction

1.1 Document Purpose

The purpose of this document is to provide an overview of the configuration of the Descartes® Mobile Resource Management Business Intelligence Database (MRM BI), a component of Descartes Route Planner™.

1.2 Intended Audience

• Client IT Team

• Client Database Management Team

• Client Security Team

• Descartes Management Team

• Descartes Professional Services Team







2 Requirements

2.1 Server Software/Hardware

2.1.1 LNOS Reporting Servers

• Intel® Xeon® Processor E3 or better

• Microsoft Corporation’s Windows Server® 2008R2 (64-bit) or 2012 R2 (preferred)

• 1.5 – 2 gigabytes (GB) RAM per vCPU, minimum 4 GB

• Disk Space 50 GB for data and logs

Note— Must be in the same or trusted domain as the database servers.

2.1.2 Database Server (DB, SQL)

• Intel® Xeon® Processor E5 or better

• 16 GB RAM (minimum)

• At least 30 GB of available disk space on system partition.

• Dedicated (separate) storage for Data, LOG and TempDB preferred.

• Size and Input/output operations per second (IOPS) requirements will vary per customer volume and throughput requirements.

• RAM requirements will also change, based on volumes, since Microsoft Corporation’s SQL Server operates better with more RAM.

• Windows® 2008 R2 operating system or Higher

• SQL Server SQL 2016, either standard or enterprise edition

Note— Must be in the same or trusted domain as the reporting servers, usually deployed on the same server as Descartes Route Planner™ (if non-hosted).







SQL/RP Compatibility Matrix

MR

M B

I V

ersio

n

SQL Server Version

2012 2014 2016

17.05 X X X

Note— It might be possible to run Descartes Route Planner on a higher version of SQL provided SQL compatibility level is configured to match the supported versions, however this is not guaranteed.

2.2 Client Hardware/Software

The current minimum requirements are as follows:

• Intel® Core™ i5 Processor or similar

• Microsoft Windows® 7 Professional (64-bit) or higher

• 4 GB DDR3-1600 RAM

• Internet Explorer® 9.0 or later (11 Preferred)

• Microsoft Edge® browser (Descartes Reported Services™ 17.05 and later)

• Google Chrome™ browser (Descartes Reported Services 17.05 and later)

2.2.1 Browser Configuration

Descartes Route Planner requires a few browser configuration changes to work correctly. It is recommended that these changes be pushed out through group policy to avoid user’s being required to individually configure their computers. Descartes Route Planner will function without these changes but the user’s may experience

irregularities or may not be notified of certain errors.

The three major configuration changes are:

• Setup site as a trusted site

• Setup site in compatibility mode

• Setup refresh on “Every visit to this webpage”







In addition, it is recommended to disable “Show Friendly HTTP Error Messages” so that more detailed messages are available to customer support.

2.3 SQL Installation Requirements

2.3.1 Memory Configuration

• SQL Server memory should be configured to use most of the memory available on the SQL Server; however, there should be a memory buffer to allow for

normal day-to-day user/operating systems.

• See the Memory Configuration Guidelines for best practices.

2.3.2 Disk Configuration

• Application Data files (MDF, NDF) should exist on a disk subsystem (LUN/Physical) separate from the operating system.

• Application Log files (LDF) should exist on a disk subsystem (LUN/Physical) separate from the operating system. Log files should be separated from the data

files as well.

• TempDB Data Files (NDF) should exist on a disk subsystem (LUN/Physical) separate from the operating system, Data & Log Files.

• Example of a properly configured 16-core SQL Server:

Drive Letter Disk Usage Example SQL File

C Windows OS & SQL Server Install *None*

G MRM BI Primary Data files MRM_BI.mdf

H MRM BI Staging Data Files MRM_BI_RPStaging.ndf

I MRM BI Log Files

TempDB Log Files

MRM_BI.ldf

tempdb.ldf

J TempDB Data Files (x4) Tempdb1..4.ndf

K TempDB Data Files (x4) Tempdb5..8.ndf

3 Solution Overview

3.1 Summary

Mobile Resource Management Business Intelligence (MRM BI) is a unified reporting database to represent the routing information from the various Descartes routing

products into a single unified structure.

At this time, the two products supported are Descartes Route PlannerTM and Descartes Route Planner OnDemandTM.







Data is extracted from the various routing systems through a series of procedures as described in the workflow below. This data is available for presentation through Descartes Reporting Services or can be used by other custom reporting packages. A set of standard Descartes Reporting Services reports and SQL views are available as

a template or framework to meet business objectives.

3.2 Terminology

3.2.1 Entities

The reporting database is grouped into several logical entities similar to the Descartes wGLN™ model of a route.

• Routing data

Route – Represents the logical representation of a series of tasks performed by a truck and/or driver

Stop – Represents a collection of activities performed at a place

Job – Represents an individual task consisting of a service or items (e.g. pickup, delivery, break, rest, etc.)

Location – Represents the place where a stop or job can occur. Can also be

the domicile location of a route/asset or a place where a route can go to load or unload items on the route.

• Asset data

Drivers – Crewmembers that can be associated with a route, one is

designated the Lead (Driver). Only the lead is tracked within the MRM BI database, however, a count of crewmembers is available at the route level.

Trucks – A tractor or straight truck for picking up or delivering goods that can be associated with a route

Trailers – A trailer (usually in combination with a truck/tractor) that can be associated with a route

• Organizational data

Partitions – A unique way of identifying where the data came from, e.g.

which database, which product, etc.

Org Units – A way to subdivide the data within a partition, e.g. a Schedule for Descartes Route Planner or a “Location” for Descartes Route Planner On-demand

Partition/OrgUnit Access – An extract of the dispatching system security configuration from which data is extracted, e.g. Schedule versus User Group associations for Descartes Route Planner or Location/Region associations for Descartes Route Planner On-demand







3.3 Workflow

The system uses a multi-step process to efficiently extract data from the dispatching system and then format the data into a standardized structure for reporting.

The following diagram illustrates this process:

3.3.1 Identifying Data to Extract

First, the system will identify which “key” records should be extracted for reporting (Route, Order). The records are retrieved along with all related entities by type

(Schedule, Order, Resource, Truck, Driver or Trailer) and the associated ID. There are several parameters to control the extraction of data.

• Filtered by Schedule

• Filtered by time “period” (e.g. older than a week, last week, last few days, etc.)

The process then identifies all the core reporting elements associated with the entities.

Identify Records to Extract

•Data is extracted in time periods

•Key Entities are identified (Routes & Orders)

Extract from Dispatch and

Stage in MRM BI

•All data related to the “Key” entities are extracted

•Data is partially-formatter before insertion

Loading from Stage to “Final”

tables in MRM BI

•Data receives further formatting

•Expensive computations are performed

Data is Summarized for

Reporting

•RPS utilizes views to summarize the data

•Users generate reports







3.3.2 Data Extraction for Reporting

Once identified, the data summary is then extracted into a staging table in the reporting database. The destination database or server is parameterized. If this database is not the SQL Server used by Descartes Route Planner, then it requires a

linked server connection to the reporting database server.

3.3.3 Loading the Data for Reporting

Once the data has been staged from Descartes Route Planner, the system is

designed to load the data into the final reporting schema tables and transition the data into “time period” tables.

3.4 Reporting

3.4.1 Descartes Reporting Services

For customers using Descartes Reporting Services, a set of pre-packaged Data Sources, Caches and Reports are available for use. These Data Sources, Caches and Reports should be used as templates if modifications are required; future upgrades

may update these items, removing any customizations.

Please see the Mobile Resource Management BI Database – Descartes Reporting Services Overview document for more details on these reports.

3.4.2 Reporting without Descartes Reporting Services

For customers using a product other than Descartes Reporting Services, a set of Data Sources are available. These Data Sources are contained in the Data Source schema of the MRM BI database. These Data Sources can be used as a template for

customization but should not be directly modified as they may be updated (replaced) by future upgrades of the application.

These data sources are:

• DataSource.BIAssetLastKnownLocation

Provides a per-asset (Truck, Trailer) dataset including key attributes as well as the last position and timestamp generated via mobile messaging.

• DataSource.BIRouteSummary

Provides a per-route dataset summarizing key planned, projected and actual metrics with one row per route.

• DataSource.BIRouteDetail

Provides a per-job dataset summarizing key planned, projected and actual metrics for both the route and job with one row per job.

• DataSource.BIOrderLookup

Provides a per-order dataset summarizing key properties of an order and its

associated jobs with one row per job.







4 Configuration & Maintenance

4.1 Dispatch System Database Configuration

Dispatch System Database Configuration refers to the database of the product used to “Dispatch” routes (Descartes Route Planner, Descartes Route Planner On-demand). The MRM BI database provides several tables to control the behavior of the system. All of these tables belong to the schema “BIStaging”. When querying these tables, the schema prefix must be provided.

4.1.1 BIStaging.BISysValue

This table contains the “System Values” configuration settings.

Setting Default Value Description

LoopbackServerName BILoopback Name of the linked server to use for

logging. Specified during the installation

process.

StagingDatabase MRM_BI Name of the database to which extracted

data is staged. Usually this database is

the same database that is used for

reporting.

StagingServerName NULL Name of the linked server to use for

connecting to the Staging database. If

null, system will assume the local server

(Default).

StagingCleanupProc BIStaging_RPCleanStagedData When performing an “update” system

looks for overlapping data. This process

will differ according to the dispatching

system and should not be manually

updated.

StagingValidateSchemaTableName BIStaging_RPOrder This table is used for the validation check

that is performed when connecting to the

staging database. This process will differ

according to the dispatching system and

should not be manually updated.

4.1.2 BIStaging.FWBIUdfExtractionList (Descartes Route Planner Only)

This table contains the list of user-defined fields (UDFs) that should be extracted. By default, all UDFs are disabled. Only UDFs relevant to reporting should be extracted to reduce the size of the reporting database and to ensure minimum data is transmitted

via linked server.

• DocumentType – Which entity for which the UDF is enabled/disabled.







• UDFString[1-9] – a BIT, when 1 the UDF will be extracted, when 0 the UDF will not be extracted (default).

• UDFInteger[1-3] – a BIT, when 1 the UDF will be extracted, when 0 the UDF will not be extracted (default).

• UDFNumber[1-3] – a BIT, when 1 the UDF will be extracted, when 0 the UDF will not be extracted (default).

• UDFDateTime[1-3] – a BIT, when 1 the UDF will be extracted, when 0 the UDF will not be extracted (default).

• UDFURL[1-3] – a BIT, when 1 the UDF will be extracted, when 0 the UDF will not be extracted (default).

4.1.3 BIStaging.BITimePeriods

This table contains the definition of how data should be chunked for extraction. Older time periods should be extracted less frequently. More “current” time periods can be extracted more frequently but should be a smaller range.

The following outlines the schema and default values:

TimePeriod FirstDayOffset LastDayOffset Description

-3 -180 -31 Data older than 30 days, up to 6 months, should not be

extracted more than once a week. Often is only done once

or following an upgrade.

-2 -30 -8 Data older than 1 week, should not be extracted more than

daily

-1 -7 -2 Data older then previous day, should not be extracted more

than 2-3x daily.

0 -1 3 Data from previous to next few days, typical is daily to

hourly.

1 4 7 Data more than a few days out, typical is daily to hourly

2 8 60 Data more than a week out, typical is daily

Note— Each time period defined requires a separate extraction job.

4.1.4 Customizable Columns

Certain columns in the application are customizable after deployment. These modifications are performed by altering the appropriate in-lined Table-Valued Function (TVF).

The “Filter Date” values referred to below are used to determine the internal table to

which data will be saved.







Business Order Key

The business order key is intended to provide a unique key that is meaningful to the business. By default, the business order key is the RootOrderKey for Descartes Route Planner and the Custom field for Descartes Route Planner On-demand.

This setting can be controlled by modifying the [BIStaging].[BIGetBusinessOrderKey_Inline] TVF in the dispatching system database.

Route “Filter Date” (Descartes Route Planner only)

The route date determines the date of the route and all the stops assigned to it for filtering purposes. By default, the route date is based on the EarliestStartDate.

This setting can be controlled by modifying the [BIStaging].[BIGetRouteTimePeriodDate_Inline] TVF in the dispatching system

database.

Unrouted Order “Filter Date” (Descartes Route Planner only)

The order date determines the date of the order when unassigned for filtering

purposes. By default, the order date is based on the CloseDateTime if provided otherwise it will use LatestDate.

This setting can be controlled by modifying the

[BIStaging].[BIGetOrderTimePeriodDate_Inline] TVF in the dispatching system

database.

4.1.5 Staging Procedure

The extraction of data is managed by the staging wrapper procedure, [BIStaging].[BIStagingTaskWrapper]. As described earlier, data can be scheduled for

extraction in multiple time slices controlled by the [BIStaging].[BITimePeriods] table

outlined above. Each time slice can be scheduled separately or can be called sequentially in a single script or by specifying the @LastTimePeriod parameter.

It requires a few parameters to operate:

Parameter Required? Description

@TimePeriod Required Which time slice of data to extract as defined by

[BIStaging].[BITimePeriods]

@LastTimePeriod Optional,

Default null

If specified the procedure will loop through @TimePeriod and @LastTimePeriod

performing each extract in sequence.

Note: All time periods will have the same SessionID

@SyncFilter Optional,

Default null

When provided will filter Org Unit’s data will be extracted. Uses standard “LIKE”

criteria (e.g. %, _, etc).

Route Planner: filters by ScheduleKey

OnDemand: filters by “Location” (OD Location, not MRM BI location)







@LastSync Optional,

Default null

When not null will extract only the entities that have been modified since the

@LastSync datetime provided.

Note: This feature is experimental. It should not be configured in production at

this time.

Note: This is not supported for OnDemand.

@TargetServer Optional,

Default null

If provided will override the StagingServerName defined in

BIStaging.BISysValue.

@TargetDB Optional,

Default null

If provided will override the StagingDatabase defined in


@ReturnRecords Optional,

Default 0

If set to 1, the ID’s of the entities being extracted will be output to the caller to aid

in troubleshooting.

4.2 Reporting Database Configuration Tables

4.2.1 Config.BIProducts

This table lists products that the system is aware of; this list was initially provided at

the time of installation and determined which staging tables can be loaded into the reporting tables.

Column Description

Product Product to load for reporting

IsOwning Determines whether the system can “own” the entities imported, only owning systems can delete

records.

DoImport Determines whether staged data for the product can be loaded into the reporting tables.

4.2.2 Config.BIProductsConfig

This table lists product-specific configuration parameters and determines the formatting of the data being loaded into the reporting database.

Product ConfigKey Values

RoutePlanner WglnAggregationMode -1 (Default) – Use NewStop to determine “Stop”

0 – Use no aggregation, each job is a “Stop”

1 – Aggregate by geostop+locationkey, similar to

wGLN







OnDemand TimeWindowJeopardyThresholdMin 15 (Default) – Number of minutes prior to close of the

window, this is a “warning”.

OnDemand TimeWindowOnTimeMode 1 (Default) – Job must both arrive and complete within the

time window to be considered on-time.

2 – Job must finish within the window but can

start prior to the window.

3 – Job must finish before the close of the

window, does not violate if prior to timewindow

start.

OnDemand CheckCapacityViolation 0 (Default) – Does not check for capacity violations.

Required for customers not tracking capacity.

1 – Checks if onboard capacity exceeds vehicle

capacity (Weight, Volume, Item)

4.2.3 Config.BISysValue

This table contains the list of global configuration values for the MRM BI reporting database.

Keyword Type & Default Value Description

MinPeriodToKeep INT: -12 Maximum number of months to retain

data (negative is in the past)

MaxPeriodToKeep INT: 3 Maximum number of months to retain

data (positive is in the future)

SetIOITableName INT: 0 When 1, the internal table rows are

updated with the tablename to aid

with debugging

LoopbackServerName STR: BILoopback When logging a loopback linked

server is required, this can be shared

between multiple instances of MRMBI.

This was provided at install time.

LoadingServerName STR: NULL Default server to load data into

(beta), it should point to itself.

LoadingDatabaseName STR: NULL Default database to load data into

(beta), it should point to itself.







4.2.4 Loading Procedure

The load of data into the reporting database is managed by the loading wrapper procedure, [BIStaging].[BILoadingTaskWrapper]. It can process a single Extract

Session/TimePeriod or it can be configured to process all unloaded sessions.



@ExtractSession Optional,

Default null

If specified will process the provided session only (and all its

associated timeperiods).

If null it will loop through all unprocessed sessions.

@ForceMode Optional,

Default 0

Controls behavior if the session has already been loaded.

0 - don't allow reprocess,

1 - allow reprocesss, skip delete

2 - reprocess & delete

@MaxSessionsToProcess Optional,

Default 0

When > 0 and there is multiple timeperiods for the session or the

session is not specified it will loop through only the number of sessions

specified.

@SkipInternalSchemaCheck Optional,

Default 0

When 0 it evaluates the Min/MaxTimePeriodToKeep and creates/drops

the internal tables as required, if the table exists it will automatically

create any missing indexes.

When 1 this step is skipped to accelerate loading time.

Note: If skipped the Schema check needs to be scheduled separately,

see (Internal Tables and Schema Build/Checks) in the advanced

configuration section for further details.

@BuildTableDebugLevel Optional,

Default 1

If provided it overrides the @DebugLevel when calling the Internal

Schema Check.

Note: only applies when @SkipInternalSchemaCheck is 0

@TargetServer Optional,

Default null

If provided will override the LoadingServerName defined in


@TargetDB Optional,

Default null

If provided will override the LoadingDatabase defined in


@ReturnRecords Optional,

Default 0

If set to 1, the ID’s of the entities being extracted will be output to the

caller to aid in troubleshooting.

@AutoCleanupStaging Optional, If specified > 0 after loading it will automatically cleanup old sessions.

It determines the @CleanupLevel when calling the purging procedure,







Default 0 see (Purging>Reporting data) in the advanced configuration section

for further details.

@AutoCleanupDaysToKeep Optional,

Default 30

If @AutoCleanupStaging is 1, determines the @DaysToKeep when

calling the purging procedure.

5 Database Components

5.1 Databases and Schemas

The MRM BI solution is comprised of two or more databases: the “Dispatch System” database which is associated with a Descartes routing product (e.g. Descartes Route

Planner, Descartes Route Planner On-demand) and the “MRM BI” database which is where the reporting data will be stored.

The databases are divided into several schemas for organizational and security purposes.

5.1.1 Dispatching Database

The solution will add an additional schema and associated functions/routines required to extract the data from the dispatching system.

BIStaging

This schema is used to contain all the elements required to support the MRM BI system, they are stored in a separate schema to avoid conflicting with the

dispatching system and can be used to restrict access to the accounts used for any transfers.

DBO, etc.

These schemas are used by the dispatching system and are not modified by the MRM

BI.

5.1.2 MRM BI Database

The MRM BI database is the warehouse where information is stored for reporting

purposes. The staging tables are associated with separate file groups to allow for data storage optimization.

It is composed of the schemas detailed in the following sections, 5.1.2.1 through 5.1.2.5.

Config

This schema is used to store all the tables and functions related to the Configuration for the MRM BI database.







Staging

This schema is used for staging tables and associated procedure/functions and it can be used to restrict access to the accounts used for staging data for reporting.

Internal

This schema is used for containing reporting data that is broken into one or more tables and unified through a DBO schema view.

DBO

This schema has the public facing tables/views used for reporting purposes.

DataSource

This schema has the pre-canned views used to extract the information from the reporting database that are used in Descartes Reporting Services.

5.2 Formatters (Staging, Loading)

The formatters are a series of inline TVF functions (see appendix for details) that are used to format the data prior to transferring the data from the dispatching system into the staging tables/database or from the staging tables into the reporting tables/database. These functions have been designed to minimize the workload in the dispatching system database. These should not be directly modified as they will

be updated/replaced with future upgrades of the BI solution.

6 Advanced Configuration and Administration

6.1 Partitioned Views

All the entities are exposed for reporting through the use of a views in the DBO schema. Entities that are date driven (Route, Stop, Job, Order) are using a special type of view called a partitioned view. The partitioning is done on a field called

VC_FilterStartDate. This field allows SQL Server to identify for a given request which internal tables need to be referenced for the query.

For more information on partitioned views please refer to the following Microsoft

TechNet article:

https://technet.microsoft.com/en-us/library/ms190019(v=sql.105).aspx

6.2 Internal Tables and Schema Build/Checks

Each of the entity views are tied to one or more tables in the Internal schema. These table are intended for internal use and should not be directly queried for reporting as they are rolling. Over time, the tables will be deprecated as new tables are being created.

This process is managed by the [Config].[BIBuildAllPeriodTables] stored procedure.

This stored procedure is called automatically by the BILoadingTaskWrapper procedure unless the @SkipInternalSchemaCheck property is configured. If that is


https://technet.microsoft.com/en-us/library/ms190019(v=sql.105).aspx






the case, the stored proceudre needs to be scheduled to run at least once a month, before the Loading Procedure has been called in order to avoid failures or incomplete loads.



@DropExisting Optional,

Default 0

When enabled, all “internal” tables are dropped prior to execution allow them

to be recreated. This is intended for testing only.

@IOISetTableName Optional,

Default 0

When enabled an extra step is enabled in the IOI/IOU entity view triggers to

populate the column PartTableName, this does impact performance so should

only be enabled for debugging or in a test environment.


Default null

If provided, will associate its info log to the provided session, it is not used

to determine which session should be cleaned up.

6.3 Custom Reporting Guidelines

The MRM BI system is intended to provide a baseline of useful reports for various industries. However, it is likely that MRM BI will not meet every business requirement. If modifications to the data source views are required, they should be

performed in copies of the sources rather than in the original sources to avoid having the modifications overwritten by future upgrades. Adding new columns is no different from other packages. However, when creating new views from scratch or joining in data from other views, additional care must be taken to maintain performance and to

ensure data correctness in the application.

All joins should be done using the Entities Key field, although there are columns in the database with the “ID” from the originating dispatching system that are not indexed and are intended for internal use only. In addition, since there could be multiple sources of data, the PartitionID must be included. All indexes are based on both the PartitonID + the EntityKey. In addition to these two primary keys, when joining between date-driven entities (Route, Stop, Job, Order), the VC_FilterStartDate column should be included. This allows SQL Server to

determine which tables are relevant to the data in question and are critical to performance.







Entity Primary Keys Partitioned Entity?

Route PartitionID, ResourceKey Yes

Stop PartitionID, StopKey Yes

Job PartitionID, DispatchJobKey Yes

Order PartitionID, OrderKey Yes

Driver PartitionID, DriverKey

Truck PartitionID, TruckKey

Trailer PartitionID, TrailerKey

6.4 Logging Tables

The MRM BI has two logging tables. The first is its session processing log, which contains information on what data has been staged/loaded and its current state. The

second is a debug “information log” where debugging statements are recorded when @DebugLevel > 0 or a failure occurs (Severity > 0 in the log).

Each session/step can have one of three results:

• 1ST – Starting

• 2OK – Step completed successfully

• 3FL – Step failed to complete

To tell the Loading wrapper to ignore the session by convention: SKP

The list of stages are:

• 1 – Staging Started

• 2 – Staging in progress

• 3 – Staging Completed

• 4 – Loading Started

• 5 – Loading in progress

• 6 – Loading Completed

The BIStagingWrapper takes the session from stage 13 and the BILoadingWrapper takes the session from Stage 36

6.4.1 Staging/Import Session logs

The staging/import session logs are accessible via two views:

• [Staging].[ExtractSessionSummary]

This view contains a summary of the sessions. It has one row per session plus

time period.

Example data is provided in the table below:







ExtractID 1

ExtractSession 331DD532-5E12-4311-BB43-3195F0F1C98A

Product OnDemand

TimePeriod 0

SyncStage 6

SyncStageDesc Loading-Completed

SyncItem NULL

Result 2OK

ResultMessage Okay

StagingStart 27:18.3

StagingMin 2.9

LoadingStartTime 56:05.0

LoadingDelayMin 325.9

LoadingMin 0.4

LoadingAttemptCount 1

SyncFilter NULL

TimePeriodDaysDesc -2 to 2

TimePeriodStartNumDays -2

TimePeriodEndNumDays 2

• [Staging].[ExtractSessionDetail]

This view providers further details of the sessions and the steps taken in processing that session.

Example data is provided in the table below:

ExtractID 1 1


Product OnDemand OnDemand

TimePeriod 0 0

CurrentStage 6 6

CurrentStageDesc Loading-Completed Loading-Completed

StagingStart 6:27:18 PM 6:27:18 PM







StagingMin 2.9 2.9

LoadingMin 0.4 0.4

LoadingAttemptCount 1 1

SyncStage 2 5

SyncCategory Staging Loading

SyncStageDesc Staging-Extracting-Stops Loading-Transferring-Order

SyncItem Stops Order

ItemStart 10:27:27 PM 11:56:15 PM

ItemEnd 10:29:29 PM 11:56:18 PM

ItemDurSec 123 4

Result 2OK 2OK

ResultMessage Okay - Update/Refresh: 741

Remove: 0

Okay - Added: 0 (0 sec)

Updated: 662 (3 sec)

Deleted: 0 (0 sec)

Linking: 0 sec

6.4.2 Information log

When @DebugLevel is provided as a value greater than 0 in the stored procedures, execution steps will be logged in the Information Log. If there is a failure, it will also be written to the Information Log automatically.

The information log can be queried at [Log].[BIInfoLog].

See Debug Logging Levels for what each DebugLevel will make eligible for logging.

See







Custom Error Message ID’s for MessageID 50,000 and higher in the BIInfoLog

Example data:

LogID 6852 6853 6854 6855

LogDate 11:56:55 PM

RowCount 0 0 0 0

LogLevel 2 1 3 1

Severity 6 10 0 10

MessageID 50400 50400 50000 50000

ExtractSession 957F0B9F-826E-4DC6-AE29-3873E63D38E2

SPName Staging.BI_Transfer

Data_Partition

Staging.BI_Transfer

Data_Partition

Staging.BILoading

TaskWrapper

Staging.BILoading

TaskWrapper

Message Unable to Get/Set

PartitionID, checking

staging table to

verify partition

record exists!

Failed while processing

(null) - (null), Error: Unable

to Get/Set PartitionID,

checking staging table to

verify partition record

exists!

Enter Final Catch... Loading session

957F0B9F-826E-4DC6-

AE29-3873E63D38E2

Encountered error in

BI_TransferData_Partition

at line 149 [50400:

Unable to Get/Set

PartitionID, checking

staging table to verify

partition record exists!]

In addition, a view is provided which combines the Staging/Import session log with the InfoLog to aid with investigation. It can queried at [Staging].[ExtractSessionDetailWithLog].

Example data:

ExtractID 1


Product OnDemand

TimePeriod 0

CurrentStage 6

CurrentStageDesc Loading-Completed

StagingStart 18:27:18

StagingMin 2.9

LoadingMin 0.4







LoadingAttempt

Count

1

SyncStage 2

SyncCategory Staging

SyncStageDesc Staging-Extracting-Orders

SyncItem Orders

ItemStart 22:27:26

ItemEnd 22:27:27

ItemDurSec 0

Result 2OK

ResultMessage Okay - Update/Refresh: 662 Remove: 0

LogID 1839 1840 1841 1842 1843 1844

LogDate 22:27:26 22:27:26 22:27:26 22:27:26 22:27:26 22:27:26

LogLevel 1 1 2 2 2 1

Severity 0

MessageID 50000

spname Staging.BIStaging_SetProcessingStage

Message Starting... Completed

Parameter

Validation

old extract,

finding parent

record

old extract, updating

parent record

adding

history

record

Ending...

6.5 Purging Procedures

The MRM BI has built-in cleanup mechanisms for both the staging and reporting tables.

6.5.1 Staging Data

The staging data cleanup is performed automatically following a loading task (default) or can be scheduled independently. This process is controlled by the stored procedure [BIStaging].[BICleanupLog]



@CleanupLevel Required Determines how much data should be removed.

1 removes log entries for succesfull imports only







2 removes the data for all log entries

@ DaysToKeep Required Determines how many days in the past data should be retained for.


Default null

If provided, will associate its info log to the provided session, it is not used

to determine which session should be cleaned up.

6.5.2 Reporting data

The reporting data is automatically cleaned up based on the Config.BISysvalue > MinDaysToKeep parameter. As each month passes, the next “internal” table is generated for each BI Entity and the oldest table is automatically dropped. This process is triggered when the Loading Procedure is called and is managed by the

[Config].[BIBuildPeriodTable] procedure.

6.6 Indexing “Internal” Tables

If additional indexes are required to support custom queries, they need to be added

to the [Config].[BIPeriodTableDefParts] table. This table is used in the construction

and maintenance of the Internal schema tables.

Any custom entries should be added with a “Seq” of 1000 or higher to avoid conflict with future core changes.

The following table outlines each of the columns of this table:

Column Description

Entity This column contains the primary named entity for which a index should be added.

Component This determines what type of component will be added to the table after construction (Constraint,

Index, etc)

Seq The sequence in which components should be created.

Name A descriptive name for the component

ComponentDef A query used to create the appropriate component ~EntityPeriodTable~ will be replaced by the

appropriate table name prior to construction of the component.

6.7 Debugging

All stored procedure support a @DebugLevel parameter. This parameter controls how

much information will be displayed to the user and will be logged to the [Log].[BIInfoLog] table.

6.7.1 Debug Logging Levels

DebugLevel Description







0 no logging

1 minimal logging

2-4 more logging, query sizes, etc

5 logging primary queries

6 logging helper queries (e.g. column list)

7 logging schema queries (e.g. build table)







6.7.2 Custom Error Message ID’s

MessageID Description

50000 Generic failure

50100 Parameter validation failure

50200 Internal validation failure

50300 Internal build schema failure

50400 Internal processing failure

50500 Formatter/target table columns not found

50600 Dynamic SQL query is null

50700 Entity Configuration problem

50800 No data found to stage

50900 Internal trigger fail







7 Appendix

7.1 Memory Configuration Guidelines

The following table provides general recommendations for memory usage on an x64 database server (assuming no other components are enabled):

Physical Server Memory SQL MaxServerMemory

2GB 1500

4GB 3200

6GB 4800

8GB 6400

12GB 10000

16GB 13500

24GB 21500

32GB 29000

48GB 44000

64GB 60000

72GB 68000

96GB 92000

128GB 124000

If using other applications or SQL components, additional buffer should be provided. The requirements will vary by environment. The following table provides an outline of target memory utilization (under load):

Physical Server Memory Target Available Memory in Task Manager

< 4GB 512MB – 1GB

4GB – 32GB 1GB – 2GB

32GB – 128GB 2GB – 4GB

> 128GB > 4GB

You can use T-SQL to set your MaxServerMemory setting. The sample below sets it to 3500, which is the equivalent of 3.5 GB. This setting is dynamic in SQL Server







2005/2008/2012, which means that you can change it and it goes into effect immediately, without restarting SQL Server.

-- Turn on advanced options

EXEC sp_configure'Show Advanced Options',1;

GO

RECONFIGURE;

GO

-- Set max server memory = 3500MB for the server

EXEC sp_configure'max server memory (MB)',3500;

GO

RECONFIGURE;

GO

-- See what the current values are

EXEC sp_configure;

You can also change this setting in the SSMS GUI, as you see below:







7.2 Inline Table-Valued Function (TVF)

A TVF is a function that returns a table of values similar to a subquery. An inline TVF is a special type of TVF in SQL Server. Scalar functions and non-inline TVF functions

are not costed in the execution plan evaluation. This means if they are complex (e.g. many sub lookups, etc.) SQL Server will underestimate the cost of using them and can come up with a poor quality plan that takes significantly more CPU or IO.

Here is an example of an inline TVF:

create FUNCTION [BIStaging].[BIGetRouteTimePeriodDate_Inline_Filter]

( @RouteID int, @FirstDay int, @LastDay int )

RETURNS TABLE

AS

RETURN (

SELECT datediff(d, CONVERT(DATE, getdate()), LatestEndDate) [DaysFromToday]

, LatestEndDate [TimePeriodDate]

FROM FWResource WITH (NOLOCK)

JOIN FWRoute WITH (NOLOCK)

ON FWResource.ResourceID=FWRoute.ResourceID

WHERE FWRoute.RouteID = @RouteID

and (

-- doing the function manipulation (dateadd) on the constant

-- is crucial to performance!

(

LatestEndDate >= convert(date,DATEADD(d,@FirstDay,getdate()))

and LatestEndDate < convert(date,DATEADD(d,@LastDay+1,getdate()))

)

OR (@FirstDay is null or @LastDay is null)

)

)

The defining points of an inline TVF are the use of the RETURN (…query…) syntax

with no work being done outside the …query… section.

Performance Tips:

If the query contained in the TVF uses joins or subqueries, it is important to include any parameters in the filters/joins/subqueries as early as possible to help SQL Server know which data is relevant to the remainder of the function.

For example:

-- slower

select FWStop.StopID,FWRoute.ResourceKey, FWStop.StopNumber, …

from FWStop

JOIN FWRoute on FWStop.RouteID=FWRoute.RouteID

JOIN …

JOIN …

WHERE FWStop.RouteID=@RouteID AND …







Vs

-- faster

select FWStop.StopID,FWRoute.ResourceKey, FWStop.StopNumber, …

from FWStop

JOIN FWRoute on FWStop.RouteID=FWRoute.RouteID AND FWStop.RouteID=@RouteID

JOIN …

JOIN …

WHERE …

Function manipulation should always be performed on the constant portion of the

where/join clauses. If they are performed on the table-portion, it prevents SQL Server from being able to use the indexes and will force scans rather than seeks, reducing the overall performance of the system.

For Example:

-- Fast (Seek)

WHERE (

LatestEndDate >= convert(date,DATEADD(d,@FirstDay,getdate()))

and LatestEndDate < convert(date,DATEADD(d,@LastDay+1,getdate()))

)

VS

-- Slow (Scan)

WHERE (

datediff(d,convert(date,LatestEndDate),getdate())

between @FirstDay and @LastDay

)







Here is the analysis from SQL Server of the two clauses above. Notice the “slow” version is 92 percent of the batch or 11.5 times more work than the “fast” version. On small datasets, this difference is negligible but on large datasets it can be significant.

-







7.3 Report Types

This section details the different types reports and all fields associated with each report. There are three types of reports:

• Route-centric

• Job-centric

• Geocode Information

7.3.1 Route-centric Reports

BI_Monthly Planning Route

This report explains the utilization of the routes based on number of stops, capacity (Measure 1) and time. It also contains information for cost, number of stops and distance.

Field Name Definition

OrgUnitName (Hide & Run-Time) Organizational Unit Name. Used to filter data

SourceName (Hide & Run-Time) Name of the database where data is coming from. Used to filter data

AppOrgName (Hide & Run-Time) Company identifier. Used to filter data

Filter Date (Hide & Run-Time) Start date. Used to filter data

BusinessOrgUnitName This field represents the Organizational Unit (Schedule in Descartes Route Planner™,

FK_tblLocation in Descartes Route Planner On-demand, etc.). In parenthesis is the number or records (routes) that belong to this field.

InitialLocationKey The initial location at which the route begins. In parenthesis is the number or records (routes) that belong to this field

Year Year where data is coming from. In parenthesis is the number or records (routes) that belong to this

field.

Month Month where data is coming from. In parenthesis is the number or records (routes) that belong to this

field.

# of Routes Total number of routes available

# Used Routes Number of routes used based on number of jobs

# Empty Routes Number of unused (empty) routes based on number

of jobs







% Used Routes Percentage of used routes from total number of

routes available

% Empty Routes Percentage of unused routes from total number of routes available

Available Time (Hr) Total available time the used routes have

Planned Time (Hr) Time allocated in planning for the used routes

Unused Time (Hr) Time not allocated in planning from the total

available time

% Planned Time Percentage of time planned from the total available time

% Unused Time Percentage of time not used from the total available time

Available Resource Measure 1 Available capacity for Measure 1 (Capacity of vehicle

multiplied by the number or recharges)

Planned Measure 1 Dropoff Dropoff planned capacity planned

Unused Measure 1 Dropoff Unused capacity for measure 1 in Dropoff

% Planned Measure 1 Dropoff Percentage of planned Measure 1 from total Dropoff

% Unused Measure 1 Dropoff Percentage of unused Measure 1 from total Dropoff

Planned Measure 1 Pickup Pickup planned capacity planned

Unused Measure 1 Pickup Unused capacity for measure 1 in Pickup

% Planned Measure 1 Pickup Percentage of planned Measure 1 from total Pickup

% Unused Measure 1 Pickup Percentage of unused Measure 1 from total Pickup

Profile Cost Cost of the route

Planned # Jobs Planned number of geographical stops that the vehicle makes

Planned # Stops Planned number of deliveries

Planned Miles Planned number of miles per route

Average Distance per Job Average distance, in miles, per job







BI_Monthly Route Last Report Status

This report depicts the number and percentage of routes that have each different status as their las report status.






Usage (Hide and equal to 1) Usage equal to 1 means that the route is used as opposed to empty

BusinessOrgUnitName This field represents the Organizational Unit

(Schedule in Descartes Route Planner, FK_tblLocation in Descartes Route Planner On-

demand, etc.). In parenthesis is the number or records (routes) that belong to this field

InitialLocationKey The initial location at which the route begins. In

parenthesis is the number or records (routes) that belong to this field

Year Year where data is coming from. In parenthesis is

the number or records (routes) that belong to this field

Month Month where data is coming from. In parenthesis is


# Routes Number of routes used based on number of jobs

# Pending Routes Number of routes with pending as their last

reported status

% Pending Routes Percentage of routes with pending as their last reported status from the total number of assigned

routes

# Arrived Routes Number of routes with arrived as their last reported

status

% Arrived Routes Percentage of routes with arrived as their last reported status from the total number of assigned

routes







# Completed Routes Number of routes with completed as their last

reported status

% Completed Routes Percentage of routes with completed as their last reported status from the total number of assigned

routes

# Exception Routes Number of routes with exception as their last reported status

% Exception Routes Percentage of routes with exception as their last reported status from the total number of assigned routes

# Missed Routes Number of routes with missed as their last reported status

% Missed Routes Percentage of routes with missed as their last

reported status from the total number of assigned routes







BI_Monthly Publish Routes

This report shows the number and percentage of routes that are created (not published), published or changed after published.



SourceName (Hide & Run-Time) Name of the database where data is coming from.

Used to filter data



Usage (Hide and equal to 1) Usage equal to 1 means that the route is used as opposed to empty



demand, etc.). In parenthesis is the number or records (routes) that belong to this field


parenthesis is the number or records (routes) that belong to this field






# Routes Created (Not Published) Number of routes with a publish status of created

% Routes Created (Not Published) Percentage of routes with a publish status of

created from # of used routes

# Published Routes Number of routes with a publish status of publish

% Published Routes Percentage of routes with a publish status of publish from # of used routes

# Routes Changed After Published Number of routes with a publish status of changes

after publish

% Routes Changed After Published Percentage of routes with a publish status of publish

from # of from # of used routes







BI_Monthly Alerts by Route

This report shows the number of routes that had any of the listed (12) alerts.

Field Name Description





Usage (Hide and equal to 1) Usage equal to 1 means that the route is used as

opposed to empty

BusinessOrgUnitName This field represents the Organizational Unit (Schedule in Descartes Route Planner,

FK_tblLocation in Descartes Route Planner On-demand, etc.). In parenthesis is the number or records (routes) that belong to this field

InitialLocationKey The initial location at which the route begins. In parenthesis is the number or records (routes) that belong to this field

Year Year where data is coming from. In parenthesis is the number or records (routes) that belong to this field


field


Capacity Exceeded Violation Number of routes with the given alert

% Capacity Exceeded Violation Percentage of routes with the given alert from total number of used routes

Commodity Violation Number of routes with the given alert

% Commodity Violation Percentage of routes with the given alert from total

number of used routes

Job Late Violation Number of routes with the given alert







% Job Late Violation Percentage of routes with the given alert from total


Job Early Violation Number of routes with the given alert

% Job Early Violation Percentage of routes with the given alert from total number of used routes

Location Capacity Exceeded Violation Number of routes with the given alert

% Location Capacity Exceeded Violation Percentage of routes with the given alert from total


Near Window Close Warning Number of routes with the given alert

% Near Window Close Warning Percentage of routes with the given alert from total number of used routes

Related Previous Job Violation Number of routes with the given alert

% Related Previous Job Violation Percentage of routes with the given alert from total


Requirements Violation Number of routes with the given alert

% Requirements Violation Percentage of routes with the given alert from total number of used routes

Route Late Or Too Many Hours Violation Number of routes with the given alert

% Route Late Or Too Many Hours Violation Percentage of routes with the given alert from total


Served Before Available Violation Number of routes with the given alert

% Served Before Available Violation Percentage of routes with the given alert from total number of used routes

Too Many Stops Violation Number of routes with the given alert

% Too Many Stops Violation Percentage of routes with the given alert from total number of used routes

Wrong Sequence Violation Number of routes with the given alert

% Wrong Sequence Violation Percentage of routes with the given alert from total number of used routes







BI_Monthly Planned vs Actual

This report shows the difference between the planned and the actual quantities measured.

Note— All the delta quantities are calculated as planned minus actual.


Usage (Hide and equal to 1) Usage equal to 1 means that the route is used as

opposed to empty

OrgUnitName (Hide & Run Time) Organizational Unit Name. Used to filter data

SourceName (Hide & Run Time) Name of the database where data is coming from.

Used to filter data

AppOrgName (Hide & Run Time) Company identifier. Used to filter data

Filter Date (Hide & Run Time) Start date. Used to filter data


(Schedule in Descartes Route Planner,

FK_tblLocation in Descartes Route Planner On-

demand, etc.). In parenthesis is the number or

records (routes) that belong to this field


parenthesis is the number or records (routes) that

belong to this field

DriverKey Database Identifier of the driver record


the number or records (routes) that belong to this

field



field

DriverName Driver first and last name

ResourceKey Database Identifier of the Route record

PlannedNumberofStops

NumberofStops

Delta Number of Stops







PlannedNumberofJobs

NumberofJobs

Delta Number of Jobs

PlannedMiles

ActualMiles

Delta Distance

PlannedMeasure1Dropoff

ActualMeasure1Dropoff

Delta Measure 1 Dropoff

PlannedMeasure1Pickup

ActualMeasure1Pickup

Delta Measure 1 Pickup

PlannedTravelTime

ActualTravelTime

Delta Travel Time

Planned Work Time

Actual Work Time

Delta Work Time

Planned Parking Time

Actual Parking Time

Delta Parking Time

Planned Packup Time

Actual Packup Time

Delta Packup Time







BI_Monthly Service Time Compliance – Histogram of Service Time Compliance


Usage (Hide) Usage Text where Is Equal to : ‘Used’



Used to filter data




FK_tblLocation in Descartes Route Planner On-demand, etc.). In parenthesis is the number or


InitialLocationKey The initial location at which the route begins



field


field



# Routes Total number of used routes

Planned vs Actual Service time < -40%

Planned vs Actual Service time -20 to -40%




Planned vs Actual Service time -1 to 1%

Planned vs Actual Service time 1 to 5%




Planned vs Actual Service time < 40%







BI_Monthly Driving Time Compliance – Histogram of Driving Time Compliance





Used to filter data









field


field



# Routes Total number of assigned routes

Planned vs Actual Driving Time < -40%

Planned vs Actual Driving Time -20 to -40%




Planned vs Actual Driving Time -1 to 1%

Planned vs Actual Driving Time 1 to 5%




Planned vs Actual Driving Time < 40%







BI_Monthly Distance Compliance – Histogram of Distance Compliance





Used to filter data









field


field




Planned vs Actual Distance < -40%

Planned vs Actual Distance -20 to -40%




Planned vs Actual Distance -1 to 1%

Planned vs Actual Distance 1 to 5%




Planned vs Actual Distance < 40%







BI_Monthly Late Start Compliance – Histogram of Late Start Compliance





Used to filter data









field


field




Planned vs Actual Late Start < -40%

Planned vs Actual Late Start -20 to -40%




Planned vs Actual Late Start -1 to 1%

Planned vs Actual Late Start 1 to 5%




Planned vs Actual Late Start < 40%







BI_Monthly Late End Compliance – Histogram of Late End Compliance





Used to filter data









field


field




Planned vs Actual Late End < -40%

Planned vs Actual Late End -20 to -40%




Planned vs Actual Late End -1 to 1%

Planned vs Actual Late End 1 to 5%




Planned vs Actual Late End < 40%







BI_Monthly Stop Sequence Compliance - Histogram of Sequence Compliance





Used to filter data









field


field




Planned vs Actual Stop Sequence < -40%

Planned vs Actual Stop Sequence -20 to -40%




Planned vs Actual Stop Sequence -1 to 1%

Planned vs Actual Stop Sequence 1 to 5%




Planned vs Actual Stop Sequence < 40%







7.3.2 Jobs-centric Reports

BI_Jobs Assignment




Used to filter data





demand, etc.). In parenthesis is the number or



field


field

# Days

# Jobs

# Assigned Jobs

# Jobs not Assigned

% Assigned Jobs

% Jobs not Assigned







BI_Jobs Jobs Location Type




Used to filter data








field


field

# Days

Total # Jobs

# Assigned Jobs

# Customer

% Customer

# Depots

% Depots

# Lunch

% Lunch

# Breaks

% Breaks

# Rests

% Rests

# Fuel

% Fuel







BI_Jobs Jobs Type




Used to filter data








field


field

# Days

Total # Jobs

# Assigned Jobs

# Delivery

% Delivery

# Delivery (Complex)

% Delivery (Complex)

# Final

% Final

# Initial

% Initial

# Locationless

% Locationless

# Pickup

% Pickup

# Pickup (Complex)

% Pickup (Complex)

# Recharge

% Recharge







BI_Jobs Jobs Alerts




Used to filter data








field


field

# Days

# of Jobs

# Assigned Jobs

Capacity Exceeded Violation

% Capacity Exceeded Violation

Commodity Violation

% Commodity Violation

Job Late Violation

% Job Late Violation

Job Early Violation

% Job Early Violation

Location Capacity Exceeded Violation

% Location Capacity Exceeded Violation

Near Window Close Warning

% Near Window Close Warning

Related Previous Job Violation

% Related Previous Job Violation

Requirements Violation

% Requirements Violation

Route Late Or Too Many Hours Violation







% Route Late Or Too Many Hours Violation

Served Before Available Violation

% Served Before Available Violation

Too Many Stops Violation

% Too Many Stops Violation

Wrong Sequence Violation

% Wrong Sequence Violation







BI_Jobs Jobs Status




Used to filter data








field


field

# Days

# Jobs

# Assigned Jobs

# Arrived

% Arrived

# Pending

% Pending

# Completed

% Completed

# Locationless

% Locationless

# Exception

% Exception

# Missed

% Missed







7.3.3 Geocode Information

BI_Geocode Source and Score Summary




Used to filter data




(Schedule in Descartes Route Planner, FK_tblLocation

in Descartes Route Planner On-demand, etc.). In



Year Year where data is coming from. In parenthesis is the

number or records (routes) that belong to this field



field

GeocodeScore

# Jobs

# Routes

# Days

AvgAutoCorrectVsPlacedLocationDistance

StDevAutoCorrectVsPlacedLocationDistance

AvgGeocodeVsPlacedLocationDistance

StDevGeocodeVsPlacedLocationDistance

AvgStatusVsLocationGeoDistance

StDevStatusVsLocationGeoDistance







BI_Geocode Flags




Used to filter data



Year Year where data is coming from. In parenthesis is the

number or records (routes) that belong to this field



field

Geocodeflags

BusinessOrgUnitName This field represents the Organizational Unit (Schedule in Descartes Route Planner, FK_tblLocation in Descartes Route Planner On-demand, etc.). In



# Jobs

# Routes

NumTotal

# Days







BI_Geocode Daily Summary




Used to filter data




field



field



(Schedule in Descartes Route Planner,


demand, etc.)

VC_FilterStartDate

GeocodeSource

GeocodeScore

# Jobs

# Routes

# Days













BI_Geocode Source and Score Detail




Used to filter data




field


field

GeocodeSource

GeocodeScore



demand, etc.)

# Jobs

# Routes

# Days













8 Document Management

8.1 Document Control Table

Version Date Author Comment

1.0 06/06/2017 Justin Marshall Initial Draft

1.1 07/21/2017 Justin Marshall Updates to TVF Appendix, completed product summary, added workflow diagram. Removed installation requirements (moved to install guide).


U S E R A N D C O N F I G U R A T I O N G U I D E Mobile ... · U S E R A N D C O N F I G U R A T I...

Documents

Transcript of U S E R A N D C O N F I G U R A T I O N G U I D E Mobile ... · U S E R A N D C O N F I G U R A T I...