> ## Documentation Index
> Fetch the complete documentation index at: https://docs.fire.rest/llms.txt
> Use this file to discover all available pages before exploring further.
# Out of stock
> Turn off a product that ran out mid-service and let it come back on its own, without touching the menu or relying on someone remembering.
It is two in the afternoon and the kitchen has run out of fries. The product is still selling, orders keep coming in, and somebody is going to have to call the customer and tell them there are none. Until now the alternative was editing the menu: slow, risky, and with a guarantee that at six, when the delivery arrives, nobody will remember to undo it.
This screen exists for that. Turn the product off for a while, with a reason, and it comes back on its own. Go to **Restaurant OS → Operations → Out of stock**.
***
## The minimum you need to know
**1. You are not editing the menu.** The published menu is untouched. This is a separate, temporary layer that switches itself off. Nobody has to remember to undo it.
**2. Every turn-off has an expiry, and it never outlives the store's closing.** If the store closes at 22:00, no turn-off survives that hour. The next day the product wakes up selling.
**3. The reason is mandatory and cannot be edited afterwards.** It is the only thing left to explain why the product was turned off. Write it for whoever reads it tomorrow.
**4. The turn-off travels to the channels where the product sells.** Turning off, restoring and expiring all reach the kiosk, the till and the aggregators. The screen tells you if one of them did not get the word.
***
## The simple path
Something ran out and you want it out of sale now:
1. Pick the store in the selector at the top right.
2. Find the product and open the three-dot menu on its row.
3. **Turn off temporarily**.
4. Leave the duration at **1 hour**, write the reason and confirm with **Turn off**.
Done. The product goes to **Turned off**, the **Until** column shows what time it comes back, and it comes back on its own.
If this is your case — it ran out, I turn it off, it comes back when the delivery arrives — you are finished. The rest of this manual is for when the turn-off has to last until closing, or affect only one channel.
***
## How long the turn-off lasts
The first thing you decide when turning a product off is how long.
| Option | What it does |
| ------------------------------------- | -------------------------------------- |
| **30 min** · **1 hour** · **2 hours** | Counts from now |
| **Until closing** | Until the store closes its service day |
| **Specific time** | A time today that you type |
The same line always appears below: **"Comes back automatically at…"**, with the time and how long is left. It is the confirmation of what you just picked.
### The ceiling is the store's closing time
No turn-off can outlive the close of the service day. The dialog says so, always: *"It can never outlive today's service — the store closes at…"*, with that store's closing time.
That is why the options that would run past closing **appear disabled**. Twenty minutes before closing, **1 hour** and **2 hours** cannot be picked: all that is left is **30 min**, **Until closing** and a **Specific time** before closing.
**Why you cannot turn a product off until tomorrow.** A product being out of stock is a fact about today's service. Tomorrow the kitchen opens with another reality, another delivery and probably other people. A turn-off that crosses closing arrives the next day without anyone having decided it, and the first person to find out is the customer who orders the product and is refused.
If there will be none tomorrow either, the right answer is not to stretch the turn-off: it is to take the product out of the menu.
### Changing the duration without starting over
If the turn-off falls short, the three-dot menu has **Change expiry**. It moves the time and nothing else.
**The reason cannot be changed.** **Change expiry** only moves the time. The reason is the evidence of why the product was turned off, and rewriting it while the turn-off is still live would leave a record that does not match what happened. If the reason genuinely changed, restore the product and turn it off again.
***
## The times are on your clock; the closing is the store's
They are two different questions and it pays not to mix them.
**How long can a turn-off last?** The store decides, with its operational closing time. The store is what opens and closes.
**Which clock are the times on screen written in?** Yours. All of them — the dialog, the **Until** column, the detail and the **Audit** — are shown in your device's time zone, the same as everywhere else in the panel. You will never see two different times for the same turn-off.
If you manage stores in another country, both things show up together. A São Paulo store that closes at 22:00, operated from Ecuador — two hours behind — shows *"the store closes at 08:00 PM"*. These are not two schedules: it is the same instant, written on the clock in front of you.
The only place that names the store's clock is the error message when you try to run past closing. There it does say the time is the store's, because that is the schedule the store publishes and it is what makes the limit understandable.
***
## Where it gets turned off: the channels
A product can have run out in one channel and not in another. The **Where?** block decides the scope.
* **Every channel in this store** — the product stops selling across the whole store.
* **Only some channels** — you tick the channel and fulfillment pairs affected.
Each checkbox is a **channel · fulfillment type** pair: *Kiosk · Takeaway*, *Kiosk · Dine-In*, *Point of Sale · Takeaway*, *Point of Sale · Dine-In*. The channels listed are the ones that store has configured.
In the table, the **Scope** column shows **All channels** or the specific pair, so you can see at a glance how far each turn-off reaches.
**Turning off too much costs sales.** If the product ran out for takeaway but there is still some for dine-in, picking **Every channel in this store** stops you selling where you did have product. The broad scope is the convenient one to tick and the one that leaves the most money on the table.
### The scope decides who gets told
The turn-off is only sent to the channels the scope touches. A turn-off on **Kiosk · Takeaway** says nothing to the till or to the aggregators. A turn-off on **Every channel in this store** talks to every channel that store has configured.
Each kind of channel receives the word its own way, but that is the system's business: what you pick is the scope.
***
## When the channel does not know the menu yet
A product can be in the menu assigned to the store and never have reached the channel, because that menu has not been published yet. Over there the product does not exist, so there is nothing to turn off — and the attempt is rejected before anything is saved:
> Ninguno de los canales de este alcance tiene el menú de la tienda sincronizado, así que allá el producto no existe y el apagado no tendría efecto. Sincronizá el menú y volvé a intentarlo.
Products are listed from the assigned menu on purpose, so they show up even before publishing. Publish the store's menu and the turn-off becomes available.
A channel that is **unconfigured or disabled** blocks nothing: it is not the destination of any notification, and that is about the account's configuration, not about the product.
### The other two rejections
| Message | What to do |
| ------------------------------------------------------------------------------ | ------------------------------------------------------------------------------------------------- |
| *"Ese producto ya tiene un apagado vigente que se superpone con este alcance"* | Restore the turn-off that already exists, then turn the product off again with the scope you want |
| *"Ese producto no se vende en alguno de los canales seleccionados"* | Untick that pair: the store does not have it assigned |
***
## When the product is also a side
A product does not always sell on its own: it can be an option inside a combo. That is why, when the product you are about to turn off is also sold inside modifier groups, the dialog names them before you confirm:
There is nothing to decide: the notice is there so you know the real reach of what you are turning off.
**As an option inside a combo, the product can still be picked.** The turn-off records those options — they show in the detail and in the **Audit** — but it does not turn them off. What the channels receive is availability **per product**, and an option inside a combo has nowhere to go in that.
If the product mostly sells as a side, turning it off is not enough: it has to come out of the modifier group in the menu.
***
## Selling again
There are two paths, and the normal one is to do nothing.
**It expires on its own.** When the time comes, the product sells again with nobody stepping in. It is the default behaviour and the reason the duration is mandatory.
**Restore now.** If the problem was solved earlier, the three-dot menu has **Restore now** and the product comes back immediately.
The header holds up to four counters, and the last two only appear when there is something to deal with: how many products are **turned off**, how many are **expiring within the hour**, how many **were not turned back on** and how many are **without notifying a channel**. The first two are the picture of the service; the last two are things somebody has to resolve.
The filters above the table are four: **All**, **Turned off**, **Expiring soon** and **Not turned back on**.
The **Until** column shows **the time**, not a countdown. A countdown forces you to do the arithmetic in your head and goes stale the moment you look away.
### Turning several off at once
Ticking the checkboxes on several rows brings up **Turn off temporarily (N)** at the top. The dialog is the same, and what you pick applies to everything selected: same duration, same scope, same reason.
Only products that are selling go in. The ones already turned off are ignored, so there is no risk of overwriting an existing turn-off by over-selecting.
***
## When the product was never turned back on
The automatic turn-back-on rides on a single scheduled task. If that task fails, the product shows as selling again here while **the channel still has it turned off**. That is the dangerous case: the screen is wrong in the direction that costs sales.
That is why it flags itself:
* A counter in the header: **N were not turned back on**.
* A **Not turned back on** filter, to isolate them.
* On the row, the status **Still off in the channel**, with the last attempt's error on hover.
* The **Turn back on now** action, which is the real fix: it closes the turn-off **and** sends the channel the switch-on the task failed to send.
**A product that says "Selling" is not always selling.** If you see that counter, deal with it before the shift change: every row there is a product the channel is not offering and nobody decided to leave off.
***
## When a channel did not get the word
Saving the turn-off and telling the channel are two different things, and they are reported separately: first the notice that the product was turned off, then a **second notice** about the channels.
| Notice | What it means |
| ----------------------------------------------------------- | ------------------------------------------------- |
| **Availability sent to the channels** | It reached all of them |
| **Sent, but some channels are not configured yet** | It reached some; others are missing configuration |
| **The channels are not fully configured: nothing was sent** | Configuration is missing on all of them |
| **Part of the change could not be sent to the channels** | Some channel rejected the notification |
| **The channels could not be notified** | None of them received it |
In every case **the turn-off was saved**: a channel being down never reads as a failed turn-off. And the verdict does not leave with the notice — live turn-offs that did not reach some channel are counted in the header as **N without notifying a channel** and carry the **A channel was not notified** mark on their row.
The notice says **sent**, never "applied". A channel can accept the notification and take a while to reflect it.
***
## Publishing the menu closes the turn-off
Publishing the store's menu re-emits the product with the availability the **menu** states, so in that channel it starts selling again. The menu wins, and the system acknowledges it instead of arguing with it: the turn-off is closed with the outcome **Replaced by a sync** and its scheduled turn-back-on is cancelled.
It is closed **when the publish covered every channel in the turn-off's scope**, and not before.
| Turn-off scope | What was published | What happens |
| -------------------- | --------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------- |
| **Kiosk · Takeaway** | the kiosk's menu | Closed: **Replaced by a sync** |
| **All channels** | the menu for every channel in the store | Closed: **Replaced by a sync** |
| **All channels** | only the kiosk's menu | **Still turned off.** Nobody republished anything for the till or the aggregators, so over there the product really is still out of sale |
That last row is the reason for the rule: if a partial publish closed the turn-off, the screen would say "Selling" for a product two channels are still not offering, and its turn-back-on — the one that did have to reach them — would be cancelled.
The publish has to be **later** than the turn-off and have finished cleanly. A menu published before the turn-off undid nothing, and a publish that failed on the channel does not count either.
**Why the menu wins.** A turn-off is a correction to today's service; publishing the menu is a deliberate decision about what the store sells. If the turn-off survived, the screen would keep claiming "Turned off" while the channel is already selling, and later a switch-on would go out for something nobody had turned off any more.
If there is still none of the product after publishing, it has to be turned off again.
***
## The Audit tab
**Audit** keeps every turn-off in the store and how each one ended.
| Outcome | What happened |
| ---------------------- | ----------------------------------------------------------------------------------------- |
| **Active** | Still turned off right now |
| **Restored** | Somebody put it back on sale by hand |
| **Expired** | The duration ran out and it came back on its own |
| **Replaced by a sync** | The menu was published to every channel in scope and the turn-off was left without effect |
Every row carries the user and the reason. It is the answer to *"why didn't we sell fries yesterday between two and six?"*, and it is why the reason is mandatory.
The detail of a live turn-off opens from **View detail**:
The **Via** field says where the product was turned off from. **Fire** is the panel; a turn-off done from the point of sale shows its own origin, and is restored from here just the same.
***
## Recipes: how the real cases get solved
1. Pick the store in the selector at the top.
2. Type "fries" in the search box.
3. Open the three-dot menu on the row and pick **Turn off temporarily**.
4. Duration **1 hour** — what you reckon the delivery takes — and scope **Every channel in this store**.
5. Reason: *"Ran out of stock in the kitchen"*.
6. **Turn off**.
The second notice tells you whether the channels got the word. If the delivery arrives earlier, **Restore now**. If it takes longer, **Change expiry**.
1. Filter or search so the table holds that station's products.
2. Tick all of their checkboxes.
3. **Turn off temporarily (12)** appears at the top.
4. Duration **Until closing**: the hot kitchen is not opening again today.
5. Reason: *"Hot kitchen closed for the day"*.
6. **Turn off**.
All twelve end up turned off with the same duration and the same reason, and tomorrow they wake up selling.
1. Open **Turn off temporarily** on the product.
2. Under **Where?**, pick **Only some channels**.
3. Tick only the kiosk pairs: *Kiosk · Takeaway* and *Kiosk · Dine-In*.
4. Reason, then **Turn off**.
In the table, the **Scope** column stops saying "All channels" and shows the specific pair. The notification travels only to the kiosk: the product keeps selling at the till.
1. Open **Turn off temporarily**.
2. Duration **Until closing**.
3. Reason: *"No supplier delivery, restocking tomorrow"*.
4. **Turn off**.
The turn-off dies with the service day. When you open tomorrow the product is selling again, so if the delivery did not arrive it has to be turned off once more — nobody is going to warn you.
1. Filter by **Turned off** to see only what is out of sale.
2. Open the product's three-dot menu.
3. **Restore now**.
It sells again immediately, and the switch-on goes out to the channels in scope. In **Audit** it stays as **Restored**, with the real time it came back.
1. Open the three-dot menu on the turned-off product.
2. **Change expiry**.
3. Pick the new time and save.
Only the time moves: the original reason stays as it was. If what changed is the reason — it is no longer "out of stock" but "broken fryer" — restore the product and turn it off again with the right reason.
1. Filter by **Not turned back on**.
2. Go through each row: the **Still off in the channel** status shows the last attempt's error on hover.
3. In the three-dot menu, **Turn back on now**.
That closes the turn-off and sends the channel the switch-on that never went out. Do it before the shift change: until then, those products are not being offered.
1. Note which store it happened in, and with what scope.
2. Go to that store's menu publishing and publish it.
3. Come back to **Out of stock** and try the turn-off again.
The product shows in the list because it is in the menu assigned to the store, but while that menu is unpublished the channel does not know it and there is nothing to turn off over there.
***
## One service, hour by hour
A store that closes at 22:00. This is what the operator sees at each point:
| Time | What happens | Status in store | **Until** column |
| ----- | --------------------------------------------------------- | --------------- | ---------------- |
| 12:40 | The fries run out. **1 hour** turn-off, every channel | **Turned off** | 13:40 |
| 13:10 | The delivery is late. **Change expiry** to 15:00 | **Turned off** | 15:00 |
| 14:20 | The delivery arrives. **Restore now** | **Selling** | — |
| 19:00 | They run out again, no more deliveries. **Until closing** | **Turned off** | 22:00 |
| 22:00 | The service day closes. The turn-off expires on its own | **Selling** | — |
Both entries stay in **Audit**: the first as **Restored** at 14:20, the second as **Expired** at 22:00. Nobody had to remember anything.
And if at 19:00 someone had tried to turn the product off "until tomorrow at noon", the dialog would not have allowed it: that store's ceiling is 22:00.
***
## Mistakes that cost money
**Turning off every channel when it was missing in only one.** It is the option ticked by default and the fastest one to confirm. If the product only ran out at the kiosk, you also stop selling it at the till and in the dining room, where you did have it.
**A generic reason.** *"Test"*, *"out of stock"*, *"xx"*. The reason is the only thing left in the history and it **cannot be edited**. When somebody asks a month from now why that product was out of sale for four hours, that text is the whole answer there is going to be.
**Believing you can turn a product off until tomorrow.** The turn-off dies with the service day, always. If the product is going to be missing tomorrow too, it has to be turned off again at opening — or taken out of the menu, which is the right tool when the problem is not about one service.
**Ignoring the counters on the right.** **Were not turned back on** and **without notifying a channel** are not informational: they are products whose state in the channel does not match what the screen says. Each one is either a sale that is not happening, or a sale of something you do not have.
**Counting on the turn-off for a product that sells as a side.** Turning it off takes it out of the à la carte listing, but it can still be picked inside a combo. If that is where it sells, it has to come out of the modifier group.
**Reading out the time you see over the phone, from a different country than the store.** What the screen shows is written on your clock, not the store's. If you tell the manager "it comes back at eight" and they are two hours ahead, each of you is talking about a different moment.
***
## Glossary
| Term | What it means |
| ------------------------------- | --------------------------------------------------------------------------------------------------------------- |
| **Temporary turn-off** | Taking a product out of sale in one store, for a while and with an expiry. It does not touch the menu. |
| **Duration** | What time the turn-off lasts until. Picked when turning off, and movable afterwards. |
| **Service day** | The store's working day, with its closing time. It is the ceiling of any turn-off. |
| **Scope** | Where the turn-off applies: the whole store, or only certain channels. It also decides which channels get told. |
| **Channel** | Where the sale comes in: kiosk, point of sale, aggregators, and whatever the store has configured. |
| **Fulfillment type** | How the order is handed over: takeaway, dine-in. It combines with the channel. |
| **Reason** | Why it was turned off. Mandatory, minimum five characters, cannot be edited afterwards. |
| **Modifier group** | The set of options in a combo. |
| **Audit** | The history of every turn-off in the store and how each one ended. |
| **Restore** | Putting the product back on sale before the duration runs out. |
| **Not turned back on** | A turn-off whose duration expired but whose switch-on never reached the channel. Has to be resolved by hand. |
| **Without notifying a channel** | A live turn-off that did not reach one of the channels in its scope. |
| **Menu sync** | Publishing the store's menu to its channels. It closes the live turn-offs whose scope it covered completely. |
| **Replaced by a sync** | The outcome of a turn-off closed because the menu was published to every channel in its scope. |
| **Via** | Where the product was turned off from: the panel (**Fire**) or the point of sale. |
***
## Frequently asked questions
Because a turn-off cannot outlive the close of the store's service day. It is a rule, not a technical limit: the state of today's kitchen says nothing about tomorrow's service, and a turn-off that crosses the night arrives the next day without anyone having decided it.
If the product is going to be missing for several days, the right move is to take it out of the menu.
Yes. Turning off, restoring and expiring all travel to the channels in scope, each with its own mechanism: X-Mart channels get the product listing, and aggregators get an availability event per channel.
What stays here is the record: this screen is Fire's operational account of what stopped being sold, when and why. It never becomes part of the menu — the menu still says the product exists, and the turn-off says it is not selling right now.
The one thing that does not travel is the product as an **option inside a combo**: there is nowhere to put it in what the channels receive. It is recorded on the turn-off, but it can still be picked.
From the second notice that appears when you save, and from the table header. If some channel was left uninformed, the turn-off adds to the **without notifying a channel** counter and its row carries the **A channel was not notified** mark. The turn-off was still saved: what is missing is the notification, not the turn-off.
Your device's, on every screen: the dialog, the **Until** column, the detail and the **Audit** all use the same clock, so you will never see two different times for the same turn-off.
What does not depend on your clock is the limit. A turn-off cannot run past the store's closing, and the store sets that closing; if you are in another country, you see it translated into your time.
It sells again on its own once the duration runs out. That is the point: the turn-off does not need anyone to remember to undo it. In **Audit** it stays as **Expired**.
If the switch-on never made it to the channel, the product shows up in the **Not turned back on** filter and is resolved with **Turn back on now**.
That is a turn-back-on that never went out. Filter by **Not turned back on**: it shows there with the **Still off in the channel** status and the last attempt's error. **Turn back on now** resolves it and sends the channel the switch-on that was missing.
The ones the publish covered completely get closed. Publishing the menu re-emits the product with the menu's availability, so in those channels it starts selling again: the turn-off is left without effect and is closed as **Replaced by a sync**, cancelling its scheduled turn-back-on.
If you published only some channels and the turn-off reached more, **the turn-off stays live**: in the channels you did not republish the product is still out of sale and its turn-back-on still has to reach them.
If there is still none of the product after publishing, it has to be turned off again.
The product is in the menu assigned to the store, but that menu has not been published to the channels in that scope yet. Over there the product does not exist, so there is nothing to turn off. Publish the store's menu and try again.
The list shows what that store actually sells: the products in the menu it has published or assigned. If the product is not in that menu, it cannot be turned off because it is not selling there.
Check which menu the product is in, and which menu the store has assigned.
That shows up when the store has no menu yet, and then there is nothing to turn off. The **Go to menu assignments** button takes you straight to fixing it.
Yes. A live turn-off is operational state, not the property of whoever created it. The **Via** field in the detail says where it was made from, but it does not limit who can put the product back on sale.
***
## What is coming
* **Hot pricing.** Changing a product's price during service with the same duration-and-reason mechanics, without touching the price list.