Why Auto STR
The problem
In a multi-warehouse pharmacy, the same SKU is rarely balanced. Ward A sells through paracetamol by noon while the central store holds weeks of cover. Manual spreadsheet transfers are slow, error-prone, and always a day late — so one branch misses sales while another ties up cash in dead stock.
We felt this on our own floors: IPD Block B would show zero on a fast mover while Central Warehouse still had cartons. Pharmacists spent Friday afternoons guessing quantities instead of verifying batches.
How Auto STR solves it
Auto STR reads sales velocity and on-hand stock for every SKU in every participating warehouse. It computes how many days of cover each location has (your DID setting), finds deficits and surpluses, and proposes transfers — central warehouse first, then peer warehouses by priority.
Version 2.0 adds what spreadsheets can’t: a pharmacist review gate. Every proposed line is approved, reduced, or rejected with a reason. A four-pass allocator then checks real stock (respecting DID floors and FEFO) before any transfer is created.
Why it’s different
| Typical WMS | Auto STR |
|---|---|
| Fixed min/max per SKU per location | Velocity-driven — adapts as demand shifts |
| Manual transfer requests | Engine proposes; pharmacist confirms |
| Create-and-hope | Validate against live stock before finalize |
| One-size batch moves | Scenario B proportional rationing when system is short |
When it doesn’t apply
- Single-warehouse tenants — need at least two participating locations.
- No sales history — SKUs without velocity are skipped.
- Order-driven shortages — OMS Auto-STR for order fulfillment is a separate flow (see OMS docs).
- Ad-hoc emergency transfers — use manual Stock Transfers instead.