Centurio System & Module Documentation
🏛️ Platform Architecture 🔑 Login
All Modules / sales_billing / Kassensystem (POS)
📘

Kassensystem (POS)

pos sales_billing 🛡️ RLS Protected

Kassensystem (POS) — aus Code abgeleitete Prozess- und API-Dokumentation.

Fachliche Bestimmung: Verkauf & Kundenaufträge steuert die verbindliche vertragliche Auftragsabwicklung: Erfassung und Bestätigung von Kundenaufträgen über Omnichannel-Schnittstellen (B2B, Shop, EDI, POS), strikte Kreditlimit- und Bonitätsprüfung, Lieferterminierung nach CTP (Capable-to-Promise), automatische Verzweigung in Fertigungs- (MTO), Lager- (MTS) oder Streckenkaskaden (Dropshipping) und die lückenlose Übergabe an Fakturierung und Logistik.

⚡ 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.

sequenceDiagram autonumber actor Customer as Ladenkunde actor Cashier as Kassenkraft participant POS as Kassenterminal (POS) participant TSE as Technische Sicherheitseinrichtung (TSE) participant CardTerminal as EC-/Kreditkartenterminal participant ERPFinance as ERP-Kassenbuch & Bestände Cashier->>POS: Artikel scannen & Barcode erfassen Customer->>Cashier: Kartenzahlung wählen POS->>CardTerminal: Betrag an Terminal übergeben (ZVT) CardTerminal-->>POS: Zahlung autorisiert (Transaktionsbeleg) POS->>TSE: Start/Finish Transaction (KassenSichV) TSE-->>POS: Signaturzähler, Zeitstempel, Prüfwert POS->>ERPFinance: Kassenbuchung & Lagerbestandsabbuchung POS-->>Customer: Kassenbon mit TSE-QR-Code
1. CART_SCAN
Warenkorb scannen
Barcodescanner erfasst Artikel; Preise, Rabatte und MwSt-Sätze werden instantan kalkuliert.
Aktionen: Barcode matchen, Bestand live prüfen
2. PAYMENT_SELECT
Zahlungsart wählen
Auswahl Barzahlung (mit Wechselgeldberechnung) oder Kartenzahlung via Terminal (ZVT/OPI).
Aktionen: Wechselgeld berechnen, Kartenterminal triggern
3. TSE_SIGNATURE
TSE-Kassensicherung
Übermittlung der Transaktionsdaten an die zertifizierte Technische Sicherheitseinrichtung (KassenSichV).
Aktionen: TSE-Signatur anfordern, Prüfcode einbetten
4. RECEIPT_PRINT
Kassenbeleg & Z-Bon
Ausgabe des Kassenbons mit QR-Code/TSE-Signatur und Fortschreibung des Kassenbuchs (Z-Bon).
Aktionen: Bon ausdrucken, Kassenbuch fortschreiben

⚙️ Fachprozesse & Capabilities (System-Fachlogik)

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

Gesamt: 12 manual_entry: 1 engine: 11
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
  • pos.cash.draw_count
Kassenverkauf buchen capability:pos.checkout
Op: pos.checkout
Intent: record_pos_sale
Quelle: code:capability_registry
⚙️ Engine
🔒 Freigabe nötig Risiko: external_effect
  • pos_transaction.recorded
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.checkout_sale
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.close_register
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.create_register
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
  • pos.resume_held_sale
Bon per Mail capability:pos.receipt.email
Op: pos.receipt.email
Objekt: pos_sale
Quelle: code:capability_registry
⚙️ Engine
✓ Auto Risiko: business_record
  • pos.receipt.email
POS stornieren capability:pos.sale.void
Op: pos.sale.void
Objekt: pos_sale
Quelle: code:capability_registry
⚙️ Engine
✓ Auto Risiko: business_record
  • pos.sale.void
Kasse schließen capability:pos.session.close
Op: pos.session.close
Intent: close_pos_session
Quelle: code:capability_registry
⚙️ Engine
✓ Auto Risiko: business_record
  • pos_register.closed
Kasse öffnen capability:pos.session.open
Op: pos.session.open
Intent: open_pos_session
Quelle: code:capability_registry
⚙️ Engine
✓ Auto Risiko: business_record
  • pos_register.opened
Kasse schließen capability:pos.shift.close
Op: pos.shift.close
Objekt: pos_register
Quelle: code:capability_registry
⚙️ Engine
✓ Auto Risiko: business_record
  • pos_register.closed

🧠 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 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:

  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

PosDailyClosings pos_daily_closings RLS Aktiv
25 Fields / Columns

Tabelle pos_daily_closings

Feldname Data Type Required Schlüssel Functional Meaning
register_id UUID Ja * FK ➔ pos_registers.id Feld register_id
closing_number INTEGER Ja * - Feld closing_number
closing_date DATE Ja * - Feld closing_date
opening_balance NUMERIC(14, 2) Ja * - Feld opening_balance
total_sales_gross NUMERIC(14, 2) Ja * - Feld total_sales_gross
total_sales_net NUMERIC(14, 2) Ja * - Feld total_sales_net
total_tax_19 NUMERIC(14, 2) Ja * - Feld total_tax_19
total_tax_7 NUMERIC(14, 2) Ja * - Feld total_tax_7
total_cash_payments NUMERIC(14, 2) Ja * - Feld total_cash_payments
total_card_payments NUMERIC(14, 2) Ja * - Feld total_card_payments
total_deposits NUMERIC(14, 2) Ja * - Feld total_deposits
total_withdrawals NUMERIC(14, 2) Ja * - Feld total_withdrawals
calculated_cash_balance NUMERIC(14, 2) Ja * - Feld calculated_cash_balance
actual_cash_counted NUMERIC(14, 2) Ja * - Feld actual_cash_counted
cash_difference NUMERIC(14, 2) Ja * - Feld cash_difference
is_exported_to_accounting BOOLEAN Ja * - Feld is_exported_to_accounting
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
PosHeldSales pos_held_sales RLS Aktiv
12 Fields / Columns

Tabelle pos_held_sales

Feldname Data Type Required Schlüssel Functional Meaning
register_id UUID Ja * FK ➔ pos_registers.id Feld register_id
label VARCHAR(120) Nein - Feld label
cart_snapshot JSONB Ja * - Feld cart_snapshot
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
PosRegisters pos_registers RLS Aktiv
17 Fields / Columns

Tabelle pos_registers

Feldname Data Type Required Schlüssel Functional Meaning
register_number VARCHAR(32) Ja * - Feld register_number
name VARCHAR(128) Ja * - Feld name
status VARCHAR(48) Ja * - Feld status
warehouse_id UUID Nein FK ➔ locations.id Feld warehouse_id
tse_client_id VARCHAR(128) Nein - Feld tse_client_id
tse_serial_number VARCHAR(128) Nein - Feld tse_serial_number
tse_provider VARCHAR(64) Ja * - Feld tse_provider
current_cash_balance NUMERIC(14, 2) Ja * - Feld current_cash_balance
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
PosTransactionItems pos_transaction_items RLS Aktiv
17 Fields / Columns

Tabelle pos_transaction_items

Feldname Data Type Required Schlüssel Functional Meaning
transaction_id UUID Ja * FK ➔ pos_transactions.id Feld transaction_id
product_id UUID Nein FK ➔ products.id Feld product_id
position INTEGER Ja * - Feld position
item_name VARCHAR(255) Ja * - Feld item_name
quantity NUMERIC(12, 3) Ja * - Feld quantity
unit_price NUMERIC(14, 2) Ja * - Feld unit_price
net_amount NUMERIC(14, 2) Ja * - Feld net_amount
tax_rate NUMERIC(5, 2) Ja * - Feld tax_rate
tax_amount NUMERIC(14, 2) Ja * - Feld tax_amount
gross_amount NUMERIC(14, 2) Ja * - Feld gross_amount
discount_percent NUMERIC(5, 2) Ja * - Feld discount_percent
discount_amount NUMERIC(14, 2) Ja * - Feld discount_amount
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
metadata JSONB Ja * - Feld metadata
PosTransactions pos_transactions RLS Aktiv
32 Fields / Columns

Tabelle pos_transactions

Feldname Data Type Required Schlüssel Functional Meaning
register_id UUID Ja * FK ➔ pos_registers.id Feld register_id
customer_id UUID Nein FK ➔ customers.id Feld customer_id
invoice_id UUID Nein FK ➔ invoices.id Feld invoice_id
transaction_number VARCHAR(64) Ja * - Feld transaction_number
receipt_number VARCHAR(64) Ja * - Feld receipt_number
transaction_type VARCHAR(48) Ja * - Feld transaction_type
gross_amount NUMERIC(14, 2) Ja * - Feld gross_amount
net_amount NUMERIC(14, 2) Ja * - Feld net_amount
tax_amount NUMERIC(14, 2) Ja * - Feld tax_amount
payment_method VARCHAR(48) Ja * - Feld payment_method
given_amount NUMERIC(14, 2) Nein - Feld given_amount
change_amount NUMERIC(14, 2) Nein - Feld change_amount
discount_amount NUMERIC(14, 2) Ja * - Feld discount_amount
secondary_payment_method VARCHAR(48) Nein - Feld secondary_payment_method
secondary_payment_amount NUMERIC(14, 2) Nein - Feld secondary_payment_amount
tse_transaction_number BIGINT Nein - Feld tse_transaction_number
tse_signature_counter BIGINT Nein - Feld tse_signature_counter
tse_signature_value TEXT Nein - Feld tse_signature_value
tse_algorithm VARCHAR(32) Nein - Feld tse_algorithm
tse_public_key TEXT Nein - Feld tse_public_key
tse_started_at DATETIME Nein - Feld tse_started_at
tse_finished_at DATETIME Nein - Feld tse_finished_at
tse_qr_code_payload TEXT Nein - Feld tse_qr_code_payload
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/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)