Skip to content

Void Post Inspection Form

Live dependencies & version history: see the auto-generated catalog page — its Dependencies & Related section lists the sub-forms, sub-tasks and workflows that use this form, refreshed on every dev pull.

The Void Post Inspection form is the void handover / post-inspection checklist, run by voids officers after works are complete. It is order-driven: launched from a QL order with an Order Appointment diary configuration (60 min), not selected from Property Search.

Ticket 22387 (Jo Blackburn, owner Andy Tyler) asked for a "new" digital void post-inspection checklist. Peter and Mark were right that one already existed — the work was an extension of a stale form, not a new build. The form already carried the QL order launch, the diary appointment, the PostInspection / CompleteOrder QL write-back, the EDRMS DocEx handler (VoidPostInsp) and the Transaction_Task_VoidPostInspection* warehouse tables. The fact it is order-driven also settled Jo's own open question about whether to launch it from Property Search.

⚠ Three records share this name — check the id, not the version number

Version numbers are not comparable across environments, and the highest number is not the newest content. Confirm the record id per environment before doing anything:

Env Record id Version Items Note
Dev bfc2b5bc-f079-ec11-8df1-000d3ad48fe9 v9 (active + latest) 548 at v3 The newest content — v3 modified 30/04/2026 by WrighM
Test cbea7488-dfbe-eb11-8de9-000d3ad48fe9 v28 536 2022 content despite the high number
Live 01c8873c-… v18 536 2022 content

The on-disk Void+Post+Inspection_28.form is the Test lineage — not Dev. This is the extracted/ filename collision trap. The pristine Dev baseline is Void+Post+Inspection_3.form (md5 8f590992…, verified byte-identical to a fresh single-form Dev download).

All three are structurally the same form — the same five branches plus the Inspection Hub and the Meter_* / Misc_* item families — so a design validated against one holds for the others.

Version history (Dev record bfc2b5bc…)

Version Date Summary
v0–v2 — Original build (Lewisr)
v3 30/04/2026 Baseline before ticket 22387 — 548 items (WrighM)
v4–v6 29/07/2026 ⚠ Corrupt drafts from hand-authored package metadata — inert, see below
v7 29/07/2026 Recovery — MS-exported v3 re-imported; content == v3
v8–v9 29/07/2026 Ticket 22387 — Lettable Standard branch. v9 active

What v9 added — the Lettable Standard branch

A sixth branch off the Inspection Hub, plus its Hub button. 70 new items; all existing branches untouched.

  • 22 × LS_QNN Yes/No/N-A questions, each with an LS_QNNComments box gated on answer ≠ Yes
  • 19 × LS_QNNPhoto
  • LS_KeysSupplied, LS_FobsSupplied, LS_FobsPhoto, LS_ItemsToFit
  • Meter_ElectricLocation, Meter_GasLocation, Meter_ElectricDebt

Visibility gates use Conditions, not JS Expressions, so the ~178-character expression truncation cannot bite.

Scripts: versaa-rag/transform_void_post_insp_lettable_standard.py → versaa-rag/build_void_post_insp_package.py. Build artefacts live in versaa-rag/staging/void_post_insp/ — deliberately not in extracted/forms/Forms/, which convert_exports.py globs and would turn a build artefact into a catalog page.

The transform mints formula/element ids with uuid.uuid4(), so its output is not byte-reproducible. Void+Post+Inspection_ls.form in the staging folder is the exact artefact that became Dev v9 — keep it.

⚠ Two packaging hazards specific to this form

1. The catalog page reports the wrong version. wiki/catalog/forms/Void_Post_Inspection.md shows current_version: "28" even immediately after a clean Dev pull. The catalog picks the highest _N filename, and _28 is the Test lineage (cbea7488…). Dev is on v9 (_9.form, bfc2b5bc…). Read the version from Management Studio or from the id= on line 1 of the .form — not from this form's catalog page.

2. The package entry name collides with the pristine baseline. The LS package is cloned from VPI-v3.ftpackage, whose .rels Target is Forms/Void+Post+Inspection_3.form, so the built package carries that entry name too — and the watcher extracts it straight over extracted/forms/Forms/Void+Post+Inspection_3.form, the pristine Dev v3 baseline the transform reads as input. It has not bitten since v9 shipped (the baseline currently verifies at md5 8f590992ce4ce212639501a14039fdda), but a --force reprocess would clobber it with LS content and a re-run of the transform would then double-apply the branch.

A recovery copy is kept at versaa-rag/staging/void_post_insp/Void+Post+Inspection_3_BASELINE.form (same md5). Verify the baseline hash before re-running the transform. Renaming the package entry is not the fix — the .rels Target would have to change with it, and hand-editing package metadata is what produced the corrupt v4–v6 in the first place.

Completion chain (verified)

Void Post Inspection.OrderApptComp → Order Appointment Completion, which fans out:

Message Goes to
.UpdateHMSData Void Post Inspection QL Update (PostInspection + CompleteOrder)
.GenerateMRDocument Void Insp Meter Readings
.GenerateDocument Generic Generate Document
.ExportToSharePoint DocEx handler, docType VoidPostInsp
.SaveToDataWarehouse Transaction_Task_VoidPostInspection*

The completion email needs no new workflow. Generic Generate Document (15 steps) already renders, saves and emails with the attachment, gated on Form_EmailRecipient / Form_DocumentEmailAttachmentName; Form_EmailFrom defaults to $ENV_DefaultEmailFrom$ and the form already has Form_DocumentTemplateName. So the email is a form-items-only change. (Void Pre Insp Prop Email is a different, property-changed email — don't confuse the two.)

Gaps still open

  1. §2's 24 Yes/No/N/A questions — addressed by the Lettable Standard branch (22 of them). The pre-existing Misc_* partial equivalents were left alone on purpose: the Word template and the warehouse tables bind to them.
  2. Form_Email* items — coded but not emitted; pass --email-recipient <mailbox> once Jo confirms the planning-team mailbox. Deferred so both changes land in one import (MS burns a version per import).
  3. QLpost_ contact block — not yet built. Copy the QLcrm_ block from _Data Items and leave all *_Use … Client No = Yes.
  4. Form_OperativeName / Form_InspectionDate exist but are not displayed.
  5. Word template bindings (~24 + 20) — manual, via the Connector field picker; binding GUIDs are server-allocated and cannot be scripted. Fallback is one repeating LS_Photos group.

⚠ QL side is not ready

The requirement doc's embedded image is a QL CRM classification grid (EMPTYHOMES/POSTINSPEC/{PASSED,FAIL}/{CLEAN,REPAIRS,WITH WORK}/{CLEAN}) — i.e. a contact classification. Separately, Aareon.QL-x.PostInspResults actually holds only TEST / ERROR / SATISFACTO / UNSATISFAC / INCOMPLETE — Jo's five outcomes are not in it.

Every Action Code in that classification grid is BLANK. Per gotchas that is the RT0016 silent-fail pattern: contacts arrive, nothing fires, no error is raised. Flag to Peter — classification config is not environment-synced.

Open questions for Jo

Planning-team mailbox; whether photos are mandatory; keys/fobs as numeric counts; whether §3 wants photos; and whether her five outcomes become new QL POSINS_RES codes or map onto the existing three. Drafts: scratch/halo_tickets/ticket_22387_jo_questions.md, ticket_22387_peter_ql_asks.md.