Schema Entities¶

Entity: Activity (Input)¶

Activity defines what is to be scheduled. Activities can be things such as service calls, work breaks or private appointments where a resource is not available for work. An activity could be split, prioritized, deprioritized or treated in a special way in relation to other activities.

A 'repeatable' activity can be created that can be scheduled to resources indefinitely, i.e. as long as there is enough space in a resource's route, multiple visits (essentially occurrences) of this activity will be allocated to the resource. A 'repeatable' activity defines a multi-visit activity. This is restricted to be used in Cyclic Scheduling only.

Activities can be identified as being able to be split into a number of consecutive visits spread over shifts. This is achieved by setting Split Allowed to true.

Activities at the same location can be treated in a special way to either force all activities at the location to be scheduled together, or to give the scheduler an extra incentive to do so. This is achieved via the attribute do_on_location_incentive. For example, suppose a resource is working on an activity at a certain location where there are several other activities outstanding. If an urgent activity then came into the system he could still be sent away from that location to do the urgent activity before returning later to finish the other activities there. In fact, the other activities may even be scheduled elsewhere in this situation. By setting a soft constraint the resource could be made to stay on location unless the urgent job was particularly valuable. By setting a hard constraint you can ensure that the resource will never be sent away from the location in these circumstances. Of course, in the normal run of things you can expect all activities at a location to be scheduled together, as this would be the best schedule.

We can make a distinction between location and locality by making use of the do_in_locality_incentive attribute. This can be used in conjunction with the do_on_location_incentive. For example, we could have a block of flats, each flat has a different location but the same locality. We can then set a hard constraint on the location but a soft constraint on the locality and schedule jobs within the same location together, i.e. jobs at each flat first.

If the do_in_locality_incentive is not set then the do_on_location_incentive will apply for locations and localities.

A soft constraint is set by using a positive value. A value of 1 has no effect. A value greater than 1 makes it more likely that another activity at the same location will be scheduled immediately after this one, by increasing the value of the visits. The value represents the maximum multiplier that may be applied to the visit value when activities at the same location are scheduled together. The actual multiplier applied increases with the total number of same location activities scheduled within a single trip.

If a hard constraint is required the value of 'do_on_location_incentive' should be set to -1. In this situation whenever a resource is scheduled to arrive at a location, he must carry out all work it is possible for him to do at that time. More specifically, if there is another activity at the location with a do_on_location_incentive of -1, then he must carry out this activity unless one of the following conditions holds:

1. The resource is not permitted to carry out the activity, for example due to not having the correct skills.
2. The activity is not available to be carried out at any time within the shift in question.
3. Only applicable if the parameter 'DoOnLocationCheckSingleLocation' is set to true: The only activities scheduled within the shift in question are also at this location.

The third exception condition is not considered by default as it can have confusing side effects.

Examples¶

<Activity>
    <id>Example1</id>
    <location_id>NG161QD</location_id>
</Activity>

<Activity>
    <id>Example2</id>
    <activity_class_id>CALL</activity_class_id>
    <activity_type_id>AT2</activity_type_id>
    <location_id>NG161QD</location_id>    
    <priority>2</priority>
    <split_allowed> true</split_allowed>
    <do_on_location_incentive>1</do_on_location_incentive>
    <min_split>PT2H0M0S</min_split>
    <priority>3</priority>
    <description>All attributes defined</description>
    <date_time_created>2006-01-03T12:01:00.0000000+01:00</date_time_created>
    <date_time_open>2006-01-03T12:01:00.0000000+01:00</date_time_open>
    <external_ref>Test 8</external_ref>
</Activity>

Entity: Activity_Availability_Set (Input)¶

Links an activity to an availability set.

Entity: Activity_Category (Input)¶

Represents an association between an activity and a category.

Entity: Activity_Class (Lookup)¶

Activity Class defines what sort of activity is represented. Activities can relate to some operational process, a resource rest period or a private activity where the resource is unavailable to be scheduled for work. Activity Class is a method of incorporating these different types of activities into the scheduling process.

There are six classes of activities :-

BREAK: which defines a period of time within a time window where the resource must stop servicing call class activities.

CALL: which defines an activity a resource must undertake at a location.

DEPOT: defines the location of a depot to be used for part replenishment.

PRIVATE: defines periods of time when the resource is not available to service activities of any other class.

REPEATABLE: defines an activity that can be undertaken multiple times.

WRAPPER: defines an activity to be carried out as an initial or final task in a batch of work.

Entity: Activity_Custom_Metric (Input)¶

This defines the value an activity has against a custom metric. This value is used for the activity when validating shift rules or parallel rules involving custom metrics.

Entity: Activity_Custom_URL (Input)¶

Defines the custom url to be used for a particular activity. Custom url parameters can be specified for the activity, the use of which is defined on the URL_Parameter record for the specific custom url id (see example below).

<Activity_Custom_URL>
    <activity_id>SVC_1</activity_id>
    <custom_url_id>urlActivities</custom_url_id>
    <custom_parameter_value1>SVC_1</custom_parameter_value1>
  </Activity_Custom_URL>
  <Custom_URL>
    <id>urlActivities</id>
    <name>Prepare work order</name>
    <custom_action>ACTIVITY_DETAIL_FORM</custom_action>
  </Custom_URL>
  <URL_String>
    <custom_url_id>urlActivities</custom_url_id>
    <sequence>1</sequence>
    <string_value>https://example.com/</string_value>
  </URL_String>
  <URL_Parameter>
    <custom_url_id>urlActivities</custom_url_id>
    <sequence>2</sequence>
    <custom_parameter>1</custom_parameter>
  </URL_Parameter>

Entity: Activity_Group (Input)¶

Activity Group defines related activities either as pre-requisites, co-requisite, or combined activities, or as a suggested ordering between the activities. The type of activity group is indicated by the value in attribute pre_co_req.

A pre-requisite is an activity that must be started/completed before another activity can commence. There can optionally be specified a minimum delay after the start of the pre-requisite before this activity can commence, and a maximum time after the start of the pre-requisite before which this activity must commence. If the activity cannot be started before this time, then it will not be allocated. However, the first part of the pre-requisite may still be allocated, unless the attribute all_or_nothing is set to true.

A corequisite defines two activities that must be scheduled to start at the same time.

A combined activity group links two activities such that they will be scheduled either back-to-back with the same resource, or to be commenced at the same time by two different resources (essentially a co-requisite). The choice of how the activity is scheduled is left to the DSE, which will adopt optimum choice for the schedule.

A suggested ordering defines two activities that should ideally be scheduled one after the other.

Examples¶

<Activity_Group>
    <activity_id1>Test19-A</activity_id1>
    <activity_id2>Test19-B</activity_id2>
    <pre_co_req>PRE</pre_co_req>
</Activity_Group>

<Activity_Group>
    <activity_id1>Test19-B</activity_id1>
    <activity_id2>Test19-C</activity_id2>
    <pre_co_req>PRE</pre_co_req>
    <all_or_nothing>true</all_or_nothing>
    <min_delay>PT1H5M0S</min_delay>
    <same_resource>true</same_resource>
    <max_delay>PT6H0M0S</max_delay>
</Activity_Group>

<Activity_Group>
    <activity_id1>Act-A</activity_id1>
    <activity_id2>Act-B</activity_id2>
    <pre_co_req>COMBINED</pre_co_req>
</Activity_Group>

Entity: Activity_Group_SLA (Input)¶

Sets the SLA type to use to determine the visit value proportion when the delay between pre-requisite and dependent activities is within the specified start and end delays.

If there are multiple items within a model then these should not overlap.

Entity: Activity_Group_SLA_Model (Input)¶

Activity group SLA models are used to model how the value of a visit to an activity with a pre-requisite activity is affected by its scheduling in relation to the pre-requisite visit. For example, this could be used to prefer that the dependent activity is carried out within 1 day of the pre-requisite activity, but still allow it to be scheduled with a larger gap if required.

Entity: Activity_Incentive (Input)¶

This links an activity to an incentive, allowing visits to the activity to contribute to the incentive.

Entity: Activity_Operation (Input)¶

Links an operation to a repeatable activity.

Entity: Activity_Operation_Usage (Input)¶

Defines the current usage of the specified class for this activity and operation.

Entity: Activity_Part (Input)¶

Activity part defines what parts and how much is used when the activity is completed.

Example¶

<Activity_Part>
    <part_id>TEST30</part_id>
    <activity_id>TEST30</activity_id>
    <part_usage>1</part_usage>
</Activity_Part>

Entity: Activity_Pool (Input)¶

Activity pools provide a way of grouping activities together. This can be used to set availabilities or resource preferences across the entire pool.

A pool can be scheduled as a block, which means that any activities in the block that are scheduled will be scheduled together, without interruption from any activities from outside the block. This can be across multiple shifts and may include breaks.

A pool may have a parent pool defined. This can assist with the structure for defining pre-requisite links between pools. A pre-requisite link between two parent pools (say, Pool1 and Pool2) would mean that the all of activities belonging to all of the child pools for Pool1 would need to be completed before any activity belonging to any child pool of Pool2 could begin.

Entity: Activity_Pool_Avail_Set (Input)¶

Links an activity pool to an availability set.

Entity: Activity_Pool_Category (Input)¶

Represents an association between an activity pool and a category.

Entity: Activity_Pool_Item (Input)¶

Defines an activity's inclusion within an activity pool. Activities may belong to more than one pool, but may only belong to one pool that is to be scheduled as a block.

Entity: Activity_Pool_Link (Input)¶

Defines a link between two activity pools to indicate that one pool is a pre-requisite of another - i.e. all of the activities from one pool must be completed before any activities from the dependent pool can begin.

Entity: Activity_Pool_Wrapper (Input)¶

Wrapper activities are activities that need to be done before and/or after regular activities in a pool.

Entity: Activity_Productive_Time (Input)¶

This defines periods of productive time for an activity, which are applied against incentives and rules. This is primarily intended for use with automated resource planning.

Entity: Activity_Resource_Pool_Set (Input)¶

Defines which activities are linked together to form a "chain". All activities in the chain must be scheduled to resources from a single Resource Pool, although there may be several alternative Resource Pools in the Resource Pool Set. Some Resource Pools may be preferred to others.

Example¶

<Activity_Resource_Pool_Set>
    <activity_id>process1</activity_id>
    <resource_pool_set_id>ProcessingRoutes</resource_pool_set_id>
    <chain>251</chain>
</Activity_Resource_Pool_Set>

Entity: Activity_Skill (Input)¶

Specifies a skill that a resource must have in order for that activity to be allocated to the resource. When determining what skills an activity requires, a union of the skills between activity skill and activity type skill will be made.

Example¶

<Activity_Skill>
    <activity_id>TEST33</activity_id>
    <skill_id>TEST33</skill_id>
</Activity_Skill>
<Activity_Skill>
    <activity_id>TEST33</activity_id>
    <skill_id>TEST33</skill_id>
    <share_with_corequisite>true</share_with_corequisite>
</Activity_Skill>

Entity: Activity_SLA (Input)¶

Assigns an SLA of a given type to an activity. An activity of class CALL or BREAK that falls within the scheduling window must have an Activity_SLA for it to be considered by the scheduler. Unless stated otherwise, the system will attempt to schedule the start of the activity within the defined SLA period.

It is possible to define up to 2 SLA models for an activity - 1 start based and 1 end based. At least 1 of these models is required for activities of type CALL or BREAK (unless the activity is fixed to a time). By default SLAs will default to start_based. Within each model the times must not overlap, but the models will be applied independently, so if both models are used for an activity it will be expected that the times in each model will overlap.

Example:

2 hour response deadline:
Activty_SLA from 09:00 to 11:00, SLA_Type IN, start_based = true
Activity_SLA from 11:00 to 17:00, SLA_Type OUT, start_based = true

4 hour fix deadline:
Activty_SLA from 09:00 to 13:00, SLA_Type IN, start_based = false
Activity_SLA from 13:00 to 17:00, SLA_Type OUT, start_based = false

2 hour response and 4 hour fix:
Activty_SLA from 09:00 to 11:00, SLA_Type IN1, start_based = true
Activity_SLA from 11:00 to 17:00, SLA_Type OUT1, start_based = true
Activty_SLA from 09:00 to 13:00, SLA_Type IN2, start_based = false
Activity_SLA from 13:00 to 17:00, SLA_Type OUT2, start_based = false

The DSE would calculate the value of an activity by applying ageing factors and proportions from both models. For simplicity we should advise that if both models are being used for an activity then one of the two is kept simple - e.g. the end based SLA is flat with a drop in proportion after the deadline. If only one of the two models is used then the structure is essentially as it is now anyway.

Example¶

<Activity_SLA>
    <sla_type_id>SLA_TYPE_1</sla_type_id>
    <activity_id>Test7</activity_id>
    <priority>1</priority>
    <datetime_start>2006-01-03T12:01:00.0000000+01:00</datetime_start>
    <datetime_end>2006-01-04T13:30:00.0000000+01:00</datetime_end>
</Activity_SLA>

Entity: Activity_Status (Input)¶

This is used to assign a particular activity status to an activity after its initial load. As an activity goes through its life cycle the status needs to be updated. An Activity must always have at least one Activity Status. When an Activity is created and it is unallocated then the Activity Status should be created as unallocated. If a resource is allocated then the appropriate status is used and resource id applied. Should activity duration change then the Activity Status will be updated.

Activity Moving Rules¶

The DSE will enforce the following rules depending on status of an Activity.

1. Completed (status 70), Incomplete (80) and Visit Complete (68) activities will never be moved or extended.
2. Pending Completion (status 65) activities are treated by the DSE in the same way as On Site activities. Note however that the schedule dispatch service will treat pending completion activities in the same way as completed activities.
3. On Site (status 60) activities will never be moved. The travel for an On Site activity is never changed. If the activity is taking longer than the anticipated duration an ‘ActivityDurationExceeded’ exception will be raised.
4. The logic for activities at status waiting at location (55) is exactly the same as for travelling activities.
5. The start travel time and end travel time for a Travelling activity (status 50) is never changed. The activity start time will be the later of (its current value, the dataset time). The duration of the activity is never changed: hence the activity end time must change if the activity start time changes. If the travel is taking longer than the expected duration, a TravelDurationExceeded exception will be raised.
6. Any activities of status less than Travelling which are also Activity Status fixed – i.e. fixed to resource and date_time_fixed will be placed at their fixed times, regardless of whether this is in the past or overlapping other activities. The DSE will never change a fixed time or unfix an activity. An activity of status at least committed is treated as resource fixed regardless of the fixed flag.
7. Once all activities covered by points 1-5 have been included in the schedule, the DSE will schedule the remaining committed activities in a set order:
8. Activities at status Accepted (40), ordered first by commit_sort_value (lowest first) and then by date_time_status (earliest first)
9. Activities at status Downloaded (35), ordered first by commit_sort_value (lowest first) and then by date_time_status (earliest first)
10. Activities at status Sent (32), ordered first by commit_sort_value (lowest first) and then by date_time_status (earliest first)
11. Activities at status Committed (30), ordered first by commit_sort_value (lowest first) and then by date_time_status(earliest first)
12. Other than for ordering purposes, the DSE will treat all non-fixed activities of status committed through to accepted in the same manner.

The behaviour of committed activities can be adjusted through the use of the parameter 'CommittedActivitiesConstraintsOption'. The default setting is 1, which means that the DSE will attempt to obey all activity related constraints – i.e. time constraints such as availabilities, and group constraints such as co-requisite constraints. Alternatively, this parameter can be set to 0, which means that no activity related constraints will be observed on committed activities. In either case, all resource time constraints are adhered to where possible.

The behaviour can also be adjusted through the parameter 'ScheduleCommittedActivitiesInActiveShift'. The default for this is true, which means that committed activities will only be scheduled into the ‘active’ shift. The active shift is defined to be the shift for the resource which overlaps the current timeline. If no such shift exists it is the earliest shift which starts in the future. If the parameter is set to false, the DSE will consider all current and future shifts for the resource when scheduling committed activities. Note that once a resource has logged off the shift is treated as being in the past. In either case, when a committed activity cannot be scheduled validly, it will be scheduled in the active shift.

The DSE will then take each activity committed to the resource in the order defined in 6, and look for valid slots to schedule these activities. The earliest place it will consider must be :-

• After the current timeline
• After all previously processed committed activities
• A slot is considered valid if the travel from the previous location, the activity itself, and the travel to the next location can all be added without overlapping other activities already processed, and without going beyond the end of the shift time. In addition any other constraints applied to the activity must be valid, if these constraints are being enforced.

If no valid slot can be found, the activity will simply be appended to the route of the final shift being considered (either the active shift or the final shift for this resource).

All other activities not yet processed will be submitted to the Optimiser for scheduling. Scheduling periods will be submitted to the Optimiser for any periods of time that are (a) after the dataset time, and (b) longer than the minimum length (10 minutes), and (c) are before the end of the scheduling period, and (d) are after the scheduled time of all non-fixed committed activities. Activities that are fixed but do not have a location will be sent to the optimiser as MustBeScheduled activities, whenever the optimiser needs to know about them. This is effectively whenever a location for the activity cannot be predetermined.

Application of the Activity Moving Rules¶

Currently the activity moving rules are applied whenever the DSE receives an update. Since this invariably updates the dataset time, this shouldn't need to be changed. However, if there is ever a need for something more sophisticated, the rules below were the original rules set out.

When the dataset time changes, all resources will have the Activity Moving Rules applied to their entire schedules.

When a Resource, Shift, or Location used by a Resource changes (or other Resource-based changes), that resource will have the Activity Moving Rules applied to their entire schedule.

When an Activity, Activity Status or activity constraints change (or other activity-based changes), the resource which is currently allocated to that activity will have the Activity Moving Rules applied to their schedules. Note: activities which were previously unfixed and of status less than AsNext, and which remain so, need not cause the Activity Moving Rules to be re-applied.

Activities will not be uncommitted when a resource logs off a shift. The DSE will never change the activity status of an activity except to change activities of status 0 (unallocated) to status 10 (allocated) and vice versa.

Examples¶

<Activity_Status>
    <activity_id>Test7</activity_id>
    <duration>PT1H00M</duration>
    <date_time_stamp>2006-01-03T11:45:00.0000000-00:00</date_time_stamp>
    <date_time_status>2006-01-03T11:45:00.0000000-00:00</date_time_status>
</Activity_Status>

<Activity_Status>
    <activity_id>Test8</activity_id>
    <status_id>0</status_id>
    <visit_id>1</visit_id>
    <date_time_stamp>2006-01-03T11:45:00.0000000-00:00</date_time_stamp>
    <date_time_status>2006-01-03T11:45:00.0000000-00:00</date_time_status>
    <duration>PT0H15M5S</duration>
    <fixed>false</fixed>
    <date_time_fixed>2006-01-03T12:45:00.0000000-00:00</date_time_fixed>
    <memo>test 8 activity status</memo>
    <highlight>test 8 highlight</highlight>
    <reason>test 8 reason</reason>
    <rank>1</rank>
</Activity_Status>

Entity: Activity_Type (Input)¶

Describes a type of activity. Many different types of activities may be scheduled and from an operational process perspective it is useful to know what type the different activities are. At least 1 activity type must be loaded into the DSE. The default will be a type of 'Default'.

Default Entries¶

Example¶

<Activity_Type>
    <id>TEST11</id>
    <description>Activity Type Test 11</description>
    <duration>PT0H30M</duration>
    <ignore_days_old>1000</ignore_days_old>
</Activity_Type>

Entity: Activity_Type_App_Template (Input)¶

Used to associate an Activity_Type to an Appointment_Template, for use in the Appointment Booking screen on the Scheduling Workbench.

Entity: Activity_Type_Avail_Set (Input)¶

Links an activity type to an availability set.

Entity: Activity_Type_Category (Input)¶

Represents the association between an activity type and a category.

Entity: Activity_Type_Custom_Metric (Input)¶

This defines the value activities of an activity type have against a custom metric. This value is used for the activity when validating rules of type 'SHIFT_CUSTOM_METRIC'. The value can be overridden for individual activities via the Custom_Metric_Activity table.

Entity: Activity_Type_Custom_URL (Input)¶

Defines the custom url to be used for a particular activity type. Custom url parameters can be specified for the activity type, the use of which is defined on the URL_Parameter record for the specific custom url id (see example below).

<Activity_Type_Custom_URL>
    <activity_type_id>SERVICE</activity_type_id>
    <custom_url_id>urlActivityTypes</custom_url_id>
    <custom_parameter_value1>SERVICE</custom_parameter_value1>
  </Activity_Type_Custom_URL>
  <Custom_URL>
    <id>urlActivityTypes</id>
    <name>Prepare work order</name>
    <custom_action>ACTIVITY_DETAIL_FORM</custom_action>
  </Custom_URL>
  <URL_String>
    <custom_url_id>urlActivityTypes</custom_url_id>
    <sequence>1</sequence>
    <string_value>https://example.com/</string_value>
  </URL_String>
  <URL_Parameter>
    <custom_url_id>urlActivityTypes</custom_url_id>
    <sequence>2</sequence>
    <custom_parameter>1</custom_parameter>
  </URL_Parameter>

Entity: Activity_Type_Part (Input)¶

Records the part(s) requirement for an activity type.

Example¶

<Activity_Type_Part>
    <part_id>part1</part_id>
    <activity_type_id>activityType1</activity_type_id>
</Activity_Type_Part>

Entity: Activity_Type_Skill (Input)¶

Records a skill needed for an activity of this type. When determining what skills an activity requires, a union of the skills between activity skill and activity type skill will be made.

Example¶

<Activity_Type_Skill>
    <skill_id>Test18</skill_id>
    <activity_type_id>Test18</activity_type_id>
</Activity_Type_Skill>

Entity: Activity_Usage_Period (Input)¶

Defines the expected usage against this activity of the specified class and between the specified dates.

Entity: Additional_Attribute (Input)¶

This is used to hold additional attributes that are not used in the scheduling but need to be displayed within the scheduling software to provide additional end user information. Additional attributes can be added for either activities, resources or locations. Additional_Attribute should be used in preference to Additional_Attributes since this gives the external system a higher degree of control over the additional attributes. This attribute should be used moderately.

Example¶

<Additional_Attribute>
    <id>1234</id>
    <resource_id>TEST35-D</resource_id>
    <label>MPAN</label>
    <sequence>1</sequence>
    <label_value>G6765Y</label_value>
    <data_type>STRING</data_type>
</Additional_Attribute>
<Additional_Attribute>
    <id>12345</id>
    <label>Contact</label>
    <label_value>http://www.ifsworld.com</label_value>
    <activity_id>1</activity_id>
    <resource_id />
    <sequence>0</sequence>
    <location_id />
    <data_type>URL</data_type>
</Additional_Attribute>

Entity: Additional_Attributes (Input)¶

This is now obsolete, and the Additional_Attribute table should be used instead.

Example¶

<Additional_Attributes>
    <resource_id>TEST35-D</resource_id>
    <label>MPAN</label>
    <sequence>1</sequence>
    <label_value>G6765Y</label_value>
    <data_type>STRING</data_type>
</Additional_Attributes> 
<Additional_Attributes>
    <label>Contact</label>
    <label_value>http://www.ifsworld.com</label_value>
    <activity_id>1</activity_id>
    <resource_id />
    <sequence>0</sequence>
    <location_id />
    <data_type>URL</data_type>
</Additional_Attributes>

Entity: Aggregate_Member (Output)¶

This records which activities have been grouped to form a single aggregated activity.

Entity: Aggregated_Activity (Output)¶

Aggregated activities are created by the Schedule Distribution Service when the feeder mode aggregation mechanism is activated. See the Architecture and Sizing guide for details of this functionality. The aggregated activities are returned in the plan output. Allocation rows may refer to aggregated activities (via the activity_id), and if so details of the aggregated activity are also recorded. The Aggregated_Activity record contains basic details of the aggregated activity, and the Aggregate_Member record details which individual activities make up the aggregated activity.

Entity: Allocation (Output)¶

Allocation records are returned to the EA each time a schedule is generated by the Dynamic Scheduling Engine. It provides information about the allocation of a resource undertaking an activity at a given time.

Example¶

<Allocation>
    <activity_id>TEST35-B</activity_id>
    <visit_id>-1</visit_id>
    <activity_start>0001-01-02T00:00:00+00:00</activity_start>
    <activity_end>0001-01-02T00:20:00+00:00</activity_end>
    <visit_status>0</visit_status>
    <plan_id>1347</plan_id>
    <rank>-1</rank>
</Allocation>
<Allocation>
    <activity_id>TEST27-B</activity_id>
    <resource_id>Test25max</resource_id>
    <visit_id>1</visit_id>
    <activity_start>2006-01-03T09:59:00+00:00</activity_start>
    <activity_end>2006-01-03T10:14:00+00:00</activity_end>
    <visit_status>10</visit_status>
    <plan_id>1347</plan_id>
    <duration>PT15M</duration>
    <shift_id>Test25max_03/01/2006 09:00</shift_id>
    <rank>1</rank>
</Allocation>

Entity: Allocation_Data (Output)¶

Allocation data records are returned to the EA and provide a history of the status, duration and SLA changes to the allocation.

Entity: Allocation_Hint (Input)¶

The table stores information related to an existing schedule or plan that can be used as a reference or baseline during the scheduling process. This allows DSE to reload or utilize an existing plan for further optimisation or simulation. The table serves as an input for continuing or modifying an already defined schedule.

The DSE will prioritize using information from Allocation_Hint before checking the records in the Allocation table from an existing output plan. Activities allocated through Allocation_Hint will not be reprocessed, even if the same records are present in Allocation.

Entity: Allocation_Operation (Output)¶

Specified when an operation is expected to be performed during a visit to an activity.

Entity: Allocation_Part (Output)¶

This reports which parts have been used on which activities. Where the resource has gained parts, the quantity shown will be negative. Where a part was required but not consumed, the quantity shown will be zero.

Entity: Application_Dataset (Data)¶

This table is used to exclude the processing of particular datasets by a given application type.

Default Entries¶

Entity: Appointment_History (System)¶

Logs all appointment requests, their timings, and their success or failure.

Entity: Appointment_Offer (Output)¶

This holds the list of possible appointments to be offered in response to an Appointment Request.

Entity: Appointment_Offer_Response (Input)¶

This holds the response from the external system as to which appointment offer has been accepted.

Entity: Appointment_Request (Input)¶

This is used to record the need for an appointment request within the system. Each time an appointment is required for an activity a request is entered here with a unique id. A set of possible appointments are then returned by the scheduler and stored in Appointment Offer.

Entity: Appointment_Summary (Output)¶

This returns summary information about a booked appointment. This information is sent after an appointment offer response has been received.

When responding to a non-blocking appointment request, the appointed attribute should be used to see if the appointment offer response was successful.

Entity: Appointment_Template (Input)¶

This enables a pattern of requests to be defined for appointments. The system will automatically create these appointment requests internally over the scheduling window.

Example¶

This will request one hour morning and afternoon slots for a week, starting from the next Monday after the schedule time.

<Appointment_Template>
    <id>SAMPLE_TEMPLATE</id>
    <day_pattern>YYYYYNN</day_pattern>
    <number_of_slots>10</number_of_slots>
    <appointment_window_length>P1H</appointment_window_length>
    <granularity>PT30M</granularity>
    <template_start_day_of_week>0</template_start_day_of_week>
    <template_start_time_of_day>PT9H</template_start_time_of_day>
    <exclude_to_template_start>true</exclude_to_template_start>
    <start_based>true</start_based>
    <offer_expiry_window>PT5M</offer_expiry_window>
    <default_template>true</default_template>
  </Appointment_Template>
  <Appointment_Template_Item>
    <appointment_template_id>SAMPLE_TEMPLATE</appointment_template_id>
    <slot_start_time>PT9H</slot_start_time>
    <slot_end_time>PT12H</slot_end_time>
  </Appointment_Template_Item>
  <Appointment_Template_Item>
    <appointment_template_id>SAMPLE_TEMPLATE</appointment_template_id>
    <slot_start_time>PT13H</slot_start_time>
    <slot_end_time>PT17H</slot_end_time>
  </Appointment_Template_Item>

Entity: Appointment_Template_Item (Input)¶

Defines the slots that should be used for an appointment template.

Entity: Appt_Request_Slot_Usage (Input)¶

Used to associate an Appointment_Request to either one or multiple slot usage rule sets.

Entity: Appt_Template_Slot_Usage (Input)¶

Used to associate an Appointment_Template to either one or multiple slot usage rule sets.

Entity: Availability (Input)¶

This is used to record periods of time when either activities, activity types, locations and location types have access or are available for use in scheduling. In many cases locations and activities will have the same availability times and in this case the availabilities can be recorded against the activity type or location type. This is also used to define slots of availability for Appointment Request.

Location availabilities will take precedence over location type. Activity availabilities will take precedence over activity type availabilities. Location and activity availabilities will be intersected together (though see the note on 'LOCATION_OVERRIDE' below). Thus an activity availability of 9am until 1pm combined with a location availability of 12pm until 5pm will result in overall availability of 12pm until 1pm.

Periods of unavailability can also be specified by setting the attribute 'available' to false. If any periods of unavailability are specified these times will be excluded from the available times for the activity. For example an availability of 9am until 5pm combined with an unavailable time of 9am until 12pm would result in overall availability of 12pm until 5pm. If only unavailable times are specified the activity is assumed to be available everywhere apart from these times.

Examples¶

<Availability>
    <id>Test9</id>
    <activity_id>Test9</activity_id>
    <datetime_start>2006-01-03T11:46:00.0000000-00:00</datetime_start>
    <datetime_end>2006-01-03T20:46:00.0000000-00:00</datetime_end>
</Availability>

<Availability>
    <id>Test10</id>
    <location_id>Test10</location_id>
    <datetime_start>2006-01-03T11:46:00.0000000-00:00</datetime_start>
    <datetime_end>2006-01-03T20:46:00.0000000-00:00</datetime_end>
</Availability>

<Availability>
    <id>Test11</id>
    <activity_type_id>Test11</activity_type_id>
    <datetime_start>2006-01-03T11:46:00.0000000-00:00</datetime_start>
    <datetime_end>2006-01-03T20:46:00.0000000-00:00</datetime_end>
</Availability>

<Availability>
    <id>Test12</id>
    <location_type_id>Test12</location_type_id>
    <datetime_start>2006-01-03T11:46:00.0000000-00:00</datetime_start>
    <datetime_end>2006-01-03T20:46:00.0000000-00:00</datetime_end>
</Availability>

<Availability>
    <id>Test13</id>
    <activity_id>Test13</activity_id>
    <datetime_start>2006-01-03T09:30:00.0000000-00:00</datetime_start>
    <datetime_end>2006-01-03T10:30:00.0000000-00:00</datetime_end>
    <available>false</available>
</Availability>

<Availability>
    <id>Test14</id>
    <activity_id>Test14</activity_id>
    <datetime_start>2006-01-03T10:00:00.0000000-00:00</datetime_start>
    <datetime_end>2006-01-03T12:00:00.0000000-00:00</datetime_end>
    <availability_type>ACCEPTED_APPOINTMENT</availability_type>
</Availability>

Entity: Availability_Pattern (Input)¶

This enables a pattern of availabilities to be defined for either a Location, Location Type, Appointment Request, Activity or Activity_Type_Id. The system will automatically create these availabilities over the scheduling window.

Entity: Availability_Set (Input)¶

Defines a collection of availability periods that can be linked to activities. This can be used as a simpler way of defining the same availabilities for multiple activities.

Extra functionality can be enabled through availability sets to place additional restrictions on the schedule based on which availability period the activities are scheduled to. For example, the one_resource_per_availability setting can limit the activities linked to the availability set to use the same resource when scheduled to the same availability period. They can be scheduled to a different resource in the next period in the set, as long as there is only a single resource being used per availability period.

Entity: Availability_Set_Item (Input)¶

Defines an individual availability period belonging to an availability set.

Entity: Broadcast (Input)¶

This defines how plans and other outputs are to be communicated to external applications and users. Values should be set up with assistance from IFS. See also Broadcast Parameter.

Examples¶

Definition of a standard broadcast.

<Broadcast>
    <id>Email_BroadCast_Output</id>
    <active>true</active>
    <broadcast_type_id>EMAIL</broadcast_type_id>
    <description>Test Broadcast Email</description>
    <plan_type>COMPLETE</plan_type>
    <once_only>true</once_only>
</Broadcast>

Definition of an internal broadcast for use by the Scheduling Administration Service including input reference header record and parameter records. This will tell the Administration Service you would like a broadcast to be sent to you on the 10th failed attempt to contact an Input Manager Service. The Administration Service would attempt to contact all running Input Managers every 30 seconds (Default) and would create Application_Instance_Status rows for all running Input Managers every 60 seconds (Default).

When specifying admin broadcasts they must be put into the SCHED_ADMIN dataset. This is done on the input reference.

<Input_Reference>
    <datetime>2007-10-12T03:00:00+00:00</datetime>
    <id>ADMIN_BROADCASTS</id>
    <input_type>LOAD</input_type>
    <dataset_id>SCHED_ADMIN</dataset_id>
</Input_Reference>
<Broadcast>
    <id>ADM_SIM_NotResponding_Email</id>
    <broadcast_type_id>EMAIL</broadcast_type_id>
    <description>SIM Broadcast Email</description>
    <plan_type>ADMIN</plan_type>
</Broadcast>
<Broadcast_Parameter>
    <broadcast_id>ADM_SIM_NotResponding_Email</broadcast_id>
    <parameter_name>to_address</parameter_name>
    <parameter_value>support@xxx.com</parameter_value>
</Broadcast_Parameter>
<Broadcast_Parameter>
    <broadcast_id>ADM_SIM_NotResponding_Email</broadcast_id>
    <parameter_name>smtp_server</parameter_name>
    <parameter_value>mail.xxx.com</parameter_value>
</Broadcast_Parameter>
<Broadcast_Parameter>
    <broadcast_id>ADM_SIM_NotResponding_Email</broadcast_id>
    <parameter_name>application_type_id</parameter_name>
    <parameter_value>SIM</parameter_value>
</Broadcast_Parameter>
<Broadcast_Parameter>
    <broadcast_id>ADM_SIM_NotResponding_Email</broadcast_id>
    <parameter_name>failed_attempt_count</parameter_name>
    <parameter_value>10</parameter_value>
</Broadcast_Parameter>

Example of broadcasting manual change requests to a third party rather than sending them to the Schedule Input Manager. If the broadcast is to a webservice it can be coded so the Scheduling Workbench passes a language id and displays an error message to the user when needed.

<Broadcast>
    <id>MyWorkbenchBroadcast</id>
    <active>true</active>
    <broadcast_type_id>FILE</broadcast_type_id>
    <description>Example</description>
    <plan_type>WORKBENCH</plan_type>
</Broadcast>
<Broadcast_Parameter>
    <broadcast_id>MyWorkbenchBroadcast</broadcast_id>
    <parameter_name>file</parameter_name>
    <parameter_value>C:\IFS\Scheduling\Broadcast</parameter_value>
</Broadcast_Parameter>

Entity: Broadcast_Data (System)¶

Stores POLLING broadcast data prepared by the Schedule Broadcast Manager.

Entity: Broadcast_History (System)¶

Logs all attempts to broadcast plans by the Schedule Broadcast Manager, and their success or failure.

Entity: Broadcast_Parameter (Input)¶

This defines the various parameter values required for each Broadcast. The required parameters are created automatically depending on the Broadcast Type being used.

Plans may be generated by a number of applications such as the DSE or ABE. Using parameter plan_filter it is possible to only broadcast plans from specified applications.

Default Entries Created Based Upon Broadcast Type¶

Examples¶

File broadcast to a directory.

<Broadcast>
    <id>ao1</id>
    <active>true</active>
    <broadcast_type_id>FILE</broadcast_type_id>
    <description>Results</description>
    <plan_type>COMPLETE</plan_type>
    <minimum_plan_quality>80</minimum_plan_quality>
    <minimum_step_interval>1</minimum_step_interval>
    <once_only>false</once_only>
    <maximum_wait>PT30M</maximum_wait>
</Broadcast>
<Broadcast_Parameter>
    <broadcast_id>ao1</broadcast_id>
    <parameter_name>file_path</parameter_name>
    <parameter_value>c:\IFS\Scheduling\broadcast</parameter_value>
</Broadcast_Parameter>

Other parameter examples.

<Broadcast_Parameter>
    <broadcast_id>Email_Broadcast_Output</broadcast_id>
    <parameter_name>to_address</parameter_name>
    <parameter_value>admin@xxx.com</parameter_value>
</Broadcast_Parameter>

<Broadcast_Parameter>
    <broadcast_id>1</broadcast_id>
    <parameter_name>data_tables</parameter_name>
    <parameter_value>Activity,Activity_Status</parameter_value>
</Broadcast>

<Broadcast_Parameter>
    <broadcast_id>1</broadcast_id>
    <parameter_name>filename_format</parameter_name>
    <parameter_value>GUID</parameter_value>
</Broadcast_Parameter>

<Broadcast_Parameter>
    <broadcast_id>1</broadcast_id>
    <parameter_name>required_tables</parameter_name>
    <parameter_value>Plan,Allocation</parameter_value>
</Broadcast_Parameter>

<Broadcast_Parameter>
    <broadcast_id>1</broadcast_id>
    <parameter_name>excluded_tables</parameter_name>
    <parameter_value>Plan,Allocation</parameter_value>
</Broadcast_Parameter>

Entity: Broadcast_Type (Lookup)¶

This defines the various methods of broadcasting plans to external applications and users.

Default Entries¶

Entity: Calendar (Input)¶

This defines a calendar which can be applied to the SLAs of an activity. The slopes on the SLA will only apply during active calendar periods. The calendar consists of a weekly pattern, defined as Calendar_Item rows, plus overrides for particular days, e.g. bank holidays. These are defined as Special_Day and Special_Day_Item rows.

For example, suppose an activity has a primary SLA starting on Friday morning at 9am and finishing at 5pm Monday night (80 hours in total). Suppose the SLA has a slope from 1 to 0.9 during this time. If we say the activity has a base value of 1000, then at 9am on Monday morning we find ourselves 90% through the SLA period, so the value of the activity would be 910.

However if the activity can only be done during normal weekday working (for example, due to resource shifts or the activity's availabilities), in reality only half of the available time has been used up. To allow for this we can apply a calendar to say that the SLA slope only applies between 9am-5pm Monday-Friday. This would mean that only 16 hours of the total 80 hours counts as available time, and for the remaining time the SLA is 'suspended' without changing its value. As a result on Monday morning it is treated as still being only half way through the SLA period, so is still worth 950.

Entity: Calendar_Item (Input)¶

This defines the general pattern of active periods for the calendar.

Entity: Capacity (Input)¶

This defines the parts capacity that can be carried by a resource. It consists of an overall maximum volume and weight that can be carried, a default maximum part quantity, and individual capacities for particular parts.

Entity: Capacity_Part (Input)¶

This defines an override for the maximum quantity of stock that can be carried for a particular part. If the maximum quantity is null then there is no maximum. If exclusivity required is set to true then the resource must carry only this part for this capacity requirement.

Entity: Categorisation (Input)¶

Represents a high-level grouping or classification of categories, serving as a parent entity for organising them into meaningful groups. This can be used for filtering or grouping resources and activities in the Scheduling Workbench, or for defining rules that can restrict how the categories can be scheduled in parallel with each other.

Entity: Category (Input)¶

Defines specific items or entities within a categorisation. Activities and resources can belong to up to one category per categorisation.

Entity: Category_Custom_Metric (Input)¶

Defines the value a custom metric has for activities belonging to a particular category.

Entity: Child_Schedule (Input)¶

Defines the child schedule datasets to be created when using the DISTRIBUTED or DISTRIBUTED_STATIC process types. A scheduling problem using this process type can have multiple child datasets attached to it which are processed according to different settings. Input data is always sent into the parent dataset, and the system will automatically determine which child datasets need to be updated as a result of any change.

For 'DISTRIBUTED', exactly one child schedule of process type DYNAMIC, APPOINTMENT or REACTIVE must be specified. This should have no schedule start time meaning it is taken from the time on the parent dataset. A schedule end time and potentially an appointment window duration should be specified. This schedule will always be updated in real time.

For 'DISTRIBUTED_STATIC' there should be no dynamic child schedules.

The remaining child schedules must all be STATIC. For 'DISTRIBUTED' there may be zero, one or many of these datasets. For 'DISTRIBUTED_STATIC' there must be at least one. It is possible to get the static schedules to be updated on a periodic basis. For example, the child datasets could be configured to have a week-long dynamic schedule, a month-long static schedule that refreshes once per hour, and a year-long static schedule that generates only once per day.

By default, static schedules will not be updated, so they will only be produced once per LOAD. If updates are required, then the attribute ‘maximum_refresh_frequency’ should be set on the Child_Schedule row. This only applies for the 'DISTRIBUTED' process type. This sets a minimum elapsed time from the current schedule time when the schedule was previously updated to the current schedule time when it is refreshed. For example, if the parameter was set to 4 hours, and the initial static schedule was created at 5am, then it wouldn’t begin to create another until the schedule time reaches 9am

Entity: Contract (Input)¶

Contracts can be used for display purposes on the Scheduling Workbench, and are also used in Target-Based Scheduling and the Schedule Archive reporting tables.

Entity: Custom_Exception (Input)¶

This defines custom exceptions to be used in the Scheduling Workbench.

Entity: Custom_Exception_Data (Input)¶

This defines the custom exceptions data to be used in the Scheduling Workbench.

Entity: Custom_Metric (Input)¶

This defines a custom metric that can be specified against activities when used with the 'SHIFT_CUSTOM_METRIC' rule type, within the 'SHIFT_CAPACITY' rule category. The rule defines a limit to the total metric value that is permitted within a shift or within a reference period, and each activity may have a value assigned to it for the metric that can be used as its contribution to the rule. See the Rule_Type table for further details on setting up a custom metric rule.

Entity: Custom_URL (Input)¶

This defines a custom URL link to be used by applications. Customer URLs can be linked to activities and/or resources, and the URL link will show on the activity or resource details panel as appropriate.

The URL is defined via a combination of URL_String and URL_Parameter records. We advise that care is taken in setting up the URL, using a method that minimises the amount of data that needs to be sent into the system. There are examples below of the options available.

For simple linking of a custom url to an entity, any of the Activity Id, Resource Id, Location Id, Activity Type or Resource ID can be supplied on the Custom_URL table. Where possible, it is advised to use Activity_Type and/or Resource_Type links, and use the URL_Parameter to customise the link to the individual activity or resource.

Alternatively, the custom url id can be linked to either an Activity, Activity Type, Resource, Resource Type or Location by adding a record in the respective 'linking' table, e.g. Activity_Custom_URL. This way of setting up custom urls is particularly recommended when the Activity_Type / Resource_Type link cannot be used. A single custom url record can be added to the Custom_URL table and a record per activity can be added to the Activity_Custom_URL table. Custom parameters can be set within the linking table to be used within the URL.

Examples¶

This example provides a custom URL link for all activities of type ACT_TYPE1, with the url set to 'http://sample-url.com?id={activityId}&lang=en'.

<Custom_URL>
        <id>urlActivities</id>
        <name>Prepare work order</name>
        <custom_action>ACTIVITY_DETAIL_FORM</custom_action>
        <activity_type_id>ACT_TYPE1</activity_type_id>
      </Custom_URL>
      <URL_String>
        <custom_url_id>urlActivities</custom_url_id>
        <sequence>1</sequence>
        <string_value>http://sample-url.com?id=</string_value>
      </URL_String>
      <URL_Parameter>
        <custom_url_id>urlActivities</custom_url_id>
        <sequence>2</sequence>
        <parameter_value>id</parameter_value>
        <parameter_value_table>Activity</parameter_value_table>
      </URL_Parameter>
      <URL_String>
        <custom_url_id>urlActivities</custom_url_id>
        <sequence>3</sequence>
        <string_value>&lang=en</string_value>
      </URL_String>

This example provides a custom URL link for each activity linked to the URL, with the url set to 'http://sample-url.com?skillId={skillId}'. Here the skillId comes from a custom parameter setting.

<Activity_Custom_URL>
        <activity_id>SVC_1</activity_id>
        <custom_url_id>urlActivities</custom_url_id>
        <custom_parameter_value1>skill_1</custom_parameter_value1>
      </Activity_Custom_URL>
      <Custom_URL>
        <id>urlActivities</id>
        <name>Prepare work order</name>
        <custom_action>ACTIVITY_DETAIL_FORM</custom_action>
      </Custom_URL>
      <URL_String>
        <custom_url_id>urlActivities</custom_url_id>
        <sequence>1</sequence>
        <string_value>http://sample-url.com?skillId=</string_value>
      </URL_String>
      <URL_Parameter>
        <custom_url_id>urlActivities</custom_url_id>
        <sequence>2</sequence>
        <custom_parameter>1</custom_parameter>
      </URL_Parameter>

Entity: Customer (Input)¶

Customers can be used for display purposes on the Scheduling Workbench, and are also used in Target-Based Scheduling and the Schedule Archive reporting tables.

Entity: Dataset (Data)¶

This is used to define discrete sets of data for scheduling. By default there is one dataset called Default. Where installations wish to schedule multiple sets of data as different scheduling problems then a separate dataset must be used for each. The dataset id only has to be specified as part of the Input_Reference and not included in the data for each entity input into the system.

Datasets are also used internally by the software. These datasets will not normally be visible to the end user and data associated with these internal datasets must never be altered manually. Child datasets will be created automatically with a dataset_type of ‘SEGMENT’, ‘OBSOLETE’ and are used internally by the applications.

Default Entries¶

Entity: Dataset_Segment_Mapping (Input)¶

For internal use only.

Entity: Dataset_Status (System)¶

For internal use only.

Entity: Depot_Transfer (Input)¶

Depot transfers allow for parts to be transferred from one depot to another (from a parent depot to a child depot). The transfer will have an associated time delay and cost.

Entity: Depot_Transfer_Settings (Input)¶

Depot transfer settings determine which parts can be transferred between two depots, and what the rules are around how long it will take to transfer the part and what this will cost. Default transfer rules can be used if not explicitly defined for each part.

Entity: Distance_Penalty (Input)¶

This details the penalties that are linked to a given travel cost model. See 'Travel Cost Model' for details.

Entity: Distance_Penalty_Type (Lookup)¶

Lists the different types of travel penalty that can be applied.

Entity: Event_Type (Lookup)¶

DSE internal lookup table to record types of events which occur during the operation of an external application and which impact the schedule.

• Resource On. Resource has started their shift.
• Resource Off. Resource has finished work for their current shift.
• Resource Fix. Provides the system with the current real-time position of the resource. Either a location id or latitude and longitude co-ordinates should be provided.
• Break On. Resource has started a break.
• Break Off. Resource has completed their break.
• Attention On. Resource requires attention. This will prompt the 'Resource Attention' exception to be raised for this resource.
• Attention Off. Resource no longer requires attention.

Entity: Expl_Split_Resource_Order (Input)¶

Defines the order of preference of resources to choose from when splitting an activity for an explanation request.

Entity: Explanation_Message_Param (Output)¶

Stores the parameters to be used in a descriptive message to go with an Explanation_Outcome row.

Entity: Explanation_Outcome (Output)¶

Represents the result of an attempt that has been made for an Explanation_Request. The Schedule Explainability Service will attempt to schedule the requested activity in multiple positions within the schedule. This table gives an overview of the result from the attempt made for the chosen position.

Entity: Explanation_Outcome_Alloc (Output)¶

Represents the details of the allocations that make up an individual attempt as part of an explanation request. For example, an attempt may consist of allocating two linked activities.

Entity: Explanation_Outcome_Message (Output)¶

Represents a message belonging to an Explanation_Outcome.

Entity: Explanation_Request (Input)¶

Represents a request made to the Schedule Explainability Service.

Entity: Explanation_Request_Change (Input)¶

Represents a change request made to the Schedule Explainability Service.

Entity: Explanation_Response (Output)¶

Represents the response to a request made to the Schedule Explainability Service.

Entity: Explanation_Result_Type (Lookup)¶

Represents the types of reasons why an allocation attempt failed, or if it was successful. Used by the Schedule Explainability Service when explaining the results of various allocation attempts.

Entity: External_Change_Req_Resource (Input)¶

For an 'External_Change_Request', this table returns all resources that the external change request applies to, when the change applies to multiple resources (i.e. it is a bulk change).

Entity: External_Change_Request (Input)¶

An 'External_Change_Request' is sent when a workbench user requests to make a change to the input data based on one of the supported 'External_Change_Type' options. The request row itself, along with related child data, will contain all the information requested by the integration in order to make the change. Note that no changes are made directly in PSO based on this request, it is expected that the change request will be handled by the integration, and the integration will then update the PSO input data as appropriate.

Entity: External_Change_Request_Item (Input)¶

When an 'External_Change_Request' is sent, this table will include all user selected items, based on the 'External_Change_Select_Item' records associated with the change type.

Entity: External_Change_Select (Input)¶

This table and the related 'External_Change_Select_Item' table are used to define options that the user must select from when making a request of this type. For example, when creating a private activity, it may be required that the user select a reason for the private activity being needed (sickness, holiday etc.). An External_Change_Select row should then be included, with 'External_Change_Select_Item' rows listing the possible options.

Entity: External_Change_Select_Item (Input)¶

This table lists the items that can be selected for each specified 'External_Change_Select'. For example, if the user is required to select a reason for creating a private activity, this table would list the possible reasons to select from (Sickness, Holiday etc.).

Entity: External_Change_Type (Input)¶

This table is used to indicate which external change types are supported by the integration. The id must be one of the values supported by PSO, which currently includes 'CREATE_PRIVATE' and 'DELETE_PRIVATE', used to request the creation and deletion of private activities. If a change type is supported, then a workbench user will be given the option to make these requests (provided they have permission), and this will result in an 'External_Change_Request' record being sent back to the integration via a 'WORKBENCH' broadcast. Note that this broadcast must also be in place so that the request can be sent to the integration, instead of to the PSO system. The integration should then process these requests, make any changes in the back-end system, and send the resulting change to the input data through to PSO. No changes will be made to PSO directly as a result of the request.

Entity: Fuel_Type (Input)¶

Defines the type of fuel used in the vehicle.

Entity: Icon (Input)¶

An icon to be used when displaying data in the application. This can currently be linked to resource types and activity types.

Entity: Icon_Type (Lookup)¶

A lookup table of icon types.

Entity: Incentive (Input)¶

Incentives add value to the total plan margin when activities are scheduled to resources that meet the conditions of the incentive being applied. The conditions relate to sets of skills that the resource must satisfy. Incentives can also be restricted to only apply to a given set of activities.

In this way it is possible to encourage the DSE to use resources with particular skills to carry out certain activities, without requiring this as a hard constraint.

The primary use for incentives is in automated resource planning, but they can also be used in other scheduling problems if appropriate.

Entity: Incentive_Availability (Input)¶

This links an incentive to a period of availability where it is applicable. If no availabilities are specified then the incentive is always applicable.

Entity: Input_Load_Status (System)¶

For internal use only.

Entity: Input_Reference (Input)¶

This is used to associate an input file and scheduling time with a plan returned from the Scheduling software. The plan will contain the reference to this input data set.

One and only one record of this type should be in each data input, it is effectively the header record. This record is used to define the following :-

• The current time to the scheduler. All activity status changes, schedule events within the data must be at or before this time.
• What dataset the data belongs to, if not supplied it will default to 'Default'.
• What organisation id the data belongs to, if not supplied it will default to 1.
• Is it an initialisation of the system or an update to existing data.
• The scheduling window to be used.
• Should the scheduler produce a one off schedule or continuously seek to improve the schedule.
• The source of the data i.e. who created it.

To initialise the scheduler for the first time the attribute Input_Reference.input_type must be set to ‘LOAD’. This will stop the scheduler of processing any data it currently has for the specified dataset. To stop the scheduler from processing current data but without loading a new set of data set Input_Reference.input_type to ‘STOP’. To stop future processing but keep any data that has already been processed, set Input_Reference.input_type to ‘PAUSE’.

If subsequent data inputs wish to apply updates, or just advance the time the scheduler is working to then the Input_Reference.input_type must be set to ‘CHANGE’. Any number of change files can be sent. It is strongly recommended that the changes are presented to scheduler in chronological order to ensure the best scheduling decisions are made.

The following values for Input_Reference.input_type are supported :-

SETUP = Used when the system first starts to load system reference data.

LOAD = Used by an application to provide an initial load of data and soft restart of the scheduler.

COMPLETE = Used by an external application to provide a complete replacement data set without a restart of the system.

CHANGE = Used to provide an update of existing data.

DATA = Used to change only information in data entry tables.

STOP = When submitted will set the dataset to expired and will not process any data included with the STOP action.

PAUSE = When submitted will stop processing of data, but not set the dataset to expired.

Example¶

<Input_Reference>
    <id>Test Create</id>
    <datetime>2006-01-03T08:01:00.0000000-00:00</datetime>
    <description>Test create data</description>
    <input_type>LOAD</input_type>
</Input_Reference>

Entity: Isochrone_Point (Output)¶

These are returned by the Travel Analysis service in response to an Isochrone_Request. The sequence of points together define the requested isochrone.

Entity: Isochrone_Request (Input)¶

Used to request an isochrone, which is the sequence of points of equal travel time from a particular location. The centre location can be defined either by specifying a latitude and longitude or by using an existing location within the input data.

Entity: Load_Info (System)¶

For internal use only.

Entity: Location (Input)¶

Location entries need to be created for activities, resources, shifts where required. The EA is responsible for providing accurate location information. It is strongly advisable to have all location information validated prior to sending to the scheduling system.

Examples¶

<Location>
    <id>TEST26min-d</id>
    <latitude>52.9240</latitude>
    <longitude>-1.2487</longitude>
</Location>

<Location>
    <id>TEST26max</id>
    <location_type_id>Test26</location_type_id>
    <location_geocode_id>TEST26</location_geocode_id>
    <latitude>52.9240</latitude>
    <longitude>1.2487</longitude>
    <name>TEST26max</name>
    <address_line1>ad1</address_line1>
    <address_line2>ad2</address_line2>
    <address_line3>ad3</address_line3>
    <address_line4>ad4</address_line4>
    <address_line5>ad5</address_line5>
    <address_line6>ad6</address_line6>
    <city>city</city>
    <region>region</region>
    <state>state</state>
    <addtime>PT0H30M</addtime>
</Location>

Entity: Location_Availability_Set (Input)¶

Links a location to an availability set.

Entity: Location_Region (Input)¶

This links each location with a region entity. A location can belong to more than one region.

Example¶

<Location_Region>
    <region_id>TEST34</region_id>
    <location_id>3165</location_id>
</Location_Region>

Entity: Location_Type (Input)¶

Location types are used to associate availabilities with a type of location. This is used to reduce the amount of availabilities to be loaded for each location, rather they can be loaded against the location type. Location types do not have to be used. Where the location has a location type with availabilities and the location has availabilities then the location availabilities take precedence.