Kundenstamm
customers
crm_office
🛡️ RLS Protected
Kundenstamm — aus Code abgeleitete Prozess- und API-Dokumentation.
⚡ Workflows & Lifecycles
Kundenportal-Bestellung & ERP-Kaskadierung
portal_order_cascade
Vom Warenkorb im Kundenportal bis zur automatischen Anlage von Angebot und Lieferauftrag.
Benutzerbefehl: customer crud subagent
plan:command_customer_crud_subagent
Geprüfter Durable-Plan (durable_plan), Start: manual_command.
Benutzerbefehl: portal admin agent
plan:command_portal_admin_agent
Geprüfter Durable-Plan (durable_plan), Start: manual_command.
Kundenportal-Anfrage eingegangen
plan:portal_request_dispatch
Geprüfter Durable-Plan (durable_plan), Start: domain_event.
⚙️ 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 customer_crud_subagent
agent_entry:customer_crud_subagent
|
Agent-Einstieg customer_crud_subagent
Quelle:
code:module_agent_map
|
manual_entry |
✓ Auto
|
Keine Seiteneffekte deklariert |
Kunden anlegen
capability:customer.create
Op:
customer.create
|
Intent:
create_customer
Quelle:
code:capability_registry
|
⚙️ Engine |
✓ Auto
Risiko:
business_record
|
|
Kreditlimit
capability:customer.credit.limit_set
Op:
customer.credit.limit_set
|
Objekt:
customer
Quelle:
code:capability_registry
|
⚙️ Engine |
✓ Auto
Risiko:
business_record
|
|
Mahnsperre
capability:customer.dunning.block
Op:
customer.dunning.block
|
Objekt:
customer
Quelle:
code:capability_registry
|
⚙️ Engine |
✓ Auto
Risiko:
business_record
|
|
Kunden aktualisieren
capability:customer.update
Op:
customer.update
|
Intent:
update_customer
Quelle:
code:capability_registry
|
⚙️ Engine |
✓ Auto
Risiko:
business_record
|
|
Customer: create
capability:customers.customer.create
Op:
customers.customer.create
|
Objekt:
customer
Quelle:
code:capability_registry
|
⚙️ Engine |
✓ Auto
Risiko:
business_record
|
|
Customer: delete
capability:customers.customer.delete
Op:
customers.customer.delete
|
Objekt:
customer
Quelle:
code:capability_registry
|
⚙️ Engine |
✓ Auto
Risiko:
business_record
|
|
Customer: update
capability:customers.customer.update
Op:
customers.customer.update
|
Objekt:
customer
Quelle:
code:capability_registry
|
⚙️ Engine |
✓ Auto
Risiko:
business_record
|
|
Portal-Dokumentfreigabe widerrufen
capability:portal.document.revoke
Op:
portal.document.revoke
|
Objekt:
portal_document
Quelle:
code:capability_registry
|
⚙️ Engine |
✓ Auto
Risiko:
business_record
|
|
Portal Dokument
capability:portal.document.share
Op:
portal.document.share
|
Objekt:
portal_document
Quelle:
code:capability_registry
|
⚙️ Engine |
🔒 Freigabe nötig
Risiko:
external_effect
|
|
Passwort erzwingen
capability:portal.password.force_reset
Op:
portal.password.force_reset
|
Objekt:
portal_account
Quelle:
code:capability_registry
|
⚙️ Engine |
✓ Auto
Risiko:
business_record
|
|
Portal: create account
capability:portal.portal.create_account
Op:
portal.portal.create_account
|
Objekt:
portal
Quelle:
code:capability_registry
|
⚙️ Engine |
✓ Auto
Risiko:
business_record
|
|
Portal: create invite
capability:portal.portal.create_invite
Op:
portal.portal.create_invite
|
Objekt:
portal
Quelle:
code:capability_registry
|
⚙️ Engine |
✓ Auto
Risiko:
business_record
|
|
Portal: create ticket
capability:portal.portal.create_ticket
Op:
portal.portal.create_ticket
|
Objekt:
portal
Quelle:
code:capability_registry
|
⚙️ Engine |
✓ Auto
Risiko:
business_record
|
|
Portal: decide task
capability:portal.portal.decide_task
Op:
portal.portal.decide_task
|
Objekt:
portal
Quelle:
code:capability_registry
|
⚙️ Engine |
✓ Auto
Risiko:
business_record
|
|
Portal: reply ticket
capability:portal.portal.reply_ticket
Op:
portal.portal.reply_ticket
|
Objekt:
portal
Quelle:
code:capability_registry
|
⚙️ Engine |
✓ Auto
Risiko:
business_record
|
|
Portal: reset account password
capability:portal.portal.reset_account_password
Op:
portal.portal.reset_account_password
|
Objekt:
portal
Quelle:
code:capability_registry
|
⚙️ Engine |
✓ Auto
Risiko:
business_record
|
|
Portal: revoke invite
capability:portal.portal.revoke_invite
Op:
portal.portal.revoke_invite
|
Objekt:
portal
Quelle:
code:capability_registry
|
⚙️ Engine |
✓ Auto
Risiko:
business_record
|
|
Portal: set account status
capability:portal.portal.set_account_status
Op:
portal.portal.set_account_status
|
Objekt:
portal
Quelle:
code:capability_registry
|
⚙️ Engine |
✓ Auto
Risiko:
business_record
|
|
Portal: update profile
capability:portal.portal.update_profile
Op:
portal.portal.update_profile
|
Objekt:
portal
Quelle:
code:capability_registry
|
⚙️ Engine |
✓ Auto
Risiko:
business_record
|
|
Portal auto-freigabe
capability:portal.request.auto_approve
Op:
portal.request.auto_approve
|
Objekt:
portal_request
Quelle:
code:capability_registry
|
⚙️ Engine |
🔒 Freigabe nötig
Risiko:
external_effect
|
|
Portal-Konto anlegen
capability:portal_account.create
Op:
portal_account.create
|
Intent:
create_portal_account
Quelle:
code:capability_registry
|
⚙️ Engine |
🔒 Freigabe nötig
Risiko:
external_effect
|
|
Portal-Passwort zurücksetzen
capability:portal_account.reset_password
Op:
portal_account.reset_password
|
Intent:
reset_portal_password
Quelle:
code:capability_registry
|
⚙️ Engine |
🔒 Freigabe nötig
Risiko:
external_effect
|
|
Portal-Konto-Status setzen
capability:portal_account.set_status
Op:
portal_account.set_status
|
Intent:
set_portal_account_status
Quelle:
code:capability_registry
|
⚙️ Engine |
🔒 Freigabe nötig
Risiko:
business_record
|
|
Portal-Einladung erstellen
capability:portal_invite.create
Op:
portal_invite.create
|
Intent:
invite_portal_user
Quelle:
code:capability_registry
|
⚙️ Engine |
🔒 Freigabe nötig
Risiko:
external_effect
|
|
Portal-Einladung widerrufen
capability:portal_invite.revoke
Op:
portal_invite.revoke
|
Intent:
revoke_portal_invite
Quelle:
code:capability_registry
|
⚙️ Engine |
✓ Auto
Risiko:
business_record
|
|
Portal-Anfrage entscheiden
capability:portal_request.decide
Op:
portal_request.decide
|
Intent:
decide_portal_request
Quelle:
code:capability_registry
|
⚙️ Engine |
🔒 Freigabe nötig
Risiko:
business_record
|
|
customer: create form
form_surface_anchor:customer.create
|
Objekt:
customer
Quelle:
code:erp_form_surface
|
operator_surface |
✓ Auto
|
Keine Seiteneffekte deklariert |
customer: edit form
form_surface_anchor:customer.edit
|
Objekt:
customer
Quelle:
code:erp_form_surface
|
operator_surface |
✓ Auto
|
Keine Seiteneffekte deklariert |
Portal-Anfrage entscheiden
gateway:portal_request_decision
Op:
portal_request.decide
|
Portal-Anfrage entscheiden
Quelle:
code:reviewed_gateway
|
⚙️ Engine |
✓ Auto
|
Keine Seiteneffekte deklariert |
Benutzerbefehl: customer crud subagent
plan:command_customer_crud_subagent
|
Benutzerbefehl: customer crud subagent
Quelle:
code:reviewed_execution_plan
|
durable_plan |
✓ Auto
|
Keine Seiteneffekte deklariert |
Benutzerbefehl: portal admin agent
plan:command_portal_admin_agent
|
Benutzerbefehl: portal admin agent
Quelle:
code:reviewed_execution_plan
|
durable_plan |
✓ Auto
|
Keine Seiteneffekte deklariert |
Kundenportal-Anfrage eingegangen
plan:portal_request_dispatch
|
Kundenportal-Anfrage eingegangen
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.
Der durchgängige Businessprozess im Detail (End-to-End Fließtext-Erzählung)
Der durchgängige CRM- und Kundenakquise-Prozess in der betrieblichen Praxis
Vom ersten anonymen Webseiten-Besucher oder Messekontakt bis zum langjährigen Großkunden: Centurio ERP organisiert Kundenbeziehungen transparent, datenschutzkonform und abschlussorientiert.
1. Lead-Erfassung & Multi-Channel-Ingestion
Interessenten (Leads) gelangen über verschiedenste Berührungspunkte (Touchpoints) in das System:
- E-Mail-Posteingang & KI-Parsing (
inbox): Eingehende Kundenanfragen an Vertriebspostfächer (z.B. [email protected]) werden durch die semantische KI-Engine analysiert. Bei Erstkontakten erzeugt das System automatisch einen Lead (cap:crm.lead.create_from_inbox) und extrahiert Name, Firma, Telefonnummer und Anliegen. - Webformulare & Landingpages: Über sichere HMAC-Webhooks (
automations) fließen Kontaktanfragen von Firmen-Websites direkt in den Lead-Pool. - Messen & Veranstaltungen: Vertriebsmitarbeiter fotografieren Visitenkarten per Smartphone-App; die OCR-Erkennung legt die Kontaktdaten sekundenschnell an.
- DSGVO-Prüfung: Das System verifiziert sofort den Werbeeinwilligungsstatus (Opt-In nach Art. 7 DSGVO) und protokolliert Zeitstempel und Herkunftsquelle revisionssicher.
2. Lead-Qualifizierung & BANT-Scoring
Nicht jeder Lead ist vertriebsreif. Centurio ERP nutzt das bewährte BANT-Framework:
- B – Budget: Verfügt der Interessent über ein adäquates Investitionsbudget?
- A – Authority (Entscheidungskompetenz): Sprechen wir mit dem Entscheider (C-Level, Abteilungsleiter) oder einem reinen Informationssuchenden?
- N – Need (Bedarf): Passt die konkrete Anforderung zum Produktportfolio des Unternehmens?
- T – Timeline (Zeithorizont): Ist die Beschaffung kurzfristig (z.B. nächstes Quartal) oder erst in unbestimmter Zukunft geplant?
- Lead-Score: Anhand der Antworten und Interaktionen (z.B. E-Mail geöffnet, Datenblatt heruntergeladen) errechnet das System einen dynamischen Lead-Score (0–100 Punkte). Ab 70 Punkten gilt der Lead als vertriebsreif (Sales Qualified Lead - SQL).
3. Lead-Konvertierung & Opportunity-Anlage
Erreicht der Lead die Reife, erfolgt die Konvertierung über die Capability cap:crm.lead.convert:
- Der Lead wird archiviert.
- Ein neuer Unternehmenseintrag im Kundenstamm (
customers) sowie ein verknüpfter Ansprechpartner werden angelegt (oder mit bestehenden Stammdaten gematcht, um Dubletten zu vermeiden). - Eine konkrete Verkaufschance (Opportunity) wird eröffnet.
4. Die Opportunity-Pipeline & Umsatz-Forecast
Die Opportunity durchläuft den visuellen Kanban-Funnel des Vertriebs:
- Qualifizierung & Erstgespräch (Wahrscheinlichkeit: 10%)
- Bedarfsanalyse & Lösungsdesign (Wahrscheinlichkeit: 30%)
- Angebot vorgelegt (Wahrscheinlichkeit: 60%)
- Verhandlung & Vertragsgestaltung (Wahrscheinlichkeit: 80%)
- Gewonnen (
closed_won) oder Verloren (closed_lost)
- Gewichteter Forecast: Das Management sieht in Echtzeit den gewichteten Pipeline-Umsatz: $$\text{Forecast-Wert} = \sum (\text{Erwartetes Volumen} \times \text{Abschlusswahrscheinlichkeit})$$
- Droht ein Projekt zu stocken (z.B. keine Aktivität seit 14 Tagen), hebt das System die Opportunity rot hervor und generiert eine Wiedervorlageaufgabe.
5. 360-Grad-Kundenakte & Aktivitäten-Timeline
Alle Kundeninteraktionen laufen in einer zentralen Übersicht zusammen:
- Gesendete und empfangene E-Mails (
communications). - Telefonnotizen und Meeting-Protokolle mit Aktionspunkten.
- Verknüpfte Angebote, Aufträge, offene Rechnungen und Support-Tickets.
- Dokumentenarchiv mit Verträgen und Geheimhaltungsvereinbarungen (NDA).
6. Übergabe an Angebot & Kundenauftrag
Sobald der Kunde ein konkretes Angebot fordert:
- Aus der Opportunity heraus ruft der Vertriebler
cap:quotes.quote.create_from_opportunityauf. - Alle relevanten Daten (Ansprechpartner, Konditionen, Leistungsbeschreibung) werden übernommen; der Vertriebswechsel von der Akquise zur kaufmännischen Vorkalkulation erfolgt ohne Medienbruch.
- Gewinnt das Unternehmen den Auftrag, schließt der Gateway
gw:opportunity_closure@v1die Opportunity mit Statusclosed_wonab und stößt die Auftragsabwicklung an.
Meta-Fachlogik: Ideologische Blaupause, Soll-Weltbild & Normen
Meta-Fachlogik: Die ideologische Blaupause & das normative Weltbild
Die Meta-Fachlogik des Kundenmanagements stützt sich auf Methodiken des modernen Vertriebsmanagements (Solution Selling, Inbound Marketing), die DSGVO und datengetriebenes Sales-Controlling.
1. Methodische Vertriebsprinzipien
- BANT & Solution Selling: Professioneller B2B-Vertrieb verkauft keine Produkteigenschaften, sondern löst geschäftliche Schmerzpunkte (Pain Points) des Kunden. Die Erfassung von Kundenproblemen und erwartetem Nutzen (ROI) steht im Zentrum.
- Pipeline-Disziplin: Eine Vertriebspipeline muss aktiv bewirtschaftet werden (Pipeline Velocity). Leads und Opportunities dürfen nicht als Karteileichen verharren. Sie müssen kontinuierlich qualifiziert, vorangetrieben oder konsequent auf verloren geschlossen werden.
2. Datenschutzrechtliche Vorgaben (DSGVO & UWG)
- Rechtsgrundlage der Verarbeitung (Art. 6 DSGVO):
- Vorvertragliche Maßnahmen auf Anfrage der betroffenen Person (Art. 6 Abs. 1 lit. b DSGVO) oder berechtigtes Interesse (lit. f).
- E-Mail-Marketing und Werbeansprache erfordern im B2B die ausdrückliche Einwilligung (§ 7 UWG) bzw. eine bestehende Kundenbeziehung.
- Recht auf Vergessenwerden (Art. 17 DSGVO):
- Das Soll-Modell verlangt die Fähigkeit zur vollständigen Anonymisierung oder Löschung von Interessentendaten auf Verlangen, sofern keine steuerlichen Aufbewahrungspflichten (HGB/AO) entgegenstehen.
3. Invarianten des Soll-Modells
- Kein Werbekontakt ohne dokumentierte Werbeeinwilligung oder berechtigtes Interesse.
- Keine Konvertierung eines unqualifizierten Leads ohne Mindest-Kontaktdaten (Name, Firma, Anliegen).
- Jede verlorene Opportunity erfordert zwingend einen dokumentierten Verlustgrund (Lost Reason).
- Stammdaten müssen dublettenfrei gehalten werden (Matching von Firmennamen und Domänen).
Normbezug für customers
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:
eu-gdpr-2016-679, Regulation (EU) 2016/679 (General Data Protection Regulation, GDPR/DSGVO), Ausgabe Regulation (EU) 2016/679, anwendbar ab 2018-05-25. Art: regulatory. Ö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: ISO 8000, ISO 22745. 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 in den Modulen crm und customers.
1. Datenmodelle & Semantische Schicht (ORM)
CrmLead: Interessentenkopf (Felder:id,tenant_id,first_name,last_name,company_name,email,phone,status[new, contacted, qualified, converted, junk],lead_source,score,bant_data).Customer: Der juristische Kundenstamm (Felder:id,customer_number,company_name,tax_id,vat_id,credit_limit,payment_term_id,is_blocked).CustomerContact: Ansprechpartner des Kunden (Felder:customer_id,name,department,position,email,phone,is_primary).CrmOpportunity: Verkaufschance (Felder:id,customer_id,title,stage,probability_percent,expected_revenue,close_date,lead_id,lost_reason).CrmActivity: Interaktionshistorie (Telefonate, Notizen, E-Mails, Besuche).
2. Das Capability-Register
cap:crm.lead.create: Neuanlage eines Leads.cap:crm.lead.create_from_inbox: Automatische Extraktion aus eingehender E-Mail.cap:crm.lead.qualify: Aktualisierung des BANT-Scores und Qualifikationsstatus.cap:crm.lead.convert: Überführung in Kunde, Ansprechpartner und Opportunity.cap:crm.opportunity.create: Anlage einer Verkaufschance.cap:crm.opportunity.update_stage: Verschieben der Opportunity in die nächste Pipeline-Phase.cap:crm.opportunity.close_won: Erfolgreicher Abschluss mit Koppelung an Angebot/Auftrag.cap:crm.opportunity.close_lost: Schließen als verloren mit Verlustgrund.cap:customers.customer.gdpr_anonymize: DSGVO-konforme Löschung/Anonymisierung.
3. Der Gateway gw:opportunity_closure@v1
Sichert den Vertriebserfolg ab:
- Validierung: Prüft, ob bei
closed_wonein zugehöriges Angebot oder ein Auftrag existiert; prüft beiclosed_lost, ob ein Verlustgrund deklariert ist. - Statuswechsel: Aktualisiert den Opportunity-Status und berechnet den finalen Pipeline-Erfolg.
- Outbox-Signal: Feuert
OPPORTUNITY_CLOSED_WONbzw.OPPORTUNITY_CLOSED_LOST.
4. Statusmodelle
- Lead-Status:
new➔contacted➔qualified➔convertedoderjunk. - Opportunity-Phasen:
qualification➔needs_analysis➔proposal_presented➔negotiation➔closed_wonoderclosed_lost.
KI-Consultant Leitfaden: Customizing- & No-Code-Konzept (Soll-Ist-Synthese)
KI-Consultant Blueprint: Customizing & No-Code Architektur
Anleitung für Solution Architects zur Einrichtung von CRM- und Pipeline-Prozessen.
1. Kundenanforderungsanalyse
- Welche Vertriebsphasen bilden die tatsächliche Kundenreise (Customer Journey) ab?
- Welche Kriterien führen zum Lead-Scoring (z.B. Branche, Unternehmensgröße, Dringlichkeit)?
- Wie soll die automatische E-Mail-zu-Lead Kaskadierung reagieren (automatische Neuanlage oder erst Vorschlag zur Bestätigung)?
2. No-Code Zusatzfelder (Custom Fields)
Im No-Code Studio (/semantic/customizing):
- Auf
CrmLead:industry_sector(Auswahlliste: Maschinenbau, Automotive, Handwerk, IT, Pharma).annual_turnover_range(Auswahlliste: < 1 Mio €, 1-10 Mio €, > 10 Mio €).
- Auf
CrmOpportunity:decision_maker_identified(Checkbox): Pflicht vor Phase Verhandlung.primary_competitor(Text): Wichtigster Wettbewerber in diesem Pitch.
3. No-Code Workflow Canvas DAGs
Blueprint A: KI-E-Mail-zu-Lead Kaskadierung (Inbox Lead DAG)
- Trigger-Node: Event
INBOX_MESSAGE_CLASSIFIED(Kategorie: Neukundenanfrage). - Condition-Node:
message.sender_email NOT IN customers.contacts.email. - Action-Node 1: Rufe
cap:crm.lead.create_from_inboxauf. - Action-Node 2: Berechne BANT-Initialwert anhand des Nachrichtentexts.
- Notification-Node: Zuweisung einer Lead-Prüfaufgabe an den diensthabenden Vertriebler.
Blueprint B: Automatisches Reaktivierungs-Follow-Up (Dormant Deal DAG)
- Trigger-Node: Scheduled Cron (
0 9 * * 1) – Wöchentlich. - Condition-Node:
opportunity.stage NOT IN ['closed_won', 'closed_lost'] AND days_since_last_activity > 21. - Action-Node: Erzeuge To-Do-Aufgabe: Kunde reaktivieren oder Opportunity schließen mit Push an Opportunity-Owner.
📚 Operative Prozessbegriffe & Transaktionsschnittstellen
- Eingehende E-Mail-Anfragen an Vertriebspostfächer
- Website-Kontaktformulare über Webhooks
- Visitenkartenscans von Messen und Außendienstterminen
- Telefonische Erstanfragen im Vertriebsinnendienst
- Qualifizierte Firmen- und Ansprechpartnerdaten im Kundenstamm
- Aktive Verkaufschancen in der grafischen Pipeline-Übersicht
- Gewichtete Vertriebs- und Umsatz-Forecasts für die Geschäftsführung
- Rechtssichere DSGVO-Verarbeitungsprotokolle und Einwilligungsnachweise
- lead_converted -> customer_created: Sofortige Anlage im Stammdatenverzeichnis
- opportunity_won -> trigger_quote_or_order: Übernahme in die Angebots- oder Auftragsphase
- lead_scored_high -> notify_sales_rep: Sofortige Alarmierung bei heißen Leads
- opportunity_lost -> schedule_nurturing_campaign: Einsteuern in spätere Reaktivierung
- Dublettenprüfung und Zusammenführung doppelt erfasster Kontakte
- DSGVO-Auskunfts- und Löschersuchen (Recht auf Vergessenwerden)
- Zuweisung von Vertriebsgebieten nach Postleitzahlen und Branchen
- Rückstufung inaktiver Verkaufschancen in Marketing-Nurturing-Kampagnen
- Vertriebsphasen und prozentuale Abschlusswahrscheinlichkeiten anpassen
- BANT-Schwellenwerte für automatische Lead-Qualifizierung definieren
- Pflichtfelder (z.B. Telefon, Branche) für die Lead-Konvertierung festlegen
- No-Code Zusatzfelder für Branchen und Wettbewerber auf Opportunity anlegen
🗄️ Data Models & Fields
🔌 Entry Points (UI & APIs)
| Art | Method | Endpoint / Path | Titel & Zweck | Required Role |
|---|---|---|---|---|
| ⚡ REST API | DELETE | /api/v1/customers/{customer_id} |
delete_customer
Semantic binding: operator_surface; mutation=True
|
customers
|
| ⚡ REST API | DELETE | /api/v1/customers/{customer_id}/contacts/{contact_id} |
delete_contact
Semantic binding: operator_surface; mutation=True
|
customers
|
| ⚡ REST API | GET | /api/v1/customers |
list_customers
Semantic binding: inventory_only; mutation=False
|
customers
|
| ⚡ REST API | GET | /api/v1/customers/stats |
customer_stats
Semantic binding: inventory_only; mutation=False
|
customers
|
| ⚡ REST API | GET | /api/v1/customers/{customer_id} |
get_customer
Semantic binding: inventory_only; mutation=False
|
customers
|
| ⚡ REST API | GET | /api/v1/customers/{customer_id}/contacts |
list_contacts
Semantic binding: inventory_only; mutation=False
|
customers
|
| ⚡ REST API | GET | /api/v1/customers/{customer_id}/invoice-recipient |
get_invoice_recipient
Semantic binding: inventory_only; mutation=False
|
customers
|
| ⚡ REST API | GET | /api/v1/customers/{customer_id}/portal |
customer_portal_state
Semantic binding: inventory_only; mutation=False
|
customers
|
| ⚡ REST API | GET | /api/v1/customers/{customer_id}/shop-rates |
list_partner_shop_rates
Semantic binding: inventory_only; mutation=False
|
customers
|
| ⚡ REST API | GET | /api/v1/customers/{customer_id}/tree |
get_customer_tree
Semantic binding: inventory_only; mutation=False
|
customers
|
| ⚡ REST API | GET | /customers |
customers_page
Semantic binding: inventory_only; mutation=False
|
customers
|
| ⚡ REST API | GET | /customers/new |
customer_create_page
Semantic binding: inventory_only; mutation=False
|
customers
|
| ⚡ REST API | GET | /customers/{customer_id} |
customer_detail_page
Semantic binding: inventory_only; mutation=False
|
customers
|
| ⚡ REST API | GET | /customers/{customer_id}/edit |
customer_detail_page
Semantic binding: inventory_only; mutation=False
|
customers
|
| ⚡ REST API | GET | /customers/{customer_id}/portal |
customer_portal_admin_page
Semantic binding: inventory_only; mutation=False
|
customers
|
| ⚡ REST API | GET | /portal/{slug}/profil |
profile_page
Semantic binding: inventory_only; mutation=False
|
customers
|
| ⚡ REST API | PATCH | /api/v1/customers/{customer_id} |
update_customer
Semantic binding: operator_surface; mutation=True
|
customers
|
| ⚡ REST API | PATCH | /api/v1/customers/{customer_id}/contacts/{contact_id} |
update_contact
Semantic binding: operator_surface; mutation=True
|
customers
|
| ⚡ REST API | POST | /api/v1/customers |
create_customer
Semantic binding: operator_surface; mutation=True
|
customers
|
| ⚡ REST API | POST | /api/v1/customers/{customer_id}/contacts |
create_contact
Semantic binding: operator_surface; mutation=True
|
customers
|
| ⚡ REST API | POST | /api/v1/customers/{customer_id}/portal/accounts |
customer_portal_account_add
Semantic binding: operator_surface; mutation=True
|
customers
|
| ⚡ REST API | POST | /api/v1/customers/{customer_id}/portal/accounts/{account_id}/password |
customer_portal_account_password
Semantic binding: operator_surface; mutation=True
|
customers
|
| ⚡ REST API | POST | /api/v1/customers/{customer_id}/portal/accounts/{account_id}/status |
customer_portal_account_status
Semantic binding: operator_surface; mutation=True
|
customers
|
| ⚡ REST API | POST | /api/v1/customers/{customer_id}/portal/invites |
customer_portal_invite
Semantic binding: operator_surface; mutation=True
|
customers
|
| ⚡ REST API | POST | /api/v1/customers/{customer_id}/portal/invites/{invite_id}/revoke |
customer_portal_invite_revoke
Semantic binding: operator_surface; mutation=True
|
customers
|
| ⚡ REST API | POST | /api/v1/customers/{customer_id}/portal/toggle |
customer_portal_toggle
Semantic binding: operator_surface; mutation=True
|
customers
|
| ⚡ REST API | POST | /customers/{customer_id}/portal |
customer_portal_admin_save
Semantic binding: operator_surface; mutation=True
|
customers
|
| ⚡ REST API | POST | /customers/{customer_id}/portal/accounts |
customer_portal_account_create
Semantic binding: operator_surface; mutation=True
|
customers
|
| ⚡ REST API | POST | /customers/{customer_id}/portal/accounts/{account_id}/password |
customer_portal_account_password
Semantic binding: operator_surface; mutation=True
|
customers
|
| ⚡ REST API | POST | /customers/{customer_id}/portal/accounts/{account_id}/status |
customer_portal_account_status
Semantic binding: operator_surface; mutation=True
|
customers
|
| ⚡ REST API | POST | /customers/{customer_id}/portal/invites |
customer_portal_invite_create
Semantic binding: operator_surface; mutation=True
|
customers
|
| ⚡ REST API | POST | /customers/{customer_id}/portal/invites/{invite_id}/revoke |
customer_portal_invite_revoke
Semantic binding: operator_surface; mutation=True
|
customers
|
| ⚡ REST API | POST | /portal/{slug}/profil |
profile_submit
Semantic binding: operator_surface; mutation=True
|
customers
|
| ⚡ REST API | POST | /portal/{slug}/profil/kontakte |
profile_contact_save
Semantic binding: operator_surface; mutation=True
|
customers
|
| ⚡ REST API | POST | /portal/{slug}/profil/kontakte/{contact_id}/loeschen |
profile_contact_delete
Semantic binding: operator_surface; mutation=True
|
customers
|
| ⚡ REST API | POST | /portal/{slug}/profil/standorte |
profile_location_save
Semantic binding: operator_surface; mutation=True
|
customers
|
| ⚡ REST API | POST | /portal/{slug}/profil/standorte/{location_id}/deaktivieren |
profile_location_deactivate
Semantic binding: operator_surface; mutation=True
|
customers
|
| ⚡ REST API | PUT | /api/v1/customers/{customer_id}/shop-rates |
upsert_partner_shop_rate
Semantic binding: operator_surface; mutation=True
|
customers
|
| 🖥️ WEB-UI | GET | /portal/{slug}/ |
Portal Startseite
Kunden-Dashboard mit Schnellzugriffen und Statuskacheln
|
Standard |
| 🖥️ WEB-UI | GET | /portal/{slug}/bestellung |
Portal Bestellseite
Katalogbestellung mit dynamischen Fieldsets
|
Standard |
| 🖥️ WEB-UI | GET | /portal/{slug}/rechnungen |
Portal Rechnungen
Rechnungsarchiv und PDF-Download
|
Standard |
| ⚡ REST API | POST | /portal/{slug}/bestellung |
Bestellung einreichen
Validiert Fieldsets und erzeugt Quote/WorkOrder
|
Standard |
🛡️ Regulatory & Compliance
Dieses Modul unterliegt folgenden gesetzlichen, regulatorischen und Revisionsstandards:
- GoBD Nachvollziehbarkeit
- Mandanten-Isolation (PostgreSQL RLS)