Skip to main content

Split Timing for Pickup vs Dropoff for the Locations

Why Separate Pickup and Dropoff Timing?​

In many real-world logistics operations, the time it takes to service a location varies dramatically based on what the vehicle is doing there. The most common example is a depot or distribution center:

  • Picking up goods (loading) typically requires staging, counting, and physically loading items — a process that can take 10–30 minutes per vehicle.
  • Dropping off goods (unloading) is often much faster — the driver simply offloads pre-loaded goods at the destination, which might take 5–15 minutes.
  • Point nodes (e.g., driver breaks, refueling, weigh stations) have their own distinct timing needs.

Treating all these node types with the same service time leads to inaccurate route predictions — either overestimating dropoff time (wasting capacity) or underestimating pickup time (causing SLA violations).

When to Use This Feature​

Use per-node-type calculation_params overrides in the following scenarios:

ScenarioWhy It Matters
Depot/DC operationsLoading trucks takes significantly longer than unloading them. Separating pickup vs dropoff timing improves accuracy of route ETAs and shift completion predictions.
Warehouses with shared time windowsA customer receives deliveries (dropoffs) between 08:00–12:00 but only allows shipments to leave (pickups) after 14:00. Different open/close offsets for each node type model this precisely.
Facilities with different entry proceduresA warehouse might have a fast express lane for deliveries but a full security check and weighing procedure for pickups leaving the premises.
Customer locations where returns are collectedA driver drops off a bulk order at 09:00 but picks up returned goods or empties at 11:00, after the customer has processed the delivery. The node type reflects this sequence.
Multi-use facilities with compound zonesWhen vehicles enter a large industrial park, the entry/exit time differs based on whether they're going to the loading bay (pickup) or the receiving dock (dropoff).

Industries & Use Cases​

  1. FMCG & Beverage Distribution:

    • Distributors deliver full kegs/crates to stores and pick up empties or returns. Unloading 50 crates takes 5–10 min, but counting and signing for 30 empties might take 20 min.
    • The depot itself is a pickup location during the morning dispatch wave and a dropoff location during the afternoon return wave.

  2. Pharmaceutical & Healthcare:

    • Delivering medical supplies (dropoff) requires a simple handoff. Collecting samples or expired goods (pickup) requires chain-of-custody verification, temperature logging, and additional documentation — doubling the service time.

  3. E-Commerce Fulfillment Centers:

    • Loading outbound orders for delivery requires batch verification, route-sequence loading, and vehicle inspections (15–30 min). Dropoff of returned items at the same facility involves a simplified scan-and-sign process (3–5 min).

  4. Construction Material Delivery:

    • Delivering sand, cement, or steel to a job site (dropoff) involves simple offloading. Picking up construction waste or excess materials (pickup) requires sorting, weighing, and segregation — significantly more time.

The Optimization Challenge​

Without per-node-type timing, the optimization engine applies a single service time value to all nodes at a location. This creates several problems:

  • Routes over- or under-utilize vehicles: If you use the maximum service time (pickup) for all node types, you waste capacity because dropoffs complete faster than estimated.
  • Time windows are violated: If you use the minimum service time (dropoff) for all node types, pickups run longer than expected, pushing subsequent stops past their time windows.
  • Shift time calculations are inaccurate: End-of-day predictions become unreliable because the solver doesn't know which node types are in the route.

Modeling with the API​

1. Basic Service Time Separation​

Configure different fixed service times for pickups vs dropoffs at a depot:

{
  "calculation_params": {
    "service_time": {
      "fixed": 300
    },
    "pickup": {
      "service_time": {
        "fixed": 900
      },
      "coefficients": {
        "AMBIENT": { "cbcm": 0.00002, "weight": 0.005 }
      }
    },
    "dropoff": {
      "service_time": {
        "fixed": 180
      }
    }
  }
}

Result: The solver applies:

  • 900 seconds (15 min) for pickups + demand-based scaling
  • 180 seconds (3 min) for dropoffs
  • 300 seconds (5 min) base as a fallback

2. Time Window Offsets Per Node Type​

When a location has different operating hours for pickups vs dropoffs, use open_ts_offset and close_ts_offset:

{
  "calculation_params": {
    "open_ts_offset": { "fixed": 0 },
    "close_ts_offset": { "fixed": 0 },
    "pickup": {
      "open_ts_offset": { "fixed": 0 },
      "close_ts_offset": { "fixed": 0 }
    },
    "dropoff": {
      "open_ts_offset": { "fixed": 1800 },
      "close_ts_offset": { "fixed": -1800 }
    }
  }
}

Result: Dropoff nodes shift their time windows by ±30 minutes relative to the base, while pickup nodes keep the base windows.

info

Time window offsets require enable_time_windows_adjustment: true in your simulation settings.

3. Compound Zone Entry/Exit Times​

Model a facility where trucks enter through a security gate for pickups but use an express lane for dropoffs:

{
  "calculation_params": {
    "enter_time": { "fixed": 180 },
    "exit_time": { "fixed": 120 },
    "pickup": {
      "enter_time": { "fixed": 420 },
      "exit_time": { "fixed": 300 }
    },
    "dropoff": {
      "enter_time": { "fixed": 60 },
      "exit_time": { "fixed": 30 }
    }
  }
}

Result: Pickup nodes incur 7 min entry / 5 min exit penalties. Dropoff nodes only incur 1 min entry / 30 sec exit. Nodes of different types at the same location are placed into separate compound zones.

4. Group-Level Defaults with Location Overrides​

Set general rules at the Operations Location Group level and override specific node types for individual locations:

/api/v2/operationslocationgroup/{id}
{
  "calculation_params": {
    "service_time": { "fixed": 240 },
    "pickup": {
      "service_time": { "fixed": 600 },
      "coefficients": { "AMBIENT": { "cbcm": 0.000015 } }
    },
    "dropoff": {
      "service_time": { "fixed": 120 }
    }
  }
}
/api/v2/operationslocation/{id} (overrides the group)
{
  "group": "/api/v2/operationslocationgroup/42",
  "calculation_params": {
    "pickup": {
      "service_time": { "fixed": 900 },
      "coefficients": {
        "CHILLED": { "cbcm": 0.00003, "weight": 0.008 }
      }
    }
  }
}

Result: This specific location uses 900s for pickups with CHILLED coefficients. All other node types (dropoff, point) inherit from the group. The group's AMBIENT coefficient does not carry over — the entire pickup object is replaced at the location level.

Complete Payload Example​

Here is how a booking upload references an Operations Location and automatically inherits its per-node-type parameters:

POST /api/v2/microservices/logisticsapi
{
  "sim_id": 12345,
  "bookings": [
    {
      "external_id": "ORD-2026-001",
      "pickup_operations_location_external_id": "DEPOT-MAIN",
      "dropoff_operations_location_external_id": "STORE-042",
      "product_kind": "AMBIENT",
      "demand": {
        "cbcm": 500000,
        "weight": 150
      },
      "pickup_time_window": {
        "open_ts": "2026-04-24T06:00:00+07:00",
        "close_ts": "2026-04-24T08:00:00+07:00"
      },
      "dropoff_time_window": {
        "open_ts": "2026-04-24T09:00:00+07:00",
        "close_ts": "2026-04-24T12:00:00+07:00"
      }
    }
  ]
}

The solver will automatically:

  1. Look up DEPOT-MAIN → retrieve calculation_params → apply pickup service time (900s + coefficients)
  2. Look up STORE-042 → retrieve calculation_params → apply dropoff service time (120s base)
  3. Calculate compound zones with node-type-specific entry/exit times
  4. Apply time window offsets if configured

Migration Notes​

  • If your calculation_params do not include pickup, dropoff, or point keys, the system behaves exactly as before — using the base-level parameters for all node types.
  • Adding these keys is backward compatible. You can introduce them incrementally, starting with the locations where service times differ most between pickup and dropoff.
  • For existing projects, a good starting point is to analyze your booking data and identify locations where pickup and dropoff nodes have significantly different actual service times, then configure overrides for those locations first.
Last updated on