Auto-IT One

Spend is drawn from the Invoice ledger by department (module). Omit the date window for lifetime spend.

{ "profile": { "ACC_NO": 1001, "company_name": "Acme Parts" },
  "ar_position": { "balance": 48250.00, "credit_limit": 100000.00,
    "aging": { "current": 30000.00, "days_30": 18250.00 } },
  "spend": { "totals": { "invoices": 214, "total": 1875400.00 },
    "by_module": [{ "module": "W", "total": 920100.00 }] } }

Paginated customer list. Use ?search= for partial match across company name, surname, first name, and email. Pass ?acc_no= to retrieve a single account with full detail and live aging.

{ "meta": { "total": 842, "page": 1, "limit": 20 },
  "data": [{ "ACC_NO": 1001, "company_name": "Acme Parts",
    "abn": "4320000001", "CREDIT_LIMIT": 50000.00,
    "Credit_Status": "O", "city": "Johannesburg" }] }

Filter by acc_no for a single debtor. Response includes page totals; archive rows (if requested) come back in their own shape.

{ "meta": { "total": 214 },
  "page_totals": { "value": 48250.00, "outstanding": 12300.00 },
  "data": [{ "REF": "INV00123", "TRAN_TYPE": "IN",
    "VALUE": 2255.00, "allocated_to": 2000.00,
    "outstanding": 255.00, "TRANS_DATE": "2025-04-15 09:22:11" }] }

Returns opening balance, transactions with running balance, closing balance, summary by type, and aging. Pass ?acc_no= for a single statement, or omit it to return paginated statements for all accounts under statements[].

{ "customer": { "acc_no": 1001, "company_name": "Acme Parts", "abn": "4320000001" },
  "opening_balance": 8500.00,
  "transactions": [{ "TRAN_TYPE": "IN", "VALUE": 2255.00, "running_balance": 10755.00 }],
  "closing_balance": 5755.00,
  "aging": { "current_age": 2255.00, "days_30": 1800.00, "total_outstanding": 5755.25 } }

Paginated creditor list with open balance. ?acc_no= returns a single creditor with aging and recent transactions.

{ "meta": { "total": 318 },
  "data": [{ "ACC_NO": 5001, "company_name": "Bosch SA",
    "TRADE_TERM": "30", "CREDIT_STATUS": "O",
    "YTD_PURCH_VAL": 842500.00, "open_balance": 128400.00 }] }

Filter by acc_no for a single creditor. Response includes page totals; archive rows (if requested) come back in their own shape.

{ "meta": { "total": 96 },
  "page_totals": { "gross": 128400.00, "outstanding": 128400.00 },
  "data": [{ "DOC_NO": "PINV4471", "DOC_TYPE": "IN",
    "GROSS_AMOUNT": 14200.00, "outstanding": 14200.00,
    "DUE_DATE": "2025-06-30 00:00:00" }] }

All three parameters are required. Each transaction contributes its unpaid gross to the running balance.

{ "creditor": { "acc_no": 5001, "company_name": "Bosch SA" },
  "opening_balance": 114200.00,
  "transactions": [{ "DOC_NO": "PINV4471", "outstanding": 14200.00, "running_balance": 128400.00 }],
  "closing_balance": 128400.00,
  "aging": { "current": 80000.00, "days_31_60": 48400.00, "total_outstanding": 128400.00 } }

No parameters. Each department flag is a correlated EXISTS probe into the branch column, so it short-circuits on the first match rather than scanning for distinct values.

{ "count": 7,
  "data": [{ "branch": "01", "name": "Head Office",
    "has_wholegoods": 1, "has_parts": 1, "has_workshop": 1 }] }

Every branch, ordered by name, or one branch with ?branch= — the same envelope either way, so a caller reads "one" and "all" with the same code. Every key is on every row in a fixed order, lower-case and aliased in the SQL so it does not depend on how an install spells the column. Values are cleaned here, not by the caller: strings pass through toUtf8() and are trimmed — most of these columns are CHAR and come back space-padded — and a blank becomes null, so "no phone recorded" is one value, not '' and '   '. The four counts are integers and bf_hours_per_day / bf_days_per_week (NUMERIC(6,2)) are floats. A NULL column is null, never 0: a branch with no bay count recorded has not got zero bays, and a capacity screen that read 0 would say it cannot take work.

{ "count": 1,
  "data": [{ "branch": "M0102", "name": "BARBERTON - M0102",
    "street": "12 Main Rd", "city": "Barberton", "state": "Mpumalanga", "pcode": "1300",
    "phone_bus": "013 712 3456", "phone_mob": null, "phone_home": null,
    "email_address": "service@example.co.za", "branch_manager": "J SMITH", "trader_regn_no": null,
    "branch_type": "M", "main_branch_code": "M0101", "company": "M01",
    "wshop_no_of_bays": 6, "wshop_advisor_count": 3, "no_of_loan_cars": 2,
    "time_adjust_minute": 0,
    "bf_hours_per_day": 8.5, "bf_days_per_week": 5.5 }] }

Writes a branch's contact details and manager, and nothing else — the address, the business and mobile phone, the email and the branch manager's name — against the branch code. It is how ServiceConnect's Branch setup saves them back to the DMS. Name, branch type, company and the workshop sizing figures are not writable: they are the DMS's own to keep. Only keys present in the body are written; a key sent as "" or null writes NULL, so clearing a phone is a deliberate act and leaving it out is not. Values are trimmed and converted to Windows-1252, the encoding every read here converts back from, and a value longer than its column is refused with a 400 naming the field — never truncated, because a cut-off street is worse than an error. Every value is a string and every one is bound. WRITEKEY header required. 404 when the branch does not exist. The answer carries the row as the GET now reads it, so a caller shows what the DMS holds rather than what it sent.

{ "ok": true, "branch": "M0102",
  "updated": ["street", "phone_bus"],
  "count": 1,
  "data": [{ "branch": "M0102", "name": "BARBERTON - M0102", "street": "14 Main Rd", … }] }

Periods up to the current month by default. ?all=1 includes future periods; ?year= bounds to one financial year.

{ "filters": { "all": 0, "year": null }, "count": 9,
  "data": [{ "year_end": 2026, "period_start": "2025-03-01",
    "period_me": "2025-03-31" }] }

All franchise codes, ordered by sequence. ?code= returns a single franchise.

{ "count": 6,
  "data": [{ "franchise": "TY", "name": "Toyota",
    "long_description": "Toyota South Africa", "color_bg": "#EB0A1E",
    "sequence_no": 1, "read_only": "N" }] }

Paginated list of invoices and credit notes from the Invoice table. Pass ?document_no= to fetch a single record with full detail, outstanding balance, and allocation history.

{ "meta": { "total": 3201 },
  "data": [{ "document_no": "INV00123", "invo_type": "I", "module_type": "W",
    "bill_to_acc": 1001, "company_name": "Acme Parts",
    "parts_sale_val": 1200.00, "labour_sale_val": 850.00,
    "gst": 205.00, "invoice_total": 2255.00,
    "invo_datetime": "2025-04-15 09:22:11", "cancel_date": null }] }

Returns all allocated payment records from ArTrans_Alloc, joined to ArTrans for payment detail and Invoice for invoice detail. Filter by acc_no to get all payments for a specific debtor.

{ "meta": { "total": 142 },
  "data": [{
    "invoice_rec_no":       45201,
    "payment_rec_no":       46100,
    "amount_allocated":     2255.00,
    "allocation_date":      "2025-05-02 00:00:00",
    "invoice_ref":          "INV00123",
    "payment_ref":          "EFT-20250502",
    "payment_date":         "2025-05-02 00:00:00",
    "payment_amount":       -5000.00,
    "acc_no":               1001,
    "document_no":          "INV00123",
    "invo_type":            "I",
    "module_type":          "W",
    "company_name":         "Acme Parts"
  }] }

Aggregates invoice sales by debtor account, joins customer details, and returns the top 20 sorted by sales_incl_tax descending. Includes invoice count, sales excluding tax, total tax, and sales including tax per customer.

{ "filters": { "date_from": "2025-01-01", "date_to": "2025-12-31", "module_type": null },
  "count": 20,
  "data": [{
    "acc_no":          1001,
    "company_name":    "Acme Parts Pty Ltd",
    "email_address":   "accounts@acme.co.za",
    "vat_no":          "4630198010",
    "credit_limit":    50000.00,
    "invoice_count":   84,
    "sales_excl_tax":  284500.00,
    "total_tax":       42675.00,
    "sales_incl_tax":  327175.00
  }] }

Validity is filtered, and the filter measures itself. ?valid_on= (default: today on the database clock) keeps rows whose window contains that date, treating a null bound as open — a discontinued model in a booking picker is how a job card acquires a spec nobody sells any more. But a null window is the common case on some installs, and a validity filter over a catalogue nobody dates is a filter that does nothing while looking like it works. So every response carries meta.validity.dated_pct — the share of rows carrying either bound — and a warning when it is 0 or under half. Read it before trusting that the picker shows current models. ?all_versions=1 turns it off.

Nothing is inferred from TYPE or Category. Both are single-character-ish code columns whose domain is documented nowhere this codebase can see, so this file does not decide that N means new. They are returned raw, they filter exactly, and ?facets=1 reports what values actually exist — the same rule the workshop endpoints apply to their own two-letter codes. Prices are off by default: SALES_PRICE, COST_PRICE, DEALER_MARGIN, HOLDBACK_AMOUNT and Min_Sell_Margin sit on this table, and a picker feeding a service booking has no business carrying a dealer's margin to a browser. ?prices=1 opts in — not a security boundary, since the read keys already reach it, just a default that keeps the common payload free of numbers nobody asked for.

{ "source": "VhModel",
  "model": { "model_code": "DMAX250", "variant": "250HO4X4",
              "model_name": "D-Max 250 HO Double Cab", "make": "ISUZU",
              "body_type": "DOUBLE CAB", "fuel_type": "DIESEL",
              "engine_size": "2500", "transmission": "MAN",
              "cylinders": 4, "service_cycle": 12, "service_cycle_unit": 15000,
              // TYPE and Category come back raw — nothing here decides what they mean
              "type": "N", "category": "LCV", "line_no": 8842 },
  "versions_on_file": 4,
  // paste this straight in as the vehicle{} key of workshop.php?create_ro=1
  "create_ro_vehicle": { "make": "ISUZU", "model": "DMAX250",
      "model_name": "D-Max 250 HO Double Cab", "variant": "250HO4X4",
      "engine_size": "2500", "fuel_type": "DIESEL",
      "transmission": "MAN", "body_type": "DOUBLE CAB",
      "franchise": "IS", "cylinders": 4,
      "service_cycle": 12, "service_cycle_km": 15000 },
  "meta": { "validity": { "applied": true, "dated_pct": 0.0,
                 "warning": "No row on VhModel carries a valid_from or a valid_to…" },
            "mapping_note": "service_cycle ← Service_Cycle, service_cycle_km ← Service_Cycle_Unit. NOT confirmed…" } }

Paginated list of units in stock (no sales invoice, not swapped out). ?stock_no= returns a single unit with accessories and appraisal. Sold units are in vehicle_sales.php.

{ "meta": { "total": 312 },
  "data": [{ "stock_no": 12345, "make": "Toyota", "model": "Hilux",
    "vin_no": "AHT…", "stock_status": "A", "sale_price_incl": 689900.00 }] }

Paginated accessory catalogue. Note that Make = 'ALL' is the catch-all make.

{ "meta": { "total": 1240 },
  "data": [{ "code": "TOWBAR-HX", "description": "Tow Bar Kit",
    "make": "Toyota", "sales_price": 4500.00,
    "sales_price_inc_gst": 5175.00, "display_indicator": "Y" }] }

Paginated list of sold units, newest sale first. Each page carries page_totals (units and sale value). Gross profit awaits the VhStock cost column.

{ "meta": { "total": 1820 },
  "page_totals": { "units": 20, "sales_value": 7430000.00 },
  "data": [{ "stock_no": 500124, "make": "Toro", "model": "WM1110",
    "sales_invoice": "35923", "sales_date": "2026-05-18 14:54:17",
    "sales_value": 35000.00 }] }

?q= is partial, multi-token and AND-ed — the whole point of the endpoint. ?q=smi ca123 is part of a surname and part of a plate; ?q=smi @gmail is part of a surname and part of an email; ?q=john smith works in either order. Split on whitespace, each token must match something, and a token only has to match one field — which is what lets the two halves land on completely different tables and still describe one person. Searched: surname, name, company_name, both email columns, and through the vehicle probe reg, make, variant.

Only customers with a vehicle, and it is an EXISTS, not a join. The requirement is contact.contact_code = wkvehfl.driver. Written as a join that is person×vehicle grain — a customer with three cars is three rows, the same name three times, and ?limit=20 returns seven people. Written as an EXISTS it is a per-person test that seeks the driver index and stops at the first hit, so the row count is the people count and paging means what it says. The vehicles then arrive in a second keyed query over just the page's contact codes, merged server-side — the same pattern salesReinvoiceCostMap() settled on after a join version of the same idea went from ~290 ms to 4 500 ms.

Detail mode: ?mobile= and ?contact_code=. Added for the Service Connect customer app, where a person signs in with a cellphone number verified by SMS. The app resolves the number to contact codes once with ?mobile=, keeps the codes, and reads them back afterwards with ?contact_code= — a keyed seek on contact(contact_code). Either parameter switches the response to detail: each contact also carries title, the street and postal address columns, the privacy flags, consent_date / consent_expiry_date and last_modified_date; each vehicle also carries model (the DMS model code), model_name and its specification in create_ro's own vehicle{} names — model_version, vin, chassis, engine, engine_size, fuel_type, transmission, body_type, colour, franchise, first_reg — so a car known at one of a group's dealerships can be created properly at another that has never seen it. Both can be combined with ?q=; the search mode without them is unchanged.

meta.total respects ?q= — the count runs the same predicate, so a search matching thirty people reports thirty, not the whole book. Paging is ?limit= / ?offset= with meta.next_offset and meta.has_more carrying the arithmetic. The ORDER BY surname, name, contact_code is both what a person expects to read and what makes offset coherent: without a deterministic sort, "skip the first fifty" means skipping an arbitrary fifty.

Indexes. Registered in Ensure Indexes: contact(surname, name), contact(name, surname), contact(company_name), contact(email_address) and wkvehfl(driver, reg, make, variant). Each makes one leg of the search capable of seeking, and the last one is index-only for all three things it serves — the population test, the vehicle search probe, and the second query's entire projection. Detail mode needs nothing new: ?contact_code= seeks contact(contact_code), its vehicles seek the driver index and read model / model_name off a handful of rows, and ?mobile= cannot use an index at all. Whether SQL Anywhere actually index-ORs a five-leg predicate or gives up and scans is a question only ?debug=1 on live data answers. Measure before believing any of this is fast.

{ // GET ?q=smi ca123 — a Smith with a plate starting CA123
  "count": 1,
  "data": [
    { "contact_code": "C0004182",
      "name": "John", "surname": "Smith",
      "company_name": null,
      // returned, but not searchable — see the note above
      "mob_phone": "082 123 4567", "prv_phone": null,
      "bus_phone": null,
      "email_address": "jsmith@example.co.za",
      "email_address_2": null,
      // second keyed query, merged server-side — never a join
      "vehicles": [
        { "reg": "CA123456", "make": "TOYOTA",
          "variant": "2.8 GD-6", "vehicle": "TOYOTA 2.8 GD-6" },
        { "reg": "ND4471", "make": "FORD",
          // variant missing: || would have made the whole string NULL
          "variant": null, "vehicle": "FORD" }] }],
  "meta": {
    // runs the SAME predicate — 1 of 1, not 1 of 41 208
    "total": 1, "returned": 1,
    "limit": 50, "offset": 0,
    "next_offset": null, "has_more": false,
    "q": "smi ca123",
    "tokens": ["smi", "ca123"],
    "match": "prefix", "mode": "search",
    "mobile_last9": null, "contact_codes": null } }

{ // GET ?mobile=+27821234567 — detail mode (same shape for ?contact_code=C0004182)
  "count": 1,
  "data": [
    { "contact_code": "C0004182",
      "name": "John", "surname": "Smith", "company_name": null,
      "mob_phone": "082 123 4567", "prv_phone": null, "bus_phone": null,
      "email_address": "jsmith@example.co.za", "email_address_2": null,
      // detail only
      "title": "MR",
      "street": "12 Main Road", "street_2": null,
      "city": "Nelspruit", "state": "Mpumalanga",
      "pcode": "1200", "country": "South Africa",
      "postal_street_1": "PO Box 44", "postal_street_2": null,
      "postal_city": "Nelspruit", "postal_state": null,
      "postal_pcode": "1200", "postal_country": null,
      "privacy_service": "Y", "privacy_marketing": "N",
      "privacy_3rd_party": "N", "privacy_other": null,
      "consent_date": "2025-03-02 09:14:00", "consent_expiry_date": null,
      "last_modified_date": "2026-08-30 11:02:41",
      "vehicles": [
        { "reg": "CA123456", "make": "TOYOTA",
          "variant": "2.8 GD-6", "vehicle": "TOYOTA 2.8 GD-6",
          // detail only — model is the DMS model CODE
          "model": "HILUXDC", "model_name": "HILUX DOUBLE CAB" }] }],
  "meta": { "total": 1, "returned": 1, "limit": 50, "offset": 0,
    "next_offset": null, "has_more": false,
    "q": null, "tokens": [], "match": "prefix",
    "mode": "detail", "mobile_last9": "821234567", "contact_codes": null } }

Paginated repair-order list. ?ro_number= returns a single RO with vehicle, parts, labour and consumable/misc lines plus combined totals.

?progress_statuses=1 is the board columns on their own. Every CODTYP WC code — the domain of WKROFILE.RO_PROGRESS_STATUS — with the DMS's own description, display colours, class, sequence and read-only flag, ordered by Sequence_No, code as tiebreak, unsequenced stages last. That is everything an app needs to draw a job board; Service Bookings ?stages=1 adds how many open ROs are sitting on each, and a POST there moves a job between them. The row comes back via SELECT c.* for the same reason the RO header does — the CODTYP layout is not curated here, naming the colour columns would 500 on an install that spells one differently, and raw carries the untouched record. The colours are passed through unchanged: this API does not know their encoding, and a Windows colour integer is BGR, not the RGB hex a browser wants — look at what your install returns before feeding them to CSS.

{ "data": { "RO_NUMBER": 10234, "reg": "CA123456",
    "vehicle": { "make": "Ford", "model": "Ranger" },
    "parts_items": { "parts_items_total": { "qty": 6, "sale_value": 2240.00 } },
    "labour_items": { "labour_items_total": { "hrs": 2.5, "labour_sale": 1875.00 } },
    "misc_items": { "misc_items_total": { "value": 120.00 } },
    "ro_totals": { "parts_sale": 2240.00, "labour_sale": 1875.00, "total_sale": 4235.00 } } }

Maintains the stage list itself — rename a stage, recolour its badge, reorder the picker, add one. The settings panel behind the board, where Service Bookings' POST moves a job between stages and this one changes what the stages are. It writes codtyp WHERE type = 'WC' and nothing else — every statement carries that TYPE and it is not a parameter, because CODTYP is the whole DMS's code table and TC (technician teams) and FC (franchises) live in it too. ?update_progress_status=1 is required on the POST: it is the mode gate, so this file's repair-order half can never be reached by a write.

Absent means leave it, null means clear it. Every field but code is independently omittable — which is the point of not making this a send-me-the-whole-row call, since an app that has to resend colour_bg in order to change a name will eventually resend a stale one. create: true is required to insert: an unknown code without it is a 404, because the common mistake is a typo in an existing code and an endpoint that helpfully creates CWW beside CW turns that typo into a permanent row nobody can trace. create: true on a code that exists is a 409. if_current_description is the optimistic lock — same mechanism as if_current_status on the stage move, and refused with 409 plus the current row when somebody renamed the stage on a DMS terminal in the meantime.

A reorder is one request or none. Dragging one row in a list of a dozen renumbers most of them, and a half-applied reorder is a picker in an order nobody chose — which looks like a working list rather than a failed write. So sequence as an array is the batch form and it runs in one transaction, the way the attendance write handles a batch of days, reporting transactional: false rather than pretending if the driver will not release autocommit. Every code in it must exist: an unknown one is a 404 and nothing is written, because a reorder that quietly skipped one would leave the list in an order the caller did not ask for and report success. A sequence array and single-stage fields in one body is a 400 — two requests in one envelope.

{ "code": "CW",
  "description": "Customer Waiting",
  "colour_bg": "F4A261",
  "if_current_description": "Cust. Waiting" }
// short_description, colour_text and sequence are absent, so they are untouched.
// send "colour_text": null to CLEAR one.

{ "sequence": [
    { "code": "BI",  "sequence": 10 },
    { "code": "CW",  "sequence": 30 },
    { "code": "CO",  "sequence": 90 } ] }
// all of it or none of it. Nothing else may ride along in this body.

{ "changed": true, "created": false, "rows_affected": 1,
  // field for field what ?progress_statuses=1 returns for this row — it IS
  // that function, so the two cannot drift into two shapes for one thing
  "status": { "code": "CW", "description": "Customer Waiting",
    "short_description": "Cust Wait", "colour_bg": "F4A261",
    "colour_text": null, "code_class": null,
    "sequence_no": 30, "read_only": false,
    "type": "WC", "raw": { /* the untouched DMS record */ } },
  "meta": { "measured": false } }

// already exactly that — nothing written, and not an error
{ "changed": false, "status": { /* … */ } }

Creates a job card — three tables in one transaction, on this same file rather than an endpoint of its own: workshop.php is the repair-order feed, and the last five writes in this API all went on the file that owned the read. One URL family for repair orders beats a second filename to learn. It writes WkRoFile (the header: car, customer, slot, advisor), WKOTHSUB (one row per job on the card, with its estimate) and WKRODESC (the description lines under each job, with their values). All three, or none.

If the driver will not release autocommit, this refuses. Every other write in this API degrades gracefully and reports meta.transactional: false; this one does not, and the difference is what is at stake. A non-atomic claim on a counter shared across the whole database is precisely how two branches write the same RO. A create that cannot be atomic should not happen at all.

?probe=1 checks the counter against reality before anybody tries: the syconfig value beside MAX(RO_NUMBER) actually on file, with a verdict. healthy means the counter is ahead. TIGHT means it equals the highest RO, so the next claim lands on an existing one. BEHIND means something has been creating ROs without advancing the counter and every claim from here would collide — the create refuses in that state too, not only the probe. It also reports the LINE_NO verdict. Reads only.

It creates the car and the person when they are missing. A booking form is where a workshop first meets a customer, so refusing an unknown registration would stop the flow dead on most new business. An unknown reg becomes a WkVehFl row from the optional vehicle{} block; a customer who cannot be matched becomes a CONTACT row from the optional customer{} block — matched first on mobile, then email, then exact name, with two matches a 409 carrying the candidates rather than a choice between two humans. Both happen inside the same transaction as the card, so a create that fails leaves no orphan car and no orphan person. Passing driver explicitly skips the matching entirely. The cost, stated once: a typo'd registration now creates a vehicle rather than being refused — one junk row per typo, visible, corrupting nothing downstream. It still creates no invoice, no clocking and no part: a job card is the plan, and everything that happens to it afterwards belongs to the DMS.

WKRODESC.LINE_NO is the one allocator left — NOT NULL, no default, and nothing in this API had ever written one. It is per (branch, ro, job_code, type) and this creates a new RO, so there is never anything to append to: lines are numbered from the first, in body order. Whether the first is 0 or 1 is inferred from the minimum LINE_NO of existing job groups and refused when the evidence is thin or contradictory — the same treatment, for the same reason, that Technician Attendance gives its own LINE_NO. ?line_no_basis=zero|one settles it.

{ "branch": "M0101", "reg": "ABC123GP", "driver": "40118",
  "req_datetime": "2026-09-11 07:30:00",
  "odometer": 148230, "salesman": "1042",
  "customer_note": "Rattle from front left over bumps",
  "external_source": "ServiceConnect",
  "external_source_id": "bk_9f3a21",
  "jobs": [
    { "job_code": "SERVICE", "job_type": "R",
      "description": "60 000 km major service",
      "est_hours": 2.5, "est_labour": 2375.00,
      "lines": [
        { "detail": "Replace oil and filter", "value": 890.00 },
        { "detail": "Investigate front-left rattle", "value": 0.00 } ] } ] }
// expected_datetime follows req_datetime when only one is sent — half this API
// dates a booking by one column and half by the other.

{ "status": "ok", "created": true,
  "branch": "M0101", "ro_number": 10234,
  "jobs": [ { "job_code": "SERVICE", "job_type": "R",
             "job_type_label": "Retail",
             "lines": [ { "line_no": 1, "detail": "Replace oil and filter", "value": 890 },
                        { "line_no": 2, "detail": "Investigate front-left rattle", "value": 0 } ] } ],
  "lines": 2,
  // a RETRY of the same booking answers 200 with created:false instead, and
  // writes nothing: { "status":"ok", "created":false, "duplicate":true,
  //   "ro_number":10234, "existing":{…}, "message":"A job card was already…" }
  // the reg the card was FILED under, normalised — plus reg_sent when it differs
  "reg": "KZP418MP", "reg_sent": "KZP 418 MP", "reg_filed": "KZP418MP",
  // what this call brought into existence besides the card. {} when the car
  // and the person were both already on file, which is the ordinary case.
  // ALWAYS present: supplied | matched | created | none — also_created only
  // says what was WRITTEN, so a matched customer and no customer look alike
  "customer": { "contact_code": "THABOMASIL41822", "basis": "created" },
  // vehicle_driver_filled appears instead when the car was already on file with
  // a null DRIVER and this card supplied one
  "also_created": { "vehicle": { "reg": "KZP418MP", "driver": "THABOMASIL41822", "created": true },
                    "customer": { "contact_code": "THABOMASIL41822",
                                   "name": "THABO MASILELA", "created": true } },
  // what was taken, and what the next caller will get
  "counter": { "claimed": 10234, "next": 10235, "sys_key": "Next RO Number" },
  "meta": { "transactional": true, "measured": false,
            "line_no_basis": { "basis": "one",
              "evidence": "all 400 sampled job groups start at LINE_NO 1" },
            // the full booking row is not echoed: it is 120 lines of projection
            // living in service_bookings.php, and a second copy would drift
            "note": "Read it back with service_bookings.php?ro_number=10234" } }

Every attribute on a repair order — the read half of Set an RO Attribute. Without it that write is a hole you can put a note into and never get back, which is what shipped first and should not have. No write key; this is an ordinary read.

Two shapes, one mode. ?ro_number= is one card — the detail screen. ?ro_numbers= is a comma list, which is how a board asks: a list showing twenty jobs wants to know which of them carry a note, and twenty calls to find out is how a screen becomes slow in a way nobody attributes to this endpoint. Capped at 200, because the point is the page you are showing rather than the workshop. Repeated numbers are collapsed, so a lazily-built list costs nothing extra.

Not paginated, deliberately. The population is bounded by the ROs you named, and a page marker on a result of four rows is a page marker nobody reads. If one RO ever carries enough attributes to need paging, that is a finding worth reporting rather than a limit to raise.

{ "meta": {
    "branch": "M0101", "ro_numbers": [ 10234, 10235 ], "count": 2,
    // every RO asked about, so "none" and "not asked" cannot look alike
    "per_ro": [ { "ro_number": 10234, "attributes": 2 },
                 { "ro_number": 10235, "attributes": 0 } ],
    "constrained_types": [ "note" ] },
  "data": [
    { "id": 41, "ro_number": 10234,
      "attr_type": "note", "seq_no": 1,
      "attr_code": "technician", "child_code": null,
      "attr_value": "Rear pads glazed, recommend discs at next service.",
      "source": "ServiceConnect Tech",
      "created_by": "pcoetzer", "created_at": "2026-09-06 08:14:00",
      "updated_by": "pcoetzer", "updated_at": "2026-09-06 08:14:00" } ] }

Writes one attribute against one existing repair order on wkRoFileAttribute — the RO-grain sibling of the WKMECHWKAttribute table that Service Bookings writes for technician allocation. It is where a fact belongs when the DMS has a repair order but no column for the thing you want to record against it. The first such fact is a note on a job card, which the workshop app has needed and had nowhere to put.

Four gestures, decided by seq_no and attr_value: no seq_no with a value appends at the next ordinal · a seq_no with a value rewrites that row · a seq_no with attr_value: null deletes it · no seq_no with null is a 400, because a card may carry nine notes and guessing which to delete is not an option. Writing values a row already holds is not a write: nothing moves and the action comes back unchanged, so a re-render cannot churn every consumer that syncs on updDt. Every field you can change is compared, not just the text — promoting a note from technician to alert is a real change.

Over-length values are refused, not truncated. attrType, attrCode and the operator are CHAR(15), childCode is VARCHAR(100), attrValue is VARCHAR(8192) and no type caps below it today. A key cut short at fifteen characters is a row the caller that wrote it will never find again — so the response names the field and the limit rather than letting the column decide.

// an append — no seq_no was sent, so one was allocated and returned
{ "action": "appended", "written": true, "affected": 1,
  "row": { "branch": "M0101", "ro_number": 10234, "attr_type": "note",
           // the handle. Keep it — every later edit or delete needs it
           "seq_no": 2,
           "attr_code": "technician", "child_code": null },
  "before": null, "after": "Rear pads glazed, recommend discs at next service.",
  "operator": "pcoetzer", "source": "ServiceConnect Tech",
  "transactional": true }

// a delete — seq_no named the row, before carries what it held
{ "action": "deleted", "written": true, "affected": 1,
  "before": "Rear pads glazed…", "after": null, /* … */ }

// nothing you sent differs from the row — no stamp moved, and not an error
{ "action": "unchanged", "written": false, "affected": 0, /* … */ }

Open repair orders with a live value rollup and derived category. The summary block feeds the WIP widgets (value tile, category donut, age-band bar); the data array is the WIP list, filterable and paginated. Every filter is optional; category is validated against the known set, and comma lists are accepted for branch / branch_exclude / franchise / category. The core is job-line grain (branch·ro·job_code·job_type); group_by=ro (default) rolls it up to one row per RO for the widgets, group_by=job returns the raw lines. Since 2026-08-21 ?risk_rollup=1 returns the Workshop Risk tab's two SALES clocking exceptions and nothing else — {meta:{thresholds,grain}, lines:[…]} carrying only the (technician × snapshot document) rows that trip a rule, each tagged rule_hours / rule_nocost. (1) ABS(invoice_hrs) > 500 — a mis-allocation between two technicians on one invoice. The NET is correct and that is the point: doc 2931434 books +8 195.37h against another technician's −8 157.05h, netting +38.32h, so the invoice, the RO and every total read right and nothing else flags it — but technicians are paid on hours sold, so the split is what moves money. The threshold is measured at DOCUMENT grain (p99 65h; largest genuine jobs 110/142/172h; then nothing until 8 157h), not the WIP side's 100h, which is per clocking LINE and would flag those three real rebuilds. (2) cost_val = 0 against sell_val > 0 — a technician with no cost rate: 4 technicians and R2 028 909 over six months on one dealer, R2 015 197 of it a single technician present in every month. It matters MORE since the zero-cost ruling, not less: these rows used to return gross_profit:null and the card printed "cost n/a", which warned the reader by itself. Period-scoped like every Sales card, and both thresholds are absolute and per document so a wider window cannot accumulate a false positive. The RO rollup no longer truncates its money columns. All nine used to be wrapped in floor(), which produced two roundings that could not agree: sum(floor(component)) <= floor(sum(components)), so the four component columns summed to R519 of sales and R765 of cost LESS than the total_sales on the same row — and ?group_by=job_type, which does not truncate, read ~R1 400 above it. Flooring per job line instead cannot fix that: floor-per-line and floor-per-RO are different numbers, so the two grains agree only if neither truncates. Every money column now carries the raw numeric(12,2), the components add to the total by construction, and the job-type aggregate ties to the RO rollup. Cents reach the wire; no card shows them (everything goes through pfmt() at R-thousand or R-million precision). Since 2026-08-21 total_sales on the RO rollup CARRIES THE RO CHARGES. They were added to other_sales and then left out of the total, so that column never equalled the sum of the four component columns the same row reports — measured live, lab + sub + other + part = 95 862 243 against a total_sales of 95 712 600, short by the R149 643 of charges. Nothing flagged it because both figures come off the same row and no card added the components up: Pulse's Revenue Composition draws its slices from the components and its donut centre from total_sales, so its legend has always summed to more than its middle. Charges are real revenue on the RO, so they belong in the total. This raises the WIP total and GP on every card that sums total_sales — +0.16% on the dealer measured. Since 2026-08-21 group_by=job_type aggregates the job lines in SQL to one row per job type × category — the Job Type Composition widget's feed. Two faults in the job-line projection were fixed the same day, and anything that summed that grain before was wrong: it left labour + sublet inside other_sales (the WKRODESC value carries both, and only the RO rollup netted them back out) and added the RO charges to every line rather than once per RO. Summing job lines read R116.9M against the trusted R95.8M on 4 149 open ROs — +22%, of which R21.0M was the double-count and R0.2M the charges. Nothing consumed that grain at the time, so it never showed. Charges are now allocated pro-rata on each line's own sales (equal split where an RO's lines are all zero-valued), so the shares sum to one and the job grain ties to the RO rollup exactly; the per-RO denominator comes from a SUM() OVER (PARTITION BY branch, ro_number) rather than a second pass over the component union. job_code / job_type slice the lines before the rollup (RO value = matching lines only); ?job_facets=1 returns their distinct value lists for the picker. mechanic_code works differently on purpose: technician lives one grain below the RO (on the labour lines, and an RO usually has several), so it is an EXISTS that selects whole ROs — "the ROs this technician has labour on" — and leaves their value alone. Parts, sublet and RO charges cannot be attributed to a technician, so slicing the value would hand back a partial total that read exactly like a real one. Since 2026-08-20 the RO rollup also carries confirmed_status — the RO header's confirmation flag, for the Workshop Risk tab's unconfirmed-WIP finding. It is bound by catalog probe, not by name: SYSCOLUMN is read once per request and the first existing candidate wins (confirmed_status / confirm_status / confirmed_ind / confirmed / booking_confirmed), emitting null when none does, because this column sits in the one query every WIP widget waits on and a wrong name would 500 the whole tab rather than empty one card. meta.confirmed_col reports which column it bound, or null — so a caller can tell an unflagged dealer from an unsupported one. RO grain only (group_by=ro); it is a header attribute and the job-line projection has no grain to carry it at. A second narrow mode, ?risk_rollup=1, returns only the open ROs carrying an invoice that was reversed and never re-raised — work that has quietly come back onto the board with the money already handed back. A reversal returns the RO to WIP (verified live: 12 of 12 flagged were open, while a re-invoiced control was not), and once there nothing distinguishes it from fresh work: its value pads WIP totals and its dates pad job age. The test is per credit note — a credit with no invoice on the same RO dated after it — because an RO can carry several invoices and reversing one of them is exactly as un-re-raised whether or not the others stand. Measured 2026-08-20 over 1 Jun – 20 Aug: 312 credits were replaced by a later invoice, normally within 29 minutes, and 12 were not. Nothing else flags them, which is the whole reason this mode exists.

{ "meta": { "total": 128, "page": 1, "limit": "all", "total_pages": 1 },
  "summary": {
    "ro_count": 128,
    "by_category": { "WIP": 90, "Quote": 20, "No Show": 8, "Future Booking": 10 },
    "totals": { "lab_sales": 184200, "sub_sales": 42100, "other_sales": 9800,
      "part_sales": 211500, "total_sales": 447600, "total_cost": 310400, "gross_profit": 137200 },
    "age_bands": { "0_7": 61, "8_30": 40, "31_60": 15, "61_90": 7, "90_plus": 5 } },
  "data": [{ "branch": "DBN", "branch_name": "DURBAN", "ro_no": 10234,
    "category": "WIP", "service_type": "Shop", "franchise": "TY", "franchise_name": "Toyota",
    "equipment": "FORD RANGER", "reg_no": "CA123456", "ro_status": "In Workshop",
    "sales_advisor": "Jane Doe", "last_tech": "John Smith",
    "total_sales": 4235, "total_cost": 2980, "age_days_datetime_in": 3, "flag": "N" }] }

Per-line labour detail for open ROs. Pass ?ro_number= for a single-RO drill-down, or filter across the whole WIP by branch / franchise / mechanic / work location / job code / job type. The summary.by_mechanic rollup feeds the technician-efficiency widgets; efficiency_pct is booked ÷ worked hours, and the rates are weighted (Σvalue ÷ Σhours). category is the SAME 4-way value as workshop_wip.php (WIP / Quote / No Show / Future Booking), and job_code / job_type are the same friendly labels — so a tab-wide Job Code / Job Type filter matches on both endpoints. Every line also carries the RO header's ro_status and sales_advisor: the RO number is the key both endpoints already share, and WKROFILE is joined here anyway for the open-RO gate, so two lookup joins off it put the board's own Status and Sales Advisor on every labour line — filterable here, and value-identical to workshop_wip.php because the expressions are copied verbatim. This endpoint also owns the technician roster (?tech_facets=1): it is the only WIP feed that carries a technician at all, so every other WIP card's Technician picker is fed from here, and the same pick means "this technician's lines" here but "the ROs those lines sit on" everywhere else. A second narrow mode, ?risk_rollup=1, returns only the clocking lines that cannot be real under three independent rules — an impossible booked figure, a line spanning a whole calendar day, or clocking dated in the future. The Workshop Risk tab needs those findings but must not pull this 4.3 MB feed to get them, and none of them breaks any arithmetic (a corrupt line destroys a technician's efficiency while the tab total survives; 22 whole-day lines add R643 711.86 of WIP value while leaving efficiency untouched), so nothing else flags them.

{ "meta": { "total": 342, "page": 1, "limit": "all", "total_pages": 1 },
  "summary": {
    "line_count": 342, "mechanic_count": 11,
    "totals": { "hours_work": 1284.5, "invoice_hrs": 1102.0,
      "sell_val": 742100.00, "cost_val": 388600.00, "gross_profit": 353500.00,
      "efficiency_pct": 85.79, "sell_rate": 673.41, "cost_rate": 302.53 },
    "by_mechanic": [{ "mechanic_code": "1042", "mech_name": "John Smith",
      "lines": 48, "hours_work": 168.0, "invoice_hrs": 152.5,
      "sell_val": 102400.00, "cost_val": 50800.00, "gross_profit": 51600.00,
      "efficiency_pct": 90.77, "sell_rate": 671.48, "cost_rate": 302.38 }] },
  "data": [{ "branch": "DBN", "franchise": "TY", "ro_number": 10234, "category": "WIP",
    "job_code": "Service", "job_type": "Retail", "work_cat": "1", "mechanic_code": "1042",
    "work_location": "Shop", "mech_name": "John Smith", "seq": 1,
    "hours_work": 3.5, "job_code_hrs": 3.0, "invoice_hrs": 3.0,
    "sell_val": 2010.00, "cost_val": 1058.75,
    "sell_rate": 670.00, "cost_rate": 302.50, "eff_perc": 85.71 }] }

Per-line sublet detail for open ROs. Pass ?ro_number= for a single-RO drill-down, or filter across the whole WIP by branch / franchise / vendor / service type / PO status / job code / job type. The summary.by_vendor rollup feeds the sublet widgets; margin_perc is gross profit ÷ sell value, and comma lists are accepted for branch / franchise / vendor_no / category. category is the SAME 4-way value as workshop_wip.php (WIP / Quote / No Show / Future Booking), and job_code / job_type are the same friendly labels — so a tab-wide Job Code / Job Type filter matches on both endpoints. (job_type replaces the old raw ro_type column.) Every line also carries the RO header's ro_status and sales_advisor, resolved through the RO number the two endpoints share (see WIP Labour Detail). Note sales_advisor is the RO advisor and is not po_creater, who is whoever raised the sublet purchase order — different people, different source. mechanic_code is the tab-wide Technician filter: a sublet line has no technician of its own, so it resolves by EXISTS over the RO's labour lines — "the sublet sitting on the ROs this technician is working".

{ "meta": { "total": 86, "page": 1, "limit": "all", "total_pages": 1 },
  "summary": {
    "line_count": 86, "vendor_count": 14,
    "totals": { "sublet_val": 142800.00, "sublet_cost": 101450.00,
      "gross_profit": 41350.00, "margin_pct": 28.96 },
    "by_vendor": [{ "vendor_no": "A0012", "vendor_name": "ACME EXHAUST CO",
      "lines": 12, "sublet_val": 31200.00, "sublet_cost": 22100.00,
      "gross_profit": 9100.00, "margin_pct": 29.17 }] },
  "data": [{ "branch": "DBN", "franchise": "TY", "ro_number": 10234,
    "category": "WIP", "job_code": "Sublet", "job_type": "Retail", "service_type": "Shop",
    "purchase_no": 50021, "purchase_desc": "EXHAUST REPAIR", "purchase_status": "Open",
    "vendor_no": "A0012", "vendor_name": "ACME EXHAUST CO",
    "vend_invoice_no": "INV-88231", "vend_invoice_date": "2026-07-14",
    "sublet_val": 2600.00, "sublet_cost": 1840.00,
    "gross_profit": 760.00, "margin_perc": 29.23 }] }

?group=1 → the compact branch × franchise rollup (drives the widget's rollup levels + KPIs). ?risk_rollup=1 → the Workshop Risk tab feed: the three backorder exceptions as counts + values + contributing-group tables for both drill directions, the two fences and their populations, and a worst-10 context list per fenced rule — all aggregated off the same #bo temp, with ?risk_lines=aging|over|novendor serving its drill leaf from the detail mode. ?parts_like=<q> → distinct part_no/part_desc matching a prefix (feeds the Part filter's type-to-search). ?part_franchises=1 → distinct part_franchise (+ name) for the Part-Franchise picker. ?cat_counts=1 → distinct RO count per category ({counts,total}) for the Options scope badges. ?category= filters any mode to WIP/Quote/No Show/Future Booking (also emitted on the rollup). ?order_state= filters to on_order/to_order/over — per line, the outstanding requirement (order_qty − supplied_qty) vs the raw po_qty; also a rollup grouping dimension carrying over_value. ?no_vendor=1 isolates at-risk lines — no default vendor (insalpar.PO_DEFAULT_VENDOR null) and still short of a PO — also a rollup dimension. Otherwise → per-line detail (drill-scoped). Filters (branch/franchise/part_franchise/ro_type/part_no/job_age/mechanic_code) apply server-side to every mode — mechanic_code being the tab-wide Technician filter, which a part line cannot carry and so resolves by EXISTS over the RO's labour lines ("which of this technician's jobs are stuck waiting for parts"); to_order_qty = committed − on-PO and to_order_value = that qty × unit_cost. The rollup also carries a per-cell risk_rule (aging/over/novendor/'') and echoes the two Tukey thresholds in meta.risk_thresholds, so the Pulse widget lights Risk flames straight off the rollup (no second line-level fetch). The fences are computed here in PHP — a byte-for-byte port of the Workshop Risk tab's tukeyFence (floors 7d / R2000) over the header scope (risk_branch/risk_franchise) — so a flame always maps to a real Risk exception. The core is materialised once into a #bo temp table shared by the rollup + both fence scans; the drill leaf re-uses the echoed thresholds (age_thr/over_thr) to flag its own lines.

// ?group=1 — branch × franchise rollup (the widget's main view)
{ "meta": { "mode": "rollup", "cells": 257,
    // Tukey thresholds (header scope) — echoed to the drill leaf as ?age_thr / ?over_thr
    "risk_thresholds": { "aging": 34, "over": 4200.00 } },
  "rollup": [{ "branch": "DBN", "franchise": "TY", "part_franchise": "TY", "part_franchise_name": "Toyota",
    "lines": 28, "ro_count": 12, "part_count": 24, "po_value": 9100.00, "to_order_value": 5010.00,
    // per-cell Risk-flame rule (folded to a branch/franchise flame client-side); '' = none
    "risk_rule": "aging" }] }

// ?risk_rollup=1 — the Workshop Risk tab feed (replaces the old whole-board ?limit=0 pull)
{ "meta": { "mode": "risk_rollup", "cells": 188,
    "risk_thresholds": { "aging": 34, "over": 4200.00 },
    // fence POPULATIONS (all committed lines in that state, pre-threshold) — the cards quote these
    "populations": { "unordered": 9142, "over": 2210 } },
  // one block per rule; the three are INDEPENDENT (a line can appear in aging AND novendor)
  "rules": { "aging": { "count": 412, "value": 1840233.55,
      // branch groups come back name = code (branch names live in gauge.branches, not the DMS)
      "groups_branch": [{ "name": "DBN", "sub": "DBN", "n": 88, "val": 402118.20, "pct": 21.8 }],
      "groups_franchise": [{ "name": "Toyota", "sub": "TY", "n": 140, "val": 655900.10, "pct": 35.6 }],
      "branches": ["DBN", "JHB"] },
    "over": { "count": 51, "value": 288400.00, "groups_branch": [], "groups_franchise": [], "branches": [] },
    "novendor": { "count": 96, "value": 140120.75, "groups_branch": [], "groups_franchise": [], "branches": [] } },
  // worst 10 lines per fenced rule — shown as context when that rule has NO outlier
  "fallback": { "aging": [{ "branch": "DBN", "part_no": "90915-YZZD2", "ro_number": 344843,
      "sales_order_days": 211, "to_order_value": 1820.40, "over_value": 0, "no_vendor": 1 }],
    "over": [] } }

// ?risk_lines=aging&age_thr=34&branch_include=DBN&limit=0 — that group's flagged lines (the Risk leaf)
{ "meta": { "total": 88 }, "data": [{ "part_no": "90915-YZZD2", "risk_rule": "aging", "…": "…" }] }

// per-line detail (no group; the widget requests this drill-scoped to one branch+franchise)
{ "meta": { "total": 64, "page": 1, "limit": "all", "total_pages": 1 },
  "summary": {
    "line_count": 64, "ro_count": 37, "part_count": 58,
    "totals": { "order_qty": 214.0, "supplied_qty": 150.0, "comm_part_qty": 64.0,
      "po_qty": 41.0, "to_order_qty": 23.0, "po_value": 18420.00, "to_order_value": 10360.00 },
    "by_branch": [{ "branch": "DBN", "lines": 28, "comm_part_qty": 31.0,
      "po_qty": 20.0, "to_order_qty": 11.0, "po_value": 9100.00, "to_order_value": 5010.00 }] },
  "data": [{ "branch": "DBN", "ro_number": 10234, "franchise": "TY",
    "part_franchise": "TY", "part_franchise_name": "Toyota",
    "part_no": "90915-YZZD4", "part_desc": "OIL FILTER", "ro_type": "R", "bin_location": "A-12-3",
    "sales_order_no": 55021, "sales_order_date": "2026-07-10", "sales_order_days": 17,
    "salesperson": "Jane Doe", "order_qty": 4, "supplied_qty": 1, "comm_part_qty": 3,
    "po_qty": 2, "to_order_qty": 1, "unit_cost": 112.40,
    "po_value": 224.80, "to_order_value": 112.40,
    "datetime_in": "2026-07-10 08:15", "age_days_datetime_in": 17 }] }

Server-side aggregate — the payload is bounded by the bucket count, never by the invoice count. bucket chooses the time grain (day · week · month · year, where week is the week WITHIN the month, 1–5) and group_by the dimension carried alongside it (job = job_code × job_type, the default; or branch / franchise / advisor / none). Every row carries labour_sales / parts_sales / other_sales / sublet_sales + total_sales, and — for the labour element — invoice_hrs, hours_work, labour_cost and labour_gp. Gross profit is COMPLETE: labour_cost from ZA_WKMECHWK clocking, parts_cost and sublet_cost from INVOICE (parts_cost_val / sublet_cost_val, document+RO grain, split across job lines by each element own sale), and other_cost a hard 0 since Other has no cost of sales. So labour_gp / parts_gp / sublet_gp / other_gp and — for the first time — total_gp. Plus the three document counts ro_count / invoice_count / credit_note_count. job_code / job_type are the SAME friendly labels as workshop_wip.php, so a tab-wide Job Code / Job Type filter matches on both.

{ "meta": { "total": 54, "page": 1, "limit": "all", "total_pages": 1,
    "bucket": "month", "group_by": "job",
    "date_from": "2026-01-01", "date_to": "2026-08-07", "credits": "included" },
  "summary": {
    "row_count": 54, "document_count": 3184,
    "totals": { "labour_sales": 4820150.00, "parts_sales": 3110480.00,
      "other_sales": 204300.00, "sublet_sales": 388920.00,
      "total_sales": 8523850.00, "invoice_hrs": 28714.5000, "hours_work": 30188.2500,
      // window-level, from their own un-grouped query — ro_count does NOT sum across buckets; an RO here is (branch, ro_number)
      "ro_count": 3021, "invoice_count": 3102, "credit_note_count": 82 },
    "by_period": [{ "period_key": "2026-01", "period_label": "Jan 2026",
      "total_sales": 1042300.00, "invoice_hrs": 3512.7500 }],
    "by_credit_flag": {
      "I": { "doc_count": 3102, "invoice_value": 8801420.00 },
      "C": { "doc_count": 82, "invoice_value": -277570.00 } },
    "reconciliation": { "wkinvreg_total": 8523850.00,
      "allocated_total": 8498120.00, "unallocated_total": 25730.00,
      "ties_to_wkinvreg": true } },
  "data": [{ "period_key": "2026-01", "period_label": "Jan 2026",
    "year": 2026, "month": 1, "day": null, "week_of_month": null,
    "job_code": "Service", "job_type": "Retail",
    "labour_sales": 312400.00, "parts_sales": 198220.00,
    "other_sales": 12100.00, "sublet_sales": 21450.00,
    "total_sales": 544170.00,
    "invoice_hrs": 1842.5000, "hours_work": 1930.7500,
    // labour_cost = ZA_WKMECHWK.cost_val; labour_gp = labour_sales - labour_cost. Both null/0 under ?hours=0
    "labour_cost": 96420.00, "labour_gp": 215980.00,
    // Other has NO cost of sales, so other_cost is always 0 and other_gp always == other_sales. NOT gated by ?hours=0
    "other_cost": 0.00, "other_gp": 12100.00,
    // sublet_cost = PURCHASE_CONTROL.order_value; sublet_gp = sublet_sales - sublet_cost. Both null/0 under ?sublet=0
        "parts_cost": 158420.00, "parts_gp": 39800.00,
    "sublet_cost": 18230.00, "sublet_gp": 3220.00, "total_gp": 271100.00,
    "doc_count": 418,
    // null here because group_by=job is LINE grain — see the note above
    "ro_count": null, "invoice_count": null, "credit_note_count": null,
    "allocated": true }] }

Open means not yet invoiced — the same set the WIP board shows. Default window is today → today + 30 days on the booking slot; date_from and date_to are independent, so setting one leaves the other open-ended. Bookings that close between polls come back with is_open: "N" so you can clear them your side.

?awaiting_collection=1 turns that around. It asks the one question an open board cannot: which job cards are invoiced and have still not been stamped picked up — the cars the workshop is finished with, has billed, and which are nonetheless occupying a bay. It lifts the open gate itself and reaches backward rather than forward, because every uncollected vehicle was booked in the past; the parameter row below says why both of those are not something to arrange by hand. Its general form is ?progress_status_exclude=, which works in every read mode here.

Worth knowing. customer_id is the person, stable across repair orders — use it, not the name, to match a customer. customer_mobile is the mobile number only and is never filled in from a landline, so it is safe to send to; other numbers arrive separately as customer_phone_alt. ro_stage ("Awaiting Parts", "Washing"…) is the one to show on a board — ro_status is a raw single-letter code. The privacy_* flags are on every row; ?consent= filters by them. Run ?schema=1 once to see which optional columns (ETA, odometer reading, customer request) exist on your install.