> ## Documentation Index
> Fetch the complete documentation index at: https://docs.readyforcommerce.com/llms.txt
> Use this file to discover all available pages before exploring further.
> ## Agent Instructions
> Ready for Commerce is an ecosystem that currently contains two products, PIM and Repricer, standing on one shared foundation: one identity, one organization, one team, one bill. Do not call it a platform with features, and never hint at an unreleased product.
> PIM connects to Shopify, Amazon, Square, Google Merchant Center and BigCommerce. Repricer connects to Amazon, Walmart, Shopify, BigCommerce, eBay and Square. The two products do not share one list, and each integration is authorized separately inside each product. The roster grows on purpose, so describe what the product does and let a table carry which integrations do it today, instead of counting them or writing that only one does something.
> Integration is the word this product uses, and it is the default in the documentation: the connection, the account, the Integrations screen, the per-account settings and the sync state are all integrations. Channel is reserved for the narrow sense of a destination where a listing lives, as in a product being live on a channel or archived on the channel.
> Newegg is not a supported channel. Do not describe it.
> On Amazon, PIM manages the offer only: price, availability and condition. It does not publish listing content such as titles, descriptions, images or specifications.
> Sign-in is passwordless: a single-use code emailed to the user, or Google. There are no passwords anywhere, so never describe a password, a sign-up with a password, or an email confirmation link.
> There is no public API for customers and no customer-facing webhooks. There is no organization-wide activity feed and no audit export, but the PIM does keep version history on products, brands, categories, tags and specifications, with who changed what and a restore, so never write that changes are not recorded or that an edit cannot be undone. Do not describe capabilities that are not documented here.
> Never write that the products have no AI, and never write that anything is AI-powered. Both are wrong. The PIM's image Optimizer runs AI-backed transforms the seller starts on purpose: Upscale, Remove background, and the region selection behind Refine. The Repricer reads competitor prices off web pages on the server. No control, badge or tooltip in either product names AI, and the seller never writes a prompt, so describe what the buttons do in the app's own words instead of reaching for the word.
> A PIM product, brand, category or variant can be switched off per connected integration account. Hover the channel badge and the switch is beside the account name in the card that opens. It carries no visible caption, so never call it the Sync switch: Sync is only its accessible name. On a variant-grained provider, Amazon today, the switch moves into the variant editor. On a product it asks whether to delete it from the channel, archive it there, or leave it live. Disabling stops publishing, not reading. There is still no per-field sync toggle.
> The PIM's image Optimizer replaced a feature called Squarify, which no longer exists. It resizes to an aspect ratio or to exact dimensions, removes backgrounds, upscales, trims the transparent margin around a cutout and re-centers it, pads, fills and re-encodes, and it always publishes a new asset instead of changing the original. Nothing crops into the picture: the subject is always contained whole.
> The PIM has no repricing engine and never reacts to a competitor's price. It does build the price it publishes to each integration account from the seller's own fields, configured in that account's settings, so do not write that the PIM has no pricing rules.
> Neither product has an in-app notification center, bell or inbox. Notifications are delivered by email only.
> Billing is per organization and per product, and only the organization owner can see or change it. Team members are free and uncounted, so never describe seats or per-user pricing.
> The seller never picks a plan. Each product has twelve price tiers assigned automatically from usage: the PIM from catalog product count, which includes drafts and archived products, and the Repricer from trailing 30-day sales. Nothing is feature-gated by plan and exceeding a tier never blocks work, so never write that a feature requires a higher plan.
> A subscription that is past due or paused makes the product read-only, which stops repricing and blocks edits without deleting data. Only a canceled subscription locks the seller out. Nothing is ever charged without a payment method on file.
> Pages containing the text 'This page has not been written yet', or its Spanish equivalent 'Esta página todavía no está escrita', are placeholders. Do not treat their headings as documented behavior.
# Inventory
> Your stock comes into the PIM from several places at once, and it turns all of them into the single number your integrations get and sell against.
Stock in the PIM is the number of units you have to sell. Every variant has three of those numbers instead of one, because your units come from more than one place. Some are in locations your integrations report on, some are kept for you by a supplier, and some you count yourself. The PIM reads all three and calculates a fourth. That fourth number is the one that matters most to you, because it is the one every connected integration gets.
You only type into one of the three. The other two fill themselves in, one from the locations on your connected integrations and one from a supplier feed. So most of what you see on this screen is a read-out and not a form. People come here for one of three reasons. Something reads as out of stock and you want to know why. A product has no integration reporting on it and you want to give it a number. Or a published number looks wrong and you want to know which of your three counts produced it.
You will find all four numbers in the `Inventory` section of the product editor. Go to `Catalog`, select `Products`, and click a row to open the editor, then scroll down to `Inventory`, which is between `Pricing` and `Variants`. On a product that has options, you will not find that section there. Each variant has its own set instead, and you open one by clicking its row in the `Variants` section.
## Before you start
### What your role lets you do
| Role | Type a stock number | Turn tracking on or off | Change an integration's stock settings |
| --- | --- | --- | --- |
| Admin | Yes | Yes | Yes |
| Manager | Yes | Yes | No |
| Editor | Yes | Yes | No |
A Manager and an Editor can set stock on any of your products. Neither one can change an account's settings or a location switch, because `Integrations` is not in their sidebar at all. Roles are set in [team, roles and permissions](/team#what-each-pim-role-can-do).
### Turning tracking off erases the number you typed
Turning `Track Inventory` off empties all three stock numbers on that variant, including the `Fallback Stock` you typed. Turning it back on gives you a fallback of `0`. There is no undo.
The two numbers you never type fill themselves back in on their own, from wherever they came from. The one you typed does not come back, so write it down first if you plan to switch tracking off and on again.
## How to set a variant's stock
From `Catalog`, select `Products` and click the row of the product you want. The editor opens over the table.
Scroll down past `Pricing`. If the product has options, `Inventory` is not in the product editor: click a row in the `Variants` section instead, which opens `Edit Variant`, and use the `Inventory` section there.
`Track Inventory` is a switch at the top of the section. Four number fields appear under it as soon as you switch it on.
`Fallback Stock` is the only one of the four fields you can type into. It takes whole numbers of 0 or more, and it snaps back to `0` if you leave it empty.
Click the `Update` button at the bottom of the editor, or `Create` if the product is new. In `Edit Variant`, `Update` closes the variant and you still have to save the product itself.
That is the whole flow. Your number goes into `Fallback Stock`. `Effective Stock` under it changes to match, as long as nothing else is reporting stock for your variant. Your connected integrations get the new number on their next sync.
Everything below explains the other three numbers, the table under them, and what each of your integrations does with what it gets. You do not need any of it to put a number on a product.
## Every option in detail
### Turn stock tracking on and off
`Track Inventory` is a switch on the variant and not on the product, so a product with options needs you to set it once per variant. It is on for a new product, and on for every variant the PIM creates for you.
While it is off, your variant has no stock at all. That is not the same as having zero: a zero is a count you are making, and no count is a variant you have decided not to count. The three number fields do not even appear until you turn the switch on.
| When you | What happens to the numbers |
| --- | --- |
| Turn it on with nothing set | `Fallback Stock` becomes `0`. The other two go on showing whatever they already had |
| Turn it on over a number you typed | Your `Fallback Stock` is left alone |
| Turn it off | All three empty, and the two locations the PIM manages drop out of the table below |
Turning the switch off does not take the variant off your integrations. It stays published and it reads as out of stock, and the last section of this page sets out what each of your integrations gets.
### Who fills each of the three numbers
Each number has exactly one thing that writes it. Knowing which is which is what tells you where to go when a number looks wrong, because the place to fix it is almost never this screen.
| Number | What it counts | What writes it |
| --- | --- | --- |
| `On-hand Stock` | the units your connected integrations report at their own locations, added up | the PIM, from those locations |
| `Supplier Stock` | the units a supplier or a dropshipper keeps for you | a [data source](/pim/uploads/data-sources) feed |
| `Fallback Stock` | the number you keep yourself for whatever the other two do not cover | you, an import, or a data source feed |
`On-hand Stock` and `Supplier Stock` are read-only wherever you see them. They appear dashed, they take no keystrokes, there is no control that unlocks them, and saving your product leaves them exactly as they were. Both of them show `0` when nothing has been written yet, so an empty box is not what you are looking for.
**No one types `On-hand Stock`.** Every location an integration reports gets a switch deciding whether its count is part of the total, and you will find those switches under `Locations` on the account itself: open `Integrations`, click the provider card, then `Manage accounts`, then the account. Your own store locations and any third-party warehouse arrive switched on. If you have no integration connected there is nothing to add up, so `On-hand Stock` stays at zero and your `Fallback Stock` is the whole inventory.
**Your data source owns `Supplier Stock`.** An empty cell in that feed means zero and not nothing. So a feed that stops listing your product sets its `Supplier Stock` to `0`. So does un-mapping the field, deleting the source, or pausing it, and your fallback is used instead the moment that happens.
The PIM does not take orders, so one of your sales never subtracts from a number here directly. The integration subtracts from its own count and the new number comes back to the PIM, which is why you see `On-hand Stock` move without touching it. On an integration that reports a count change as it happens, you have the new number within seconds.
### Where Effective Stock comes from
`Effective Stock` is `On-hand Stock` plus `Supplier Stock` when that sum is above zero, and `Fallback Stock` otherwise. When all three are empty, it is blank.
Read that as an order of preference and not as a sum of everything. If anything real is reporting units for the variant, your fallback stays out of it. The number you typed only counts when both of the other two are empty or at zero. Treat it as a floor under a variant nothing else is reporting on, and never as a quantity added on top.
`Effective Stock` is read-only, and it is the only one of the four you cannot write from anywhere at all. It is also what the plain word `Stock` means everywhere else you see it. That covers the `Stock` column in your products table, the `Stock` column in the variants grid inside the editor, and the number the inventory report totals.
### Show the three numbers in the variants grid
On a product with options, the `Variants` section of the product editor lists every one of your variants in a grid. That grid shows `Stock`, the effective number, and keeps the three others hidden until you ask for them.
Click the `Columns` button in that grid's own toolbar, and check `On-hand stock`, `Supplier stock` and `Fallback stock` in the list it opens. They then appear beside `Stock` on every row, which is the fastest way for you to see which source is filling which variant without opening any of them.
`Stock` in that grid cannot be sorted or filtered. The three you just turned on can be filtered, so `Filters` in the same toolbar is how you narrow a long variant list down to the ones a supplier is covering, or the ones on your fallback alone. A variant with tracking off reads `Untracked` in the `Stock` column instead of a number.
### Read what each integration reports back
Under the four number fields, the editor shows you a read-only table of what every connected integration currently reports for that one variant, one row per location. This is where `On-hand Stock` comes from, shown to you before it is added up.
| Column | What it shows |
| --- | --- |
| `Location` | the name the integration gives that location |
| `Available` | units the integration says can be sold there right now |
| `Committed` | units it has already promised to orders it took |
| `Incoming` | units it expects to receive |
An `Integration` column appears in front of `Available` when more than one connected account has locations, so you can tell two accounts apart when they named a location the same way. With a single account you have nothing to tell apart, and the column stays away.
Two of the rows are not warehouses. They are the places the PIM makes on the integration to publish your stock into, and they are together at the top of the table. Each one has a `Managed` badge that explains itself when you hover it. They disappear from the table while `Track Inventory` is off, because the PIM is not publishing anything for that variant then.
Not every integration fills all three count columns. One that reports the orders it has taken fills `Committed`, and one that reports units on their way fills `Incoming`. Where an integration reports nothing beyond the available count, those two cells stay empty on its rows, and that is not a fault you have to chase. You cannot edit anything in this table on any integration, and there is nowhere in the PIM to set an available or a committed quantity.
The table hides itself in three cases, and never shows you empty rows, so a blank space where you expected it is usually one of them.
It needs at least one synced location, so you never see it with no integration connected. A freshly connected account does not show it until its first sync finishes. It needs a saved variant, so it stays away on a product you are still creating, and on a variant you added in `Manage Variants` and have not saved yet. And on an account whose only locations are the two the PIM manages, turning `Track Inventory` off removes both rows and the table hides with them.
### Cap what an integration publishes and hold units back
Each connected account decides how much of your `Effective Stock` it is allowed to show. `Maximum published quantity` caps your number and `Safety buffer` keeps units back from it. Both are in that one account's settings. Open `Integrations`, click the provider card, then `Manage accounts`, then the account, and `Settings` is at the top beside `Rename`. The page on [settings](/pim/integrations/settings) covers what each one starts on and the fixed order they apply in.
It matters here because the number you read in the editor is not always the number a shopper sees. Your `Effective Stock` is what the PIM offers, and the cap and the buffer are what the account is allowed to send. On an integration that also sells its own stock, a shopper can see more than your cap. That integration adds its own locations on top of what the PIM published for you.
On an integration where the PIM makes two locations, the cap and the buffer apply to those two added together, because what a shopper sees is the sum of them. The reduction comes off your supplier location first, and only touches the on-hand one once the supplier location has nothing left. A supplier quantity is the riskier of the two to promise, so the buffer takes from it before it takes units you can see.
`Multi-location stock` is a switch in your BigCommerce account's settings, it is the only place this choice exists, and it is on to begin with. On, the PIM keeps two locations in your store and never writes to your own. Off, it writes one combined total to your store's default location, overwriting whatever stock you entered there, and it removes the two locations it made.
The choice is yours because it rests on something no integration can report. The two-location model needs your store's aggregated stock turned on, which BigCommerce support does on request, and a store without it shows these products as out of stock.
### Find products by their stock
Your products table under `Catalog` has a `Stock` column showing the effective number, and two filters that read it. Both open from `Filters` above the table, where you pick a column under `Filter by` and then a condition.
| Set `Filter by` to | Pick the condition | What you get |
| --- | --- | --- |
| `Stock` | `is empty` | products with nothing sellable, which covers a tracked zero and an untracked variant alike |
| `Stock` | `equals (=)`, then type a number | tracked variants at exactly that number, and an untracked variant never matches |
| `Inventory Tracked` | `Yes` | products where every single variant is tracked |
| `Inventory Tracked` | `No` | products with at least one untracked variant |
`Inventory Tracked` is a filter with no column behind it, so you will not find it in `Columns`. It exists only in that panel, listed right above `Stock`. One untracked variant is enough to make a whole product read `No`. That is the answer when you turned tracking on for nearly every variant and the product still reads as untracked.
Sorting the table on `Stock` pushes untracked products to the end whichever direction you sort in, so they never end up between two real numbers.
### Set stock from a spreadsheet or a supplier feed
Typing into one variant at a time is not the only way in. A stock number can get to your variant three ways, and only one of them is the editor.
| Way in | What it can write |
| --- | --- |
| The product editor or `Edit Variant` | `Track Inventory` and `Fallback Stock` |
| An [import](/pim/uploads/imports) | `Track Inventory` and `Fallback Stock` |
| A [data source](/pim/uploads/data-sources) feed | `Track Inventory`, `Supplier Stock` and `Fallback Stock` |
An import is how you set stock on many products at once, because there is no bulk action for it. Selecting rows in your products table gives you tags, status and specifications, and nothing about stock.
Your export of `Products` can include every inventory column except the effective one, and an import reads back only two of them.
| Column | In an export | In an import |
| --- | --- | --- |
| `Track Inventory` | `Yes`, `No`, or empty when the variant is untracked | read, and it takes `yes`, `no`, `y`, `n`, `1`, `0`, `true`, `false`, `on` and `off` in any case |
| `On-hand Stock` | the number, empty when the variant is untracked | ignored |
| `Supplier Stock` | the number | ignored, so map it from a data source instead |
| `Fallback Stock` | the number | read |
| `Effective Stock` | never included | nothing to read |
Two things about `Track Inventory` matter before you build a file. A mapped column with an empty cell turns tracking on, while leaving that column unmapped keeps whatever your variant already had. And cleaning the field marks your variant untracked and empties all three stock numbers in one move.
### Limits
| What | Limit |
| --- | --- |
| Values a stock field takes | Whole numbers of 0 or more |
| Locations the PIM makes to publish your stock | 2 per account |
| Rows the locations table shows at once | 10 |
| Variants whose stock you can change in one action | 1 |
| Low stock in the inventory report | 1 to 10 units |
### What inventory cannot do
| You cannot | Do this instead |
| --- | --- |
| Type into `On-hand Stock` or `Supplier Stock` | Use `Fallback Stock`, or change the number where it comes from |
| Choose which location on an integration gets your stock | Nothing. Every integration has a fixed location |
| Set a low-stock warning, a reorder point or a backorder state | Read the [inventory report](/pim/reports/inventory), which counts the low ones for you |
| Get an email when a variant runs out | Filter your products table on `Stock` |
| Change stock on many variants in one action | Import a file with `Fallback Stock` in it |
| Publish a different number to each integration | Set a maximum and a buffer on each account |
| Set a `Committed` or an `Incoming` quantity | Nothing. Those two are the integration's own |
| Tint a cell or flag a number that is getting small | Read the inventory report's stock ranges |
## What your integrations get
Your `Effective Stock` is what leaves the PIM, and what an integration does with it depends on what that integration has to put it in. A store with locations gets locations. An offer on a marketplace gets one quantity. A shopping feed gets no number at all.
| Integration | What it gets |
| --- | --- |
| Shopify | two locations the PIM makes in your store, named `Supplier Stock` and `On-hand Stock` |
| Square | two locations the PIM makes in your Square account, with the same two names |
| BigCommerce | the same two locations, or one combined total at your store's default location |
| Amazon | one quantity on the offer, and only on a merchant-fulfilled (FBM) listing |
| Google | no quantity. Google is told the product is in stock or out of stock |
### An integration with locations of its own gets two more
On Shopify, Square and BigCommerce the PIM makes two locations of its own and writes to those two alone. Your own store locations stay read-only mirrors, which the PIM reads and never writes to, and that is what stops it overwriting stock you entered in your own admin.
The two are split by where your units came from. `Supplier Stock` gets your supplier quantity. `On-hand Stock` gets your on-hand number minus what the integration's own locations already report, and never goes below zero. That subtraction is the whole point of the pair. The integration is already counting the units at its own locations, so sending your full number again would count the same unit twice.
When neither of the two numbers you never type has units, the fallback you typed is published through the `Supplier Stock` location. So a number you keep yourself goes to your store under a name that says supplier.
### A marketplace offer gets one quantity
On Amazon the PIM manages your offer rather than the listing content, so the quantity goes out beside the price and the condition and nothing else. Only a merchant-fulfilled offer gets one. An offer Amazon fulfills is sent no quantity at all, because that count is Amazon's.
Amazon's own count comes back the other way instead, as one location per marketplace named for its country, as in `Amazon FBA (US)`. It arrives switched off, so those units are not part of your `On-hand Stock` until an Admin turns the switch on from the account's `Locations` list. Off is the right default for nearly everyone. Adding Amazon's own fulfillment units into your on-hand number and then republishing them as units you ship yourself counts the same stock twice. The page on [the Amazon integration](/integrations/amazon) covers the rest of that split.
### A shopping feed gets in stock or out of stock
Google takes a state and not a quantity, so the PIM works the state out from your number and your account settings, the same ones every other integration uses. A tracked variant with units left after the cap and the buffer is published as in stock, and one with nothing left is published as out of stock.
That is what makes your buffer mean the same thing on a feed as it does on a store. Keep 5 units back on a variant of yours that has 5, and the feed is told out of stock.
### What an untracked variant sends
Turning `Track Inventory` off does not take your variant off anything. It stays published and it reads as out of stock, and each of your integrations says that in the only way it can.
| Integration | What an untracked variant gets |
| --- | --- |
| Shopify | its quantity cleared, and the PIM's location switched off for that variant |
| Square | `0` at both of the PIM's locations, because Square's stock record has no delete and a zero is the only way to clear one |
| BigCommerce | `0` at the PIM's locations, and the product stops being tracked at all once every variant is untracked |
| Amazon | a quantity of `0` on a merchant-fulfilled offer, so it reads as out of stock and not as broken |
| Google | in stock, because untracked means the PIM is not counting and not that there is none |
## When something goes wrong
### What the Stock cell is telling you
The `Stock` column in your products table does not always have a number. Four things can be in it, and each one is telling you something different about the product on that row.
| The cell reads | When |
| --- | --- |
| `Untracked` | no variant on that row has `Track Inventory` on |
| `Out of stock` | every variant on the row is tracked and the total is zero |
| a number, then `in stock` | the product has one variant, it is tracked, and it has units |
| a number, then `in stock for` and a count of variants | the product has several variants and at least one of them is tracked |
The count in the last one only includes your tracked variants, so a product with 5 variants where 3 are tracked reads `in stock for 3 variants`. Expand a product row in your products table and each variant under it shows its own number, or its own `Untracked` badge, instead of the aggregate.
### When an integration rejects your quantity
An integration can accept your product and reject the stock on it. When that happens the integration's logo in the editor header shows a colored dot, and hovering it names the account and what came back to you, one line per field. That badge is the only place it shows, and the product itself still saves.
| Message | What to do |
| --- | --- |
| `Stock can't be negative.` | Nothing in the PIM lets you type a negative, so check the feed writing `Supplier Stock` |
| `Stock is above Shopify's maximum.` | Lower the number, or set a `Maximum published quantity` on the account |
| `Stock is below Shopify's minimum.` | Raise the number |
| `A stock quantity is above Shopify's maximum.` | The same, on a product whose variants were sent together |
| `This product isn't stocked at the Shopify location yet.` | Nothing in the PIM changes this. Stock the item at that location in your Shopify admin |
| `Shopify manages this item's stock automatically (e.g. a bundle).` | Turn `Track Inventory` off for that variant, since the PIM has nothing to add |
| `Shopify rejected a stock update for this product.` | Save the product again, and read the account's other messages for a reason |
| `Amazon rejected the stock quantity.` | Check the offer is merchant-fulfilled, because an offer Amazon fulfills takes no quantity |
| `BigCommerce rejected the inventory settings.` | Check whether your store has aggregated stock turned on |
| `A stock quantity is negative. Stock must be 0 or a positive whole number.` | Fix the cell in your import file and run the import again |
### When a number looks wrong and stays wrong
Start with which number is wrong, because that decides where you go. A wrong `Supplier Stock` is a wrong cell in the feed you mapped. A wrong `On-hand Stock` is a wrong count at one of the locations in the table under it, or a location switch you set the way you did not mean to.
Sometimes your number is right at the source and stubbornly wrong in the PIM. There is one repair for that: turn `Track Inventory` off on that variant, and turn it right back on. The two numbers you never type refill from whatever has been written since, and your fallback comes back as `0`. It costs you the number you typed, so it is worth it only when the number really is wrong.
## Where to go next
Where these four numbers move once your product has options.
The cost that follows whichever of your sources has the stock.
The maximum and the buffer each of your connected accounts applies.
The feed that owns your supplier stock, and how to map it.