Der Kontext.
Ohne die Rohdaten.

Im Mittelpunkt steht eine Zeiterfassung mit mehreren Eingangswegen. Beschäftigte, Büro und professionelle Erfassung sollen nicht durch eine einzige starre Maske abgebildet werden. Scanner- und Terminal-Situationen gehören zum Bedarf. Online- und Offline-Aspekte sowie eine Odoo-Anbindung müssen gemeinsam betrachtet werden. Der End-to-End-Nachweis für reale Hardware bleibt ein eigener Abnahmeschritt.

Zum fachlichen Ziel kommen Umgebung, Betrieb und Übergabe hinzu. Der dokumentierte Kundenwunsch nennt Odoo 19 Community. Im später vorliegenden Implementierungsbestand sind dagegen Odoo 17 und 18 beschrieben. Diese Differenz ist vor dem Pilot ausdrücklich aufzulösen; sie ist kein bereits bestandener Kompatibilitätsnachweis.

Eine erfasste Zeit soll zunächst als Rohzeit nachvollziehbar bleiben. Prüfung, Zuordnung und Freigabe sind fachlich vom endgültigen Buchen zu unterscheiden. Rollen und Verantwortlichkeiten müssen zu diesen Übergängen passen. Die spätere Abnahme soll nicht nur den Normalfall, sondern auch Korrekturen und fehlerhafte Eingänge erfassen.

Übergeben beziehungsweise beschrieben wurden Markenmaterial, vorhandene Mitarbeiter- und Profi-Ansichten, Referenzmasken sowie Scanner- und Terminal-Situationen. Dieses Material dient als fachlicher und gestalterischer Kontext. Fremdkunden-Rohdaten, private Kontaktangaben und Zugänge sind nicht Bestandteil des Berichtspakets. Ein vorhandener Referenzbildschirm belegt keine bereits integrierte Funktion.

PWA-Zwischenstände und ein Brand-Studio machen Bedienwege und Gestaltung sichtbar. Die Oberflächen sind eigene Demoartefakte. Sie können durchgeklickt und diskutiert werden, ohne als produktiv verbundenes Odoo oder als Hersteller-Software ausgegeben zu werden. Für jede Berichtsadaption werden Originalpfad und Änderungen sichtbar gehalten.

Der Schwerpunkt liegt auf Architektur, Modulzuschnitt, Auftragspapieren, Steuerung, Gegenprüfung und Dokumentation. Sieben Odoo-18-CE-Module und der eigenständige Weg bilden den technischen Bestand. Historische PASS-Marken gelten nur für ihren jeweiligen Testumfang. Fehlgeschlagene Zielsystemtests, offene Hardware-Abnahme und noch nicht geschlossene Release-Gates bleiben sichtbar offen.

Es liegt ein überprüfbarer Entwicklungsstand von Lunis Ist-Zeit vor. Der vorgegebene Leistungsrahmen beträgt 40 Stunden; 35 Stunden sind direkt aufgelistet, rund 5 Stunden geschätzt zugeordnet. Bei 150 Euro pro Stunde ergibt sich ein Rechenwert von 6.000 Euro netto, keine Rechnung oder Zahlung. Die nächste Freigabe sollte einen begrenzten Pilot mit eindeutiger Version, klarer Betriebsverantwortung, geschlossenem Datenschutz-Gate und fachlicher Abnahme betreffen.

Vor Pilotbeginn: verbindliches Odoo-Versionsziel festlegen, Zielumgebung herstellen und Installation, Upgrade sowie ORM-Läufe wiederholen. PIN-Hash und Fehlversuchssperre im laufenden System prüfen. Reale Scanner-/Terminal-Eingänge bis zur freigegebenen Buchung testen, einschließlich Wiederholung und Fehlerfällen. Archiv-Allowlist, entpackten Privacy-Scan und korrekte Publisher-Exitcodes sicherstellen. Historische Geheimnisse nach Freigabe behandeln. Nachweise mit Datum, Revision, Testumfang und offenem Rest dokumentieren.