[[Uebersicht|← Zurück zur Homepage]] # PaperSafe – Feinkonzept Regelwerk (Dateiimport) > **Zweck:** Der Import ist *nicht* von selbst intelligent. Er folgt Regeln, die wir definieren. Diese Note beschreibt das Regelwerk für den **Import aus lokalen Ordnern** – Korrespondenten, Tags, Speicherpfade, Workflows – und das Vorgehen, es einzuführen. > > **Der E-Mail-Import ist ein eigenes Arbeitspaket und steht in [[09-E-Mail-Import]].** Er wird erst nach Abschluss des Dateiimports aufgegriffen. > > **Wissensstand:** Alle Angaben wurden am 19.07.2026 gegen die Dokumentation **exakt zur installierten Version 2.20.15** geprüft (Quellen am Ende), nicht aus dem Gedächtnis geschrieben. ## Ausgangslage Erste echte Dokumente sind importiert. Der Befund im System: | Wert | Stand 19.07.2026 | |---|---| | Dokumente | 3 | | ohne Korrespondent | 3 | | ohne Dokumenttyp | 3 – **irrelevant**, Dokumenttypen werden nicht verwendet (Abschnitt 5) | | ohne Tags | 0 | | Vorhandene Tags | `Elektrorad` (aus dem Ordnernamen) | | Korrespondenten / Dokumenttypen / Speicherpfade | keine angelegt | Der Ordnername wird also zuverlässig zum Tag – alles Übrige bleibt leer. **Genau das ist der zu lösende Punkt.** ## Zielbild PaperSafe ist eine **Ablage zum Wiederfinden**, kein Verwaltungssystem. Dokumente kommen aus lokalen Ordnern herein (später zusätzlich aus E-Mail-Postfächern), werden per OCR durchsuchbar gemacht und danach über die Suche gefunden. Typische Suche: *„Versicherung X, Jahr 2024"* – nicht *„zeige alle Policen"*. **Was daraus folgt – und was bewusst entfällt:** | Element | Entscheidung | |---|---| | **Dokumenttypen** | **Entfallen** (19.07.2026). Steht „Rechnung" im Text, findet die Volltextsuche es ohnehin – siehe Abschnitt 5 | | **Workflow-Tags** (`zu erledigen`, `Frist`, `strittig`) | **Entfallen.** Setzen laufende Bearbeitung voraus, die es hier nicht gibt | | **Custom Fields** | **Entfallen.** Müssten je Dokument gepflegt werden | | **Speicherpfade** | **Entfallen** – globales Schema genügt, siehe Abschnitt 6 | | **Tags** | **Bleiben** – entstehen automatisch aus Ordnernamen | | **Korrespondenten** | **Bleiben** – das einzige Feld, das aktiv gepflegt wird | | **Vertraulichkeit** | Über Tags `Privat`/`Obeco` aus den beiden obersten Ordnern, siehe Abschnitt 6b | | **Volltextsuche** | **Der eigentliche Zugangsweg.** Alles andere grenzt nur ein | **Damit ist der Fall klar umrissen:** Von den vier Ordnungsmitteln in Paperless nutzen wir zwei. Ein leeres Feld *Dokumenttyp* oder *Speicherpfad* ist der Sollzustand. Als „leere Basisdaten" gilt nur ein fehlender **Korrespondent**. --- ## 1. Der Denkfehler, den es aufzulösen gilt Paperless hat **zwei voneinander unabhängige Automatiken**. Sie werden oft verwechselt, und die Unterscheidung ist die Grundlage des ganzen Konzepts: | | **Matching** | **Workflows** | |---|---|---| | Wo definiert | Am Objekt selbst (jeder Tag, Korrespondent, Typ hat ein Suchmuster) | Eigener Menüpunkt, Auslöser + Aktionen | | Worauf reagiert es | **Auf den Text im Dokument** | Auf Quelle, Dateiname, **Dateipfad**, Mail-Regel oder Inhalt | | Typischer Einsatz | „Steht ‚Allianz' im Text → Korrespondent Allianz" | „Kommt aus Ordner `…/Allianz/…` → Korrespondent Allianz" | | Grenze | Braucht erkannten Text. Bei schlechter OCR wirkungslos | Kennt den Dateipfad nur beim Import, danach nicht mehr | **Beide zusammen ergeben die Abdeckung.** Der Dateipfad greift dort, wo die OCR schwach ist; der Text greift dort, wo die Ordnerstruktur nichts hergibt. ## 2. In welcher Reihenfolge das System arbeitet Das ist keine Nebensache – davon hängt ab, welche Regel welche überschreibt: ``` Datei erscheint im Consume-Ordner │ ├─ 1. Workflows „Consumption Started" │ kennen: Quelle, Dateiname, Dateipfad, Mail-Regel │ kennen NICHT: den Text (OCR läuft erst danach) │ ├─ 2. Texterkennung / Dokumentaufbereitung │ ├─ 3. Matching │ Tags, Korrespondenten, Typen, Speicherpfade nach Textmuster │ ├─ 4. Workflows „Document Added" │ kennen jetzt: Text UND die eben zugewiesenen Metadaten │ └─ Dokument fertig ``` **Geprüft, nicht angenommen:** Es kursiert ein Fehlerbericht, „Document Added" laufe schon *vor* der Texterkennung. Der Bericht wurde geschlossen und von einem Maintainer im Quellcode widerlegt – die Workflows sind nach `set_correspondent`, `set_document_type`, `set_tags` und `set_storage_path` eingehängt und laufen synchron. **Die Reihenfolge oben gilt.** Zwei Konsequenzen daraus: - Regeln, die den **Dateipfad** brauchen, müssen bei *Consumption Started* sitzen. Später ist der Pfad weg. - Regeln, die den **Inhalt** brauchen, gehören zu *Document Added*. --- ## 3. Korrespondenten **Aufgabe:** Wer hat das Dokument geschickt bzw. mit wem besteht das Verhältnis. Für dich der wichtigste Ordnungsbegriff, weil deine Ablage schon nach Firmen getrennt ist. **Zwei Wege, beide ohne Handarbeit:** | Weg | Regel | Wirkt bei | |---|---|---| | **Textmuster** | Korrespondent „Allianz", Algorithmus *Beliebig*, Muster `Allianz` | Allen Dokumenten, in denen der Name vorkommt – egal woher sie kommen | | **Dateipfad** | Workflow *Consumption Started*, Filter Dateipfad `*/Allianz/*` → Korrespondent zuweisen | Allen Dateien aus diesem Ordner, auch wenn die OCR versagt | **Empfehlung:** Für jeden Korrespondenten **beide** anlegen. Der Aufwand ist einmalig und minimal, die Abdeckung deutlich besser. **Zu den Matching-Algorithmen** – die Wahl ist wichtiger, als sie aussieht: | Algorithmus | Verhalten | Wann sinnvoll | |---|---|---| | *Beliebig* | Eines der Wörter kommt vor | Standardfall, mehrere Schreibweisen mit Anführungszeichen: `"Allianz SE" Allianz` | | *Alle* | Alle Wörter kommen vor | Wenn ein Wort allein zu unspezifisch ist | | *Exakt* | Genaue Zeichenfolge inkl. Reihenfolge | Firmierungen wie `Stadtwerke Musterstadt GmbH` | | *Regulärer Ausdruck* | Volle Mustersprache | Kundennummern, IBAN-Fragmente, Aktenzeichen | | *Unscharf* | Ähnlichkeitstreffer | **Gut bei OCR-Fehlern** – fängt „Alllanz" noch ab | | *Automatisch* | Lernendes Netz | **Für uns vorerst wirkungslos**, siehe unten | **Zum lernenden Verfahren (*Automatisch*):** Es lernt aus Dokumenten, die du **selbst** zugeordnet hast, und **ignoriert dabei alle Dokumente mit Posteingangs-Tag**. Ohne manuelle Zuordnung fehlt ihm die Grundlage. Es ist keine Alternative zu festen Regeln, sondern eine mögliche **Ergänzung später** – wenn genug korrigierte Dokumente vorliegen, kann man einzelne Korrespondenten probeweise umstellen. ## 4. Tags **Aufgabe:** Thema und Lebensbereich, mehrfach vergebbar. Drei Quellen, alle automatisch: 1. **Ordnername** – läuft bereits über `PAPERLESS_CONSUMER_SUBDIRS_AS_TAGS`. Deine Ordnerstruktur *ist* dein Tag-Schema 2. **Textmuster** – wie beim Korrespondenten, z. B. Tag `Steuer` mit Muster `Steuererklärung Einkommensteuer Finanzamt` (*Beliebig*) 3. **Workflow** – Tags zuweisen abhängig von Pfad, Quelle oder Mail-Regel **Wichtig:** Tags aus Ordnernamen entstehen **nur beim Import**. Sortierst du später deine Quellordner um, ändert das nichts an bereits importierten Dokumenten. **Empfehlung zur Struktur:** Keine tiefe Hierarchie erfinden. Die Ordnernamen sind gewachsen und passen zu deinem Suchverhalten. Ergänzend höchstens eine Handvoll übergreifender Themen-Tags per Textmuster (`Steuer`, `Versicherung`, `Fahrzeug`, `Immobilie`, `Gesundheit`). ## 5. Dokumenttypen – gestrichen **Entscheidung 19.07.2026: Dokumenttypen werden nicht verwendet.** Das Feld bleibt leer und wird ignoriert. **Zur Begriffsklärung, weil sie eine echte Fehlerquelle ist:** „Dokumenttyp" meint in Paperless **nicht** die Dateiendung. `.pdf`, `.docx`, `.xlsx` erfasst das System automatisch als MIME-Typ, sichtbar im Reiter *Metadaten* – daran ist nichts einzustellen. Der Dokumenttyp meint die *inhaltliche* Art: Rechnung, Vertrag, Police, Bescheid. **Begründung der Streichung:** Steht „Rechnung" im Dokument, findet die Volltextsuche es ohnehin. Ein eigenes Feld verdoppelt, was die Suche bereits leistet. **Was dadurch entfällt** – bewusst in Kauf genommen: Die Volltextsuche findet auch Dokumente, die den Begriff nur *erwähnen* („…wie in unserer Rechnung vom 3. Mai…"). Ein Typfeld wäre trennscharf gewesen. Beim Suchmuster „Firma + Zeitraum" fällt das nicht ins Gewicht. **Folge fürs Formular:** Ein leeres Feld *Dokumenttyp* ist damit **kein Mangel**, sondern der Sollzustand – genau wie beim Speicherpfad. Als „leere Basisdaten" gelten nur noch fehlende **Korrespondenten**. ## 6. Aufgabe der Speicherpfade **Was sie sind:** Ein Speicherpfad ist ein *eigenes Dateinamens-Schema für eine Teilmenge von Dokumenten*. Er überschreibt für diese Dokumente das globale `PAPERLESS_FILENAME_FORMAT`. **Was sie nicht sind:** Kein Ordnungsmittel für die Suche. Sie bestimmen ausschließlich, **wie die Dateien auf der Platte liegen** – für das Wiederfinden in der Oberfläche sind sie ohne Bedeutung. Aktuell gilt global: ``` {{ created_year }}/{{ correspondent }}/{{ title }} ``` zusammen mit `PAPERLESS_FILENAME_FORMAT_REMOVE_NONE=true`, das leere Felder aus dem Pfad entfernt statt `none` zu schreiben. **Wozu die Ablagestruktur trotzdem zählt:** Sie ist die **Rückfallebene**. Sollte Paperless in einigen Jahren nicht mehr wartbar sein, liegt dort ein Aktenschrank, den jeder Dateimanager öffnen kann – ohne Datenbank, ohne Software. Deshalb lohnt ein vernünftiges globales Schema, und deshalb `REMOVE_NONE`: sonst hieße jeder zweite Ordner `none`. **Empfehlung: keine zusätzlichen Speicherpfade anlegen** – mit einer möglichen Ausnahme, siehe 6b. **Merke:** Ein leerer Speicherpfad im Formular ist **kein Mangel**. Er bedeutet schlicht „globales Schema" – anders als ein leerer Korrespondent. ## 6b. Intern und extern – Vertraulichkeit statt Ablage **Nutzerangabe 19.07.2026:** Es gibt zwei grundsätzliche Gruppen, und die **Quellordner sind bereits entsprechend zweigeteilt**: | Ordner | Bedeutung | |---|---| | **`Privat`** | Ausschließlich persönlicher Umgang – verlässt das Haus nicht | | **`Obeco`** | Gemeinsam bearbeitet – verlässt das Haus | > ### GoBD – geprüft und entschieden (19.07.2026) > > Der Ordner `Obeco` warf die Frage auf, ob die Grundsatzentscheidung aus [[00-Start]] und [[01-Konzept-Architektur]] – *„rein privat, keine Obeco-Belege, damit keine GoBD-Anforderungen"* – noch trägt. > > **Entscheidung des Nutzers: Die Obeco-Unterlagen in PaperSafe sind nicht GoBD-pflichtig.** Damit bleibt die bisherige Einordnung des Projekts unverändert gültig: keine Verfahrensdokumentation, keine Anforderungen an Unveränderbarkeit, keine besonderen Aufbewahrungsfristen. > > Festgehalten, damit später nachvollziehbar ist, dass der Punkt geprüft und nicht übersehen wurde. Das ist kein Ablage-, sondern ein **Vertraulichkeitskriterium**. Daraus folgt die Werkzeugwahl: **Der Tag ist hier das wichtigere Werkzeug – nicht der Speicherpfad.** Der Fehler, den es zu verhindern gilt, passiert beim Heraussuchen eines Dokuments zur Weitergabe. In diesem Moment sitzt man in der Oberfläche: Ein Tag ist dort sichtbar und warnt, ein Speicherpfad ist unsichtbar und wirkungslos. **Keine Regel kann diese Unterscheidung aus dem Inhalt ableiten.** Kein Textmuster erkennt „darf das Haus nicht verlassen". Sie muss aus der Ordnerstruktur kommen – und die steht bereits: ``` papersafeconsume/ Privat/ Gesundheit/… -> Tags: Privat, Gesundheit Finanzen/… -> Tags: Privat, Finanzen Obeco/ Allianz/… -> Tags: Obeco, Allianz ``` Beim Import unter diesen beiden obersten Ebenen entsteht die Kennzeichnung **automatisch**, weil `SUBDIRS_AS_TAGS` jede Ebene zum Schlagwort macht. Kein zusätzlicher Handgriff, keine Regel. **Speicherpfad zusätzlich – hier spricht mehr dafür als zunächst gedacht.** Ein Workflow mit Pfadfilter `Privat/*` bzw. `Obeco/*` setzt zusätzlich einen Speicherpfad und trennt die Gruppen körperlich: ``` Privat/{{ created_year }}/{{ title }} Obeco/{{ created_year }}/{{ correspondent }}/{{ title }} ``` Bei einer Trennung privat/geschäftlich ist die körperliche Trennung **plausibler als im allgemeinen Fall**: Sie hält die Rückfallebene sauber getrennt und erlaubt, eine Gruppe geschlossen zu sichern, herauszugeben oder zu entfernen – etwa bei einer Betriebsprüfung, einer Übergabe an Dritte oder einem späteren Systemwechsel. Das lohnt **nur**, wenn geschlossene Herausgabe, getrennte Sicherung oder Migration einer Gruppe ein realistisches Szenario ist. Sonst ist es Komplexität ohne Gegenwert – der Tag leistet das Nötige. > **Wichtige Einschränkung:** Weder Tag noch Speicherpfad **schützen** etwas. Beide sind Kennzeichnung, keine Sperre. Wer Zugang zu Paperless hat, sieht alles. Echten Schutz gäbe es nur über Benutzer und Berechtigungen – bei einem Ein-Personen-System viel Reibung für wenig Gewinn. **Die Kennzeichnung schützt vor dem eigenen Versehen, nicht vor fremdem Zugriff.** **Zeitkritisch:** Die Zweiteilung muss **beim Import** stehen. Tags entstehen ausschließlich beim Einlesen – nachträglich ließe sich die Kennzeichnung nur von Hand nachziehen. ## 6c. Bilder ausschließen – Ergebnis statt Arbeitsmaterial **Nutzerangabe 19.07.2026:** Rund **40 % der Dateien in den Quellordnern sind Bilder** – Screenshots aus Handbüchern und Systemdokumentationen. Die Handbücher selbst liegen als fertige Dateien vor. Abfotografierte Belege, die per OCR erkannt werden müssten, gibt es **nicht**. **Das Problem:** Paperless kennt **keine Anlagen**. Jede Datei wird ein eigenständiges Dokument, gleichrangig neben dem Handbuch, zu dem sie gehört. | Folge | Wirkung | |---|---| | Jeder Screenshot ein eigenes „Dokument" | 40 % des Bestands wäre kein Archivgut | | Screenshots werden per OCR erfasst | Sie enthalten Text – Menüs, Schaltflächen, Feldnamen. Suchen nach „Einstellungen" oder „Speichern" träfen hunderte Screenshots | | Sie tragen dieselben Tags wie das Handbuch | Über Schlagwörter nicht wegzufiltern | | Archivversion je Bild | Speicherbedarf grob verdoppelt | **Die zweite Zeile wiegt am schwersten.** Anders als Fotos, die still danebenliegen, **verschlechtern Screenshots aktiv die Suche** – sie erzeugen Treffer bei genau den Allerweltswörtern, die in Benutzeroberflächen vorkommen. **Grundsatz:** > Ins Archiv gehört das **Ergebnis**, nicht das **Arbeitsmaterial**. Das fertige Handbuch als PDF gehört nach PaperSafe. Die Screenshots, aus denen es entstand, bleiben Projektmaterial auf dem NAS. Derselbe Schnitt wie bei ZIP-Archiven, Videos und CAD-Dateien – nur weniger offensichtlich, weil Bilder *importierbar* wären. **Umsetzung:** `PAPERLESS_CONSUMER_IGNORE_PATTERNS` – eine JSON-Liste von Mustern, die auf Ordner *und* Dateinamen greift. ### ⚠ Die Muster sind case-sensitiv **Im Quellcode geprüft (19.07.2026):** `_is_ignored()` in `document_consumer.py` nutzt `fnmatch.filter`. Unter Linux ist `fnmatch` **case-sensitiv** – empirisch bestätigt: ``` "*.jpg" gegen foto.JPG -> kein Treffer "*.jpg" gegen foto.jpg -> Treffer ``` **Die vom Nutzer gelieferte Endungsliste ist gemischt geschrieben** – `.GIF`, `.PCX`, `.HEIC`, `.JPEG`, `.CDR` und sogar `.Tiff`. Ein erster Entwurf mit reinen Kleinbuchstaben hätte rund die Hälfte der Dateien durchgelassen. Auch simples Verdoppeln (klein *und* groß) genügt nicht, weil `.Tiff` gemischt ist. **Lösung: Zeichenklassen je Buchstabe**, die jede Schreibweise abdecken: ``` *.[tT][iI][fF][fF] trifft tiff, TIFF, Tiff, tIfF … ``` ### Gesetzte Liste (32 Muster) Die neun Standardwerte plus 23 Grafikformate – die vom Nutzer genannten 19 sowie `jpe`, `jfif`, `webp`, `art` aus der von Paperless unterstützten Liste: ``` Standard: .DS_Store .DS_STORE ._* .stfolder/* .stversions/* .localized/* desktop.ini @eaDir/* Thumbs.db Grafik: jpg jpeg jpe jfif png gif bmp ico tif tiff wmf svg pcx eps heic cdr psd jpc dng jp2 ufo webp art (jeweils als Zeichenklasse) ``` Ein Teil davon (`ico`, `wmf`, `svg`, `pcx`, `eps`, `cdr`, `psd`, `jpc`, `dng`, `jp2`, `ufo`) wird von Paperless ohnehin nicht unterstützt. Sie stehen trotzdem in der Liste: So werden sie **sauber übersprungen**, statt beim Import abgewiesen zu werden und Fehlermeldungen zu erzeugen. **Zwei Warnungen dazu:** 1. **Die Voreinstellung wird komplett ersetzt, nicht ergänzt.** Die Standardwerte müssen mit übernommen werden – insbesondere `@eaDir/*`, der Ordner, in dem **Synology seine Vorschaubilder ablegt**. Fehlt er, importiert Paperless massenhaft NAS-Thumbnails 2. **Scanner-Ausgaben – geklärt (19.07.2026):** Ein Ausschluss von TIFF/JPG hätte künftige Scans stillschweigend verworfen. **Nutzerangabe: Die vorhandenen Scanner liefern ausschließlich PDF.** Damit besteht kein Konflikt. Falls je ein Gerät hinzukommt, das anders ausgibt, muss diese Liste angepasst werden – sonst kommen dessen Scans ohne Fehlermeldung nicht an **Der Ausschluss nach Dateiendung ist hier möglich, weil keine Belege als Bilddatei vorliegen.** Gäbe es abfotografierte Rechnungen, müsste stattdessen nach Ordnermustern ausgeschlossen werden – abhängig von der Ordnerstruktur und deutlich fehleranfälliger. ## 7. Workflows Der Startsatz, in dieser Reihenfolge: | # | Name | Auslöser | Filter | Aktion | |---|---|---|---|---| | 1 | Herkunft aus Ordner | Consumption Started | Dateipfad `*/<Firma>/*` | Korrespondent zuweisen (je Firma ein Eintrag) | | 2 | Gruppe zuordnen (optional) | Consumption Started | Dateipfad `Privat/*` bzw. `Obeco/*` | Speicherpfad zuweisen – nur falls körperliche Trennung gewünscht (Abschnitt 6b) | **Zu Workflow 1:** Er ist das Gegenstück zum Ordner-Tag. Der Tag entsteht ohnehin automatisch – der Korrespondent nicht. Genau diese Lücke schließt der Pfad-Filter. **Reihenfolge beachten:** Workflows laufen nach Sortierung, und **spätere Zuweisungen überschreiben frühere**. Ausnahme: Tags, Custom Fields und Berechtigungen werden *zusammengeführt*, nicht ersetzt. --- ## 8. Leere Einträge vermeiden – und was dabei nicht geht Das Ziel „keine leeren Basisdaten" lässt sich weitgehend, aber nicht restlos automatisieren. Ehrlich dazu: **Es geht nur noch um den Korrespondenten.** Dokumenttyp und Speicherpfad sind bewusst leer, Tags entstehen bereits automatisch. **Was sicher funktioniert:** - Korrespondent per Textmuster **und** Pfad-Workflow – doppelte Absicherung - Tag aus dem Ordnernamen – läuft bereits - Auffangregel bei E-Mail **Was nicht direkt geht:** Ein Workflow-Filter „*nur wenn das Feld leer ist*" existiert nicht. Die verfügbaren Filter sind „hat Korrespondent X" bzw. „hat **nicht** Korrespondent X, Y, Z" – aber kein „hat gar keinen". Eine Regel „setze Korrespondent auf *Unbekannt*, falls keiner gefunden wurde" ist damit **nicht sauber abbildbar**. Eine unbedingte Zuweisung würde die guten Treffer überschreiben. **Praktikabler Weg stattdessen:** In der Dokumentenliste nach *ohne Korrespondent* filtern, die Treffer ansehen und per Massenbearbeitung zuordnen. Aus jeder Zuordnung, die mehrfach vorkommt, wird dann eine neue Regel. Der Rückstand schrumpft mit jeder Runde von selbst. **Das ist der Punkt, an dem etwas Handarbeit unvermeidlich ist** – nicht als Dauerzustand, sondern als Rückkopplung, die das Regelwerk schärft. Wer null Handarbeit will, muss leere Felder in Kauf nehmen; beides zugleich geht nicht. --- ## 9. Wie du danach suchst Der Zugang ist die Suchleiste, nicht die Ordnernavigation. Beispiel *„Allianz, 2024"*: | Weg | Eingabe | |---|---| | Volltext + Zeitraum | `Allianz created:[2024-01-01 TO 2024-12-31]` | | Volltext + Tag | `Allianz`, dann in der Seitenleiste den Tag anklicken | | Nur Volltext | `Allianz 2024` – reicht meist, da die Jahreszahl im Dokument steht | | Nach Art | `Allianz Rechnung` – ersetzt den gestrichenen Dokumenttyp | Die Suche greift auf den **OCR-Text** zu, nicht nur auf Dateinamen. Deshalb war die OCR-Prüfung in Phase 4 wichtig: Was Tesseract nicht erkennt, ist auch nicht auffindbar. ## 10. Grenzen des Konzepts Damit später keine Enttäuschung entsteht: 1. **Das lernende Verfahren (*Automatisch*) bleibt vorerst wirkungslos.** Es lernt aus Dokumenten, die du selbst zugeordnet hast, und ignoriert dabei alles mit Posteingangs-Tag. Ohne Zuordnungen fehlt ihm die Grundlage. Erst nach einer Aufräumrunde (Schritt 7) wird es zur Option 2. **Tags entstehen nur beim Import.** Sortierst du später deine Quellordner um, ändert das nichts an bereits importierten Dokumenten 3. **Die Suchqualität hängt an der OCR.** Bei digitalen PDFs und sauberen Scans sehr gut; bei schlechten Vorlagen, Handschrift oder Stempeln deutlich schlechter. Große Umlaute (ÄÖÜ) in Versalien werden nicht zuverlässig erkannt (siehe [[03-Konfiguration]]) 4. **Titel kommen aus dem Dateinamen.** Sprechende Dateinamen zahlen sich aus; `scan0001.pdf` bleibt kryptisch. Ein Workflow kann Titel per Vorlage setzen – lohnt aber erst, wenn ein Muster erkennbar ist 5. **Paperless verschiebt die Dateien** aus dem Consume-Ordner. Beim Erstimport mit **Kopien** arbeiten, nicht mit den Originalordnern 6. **Kein Filter „nur wenn Feld leer"** – siehe Abschnitt 8 ## 11. Vorgehen in Schritten Jeder Schritt ist einzeln prüfbar. Nicht mehrere auf einmal. | Schritt | Inhalt | Ergebnis prüfbar an | |---|---|---| | **0a** | **Zweiteilung `Privat`/`Obeco` beim Kopieren beibehalten** – die beiden Gruppen als oberste Ebenen in der Freigabe (Abschnitt 6b) | Struktur steht vor dem ersten Import | | ~~**0b**~~ | ~~Bildausschluss setzen (Abschnitt 6c)~~ | **erledigt 19.07.2026** – `.png` blieb liegen, `.txt` kam durch | | ~~**0c**~~ | ~~Speicherpfade `Privat`/`Obeco` samt Workflows anlegen (Abschnitt 6b)~~ | **erledigt 19.07.2026** – Ablage unter `Privat/2026/…` bzw. `Obeco/2026/…` verifiziert | | **1** | **Ordnerstruktur erheben** – Liste der Quellordner. Sie ist die Rohdatenbasis für Korrespondenten und Tags | Liste liegt vor | | **2** | Korrespondenten anlegen (Textmuster), zunächst die 10–15 häufigsten | Objekte existieren | | **3** | Workflow 1 (Pfad → Korrespondent) für dieselben Firmen | Workflow aktiv | | **4** | **Testlauf mit 20–30 Dokumenten** aus verschiedenen Ordnern | Quote: wie viele haben einen Korrespondenten? | | **5** | Muster nachschärfen, wo Treffer fehlten oder falsch waren | Zweiter Testlauf besser als der erste | | **6** | Erst jetzt Gesamtbestand einspielen; Lastverhalten beobachten | `cpuunits 50` hält | | **7** | Rückstand „ohne Korrespondent" per Massenbearbeitung abarbeiten, wiederkehrende Fälle zu Regeln machen | Rückstand sinkt | | **8** | Nach einigen Wochen prüfen, ob *Automatisch* als Ergänzung taugt | Trefferquote im Vergleich | **Danach – eigenes Arbeitspaket:** E-Mail-Import einrichten, siehe [[09-E-Mail-Import]]. **Der Testlauf in Schritt 4 ist die eigentliche Qualitätssicherung.** Ein Regelwerk, das an 30 Dokumenten schlecht abschneidet, wird an 3000 nicht besser – es wird nur mühsamer zu korrigieren. --- ## Offene Punkte – Dateiimport Offene Punkte **des Dateiimports**. Der E-Mail-Import wird separat in [[09-E-Mail-Import]] geführt. ### Angaben, die ich von dir brauche - [ ] **Ordnerliste** der beiden Quellbäume `Privat` und `Obeco` (ein `dir /b` genügt). Ohne sie kann ich Korrespondenten und Pfad-Workflows nicht konkret vorschlagen – alles andere wäre geraten - [x] ~~Speicherpfade für `Privat`/`Obeco`~~ – entschieden und umgesetzt 19.07.2026: **ja**, körperliche Trennung. Speicherpfade und Workflows angelegt, verifiziert - [ ] Die drei vorhandenen `Elektrorad`-Dokumente haben **keinen Speicherpfad** – Workflows wirken nicht rückwirkend. Bei Bedarf in der Oberfläche zuweisen, Paperless verschiebt die Dateien dann selbst - [ ] **Wie weit soll die Handarbeit gehen?** Gar nicht (dann bleiben Lücken beim Korrespondenten), oder eine Aufräumrunde nach dem Massenimport (dann wird der Bestand sauber und das lernende Verfahren nutzbar) ### Umsetzung, offen - [ ] **Testlauf mit 20–30 realen Dokumenten**, danach erst der Gesamtbestand - [ ] **Erstimport mit Kopien**, nicht mit den Originalordnern - [x] ~~`PAPERLESS_CONSUMER_IGNORE_PATTERNS` setzen~~ – erledigt 19.07.2026, 32 Muster aktiv, alle 19 Nutzerendungen in jeder Schreibweise geprüft (Abschnitt 6c) - [x] ~~Scanner-Ausgabeformat prüfen~~ – geklärt 19.07.2026: **vorhandene Scanner liefern ausschließlich PDF**, kein Konflikt mit dem Bildausschluss - [ ] Lastverhalten beim Massenimport beobachten – `cpuunits 50` ist bisher nur an Einzeldokumenten geprüft - [ ] Rückstand „ohne Korrespondent" abarbeiten und daraus neue Regeln ableiten - [ ] Datumserkennung stichprobenhaft prüfen – bei `er_06_2025.pdf` wurde kein Datum im Text gefunden, das Dokument liegt unter `2026` statt `2025` ### Betrieb und Altlasten - [ ] Eigener DSM-Benutzer für die Consume-Freigabe statt `dsadmin` (gleiche offene Trennung wie beim Export) - [ ] In DSM prüfen: Btrfs-Volume? Dann Snapshot Replication aktivieren ([[04-Betrieb-Backup]]) - [ ] [[03-Konfiguration]] enthält noch überholte Passagen zu Dokumenttypen und Tag-Schema – widerspricht diesem Konzept - [ ] Scanner-Anbindung offen – Geräte liefern PDF, offen ist nur der Übergabeweg (Scan-to-Folder auf die Consume-Freigabe) - [ ] `vm.swappiness=60` unverändert – Swap-Anzeige wird beim Massenimport voraussichtlich wieder hochgehen (harmlos, siehe [[06-Umsetzungsprotokoll]] Phase 8) ## Quellen - Paperless-ngx – `docs/usage.md`, Tag `v2.20.15`: Abschnitt *Workflows* (Trigger-Typen, Filter, Aktionen, Platzhalter) – Zugriff 19.07.2026 - Paperless-ngx – `docs/configuration.md`, Tag `v2.20.15`: `PAPERLESS_CONSUMER_IGNORE_PATTERNS` (JSON-Liste, greift auf Ordner und Dateinamen, ersetzt die Voreinstellung vollständig) – Zugriff 19.07.2026 - Paperless-ngx – Quellcode `src/documents/management/commands/document_consumer.py`, Funktion `_is_ignored()` der installierten Version 2.20.15: Musterabgleich über `fnmatch.filter` und damit unter Linux **case-sensitiv**; empirisch bestätigt – Zugriff 19.07.2026 - Paperless-ngx – `docs/advanced_usage.md`, Tag `v2.20.15`: Abschnitte *Matching* (Algorithmen *Beliebig/Alle/Exakt/Regex/Unscharf/Automatisch*), *Automatic matching* (Einschränkungen des lernenden Verfahrens), *Placeholders*, *Empty placeholders*, *Storage paths* – Zugriff 19.07.2026 - Paperless-ngx – Issue #12117 „Document Added workflow triggers run before OCR": **geschlossen und widerlegt**; `run_workflows_added` ist in `apps.py` nach `set_correspondent`/`set_document_type`/`set_tags`/`set_storage_path` eingehängt und läuft synchron – Zugriff 19.07.2026 - Eigene Erhebung am laufenden System CT 110 (Bestand, Tags, Korrespondenten, Typen, Speicherpfade) – 19.07.2026 - Hinweis: `docs.paperless-ngx.com` liefert weiterhin HTTP 403 (Bot-Schutz). Quelle war jeweils das Repository zum passenden Versions-Tag – dadurch ist die Doku sogar versionsgenau statt „aktuellster Stand" --- **Status:** Konzept Dateiimport – **Vorbereitung umgesetzt** (Bildausschluss, Speicherpfade, Gruppen-Workflows). Offen: Ordnerliste, Korrespondenten, Testlauf **Version:** 1.9 **Letzte Aktualisierung:** 19.07.2026 ### Änderungshistorie | Version | Datum | Uhrzeit | Änderung | |---|---|---|---| | 1.0 | 19.07.2026 | – | Erstfassung – Feinkonzept für das Regelwerk. Unterscheidung Matching vs. Workflows, Verarbeitungsreihenfolge (gegen die Quellen geprüft, kursierender Fehlerbericht widerlegt), Konzepte für Korrespondenten, Tags, Dokumenttypen, Speicherpfade, Workflows und E-Mail. **Dokumenttypen bewusst wieder aufgenommen** – der frühere Einwand (manuelle Pflege) entfällt bei Regelzuordnung. Ehrliche Grenze dokumentiert: ein Workflow-Filter „nur wenn Feld leer" existiert nicht. Zehnstufiges Vorgehen mit Testlauf als Qualitätssicherung | | 1.1 | 19.07.2026 | – | **Dokumenttypen wieder gestrichen** (Nutzerentscheidung). Anlass war eine Begriffsklärung: „Dokumenttyp" war als Dateiendung verstanden worden, gemeint ist die inhaltliche Art. Begründung der Streichung: Steht „Rechnung" im Text, findet die Volltextsuche es ohnehin – ein eigenes Feld verdoppelt das nur. Bewusst in Kauf genommen: die Volltextsuche findet auch bloße Erwähnungen. Abschnitt 5 zur Begriffsklärung umgeschrieben, Workflow 3 entfallen, Vorgehen auf neun Schritte gekürzt. **Als „leere Basisdaten" gilt jetzt nur noch der fehlende Korrespondent** – Dokumenttyp und Speicherpfad sind gewollt leer | | 1.2 | 19.07.2026 | – | **Inhalte aus [[07-Automatischer-Import]] übernommen**, damit alles Offene an einer Stelle steht: Zielbild mit der Tabelle „was entfällt", Suchwege (Abschnitt 10), Grenzen des Konzepts (Abschnitt 11). **Offene Punkte vollständig zusammengeführt** und nach Angaben/Umsetzung/Betrieb gegliedert – einschließlich der Betriebs-Altlasten aus 04 und 06. Note 07 auf ihre verbleibende Rolle zurückgeschnitten (Ist-Dokumentation der Zuleitung) | | 1.3 | 19.07.2026 | – | **Abschnitt 6b ergänzt: intern/extern.** Nutzerangabe – zwei Gruppen (persönlich vs. das Haus verlassend), Quellordner bereits zweigeteilt. Als **Vertraulichkeits-**, nicht als Ablagekriterium eingeordnet. Bewertung: **der Tag ist hier das wichtigere Werkzeug**, weil der Fehler beim Heraussuchen in der Oberfläche passiert, wo ein Speicherpfad unsichtbar ist. Kennzeichnung entsteht automatisch aus den beiden obersten Ordnern; Speicherpfad optional bei Bedarf an körperlicher Trennung. Einschränkung festgehalten: beides ist Kennzeichnung, kein Schutz. Vorgehen um Schritt 0 erweitert (Zweiteilung muss vor dem Import stehen), Rückfallebene in Abschnitt 6 ergänzt | | 1.4 | 19.07.2026 | – | **Ordnernamen konkretisiert: `Privat` und `Obeco`** (Nutzerangabe). **Dabei Widerspruch zur Grundsatzentscheidung aufgedeckt** – [[00-Start]] und [[01-Konzept-Architektur]] schließen geschäftliche Obeco-Belege ausdrücklich aus, weil daran die Einordnung „keine GoBD-Anforderungen, keine Verfahrensdokumentation" hängt. Als Warnblock in 6b und als offener Punkt aufgenommen, mit den zwei entscheidenden Fragen (Art der Dokumente, führendes Archiv oder Arbeitskopie). Bis zur Klärung keine steuerlich relevanten Belege einspielen. Empfehlung zum Speicherpfad entsprechend angehoben – bei privat/geschäftlich spricht mehr für körperliche Trennung | | 1.5 | 19.07.2026 | – | **GoBD-Frage geklärt: Die Obeco-Unterlagen in PaperSafe sind nicht GoBD-pflichtig** (Entscheidung des Nutzers). Die Grundsatzentscheidung des Projekts bleibt damit unverändert gültig. Warnblock in 6b durch einen Entscheidungsvermerk ersetzt, offener Punkt gestrichen, Schritt 0 wieder auf die reine Ordnerstruktur reduziert. Bewusst als Vermerk festgehalten statt gelöscht, damit nachvollziehbar bleibt, dass der Punkt geprüft wurde | | 1.6 | 19.07.2026 | – | **E-Mail-Import ausgegliedert** nach [[09-E-Mail-Import]] (Nutzerentscheidung: erst Dateiimport, dann Mail). Abschnitt 8 entfernt, Abschnitte 9–12 auf 8–11 umnummeriert, Querverweise nachgezogen. Note auf den Dateiimport zugespitzt: Titel, Zweck, Zielbild und Quellen angepasst, offene Punkte um die Mail-Themen bereinigt. Workflow 2 von „Quelle E-Mail kennzeichnen" auf „Gruppe zuordnen" geändert. **Zwei Punkte aus der Zwischenzeit ergänzt:** Bilder vor dem Import aussortieren, Datumserkennung stichprobenhaft prüfen (Befund `er_06_2025.pdf` liegt unter 2026) | | 1.7 | 19.07.2026 | – | **Abschnitt 6c ergänzt: Bilder ausschließen.** Nutzerangabe – rund 40 % der Quelldateien sind Screenshots aus Handbüchern und Systemdokumentationen; die Handbücher liegen als fertige Datei vor, abfotografierte Belege gibt es nicht. Kernbegründung: **Paperless kennt keine Anlagen**, jeder Screenshot würde ein eigenständiges Dokument – und da Screenshots Oberflächentext enthalten, würden sie die Volltextsuche aktiv verschlechtern. Grundsatz „Ergebnis statt Arbeitsmaterial" festgehalten. Umsetzung über `PAPERLESS_CONSUMER_IGNORE_PATTERNS` mit zwei Warnungen: Voreinstellung wird ersetzt statt ergänzt (`@eaDir/*` für Synology-Vorschaubilder nicht vergessen) und **Abhängigkeit zur offenen Scanner-Anbindung** (JPG/TIFF-Ausgabe würde stillschweigend verworfen). Vorgehen um Schritt 0b erweitert | | 1.8 | 19.07.2026 | – | **Scanner-Abhängigkeit geklärt:** Die vorhandenen Scanner liefern ausschließlich PDF (Nutzerangabe) – kein Konflikt mit dem Bildausschluss aus 6c. Offener Punkt geschlossen, Hinweis für den Fall eines künftigen Geräts mit anderer Ausgabe belassen. Scanner-Anbindung präzisiert: offen ist nur noch der Übergabeweg, nicht das Format | | 1.9 | 19.07.2026 | – | **Bildausschluss und Speicherpfade umgesetzt und verifiziert.** Nutzer lieferte 19 Grafikendungen; **entscheidender Befund: die Muster sind case-sensitiv** (`fnmatch` unter Linux, im Quellcode geprüft und empirisch bestätigt). Ein erster Entwurf mit Kleinbuchstaben hätte rund die Hälfte durchgelassen, simples Verdoppeln hätte an `.Tiff` versagt – Lösung sind Zeichenklassen je Buchstabe. 32 Muster gesetzt und alle Endungen in jeder Schreibweise geprüft. Speicherpfade `Privat`/`Obeco` samt Workflows (Pfadfilter → Speicherpfad) angelegt; End-to-End getestet: Ordner-Tags, Speicherpfadzuweisung und Ablage unter `Privat/2026/…` bzw. `Obeco/2026/…` bestätigt, `.png` blieb liegen. Neuer offener Punkt: bestehende Dokumente haben keinen Speicherpfad, Workflows wirken nicht rückwirkend | --- [[Impressum|Impressum]] | [[Datenschutzerklärung|Datenschutz]]