Skip to content

Depots

Depots are a powerful feature which allow many real-life situations to be modelled. This section covers more details of what depots can do.

Depot Activities Have Zero Value

It is important that depots are only used if necessary, in order to do later activities. There is no point in collecting parts from a depot, if they are not going to be used: this would just waste time and travel. In order to achieve this, it is recommended to give depot activities a base value of zero. They will then only be used if they can help allocate another activity (which has a value).

Here is an example of what can happen if depot activities are given a value greater than zero: the Dynamic Scheduling Engine can increase the total schedule score by adding unnecessary visits to the depot. Firstly, with depots having no value:

As you can see, only two depot visits are necessary. Now, if we give the depots a positive value, this is what happens:

Lots of unnecessary depot visits have been added!

Capacity

Depots can provide any parts for which they have Part_Stock records defined. It is also possible to have a maximum number of a certain part, using the Part_Stock record. For example, here is an example where all resources start with four parts, and the depot has an unlimited stock:

And here is the same example with the Depot having a stock of only one part:

As you can see, one resource can pick up the one spare part and do five activities, but the others are limited to four, and as a result, three activities are unallocated.

This is the Part_Stock record which limits the number of parts in the depot:

<Part_Stock>
            <id>PS1</id>
            <part_id>Widget</part_id>
            <activity_id>A21_Depot</activity_id>
            <stock>1</stock>
            <override_existing>false</override_existing>
        </Part_Stock>

Replenishing a Depot

Using the Part_Stock record, the Depot may also be replenished at certain times, in the same way we saw for resources with Van Stock. The Part_Stock record, for depots, must refer to the activity_id of the depot, rather than to a resource_id.

<Part_Stock>
            <id>PS1</id>
            <part_id>Widget</part_id>
            <activity_id>A21_Depot</activity_id>
            <available_datetime>2016-06-29T08:00:00+01:00</available_datetime>
            <stock>100</stock>
            <override_existing>true</override_existing>
        </Part_Stock>

Depots may also act as stores for reusable parts, in which case they are replenished automatically when the reusable part is returned to the depot. See the section below for further details on reusable parts.

Depot Transfers

Parts may be transferred from one depot to another using a Depot_Transfer record, defining two distinct depots for the transfer. This allows parts to be transferred from a central depot to another child depot in a location closer to where a resource will require them.

For example, suppose that all required parts are stored in a central depot. When an activity requires parts, a courier company is used to transfer the parts from the central depot to a pick-up/drop-off box near to the activity. A resource can then pick up the parts from here and use them on the activity.

Depot Transfers are used to tell the DSE which options are available for transferring parts, and Transfer Rules are used to set restrictions around these transfers. The rules allow for the following options:

  • Delayed Availability: It is possible to specify an earliest time that the part can be available in the child depot, and the DSE will not plan a resource to pick up the part until this time.
  • Transfer Cost: It is possible to set a cost against the transfer. The DSE can then use this to determine whether to use the child depot or go direct to the central depot.
  • Multi-Level Transfers: It is possible to set multiple levels of transfer (e.g. same day and next day), with different costs and available times associated with each.

Note

The ARP can be used to set up the rules surrounding how long it will take to transfer parts, and how much the transfers will cost. The depot transfers in the input data can then reference these rules.

Note

Transfers are assumed to happen externally, so resources will not be scheduled to carry out the transfer themselves.

Warning

Transferring reusable parts between depots is not currently supported. See section below for more information about reusable parts.

The rule of transferring the part is defined in a Transfer_Rule record.

<Transfer_Rule>
            <transfer_rule_set_id>TransferRuleSet1</transfer_rule_set_id>
            <sequence>1</sequence>
            <earliest_available_time>2017-10-09T12:00:00+01:00</earliest_available_time>
            <unit_cost>50</unit_cost>
        </Transfer_Rule>

See the Scheduling Schema Guide for further details about how to set up depot transfers.