> ## Documentation Index > Fetch the complete documentation index at: https://docs.tryoto.com/llms.txt > Use this file to discover all available pages before exploring further. # Inbound inventory > Receive stock from suppliers, other locations and customers with inventory orders, check it against what was expected, and set replenishment alerts. > [!NOTE] > > **Where to find it:** OTO PACK → Operations → Inbound — [Open in OTO ↗](https://app.tryoto.com/operations) Stock arrives from suppliers, from other locations in your own business, and back from customers. All three enter through the same door and become the same kind of record. ## Inventory orders An inventory order is the instrument for a deliberate change in stock — as opposed to the automatic changes a sale or a return produces. They come in two directions, and both are created from **OTO PACK → Operations** with **Add Inventory Order**. | Direction | What it covers | | - | - | | **Inbound** | Stock increases: purchases from vendors, production output, goods coming back from customers. | | **Outbound** | Stock decreases: returns to a supplier, disposals and write-offs, transfers out to another location. | Completing an inventory order updates **Quantity on Hand** and recalculates **Quantity Available** automatically, and with bin tracking it updates the affected bins at the same time. Nothing needs a second entry anywhere. The line items across all of them are reportable in their own right: **Inventory Order Items**, at **Performance → Reports → OTO PACK**, lists what was actually on each receipt and dispatch rather than the orders that carried them. ![The Add Inventory Order form](https://mintcdn.com/oto/ft-bRlLvOnJkbVoC/images/inv-5-add-inventory-order.png?fit=max\&auto=format\&n=ft-bRlLvOnJkbVoC\&q=85\&s=d47279268a43ab909d24a9304b970a1f) Fig. 1 — Type is the only required field above the items, and it comes first — it is what decides whether this movement adds stock or removes it. | Field | What it carries | | - | - | | **Type** required | What kind of movement this is — a purchase or replenishment, a transfer, a return. | | **Order Date** · **Delivery Date** | Raised and expected. | | **Status** | Opens at **New Order** and moves on from there — **Assigned** once it has an owner. | | **Waybill Number** | The carrier’s reference, so the receipt can be matched to the delivery that brings it. | | **Description** | Free text — the place for the context that no field covers. | ### Order Items Three columns per line: **Product Name** and **Quantity**, both required, and **Expiry Date**. Lines are added one at a time with **Add New Row**, or in bulk with **Import by Template** for a large receipt. > [!TIP] > > **Expiry belongs to the receipt, not the product** > > It is tempting to think of a shelf life as a property of a SKU. It is not — it is a property of *this delivery of it*. Two pallets of the same yoghurt arriving a fortnight apart expire a fortnight apart, and a single date on the product record cannot express that. > > Capturing it per line at receipt is what makes oldest-first picking possible and what lets you see what is about to go out of date rather than discovering it. It is one field, and it is filled in at the only moment anyone is holding the box that has the date printed on it. ### The inbound list The **Inbound** tab of Operations carries one row per expected receipt, with every column filterable: | | | | - | - | | **Waybill Number** | The carrier’s reference for the delivery. | | **Type** | What kind of receipt this is — a purchase or replenishment, a transfer, a return. | | **Responsible** | Who is receiving it. | | **Order Date** · **Delivery Date** | Raised and expected. The gap between them is your supplier’s reliability, written down. | | **Ingoing Warehouse** · **Ingoing Branch** | Where it lands. | | **Status** | Where the receipt has got to — **Assigned** once someone owns it. | ![The Operations screen on the Inbound tab](https://mintcdn.com/oto/YkJay8Y-1RDv8ciw/images/inv-6-inbound-tab.png?fit=max\&auto=format\&n=YkJay8Y-1RDv8ciw\&q=85\&s=57a1e69b820a07573fdfc076a6d78d11) Fig. 2 — One row per expected receipt, every column filterable, with the status carried as a chip on the right. Goods ordered against a vendor start life one screen earlier, at **OTO PACK → Purchase Orders**, which carries the **Vendor**, **Requested By** and **Shipping Term** for the purchase itself. ## Receiving against what was expected The value of receiving in a system rather than on a clipboard is the comparison: what the supplier said they sent, against what is actually on the pallet. A **goods receive note** is that comparison written down and agreed — the document that turns “we think two cases were short” into a claim you can make. Receiving itself happens in the OTO PACK app on the **Inbound** page, as a scan against the expected lines. Catching a short or wrong delivery there, while the driver is still in the yard, is worth considerably more than catching it in a count three weeks later. > [!TIP] > > **The discrepancy is the point** > > It is tempting to treat receiving as a formality when the paperwork usually matches. But the receipt is the only moment when the supplier is still accountable and the evidence is still in front of you. Every discrepancy not recorded at that moment becomes, a few weeks later, an unexplained inventory loss that looks like your problem. ### Gate entry For operations that need it, arrival is logged at the gate before goods reach the receiving bay — vehicle, supplier, time in. It separates two facts that are otherwise conflated: that a delivery arrived, and that it was accepted. On a busy yard, that separation is what lets you answer where a delivery got to when it never made it as far as the dock. ## Transfers between locations Moving stock from one of your locations to another is an outbound order at one end and an inbound at the other, which is what keeps both sets of books right while the goods are in transit — the stock has left one location and has not yet arrived at the other, and the system says so rather than double-counting it. Order-driven transfers between depots are covered in [Order fulfillment](https://docs.tryoto.com/modules/omnichannel-oms/order-fulfillment.md). ## Thresholds, alerts and replenishment A threshold turns inventory from something you check into something that tells you. **Min Inventory** is set per SKU per location; when stock falls to it, that is the signal to reorder from a vendor or to pull from reserve. Inside a warehouse, the same idea runs at bin level: when a pick-face bin runs low, replenishment proposes moving stock from the reserve behind it, so picking does not stop at an empty shelf while a full pallet sits two aisles away. The **Bin Replenishment Report** — at **Performance → Reports → OTO PACK** — exists to answer *how much*, in the product’s words *“to smartly decide how much to replenish in your Put & Pick bins.”* See [Inbound and putaway](https://docs.tryoto.com/modules/warehouse-management/inbound-putaway.md). > [!NOTE] > > **Two different replenishments** > > Replenishing a *bin* moves stock you already own from one place in the building to another — it changes nothing at all about how much you have. Replenishing a *location* means buying or transferring more. Both are triggered by a low number, and confusing them is how a warehouse ends up ordering stock it is standing next to. ## Related * [Inbound and putaway](https://docs.tryoto.com/modules/warehouse-management/inbound-putaway.md) — the physical receiving and shelving. * [Inventory tracking](https://docs.tryoto.com/modules/inventory-management/inventory-tracking.md) — what the receipt changes. ## Related topics - [Inbound and putaway](https://docs.tryoto.com/modules/warehouse-management/inbound-putaway.md) - [Inventory Management](https://docs.tryoto.com/modules/inventory-management/overview.md) - [Product catalog and SKU configuration](https://docs.tryoto.com/modules/inventory-management/product-configuration.md) This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.