Schedules

From CTMS
Revision as of 10:17, 30 December 2008 by Crisfordm (talk | contribs) (New page: A schedule within MTS relates to a physical grouping of orders and trips that can be used to refer to a schedule of work. All orders, order lines, trips, trip stops, and haulage activities...)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)

A schedule within MTS relates to a physical grouping of orders and trips that can be used to refer to a schedule of work. All orders, order lines, trips, trip stops, and haulage activities must belong to a parent schedule, which acts as a container for those key items of data which defines the work that MTS is managing.

As such a schedule is a driving entity within the MTS system and is used to restrict the view of data presented within forms, reports, exports, interfaces and many other elements of the MTS system.

However, the creation of a schedule itself is not something that a user has to necessarily be concerned about, since schedules are automatically created when creating orders in MTS.

Schedules generated by the MTS application will either have a name of YYMMDD e.g. 020101 (if the date was 1st Jan 2002); this is the default, or WKDAY e.g. 01MON.

In the case of YYMMDD a "Key DateTime" is taken from the order (usually the early delivery date). The schedule has a nominal start time, stored in a system parameter and if the time component of the Key DateTime is after this time, then the date component of the Key DateTime is used as the schedule name, otherwise the previous day is used.

In the case of WKDAY, this format uses the week number and a three-letter abbreviation for the day of the week as the schedule name. For example, in the case of 01MON the WK 01 would represent a schedule for the first week of the financial year and the DAY MON would represent a Monday within that first week of the financial year. The WK part of the schedule name is in fact the number of weeks elapsed since a fixed date specified by a system parameter. (The week containing this date is deemed to be week 1.) The Schedule Start time is used as above.

In the case of YYMMDD, which is the most commonly used format for schedules within MTS, (WKDAY does not indicate year so has implications after a system configured in this manner has been operational for more than a year) a schedule can be for any number of days although 1 day and 7 days (a week) are the most commonly used values.

When a user or an interface creates an order in MTS, the Schedule module will look to see if a schedule already exists for the Key DateTime that is defined and if it does the order will be placed into that schedule, otherwise a new schedule will be created for that order and any other orders which have the same Key DateTime will also be placed into that schedule too.

Schedules have a status of either active or closed. If a schedule is active then operations can be undertaken on the trips and orders that reside in that schedule, assuming for the operation that the user wants to perform, the trip or order being worked upon is in an appropriate status.

Schedule 1.jpg

The schedule form is the entry point to the MTS application, in that it is the first form that a user would be presented with after they have logged in using their username and password. It lists all of the schedules within the database, their start date and their status and whether the schedule is locked or not. It also provides statistics about orders and trips within the schedule (if the show stats checkbox is selected) and allows the user to create a new schedule close a schedule and delete a schedule (assuming that they have the correct access privileges).

The locked by property of a schedule is used if a user is performing an operation that affects the whole of the schedule and the schedule must not be viewed or updated by another user. When this type of activity occurs the locked property would display the username of the user that is running the process that is locking the schedule such as a synchronisation of trips from a planning tool back to MTS, once the process that has locked the schedule has completed the locked property would be unset.

Since the schedule form is the entry point to the MTS application it is also the exit point in that when a user wants to end their session in MTS they should use the Exit button to gracefully exit the MTS application.