msolarczekandClaude Opus 5
c8e6f30a27
Unveränderter Stand von certvia/dev (a48c5fb) plus Craftvia-Spezifikation und Brandbook unter docs/craftvia/. ISMS-Module werden im Folgecommit entfernt. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2481 lines
47 KiB
Markdown
2481 lines
47 KiB
Markdown
# 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<ExtractedText>;
|
||
extractStructuredData(text: string): Promise<WorkOrderExtraction>;
|
||
}
|
||
```
|
||
|
||
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.
|