> ## Documentation Index > Fetch the complete documentation index at: https://www.twicecommerce.com/docs/llms.txt > Use this file to discover all available pages before exploring further. # How to control what stock a listing draws from > Bind a listing to the stock items that fulfil it — base and extra rules, matching by name, code, or attribute, and checking what a rule actually finds. catalog/listings A listing is what you sell. Stock items are what goes out of the door. The **Fulfilment** tab is where you say which of the second the first is allowed to use. Nothing binds itself. Stock does not attach to a listing because it looks related, and a listing with no rules has nothing behind it. The whole job is writing rules that match the units you mean — and then checking that they actually do, which TWICE will tell you if you look. ## Prerequisites **Required permission:** listing manage rights, and stock item view rights to see what your rules match. All four system roles hold both. **Decide first whether this listing has stock behind it at all.** Delivery, insurance, instruction, a service fee — these are things you sell that no unit fulfils. For those, turn **Inventory Tracking** off and skip everything else here. ## The Walkthrough Open the listing's **Fulfilment** tab. The first control is **Inventory Tracking**. **Off** — the listing shows **Not tracking inventory** and **Unlimited availability**. No stock items are reserved or deducted when it is purchased. This is right for anything without a physical unit behind it, and wrong for anything with one, because nothing will ever be held. **On** — the listing reserves or deducts stock when it is booked or sold, and the rest of this guide applies. Under **Stock items**, the **Base item** is what this listing always needs. Its rule reads as a sentence: > **Stock item where** *\[field]* *\[operator]* *\[value]* Give it a **Label** — you will see it in the rules table, so name it after what it matches, not "Rule 1". Add conditions and join them with **and** or **or** to narrow or widen the match. A rule with no conditions is rejected: **Conditions cannot be empty**. A condition can match on five things, and picking the right one is most of the skill: | Match on | Good for | | -------------- | ----------------------------------------------------------------------------------- | | **Attribute** | Anything you have defined — size, colour, grade, condition. The most durable choice | | **Item Names** | A specific unit by name | | **SKU Names** | Every unit under a product definition | | Item code | One exact unit | | SKU code | Every unit of one SKU | **Match on SKU or attribute, not on individual items,** unless you genuinely mean one specific unit. A rule naming units by name stops working the moment you buy another one — which is exactly when you least want to find out. The built-in **Condition** field on a stock item is **not** one of the five. If you grade stock, the grade has to live in an attribute for a rule to see it. **Quantity needed** is how many matching units one of these goes out with. One for an ordinary listing. More than one, and you have a kit — a listing that reserves several units together. Add **Extra rules** for the other components, each with its own conditions and its own quantity, and every rule has to resolve before the listing is bookable. This is the step that saves the afternoon. Each rule shows a live count — ***n* matches in inventory** — against your current stock. Read it before you move on: * **A number you expect** — the rule works. * **Zero**, or **No stock items available with these conditions** — the rule matches nothing. It will never be bookable. * **More than you expect** — the rule is wider than you meant, and units you did not intend will go out on this listing. Fix it here rather than discovering it from a customer. If the listing has variants and each draws from different stock, use **Variant specific rules** to set additional stock rules per variant. Use them only where variants genuinely differ. If every variant draws from the same pool, the base rule already covers it and per-variant rules are maintenance you have signed up for with nothing in return. **Available stock** shows the stock level by location — **Location**, **Total in stock** — for what the rules resolve to. That table is the answer to "is this listing actually sellable, and where". A listing with rules that match nothing at a location has no availability there whatever the catalog says. ## How do I know it worked? * **Each rule shows a non-zero match count** that is the number you expected. * **Available stock shows units at the locations you sell from.** * **A test booking holds a unit you meant it to hold** — check the item's Events tab afterwards. * **For a kit, every rule resolves.** One rule matching nothing makes the whole listing unbookable. ## Troubleshooting / Common Pitfalls **What it looks like:** a zero count, or **No stock items available with these conditions**. **Work through it in this order.** Is the value spelled exactly as it is on the stock items — matching is exact, not fuzzy? If it matches on an attribute, do the units actually have that attribute set, or is the value only in a free-text field? Are the conditions joined with **and** when you meant **or** — an *and* of two attributes only matches units carrying both? Fix the rule, or fix the stock. Bulk-editing the units to carry a consistent attribute is usually the more durable of the two. **Rules are one of several checks.** A rule matching units makes the listing *fulfillable*; it still has to be Public, available at the location, and the location has to offer the right fulfilment for the purchase type. **What to do:** work through [Check availability](/docs/guides/inventory/check-availability), which covers all of them in order. **Cause:** the rule is wider than you meant. An attribute condition that many units happen to satisfy quietly pulls all of them in. **What to do:** read the match count against what you expect to be in that pool. If the count is larger, narrow the rule — add a condition with **and**, or match on SKU rather than on a broad attribute. **Almost always the rule matches by item name or item code**, so it names units that existed when you wrote it and cannot see anything bought since. **What to do:** rewrite the rule to match on SKU or attribute. Naming individual units is right only when you mean one specific unit and always will. **Cause:** the built-in Condition field is free text and is not one of the five things a rule can match on. **What to do:** put the grade in an attribute and point the rule at that. Keep Condition for prose detail. This is the most common way a resale listing ends up finding nothing. **On a multi-rule listing, availability is the scarcest component.** Every rule has to resolve for the listing to be bookable, so one rule with nothing free blocks the whole thing regardless of how much stock the others have. **What to do:** check each rule's availability separately, not the total. The bottleneck is one rule, and it is usually the smallest pool. ## Next Steps The other checks between stock and a bookable listing. The model behind rules, stock, and eligibility. Creating the attribute a rule matches on. The tab reference, field by field.