Skip to main content

Cartonization: which picks go to the solver

What this shows. For one reserved pick: which settings decide if it gets a planned carton, goes without a box, or ships as is.

The checks run in this fixed order. The first one that matches wins.

How to read it​

NodeSettingWhat it changes
Pack item for the pick UOMThe SKU pack and its itemsThe pack item whose UOM equals the pick UOM is the "level". No such item means Bypassed.
ship_as_is is onPack item, API only (no screen field)The pick gets outcome ShipAsIs with a frozen proof of the pack item. It is never solved.
cartonize is onPack item, "Cartonize" checkboxOff means Bypassed. A pick of that level gets the normal destination, no carton.
A policy resolvesSKU "Cartonization Policy", else owner defaultThe SKU value wins. If both are empty the pick is Bypassed.
Solver, one run per policyThe policyPicks of different policies are solved apart and never share a carton.
PlannedResultThe pick has a carton code. It gets a task.
BlockedResultThe pick has an unplaced unit and no placed unit. It gets no task until the data is fixed and the order is reserved again. See 14.

Bypassed and ShipAsIs picks are executable. They get tasks with the normal destination (or the factory package). Pending (the default before any plan) and Blocked get no task.

Stored only. It has no effect today.​

These are on the policy screen but the planning code does not use them to decide anything:

  • Policy Active checkbox. The engine loads the policy by id whatever this flag says. Only the save rule reads it (an active policy needs one active carton).
  • Policy Name, Description, carton Description.
  • Policy Solver and Algorithm (one value each).
  • Maximum candidates. It is saved and goes into the plan fingerprint only.
  • The six "Exception handling" drop-downs. Every unplaced unit gets action Stop.

Where it comes from​

ClaimSource
Level is the pack item of the SKU pack with the pick UOMcrates/libs/wms-outbound/src/cartonization/read_from_db.rs:252
Level fields read: size, weight, rotationcrates/libs/wms-outbound/src/cartonization/read_from_db.rs:261
Policy is looked up per SKU and ownercrates/libs/wms-outbound/src/cartonization/read_from_db.rs:199
SKU policy first, else owner defaultcrates/libs/wms-lib-core/src/model/sku.rs:915
No level gives Bypassedcrates/libs/wms-outbound/src/cartonization/reservation.rs:130
Factory package is tested before cartonizecrates/libs/wms-outbound/src/cartonization/reservation.rs:136
cartonize off gives Bypassedcrates/libs/wms-outbound/src/cartonization/reservation.rs:151
No policy gives Bypassedcrates/libs/wms-outbound/src/cartonization/reservation.rs:163
Bypassed and ShipAsIs outcomes are writtencrates/libs/wms-outbound/src/cartonization/write.rs:217
One run per policy partitioncrates/libs/wms-outbound/src/cartonization/plan.rs:123
Task eligibility per outcomecrates/libs/wms-outbound/src/cartonization/handoff.rs:27
Blocked only when no placement existscrates/libs/wms-lib-core/src/model/outbound/pick_detail.rs:474
New picks start as Pendingcrates/libs/wms-lib-sql/sql/wms-app/migrations/007_a_pick_says_which_carton_it_goes_into.sql:42
Screen words for the outcomescrates/libs/wms-lib-sql/sql/wms-meta-ui/migrations/015_the_order_screen_shows_the_cartonization.sql:55
The engine does not read the policy Active flagcrates/libs/wms-outbound/src/cartonization/plan.rs:124
Maximum candidates only validated and put in the snapshotcrates/libs/wms-outbound/src/cartonization/snapshot.rs:120
Solver only copied to the snapshotcrates/libs/wms-outbound/src/cartonization/snapshot.rs:114
Unplaced action is always Stopcrates/libs/wms-outbound/src/cartonization/write.rs:556