BLOOMINVENTORY
Careers 4Book a demo

Approach

The Ledger Is
the Product.

Every inventory system shows you a number. What matters is what stands behind it. In Bloom Inventory that number is not stored anywhere — it is the sum of every movement that has touched a product at a location, and it can be read back one movement at a time. That single decision settles most of the others below.

The ledger

How we model stock

  1. Stock is a balance, not a field.

    A stock level is not a number somebody types. It is what you get when you add up everything that touched a product at a location — received, sold, transferred, counted, returned, adjusted. We store the movements and derive the balance from them. There is no quantity field to overwrite, so nothing can quietly overwrite it.

  2. Nothing is edited in place.

    A mistake is not fixed by changing the row that recorded it. It is fixed by a new movement that reverses it, written at the moment you noticed, carrying your name. The breakage booked at 10:11 is still there underneath the adjustment that cancels it. The history you audit is the history that happened, not the history that survived editing.

  3. One transaction, or none.

    A sale at the counter moves stock, raises an invoice and records a payment. Those are three writes, and any system that lets one land without the other two will drift — slowly, quietly, and in a direction nobody notices until the count. We write them together or we write none of them.

  4. Every movement carries a name, a place and a time.

    Not an audit log kept beside the data, which can be switched off, trimmed, or fall out of step with what it describes. The movement itself carries who, where and when. Who moved the missing forty units is a question you ask of the stock record, not of a second system.

Access

How we handle who sees what

  1. Isolation sits at the repository, not the screen.

    Hiding a menu item is not access control. It is decoration over a query that would still have returned the data. Every read and write is scoped to one business a layer above the database, so a mistake in a screen cannot reach another business's stock.

  2. Permissions shaped like jobs that exist.

    Roles start from blueprints for seven real jobs — the cashier, the storekeeper, the branch manager, the bookkeeper — because that is how a shop already divides its work. Permissions per resource and action are there for the cases the blueprints miss, not for the thing you are asked to configure on your first morning.

Here

How we build for where it runs

  1. The scanner is the phone in your pocket.

    A scanner you have to source, import, register and replace is a reason this week's count does not happen. A camera already in the hand of the person standing at the shelf is a reason it does. Receiving, counting and selling all scan with it.

  2. Ethiopian by default, not by setting.

    Birr, VAT at 15 percent, withholding, and the documents the tax office expects are the shape of the product, not a locale file switched on at setup. When the rules move — as they are moving now with mandatory electronic invoicing — that is work for us, not a workaround left with you.

  3. We ship into the back room, not the demo.

    The conditions that decide whether software is used are a queue at the counter, a connection that comes and goes, a device three people share, and someone who was hired to sell rather than to operate a system. A feature that only works in a quiet room on good internet has not shipped yet.

We write this down as we go.

The thinking behind these decisions — stock valuation, cycle counting, landed cost, what the electronic invoicing directive actually asks of a till — is published rather than kept as sales material.

Read our writing