Target time
Last updated
Was this helpful?
Last updated
Was this helpful?
The idea of the target time is that we make use of the information when an order should be picked up by a shipping provider for delivery or when the customer is expected earliest to pick up the fulfilled order.
Therefore we have the possibility to specify a date & time for each order. Either we get this information from our connected shop system where the customer defined the target time or we will calculate the target time like described in the following paragraph. In the end in the persisted task there is always a target time.
If this is the case, we check for cutoff times / pickup times of carriers at a facility. Cutoff times are connected to the facility and carrier.
The systems checks whether it is possible to fulfill the order (operationally) before the selected carrier arrives at this day. If this is the case, the target time equals the pickup time of the selected carrier at this day.
If it is not possible anymore to fulfill the order before today' pickup time of the selected carrier, the target time is the next upcoming cutoff time of this carrier for which it can be guaranteed that the fulfillment took place beforehand.
This check also includes the fulfillment times as well as the closing days of this facility. The buffer time is only considered within the defined fulfillment times of a facility.
Order has type ship-from-store and DHL as the selected carrier.
DHL’s pickup times within the facility is Mo-Fr 16:00.
fulfillment times at this facility is Mo-Fr 09:00 - 18:00
No closing days were defined in this example
Fulfillment process buffer (e.g. the amount of time that an employee needs to fulfill an order) = 2 hours
Order was created Monday 13:30 → generated target time is Monday 16:00 (since 13:30 + 2 hours = 15:30 < 16:00 (pickup time))
Order was created Monday 14:30 → generated target time is Tuesday 16:00 (since 14:30 + 2 hours = 16:30 > 16:00 (pickup time); Therefore the next pickup time is only next day)
Order has type ship-from-store and DHL as the selected carrier.
DHL’s pickup times within the facility is Mo-Fr 11:00.
fulfillment times at this facility is Tu-Fr 09:00 - 17:00
No closing days were defined in this example
Fulfillment process buffer (e.g. the amount of time that an employee needs to fulfill an order) = 2 hours
Order was created Monday 08:00 → generated target time is Monday 11:00 (since 09:00 + 2 hours = 11:00 = 11:00 (pickup time))
Order was created Monday 14:30 → generated target time is Tuesday 16:00 (since 14:30 + 2 hours = 16:30 > 11:00 (pickup time); Therefore the next pickup time is only next day)
If this is the case the systems predicts when the pickjob is ready for pickup taking the fulfillment process buffer as well as the fulfillment times into consideration.
The target time is calculated by adding the fulfillment process time to the point of time when the pickjob was created. The fulfillment process time is only considered within the defined fulfillment times of a facility.
Order has the type click and collect
fulfillment times at this facility is Mo-Fr 09:00 - 18:00
No closing days were defined in this example
Fulfillment process buffer (e.g. the amount of time that an employee needs to fulfill an order) = 4 hours
Order was created Monday 16:00 → generated target time is Tuesday 11:00 (since 16:00 + 2 hours (50% of the buffer) + 09:00 (fulfillment times next da) + 2 hours(remaining 50% of the buffer) = 11:00)
Order has the type click and collect
fulfillment times at this facility is Mo-Fr 09:00 - 18:00
No closing days were defined in this example
Fulfillment process buffer (e.g. the amount of time that an employee needs to fulfill an order) = 4 hours
Order was created Monday 8:00 → generated target time is Monday 13:00 (since the facility opens at 9:00 and only from here the buffer time is counted)
In theory it is possible to not be able to determine a target time if the process buffer is too high and the provided fulfillment times are not sufficient to be fulfilled. This case will most likely be due to a configuration error. In this case target time is being set to 2 days after the order creation date at 12:00 noon.
Setting maximum capacities per day/fulfillment slot can have an impact on the calculated target time of a pickjob. In case there is no fulfillment capacity left before the CEP-pick up time on the same day the order is placed, the target time is adjusted to the next free capacity slot and its corresponding pick up time.
Nevertheless if the target time is defined within the order (we call this “hard” target time), we simply pass on the target time.
In order to do this we check for the next pickup-time of the selected carrier which is reachable when the order is picked within the planned fulfillment-slot. Only if the pickup-time can be reached including free capacity this pickup time is selected as the new target time
Next to checking the capacity, we also consider the temporal feasibility of whether the task can be picked before the targettime. In case the time at which the order was created plus the average picking duration exceeds the targettime, then the next upcoming slot is selected. If the targettime is a hard targettime (see next paragraph) it might happen that the order can not be routed and therefore has the status unroutable.
Example:
Order comes in on monday 14:00
avg. fulfillment duration 30 min
Order should be fulfilled by DHL, DHL' pickup-time is daily 16:00
if we do not plan capacities (rating / fence is inactive) the TT would be monday 16:00
if we do plan capacities and the slot is planned < monday 15:30 the TT would be monday 16:00
if we do plan capacities and the slot is planned e.g. wednesday 15:00 the TT would be wednesday 16:00
we use the starting point of the future capacity slot
if starting point + avg. duration < pickup time (1) then pickup time (1) otherwise pickup time (2 (next TT))
if date now is within the slot, we use date now + avg. duration < pickup time (1) then pickup time
If our time triggered reroute function is active and the targettime, without this feature active would be after the time triggered timeframe, the targettime would be: PJ created + set reroute timeframe
If our time triggered reroute function is active and the targettime, without this feature active would be before the time triggered timeframe and it can be met (pj created + avg. FF duration < PJ created + set reroute timeframe), the targettime would be: carrier cutoff time, which can be met
e.g. 14:00Pj created / 2 hours time to start picking / 30 min avg. FF duration / Carrier cutoff 15:00 ---> Targettime would be 15:00
e.g. 14:00Pj created / 2 hours time to start picking / 3 hours! avg. FF duration / Carrier cutoff 15:00 ---> Targettime would be 16:00
To make sure that our systems does not occupy capacities that are too far in the future. We introduced the setting “Time frame for future capacity planning”, which is a limit which defines how many days in the future capacities can be used and “booked”. This is the base for our capacity Fence.
This value includes always the capacity of a calendar day (and not days with fulfillment-times (opening-day))
This value can be set as a tenant wide default via the api and/or via the backoffice or for a specific facility (only via API). If one changes the default only the facilities using the default value changes - facilities which have their own number saved, are not changed (even if this value is the same as the default).
Example:
e.g. today is Monday 14:00
the parameter is set to 3 Days
→ the capacity till thursday (including thursday) can be used for planning.
Users of our platform have the possibility to define:
a Ship-from-Store cutoff time for a specific facility carrier connection
a tenant-wide default value
a tenant-wide cutoff time for click and collect orders via our API.
Those cutoff times in combination with the concept of a lead time, allows us to predict whether or not an incoming order can be fulfilled in time in order to be shipped via a certain carrier.
We introduced a timespan which we call “picking buffer” into our platform. For now this buffer time represents the complete fulfillment-circle. Later more buffers (e.g. for packing etc.) might be added and actual durations for processes which will be measured might be used.
This buffer time can be defined on facility level via our API and with our Backoffince by users with the role Admin or Supervisor. Furthermore an admin can define a tenant-wide default fallback via API, which is initially set to 240 minutes.
If the order is connected to a Service Job or multiple , the execution time of the Service Job(s) will be taken into account for the calculation of the target time by adding the execution time to the order time.