Route Optimiser Extended Import File Guide v1 - dps-int.se Optimiser... · Conventions Defining the...

Route Optimiser Extended Import File Guide v1.7

Route Optimiser Extended Import File Guide v1.7 Page 1

Contents

Revision Control 3

Introduction 4

Conventions 4

Getting Started 5

Field List 5

Field Header Notes 11

Action 11

Order ref 11

Order type 11

Call name 12

Address lines 12

Zip code 13

Banveh 13

Bandays 13

Book time 14

Zone 14

Pair or Tramping 14

Group 17

Sequence 17

Position 17

Uninterrup 17

PrefDep/Territory 17

Product types 18

Priority 18

Cust Info 19

Bays 19

Shadow 19

Depot group 19

Depname 19

DepFleet 19

Shelf_Life 20


Stock 20

MVAttrib 20

Options 20

XVAttrib 22

Options 22

ProdNum & Quantity 22

Worktime 22

EXTENDED RECORD TYPES 23

Type “D” – Depot upload 23

Type “V” – Fleet availability 24

Type “H” – Auto header 26

Route upload 27

Type “J” – Summary Upload 28

Type “S” – Schedule Upload 29

Type “Z” - Zone import 33

Zone Type 1 33

Zone Type 2 33

Zone Type 3 34

Type “Q” - Hours import 34

Type “F” - Shift import 36

Type “I” – Vehicle type import 36

Type “P” – Products 37

Creating an Import File 39

Sample import file 39


Revision Control

Revision Date By Details

1.0 05/10/15 Mohammad Arif

Initial version – Content taken from Interface Suggestions v46


Record field added to ‘J’ record Import


MaxServe added to the “Q” table


Stock added to “I” type records


Import format corrected for the cost fields on the “I” record


DepGroup and DepName removed as importable Task columns


Stock removed from “I” record types and replaced by ProdBans


Added extra address columns STREET, SUBURB, DISTRICT, CITY, TOWN, STATE, COUNTY, PROVINCE, REGION and COUNTRY

Added more notes to the ‘H’ record section.


Introduction

Route Optimiser relies upon two sets of data to complete the scheduling process, firstly there are the user configurable Parameters and secondly, the variable order data that needs to be imported.

This imported data contains details of your deliveries and collections and includes such information as the address and opening times of your orders. This needs to be compiled in a file format that Route Optimiser can interpret and import successfully.

Route Optimiser can read and import various types of files such as ASCII, XLS and DBF, however the most commonly used file format is Comma Separated Values (.CSV), where by each piece of information for an order is separated by a comma. The benefit of using this format is that it can be created and edited using spreadsheets and databases such as Excel and Lotus. In this format field headers are used at the top of each column to represent a data field in Route Optimiser. Cells under the headers are then populated with the relevant information with each row being dedicated to a separate order. Each line is therefore treated as a separate Record.

How the import file is created will very much depend on your company’s internal structure.

The data might be generated by an external data source such as a Sales Order Management System or Transport Management System or you might have to personally create the import file from scratch each time you create a new Profile. Either way certain headers must be included for Route Optimiser to recognise the data as orders and import them successfully.

Conventions

Defining the goal or identifying the reason why an action or activity should take places.

Throughout the document, this type of highlight identifies key notes.

Impact points identify where caution needs to be used. It may seem a great idea to

run the top level of detail, and the most detailed set of requirements, however if this

is taken too far then there may be a negative IMPACT on the result.

Where possible we will make a recommendation

INI settings


Getting Started

This section describes how to create a simple import file using the basic field headers enabling you to begin importing as soon as possible. Even if the import file is generated for you automatically it is still worth reading this section so that you have a good understanding of the required field headers, the reasoning behind their inclusion and how to create one should you ever be required to do so.

Useful points regarding the import file to bear in mind are:

Blank headers or headers not listed below can be used if you want to include data in your

import file for other purposes but do not want Route Optimiser to import it.

If fields are not required they can be omitted rather than included and left blank.

Fields can appear in any sequence in the import file but it will help support if you follow

the sequence in the table below.

Different record types can be mixed in a single import file or separate files for each typed

can be created if required.

The CSV files can be of the following types:

Address (call point) records

Task (order) records

Combined Task and Address records

Depot records

The type of file being imported is determined by the content of the TYPE field. For Address records this should be ‘A’, for Task records ‘T’. The absence of a TYPE field or a blank TYPE record indicates a combined Task and Address record.

The basic field headers are listed in the table below along with a brief description and the permitted values. Columns in your import file should appear as they are written here otherwise Route Optimiser may not recognise them. You can include columns with different headers in your file but Route Optimiser will simply ignore them. As an absolute minimum the import file must contain the ORDERREF and ORDERTYPE fields along with an address field such as POSTCODE or ADDRESS in order to locate the order you are importing.

Field List

The table below shows all potential import fields and which types of record they are appropriate for.

Key: = mandatory

O = optional

Blank = not appropriate


VALID FOR

NAME SIZE TYPE DESCRIPTION CO

MB

INE

D

OR

D O

NL

Y

AD

DR

ON

LY

DE

PO

T

TYPE 1 String Record type - if omitted combined order assumed. Permitted values: A – Address record C – Calls D – Depot record E – Trailer types F – Shifts H – Auto Header record I – Vehicle types J – Summary upload K – Driver M – Motive Asset N – Trailer Asset P -- Products Q – Hours R – Daily resource availability S – Schedule upload T – Task (order) record V – Vehicle availability record Z – Zone

Blank – combined address/task record

Type field must precede any product fields

ACTION 1 String Record action - if omitted action A(dd) assumed. Permitted values:

A – add record

D – delete record C – change record (changes the fields as passed leaving any other fields in tact) U – update record (removes current record and replaces it with current import content)

O O O O

CALLREF 12 String Call point reference number. Must be unique for each delivery/collection address (or for each customer at an address if you need to differentiate at this level) within a work area

Not applicable to ORDERTYPE “B” records see below.

O

ORDERREF

12 String Order reference. Must be unique for each order record within a work

area

A maximum of 11 characters should be used for the order number

in case Route Optimiser needs to append a single character

identifier.

ORDERTYPE

1 String Order type. Permitted values:

C – collection

D – delivery

B – Both (used for tramping as a simpler alternative to pair numbers. Also requires extra fields as detailed in the “Pair” section). Cannot be used in conjunction with CALLREF


VALID FOR


MB

INE

D

OR

D O

NL

Y

AD

DR

ON

LY

DE

PO

T

CALLNAME 40 String Customer name.

ADDRESS1 30 String First line of record address, can include house number O O O

ADDRESS1/STREET

30 String Second line of record address O O O

ADDRESS2/SUBURB/DISTRICT

30 String Third line of record address O O O

ADDRESS3/CITY/TOWN

30 String Fourth line of record address O O O

POSTCODE/ZIPCODE

10 String Postcode/zip code O O O

COUNTRY 3 String ISO Code number, or the Two or Three character codes for the country

BANVEH 15 String Banned vehicles. Permitted values:

A to O to link with vehicle groups as set in parameters. For example, to only allow vehicle type B if A, B, C, and D the entry should be ACD

O O

VEHICLE 1 String Imposed vehicle type for this order. Permitted values: A to O to link with vehicle groups as set in parameters

O O

BANDAYS 8 String Closed days. O O

OPEN1 4 String Opening time of time window 1

In 24 hour, hh:mm format, e.g. 01:35, 23:50 Window 2 must not overlap window 1 If both windows are omitted the address will be assumed to be open 24 hours If only one time window is required, window 2 can be omitted or left blank Zero is taken to mean midnight – do not use zero to represent no time window

O O O

CLOSE1 4 String Closing time of time window 1

O O O

OPEN2 4 String Opening time of time window 2

O O O

CLOSE2 4 String Closing time of time window 2

O O O

BOOKTIME 4 String Booking time in 24 hour, hhmm format, e.g. 01:35, 23:50 O O

BOOKDAY 1 Integer Booked day. Permitted values:

Day number 1 to 7 where 1 = Monday,

2 = Tuesday, etc

O O

ZONE 4 Integer Zone number, used for fixed route planning O O

PAIR 4 Integer Pair number used for tramping. O O


VALID FOR


MB

INE

D

OR

D O

NL

Y

AD

DR

ON

LY

DE

PO

T

REVENUE 10 Float Imposed revenue O O

GROUP 4 Integer Used to group orders to ensure they are scheduled together, i.e. Booking number

O O

SEQUENCE

3 Integer Sequence of calls within a route O O

UNINTERRUP

1 Boolean T = calls within a group CANNOT have other calls between them

F = calls within a group CAN have other calls between them

O O

SHELF_LIFE

2 Integer Maximum number of shifts in transit, i.e. shelf life on the vehicle. Can also be set as hours

O O

POSITION 1 Integer Position can work in two mutually exclusive modes 1) Imposed position on trip. Permitted values: 1 – first in trip 2 – last in trip 0 or blank – any position 2) Trailer mode (must be running in trailer mode, and have PositionAsFB= true set in PL.INI) 1 – order must go on the front unit 2 – order must go on the trailer unit 0 or blank either unit

O O

WORKSPEED

3 Integer Percentage adjustment applied to work time O O

WORKTIME 4 Integer Imposed work time at the call point in minutes

Can be minutes, 1/10ths or 1/100ths based on PL.INI setting

WorkTimePlaces

Maximum time 1440 minutes (24hours)

O O

WORKSECS

6 Integer Imposed work time at the call point in seconds O O

DEPTIME 4 Integer Imposed work time at the depot in 1/10ths of a minute O O

DEPOTSECS

6 Integer Imposed work time at the depot in seconds O O

FIXTIME 4 Integer Fixed time spent at the call point in minutes

Maximum time 1440 minutes (24hours)

O O

FIXEDSECS

6 Integer Fixed time spent at the call point in seconds O O

PREFDEP/TERRITORY

20 String Depot or depot group from which the order must be served using either the depot name or group letter as set in parameters or through the import fields

O O

PROD1 5 Integer Quantity of product 1 on the order


VALID FOR


MB

INE

D

OR

D O

NL

Y

AD

DR

ON

LY

DE

PO

T


For further information on product types see

following notes

O O

up to O O


O O

PRIORITY 1 Integer Order priority from 1 to 9 with 1 being the highest priority. If omitted or left blank, defaults to 5.

O O

CUST_INFO1

40 String Customer information/comments O O

CUST_INFO2


CUST_INFO3


CUST_INFO4

40 String The first character (numeric) can be used to indicate the number of loading bays available at a customer’s site

O O

CUST_INFO5


PHONE 20 String Customer telephone number O O

DEPCAP1 12 Float Maximum throughput per shift period - load unit 1 O

DEPCAP2 12 Float Maximum throughput per shift period - load unit 2 O

TOTCAP1 12 Float Maximum throughput total – load unit 1 O

TOTCAP2 12 Float Maximum throughput total – load unit 2 O

STOCK 26 String Defines what product types can be handled by a depot or vehicle type (PL.INI setting ProductTypes must be yes)

O

CATEGORY

1 Integer Depot category. Permitted values: 1 to 7 where the value is the total of

1 – garage 2 – trip start 4 – trip end

Therefore, if a depot is a garage and trip start the value is 3. If the field is omitted or blank, a value of 7 is assumed

O

ETC_HOUR 11 Float Estimated transport cost per hour O

ETC_KM 11 Float Estimated transport cost per distance unit O

SUPP_COST1

11 Float Estimated transport cost per load unit 1 O

SUPP_COST2

11 Float Estimated transport cost per load unit 2 O


VALID FOR


MB

INE

D

OR

D O

NL

Y

AD

DR

ON

LY

DE

PO

T

DEPFLEET String Usage varies dependant on record type H – used to import Auto planning settings V – used to import the available fleet

BAYS 2 Integer Number of loading bays at a location (See notes) O O

SHADOW 6 Integer Shadow time in minutes before a vehicle can re-use a bay (See notes)

MVATTRIB 32 String Used to allow certain vehicle types to service this order O

XVATTRIB 32 String Used to ban certain vehicle types from servicing this order O

PRODNUM 2 Integer The product number to which the Quantity value applies to O

QUANTITY 5 Integer Quantity of product on the order O

FirstDOP 10 String First Date/Day of Plan – when the order can be collected or delivered O

LastDOP 10 String Last Date/Day of Plan – when the order can be collected or delivered O


Field Header Notes

Below is a list of additional information for any header outlined that needs further clarification due to the function(s) performed.

Action

The action taken by import once the record has been read- if omitted action A(dd)

assumed. Permitted values:

A – add record

D – delete record

C – change record (changes the fields as passed leaving any other fields intact)

U – update record (removes current record and replaces it with current import content)

When using change records, the following fields can be cleared by passing a string

containing only “_” underscore characters

Address fields

Cust_Info fields

PrefDep/Territory

Delete records are processed before Add, Change or Update records

Order ref

The “order ref” is used by Route Optimiser to identify orders, and therefore must be

unique within a work area. The “order ref” is 12 characters case insensitive i.e. “A12” is the

same as “a12”.

It is recommended that only the first 11 characters be used. When tramped orders are

imported as single type “B” orders, Route Optimiser outputs 2 records one for the

collection and one for the delivery these are identified by the addition of a “C” or “D” to

the end of the Order ref.

If other non-unique order reference numbers are required, they can be transferred via “Cust Info” fields.

Order type

Order type. Permitted values:

C – collection

D – delivery

B – Both (used for tramping as a simpler alternative to pair numbers.)

All fields for both collection and the delivery of the tramped order can be imported as one record using the B order type field. In this case, standard field headers relate to the delivery side of the order and those for the collection side have a suffix of C (e.g. ADDRESS1C, OPEN1C). Fields that are common to both sides of the order (e.g. those that are order rather than address related such as ORDERREF, PROD1) use the standard header and only appear once.

When tramped orders are imported as single type “B” orders, Route Optimiser outputs 2

records one for the collection and one for the delivery these are identified by the

addition of a “C” or “D” to the end of the Order ref.


Added a setting called ReadCollectionFields to PL.INI. Current values are 0 (default) or 1.

If the value is 1 then for records of Order Type 'C' the engine will expect to find the data

for records in the 'C' header columns (e.g. ADDRESS1C, CUSTINFO2C etc). The references

will NOT have a 'C' suffix appended as would be the case for 'B' order type records.

Call name

The customer name field does not affect the scheduling calculations made by Route

Optimiser, but can be used with the grid reference to group orders together within a

route. Orders are planned based on their geographical details i.e. longitude and latitude,

most often calculated from the postcode or address details. Single postcodes can cover

a number of addresses, and you do not want to wander between houses within a

postcode, therefore Route Optimiser will group by the Customer name field when the

longitude and latitude are the same for a number of orders.

Careful formatting can benefit the user, it is the key visual guide to an order when it is displayed on a route so it is important to make it meaningful. For example, if you deliver to a string of restaurants called Tesco it may be that the name is passed only as that, so if a route delivers to restaurants in Leicester, Nottingham and Derby the route listing will read

Tesco

Tesco

Tesco

This is meaningless to the user. It is therefore worth considering adding other information to the name, either by setting it up differently on the originating system or combining it with other fields such as town or postcode when creating the data for Route Optimiser.

Address lines

When using change records, the Address fields can be cleared by passing a string


You may choose to have a single header for Address or multiple as below: -

Field Name Max Size

Address1 ADDRESS1 30




Postcode POSTCODE/ZIPCODE 10

Where multiple fields are identified, they will be automatically combined for location purposes. The address fields will be scanned for location information, which may be in the form of a recognised map reference as postcode or town name. For the record to be located either address information in (any style) OR Latitude & Longitude must be given.

Route Optimiser plans based on the co-ordinates of the address. If the co-ordinates are

not supplied by the interface then an approximation can be made from the address data.

As an example of how we can locate a customer, the following entries all point, with varying degrees of accuracy, to D.P.S' Head Office:

B62 postal district (zone)

Halesowen, West Midlands. literal address

B62 8 postal sector


B62 8AN full postcode (See section on Zip code)

SO 9684 4-figure UK grid reference

SO 968843 6-figure UK grid reference

25262 9191 Easting and Northing

3968 2843 8-figure UK grid reference

52.456 -2.047 latitude/longitude (degrees)

52:27.36n 2:2.82w lat/long (degrees:minutes)

52:27:22n 2:2:49w lat/long (degrees:mins:secs)

Route Optimiser decides which data to use based on confidence levels, the smaller the area defined by the data the higher the confidence level.

To locate orders, the map database contains a gazetteer of place names.

Orders that cannot be located to the required confidence level are rejected and can be

manually corrected within Route Optimiser.

Zip code

Postcodes can be supplied at one of three levels

B62 post zone

B62 8 post sector

B62 8AN full postcode

Banveh

Vehicle groups that cannot access this address. Group letters need to be consistent with parameters. For example, if an 18T vehicle is set up as group A, a 7.5T as group B and a Van is set as group C, an order for a location that could not accept an 18T and a Van vehicle would have a BANVEH of AC. If this information is not known or is not necessary this field can be omitted.

Banveh should contain a list of vehicle groups onto which the order cannot be planned

i.e. ABCFMO.

Bandays

The Bandays field lists the days on which the order cannot be delivered i.e. you define

the CLOSED DAYS.

Definition of Days is Monday = 1, Tuesday = 2 etc.

For example.

1) A delivery can be made any day Monday to Friday: BANDAYS = 67

2) A Delivery can ONLY be made Tuesday: BANDAYS = 134567

If more detail is required, the recommended method is to prefix the field with a P and use the following values for each day (Monday is the first day):

0 - open all day

1 - Closed for the first time window

2 - Closed for the second time window

3 - Closed all day


These values work in conjunction with those in OPEN1/CLOSE1/OPEN2/CLOSE2.

Given the following data on an order line

OPEN1 0800

CLOSE1 1300

OPEN2 1400

CLOSE2 1800

BANDAYS P0001023

Therefore, if a customer can be delivered to all week except for Thursday morning, Saturday afternoon and all day Sunday, the following values could be used:

Or put another way

BANDAYS Meaning

P Use day listing

0 Monday, open all day

0 Tuesday, open all day

0 Wednesday, open all day

1 Thursday, closed 08:00 to 13:00

0 Friday, open all day

2 Saturday, Closed 14:00 to 18:00

3 Sunday, closed all day

Book time

Under most circumstances Route Optimiser is used to calculate routes, but not for the management of the route once it has started. The addition of actual dates and times to the order data allows Route Optimiser to re-plan based on what has already been completed and asses the feasibility of the remaining route.

For example the expected time of arrival may be 14:10, the actual time of arrival could be 16:35, meaning the driver is running 2 hours 25 minutes behind schedule. The addition of the 16:35 in the “book time” field allows Route Optimiser to reschedule the route knowing the actual time, then calculate the effect on the remainder of the route. This gives the planner the ability to adjust the plan as required, or update customers with a revised ETA.

Zone

Although Route Optimiser is a dynamic planning tool, many customers still like to subdivide their work into zones or fixed routes before planning. These Zone names are then used to group the orders on to trips, and forms part of the route name.

Zones numbers can range from 1 - 9999

Pair or Tramping

Route Optimiser has the capacity to run in a mode that we call "tramping", which allows a collection and delivery pair to be specified. In an example case, a route would leave the depot in Tamworth deliver through Northamptonshire and finish in Huntingdon. The vehicle


then travels to Cambridge and collects a full load order. This collection order has already been fixed by the user to be delivered to Coleshill. Having completed this it returns to the depot in Tamworth. These orders are linked together via their respective Order References.

In this case, the “Order type” field should be B (Both) as each line in Spreadsheet represents BOTH a Collection AND Delivery.

Tramping import files can be set in one of two ways:

The collection and delivery can be imported as two separate, standard records with the

same value in the pair field. Pair numbers do not have to be sequential and can have a

value up to 9999. They must be unique to a tramping pair within a work area.

All fields for both collection and the delivery of the tramped order can be imported as

one record using the B order type field. In this case, standard field headers relate to the

delivery side of the order and those for the collection side have a suffix of C (e.g.

ADDRESS1C, OPEN1C). Fields that are common to both sides of the order (e.g. those that

are order rather than address related such as ORDERREF, PROD1) use the standard

header and only appear once. The following fields are added to the interface for

collections when “B” type orders are used :-

CALLNAMEC BANVEHC BANDAYSC CLOSEDC OPEN1C CLOSE1C OPEN2C CLOSE2C ZONEC SEQUENCEC ADDRESSC ADDRESS1C STREETC ADDRESS2C CITY2C/SUBURBC/DISTRICTC ADDRESS3C CITYC/TOWNC ADDRESS4C STATEC/COUNTYC/PROVINCEC/REGIO

NC POSTCODEC ZIPCODEC COUNTRYC CUSTINFO1C CUSTINFO2C CUSTINFO3C CUSTINFO4C CUSTINFO5C PHONEC BOOKTIMEC WORKTIMEC DEPTIMEC FIXTIMEC REVENUEC INTFLAGC BOOKDAYC WORKSPEEDC ROUTEC

WORKSECSC FIXEDSECSC DEPOTSECSC FIRSTDOPC LASTDOPC

16

How To…Template - Contents

The following is a list of example of a single line tramped header.

ACTION

ORDERREF

ORDERTYPE

CALLNAME

ADDRESS_1

ADDRESS_2

ZIPCODE

BANVEH

OPEN1

CLOSE1

BOOKDAY

PROD1

PROD2

CUST_INFO1

CALLNAMEC

ADDRESS_1C

ADDRESS_2C

ZIPCODEC

BANVEHC

OPEN1C

CLOSE1C

BOOKDAYC

CUST_INFO1C

A Ord_1 B Delivery name

Delivery Road

Delivery town

Del_Pcode 900 1730 1 7 8

Delivery notes 1

Collection name

Collection Avenue

Collection town

Col_Pcode 900 1630 1

Collection notes 1


Group

One example of the usage of the group field would be when a number of orders must be collected as one job under a customer supplied booking number. This way Route Optimiser will endeavour to keep all the orders with the same booking number on the same route.

In the case of a “tramped” order, it might be collected under one booking number and

then delivered under another. This is a reason for using “tramped pairs”.

As Group numbers are limited to 4 digits, and as multiple customers could decide to use the

same booking number, it is recommended that the Group number be translated to a unique

number for the given workarea.

Sequence

If a plan is to be resent to Route Optimiser for review or update, it is essential that the sequence number is supplied to Route Optimiser. In certain circumstances, a route will evaluate differently the second time around. The addition of a single order with a time window on it could cause the route to run in reverse, Sequence numbers prevent this from happening as the scheduling engine can be told to obey the sequence, even if this results in a less efficient route.

Position

Position can work in two mutually exclusive modes.

Trip position, which is the default, whereby the position flag can force auto to make an order the first or last on a trip: - 1 – first in trip 2 – last in trip 0 or blank – any position

Or the optional Trailer mode. If you have PositionAsFB= true set in the PL.INI, then the usage of the position flag changes 1 – order must go on the front unit 2 – order must go on the trailer unit 0 or blank – either unit

Uninterrup

If you want a group of orders to be kept together within a route and for other groups to not split the route then uninterrup need to be T(rue).

ObeySequence must be switched on otherwise Import will ignore this column

PrefDep/Territory

If an order is to be completed by a particular depot the depot name must be passed in the “PrefDep” or “Territory” field. The name must be identical to that set within the Route Optimiser parameters.

When using change records, the PrefDep/Territory field can be cleared by passing a string



Product types

Product type fields relate to the products set up in parameters. Therefore, if you have two products you only need to import PROD1 and PROD2 fields. For each product defined within the master work area, there must be a corresponding product in the import file. Product numbers are allocated sequentially within Route Optimiser

Route Optimiser has the ability to express vehicle capacity in two user definable units i.e.

the user chooses if they are m3, kgs, pallets, garments etc. Route Optimiser can then take;

the values passed in the Product fields and using a user-defined multiplier establish the

size. The loading and unloading times are calculated in a similar manner.

If multiple product values are sent for a given order the effect on the planning unit is

additive.

NB the PROD fields are integers. If your source values have decimal places use the

following multipliers:

1 decimal place multiply by 10

2 decimal places multiply by 100

3 decimal places multiply by 1000

Reverse factoring can then be set up in parameters so that the correct original value is

displayed.

Priority

Priority is used to determine which orders are delivered when resources are limited. If resources are unlimited, then all orders will be scheduled and Priority has no effect. However, if some orders must be delivered (for example they are Next Day or Specific AM deliveries they could be Priority 1) while others "could be delivered” if there is sufficient time and/vehicle capacity (for example 3 days service level and this is the first day) then these would have be Priority 2. In the calculations Route Optimiser will deliver all Priority 1 orders then use any excess capacity to deliver Priority 2, 3 etc in sequence.

Priority works in Auto scheduling by attempting to plan all the highest priority orders first, moving to the next level and so on. The impact of this is that if the highest priority represents a small proportion of the total order pool, the scheduling results may not be what you expect. If not carefully controlled the use of priorities can have a detrimental effect on the plan’s overall efficiency.

Although there are 9 levels of priority using all of them could fragment automatic

scheduling so it is recommended that if possible only 3 levels are used. Also it is a

good idea not to automate the use of levels 1 and 9 as this would not allow the

possibility of a manual override in extreme circumstances. Therefore in layman’s terms

the following could be used:

Priority 3 – jobs that must be done in this schedule.

Priority 5 (or field left blank) – jobs that should be considered to be done in this

schedule.

Priority 7 – jobs that can be readily deferred to a later schedule if there are not

sufficient resources available.

It is recommended that if you are contemplating having different levels of priority, you

approach it from the perspective of setting a lower priority on the orders that are less important

rather than giving a higher priority to an ‘elite’ set of orders.

As the default value is 5, anything from 1 to 4 is of higher priority; anything from 6 to 9 is lower.


Cust Info

These are additional fields for free format data concerning either the specific customer or order. These fields are limited to 40 characters.

When using change records, the Custinfo fields can be cleared by passing a string


If working with CSV files use “}” as a delimiter

Bays

Bays allow you to set the number of vehicles that can be at a customer or depot at the same time. They work in conjunction with Shadows, which sets the period for which the bay must be empty before it can be reused.

Shadows cannot be used with extend opening

For Shadows to work, you must have Multiple Route Evaluation switched on.

Shadowed orders must all have the same time windows.

See shadows

For Bays to have an effect, the PL.INI settings Loadingbays=yes, must be set.

Shadow

Shadows work in conjunction with Bays. Shadow, sets the period for which a bay must be empty before it can be reused.

Shadow time is defined as a period after the vehicle has departed during which the bay is classed as being in use. It is used to prevent all orders being planned onto one vehicle and Route Optimiser inserting waiting time.

Shadows can be used to force orders to be delivered to the same location apart.

Shadows cannot be used with extend opening.

For Shadows to work, you must have Multiple Route Evaluation switched on.

Shadowed orders must all have the same time windows. - See bays.

For Shadow to have an effect the order must have bays set. The PL.INI settings,

Loadingbays=yes, must be set.

Orders with shadow times set, cannot be consolidated with other orders

Depot group

A depot can be a singular, or part of a group, therefore an order with a depot group attached can be serviced by any depot within the group. This gives Route Optimiser the capability to produce the best collection and delivery plan leaving the trunk to be planned separately.

Depname

Used in conjunction with DepFleet, must be a valid Route Optimiser depot name as set in Route Optimiser parameters.

DepFleet

The usage of the “DepFleet” field is dependent on the record type. In all cases, the “DepName” field must be populated with the depot name as set within the Route Optimiser parameters.


Shelf_Life

The Shelf life, time on a route can be defined in terms of Shifts, Hours or minutes as defined by PL.INI settings.

ShelfLife for tramped orders is calculated as being from the arrival time of the collection to

the departure time of the delivery.

For deliveries, the time is calculate as the arrival time at the depot, to the departure time of

the order.

For collections, the time is calculated at the arrival time at the order, to the departure time

at the depot.

Where order is stated in the above it means the arrival/departure time for the given order,

not the call.

Stock

Requires ProductTypes to be on in the PL.INI

The Stock field is applicable to depot and vehicle type records and defines which product types can be handled by a given depot or vehicle type. When left blank, the depot or vehicle type is assumed able to handle any product.

The field can be populated in one of two ways:-

As a series of letters, where A = Product1, and X = Product24 therefore ABC, means the depot or vehicle type can only handle products 1,2 and 3

As a bit pattern where 1 = Product1, 128 = Product 8 therefore 7, means the depot or vehicle type can only handle products 1,2 and 3

MVAttrib

MVATTRIB is an import header used for importing data.

The MVATTRIB field is used to allow certain vehicle types at a specific customer.

The profile must contain a definition of the vehicles used within the fleet i.e. capacity speed etc. As part of this data it is possible to allocate Vehicles to vehicle attributes i.e. having materials handling, tail lift, open vehicle, small van etc. These vehicle types are used to establish the available fleet for a given order i.e. a cardboard box cannot go on an open vehicle.

Vehicle Attributes functionality has the same effect as Access Groups, and may also be used

in combination with Access Groups.

Vehicle Attributes can be named by the user and max amount is 32, while Access Groups

are named with a letter (A-O) and max amount is 16.

Options

MVATTRIB ranges from 1-32

Use numbers 1-9 (attributes 1-9) and letters A-W (attributes 10-32) to represent each attribute. List the characters without spaces or punctuation. So, for example, to include attributes 2, 8, 11, 14, 21 you would use 'MVATTRIB' as the header and then input '28BEL'.

Applicability

Optional value for combined Order, Address and Vehicle Type records.

Remarks

MVATTRIB should contain a list of vehicle attributes onto which the order can be planned.

https://dpsintltd.sharepoint.com/DPSwiki/Scheduling%20Functions/Access%20Groups.aspx


The opposite XVATTRIB should contain a list of vehicle attributes onto which the order cannot be planned.


XVAttrib

XVATTRIB is an import header used for importing data.

The XVATTRIB field is used to ban certain vehicle types at a specific customer.

The profile must contain a definition of the vehicles used within the fleet i.e. capacity speed etc. As part of this data it is possible to allocate Vehicles to vehicle attributes i.e. having materials handling, tail lift, open vehicle, small van etc. These vehicle types are used to establish the available fleet for a given order i.e. a cardboard box cannot go on an open vehicle.

Vehicle Attributes functionality has the same effect as Access Groups, and may also be used

in combination with Access Groups.

Vehicle Attributes can be named by the user and max amount is 32, while Access

Groups are named with a letter (A-O) and max amount is 16.

Options

XVATTRIB ranges from 1-32

Use numbers 1-9 (attributes 1-9) and letters A-W (attributes 10-32) to represent each attribute. List the characters without spaces or punctuation. So, for example, to include attributes 2, 8, 11, 14, 21 you would use 'XVATTRIB' as the header and then input '28BEL'.

Applicability

Optional value for combined order records and address records.

Remarks

XVATTRIB should contain a list of vehicle attributes onto which the order cannot be planned.

The opposite MVATTRIB should contain a list of vehicle attributes onto which the order can be planned.

ProdNum & Quantity

In quite a few cases, orders are for only one product type. A products override has been introduced which makes use of the existing PRODNUM column (previously only for Product 'P' type records) and includes a new QUANTITY column. If on an order type record the PRODNUM column contains a valid Product type number and the QUANTITY column has a value in it which is greater than -1 then all product quantities for other products on the order will be set to 0, (to remove them from TASKSIZE if they exist) and just one TASKSIZE record added (or deleted if QUANTITY is 0) for the specific product.

ProdNum and Quantity are not output as part of the Userout fields.

It should be that we can mix and match between entries on some orders with a PRODNUM

and QUANTITY entry and other orders with PROD1, PROD2. PROD3 etc values.

Worktime

The number of minutes to deliver or collect the order. This will override the variable element of collection or delivery time set in parameters. It is most often used to force a non-standard time on a job that is known to differ significantly from the average.

http://www.dps-int.se/dpswiki/index.php?title=Access_Groups




https://dpsintltd.sharepoint.com/DPSwiki/Input%20Data/MVATTRIB.aspx


EXTENDED RECORD TYPES

The following record types allow for greater control over scheduling, even allowing for the ability to define routes and pass them to Route Optimiser or a Route Optimiser server component for evaluation.

Please note that the “Usage” given below, is for example purposes. The exact definition can

be found in the user manuals and help texts for Parameters.

If any of the optional fields are left blank, the prevailing defaults will be used. Due to

legislative changes that may take place in the future, these default values may vary from

version to version.

Type “D” – Depot upload

A typical usage of this record type is if you have Drivers who start their next day’s work at or near where they finished the current days’ work.

The fields used are as follows, definitions of these files can be found above. Where multiple field names are listed in the table, these represent the options available.

If you include a row where TYPE = D, ACTION = D and Name=******** (8x*), then all Depot

records are deleted at the start of the import.

Lat longs can be passed as part of the address data.

Field Mandatory Usage

Type Yes D to indicate Depot record

Action No A for add

Name Yes Depot name

DepNum Yes DepNum is mandatory for LogiXIE, and must be a unique identifier

Address Address1 Address2 Address3 Address4 Postcode

Yes You can choose to use a single line for the address or multiple lines. The same address searching options that apply to order addresses apply to depot addresses. Where multiple fields are identified, they will be automatically combined for location purposes. The address fields will be scanned for location information, which may be in the form of a recognised map reference as postcode or town name. For the record to be located either address information in (any style) OR Latitude & Longitude must be given

Phone No

Custinfo1 No

Custinfo2 No

Custinfo3 No

Custinfo4 No

Custinfo5 No

Open1 No Depot opening time 1

Close1 No Depot Closing time 1

Open2 No Depot opening time 2

Close2 No Depot Closing time 2

Bandays No Sets the working days/period

DepCap1 No Daily throughput limit for the Primary unit

DepCap2 No Daily throughput limit for the Secondary unit


Field Mandatory Usage

DepCap3 No Daily throughput limit for the Tertiary unit

TotCap1 No Total capacity in primary unit for the planning period

TotCap2 No Total capacity in secondary unit for the planning period

Category No Depot category. Permitted values: 1 to 7 where the value is the total of 1 – garage 2 – trip start 4 – trip end Therefore, if a depot is a garage and trip start the value is 3. If the field is omitted or blank, a value of 7 is assumed

DepGroup No Single character Depot group

StartDep No Amount of admin minutes at the start of the depot

TurnDep No Amount of admin minutes at the turn of the depot

EndDep No Amount of admin minutes at the end of the depot

Stock No Import a letter corresponding to the prods (A = prod1, B = prod2, etc) to denote that stock is available at the depot.

ETCHour No Transport cost per hour

ETCKm No Transport cost per Km

SuppCost1 No Depot supply cost primary unit

SuppCost2 No Depot supply cost secondary unit

Bays No Number of loading bays at the depot

Shadow No Loading bay shadow in minutes

Type “V” – Fleet availability

The DepFleet field is used to pass a variable number of data items separated by a “}” character.

For example, if we wanted to tell Route Optimiser there are 40 drivers available, with a fleet of 35 vehicles of type “7.5T” and 10 vehicles of type “HGV” then the following data would be sent to Route Optimiser in the DepFleet field.

40}7.5T}35}HGV}10

It is important to ensure that the vehicle names used are the same as those set in the Route Optimiser vehicle parameters.

Unlimited fleet is sent through as a –1.

As the underlying availability data is recreated each time, Delete action is not supported

“DepName” field must be populated with the depot name as set within the Route Optimiser

parameters.

Must be used in conjunction with the “H” record.

Field Mandatory Type Size Usage

Type Yes Char 1 V to indicate Fleet Availability record

Action No Char 1 A for add

DepName Yes Char 20 Used to identify the depot

DepFleet Yes Char N/A Defines fleet availability by vehicle type – see notes above


Type “H” – Auto header

Not available within LogiXIE

H records will only update LogiXIE.ini and Auto will obey this (important to remember for

API).

The GUI will read from PL.ini [Auto32] section so this can look different and when you click

save it will save the settings it’s showing into LogiXIE.ini too so the display and scheduling

settings are then consistent.

If you want the display and scheduling settings to be consistent then you have two options.

o Import H and G records with the same settings.

o Import the scheduling parameters via the ROXML (API only) and this will write

to PL.ini and LogiXIE.ini with what it’s just read in.

Again the “}” character is used to separate the individual data items held within the DepFleet field.

1}1}0}4}-1}-1}AUTO}3

The above can be decoded as follows

Value Usage Options

1 Planning day 1 = Monday 2 = Tuesday etc…

1 Planning period 1 = Single day 2 = 2 days etc. 7 = Full Week

0 Max nights 0 = no overnights 1 = maximum of 1 overnight per trip 2 = maximum of 2 overnights per trip etc.

4 Max trips 1 = 1 trip per route 2 = 2 trips i.e. 1 return to depot to reload per route etc

-1 Collection at end -1 = collections can be mixed with deliveries 0 = collections must be done after deliveries

-1 Fixed fleet size -1 = free fleet 0 = fixed fleet

AUTO Route name prefix

Used by auto as the prefix for route names, 4 characters or fewer

3 Auto Mode 1 = Reschedule 2 = Pre-allocated routes 3 = Continue schedule 4 = Add to existing 5 = New routes only preserve all 6 = Re-optimise routes 7 = Extend 8 = Spread It is not possible to indicate which routes should be handled in continue, add to existing or preserve modes. Therefore, if mode 4, Add to existing is chosen, all routes are available to be added too

As the underlying availability data is recreated each time, the Delete action is not supported


Route upload

The Route Optimiser Auto scheduling engine can be used with other applications for a variety of purposes

Single route evaluation Route building ETA calculations Production of qualified alerts Dynamic work load balancing Ad-hoc / emergency work planning

In the above examples the user may use an existing system to Load build and maintain the routes but wish to benefit from the power of the Route Optimiser Auto engine, as such it must be possible to pass not only the order data, but also the current status of the plan.

Based on an empty workarea, the order data, as defined above can be imported, the routes as they stand now can then be added, this includes the ability to lock (dispatch) orders (or task such as a rest break) on a route. A dispatched route or order cannot be modified by Auto, if actual Times and distances are added, then Auto can be used as a “re-evaluation engine”. By adding actual arrival and departure times to the dispatched Schedule record, you can overrule the values as calculated by Auto.

For example if we take the following route at the schedule level

Task Travel time

Expected Start time

Expected Duration

Expected End time

Time window Status

Depot start ---- 07:00 15 mins 07:15 ---- 2

Delivery 1 30 mins 07:45 20 mins 08:05 07:45 – 10:00 2



Depot end 47 mins 17:47 15 mins 18:02 ---- 2

The above route or multiple routes can then be sent through to auto, however actual times and distances can be added

Task Actual Travel time

Actual Start time

Actual Duration

Actual End time

Time window Status

Depot start ---- 06:50 20 mins 07:10 ---- 3



Delivery 3 210 mins 14:56 wait 4 mins

90 mins 16:30 15:00 – 18:00 2

Depot end 47 mins 17:17 15 mins 17:32 ---- 2

In the above table, the cells marked light blue contain the updated actual data. The cell marked orange indicates where Auto will have accepted the times given to it and calculated that a 4 minute waiting time needs to be added to obey the time window on Delivery 3. The cells marked green indicate where Auto has calculated the remainder of the route.

Certain fields can be used in either their numeric or character equivalents. When accessing or

defining routes etc DPS recommends that the character equivalents are used as there is no

guarantee that the numeric representation will not change during scheduling.

To enable route upload please ensure that the following are set within the Auto32 section of

the workarea’s PL.INI file

ImportJourneys=TRUE

ScheduleImportFile=Ischedule.csv

SummaryImportFile=Isummary.csv


You cannot upload a journey or modify a journey within an existing plan. Within the workarea

structure, the Summary.dbf and Schedule.dbf files must be removed before uploading the

journey details.

Schedule.csv and Summary.csv are not acceptable import file names, as these are reserved for

output. Schedule output records do not contain dispatched orders/tasks.

When uploading summary and schedule records, auto assumes that the data given is correct.

Therefore, if dispatched records have incompatible times i.e. order 3 is delivered before order 2,

the data will be uploaded and auto will assume that the last record set to dispatch for a given

route is correct.

Type “J” – Summary Upload

Summary uploading is used in conjunction with the schedule upload to define pre-planned routes. The Summary table can be thought of as being the Route level data, linking to multiple schedule records being the activities on the route.

If a summary record is marked as dispatched, then all of the schedule records for the route

should also be dispatched.

Start and end depot names can differ, but should match those specified within the schedule

record. If the plan is built as “end at depot = No” then there is no need to supply the end

depot.

The “Start Time” cannot be uploaded, as this is taken from the Shift start. The “User Start” is

the set time that the “user” wishes the route to start at; the routes “Start Time” of a route

can be varied by Auto within the required parameter to produce the optimal route.

It is the responsibility of the data source to ensure that the summary and its associated

schedule records have compatible statuses. Therefore, if the summary record is dispatched,

then the data source should ensure that all related schedule records are also dispatched.

If you include a row where TYPE = J, ACTION = D and ROUTENAME=******** (8x*), then all

summary records are deleted at the start of the import.

When running with availability records, the AvailRef field links the route to the vehicle

availability record. If you are using availability records, then the field is mandatory. If the

field is left blank when running in availability mode, the route is seen as being in addition to

the availability.


Route Y Num 5 Route identifier

Route will be imported by WLI32 RouteName Char 8

StartDepot Y Num 5 Starting depot identifier

StartDepotName Char 20

Depot Num 5

DepotName Char 20

TurnDepot N Num 5 If omitted assumed to be the start depot

TurnDepotName Char 20

FinishDepot N Num 5 End depot if applicable, if omitted assumed to be the start depot FinishDepotName Char 20

EndDepot Num 5

EndDepotName Char 20

Shift Y Num 5 Working shift to be applied to the route

ShiftName will be imported by WLI32 ShiftName Char 18

Vehicle Y Num 5 Vehicle type to be used on the route

VehicleName Char 12



VehicleName will be imported by

WLI32

Condition N

UserDay Y Num 1 Start day for the route Where 1=Monday UserStartDay

Record N Num 1 0 = Fixed Time is on, End at depot on 1 = Fixed Time is off, End at depot is on 2 = Fixed time is on, End at Depot is off 3 = Fixed Time is off, End at Depot is off

UserSecs N See usage

Num 6 The User time is the fixed time at which the route should start HHMMSS. If the field is left blank, Auto will vary the start time of the route within the limits of the defined shift

ShiftStartSecs

StartSecs

Status Y Num 1 Summary Status 1 = available 2 = scheduled 3 = despatched 4 = frozen 5 = held

Description N Char 30 Short description of route

Nights N Num 1 The maximum number of nights away that the route can contain. This is different to the number of nights away that the route actually contains

AvailRef N Char 8 Only applicable, when running with availability records. As it links the route to the vehicle availability record if you are using availability records, then the field is mandatory. If the field is left blank when running in availability mode, the route is seen as being in addition to the availability

Type Y Char 1 Record type indicator must be “J”

If global EndAtDepot=Yes and a RECORD column is not imported as part of the ‘S’ record

then RECORD will be set as 2.

If global EndAtDepot=No and a RECORD column is not imported as part of the ‘S’ record

then RECORD will be set as 1.

Type “S” – Schedule Upload

The Schedule upload is used in conjunction with the summary upload to define pre-planned routes. The schedule table links Schedules (Routes) with activities (rest breaks etc) and orders (tasks). Certain fields can be used in either their numeric or character equivalents. When accessing or defining routes etc DPS recommends that the character equivalents are used as there is no guarantee that the numeric representation will not change during scheduling.

For routes to be correctly recalculated rest breaks must be sent as part of the data. If the

required rest breaks have been taken by the driver, but not sent to auto, it is likely that

extra rest breaks will be added, therefore reducing the time available for work. Failure to

send correct rest breaks could cause routes to be modified or failed incorrectly.


Although it is good practice to mark all summary records that are known to be complete or

committed (i.e. cannot be transferred to another vehicle or re-sequenced) to a vehicle as

dispatched, the auto engine looks for the last dispatched record on a route, and assume

that all records prior are also dispatched. Therefore, if a driver completes their route in a

different sequence to that that is expected, the actual sequence should be sent to auto.

The way that sequence is used within schedule upload differs to that in the order upload in

several key ways:-

You cannot have multiple schedule orders of the same sequence.

The supplied sequence is not stored within the database see following note.

Sequence numbers do not need to be consecutive. Auto will sort the schedule records

based on the supplied sequence, however once this sort has been completed, the

sequence number is recalculated to be consecutive starting from 1.

Regardless of the minimum rest break period set within the workarea parameters, any time

sent as a rest break will be counted. It is therefore recommended that the data source

system validates any rest breaks recorded against the minimum before the data is sent to

auto.

For calculation purposes, travel time and duration fields are ignored. For dispatched

records, they are calculated from the supplied arrival and departure times. For non-

dispatched records, time and distance fields are recalculated according to the settings

within the work area.

When TravelKms is supplied for dispatched records, it will be used for costing purposes.

For non-dispatched records, distances are recalculated.

The first task on a route should be in depot time, at the starting depot. If this varies from

the start depot set on the summary record, Auto will introduce a depot-to-depot link. The

depot-to-depot link representing the travel time etc, from the start depot as set on the

summary to the depot at the start of the routes schedule.

If you include a row where TYPE = S, ACTION = D and ORDER = ******** (8x*), then all

schedule records are deleted at the start of the import.

When implementing the logic to mark records as dispatched, the following must be

considered:-

At what point does a task become fixed on a route?

This might be after the job is completed, or when the driver has completed the job before,

and is therefore travelling to the next.

What is meant by a job, is it a single order, or all the orders at a call? Should the arrival time be allocated to the first order at a call, and the departure time to the

last order at a call? If so, how will the interim time be apportioned across all the orders at the call?

When a rest break is dispatched (marked as taken), how do you apportion the travel time and distance between calls? For example, the driver takes a break 30 minutes into an hour's drive, is he half way? That depends on the traffic. If the driver takes their break 30 minutes after they should have arrived at the next call, what does that mean with regard to the remainder of the route? The same issues apply for travel distance.


Route Y Num 5 Route identifier

RouteName Char

Sequence Y Num 3 Sequence within the routes Cannot include negative numbers

CallType Y Num 1 Type of record, collection



1 = collection 2 = delivery 3 = off duty period 4 = depot call 5 = rest break 6 = other work 7 = waiting time

Class N Not currently used

LogiX Y Bool T(rue) or F(alse). Will normally be “FALSE”, however in the event that an order is split by a rest break etc, then subsequent lines must be marked “TRUE”

ServDepot

See note

N Char 20 Used to indicate the serving depot for a particular order. If the field is left blank, and the order is a: Collection ServDepot = Start depot Delivery ServDepot = End depot For tramped orders: Collection ServDepot = End depot Delivery ServDepot = Start depot

Reference Y See usage

Char 12 Mandatory if CallType equals 1 or 2, as it links to the task table Order

DurSecs Y Num Time on site in seconds

ArriveDay Y Num Arrival / start day Where 1=Monday

StartDOP N

Unit1 Y See usage

Num 6.5 Units can only be uploaded for dispatched orders; the value is then seen as the actual, for comparison against that on the order. For all other order statuses the unit values are calculated from the order. Max value = 999999.99999

Unit2 Y See usage

Num 6.5 See Unit1

ArriveTimeSecs Y Num Arrival time in the format HHMMSS

DepartDay Y Num Departure / end day Where 1=Monday

EndDOP N

DepartTimeSecs Y Num Departure time in the format HHMMSS

TravelKms Y Num 10.3 Travel distance from the location of the previous schedule record. Max value = 999999.999

TravelSecs Y Num Travelling time in seconds

Status Y Num Status of the record 1 = available 2 = scheduled 3 = despatched 4 = frozen 5 = held

Description N Char Short description of route



Phase N Num 1 Used in connection with multi-frequency orders, if omitted defaults to 1

Type Y Char 1 Record type indicator must be “S”

When using the WLI32 import engine to import Depot (CallType = 4) records, the Depot

name should be entered in the CALLNAME column.


Type “Z” - Zone import

Zones can be use in a number of modes, and for a number of usages for example:-

To force Auto to build “Pre-allocated” routes, classically these are milk round / territorial routes or “Owned” customers where a driver or franchisee is responsible for all visits to a given location/customer.

Another usage is to allow the user to easily identify types of work/orders on the map.

If you include a row where TYPE = Z, ACTION = D and ZoneName=******** (8x*), then all

Zone records are deleted at the start of the import.


Type Yes Char 1 Z to indicate Zone record


ZoneType Yes Num 1 1 = Centroid 2 = Postcode based zoning 3 = Assign a zone to a vehicle type

Zone Yes Num 4 4 digit zone number

ZoneName Yes Char 20 Name associated with the zone number. Only applicable as a Zone name to Zone Type 1 records. For Type 3 records, this field is used to allocate the Zone to a Vehicle type

Address No Char 20 The address field will be scanned for location information, which may be in the form of a recognised map reference, a postcode or town name. For the record to be located either address information in (any style) OR Latitude & Longitude must be given. Only applicable to Zone Type 3 records

Zone Type 1

When importing order data, it can include a 4-digit zone number, which can be edited using the task editor. However, it can also be useful to associate a name with your zone numbers, to make them more meaningful to the user when selecting zones to be displayed on the map.

Zone Type 2

Only applicable to LogiXIE

Must be used in conjunction with PL.INI setting ZoneControl

When using LogiXIE, Zones can be created based on postcodes. When using this feature the Zone number is allocated all order within a postcode area. The postcode is defined in the ZoneName.


Zone Type 3

Must be used in conjunction with PL.INI setting SetRouteZones = True

SetRouteZones is only applicable when using a fixed fleet

SetRouteZones is incompatible with vehicle swapping

The Zone number is the Zone to be associated to a vehicle type.

The Zone Name is used to define the day of plan and vehicle type that must be used for the zone. The first 2 characters of the zone name are used to define the day of plan (“00” means any day), the remainder must exactly match an existing vehicle type.

For example 0113T entered into the Zone Name, would mean that the zone is to be allocated to a vehicle of type “13T” on the first Monday of the planning period (assuming that the plan start on Monday).

Type “Q” - Hours import

When used in conjunction with Shift records, Hours can be used to define the working patterns for driver. The Hours define for how long the driver can work, the shift defines when they start and end work, and rates of pay.

If any of the optional fields are left blank, the prevailing defaults will be used. Due to

legislative changes that may take place in the future, these default values may vary from

version to version.

All time values are in minutes.

If you include a row where TYPE = Q, ACTION = D and HoursName=******** (8x*), then all

Hours records are deleted at the start of the import.


Type Yes Char 1 Q to indicate Hours record


HoursName Yes Char 18 The name by which the user will reference the Hours profile. Also used for linking Hours profiles to Shifts and Vehicles

MaxDrive No Num 4 Maximum driving time within a shift

ContDrive No Num 4 Maximum continuous driving time before a break must be taken

MaxDuty No Num 4 Maximum duty time within a shift

ContDuty No Num 4 Maximum continuous duty before a break must be taken

MaxBreak No Num 4 Maximum break time to be taken in one go. It is possible that multiple periods of rest break will be required within a shift or route

MinBreak No Num 4 In some cases, it is optimal to split a period of break into multiple parts, i.e. a 15-minute break at one location and a 30 minute break at another, used to total a required 45 minute break. Auto has the option to take rest breaks instead of waiting time. This setting defines the minimum period of break, which can be used as a partial break

NightBase No Num 4 Minimum time off-duty at base i.e. home depot

NightAway No Num 4 Minimum time off-duty when away from base


MaxServe No Num 4 Maximum Service Period formally known as union limit


Type “F” - Shift import

When used in conjunction with Hours records, Shifts define when they start and end work, and rates of pay. Hours records can be used to define how long the driver can work.

If you include a row where TYPE = F, ACTION = D and ShiftName=******** (8x*), then all

Shift records are deleted at the start of the import.



HoursName No Char 18 Used to link a particular Hours profile to the Shift

RateMin No Num 11.4 Minimum Shift cost

RateNight No Num 11.4 Overnight allowance

RateNorm No Num 11.4 Normal pay rate per hour

RateOT No Num 11.4 Overtime pay rate per hour

ShiftDuration, Duration

No Num 4 Number of minutes on normal pay

ShiftEndTime No Num 4 Shift end time. Formatted as hhmm

ShiftName Yes Char 18 The name by which the user will reference the Shift profile. Also used for linking Shift profiles to Vehicles

ShiftStartTime No Num 4 Shift start time. Formatted as hhmm

Type Yes Char 1 F to indicate Shift record

Type “I” – Vehicle type import

Defines the base types for Vehicles/motive units. These can then be used to define vehicle assets.

If you include a row where TYPE = I, ACTION = D and VehicleName=******** (8x*), then all

Vehicle type records are deleted at the start of the import.

When using vehicle types and trailer types together it should be noted that there is a limit

of 16 tanks per combined unit. Scheduling speed will be greatly affected if there are more

than 5 unique tank sizes in any combination.

If running with multiple tank sizes, consider using the PL.INI setting UseTankFiles

When importing tank capacities using decimal places, the value will be truncated in line

with the display settings for the Primary Unit.



CO2 No Num

EndDepot No Num 4 Time in minutes allowed at the end depot

ETCHour/CostHour No Float 11 Running cost per hour e.g. 5.50

ETCKm/CostKM No Float 11 Running cost per Kilometre e.g. 5.50

HoursName No Char 18 Attached Hours name

VATTRIB or MVATTRIB No Char 32 Attribute strings are like Depot Stock. If all 32 attributes are set, then the string would be "0123456789ABCDEFGHIJKLMNOPQRSTUVW". If any of these characters are in the attribute string,



then the corresponding attribute bit is set in VEHICLE.dbf.

ShiftName No Char 18 Attached Shift name

SleeperCab No Bool 1 T(rue) or F(alse), does the vehicle type have a sleeper cab, and is therefore available to do multi-day routes

StartDepot No Num 16

ProdBans No Char 26 Import a letter corresponding to the prods (A = prod1, B = prod2, etc) to denote that stock is not applicable to this vehicle type

Tank1 No Num Up to 16 tank compartments can be defined called Tank1…Tank16

TurnDepot No Num 4 Time in minutes allowed at any intermediate depot

Type Yes Char 1 I to indicate Vehicle record

VehCap1 No Num 12 Maximum capacity for the primary loading unit

VehCap2 No Num 12 Maximum capacity for the secondary loading unit

VehCap3 No Num 12 Maximum capacity for the tertiary loading unit

ETCDay/VehCostDay No Float 11 Running cost per Day e.g. 5.50

VehGroup No Char 1 A-O vehicle grouping. Used in conjunction with VehBan on the order

VehHiLoading No Num 3 Vehicle fill penalty, percentage at which a maximum effect starts

VehHiSpeedAdj No Num 3 Fill penalty Maximum effect percentage, applied at VehHiLoading

VehicleName Yes Char 12 The name by which the user will reference the Vehicle type.

VehLoadAdj No Num 3 Percentage loading speed adjustment factor

VehLoLoading No Num 3 Vehicle fill penalty, percentage at which a minimum effect starts

VehSpeedAdj No Num 3 Percentage driving speed adjustment factor

Type “P” – Products

Defines Product types.

If you include a row where TYPE = P, ACTION = D and ProdName = ******** (8x*), then all

product records are deleted at the start of the import.


Type Yes Char 1 P to indicate Product record


ProdNum Yes Num 2 In the range 1 to 25

ProdName Yes Char 16 Product name

ProdSize1 No Num 8.3 Conversion factor to primary unit

ProdSize2 No Num 8.3 Conversion factor to secondary unit

ProdSize3 No Num 8.3 Conversion factor to tertiary unit

ProdLoadTime No Num 8.4 Time to load in minutes


ProdUnloadTime No Num 8.4 Time to unload in minutes

ProdDepotLoadTime No Num 8.4 Time to load in minutes

ProdDepotUnloadTime No Num 8.4 Time to unload in minutes

Revenue No Num 11.4 Revenue

Description No Char 40


Creating an Import File

Start by opening a new workbook in MS Excel. Input the field headers you require across the top of the workbook, using a different cell for each header. Now enter the data for your orders working from left to right filling in the corresponding column with the order data. The below screenshot is an example of a section of an import file.

Once your import file has been created you need to save it into .CSV format. To save the workbook in this format click on File then Save As. Input a filename and then click on the ‘Save As Type’ drop down menu. Scroll down through the list and click on CSV (Comma Delimited):

Choose a location to save the file to (local PC or network drive etc) and then click on the Save command button. The below dialog box will then appear:

Click on Yes and another dialog box will appear:

Your import file will have been successfully saved as a .CSV file. Once you close the file you are ready to import it into Route Optimiser.

Sample import file

IMPORT HEADER

DESCRIPTION.xls

Route Optimiser Extended Import File Guide v1 - dps-int.se Optimiser... · Conventions Defining the...

Documents

Transcript of Route Optimiser Extended Import File Guide v1 - dps-int.se Optimiser... · Conventions Defining the...