My role
Workflow modelling and public demonstration implementation
The result
The visitor can inspect the full relationship between a quote revision, its approval, the resulting invoice and the remaining balance. The example makes ordinary business rules visible rather than hiding them behind a dashboard.
01
The problem
A quote is more than a total. Once a customer approves a revision, later edits must not silently alter that agreement. Invoices and payments must retain a clear relationship to the approved work.
02
Operational context
Demo Contractor is fictional. This isolated reconstruction communicates a business-workflow pattern without publishing a client's records or claiming the current state of a private office system.
03
My contribution
I modelled the sequence as explicit document and ledger states, with revision history, approval prerequisites and deterministic amounts. The public example keeps the visitor's records in their own browser and marks every exported business document as a demonstration.
04
Constraints
- Fictional parties and synthetic prices; no customer addresses, tax identifiers or banking details.
- Integer-cent calculations with explicit half-up rounding.
- An approved revision remains unchanged when a later draft is edited.
- No real signature, charge, message or external customer account.
05
Implementation decisions
- Store versioned records in IndexedDB so the workflow survives reload without creating a shared backend.
- Create an invoice only from an approved revision and prevent duplicate invoices for that revision.
- Treat a payment as a bounded local ledger entry; reject negative amounts and overpayments.
- Export a readable document with deterministic references and a prominent non-payable demonstration label.
06
Alternatives considered
- Editing a single mutable quote would erase the relationship between approval and the accepted scope.
- A simulated progress animation would conceal the actual business rules and persistence behaviour.
- Connecting a payment provider or sending real invoices would go beyond the public demonstration.
07
Validation approach
- Quote revisions remain independent; approval is required before invoicing.
- Invoice uniqueness, payment balance, reload recovery and storage failures.
- Two browser contexts remain isolated; reset touches only demonstration records.
08
What this shows
The visitor can inspect the full relationship between a quote revision, its approval, the resulting invoice and the remaining balance. The example makes ordinary business rules visible rather than hiding them behind a dashboard.
09
Limits of the evidence
- Browser-local persistence is not a multi-user accounting backend.
- The sample tax calculation is a demonstration rule, not tax guidance.
- A demonstration approval is not a legally binding electronic signature; a payment entry moves no money.
Inspect the work
A similar problem in your organization?
This example can be a starting point for defining your own project, its dependencies and acceptance criteria.