Kassensystem (POS)
pos
sales_billing
🛡️ RLS Protected
Kassensystem (POS) — aus Code abgeleitete Prozess- und API-Dokumentation.
⚡ Workflows & Lifecycles
Kassenverkauf mit TSE-Signatur & Z-Bon Tagesabschluss
pos_cash_desk_checkout
Bar- und Kartenzahlung am Point of Sale mit gesetzlicher KassenSichV-TSE-Signierung, Bon-Druck und automatischem Kassenabschluss.
⚙️ 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 |
Kassenzählung
capability:pos.cash.draw_count
Op:
pos.cash.draw_count
|
Objekt:
cash_drawer
Quelle:
code:capability_registry
|
⚙️ Engine |
✓ Auto
Risiko:
business_record
|
|
Kassenverkauf buchen
capability:pos.checkout
Op:
pos.checkout
|
Intent:
record_pos_sale
Quelle:
code:capability_registry
|
⚙️ Engine |
🔒 Freigabe nötig
Risiko:
external_effect
|
|
Pos: checkout sale
capability:pos.pos.checkout_sale
Op:
pos.pos.checkout_sale
|
Objekt:
pos
Quelle:
code:capability_registry
|
⚙️ Engine |
✓ Auto
Risiko:
business_record
|
|
Pos: close register
capability:pos.pos.close_register
Op:
pos.pos.close_register
|
Objekt:
pos
Quelle:
code:capability_registry
|
⚙️ Engine |
✓ Auto
Risiko:
business_record
|
|
Pos: create register
capability:pos.pos.create_register
Op:
pos.pos.create_register
|
Objekt:
pos
Quelle:
code:capability_registry
|
⚙️ Engine |
✓ Auto
Risiko:
business_record
|
|
Pos: resume held sale
capability:pos.pos.resume_held_sale
Op:
pos.pos.resume_held_sale
|
Objekt:
pos
Quelle:
code:capability_registry
|
⚙️ Engine |
✓ Auto
Risiko:
business_record
|
|
Bon per Mail
capability:pos.receipt.email
Op:
pos.receipt.email
|
Objekt:
pos_sale
Quelle:
code:capability_registry
|
⚙️ Engine |
✓ Auto
Risiko:
business_record
|
|
POS stornieren
capability:pos.sale.void
Op:
pos.sale.void
|
Objekt:
pos_sale
Quelle:
code:capability_registry
|
⚙️ Engine |
✓ Auto
Risiko:
business_record
|
|
Kasse schließen
capability:pos.session.close
Op:
pos.session.close
|
Intent:
close_pos_session
Quelle:
code:capability_registry
|
⚙️ Engine |
✓ Auto
Risiko:
business_record
|
|
Kasse öffnen
capability:pos.session.open
Op:
pos.session.open
|
Intent:
open_pos_session
Quelle:
code:capability_registry
|
⚙️ Engine |
✓ Auto
Risiko:
business_record
|
|
Kasse schließen
capability:pos.shift.close
Op:
pos.shift.close
|
Objekt:
pos_register
Quelle:
code:capability_registry
|
⚙️ Engine |
✓ Auto
Risiko:
business_record
|
|
🧠 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 pos
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.
Im Prüfkatalog ist keine modulspezifische Anforderung und keine primäre Prüfreferenz hinterlegt.
Im Auditauftrag zusätzlich genannt und nicht im Prüfkatalog v2026.10.1: KassenSichV, DSFinV-K, 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
🔌 Entry Points (UI & APIs)
| Art | Method | Endpoint / Path | Titel & Zweck | Required Role |
|---|---|---|---|---|
| ⚡ REST API | DELETE | /api/v1/pos/held-sales/{held_sale_id} |
discard_held_sale
Semantic binding: operator_surface; mutation=True
|
pos
|
| ⚡ REST API | GET | /api/v1/pos/products/search |
search_products
Semantic binding: inventory_only; mutation=False
|
pos
|
| ⚡ REST API | GET | /api/v1/pos/registers |
list_registers
Semantic binding: inventory_only; mutation=False
|
pos
|
| ⚡ REST API | GET | /api/v1/pos/registers/{register_id} |
get_register
Semantic binding: inventory_only; mutation=False
|
pos
|
| ⚡ REST API | GET | /api/v1/pos/registers/{register_id}/held-sales |
list_held_sales
Semantic binding: inventory_only; mutation=False
|
pos
|
| ⚡ REST API | GET | /api/v1/pos/transactions/{transaction_id} |
get_transaction
Semantic binding: inventory_only; mutation=False
|
pos
|
| ⚡ REST API | GET | /pos |
pos_terminal_page
Semantic binding: inventory_only; mutation=False
|
pos
|
| ⚡ REST API | POST | /api/v1/pos/held-sales/{held_sale_id}/resume |
resume_held_sale
Semantic binding: operator_surface; mutation=True
|
pos
|
| ⚡ REST API | POST | /api/v1/pos/registers |
create_register
Semantic binding: operator_surface; mutation=True
|
pos
|
| ⚡ REST API | POST | /api/v1/pos/registers/{register_id}/cash-movement |
cash_movement
Semantic binding: operator_surface; mutation=True
|
pos
|
| ⚡ REST API | POST | /api/v1/pos/registers/{register_id}/checkout |
checkout
Semantic binding: operator_surface; mutation=True
|
pos
|
| ⚡ REST API | POST | /api/v1/pos/registers/{register_id}/close |
close_register
Semantic binding: operator_surface; mutation=True
|
pos
|
| ⚡ REST API | POST | /api/v1/pos/registers/{register_id}/daily-closing |
daily_closing
Semantic binding: operator_surface; mutation=True
|
pos
|
| ⚡ REST API | POST | /api/v1/pos/registers/{register_id}/held-sales |
hold_sale
Semantic binding: operator_surface; mutation=True
|
pos
|
| ⚡ REST API | POST | /api/v1/pos/registers/{register_id}/open |
open_register
Semantic binding: operator_surface; mutation=True
|
pos
|
🛡️ Regulatory & Compliance
Dieses Modul unterliegt folgenden gesetzlichen, regulatorischen und Revisionsstandards:
- GoBD Nachvollziehbarkeit
- Mandanten-Isolation (PostgreSQL RLS)