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>
58 lines
2.8 KiB
SQL
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);
|