EquipmentTests & Maintenance

EquipmentTest definitions, performing equipment-tests, due status, certifications, and the dispatch gate.

Overview#

EquipmentTests define reusable safety and maintenance checks — PAT tests, LOLER examinations, service schedules, condition checks — and track when each asset is due, whether it passed, and whether it is safe to dispatch. The engine covers definitions, execution, due computation, certification expiry, auto-repair on failure, and a dispatch enforcement gate.

EquipmentTest admin routes:

Performing an equipment test and reviewing results:

Defining an equipment test#

A definition is an ordered list of typed tasks:

Each definition has a schedule — a time interval, a usage threshold (against a usage metric), or both. When both are set, an asset falls due on whichever comes first. Definitions can be assigned to catalogue items from either the equipment test or the catalogue item; a certifying equipment test also carries a validity period used for certification expiry.

Performing an equipment test#

From an asset's asset detail, choose Perform EquipmentTest and complete the task checklist. The outcome is derived automatically:

• All required tasks answered and passing → pass (optional failures are ignored).
• Any required task failing → fail.
• A required task left unanswered → incomplete.

Task answers are snapshotted, so they survive later edits to the definition. Attachments can be added to the result. Each execution creates a new result — there is no in-place amendment.

EquipmentTest certificates#

For a passed result on a certifying equipment test, the result detail page (/equipment-test-results/{equipmentTestResult}) shows Generate Certificate. The action requires documents.create, renders the warehouse's inspection_certificate template, persists a numbered document (CERT-…), and downloads the PDF. Non-certifying equipment-tests and non-passing outcomes hide the button; the same eligibility rules apply on the API generate path.

Due status & certifications#

For every asset × equipment test, the engine computes the next due date from the last pass (or from asset creation if never tested), against time and/or usage. When a usage-scheduled metric has no readings yet, due degrades to time-only and the asset is flagged awaiting first reading. Cached next_inspection_due and inspection_status rollups are kept current on every change, with a daily scanner as a backstop. Certifying equipment-tests feed a next_certification_expiry rollup and a threshold-gated expiring notification. Due, overdue, failed, and expiring notifications are transition-gated so daily scans do not re-spam.

Auto-repair on failure#

A failing equipment test on a definition flagged for auto-repair raises a repair through the shared repair path, linked back to the result. The barcoded conflict policy still applies, and any rejection is audit-logged without blocking the result.

Dispatch enforcement gate#

The dispatch pipeline includes an equipment-test gate that runs after the shortage gate. Per definition, enforcement is none, warn, or prevent, evaluated against the rental's off-hire date — so an asset that will fall due mid-hire is flagged before it leaves. The strictest applicable mode wins.

• Warn — dispatch proceeds only when the operator holds the override permission and records an explicit acknowledgement.
• Prevent — a hard compliance block that the override cannot relax.

The gate applies to single-asset, bulk, quick book-out, and flightcase/kit manifest dispatch, with Inspect Now deep links straight into the perform flow.

Permissions#

API#

See the EquipmentTests API, EquipmentTest Results API, and Usage Readings API.