Every quantity change is kept

Quantity edits are append-only rows keyed to the design, so the current number is the latest row and the history survives a reset.

What it is

Building_material_adjustments records design_id, line_key, usage, item, category, unit, the original take-off quantity, the new quantity, where the change came from (estimates / project / field) and an optional reason. The current quantity for a line is simply its most recent row.

Also called: material change history · who changed the quantity · material audit log

See it
Every quantity change is kept
Prepared for
Ivy Brubaker
1140 Ridge Line Rd · Fair Play
Shell package$31,577
Concrete & site$9,167
Doors & windows$6,112
Trim & finish$4,074
Total
$50,930
Signature
Not directly visual — best shown as the edited-row state persisting after a reload. materialAdjustments.ts `latestQtyByLine`. Sample data — no customer information appears here.
How it works
  1. 1materialLineKey(usage, item, lengthFt) identifies a line across surfaces
  2. 2Each edit inserts a new row rather than updating one
  3. 3latestQtyByLine walks the rows newest-first and takes the first per key
  4. 4A reset inserts qty = takeoff_qty, with reason 'reset-all' on a bulk reset
  5. 5source is constrained to estimates / project / field so a later field report shares the same log
Why we built it

Migration 233: 'Each write is a new row (append-only) so Estimates, Project Management, and a later field report all share one audit log keyed by design_id… Reset = insert qty = takeoff_qty (the history stays).'

The problem
  • An overwritten quantity erases the reason it was changed
  • Three surfaces editing the same line with no shared record
Sound familiar?
What you get
A reset does not destroy the history
One log shared by estimating, PM and the field

See it on your own jobs

Twenty minutes, your numbers, no slide deck. We’ll build one of your real buildings in front of you and send you the estimate link at the end — yours to keep either way.

or keep browsing features →