feat: Rechnungen werden abgelegt, gesichert und mitversendet

Die Rechnung entstand bisher nur als Datenbankzeile; das PDF wurde bei jedem
Abruf neu gerendert und tauchte in keiner E-Mail auf. Das hatte drei
Nachteile: Gastbestellungen haben kein Konto, in dem sie den Beleg finden
koennten; eine Sicherung der Datenbank sicherte den Beleg nicht mit; und ein
spaeter erneut gerendertes PDF konnte nach einer Aenderung an Firmendaten
oder Layout anders aussehen als das, was die Kundschaft in Haenden hielt.

Ablage jetzt unter INVOICE_DIR, nach Jahr und Kunde sortiert:

  invoices/2026/mustermann-erika/RE-2026-A3F9C1B2.pdf

Das Jahr zuerst, weil sich die Aufbewahrungsfrist danach richtet — ein
abgelaufener Jahrgang laesst sich als ganzes Verzeichnis archivieren. Der
relative Pfad steht als Invoice.pdfPath in der Datenbank, damit eine spaetere
Aenderung an der Pfadbildung keine bereits abgelegten Belege unauffindbar
macht. Dafuer wurde die nie gelesene Spalte "pdfUrl" umbenannt; eine URL war
ohnehin das falsche Konzept.

INVOICE_DIR ist bewusst ein ANDERES Verzeichnis als UPLOAD_DIR:
app/uploads/[...path] liefert jede Datei unterhalb von UPLOAD_DIR ohne
Anmeldung aus. Laegen Rechnungen dort, koennte jede Person, die den Pfad
erraet, fremde Rechnungen samt Anschrift und Bestellinhalt herunterladen.
Auf das Rechnungsverzeichnis zeigt keine oeffentliche Route; der Abruf laeuft
weiter ueber /rechnung/<nummer>/pdf mit Besitzpruefung.

Der Abruf liefert jetzt die abgelegte Datei aus und rendert nur neu, wenn
keine da ist — also bei Rechnungen aus der Zeit davor.

Versand: das PDF haengt an der Bestellbestaetigung. sendMail nimmt dafuer
optionale Anhaenge entgegen, alle zehn bestehenden Aufrufe bleiben
unveraendert. Schlaegt das Erzeugen oder Ablegen fehl, geht die Bestaetigung
trotzdem raus und die Rechnung bleibt abrufbar: ein 500er an Stripe waere
die falsche Antwort auf eine volle Platte, denn die Zahlung ist erfolgt und
ein Wiederholungslauf aenderte daran nichts.

Sicherung: der taegliche CronJob packt das Verzeichnis als
rechnungen-<Zeitstempel>.tar.gz neben den Datenbank-Dump und haengt das
Volume nur lesend ein. Vermerkt ist dort auch die Einschraenkung, dass
wabenhain-invoices als ReadWriteOnce nur von Pods auf demselben Knoten
einhaengbar ist — bei mehreren Knoten braucht es ReadWriteMany, sonst bleibt
der Sicherungs-Pod lautlos in "Pending".

Weiterhin offen und im README vermerkt: die Rechnungsnummer ist eindeutig,
aber nicht fortlaufend (§ 14 Abs. 4 Nr. 4 UStG), und das PDF weist keine
Umsatzsteuer aus.

Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>

k8s/01-configmap.yaml

@@ -54,6 +54,14 @@ data:
   # nirgends zugesichert. Deshalb hier ausdruecklich setzen.
   UPLOAD_DIR: "/app/uploads"
 
+  # Ablage der Rechnungs-PDFs, nach Jahr und Kunde sortiert:
+  #   /app/invoices/2026/mustermann-erika/RE-2026-A3F9C1B2.pdf
+  # Muss zum mountPath des "invoices"-Volumes in 05-app-deployment.yaml
+  # passen. BEWUSST ein anderes Verzeichnis als UPLOAD_DIR: auf die Uploads
+  # zeigt eine oeffentliche Route, auf dieses Verzeichnis keine. Siehe
+  # src/lib/invoice-storage.ts und 04-uploads-pvc.yaml.
+  INVOICE_DIR: "/app/invoices"
+
   # Threads fuer das Umrechnen hochgeladener Videos (Admin -> Inhalte ->
   # Hero-Video). NICHT ohne Not erhoehen: ffmpeg teilt sich das Speicherlimit
   # dieses Pods mit dem Node-Prozess, und jeder zusaetzliche Thread haelt

k8s/04-uploads-pvc.yaml

@@ -38,3 +38,33 @@ spec:
   resources:
     requests:
       storage: 5Gi
+---
+# Ablage der Rechnungs-PDFs (INVOICE_DIR, siehe 01-configmap.yaml und
+# src/lib/invoice-storage.ts), sortiert nach Jahr und Kunde:
+#   /app/invoices/2026/mustermann-erika/RE-2026-A3F9C1B2.pdf
+#
+# BEWUSST EIN EIGENES VOLUME, nicht ein Unterordner von "uploads":
+# app/uploads/[...path]/route.ts liefert JEDE Datei unterhalb von UPLOAD_DIR
+# ohne Anmeldung aus. Laegen die Rechnungen dort, koennte jede Person, die den
+# Pfad erraet, fremde Rechnungen samt Anschrift und Bestellinhalt
+# herunterladen. Auf dieses Volume zeigt keine oeffentliche Route.
+#
+# Zweiter Grund fuer die Trennung: die Aufbewahrungsfristen sind
+# verschieden. Produktfotos lassen sich ersetzen; Rechnungen unterliegen in
+# Deutschland zehn Jahren Aufbewahrungspflicht (§ 147 AO). Dieses Volume
+# sichert der CronJob in 07-backup-cronjob.yaml taeglich mit.
+#
+# 2Gi sind reichlich bemessen: eine Rechnung ist wenige Kilobyte gross, das
+# reicht fuer weit mehr Bestellungen, als die Aufbewahrungsfrist umfasst.
+apiVersion: v1
+kind: PersistentVolumeClaim
+metadata:
+  name: wabenhain-invoices
+  namespace: wabenhain
+spec:
+  accessModes:
+    - ReadWriteOnce
+  # storageClassName: "dein-storage-class"
+  resources:
+    requests:
+      storage: 2Gi

k8s/05-app-deployment.yaml

@@ -77,6 +77,12 @@ spec:
             # (fehlende Volume-Referenz).
             - name: uploads
               mountPath: /app/uploads
+            # Rechnungsablage, getrennt von den Uploads — auf dieses
+            # Verzeichnis zeigt bewusst KEINE oeffentliche Route. Muss zu
+            # INVOICE_DIR in 01-configmap.yaml passen, ausfuehrliche
+            # Begruendung in 04-uploads-pvc.yaml.
+            - name: invoices
+              mountPath: /app/invoices
           # Prueft die Datenbank mit (siehe app/api/health/ready/route.ts).
           # Schlaegt sie fehl, nimmt Kubernetes den Pod nur aus dem
           # Load-Balancing, startet ihn aber nicht neu.
@@ -158,6 +164,9 @@ spec:
         - name: uploads
           persistentVolumeClaim:
             claimName: wabenhain-uploads
+        - name: invoices
+          persistentVolumeClaim:
+            claimName: wabenhain-invoices
 ---
 apiVersion: v1
 kind: Service

k8s/07-backup-cronjob.yaml

@@ -105,14 +105,25 @@ spec:
                     | gzip -9 > "${target}.partial"
                   mv "${target}.partial" "${target}"
 
+                  # Rechnungsablage mitsichern (INVOICE_DIR, siehe
+                  # 04-uploads-pvc.yaml). Die Datenbank kennt von einer
+                  # Rechnung nur Nummer, Betrag und Pfad — das ausgelieferte
+                  # PDF liegt ausschliesslich auf dem Volume. Ein
+                  # Datenbank-Dump allein ersetzt den Beleg also NICHT.
+                  invoices="/backup/rechnungen-${stamp}.tar.gz"
+                  tar -czf "${invoices}.partial" -C /invoices .
+                  mv "${invoices}.partial" "${invoices}"
+
                   # Angefangene Dateien frueherer Abbrueche mit aufraeumen.
                   find /backup -name 'wabenhain-*.sql.gz.partial' -mtime +1 -delete
+                  find /backup -name 'rechnungen-*.tar.gz.partial' -mtime +1 -delete
 
                   # 30 Tage Aufbewahrung. Achtung: ersetzt KEINE
                   # langfristige Archivierung der Rechnungen (§ 147 AO,
                   # zehn Jahre) — dafuer die Rechnungs-PDFs bzw. regelmaessig
                   # ausgelagerte Sicherungen nutzen.
                   find /backup -name 'wabenhain-*.sql.gz' -mtime +30 -delete
+                  find /backup -name 'rechnungen-*.tar.gz' -mtime +30 -delete
 
                   echo "Sicherung abgeschlossen:"
                   ls -lh /backup
@@ -125,7 +136,24 @@ spec:
               volumeMounts:
                 - name: backup
                   mountPath: /backup
+                # Nur lesend: dieser Job darf Belege sichern, niemals aendern.
+                - name: invoices
+                  mountPath: /invoices
+                  readOnly: true
           volumes:
             - name: backup
               persistentVolumeClaim:
                 claimName: wabenhain-db-backup
+            # ACHTUNG bei mehr als einem Knoten: wabenhain-invoices ist
+            # ReadWriteOnce (04-uploads-pvc.yaml). Ein solches Volume laesst
+            # sich nur von Pods auf DEMSELBEN Knoten einhaengen. Landet dieser
+            # Sicherungs-Pod auf einem anderen Knoten als der App-Pod, bleibt
+            # er in "Pending" haengen — sichtbar nur, wenn man nachsieht,
+            # denn ein Pending-Pod meldet keinen Fehler.
+            #
+            # Auf einem Ein-Knoten-Cluster ist das kein Thema. Bei mehreren
+            # Knoten das PVC auf ReadWriteMany umstellen (NFS/SMB/CephFS) —
+            # dann greift die Einschraenkung nicht mehr.
+            - name: invoices
+              persistentVolumeClaim:
+                claimName: wabenhain-invoices