> ## 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 read a stock item's history > Answer "where has this unit been" from a stock item's Events and Activity log tabs — what each one records, and why the two are not the same history. inventory/stock-items Sooner or later someone asks a question about one specific unit. Who had it in March. Whether it was in the workshop when that damage was reported. Why it shows as unavailable next Tuesday. Who changed its location, and when. A stock item answers all of that, but across **two tabs that record different things** — and picking the wrong one is the usual reason people conclude the history is missing. * **Events** is the operational timeline: where the unit was committed, and when. Bookings and scheduled events, on one axis of time. * **Activity log** is the audit trail: who edited the record, and what changed. "It was out on a rental" is an Events question. "Someone changed its status and I want to know who" is an Activity log question. This guide covers reading both, and the traps in each. ## Prerequisites **Required permissions:** `inventory:stock_item:view` for the item and its events. All four system roles hold it. Reading the item's costs is separate — `stock_item_cost` is the one inventory sub-resource the Member role does not hold — so the Income & Expenses tab may be missing for you even when the history tabs are not. **Worth knowing before you start:** the Events tab is filtered to the locations you currently have in scope. On a multi-location account this is the difference between "no history" and "no history *here*" — see the pitfalls. ## The Walkthrough Go to **Inventory > Stock items** and open the unit. If you only have a code or a barcode, search the table for it rather than scrolling — the item's own page is where every tab below lives. **Events** merges two kinds of row into one timeline, which is what makes it useful: * **Order bookings** — one row per time this unit was committed to an order. The **Event name** column reads *Order*, and **Reference** is the order it belongs to. * **Scheduled events** — reservations, maintenance, internal holds. The name is whatever the event was called, or its type. The columns worth knowing: | Column | What it tells you | | ----------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------- | | **Start Date** / **End Date** | The committed period. For an order row this is the pickup and return, falling back to the line item's rental period when those are not set. | | **Event name** | *Order* for a booking; the event's own name otherwise. | | **Buffer time** | Turnaround padding around a booking, shown as *before* / *after*. Selecting the chip opens it for editing. | | **Reference** | The order for an order row, the event's own identifier otherwise. | | **Created at** | When the row was made — not when the period starts. Useful for "when was this booked". | | **Comment** | Free text on a scheduled event. | | **Location** | Which location the row belongs to. | | **Has conflicts** | Flags a row that is committed with nothing actually holding it. | Read it top to bottom for provenance: the order rows are the unit's working life, and the gaps between them are what it did when it was not earning. **Activity log** is scoped to this one item, so everything on it is about this unit. It answers a different question entirely: not where the unit went, but who touched its record. That is the tab for "its status changed and nobody owns up", "the location is wrong and I want to know when it moved", or any question ending in *who did this*. Actions taken through the API are attributed too, rather than showing as anonymous. The tab does not appear until the item exists, so a stock item you are still creating has no log yet. Read more: [Activity Logs](/docs/concepts/admin/activity-logs) Events tells you *that* the unit went out on an order and *when*. It does not tell you who rented it, what they paid, or how it came back. Open the order from the row's **Reference** for that. The unit's condition on return, any damage charged, and the customer are all on the order, not on the item. ## How do I know it worked? You have the answer when you can say which tab it came from: * **A period the unit was committed** — Events, with a start and end and a reference. * **A change to the record, with a person and a timestamp attached** — Activity log. If neither tab shows what you expected, that is a real finding rather than a dead end. Work through the pitfalls below before concluding the history is missing. ## Troubleshooting / Common Pitfalls **Most likely cause: location scope.** The Events tab only lists rows belonging to the locations currently in your scope. A unit that spent its life at a location you are not viewing shows an empty timeline, with no message explaining why. **What to do:** widen the location selection and look again. This is the first thing to check on any multi-location account, and it accounts for most "the history is gone" reports. **Other causes:** the bookings were on a different unit of the same SKU — easy on pooled stock, where the SKU is booked and units are interchangeable. Check the SKU's other items. **There is no Orders tab on a stock item.** Orders appear as rows inside **Events**, named *Order*, with the order in the **Reference** column. A customer profile does have its own Orders tab, which is where the expectation usually comes from. For a unit, the timeline is the orders view. **What it means depends on the row.** On an **order** row, the booking has no assigned unit behind it — the order still expects this item, but nothing is holding it. That is a stock item conflict and it needs resolving on the order. On a **reservation** row, the reservation has no unavailability behind it and has not yet ended, so it is not actually blocking the dates it claims to. **What to do:** for order rows, open the order and reassign. The **Buffer time** cell on a conflicted booking shows a dash rather than a chip, with a tooltip explaining that a booking with no assigned unit has nothing to pad — that is the same condition seen from another angle. Read more: [Stock Item Conflicts](/docs/concepts/orders/stock-item-conflicts) **Cause:** audit history has a retention window, and it depends on your plan. Older entries are not hidden — they are gone. **What to do:** for anything you need to keep beyond the window, take it out while it is still there. The [Activity Logs](/docs/concepts/admin/activity-logs) concept page has the retention detail and what the log records. **Wrong tab.** Neither history tab carries money. **What to do:** open **Income & Expenses** on the same item. That tab needs the `stock_item_cost` permission, which the Member system role does not hold — if you cannot see it, that is why. **Cause:** an order row shows the unit's pickup and return when those are set, and falls back to the line item's rental period when they are not. A booking that was never formally picked up or returned therefore shows the period it was *supposed* to run, not what happened. **What to do:** open the order and check its fulfilment and return records. **Created at** on the Events row tells you when the booking was made, which is often the detail that settles the argument. ## Next Steps The tab reference, field by field. What the audit trail records, and for how long. Creating the scheduled events that show up here. What happens to a unit's commitments at the end of its life.