Service functional design
Purpose and boundary
The Service module models a service definition and the events performed for it. It owns service types, dynamic properties, checklists, event places, documents, versioned report definitions, criteria, and results. It integrates with Equipment, Organisation, File, Reporting/export, and Scheduler.
Core model
Service\Entity\Service is the master record. It has a service type, configurable property values, checklist entries, and service events. An event represents a dated occurrence of the work and can carry its place, documents, imported data, and report results.
Report definitions are versioned. Report types contain versions; versions contain ordered criteria. Criteria can be classified by category and type and can themselves have version-specific configuration. This keeps old event results interpretable after a report definition changes.
Workflows
Define service types, property definitions, report categories/types, and event places.
Create a service, complete its properties, and build its checklist.
Create or import events and attach documents.
Enter or import criterion results against the correct report version.
Review results, move them only through the dedicated action, and export services, events, or results as needed.
The planner provides a planning-oriented view of services. Equipment associations expose service history from the equipment detail page.
Implementation structure
Controllers are grouped under Controller/Service, Controller/Service/Event, and Controller/Report. Service and event imports use controller plugins and generated workbook templates. JSON controllers reorder checklists and report criteria. Entities, repositories, services, assertions, view helpers, routes, navigation, and Twig views are registered in the Service module configuration.
Invariants for changes
Never reinterpret stored results by mutating a released report version; create a new version.
Preserve the service → event → document/result relationship during imports and moves.
Validate property values through the shared property-type system.
Keep imports idempotent where stable external identifiers are available and show a preview before destructive replacement.
Update exports and tests whenever report criteria or result columns change.