Line items can carry a supplier_id. Signatures carry the same field: null means the whole change order, a value means that supplier's block. The status math requires every distinct supplier key to have a matching signature before the change order flips to approved; some-but-not-all yields 'partially_signed'. On approval, one draft supplier order is created per supplier group, idempotent on (change_order_id, supplier_id).
Also called: multiple suppliers on a change order · partially signed · supplier split · purchase orders from a change order
- 1Assign a supplier per line item in the editor (empty is treated as unassigned).
- 2The signing modal filters line items and the subtotal to the block being signed, 'so the customer sees the dollar amount they're actually authorizing — not the grand total of the whole CO'.
- 3From the portal the customer authorises the whole change order, so one signature row is written per outstanding block — keeping the status math identical to the in-person admin flow.
- 4Approval generates purchase orders per supplier; lines with no supplier are ignored because they map to no PO recipient.
Migration 050 introduced the split and the code documents the backward-compatible path: 'Pre-migration-050 callers omit supplierId and the CO has no per-line supplier assignments — blockKeys collapses to a single key, the signature covers it, and the CO flips straight to "approved" same as the old single-signature flow. New behavior only kicks in when the CO actually has multi-supplier line items.'
- Multi-supplier scope changes forced into one all-or-nothing signature
- Manual purchase-order creation after each approved change
- No visibility into partially authorised changes
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 →