Git-Repository für bestehenden archivdms-Code initialisiert, Branch-/Commit-Konvention (feature/<ticket>-<slug>-Branches, Ticket-Prefix in Commit-Nachricht) etabliert.
3.6 KiB
name, description, metadata
| name | description | metadata | ||
|---|---|---|---|---|
| project_gobd_verfahrensdokumentation | GoBD-Verfahrensdokumentation-Export-Feature — Gliederung, was automatisch/manuell ableitbar, Konzeptstand |
|
Feature-Idee (aus Paperless-Kursvergleich, siehe project_paperless_pilot_kurs_vergleich): automatisch generierte GoBD-Verfahrensdokumentation aus archivdms-Systemdaten, potenzielles Alleinstellungsmerkmal ggü. Paperless-ngx/ecoDMS. Stand 2026-07-30: Konzept fertig geklärt, KEIN Code geschrieben.
Gliederung (GoBD-Standard, BMF-Schreiben Rz.151-155 + Fachpraxis):
- Allgemeine Beschreibung (Organisation, Verantwortliche) — MANUELL, nicht im System
- Anwenderdokumentation (Erfassungsprozesse) — teilweise automatisch (workflows/classification_templates)
- Technische Systemdokumentation (Hard-/Software) — MANUELL/Platzhalter
- Betriebsdokumentation (Backup, Notfall, Zugriffsschutz) — Zugriffsschutz automatisch (permission_groups+Grants), Backup/Notfall MANUELL
- Verfahrensabläufe: Erfassung/Indizierung/Verarbeitung/Speicherung/Absicherung/Fristen/Vernichtung/Wiederauffinden — größtenteils automatisch ableitbar
- Änderungshistorie der Doku selbst — MANUELL (oder: Zeitstempel "Stand: " bei jeder Live-Generierung)
Automatisch ableitbar aus echtem Code-Stand (geprüft, nicht geraten):
- Fristen-Kapitel:
retention_rulesTabelle (Migration 022) — trigger_type, retention_years/days, legal_basis, dsgvo_conflict, Präzedenz doc-typ-spezifisch > tenant-Default - Zugriffsschutz-Kapitel:
permission_groups+document_type_grants/tag_grants/document_grants(Migration 008), Rollenmodell superadmin/domain_admin/user - Löschkonzept-Kapitel:
document_delete_requests(Migration 007) — Vier-/Zwei-Augen-Workflow, Status pending/confirmed/executed/blocked_retention,documents.deleted_at/deleted_by - Unveränderbarkeit: chmod 0440 + SHA-256 Content-Hash — technische Fließtext-Aussage, kein DB-Query nötig
- Erfassungsprozess (teilweise):
workflows/workflow_actions/workflow_runs(Migration 012),classification_templates(Migration 011) - Nachvollziehbarkeit:
audit_logappend-only via BEFORE UPDATE/DELETE Trigger (Migration 001)
Zwingend manuell (nicht im System): Organisationsbeschreibung, Verantwortliche/Vertretungsregeln, Server-/Backup-/Notfallkonzept außerhalb des DMS, Änderungshistorie der Doku selbst.
Format-Entscheidung: Markdown als Primärformat (kein PDF-Sidecar im ersten Schritt), pro Mandant individuell (alle relevanten Tabellen sind tenant-skopiert), live aus aktuellem DB-Stand generiert (kein Caching), mit Zeitstempel-Hinweis "Stand: , kein rechtsverbindliches Fertigdokument".
Endpoint-Vorschlag: GET /api/compliance/procedure-documentation, Auth-Pattern wie
internal/api/retention_rule_handlers.go (domain_admin+ für eigenen Tenant, superadmin optional mit
?tenant_id= für Cross-Tenant, aber kein automatisches Vermischen mehrerer Mandanten in einem Dokument).
Warum kein Code in diesem Durchgang: Der generierte Text kann vom Kunden gegenüber dem Finanzamt/Betriebsprüfer verwendet werden — Formulierungsrisiko, nicht Technikrisiko. Empfehlung: Konzept an backend-dev übergeben mit dieser Tabelle als Vorgabe, Platzhalter-Abschnitte klar als "TODO: durch Mandant auszufüllen" markieren, Rechtsgrundlagen-Texte vor Go-Live durch retention-compliance-Rolle gegenlesen lassen.
How to apply: Bei Fortsetzung dieses Features zuerst hier nachlesen statt Gliederung neu zu recherchieren. Code-Stand der referenzierten Tabellen vor Umsetzung erneut gegen aktuelle Migrations-Dateien prüfen (Stand könnte sich geändert haben).