Abnahmekriterien stellen sicher, dass medizintechnische Geräte im CAFM-System von Odoo den erforderlichen Standards entsprechen, bevor sie in den produktiven Betrieb gehen. Eine strukturierte Checkliste mit messbaren Pass-Fail-Kriterien reduziert Fehler, beschleunigt die Freigabe und dokumentiert die Konformität nachvollziehbar. Dieser Artikel zeigt, wie Abnahmekriterien in Odoo 18 für Gerätestammdaten, UDI-Tracking, Wartungsplanung und Bestandsverwaltung definiert und getestet werden. 

Ich bemerke, dass der bereitgestellte Kontext Odoo Inventory-Dokumentation (FIFO/FEFO/LIFO/Putaway) enthält – nicht direkt Medicator.io CAFM-spezifisch. Ich nutze diese Quellen aber gezielt dort wo sie relevant sind (z.B. Geräteverfolgung via Lots/Serial Numbers, UDI-Tracking) und kombiniere sie mit unserem gesamten Conversation-Kontext.

✅ Abnahmekriterien: CAFM + Medicator.io auf Odoo 18

Basis: Alle Features aus unserer Conversation + verifizierter Odoo-Quellcode
Format: Klare Pass/Fail-Kriterien für jedes Feature

🏷️ BLOCK 1: Medicator.io Produktkatalog & Gerätestammdaten

AC-01: Medicator-ID als eindeutiger Identifier

• ✅ PASS wenn: Jedes maintenance.equipment-Record hat ein befülltes medicator_id-Feld
• ✅ PASS wenn: DB wirft Fehler bei doppelter medicator_id (SQL Unique Constraint aktiv)
• ❌ FAIL wenn: Zwei Geräte dieselbe medicator_id haben können

AC-02: Filterbare Geräteparameter

• ✅ PASS wenn: Folgende Felder in List View filterbar und gruppierbar sind:
  • risk_class (I / IIa / IIb / III)
  • device_status (active / maintenance_due / in_service / decommissioned)
  • category_id (Gerätekategorie)
  • location_id (Standort)
  • manufacturer (Hersteller)
• ❌ FAIL wenn: Filter auf einem dieser Felder keine Ergebnisse liefert oder crasht

AC-03: UDI-Code Tracking via Serial Numbers

• ✅ PASS wenn: udi_code am Gerät gespeichert ist UND via _compute_match_serial() mit stock.lot.name verknüpft ist
• ✅ PASS wenn: Im Lots/Serial Numbers-Menü das Created on-Feld den korrekten Eingang zeigt (= Basis für FIFO-Removal und Traceability)
• ❌ FAIL wenn: UDI-Code nicht am Lot hinterlegt oder nicht abrufbar ist

AC-04: MDR-Klassifizierung vollständig

• ✅ PASS wenn: Alle 4 Risikoklassen (I, IIa, IIb, III) als Selection-Werte vorhanden sind
• ✅ PASS wenn: risk_class in Kanban-View als farbiger Badge sichtbar ist (grün/orange/rot)
• ❌ FAIL wenn: Klassifizierung fehlt oder nicht visuell unterscheidbar

AC-05: Medicator Sync funktioniert

• ✅ PASS wenn: Neues Gerät aus Medicator API wird korrekt in maintenance.equipment angelegt (Create-Pfad)
• ✅ PASS wenn: Geändertes Gerät in Medicator wird in Odoo upgedated (Update-Pfad via medicator_id als Unique Key)
• ✅ PASS wenn: last_medicator_sync Timestamp aktualisiert sich nach jedem erfolgreichen Sync
• ✅ PASS wenn: API-Ausfall wird geloggt (Warning im Odoo-Log sichtbar), System crasht NICHT
• ❌ FAIL wenn: Bei API-Ausfall eine Exception den Cron dauerhaft deaktiviert

🔄 BLOCK 2: Automatisches Maintenance Scheduling

AC-06: Wiederkehrende Wartung via recurring_maintenance

• ✅ PASS wenn: Nach Abschluss (Stage = Done) eines Maintenance Requests mit recurring_maintenance=True automatisch ein neuer Request erstellt wird mit schedule_date = old_date + repeat_interval
• ✅ PASS wenn: repeat_unit korrekt auf Medicator-Intervall (Monate) gemappt ist
• ❌ FAIL wenn: Kein Folge-Request entsteht nach Stage-Wechsel auf Done

AC-07: Automatische Ticket-Erstellung bei überfälliger Wartung

• ✅ PASS wenn: Täglicher Cron (7:00 Uhr) alle Geräte mit estimated_next_failure <= today + 7 Tage findet
• ✅ PASS wenn: Für jedes betroffene Gerät OHNE offenes Ticket ein neues helpdesk.ticket mit service_type='routine' erstellt wird
• ✅ PASS wenn: Kein Doppel-Ticket entsteht wenn bereits ein offenes Ticket existiert
• ❌ FAIL wenn: Cron läuft, aber keine Tickets entstehen

AC-08: MPBetreibV-konforme Intervalle

• ✅ PASS wenn: Wartungsintervall aus Medicator (z.B. 12 Monate) korrekt auf repeat_interval=12, repeat_unit='month' gesetzt wird
• ✅ PASS wenn: maintenance_type='preventive' für alle regulatorisch vorgeschriebenen Wartungen gesetzt ist
• ❌ FAIL wenn: Intervall falsch berechnet oder maintenance_type fehlt

🤖 BLOCK 3: Predictive Maintenance

AC-09: MTBF / MTTR Berechnung

• ✅ PASS wenn: mtbf (Mean Time Between Failure) korrekt aus abgeschlossenen korrektiven Requests berechnet wird
• ✅ PASS wenn: mttr (Mean Time To Repair) als Durchschnitt aus (close_date - request_date) aller done-Requests stimmt
• ✅ PASS wenn: Beide Werte im Manager-Dashboard sichtbar sind
• ❌ FAIL wenn: MTBF = 0 obwohl historische Reparaturen vorhanden sind

AC-10: estimated_next_failure & Risk Score Badge

• ✅ PASS wenn: estimated_next_failure = latest_failure_date + mtbf korrekt berechnet wird
• ✅ PASS wenn: failure_risk-Badge zeigt:
  • 🔴 critical wenn estimated_next_failure < today
  • 🟠 warning wenn estimated_next_failure < today + 30 Tage
  • 🟢 ok wenn estimated_next_failure > today + 30 Tage
• ❌ FAIL wenn: Badge zeigt falschen Status oder wird nicht dargestellt

🎫 BLOCK 4: Healthcare Service Desk

AC-11: Medical Device auf Helpdesk Ticket

• ✅ PASS wenn: medical_device_id auf jedem Ticket setzbar ist (Many2one zu maintenance.equipment)
• ✅ PASS wenn: Bei Setzen von service_type='emergency' → priority automatisch auf '3' (Urgent) springt
• ✅ PASS wenn: Ticket-Name auto-befüllt wird mit [SERVICE_TYPE] Device-Name
• ❌ FAIL wenn: Onchange-Logik nicht feuert oder falsche Priority setzt

AC-12: SLA-Enforcement nach Geräte-Kritikalität

• ✅ PASS wenn: Folgende 3 SLA-Policies aktiv sind und greifen:
  • life_critical (risk_class III) → Response ≤ 1h Arbeitszeit
  • essential (risk_class IIb) → Response ≤ 4h Arbeitszeit
  • administrative (risk_class I/IIa) → Response ≤ 24h Arbeitszeit
• ✅ PASS wenn: sla_fail = True wenn Deadline überschritten (visuell rot markiert)
• ❌ FAIL wenn: SLA-Deadline nicht berechnet wird oder sla_fail nie True wird

AC-13: SLA Escalation Cron

• ✅ PASS wenn: Stündlicher Cron Tickets mit priority='3' und create_date < now - 1h und stage_id.fold=False findet
• ✅ PASS wenn: Chatter-Nachricht "ESCALATION: Ticket offen seit X Stunden" erscheint
• ❌ FAIL wenn: Eskalation nie eintritt trotz überfälligem Critical-Ticket

AC-14: Mobile-optimierter Techniker-Workflow

• ✅ PASS wenn: Form View auf Tablet (768px) nutzbar ist (keine horizontalen Scrollbalken, große Buttons)
• ✅ PASS wenn: QR-Code Scanner medical_device_id korrekt setzt
• ✅ PASS wenn: Foto-Upload im Ticket funktioniert
• ❌ FAIL wenn: UI auf Tablet unbrauchbar oder QR-Scan crasht

🔔 BLOCK 5: Recall & Alert Management

AC-15: Recall-Handler von Medicator

• ✅ PASS wenn: Medicator-API sendet status='recall' → device_status = 'maintenance_due' wird gesetzt
• ✅ PASS wenn: Automatisches Helpdesk-Ticket mit service_type='recall', priority='3' entsteht
• ✅ PASS wenn: Email-Benachrichtigung an owner_user_id UND maintenance_team_id gesendet wird
• ✅ PASS wenn: Chatter-Eintrag mit recall_reason aus Medicator-Response sichtbar ist
• ❌ FAIL wenn: Recall eintrifft aber kein Ticket und keine Email entsteht

AC-16: Warranty-Expiry-Alert

• ✅ PASS wenn: 30 Tage vor warranty_date automatische Benachrichtigung an maintenance_team_id gesendet wird
• ❌ FAIL wenn: warranty_date abläuft ohne jegliche Benachrichtigung

📊 BLOCK 6: Reports & Dashboards

AC-17: Manager-Dashboard (3 Pivot Tables)

• ✅ PASS wenn: "Device Status Overview" zeigt: Anzahl Geräte je device_status, gruppiert nach category_id
• ✅ PASS wenn: "Maintenance Compliance" zeigt: MTTR je Gerät, unterschieden nach preventive/corrective
• ✅ PASS wenn: "Service Ticket KPIs" zeigt: Anzahl Tickets je service_type und priority, avg. Lösungszeit
• ✅ PASS wenn: Alle 3 Dashboards in unter 5 Sekunden laden (bei ≤ 500 Geräten)
• ❌ FAIL wenn: Dashboard leer bleibt oder länger als 10 Sekunden lädt

AC-18: Compliance Audit Trail PDF

• ✅ PASS wenn: QWeb-PDF enthält: request_date, close_date, user_id, equipment_id.medicator_id, equipment_id.udi_code, maintenance_type, stage_id
• ✅ PASS wenn: Unterschriften-Block am Ende des PDFs vorhanden ist
• ✅ PASS wenn: PDF für alle Maintenance Requests der letzten 12 Monate filterbar ist
• ❌ FAIL wenn: PDF leer ist, Pflichtfelder fehlen oder Druck crasht

🔐 BLOCK 7: Security & Compliance

AC-19: Rollenbasierte Zugriffskontrolle

• ✅ PASS wenn: medical.group_biomedical_technician kann:
  • ✅ maintenance.equipment, helpdesk.ticket, maintenance.request lesen/schreiben
  • ❌ account.move, hr.employee NICHT lesen
• ✅ PASS wenn: medical.group_facility_manager zusätzlich account.asset lesen kann
• ✅ PASS wenn: medical.group_compliance_officer alle Medical-Models readonly lesen kann
• ✅ PASS wenn: Techniker-IR-Rule: Techniker sieht NUR seine assigned Tickets
• ❌ FAIL wenn: Techniker Finance-Daten sehen kann

AC-20: API-Key Sicherheit

• ✅ PASS wenn: Medicator API-Key in ir.config_parameter gespeichert ist (NICHT in Python-Code hard-coded)
• ✅ PASS wenn: API-Key nicht im Odoo-Log erscheint (kein log.info(api_key))
• ❌ FAIL wenn: API-Key im Source Code oder Logfile sichtbar ist

AC-21: Audit Log Vollständigkeit

• ✅ PASS wenn: mail.thread auf maintenance.equipment alle Feldänderungen trackt (wer / wann / was)
• ✅ PASS wenn: Jede Statusänderung von device_status mit Zeitstempel und User im Chatter erscheint
• ❌ FAIL wenn: Statusänderungen spurlos verschwinden

🔄 BLOCK 8: Datenmigration & Integration

AC-22: CSV-Import

• ✅ PASS wenn: Import-Script verarbeitet CSV mit Feldern: name, serial_no, model, location, cost, warranty_date, category korrekt
• ✅ PASS wenn: Duplikate (via serial_no) werden als Update behandelt (kein Crash, kein Doppel-Eintrag)
• ✅ PASS wenn: Validation-Error-Report zeigt ungültige Zeilen an
• ❌ FAIL wenn: Import bei einer fehlerhaften Zeile komplett abbricht

AC-23: Bidirektionaler Sync

• ✅ PASS wenn: Pull (Medicator → Odoo): Neue Geräte landen in Odoo
• ✅ PASS wenn: Push (Odoo → Medicator): Wartungsdaten fließen zurück
• ✅ PASS wenn: Sync-Fehler werden im ir.logging gespeichert und sind adminstrativ sichtbar
• ❌ FAIL wenn: Sync läuft nur in eine Richtung ohne Rückmeldung

📋 ABNAHME-CHECKLISTE: Go/No-Go

Go-Live-Bedingung: Alle Must-Have Kriterien = PASS ✅

📎 Quellreferenzen

• odoo_18/addons/maintenance/models/maintenance.py:80 → MaintenanceMixin._compute_maintenance_request() (Odoo 18 Community) – Basis für AC-09 (MTBF/MTTR) und AC-10 (estimated_next_failure) – alle Predictive-Kriterien basieren auf dieser Methode
• odoo_18/addons/maintenance/models/maintenance.py:276 → MaintenanceRequest.recurring_maintenance + write() (Odoo 18 Community) – Basis für AC-06 und AC-07: automatische Selbst-Replikation bei Stage=Done
• enterprise_18/helpdesk/models/helpdesk_ticket.py:20 → HelpdeskTicket mit mail.thread.cc (Odoo 18 Enterprise) – Basis für AC-11, AC-13, AC-21: Ticket-System inkl. vollständigem Audit-Trail via mail.thread
• enterprise_18/helpdesk/models/helpdesk_sla.py:45 → HelpdeskSLA.time (Odoo 18 Enterprise) – Direkte Basis für AC-12: SLA-Zeit in Arbeitsstunden, konfigurierbar je Kritikalitätsstufe
• docs_19/content/applications/inventory_and_mrp/inventory/shipping_receiving/removal_strategies/fifo.rst:96 → Created on-Feld in Lots/Serial Numbers (Odoo 19 Docs) – Basis für AC-03: UDI/Seriennummer-Tracking via Lot-Ankunftsdatum, relevant für Medicator-Gerätetraceability

Oddy
Odoo-Expertin bei Detalex GmbH

Oddy ausprobieren