Build warehouse stock control around your locations

Track stock by location, not just by product

A warehouse differs from a stockroom in one important way: the same product can sit in several places at once. A pallet in receiving, six boxes in rack A-03 and two open boxes at the packing bench are one product with three quantities. If the app stores a single total per product, nobody can find anything.

Define locations first — zones, racks, bins or shelves with short codes your team already uses — and record every quantity against a product and a location. A product’s on-hand total is then the sum across locations, computed from records rather than typed in.

Model receipts, putaway, picks and transfers

Each movement changes stock at a location: a receipt adds quantity at a receiving bay, putaway moves it to a bin, a pick removes it for an order. A transfer between bins must subtract and add as one recorded action — if only half of it is saved, the totals silently stop matching the shelves.

Keep the reason and the responsible person on every movement. When a count disagrees with the app, record the correction as an adjustment with a reason, not by editing the expected number: the history of disagreements is what reveals a process problem.

• Location: zone, bin code and a description a picker recognizes.
• Movement: product, from and to location, quantity, reason and timestamp.
• Receipt: supplier or delivery reference and the receiving location.
• Adjustment: counted quantity, expected quantity, reason and approver.

Start with a specific stock-control prompt

Replace the zones and movement rules with your own. Ask for a managed database explicitly, and use synthetic products until the numbers have been checked.

Check the app with a cycle count you control

Create a sample product, receive 20 units into RECEIVING, put away 15 to bin A-03 and pick 4 from A-03. The expected result: 5 in RECEIVING, 11 in A-03 and 16 on hand in total. Then count A-03 as 10 and record an adjustment — the variance, its reason and the corrected total should all be visible in the history.

Attempt the two classic failure cases: a pick larger than the bin’s quantity must be rejected, and a transfer interrupted mid-save must never leave the source reduced without the destination increased.

• Reload and confirm every movement and the bin breakdown remain.
• Sign in with a second company account and verify it sees none of the first account’s bins or products.
• Test a failed request: input is preserved and nothing is reported as saved.
• Use a phone to record a receipt and a transfer, including long bin codes.
• Export or total a small known dataset and compare it against the app’s numbers.

Publish after a count agrees with the shelves

For supported managed apps, BrainHalf builds and verifies a saved version before activating the public release. Production has its own database; development test records are not copied. Run one real receipt-to-pick cycle with disposable products on the public URL before moving daily work into it.

Barcode scanners, label printing and courier integrations add hardware and provider requirements that need separate testing; this page is a build brief, not a claim they are built in. Decide how records are recovered before the app becomes the only source of stock truth.