Those three decisions are usually made in week one of an implementation, by whoever happened to be doing the setup, in about forty minutes. Two years later they are the reason a report can or cannot be produced — because every historical record is filed against them and refiling history is not a thing anybody does. This is the least glamorous hour of a rollout and by some distance the highest-leverage one.
Why this page exists
You can rewrite a workflow, replace a report, re-theme the interface and add a module. What you cannot easily do is retrospectively decide that the last two years of expenses should have been coded to eight departments rather than three, or that stock should have been tracked to bin level rather than to warehouse. The records exist. They carry the codes they were given. Nobody is going to open eleven thousand of them.
How finely do you need to attribute cost? If the answer might ever be “by branch” or “by programme” or “by grant”, the department list has to reflect that from the beginning. Three departments called Admin, Operations and Sales will answer no question anybody eventually asks.
How precisely do you need to find things? A warehouse alone tells a picker which building. A location tells them which shelf. The difference is a working day per week in a store of any size, and it is decided by whether locations were set up at all.
What are the real reasons stock moves in your operation? Not the generic list — yours. “Issued to a programme”, “written off after flood damage”, “transferred to the clinic”. A reason code list that does not match how your organisation actually loses and gains stock produces a variance report nobody can act on.
Axis one — who
It is deliberately one flexible concept rather than several rigid ones, because organisations mean different things by it: a team, a branch, a division, a site, a programme, a funded project. Whatever you mean, it is the thing you will eventually want a total by — and it is carried on sixteen different record types so that total is available everywhere rather than in one module.
One honest note on granularity. A department here is a flat list rather than a tree — there is no parent-child hierarchy, so “East Region → Kisumu → Stores” is three departments rather than one path. In practice most organisations encode the hierarchy in the naming and get what they need; if you genuinely need to roll a total up through several levels, say so early, because that is a structural conversation rather than a setting.
Axis two — where
A warehouse says which building. A location says which shelf. Almost every implementation sets up warehouses immediately and puts locations off until later — and later never arrives, because by then there are twelve thousand stock rows with no location on them and adding the level means a physical exercise nobody has time for.
A name, a stable code, an address, a manager and a status. The code is the important field: it is what the import templates reference, what appears on transfer documents, and what other records point at. Short and permanent beats descriptive and changeable, because five other things will reference it.
A location belongs to a warehouse and carries a name and a code of its own — plus a structured placement: zone, aisle, bay, shelf and bin. Those five are separate fields rather than a free-text string, which is what lets a location print as “Zone A / Aisle 4 / Bay 2 / Shelf 3” and be sorted, filtered and reported on rather than merely displayed.
A number per location, which is the difference between a picking list that follows the aisle and one that sends a person back and forth across the store. It is one integer and it is the single highest-value field on this page for anywhere with more than a few hundred lines.
Optional, and worth filling in if you intend to make slotting decisions. A location with a capacity is a location a system can reason about; one without is a label.
Eight storage roles
A location also declares what it is for. This is not decoration: a receiving bay and a quarantine shelf hold stock under completely different assumptions, and a system that cannot tell them apart cannot stop somebody picking from quarantine.
pick_face Where picking actually happens. The fast-moving front line of the store. bulk Pallets and volume, replenishing the pick faces rather than being picked from directly. reserve Held back deliberately — safety stock, seasonal, allocated. staging Assembled and waiting to move. Neither properly in nor properly out. receiving Where a delivery lands before it is put away. Stock here is present and not yet placed. shipping The other end: picked, packed and about to leave. quarantine Held back on purpose — damaged, expired, disputed, awaiting a decision. The role that most needs to be distinguishable. bin The default, and an honest one. Not everything in a store has a designed purpose. Axis three — why
Twenty-five reason codes ship with the product — ten for stock coming in, fifteen for stock going out — and they exist so that a quantity change carries its own explanation. A default is resolved per movement type, so nothing is ever recorded unexplained, and the list is yours to add to, rename and prune.
And one of the fields on a reason code deserves its own paragraph, because it is a checkbox on a reference record that has an accounting consequence. Read the right-hand column below.
Bought to sell on. The commonest inbound reason in a trading business, and the one that makes cost of sales meaningful.
Bought to consume. Distinguished from resale because they land in different places in your accounts.
Stock arriving without a purchase. Essential for donor-funded work, where in-kind receipts have to be reportable separately.
Stock from a grant or a government programme, which usually carries its own reporting obligation.
Received against a procurement decision, linking the movement back to the sourcing chain.
On your shelf, not yet yours. A distinction that matters enormously at a valuation.
Finished goods you made rather than bought — the output side of a job.
Coming back from a customer, which is a different event from a purchase and should never be counted as one.
A correction for price or valuation rather than a physical movement.
Sold to a customer. Carries the revenue flag, which is what makes a check-out post as a sale rather than as a consumption.
Issued against a paid service or project. Also carries the revenue flag, for work billed rather than goods sold.
Issues to internal use, to programmes, to projects, write-offs, damage, expiry, theft, transfers and returns to supplier — all of which reduce stock without producing revenue, and each of which is separately reportable.
A reason code carries a generates revenue setting. When a check-out is recorded against a reason that has it, the movement is treated as revenue-producing rather than as internal consumption. Two of the twenty-five shipped reasons carry it: Sale and Paid Checkout.
Because it means a checkbox on a settings screen has an accounting consequence, and somebody who duplicates “Sale” as “Sale (retail)” without ticking it has created a reason that looks like a sale and does not post like one. It is exactly the kind of thing to know before you edit the list rather than after.
The movement stores the reason as text, and the flag is resolved by looking the name up. That makes the historical record readable without a join — and it means renaming a reason in the settings screen does not rewrite what past movements say they were, which is usually the behaviour you want and always worth knowing.
All three at once
None of these is a clever report. Each is an intersection — and each is impossible if one of the three dimensions is missing from the records, which is why the setup hour matters more than any dashboard.
Reason code says written off, department says whose stock it was, date says when. If the reason list has one generic "adjustment" entry, this report cannot exist.
Storage role says quarantine, warehouse says which site. Without the role, quarantined stock is indistinguishable from available stock in the same building.
Reason in, reason out, and the department that received it. Three fields, one report, and the difference between a donor file that assembles itself and a fortnight of reconstruction.
A budget belongs to a department and so does the spend. Without the department on both, this is two lists somebody compares by eye.
Pick sequence per location, and locations that exist at all. The saving is measured in hours per week and it is one integer per shelf.
Damage, expiry, theft and miscount are four different problems with four different fixes. Filed under one reason they are one unactionable total.
The straight answer
The value here is that the dimensions exist on the right records and are used consistently. What they are not is a hierarchy engine.
What depends on it
Loading warehouses then locations, in order, joined by codes — and why deciding the codes first pays for itself.
Open featureWhat the location structure, pick sequence and storage roles actually do once stock is in them.
Open featureWhere reason codes are chosen, and how a movement carries its own explanation.
Open featureBudget versus actual by department — the report the "who" axis exists for.
Open featureQuarantine as a storage role, and the difference between stock that is present and stock that is available.
Open featureThe location, throughput and spend reports that read these three dimensions.
Open featureWhat changes
That is the whole return on the setup hour. Two years in, somebody asks a question nobody anticipated — spend by branch, write-offs by cause, everything sitting in quarantine — and the answer is a filter rather than a project, because the records were filed properly when they were created.
One department dimension on sixteen record types, so every total can be taken by team.
Zone, aisle, bay, shelf and bin as separate fields, sortable and reportable rather than a text note.
One integer per location, and a picking list that follows the aisle instead of the database.
Eight storage roles, so quarantine is not just another shelf in the same building.
Twenty-five reasons, a resolved default, and nothing recorded as an unexplained number.
Damage, expiry, theft and miscount as four separate reasons rather than one total nobody can fix.
Help Center
Run inventory, procurement, assets, sales, and field work with approved AWRA guidance for setup, migration, integrations, security, pricing, and support.
