bc-job-number

BC Job Number (2026-07-30)

JES/Groundworks are retiring customer numbers; their new indexing is customer name, address, or BC Job Number. Platform change (entirely-api 5c175c3, entirely-portal 51f7baf, migration 029):

• projects.bc_job_number + ppdr_staging.bc_job_number (text NULL); projects_enriched extended; ppdr_staging.customer_number NOT NULL dropped.
• Both references are now OPTIONAL at intake (portal wizard, intake-ui at unlikely.icu, triage new-project form). The old “Customer number is required for JES branches” guards are gone (routes/intake.py, services/intake_requests.py).
• Display rule everywhere (certs, invoices, portal, unlikely.report): customer_number wins with its existing label; when absent, bc_job_number renders with label “BC Job Number” / “BC Job #“.
• Plumbing: config.FIELD_BC_JOB_NUMBER = "s_bc_job_number" pseudo-slug → SUPABASE_FIELD_MAP → flows generically through create_record / update_record / _record_from_row.
• Invoice INV Reference composite is (customer_number or bc_job_number)-project_id; remittance parsing already extracts the project-id pattern regardless of prefix.
• unlikely.report URLs fall back to the BC number as path segment; resolver matches either column; index pages label the ref “BC Job” when it matched bc_job_number.
• Search: quick-search, projects list, /projects/suggest, triage check, and the portal client-side filters all match bc_job_number.

Known gap: ppdr_matcher still keys on customer_number only — Stephaney’s workbook has no BC column yet. Extend matcher + workbook ingestion when JES starts sending BC numbers on the tracker.

Related: cert-public-hosting, confidence-routing