Ein strukturierter Entwicklungsplan für die Integration eines Computer-Aided-Facility-Management-Systems in Odoo 18 basiert auf vorhandenen Maintenance-Modulen und kann mit täglichem Zeitaufwand von zwei Stunden über sechs Wochen realisiert werden. Der Plan nutzt bestehende Odoo-Funktionalitäten wie Equipment-Management, MTBF/MTTR-Berechnungen und Predictive-Maintenance-Features als Fundament für eine kundenspezifische Lösung. Eine systematische Code-basierte Entwicklung ermöglicht die schrittweise Erweiterung der Kernmodule um spezifische Anforderungen wie UDI-Integration und Medicator-Kompatibilität.

Perfekt – ich habe jetzt alles was ich brauche! Hier ist der echte, code-basierte Entwicklungsplan für dein 2-Stunden-pro-Tag-Setup:

🚀 CAFM + Medicator.io: Pair-Coding-Plan mit Claude

Basis: Echter Odoo 18 Quellcode | 2h/Tag inkl. Wochenenden → ~6 Wochen

🧱 Was Odoo 18 schon mitbringt (NICHT neu bauen!)

Ich habe im echten Code nachgeschaut – diese Basis nutzen wir direkt:

1. maintenance.equipment – unser Geräte-Fundament

odoo_18/addons/maintenance/models/maintenance.py:121 → MaintenanceEquipment – Das Kern-Model für alle Geräte. Bereits vorhanden: serial_no, warranty_date, cost, location, model. Wir erweitern es statt neu zu bauen.

odoo_18/addons/maintenance/models/maintenance.py:179 → _sql_constraints = [('serial_no', 'unique(serial_no)...)] – Seriennummer ist bereits DB-unique enforced. Gut für UDI/Medicator-IDs.

2. maintenance.mixin – MTBF/MTTR gratis

odoo_18/addons/maintenance/models/maintenance.py:80 → MaintenanceMixin – Dieses AbstractModel berechnet automatisch mtbf, mttr, estimated_next_failure und latest_failure_date. Das ist unser Predictive Maintenance Fundament – kostenlos.

odoo_18/addons/maintenance/models/maintenance.py:106 → _compute_maintenance_request() – Berechnet MTBF als (latest_failure - effective_date) / count_repairs. Wir müssen das nur mit Medicator-Daten füttern.

3. maintenance.request – Wiederkehrende Wartung gratis

odoo_18/addons/maintenance/models/maintenance.py:276 → recurring_maintenance, repeat_interval, repeat_unit – Automatische Wartungswiederholung ist bereits eingebaut! Bei repeat_unit: week/month/year. Wir müssen nur Medicator-Intervall → dieses Feld mappen.

odoo_18/addons/maintenance/models/maintenance.py:349 → In write(): Wenn Stage auf done gesetzt wird und recurring_maintenance=True → kopiert sich der Request automatisch mit schedule_date += repeat_interval. Gratis-Automatisierung!

4. helpdesk.ticket – Service-Desk Basis

enterprise_18/helpdesk/models/helpdesk_ticket.py:20 → HelpdeskTicket – Vollständiges Ticket-System mit priority, kanban_state, tag_ids, properties. Wir fügen nur medical_device_id als Custom-Feld hinzu.

enterprise_18/helpdesk/models/helpdesk_ticket.py:93 → properties = fields.Properties(...) – Wichtig! Wir können Medical-spezifische Properties (UDI, Risikoklasse, etc.) ohne Custom-Code als Properties definieren. Spart Tag 1 komplett.

5. SLA – bereits fertig

enterprise_18/helpdesk/models/helpdesk_sla.py:45 → time = fields.Float('Within') – SLA-Zeit in Arbeitsstunden. Wir definieren einfach: life_critical → time=1.0, essential → time=4.0, administrative → time=24.0. Keine eigene SLA-Logik nötig.

6. stock.lot – Serial Numbers für UDI

odoo_18/addons/stock/models/stock_lot.py:23 → StockLot – Hat bereits name (Seriennummer), ref (interne Referenz), lot_properties (für UDI/Medicator-Metadaten). Equipment kann via serial_no direkt verknüpft werden – siehe _compute_match_serial().

odoo_18/addons/maintenance/models/maintenance.py:162 → _compute_match_serial() – Verknüpft automatisch maintenance.equipment.serial_no mit stock.lot.name. Wir tracken UDI-Codes dort.

📅 DER PLAN: 2h/Tag, 6 Wochen, echter Code

WOCHE 1 (Mo-So = 14h total)

Ziel: Custom Module + Medicator-Felder + erster Sync

Tag 1-2 (4h): Addon-Skeleton + Equipment erweitern

Was Claude schreibt:

# Prompt an Claude:
"Erstelle ein Odoo 18 Custom Addon 'medical_cafm'.
Erweitere maintenance.equipment mit diesen Feldern:
- medicator_id (Char, unique, index=True)
- udi_code (Char, 'Unique Device Identification')
- risk_class (Selection: I, IIa, IIb, III)
- device_status (Selection: active, maintenance_due, in_service, decommissioned)
- last_medicator_sync (Datetime, readonly)
Nutze _inherit = 'maintenance.equipment'.
Basis: maintenance.equipment hat bereits serial_no, warranty_date, cost."

Du testest: Addon installiert? Felder sichtbar in Form View?

Tag 3-4 (4h): Medicator API Connector

Was Claude schreibt:

# Prompt an Claude:
"Schreib einen Odoo 18 Service 'MedicatorSyncService' der:
1. Medicator REST API pullt (API-Key aus ir.config_parameter)
2. Response mapped auf maintenance.equipment Felder
3. Upsert by medicator_id (create wenn neu, write wenn existiert)
4. last_medicator_sync = fields.Datetime.now() nach Sync
5. Fehler: Retry 3x, dann log.warning und weiter
Zeige mir nur fertigen Python-Code."

Tag 5-7 (6h): Cron + erste Tests

# Prompt an Claude:
"Erstelle einen ir.cron der täglich um 3:00 Uhr MedicatorSyncService.sync_all() aufruft.
Schreib dazu 3 Unit Tests:
1. Test: Neues Gerät wird erstellt
2. Test: Existierendes Gerät wird upgedated (by medicator_id)
3. Test: API-Fehler wird geloggt (kein Crash)"

Deliverable Woche 1: ✅ Addon installiert, ✅ Medicator-Daten fließen in maintenance.equipment

WOCHE 2 (Mo-So = 14h total)

Ziel: Helpdesk-Integration + Medical Service Workflows

Tag 1-2 (4h): Ticket-Erweiterung

Was Claude schreibt:

# Prompt an Claude:
"Erweitere helpdesk.ticket mit:
- medical_device_id = Many2one('maintenance.equipment')
- device_criticality = Selection(related='medical_device_id.risk_class')
- service_type = Selection(['routine','emergency','inspection','recall'])

Wenn service_type='emergency' → setze priority='3' automatisch (onchange).
Wenn medical_device_id gesetzt → subject auto-fill mit Device-Name."

Tag 3-4 (4h): Auto-Ticket-Erstellung

# Prompt an Claude:
"Schreib eine Server Action die auf maintenance.equipment läuft:
Wenn device_status = 'maintenance_due' → erstelle automatisch helpdesk.ticket
mit service_type='routine', medical_device_id=self, priority basierend auf risk_class:
- risk_class III → priority '3' (Urgent)
- risk_class IIb → priority '2' (High)
- risk_class I/IIa → priority '1' (Medium)
Verknüpfe mit existing SLA-Policy 'Medical Services'."

Tag 5-7 (6h): Mobile-optimierte Views + UAT

<!-- Prompt an Claude:
Erstelle eine mobile-optimierte Form View für helpdesk.ticket
die medical_device_id, service_type, device_criticality zeigt.
Füge einen 'QR Scan' Button hinzu der device_serial_no scannt
und medical_device_id auto-setzt.
Zeige nur XML." -->

Live Test: Öffne Odoo auf Tablet, erstelle Ticket, scann QR-Code.

Deliverable Woche 2: ✅ Techniker kann Tickets erstellen, ✅ Auto-Tickets bei überfälligen Geräten

WOCHE 3 (Mo-So = 14h total)

Ziel: Dashboards + Reports

Tag 1-2 (4h): Manager-Dashboard

# Prompt an Claude:
"Schreib 3 Odoo 18 Pivot-Reports:

1. 'Device Status Overview' (maintenance.equipment)
   Rows: category_id, Cols: device_status, Values: count, avg cost

2. 'Maintenance Compliance' 
   Rows: equipment_id, Cols: maintenance_type (preventive/corrective)
   Values: count, avg MTTR (aus maintenance.mixin.mttr)
   
3. 'Service Ticket KPIs' (helpdesk.ticket)
   Rows: service_type, Cols: priority
   Values: count open/closed, avg resolution time

Nutze Odoo 18 Report-Syntax. Nur XML + Python."

Tag 3-4 (4h): Compliance-Report

# Prompt an Claude:
"Erstelle einen QWeb-PDF-Report 'Medical Compliance Audit Trail' der:
- Alle maintenance.request der letzten 12 Monate zeigt
- Gruppiert nach equipment_id
- Felder: date, maintenance_type, technician, stage (done/open), close_date
- Footer: Unterschriften-Block für Inspector
Nutze Odoo 18 report.report_sxw."

Tag 5-7 (6h): Dashboards live testen mit echten Daten

Deliverable Woche 3: ✅ Manager sieht Gerätestatus in 30s, ✅ Compliance-PDF druckbar

WOCHE 4 (Mo-So = 14h total)

Ziel: Automatisierungen + Predictive Features

Tag 1-2 (4h): Cron-basierte Automationen

# Prompt an Claude:
"Schreib 2 Cron-Jobs für Odoo 18:

1. Daily 7:00 - 'Check Maintenance Due':
   - Finde alle maintenance.equipment wo:
     estimated_next_failure <= today + 7 Tage (aus maintenance.mixin)
   - Setze device_status = 'maintenance_due'
   - Erstelle helpdesk.ticket wenn noch kein offenes Ticket existiert
   - Sende Email an maintenance_team_id

2. Hourly - 'SLA Escalation Check':
   - Finde alle helpdesk.ticket wo:
     priority='3' AND create_date < now - 1h AND stage_id.fold=False
   - Sende chatter-Nachricht: 'ESCALATION: Ticket offen seit X Stunden'
   - Weise supervisor_id zu"

Tag 3-4 (4h): Predictive Maintenance nutzen

Wichtig: MaintenanceMixin.estimated_next_failure ist bereits berechnet! Wir bauen nur darauf auf:

# Prompt an Claude:
"Erstelle eine computed field 'failure_risk_score' auf maintenance.equipment:
- Basis: estimated_next_failure (bereits in maintenance.mixin vorhanden)
- Logic:
  - estimated_next_failure < today → 'critical' (rot)
  - estimated_next_failure < today + 30 Tage → 'warning' (orange)  
  - estimated_next_failure > today + 30 Tage → 'ok' (grün)
- Zeige als Color-Badge in List View und Kanban View."

Tag 5-7 (6h): Recall-Management

# Prompt an Claude:
"Wenn Medicator-API ein Gerät mit status='recall' zurückgibt:
1. Setze device_status = 'maintenance_due' in maintenance.equipment
2. Erstelle helpdesk.ticket mit service_type='recall', priority='3'
3. Sende Email an owner_user_id UND maintenance_team_id
4. Chatter-Eintrag: 'SAFETY RECALL von Medicator.io empfangen: [recall_reason]'
Schreib die komplette Webhook-Handler-Methode."

Deliverable Woche 4: ✅ Automationen laufen, ✅ Predictive Colors sichtbar, ✅ Recall-Handler

WOCHE 5 (Mo-So = 14h total)

Ziel: Data Migration + Security + Staging-Tests

Tag 1-2 (4h): Import-Script für bestehende Geräte

# Prompt an Claude:
"Schreib ein Python-Script das CSV importiert in maintenance.equipment:
Spalten: name, serial_no, model, location, cost, warranty_date, category
Mapping: serial_no → maintenance.equipment.serial_no (unique check)
Wenn serial_no existiert → update, sonst → create
Nach Import: triggere Medicator-Sync für jedes neue Gerät (match by serial_no)
Zeig Script + Validation-Fehler-Report."

Tag 3-4 (4h): Security Setup

# Prompt an Claude:
"Erstelle Odoo 18 Security-Config für medical_cafm:
- Gruppe 'medical.group_biomedical_technician':
  - Kann lesen/schreiben: maintenance.equipment, helpdesk.ticket, maintenance.request
  - Kann NICHT lesen: account.move, hr.employee
  
- Gruppe 'medical.group_facility_manager':
  - Alles von Technician PLUS account.asset lesen
  
- Gruppe 'medical.group_compliance_officer':
  - Alle Medical-Models lesen (readonly)
  - Kann PDF-Reports drucken

- ir.rule: Technician sieht nur seine assigned Tickets
Zeig ir.model.access.csv + security.xml"

Tag 5-7 (6h): Full Integration Test auf Staging

Checkliste die du durchgehst:

□ Medicator-Sync: Gerät aus API landet in Odoo?
□ Auto-Ticket: device_status=maintenance_due → Ticket erstellt?
□ SLA: priority=3 Ticket → Escalation nach 1h?
□ PDF-Report: Compliance Audit Trail druckbar?
□ Security: Techniker sieht keine Finance-Daten?
□ Mobile: Ticket auf Tablet erstellbar?
□ Recall: Medicator sendet recall → Email geht raus?

Deliverable Woche 5: ✅ Staging-System komplett getestet, ✅ Security korrekt

WOCHE 6 (Mo-So = 14h total)

Ziel: Production Go-Live + erste echte Nutzung

Tag 1 (2h): Go-Live

□ Production DB backup
□ Addon deployen
□ Medicator API-Key in ir.config_parameter setzen
□ Ersten Sync manuell triggern
□ 3 Test-Geräte anlegen
□ Team einschulen (30 Min Demo)

Tag 2-7 (12h): Live Monitoring + Quick Fixes

Tägliche Claude-Session:

Du: "Hier ist der heutige Error-Log: [paste]"
Claude: "Zeile 42 in sync_service.py – API gibt None zurück 
         wenn medicator_id fehlt. Fix: if not record.get('medicator_id'): continue"
Du: "Deployed. Test: ✅"

Deliverable Woche 6: ✅ System in Production, ✅ echte Geräte verwaltet

⏱️ Zeitplan-Übersicht

🎯 Die 3 wichtigsten Erkenntnisse aus dem echten Code

1. MaintenanceMixin.estimated_next_failure ist bereits eingebaut – Predictive Maintenance kostet uns 0 Entwicklungsstunden, nur Medicator-Daten reinfüttern.

2. recurring_maintenance + repeat_interval – wiederkehrende Wartungsanfragen generieren sich selbst. Medicator-Intervall → dieses Feld = fertig.

3. helpdesk.ticket.properties – Medical-Metadaten (UDI, Risikoklasse) als Properties definierbar ohne Custom-Code. Spart 1-2 Tage Entwicklung.

📎 Quellreferenzen

• odoo_18/addons/maintenance/models/maintenance.py → MaintenanceMixin._compute_maintenance_request() (Odoo 18 Community) – Berechnet MTBF/MTTR/estimated_next_failure automatisch aus Reparaturhistorie
• odoo_18/addons/maintenance/models/maintenance.py → MaintenanceRequest.recurring_maintenance (Odoo 18 Community) – Automatische Wiederholung von Wartungsanfragen basierend auf repeat_interval + repeat_unit
• odoo_18/addons/maintenance/models/maintenance.py → MaintenanceEquipment (Odoo 18 Community) – Basis-Gerätemodell mit serial_no, warranty_date, cost – wird mit medicator_id erweitert
• enterprise_18/helpdesk/models/helpdesk_ticket.py → HelpdeskTicket.properties (Odoo 18 Enterprise) – Properties-Feld für flexible Medical-Metadaten ohne Custom-Code
• enterprise_18/helpdesk/models/helpdesk_sla.py → HelpdeskSLA.time (Odoo 18 Enterprise) – SLA-Zeit in Arbeitsstunden, direkt konfigurierbar für life_critical/essential/administrative
• odoo_18/addons/stock/models/stock_lot.py → StockLot (Odoo 18 Community) – Serial-Number-Tracking, verknüpfbar mit maintenance.equipment via serial_no für UDI-Code-Verwaltung

Oddy
Odoo-Expertin bei Detalex GmbH

Oddy ausprobieren