Centurio System & Module Documentation
🏛️ Platform Architecture 🔑 Login
All Modules / sales_billing / Streckengeschäft (Dropshipping)
🚚

Streckengeschäft (Dropshipping)

dropship sales_billing 🛡️ RLS Protected

Direktbelieferung vom Lieferanten an den Endkunden, Lieferanten-PO-Generierung und Fakturierungsfreigabe-Sperre.

Fachliche Bestimmung: Bildet echte Dreiecks- und Streckengeschäfte nahtlos in Einkauf und Verkauf ab. Beim Annehmen eines Angebots mit Streckenpositionen wird automatisch eine Einkaufsbestellung an den Lieferanten mit der Lieferadresse des Kunden generiert. Gleichzeitig wird die Kundenrechnung für diese Position durch ein Billing Release Gate gesperrt, bis der physische Zustellnachweis (Proof of Delivery / Tracking) vorliegt.

⚡ Workflows & Lifecycles

Strecken-Lebenszyklus & Fakturasperre dropship_lifecycle

Kaufmännischer und logistischer Ablauf des Streckengeschäfts ohne Zwischenlagerung.

sequenceDiagram Customer->>ERP: Bestellt Artikel (Route: Dropship) ERP->>Supplier: PO (Lieferadresse: Kunde, Typ: dropship) Note over ERP: billing_released = False (Fakturasperre) Supplier->>Customer: Liefert Ware direkt aus Supplier-->>ERP: Sendungsnummer / Zustellnachweis ERP->>ERP: Status = delivered & billing_released = True ERP->>Customer: Ausgangsrechnung wird generiert
1. ROUTE_DETECTION
Routenerkennung
resolve_route ermittelt Streckengeschäft anhand von Produktkategorie oder Positions-Override.
Aktionen: Lagerbedarf überspringen
2. PURCHASE_ORDER
Bestellgenerierung
DropshipService bündelt Positionen nach Lieferant und erzeugt PO mit procurement_type='dropship'.
Aktionen: Lieferanschrift = Kundenadresse
3. TRACKING
Versandüberwachung
Lieferant meldet Tracking-Nummer und Versanddienstleister.
Aktionen: Status 'in_transit'
4. DELIVERY_CONFIRM
Zustellung
Bestätigung der Zustellung beim Kunden (POD).
Aktionen: Status 'delivered'
5. BILLING_RELEASE
Fakturafreigabe
billing_released wird auf True gesetzt; Kundenrechnung wird freigeschaltet.
Aktionen: Ausgangsrechnung erstellbar

Kundenauftrag → Abwicklung cascade:business.customer_order.fulfill

Kaskade (review_gated).

1. order
Verkaufsauftrag anlegen / bestätigen
sales
Aktionen: sales.create
2. issue
Warenausgang als Entwurf buchen
inventory
Aktionen: stock.issue.create
3. tour
Auslieferungstour einplanen
logistics
Aktionen: create_tour
4. project
Projekt / Kostenstelle zuordnen
projects
Aktionen: link_project
5. task
Auftrag ausführen / abrechnen
tasks
Aktionen: create_task

Verkaufsauftrag anlegen / bestätigen cascade_target:business.sales_order.create

Kaskade (review_gated).

1. cascade
Verkaufsauftrag anlegen / bestätigen

Benutzerbefehl: sales order agent plan:command_sales_order_agent

Geprüfter Durable-Plan (durable_plan), Start: manual_command.

1. sales_order_agent
sales_order_agent
{"key": "execute_command", "label": "Befehl prüfen, ausführen oder zur Freigabe vorlegen", "adapter": "agent.execute", "agent": "sales_order_agent", "condition_fact": null}
Aktionen: sales_order_agent

⚙️ Fachprozesse & Capabilities (System-Fachlogik)

Registrierte Fachoperationen und System-Capabilities dieses Moduls zur Steuerung von Workflows, Kaskaden und KI-Agenten.

Gesamt: 48 manual_entry: 1 engine: 35 reviewed: 2 review_gated: 2 operator_surface: 2 engine_step: 5 durable_plan: 1
Capability & Schlüssel Fachliche Bezeichnung Ausführung / Coverage Risikostufe & Freigabe Effekte & Kaskaden
Agent-Einstieg quote_agent agent_entry:quote_agent
Agent-Einstieg quote_agent
Quelle: code:module_agent_map
manual_entry
✓ Auto
Keine Seiteneffekte deklariert
Verkaufsauftrag stornieren capability:cancel_sales_order
Op: cancel_sales_order
Objekt: sales_order
Quelle: code:capability_registry
⚙️ Engine
✓ Auto Risiko: business_record
  • sales_order.cancelled
Lieferung abschließen capability:complete_sales_delivery
Op: complete_sales_order_delivery
Objekt: sales_order
Quelle: code:capability_registry
⚙️ Engine
✓ Auto Risiko: business_record
  • sales_order.delivered
Auftragslieferung abschließen capability:complete_sales_order_delivery
Op: complete_sales_order_delivery
Objekt: sales_order
Quelle: code:capability_registry
⚙️ Engine
✓ Auto Risiko: business_record
  • sales_order.delivered
Verkaufsauftrag abwickeln capability:confirm_and_fulfil_sales_order
Op: confirm_and_fulfil_sales_order
Intent: fulfil_sales_order
Quelle: code:capability_registry
reviewed
🔒 Freigabe nötig Risiko: business_record
  • engine:sales_fulfillment
Verkaufsauftrag bestätigen capability:confirm_sales_order
Op: confirm_sales_order
Objekt: sales_order
Quelle: code:capability_registry
⚙️ Engine
✓ Auto Risiko: business_record
  • sales_order.confirmed
Auftrag aus Angebot anlegen capability:create_sales_order_from_quote
Op: create_sales_order_from_quote
Objekt: quote
Quelle: code:capability_registry
⚙️ Engine
✓ Auto Risiko: business_record
  • sales_order.created
Rahmenabruf capability:sales.blanket.release
Op: sales.blanket.release
Objekt: sales_order
Quelle: code:capability_registry
⚙️ Engine
✓ Auto Risiko: business_record
  • sales.blanket.release
Provision abgrenzen capability:sales.commission.accrue
Op: sales.commission.accrue
Objekt: sales_order
Quelle: code:capability_registry
⚙️ Engine
✓ Auto Risiko: business_record
  • sales.commission.accrue
Verkaufsauftrag anlegen / bestätigen capability:sales.create
Op: sales.create
Objekt: sales.create
Quelle: code:capability_registry
reviewed
🔒 Freigabe nötig Risiko: business_record
  • cascade:business.sales_order.create
Gutschrift aus Auftrag capability:sales.credit_note.from_order
Op: sales.credit_note.from_order
Objekt: sales_order
Quelle: code:capability_registry
⚙️ Engine
✓ Auto Risiko: business_record
  • sales.credit_note.from_order
Rückstand auslösen capability:sales.order.backorder_release
Op: sales.order.backorder_release
Objekt: sales_order
Quelle: code:capability_registry
⚙️ Engine
✓ Auto Risiko: business_record
  • sales.order.backorder_release
Verkaufsauftrag stornieren capability:sales.order.cancel
Op: sales.order.cancel
Objekt: sales_order
Quelle: code:capability_registry
⚙️ Engine
🔒 Freigabe nötig Risiko: business_record
  • sales_order.cancelled
Verkaufsauftrag bestätigen capability:sales.order.confirm
Op: sales.order.confirm
Objekt: sales_order
Quelle: code:capability_registry
⚙️ Engine
🔒 Freigabe nötig Risiko: business_record
  • sales_order.confirmed
Verkaufsauftrag anlegen capability:sales.order.create
Op: sales.order.create
Objekt: sales_order
Quelle: code:capability_registry
⚙️ Engine
✓ Auto Risiko: business_record
  • sales_order.created
Rechnung aus Verkaufsauftrag capability:sales.order.create_invoice
Op: sales.order.create_invoice
Objekt: sales_order
Quelle: code:capability_registry
⚙️ Engine
🔒 Freigabe nötig Risiko: external_effect
  • invoice.draft_created
Aufträge zusammenführen capability:sales.order.merge
Op: sales.order.merge
Objekt: sales_order
Quelle: code:capability_registry
⚙️ Engine
✓ Auto Risiko: business_record
  • sales.order.merge
Teilrechnung aus Auftrag capability:sales.order.partial_invoice
Op: sales.order.partial_invoice
Objekt: sales_order
Quelle: code:capability_registry
⚙️ Engine
✓ Auto Risiko: business_record
  • sales.order.partial_invoice
Reservierung freigeben capability:sales.order.release_reservation
Op: sales.order.release_reservation
Objekt: sales_order
Quelle: code:capability_registry
⚙️ Engine
✓ Auto Risiko: business_record
  • sales.order.release_reservation
Bestand reservieren capability:sales.order.reserve_stock
Op: sales.order.reserve_stock
Objekt: sales_order
Quelle: code:capability_registry
⚙️ Engine
✓ Auto Risiko: business_record
  • sales.order.reserve_stock
Lieferung planen capability:sales.order.schedule_delivery
Op: sales.order.schedule_delivery
Objekt: sales_order
Quelle: code:capability_registry
⚙️ Engine
✓ Auto Risiko: business_record
  • sales.order.schedule_delivery
Auftrag splitten capability:sales.order.split
Op: sales.order.split
Objekt: sales_order
Quelle: code:capability_registry
⚙️ Engine
✓ Auto Risiko: business_record
  • sales.order.split
Lieferung starten capability:sales.order.start_delivery
Op: sales.order.start_delivery
Objekt: sales_order
Quelle: code:capability_registry
⚙️ Engine
✓ Auto Risiko: business_record
  • sales_order.delivery_started
Preise neu berechnen capability:sales.price.recalculate
Op: sales.price.recalculate
Objekt: sales_order
Quelle: code:capability_registry
⚙️ Engine
✓ Auto Risiko: business_record
  • sales.price.recalculate
Sales Order: add item capability:sales.sales_order.add_item
Op: sales.sales_order.add_item
Objekt: sales_order
Quelle: code:capability_registry
⚙️ Engine
✓ Auto Risiko: business_record
  • sales_order.add_item
Sales Order: cancel capability:sales.sales_order.cancel
Op: sales.sales_order.cancel
Objekt: sales_order
Quelle: code:capability_registry
⚙️ Engine
✓ Auto Risiko: business_record
  • sales_order.cancel
Sales Order: confirm capability:sales.sales_order.confirm
Op: sales.sales_order.confirm
Objekt: sales_order
Quelle: code:capability_registry
⚙️ Engine
✓ Auto Risiko: business_record
  • sales_order.confirm
Sales Order: create capability:sales.sales_order.create
Op: sales.sales_order.create
Objekt: sales_order
Quelle: code:capability_registry
⚙️ Engine
✓ Auto Risiko: business_record
  • sales_order.create
Sales Order: create from quote capability:sales.sales_order.create_from_quote
Op: sales.sales_order.create_from_quote
Objekt: sales_order
Quelle: code:capability_registry
⚙️ Engine
✓ Auto Risiko: business_record
  • sales_order.create_from_quote
Sales Order: create invoice capability:sales.sales_order.create_invoice
Op: sales.sales_order.create_invoice
Objekt: sales_order
Quelle: code:capability_registry
⚙️ Engine
✓ Auto Risiko: business_record
  • sales_order.create_invoice
Sales Order: delete item capability:sales.sales_order.delete_item
Op: sales.sales_order.delete_item
Objekt: sales_order
Quelle: code:capability_registry
⚙️ Engine
✓ Auto Risiko: business_record
  • sales_order.delete_item
Sales Order: mark delivered capability:sales.sales_order.mark_delivered
Op: sales.sales_order.mark_delivered
Objekt: sales_order
Quelle: code:capability_registry
⚙️ Engine
✓ Auto Risiko: business_record
  • sales_order.mark_delivered
Sales Order: start delivery capability:sales.sales_order.start_delivery
Op: sales.sales_order.start_delivery
Objekt: sales_order
Quelle: code:capability_registry
⚙️ Engine
✓ Auto Risiko: business_record
  • sales_order.start_delivery
Sales Order: update capability:sales.sales_order.update
Op: sales.sales_order.update
Objekt: sales_order
Quelle: code:capability_registry
⚙️ Engine
✓ Auto Risiko: business_record
  • sales_order.update
Sales Order: update item capability:sales.sales_order.update_item
Op: sales.sales_order.update_item
Objekt: sales_order
Quelle: code:capability_registry
⚙️ Engine
✓ Auto Risiko: business_record
  • sales_order.update_item
Auftrag aus Angebot umwandeln capability:sales_order_from_quote
Op: create_sales_order_from_quote
Objekt: quote
Quelle: code:capability_registry
⚙️ Engine
✓ Auto Risiko: business_record
  • sales_order.created
Lieferung anstoßen capability:start_sales_delivery
Op: start_sales_order_delivery
Objekt: sales_order
Quelle: code:capability_registry
⚙️ Engine
✓ Auto Risiko: business_record
  • sales_order.in_delivery
Auftragslieferung starten capability:start_sales_order_delivery
Op: start_sales_order_delivery
Objekt: sales_order
Quelle: code:capability_registry
⚙️ Engine
✓ Auto Risiko: business_record
  • sales_order.in_delivery
Kundenauftrag → Abwicklung cascade:business.customer_order.fulfill
Kundenauftrag → Abwicklung
Quelle: code:cascade_process
review_gated
✓ Auto
Keine Seiteneffekte deklariert
Verkaufsauftrag anlegen / bestätigen cascade_target:business.sales_order.create
Op: sales.create
Verkaufsauftrag anlegen / bestätigen
Quelle: code:cascade_target
review_gated
🔒 Freigabe nötig
Keine Seiteneffekte deklariert
sales_order: create form form_surface_anchor:sales_order.create
Objekt: sales_order
Quelle: code:erp_form_surface
operator_surface
✓ Auto
Keine Seiteneffekte deklariert
sales_order: edit form form_surface_anchor:sales_order.edit
Objekt: sales_order
Quelle: code:erp_form_surface
operator_surface
✓ Auto
Keine Seiteneffekte deklariert
Verkaufsauftrag abwickeln gateway:sales_fulfillment
Op: confirm_and_fulfil_sales_order
Verkaufsauftrag abwickeln
Quelle: code:reviewed_gateway
⚙️ Engine
✓ Auto
Keine Seiteneffekte deklariert
sales order cancel gateway:sales_order_cancel
Op: cancel_sales_order
sales order cancel
Quelle: code:engine_facade
⚙️ Engine
✓ Auto
Keine Seiteneffekte deklariert
sales order confirm gateway:sales_order_confirm
Op: confirm_sales_order
sales order confirm
Quelle: code:engine_facade
⚙️ Engine
✓ Auto
Keine Seiteneffekte deklariert
sales order delivery gateway:sales_order_delivery
Op: complete_sales_order_delivery
sales order delivery
Quelle: code:engine_facade
⚙️ Engine
✓ Auto
Keine Seiteneffekte deklariert
sales order from quote gateway:sales_order_from_quote
Op: create_sales_order_from_quote
sales order from quote
Quelle: code:engine_facade
⚙️ Engine
✓ Auto
Keine Seiteneffekte deklariert
Benutzerbefehl: sales order agent plan:command_sales_order_agent
Benutzerbefehl: sales order agent
Quelle: code:reviewed_execution_plan
durable_plan
✓ 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.

Dual Knowledge Layer
📖

Der durchgängige Businessprozess im Detail (End-to-End Fließtext-Erzählung)

Der durchgängige Verkaufsprozess in der betrieblichen Praxis

Der Verkaufsauftrag ist das zentrale juristische und operative Bindeglied zwischen Vertrieb, Fertigung, Lager und Debitorenbuchhaltung. Er manifestiert den gegenseitigen Vertrag und steuert alle nachgelagerten Erfüllungsprozesse.

1. Auftragseingang & Omnichannel-Erfassung (Order Ingestion)

Kundenaufträge gelangen über unterschiedliche Kanäle in das System:

  • Angebotskonvertierung (quotes): Der Kunde nimmt ein Angebot an; der Annahme-Gateway generiert 1:1 den Auftrag (cap:sales.sales_order.create_from_quote).
  • E-Commerce & Marktplätze (ecommerce): Shop-Bestellungen (Shopify, WooCommerce, Magento) treffen per Webhook ein. Das System validiert Preise, Steuern und Kundendaten und legt den Auftrag vollautomatisch an (cap:sales.sales_order.create_from_ecommerce).
  • Direktbestellung per E-Mail (inbox): E-Mails bekannter Kunden mit Bestellabsicht werden von der KI analysiert, Positionen gematcht und als Auftragsentwurf bereitgestellt.
  • Kassensystem Point of Sale (pos): Bar- und Kartentransaktionen im Ladengeschäft erzeugen sofortige Auftrags- und Warenausgangsbuchungen.
  • Manuelle Auftragserfassung: Der Innendienst erfasst Kundenwünsche direkt im Webportal.

2. Bonitätsprüfung, Kreditlimit & Zahlungsbedingungen

Vor der Annahme prüft das System das finanzielle Ausfallrisiko:

  • Kreditlimitprüfung: Das System ermittelt das Gesamtexposure des Kunden: $$\text{Obligo} = \text{Offene Posten (OP)} + \text{Noch nicht fakturierte Aufträge} + \text{Aktueller Auftrag}$$ Übersteigt das Obligo das im Kundenstamm (customers) hinterlegte Kreditlimit, sperrt das System die automatische Bestätigung. Der Auftrag wechselt in den Zustand Kreditsperre (credit_hold) und erfordert eine explizite Freigabe durch die Finanzbuchhaltung (cap:sales.sales_order.approve_credit_override).
  • Zahlungsbedingungen & Vorkasse: Bei Neukunden oder schlechter Bonität erzwingt das System Vorkasse: Der Auftrag wird erst für die Logistik freigegeben, wenn der Zahlungseingang auf dem Bankkonto verbucht ist.

3. Auftragsbestätigung (AB) & Vertragsschluss

  • Ist die kaufmännische Prüfung erfolgreich, wechselt der Auftrag auf Bestätigt (confirmed).
  • Auftragsbestätigung: Das System generiert die rechtsverbindliche Auftragsbestätigung nach HGB § 362 / BGB § 145 mit Angabe von Liefertermin, Zahlungsziel, Incoterms und Leistungsbeschreibung (cap:sales.sales_order.confirm_and_send).

4. Lieferterminierung & CTP-Verfügbarkeitsprüfung (Capable-to-Promise)

Parallel zur Bestätigung erfolgt die logistische Einplanung:

  • Lagerware (Make-to-Stock - MTS): Das System prüft die ATP-Verfügbarkeit. Sind Artikel auf Lager, werden sie sofort reserviert (cap:inventory.stock.reserve).
  • Fertigungsware (Make-to-Order - MTO): Handelt es sich um Sonderanfertigungen, errechnet die CTP-Engine (Capable-to-Promise) anhand der aktuellen Maschinenbelegung und Materialbeschaffungszeiten den frühestmöglichen Fertigstellungstermin. Die Verkaufsauftragszeile dockt direkt an das Fertigungsmodul an (cap:assembly.create_order_from_order_line).
  • Streckengeschäft (Dropshipping): Ist der Artikel als Streckenposition markiert, generiert das System eine direkte Beschaffungsanforderung an den Lieferanten (dropship), der die Ware direkt an den Endkunden liefert.

5. Teillieferungen & Versandsteuerung

  • Lieferpräferenzen: Der Kunde kann wählen zwischen Komplettlieferung (Versand erst, wenn alle Positionen verfügbar sind) oder Teillieferung erlaubt.
  • Warenausgangsfreigabe: Sobald reservierte Mengen im Lager bereitstehen, generiert das System den Lieferauftrag (cap:inventory.picking.generate). Nach Warenausgangsbuchung schaltet die Auftragszeile auf geliefert.

6. Fakturierung & Belegfluss (Invoice Trigger)

  • Je nach Vereinbarung erfolgt die Abrechnung:
    • Sofortfaktura nach Lieferung: Der bestätigte Lieferschein stößt unmittelbar die Ausgangsrechnung im Rechnungsmodul an (invoices).
    • Sammelrechnung: Lieferungen eines Monats werden zu einer gebündelten Monatsrechnung zusammengefasst.
    • Abschlags- und Schlussrechnung: Bei Projekten und Großaufträgen werden Meilensteinzahlungen nach Zahlungsplan abgerechnet.

7. Auftragsabschluss & Reklamationsanbindung

  • Sind alle Positionen geliefert und vollständig fakturiert, wechselt der Verkaufsauftrag über den Abschluss-Gateway in den Status Abgeschlossen (completed).
  • Treten nach Lieferung Mängel auf, dockt das Reklamationsmodul (returns) direkt an die Verkaufsauftragsnummer an, um Retouren, Ersatzlieferungen oder Gutschriften zuzuordnen.
🏛️

Meta-Fachlogik: Ideologische Blaupause, Soll-Weltbild & Normen

Meta-Fachlogik: Die ideologische Blaupause & das normative Weltbild

Die Meta-Fachlogik des Verkaufs basiert auf handelsrechtlichen Vorschriften (HGB), zivilrechtlichem Vertragsrecht (BGB), internationalen Handelsklauseln (Incoterms 2020) und Grundsätzen kaufmännischen Risikomanagements.

1. Handelsrechtliche Grundlagen & Vertragsschluss

  • Kaufmännisches Bestätigungsschreiben (HGB § 362 analog):
    • Im B2B-Geschäftsverkehr fixiert die Auftragsbestätigung den verbindlichen Vertragsinhalt. Widerspricht der Kunde nicht unverzüglich, gilt der Inhalt als vereinbart.
    • Das Soll-Modell verlangt die lückenlose Dokumentation von Angebots- und Auftragsständen sowie den Ausschluss widersprüchlicher AGB (Kollision Allgemeiner Geschäftsbedingungen).
  • Leistungs- und Erfüllungsort (Incoterms 2020):
    • Definition des Gefahrenübergangs und der Kostenverteilung: z.B. EXW (Ab Werk), FCA (Frei Frachtführer) oder DAP (Geliefert benannter Ort). Das System muss den Gefahrenübergang exakt an die Lieferscheinbuchung koppeln.

2. Risikomanagement & Funktionstrennung (Segregation of Duties)

  • Kreditrisiko-Steuerung: Vertriebsmitarbeiter dürfen keine eigenmächtigen Krediterweiterungen vornehmen. Das Soll-Modell verlangt strikte Funktionstrennung zwischen Vertrieb (Umsatzorientierung) und Debitoren-Risikomanagement (Liquiditätssicherung).
  • Lieferverzug & Pönalen: Das System muss Lieferzusagen überwachen, um Schadensersatzforderungen oder Vertragsstrafen wegen Lieferverzugs (§ 286 BGB) proaktiv abzuwenden.

3. Invarianten des Soll-Modells

  1. Keine Auslieferung ohne bestätigten Auftrag oder autorisierte Freigabe.
  2. Keine Auftragsfreigabe bei Kreditlimitüberschreitung ohne Autorisierung durch Finance.
  3. Ein bestätigter Auftrag darf nachträglich nicht stillschweigend editiert werden; Änderungen erfordern Auftragsänderungsbelege.
  4. Fakturierte Positionen sind für Preisänderungen gesperrt.

Normbezug für dropship

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:

  • scor-ds-14.0, SCOR Digital Standard (SCOR-DS) Version 14.0, Ausgabe SCOR-DS 14.0 (2025). Art: reference_process. Lizenz schließt eine inhaltliche Nutzung aus. 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 Kernmodul sales.

1. Datenmodelle & Semantische Schicht (ORM)

  • SalesOrder: Auftragskopf (Felder: id, tenant_id, order_number, customer_id, status, order_date, confirmed_delivery_date, total_net_amount, total_tax_amount, currency, incoterms, payment_term_id, shipping_address_id, billing_address_id).
  • SalesOrderLine: Auftragspositionen (Felder: sales_order_id, line_number, product_id, quantity, unit_price, discount_percent, fulfillment_type [stock, assembly, dropship], shipped_quantity, invoiced_quantity, status).
  • SalesOrderHold: Dokumentation von Liefersperren (Kreditlimit, Compliance-Check, manuelle Sperre).

2. Das Capability-Register

  • cap:sales.sales_order.create: Manuelle oder automatisierte Anlage eines Kundenauftrags.
  • cap:sales.sales_order.create_from_quote: Übernahme aller Daten aus einem Angebot.
  • cap:sales.sales_order.confirm_and_send: Bestätigung und PDF-Versand an den Kunden.
  • cap:sales.sales_order.check_credit_limit: Automatische Prüfung des Debitorenobergrenze.
  • cap:sales.sales_order.approve_credit_override: Entsperrung eines kreditsistierten Auftrags.
  • cap:sales.sales_order.reserve_stock: Auslösung der ATP-Reservierung im Lager.
  • cap:sales.sales_order.trigger_fulfillment: Kaskadierung an Lager (Pickauftrag), Fertigung (MTO) oder Dropship.
  • cap:sales.sales_order.cancel: Stornierung mit automatischer Auflösung aller Reservierungen.

3. Der Gateway gw:sales_order_fulfillment@v1

Der Erfüllungs-Gateway steuert die Übergabe an die Wertschöpfung:

  1. Validierung: Prüft Kreditstatus, steuerliche Plausibilität (z.B. USt-IdNr. bei innergemeinschaftlicher EU-Lieferung) und Vollständigkeit der Lieferadresse.
  2. Kaskadierung: Erzeugt transaktional die Reservierungen in inventory oder ruft cap:assembly.create_order_from_order_line auf.
  3. Statuswechsel: SalesOrder.status = 'processing'.
  4. Outbox-Signal: Feuert SALES_ORDER_FULFILLMENT_STARTED.

4. Statusmodelle

draft (Entwurf) ➔ credit_hold (Kreditsperre) ➔ confirmed (Bestätigt) ➔ processing (In Ausführung) ➔ partially_delivered (Teilgeliefert) ➔ delivered (Geliefert) ➔ invoiced (Fakturiert) ➔ completed (Abgeschlossen) oder cancelled (Storniert).

🤖

KI-Consultant Leitfaden: Customizing- & No-Code-Konzept (Soll-Ist-Synthese)

AI Solution Architect Blueprint

KI-Consultant Blueprint: Customizing & No-Code Architektur

Leitfaden für Solution Architects zur Einrichtung von Vertriebs-Workflows.

1. Kundenanforderungsanalyse

  • Welche Verkaufskanäle müssen synchronisiert werden (Webshop, EDI nach EDIFACT/VDA, Ladenkasse POS)?
  • Wie restriktiv soll die Kreditsperre greifen (strikter Stopp oder nur Warnhinweis)?
  • Werden Teillieferungen standardmäßig gebündelt oder sofort bei Teilverfügbarkeit versandt?

2. No-Code Zusatzfelder (Custom Fields)

Im No-Code Studio (/semantic/customizing):

  • Auf SalesOrder:
    • customer_order_reference (Text): Externe Bestellnummer des Kunden (z.B. PO-12345).
    • delivery_instructions (Mehrzeiliger Text): Sonderanweisungen für den Frachtführer (z.B. Hebebühne erforderlich, Aviso 1 Stunde vor Ankunft).
    • project_code (Text): Zuweisung zu übergeordnetem Kundenprojekt.
  • Auf SalesOrderLine:
    • customer_part_number (Text): Artikelnummer des Kunden zur Ausweisung auf Belegen.
    • serial_number_required (Checkbox): Erzwingt Seriennummernprüfung bei Auslagerung.

3. No-Code Workflow Canvas DAGs

Blueprint A: Automatischer Webshop-Bestellflow (E-Commerce Ingest DAG)
  • Trigger-Node: Webhook ecommerce.order.created.
  • Condition-Node: order.payment_status == 'paid' AND order.customer.is_fraud_suspect == false.
  • Action-Node 1: Erzeuge SalesOrder mit Status confirmed.
  • Action-Node 2: Führe cap:sales.sales_order.reserve_stock aus.
  • Branch-Node: Wenn alle Artikel lagernd ➔ Erzeuge sofort Warenausgangsauftrag; wenn Fehlteile ➔ Sende Push an Einkauf.
Blueprint B: Kreditsperren-Eskalation (Credit Hold DAG)
  • Trigger-Node: Event SALES_ORDER_CREDIT_HOLD.
  • Action-Node: Erzeuge dringende Prüfaufgabe für Debitorenbuchhaltung mit Ausweisung der überfälligen Rechnungen und des aktuellen Auftragswerts.
  • Freigabe-Gate: Erst nach Klick auf Limit erhöhen oder Einzelfreigabe erteilen wechselt der Auftrag in den Status confirmed.

📚 Operative Prozessbegriffe & Transaktionsschnittstellen

Zentrale Fachbegriffe im Prozesszusammenhang (Operatives Modell)
Auftragsbestätigung (AB)
Rechtsverbindliche Bestätigung des Vertragsschlusses mit Preisen, Terminen und Incoterms.
Kreditlimit & Obligo
Höchstgrenze des finanziellen Risikos eines Kunden aus offenen Rechnungen und laufenden Aufträgen.
CTP (Capable-to-Promise)
Prüfung der Lieferfähigkeit unter Einbeziehung künftiger Fertigungskapazitäten und Beschaffungen.
Teillieferung
Versand verfügbarer Teilmengen eines Auftrags vor Fertigstellung der Gesamtlieferung.
Dropshipping (Streckengeschäft)
Direktlieferung vom Vorlieferanten an den Endkunden ohne Zwischenlagerung.
Incoterms 2020
Internationale Handelsklauseln zur Festlegung von Transportkosten und Gefahrenübergang.
Invoicing-Trigger
Automatischer Anstoß der Rechnungsstellung nach Lieferscheinquittierung.
📥 Eingänge & Trigger (Inputs)
  • Angenommenes Angebot aus dem Quotes-Modul
  • E-Commerce-Bestellung über Shop-Konnektoren (Shopify, WooCommerce)
  • Manuelle Auftragserfassung durch den Vertriebsinnendienst
  • Elektronischer Datenaustausch (EDI / EDIFACT ORDERS)
📤 Ausgänge & Arbeitsergebnisse (Outputs)
  • Rechtsverbindliche Auftragsbestätigung (PDF) mit Lieferterminzusage
  • Lagerreservierungen für Vorratsartikel (ATP)
  • Fertigungsanforderungen für kundenindividuelle Baugruppen (MTO)
  • Liefer- und Kommissionieraufträge für die Versandlogistik
  • Fakturierungsaufträge für die Debitorenbuchhaltung
⚡ Kaskaden & Folgeprozesse (Cascades)
  • order_confirmed -> stock_reservation: Sofortige Bestandsreservierung im Lager
  • order_confirmed -> trigger_mto_assembly: Erzeugung von Fertigungsaufträgen bei MTO
  • order_shipped -> invoice_generation: Automatischer Rechnungsentwurf nach Warenausgang
  • credit_limit_exceeded -> lock_order: Kreditsperre und Benachrichtigung an Finance
🛡️ Nebenprozesse & Resilienz
  • Bonitäts- und Kreditlimitprüfung mit Ausnahmegenehmigung durch den CFO
  • Stornierung von Aufträgen mit automatischer Freigabe gebundener Bestände
  • Rückstandsbearbeitung und Lieferterminanpassung bei Lieferantenverzögerung
  • Zollprüfung und Sanktionslistenabgleich bei Exportkunden in Drittländer
💡 No-Code Checkliste & Praxistipps
  • Kreditlimits und Zahlungsziele kundenindividuell im Debitorenstamm hinterlegen
  • Lieferzeit-Puffer für die CTP-Terminierung im System definieren
  • Sperrgründe für Aufträge (z.B. ungeklärte Technik, Kreditsperre) parametrieren
  • No-Code Zusatzfelder für Kundenbestellnummer und Frachtführerhinweise anlegen

🗄️ Data Models & Fields

DropshipLines dropship_lines RLS Aktiv
37 Fields / Columns

Tabelle dropship_lines

Feldname Data Type Required Schlüssel Functional Meaning
item_type VARCHAR(24) Ja * - Feld item_type
item_id UUID Ja * - Feld item_id
quote_id UUID Nein FK ➔ quotes.id Feld quote_id
work_order_id UUID Nein FK ➔ work_orders.id Feld work_order_id
project_id UUID Nein FK ➔ projects.id Feld project_id
customer_id UUID Nein FK ➔ customers.id Feld customer_id
product_id UUID Nein FK ➔ products.id Feld product_id
description VARCHAR(255) Ja * - Feld description
quantity NUMERIC(14, 4) Ja * - Feld quantity
unit VARCHAR(16) Ja * - Feld unit
sales_net NUMERIC(14, 2) Ja * - Feld sales_net
supplier_id UUID Nein FK ➔ suppliers.id Feld supplier_id
purchase_id UUID Nein FK ➔ purchases.id Feld purchase_id
purchase_item_id UUID Nein FK ➔ purchase_items.id Feld purchase_item_id
cost_net NUMERIC(14, 2) Nein - Feld cost_net
ship_to TEXT Nein - Feld ship_to
status VARCHAR(16) Ja * - Feld status
carrier VARCHAR(120) Nein - Feld carrier
tracking_number VARCHAR(120) Nein - Feld tracking_number
tracking_url VARCHAR(512) Nein - Feld tracking_url
expected_delivery_date DATE Nein - Feld expected_delivery_date
shipped_at DATETIME Nein - Feld shipped_at
delivered_at DATETIME Nein - Feld delivered_at
proof_document_id UUID Nein FK ➔ documents.id Feld proof_document_id
billing_released BOOLEAN Ja * - Feld billing_released
release_reason VARCHAR(255) Nein - Feld release_reason
chain_review BOOLEAN Ja * - Feld chain_review
issue_note VARCHAR(500) Nein - Feld issue_note
id UUID Nein PK Feld id
tenant_id UUID Ja * FK ➔ organizations.id Feld tenant_id
created_at DATETIME Ja * - Feld created_at
updated_at DATETIME Ja * - Feld updated_at
created_by UUID Nein - Feld created_by
updated_by UUID Nein - Feld updated_by
source_type VARCHAR(32) Nein - Feld source_type
source_id UUID Nein - Feld source_id
metadata JSONB Ja * - Feld metadata
SalesAgents sales_agents RLS Aktiv
18 Fields / Columns

Tabelle sales_agents

Feldname Data Type Required Schlüssel Functional Meaning
name VARCHAR(255) Ja * - Feld name
email VARCHAR(320) Nein - Feld email
phone VARCHAR(64) Nein - Feld phone
customer_id UUID Nein FK ➔ customers.id Feld customer_id
supplier_id UUID Nein FK ➔ suppliers.id Feld supplier_id
default_commission_percent NUMERIC(5, 2) Nein - Feld default_commission_percent
default_markup_percent NUMERIC(5, 2) Nein - Feld default_markup_percent
notes TEXT Nein - Feld notes
active BOOLEAN Ja * - Feld active
id UUID Nein PK Feld id
tenant_id UUID Ja * FK ➔ organizations.id Feld tenant_id
created_at DATETIME Ja * - Feld created_at
updated_at DATETIME Ja * - Feld updated_at
created_by UUID Nein - Feld created_by
updated_by UUID Nein - Feld updated_by
source_type VARCHAR(32) Nein - Feld source_type
source_id UUID Nein - Feld source_id
metadata JSONB Ja * - Feld metadata

🔌 Entry Points (UI & APIs)

Art Method Endpoint / Path Titel & Zweck Required Role
⚡ REST API DELETE /api/v1/sales/orders/{order_id}/items/{item_id}
delete_item
Semantic binding: operator_surface; mutation=True
sales
⚡ REST API GET /api/v1/sales/orders
list_sales_orders
Semantic binding: inventory_only; mutation=False
sales
⚡ REST API GET /api/v1/sales/orders/{order_id}
get_sales_order
Semantic binding: inventory_only; mutation=False
sales
⚡ REST API GET /api/v1/sales/summary
sales_summary
Semantic binding: inventory_only; mutation=False
sales
⚡ REST API GET /portal/{slug}/bestellung
order_form
Semantic binding: inventory_only; mutation=False
sales
⚡ REST API GET /verkauf
sales_page
Semantic binding: inventory_only; mutation=False
sales
⚡ REST API GET /verkauf/{order_id}
sales_order_page
Semantic binding: inventory_only; mutation=False
sales
⚡ REST API PATCH /api/v1/sales/orders/{order_id}
update_sales_order
Semantic binding: operator_surface; mutation=True
sales
⚡ REST API PATCH /api/v1/sales/orders/{order_id}/items/{item_id}
update_item
Semantic binding: operator_surface; mutation=True
sales
⚡ REST API POST /api/v1/sales/orders
create_sales_order
Semantic binding: operator_surface; mutation=True
sales
⚡ REST API POST /api/v1/sales/orders/from-quote/{quote_id}
create_from_quote
Semantic binding: operator_surface; mutation=True
sales
⚡ REST API POST /api/v1/sales/orders/{order_id}/cancel
cancel_sales_order
Semantic binding: operator_surface; mutation=True
sales
⚡ REST API POST /api/v1/sales/orders/{order_id}/confirm
confirm_sales_order
Semantic binding: operator_surface; mutation=True
sales
⚡ REST API POST /api/v1/sales/orders/{order_id}/invoice
invoice_sales_order
Semantic binding: operator_surface; mutation=True
sales
⚡ REST API POST /api/v1/sales/orders/{order_id}/items
add_item
Semantic binding: operator_surface; mutation=True
sales
⚡ REST API POST /api/v1/sales/orders/{order_id}/mark-delivered
mark_delivered
Semantic binding: operator_surface; mutation=True
sales
⚡ REST API POST /api/v1/sales/orders/{order_id}/start-delivery
start_delivery
Semantic binding: operator_surface; mutation=True
sales
⚡ REST API POST /portal/{slug}/bestellung
order_submit
Semantic binding: operator_surface; mutation=True
sales
🖥️ WEB-UI GET /quotes?status=dropship
Strecken-Filter Angebote
Filtert Angebote mit Streckengeschäft-Positionen
quotes:read
🖥️ WEB-UI GET /purchasing#dropship
Streckengeschäft Einkauf
Dedizierter Einkaufs-Reiter mit Kennzahlen und Tracking
purchasing:read
⚡ REST API GET /api/v1/dropshipping
Streckenpositionen API
Liefert Streckengeschäft-Positionen mit Lieferanten- und Belegdaten
quotes:read
⚡ REST API POST /api/v1/dropshipping/{id}/assign-supplier
Lieferant zuweisen
Weist Lieferant zu und erzeugt Einkaufsbestellung
purchasing:write
⚡ REST API POST /api/v1/dropshipping/{id}/tracking
Tracking hinterlegen
Trägt Trackingnummer ein und setzt Status auf in_transit
purchasing:write
⚡ REST API POST /api/v1/dropshipping/{id}/delivered
Zustellung bestätigen
Setzt Status auf delivered und erteilt Rechnungsfreigabe
purchasing:write

🛡️ Regulatory & Compliance

Dieses Modul unterliegt folgenden gesetzlichen, regulatorischen und Revisionsstandards:

  • UStG §25b (Innergemeinschaftliche Dreiecksgeschäfte)
  • GoBD (Fakturierung erst nach Leistungserbringung)
Related Modules:
➔ finance ➔ purchasing ➔ catalog ➔ customers ➔ suppliers