Multi-SKU beta
Method and limitations
This planner deliberately starts with a conservative, explainable heuristic. It produces a feasible planning candidate, not a mathematically proven optimum or a safety approval.
Allocation method
- Each SKU receives its own best upright single-layer pattern.
- Each layer contains only one SKU, so carton height is consistent within that layer.
- Higher-priority SKUs are considered first; equal priorities retain input order.
- Complete layers are allocated in repeated round-robin passes.
- Shared pallet height and cargo-weight limits are checked before every layer.
- Per-SKU layer count, no-load-above, and user-provided supported-weight limits are checked.
- After no more complete layer fits, at most one partial layer is placed on top.
- Any remaining quantities continue onto the next pallet using the same deterministic rules.
Why only one partial top layer?
Stacking another planned layer over an incomplete layer may leave unsupported cartons. Restricting the current model to one partial top layer avoids presenting that specific arrangement as routine. It still does not prove that complete layers provide adequate support, compression strength, or stability.
Stacking constraints
A per-SKU layer limit is reapplied on every pallet. A layer marked as unable to support load above is kept at the top. When a per-carton supported-weight value is supplied, the planner limits the aggregate weight above that layer to the carton count multiplied by the supplied value.
This arithmetic guard does not establish compression strength or safe stacking. It assumes weight is distributed across the supporting cartons and does not model contact area, edge alignment, dynamic handling, moisture, damaged cartons, or uneven forces. Only use a value provided for the actual carton and loading conditions, and have the plan reviewed where safety requires it.
Priority behavior
Priority controls allocation order, not carton safety. Full layers rotate through all feasible SKUs so one high-priority SKU does not automatically consume every layer. If only a partial top layer remains, the highest-priority feasible SKU wins; equal priorities use the order shown in the form.
Not yet modeled
The beta does not place multiple SKUs within the same layer, optimize revenue or fulfillment value, prove inter-layer support or compression strength, model center of gravity, pallet deflection, overhang, securing, handling, or carrier rules. Always review the plan with the pallet supplier, warehouse, carrier, and a qualified load-safety professional where required.
Multiple pallets
After a pallet is complete, only its unallocated quantities are sent to the next pallet. The planner stops when all cartons are allocated, when no remaining carton can be loaded, or when the browser resource guard is reached. Every pallet is checked independently against the same height and weight limits.
Manual layer review
After calculation, one carton at a time can be moved or given another permitted base orientation. The validation engine rejects non-finite coordinates, surface overrun, overlap, and a rotated orientation when rotation is disabled for that SKU. Adjustments do not add, remove, or move cartons between layers, so the calculated quantities, heights, weights, and stacking relationships stay fixed.
Manual changes exist only in browser memory, are included in the current print report, and are cleared by recalculation. Passing these checks means only that the edited rectangles are geometrically feasible under the stated rules; it is not an optimized or safety-approved arrangement.
Privacy
Inputs and calculations remain in browser memory. This version has no account, database, upload endpoint, advertising script, or affiliate link. Optional page-level Cloudflare analytics never receives planner inputs, imported files, or results from this application.
Local JSON files
Exported files contain versioned planner inputs, not a trusted result snapshot. On import, the file structure and every field are validated before the current calculation engine recomputes the plan. Files are read locally, limited to 256 KB in the beta interface, and are not uploaded. Version checks prevent a future format from being silently interpreted under incompatible rules.
Local CSV files
The downloadable CSV template includes explicit length and weight units. Every row is validated locally, including its identifier, dimensions, quantity, priority, rotation flag, and shared units. An error identifies the affected row and field without replacing the current form. CSV imports SKU rows only; the pallet and shared limits remain as currently entered.