AI / ML
Follow One Vendor Price from Source Row to Project Selection
By Vivek Jalondhara · 5 min read
Published
Trace a vendor price through AI extraction, source review, catalogue storage, and project selection in an illustrative Sheet Parser workflow.
A useful price import should answer a simple question later: why does this project show this amount for this item? Following one row through the application makes the responsibilities of the interface, model, backend, and database easier to explain.
This walkthrough uses Sheet Parser's confirmed React, Node.js, TypeScript, OpenRouter, Prisma, and PostgreSQL stack. All identifiers, prices, and review mechanics below are synthetic design examples. The focus is the relationship between stages, rather than a claim about deployed implementation details.
Begin with the vendor and the exact source
Imagine a fictional speaker row labelled SPK-42 with the text INR 12,400.00 per pair. It appears on row 18 of the Speakers sheet. Before extraction, the backend associates the upload with an authorised vendor and workspace and records which stored file version contains that row.
The filename alone is insufficient because a vendor can reuse it next month. A source reference should resolve to the exact imported content, subject to access control. Retaining that reference gives later stages a common anchor even when a description is corrected or the row is extracted again.
Ask the model for a proposal
The extraction request asks for the product code, amount, currency, and selling unit. For this row, a plausible proposal is SPK-42, 12400.00, INR, and pair. Structured outputs on compatible OpenRouter models help constrain the response shape. Application validation and comparison with the source remain separate steps.
The model does not choose the workspace or decide that its own proposal is accepted. The backend attaches trusted context to the returned fields and retains the interpretation as a draft. If the unit is missing, the row needs review rather than an automatic assumption that the price is for one speaker.
Review the interpretation in context
The React review screen should make the original row and relevant headings easy to inspect next to the draft. The reviewer is answering specific questions: does the code match, is the amount read correctly, and does pair describe the price basis? Displaying only the extracted JSON hides the evidence for those decisions.
A correction should record what changed while leaving the original extraction available. Accepting a reviewed revision requires a server-side permission check and a conflict rule if the draft changed while it was open. The example snapshot below represents the result of that review, not a model response that can approve itself.
Store an accepted catalogue reference
Once accepted, the price receives an application-owned revision identity. Keep the amount, currency, and selling unit together with the source reference. PostgreSQL numeric can store decimal amounts exactly within the selected precision and scale; use a representation at the API boundary that does not silently pass the value through floating-point arithmetic.
The catalogue connects this revision to a vendor item. Where acceptance changes several related records, define one transactional operation so the visible accepted state is coherent. Prisma provides transaction mechanisms, but the application still decides which writes belong together and how conflicts are reported to the reviewer.
Let a project select a specific accepted price
Suppose a project requires four pairs. Its selection can reference the accepted revision and record a quantity with the same basis. This preserves the distinction between the vendor's price and the project's chosen quantity. A project-specific negotiated amount, if supported, needs its own explicit relationship and explanation.
Now a second sheet arrives with a different speaker price. A reference to the earlier accepted revision lets the project continue displaying the value its team selected. Updating that selection becomes a visible action with a comparison, rather than a hidden consequence of asking for the latest catalogue price on every page load.
Demonstrate the chain in both directions
A useful portfolio demonstration begins with the synthetic source, accepts a draft, and selects it for a project. Then reverse the journey: open the project selection, inspect the accepted price, and locate the originating row. This shows why each stored relationship exists without revealing a customer sheet.
Also show a changed source and an unresolved row. The important property is that the application can explain what is known and which version a project uses. Extraction, catalogue management, and project pricing become one understandable workflow when every stage preserves that explanation instead of only passing along a number.
A synthetic snapshot with a traceable price selection
These application-owned identifiers illustrate relationships after review. The model supplies candidate fields only. Vendor and workspace context, access checks, and acceptance history are omitted from this display fragment.
Illustrative example · JSON · Simplified for explanation
{
"source": {
"id": "source-demo-1",
"sheet": "Speakers",
"row": 18,
"rawPrice": "INR 12,400.00 per pair"
},
"acceptedPrice": {
"id": "revision-demo-1",
"sourceId": "source-demo-1",
"sku": "SPK-42",
"amount": "12400.00",
"currency": "INR",
"unit": "pair"
},
"projectSelection": {
"projectId": "project-demo-1",
"priceRevisionId": "revision-demo-1",
"quantity": "4",
"unit": "pair"
}
}- Vendor row and exact source
- Extracted draft and source review
- Accepted catalogue revision
- Project selection with a quantity
Conceptual flow for the example above.
Tradeoff to keep in mind
Preserving source and revision relationships makes updates explicit, but requires retention and deletion policies. A traceable amount can still be wrong; provenance explains where a value came from and supports review rather than proving accuracy.