What makes this vertical distinctive
- Capacity-gated customer returns — a customer return is only picked up once the truck’s load has dropped under a set weight, or its deliveries are done, not on a fixed slot.
- Subcontractor revenue floor — a subcontracted route guarantees a minimum payout, with the revenue from its drops counted one-for-one beyond it.
- Equipment-dependent service time — a solo crew without a dolly takes measurably longer on a heavy item than a two-person crew.
- Two-person crews — heavy items are only assigned to crews certified for two-person handling.
Combined example
Capacity-gated customer returns
Every delivery stop carriesnbDeliveries: 1 and the customer return’s pickup carries nbPickups: 1, on top of their real weight; both counters are also declared on each resource so the constraint reads an explicit load. The single atLeastOneValidCapacity constraint then requires, at every stop, at least one of three things to hold: no delivery left on board (nbDeliveries: 0), no return collected yet (nbPickups: 0), or no more than 400 kg on board, the return included (weight: 400). Once the return is on board, nbPickups never drops back to 0 — so the return can only be placed once the truck has finished its deliveries, or dropped enough of them to stay at or under 400 kg. See Sequencing pickups after deliveries for the same pattern traced step by step.
Subcontractor revenue floor
Each subcontracted drop carries the revenue it earns (order-subcontracted-drop.capacities.revenue: 40), and revenue is also declared on team-two-person with a ceiling that never binds, so it reads back in the tour’s capacity values; the cost doesn’t need that declaration. costsByCapacity is computed on the quantities handled at the tour’s stops, and each drop counts its revenue once, at delivery: the base is the total revenue of the drops the tour serves. constantCost: 650 guarantees the minimum payout even if fewer drops are served, and past costFloor: 650, costCoeff: 1 follows the revenue one-for-one: the resource is paid max(650, revenue). See Guaranteeing a minimum per-tour revenue via costsByCapacity — the exact worked example this follows.
Equipment-dependent service time
additionalOperationDurations adds 20 minutes to every job:heavy-item stop when it’s served by a resource tagged equipment:solo-no-dolly — the base operationDuration on the stop stays the crew-agnostic default, and the solo penalty is added only for the resources it actually applies to. See Plan-level fields.
Two-person crews
order-heavy-item.requiredSkills: ["team_of_two_required"] only matches resources carrying that same skill — team-two-person qualifies, team-solo doesn’t. See Driver skills and qualifications.
Full payload
Full payload — ready to submit as POST /plans
Full payload — ready to submit as POST /plans
The preceding example isolates the four mechanisms this vertical needs; this expands it to the scale of a real working day — a full fleet schedule (
workingTimeWindow, departure, arrival), the complete objectives list, and enough padding orders to look like an actual route rather than a minimal illustration. Submit it as-is via POST /plans — the service assigns the plan’s id, so don’t include one of your own.See also
- Cost modeling — the
costsByCapacityrevenue-floor pattern. - Modeling advanced constraints — capacity-based sequencing, and the
atLeastOneValidCapacitybuilding block. - Data model — the full
additionalConstraintsandglobalConstraintscatalog.