Inventory App
The Hii Retail Inventory app is the handheld app for the people who do the physical work behind the Inventory services: receiving deliveries, sending stock between stores, picking Click and Collect orders, and counting and correcting stock. Extenda supplies it, and it runs on iOS and Android: iPhone and iPad, Android phones and tablets, and Zebra rugged handhelds. On the device it is called HiiRetail Inventory.
Three things set it apart from a thin client on top of the APIs:
- It keeps working when the network does not. Back rooms, chillers and concrete stock rooms have no signal. Work done there is kept on the handset and sent, in order, when the signal returns. See Working offline.
- It tells the store what is waiting. Push notifications for new orders, approaching deadlines, deliveries due, transfers on their way and counts that can start, and a list of everything still undone. See Notifications.
- It scans like store equipment. The camera on any phone, or the trigger on a Zebra handheld, and scale labels fill in their own weight. See Scanning and quantities.
Do you need to build a store app?
No. A customer adopting the Inventory services does not have to build a client for store staff: the app is the supplied path, and the concept pages of each service assume it.
Every tap in the app is an ordinary call to one of the Inventory services, made with the signed-in user's own token. Nothing in it is private to the app, so a customer who wants to drive part of the work from their own system can call the same endpoints:
| Module in the app | Service it calls | What that service documents |
|---|---|---|
| Goods receivable | Goods Received | Delivery lifecycle, quantities and reason codes |
| Store transfers | Store Transfer | Raising, picking and receiving a transfer |
| Click & Collect, Store Layout | Click and Collect | Picking, substitutions, store layout |
| Stock counting | Stock Count | Count types, counting and deviations |
| Stock correction | Stock Corrections | Corrections and reason codes |
| Stock events, current stock | Stock Inventory | The Query API |
| Notifications, Control tasks | Inventory Notifications | Notifications |
What this means for an integration: your systems send the work in (expected deliveries, customer orders, planned counts) and subscribe to the services' events to learn what the store did. They do not talk to the app, and they do not drive what staff do in it. The order moves because someone in the store picked it; the delivery is received because someone counted it.
⚠ Work done offline reaches the services late. A count made in a dead spot at 10:02 can arrive at 10:07, together with everything else done in between. The events then carry the time the work was done, not the time it arrived. Read what this means for your systems before you build anything that orders events by arrival.
One store at a time
The app always works for one business unit, the store chosen after sign-in. Every list, count and notification is that store's. A colleague who helps out in another store changes the store in the app first. See Devices, sign-in and stores.
Where to read next
| If you want to… | Read |
|---|---|
| roll the app out: devices, sign-in, stores, access | Devices, sign-in and stores |
| see what each module does | Modules |
| understand scanning, weight labels and decimal quantities | Scanning and quantities |
| understand what happens without a network, and what your systems see | Working offline |
| know what notifications staff get, and why | Notifications |