What Each Document Remembers
Five documents, four handovers. At each handover something is carried forward and something is dropped, and the dropped things are not obvious from any screen. This is the map — what survives each step, and what you have to carry yourself.
A purchase in this system passes through five documents: a request, a [request for quotation](/glossary/request-for-quotation), a supplier's quotation, an order, and a receipt, with a payment behind it. Each handover is a small translation, and every translation loses something.
None of the losses is dramatic. All of them are invisible on the screen where they happen. Together they are the difference between a chain you can audit and a chain you can only follow.
Handover one: request to request for quotation
Carried: the items, the quantities, the destination warehouse and location, and the approval — an order cannot be raised against an unapproved request, and that refusal is the anchor for everything downstream.
Dropped: the department, in a specific and technical sense. It is held on the request as text rather than as a reference, so it survives as a word rather than as a link. If the request for quotation does not carry a department of its own, that word has to be matched by exact name later, and where it does not match the department is simply absent from the order. See A Department That Is Only a Word.
Also not carried: any value the requester intended. The figure shown on a request is the quantity times the item master's buying price, not something the requester supplied — see The Estimate That Is Not Yours.
Handover two: request for quotation to quotation
Carried: the basket. A request has real line rows, and every invited supplier is answering the same list, which is what makes the responses comparable at all.
Dropped: the queryability of the answer. A quotation holds its lines as a structured field on the header rather than as rows, so nothing can compare line against line across suppliers. See The Quote Lines That Are Not Rows.
You can query what you asked for at every step of this chain. The one thing you cannot query is what the supplier answered.
Handover three: quotation to order
Carried: the price, the supplier, the lines — which become relational rows on the order — and the currency, though not by being copied. An order has no currency field of its own and resolves one through the quotation each time it needs it. See The Order That Borrows Its Currency.
Dropped: the commercial terms, because there were never any to carry. No delivery terms, no incoterm, no payment days — none of those exist on a supplier or on an order. See A Supplier With No Standing Terms.
Handover four: order to receipt
Carried: the ordered quantity, as something to be checked against. An over-receipt is refused before anything is written, counting every earlier delivery so a split consignment cannot creep past the order one lorry at a time.
Deliberately not enforced: the other direction. A short delivery is recorded and never blocked, because refusing goods that are physically on the floor produces a lie rather than a stop. See One Refusal and One Record.
Dropped: any quality decision. A batch carries a quality status you can set and nothing holds stock pending inspection, so goods that failed a check are still available to sell.
Handover five: receipt to payment
Carried: the whole comparison. A single gate decides whether an order may be paid, and every one of the six payment paths calls it. A discrepancy blocks by default; an override needs a dedicated permission and a written reason, and is pinned to the discrepancy count it authorised so it withdraws itself when the problem changes.
Dropped: the supplier's own invoice, which never entered the chain at any point. What the match compares is our order against our valuation of the receipt. See The Third Document That Is Our Own.
The map, in one place
What survives each handover
| Carried through | Req → RFQ | RFQ → Quote | Quote → PO | PO → Receipt | Receipt → Pay |
|---|---|---|---|---|---|
| Items and quantities | Yes | Yes | Yes | Yes | Yes |
| Approval authority | Yes | Yes | Yes | Yes | Yes |
| Department | Partly — configurable by you | Partly — configurable by you | Partly — configurable by you | No | No |
| Line-level detail you can query | Yes | No | Yes | Yes | Partly — configurable by you |
| Currency | No | Yes | Partly — configurable by you | No | No |
| Commercial terms | No | No | No | No | No |
| The supplier's own figures | No | Yes | Yes | No | No |
Built and maintained Configurable by you, not maintained by us Not built
A partial mark means it survives under a condition stated in the section above — the department only where a name matches or an earlier document carried a reference; the currency only by derivation rather than by being stored.
What AWRA OpsHub does today
- Five linked documents with the request retained and referenced all the way through.
- Requisition approval enforced before an order can be raised, with named actors and timestamps at every approval.
- Relational line items on requisitions, requests for quotation and purchase orders.
- An over-receipt guard counting prior deliveries, and a payment gate on all six payment paths.
- A supplier portal in which the other side can respond, acknowledge, accept, reject and update shipping.
What it does not do
- A department reference on a requisition — it is text, matched later by exact name.
- Relational quotation lines, so nothing compares supplier answers line by line.
- A currency field on a purchase order, or any commercial terms on a supplier or an order.
- Any capture of a supplier invoice, so the third leg of matching is our own valuation.
- A quality hold at receipt, so an inspection result does not stop stock becoming available.
Not ours, by choice
- Nothing in this map is new. Every line is argued at length in a linked post, and the value here is seeing them in sequence rather than one at a time.
- The chain is strong at both ends — approval at the start, the payment gate at the finish — and thin in the middle, which is the shape worth knowing before you design your process around it.
- Nothing here is Ugandan. It is a map of the product; this is a market where the whole chain, rather than one part of it, tends to sit inside one system.
What is not built for Uganda today can still be built for you
Anything described above as not built is a statement about what ships in the standard product today — not a limit on what AWRA OpsHub can do in Uganda. Kenya's eTIMS integration and its maintained payroll engine exist because Kenyan clients needed them and commissioned them; neither appeared by itself. The same door is open here. If EFRIS fiscalisation, a bank or mobile money feed, a statutory return format, a rule your own operation needs that the standard one does not have, or a link to a system you already run is what stands between you and a decision, tell us and we will scope it as a build — written spec, timeline and price — before you commit to anything.
EFRIS fiscalisation
Invoice submission against URA's published interface, with the parts vendors gloss over — retries, a failure queue, and a daily report of sales carrying no fiscal reference.
MTN, Airtel and bank feeds
Mobile money and bank statement feeds pulled into the Payments Register, so collections match invoices without anyone re-keying a statement at month end.
The operational work, which is what most commissions actually are
An extra approval stage in a chain that does not match the standard one, a custom field set on employees or assets that only your sector needs, an expiry that has to block an order rather than send an email, a report your board asks for in a shape nothing produces, or a scanner or weighbridge feeding the goods-in door. These are the commissions we are asked for most often and the smallest ones we quote — and unlike a revenue-authority pipeline, none of them waits on a regulator.
Payroll and statutory returns
PAYE and NSSF schedules produced in the layout your filing body expects, generated from live payroll records rather than rebuilt in a spreadsheet each month.
Systems you already run
The accounting package, CRM, online store or custom database you intend to keep — connected through our API so a fact is entered once and appears everywhere it is needed.
How it works: you describe the requirement, we return a written scope, timeline and cost, and once agreed it is built into your environment and maintained as part of the product. No roadmap slide, and no pretending in a demo that something exists when it does not.
Tell us what you need integratedThe handover question, for any system
Walk one purchase from request to payment and tell me what each step drops.
A good answer sounds like
A specific answer at each step.
What it actually means
Nobody asks this and it is the most revealing question in a procurement evaluation, because losses happen at handovers rather than inside documents.
Which fields are references and which are text?
A good answer sounds like
A clear split.
What it actually means
Text fields that later have to become references are where silent failures live, in every system of this kind.
Where does the supplier's own data first enter, and where does it stop?
A good answer sounds like
Two named points.
What it actually means
In ours it enters at the quotation and stops there. Knowing that is the difference between trusting the match and understanding it.
Our position
Strong at the ends, thin in the middle. Approval at the start and the payment gate at the finish are genuine controls and better than the norm. Between them, the things that get dropped are the department, the queryability of a supplier's answer, and the commercial terms — so put those three somewhere deliberate in your own process rather than assuming the chain carries them.
Walk your own chain once, on paper
Take one real purchase from last month and follow it through all five documents, noting what each step lost. It takes an hour and it will tell you exactly which three habits your team needs.
Walk it with usFrequently asked questions
Which of these losses matters most?
The department, because it is the only one that silently affects a number somebody reports on. A budget that reads underspent generates a compliment rather than an investigation, so nothing corrects it.
Can I skip the request for quotation step?
You can raise an order from a quotation without a full competitive process, and you lose the shared basket that makes quotes comparable. More importantly for this map, a request for quotation is the natural place to carry a department reference, which removes the exact-name lookup entirely.
Is the chain auditable end to end?
Yes, in the sense that matters most: every approval, receipt, override and payment carries an actor and a timestamp, and the documents are linked. What is not reconstructable is anything that was never captured — a supplier's invoice figures, a commercial term, or a department that failed to resolve.
