Bestandskorrektur (GoBD-Verfahrensdokumentation)

Diese Seite ist die Verfahrensdokumentation für das Feature „Bestandskorrektur" im WMS-Modul. Sie ist Bestandteil der GoBD-Pflichtdokumentation und muss bei einer Betriebsprüfung vorgelegt werden können.

1. Zweck und Anwendungsbereich

Die Bestandskorrektur erlaubt autorisierten Mitarbeitern, den Lagerbestand eines Artikels manuell zu reduzieren oder zu erhöhen, wenn der reale Bestand vom Systembestand abweicht. Typische Anlässe:

• Diebstahl (Laden- oder Lagerdiebstahl)
• Bruch / Beschädigung
• Inventur-Differenzen (Plus oder Minus)
• Vernichtung am Saison- oder Produktende
• Eigenverbrauch (Showroom, Foto-Shoot)
• Marketing-Samples / Presse / Influencer
• Kulanz-Ersatz ohne Retoure-Beleg
• Qualitäts-Mängel, die nach der Einlagerung erkannt wurden
• Bestand, der wieder aufgetaucht ist

Die Funktion ist nicht für regulären Wareneingang oder Standort-Umlagerungen vorgesehen — dafür existieren eigene Routen.

2. Reason-Code-Katalog

Jede Buchung muss einen Reason-Code haben. Reasons sind im System hartcodiert und versioniert.

3. Pflichtfelder und Validierungsregeln

Weitere Validierungen:

• inventory_diff_loss ist nur in Richtung out zulässig.
• inventory_diff_gain und found sind nur in Richtung in zulässig.
• Bei Direction out: Source-Lagerplatz muss genug Bestand haben (Pessimistic Lock, ADR-0022).

4. Rollen-/Berechtigungs-Matrix

Zugriff wird über die Permission wms-correct-stock gesteuert:

Permission-Check passiert in jeder API-Route (apps/web/src/app/api/wms/adjustments/**) über canAccessModule(role, 'wms-correct-stock', extraModules).

5. Korrektur- und Storno-Workflow

┌────────────────────────────┐
│ Benutzer öffnet /warehouse/│
│ adjustments/new            │
└──────────┬─────────────────┘
           │
┌──────────▼─────────────────┐
│ Formular: Richtung, Site,  │
│ Location, Artikel, Menge,  │
│ Reason-Code, Notiz         │
└──────────┬─────────────────┘
           │
┌──────────▼─────────────────┐
│ Confirm-Dialog mit         │
│ Übersicht aller Felder     │
└──────────┬─────────────────┘
           │
┌──────────▼─────────────────┐
│ POST /api/wms/adjustments  │
│  → bookMovement (Ledger)   │
│  → next_doc_no (Beleg-Nr.) │
│  → INSERT stock_adjustments│
└──────────┬─────────────────┘
           │
┌──────────▼─────────────────┐
│ Success-Card mit Belegnr.  │
└────────────────────────────┘

Storno (kein Edit, kein Delete):

1. Original-Buchung bleibt unverändert (Append-only-Trigger blockt UPDATE/DELETE).
2. User öffnet Detail-Seite → klickt "Stornieren" → Pflicht-Begründung (≥ 3 Zeichen).
3. System legt eine neue Adjustment-Zeile an mit:
   • invertierter direction
   • gleicher quantity / location_id / variant_id
   • reason_code = 'correction_other'
   • reverses_id → ID der Original-Buchung
   • eigener neuer doc_no
4. Die Bestandsbewegung wird symmetrisch über das normale Movement-Ledger gebucht.

Eine Buchung kann nur einmal storniert werden; ein Storno selbst kann nicht erneut storniert werden.

6. Datenfelder pro Buchung (für Prüfer)

Tabelle stock_adjustments:

7. Aufbewahrung

• Die Tabelle stock_adjustments ist append-only: UPDATE und DELETE werden durch einen Datenbank-Trigger (stock_adjustments_no_update, stock_adjustments_no_delete) blockiert.
• Die zugehörige Bewegung in stock_movements ist ebenfalls append-only (stock_movements_no_update, stock_movements_no_delete).
• Die Daten werden mindestens 8 Jahre aufbewahrt (§ 147 AO, Buchungsbelege seit 2025). Ein automatisierter Cleanup ist derzeit nicht eingerichtet; sollte er später per pg_cron ergänzt werden, gilt diese Frist als Mindestalter.

8. Datenzugriff Z3 (Betriebsprüfer)

Für Z3-Prüfungen kann der CSV-Export verwendet werden:

GET /api/wms/adjustments/export?from_date=2026-01-01&to_date=2026-12-31

Response: text/csv; charset=utf-8 mit UTF-8 BOM (Excel-kompatibel), Spalten in dieser Reihenfolge:

doc_no, created_at, direction, reason_code, reason_note, site_id, location_id, variant_id, quantity, movement_id, reverses_id, created_by

Der Export ist nur für Benutzer mit Permission wms-correct-stock zugänglich und filtert serverseitig nach tenant_id.

9. Änderungshistorie der Doku