odoo_mqtt/docs/IMPLEMENTATION_PLAN_POS_MACHINE_TIME_BILLING.md

Implementation Plan: PoS Maschinenzeit aus IoT-Sessions

Stand: 2026-02-21
Status: In Umsetzung (Schritt 4 erweitert)

Ziel dieses Dokuments

Dieser Plan enthält ausschließlich die Umsetzungsreihenfolge.
Technische Implementierungsdetails werden in einem nächsten Schritt ergänzt.

Reihenfolge

1. Neues Modul anlegen (Grundgerüst + Name festlegen)

   • Arbeitsfähige Basis schaffen und Modulname verbindlich festlegen.
   • Modulname: open_workshop_pos_mqtt.
   • Modulpfad: extra-addons/open_workshop/open_workshop_pos_mqtt.

   Ziel von Schritt 1

   • Verbindlichen Startpunkt für die Umsetzung schaffen.
   • Neues Modul ist als eigenständiger Arbeitskontext klar benannt und eingeordnet.
   • Team kann auf dieser Basis die Folgeschritte ohne Strukturentscheidungen starten.

   Abgrenzung von Schritt 1

   • In diesem Schritt wird nur die Modulbasis festgelegt.
   • Fachlogik, PoS-Flow, Datenimport und Testautomatisierung sind nicht Teil dieses Schritts.

   Abnahmekriterien Schritt 1

   • Modulname open_workshop_pos_mqtt ist final bestätigt.
   • Zielpfad extra-addons/open_workshop/open_workshop_pos_mqtt ist final bestätigt.
   • Das Modul ist im Plan als offizieller Startpunkt dokumentiert.
   • Es gibt keinen offenen Alternativpfad mehr zur Modulplatzierung.

   Erwartetes Ergebnis Schritt 1

   • Eindeutige Entscheidungsgrundlage für alle nachfolgenden Schritte.
   • Keine weitere Diskussion über Modulname oder Modulort vor Beginn von Schritt 2.

2. Testfunktionen für Session-Testdaten bereitstellen

   • Einfacher Weg, abgeschlossene Sessions gezielt in die Datenbank einzuspielen.

   Ziel von Schritt 2

   • Verlässliche und reproduzierbare Session-Daten für die PoS-Entwicklung bereitstellen.
   • Entwicklung und Prüfung des PoS-Flows unabhängig von Live-Daten ermöglichen.
   • Typische Werkstattfälle mit abgeschlossenen Sessions gezielt nachbilden können.

   Abgrenzung von Schritt 2

   • Fokus liegt auf Verfügbarkeit und Nutzbarkeit von Testdaten.
   • PoS-UX, finale Datenanbindung und UI-Automation sind nicht Teil dieses Schritts.

   Abnahmekriterien Schritt 2

   • Abgeschlossene Sessions können gezielt und wiederholbar eingespielt werden.
   • Mehrere realistische Datenszenarien sind verfügbar (z. B. kein Treffer, ein Treffer, mehrere Treffer).
   • Die eingespielten Daten sind für den vorgesehenen Werkstattnutzer-Kontext nutzbar.
   • Das Team kann denselben Testdatensatz mehrfach verwenden, ohne manuelle Nacharbeit.

   Erwartetes Ergebnis Schritt 2

   • Stabiler Testdatenpfad als Grundlage für Schritt 3 und Schritt 4.
   • Schnelle Überprüfbarkeit des PoS-Flows mit definierten Sessions statt Zufallsdaten.

3. Datenanbindung an open_workshop_mqtt aktivieren

   • Session-Daten für den PoS-Flow verfügbar machen und im Prototyp verwenden.

   Ziel von Schritt 3

   • Relevante Session-Daten für den PoS-Flow verlässlich bereitstellen.
   • Fachliche Zuordnung zwischen Maschinenzeit und abrechenbarem Produkt festlegen.
   • Einheitliche Datenbasis schaffen, auf der der Frontend-Prototyp arbeiten kann.

   Abgrenzung von Schritt 3

   • Fokus liegt auf der fachlichen Verfügbarkeit und Zuordnung der Daten.
   • UI-Feinschliff, UX-Validierung und UI-Automation sind nicht Teil dieses Schritts.

   Abnahmekriterien Schritt 3

   • Session-Daten aus open_workshop_mqtt sind für den PoS-Kontext abrufbar.
   • Die Verbindung zwischen Produkt und Maschinenzeit ist fachlich eindeutig definiert.
   • Mehrere Maschinen können auf dasselbe abrechenbare Produkt referenzieren.
   • Die bereitgestellten Daten reichen aus, um in Schritt 4 Vorschläge im PoS zu bilden.

   Erwartetes Ergebnis Schritt 3

   • Konsistente Datengrundlage inklusive Produktbezug für den PoS-Flow.
   • Keine offene Grundsatzfrage mehr zur Produkt- und Session-Zuordnung vor Schritt 4.

4. PoS-Frontend-Prototyp umsetzen

   • Bedienfluss im PoS für Session-Auswahl und Übernahme sichtbar machen.

   Ziel von Schritt 4

   • Sichtbarer und nutzbarer MVP-Flow im PoS für den Werkstattnutzer.
   • Session-Vorschläge können im Popup ausgewählt und in den Auftrag übernommen werden.
   • Danach bleibt die Orderline im normalen PoS-Flow bearbeitbar.

   Abgrenzung von Schritt 4

   • Fokus liegt auf Bedienbarkeit und Nutzerfluss im Frontend.
   • Backend-Optimierung und UI-Automation sind nicht Teil dieses Schritts.

   Abnahmekriterien Schritt 4

   • Der Einstieg in den Maschinenzeit-Flow ist im PoS eindeutig erreichbar.
   • Das Session-Auswahl-Popup kann geöffnet und geschlossen werden.
   • Vorschlagszeilen sind sichtbar und auswählbar.
   • Eine Übernahmeaktion schreibt die Auswahl in den aktuellen Auftrag.
   • Übernommene Positionen können anschließend normal im PoS angepasst werden.
   • Bei „kein Treffer“ wird ein klarer Hinweis angezeigt.

   Erweiterungen aus Review (verbindlich)

   • Das Maschinenzeit-Icon in der Orderline wird nur angezeigt, wenn die Orderline ein Produkt referenziert, das über ows.pos.mqtt.product.map mindestens einer aktiven MQTT-Device-Zuordnung entspricht.
   • Im Session-Popup werden nur Sessions angezeigt, deren Device dem aktuell ausgewählten Produkt zugeordnet ist.
   • Das Session-Zeitfenster basiert auf der tatsächlichen Öffnungszeit des aktuellen PoS-Kontexts (laufende Verkaufstransaktion). Falls Odoo diese Zeit bereits standardmäßig bereitstellt, wird diese Quelle verwendet; andernfalls wird eine eindeutige und konsistente Fallback-Quelle im Modul definiert.
   • Es existiert ein externes Modul (außerhalb dieses Workspaces), das den Kunden-Anmeldezeitpunkt bereits in der UI anzeigt. Nach Bereitstellung im Workspace wird geprüft, ob dieser Zeitstempel als priorisierte Quelle für das Session-Zeitfenster verwendet werden kann.

   Integrationsnotiz (externes Modul)

   • Bis zur Verfügbarkeit des externen Moduls bleibt die aktuelle Zeitquellenlogik aktiv.
   • Nach Bereitstellung erfolgt ein gezieltes Mapping der Zeitquelle mit klarer Priorität: externe Kunden-Anmeldezeit (falls vorhanden/valide) vor Fallback-Zeitquelle.

   Zusätzliche Abnahmekriterien Schritt 4 (Review)

   • Bei nicht gemappten Produkten ist in der Orderline kein Maschinenzeit-Icon sichtbar.
   • Bei gemappten Produkten ist das Icon sichtbar und öffnet den bestehenden Maschinenzeit-Dialog.
   • Die Vorschlagsliste enthält keine Sessions fremder Produktzuordnungen.
   • Die Vorschlagsliste enthält nur Sessions innerhalb des relevanten PoS-Startzeitfensters bis „jetzt“.

   Erwartetes Ergebnis Schritt 4

   • Klickbarer, demonstrierbarer Frontend-Prototyp für den vollständigen Bedienfluss.
   • Klare Entscheidungsgrundlage, ob der UX-Ansatz vor weiterem Ausbau bestätigt wird.

5. Manuelle End-to-End-Prüfung mit Testdaten

   • PoS-Flow mit eingespielten Sessions wiederholt durchspielen.

6. Automatische UI-Tests aufsetzen

   • Reproduzierbare Tests für den PoS-Flow (Auswahl, Übernahme, Bearbeitung).

7. Stabilisierung der UI-Tests und Regression-Basis

   • Tests für wiederkehrende Nutzung zuverlässig machen.

8. Abschluss-Validierung der MVP-Reihenfolge

   • Prüfen, dass Frontend-Flow, Testdatenweg und UI-Automation zusammen funktionieren.

Bezug

• Feature Request: docs/FEATURE_REQUEST_POS_MACHINE_TIME_BILLING.md