Funktionsweise und Absicherung der digitalen Annahme

Ablauf

1. Dokument: eines der mit dem Vertrag verknüpften PDFs (nicht der Nachweis). Die Art stammt aus der Rolle in der Dokumentenzentrale, der Unterzeichnungsmodus aus der Quellvorlage; ersatzweise sind Kündigung und Leistungsnachweis einseitig, alles andere zweiseitig.
2. Unterzeichner: nur Personen der Parteien, mit der aus der Person aufgelösten E-Mail-Adresse (eine im POST gesendete Adresse wird nicht akzeptiert). Zweiseitig: jede Pflichtpartei erhält einen Unterzeichner; einseitig: nur die erklärende Partei; unbekannter Erklärender: genau eine Partei.
3. Methode: click, email_otp (6-stelliger Code per E-Mail), sms_otp (nicht verfügbar, kein produktiver SMS-Weg), dap (Adapter fertig, available = false). Für Arbeitsverträge und die in den Einstellungen markierten Arten ist nur dap wählbar.
4. Einfrieren: Der SHA-256-Fingerabdruck der PDF-Bytes (doc_sha256) wird beim Versand festgehalten.
5. Einladung: über den zentralen Mailweg (esign_invite) im Namen des Clients in der Sprache des Unterzeichners; eindeutiger Link mit 64-stelligem Hex-Token, Gültigkeit 1–90 Tage (Standard 14).
6. Signaturseite: Ablaufprüfung; abweichender Hash wird verweigert (doc_changed); eingebettetes PDF; Erklärung (Unterzeichner, Vertragsnummer, Dokumentname und SHA-256); Pflicht-Kontrollkästchen. E-Mail-Code: 10 Minuten gültig, 5 Versuche je Code, höchstens 5 Codes je Unterschrift, mindestens 60 s Abstand. Ablehnung mit Begründung. Header: noindex, no-store, no-referrer; POSTs mit Sitzungstoken (CSRF).
7. Nach der Unterschrift: Status signed, IP, Browser, SHA-256 der angenommenen Erklärung; Nachweis-PDF in der Dokumentenzentrale (signature_evidence): Unterzeichner, E-Mail, Methode, Dokument und Hash, Zeitpunkte von Versand, Ansicht und Unterschrift, IP, Browser, Erklärung und Hash, Ereignisprotokoll. Ohne Speicherregel bleibt die Unterschrift gültig, die Lücke wird protokolliert, der Nachweis kann später erzeugt werden (contract/esign.evidence).
8. Zusammenfassung: esign_status des Vertrags (leer, pending, partial, signed, declined) und esign_date; haben alle Unterzeichner des Hauptvertragsdokuments (Rolle contract) unterschrieben, erhält date_signed den Tag der letzten Unterschrift, falls leer.

Signaturzustände: pending, sent, viewed, signed, declined, expired, cancelled. Erneuter Versand mit neuem Token; Widerruf: cancel; der Ablauf wird verzögert geprüft (beim Öffnen des Links und beim Laden des Admin-Blocks).

Datenmodell

Die Tabellennamen tragen in der Datenbank das eigene Präfix der Installation. contract_signature (eindeutig token_hash): contract_id, doc_id, doc_sha256, signer_person_id, signer_company_id, signer_name, signer_email, language_id, method, expires_at, otp_hash, otp_expires_at, otp_attempts, otp_sent_count, otp_sent_at, status, Zeitstempel, decline_reason, ip, user_agent, accept_text_hash, evidence_doc_id. contract_signature_event: event, ip, user_agent, data (JSON, ohne Geheimnisse).

Sicherheit

Link-Token (256 Bit) und Code werden nur als SHA-256-Hash gespeichert (der Code mit der Signaturkennung gesalzen); Rohwerte gelangen weder in das Ereignisprotokoll noch in Listen oder Logs. Ereigniscodes: created, sent, resent, viewed, reopened, otp_sent, otp_failed, signed, declined, expired, cancelled, doc_mismatch, mail_failed, evidence, evidence_failed.

Einstellungen

Installationseigene JSON-Einstellung: Arten mit qualifizierter Signatur (Haupt- oder Untertypcodes), Standardgültigkeit (Tage), DÁP: aktiviert, Client-ID, Zertifikatspfad, Umgebung (test oder prod), Client-Secret (die Oberfläche zeigt nur, ob es gesetzt ist).

Rechtlicher Rahmen

Endpunkte und Rechte

E-Mails: esign_invite, esign_otp. Protokollkanal: contract/esign.