Dokumentenumläufe & Prüfungen
circulations
crm_office
🛡️ RLS Protected
Dokumentenumläufe & Prüfungen — aus Code abgeleitete Prozess- und API-Dokumentation.
⚡ Workflows & Lifecycles
Benutzerbefehl: circulation agent
plan:command_circulation_agent
Geprüfter Durable-Plan (durable_plan), Start: manual_command.
Umlauf
status:circulation
Beobachtbare Zustandsmaschine (observable_only). Übergänge hier nicht erzwungen — siehe Service-Validierung.
⚙️ Fachprozesse & Capabilities (System-Fachlogik)
Registrierte Fachoperationen und System-Capabilities dieses Moduls zur Steuerung von Workflows, Kaskaden und KI-Agenten.
| Capability & Schlüssel | Fachliche Bezeichnung | Ausführung / Coverage | Risikostufe & Freigabe | Effekte & Kaskaden |
|---|---|---|---|---|
Agent-Einstieg circulation_agent
agent_entry:circulation_agent
|
Agent-Einstieg circulation_agent
Quelle:
code:module_agent_map
|
manual_entry |
✓ Auto
|
Keine Seiteneffekte deklariert |
Umlauf abbrechen
capability:circulation.cancel
Op:
circulation.cancel
|
Objekt:
circulation
Quelle:
code:capability_registry
|
⚙️ Engine |
✓ Auto
Risiko:
business_record
|
|
Umlaufschritt abschließen
capability:circulation.complete_step
Op:
circulation.complete_step
|
Objekt:
circulation
Quelle:
code:capability_registry
|
⚙️ Engine |
✓ Auto
Risiko:
business_record
|
|
Umlauf anlegen
capability:circulation.create
Op:
circulation.create
|
Objekt:
circulation
Quelle:
code:capability_registry
|
⚙️ Engine |
✓ Auto
Risiko:
business_record
|
|
Umlauf starten
capability:circulation.start
Op:
circulation.start
|
Intent:
start_circulation
Quelle:
code:capability_registry
|
⚙️ Engine |
✓ Auto
Risiko:
business_record
|
|
Circulation: add assignee
capability:circulations.circulation.add_assignee
Op:
circulations.circulation.add_assignee
|
Objekt:
circulation
Quelle:
code:capability_registry
|
⚙️ Engine |
✓ Auto
Risiko:
business_record
|
|
Circulation: add comment
capability:circulations.circulation.add_comment
Op:
circulations.circulation.add_comment
|
Objekt:
circulation
Quelle:
code:capability_registry
|
⚙️ Engine |
✓ Auto
Risiko:
business_record
|
|
Circulation: add document
capability:circulations.circulation.add_document
Op:
circulations.circulation.add_document
|
Objekt:
circulation
Quelle:
code:capability_registry
|
⚙️ Engine |
✓ Auto
Risiko:
business_record
|
|
Circulation: add stamp
capability:circulations.circulation.add_stamp
Op:
circulations.circulation.add_stamp
|
Objekt:
circulation
Quelle:
code:capability_registry
|
⚙️ Engine |
✓ Auto
Risiko:
business_record
|
|
Circulation: cancel
capability:circulations.circulation.cancel
Op:
circulations.circulation.cancel
|
Objekt:
circulation
Quelle:
code:capability_registry
|
⚙️ Engine |
✓ Auto
Risiko:
business_record
|
|
Circulation: complete step
capability:circulations.circulation.complete_step
Op:
circulations.circulation.complete_step
|
Objekt:
circulation
Quelle:
code:capability_registry
|
⚙️ Engine |
✓ Auto
Risiko:
business_record
|
|
Circulation: create
capability:circulations.circulation.create
Op:
circulations.circulation.create
|
Objekt:
circulation
Quelle:
code:capability_registry
|
⚙️ Engine |
✓ Auto
Risiko:
business_record
|
|
Circulation: remove assignee
capability:circulations.circulation.remove_assignee
Op:
circulations.circulation.remove_assignee
|
Objekt:
circulation
Quelle:
code:capability_registry
|
⚙️ Engine |
✓ Auto
Risiko:
business_record
|
|
Circulation: remove document
capability:circulations.circulation.remove_document
Op:
circulations.circulation.remove_document
|
Objekt:
circulation
Quelle:
code:capability_registry
|
⚙️ Engine |
✓ Auto
Risiko:
business_record
|
|
Circulation: start
capability:circulations.circulation.start
Op:
circulations.circulation.start
|
Objekt:
circulation
Quelle:
code:capability_registry
|
⚙️ Engine |
✓ Auto
Risiko:
business_record
|
|
Circulation: update
capability:circulations.circulation.update
Op:
circulations.circulation.update
|
Objekt:
circulation
Quelle:
code:capability_registry
|
⚙️ Engine |
✓ Auto
Risiko:
business_record
|
|
Circulation: update step
capability:circulations.circulation.update_step
Op:
circulations.circulation.update_step
|
Objekt:
circulation
Quelle:
code:capability_registry
|
⚙️ Engine |
✓ Auto
Risiko:
business_record
|
|
circulation: edit form
form_surface_anchor:circulation.edit
|
Objekt:
circulation
Quelle:
code:erp_form_surface
|
operator_surface |
✓ Auto
|
Keine Seiteneffekte deklariert |
Benutzerbefehl: circulation agent
plan:command_circulation_agent
|
Benutzerbefehl: circulation agent
Quelle:
code:reviewed_execution_plan
|
durable_plan |
✓ Auto
|
Keine Seiteneffekte deklariert |
Umlauf
status:circulation
|
Objekt:
circulation
Quelle:
code:status_machine
|
observable_only |
✓ Auto
|
Keine Seiteneffekte deklariert |
🧠 Fachprozess-Erzählung & Dual Knowledge Architektur
Synthese aus der ideologischen Blaupause (Meta-Fachlogik / Soll), der faktischen System-Implementierung (System-Fachlogik / Ist) und No-Code Customizing für KI-Consultants.
Der durchgängige Businessprozess im Detail (End-to-End Fließtext-Erzählung)
Der durchgängige Posteingangs- und Belegverarbeitungsprozess in der Praxis
In jedem modernen Unternehmen treffen täglich hunderte Dokumente und E-Mails unstrukturiert ein: Angebote, Bestellungen, Rechnungen, Reklamationen und allgemeine Anfragen. Centurio ERP überführt diese Informationsflut durch intelligente Vorverarbeitung und automatisierte Kaskaden in strukturierte Geschäftsprozesse.
1. Multi-Channel-Posteingang & Dokumentenaufnahme
Das Modul inbox aggregiert alle Eingangskanäle an einem zentralen Ort:
- E-Mail-Postfächer (
communications): Über angebundene IMAP- oder Exchange-Postfächer (z.B. info@, einkauf@, vertrieb@, rechnung@) werden E-Mails inklusive aller Dateianhänge (PDF, TIFF, JPEG) automatisch im 60-Sekunden-Takt abgeholt. - Scanner & Digitalkopierer: Multifunktionsdrucker scannen Papierdokumente direkt in das ERP-Eingangspostfach (
cap:inbox.item.create_from_scan). - Web-Upload & Mobile App: Mitarbeiter oder Kunden laden Belege per Drag & Drop oder Smartphone-Kamera hoch.
2. Optische Texterkennung (OCR) & Layout-Analyse
Sobald ein Dokument eintrifft, durchläuft es die OCR-Pipeline:
- Volltext-Extraktion: Das System wandelt Bilddaten und gescannte PDFs in durchsuchbaren Reintext um.
- Layout-Segmentierung: Die Engine erkennt Kopfdaten, Tabellenzeilen (z.B. Positionstabellen mit Artikel, Menge, Einzelpreis) und Fußzeilen (Steuerbeträge, IBAN, USt-IdNr.).
3. Semantische Klassifikation & Absender-Matching
Nun greift die integrierte KI- und Regel-Engine:
- Absender-Identifikation: Die E-Mail-Adresse oder die im Beleg gefundene Firmierung/USt-IdNr. wird gegen den Datenbestand abgeglichen:
- Ist es ein Bestandskunde (
customers)? - Ist es ein Lieferant (
suppliers)? - Handelt es sich um einen bisher unbekannten Dritten (Erstkontakt)?
- Ist es ein Bestandskunde (
- Dokumenten-Klassifikation: Der Textinhalt wird semantisch kategorisiert:
- Neukunden-Anfrage (Lead Inquiry)
- Bestellung / Bestellanforderung (Purchase Order)
- Eingangsrechnung / Gutschrift (Invoice)
- Lieferanten-Auftragsbestätigung (Order Ack)
- Reklamation / Mängelrüge (Complaint)
- Allgemeine Korrespondenz / Spam
4. Die Kaskadierungs-Engine (Automatisierte Folgeprozesse)
Anhand des Absenders und der Absichtsklassifikation löst das System determinierte Fachkaskaden aus:
Fall A: Neukundenanfrage ➔ CRM-Lead-Kaskade
- Kontext: E-Mail eines unbekannten Absenders mit Anforderung von Produktinformationen oder Beratung.
- Ablauf: Das System legt automatisch einen neuen
CrmLeadim Status Neu an (cap:crm.lead.create_from_inbox). Die KI extrahiert Ansprechpartner, Firma, Telefonnummer und das Kernanliegen in strukturierte Felder und weist den Lead dem diensthabenden Vertriebsmitarbeiter zu.
Fall B: Mail-Bestellung eines bekannten Kunden ➔ Angebots-/Auftragsentwurf
- Kontext: Ein bekannter Kunde schreibt: "Hallo, bitte liefert uns wie gewohnt 50x Artikel A und 20x Artikel B bis nächste Woche Dienstag."
- Ablauf:
- Das System matcht die E-Mail auf das bestehende Kundenkonto (
Customer). - Die KI extrahiert die Artikelbezeichnungen und gleicht sie gegen den Artikelstamm (
products) ab. - Es wird automatisch ein Angebots- oder Auftragsentwurf (
quotes,sales) angelegt (cap:quotes.quote.create_from_inbox). - Dem zuständigen Sachbearbeiter wird ein fertiger Vorschlag zur Bestätigung vorgelegt: Er sieht das Originaldokument links und den vorbefüllten Beleg rechts, muss nur noch die Plausibilität prüfen und mit einem Klick freigeben.
- Das System matcht die E-Mail auf das bestehende Kundenkonto (
Fall C: Lieferantenrechnung ➔ Eingangsrechnungsprüfung
- Kontext: Eingehende Rechnung eines Lieferanten per PDF oder ZUGFeRD-XML.
- Ablauf: Das System erzeugt den Beleg in der Rechnungsprüfung (
invoices), liest Rechnungsnummer, IBAN und Rechnungsbetrag aus und startet sofort den 3-Wege-Abgleich gegen die offene Einkaufsbestellung (purchasing).
5. Revisionssichere Archivierung im Dokumentenmanagementsystem (DMS)
Nach erfolgreicher Verarbeitung oder manueller Zuordnung wird die Originaldatei nicht gelöscht:
- Das Dokument wird mit einem unveränderbaren SHA-256 Prüfzeitstempel versehen und GoBD-konform im revisionssicheren DMS (
documents) archiviert. - Der Beleg bleibt für die gesetzliche Aufbewahrungsfrist von 10 Jahren schreibgeschützt mit dem erzeugten ERP-Vorgang (Auftrag, Rechnung, Lead) verknüpft.
Meta-Fachlogik: Ideologische Blaupause, Soll-Weltbild & Normen
Meta-Fachlogik: Die ideologische Blaupause & das normative Weltbild
Die Meta-Fachlogik des Posteingangs stützt sich auf die GoBD (Grundsätze zur ordnungsmäßigen Führung digitaler Unterlagen), das Handelsgesetzbuch (§ 257 HGB) und die Abgabenordnung (§ 147 AO).
1. GoBD-Vorschriften für den Belegeingang
- Zeitgerechte Erfassung & Schutz vor Verlust (GoBD Rz. 45–52):
- Jeder geschäftsrelevante Beleg muss unverzüglich nach Eintreffen protokolliert und gegen Verlust gesichert werden.
- Das Soll-Modell verlangt ein zentrales Eingangsprotokoll, das jedes Dokument erfasst, bevor Fachbereiche Manipulationen oder Löschungen vornehmen können.
- Originalgetreue Aufbewahrung:
- Elektronisch eingegangene Belege (z.B. E-Mail-Anhänge) müssen zwingend in dem Format aufbewahrt werden, in dem sie eingegangen sind (keine bloße Papierablage nach Ausdruck!).
- Einbettung von Prüfsummen und revisionssicheren Zeitstempeln.
2. KI als Assistenz vs. rechtliche Verbindlichkeit
- Der Grundsatz der menschlichen Kontrollschranke:
- Eine KI-Klassifikation oder ein OCR-Ergebnis stellt rechtlich lediglich einen Bearbeitungsvorschlag dar.
- Das Soll-Modell verbietet das vollautomatische Festschreiben haftungs- oder finanzrelevanter Verträge ohne menschliche Verifikation oder explizit konfigurierte Freigabeschranken (Human-in-the-Loop).
3. Invarianten des Soll-Modells
- Kein Posteingangsdokument darf vor Ablauf der gesetzlichen Aufbewahrungsfrist gelöscht werden.
- Jeder verarbeitete Beleg muss einen permanenten Link zum erzeugten ERP-Geschäftsobjekt tragen.
- Eingehende Rechnungen dürfen nicht stillschweigend gebucht werden, ohne den Nachweis des Belegeingangs festzuschreiben.
Normbezug für circulations
Prüfkatalog Standards-Registry v2026.10.1. Dieser Abschnitt ordnet Prüfreferenzen zu und stellt nicht fest, dass das Modul eine Norm einhält; keine Kataloganforderung ist als PASS bewertet.
Geführte Prüfreferenzen:
bpmn-2.0.2, Business Process Model and Notation (BPMN) 2.0.2, Ausgabe BPMN 2.0.2 (2013-12). Art: technical_interoperability. Öffentlicher Text. Die Nennung ist keine Klauselprüfung. Keine modulspezifische Kataloganforderung. Die Zuordnung bleibt eine Prüfreferenz.iso-9001-2026, ISO 9001:2026 Quality management systems — Requirements, Ausgabe ISO 9001:2026 (6. Ausgabe, 2026-09-16). Art: normative. Volltext liegt nicht vor. Keine Klauselprüfung. Keine modulspezifische Kataloganforderung. Die Zuordnung bleibt eine Prüfreferenz.
Plattformweite Katalogwerke mit Geltungsbereich all (unter anderem WCAG 2.2, EN 301 549 V4.1.1, ISO 9241-110:2020, ISO 9241-210:2019, ISO/IEC 25010:2023, ISO 9001:2026, ISO/IEC 27001:2022, APQC PCF 8.0, DSGVO, EU AI Act) umfassen dieses Modul mit. Wo der Volltext fehlt, bleibt der Zugang ohne Quelle, lizenzpflichtig oder nur als öffentliche Zusammenfassung gekennzeichnet. Auch diese Nennung weist keine eingehaltene Vorgabe nach.
Systemische Fachlogik: Faktische Umsetzung in Centurio ERP & Capabilities
Systemische Fachlogik: Die faktische Umsetzung in Centurio ERP
Die System-Fachlogik dokumentiert die Realisierung im Modul inbox und der Dokumentenablage documents.
1. Datenmodelle & Semantische Schicht (ORM)
InboxItem: Posteingangseintrag (Felder:id,tenant_id,item_type[email, scan, upload, webhook],source_identifier,sender_address,subject,received_at,status[new, parsed, classified, processed, ignored],matched_customer_id,matched_supplier_id,classified_category,confidence_score).InboxAttachment: Angehängte Dokumente (Felder:inbox_item_id,file_name,mime_type,file_size_bytes,storage_path,ocr_text).Document: Revisionssicher archiviertes Dokument im DMS mit SHA-256 Hash.
2. Das Capability-Register
cap:inbox.item.create: Empfang und Speicherung einer neuen Eingangsnachricht.cap:inbox.item.run_ocr: Ausführung der optischen Texterkennung und Layoutextraktion.cap:inbox.item.classify: Semantische Klassifikation der Absicht (Lead, Order, Invoice).cap:inbox.item.match_partner: Abgleich des Absenders gegen Kunden- und Lieferantenstamm.cap:inbox.item.trigger_cascade: Ausführung der determinierten Folgekaskade (z.B. Lead-Anlage oder Angebotsentwurf).cap:inbox.item.archive_to_dms: Revisionssichere Festschreibung im DMS.
3. Der Gateway gw:inbox_cascade@v1
Sichert die automatisierte Weiterleitung ab:
- Plausibilität: Prüft Klassifikations-Konfidenz (z.B. Score > 0.85).
- Kaskaden-Ausführung: Erzeugt transaktional das Folgeobjekt (Lead in
crm, Quote-Draft inquotesoder Eingangsrechnung ininvoices). - Verknüpfung: Verlinkt die Originaldatei mit dem erzeugten Vorgang.
- Signal: Feuert
INBOX_CASCADE_EXECUTED.
4. Statusmodelle
new (Eingegangen) ➔ ocr_processed (Text extrahiert) ➔ classified (Kategorie erkannt) ➔ proposal_generated (Vorschlag vorliegend) ➔ processed (In ERP überführt) oder ignored (Spam/Privat).
KI-Consultant Leitfaden: Customizing- & No-Code-Konzept (Soll-Ist-Synthese)
KI-Consultant Blueprint: Customizing & No-Code Architektur
Anleitung für Solution Architects zur Einrichtung automatisierter Posteingangs- und Belegkaskaden.
1. Kundenanforderungsanalyse
- Welche E-Mail-Postfächer sollen angebunden werden?
- Sollen eingehende Mail-Bestellungen sofort als verbindlicher Auftrag oder als vorbefülltes Angebot angelegt werden?
- Welche Schwellenwerte für KI-Konfidenz sollen gelten (z.B. ab 85% automatische Zuordnung, darunter manuelle Prüfung)?
2. No-Code Zusatzfelder (Custom Fields)
Im No-Code Studio (/semantic/customizing):
- Auf
InboxItem:cost_center_hint(Text): Automatisch erkannte Kostenstelle im Rechnungstext.urgency_level(Auswahlliste: Normal, Dringend, Notfall): Steuert die Priorisierung im Postkorb.
3. No-Code Workflow Canvas DAGs
Blueprint A: E-Mail-Bestellung eines Stammkunden ➔ Angebotsentwurf
- Trigger-Node: Event
INBOX_MESSAGE_CLASSIFIEDmit Kategorie Customer Order. - Condition-Node:
inbox_item.matched_customer_id != null AND inbox_item.confidence_score >= 0.80. - Action-Node 1: Rufe
cap:quotes.quote.create_from_inboxauf und übernehme extrahierte Artikel. - Action-Node 2: Erzeuge eine Prüfaufgabe für den Innendienstmitarbeiter: Angebotsentwurf aus Mail bestätigen.
- Notification-Node: Sende sofortige Eingangsbestätigung an den Kunden: "Vielen Dank, Ihre Anfrage wird bearbeitet."
Blueprint B: Automatische Lead-Generierung bei Neukunden
- Trigger-Node: Event
INBOX_MESSAGE_CLASSIFIEDmit Kategorie Lead Inquiry. - Condition-Node:
inbox_item.matched_customer_id == null. - Action-Node: Rufe
cap:crm.lead.create_from_inboxauf und setze Lead-Status aufnew.
📚 Operative Prozessbegriffe & Transaktionsschnittstellen
- Eingehende E-Mails über IMAP/Exchange-Postfächer
- Gescannte Papierdokumente von Netzwerk-Multifunktionsgeräten
- Web-Uploads von Rechnungen und Lieferscheinen durch Benutzer
- Digitale Beleg-Zustellungen über API-Connectoren
- Strukturierte ERP-Vorgänge (CRM-Leads, Angebotsentwürfe, Rechnungen)
- Revisionssichere PDF/A-Archivdokumente im zentralen DMS
- Extrahierte Volltexte und Metadaten für die globale Suche
- Automatische Empfangs- und Eingangsbestätigungen an Absender
- inbox_lead_classified -> create_crm_lead: Automatische Anlage einer Verkaufschance
- inbox_order_classified -> create_quote_draft: Vorbefüllung eines Angebotsentwurfs
- inbox_invoice_classified -> trigger_incoming_invoice_match: Start des 3-Wege-Abgleichs
- inbox_processed -> archive_document_to_dms: GoBD-konforme Festschreibung im Dokumentenarchiv
- Aussortierung von Spam und privaten E-Mails vor Geschäftsarchivierung
- Manuelle Nachkorrektur bei unleserlichen Scans oder OCR-Fehlern
- Belegsplit bei mehrseitigen Sammel-PDFs mit mehreren Dokumenten
- Prüfung auf Schadsoftware und Makroviren vor Verarbeitung von Anhängen
- Postfach-Konnektoren mit TLS-Verschlüsselung und OAuth2/App-Passwörtern konfigurieren
- Mindest-Konfidenzwerte für vollautomatische Kaskadierung einstellen
- Standard-Verantwortliche für ungeklärte Posteingänge zuweisen
- No-Code Zusatzfelder für Kostenstellenhinweise und Dringlichkeit auf InboxItem anlegen
🗄️ Data Models & Fields
🔌 Entry Points (UI & APIs)
| Art | Method | Endpoint / Path | Titel & Zweck | Required Role |
|---|---|---|---|---|
| ⚡ REST API | DELETE | /api/v1/circulations/{circulation_id}/assignees/{step_id} |
remove_assignee
Semantic binding: operator_surface; mutation=True
|
circulations
|
| ⚡ REST API | DELETE | /api/v1/circulations/{circulation_id}/documents/{document_id} |
remove_document
Semantic binding: operator_surface; mutation=True
|
circulations
|
| ⚡ REST API | GET | /api/v1/circulations |
list_circulations
Semantic binding: inventory_only; mutation=False
|
circulations
|
| ⚡ REST API | GET | /api/v1/circulations/{circulation_id} |
get_circulation
Semantic binding: inventory_only; mutation=False
|
circulations
|
| ⚡ REST API | GET | /api/v1/circulations/{circulation_id}/documents/{document_id}/preview |
document_preview
Semantic binding: inventory_only; mutation=False
|
circulations
|
| ⚡ REST API | GET | /api/v1/circulations/{circulation_id}/final-pdf |
download_final_pdf
Semantic binding: inventory_only; mutation=False
|
circulations
|
| ⚡ REST API | GET | /circulations |
circulations_page
Semantic binding: inventory_only; mutation=False
|
circulations
|
| ⚡ REST API | GET | /circulations/new |
circulation_create_page
Semantic binding: inventory_only; mutation=False
|
circulations
|
| ⚡ REST API | GET | /circulations/{circulation_id} |
circulation_detail_page
Semantic binding: inventory_only; mutation=False
|
circulations
|
| ⚡ REST API | PATCH | /api/v1/circulations/{circulation_id} |
update_circulation
Semantic binding: operator_surface; mutation=True
|
circulations
|
| ⚡ REST API | PATCH | /api/v1/circulations/{circulation_id}/assignees/{step_id} |
update_assignee
Semantic binding: operator_surface; mutation=True
|
circulations
|
| ⚡ REST API | POST | /api/v1/circulations |
create_circulation
Semantic binding: operator_surface; mutation=True
|
circulations
|
| ⚡ REST API | POST | /api/v1/circulations/{circulation_id}/assignees |
add_assignee
Semantic binding: operator_surface; mutation=True
|
circulations
|
| ⚡ REST API | POST | /api/v1/circulations/{circulation_id}/begin-review |
begin_review
Semantic binding: operator_surface; mutation=True
|
circulations
|
| ⚡ REST API | POST | /api/v1/circulations/{circulation_id}/cancel |
cancel_circulation
Semantic binding: operator_surface; mutation=True
|
circulations
|
| ⚡ REST API | POST | /api/v1/circulations/{circulation_id}/comments |
add_comment
Semantic binding: operator_surface; mutation=True
|
circulations
|
| ⚡ REST API | POST | /api/v1/circulations/{circulation_id}/complete-step |
complete_step
Semantic binding: operator_surface; mutation=True
|
circulations
|
| ⚡ REST API | POST | /api/v1/circulations/{circulation_id}/documents |
add_document
Semantic binding: operator_surface; mutation=True
|
circulations
|
| ⚡ REST API | POST | /api/v1/circulations/{circulation_id}/return |
return_for_revision
Semantic binding: operator_surface; mutation=True
|
circulations
|
| ⚡ REST API | POST | /api/v1/circulations/{circulation_id}/stamps |
add_stamp
Semantic binding: operator_surface; mutation=True
|
circulations
|
| ⚡ REST API | POST | /api/v1/circulations/{circulation_id}/start |
start_circulation
Semantic binding: operator_surface; mutation=True
|
circulations
|
| ⚡ REST API | POST | /api/v1/circulations/{circulation_id}/steps/reorder |
reorder_steps
Semantic binding: operator_surface; mutation=True
|
circulations
|
| ⚡ REST API | POST | /api/v1/circulations/{circulation_id}/upload |
upload_document
Semantic binding: operator_surface; mutation=True
|
circulations
|
🛡️ Regulatory & Compliance
Dieses Modul unterliegt folgenden gesetzlichen, regulatorischen und Revisionsstandards:
- GoBD Nachvollziehbarkeit
- Mandanten-Isolation (PostgreSQL RLS)