Bundle Inventory
Bundle inventory is an inventory-control method where a sellable bundle or kit is represented as a parent SKU while actual stock is tracked at component SKU level. Bundle availability is derived from components, not maintained as independent stock. The number of available bundles equals the limiting component's on-hand quantity divided by bundle quantity required, rounded down.
On the shop floor, bundle inventory supports any sellable unit assembled from fixed components: a starter kit, service set, or prepacked assortment. The warehouse receives component SKUs, stores them separately, and the system calculates how many complete bundles can be built from current component availability. When an order is released, the WMS or ERP reserves the required component quantities at pick time or deducts them at shipment, then refreshes the bundle's sellable quantity from the remaining component balances. In multi-location operations, the logic may be location-based, requiring all components in the same fulfillment site, or pooled, counting stock across sites. Lot, batch, or serial traceability stays on component records, not the bundle record, so every bundle transaction maps back to the exact inputs consumed. Component inventory remains the source of truth; the bundle is only the derived sellable configuration, preventing a separate stock record from drifting out of sync.
What determines bundle ATP?
Bundle available-to-promise is the minimum across all required components of the integer floor of on-hand component quantity divided by bundle requirement quantity, adjusted for reservations, location rules, and inventory status exclusions.
Should bundles carry their own editable on-hand balance?
In a robust design, no. The bundle should be derived from component stock so that component receipts, issues, and adjustments propagate automatically. Maintaining an independent bundle balance creates a second source of truth that can drift out of sync.
Why do ERP and WMS integrations often break bundle logic?
Upstream procurement, receiving, and cycle count adjustments often update component SKUs independently, while downstream ecommerce or order orchestration layers may lag in recalculating the derived bundle quantity, creating mismatched available-to-promise.