Hi All, This is indeed an architectural challenge while bridging storefront validation rules with downstream Assemble/Configure-to-Order (ATO/CTO) logic.
IMO the intended behaviour from requireInventory='Y' setting should be subject to product type as it directly influences subsequent order fulfilment in OFBiz. Product types require a dynamic, tiered validation approach rather than relying on a global store flag that treats all items as simple physical, off-the-shelf goods along following lines: A) For product types whose fulfilment is contingent upon component breakup (such as Configurable/AGGREGATED and Marketing Package - Pick Assemblies(MPPA)), the system could be better off by executing a sequential parent-and-component inventory lookup: -- Tier 1 (Parent Level Check): The system first checks inventory at the parent level. If there is sufficient ATP (say, due to a previous customer return, a cancelled order, or pre-built buffer stock), the order should be accepted immediately, bypassing component logic. -- Tier 2 (Component Check Fallback): If parent stock(ATP) is insufficient (or zero), the system drops down to evaluate the component-level ATP. If all required constituent components are available to satisfy the order or the chosen configuration, the order should be accepted. Here, requireInventory = N could backorder when inventory is neither found at parent nor at component level. B) Conversely, products meant to be fulfilled strictly in their own true form—such as standard Finished Goods or Marketing Package - Auto Manufactured (MPAM)—should only ever look up their own parent-level inventory. requireInventory = N could retain its current behaviour i.e. just backorder when product's own inventory is not available Apart from it, as noted, the current availability check service only receives the parent productId, making a dynamic, runtime component check impossible during the initial cart phase. To make the two-tiered lookup technically feasible within OFBiz, a configurable product check cannot run on a simple productId. It must receive the configId or the runtime array of selected ProductConfigOption IDs. Similarly MPPA should explode the BoM to have component level check triggered during the cart-to-order transition phase One caveat however is that system should expect performance overhead due to BoM explosions to run component level ATP checks. However, this still offers a much more accurate representation of ATO/CTO fulfilment than a flat block, Looking forward to hear if and how others have approached these performance in real-world deployments. Regards, Swapnil -----Original Message----- From: Anil Patel <[email protected]> Sent: 01 July 2026 17:12 To: [email protected]; ofbiz users <[email protected]> Subject: [DISCUSS] How should inventory availability work for configurable products? Hi all, Another old one that is really a requirements question: OFBIZ-1887, about ordering configurable products when a store requires inventory. https://issues.apache.org/jira/browse/OFBIZ-1887 A configurable product like the demo PC001 (type AGGREGATED) holds no stock of its own - it is assembled from the components you choose. Today the availability check only knows how to do this for marketing packages, where it works out availability from the components. Configurable products fall through to the normal check, which looks at the parent product's own stock - zero - and, when the store has requireInventory = Y, blocks the order even though the components are in stock. With the demo default of requireInventory = N it is hidden, because everything just backorders. So we have two kinds of "assembled from components" product - marketing packages and configurable products - and only marketing packages have component-aware availability. Before fixing anything I would like to agree on the intended behavior: - Should a configurable product's availability be worked out from the components in the chosen configuration, the same way marketing packages are handled? - Or should configurable products simply pass the availability check and rely on the components being checked at fulfillment? - And how should requireInventory = Y behave for these - block, backorder, or something in between? There is also a practical wrinkle: the availability check only receives the productId, not the chosen configuration, so it cannot currently see which components to check. This is closely related to OFBIZ-1411 (marketing packages) - both come down to the same question of how availability should work for products assembled from components. It would be good to settle the intended behavior once for both. What do people think? Thanks and Regards Anil Patel CEO HotWax Systems http://www.hotwaxsystems.com
