📘

Lieferantenstamm

suppliers supply_chain 🛡️ RLS Protected

Lieferantenstamm — aus Code abgeleitete Prozess- und API-Dokumentation.

Fachliche Bestimmung: Einkauf & Beschaffung steuert die unternehmensweite Material- und Dienstleistungsversorgung: Bedarfsbündelung aus MRP und Lager (BANF), Lieferantenanfragen (RFQ) mit Preisspiegelvergleich, mehrstufige Genehmigungswertgrenzen, verbindliche Bestellschreibung (PO), Liefertermin-Monitoring sowie den revisionssicheren 3-Wege-Abgleich (Bestellung ➔ Wareneingang ➔ Eingangsrechnung).

Fachprozess-Erzählung & KI-Architektur Workflows & Lifecycles (1) Fachprozesse & Capabilities (10) Data Models & Fields (3) Entry Points (UI & APIs) (7) Regulatory & Compliance

⚡ Workflows & Lifecycles

Benutzerbefehl: supplier crud subagent `plan:command_supplier_crud_subagent`

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

1. supplier_crud_subagent

supplier_crud_subagent

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

Aktionen: supplier_crud_subagent

⚙️ Fachprozesse & Capabilities (System-Fachlogik)

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

Gesamt: 10 manual_entry: 1 engine: 6 operator_surface: 2 durable_plan: 1

Capability & Schlüssel	Fachliche Bezeichnung	Ausführung / Coverage	Risikostufe & Freigabe	Effekte & Kaskaden
Agent-Einstieg supplier_crud_subagent `agent_entry:supplier_crud_subagent`	Agent-Einstieg supplier_crud_subagent Quelle: `code:module_agent_map`	manual_entry	✓ Auto	Keine Seiteneffekte deklariert
Lieferant anlegen `capability:supplier.create` Op: `supplier.create`	Intent: `create_supplier` Quelle: `code:capability_registry`	⚙️ Engine	✓ Auto Risiko: `business_record`	`supplier.created`
Lieferant onboarden `capability:supplier.onboard` Op: `supplier.onboard`	Objekt: `supplier` Quelle: `code:capability_registry`	⚙️ Engine	✓ Auto Risiko: `business_record`	`supplier.onboard`
Lieferant aktualisieren `capability:supplier.update` Op: `supplier.update`	Intent: `update_supplier` Quelle: `code:capability_registry`	⚙️ Engine	✓ Auto Risiko: `business_record`	`supplier.updated`
Supplier: create `capability:suppliers.supplier.create` Op: `suppliers.supplier.create`	Objekt: `supplier` Quelle: `code:capability_registry`	⚙️ Engine	✓ Auto Risiko: `business_record`	`supplier.create`
Supplier: delete `capability:suppliers.supplier.delete` Op: `suppliers.supplier.delete`	Objekt: `supplier` Quelle: `code:capability_registry`	⚙️ Engine	✓ Auto Risiko: `business_record`	`supplier.delete`
Supplier: update `capability:suppliers.supplier.update` Op: `suppliers.supplier.update`	Objekt: `supplier` Quelle: `code:capability_registry`	⚙️ Engine	✓ Auto Risiko: `business_record`	`supplier.update`
supplier: create form `form_surface_anchor:supplier.create`	Objekt: `supplier` Quelle: `code:erp_form_surface`	operator_surface	✓ Auto	Keine Seiteneffekte deklariert
supplier: edit form `form_surface_anchor:supplier.edit`	Objekt: `supplier` Quelle: `code:erp_form_surface`	operator_surface	✓ Auto	Keine Seiteneffekte deklariert
Benutzerbefehl: supplier crud subagent `plan:command_supplier_crud_subagent`	Benutzerbefehl: supplier crud subagent 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 Beschaffungsprozess in der betrieblichen Praxis

Ein exzellenter Einkauf sichert die Lieferfähigkeit des Gesamtunternehmens zu wettbewerbsfähigen Preisen und verhindert Kapitalbindung in Überbeständen. Centurio ERP bildet den kompletten Procure-to-Pay-Zyklus ab.

1. Bedarfsentstehung & Bedarfsanforderung (Purchase Requisition / BANF)

Bedarfe entstehen an verschiedenen Stellen der Organisation:

Materialbedarfsplanung MRP (assembly): Die Stücklistenauflösung offener Fertigungsaufträge detektiert Fehlteile bei Zukaufkomponenten und generiert automatisch eine Bedarfsanforderung (cap:purchasing.purchase_request.create_from_mrp).
Meldebestandsunterschreitung (inventory): Fällt der Vorrat im Rohstoff- oder Handelswarenlager unter den Meldebestand, stößt das LVS eine automatisierte Nachbestell-BANF an.
Manueller Fachbereichsbedarf: Mitarbeiter erfassen interne Bestellanforderungen (z.B. Werkzeuge, Büromaterial, IT-Geräte oder externe Dienstleistungen).

2. Lieferantenauswahl, Rahmenverträge & Preisanfrage (RFQ)

Liegt kein bestehender Rahmenvertrag vor, startet der Einkäufer den Preisvergleich:

Über cap:purchasing.rfq.create wird eine Angebotsanfrage (Request for Quotation - RFQ) an einen oder mehrere qualifizierte Lieferanten (suppliers) gerichtet.
Das System erfasst die eingehenden Lieferantenangebote und stellt Staffelpreise, Lieferzeiten, Skontokonditionen und Nebenkosten (Verpackung, Fracht) in einem übersichtlichen Preisspiegel gegenüber.
Lieferantenbewertungen (Qualitätsquote, Termintreue vergangener Lieferungen) fließen direkt in die Vergabeentscheidung ein.

3. Genehmigungsworkflow nach Wertgrenzen (Approval Gate)

Zur Einhaltung des Vier-Augen-Prinzips und Vermeidung von Fehlkäufen greift die Autorisierungs-Matrix:

Geringwertige Bestellungen (z.B. unter 1.000 €) werden vom Einkäufer direkt freigegeben.
Bei Überschreitung definierter Wertgrenzen wird der Bestell-Draft blockiert und erfordert gestaffelte Genehmigungen:
- 1.000 € bis 10.000 €: Freigabe durch den Einkaufsleiter.
- Über 10.000 €: Freigabe durch den Finanzvorstand (CFO).
Über die Capability cap:purchasing.purchase_order.approve erteilt der Vorgesetzte die digitale Signatur.

4. Verbindliche Bestellung (Purchase Order - PO) & Übermittlung

Nach Freigabe wandelt das System die Anforderung in eine offizielle Bestellung (cap:purchasing.purchase_order.create).
Der Beleg wird mit Bestellnummer, Lieferanschrift, gewünschtem Liefertermin und Preisen erzeugt und automatisiert per E-Mail, EDIFACT ORDERS oder Lieferantenportal übermittelt (cap:purchasing.purchase_order.send).
Bestellbestätigung (AB): Trifft die Bestätigung des Lieferanten ein, erfasst der Sachbearbeiter eventuelle Abweichungen (z.B. geänderter Liefertermin oder Teilmengen) direkt an der Bestellzeile.

5. Lieferterminüberwachung & Mahnwesen (Expediting)

Das System überwacht kontinuierlich zugesagte Liefertermine.
Droht ein Lieferverzug, erzeugt das Modul automatische Erinnerungen oder Liefermahnungen (cap:purchasing.purchase_order.send_reminder).
Bei kritischen Komponenten für die Fertigung wird der Produktionsdisponent über drohende Verzögerungen alarmiert, um den Produktionsplan anzupassen.

6. Wareneingang & Qualitätskontrolle (Goods Receipt)

Die Lieferung trifft am Wareneingang ein. Der Lagermitarbeiter identifiziert die Sendung anhand der Bestellnummer oder des Lieferscheins.
Über cap:inventory.goods_receipt.create wird die Ware vereinnahmt. Das System vergleicht bestellte Menge gegen gelieferte Menge.
Bei Mengendifferenzen bleibt die Bestellung teiloffen; bei Falschlieferung oder Qualitätsmängeln wird eine Reklamation ausgelöst (returns) und die Ware auf das Quarantänelager gebucht.

7. Der revisionssichere 3-Wege-Abgleich (3-Way Matching)

Trifft die Lieferantenrechnung ein, verhindert Centurio ERP Überzahlungen und Fehlbuchungen:

Der 3-Wege-Abgleich vergleicht automatisch:
1. Den genehmigten Preis und die Menge der Bestellung (PO).
2. Die tatsächlich quittierte Menge des Wareneingangsbelegs.
3. Die berechneten Preise und Mengen der Eingangsrechnung.
Liegen alle Werte innerhalb der Toleranz (z.B. Cent-Rundungsdifferenzen), wird die Rechnung automatisch zur Zahlung freigegeben (cap:invoices.incoming_invoice.approve_for_payment).
Treten Abweichungen auf (z.B. Rechnungspreis höher als bestellt), wird die Rechnung gesperrt und dem Einkäufer zur Klärung vorgelegt.

8. Abschluss & Kreditorenbuchung

Nach erfolgreichem 3-Wege-Abgleich übergibt das Einkaufsmodul den Vorgang an die Finanzbuchhaltung: Der Aufwand wird verbucht, die Verbindlichkeit im Kreditoren-OP angelegt und nach Zahlungsziel skontiert beglichen.

🏛️

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

Meta-Fachlogik: Die ideologische Blaupause & das normative Weltbild

Die Meta-Fachlogik des Einkaufs basiert auf dem SCOR-Modell (sS1 Source Stocked Product), betriebswirtschaftlichen Grundsätzen der Compliance und gesetzlichen Vorgaben zur Funktionstrennung.

1. Compliance, Funktionstrennung & Betrugsprävention

Segregation of Duties (Funktionstrennung):
- Niemand darf eine Bestellung anlegen, den Wareneingang quittieren und die Rechnung freigeben (Vermeidung von Scheinlieferungen und Veruntreuung).
- Das Soll-Modell erzwingt die strikte personelle Trennung zwischen Bestellauslösung, physischer Warenannahme und Rechnungsfreigabe.
Lieferanten-Compliance & LkSG (Lieferkettensorgfaltspflichtengesetz):
- Unternehmen müssen ihre Lieferanten hinsichtlich Umwelt- und Menschenrechtsstandards bewerten.
- Das Soll-Modell verlangt die Erfassung von Nachhaltigkeitsnachweisen (z.B. ISO 14001, CSR-Berichte) direkt am Lieferantenstamm.

2. Kaufmännische Prinzipien

TCO (Total Cost of Ownership): Die Beschaffungsentscheidung basiert nicht allein auf dem Stückpreis, sondern bezieht Frachtkosten, Verpackung, Zölle, Zahlungsziele und Qualitätskosten (Ausschussrisiko) mit ein.
Skonto-Optimierung: Zahlungsziele werden so ausgesteuert, dass Skontofristen (z.B. 2% Skonto innerhalb von 10 Tagen) durch schnelle Rechnungsdurchlaufzeiten voll ausgenutzt werden, da der Skontoertrag auf das Jahr hochgerechnet einer Spitzenrendite entspricht.

3. Invarianten des Soll-Modells

Keine Bestellung ohne dokumentierte Genehmigung ab Überschreitung der Wertgrenze.
Keine Rechnungsfreigabe ohne nachgewiesenen Wareneingang (außer bei expliziter Vorkasse).
Keine nachträgliche Erhöhung der Bestellpreise nach Übermittlung an den Lieferanten ohne Revisionsbeleg.
Jede Preis- oder Mengenabweichung im 3-Wege-Abgleich oberhalb der Toleranz erfordert eine begründete Freigabe.

Normbezug für `suppliers`

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:

iso-9001-2026, ISO 9001:2026 Quality management systems — Requirements, Ausgabe ISO 9001:2026 (6. Ausgabe, 2026-09-16). Art: normative. Volltext liegt nicht vor. Keine Klauselprüfung. Keine modulspezifische Kataloganforderung. Die Zuordnung bleibt eine Prüfreferenz.

Im Auditauftrag zusätzlich genannt und nicht im Prüfkatalog v2026.10.1: ISO 8000, ISO 20400. 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 konkrete Umsetzung im Modul purchasing.

1. Datenmodelle & Semantische Schicht (ORM)

PurchaseOrder: Bestellkopf (Felder: id, tenant_id, po_number, supplier_id, status, order_date, expected_delivery_date, total_net_amount, total_tax_amount, currency, payment_term_id, incoterms).
PurchaseOrderLine: Bestellzeilen (Felder: purchase_order_id, product_id, ordered_quantity, received_quantity, invoiced_quantity, unit_price, status).
PurchaseRequest: Interne Bedarfsanforderung (BANF) aus Werkstatt oder MRP.
PurchaseApproval: Autorisierungsnachweis mit Freigabestufe und Zeitstempel.

2. Das Capability-Register

cap:purchasing.purchase_request.create: Anlage einer Bedarfsanforderung.
cap:purchasing.purchase_request.create_from_mrp: Automatisches Bündeln von Fertigungsfehlteilen in BANFs.
cap:purchasing.purchase_order.create: Erzeugung einer Einkaufsbestellung aus einer BANF oder manuell.
cap:purchasing.purchase_order.approve: Wertgrenzen-Freigabe durch Einkaufsleiter oder Geschäftsführung.
cap:purchasing.purchase_order.send: Versand der Bestellung an den Lieferanten (PDF/EDI).
cap:purchasing.purchase_order.record_order_ack: Erfassung der Lieferanten-Auftragsbestätigung.
cap:purchasing.purchase_order.send_reminder: Generierung einer Liefermahnung bei Verzug.
cap:purchasing.purchase_order.match_three_way: Ausführung des automatischen 3-Wege-Abgleichs.

3. Der Gateway `gw:procure_to_pay_approval@v1`

Der Bestell-Gateway sichert die Verbindlichkeit ab:

Prüfung: Prüft Wertgrenzen gegen die Benutzerrolle und verifiziert, ob der Lieferant aktiv und nicht gesperrt ist.
Freigabe: Bei Überschreitung der Zeichnungsbefugnis wird eine Genehmigungsaufgabe erzeugt; andernfalls wird die Freigabe sofort erteilt.
Statuswechsel: PurchaseOrder.status = 'approved'.
Outbox-Signal: Feuert PURCHASE_ORDER_APPROVED.

4. Statusmodelle

draft (Entwurf) ➔ waiting_approval (Genehmigung erforderlich) ➔ approved (Freigegeben) ➔ sent (Bestellt) ➔ partially_received (Teilgeliefert) ➔ received (Vollständig geliefert) ➔ matched (3-Wege-Abgleich OK) ➔ 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

Anleitung für Solution Architects zur individuellen Einkaufskonfiguration.

1. Kundenanforderungsanalyse

Wie lautet die unternehmensspezifische Zeichnungsberechtigungs-Matrix (Wertgrenzen je Hierarchiestufe)?
Werden automatische Nachbestellungen ohne menschliche Freigabe für C-Artikel (z.B. Schrauben, Kartonagen) gewünscht?
Welche Toleranzgrenzen gelten für Preisabweichungen beim 3-Wege-Abgleich (z.B. max. 2 € oder max. 1%)?

2. No-Code Zusatzfelder (Custom Fields)

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

Auf PurchaseOrder:
- budget_center_code (Text): Zuordnung zum Kostenstellen-Budget.
- lksg_risk_acknowledged (Checkbox): Bestätigung der Einhaltung des Lieferkettengesetzes.
- customs_tariff_group (Text): Zollwarengruppe bei Importen aus Drittländern.
Auf PurchaseOrderLine:
- cost_allocation_project_id (Text): Weiterbelastung der Materialkosten an ein Kundenprojekt.
- supplier_packaging_unit (Dezimal): Gebindegröße des Lieferanten (z.B. VPE 50 Stk.).

3. No-Code Workflow Canvas DAGs

Blueprint A: Mehrstufige Einkaufs-Wertgrenzenfreigabe (PO Approval DAG)

Trigger-Node: PurchaseOrder wechselt auf waiting_approval.
Condition-Node 1: po.total_net_amount <= 2500.
- Action 1: Automatische Freigabe durch System oder Zuweisung an Teamleiter.
Condition-Node 2: po.total_net_amount > 2500 AND po.total_net_amount <= 25000.
- Action 2: Genehmigungsaufgabe an Einkaufsleiter.
Condition-Node 3: po.total_net_amount > 25000.
- Action 3: Genehmigungsaufgabe an Geschäftsführung (CFO).

Blueprint B: Automatisches Lieferanten-Mahnwesen (Supplier Expediting DAG)

Trigger-Node: Scheduled Cron (0 7 * * 1-5) – Täglicher Scan.
Condition-Node: po.status == 'sent' AND po.expected_delivery_date < current_date AND po.received_quantity < po.ordered_quantity.
Action-Node: Generiere Liefermahnung Stufe 1 per E-Mail an Lieferanten und setze Wiedervorlage auf +3 Tage.

📚 Operative Prozessbegriffe & Transaktionsschnittstellen

Zentrale Fachbegriffe im Prozesszusammenhang (Operatives Modell)

Bedarfsanforderung (BANF)

Interner Antrag zur Beschaffung von Materialien oder Fremddienstleistungen.

3-Wege-Abgleich (Three-Way Match)

Automatisierter Vergleich zwischen Bestellung, Wareneingang und Eingangsrechnung.

RFQ (Request for Quotation)

Ausschreibung oder Angebotsanfrage an Lieferanten zum Preis- und Konditionenvergleich.

Lieferantenbewertung

Objektive Messung von Termintreue, Mengentreue und Qualitätsquote vergangener Lieferungen.

Wertgrenzen-Matrix

Organisatorische Vorgabe von Zeichnungsbefugnissen je Mitarbeiter- und Führungsebene.

Liefermahnung (Expediting)

Schriftliche Aufforderung zur Erfüllung bei drohendem oder eingetretenem Lieferverzug.

Rahmenkontrakt

Langfristige Vereinbarung über Abnahmemengen und Festpreise mit periodischen Lieferabrufen.

📥 Eingänge & Trigger (Inputs)

Materialbedarfsanforderungen aus der MRP-Planung der Fertigung
LVS-Meldebestandsunterschreitungen aus dem Lager
Manuelle Bestellanforderungen von Kostenstellen und Fachbereichen
Ersatzteilbedarfe aus Wartungs- und Außendienstaufträgen

📤 Ausgänge & Arbeitsergebnisse (Outputs)

Verbindliche Einkaufsbestellungen (PDF/EDI) an Lieferanten
Lieferantenanfragen (RFQ) mit Vergleichs-Preisspiegeln
Wareneingangsavis für die Lagerlogistik
Rechnungsfreigaben nach 3-Wege-Abgleich für die Kreditorenbuchhaltung
Lieferantenbewertungs-Reports für das strategische Einkaufscontrolling

⚡ Kaskaden & Folgeprozesse (Cascades)

purchase_order_sent -> expect_goods_receipt: Bereitstellung des Avis im Lager
goods_receipt_confirmed -> trigger_invoice_matching: Prüfung wartender Eingangsrechnungen
matching_approved -> release_payment_order: Zahlungsfreigabe in der Buchhaltung
delivery_delayed -> alert_production_planner: Warnung bei Materialengpässen

🛡️ Nebenprozesse & Resilienz

Mängelrüge und Rücksendung bei schadhaftem Wareneingang
Klärung von Preisabweichungen zwischen Bestellung und Lieferantenrechnung
Verwaltung von Lieferanten-Rahmenverträgen und periodischen Abrufen
Zollabfertigung und Importabwicklung bei Beschaffung im Drittland

💡 No-Code Checkliste & Praxistipps

Wertgrenzen für Freigaben je Kostenstelle und Benutzerrolle festlegen
Lieferanten-Zahlungsbedingungen und Standard-Skontosätze pflegen
Toleranzgrenzen für Cent- und Prozentabweichungen beim 3-Wege-Abgleich einstellen
No-Code Zusatzfelder für Budgetcodes und Lieferkettengesetz auf PurchaseOrder anlegen

🗄️ Data Models & Fields

SupplierQuoteLines supplier_quote_lines RLS Aktiv

12 Fields / Columns

Tabelle supplier_quote_lines

Feldname	Data Type	Required	Schlüssel	Functional Meaning
`quote_id`	`UUID`	Ja *	FK ➔ supplier_quotes.id	Feld quote_id
`rfq_line_id`	`UUID`	Nein	FK ➔ purchase_rfq_lines.id	Feld rfq_line_id
`description`	`TEXT`	Ja *	-	Feld description
`quantity`	`NUMERIC(14, 4)`	Ja *	-	Feld quantity
`unit_price`	`NUMERIC(14, 2)`	Ja *	-	Feld unit_price
`tax_rate`	`NUMERIC(6, 4)`	Nein	-	Feld tax_rate
`lead_time_days`	`INTEGER`	Nein	-	Feld lead_time_days
`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

SupplierQuotes supplier_quotes RLS Aktiv

16 Fields / Columns

Tabelle supplier_quotes

Feldname	Data Type	Required	Schlüssel	Functional Meaning
`rfq_id`	`UUID`	Ja *	FK ➔ purchase_rfqs.id	Feld rfq_id
`supplier_id`	`UUID`	Ja *	FK ➔ suppliers.id	Feld supplier_id
`status`	`VARCHAR(48)`	Ja *	-	Feld status
`quote_number_external`	`VARCHAR(128)`	Nein	-	Feld quote_number_external
`currency`	`VARCHAR(3)`	Ja *	-	Feld currency
`valid_until`	`DATE`	Nein	-	Feld valid_until
`notes`	`TEXT`	Nein	-	Feld notes
`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

Suppliers suppliers RLS Aktiv

35 Fields / Columns

Tabelle suppliers

Feldname	Data Type	Required	Schlüssel	Functional Meaning
`name`	`VARCHAR(255)`	Ja *	-	Feld name
`supplier_number`	`VARCHAR(64)`	Nein	-	Feld supplier_number
`normalized_name`	`VARCHAR(255)`	Ja *	-	Feld normalized_name
`vat_id`	`VARCHAR(32)`	Nein	-	Feld vat_id
`tax_id`	`VARCHAR(32)`	Nein	-	Feld tax_id
`iban`	`VARCHAR(34)`	Nein	-	Feld iban
`email`	`VARCHAR(320)`	Nein	-	Feld email
`phone`	`VARCHAR(64)`	Nein	-	Feld phone
`website`	`VARCHAR(255)`	Nein	-	Feld website
`street`	`VARCHAR(255)`	Nein	-	Feld street
`postal_code`	`VARCHAR(16)`	Nein	-	Feld postal_code
`city`	`VARCHAR(128)`	Nein	-	Feld city
`country_code`	`VARCHAR(2)`	Nein	-	Feld country_code
`latitude`	`NUMERIC(9, 6)`	Nein	-	Feld latitude
`longitude`	`NUMERIC(9, 6)`	Nein	-	Feld longitude
`default_expense_category`	`VARCHAR(64)`	Nein	-	Feld default_expense_category
`payable_account_code`	`VARCHAR(32)`	Nein	-	Feld payable_account_code
`peppol_endpoint_id`	`VARCHAR(64)`	Nein	-	Feld peppol_endpoint_id
`peppol_endpoint_scheme`	`VARCHAR(16)`	Nein	-	Feld peppol_endpoint_scheme
`external_reference`	`VARCHAR(128)`	Nein	-	Feld external_reference
`adr_certified`	`BOOLEAN`	Ja *	-	Feld adr_certified
`purchase_grouping_mode`	`VARCHAR(32)`	Ja *	-	Feld purchase_grouping_mode
`status`	`VARCHAR(48)`	Ja *	-	Feld status
`detection_confidence`	`NUMERIC(4, 3)`	Nein	-	Feld detection_confidence
`notes`	`TEXT`	Nein	-	Feld notes
`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
`deleted_at`	`DATETIME`	Nein	-	Feld deleted_at

🔌 Entry Points (UI & APIs)

Art	Method	Endpoint / Path	Titel & Zweck	Required Role
⚡ REST API	DELETE	`/api/v1/suppliers/{supplier_id}`	delete_supplier Semantic binding: operator_surface; mutation=True	`suppliers`
⚡ REST API	GET	`/api/v1/suppliers`	list_suppliers Semantic binding: inventory_only; mutation=False	`suppliers`
⚡ REST API	GET	`/api/v1/suppliers/matches`	match_suppliers Semantic binding: inventory_only; mutation=False	`suppliers`
⚡ REST API	GET	`/api/v1/suppliers/{supplier_id}`	get_supplier Semantic binding: inventory_only; mutation=False	`suppliers`
⚡ REST API	GET	`/suppliers/{supplier_id}`	supplier_detail_page Semantic binding: inventory_only; mutation=False	`suppliers`
⚡ REST API	PATCH	`/api/v1/suppliers/{supplier_id}`	update_supplier Semantic binding: operator_surface; mutation=True	`suppliers`
⚡ REST API	POST	`/api/v1/suppliers`	create_supplier Semantic binding: operator_surface; mutation=True	`suppliers`

🛡️ Regulatory & Compliance

Dieses Modul unterliegt folgenden gesetzlichen, regulatorischen und Revisionsstandards:

GoBD Nachvollziehbarkeit
Mandanten-Isolation (PostgreSQL RLS)