Files
Holzleitner---Backend--aktu…/migrations/0008_payment_methods.sql
Dennis Nemec 6a9b5872e1 Backend-Arbeitsstand: ERP-Sync, Lieferlebenszyklus, Reports + config.toml
Bringt das Backend vom initialen Skeleton auf den aktuellen Arbeitsstand
(Clean Architecture: domain → application → infrastructure → api).

Wesentliche Bereiche:
- ERP-Anbindung (MSSQL-Pull der Touren, Import-Scheduler, Rückschreiben)
- Lieferlebenszyklus: Scan/Hold/Cancel/Complete, Gutschriften, Notizen,
  Bild-Anhänge, Unterschriften, PDF-Lieferreport → DOCUframe
- Stammdaten: Kunden, Artikel, Lager, Zahlungsarten, Services
- Keycloak-JWT-Gate + Fahrer-Provisionierung via Admin-API
- Admin-API-Key-Gate (X-Admin-Api-Key) für Maschinen-Endpunkte

Jüngste Änderungen dieser Session:
- Belegspezifische Kontaktdaten: alle ERP-Adressen (Beleg-/Liefer-/
  Rechnungsadresse, Ansprechpartner, Kundenstamm) mit Telefon/Mobil/
  E-Mail werden gesynct (Migration 0029, MSSQL-Query, TourDetails)
- Konfiguration von .env (envy/dotenvy) auf config.toml (toml/serde)
  umgestellt; Vorlage config.example.toml, Pfad via HOLZLEITNER_CONFIG

Nicht im Repo (per .gitignore): config.toml (Secrets), data/ (Laufzeit-/
Kundendaten), demo.mp4, .claude/, variocontrol-ai/.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
2026-06-01 17:52:58 +02:00

58 lines
2.8 KiB
SQL

-- 0008_payment_methods.sql
--
-- Zahlungs-Stammdaten + Zahlungs-Felder an Lieferungen.
--
-- Designentscheidung: eigene Tabelle statt Enum, damit Methoden über
-- einen API-Endpoint zur Laufzeit angelegt/deaktiviert werden können
-- (z. B. neue Anbieter wie PayPal oder Klarna). FK auf `deliveries`
-- mit `ON DELETE RESTRICT` — historische Lieferungen sollen ihren
-- Methoden-Bezug niemals verlieren. Soft-Delete ist als
-- `active`-Flag möglich; Hard-Delete bleibt für nie-genutzte Methoden.
CREATE TABLE payment_methods (
id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
-- `code` ist der stabile Programm-Identifier (z. B. „cash"). Wird vom
-- Aufrufer vergeben, muss eindeutig sein. App und Berichts-Code
-- können darüber spezielle Methoden referenzieren, ohne die UUID
-- kennen zu müssen.
code TEXT NOT NULL UNIQUE,
-- Display-Name in der UI — frei änderbar via PATCH, z. B.
-- „EC-Karte" → „Girocard".
name TEXT NOT NULL,
-- Soft-Delete: deaktivierte Methoden bleiben im DB-Stamm und
-- bleiben damit für historische Lieferungen referenzierbar.
-- Bei neuen Lieferungen filtert die App standardmäßig auf
-- `active = true`.
active BOOLEAN NOT NULL DEFAULT TRUE,
created_at TIMESTAMPTZ NOT NULL DEFAULT NOW()
);
-- Initialer Stamm: die vier vom CEO definierten Methoden mit
-- deterministischen UUIDs, damit Demo-Seeds und Tests stabile Keys
-- haben.
INSERT INTO payment_methods (id, code, name) VALUES
('99999999-9999-9999-9999-999999999901', 'cash', 'Bar'),
('99999999-9999-9999-9999-999999999902', 'ec_card', 'EC-Karte'),
('99999999-9999-9999-9999-999999999903', 'credit_card', 'Kreditkarte'),
('99999999-9999-9999-9999-999999999904', 'invoice', 'Auf Rechnung (14 Tage netto)');
-- Lieferungen: Vorauszahlung + gewählte Zahlungsmethode für den Rest.
-- `prepaid_amount` ist `DOUBLE PRECISION` (≈ f64), kein NUMERIC —
-- für 2 Nachkommastellen reicht das locker und die sqlx-Default-
-- Features unterstützen es nativ ohne extra Crates.
ALTER TABLE deliveries
ADD COLUMN prepaid_amount DOUBLE PRECISION NOT NULL DEFAULT 0
CHECK (prepaid_amount >= 0),
-- Default beim Migrieren auf „cash" — die häufigste Methode. Die
-- Default-Klausel räumen wir gleich wieder ab, damit zukünftige
-- INSERTs den FK explizit setzen müssen.
ADD COLUMN payment_method_id UUID NOT NULL
DEFAULT '99999999-9999-9999-9999-999999999901'
REFERENCES payment_methods(id) ON DELETE RESTRICT;
ALTER TABLE deliveries ALTER COLUMN payment_method_id DROP DEFAULT;
-- Lookup-Index: Reports oder Filter „alle Lieferungen mit Rechnung"
-- profitieren davon. Ohne Index wäre das ein voller Tabelle-Scan.
CREATE INDEX deliveries_payment_method ON deliveries(payment_method_id);