Skip to main content

Open in TWICE Admin

catalog/listings
A new SKU does not attach itself to any listing. Registering its stock is only half the job — the listing’s Fulfilment rules also have to recognise the new units, and on a rule built from a fixed list of names or codes, they will not until you add them.

​
Prerequisites

Required permissions: inventory:sku_general:create and inventory:stock_item_general:create to register the new stock, plus listing manage rights to edit the fulfilment rule. All four system roles hold these.
Before you start, know:
  • Which listing (and which variant, if it has any) should sell the new SKU.
  • What the existing rule matches on — open the listing’s Fulfilment tab and read the condition before changing anything. This decides whether the next steps take one click or several.

​
The walkthrough

1

Register the new SKU and its stock

Follow Register stock items to create the SKU (if it does not exist yet) and the stock items behind it. Give it whatever attributes your existing rules match on — size, colour, category, or whatever the listing already uses to sort stock.
2

Open the listing's Fulfilment tab and find the relevant rule

On a plain listing this is the Base item. On a listing with variants, check whether the variant the new SKU belongs to has its own Variant specific rule — if it does, that is the one to edit, not the base rule underneath it.Read the condition as the sentence it is: [field] [operator] [value]. The operator is what decides what happens next.
3

Matching on Attribute: nothing to do

If the condition matches Attribute is [value] and the new stock items carry that attribute, they are already included — the rule discovers matching stock at order time, not at rule-writing time. Skip to the last step and confirm the count moved.
4

Matching Item Names, Item Code, SKU Names, or SKU Code with "is in list": add the new value

A condition can read is (one exact value), is in list, or is not in list. The last two carry an explicit, fixed set of values — TWICE does not add to that list on its own when a new SKU is created, even one that belongs there.Open the condition, find the values list, and add the new SKU’s code or name — matching whichever the condition is built on. A condition reading SKU Code is in list needs the SKU’s code; SKU Names is in list needs its name. Adding the code when the condition lists names does nothing.
Edit rule dialog with SKU Name is in list and three removable value chips, above the live matches in inventory count

Listing > Fulfilment > Edit rule

5

Repeat for every variant rule that should include it

Each Variant specific rule keeps its own separate condition and its own value list — editing the base rule does not reach them. If the new SKU should fulfil more than one variant value, its identifier has to be added to each of those variant rules individually.
6

Confirm the match count moved

Back on the condition you edited, the live n matches in inventory count should read higher than before by the number of stock items you registered. If it did not move, the value you typed does not equal what the stock items actually carry — check spelling and case, and check you added it to the right field (name vs. code).

​
How do I know it worked?

  • The condition’s match count increased by exactly the number of new stock items.
  • On a listing with variants, Stock Availability on the Variants tab shows units behind the variant the new SKU belongs to. That number is computed from the fulfilment rules every time the tab loads — it is a read-out, not a field, so there is nothing to type into it directly. If it is still zero after the rule change, the rule is the thing to re-check.
  • A test booking of that listing (or that variant) holds one of the new units — check the item’s Events tab afterwards to confirm.

​
Troubleshooting / common pitfalls

Cause: the rule that should fulfil it uses is in list (or a single is) against item/SKU names or codes, and the new SKU’s identifier was never added to that list. Nothing about creating a SKU updates a fulfilment rule automatically, no matter how well it fits that list.What to do: open the condition, confirm which field it lists (names or codes), and add the new SKU’s matching value.
Cause: it looks like a field because it sits in a table cell, but it is derived — the live result of resolving that variant’s fulfilment rule against current stock, recalculated on every load. There is no way to set it, and no code path that writes to it.What to do: change the thing it is computed from instead — the fulfilment rule’s conditions (this guide) or the stock itself (missing attribute, wrong location, inactive status).
Cause: Item Names / SKU Names and Item Code / SKU Code are different fields matching different values on the stock item. Adding a code to a names list, or a name to a codes list, matches nothing.What to do: read the condition’s field label before typing anything in, not just the operator.
Cause: the rule is built on a maintained list of specific values rather than on an attribute every current and future SKU shares.What to do: if every SKU that should fulfil this listing (or variant) shares something structural, such as a category, a size, or a product line, add that as an attribute and rewrite the condition to match on it instead. See Listing inventory rules for matching on an attribute versus a fixed list.A list you maintain by hand is fine for a handful of SKUs that rarely change. It is the wrong tool for a catalog that keeps growing.
Cause: a Variant specific rule overrides the base rule for that variant value. The base rule’s list is not consulted for a variant that has its own rule.What to do: find and edit that variant’s own rule on the Fulfilment tab, not the base rule.

Register stock items

Create the SKU and the stock items behind it.

Listing inventory rules

The full rule model — matching fields, operators, and checking what a rule finds.

Set up variants

Variant-specific rules, and reading Stock Availability per variant.

SKUs

What a SKU is, and how Stock Items inherit from it.