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 → Configuration → 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 → Configuration → Organization Settings → Attributes by choosing Prepack as the model (that's the model name for packs), 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, pack definitions are loaded through Toolio's standard CSV import, the same data-feed mechanism used for other Toolio data — not from the Packs page itself. The file 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.

Each pack imports as a unit: if any one of its rows fails validation the whole pack is rejected, though the other packs in the file still import. Errors are reported per row and per pack. For how import files are delivered and run, see Manual Imports and Automated CSV Feeds.

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 removes the pack from all grids and pickers. A pack that came from an import comes back if a later import sends the same pack_id. A pack you created in Settings cannot be brought back, because its Pack External ID is generated for you and there is nowhere to re-enter it. To stop using a pack without deleting it, set it Inactive.

Before the optimizer can use a pack, the pack has to apply to the choice being ordered. That's managed on the Packs 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.

Each row has an Include checkbox: check it to include the pack, leave it unchecked to 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 the placeholder Click "Optimize Packs" to generate pack recommendations. — nothing runs on its own. The Optimize Packs button is grayed out (with a tooltip explaining why) when no choice in the document has an included pack, or when the document needs a refresh to build pack eligibility. It is also unavailable once the PO has been issued.

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, with a select-all) and these 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.

To see why a choice packed the way it did, right-click any row and choose View Summary. The Pack Optimization Summary reports, for the whole document and for each PO Number × Choice:

It's the fastest way to answer "why did this choice come out this way?" without leaving the PO.

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 (for the same receipt date) on save, and the units recompute. Singles rows can't be edited here. Your edits commit behind the standard You have unsaved changes banner. Once the PO has been issued, the whole step becomes read-only.

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 (and separately per destination when a choice is split across warehouses). 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 is the read-only Pack Overage Allowed %, fixed at 50) — it prevents a 1-unit shortfall from dragging in a whole pack. Total Demand Overage % 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:

Right-click a row and choose View Summary to see the exact reason for a given choice.

Overage is the optimizer rounding up to meet demand — "buy a few units more rather than under-buy." It stays within the Total Demand Overage % you set (default 55). If you don't want any over-buy, set Total Demand Overage % 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). A pack can also add a size you didn't plan — see the next question.

When a pack includes a size this choice offers but you didn't plan demand for, Toolio can still use that pack and fills the extra size as overage — so a size row appears with units you didn't ask for. That's the pack's fixed size ratio at work. To avoid it, use a pack whose sizes match your planned run, or lower Total Demand Overage % (set it to 0 to stop any over-buy).

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.