A standing script that walks every shipped preset and the whole option matrix, asserts each emitted usage has a price row, that the unit crossing is legal, and that lines relying on a per-foot rate actually carry purchasedLf or lengthFt. Runtime conversion lives in billableQty and stockRowSellTotal.
Also called: unit mismatch · priced per foot vs per piece · estimate came out too low · pricing guard
- 1COUNTED_UNITS (pcs, panels, sheets) crossed with an LF book row must convert: purchasedLf first (it already accounts for cutting waste), then qty times lengthFt.
- 2stockRowSellTotal prices ONE stock row as pieces times length, and for custom-cut members with no stock length it apportions the line's purchased footage by piece share.
- 3The guard prices against resolvedPriceBook(null) — exactly what a tenant with no overrides gets — because checking the bare usage defaults made the assertions vacuous for every bound usage.
One class of mistake — a rate in one unit multiplied by a quantity in another — shipped three times in a single afternoon, silently each time: steel priced at zero because the panel rates and the panel lines were keyed differently, a 16ft post charged as one foot when a per-foot rate met a piece count, and 29.2 feet of decorative timber billed as 29 trusses, putting $27,740 on a 16ft porch. The same class later priced a 4,000 sq ft roof at $225 and left one estimate $8,299 under what the same building totalled elsewhere — the same estimate wearing two prices. A guard now fails the build whenever a priced line's unit does not match the unit of the rate applied to it, so it cannot ship a fourth time.
- Silent zero-cost lines from a key that matches nothing.
- Per-foot rates multiplied by a piece count.
- Two pricing surfaces disagreeing about the same building.
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 →