# Technische Spezifikation – Handwerker- und Montageeinsatz-App **Dokumenttyp:** Software Design Specification / Technisches Umsetzungskonzept **Zielgruppe:** Codex, Claude Code, Softwareentwickler und technische Projektleitung **Status:** Entwurf für MVP **Version:** 1.0 **Sprache:** Deutsch --- ## 1. Zielsetzung Ziel ist die Entwicklung einer mandantenfähigen Webanwendung für Handwerks- und Montagebetriebe. Die Anwendung soll den vollständigen Ablauf eines Kunden- oder Baustelleneinsatzes digital unterstützen: 1. Auftragsbestätigung oder Einsatzdokument importieren 2. Auftragsdaten automatisch erkennen 3. Auftrag prüfen und einem Montageteam zuweisen 4. Auftrag auf Tablet oder Smartphone bearbeiten 5. Leistungen, Arbeitszeiten, Material, Fotos und Notizen dokumentieren 6. Tagesbericht oder Abschlussbericht erzeugen 7. Auftrag an das Backoffice zur Abrechnung übergeben 8. Einsatzhistorie je Kunde und Objekt dauerhaft verfügbar halten Für den MVP wird keine native iOS- oder Android-App entwickelt. Die Lösung wird als responsive Progressive Web App, kurz PWA, umgesetzt. --- ## 2. Produktvision Die Anwendung soll keine vollständige ERP-, Buchhaltungs- oder Warenwirtschaftslösung ersetzen. Sie bildet die operative Verbindung zwischen: - Backoffice - Montageteams - Kunden - Baustellen - Objekten - Auftragsdokumenten - Einsatzdokumentation - Abrechnungsvorbereitung Das System soll modular aufgebaut werden, sodass später weitere Funktionen und Schnittstellen ergänzt werden können. Mögliche spätere Erweiterungen: - direkte ERP- und Buchhaltungsschnittstellen - digitale Zeiterfassung - Lager- und Bestandsverwaltung - Artikelstammdaten - Anlagen- und Geräteverwaltung - Wartungsintervalle - Angebots- und Rechnungsstellung - Kundenportal - Tourenplanung - Kalenderintegration - automatische Einsatzplanung - KI-Assistent für Monteure und Backoffice --- ## 3. Grundlegende Architekturentscheidung ### 3.1 Anwendungstyp Der MVP wird als responsive Webanwendung mit PWA-Funktionen umgesetzt. Die Anwendung muss auf folgenden Geräten nutzbar sein: - Desktop-PC - Notebook - iPad - Android-Tablet - iPhone - Android-Smartphone ### 3.2 Vorteile der PWA - keine separate Entwicklung für iOS und Android - Installation auf dem Startbildschirm möglich - Nutzung der Gerätekamera - Nutzung des Mikrofons - lokale Zwischenspeicherung - eingeschränkte Offline-Fähigkeit - zentrale Bereitstellung von Updates - geringerer Entwicklungs- und Wartungsaufwand ### 3.3 Mandantenfähigkeit Die Anwendung muss von Beginn an vollständig mandantenfähig aufgebaut werden. Jeder Handwerksbetrieb stellt einen eigenen Mandanten dar. Mandanten dürfen ausschließlich auf ihre eigenen Daten zugreifen. Eine Vermischung von Daten verschiedener Mandanten muss technisch ausgeschlossen werden. --- ## 4. Rollenmodell ### 4.1 Plattformadministrator Der Plattformadministrator verwaltet die gesamte SaaS-Plattform. Berechtigungen: - Mandanten anlegen - Mandanten deaktivieren - Mandantenadministratoren anlegen - Systemstatus einsehen - globale Systemeinstellungen verwalten - Funktionsmodule je Mandant aktivieren - Speicherverbrauch und Nutzung einsehen - Supportzugriff nach expliziter Freigabe durchführen Der Plattformadministrator soll nicht standardmäßig auf fachliche Mandantendaten zugreifen können. --- ### 4.2 Mandantenadministrator Der Mandantenadministrator verwaltet die Organisation eines Kunden. Berechtigungen: - Benutzer anlegen - Benutzer deaktivieren - Rollen vergeben - Montageteams anlegen - Mitarbeiter Teams zuordnen - Kunden verwalten - Objekte verwalten - Vorlagen verwalten - Auftragsstatus konfigurieren - E-Mail-Empfänger konfigurieren - Unternehmensdaten verwalten - Berichtsvorlagen verwalten - Nummernkreise konfigurieren --- ### 4.3 Backoffice Das Backoffice plant, verwaltet und kontrolliert Aufträge. Berechtigungen: - Auftragsdokumente importieren - erkannte Daten prüfen - Kunden und Objekte anlegen - Aufträge erstellen - Aufträge bearbeiten - Montageteams zuweisen - Dokumente und technische Zeichnungen hinterlegen - Auftragsfortschritt einsehen - Berichte prüfen - Aufträge zur Abrechnung freigeben - Einsatzhistorie einsehen - Notdiensteinsätze nachbearbeiten --- ### 4.4 Monteur Der Monteur bearbeitet zugewiesene Aufträge. Berechtigungen: - eigene und dem Team zugewiesene Aufträge einsehen - Auftragsinformationen anzeigen - Kundendaten und Objektinformationen anzeigen - technische Dokumente und Zeichnungen anzeigen - Einsatz starten und beenden - Arbeitszeiten dokumentieren - Material dokumentieren - Fotos aufnehmen - Notizen erfassen - Sprachnotizen aufnehmen - Tagesberichte erstellen - Abschlussberichte erstellen - Kundenunterschrift erfassen - Notdiensteinsatz anlegen - vorherige freigegebene Einsätze am Objekt einsehen Ein Monteur darf keine Aufträge oder Kundendaten anderer Teams einsehen, sofern ihm hierzu keine zusätzliche Berechtigung erteilt wurde. --- ### 4.5 Teamleiter Der Teamleiter besitzt die Rechte eines Monteurs und zusätzlich: - Teamaufträge einsehen - Aufträge innerhalb des Teams koordinieren - Tagesberichte prüfen - Abschlussberichte freigeben - Teammitglieder einem Einsatz zuordnen - Korrekturen vor Abschluss anfordern --- ## 5. Mandantenmodell Jeder Datensatz muss eindeutig einem Mandanten zugeordnet sein. Dies betrifft insbesondere: - Benutzer - Rollen - Teams - Kunden - Ansprechpartner - Objekte - Aufträge - Einsätze - Berichte - Dokumente - Fotos - Materialien - Benachrichtigungen - Audit-Logs - Vorlagen ### 5.1 Technische Anforderung Jede relevante Datenbanktabelle erhält ein Feld: ```text tenant_id ``` Der Zugriff auf Daten muss serverseitig immer über den aktuellen Mandantenkontext eingeschränkt werden. Eine reine Filterung im Frontend ist nicht ausreichend. ### 5.2 Empfohlene Umsetzung Für den MVP kann eine gemeinsame Datenbank mit mandantenbezogener Datenisolation verwendet werden. Empfehlung: - PostgreSQL - Row-Level Security oder zentraler Repository-Filter - tenant_id in allen fachlichen Tabellen - serverseitige Autorisierungsprüfung bei jedem Zugriff - getrennte Dateipfade oder Buckets je Mandant Später kann optional ein Datenbank-pro-Mandant-Modell ergänzt werden. --- ## 6. Kernmodule des MVP Der MVP besteht aus folgenden Modulen: 1. Benutzer- und Rollenverwaltung 2. Mandantenverwaltung 3. Kundenverwaltung 4. Objektverwaltung 5. Teamverwaltung 6. Auftragsimport 7. Auftragsverwaltung 8. Einsatzbearbeitung 9. Materialdokumentation 10. Foto- und Dokumentenverwaltung 11. Tages- und Abschlussberichte 12. Notdiensteinsätze 13. Objekt- und Einsatzhistorie 14. Benachrichtigungen 15. Audit-Logging 16. PWA- und Offline-Funktionen --- ## 7. Kundenverwaltung ### 7.1 Kundendaten Folgende Daten sollen verwaltet werden: - Kundennummer - Firmenname - Anrede - Vorname - Nachname - Straße - Hausnummer - Postleitzahl - Ort - Land - Telefonnummer - Mobilnummer - E-Mail-Adresse - allgemeine Hinweise - Abrechnungshinweise - Status - Erstellungsdatum - Änderungsdatum ### 7.2 Ansprechpartner Ein Kunde kann mehrere Ansprechpartner besitzen. Daten: - Name - Funktion - Telefonnummer - Mobilnummer - E-Mail-Adresse - bevorzugter Kontaktweg - Bemerkungen ### 7.3 Dublettenprüfung Beim Import eines Auftrags muss geprüft werden, ob der Kunde bereits existiert. Mögliche Vergleichswerte: - Kundennummer - Firmenname - Adresse - E-Mail-Adresse - Telefonnummer Bei unsicherer Übereinstimmung muss das Backoffice entscheiden: - bestehenden Kunden verwenden - neuen Kunden anlegen - Datensätze zusammenführen Eine automatische Zusammenführung darf im MVP nicht ohne Bestätigung erfolgen. --- ## 8. Objektverwaltung Ein Kunde kann mehrere Objekte besitzen. Beispiele: - Baustelle - Filiale - Wohnhaus - Produktionsstandort - Bürogebäude - technische Anlage - Wartungsstandort ### 8.1 Objektdaten - Objektbezeichnung - Kunde - Straße - Hausnummer - Postleitzahl - Ort - Land - Ansprechpartner vor Ort - Telefonnummer - Zugangshinweise - Parkhinweise - Sicherheitsinformationen - allgemeine technische Hinweise - Status - geografische Koordinaten optional ### 8.2 Objektbezogene Dokumente Pro Objekt können Dokumente hinterlegt werden: - technische Zeichnungen - Grundrisse - Schaltpläne - Montageanleitungen - Sicherheitsunterlagen - Produktunterlagen - Kundenhinweise - Fotos vorheriger Einsätze - sonstige PDF-Dateien ### 8.3 Objekt-Historie Die Anwendung muss pro Objekt eine chronologische Einsatzhistorie anzeigen. Anzuzeigen sind: - Datum - Auftrag - Einsatzart - eingesetztes Team - durchgeführte Arbeiten - verwendetes Material - Fotos - Berichte - besondere Hinweise - Kundenunterschrift - Status - offene Folgearbeiten Für den MVP ist keine vollständige Geräte-, Anlagen- oder Seriennummernverwaltung erforderlich. --- ## 9. Auftragsimport per PDF ### 9.1 Ziel Das Backoffice soll Auftragsdaten nicht vollständig manuell erfassen müssen. Eine Auftragsbestätigung oder ein vergleichbares PDF-Dokument wird in die Anwendung hochgeladen. Das System extrahiert daraus möglichst viele relevante Daten und erstellt einen Auftragsentwurf. ### 9.2 Unterstützte Dateien MVP: - PDF mit eingebettetem Text - gescannte PDF-Dateien - optional Bilddateien wie JPG und PNG ### 9.3 Verarbeitung Der Importprozess besteht aus: 1. Datei hochladen 2. Malware- und Dateitypprüfung 3. Texterkennung 4. Dokumentenanalyse 5. strukturierte Datenextraktion 6. Plausibilitätsprüfung 7. Dublettenprüfung 8. Anzeige einer Prüfmaske 9. Bestätigung durch das Backoffice 10. Erstellung oder Zuordnung von Kunde, Objekt und Auftrag ### 9.4 OCR und KI-Extraktion Für gescannte Dokumente wird OCR eingesetzt. Für die strukturierte Extraktion kann ein KI-Modell verwendet werden. Zu extrahierende Felder: - Auftragsnummer - Angebotsnummer - Kundennummer - Firmenname - Kundenadresse - Objektadresse - Ansprechpartner - Telefonnummer - E-Mail-Adresse - Auftragsdatum - geplanter Ausführungszeitraum - Leistungsbeschreibung - Positionen - Mengen - Materialinformationen - besondere Hinweise - Gesamtbetrag optional - Referenzen - Dokumentdatum ### 9.5 Vertrauenswerte Für jedes erkannte Feld soll ein Vertrauenswert gespeichert werden. Beispiel: ```json { "field": "customer_name", "value": "Musterbau GmbH", "confidence": 0.96 } ``` Unsichere Felder müssen in der Prüfmaske hervorgehoben werden. ### 9.6 Manuelle Prüfung Ein importierter Auftrag darf nicht automatisch produktiv freigegeben werden. Status nach Import: ```text Entwurf – Prüfung erforderlich ``` Das Backoffice muss die erkannten Daten bestätigen oder korrigieren. ### 9.7 Originaldokument Das Originaldokument wird dauerhaft am Auftrag gespeichert. Zusätzlich werden gespeichert: - Importdatum - importierender Benutzer - erkannter Text - strukturierte Extraktion - Extraktionsversion - verwendetes Extraktionsmodell - Korrekturen des Benutzers --- ## 10. Auftragsverwaltung ### 10.1 Auftragsdaten - interne Auftrags-ID - externe Auftragsnummer - Mandant - Kunde - Objekt - Ansprechpartner - Auftragsart - Priorität - Status - Beschreibung - Leistungsumfang - geplantes Datum - geplanter Zeitraum - zugewiesenes Team - zuständiger Teamleiter - Dokumente - Materialvorgabe - Pflichtfotos - Pflichtfelder - Unterschrift erforderlich - Abrechnungsart - interne Hinweise - Hinweise für Monteure - Erstellungsdatum - Änderungsdatum ### 10.2 Auftragsarten Beispiele: - Montage - Reparatur - Wartung - Störung - Notdienst - Besichtigung - Abnahme - Nacharbeit Die Auftragsarten sollen je Mandant konfigurierbar sein. ### 10.3 Statusmodell Empfohlene Statuswerte: ```text Entwurf Prüfung erforderlich Geplant Zugewiesen Angenommen In Anfahrt In Bearbeitung Pausiert Wartet auf Material Tagesbericht erstellt Technisch abgeschlossen Unterschrift ausstehend Zur Prüfung Zur Abrechnung freigegeben Abgerechnet Storniert ``` Statusübergänge müssen serverseitig geprüft werden. ### 10.4 Teamzuweisung Ein Auftrag kann einem Montageteam zugewiesen werden. Optional können zusätzlich einzelne Mitarbeiter ausgewählt werden. Ein Team erhält nach Zuweisung eine Benachrichtigung. --- ## 11. Montageteams ### 11.1 Teamdaten - Teamname - Teamleiter - Mitglieder - Status - Telefonnummer - Fahrzeug optional - Einsatzgebiet optional - interne Hinweise ### 11.2 Auftragsansicht Monteure sehen: - heutige Aufträge - kommende Aufträge - laufende Aufträge - pausierte Aufträge - abzuschließende Aufträge - vergangene eigene Aufträge Darstellung als: - Listenansicht - Kalenderansicht optional - Kartenansicht erst nach dem MVP --- ## 12. Einsatzbearbeitung durch Monteure ### 12.1 Einsatzstart Beim Start eines Einsatzes werden gespeichert: - Startzeit - Benutzer - Team - Auftrag - optional Standort - Gerätestatus - Online- oder Offline-Status Optional kann ein Status „In Anfahrt“ vor dem eigentlichen Arbeitsbeginn gesetzt werden. ### 12.2 Arbeitszeiten Ein Einsatz kann mehrere Zeitabschnitte besitzen. Beispiele: - Anfahrt - Arbeitszeit - Pause - Materialbeschaffung - Rückfahrt - Unterbrechung Für den MVP genügt eine einfache Start-, Pause- und Stopp-Funktion. Manuelle Korrekturen müssen protokolliert werden. ### 12.3 Tätigkeitsdokumentation Monteure können dokumentieren: - durchgeführte Arbeiten - Abweichungen vom Auftrag - Probleme - zusätzliche Leistungen - nicht ausführbare Arbeiten - erforderliche Folgearbeiten - Empfehlungen - Kundenhinweise Eingabemöglichkeiten: - Text - strukturierte Auswahlfelder - Sprachnotiz - Foto ### 12.4 Checklisten Ein Auftrag kann eine Checkliste enthalten. Beispiele: - Anlage spannungsfrei geschaltet - Arbeitsbereich abgesichert - Material geprüft - Funktionsprüfung durchgeführt - Arbeitsbereich gereinigt - Kunde eingewiesen - Pflichtfotos erstellt Checklisten können je Auftragsart als Vorlage definiert werden. --- ## 13. Materialdokumentation ### 13.1 Materialvorgabe Das Backoffice kann geplantes Material am Auftrag hinterlegen. Felder: - Bezeichnung - Artikelnummer optional - geplante Menge - Einheit - Bemerkung ### 13.2 Tatsächlich verwendetes Material Der Monteur bestätigt oder ändert je Position: - vollständig verwendet - teilweise verwendet - nicht verwendet - zusätzlich verwendet Zu erfassen: - tatsächliche Menge - Einheit - Begründung bei Abweichung - Foto optional - Notiz optional ### 13.3 Zusatzmaterial Monteure können nicht geplantes Material ergänzen. Felder: - Bezeichnung - Artikelnummer optional - Menge - Einheit - Grund - Foto optional ### 13.4 MVP-Abgrenzung Im MVP erfolgt keine automatische Lagerbuchung. Die Materialdokumentation dient: - dem Arbeitsnachweis - der Abrechnungsvorbereitung - der Nachkalkulation - der Information des Backoffice --- ## 14. Foto- und Dateidokumentation ### 14.1 Fotofunktionen Monteure können Fotos: - direkt mit der Kamera aufnehmen - aus der Galerie auswählen - einem Auftrag zuordnen - einer Checklistenposition zuordnen - als Vorher-, Während- oder Nachher-Foto kennzeichnen - mit Kommentar versehen ### 14.2 Pflichtfotos Das Backoffice kann Pflichtfotos definieren. Beispiele: - Ausgangszustand - Typenschild - Leitungsverlauf - Zwischenschritt - fertige Montage - Funktionsprüfung - Arbeitsbereich nach Abschluss Ein Auftrag kann nicht abgeschlossen werden, wenn verpflichtende Fotos fehlen. ### 14.3 Metadaten Zu jedem Foto werden gespeichert: - Auftrag - Einsatz - Benutzer - Zeitstempel - Kategorie - Kommentar - Dateigröße - MIME-Type - optional Standort - Uploadstatus - Prüfsumme ### 14.4 Bildoptimierung Bilder sollen vor dem Upload komprimiert werden. Das Original kann optional erhalten bleiben. Empfehlung: - Vorschaubild - optimierte Arbeitskopie - optional Originaldatei --- ## 15. Sprachaufnahmen und KI-Unterstützung ### 15.1 Sprachnotizen Monteure können Sprachnotizen aufnehmen. Das System speichert: - Audiodatei - Transkription - Zeitstempel - Benutzer - Bezug zum Auftrag oder Einsatz ### 15.2 KI-Verarbeitung Die KI kann aus den vorhandenen Informationen einen Berichtsentwurf erstellen. Datenquellen: - Auftragsbeschreibung - Tätigkeitsnotizen - Sprachnotizen - Checklisten - Materialabweichungen - Fotos und Bildkommentare - Arbeitszeiten - offene Folgearbeiten ### 15.3 Freigabeprinzip KI-generierte Inhalte dürfen nicht automatisch als endgültiger Bericht versendet werden. Der Monteur oder das Backoffice muss den Bericht prüfen und freigeben. ### 15.4 Transparenz KI-generierte Texte werden als Entwurf gekennzeichnet. Die ursprünglichen Notizen bleiben erhalten. --- ## 16. Tagesbericht ### 16.1 Zweck Ein Tagesbericht wird erstellt, wenn ein Auftrag über mehrere Tage läuft oder noch nicht abgeschlossen wurde. ### 16.2 Inhalte - Kunde - Objekt - Auftrag - Datum - eingesetzte Mitarbeiter - Arbeitszeiten - durchgeführte Tätigkeiten - verwendetes Material - Fotos - Abweichungen - Probleme - offene Punkte - geplante nächste Schritte - Status - Unterschrift optional ### 16.3 Ablauf 1. Monteur beendet den Arbeitstag 2. System prüft Pflichtangaben 3. Berichtsentwurf wird erzeugt 4. Monteur prüft und ergänzt 5. Bericht wird gespeichert 6. Backoffice wird optional informiert 7. Auftrag bleibt geöffnet --- ## 17. Abschlussbericht und Arbeitsnachweis ### 17.1 Zweck Der Abschlussbericht dient als: - Leistungsnachweis - Montagebericht - Arbeitsnachweis - Grundlage für die Rechnungsstellung - interne Dokumentation - Kundendokumentation ### 17.2 Inhalte - Logo und Unternehmensdaten des Mandanten - Kunde - Objekt - Ansprechpartner - Auftragsnummer - Einsatzdatum - eingesetzte Mitarbeiter - Arbeitszeiten - Auftragsbeschreibung - ausgeführte Leistungen - Abweichungen - Zusatzleistungen - verwendetes Material - nicht verwendetes Material - offene Restarbeiten - Hinweise - Fotos - Kundenunterschrift - Name des Unterzeichners - Datum und Uhrzeit - Name des Monteurs - Berichtsversion ### 17.3 PDF-Erstellung Nach Freigabe wird ein nicht veränderbares PDF erzeugt. Das PDF wird: - am Auftrag gespeichert - in der Objekt-Historie abgelegt - dem Backoffice zur Verfügung gestellt - optional per E-Mail versendet ### 17.4 Versionierung Änderungen nach Freigabe erzeugen eine neue Berichtsversion. Bereits freigegebene Versionen dürfen nicht überschrieben werden. --- ## 18. Digitale Kundenunterschrift ### 18.1 Funktionen Der Kunde kann auf dem Tablet oder Smartphone unterschreiben. Zusätzlich werden erfasst: - Name des Unterzeichners - Funktion optional - Datum - Uhrzeit - Bestätigungstext - Bezug zum Bericht - Benutzer, der die Unterschrift aufgenommen hat ### 18.2 Ablehnung oder Abwesenheit Folgende Optionen müssen vorhanden sein: - Kunde nicht anwesend - Kunde verweigert Unterschrift - Unterschrift wird später eingeholt - Unterschrift nicht erforderlich Eine Begründung kann verpflichtend sein. --- ## 19. Notdiensteinsatz ### 19.1 Ziel Ein Monteur muss außerhalb der Geschäftszeiten selbstständig einen neuen Einsatz anlegen können. ### 19.2 Erfassungsmaske Pflichtfelder: - Kunde - Objekt oder Einsatzadresse - Ansprechpartner - Telefonnummer - Grund des Notdiensteinsatzes - Beginn - Team oder Monteur Optionale Felder: - bestehender Kunde auswählen - neuen vorläufigen Kunden anlegen - vorhandenes Objekt auswählen - Fotos - Sprachnotiz - Material - Tätigkeiten - Kundenunterschrift ### 19.3 Vorläufige Datensätze Falls der Kunde noch nicht existiert, wird ein vorläufiger Kundendatensatz angelegt. Status: ```text Vorläufig – Prüfung durch Backoffice erforderlich ``` Das Backoffice kann am nächsten Arbeitstag: - Kunden bestätigen - bestehenden Kunden zuordnen - Dublette zusammenführen - Objekt korrigieren - Auftrag ergänzen - Abrechnung freigeben ### 19.4 Benachrichtigung Nach Abschluss eines Notdiensteinsatzes wird das Backoffice automatisch informiert. Beispiel: ```text Neuer Notdiensteinsatz abgeschlossen Monteur: Martin Solarczek Kunde: Lutz Meier Einsatzbeginn: 28.07.2026, 23:42 Uhr Einsatzende: 29.07.2026, 01:18 Uhr Status: Zur Prüfung und Abrechnung ``` Benachrichtigungskanäle im MVP: - E-Mail - interne Benachrichtigung im Dashboard Push-Benachrichtigungen können später ergänzt werden. --- ## 20. Benachrichtigungen ### 20.1 Ereignisse Benachrichtigungen sollen unter anderem ausgelöst werden bei: - neuer Teamzuweisung - Änderung eines Auftrags - Auftrag storniert - Auftrag gestartet - Tagesbericht erstellt - Auftrag technisch abgeschlossen - Unterschrift fehlt - Bericht zur Prüfung eingereicht - Auftrag zur Abrechnung freigegeben - Notdiensteinsatz erstellt - Notdiensteinsatz abgeschlossen - Pflichtangaben fehlen - Synchronisationsfehler ### 20.2 Kanäle MVP: - In-App-Benachrichtigung - E-Mail Später: - Web Push - SMS - Microsoft Teams - Slack - ERP-Webhook --- ## 21. Backoffice-Dashboard Das Dashboard zeigt mindestens: - offene Aufträge - heutige Einsätze - laufende Einsätze - nicht angenommene Aufträge - überfällige Aufträge - Berichte zur Prüfung - abgeschlossene Aufträge - Aufträge zur Abrechnung - neue Notdiensteinsätze - fehlende Unterschriften - Synchronisationsfehler Filter: - Zeitraum - Kunde - Objekt - Team - Monteur - Status - Auftragsart - Priorität --- ## 22. Mobile Auftragsansicht Die mobile Ansicht muss für die Bedienung auf Baustellen optimiert sein. Anforderungen: - große Schaltflächen - geringe Texteingabe - klare Statusanzeige - gute Lesbarkeit bei Tageslicht - wenige Navigationsebenen - Kamera direkt erreichbar - Materialerfassung mit wenigen Eingaben - automatische Zwischenspeicherung - Offline-Hinweis - Synchronisationsstatus sichtbar Empfohlene Hauptnavigation: ```text Heute Aufträge Notdienst Synchronisation Profil ``` --- ## 23. Offline-Fähigkeit ### 23.1 Ziel Ein Auftrag soll auch bei schlechter oder fehlender Internetverbindung bearbeitet werden können. ### 23.2 Offline verfügbare Daten Vor einem Einsatz sollen lokal gespeichert werden: - Auftragsdaten - Kundendaten - Objektdaten - Ansprechpartner - Checklisten - Materialvorgaben - relevante Dokumente - technische Zeichnungen - letzte freigegebene Einsatzberichte - notwendige Vorlagen ### 23.3 Offline erfassbare Daten - Arbeitsbeginn und Arbeitsende - Tätigkeitsnotizen - Checklisten - Material - Fotos - Sprachnotizen - Unterschrift - Tagesbericht - Abschlussbericht ### 23.4 Synchronisation Lokale Änderungen werden in einer Warteschlange gespeichert. Sobald eine Internetverbindung vorhanden ist, erfolgt die Synchronisation. Jede Änderung erhält: - lokale ID - Server-ID nach Synchronisation - Zeitstempel - Benutzer - Versionsnummer - Synchronisationsstatus - Fehlerstatus ### 23.5 Konfliktbehandlung Bei Konflikten gilt: - Daten dürfen nicht stillschweigend überschrieben werden - Konflikte werden protokolliert - konfliktfreie Felder werden automatisch synchronisiert - kritische Konflikte müssen im Backoffice geprüft werden --- ## 24. Dokumentenverwaltung ### 24.1 Dokumentkategorien - Auftragsbestätigung - technische Zeichnung - Montageanleitung - Sicherheitsunterlage - Arbeitsnachweis - Tagesbericht - Abschlussbericht - Kundenfreigabe - Foto - sonstiges Dokument ### 24.2 Versionierung Dokumente müssen versionierbar sein. Zu speichern: - Version - Dateiname - Kategorie - Ersteller - Uploaddatum - Änderungsdatum - Freigabestatus - Prüfsumme ### 24.3 Zugriffsrechte Dokumente können markiert werden als: - nur Backoffice - für Teamleiter - für Montageteam - für Kundenbericht freigegeben --- ## 25. Suche Die Anwendung benötigt eine mandantenbezogene Suche. Suchbereiche: - Kunden - Objekte - Aufträge - Einsatzberichte - Auftragsnummern - Ansprechpartner - Adressen - Dokumentnamen - Notizen Filterbare Suchergebnisse: - Zeitraum - Kunde - Objekt - Auftragsart - Status - Team - Monteur Eine KI-basierte semantische Suche ist nicht Bestandteil des MVP, kann aber später ergänzt werden. --- ## 26. Audit-Logging Sicherheits- und fachlich relevante Aktionen müssen protokolliert werden. Beispiele: - Anmeldung - fehlgeschlagene Anmeldung - Benutzer angelegt - Rolle geändert - Auftrag importiert - Extraktionsdaten geändert - Auftrag zugewiesen - Status geändert - Arbeitszeit korrigiert - Material geändert - Bericht freigegeben - PDF erzeugt - Dokument gelöscht - Unterschrift erfasst - Mandanteneinstellung geändert Ein Audit-Log enthält: - Mandant - Benutzer - Aktion - Objektart - Objekt-ID - Zeitstempel - alte Werte - neue Werte - IP-Adresse - User-Agent - Ergebnis Audit-Logs dürfen durch normale Benutzer nicht verändert oder gelöscht werden. --- ## 27. Datenschutz und Informationssicherheit ### 27.1 Grundprinzipien - Datenschutz durch Technikgestaltung - Mandantentrennung - minimale Berechtigungen - verschlüsselte Datenübertragung - verschlüsselte Speicherung sensibler Daten - sichere Passworthashes - revisionsfähige Protokollierung - definierte Löschfristen - Datensicherung - Wiederherstellbarkeit ### 27.2 Authentifizierung MVP: - E-Mail-Adresse und Passwort - sichere Passwortanforderungen - Passwort-Reset - Sitzungsverwaltung - optional verpflichtende Mehrfaktor-Authentifizierung für Administratoren Empfehlung: - MFA von Beginn an technisch vorbereiten - später Microsoft Entra ID und weitere Identity Provider über OIDC integrieren ### 27.3 Autorisierung Autorisierung muss serverseitig erfolgen. Prüfung mindestens auf: - Mandant - Rolle - Team - Auftragszuweisung - Dokumentenfreigabe - Aktion ### 27.4 Dateisicherheit - erlaubte Dateitypen einschränken - Dateigröße begrenzen - MIME-Type prüfen - Dateinamen normalisieren - Malware-Scan - direkte öffentliche Dateilinks vermeiden - zeitlich begrenzte Download-URLs verwenden ### 27.5 Löschkonzept Daten dürfen nicht ausschließlich durch hartes Löschen entfernt werden. Für fachliche Datensätze wird zunächst Soft Delete verwendet. Berichte und abrechnungsrelevante Nachweise erhalten mandantenbezogene Aufbewahrungsfristen. --- ## 28. Datenmodell – Hauptentitäten ### 28.1 Tenant ```text Tenant - id - name - slug - status - settings - created_at - updated_at ``` ### 28.2 User ```text User - id - tenant_id - email - password_hash - first_name - last_name - phone - status - last_login_at - created_at - updated_at ``` ### 28.3 Role ```text Role - id - tenant_id - name - permissions ``` ### 28.4 Team ```text Team - id - tenant_id - name - leader_user_id - status ``` ### 28.5 TeamMember ```text TeamMember - team_id - user_id - valid_from - valid_to ``` ### 28.6 Customer ```text Customer - id - tenant_id - customer_number - company_name - first_name - last_name - address - contact_data - status - is_provisional ``` ### 28.7 Site ```text Site - id - tenant_id - customer_id - name - address - contact_person_id - access_notes - safety_notes - technical_notes ``` ### 28.8 WorkOrder ```text WorkOrder - id - tenant_id - customer_id - site_id - external_order_number - order_type - priority - status - title - description - planned_start - planned_end - assigned_team_id - signature_required - source_document_id ``` ### 28.9 WorkSession ```text WorkSession - id - tenant_id - work_order_id - user_id - team_id - type - started_at - ended_at - status ``` ### 28.10 MaterialPlan ```text MaterialPlan - id - tenant_id - work_order_id - name - article_number - planned_quantity - unit ``` ### 28.11 MaterialUsage ```text MaterialUsage - id - tenant_id - work_order_id - material_plan_id - name - article_number - actual_quantity - unit - usage_status - deviation_reason ``` ### 28.12 Report ```text Report - id - tenant_id - work_order_id - type - version - status - content - pdf_document_id - approved_by - approved_at ``` ### 28.13 Document ```text Document - id - tenant_id - customer_id - site_id - work_order_id - category - file_name - storage_key - mime_type - file_size - checksum - version - visibility ``` ### 28.14 Notification ```text Notification - id - tenant_id - user_id - type - title - message - read_at - sent_at ``` ### 28.15 AuditLog ```text AuditLog - id - tenant_id - user_id - action - entity_type - entity_id - old_values - new_values - ip_address - user_agent - created_at ``` --- ## 29. API-Konzept Die Anwendung soll über eine versionierte API verfügen. Beispiel: ```text /api/v1/ ``` ### 29.1 Beispiel-Endpunkte ```text POST /api/v1/auth/login POST /api/v1/auth/logout POST /api/v1/auth/refresh GET /api/v1/customers POST /api/v1/customers GET /api/v1/customers/{id} PATCH /api/v1/customers/{id} GET /api/v1/sites POST /api/v1/sites GET /api/v1/sites/{id}/history GET /api/v1/work-orders POST /api/v1/work-orders GET /api/v1/work-orders/{id} PATCH /api/v1/work-orders/{id} POST /api/v1/work-orders/{id}/assign POST /api/v1/work-orders/{id}/start POST /api/v1/work-orders/{id}/pause POST /api/v1/work-orders/{id}/complete POST /api/v1/work-orders/import GET /api/v1/imports/{id} POST /api/v1/imports/{id}/confirm POST /api/v1/work-orders/{id}/materials POST /api/v1/work-orders/{id}/photos POST /api/v1/work-orders/{id}/voice-notes POST /api/v1/work-orders/{id}/daily-report POST /api/v1/work-orders/{id}/completion-report POST /api/v1/reports/{id}/approve GET /api/v1/reports/{id}/pdf POST /api/v1/emergency-orders POST /api/v1/sync ``` ### 29.2 API-Anforderungen - REST oder vergleichbares klar definiertes API-Modell - OpenAPI-Dokumentation - konsistente Fehlercodes - Pagination - Filter - Sortierung - Idempotency Keys für kritische mobile Aktionen - Rate Limiting - Mandantenprüfung - Rollenprüfung - Audit-Logging --- ## 30. Technologievorschlag Der konkrete Stack kann angepasst werden. ### 30.1 Frontend Empfehlung: - Next.js oder React - TypeScript - responsive UI-Komponenten - PWA Service Worker - IndexedDB für Offline-Daten - React Query oder vergleichbare Datenabstraktion - Formularvalidierung mit Zod - PDF- und Bildvorschau ### 30.2 Backend Mögliche Varianten: **Variante A** - TypeScript - NestJS - Prisma ORM - PostgreSQL **Variante B** - Python - FastAPI - SQLAlchemy - PostgreSQL Für eine einheitliche TypeScript-Codebasis wird Variante A empfohlen. ### 30.3 Dateispeicher - S3-kompatibler Object Storage - MinIO für lokale oder selbst gehostete Umgebungen - alternativ Cloudflare R2, AWS S3 oder Azure Blob Storage ### 30.4 Hintergrundverarbeitung Für folgende Aufgaben ist eine Job Queue erforderlich: - OCR - KI-Extraktion - Transkription - PDF-Erstellung - Bildoptimierung - E-Mail-Versand - Benachrichtigungen - Synchronisationsnachverarbeitung Mögliche Technologien: - Redis - BullMQ - Celery bei Python - RabbitMQ optional ### 30.5 Bereitstellung Empfehlung: - Docker - Docker Compose für Entwicklung - Coolify für Hosting - PostgreSQL - Redis - Object Storage - Reverse Proxy - TLS - getrennte Entwicklungs-, Test- und Produktionsumgebung --- ## 31. KI- und OCR-Abstraktion KI- und OCR-Funktionen dürfen nicht fest mit einem einzigen Anbieter verbunden werden. Es wird eine Provider-Abstraktion empfohlen. Beispiel: ```typescript interface DocumentExtractionProvider { extractText(file: Buffer): Promise; extractStructuredData(text: string): Promise; } ``` Mögliche Provider: - Azure AI Document Intelligence - Google Document AI - AWS Textract - Tesseract OCR - OpenAI - Anthropic - lokales Sprachmodell Konfiguration je Mandant oder Plattform: - Provider - Modell - Region - Datenschutzoptionen - Aufbewahrung - maximale Dateigröße - Kostenlimit --- ## 32. PDF-Berichtsgenerierung Berichte sollen über HTML-Templates erzeugt und als PDF gerendert werden. Mögliche Technologien: - Playwright - Puppeteer - serverseitige HTML-zu-PDF-Engine Vorteile: - anpassbares Layout - Mandantenlogo - individuelle Berichtsvorlagen - saubere Seitenumbrüche - Fotoübersichten - Unterschriftenintegration Jeder erzeugte Bericht erhält: - eindeutige Bericht-ID - Versionsnummer - Erstellungsdatum - Prüfsumme - Freigabestatus --- ## 33. E-Mail-Versand ### 33.1 E-Mail-Ereignisse - Teamzuweisung - Bericht zur Prüfung - Auftrag zur Abrechnung - Notdiensteinsatz - Fehler bei der Dokumentverarbeitung ### 33.2 Konfiguration Je Mandant konfigurierbar: - Absendername - Absenderadresse - Empfänger für Notdienste - Empfänger für Abrechnung - Antwortadresse - E-Mail-Vorlagen ### 33.3 Technische Umsetzung Mögliche Anbindung: - SMTP - Microsoft Graph - Amazon SES - Mailgun - Postmark E-Mails werden über eine Warteschlange versendet. Versandstatus und Fehler werden protokolliert. --- ## 34. Nichtfunktionale Anforderungen ### 34.1 Performance - Standardseiten sollen innerhalb von zwei Sekunden reagieren - Auftragslisten müssen paginiert werden - Bilder werden asynchron geladen - große Dokumente werden im Hintergrund verarbeitet - Uploadfortschritt muss sichtbar sein ### 34.2 Verfügbarkeit Für den MVP wird eine Zielverfügbarkeit von 99,5 Prozent empfohlen. ### 34.3 Skalierbarkeit Die Architektur muss horizontal erweiterbar sein. Insbesondere: - stateless Backend - externer Dateispeicher - zentrale Datenbank - Redis oder Queue-System - getrennte Worker ### 34.4 Browserunterstützung - aktuelle Version von Chrome - aktuelle Version von Edge - aktuelle Version von Safari - aktuelle Version von Firefox - mobile Browser unter iOS und Android ### 34.5 Barrierearme Bedienung - ausreichende Kontraste - verständliche Beschriftungen - Tastaturbedienung im Backoffice - große Touch-Ziele - Fehlermeldungen in Klartext --- ## 35. MVP-Abgrenzung Nicht Bestandteil des initialen MVP: - native iOS-App - native Android-App - vollständige Lagerverwaltung - automatische Bestandsbuchung - vollständige Anlagenverwaltung - Seriennummern- und Gerätehistorie - Rechnungsstellung - Finanzbuchhaltung - direkte DATEV-Schnittstelle - direkte ERP-Schnittstellen - automatische Tourenoptimierung - GPS-Dauertracking - Fahrzeugverwaltung - Kundenportal - Lieferantenportal - automatische Angebotserstellung - komplexe Ressourcenplanung - Lohnabrechnung - vollautomatische KI-Freigaben - semantische Suche über alle Dokumente --- ## 36. Priorisierung ### 36.1 Muss-Funktionen für den MVP - Multitenancy - Benutzer und Rollen - Kunden - Objekte - Teams - PDF-Import - OCR und Datenextraktion - manuelle Prüfmaske - Aufträge - Teamzuweisung - mobile PWA - eingeschränkte Offline-Nutzung - Arbeitszeiten - Tätigkeitsdokumentation - Materialdokumentation - Fotos - Checklisten - Tagesbericht - Abschlussbericht - PDF-Erstellung - Kundenunterschrift - Notdiensteinsatz - Backoffice-Benachrichtigung - Objekt-Historie - technische Dokumente - Audit-Logging ### 36.2 Soll-Funktionen - Sprachnotizen - Transkription - KI-Berichtsentwurf - konfigurierbare Vorlagen - E-Mail-Versand von Berichten - Berichtsversionierung - MFA - Kartenlink zur Einsatzadresse ### 36.3 Kann-Funktionen - Push-Benachrichtigungen - Kalenderansicht - Standorterfassung beim Einsatzstart - Barcode- oder QR-Code-Erfassung - kundenspezifische Statusmodelle - digitale Einsatzfreigabe durch Teamleiter --- ## 37. User Stories ### US-001 – Mandant anlegen **Als Plattformadministrator** möchte ich einen neuen Handwerksbetrieb als Mandanten anlegen, damit dieser die Anwendung mit vollständig getrennten Daten nutzen kann. **Akzeptanzkriterien:** - Mandant erhält eine eindeutige ID - Mandantenadministrator kann angelegt werden - Daten anderer Mandanten sind nicht sichtbar - Mandant kann deaktiviert werden --- ### US-002 – Auftragsbestätigung importieren **Als Backoffice-Mitarbeiter** möchte ich eine Auftragsbestätigung als PDF hochladen, damit Kunden-, Objekt- und Auftragsdaten automatisch übernommen werden. **Akzeptanzkriterien:** - PDF kann hochgeladen werden - Text wird erkannt - strukturierte Felder werden extrahiert - unsichere Felder werden markiert - Daten können korrigiert werden - Auftrag wird erst nach Bestätigung angelegt - Originaldokument bleibt gespeichert --- ### US-003 – Bestehenden Kunden erkennen **Als Backoffice-Mitarbeiter** möchte ich beim Import erkennen, ob der Kunde bereits existiert, damit keine unnötigen Dubletten entstehen. **Akzeptanzkriterien:** - System prüft Kundennummer, Name und Adresse - mögliche Treffer werden angezeigt - Benutzer entscheidet über Zuordnung - keine automatische Zusammenführung ohne Bestätigung --- ### US-004 – Auftrag einem Team zuweisen **Als Backoffice-Mitarbeiter** möchte ich einen Auftrag einem Montageteam zuweisen, damit das Team den Auftrag auf dem Tablet bearbeiten kann. **Akzeptanzkriterien:** - Team kann ausgewählt werden - Auftrag erscheint in der mobilen Ansicht - Team wird benachrichtigt - Zuweisung wird protokolliert --- ### US-005 – Technische Unterlagen ansehen **Als Monteur** möchte ich technische Zeichnungen und frühere Einsatzberichte am Objekt ansehen, damit ich den aktuellen Einsatz korrekt durchführen kann. **Akzeptanzkriterien:** - relevante Dokumente sind am Auftrag sichtbar - freigegebene frühere Berichte sind sichtbar - Dokumente können vorab offline gespeichert werden - Backoffice-interne Dokumente bleiben verborgen --- ### US-006 – Einsatz dokumentieren **Als Monteur** möchte ich Arbeiten, Zeiten, Fotos, Material und Notizen erfassen, damit ein vollständiger Arbeitsnachweis entsteht. **Akzeptanzkriterien:** - Einsatz kann gestartet und beendet werden - Fotos können aufgenommen werden - Materialmengen können bestätigt oder geändert werden - Zusatzmaterial kann erfasst werden - Notizen bleiben bei Verbindungsabbruch erhalten --- ### US-007 – Tagesbericht erstellen **Als Monteur** möchte ich am Ende eines Arbeitstages einen Tagesbericht erstellen, damit der Fortschritt eines mehrtägigen Auftrags dokumentiert ist. **Akzeptanzkriterien:** - Bericht enthält Arbeitszeiten und Tätigkeiten - offene Punkte können dokumentiert werden - Fotos können eingebunden werden - Auftrag bleibt geöffnet - Bericht erscheint in der Objekt-Historie --- ### US-008 – Abschlussbericht erstellen **Als Monteur** möchte ich nach Abschluss einen Bericht erzeugen, damit der Kunde und das Backoffice einen Leistungsnachweis erhalten. **Akzeptanzkriterien:** - Pflichtangaben werden geprüft - Pflichtfotos werden geprüft - Materialabweichungen sind enthalten - Kundenunterschrift kann erfasst werden - PDF wird erzeugt - Auftrag erhält den Status „Zur Prüfung“ --- ### US-009 – Auftrag zur Abrechnung freigeben **Als Backoffice-Mitarbeiter** möchte ich einen abgeschlossenen Auftrag prüfen und zur Abrechnung freigeben, damit die Rechnung erstellt werden kann. **Akzeptanzkriterien:** - Bericht ist einsehbar - Arbeitszeiten sind einsehbar - Material ist einsehbar - Bericht kann freigegeben oder zurückgewiesen werden - Freigabe wird protokolliert - zuständige Stelle wird benachrichtigt --- ### US-010 – Notdiensteinsatz anlegen **Als Monteur** möchte ich außerhalb der Geschäftszeiten selbst einen Notdiensteinsatz anlegen, damit der Einsatz vollständig dokumentiert und später abgerechnet werden kann. **Akzeptanzkriterien:** - bestehender Kunde kann ausgewählt werden - vorläufiger Kunde kann angelegt werden - Objekt oder Einsatzadresse kann erfasst werden - Zeiten, Tätigkeiten, Material und Fotos können dokumentiert werden - Abschlussbericht kann erstellt werden - Backoffice wird automatisch informiert - Einsatz ist am nächsten Arbeitstag zur Prüfung sichtbar --- ### US-011 – Objekt-Historie aufrufen **Als Monteur oder Backoffice-Mitarbeiter** möchte ich die bisherigen Einsätze eines Objekts einsehen, damit frühere Arbeiten und technische Hinweise berücksichtigt werden. **Akzeptanzkriterien:** - chronologische Liste aller freigegebenen Einsätze - Berichte und Fotos sind abrufbar - verwendetes Material ist sichtbar - offene Folgearbeiten werden hervorgehoben --- ### US-012 – Offline arbeiten **Als Monteur** möchte ich einen Auftrag ohne stabile Internetverbindung bearbeiten, damit die Dokumentation auf Baustellen nicht unterbrochen wird. **Akzeptanzkriterien:** - Auftragsdaten sind offline verfügbar - Eingaben werden lokal gespeichert - Fotos werden in die Uploadwarteschlange aufgenommen - Synchronisationsstatus ist sichtbar - Daten werden nach Wiederherstellung der Verbindung übertragen - Konflikte werden nicht stillschweigend überschrieben --- ## 38. Beispielprozess – regulärer Auftrag ```text Backoffice lädt Auftragsbestätigung hoch ↓ OCR und KI extrahieren Daten ↓ Backoffice prüft Kunden-, Objekt- und Auftragsdaten ↓ Bestehender Kunde und bestehendes Objekt werden zugeordnet ↓ Auftrag wird einem Montageteam zugewiesen ↓ Team lädt Auftrag und Dokumente auf das Tablet ↓ Monteur startet Einsatz ↓ Arbeiten, Zeiten, Material, Fotos und Notizen werden erfasst ↓ Monteur erstellt Abschlussbericht ↓ Kunde unterschreibt ↓ PDF-Arbeitsnachweis wird erzeugt ↓ Backoffice prüft Bericht ↓ Auftrag wird zur Abrechnung freigegeben ↓ Einsatz erscheint in der Objekt-Historie ``` --- ## 39. Beispielprozess – Notdiensteinsatz ```text Monteur erhält außerhalb der Geschäftszeit einen Anruf ↓ Monteur öffnet „Notdienst“ ↓ Bestehender Kunde wird ausgewählt oder vorläufig angelegt ↓ Einsatzadresse und Störungsgrund werden erfasst ↓ Einsatz wird gestartet ↓ Arbeiten, Material, Fotos und Zeiten werden dokumentiert ↓ Kunde unterschreibt oder Abwesenheit wird dokumentiert ↓ Abschlussbericht wird erzeugt ↓ Backoffice erhält E-Mail und In-App-Benachrichtigung ↓ Backoffice prüft am nächsten Arbeitstag die Stammdaten ↓ Auftrag wird zur Abrechnung freigegeben ``` --- ## 40. Akzeptanzkriterien für den Gesamt-MVP Der MVP gilt als fachlich abnahmefähig, wenn: 1. mehrere Mandanten mit sicher getrennter Datenhaltung betrieben werden können 2. Benutzer, Rollen und Montageteams verwaltet werden können 3. Auftragsbestätigungen als PDF importiert werden können 4. Kunden-, Objekt- und Auftragsdaten automatisiert extrahiert werden 5. das Backoffice die erkannten Daten prüfen und korrigieren kann 6. Aufträge Teams zugewiesen werden können 7. Monteure Aufträge auf Tablets und Smartphones bearbeiten können 8. wesentliche Daten offline erfasst werden können 9. Arbeitszeiten, Tätigkeiten, Material und Fotos dokumentiert werden können 10. Tagesberichte erzeugt werden können 11. Abschlussberichte inklusive Kundenunterschrift erzeugt werden können 12. ein PDF-Arbeitsnachweis erstellt wird 13. das Backoffice abgeschlossene Aufträge zur Abrechnung freigeben kann 14. Monteure selbstständig Notdiensteinsätze anlegen können 15. das Backoffice über Notdiensteinsätze informiert wird 16. frühere Einsätze und technische Dokumente pro Objekt abrufbar sind 17. relevante Änderungen revisionsfähig protokolliert werden --- ## 41. Empfohlene Entwicklungsphasen ### Phase 0 – Technische Basis - Repository - CI/CD - Docker - Datenbank - Authentifizierung - Mandantenkontext - Rollen und Berechtigungen - Logging - Object Storage - Grundlayout ### Phase 1 – Stammdaten und Aufträge - Kunden - Ansprechpartner - Objekte - Teams - Benutzer - Aufträge - Statusmodell - Dokumentenupload - Teamzuweisung ### Phase 2 – PDF-Import - Upload - OCR - Extraktion - Prüfmaske - Dublettenprüfung - Auftragsentwurf - Originaldokument ### Phase 3 – Mobile Einsatzbearbeitung - PWA - mobile Auftragsliste - Einsatzstart - Arbeitszeiten - Checklisten - Material - Fotos - Notizen - Offline-Speicherung ### Phase 4 – Berichte - Tagesbericht - Abschlussbericht - Unterschrift - PDF-Erstellung - Berichtsversionen - Backoffice-Freigabe ### Phase 5 – Notdienst - Notdiensteinsatz - vorläufiger Kunde - vorläufiges Objekt - Benachrichtigungen - Nachbearbeitung im Backoffice ### Phase 6 – Stabilisierung - Audit-Logging - Sicherheitsprüfungen - Lasttests - Offline-Konflikte - Backup und Restore - Monitoring - Fehlerbehandlung - Pilotbetrieb --- ## 42. Definition of Done Eine Funktion gilt als fertig, wenn: - fachliche Anforderungen umgesetzt sind - Mandantentrennung geprüft wurde - Rollen- und Rechteprüfung vorhanden ist - Eingaben validiert werden - Fehlerfälle behandelt werden - relevante Aktionen protokolliert werden - automatisierte Tests vorhanden sind - API dokumentiert ist - responsive Darstellung geprüft wurde - Offline-Verhalten geprüft wurde, sofern relevant - Datenschutzanforderungen berücksichtigt sind - technische Dokumentation aktualisiert wurde - Funktion in einer Testumgebung abgenommen wurde --- ## 43. Teststrategie ### 43.1 Unit-Tests - Datenvalidierung - Statusübergänge - Berechtigungen - Mandantenfilter - Materialberechnungen - Berichtsgenerierung - Extraktionsmapping ### 43.2 Integrationstests - PDF-Import - OCR-Verarbeitung - Dateiupload - E-Mail-Versand - PDF-Erstellung - Datenbank - Object Storage - Queue-Verarbeitung ### 43.3 End-to-End-Tests - regulärer Auftrag vom Import bis zur Freigabe - mehrtägiger Auftrag mit Tagesbericht - Notdiensteinsatz - Offline-Erfassung und Synchronisation - fehlende Pflichtfotos - fehlende Unterschrift - Dublettenprüfung - Mandantentrennung ### 43.4 Sicherheitstests - Zugriff auf fremde Mandantendaten - manipulierte IDs - unzulässige Rollenaktionen - schädliche Uploads - Session-Handling - Rate Limiting - Passwort-Reset - Audit-Log-Manipulation --- ## 44. Offene fachliche Entscheidungen vor Produktivbetrieb Folgende Punkte müssen spätestens während der Umsetzung konkretisiert werden: - genaue Berichtsvorlage des Pilotkunden - Pflichtfelder je Auftragsart - erforderliche Fotoarten - Regelung der Arbeitszeitkorrektur - Aufbewahrungsfristen - Empfänger der Abrechnungsbenachrichtigung - bevorzugter OCR- und KI-Anbieter - gewünschter E-Mail-Dienst - Hostingstandort - gewünschte MFA-Regelung - Umgang mit Standortdaten - maximale Offline-Dauer - maximale Dateigrößen - konkrete Buchhaltungssoftware des Pilotkunden - später gewünschte Schnittstellen - Unternehmensbranding der PWA - Berichtssprache - Lösch- und Archivierungskonzept --- ## 45. Perspektive für Version 2 Für Version 2 werden folgende Erweiterungen empfohlen: - direkte Schnittstelle zum Buchhaltungs- oder ERP-System - Artikel- und Materialstamm - Lagerbestände - automatische Übergabe abrechnungsrelevanter Positionen - Kalender und Einsatzplanung - Routenplanung - Kundenportal - Wartungsplanung - Anlagen- und Geräteverwaltung - Seriennummern - QR-Codes an Objekten oder Anlagen - automatische Erinnerungen - Web-Push-Benachrichtigungen - Microsoft-365-Integration - DATEV-Export - KI-Suche in Einsatzhistorien - KI-Assistent für Monteure - automatische Zusammenfassung früherer Einsätze - Auswertung von Nachkalkulationen - Kennzahlen je Team, Auftrag und Kunde - konfigurierbare Workflows je Mandant --- ## 46. Zusammenfassung Der MVP soll eine mandantenfähige PWA für Handwerks- und Montagebetriebe bereitstellen. Der Kernnutzen besteht darin, Auftragsdaten aus bestehenden PDF-Dokumenten zu übernehmen, Montageteams digital mit allen notwendigen Informationen zu versorgen und aus der tatsächlichen Arbeit vor Ort einen vollständigen, abrechnungsfähigen Nachweis zu erzeugen. Besonders wichtig sind: - geringe manuelle Datenerfassung - einfache Bedienung auf der Baustelle - Offline-Fähigkeit - vollständige Foto- und Materialdokumentation - Tages- und Abschlussberichte - Notdiensteinsätze ohne Backoffice - dauerhafte Objekt-Historie - technische Dokumente am Objekt - sichere Mandantentrennung - modular erweiterbare Architektur Die Lösung bildet damit die Grundlage für eine später umfassendere SaaS-Plattform für Handwerks- und Montagebetriebe.