E-Commerce & Marktplätze
ecommerce
sales_billing
🛡️ RLS Protected
E-Commerce & Marktplätze — aus Code abgeleitete Prozess- und API-Dokumentation.
⚡ Workflows & Lifecycles
E-Commerce Bestellimport & Bestandsabgleich
shop_order_synchronization
Vollautomatischer Import externer Shop-Bestellungen (Shopify, WooCommerce), Zahlungsverifikation und Bestandsreservierung.
⚙️ 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 billing_general_agent
agent_entry:billing_general_agent
|
Agent-Einstieg billing_general_agent
Quelle:
code:module_agent_map
|
manual_entry |
✓ Auto
|
Keine Seiteneffekte deklariert |
E-Commerce-Bestellung übernehmen
capability:ingest_ecommerce_order
Op:
ingest_ecommerce_order
|
Intent:
ingest_ecommerce_order
Quelle:
code:capability_registry
|
⚙️ Engine |
✓ Auto
Risiko:
business_record
|
|
E-Commerce-Bestellung übernehmen
gateway:ecommerce_order_ingest
Op:
ingest_ecommerce_order
|
E-Commerce-Bestellung übernehmen
Quelle:
code:reviewed_gateway
|
⚙️ Engine |
✓ 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 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.
- Sofortfaktura nach Lieferung: Der bestätigte Lieferschein stößt unmittelbar die Ausgangsrechnung im Rechnungsmodul an (
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
- Keine Auslieferung ohne bestätigten Auftrag oder autorisierte Freigabe.
- Keine Auftragsfreigabe bei Kreditlimitüberschreitung ohne Autorisierung durch Finance.
- Ein bestätigter Auftrag darf nachträglich nicht stillschweigend editiert werden; Änderungen erfordern Auftragsänderungsbelege.
- Fakturierte Positionen sind für Preisänderungen gesperrt.
Normbezug für ecommerce
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:
wcag-2.2, Web Content Accessibility Guidelines (WCAG) 2.2, Ausgabe W3C Recommendation 2023-10-05. Art: normative. Öffentlicher Text. Die Nennung ist keine Klauselprüfung. Keine modulspezifische Kataloganforderung. Die Zuordnung bleibt eine Prüfreferenz.
Im Auditauftrag zusätzlich genannt und nicht im Prüfkatalog v2026.10.1: GS1, PCI DSS. Dafür gibt es hier keine Klausel und keine Aussage, dass eine Vorgabe eingehalten wird.
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:
- Validierung: Prüft Kreditstatus, steuerliche Plausibilität (z.B. USt-IdNr. bei innergemeinschaftlicher EU-Lieferung) und Vollständigkeit der Lieferadresse.
- Kaskadierung: Erzeugt transaktional die Reservierungen in
inventoryoder ruftcap:assembly.create_order_from_order_lineauf. - Statuswechsel:
SalesOrder.status = 'processing'. - 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)
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
SalesOrdermit Statusconfirmed. - Action-Node 2: Führe
cap:sales.sales_order.reserve_stockaus. - 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
- Angenommenes Angebot aus dem Quotes-Modul
- E-Commerce-Bestellung über Shop-Konnektoren (Shopify, WooCommerce)
- Manuelle Auftragserfassung durch den Vertriebsinnendienst
- Elektronischer Datenaustausch (EDI / EDIFACT ORDERS)
- 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
- 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
- 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
- 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
Keine dedizierten Tabellen für dieses Modul registriert.
🔌 Entry Points (UI & APIs)
| Art | Method | Endpoint / Path | Titel & Zweck | Required Role |
|---|---|---|---|---|
| ⚡ REST API | GET | /api/v1/ecommerce/channels |
list_channels
Semantic binding: inventory_only; mutation=False
|
ecommerce
|
| ⚡ REST API | GET | /api/v1/ecommerce/webhooks/channels/{channel_id} |
receive_channel_webhook_challenge
Semantic binding: inventory_only; mutation=False
|
ecommerce
|
| ⚡ REST API | GET | /ecommerce |
ecommerce_page
Semantic binding: inventory_only; mutation=False
|
ecommerce
|
| ⚡ REST API | GET | /ecommerce/channels/{channel_id}/preview-order |
preview_order_page
Semantic binding: inventory_only; mutation=False
|
ecommerce
|
| ⚡ REST API | GET | /ecommerce/channels/{channel_id}/settings |
channel_settings_page
Semantic binding: inventory_only; mutation=False
|
ecommerce
|
| ⚡ REST API | POST | /api/v1/ecommerce/channels |
create_channel
Semantic binding: operator_surface; mutation=True
|
ecommerce
|
| ⚡ REST API | POST | /api/v1/ecommerce/webhooks/channels/{channel_id} |
receive_signed_channel_webhook
Semantic binding: operator_surface; mutation=True
|
ecommerce
|
| ⚡ REST API | POST | /api/v1/ecommerce/webhooks/{channel_slug} |
receive_order_webhook
Semantic binding: operator_surface; mutation=True
|
ecommerce
|
| ⚡ REST API | POST | /ecommerce/channels |
create_channel
Semantic binding: operator_surface; mutation=True
|
ecommerce
|
| ⚡ REST API | POST | /ecommerce/channels/{channel_id}/delete |
delete_channel
Semantic binding: operator_surface; mutation=True
|
ecommerce
|
| ⚡ REST API | POST | /ecommerce/channels/{channel_id}/poll-orders |
poll_channel_orders
Semantic binding: operator_surface; mutation=True
|
ecommerce
|
| ⚡ REST API | POST | /ecommerce/channels/{channel_id}/preview-order |
preview_order_submission
Semantic binding: operator_surface; mutation=True
|
ecommerce
|
| ⚡ REST API | POST | /ecommerce/channels/{channel_id}/settings |
update_channel_settings
Semantic binding: operator_surface; mutation=True
|
ecommerce
|
| ⚡ REST API | POST | /ecommerce/channels/{channel_id}/simulate-order |
legacy_simulate_order
Semantic binding: operator_surface; mutation=True
|
ecommerce
|
| ⚡ REST API | POST | /ecommerce/channels/{channel_id}/toggle |
toggle_channel
Semantic binding: operator_surface; mutation=True
|
ecommerce
|
| ⚡ REST API | POST | /ecommerce/order-syncs/{sync_id}/push-fulfillment |
push_order_fulfillment
Semantic binding: operator_surface; mutation=True
|
ecommerce
|
🛡️ Regulatory & Compliance
Dieses Modul unterliegt folgenden gesetzlichen, regulatorischen und Revisionsstandards:
- GoBD Nachvollziehbarkeit
- Mandanten-Isolation (PostgreSQL RLS)