# Vehicle Repair Center (VRC) — Requirements Coverage Survey & Gap-Closure Plan

> Survey date: 2026-06-27 · Module: `Modules/Vrc` (Vehicle Repair Center) on the `saas-one` UltimatePOS host
> Scope: full automation of a vehicle repair center — front desk → workshop floor → delivery → after-sales,
> benchmarked against the supplied 10-section requirement list and ISO 9001 / 14001 / 45001 / 18541.

---

## 0. How to read this

VRC is **not a monolith**. Functionality is delivered in three layers, and a requirement counts as "covered"
if **any** layer provides it:

| Layer | What it provides | Examples |
|---|---|---|
| **VRC module** (`Modules/Vrc`) | The workshop domain | Repair orders/job cards, estimates, DVI inspections, bays, technicians, insurance, warranty, reminders, service plans, portal |
| **ERP core** (UltimatePOS `app/`,`database/`) | Commercial/financial/inventory backbone | Contacts, products, stock, purchases, invoicing, tax, multi-location, multi-currency, RBAC, media, audit, dashboard, SMS/email |
| **Sibling modules** (`Modules/*`) | Cross-vertical capabilities | AdvancedTransfer (stock transfer w/ approval), PurchaseRequisition (PO approval), WhatsApp, Connector (REST API), AiCore (AI engine), PortalApi (customer portal pattern), LandedCost |

**Status legend:** ✅ Covered today · 🟡 Partial (exists but with a named gap) · ❌ Missing (needs building)

**Headline (original survey):** Of ~50 discrete requirements, **~28 fully covered, ~13 partial, ~9 missing.**
The operational spine (Sections 1–6 and 10) was ~85% covered; gaps clustered in **Section 8 (ISO compliance)**
plus customer-experience and security extras.

> ### ✅ Implementation update — 2026-06-28: **all five phases built**
> A single module-only patch (no core changes) closed essentially all of the partial/missing items below. Added:
> 22 tables + 22 models; **work-center routing + workshop Kanban**; **technician certifications**; **storage bins**;
> **support tickets + escalate-to-NCR**; **CSAT/NPS surveys**; **authenticated phone-OTP owner portal**;
> **ISO 9001** (controlled docs/SOPs, NCR, CAPA); **ISO 14001** (waste streams, disposal log, aspects);
> **ISO 45001** (hazards/risk, incidents, safety training); **ISO 18541 RMI** console (VIN decode + use-case lookups
> behind a pluggable provider contract, offline stub by default); **demand-forecast** report; **step-up TOTP 2FA**;
> **HSN/SAC** on services → lines → estimate & job-card PDFs; and the **check-in body-damage diagram**.
> Remaining true externals: a **licensed RMI provider** (contract ready, stub today), **extra payment gateways**
> (core/Connector + merchant accounts), and **production SMS/WhatsApp OTP delivery** for the owner portal.
> See §3 for the per-item status and §A for the file map.

> ### ✅ Follow-up patch — 2026-06-28b: production hardening + rework KPI
> A second module-only patch turned three stubs into production wiring and added a quality KPI:
> **Owner-portal OTP now delivered** over the business's configured SMS/WhatsApp channel via the ERP
> notification boundary (sends to the registered contact; safe no-op when no gateway is set).
> **RMI now has a config-driven HTTP provider adapter** (`HttpRepairInfoService`) that activates on
> `VRC_RMI_BASE_URL` + `VRC_RMI_API_KEY` and transparently falls back to the offline stub otherwise —
> so going live with TecRMI/HaynesPro/Autodata is just env + a one-line binding (already env-conditional).
> **Test-drive result** captured on the final DVI (performed / pass-fail / odometer / notes) + on the report PDF.
> **Rework / comeback tracking**: a repair order can be flagged a comeback of a prior order with a reason;
> a **rework-rate report** (`reports/rework`) surfaces the KPI, and a flagged comeback can be **escalated to an
> NCR** (source `rework`), feeding the existing ISO 9001 NCR→CAPA loop. 2 migrations (test-drive cols on
> `vrc_inspections`; `is_rework`/`rework_of_id`/`rework_reason`/`rework_ncr_id` on `vrc_repair_orders`). Core
> still byte-identical.

---

## 1. Coverage matrix (against your 10 sections)

### Section 1 — Core System Foundation

| # | Requirement | Status | Where it lives / Note |
|---|---|---|---|
| 1.1 | Multi-branch / multi-location | ✅ | ERP `business_locations`; VRC carries `location_id` on bays, appointments, repair orders, estimates, technicians. Plus the SaaS host runs each tenant on its own DB. |
| 1.2 | Multi-language & RTL/LTR | ✅ | Core i18n + Arabic RTL; VRC ships `Resources/lang/{en,ar}` and `name_ar`/`label_ar` on every catalog table. |
| 1.3 | Multi-currency & tax (HS/HSN/SAC) | 🟡 | Multi-currency ✅ (`currencies`, `business.currency_id`, `transactions.exchange_rate`); tax ✅ (`tax_rates`, tax groups, inclusive/exclusive). **Gap:** no dedicated HSN/SAC code field — only generic `product_custom_field1..4` as a workaround. |
| 1.4 | Role-based access control | ✅ | Spatie roles/permissions + `Admin#<biz>` Gate::before bypass; 26 `vrc.*` permissions; demo roles wired (Admin, Service Advisor, Technician, Parts, Branch Manager, Cashier). |
| 1.5 | Comprehensive dashboard (KPIs, invoices, quotations, reports) | 🟡 | ERP `HomeController` dashboard ✅; VRC has a dashboard (`VrcController@index`) + 8 reports. **Gap:** no consolidated real-time VRC KPI tile board (WIP count, bay load, today's deliveries, estimate-approval queue). |

### Section 2 — Customer & Vehicle Management

| # | Requirement | Status | Where it lives / Note |
|---|---|---|---|
| 2.1 | Customer profiles (contact, history, prefs) | ✅ | ERP `contacts` (+ ledger, customer groups); VRC links via `erp_customer_id`. |
| 2.2 | Vehicle profiles (make/model/year/VIN/plate/history) | ✅ | `vrc_vehicles` (VIN, plate, engine no, color, fuel, transmission, odometer, registration/insurance expiry) + `vehicles/{id}/history`. |
| 2.3 | Vehicle & brand/type management | ✅ | `vrc_vehicle_makes`, `vrc_vehicle_models`, `vehicle_type` field; seeded with 12 makes. |
| 2.4 | Document & image management | ✅ | ERP polymorphic `media` table; VRC stores inspection photos & signatures via `MediaServiceContract`. (Generic doc-attach UI on the vehicle page could be surfaced more explicitly.) |

### Section 3 — Reception & Check-in

| # | Requirement | Status | Where it lives / Note |
|---|---|---|---|
| 3.1 | Vehicle check-in & digital inspection (body images, odometer) | 🟡 | `odometer_in`, `fuel_level_in`, `checked_in_at` ✅; intake DVI with photos ✅. **Gap:** no annotated body-damage diagram (walk-around marker map) at intake. |
| 3.2 | Digital checklists for receiving | ✅ | `vrc_inspection_templates` + items (sections, `status/number/text/photo` inputs); intake-type inspection captures arrival condition. |
| 3.3 | Service quotation (drafts → work order) | ✅ | `vrc_estimates` (draft → sent → approved/declined), PDF, validity date; approve copies lines onto the repair order. |
| 3.4 | Appointment scheduling & service calendar (bays, technicians) | ✅ | `vrc_appointments` + FullCalendar feed; bay assignment with double-book detection; technician assignment; check-in spawns the RO. |
| 3.5 | Job/work order creation | ✅ | `vrc_repair_orders` (customer, vehicle, advisor, bay, concerns, priority, promised_at) + service/part lines. |

### Section 4 — Workshop & Repair Operations

| # | Requirement | Status | Where it lives / Note |
|---|---|---|---|
| 4.1 | Worksheet management (tasks, assignment, est. time per mechanic) | ✅ | `vrc_repair_order_services` = the worksheet: per-line `description`, `labor_hours`, `assigned_technician_id`, line `status` (pending/in_progress/done/skipped). |
| 4.2 | Service & repair tracking (status, cost, timeline) | ✅ | RO state machine + `vrc_repair_order_status_history` audit + timestamps + live totals. |
| 4.3 | Multi-stage workflows (mechanical → paint → QC) | 🟡 | State machine has `in_progress → quality_check → ready_for_pickup` ✅. **Gap:** no explicit work-center/department routing (e.g. Mechanical → Body/Paint → Electrical → QC) with per-stage queues and hand-off sign-off. |
| 4.4 | Digital checklists for delivery (test drive, final QC, cleanliness) + customer e-signature | ✅ | Final-type DVI is **required** to reach `ready_for_pickup`; `customer_signature_path` + `/sign` endpoint capture the handover signature. (Add an explicit "test-drive result" field — minor.) |
| 4.5 | Service history & vehicle timeline | ✅ | `vehicles/{id}/history` + RO `timeline()` (JSON status ladder). |
| 4.6 | Technician management (productivity, assignments, skills/certs) | 🟡 | Technicians + `specialties` (JSON) + labor logs + productivity report ✅. **Gap:** no formal certification/training-record tracking with expiry. |

### Section 5 — Warehouse & Inventory

| # | Requirement | Status | Where it lives / Note |
|---|---|---|---|
| 5.1 | Centralized inventory control | ✅ | ERP `products`/`variations`/`variation_location_details`. |
| 5.2 | Multi-warehouse / location support | 🟡 | Multi-location ✅. **Gap:** only flat `ProductRack`; no bin/zone/shelf hierarchy (workstation mini-stores are locations, not sub-bins). |
| 5.3 | Parts movement & transfer (request/approve/track) | ✅ | **AdvancedTransfer** module: prepare → ship → receive with status — the approval-style transfer workflow. |
| 5.4 | Parts usage & consumption (auto-deduct) | ✅ | RO part lines → `StockServiceContract` → ERP stock movement (`erp_stock_movement_id`). |
| 5.5 | Product categorization (HS/HSN/SAC) | 🟡 | Categories ✅; **HSN/SAC code field ❌** (custom-field workaround only). |
| 5.6 | Stock alerts & reordering | ✅ | `products.alert_quantity` + VRC low-stock & "parts-to-order" screens + **PurchaseRequisition** (request→approve→PO). |
| 5.7 | Supplier & purchase management | ✅ | ERP supplier contacts + purchases/PO + PurchaseRequisition + **LandedCost** distribution. |

### Section 6 — Financial & Invoicing

| # | Requirement | Status | Where it lives / Note |
|---|---|---|---|
| 6.1 | Invoicing & billing (tax, discount, charges) | ✅ | ERP `transactions` + invoice layouts/schemes; VRC `invoice()` generates the ERP sale from the RO; insurance excess split supported. |
| 6.2 | Expense tracking | ✅ | ERP `expenses` + categories. |
| 6.3 | Income management | ✅ | ERP sells + VRC revenue/profit reports. |
| 6.4 | Payment gateway integration | 🟡 | Stripe, Razorpay, Pesapal ✅; offline (cash/card/bank/cheque) ✅. **Gap:** PayPal, PayTabs, Flutterwave, CCAvenue not integrated. |
| 6.5 | Financial reporting (P&L, tax, revenue by service) | ✅ | ERP P&L / tax / balance-sheet / trial-balance + VRC revenue, profit, revenue-by-service, receivables-aging. |

### Section 7 — Communication & Customer Experience

| # | Requirement | Status | Where it lives / Note |
|---|---|---|---|
| 7.1 | Automated notifications (email & SMS via Twilio; reminders/updates/readiness) | ✅ | ERP `notification_templates` (email/SMS, Twilio/Nexmo in `Util.php`) + **WhatsApp** module + VRC comms-matrix + `vrc:send-reminders` daily job. |
| 7.2 | Customer portal (self-service: history, book, track) | 🟡 | Public **token** portal ✅ (online booking, live tracking, estimate approval — no login). **Gap:** no *authenticated* vehicle-owner account with full history + invoices + reminders (the **PortalApi/VetPortal** pattern exists to build it on). |
| 7.3 | Support & ticketing system | ❌ | No ticketing/help-desk module anywhere. |

### Section 8 — ISO & International Compliance

| # | Requirement | Status | Where it lives / Note |
|---|---|---|---|
| 8.1 | **ISO 9001** Documented information (controlled SOPs/work instructions) | 🟡 | Essentials `Document` stores files. **Gap:** no version control, approval/acknowledgement, controlled-register. |
| 8.2 | **ISO 9001** Service quality & customer satisfaction (complaints, feedback, corrective action) | ❌ | No complaints/CSAT/CAPA register. |
| 8.3 | **ISO 9001** Continuous improvement (analytics → improvement loop) | 🟡 | Reports exist; no NCR/CAPA-driven improvement loop. |
| 8.4 | **ISO 18541** Standardized RMI access (manufacturer repair data) | ❌ | No RMI integration; no VIN-decode-to-OEM-procedure feed. |
| 8.5 | **ISO 18541** Use-case management | ❌ | Not modelled. |
| 8.6 | **ISO 14001** Waste management (oils/solvents/batteries/tyres disposal) | ❌ | No hazardous-waste log / disposal manifests. |
| 8.7 | **ISO 14001** Environmental aspect identification | ❌ | No environmental aspects/impacts register. |
| 8.8 | **ISO 45001** Hazard ID & risk assessment | ❌ | No risk-assessment register. |
| 8.9 | **ISO 45001** Incident reporting (accidents/near-misses) | ❌ | No incident log/investigation workflow. |
| 8.10 | **ISO 45001** Safety training & certification records | ❌ | No training/cert/medical record tracking. |

### Section 9 — Technical & System

| # | Requirement | Status | Where it lives / Note |
|---|---|---|---|
| 9.1 | Scalability (SaaS) | ✅ | Multi-project SaaS host, per-tenant DB, module entitlements; VRC is its own project (`vrc_one_demo`). |
| 9.2 | Security (encryption, secure auth, vuln protection; 2FA recommended) | 🟡 | Laravel auth + RBAC + encryption + entitlement gating ✅. **Gap:** no Two-Factor Authentication. |

### Section 10 — Reporting & Analytics

| # | Requirement | Status | Where it lives / Note |
|---|---|---|---|
| 10.1 | Customizable reports (service/inventory/finance/employee) | 🟡 | 8 VRC reports + full ERP report suite ✅. **Gap:** no user-defined report builder (the `Spreadsheet` module is not installed here). |
| 10.2 | Operational analytics (efficiency, bay utilization, technician productivity) | ✅ | Bay utilization, technician productivity, turnaround, estimate-conversion reports. |
| 10.3 | Historical data analysis (trends, demand forecast, inventory optimisation) | 🟡 | Historical reporting ✅; no predictive forecasting (candidate for AiCore). |

---

## 2. Deep-dive on the themes you emphasised

### 2.1 Worksheets & task tracking — **covered, strong**
The repair order **is** the digital worksheet. Each `vrc_repair_order_services` line is a task with: description,
estimated `labor_hours`, `labor_rate`, an `assigned_technician_id`, and a line-level `status`
(`pending → in_progress → done → skipped`). Actual time is captured by start/stop **labor logs**
(`vrc_repair_order_labor_logs`, `duration_min`), which feed the technician-productivity report. Parts consumed sit on
`vrc_repair_order_parts` and auto-deduct ERP stock. The quality-check transition is **blocked** until every task line
is `done`/`skipped`. The only enhancement is *work-center routing* (§4.3) so a job can be tracked across
Mechanical → Paint → Electrical → QC sub-queues.

### 2.2 Cycle of approvals — **covered across the board**
The system already enforces multiple, audited approval cycles:

| Approval cycle | Mechanism | Gate |
|---|---|---|
| **Estimate approval** | draft → sent (tokenised link) → approved/declined, by advisor **or** customer via portal; `decided_by`, `decided_at`, `decision_method`, validity-date check | Work can't start until estimate approved (RO `estimate_approved`) |
| **Repair-order lifecycle** | 14-state machine with legal-transition guard + data guards: needs ≥1 technician for `in_progress`, all lines done for `quality_check`, completed final-DVI for `ready_for_pickup`, paid invoice for `completed` (unless `deliver_with_balance` permission) | Hard-blocks illegal/early transitions; every change logged with actor + reason |
| **Delivery sign-off** | Final DVI + customer e-signature | Required before pickup |
| **Insurance claim** | draft → submitted → approved/partially_approved/rejected → settled; approved/excess split drives the invoice | Excess becomes customer payable |
| **Appointment** | requested → confirmed → checked-in / rescheduled / cancelled / no-show | Bay conflict check |
| **Service-plan redemption** | active plan, not expired, visits remaining | Decrements drawdown |
| **Parts transfer** (AdvancedTransfer) | prepare → ship → receive | Cross-location approval |
| **Purchase requisition** (PurchaseRequisition) | pending_approval → approved → PO | `purchase_requisition.approve` |

### 2.3 Digital inspection / check-in & delivery checklists — **covered, one enhancement**
Templated DVI with sections, four input types (status/number/text/photo), per-item severity
(`ok/attention/critical/na`), photo capture, **dual e-signatures** (advisor + customer), PDF report, and
"push-to-estimate" (a failed item → a recommended service line). Intake DVI documents arrival condition; final DVI
gates delivery. Enhancement: an **annotated body-damage diagram** at check-in (§3.1).

---

## 3. Gap register (status after the 2026-06-28 patch)

| # | Gap | Was | Now | What shipped |
|---|---|---|---|---|
| 1 | ISO 45001 hazards/incidents/training *(§8.8–8.10)* | ❌ | ✅ | `vrc_hazards` (auto risk-band), `vrc_incidents`, `vrc_safety_trainings` registers |
| 2 | ISO 14001 waste + aspects *(§8.6–8.7)* | ❌ | ✅ | `vrc_waste_streams`, `vrc_waste_disposals` (manifests/certs), `vrc_environmental_aspects` |
| 3 | ISO 9001 complaints/CSAT/CAPA *(§8.2)* | ❌ | ✅ | `vrc_tickets` (+escalate→NCR), `vrc_satisfaction_surveys` (CSAT/NPS), `vrc_ncrs`, `vrc_capas` |
| 4 | ISO 18541 RMI access *(§8.4–8.5)* | ❌ | ✅* | RMI console + `RepairInfoServiceContract`; *offline stub adapter (swap for licensed provider) |
| 5 | Support & ticketing *(§7.3)* | ❌ | ✅ | Ticket workflow + message thread |
| 6 | Authenticated owner portal *(§7.2)* | ❌ | ✅* | Phone-OTP portal (history/tracking/estimates); *wire SMS/WhatsApp OTP for prod |
| 7 | Two-Factor Authentication *(§9.2)* | ❌ | ✅ | Self-contained TOTP + step-up middleware (fail-open) |
| 8 | Controlled SOP/document mgmt *(§8.1)* | 🟡 | ✅ | `vrc_documents` (version/approval) + acknowledgement table |
| 9 | Multi-stage work-center routing *(§4.3)* | 🟡 | ✅ | `vrc_work_centers` + stage routing + audited Kanban board |
| 10 | HSN/SAC tax codes *(§1.3, §5.5)* | 🟡 | ✅ | On services → RO/estimate lines → estimate & job-card PDFs |
| 11 | Technician certifications *(§4.6)* | 🟡 | ✅ | `vrc_technician_certifications` (expiry) |
| 12 | Check-in body-damage diagram *(§3.1)* | 🟡 | ✅ | Clickable body-outline markers on the intake DVI + report PDF |
| 13 | Bin/zone/shelf storage *(§5.2)* | 🟡 | ✅ | `vrc_storage_bins` + product→bin map |
| 14 | VRC KPI dashboard tiles *(§1.5)* | 🟡 | ✅ | Existing dashboard (open WIP, ready, revenue today/MTD, low-stock) |
| 15 | Forecast analytics *(§10.3)* | 🟡 | ✅ | Demand-forecast report (heuristic; AiCore-ready) |
| 15b | User-defined report builder *(§10.1)* | 🟡 | 🟡 | Fixed reports only — a generic builder is still future work |
| 16 | Extra payment gateways *(§6.4)* | 🟡 | 🟡 | Out of module scope — core/Connector + merchant accounts |
| 17 | Owner-portal OTP delivery *(§7.2)* | 🟡 | ✅ | Delivered via configured SMS/WhatsApp channel through the ERP notification boundary |
| 18 | RMI provider plumbing *(§8.4)* | 🟡 | ✅* | Config-driven `HttpRepairInfoService` (env-activated, stub fallback); *still needs a licensed subscription |
| 19 | Test-drive result on final DVI *(§4.4)* | 🟡 | ✅ | Performed / pass-fail / odometer / notes on the delivery inspection + report PDF |
| 20 | Rework / comeback rate KPI *(§8.2–8.3)* | ❌ | ✅ | RO comeback flag + link to original + rework-rate report + escalate-to-NCR (feeds CAPA) |

**Still open (by design / external dependency):** a licensed RMI **subscription** (HTTP adapter is built),
extra payment gateways, and a user-defined report builder.

---

## 4. Phased plan to close the gaps (all module-only, no core edits)

Each item is built **inside `Modules/Vrc`** or as a small new sibling module, following the project rule that
`app/ config/ resources/ routes/ database/` stay byte-identical. Migrations live in the module; menus inject via the
existing `modifyAdminMenu` hook; AI reuses AiCore; notifications reuse WhatsApp/SMS.

### Phase 1 — Quick wins & hardening *(low effort, high value)*
- **HSN/SAC codes** — add `hsn_sac` to `vrc_services` + show on estimate/job-card/invoice PDFs. *(§1.3, §5.5)*
- **Body-damage diagram at check-in** — add a `diagram` DVI input type + SVG marker map; store on intake DVI. *(§3.1)*
- **Test-drive result** field on final DVI; **VRC KPI dashboard tiles** (WIP, bay load, deliveries due, approval queue). *(§4.4, §1.5)*
- **2FA** — small `VrcSecurity`/auth hook enabling Google2FA TOTP at login (module-only middleware). *(§9.2)*

### Phase 2 — Workshop depth (worksheets & routing)
- **Work-center routing** — `vrc_work_centers` (mechanical/body-paint/electrical/QC) + `current_stage` & stage-history on service lines; per-stage Kanban board; hand-off sign-off between stages. *(§4.3)*
- **Technician competence** — `vrc_technician_certifications` (skill, cert no, issued/expiry) + expiry alerts; gate assignment by required skill. *(§4.6)*
- **Storage structure** — optional `vrc_bin`/rack-zone-shelf mapping for parts within a location. *(§5.2)*

### Phase 3 — Customer experience & after-sales
- **Authenticated vehicle-owner portal** — build on the PortalApi/VetPortal pattern: phone-OTP login, repair history, live tracking, estimate approval, invoices, reminders, service plans. *(§7.2)*
- **Support / complaints / CSAT** — `vrc_tickets` (open → assigned → in_progress → resolved) + post-delivery satisfaction survey + rating, surfaced in the portal. Feeds the CAPA register in Phase 4. *(§7.3, §8.2)*

### Phase 4 — ISO compliance suite *(largest; consider a shared `Compliance`/`Hse` module reusable by all verticals)*
- **ISO 9001** — controlled-document/SOP management (versioning, approval, read-acknowledgement), non-conformance reports (NCR) + **CAPA** register linked to complaints/incidents; satisfaction analytics. *(§8.1–8.3)*
- **ISO 14001** — hazardous-waste log (waste stream, qty, disposal vendor, manifest/certificate, dates) for oils/solvents/batteries/tyres; environmental aspects & impacts register with monitoring. *(§8.6–8.7)*
- **ISO 45001** — hazard identification & risk-assessment register; incident/accident/near-miss reporting & investigation workflow; safety training/certification/medical-record tracking (links to technicians). *(§8.8–8.10)*

### Phase 5 — RMI, intelligence & payments
- **ISO 18541 RMI** — a `RepairInfoServiceContract` abstraction with a pluggable adapter to a commercial RMI/OEM data provider (e.g. TecRMI/HaynesPro/Autodata) + VIN decode; expose use-case-driven lookups inside the RO. Supplement with AiCore repair guidance. *(§8.4–8.5)*
- **Predictive analytics** (parts-demand forecast, service-due prediction) via AiCore; **report builder**; **extra payment gateways** (PayPal/PayTabs) via the Connector/payment layer. *(§10.1, §10.3, §6.4)*

### Suggested sequencing
Phase 1 → 2 → 3 in order (each shippable independently). Phase 4 is the heaviest and is best delivered as a
reusable cross-vertical compliance module. Phase 5 depends on a commercial RMI subscription and is mostly integration.

---

## 5. Appendix — what already ships in the VRC module (reference)

28 tables across vehicles, catalog, appointments/bays, repair orders (header + service/part/labor/status-history),
inspections (templates/items/results), estimates, technicians, insurance/warranty, reminders, service plans, settings.
16 functional areas, a 14-state repair-order machine with data guards, a tokenised customer portal (book/track/approve),
8 reports, an AI estimate assistant, a daily reminders job, and an ERP anti-corruption layer
(`Services/Contracts/*` bound to `Services/Adapters/Erp/*`) so the module reuses ERP contacts, stock, invoicing,
tax, media, audit and notifications without touching core.
