Multi-location inventory: running stock across sites, vans and job sites

A second location is a partition, not a filter. The moment you create one, the same part becomes two records with two quantities and two thresholds, and nothing in Stockout moves stock between them for you. Decide the naming, the owner and the move procedure before the second site exists; retrofitting them costs more than setting them up did.

When a second location is worth its upkeep

Creating a location does not filter your catalog. It duplicates the part of the catalog that is stocked in both places, and every duplicate is a separate quantity, a separate Low Stock At, a separate line in every count round, and one more record somebody has to remember to adjust. Start from that cost rather than from the tidiness.

Create the second location if you can answer yes to two or more of these four:

1. Do two people count the same part in two buildings, without being able to see each other's shelf?
2. Does stock leave one place and get consumed somewhere else, out of sight?
3. Does the second place need its own low-stock trigger, because it runs out on a different schedule?
4. Would a total that mixes both places cause someone to skip an order?

One yes or none, and you can separate the stock with two things that cost nothing. The item's Storage Spot field is free text — "Aisle 1, Shelf A", "Van 4 bin 2" — and the Inventory funnel sheet filters by it alongside Category. Folders are location-scoped named collections that reference items, kits, equipment, checklists, labels, suppliers, customers and work orders without moving or copying anything, and removing an entry never touches the underlying record.

Both have the same ceiling. Storage Spot is unstructured text with no zone or bin hierarchy, and a folder cannot hold a quantity of its own. Two people who both draw from "Van 4 bin 2" are still sharing one number, so the first of them to take six units makes the second one's count wrong. That is the line where a real location starts paying for itself.

One nuance in the other direction: a folder belongs to one location, but the records it references need not. Suppliers and customers are org-wide and label templates are shared across every location, so the same vendor can sit in a "reorder from this vendor" folder at three different sites.

What a location partitions

Every item, kit, piece of equipment, checklist, folder and work order belongs to exactly one location. The same product at two sites is two separate item records with independent quantities and independent thresholds. Nothing joins them except the SKU string you typed into both.

There is no transfer workflow, no in-transit stock and no single quantity spanning sites that you can edit — a move is two separate adjustments.

Analytics is scoped to whatever the device is set to. On a specific site the charts cover only that site; in All Locations on Windows or Android they aggregate every located record, and a per-item chart tags each bar with the site it came from. A cross-site figure in a browser is something you assemble yourself: switch sites and add, or read the stock-movement ledger through the read-only public API.

And an alert fires for the location its device is set to, so a site nobody's device is pointed at raises nothing at all. That is half the reason to name an owner per site.

A naming convention that keeps sorting as you add sites

Names are load-bearing because the web app does not remember which location you were on: every page load selects the first location alphabetically. Rename a site, or add one that sorts earlier, and you have silently changed where every web user lands.

Six rules:

1. Put the sorting key first — a prefix, never a person's name or a street.
2. Zero-pad the number to two digits, so 02 sorts before 10 instead of after it.
3. Reserve the lowest prefix for the site most people should land on. Digits sort ahead of letters, so an unprefixed "Airport Depot" cannot steal first place — but a "00 Airport Depot" can, and every web user then lands there.
4. Group by kind with a decade — 0x fixed sites, 2x vehicles, 3x trailers and containers, 4x job sites.
5. Keep the human name after the prefix, so the location chip is still readable on a phone.
6. Close a job site rather than renaming it, and never rename a live site mid-week.

Job sites need an end state decided on day one, because deleting a location permanently removes every item, kit, piece of equipment and checklist at that site. Settle in advance whether a finished job's leftovers come back to a fixed site — two adjustments, per the procedure below — before anybody deletes anything. You also cannot delete your last remaining location.

The awkward part is that there is no archive for a location. A closed job site either sits in the picker forever or is deleted along with its contents. Empty it first, then delete it.

One SKU, two records: the identifier rules

The two records that represent one part at two sites are joined by nothing except the SKU string you type. Keep that string identical everywhere. It is the whole rule, and most of the cross-site reporting problems downstream are a violation of it.

This is not tidiness. A scan looks the item up by SKU and adds or removes stock in one tap. Suffix the SKU per site — FL-220-NORTH — and a scan of the printed FL-220 code matches nothing at that site, at which point Stockout offers "Create New Item" with the SKU pre-filled. One part now has three records.

Put the site somewhere else. The location already partitions the record, so a site code on the SKU is redundant; if people need it on paper it belongs in Storage Spot or in the item name. An item can also carry several SKUs or barcodes, and a scan or search matches any of them, which is the right home for a supplier's alternate code rather than for a per-site variant.

Print the same thing at every site: a label's code encodes either the item's SKU or its Name, templates are shared team-wide, and which code to print and what to encode on it is a decision worth making once.

Changing a SKU breaks the link to any tag already written, so a rename is a re-tag at every site that holds the part.

Cross-site totals are your arithmetic, not the app's. Switch to each site, read the quantity for that SKU, add them up. Or pull the stock-movement ledger through the public API and group by SKU in your own sheet — it is GET and HEAD only, and a key reads the whole org rather than one site.

Recording a move between sites

There is no transfer workflow. A move is two independent adjustments: remove at the source, switch the device's active location, add at the destination. Nothing links the two halves, no reference number joins them, and nothing in the product ever confirms that the stock arrived.

Do it in this order, and finish it the same day.

1. At the source site, open the item's three-dot menu → Adjust and remove the exact quantity that is leaving. The sheet previews the resulting number before you commit.
2. Read the new quantity back off the card before you move on.
3. Switch the device's active location to the destination.
4. Confirm the location chip reads the destination — and on the web, confirm it again if the page has reloaded since step 3.
5. Adjust again, adding the same quantity.
6. Read that quantity back too.

Never split the halves across days, and never let two people do one half each. Nothing reconciles them, so an unfinished move stays invisible until a count trips over it. A move that genuinely takes days is the one exception: remove on dispatch, add on arrival, and keep the in-flight quantity written down outside the app, because the org total is understated until it lands.

You cannot label the pair either. Movement reasons are fixed strings the app writes itself, and they are never read back for reporting, so there is no way to mark two adjustments as one transfer. If a move needs paperwork, that paperwork lives outside Stockout: a note, a photo of the pallet, a line on the job sheet.

Kits are location-scoped too, and Make deducts component stock at the site you are on. There is no way to move "a kit" — move its components as items and rebuild at the destination.

The active location is per device — and the web forgets it

The Windows and Android apps store the active location per device, so two people signed into the same account can be looking at different sites right now, and nobody is told when a teammate switches. Changes reach other devices within seconds, and when two people change the same field at once, the last change saved wins, and only changed fields sync — which matters most when two people are adjusting the same item at the same site.

The web app does not store the active location at all. Every page load selects the first location alphabetically, so a web user who refreshes, opens a second tab, or comes back after the session reloads is on the first site by name whatever they were on before — and the next ± Adjust writes there.

Read the location chip before any adjustment in the browser, complete both halves of a move without reloading, and name sites so that landing on the wrong one is obvious at a glance.

Alerts follow the same per-device setting, so it also decides which site's Low Stock and Out of Stock emails you receive. Recipients are a comma-separated list saved per device or browser and they do not sync, so setting it once for the team is not something you can do — every device that should be watching a site has to be set to that site and carry its own recipient list.

You cannot pin a user to a site, there is no per-location permission, and no setting makes the browser remember. The discipline is the control.

What All Locations is good for

All Locations is a read-only aggregate in the Windows and Android apps. It appears in the location picker only once the org has more than one location, and it does not exist in the web app at all. What it shows is every site's records listed together — a part stocked at three sites is three cards with three quantities, not one summed figure.

You cannot adjust, scan, count or make a kit from it — switch to a specific site to change anything.

So whoever holds the alert device for a site leaves that device on that site: look at All Locations from a second device, or look and then deliberately switch back.

Who owns each site

Roles are org-wide, not per site. Every role, including Viewer, can switch between locations; only Owners and Admins can add, edit or delete one. There is no per-location permission and no way to restrict a user to one site, so plan around it rather than assuming a setting exists. Roles are enforced server-side, but what they enforce is what you can do, never where you can do it.

Anyone with write permission can adjust stock at any site, including one they have never visited, and an API key reads the whole org rather than one location.

Ownership therefore has to be a written rule. Name one person per site who is accountable for its count, and write it where the team already looks — a checklist name, a folder name, the shift board. Stockout stores no per-site assignment.

The only names the product captures are typed as free text at the moment of the action: the employee first and last name on a completed checklist run, and the same on an equipment check-out. Stock movements carry no user at all, so nothing tells you who adjusted a quantity at which site.

The rest of the permission map is on Roles & Permissions.

Counting cadence, per site

Count each site on its own cadence, and measure each site's accuracy on its own. A combined accuracy figure hides the one site that is wrong, and since totals never mix inside the product there is no reason to mix them in the reporting.

Set the cadence by how fast a site's record decays, not by how big the site is. A van whose stock is consumed off-site by one person decays fastest and is smallest, so count it whole, weekly. A fixed warehouse decays slowly per item and is large, so drip it daily.

Do the arithmetic per site and round up per site. Pooling 240 records at Main and 90 at North over 65 count days gives 5.1 lines a day and hides which site is falling behind; 4 at Main plus 2 at North is the same 6 lines and stays attributable. The method is unchanged from a single site — see how to run the count program.

Two people counting the same site in the same week produce offsetting corrections that read as noise, and when two people change the same field at once, the last change saved wins, and only changed fields sync. One name against each site is the fix.

Job sites are the exception: count at the start and at close-out rather than on a cycle. The close-out count is what tells you how much comes back as a two-adjustment move before the location is deleted.

Thresholds and alerts are per item, per site

Two records means two Low Stock At values, and they are almost never the same number. A site's trigger depends on that site's own usage and on how long that site takes to be replenished — and for a satellite, that is the drive from the main warehouse, not the supplier's lead time. A site that replenishes another has to count that draw in its own usage figure: the hub's rate is what leaves the hub, not what the hub consumes.

Work the number out per record, then type it in. Stockout does not compute a reorder point, has no safety-stock or lead-time field, and holds exactly one reorder-ish input: the per-item threshold. Enter it as a fixed number in # mode rather than as a percentage, because a percentage is a percentage of that item's Max Capacity and resolves to zero when no Max Capacity is set. Deriving the trigger number is arithmetic you do once per record and revisit when usage moves.

Copying one number to every site fails in both directions. A warehouse trigger applied to a small satellite can sit above what the satellite physically holds, and because Low Stock is evaluated before Max Capacity that record reads Low even when the shelf is full. A satellite trigger applied to the warehouse fires far too late. The worked example below puts numbers on both.

The per-device settings compound it. Settings carries a Default Low Stock Threshold applied to newly created items — it defaults to 5 and is stored per device, not synced — so an item created at a new site on somebody's phone sits on 5 until the real number is entered. Put "set the threshold" on the new-site checklist.

Alerts are edge-triggered: one alert at the moment a change newly crosses a threshold, no re-alert on an item already low, no scheduled digest. Combined with per-device recipients and a per-device active location, a site is only covered when a specific device is set to it, has the alert types switched on, and carries its own recipient list. The habits that get an alert to arrive in time are the subject of preventing stockouts.

Vans, trailers and job sites

Consumption on a van happens where nobody can see the shelf, so the whole model rests on one habit: the person who takes the part records it, at the site it came from, at the moment they take it.

Scanning is the shortest path to that habit, with one hard platform limit. The camera reader is the Android app only; Windows and the browser use a USB or Bluetooth reader in keyboard-wedge mode, which is fine on a bench and useless in a van. The scan buttons sit in the footer of the Inventory screen, and they are hidden for Viewers.

RFID is NFC on an Android phone, one tag at a time — workable for a van's fixed kit, useless for a walk-past count. Which code to print, and what to encode on it covers the choice.

A van's replenishment list is that site's Low tile: tap it and the list filters to everything that has crossed. Photograph it or write it down before the restock run, because there is no report to send.

Work orders are location-scoped and auto-numbered from WO-1001, and using a material line deducts stock at that site and logs a movement tagged with the WO number, with the material's cost and price snapshotted when it was added. If the job is its own location, raise the work order at the job location so the materials pull from the staged stock rather than from the warehouse.

At close-out, count what is left, bring it back as a two-adjustment move, and only then delete the location — deleting it removes every item, kit, piece of equipment and checklist there.

Setting up a second site in Stockout

A brand-new account has to create its first location before it can use the app at all, so step 2 below is also the very first thing a new team does. For everyone else it is the second site, and the order matters.

1. Take a backup before you start.
2. Create the location — Owner or Admin only, from the Locations screen.
3. Name it with the prefix convention above. Renaming it later moves every web user's landing site.
4. Create only the items that site actually stocks, using the same SKU strings as the existing site. If the second site's stock is still on a sheet, work through typing a catalog in without losing a week.
5. Set each record's own Low Stock At, in # mode.
6. Set the alert device: one phone or browser pointed at the new site, with its own recipient list and the alert types switched on.
7. Count the new site the day it opens, so the opening quantity is a counted number rather than a guess.
8. Take a second backup.

A backup is org-wide, not per location: one file covers every site, includes the locations themselves, and a restore writes each row back at its original location. It covers 15 tables, including the child rows most lists forget — kit components, supplier contacts, item-supplier links, work-order materials and folder entries — though not activity logs or stock movements, and the file only restores into the account that created it.

Two org-wide destructive actions deserve a wide berth in a multi-site setup. Reset to Sample Data and Clear Data both wipe every label template across the whole organization, and Reset also wipes all suppliers, supplier contacts, item-supplier links and customers org-wide — not only the current location's data. All four of Backup, Restore, Reset and Clear write to the shared cloud, so they affect the whole team rather than the device that ran them.

There is no bulk load. The only two ways bulk data enters Stockout are Reset to Sample Data and restoring a backup JSON made by the same account. Everything else is typed into an editor or created from a scan — and when a scanned code matches nothing, Stockout offers "Create New Item" with the SKU pre-filled, or "Add to Existing Item".

A monthly multi-site audit

Ten checks, about half an hour in total.

• Open the location picker and confirm every site in it is still real. Empty and delete anything that has closed.
• Confirm the prefix order still puts the intended site first alphabetically, because that is what the web selects on every load.
• For your three highest-value SKUs, open All Locations on a Windows or Android device, confirm one record appears for every site that stocks it, and add the quantities by hand — nothing in the app sums them for you.
• Check that no item is sitting with no location assigned — those are excluded from the aggregate.
• Spot-check five records at each satellite for a Low Stock At still sitting on the per-device default of 5.
• Confirm each site has a device set to it with the alert types on and a recipient list filled in, and that the device is not parked in All Locations.
• Confirm each satellite has a named counting owner written somewhere outside the app.
• Review the Members list and remove anyone who has left, remembering that every role can switch to every site.
• Review the API keys; a key reads the whole org.
• Download a backup and note the date. It covers every site in one file.

Nothing in Stockout reconciles two sites for you, so this routine is the reconciliation. A month is short enough that a missed half-move is still explainable, and long enough that the habit survives a busy week. The counting, the thresholds and the labels that each site depends on run through the rest of the series.