patrick
9a24ea29e1
Git-Repository für bestehenden archivdms-Code initialisiert, Branch-/Commit-Konvention (feature/<ticket>-<slug>-Branches, Ticket-Prefix in Commit-Nachricht) etabliert.
46 lines
4.4 KiB
Markdown
46 lines
4.4 KiB
Markdown
# DMS-Vergleich: Retention/Löschkonzept-Muster (Docspell, Paperless-ngx, ecoDMS, Alfresco)
|
|
|
|
Referenzdokument für retention-compliance-Agent. Vergleich existierender DMS-Systeme zu Aufbewahrung/Löschung, als Muster-Fundus für archivdms.
|
|
|
|
## ecoDMS — zweistufiges Löschmodell (direkt übertragbar)
|
|
|
|
- Nach Ablauf gesetzlicher Frist: Dokument wandert automatisch in **Papierkorb** (nicht sofort gelöscht).
|
|
- Endgültiges Löschen erfordert **separate manuelle Freigabe**.
|
|
- Jede finale Löschung erzeugt **GoBD-konformes Löschprotokoll** (wer, wann, welches Dokument, Rechtsgrundlage).
|
|
- Technische Isolation bei Mandantenfähigkeit nicht öffentlich dokumentiert (closed source).
|
|
|
|
**Für archivdms:** Passt zur zurückgestellten Papierkorb-Idee. Empfehlung: `retain_until` erreicht → Status `pending_deletion` statt Hard-Delete. Löschung nur nach explizitem Review/Freigabe-Schritt, mit Audit-Log-Eintrag (Nutzer, Zeitstempel, Rechtsgrundlage, Dokument-Hash).
|
|
|
|
## Docspell — Klassifizierung als Aufbewahrungs-Vorstufe
|
|
|
|
- Stanford NLP lernt Tag-/Korrespondent-Zuordnung aus bestehenden getaggten Dokumenten, sagt bei neuen Dokumenten voraus.
|
|
- Kein natives Retention/Löschkonzept dokumentiert — Fokus liegt auf Klassifizierung, nicht auf Fristenverwaltung.
|
|
|
|
**Für archivdms:** Kein direktes Retention-Muster, aber zeigt: korrekte Kategorie-Zuordnung (invoice/contract/personal_data/...) ist Voraussetzung für automatische Fristen-Ableitung. Bestätigt Ansatz von retention-compliance-Agent (Klassifizierung → Regel), nur regelbasiert statt ML.
|
|
|
|
## Paperless-ngx — kein natives GoBD-Retention-Feature
|
|
|
|
- Kein dokumentiertes Aufbewahrungsfristen-/Löschkonzept als Kernfunktion.
|
|
- ML-Klassifikator (scikit-learn) für Tags/Korrespondent, aber nicht an Fristenlogik gekoppelt.
|
|
- Workflow-Hooks in Konsum-Pipeline könnten theoretisch für Retention-Trigger genutzt werden, ist aber kein vorgesehenes Feature.
|
|
|
|
**Für archivdms:** Negativbeispiel — Lücke im OSS-Feld. Bestätigt, dass GoBD-konformes Retention/Löschkonzept ein Differenzierungsmerkmal von archivdms ist, kein Nachbau eines bestehenden Musters.
|
|
|
|
## Alfresco Governance Services — Terminologie/Denkmodell (nicht Architektur)
|
|
|
|
Alfresco ist ein volles Java/Spring-Content-Repository (CMIS-Standard), architektonisch **kein Vorbild** für archivdms (16+ GB RAM, 6-9 Container im Referenzstack, Solr+ActiveMQ+Transform-Services — Gegenteil von Single-LXC). Zwei Begriffe/Muster aus dem RM-Modul sind trotzdem übertragbar:
|
|
|
|
- **Retention Schedule als Step-Sequenz**: statt einer einzelnen Frist eine Abfolge von Aktionen (cutoff → retain → review → destroy/transfer), jeweils zeit- oder ereignisgetriggert. Passt zu GoBD-Fristen, die oft erst nach einem Ereignis zu laufen beginnen (z.B. Frist beginnt erst nach Ablauf des Geschäftsjahres = "cutoff"-Ereignis, nicht ab Dokumentdatum).
|
|
- **Legal Hold**: orthogonale Sperre, unabhängig von der Retention Schedule, blockiert jede Löschaktion (auch nach Fristablauf) bis explizit aufgehoben. Sauberes Vokabular für den DSGVO-vs-GoBD-Konfliktfall — Legal Hold als eigenes Flag/Objekt statt in die Fristenlogik selbst eingewoben.
|
|
- RM-Modul existiert weiterhin in Alfresco Community Edition (Grundfunktionen frei, eDiscovery/mehrstufige Freigabe-Workflows Enterprise-exklusiv).
|
|
|
|
**Für archivdms:** Erweiterung von Punkt 1 im Fazit unten — `retain_until` könnte künftig als Step-Sequenz statt Einzelwert modelliert werden, sobald ereignisgetriggerte Fristen (Geschäftsjahresende, Vertragsende) gebraucht werden. Legal-Hold-Flag als eigenständiges Feld (unabhängig von `pending_deletion`-Status) vormerken für den DSGVO/GoBD-Konfliktfall.
|
|
|
|
## Fazit für retention-compliance-Agent
|
|
|
|
1. **Zweistufiges Löschen (ecoDMS-Muster)** in Retention-Regeln vorsehen: `retain_until` abgelaufen → `pending_deletion`, nicht sofort löschen. Feld `requires_review` bereits im Ausgabeformat vorhanden, gleiche Logik für finale Löschfreigabe nutzbar.
|
|
2. **Löschprotokoll** als eigenes Audit-Artefakt mitdenken, sobald Hard-Delete tatsächlich umgesetzt wird (aktuell nicht Scope des Agenten, aber Anschlussstelle).
|
|
3. Kein bestehendes OSS-System liefert vollständiges GoBD-Retention-Vorbild — archivdms-Ansatz (regelbasiert, strengste Regel gewinnt, DSGVO nie Vorrang vor gesetzlicher Pflicht) bleibt eigenständig zu verantworten.
|
|
|
|
Quelle: siehe Memory `project_docspell_referenz` und `project_dms_vergleich_paperless_ecodms` (Recherche 2026-07-17).
|