Inventory Mover
Replenish MC1 from MC2 · bin-to-bin transfers · committed live to SkuVault
1 Find a product
Type a product name, a SKU, or a supplier code — words can be in any order.
MC2 Fetch Checker
Awaiting-shipment queue · MC1 is home · reserve stock is never pickable · lines MC1 can't cover are pulled from MC2
| SKU | Product | Need | MC1 | MC2 | RSV | MC2 bin | Action | For orders |
|---|
| SKU | Product | Demand | On hand | Left after | Outlook |
|---|
Could not confirm location
| SKU | Product | Reason | Orders |
|---|
Dashboard
The last 7 days · every station · read-only
Users
Who can use this app · the name here is the name on every row of Action History · every PIN must be different
Add somebody
Set up a device
Show this code and let the person scan it with their camera. Their phone stores the station key and then asks for their PIN. They never see the key.
Anyone who photographs this gets the station key. They still need a PIN. Hide it when the phones are done.
Action History
Every move, audit correction, PO receipt and return · all stations · newest first
Action History
Shared across every station, kept for 7 days. Failed and half-applied writes are logged too. The authoritative record is SkuVault Transaction History.
Multi-Station Sync
How work moves GitHub → CI → Google Apps Script from any station without overwriting an in-flight fix.
Audit
Warehouse audit tools · each new audit function appears as a tab below
1 Look up by
Lists every SKU the system currently has in that bin. Count what's physically there — stage any fix, then Commit to sync it all to SkuVault at once.
Shows every bin the system says this SKU lives in. Count each — stage any fix, then Commit to sync it all to SkuVault at once.
Receiving
Warehouse receiving · POs and customer returns
New PO
The client is the supplier on the PO. It is checked against SkuVault’s own list — a new name would create a new client, not a PO.
Sets the PO’s warehouse AND the one it is received into next.
Counted separately from the units — these two never have to agree.
Optional. Whatever is scanned here is what the client’s PO receipt email prints, so a PO with none arrives with a blank tracking section.
| Item | Quantity |
|---|
Creating the PO does not move stock. It opens next on the normal receiving screen, where you set the bins and receive it.
Open purchase orders
| PO | Supplier | Created | Status | Lines | Qty | Received | Remaining |
|---|
Open POs only — SkuVault leaves completed ones out of this list. Tap a row to see its lines.
| Item | Ordered | Received | Remaining | Receiving now | Bin |
|---|
One dated receipt per commit, into one warehouse — SkuVault requires a separate session per warehouse. Quantities are capped at what’s left on the PO. After committing you’ll see SkuVault’s own numbers, not ours.
1 The return
Click the box to pick from the bins in this warehouse.
Order # + tracking are stamped into each line's SkuVault note. Bins auto-suggest per line (RSV bin > current bin > last known) — the default bin covers items with no suggestion, and is remembered per warehouse on this device.
2 What the order shipped — tap what came back
3 Add an item manually
For anything not on the order — wrong item returned, no order match, etc.
4 Return lines
| Item | Qty | Bin |
|---|
Each line is received into SkuVault with reason Customer Return and the order/tracking note — shown at commit.