Pack Ordering lets you turn a Recommended Purchase Order's size-level demand into prepacks — pre-defined bundles of units across sizes — plus a singles remainder for whatever the packs can't cover cleanly. Instead of ordering loose units per size, you build a catalog of packs, tell Toolio which packs apply to each choice, and let the optimizer decide how many of each pack to buy.

Pack Ordering fits teams that buy and receive in packs rather than in loose units:

There are two kinds of packs in Toolio:

A pack's units per pack is the sum of its per-size units. When the optimizer runs, it produces pack rows (whole packs bought for a choice) and, where packs can't cover demand cleanly, singles rows (loose units of a single size).

All packs live in one place: Settings → Intelligence → Packs. This page is the central repository for every pack definition in your tenant.

The grid shows each pack with the following columns:

You can filter, sort, and search on Pack Name, Pack UPC, Pack External ID, Status, and any custom attributes. The derived columns (Actual Choice External ID, Pack Sizes, Pack Units, Pack Detail) are display-only and can't be sorted or filtered.

Click ADD in the top-right to open the pack editor. To edit an existing pack, right-click its row and choose Edit.

Fill in the pack:

Click Save when the pack is valid. Save stays disabled until all required fields and unit values are valid.

The Actual Choice picker in the editor decides the pack's type:

Picking the choice rather than typing SKUs by hand is both faster and safer — it prevents mismatched or "rainbow" packs that span more than one product.

Packs support custom attributes — for example, a Case Pack type (Inner / Master), carton type, or supplier program. Declare them on the standard attributes page at Settings → Organization → Attributes by choosing Pack as the model, exactly like attributes on any other object.

Once declared, pack attributes show as columns you can pick, filter, sort, and save into views on the Packs grid. In this phase, attribute values are populated by CSV import only (see below) — there is no field for them in the pack editor yet.

For bulk setup, download the pack template from the Packs settings page and import your definitions. The template is a single flat CSV — one row per size component, with the pack-level fields repeated on each of a pack's rows:

Toolio deduces the pack kind from the rows: any row with a SKU makes it a SKU-bound pack; none makes it a size-ratio (generic) pack. A pack must be all-or-nothing on SKUs — if one size row has a SKU, they all must. If you provide only a SKU, Toolio fills in the size from the resolved product; if you provide both, it cross-checks them and rejects the row on a mismatch.

Errors are reported per row and per pack, and valid rows still import — so one bad row doesn't block the rest of the file.

Edit a pack's Status inline on the grid or in the editor. Changes stage behind the standard You have unsaved changes banner and commit when you save. Only active packs appear when you assign packs to choices or run optimization, so deactivating a pack is the right way to retire it while preserving history.

Right-clicking a row and choosing Delete soft-deletes the pack — it disappears from all grids and pickers. To simply stop using a pack, set it Inactive rather than deleting it.

Before the optimizer can use a pack, the pack has to apply to the choice being ordered. That's managed on the Pack tab of a choice's detail panel in Assortment Plan. The tab lists every pack that applies to the choice and lets you turn each one on or off.

Packs reach a choice two ways:

Only active packs appear. If a pack is deactivated in Settings, it drops off the tab on the next refresh — its include/exclude state is remembered, not lost.

Toggle each pack with Include / Exclude. Only included packs are eligible for optimization; excluded packs are ignored. This lets you keep a library of packs matched to a choice while ordering only the ones you want this season.

Once packs are assigned, you convert demand into packs from inside the PO wizard. Create and review your Recommended Purchase Order as usual (see Creating a PO and Reviewing a PO). When Pack Ordering is enabled, a new Pack Optimization step appears after you've reviewed and, if applicable, split the PO, and before Approve.

The step starts empty with a Click Optimize Packs to generate pack recommendations placeholder — nothing runs on its own. If a PO has no pack-eligible choices at all, the Optimize Packs button is grayed out with a tooltip explaining why.

Click Optimize Packs to open the optimization dialog. It lists one row per PO Number × Choice combination in the document, each with a checkbox (checked by default) and three per-row settings:

Select the rows you want, adjust the settings, and click Optimize.

Your last run's selections and settings are remembered per document for the browser session, so re-opening the dialog pre-fills them.

After a run, the grid shows the packed result at the size level:

The original per-size demand lines aren't deleted — they're superseded by these derived rows. From this point on, the pack and singles rows are what feeds your PO totals, the export, and downstream allocation. The earlier Select and Split steps still show and edit the underlying demand.

Include In PO is read-only on this step. Excluding one size of a pack would break the pack, and hiding a whole pack would quietly under-order — so to drop a pack slice, re-run Optimize Packs with that row unchecked, which restores its demand as a normal order line.

The only editable field on this step is Adjusted Number of Packs, and only on pack rows. Editing units directly isn't allowed, because a non-multiple of the pack size (say, 6 units of a 4-pack) is meaningless.

When you change Adjusted Number of Packs on any size row of a pack, the change syncs to every size row of that same pack on save, and the units recompute. Singles rows can't be edited here. Your edits commit behind the standard You have unsaved changes banner.

There's no refresh button on this step — to recompute, click Optimize Packs again, adjust your selections, and run. Any pending grid edits are discarded, because each run regenerates the derived rows.

Because optimization is manual, demand can change after a run (for example, if you go back and edit the earlier steps). When that happens, the Pack Optimization and Approve steps show a Demand changed — re-run Optimize Packs hint. It's a reminder, never a blocker — your packs simply reflect the demand as of the last run until you re-run. Changing the warehouse split profile clears the optimization outright, so you'll start it fresh.

Optimization runs independently for each choice and receipt date on the PO. Overage or underage in one receipt week never carries into another — reaching across weeks to top up a pack is not part of this phase. The optimizer always uses your Adjusted Units as the demand and the Adjusted Receipt Date as the timing.

For each choice and date, it works in three stages:

Toolio first fills as much demand as it can with packs that fit exactly — packs that add no units beyond what's demanded. It favors larger packs, then cascades into smaller packs of the same size family to clean up the remainder. Perfect-fit packs are always used before any over-buying happens.

Once nothing fits perfectly, Toolio rounds up to finish the order, always choosing the pack that adds the least overage. A pack is only considered if it's at least half full of useful units — this prevents a 1-unit shortfall from dragging in a whole pack. Overage Allowed % caps how far this rounding can go; when the budget is reached, rounding stops and the rest falls to singles.

Whatever the packs can't cover cleanly is bought as singles — loose units of a single size — as long as Allow Singles is on (the default). This is also what happens when demand is below the smallest pack, or when a residual doesn't clear the half-full rule: it becomes singles, with no error. With Allow Singles off, that leftover is dropped instead and reported as underage.

Say a choice has a single 4-pack S:1, M:1, L:1, XL:1 assigned, and demand of S:3, M:3, L:2, XL:2 (10 units) for one receipt date, at the default settings.

Now suppose instead the demand were just S:5 against that same 4-pack. Opening the pack would fill only 1 of its 4 units (25%), below the half-full rule — so Toolio buys no packs and orders 5 single S units instead.

A choice produces no packs (everything falls to singles) for one of a few reasons:

Overage is the optimizer rounding up to meet demand — "buy a few units more rather than under-buy." It stays within the Overage Allowed % you set (default 55). If you don't want any over-buy, set Overage Allowed % to 0: the order will never exceed demand, and anything the packs can't cover becomes singles (or underage, if you've turned singles off).

Optimization is manual, so if you edit demand after running it — going back to an earlier step, changing adjusted units, or re-splitting — the pack results are based on the older demand. The hint is a reminder to re-run Optimize Packs so the packs reflect your latest numbers. It never blocks you from approving.

No. On the Pack Optimization step you can only edit Adjusted Number of Packs on pack rows; units recompute from the pack count, and the change syncs across all sizes of that pack. Singles rows are read-only. To change singles or units, re-run Optimize Packs with different selections or settings (for example, turning Allow Singles off for a row).

Nothing — they keep their normal per-size order lines. Any row you leave unchecked in the Optimize Packs dialog is untouched, so you can pack part of a document (say, your warehouse POs) and leave the rest (an Ecommerce PO) as loose units.

Not in this phase. Each choice and receipt date is optimized on its own, so a shortfall in one week is never topped up from another week's demand. Cross-date bundling is planned for a future release.