Sending an order writes the purchase order

After a successful send, the order is written with its lines, its PO number, the supplier, the customer and the job — so it exists everywhere it is needed.

What it is

A server-side write that follows the email. It allocates the next PO number for the org, inserts the supplier_orders header with status 'sent', source 'estimate' and the email it went to, and inserts the line items with their category, unit, quantity and price. It also derives the customer from the job when the caller did not supply one.

Also called: order appears on the supplier card · PO record · no orders yet bug

See it
Sending an order writes the purchase order
Area
Operations
Group
Purchasing
System
Supplier Order Lifecycle
Solves
2 named problems
01The write happens AFTER the send succeeds — 'an order that never reached the supplier is not an order'
02PO numbering scans the org's 50 most recent PO numbers and increments
03contact_id is resolved from estimate_links by job_id when the caller did not pass it
The supplier's card showing the new PO row seconds after Send. SupplierDetailPanel.tsx order list, written by api/orders/send. Sample data — no customer information appears here.
How it works
  1. 1The write happens AFTER the send succeeds — 'an order that never reached the supplier is not an order'
  2. 2PO numbering scans the org's 50 most recent PO numbers and increments
  3. 3contact_id is resolved from estimate_links by job_id when the caller did not pass it
  4. 4Line rows carry the estimate's category so receiving can group by it
  5. 5A failure here is logged but never fails the request: 'The supplier HAS the order — never fail the request over bookkeeping'
Why we built it

Migration 219 records the exact failure: 'Sending a material order from an estimate emailed the supplier and stamped a badge on the project card. It wrote no order row at all — so the supplier's contact card correctly said "No orders yet" while the supplier was reading the order in their inbox. The record only existed as an email.' The customer derivation has its own note: 'The estimates view only knows the customer when a project is selected, so orders sent from elsewhere landed with contact_id null and never appeared on the customer's card at all… The job already knows whose it is; ask it.'

The problem
  • An order living only in an inbox cannot be received against or claimed on
  • An order with no customer link never reaches the customer's card
Sound familiar?
What you get
The order appears on the supplier, the customer and the project
A PO number to quote back
Receiving and claims become possible

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 →