Hii Retail Click and Collect
Click and Collect turns an order your customer placed elsewhere — a webshop, an app, another store — into picking work on a store's shop floor, and tells you when that work is done.
It deliberately does not own the checkout. Click and Collect is the picking half: it tells you what a store has picked, what was substituted, and when the order is ready. What happens either side of that — how the customer paid, how the goods reach them — stays with the systems you already use.
If you want to…
| …then read | |
|---|---|
| get orders into a store from a webshop or OMS | Events — orders arrive from Customer Order, not from here |
| be told when something happens — order picked, ready to pay, delivered | Events — start here, and read the consuming section before writing a subscriber |
| understand what a status means | Order statuses |
| know why a picking order is not a customer order | Order types |
| set the service up for a store | Business units, item categories, configuration parameters |
| understand what a picker can do to an order | Substitutions, order statuses |
Who does the picking
Picking happens in a store, in a picker's hands, on a handheld device. Extenda supplies that app — the Hii Retail Inventory app — so a customer adopting Click and Collect does not have to build a picking client, and the statuses in these pages describe what a person does in it.
This is why the integration shape below has no "drive the picking" step. The order moves because someone in the store picked, substituted, paused or finished it.
The same actions are also ordinary REST endpoints on the Click and Collect API, under /api/v1/business-units/{businessUnitId}/orders:
| Endpoint | What it does |
|---|---|
POST /{orderId}/start-picking | a picker takes the order on |
POST /{orderId}/pause-picking | picking stops with a stated reason |
POST /{orderId}/lines/{lineId}/pick | record what was picked for one line |
POST /{orderId}/lines/{lineId}/substitutions | offer a replacement for an item |
DELETE /{orderId}/lines/{lineId}/substitutions/{itemId} | withdraw one |
POST /{orderId}/containers | record the bags or boxes used |
PUT /{orderId}/picked | the order is picked |
PUT /{orderId}/delivered | the goods left the store |
So a customer who wants to drive picking from their own system can. But the app is the supplied path, and it is what the rest of these pages assume.
Picking survives a lost signal. Shop floors have dead spots — chiller aisles, back rooms — and the app does not stop when the network does. Actions are queued on the device and sent, in order, when the connection returns, so a picker keeps working through a blackspot instead of standing still. This matters when you are reading the events: the moment a pick reaches us is not the moment it happened, and a run of actions can arrive together after a gap. See events.
The shape of an integration
Most integrations are two connections:
- Get the order to the store. Orders reach Click and Collect from Customer Order, which sends each store its share of the work. You integrate with Customer Order, not with this service.
- Subscribe to
order-status-changed. This is how you learn the order progressed — picked, ready, delivered, cancelled. See Events.
🛑 One customer order can be picked by more than one store. Click and Collect calls each store's share a fulfillment, and it has its own identifier. Two events carrying the same order id are not necessarily duplicates — they may be two stores reporting on their own halves. Events explains what to key on.