Pack Allocation lets allocation ship your warehouse stock the way it is actually stored: as prepacks (packs), pre-defined bundles of units across sizes, plus loose units called singles for whatever a pack can't cover cleanly. Allocation still works out how many units of each size every store needs. Pack Allocation then decides how those units travel, so your pickers ship whole packs instead of breaking them open. A pack can send a store a few units it didn't need, and a store can receive fewer units than planned when its source runs out of loose units.

Every allocation run first calculates the units each store needs, exactly as it does without packs. Pack Allocation then looks at each shipment: one choice, from one source location to one store, shipped on one transfer date and received on one receipt date. For each shipment it compares shipping whole packs against shipping loose units, and picks the cheaper option.

A pack is only considered for a shipment when all of these are true:

If no pack meets these conditions, the shipment goes out as singles, up to the loose units the source has for it (see When Loose Stock Runs Short).

The minimum fill decides whether a pack can be opened for a store. By default, at least half of a pack's units must go to sizes the store still needs. When a shipment opens several packs, Toolio counts them one at a time: the first pack must meet the minimum on the store's need, the second on the need the first leaves, and so on.

For example, with an S:1, M:2, L:1 four-pack:

A store's first pack. By default, a store's first pack of a choice is exempt from the minimum fill when the store holds none of that choice, on hand or in transit, and hasn't received a pack of it earlier in the run. That pack opens as long as it meets some of the store's need. Every other pack, in that shipment and later ones, still needs the minimum.

Your Customer Success team can change the minimum, turn it off, or turn off the first-pack exemption for your tenant. There's no screen for these settings yet.

When a pack can be used, Toolio prices each option. Every pack opened and every loose unit shipped counts as one pick, and each unit a pack ships beyond what a size needs counts as overage, including every unit of a size the store doesn't need on that date. Fewer picks win, and a small overage is acceptable when it saves several picks. A unit the store needs and doesn't receive costs more than either, which matters when loose stock runs short.

For example, a store needs M 4 and L 3, the source has enough loose M and L for any option, and the only pack is an M:2, L:2 four-pack:

The store receives one more L than it needed. That extra unit shows as Pack Deviation on the transfer (see below). Pack Allocation sends fewer units than allocation planned only when the source runs short of loose units.

When packs are available from several sources, Toolio draws them in this order:

The order decides where a pack comes from. It doesn't make a pack more expensive, so a pack that's cheaper than loose units is used whatever its source. Your Customer Success team can change this order or how strongly allocation prefers packs; there is no screen for these settings yet.

Pack Allocation ships only the loose units a source actually has once your inventory data splits that source's units into loose units and packs. A source counts as split as soon as its inventory for the run date reports loose units or pack units for any size of the choice. For each size it then counts:

Earlier shipments in the same run use these units up. When a source runs short, Toolio ships a pack instead if one passes the minimum fill and covers the missing units for less than the cost of going short. Otherwise the store receives fewer units than allocation planned:

Make sure each size's loose units and pack units add up to its total units on hand. Toolio uses the loose figure as reported, so when they don't add up, a store can be sent more or fewer loose units than the source holds.

At a source whose inventory data reports neither loose units nor pack units, loose units aren't limited this way. The limit also doesn't apply to transfers Pack Allocation doesn't consider: choices without packs, and receipts after your Pack Allocation Window.

Two pack settings you may already use for Pack Ordering don't affect allocation:

Allocation uses every pack that your on-hand inventory, purchase order and approved recommendation data report for the choice, whatever these two settings say. A pack that is excluded on the choice, or set to Inactive, is still shipped if your data reports it at a source location.

Allocation uses the same pack definitions as Pack Ordering, at Settings > Configuration > Intelligence > Packs. See Ordering in Packs (Prepacks) on Purchase Orders for how to create and import packs. For allocation, the important field is the Pack External ID: your on-hand inventory and purchase order data name each pack by that ID, and a pack Toolio can't match to the catalog is ignored.

A pack you create in Settings gets a Pack External ID that Toolio generates, and you can't edit it. So either your data sends that generated ID, or you import your packs with your own pack ID as their Pack External ID.

The Pack Allocation Window limits how far ahead of each run allocation ships packs. Set it at Settings > Module Settings > Allocation > Allocation Configuration, on the Pack Allocation card, in the Pack Allocation Window (Weeks) field.

With a window of, say, 2 weeks, shipments received within 2 weeks of the run date can ship in packs. Shipments received later go out as singles, and pack purchase orders or recommendations due after the window aren't used for packs.

On the Recommended Transfer Orders screen, rows are ordered by lane: one source location, one store, one transfer date and one receipt date. Within a lane, each pack shipment shows as one row per size it carries, and every one of those rows names the pack in Pack Name, Pack Ratio and Pack Count. The lane's loose units follow as Singles rows, one per size.

To see one row per shipment, group the grid by Pack Group Id. Each group row is one pack shipment, named by its pack, choice, store and transfer date, and expands to the sizes it carries. The loose units in view are grouped under Singles. You can also group by Pack Configuration or Pack Name.

The pack's name. Loose-unit rows read Singles.

The units of each size in one pack, for example S:2, M:4, L:2, XL:2. This uses the same format as the Pack Detail column on the Packs settings page. Singles rows show a dash.

Pack on the rows of a pack shipment, Single on loose-unit rows. Filter on it to see only pack shipments or only loose units, or group by it to compare the two.

How many packs the shipment carries. On the screen the header reads Pack Count (Pack Recommended Transfer Order), because the pack purchase order columns also have a Pack Count. Every size row of a shipment shows the shipment's pack count, and its In Transit To Ship Units is the pack count times that size's units in the pack. On a group row, Pack Count totals the packs of the shipments in the group, counting each shipment once. You edit it on a Pack Group Id group row (see Editing a Pack Shipment).

The pack count allocation recommended, before any manual edit. It's read-only, so you can always compare your edit against the original recommendation. A group row totals it the same way as Pack Count.

These columns split a group row's units. Units in Packs totals the units the group ships in packs and Single Units the units it ships loose. Pack Breakdown lists the packs it ships with their counts, for example Core 4-Pack ×12, Core 6-Pack ×3. On a size row, Units in Packs or Single Units shows the row's units, whichever applies. You can't sort or filter on these three columns.

How many units the row carries above or below what allocation planned for it. +1 means the pack added one unit the store didn't need; 0 means the packs fit exactly. A negative figure means the row ships fewer units than planned because the source ran short of loose units (see When Loose Stock Runs Short).

Non-zero cells are highlighted, and hovering one shows how many units more or fewer than the ideal the row ships. A Pack Group Id group row always totals the rows in it. Other group rows show a total once you total the column.

A pack can carry a size the store didn't need on that date. That size still gets its own row in the pack shipment, and its Pack Deviation equals its units, because allocation planned none of them.

On a pack row it follows your Pack Count edits. On a Singles row it keeps the figure from the run. When a size ships in both packs and loose units, its deviation is shared across its pack rows and its Singles row shows 0. You can sort, filter and total the column.

Extra units a pack sends today are counted as on their way to the store, so they lower what the store needs on later dates in the same run. Units a row ships short work the other way: the store still needs them, so a later date can ship them.

A shortfall that carries over to later dates is counted once. On a later date, a row shows only the units it ships short beyond the previous date's shortfall, so it can read 0 while the store is still short. For example, a store that ships 3 units short of a size on one date shows -3. If it is still 3 units short on the next date, that row shows 0, and if it is 5 units short, -2.

Pack Deviation is blank on transfers Pack Allocation didn't consider, such as choices without packs and receipts after your Pack Allocation Window.

Each pack row names the order its packs came from, in that order type's own columns:

To find every pack from one purchase order, add Po Number (Pack Purchase Order Item) to your view and filter on it.

A filter can leave only some of a pack's sizes in view. A Pack Group Id group row totals only the rows your filters leave in view, so its units and Pack Deviation then cover the sizes you can see. Its Pack Ratio and Pack Count still describe the whole pack.

To change how much a store receives in packs, group the grid by Pack Group Id, edit Pack Count on the shipment's group row and save. Toolio recalculates every size row's units from the pack ratio. You can't edit units or dates on a pack's size rows, because a pack can't ship a partial ratio. Singles rows stay editable. You can also edit Pack Count on a strategy's Recommended Transfer Orders tab (see below).

The Recommended Transfer Orders tab shows one strategy's transfer orders without leaving Allocation Strategies. Click the arrow icon on a strategy's row to open its details panel, and select the Recommended Transfer Orders tab.

The Source Inventory tab shows, for one choice, the packs and loose units on hand and on order at the locations its stores ship from. Open Allocation Strategies, click the arrow icon on a strategy's row to open its details panel, and select the Source Inventory tab.

The tab lists every location the strategy's stores receive from directly. A distribution center that only supplies another distribution center isn't listed, because allocation never ships from it for this strategy.

Packs and loose units on hand at each source location: Location, Pack, Ratio, Size, Pack Count and Units. Each location lists its packs first, from your most recent pack inventory data, where Units is the pack count times the units in one pack. Its loose units follow as Singles rows: one per size the run reads at that location, in size order (for example S, M, L), with sizes at 0 included. A size your inventory data reports only pack units for shows 0. A location with no packs on hand shows only Singles rows.

A triangle in the top-right corner of a Singles row's Units cell means the run didn't read that size's loose units from today's inventory. Hover the cell to see why:

A location whose inventory data reports neither loose units nor pack units shows no Singles rows, and allocation doesn't limit its loose units (see When Loose Stock Runs Short). With week-level allocation the tab shows no Singles rows at all, because Pack Allocation doesn't run.

Packs and loose units arriving at the source locations: Order Type, PO #, Location, Due Date, Pack, Ratio, Size, Pack Count, Units and Status, earliest due date first. Within one order, loose lines are listed by location, then in size order.

The grid lists orders due from today up to the strategy's end date, or up to your allocation calculation window if that comes first. Approved recommendations are listed a little further out, by the strategy's order cycle and safety stock, because allocation can still use them in later periods.

A pack spans several sizes, so its own Size cell shows a dash and the Ratio column names every size in it. Loose-unit rows read Singles in the Pack column and show their size in Size.

On the Allocation Strategies grid, add the Pack On Hand, Pack On Order and Has Prepack columns from the column picker:

On the Allocation Plan, filter on Has Prepack to plan only the choices that have prepacks, or only the ones that don't.

These columns aren't live. They refresh when Toolio recalculates your choice metrics on its regular schedule. If you don't see the columns or the filter, ask your Customer Success Manager.

Some totals on these screens are not expected to match yet. This is a known limitation, not a problem with your data.

The pack may fail the minimum fill: less than half of its units would go to sizes the store still needs. Other reasons: the pack carries a size outside the store's Size Range, no pack was at the source location by the transfer date, the receipt date is past your Pack Allocation Window, or loose units were the cheaper option for that shipment. On a shipment with a very large number of possible pack combinations, Toolio also skips packs that carry sizes the store doesn't need, to keep the run fast.

On the Recommended Transfer Orders screen, group the grid by Pack Group Id. Each group row is one shipment, and that's where you edit its Pack Count. For one strategy, open its Recommended Transfer Orders tab in Allocation Strategies, which lists one row per shipment without grouping.

Pack Allocation and Pack Ordering both need to be enabled for your tenant. Reach out to your Customer Success Manager.

Pack Allocation only ships packs when day-level allocation is on, the Day Level Allocation Enabled switch in Allocation Configuration. The pack columns and the strategy tabs appear as soon as Pack Allocation is enabled, but with week-level allocation every transfer ships as loose units, and the Source Inventory tab shows no Singles rows. Turning day-level allocation on changes how all of your allocations are calculated, not only packs, so talk to your Customer Success Manager first.

Shipping a whole pack was cheaper than shipping the same units as loose singles, even with a unit or two extra. A pack can also carry a size the store didn't need on that date, as long as at least half of the pack goes to sizes it does need. The extra units show in Pack Deviation.

Its source ran out of loose units for that size, and no pack made up the difference. The shortfall shows as a negative Pack Deviation. If the store stays short on later dates, those rows show only the units short beyond the previous date's shortfall (see Pack Deviation). Toolio records how many units went short for each of these reasons:

Your Customer Success Manager can ask Toolio to look these up for a recent run.

No. Capacity constraints only reduce transfers that aren't part of a pack shipment. Pack shipments still count toward a location's projected inventory.

They're saved, and System Pack Count keeps the original recommendation. The next allocation run replaces them with a new recommendation, and Recalculate Capacity Constraints sets them back to System Pack Count on the shipments it resets.

Yes. By default, packs on hand are used first, then purchase orders, then approved recommendations. Your Customer Success team can change this order for your tenant; there's no screen for it yet.

If a view covers more than 10,000 pack shipments, you'll see Pack rows could not be loaded. Showing the transfer orders without packs. Narrow your filters to see the pack rows.