Skip to main content

Stock Corrections

Stock Corrections records adjustments to stock that did not come from trade. A sale, a delivery, a customer return or a store transfer all move stock as a side effect of a business document. A correction is the opposite: someone has looked at the shelf, found the number wrong, and is saying so deliberately.

A correction in one moment. In the Uppsala store a colleague finds 3 broken pots of yoghurt, scans the item, chooses Remove and the reason Damaged goods, and sends 3. Stock Corrections publishes it as a change of minus 3 with its reason, and Uppsala's stock of the yoghurt goes from 12 to 9.

Typical reasons:

  • Damage — items broken in the store or in the stockroom
  • Theft and loss — shrinkage written off
  • Expiry and spoilage — goods removed because they can no longer be sold
  • Own use — items taken for displays, samples, tastings or staff use
  • Receiving errors — a delivery booked in wrongly and now corrected

The point of the service is not the arithmetic — it is the reason. Every correction must carry a reason code, so that the difference between "we lost 40 units to theft" and "we lost 40 units to spoilage" survives into reporting instead of being flattened into one unexplained adjustment.

What the service actually is​

🛑 Stock Corrections does not hold your stock. It stores nothing and it has no balance to read back. It validates a correction, stamps it with who and when, and publishes it as a public event. Whichever system owns the stock figure then applies it.

Where Stock Corrections sits. A correction comes from the Inventory app or from your system through one REST endpoint. Stock Corrections checks the reason code against the store's configuration, stamps the correction and publishes one event. It stores nothing. Stock Transaction Processing applies it when Hii Retail is the stock master; your own system applies it, through External Events, when it is.

That single sentence decides most integration questions:

  • there is one endpoint, and it writes;
  • there is no query API, no correction history, no "list yesterday's write-offs" call;
  • the event is the record. If you want a log of corrections, subscribe and keep your own.

See How it works for the path a correction takes and who applies it.

Who does the corrections​

The work happens in the store, on a handset, done by staff. Somebody notices a broken case of yoghurt, opens the app, scans it, picks a reason and adjusts the number. That is the normal shape of this service, and it is why the data is worth having.

Extenda supplies the client — the Hii Retail Inventory app has a Stock Correction screen with an item scanner, a reason-code picker and an add/remove toggle. A customer does not have to build anything to use this service.

The app does ordinary REST, so a customer who would rather drive corrections from their own system — an ERP writing off expired stock in bulk, for instance — can use the same endpoint:

ActionEndpoint
Record a correction for one itemPOST /business-units/{businessUnitId}/stock-corrections/{itemId}

That is the whole API. See The API for the request shape.

The Stock correction screen in the Inventory app. The colleague picks the reason, here Damaged goods, which preselects Remove, enters 3 and taps Update stock. The app sends one call with quantity minus 3 and the reason code. Staff always type a positive number; the toggle decides the sign.

🛑 You send corrections in and subscribe to what comes back — you do not drive the operator's actions. There is no queue of pending corrections to hand a store, no approval step, and no way to ask the app to correct something. An integration contributes corrections and reacts to the events; it does not orchestrate the person holding the handset.

Where to start​

If you want to…Read
understand the path a correction takes, and who applies it to stockHow it works
set up the reasons staff can choose fromReason codes
send corrections from your own systemThe API
receive corrections in your own systemEvents