
Calculate complete sets from available components
To calculate a fixed bundle's component-constrained availability, divide each component's available quantity by the units needed in one bundle, round each result down, then take the smallest result. That identifies complete sets for one recipe at one stock snapshot. It does not allocate shared components between competing bundles, individual sales or existing orders.
For an Australian importer selling the same imported products separately and in sets, the useful control is a recipe-to-stock record: exact component variants, required units, usable quantity, stock scope, existing commitments and the event that changes those commitments. A parent bundle SKU or a healthy warehouse total cannot supply that record by itself.
This article covers fixed commercial bundles and multipacks of existing sellable SKUs. The numerical examples are hypothetical OPL analysis. They illustrate quantity constraints, rather than manufacturing approval, accounting valuation or a promise about your ecommerce software.
Decide whether the offer uses loose components or finished kits
A bundle can be a commercial listing whose components remain separate until picking. A physically preassembled kit is different: the warehouse has already taken components out of loose stock and created a finished unit. Declare which arrangement applies before calculating availability.
For a loose-component offer, the warehouse needs instructions identifying what to pick for each purchased set. The parent listing expresses the customer offer; the component recipe expresses its stock consumption. Changing the photograph or title does not establish that the warehouse received a new recipe.
For preassembled units, record how many kits were completed and accepted under the warehouse's approved process, what components they consumed, and where the resulting units sit. Those consumed parts cannot remain available for individual sale at the same time.
Some businesses offer both arrangements. Keep the populations separate: finished kits ready to dispatch, loose components available for future sets, and work already assigned to an open assembly job. Do not add these quantities until the record explains what is exclusive and what is already included elsewhere.
The decision here is operational. A commercial recipe does not authorise an engineering substitution or establish that a newly assembled product meets Australian safety or labelling requirements.
Release one recipe with exact variants and units
Use approved product identifiers as inputs. If those identifiers are still being assigned, resolve that through the SKU, GTIN and barcode setup workflow before the bundle is released.
A workable recipe contains a parent offer identifier, recipe revision and effective date, each component SKU or variant, the quantity consumed per complete set, and the approved fulfilment arrangement. Include a required box or insert in the operational checklist when its absence blocks packing, even if the ecommerce platform does not treat it as a tracked product component.
| Recipe field | Example | Why it matters |
|---|---|---|
| Parent offer and revision | Desk set X, revision 1 | Names the instruction applicable to an order |
| Component identity | Tray A, blue variant | Prevents substituting aggregate product stock for the required variant |
| Units per set | Two A plus one B | Defines quantity consumption |
| Fulfilment arrangement | Pick loose components together | Separates an offer from existing finished-kit stock |
Keep historical orders tied to the applicable instruction. If tomorrow's offer changes from two trays to three, an old open order should not silently inherit the new requirement. Capture the order reference and agreed revision wherever the actual warehouse process records that relationship.
The recipe also needs a named approver and a way to identify unresolved mappings. An unknown warehouse SKU is an exception to resolve before release, rather than a reason to assume that a similar-looking item is equivalent.
For the calculation, combine repeated entries for the same exact component variant into one total requirement per set. Each required quantity must be a positive whole number in the declared unit. A duplicated recipe row must not create a second claim on the same stock without increasing the total units needed.
Use an available-stock snapshot with a declared scope
Choose quantities that are usable for the proposed fulfilment arrangement. Record the timestamp, time zone, included warehouse or location scope, unit of measure and meaning of the source field. A quantity of 120 units means something different from 120 cases, or 120 units distributed across locations that cannot fulfil the set together under the agreed plan.
Shopify's inventory-state documentation distinguishes on-hand, available, committed, unavailable and incoming inventory. In that platform, available stock excludes committed and unavailable quantities and does not include incoming stock. These are Shopify definitions; map the fields your own warehouse and channels actually use.
For the OPL examples below, available means loose component units at the declared fulfilment scope after pre-existing commitments and holds have been reflected. New allocations made during the example have not yet been deducted. This explicit starting condition prevents subtracting the same reservation twice.
If the warehouse extract and storefront describe different states or times, first use the 3PL, WMS and ERP reconciliation method. Bundle arithmetic should consume an explained stock position; it cannot repair an unexplained difference by choosing the larger number.
Likewise, expected imports are not automatically dispatchable components. Resolve an incomplete receipt through the warehouse receiving discrepancy record. Quality-held items require the appropriate incoming inspection and release decision, rather than being added to a bundle to improve its apparent availability.
Work through the limiting-component calculation
Assume the declared starting snapshot contains 120 available units of component A and 70 of B. There are no finished kits in this example. Bundle X requires two A and one B.
| Component | Available units | Units in X | Complete X sets supported |
|---|---|---|---|
| A | 120 | 2 | 60 |
| B | 70 | 1 | 70 |
The isolated capacity for X is 60 complete sets. A is the limiting component. The ten B units left after making all 60 X sets cannot create another X without more A.
Use whole sets. With 121 A, dividing by two gives 60.5; the remaining single A does not make a sixty-first complete X. The quantity must be rounded down. The same logic applies to a three-pack of one SKU: the recipe still consumes three units for every complete offer.
Shopify's current bundle inventory guidance describes this divide, round-down and limiting-result approach for its availability estimate. The calculation above is a separately constructed example, not a screenshot or claim that Shopify has reserved those 60 sets.
If a required component has zero usable units, physical complete-set capacity is zero. A platform setting that permits continued selling can still expose an offer, which is why the stock calculation and the publishing rule need separate checks.
Do not add bundle limits that share stock
Now offer bundle Y using one A and two B. Against the original snapshot, its isolated capacity is 35 sets: A supports 120, while B supports 35. X can show an isolated limit of 60 and Y a limit of 35, but these are alternative uses of the same components. They do not establish capacity for 95 simultaneous orders.
Suppose an authorised allocation reserves 20 X. That allocation consumes 40 A and 20 B from the original available position. The remaining quantities are 80 A and 50 B. Against that remaining stock, Y supports 25 sets.
| Declared stage | A remaining | B remaining | Isolated Y capacity |
|---|---|---|---|
| Starting snapshot | 120 | 70 | 35 |
| After reserving 20 X | 80 | 50 | 25 |
If 25 Y are then allocated, they consume another 25 A and 50 B. The resulting loose balance is 55 A and zero B. No additional X or Y can be formed from those remaining components, although A could still support individual sales if otherwise available.
This example chooses an allocation to demonstrate the constraint. It does not determine the best product mix, forecast demand or recommend which offer deserves priority. Record that commercial choice separately from the arithmetic.
The allocation is a declared external operational scenario, not a claim that Shopify or WooCommerce automatically earmarks stock for a particular offer. Confirm how the actual system records any such commitment.
Individual sales belong in the same consumption record. Selling ten B separately changes Y's component limit even when no Y order has been placed. Conversely, canceling an unfulfilled reservation may restore capacity only after the relevant reservation is actually released and the observed stock state reflects it.
Check platform settings and the warehouse order representation
Your calculation can be correct while the software is operating under a different rule. Shopify states that a component is ignored in its bundle quantity calculation when inventory is not tracked or when continued selling while out of stock is enabled. Check each component's configuration rather than assuming that a tracked parent offer makes every component constrain availability.
Shopify's Bundles app documentation also says its order SKUs are the individual items rather than the bundle SKU, and that bundle inventory is tracked against overall stock rather than location-specific quantities. Confirm the actual app and fulfilment configuration before treating a displayed bundle number as capacity at one warehouse.
WooCommerce Product Bundles documentation describes a different set of parent stock properties, component-stock checks and external-service representations. It warns that an assembled bundle might not reach an external fulfilment service as a single item, and that external inventory services can need additional integration work.
The same documentation says the extension does not reserve part of a component's stock specifically for bundles. The hypothetical allocation above is a separate, authorised operational scenario; it does not assert that WooCommerce provides that earmarking feature. Verify the actual reservation mechanism before relying on it.
Those differences make an observed acceptance test more useful than a universal instruction to “sync the bundle SKU”. Ask what the warehouse receives: a parent line, component lines or both; the quantities it actually picks; and the event that affects loose component stock. Reading a product page alone does not answer those questions.
Technical configuration belongs to the system owner or provider. An importer can define the expected operational result and preserve the test evidence without designing custom integrations or promising an update interval.
Record preassembly without counting the same stock twice
Return to the starting 120 A and 70 B, separately from the reservation example. Suppose an authorised job physically makes ten X kits using 20 A and ten B, and the resulting ten kits are accepted as finished stock. The loose component position becomes 100 A and 60 B, plus ten separately recorded finished X kits.
Keep the conversion linked to a job reference, recipe revision, consumed quantities, completed quantity, unresolved exceptions and acceptance event. Do not leave 120 A and 70 B available alongside the ten finished kits: that would offer the consumed parts twice.
If the loose stock is available for further X sets, it supports 50 additional sets. The business therefore has ten finished kits and capacity for 50 further loose-component X sets under these declared assumptions. Whether both populations can be offered through one listing depends on the approved fulfilment and stock-publication arrangement; the arithmetic does not implement that arrangement.
Opening a finished kit later is another recorded event, rather than an automatic reversal. Identify what components were actually recovered and their authorised status. A damaged or incomplete return is not a complete saleable kit, and neither should all original components be restored merely because a return label was created.
Test the events before releasing the offer
Use a bounded, authorised test with the people who own the storefront, order handoff and warehouse stock process. Start from recorded quantities and preserve order, reservation, warehouse and component identifiers. Define the expected result before running the event, then compare it with what actually occurred.
| Test event | Expected evidence to inspect | Stop condition |
|---|---|---|
| One X order | Correct revision and two A plus one B pick instruction | Missing component or duplicate parent/component consumption |
| Individual B sale | B consumption and recomputed competing capacity | Component sale absent from the stock view being used |
| Cancellation | Released reservation and observed available state | Capacity restored without release evidence |
| Partial return | Actual recovered items and approved stock status | Every original component restored automatically |
Add a preassembly test when finished kits are involved. Trace component consumption and finished-stock creation through the approved process, including any unfinished or rejected units. A kit job marked complete is not sufficient if its component quantities remain available elsewhere.
Record mismatches with an owner and closure evidence. Product operations owns an incorrect recipe; the warehouse owns supported physical stock events; the channel or system owner resolves the relevant publication or handoff issue. These are proposed responsibilities to agree, not a universal architecture assigning every field to one system.
Release the offer when the recipe, component position and observed fulfilment path agree. Keep an exception open when they do not. Recheck after a recipe, variant mapping, fulfilment arrangement or stock-publication configuration changes. The practical payoff is a defensible complete-set quantity and a traceable consumption path, rather than a parent listing that appears healthy while its required components cannot fulfil the order.





.png)
