> ## 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 work out what is available, and why something is not

> Answer "is this free on these dates" from the admin, and diagnose the ordinary reasons a unit that looks free still cannot be booked.

<Card title="Open in TWICE Admin" icon="external-link" href="https://admin.twicecommerce.com/inventory/stock-items" horizontal>
  inventory/stock-items
</Card>

This guide is written for the awkward version of the question. Not "what is free next week" — the timeline answers that on sight — but the one that arrives by phone: *a customer says they should be able to book this, and they can't, and I can see the item sitting right there.*

Almost always, the answer is that having stock and being bookable are two different things. **Raw availability** is whether a unit is free. **Eligibility** is whether the listing can be sold at that location at all. A unit can pass the first and fail the second, and nothing in the inventory table will tell you so.

Work through it in that order.

## Prerequisites

<Warning>
  **Required permission:** `inventory:stock_item:view`. All four system roles hold it.

  Diagnosing eligibility also means looking at the listing and the location, so their view permissions matter for the second half of this guide.
</Warning>

<Info>
  **Have ready:** the exact dates the customer tried, the location they were booking from, and the listing they were looking at. All three matter — the same unit can be bookable for one of these combinations and not another.
</Info>

## The Walkthrough

<Steps>
  <Step title="Look at the timeline first">
    Open **Inventory > Stock items** and switch to the timeline view. It lays units against dates, so a unit that is already committed shows as committed, and the gaps are what is genuinely free.

    If the dates the customer wanted are visibly occupied, you are done — the unit is booked, and the rest of this guide is not your problem.
  </Step>

  <Step title="Check the unit itself is in play">
    A unit can be free on the timeline and still contribute nothing. Two states do that:

    * **Inactive** — the unit is not offered for new bookings. Existing bookings behind it stay put.
    * **Archived** — the unit has left service and contributes no capacity at all. Archived items also drop out of the default lists, so if you cannot find the unit, this is the first thing to check.

    Read more: [Stock Item Status](/docs/concepts/inventory/stock-item-status)
  </Step>

  <Step title="Check what is holding the dates">
    If the unit is active and the dates look free but the booking is refused, something is holding them that is not another order. Open the item's **Events** tab:

    * **A reservation or internal hold** — maintenance, an internal booking, anything scheduled. It blocks the dates without being an order.
    * **Buffer time** — turnaround padding around a neighbouring booking. Buffers extend the block beyond the rental period itself, so a unit can be refused for dates that look clear on either side of an existing booking. This is the most common answer to "but it comes back on Tuesday and they want it Tuesday".
    * **An existing conflict** — a booking that has this unit assigned with nothing actually holding it.

    Read more: [Buffer times and bin locations](/docs/guides/inventory/buffer-times-and-bin-locations)
  </Step>

  <Step title="Check the listing draws from this unit at all">
    Stock does not attach itself to a listing. A listing draws from whatever its fulfilment rules match, and a unit outside those rules is invisible to it regardless of how free it is.

    This is worth checking early on newly added stock: register a unit, forget to make it match the rule, and it sits in inventory contributing nothing.
  </Step>

  <Step title="Check eligibility at that location">
    This is the step people skip, and it is the one that explains the strangest reports. Three conditions must all hold for a listing to be sellable at a location, and failing any one makes it unavailable there:

    | Check                                                                  | If it fails                                          |
    | ---------------------------------------------------------------------- | ---------------------------------------------------- |
    | The listing's **status is active**                                     | The listing is unavailable everywhere, not just here |
    | The listing is **available at that location**                          | Unavailable at this location                         |
    | The location **offers in-store pickup for the way this is being sold** | Unavailable at this location                         |

    The third one is the trap. Fulfilment is set per purchase type, so a location that offers pickup for sales but not for rentals makes a *rental* listing ineligible there — while the same listing sells fine as a purchase, and the stock sits on the shelf the whole time.

    Read more: [Availability](/docs/concepts/catalog/availability) and [Locations](/docs/concepts/admin/locations)
  </Step>
</Steps>

## How do I know it worked?

You have a real answer when you can name which check failed:

* **Occupied** — the timeline shows another commitment.
* **Held** — Events shows a reservation, a buffer, or a conflict.
* **Out of service** — the unit is Inactive or archived.
* **Not drawn from** — the listing's rules do not match this unit.
* **Not eligible here** — the listing is inactive, not available at this location, or the location does not offer the right fulfilment for this purchase type.

"It should work" is not one of the five. If you get there, the last two are almost always where it actually is.

## Troubleshooting / Common Pitfalls

<AccordionGroup>
  <Accordion title="The stock is there, the dates are free, and the storefront still says unavailable">
    **Almost always eligibility, not stock.** The storefront asks whether the listing can be sold at that location. Inventory answers a different question.

    **What to do:** work the three eligibility checks in order — listing status, then the listing's locations, then whether the location offers in-store pickup for the purchase type being sold. The third catches the most people, because the stock is visibly present the entire time.
  </Accordion>

  <Accordion title="It is refused for a date right after a rental comes back">
    **Buffer time.** Turnaround padding after a booking blocks the dates immediately following it, so a unit returning Tuesday morning may not be bookable Tuesday.

    **What to do:** check the **Buffer time** column on the item's Events tab for the neighbouring booking. Buffers are configurable, and the chip in that column opens for editing — but change it knowing you are shortening the turnaround your operation actually needs.
  </Accordion>

  <Accordion title="One unit of a pooled SKU is free but customers still cannot book">
    **Cause:** on pooled stock, availability is a count, not a named unit. If the SKU's other units are committed, the free one still has to be one the listing's rules draw from, at a location that is eligible.

    **What to do:** check the listing's rules and the unit's location, rather than assuming a free unit anywhere satisfies demand everywhere.
  </Accordion>

  <Accordion title="The item is not in the Stock items table at all">
    **Cause:** the lists return active records by default, so an archived unit is simply absent.

    **What to do:** look under **Settings > Archived assets**. An archived unit contributes no capacity, which is exactly the availability answer — it is not that the dates are taken, it is that the unit is gone.
  </Accordion>

  <Accordion title="The Events tab flags a conflict on the dates in question">
    **Cause:** an order has this unit assigned with no reservation behind it. The order still expects the item, so the dates read as spoken for while nothing actually holds them.

    **What to do:** resolve it on the order by reassigning to an available unit. Conflicts do not clear themselves.

    Read more: [Stock Item Conflicts](/docs/concepts/orders/stock-item-conflicts)
  </Accordion>

  <Accordion title="Availability is right in the admin and wrong on the storefront">
    **Cause:** they are answering different questions. The admin shows you stock. The storefront shows a customer what they can buy, from a location, in a purchase type, at a moment in time — and any of those can rule the listing out with the stock untouched.

    **What to do:** reproduce it as the customer: same location, same dates, same rental-or-purchase choice. A difference that vanishes when you match all three was eligibility, not stock.
  </Accordion>
</AccordionGroup>

## Next Steps

<CardGroup cols={2}>
  <Card title="Availability" icon="calendar-check" href="/docs/concepts/catalog/availability">
    The model behind the checks in this guide.
  </Card>

  <Card title="Buffer times and bin locations" icon="clock" href="/docs/guides/inventory/buffer-times-and-bin-locations">
    The turnaround padding that blocks dates either side of a booking.
  </Card>

  <Card title="Stock Item Conflicts" icon="triangle-exclamation" href="/docs/concepts/orders/stock-item-conflicts">
    Bookings assigned to a unit with nothing holding it.
  </Card>

  <Card title="Reserve a stock item" icon="calendar-plus" href="/docs/guides/inventory/reserve-a-stock-item">
    Creating the holds that take a unit out of availability.
  </Card>
</CardGroup>