The Logistics Customer Booking Consolidation

The logistics customer's ocean booking consolidation, modelled from the reference engine BookingConstraintProvider so the two can be compared rule for rule on the same instances. Bookings are entities, containers are groups.

Previewproblem type booking_consolidationmanifest 2.0

Objectives#

What the solver optimizes. Enabled objectives are weighed together.

Objective	What it means	Direction	On by default	Weight
Container Cost `minimize_containers`	One penalty per container used. Their containerCost, less the flat containerBudget reward, which is a constant and so cannot change a ranking.	minimize	Yes	1.0

Constraints#

A hard constraint must hold or the problem is infeasible; a soft one adds a penalty when broken.

Constraint	What it requires	Kind	On by default
Maximum Allowable Volume Total `maximum_volume_total`	Loaded volume per container within its declared maximum.	hard	Yes
Maximum Allowable Weight Total `maximum_weight_total`	Gross weight per container within its declared maximum.	hard	Yes
Container Bookings Must Share Schedule `shared_schedule`	Bookings loaded together must have at least one candidate sailing in common. Needed a new contract: every other rule compares SCALARS, and this requires SETS to intersect. Modelling it as same_value would refuse consolidations that are legal, which is the entire value of the rule.	hard	Yes
Container Bookings Must Share Same Partition `shared_partition`	Bookings loaded together must belong to one partition.	hard	Yes
Minimum Allowable Volume Total `minimum_volume_total`	An OCCUPIED container should reach its minimum fill. SOFT, as theirs is - a thinly loaded box is wasteful, not illegal. This is the rule that stops "minimise containers" and "respect capacity" both being satisfied by spreading freight across every slot available.	soft	Yes