Warehouse Putaway: Should Your App Suggest a Shelf or Confirm Where Goods Actually Went?

A stock app can suggest where incoming goods should be stored, but that suggestion is not evidence that someone put them there. Separate the proposed destination from the confirmed location. Before commissioning putaway features, decide how the destination is chosen and what staff do when the suggested space is unusable.

This guide concerns physical storage-location assignment after arrival. It is not a warehouse safety assessment, a hazardous-goods separation plan or proof that a product is fit for storage.

Give locations identities people can use

Begin with the actual storage map: receiving area, aisles, shelves or bins at the level your team needs. Each selectable destination should identify a real place. Do not create a separate location for every product unless the physical process really requires it.

A product identity answers what the goods are. A lot identifies a group of that product. A location answers where the quantity is recorded. Moving part of a lot need not create a new product or a new batch; the destination is a different relationship.

Use understandable labels and a stable reference. If staff rename a shelf, preserve the meaning of historical movements rather than making old records appear to refer to a different physical place.

Define why the app suggests a destination

Odoo 19's putaway documentation describes routing arriving products to storage locations and generating operations to move them there. Its rules can consider a product, product category or package type, and storage categories can constrain location capacity.

For a custom app, decide which of those distinctions actually matter. A pallet and a loose box may need different handling even when they contain the same product. If a specific-product rule and a general category rule both match, specify which wins. Staff should be able to see why a destination was chosen rather than relying on a hidden rule order.

Do not infer physical suitability from a software match. Required loading limits, segregation, temperature or other storage restrictions need qualified assessment and explicit requirements. A location field alone enforces none of them.

Keep the proposed move distinct from completion

In a fictional small warehouse, a receipt is assigned to a shelf but remains in the receiving area while staff clear space. The app should not make that stock appear physically shelved merely because it generated a destination.

Agree what confirms completion: a staff action, a scan or another reviewed operational step. A scan can identify a place or a product; specify what it proves in your process. Do not assume a scanned product code confirms the destination too.

For a split placement, retain the quantities put in each actual location. If some goods stay in receiving, leave that remainder visible. One completed line must not move the entire receipt on paper when only part was handled.

Make exceptions usable

What happens when the shelf is full, inaccessible or no longer permitted? Define whether staff may choose an alternative, request a supervisor or leave the task unresolved. Preserve the originally proposed destination alongside the actual decision where it helps explain the deviation.

If capacity is enforced, specify the measurement and how competing placements share the remaining allowance. A visual suggestion is not a reservation of space. If the first version only warns, make that limitation explicit.

Also distinguish a correction to a mistaken record from a new physical move. Changing the destination after confirmation should not quietly rewrite where the goods were previously recorded. Use an explainable correction or a new transfer under the agreed rule.

Demonstrate one receipt through its awkward cases

Use fictional goods in your acceptance criteria:

• A matching rule explains its suggested destination.
• Conflicting specific and general rules follow the documented priority.
• A suggestion leaves the physical-location record unchanged until confirmation.
• Partial placement leaves a visible remainder at the true recorded source.
• An unusable destination follows the exception path without inventing completion.
• A capacity warning or restriction behaves as described.
• A correction preserves an understandable movement history.

For a stock-workflow app brief, bring a blank receiving form and a non-confidential location sketch. Start with the places staff cannot currently find reliably, not an automatic warehouse optimiser.

Common questions

Do we need a barcode on every shelf?

Not necessarily. Decide whether scanning solves an actual identification problem. A readable selection and confirmation process may fit a small operation.

Can one product occupy several locations?

If the physical process allows it, model quantities by location rather than forcing one address onto the product record. Specify the movement and remainder rules.

Does an assigned destination prove safe storage?

No. The application can reflect reviewed restrictions and record decisions, but neither assignment nor confirmation replaces the relevant physical checks.