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>
41 lines
2.0 KiB
SQL
41 lines
2.0 KiB
SQL
-- 0026_delivery_report_jobs.sql
|
|
--
|
|
-- Zustandsanker für die Übertragung des PDF-Lieferreports an DOCUframe.
|
|
-- Beim Abschluss wird der Report erzeugt und in DOCUframe abgelegt; das ist
|
|
-- ein mehrstufiger, netzabhängiger Vorgang (Upload → ~ObjectID → Makro
|
|
-- `_SV_assignDeliveryReport`). Damit nichts verloren geht und fehlgeschlagene
|
|
-- Übertragungen per Cron wiederholt werden können, hält diese Tabelle den
|
|
-- Fortschritt **hart** in Postgres.
|
|
--
|
|
-- Genau eine Zeile pro Lieferung (PK = delivery_id). `status` ist die
|
|
-- Resume-Marke; ein Retry führt nur die noch offenen Schritte aus:
|
|
-- * 'pending' — angelegt, noch nichts übertragen
|
|
-- * 'uploaded' — PDF liegt in DOCUframe, `docuframe_object_id` gesetzt,
|
|
-- Makro-Zuordnung steht noch aus
|
|
-- * 'done' — Makro erfolgreich; lokale Dateien wurden aufgeräumt
|
|
--
|
|
-- Fehlersemantik: schlägt ein Schritt fehl, bleibt `status` auf der erreichten
|
|
-- Stufe, `last_error`/`attempts`/`last_attempt_at` werden gesetzt. Der Cron
|
|
-- greift alle Zeilen mit status <> 'done' erneut auf.
|
|
|
|
CREATE TABLE delivery_report_jobs (
|
|
delivery_id UUID PRIMARY KEY REFERENCES deliveries(id) ON DELETE CASCADE,
|
|
belegnummer TEXT NOT NULL,
|
|
status TEXT NOT NULL DEFAULT 'pending'
|
|
CHECK (status IN ('pending', 'uploaded', 'done')),
|
|
-- DOCUframe ~ObjectID des hochgeladenen Reports — hart gespeichert nach
|
|
-- dem Upload, damit ein Retry nicht doppelt hochlädt.
|
|
docuframe_object_id TEXT,
|
|
-- Zeitpunkt der erfolgreichen Makro-Zuordnung (= „Report hochgeladen").
|
|
report_uploaded_at TIMESTAMPTZ,
|
|
attempts INT NOT NULL DEFAULT 0,
|
|
last_error TEXT,
|
|
last_attempt_at TIMESTAMPTZ,
|
|
created_at TIMESTAMPTZ NOT NULL DEFAULT now(),
|
|
updated_at TIMESTAMPTZ NOT NULL DEFAULT now()
|
|
);
|
|
|
|
-- Schneller Zugriff des Retry-Cron auf offene Jobs.
|
|
CREATE INDEX delivery_report_jobs_open ON delivery_report_jobs (status)
|
|
WHERE status <> 'done';
|