> ## 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 and putaway
> Set up bins and zones, receive incoming stock, put it away with Easy Put, run quality checks, and connect other systems through the WMS API.
> [!NOTE]
>
> **Where to find it:** OTO PACK → Operations → Inbound — [Open in OTO ↗](https://app.tryoto.com/operations)
Everything a warehouse ships, it first received and put somewhere. How well it was put away determines how far everyone walks for the rest of that stock's life.
## Bins — the warehouse's addresses
A bin is a location with a name. As the product puts it: *“Bins are addresses within your warehouse, representing specific locations where products are stored or moved.”* Without them, stock is “in the warehouse”, which is not an answer anyone can walk to.
Bins live at **OTO PACK → Configuration → Bins**, with **Add Bin** and a bulk import.
Fig. 1 — Only Warehouse, Bin Name and Bin Type are required — everything else refines the address or the rules around it.
| Field | What it does |
| - | - |
| **Warehouse** required | Which building this bin is in. |
| **Bin Name** required | The address itself — what a picker reads and what a scanner returns. |
| **Bin Type** required | What the bin is for. See below. |
| **Zone** | The section of the warehouse this bin belongs to, which is what makes zone picking work. |
| **Aisle · Rack · Shelf** | The physical coordinates, as three separate fields. |
| **Bin Capacity** | How much it holds, so putaway does not suggest somewhere full. |
| **Preferred SKU** | The product that belongs here. This is what turns putaway from a decision into a confirmation. |
| **Bin Responsible Users** | Who owns this location — so a count that does not reconcile has someone to ask. |
> [!TIP]
>
> **The layout is structured, not encoded in the name**
>
> Warehouses usually bury the layout inside the bin name — **A-12-3** and everyone learns to read it. Here **Zone**, **Aisle**, **Rack** and **Shelf** are fields in their own right, so the system knows the shape of the building rather than just a string. That is what lets a pick path be ordered by where things physically are, and what makes a renumbering something you do in the data rather than on every label.
### Bin types
The type is what makes a bin behave differently from the one next to it.
| Type | Purpose |
| - | - |
| **Receive / Transfer** | Where inbound goods and incoming transfers land before they are processed. |
| **Put / Pick** | Ordinary storage — the shelves stock is picked from. |
| **Pack / Ship** | The benches and staging areas at the outbound end. |
| **Sorting** and **Sorting Station** | The sorting work and the physical station it happens at, separated so a bench and the bins on it are not the same object. |
| **Trolley** | A bin that moves. A picker’s trolley is a location like any other, which is how stock stays traceable while it is being carried. |
| **Return** | Returned goods awaiting inspection. |
| **Adjustment** | Where a stock correction lands, so the discrepancy has an address instead of vanishing into a total. |
| **Storage / QC** | Reserve stock and goods held for inspection. |
| **Non Sellable** | Stock that exists but cannot be sold — damaged, expired, quarantined. |
> [!TIP]
>
> **Sellable and non-sellable**
>
> The distinction is carried by the bin, not by a flag on the product. Damaged goods, returns awaiting inspection and quarantined stock sit in bins that do not feed available inventory, so [stock sync](https://docs.tryoto.com/modules/inventory-management/inventory-sync.md) never offers a customer something that cannot be shipped.
>
> Moving a unit into a **Non Sellable** bin is therefore a commercial act as much as a physical one: the storefront stops offering it the moment it is put there.
## Zones
A zone is a larger section of the warehouse, configured at **OTO PACK → Configuration → Zones** with **Add Zone**.
Fig. 2 — A zone is four fields — and two of them are what make zone picking work.
| Field | What it does |
| - | - |
| **Warehouse Name** required | The building the zone sits in. |
| **Zone Name** required | What it is called. |
| **Picker** | The person this zone’s work goes to. Assigning a picker to a zone is how a picker stops walking the whole building. |
| **Default** | The zone that takes work when nothing else claims it, so no task is left unassigned. |
Bins are attached to zones from the Bins tab — select bins, then **Update Zone** from the tools menu. Configuration also carries **Users**, **Teams** and **Vendors** alongside Bins and Zones.
## Receiving
Inbound orders are created and processed at **OTO PACK → Operations → Inbound**, and received in the app on the **Inbound** page. Receiving is a scan against what was expected, which is where a short or wrong delivery gets caught — while the driver is still there.
Fig. 3 — Operations is the desktop counterpart to the app, one tab per stage: Inbound · Outbound · Putaway · Packing · Shipping · Dispatching Units · Wave Picking · Sorting · Return.
| Column | What it carries |
| - | - |
| **Waybill Number** | The carrier’s reference for the delivery. |
| **Type** | What kind of receipt it is — a purchase or replenishment, a transfer, a return. |
| **Responsible** | Who is receiving it. |
| **Order Date** · **Delivery Date** | Ordered and expected, so a late delivery is visible before it is a problem. |
| **Ingoing Warehouse** · **Ingoing Branch** | Where it is landing — building and branch. |
Every column carries its own filter in the header row, and new receipts are created with **Add Inventory Order**.
Goods arriving against a purchase order come in the same way; purchase orders themselves carry **Vendor**, **Requested By** and **Shipping Term**, at **OTO PACK → Purchase Orders**.
## Putaway
A putaway task is **created automatically** once an inbound order is processed — receiving does not end with goods on the dock, it ends with an instruction to shelve them. One can also be raised by hand from **Operations → Putaway**.
Fig. 4 — Warehouse, Responsible and From Bin are required — a putaway always has an owner and a starting location, never just a destination.
| Column | What it carries |
| - | - |
| **Product Name** · **Quantity** | What is being shelved, and how much. |
| **Suggested Bins** | Where the system thinks it should go. |
| **QTY Put** · **Bin Location** | What actually went away, and where. Empty until the work is done, which is what makes a half-finished putaway visible. |
Lines are added one at a time with **Add New Row**, or in bulk with **Import by Template** for a large receipt. The task opens at status **New Order**.
The work itself is done either way:
| | In the app | On the dashboard |
| - | - | - |
| **Path** | **Menu → Put** | **Operations → Putaway → Start Putaway** |
| **Flow** | Select the putaway order, choose the item and destination bin, assign quantity, **Complete**. | Enter quantities, SKUs and destination bins by hand, then **Complete Putaway**. |
A single receipt can be **split across several bins**, which is how a pallet of one SKU gets distributed to the pick face and the reserve at once — the **QTY Put** column is what keeps that honest.
### Suggested bins
Putaway suggests where each item should go, from the bin’s **Preferred SKU** and its remaining capacity. The point is not to save a decision but to make the same decision every time: stock that lands wherever there was room is stock nobody can find twice.
### Replenishment suggestions
When a pick-face bin runs low, the system proposes moving stock from reserve, so picking does not stop at an empty shelf while a full pallet sits two aisles away.
## Easy Put
The ad-hoc counterpart: a quick transfer between any two bins, started by a person rather than by a receipt.
| | Putaway | Easy Put |
| - | - | - |
| **Triggered by** | An inbound order, automatically | A person, manually |
| **Shape** | One source, many destinations | Between any two bins |
| **For** | Systematic shelving | Unplanned movements — consolidating, clearing, correcting |
Reached at **Menu → Put → Easy Put** in the app, or the **Easy Put** button on the Putaway tab.
> [!TIP]
>
> **The alternative is worse**
>
> Without Easy Put, an unplanned move either goes unrecorded — and the stock is then lost in the system while sitting in plain sight — or it becomes a paperwork exercise nobody completes. A two-tap transfer is what keeps the record true.
## QC and stock areas
Goods that arrive damaged, fail inspection or come back as returns are put into bins that hold them out of sellable stock until someone decides. The separation is physical and recorded at once, so nothing waits in an undefined state.
## WMS API
Merchants running another WMS as the system of record can drive this one over the API — inbound orders and inventory updates — so OTO PACK handles execution while the external system keeps the books. The endpoints are documented in the OTO API reference.
## Related
* [Picking methods](https://docs.tryoto.com/modules/warehouse-management/picking-methods.md) — zones and bin layout decide how picking performs.
* [Inbound inventory](https://docs.tryoto.com/modules/inventory-management/inbound-inventory.md) — GRN, gate entry and transfers.
* [Inventory count](https://docs.tryoto.com/modules/inventory-management/inventory-count.md) — counting the bins set up here.
* [Hubs Management](https://docs.tryoto.com/modules/hubs-management/overview.md) — bins and trolleys defined per hub.
## Related topics
- [Inbound inventory](https://docs.tryoto.com/modules/inventory-management/inbound-inventory.md)
- [OTO PACK mobile app for warehouse staff](https://docs.tryoto.com/modules/warehouse-management/ops.md)
- [Warehouse Management](https://docs.tryoto.com/modules/warehouse-management/overview.md)
This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.