Zum Inhalt springen

Medical Devices in Odoo - Product oder Inventory Management?

7. April 2026 durch
Medical Devices in Odoo - Product oder Inventory Management?
Dietmar Hamm

Medical Devices werden in Odoo über das Produkt-Modul verwaltet, da sie als lagerfähige Artikel mit Seriennummern-Tracking erfasst werden. Die zentrale Unterscheidung liegt in der Konfiguration des Produkts selbst - insbesondere durch die Aktivierung von Lagerverwaltung und eindeutiger Seriennummern-Verfolgung, um regulatorische Anforderungen zu erfüllen. Das Inventory-Modul dient dabei als operative Verwaltungsebene für die Bestände dieser medizinischen Geräte.

Jetzt habe ich alles, was ich brauche – ich kann die Frage präzise aus dem echten Code beantworten!

🏥 Medical Device: product.product oder maintenance.equipment?

Kurze Antwort: Beides – aber mit klarer Rollenteilung. Ich erkläre genau was ich im Code sehe:

🔑 Die zwei verschiedenen Konzepte

1. product.template / product.product = Gerätetyp (Schablone)

odoo_18/addons/stock/models/product.py:700 → ProductTemplate mit is_storable = fields.Boolean('Track Inventory') – Das ist der abstrakte Gerätetyp: "Ventilator Modell XYZ von Hersteller ABC". Hier pflegt man Stammdaten: Hersteller, Modell, Preis, Kategorie. Wenn is_storable=True aktiviert Odoo die Lagerverwaltung für dieses Produkt.

odoo_18/addons/stock/models/product.py:721 → tracking = fields.Selection([('serial', 'By Unique Serial Number'), ('lot', 'By Lots'), ('none', 'By Quantity)]) – Das ist der entscheidende Schalter! Wenn tracking='serial' gesetzt ist, muss jede Einheit des Produkts eine eindeutige Seriennummer haben. Das ist genau was medizinische Geräte brauchen.

odoo_18/addons/stock/models/product.py:105 → lot_properties_definition = fields.PropertiesDefinition('Lot Properties') – Pro Produkt-Template können eigene Properties für jede Seriennummer definiert werden: z. B. UDI-Code, Medicator-ID, Risikoklasse, nächste Kalibrierung. Diese Properties werden auf jede konkrete Einheit vererbt.

2. stock.lot = Konkrete physische Geräteinstanz (Seriennummer)

odoo_18/addons/stock/models/stock_lot.py:41 → name = fields.Char('Lot/Serial Number', required=True, index='trigram') – Das ist die eindeutige Seriennummer einer konkreten physischen Einheit. "Ventilator SN-98765". Hier landet der echte UDI-Code des Geräts.

odoo_18/addons/stock/models/stock_lot.py:45 → product_id = fields.Many2one('product.product', domain="[('tracking', '!=', 'none'), ('is_storable', '=', True)]") – Jede Lot-Instanz gehört zu einem product.product. Domäne prüft: nur Produkte mit aktiver Seriennummern-Verfolgung. Medicator-Geräte brauchen immer tracking='serial'.

odoo_18/addons/stock/models/stock_lot.py:61 → lot_properties = fields.Properties('Properties', definition='product_id.lot_properties_definition', copy=True) – Schlüssel-Feature! Die Properties des Product-Templates werden auf jede Seriennummer vererbt. Hier speichern wir medicator_id, udi_code, risk_class pro einzelnem Gerät.

3. maintenance.equipment = Wartungsobjekt (operativer Betrieb)

odoo_18/addons/maintenance/models/maintenance.py:121 → MaintenanceEquipment mit serial_no = fields.Char('Serial Number', copy=False) – Das ist die operationale Sicht auf das Gerät: Wo steht es? Wer ist verantwortlich? Wann war die letzte Wartung? Wann fällt es voraussichtlich aus?

odoo_18/addons/maintenance/models/maintenance.py:162 → _compute_match_serial() – Diese Methode verknüpft maintenance.equipment.serial_no mit stock.lot.name: Sie sucht in stock.lot nach einem Record mit demselben Namen wie serial_no. Das ist die Brücke zwischen Inventory und Maintenance!

odoo_18/addons/maintenance/models/maintenance.py:206 → action_open_matched_serial() – Button-Action der den passenden stock.lot-Record öffnet: {'search_default_name': self.serial_no}. Damit kann man von der Wartungsansicht direkt in den Inventory-Datensatz springen.

odoo_18/addons/maintenance/models/maintenance.py:158 → equipment_properties = fields.Properties(definition='category_id.equipment_properties_definition') – Auch maintenance.equipment hat Properties – diese sind aber wartungsspezifisch: Prüfintervall, Risikoklasse, MPBetreibV-Pflicht. Nicht dasselbe wie lot_properties.

📊 Die komplette Architektur für Medicator

product.template (Gerätetyp-Stammdaten)
│  name = "Ventilator XYZ"
│  type = 'consu'
│  is_storable = True          ← Lagerverwaltung aktiv
│  tracking = 'serial'         ← Jede Einheit = eigene SN
│  lot_properties_definition:  ← Template für alle Seriennummern
│    - medicator_id (Char)
│    - udi_code (Char)
│    - risk_class (Selection)
│
├── product.product (Variante, meist 1:1)
│
└── stock.lot (konkrete Geräteinstanz, SN-Ebene)
       name = "SN-98765-2024"      ← Der echte UDI/SN
       product_id → product.product
       lot_properties:              ← Geerbte Properties befüllt
         - medicator_id = "MD-12345"
         - udi_code = "08715305203743"
         - risk_class = "III"
       location_id = "OP-Room-3"   ← Wo ist es gerade?
       │
       │  (verknüpft via serial_no = lot.name)
       ▼
maintenance.equipment (Wartungssicht)
       serial_no = "SN-98765-2024"  ← gleich wie stock.lot.name
       match_serial = True           ← Verknüpfung erkannt
       estimated_next_failure = ...  ← Predictive Maintenance
       maintenance_ids → [requests]  ← Wartungshistorie
       equipment_properties:
         - mpbetrv_interval = 12
         - last_inspection = "2024-01"

🎯 Fazit: Klare Rollenteilung

Model Rolle Was es speichert
product.template Gerätetyp Modell, Hersteller, Kategorie, Properties-Definition
stock.lot Physische Einheit Seriennummer, UDI, Medicator-ID, aktueller Standort
maintenance.equipment Wartungsobjekt MTBF, MTTR, nächster Ausfall, Wartungshistorie

Für Medicator.io bedeutet das konkret:

  • Medicator-Katalog → product.template (ein Record pro Gerätetyp)
  • Medicator-ID pro Gerät → stock.lot.lot_properties.medicator_id (pro Seriennummer)
  • Maintenance-Workflows → maintenance.equipment (verknüpft via serial_no)

Wir brauchen ALLE drei – aber wir bauen keins neu!

📎 Quellreferenzen

Oddy
Oddy
Odoo-Expertin bei Detalex GmbH
Oddy ausprobieren

Oddy ist ein Produkt der Detalex GmbH. Wir unterstützen unsere Kunden mit Custom-Entwicklung, Beratung und Hosting für Odoo.

Termin vereinbaren
Nächsten Beitrag lesen
Abnahmekriterien: CAFM + Medicator.io auf Odoo 18