Leitfaden
Markdown-ExportCTC/Clearance und Portale in der EU: belastbare Integrationen bauen
In Clearance‑ oder portalgetriebenen Systemen kann die Plattform‑Antwort (angenommen/abgelehnt, IDs, Zeitstempel) Teil des rechtlich relevanten Nachweises sein. Das verändert Speicherung, Retries und Support‑Prozesse.
Was „Clearance“ / CTC bedeutet (ohne Buzzwords)
In Clearance‑Modellen wird eine Rechnung an eine Plattform gesendet, die eine Bestätigung zurückgibt (oft mit Plattform‑ID). Die Zustellung an den Käufer kann von dieser Bestätigung abhängen.
Dadurch entsteht ein zusätzlicher Lebenszyklus: Entwurf → eingereicht → akzeptiert/abgelehnt → zugestellt/archiviert.
Engineering‑Folgen: Speicherung, Retries, Idempotenz
Behandeln Sie die Plattform als Zustandsmaschine. Speichern Sie: das exakte gesendete XML, Submission‑IDs, Bestätigungen, Zeitstempel und ggf. von der Plattform zurückgegebene „akzeptierte“ Versionen.
Idempotenz ist entscheidend. Ein Retry darf keine doppelten Rechnungen erzeugen.
Praxis-Checkliste: Engineering‑Folgen: Speicherung, Retries, Idempotenz
Nutzen Sie diese Punkte als praktische Prüfschritte für diesen Abschnitt.
- Stabile Invoice‑Keys für Deduplizierung nutzen
- Jede Response‑Payload persistieren
- Status für Nutzer sichtbar machen (eingereicht/akzeptiert/abgelehnt)
Support‑Playbook: was Sie schnell beantworten müssen
Wenn eine Rechnung im Clearance‑Modell scheitert, brauchen Nutzer klare Antworten: Was ist fehlgeschlagen (Daten vs Zustellung), was ist zu korrigieren, und kann man sicher erneut senden?
Bauen Sie „Support‑Artefakte“ ins Produkt: downloadbares XML, Validator‑Logs und Plattform‑Bestätigungs‑IDs.