Skip to main content

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.

Click and Collect is the picking half of an online order. Anna orders socks and groceries online, to collect in Stockholm before 17:00. A colleague in the Stockholm store walks the shelves with a handset that lists order C7K2M9P line by line, then bags the goods by where they are kept: dry goods, fridge and freezer. When Anna collects, the order is DELIVERED.

If you want to…​

…then read
get orders into a store from a webshop or OMSEvents — orders arrive from Customer Order, not from here
follow an order from an ERP or OMS — picked, handed over, cancelledCustomer Order's events — they carry every change made in Hii Retail, the store's picking included. Your own updates are confirmed by the response, not sent back (what is published)
react to the store's picking itself, for example from a TMSEvents — read the consuming section before writing a subscriber
understand what a status meansOrder statuses
know why a picking order is not a customer orderOrder types
set the service up for a storeBusiness units, item categories, configuration parameters
understand what a picker can do to an orderSubstitutions, 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:

EndpointWhat it does
POST /{orderId}/start-pickinga picker takes the order on
POST /{orderId}/pause-pickingpicking stops with a stated reason
POST /{orderId}/lines/{lineId}/pickrecord what was picked for one line
POST /{orderId}/lines/{lineId}/substitutionsoffer a replacement for an item
DELETE /{orderId}/lines/{lineId}/substitutions/{itemId}withdraw one
POST /{orderId}/containersrecord the bags or boxes used
PUT /{orderId}/pickedthe order is picked
PUT /{orderId}/deliveredthe 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.

Each tap in the Inventory app is an ordinary Click and Collect API call. On the line screen for Baked Beans 400g the picker sets Quantity to 1, ticks All done! and taps PICK, which sends pickedQty 1 and isDone true to the pick endpoint; ADD or SCAN offers a replacement. On the order overview, Start Picking, Stop Picking and Done Picking call start-picking, pause-picking, and containers followed by picked.

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.

Picking keeps going through a lost signal. In the chiller and freezer aisles the handset has no network from 10:01 to 10:07. The picker records milk at 10:02, frozen peas at 10:04 and yoghurt at 10:06; the app queues each one on the device. When the signal returns at 10:07 all three reach Click and Collect together, in the order they were made.

The shape of an integration​

Most integrations are two connections, both with Customer Order:

  1. 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.
  2. Follow the order through Customer Order's events. This is how an ERP or OMS learns that the order progressed: picked, substituted, handed over, cancelled. The order also changes in Hii Retail in ways that never pass through a store's picking, and Customer Order's events carry all of those, so an ERP or OMS does not need Click and Collect's events. Its own updates are the exception: they are confirmed by the response to the sync, not sent back as events (what is published).

A system that works with the store's picking itself, such as a TMS that books a driver once the goods are ready, subscribes to Click and Collect's order-status-changed. See Events.

Where Click and Collect sits. Your webshop, OMS or ERP sends the order to Customer Order and follows it through Customer Order's customer-order-updates events, which carry every change made in Hii Retail, not only the store's picking; its own updates are confirmed by the sync response rather than sent back. Customer Order gives each store its share to pick; Click and Collect turns that share into picking work for store staff using the Inventory app and reports the result back to Customer Order. A system that works with the store's picking itself, such as a TMS booking a driver, subscribes to Click and Collect's order-status-changed.

🛑 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.

One customer order can be picked by two stores. Order C3R8W5Q is split: the Stockholm store picks the milk and bananas, and the Uppsala store picks the baked beans. Each store's share is a fulfillment with its own fulfillmentId. Both stores publish a PICKED event with the same orderId, and they are not duplicates: key on fulfillmentId.