01Fachprinzip belegt
Rohzeit ≠ Buchungszeit
Eine Meldung ist zunächst ein Eingang. Prüfstatus und Freigabe müssen erhalten bleiben, statt die ursprüngliche Meldung unsichtbar in eine endgültige Buchung umzudeuten.
Technik & Ist-Zeit · Kapitel 02
Nicht nur eine Maske.
Ein klarer Fachkern.
Rohzeit, Prüfung und Buchung sind unterschiedliche Zustände. Zwei technische Wege adressieren dieselbe Aufgabe — mit verschiedenen Integrations- und Betriebsfolgen.
7 Module
Odoo 18 Community im Bestand. Zusätzlich ein eigenständiger FastAPI-/SQLite-Weg.
Zwei Wege. Eine fachliche Kette.
Die Zeichnung ist eine aus den Quellen abgeleitete Architekturübersicht, kein Beweis eines vollständig bestandenen Integrationslaufs.
MitarbeiterEinzelne Zeitmeldungen
Profi / BüroPrüfung und Zuordnung
Gruppe / ExterneMehrere Beteiligte
Scanner / TerminalHardware-Abnahme offen
Rohzeit → fachliche Prüfung → freigegebene BuchungArbeitszeit · Pause · Projektbezug · Verteilung · Zusatzkosten · nachvollziehbarer Übergang
Odoo 18 Community7 eigene Module · Odoo-ORM · bestehende ERP-Objekte
Eigenständige AnwendungPython / FastAPI · SQLite · HTML-/PWA-Oberflächen
Offline-Demo ist nicht Offline-ProduktivbetriebDiese Website und die eingebetteten Demo-Oberflächen funktionieren ohne Server. Das beweist weder Odoo-Betrieb ohne Server noch eine produktiv getestete Synchronisation der eigenständigen Anwendung. Doppelklick startet hier die Präsentation, nicht die Odoo-Instanz.
Die sieben Module.
Ein eigener Modulzuschnitt ist im Repository belegt. Die Funktionsbeschreibungen sind bewusst enger als ein pauschales Versprechen von Produktionsreife.
| Technischer Modulname | Verantwortung | Einordnung |
|---|---|---|
lunis_istzeit | Fachlicher Kern Zeit- und Projektbezug der Ist-Zeit-Anwendung | Manifest / Bestand Zielsystem-Abnahme separat |
attendance_crew_capture | Gruppenerfassung Gemeinsame Erfassung für mehrere Beschäftigte | Manifest / Bestand Zielsystem-Abnahme separat |
attendance_segment_ledger | Segmentjournal Nachvollziehbare Rohzeit- und Buchungssegmente | Manifest / Bestand Zielsystem-Abnahme separat |
attendance_percent_allocation | Prozentverteilung Zeitanteile auf Projekte oder Aufgaben verteilen | Manifest / Bestand Zielsystem-Abnahme separat |
attendance_reporting | Auswertung Aufbereitete Zeiten und Summen darstellen | Manifest / Bestand Zielsystem-Abnahme separat |
attendance_terminal_kiosk | Terminal / Kiosk Stationärer Erfassungs- und Anmeldeweg | Manifest / Bestand Zielsystem-Abnahme separat |
attendance_external_link | Externe Verknüpfung Externe Eingänge beziehungsweise Verknüpfungen anbinden | Manifest / Bestand Zielsystem-Abnahme separat |
Versionsklarheit
Sieben Module je Odoo 17 und 18 sind dokumentiert. Ein zusätzliches Theme ist nicht stillschweigend das achte Fachmodul. Die Quelle nennt 15 Manifestdateien und acht eindeutige Modulnamen über den Bestand.
Odoo 19 bleibt eine Entscheidung
Das Kunden-Zielbild vom 30.07.2026 nennt Odoo 19 Community. Dieser Bericht bestätigt weder Installation noch Kompatibilität dieser Version. Vor dem Pilot muss das verbindliche Versionsziel feststehen.
Die Oberfläche selbst erleben.
Groß eingebettet, lokal bedienbar, mit sichtbarer Herkunft. Nutzen Sie „Vollbild“ für den vollständigen Arbeitsraum.
Herkunft oneshot-input/demo-mockup-bericht/mockups/lunis-zeit-pwa-3.html · Originalquelle auf GitHub
Lokale, anonymisierte und auf die aktuelle Marke angepasste Berichtsadaption einer vorhandenen HTML-Demo. Bedienbare Beispieldaten; kein verbundenes Odoo, keine echten Buchungen und keine Kundenabnahme.
Odoo-18-Variante: Codebestand belegt, kein Live-Server in diesem PaketDie eingebetteten UIs sind eigene HTML-/PWA-Demos. Sie dürfen nicht als laufendes Odoo-18-System ausgegeben werden. Installation, ORM-Tests und echte Buchungen gehören in die gesonderte Zielsystem-Abnahme.
Tiefe zeigt sich an den Übergängen.
Der schwierige Teil ist nicht der Startknopf. Es sind die Fehlerfälle, Rollen und Zustandswechsel zwischen Eingabe und verlässlicher Buchung.
02Modulbestand belegt
Gruppe ≠ Einzelkopie
Gruppenerfassung, Prozentzuordnung und Segmente werden durch eigene Module abgebildet. Im Pilot sind Ausnahmen und Korrekturen für mehrere Personen gezielt zu prüfen.
03Laufzeitprüfung offen
Terminal ≠ freier Zugang
Kiosk-PIN-Hash und Fehlversuchssperre sind dokumentiert. Ihre Wirksamkeit gegen das laufende Odoo wurde jedoch nicht nachgewiesen.
04Abnahmekriterium
Offline ≠ synchronisiert
Ein lokal bedienbares HTML beweist nur den lokalen UI-Pfad. Konflikte, doppelte Importe und Wiederanlauf nach Verbindungsausfall brauchen getrennte Tests.
05Zielbild / Prüfung
Korrektur ≠ Überschreiben
Buchungsnähe erfordert nachvollziehbare Änderungen und klare Freigaberollen. Ein sichtbares Journal ersetzt noch keinen vollständig nachgewiesenen Audit-Trail.
06Freigabe offen
Auswertung ≠ Abrechnung
Summen, Projektverteilung und Verkaufssätze werden technisch adressiert. Eine rechtlich und kaufmännisch akzeptierte Abrechnung braucht fachliche Freigabe.
Härtung ohne Schönfärberei.
Dateiänderung, Logiktest und nachgewiesene Laufzeitwirkung sind unterschiedliche Belegstufen.
| Bereich | Dokumentierter Stand | Status | Noch nötig |
|---|---|---|---|
| Lizenzdatei / Manifest | LICENSE ergänzt; Modulmanifeste nennen LGPL-3. | Dateistand belegt | Abhängigkeiten und Auslieferungslizenzen gesondert prüfen. |
| Testserver-Bindung | Bindung an Loopback 127.0.0.1 dokumentiert. | Dateistand belegt | Kein Nachweis einer vollständig gehärteten Produktionsumgebung. |
| Kiosk-PIN | Hashing und Sperre bei Fehlversuchen logisch geprüft. | teilweise | Wirksamkeit im laufenden Odoo und Umgehungsversuche prüfen. |
| Verkaufssatz | Effektiver Verkaufssatz als geprüft beschrieben. | Historischer Test | Nicht mit vollständiger Preis-/Abrechnungsabnahme gleichsetzen. |
| Odoo-ORM-Test | Lauf scheiterte an Auflösung des Datenbank-Hostnamens. | offen | Zielumgebung korrigieren und den Test wirklich ausführen. |
| Geheimnis in Historie | Alte Zugangsinformation in der Git-Historie als offen dokumentiert. | P0 offen | Rotieren und autorisierte Historienbereinigung prüfen; keine Geheimnisse im Bericht. |
| Archiv / Publisher | Spätere Übergabe nennt umgehbaren ZIP-Filter und maskierbare Fehler. | P0 offen | Allowlist, entpackter Scan und echte Exitcode-Prüfung vor Veröffentlichung. |
Ein sinnvoller technischer Abnahmelauf.
Vorschlag für den nächsten Pilot, nicht die Behauptung bereits bestandener Tests.
Zielsystem aufbauen
Version, Module, Datenbank, Rollen und synthetische Stammdaten festhalten.
Erfassungswege prüfen
MA, Profi, Gruppe, externe Eingabe und Opticon separat durchspielen.
Fehler gezielt auslösen
Doppelte Eingabe, Abbruch, falsche PIN, Offline-Wiederholung und Korrektur testen.
Buchung belegen
Ergebnis im Zielsystem, Negativfälle und fachliche Freigabe gemeinsam dokumentieren.