The Quote Lines That Are Not Rows
A requisition has line rows. A request for quotation has line rows. A purchase order has line rows. A supplier's quotation has a JSON blob. It is the one document in the chain whose detail is not queryable, and it is the one you most need to compare.
Competitive buying is a line-by-line activity. Three suppliers quote against the same basket, and the useful question is never which total is lowest — it is which supplier is cheapest on which line, and whether the cheapest total is cheapest because it left something out.
Our system cannot answer that, and the reason is structural rather than a missing screen.
One document out of four
Walk the chain and look at how each document stores its detail.
| Document | How its lines are stored | Queryable? |
|---|---|---|
| Requisition | Rows in their own table, with an item and a quantity | Yes |
| Request for quotation | Rows in their own table, linked to items | Yes |
| Supplier quotation | A single structured field on the header | No |
| Purchase order | Rows in their own table, with quantities and prices | Yes |
The odd one out is the supplier's document. Everything you asked for is in rows; everything they answered is in a blob.
You can query what you asked for and what you ordered. You cannot query what you were offered.
What that makes impossible
Not display — the lines render perfectly well on the quotation itself. What it makes impossible is anything that requires the database to look across quotations.
- A line-by-line comparison across suppliers. The core of competitive sourcing. Three quotes side by side, one row per item, cheapest highlighted. Nothing can produce it, because the rows do not exist as rows.
- Detecting an omitted line. The most common reason one quote is cheapest is that it quoted for less. A total-versus-total comparison cannot see it, and neither can anybody in a hurry.
- Price history per item per supplier. What did this supplier quote for this item last time? The information is in the system and cannot be asked for.
- A split award. Buying line one from supplier A and line two from supplier B needs line-level identity on both quotes.
- Any report over quoted prices. Average quoted price by item, by supplier, by quarter — all of it needs rows.
And it explains something we have published elsewhere: the quote comparison scores on the header total, with weights across price, delivery time and a rating. That is not a design preference. It is the only figure available to score on.
The failure mode a blob has and a table does not
This is the part worth carrying to any evaluation, because it generalises well past this product.
A table has a schema. Ask it for a column that does not exist and something errors, immediately and loudly. A structured blob has no schema. Ask it for a key that is not there and you get nothing back — silently, successfully, forever.
That is not hypothetical here. Our receipt-matching service used to read quotation-derived invoice lines by a key the stored data never contained. Every lookup missed. Every line reported as unbilled. The service returned a discrepancy on every order, always, from the day it was written — and nobody found out, because nothing rendered its output and nothing errored.
A missing column would have been found in an afternoon. A missing key was found years later.
Why a Pakistani buyer notices first
Because the buying culture here is genuinely competitive at the line. Multiple quotes are routine rather than exceptional, suppliers are numerous, and the negotiation happens item by item — a buyer who accepts a total without going through the schedule is not doing the job.
That is exactly the work the system cannot support. It will hold the quotes, display them, and compare their totals. The line-by-line schedule that the buyer actually works from has to be assembled by hand, every time, from documents the system is holding but cannot read into a table.
It is also the reason the workaround below is not a trick. It is what people are already doing.
Working with it today
- Quote against a request, always. The request has real line rows, so it is the shared reference every supplier is answering. Without it, three quotes are three unrelated documents.
- Build the comparison schedule outside, and keep it. One row per item, one column per supplier. Attach the finished schedule to the winning quotation so the reasoning survives the decision.
- Check for omitted lines before you look at totals. Count the lines on each quote against the request. This takes ten seconds and it is the single check the system will not do for you.
- Record split awards as separate orders. One order per supplier, each referencing the same request. Ugly, correct, and reportable.
What AWRA OpsHub does today
- Requisitions, requests for quotation and purchase orders all with relational line items linked to catalogue items.
- Supplier quotations holding their own line detail, displayed on the quotation and carried through to the resulting purchase order's lines.
- A currency, a tax treatment and a financial snapshot on each quotation, so an agreed price cannot drift.
- A weighted comparison across quotations on the header total, with a persisted ranking.
- A supplier portal in which vendors submit and edit their own quotations.
What it does not do
- Relational quotation line items. The lines are held as a structured field on the header, with no table and no model.
- Any line-by-line comparison across suppliers.
- Detection of an omitted or substituted line on a quote.
- Price history per item per supplier, or any report over quoted prices.
- Split awards across suppliers from one comparison.
Not ours, by choice
- The lines are not lost — they are displayed, and they become the purchase order's relational lines when an order is raised. The gap is querying across quotations, not the document itself.
- The receipt-matching incident described above is fixed. It is quoted here because it is the clearest evidence of how a schemaless field fails, not as a current defect.
- Nothing here is Pakistani. It is what a blob cannot do; this is a market where line-level competitive buying is the norm rather than the exception.
What is not built for your market 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 your market. 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 a tax authority pipeline, 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.
Tax authority pipelines and reporting
Electronic invoicing or invoice registration against your authority's published interface, with retries, a failure queue and a daily report of sales that carry no reference. The regimes across this region differ enough that this is one build per country rather than one build for the region, and the local bench is deep in most of them — so the honest question is usually whether you need this from us at all, or whether you need the operations layer that feeds whatever you already file with.
Local payment rails and bank feeds
Real-time payment collection matched to the invoice, bulk payment files in your bank's format, and statement feeds wired into the Payments Register.
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
Statutory payroll and social security schedules computed on live records and produced in the layout each filing body expects. Per-state and per-province variation is the norm rather than the exception here, and it is what makes this a country build rather than a regional one.
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 integratedOur position
Use the request for quotation as your shared basket, compare lines in a spreadsheet, and attach that spreadsheet to the winning quote so the decision has a record. Count the lines before you read the totals. And if line-level sourcing analysis — price history, split awards, cheapest-by-line — is central to how you buy rather than occasional, raise it as a requirement, because it is a schema change rather than a report.
Three questions that expose this in any system
Show me three quotes side by side, one row per item.
A good answer sounds like
A comparison grid, on screen.
What it actually means
This is the demonstration to ask for, and it is not the same as showing three quotations in a list.
What did this supplier quote for this item last year?
A good answer sounds like
A price history.
What it actually means
Requires line-level storage. If it cannot be answered, the data is being kept and not indexed.
Can I award line one to A and line two to B?
A good answer sounds like
Yes, from the comparison.
What it actually means
Split awards are the clearest test of line-level identity, and they are how a competent buyer actually buys.
Build the comparison schedule once, properly
A single spreadsheet template — request lines down the side, suppliers across the top — turns the workaround into a process. We will build one against your own request format.
Build the templateFrequently asked questions
Do the quotation lines reach the purchase order?
Yes. When an order is raised from a quotation, the lines become relational purchase-order line items with quantities and prices. So the detail is not lost — it becomes queryable at the moment it becomes an order, which is one document too late for a comparison.
Could a report be written over the quotation lines anyway?
In principle a structured field can be read, and in practice it is fragile in a specific way: nothing enforces that every quotation stores the same keys, so a report over it is correct until the day it silently is not. That is precisely how the receipt-matching defect survived for years.
Is this a big change to fix?
It is a schema change with a data migration behind it — a table, a model, and a conversion of existing quotations — plus everything downstream that reads the current shape. That makes it a project rather than a feature, and worth scoping properly against how you actually buy rather than assumed.
