Centurio System & Module Documentation
🏛️ Platform Architecture 🔑 Login
All Modules / crm_office / Tickets & Helpdesk
🎧

Tickets & Helpdesk

tickets crm_office 🛡️ RLS Protected

Kundensupport-Tickets, SLA-Eskalationsstufen, Ticket-Routing und Verknüpfung mit Aufträgen und Kundenportal.

Fachliche Bestimmung: Kanalisiert Kundenanfragen, Störungsmeldungen und Serviceaufträge. Tickets können direkt aus dem Kundenportal, per E-Mail oder manuell erstellt werden. Unterstützt interne Teamnotizen (die für Kunden unsichtbar bleiben), Zeiterfassung sowie Eskalation nach definierten Service-Level-Agreements (SLA).

⚡ Workflows & Lifecycles

Lieferschein-Vollverarbeitung cascade:business.delivery_note.intake

Kaskade (review_gated).

1. stock
Wareneingang ins Lager buchen
inventory
Aktionen: post_goods_receipt
2. tour
Tour / Weitertransport einplanen
logistics
Aktionen: create_tour
3. task
Wareneingang prüfen / abgleichen
tasks
Aktionen: create_task
4. qc
Qualitätsprüfung bei Mängelverdacht
inventory
Aktionen: quality.check.create
5. ticket
Reklamations-Ticket bei Mängeln
tickets
Aktionen: create_ticket

Wartung / Instandsetzung cascade:business.maintenance.cycle

Kaskade (review_gated).

1. fieldservice
Außendienst-Einsatz / Bericht erfassen
fieldservice
Aktionen: create_service_report
2. followup
Wartungsfolge planen
assets
Aktionen: maintenance.schedule
3. ticket
Ticket bei Mängeln/Störung
tickets
Aktionen: create_ticket

Retourenbearbeitung cascade:business.return_note.handling

Kaskade (review_gated).

1. ticket
Reklamations-Ticket anlegen
tickets
Aktionen: create_ticket
2. tour
Abholtour einplanen
logistics
Aktionen: create_tour
3. task
Retoure weiterbearbeiten
tasks
Aktionen: create_task

Außendienst → Abrechnung cascade:business.work_report.billing

Kaskade (review_gated).

1. fieldservice
Außendienst-Einsatz / Servicebericht
fieldservice
Aktionen: create_service_report
2. task
Abrechnung nachverfolgen
tasks
Aktionen: create_task
3. ticket
Ticket bei Mängeln/Störung
tickets
Aktionen: create_ticket

Ticket / Vorgang anlegen cascade_target:business.ticket.create

Kaskade (review_gated).

1. cascade
Ticket / Vorgang anlegen

Ticket status:ticket

Beobachtbare Zustandsmaschine (observable_only). Übergänge hier nicht erzwungen — siehe Service-Validierung.

1. new
new
Status «new» der Zustandsmaschine Ticket.
2. open
open
Status «open» der Zustandsmaschine Ticket.
3. in_progress
in_progress
Status «in_progress» der Zustandsmaschine Ticket.
4. pending_customer
pending_customer
Status «pending_customer» der Zustandsmaschine Ticket.
5. pending_vendor
pending_vendor
Status «pending_vendor» der Zustandsmaschine Ticket.
6. resolved
resolved
Status «resolved» der Zustandsmaschine Ticket.
7. closed
closed
Status «closed» der Zustandsmaschine Ticket.
8. cancelled
cancelled
Status «cancelled» der Zustandsmaschine Ticket.

⚙️ Fachprozesse & Capabilities (System-Fachlogik)

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

Gesamt: 30 manual_entry: 1 reviewed: 1 engine: 21 review_gated: 5 operator_surface: 1 observable_only: 1
Capability & Schlüssel Fachliche Bezeichnung Ausführung / Coverage Risikostufe & Freigabe Effekte & Kaskaden
Agent-Einstieg core_workflow_agent agent_entry:core_workflow_agent
Agent-Einstieg core_workflow_agent
Quelle: code:module_agent_map
manual_entry
✓ Auto
Keine Seiteneffekte deklariert
Ticket / Vorgang anlegen capability:create_ticket
Op: create_ticket
Objekt: ticket
Quelle: code:capability_registry
reviewed
🔒 Freigabe nötig Risiko: business_record
  • cascade:business.ticket.create
Ticket zuweisen capability:ticket.assign
Op: ticket.assign
Intent: assign_ticket
Quelle: code:capability_registry
⚙️ Engine
✓ Auto Risiko: business_record
  • ticket.assigned
Eskalation capability:ticket.escalate
Op: ticket.escalate
Objekt: ticket
Quelle: code:capability_registry
⚙️ Engine
✓ Auto Risiko: business_record
  • ticket.escalate
Wissen vorschlagen capability:ticket.knowledge.suggest
Op: ticket.knowledge.suggest
Objekt: ticket
Quelle: code:capability_registry
⚙️ Engine
✓ Auto Risiko: business_record
  • ticket.knowledge.suggest
Tickets mergen capability:ticket.merge
Op: ticket.merge
Objekt: ticket
Quelle: code:capability_registry
⚙️ Engine
✓ Auto Risiko: business_record
  • ticket.merge
SLA-Warnung capability:ticket.sla.breach_notify
Op: ticket.sla.breach_notify
Objekt: ticket
Quelle: code:capability_registry
⚙️ Engine
✓ Auto Risiko: business_record
  • ticket.sla.breach_notify
Ticketstatus setzen capability:ticket.transition
Op: ticket.transition
Intent: update_ticket
Quelle: code:capability_registry
⚙️ Engine
✓ Auto Risiko: business_record
  • ticket.status
Ticket: add message capability:tickets.ticket.add_message
Op: tickets.ticket.add_message
Objekt: ticket
Quelle: code:capability_registry
⚙️ Engine
✓ Auto Risiko: business_record
  • ticket.add_message
Ticket: create project from ticket capability:tickets.ticket.create_project_from_ticket
Op: tickets.ticket.create_project_from_ticket
Objekt: ticket
Quelle: code:capability_registry
⚙️ Engine
✓ Auto Risiko: business_record
  • ticket.create_project_from_ticket
Ticket: create sla policy capability:tickets.ticket.create_sla_policy
Op: tickets.ticket.create_sla_policy
Objekt: ticket
Quelle: code:capability_registry
⚙️ Engine
✓ Auto Risiko: business_record
  • ticket.create_sla_policy
Ticket: create task from ticket capability:tickets.ticket.create_task_from_ticket
Op: tickets.ticket.create_task_from_ticket
Objekt: ticket
Quelle: code:capability_registry
⚙️ Engine
✓ Auto Risiko: business_record
  • ticket.create_task_from_ticket
Ticket: create team capability:tickets.ticket.create_team
Op: tickets.ticket.create_team
Objekt: ticket
Quelle: code:capability_registry
⚙️ Engine
✓ Auto Risiko: business_record
  • ticket.create_team
Ticket: create ticket capability:tickets.ticket.create_ticket
Op: tickets.ticket.create_ticket
Objekt: ticket
Quelle: code:capability_registry
⚙️ Engine
✓ Auto Risiko: business_record
  • ticket.create_ticket
Ticket: create ticket from invoice capability:tickets.ticket.create_ticket_from_invoice
Op: tickets.ticket.create_ticket_from_invoice
Objekt: ticket
Quelle: code:capability_registry
⚙️ Engine
✓ Auto Risiko: business_record
  • ticket.create_ticket_from_invoice
Ticket: create ticket from quote capability:tickets.ticket.create_ticket_from_quote
Op: tickets.ticket.create_ticket_from_quote
Objekt: ticket
Quelle: code:capability_registry
⚙️ Engine
✓ Auto Risiko: business_record
  • ticket.create_ticket_from_quote
Ticket: create ticket from return capability:tickets.ticket.create_ticket_from_return
Op: tickets.ticket.create_ticket_from_return
Objekt: ticket
Quelle: code:capability_registry
⚙️ Engine
✓ Auto Risiko: business_record
  • ticket.create_ticket_from_return
Ticket: create ticket from service report capability:tickets.ticket.create_ticket_from_service_report
Op: tickets.ticket.create_ticket_from_service_report
Objekt: ticket
Quelle: code:capability_registry
⚙️ Engine
✓ Auto Risiko: business_record
  • ticket.create_ticket_from_service_report
Ticket: create work order from ticket capability:tickets.ticket.create_work_order_from_ticket
Op: tickets.ticket.create_work_order_from_ticket
Objekt: ticket
Quelle: code:capability_registry
⚙️ Engine
✓ Auto Risiko: business_record
  • ticket.create_work_order_from_ticket
Ticket: submit csat capability:tickets.ticket.submit_csat
Op: tickets.ticket.submit_csat
Objekt: ticket
Quelle: code:capability_registry
⚙️ Engine
✓ Auto Risiko: business_record
  • ticket.submit_csat
Ticket: transition status capability:tickets.ticket.transition_status
Op: tickets.ticket.transition_status
Objekt: ticket
Quelle: code:capability_registry
⚙️ Engine
✓ Auto Risiko: business_record
  • ticket.transition_status
Ticket: update team capability:tickets.ticket.update_team
Op: tickets.ticket.update_team
Objekt: ticket
Quelle: code:capability_registry
⚙️ Engine
✓ Auto Risiko: business_record
  • ticket.update_team
Ticket: update ticket capability:tickets.ticket.update_ticket
Op: tickets.ticket.update_ticket
Objekt: ticket
Quelle: code:capability_registry
⚙️ Engine
✓ Auto Risiko: business_record
  • ticket.update_ticket
Lieferschein-Vollverarbeitung cascade:business.delivery_note.intake
Lieferschein-Vollverarbeitung
Quelle: code:cascade_process
review_gated
✓ Auto
Keine Seiteneffekte deklariert
Wartung / Instandsetzung cascade:business.maintenance.cycle
Wartung / Instandsetzung
Quelle: code:cascade_process
review_gated
✓ Auto
Keine Seiteneffekte deklariert
Retourenbearbeitung cascade:business.return_note.handling
Retourenbearbeitung
Quelle: code:cascade_process
review_gated
✓ Auto
Keine Seiteneffekte deklariert
Außendienst → Abrechnung cascade:business.work_report.billing
Außendienst → Abrechnung
Quelle: code:cascade_process
review_gated
✓ Auto
Keine Seiteneffekte deklariert
Ticket / Vorgang anlegen cascade_target:business.ticket.create
Op: create_ticket
Ticket / Vorgang anlegen
Quelle: code:cascade_target
review_gated
🔒 Freigabe nötig
Keine Seiteneffekte deklariert
ticket: edit form form_surface_anchor:ticket.edit
Objekt: ticket
Quelle: code:erp_form_surface
operator_surface
✓ Auto
Keine Seiteneffekte deklariert
Ticket status:ticket
Objekt: ticket
Quelle: code:status_machine
observable_only
✓ 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 Projekt- und Serviceprozess in der betrieblichen Praxis

Vom Handwerksbetrieb und Anlagenbauer über den IT-Dienstleister bis zum bundesweiten Service- und Wartungsunternehmen: Centurio ERP verzahnt Projektsteuerung, Werkstattaufträge und mobilen Außendienst zu einem durchgängigen Ablauf.

1. Projektanlage & Strukturierung (Project Initiation & WBS)

Großaufträge und kundenindividuelle Bau- oder Dienstleistungsvorhaben starten im Projektmodul:

  • Übernahme aus Angebot oder Auftrag (quotes, sales): Ein genehmigtes Angebot mit komplexen Montage- oder Bauleistungen wird über cap:projects.project.create_from_sales_order in ein Projekt überführt.
  • Projektstrukturplan (PSP / WBS): Das Projekt wird hierarchisch gegliedert in:
    • Projektkopf: Budget, Gesamtlaufzeit, Projektleiter, Kunde.
    • Phasen: z.B. Planung & Statik, Rohbau / Vorfertigung, Montage vor Ort, Inbetriebnahme & Abnahme.
    • Arbeitspakete / Meilensteine: Fälligkeitstermine und Zahlungsmeilensteine für Abschlagsrechnungen.
  • VOB/B-Kontext (bei Bau- und Montageprojekten): Das System aktiviert automatisch VOB/B-relevante Mechanismen (Bedenkenanmeldungen, Behinderungsanzeigen, förmliche Abnahmen nach § 12 VOB/B).

2. Arbeitsauftragserstellung & Disposition (Work Order Scheduling)

Aus den Arbeitspaketen des Projekts oder als eigenständige Serviceeinsätze (z.B. Reparatur, Wartung) entstehen Arbeitsaufträge (workorders):

  • Der Disponent plant die Aufträge im visuellen Plantafel-Kalender (calendar):
    • Prüfung der Mitarbeiterqualifikationen (z.B. Hochvolt-Schein, Schweißzertifikat nach ISO 9606).
    • Prüfung von Spezialwerkzeugen und Messgeräten.
    • Berücksichtigung von Wegezeiten und Routenoptimierung.
  • Über die Capability cap:workorders.workorder.assign wird der Auftrag dem Techniker oder Montageteam zugewiesen. Der Techniker erhält den Auftrag sofort auf seiner mobilen Service-App.

3. Materialbereitstellung & Fahrzeuglager (Mobile Van Stock)

Für Montage- und Außendiensteinsätze wird Material benötigt:

  • Materialreservierung: Das System prüft die Materialverfügbarkeit (inventory). Benötigte Teile werden für das Projekt reserviert.
  • Fahrzeuglager (Van Stock): Jeder Kundendienstwagen ist im System als rollender Lagerort (location_type = 'van') abgebildet.
  • Der Techniker entnimmt vor Abfahrt Teile aus dem Zentrallager (Umlagerung ins Fahrzeug) oder greift vor Ort direkt auf Standard-Verbrauchsmaterialien (Schrauben, Dichtungen, Kabel) aus seinem Fahrzeugbestand zu.

4. Vor-Ort-Ausführung & Mobile Erfassung (Field Service Execution)

Beim Kunden vor Ort dokumentiert der Techniker die Arbeiten digital auf seinem Tablet:

  • Zeiterfassung (Check-in/out): Ankunft vor Ort, Beginn der Rüstzeit, eigentliche Montagezeit und Pausen werden sekundengenau gestempelt (cap:fieldservice.dispatch.checkin). Fahrzeiten werden separat ausgewiesen.
  • Materialerfassung: Verbaute Ersatzteile werden per Barcode-Scan erfasst. Das System bucht die Teile sofort aus dem Fahrzeuglager aus (cap:fieldservice.dispatch.consume_material).
  • Aufmaß & Checklisten: Technische Prüfschritte (z.B. Druckprüfung, Isolationsmessung, VDE 0100 Prüfung) werden in strukturierten Checklisten protokolliert; Vorher-Nachher-Fotos werden direkt an den Beleg angehängt.

5. Rechtssicheres Abnahmeprotokoll & Kundensignatur (Digital Sign-Off)

Der kritischste Schritt für die spätere Abrechnung ist die förmliche Abnahme:

  • Das System generiert auf dem Tablet den digitalen Montagebericht / das Abnahmeprotokoll.
  • Es listet alle durchgeführten Arbeiten, erfassten Stunden und verbauten Materialien auf.
  • Digitale Unterschrift: Der Kunde zeichnet direkt auf dem Display gegen (cap:fieldservice.dispatch.sign_protocol).
  • Rechtsfolge: Das signierte Protokoll wird unveränderbar als PDF/A im Dokumentenarchiv (documents) festgeschrieben und automatisch per E-Mail an den Kunden gesendet.

6. Nachtragsmanagement & Behinderungsanzeigen

Treten während der Ausführung unvorhersehbare Zusatzaufwände auf:

  • Der Bauleiter erfasst eine Nachtragsvereinbarung (z.B. zusätzlicher Aushub, geänderte Rohrleitungsführung).
  • Bei Verzögerungen durch bauseitige Vorleistungen anderer Gewerke erzeugt das System per Knopfdruck eine förmliche Behinderungsanzeige nach § 6 Abs. 1 VOB/B, um Lieferfristen zu hemmen und Regressansprüche abzuwehren.

7. Gateway-basierter Projektabschluss & Fakturierung

  • Soll-Ist-Nachkalkulation: Das System vergleicht die budgetierten Plankosten mit den real gestempelten Zeiten und Materialverbräuchen. Projektdeckungsbeitrag und Margenabweichungen werden sofort im Controlling sichtbar.
  • Fakturierung: Über den Gateway gw:project_billing@v1 wird der Leistungsstand an das Rechnungsmodul (invoices) übergeben:
    • Abschlagsrechnung: Nach erreichtem Baufortschritt oder Meilenstein.
    • Schlussrechnung: Nach mängelfreier Abnahme mit Verrechnung aller bisherigen Abschlagszahlungen und eventuellem Sicherheitseinbehalt (z.B. 5% Gewährleistungseinbehalt nach VOB/B).
🏛️

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

Meta-Fachlogik: Die ideologische Blaupause & das normative Weltbild

Die Meta-Fachlogik des Projekt- und Servicemanagements stützt sich auf DIN 69901 (Projektmanagement), die Vergabe- und Vertragsordnung für Bauleistungen (VOB/B), das Werkvertragsrecht nach BGB (§§ 631 ff.) und anerkannte Regeln der Technik.

1. Werkvertragsrecht (BGB §§ 631 ff.) vs. Dienstvertrag (§ 611 BGB)

  • Erfolgsbezogenheit des Werkvertrags: Beim Werkvertrag schuldet der Auftragnehmer nicht nur das Tätigwerden, sondern die Herbeiführung des versprochenen Werkerfolgs.
  • Bedeutung der Abnahme (§ 640 BGB / § 12 VOB/B):
    • Die Abnahme ist der juristische Dreh- und Angelpunkt: Mit ihr geht die Gefahr des zufälligen Untergangs auf den Besteller über, die Beweislast für Mängel kehrt sich um, die Fälligkeit der Vergütung tritt ein und die Verjährungsfrist für Mängelansprüche (Gewährleistung) beginnt zu laufen.
    • Das Soll-Modell verbietet das Stellen einer Schlussrechnung ohne vorliegendes, beidseitig gezeichnetes Abnahmeprotokoll.

2. VOB/B-Standards (Vergabe- und Vertragsordnung für Bauleistungen)

  • Förmliche Abnahme (§ 12 VOB/B): Verlangt gemeinsame Begehung, Niederschrift aller Mängel und Festlegung von Beseitigungsfristen.
  • Bedenkenanmeldung (§ 4 Abs. 3 VOB/B): Verpflichtung des Auftragnehmers, den Auftraggeber schriftlich zu warnen, wenn Vorgaben, Vorleistungen anderer Handwerker oder Güteanforderungen ungeeignet sind.
  • Sicherheitseinbehalt (§ 17 VOB/B): Typischerweise 5% der Nettoabrechnungssumme als Gewährleistungsbürgschaft über 4 oder 5 Jahre.

3. Invarianten des Soll-Modells

  1. Kein Serviceeinsatz ohne dokumentierten Leistungsnachweis mit Zeiten und Material.
  2. Keine Schlussrechnung ohne mängelfreie oder vorbehaltlose Abnahme.
  3. Materialbuchungen aus Fahrzeuglagern müssen dem jeweiligen Auftrag zugeordnet sein (kein anonymer Verbrauch).
  4. Projektänderungen mit Kostenfolge verlangen zwingend einen genehmigten Nachtrag.

Normbezug für tickets

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:

  • itil-4, ITIL 4 Service Management Practices, Ausgabe ITIL 4 (2019) und Practice Guides (laufend). Art: reference_process. 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/IEC 20000-1, ISO 10002. 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 projects, workorders und fieldservice.

1. Datenmodelle & Semantische Schicht (ORM)

  • Project: Projektkopf (Felder: id, tenant_id, project_number, name, customer_id, project_manager_id, status, budget_net_amount, planned_start, planned_end, is_vob).
  • ProjectPhase: Phasen und Meilensteine (Felder: project_id, name, sequence, milestone_date, is_billing_milestone, billing_amount).
  • WorkOrder: Arbeitsauftrag (Felder: id, project_id, order_number, assigned_user_id, status, scheduled_date, estimated_hours, location_address).
  • FieldServiceDispatch: Außendiensteinsatz mit Check-in/out-Zeiten, GPS-Koordinaten und digitalem Signatur-Blob.
  • ProjectClaim: VOB-Bedenkenanmeldung oder Nachtrag.

2. Das Capability-Register

  • cap:projects.project.create: Neuanlage eines Projekts mit PSP-Struktur.
  • cap:projects.project.create_from_sales_order: Übernahme eines Verkaufsauftrags in ein Projekt.
  • cap:workorders.workorder.create: Erzeugung eines Arbeitsauftrags.
  • cap:workorders.workorder.assign: Disposition auf Techniker und Arbeitsplatz.
  • cap:fieldservice.dispatch.checkin: Beginn des Vor-Ort-Einsatzes (Zeiterfassung).
  • cap:fieldservice.dispatch.checkout: Ende des Vor-Ort-Einsatzes.
  • cap:fieldservice.dispatch.consume_material: Abbuchung von Teilen aus dem Fahrzeuglager.
  • cap:fieldservice.dispatch.sign_protocol: Erfassung der Kundensignatur auf dem Abnahmeprotokoll.
  • cap:projects.project.record_milestone_acceptance: Bestätigung eines Abrechnungsmeilensteins.

3. Der Gateway gw:project_billing@v1

Der Projektabrechnungs-Gateway steuert Abschlags- und Schlussrechnungen:

  1. Validierung: Prüft Abnahmeprotokolle, signierte Stundenzettel und Meilenstein-Freigaben.
  2. Kostenabgleich: Zieht alle real gestempelten Zeiten und Materialkosten in die Nachkalkulation.
  3. Rechnungserzeugung: Erzeugt transaktional die Abschlags- oder Schlussrechnung in invoices unter Berücksichtigung von bisherigen Zahlungen und VOB-Sicherheitseinbehalt.
  4. Outbox-Signal: Feuert PROJECT_BILLING_COMPLETED.

4. Statusmodelle

  • Projekt-Status: planning ➔ in_progress ➔ acceptance_pending ➔ completed oder on_hold.
  • Arbeitsauftrag: draft ➔ dispatched ➔ in_progress ➔ signed ➔ invoiced.
🤖

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 Anpassung von Projekt- und Serviceabläufen.

1. Kundenanforderungsanalyse

  • Handelt es sich um Bauprojekte nach VOB/B mit Abschlagsrechnungen oder um reine Serviceeinsätze auf Stundenbasis?
  • Welche Checklisten müssen vor Ort ausgefüllt werden (z.B. UVV-Prüfung, DGUV V3, Brandschutz)?
  • Gibt es rollende Fahrzeuglager (Service-Transporter)?

2. No-Code Zusatzfelder (Custom Fields)

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

  • Auf Project:
    • site_manager_contact (Text): Telefonnummer des Bauleiters vor Ort.
    • security_retainage_percent (Dezimal): Gewährleistungseinbehalt nach VOB (z.B. 5%).
  • Auf WorkOrder:
    • access_code_or_key_box (Text): Torschlüsselcode oder Schlüsseltresor-PIN für den Monteur.
    • required_safety_equipment (Auswahlliste: Helm, Absturzsicherung, Atemschutz).

3. No-Code Workflow Canvas DAGs

Blueprint A: Mobiles Abnahmeprotokoll ➔ Sofortfaktura (Mobile Sign-off DAG)
  • Trigger-Node: cap:fieldservice.dispatch.sign_protocol erfolgreich ausgeführt.
  • Condition-Node: workorder.billing_policy == 'immediate_post_signing'.
  • Action-Node 1: Erzeuge PDF/A-Dokument mit eingebetteter Signatur und sende Kopie an Kunden.
  • Action-Node 2: Rufe cap:invoices.invoice.create auf und übernehme quittierte Stunden und Materialien in die Rechnung.
Blueprint B: VOB-Fristenüberwachung bei Bedenkenanmeldung
  • Trigger-Node: Erfassung eines ProjectClaim (Typ: Bedenkenanmeldung).
  • Action-Node: Setze Fristenwiedervorlage auf 5 Werktage und informiere Projektleiter via Push über ausstehende Antwort des Bauherrn.

📚 Operative Prozessbegriffe & Transaktionsschnittstellen

Zentrale Fachbegriffe im Prozesszusammenhang (Operatives Modell)
Projektstrukturplan (PSP)
Hierarchische Gliederung aller Projektphasen, Arbeitspakete und Meilensteine.
VOB/B-Abnahme
Förmliche Bestätigung des Werkerfolgs nach § 12 VOB/B mit Beginn der Gewährleistung.
Fahrzeuglager (Van Stock)
Rollender Lagerort im Kundendienstfahrzeug mit mobiler Bestandsführung.
Abnahmeprotokoll
Rechtsverbindlicher Nachweis der erbrachten Leistung mit digitaler Kundensignatur.
Sicherheitseinbehalt
Fiskalischer Einbehalt (z.B. 5%) zur Absicherung von Gewährleistungsansprüchen.
Bedenkenanmeldung (§ 4 Abs. 3 VOB/B)
Schriftlicher Warnhinweis an den Bauherrn bei ungeeigneten Vorgaben.
Abschlagsrechnung
Teilrechnung über bereits fertiggestellte Bau- oder Meilensteinabschnitte.
📥 Eingänge & Trigger (Inputs)
  • Verkaufsauftrag mit Projekt- oder Montagepositionen
  • Kundenstörungsmeldung oder Wartungstermin über Ticket-System
  • Bauausschreibung mit Leistungsverzeichnis (GAEB/Excel)
  • Wartungsvertrag mit zyklischen Inspektionsintervallen
📤 Ausgänge & Arbeitsergebnisse (Outputs)
  • Projektstrukturpläne mit Termin- und Ressourcenleiste (Gantt)
  • Mobil signierte Abnahmeprotokolle und Montageberichte
  • Revisionssichere VOB-Schriftstücke (Behinderungsanzeigen, Bedenken)
  • Abschlags- und Schlussrechnungen mit Soll-Ist-Nachkalkulation
  • Aktualisierte Bestandsspiegel der Fahrzeuglager
⚡ Kaskaden & Folgeprozesse (Cascades)
  • protocol_signed -> trigger_invoice_creation: Sofortige Erzeugung der Rechnung nach Signatur
  • material_consumed -> van_stock_depleted: Abbuchung der Teile aus dem Kundendiensttransporter
  • milestone_reached -> unlock_billing_phase: Freigabe der nächsten Abschlagsrechnung
  • project_completed -> finalize_job_costing: Festschreibung der Nachkalkulation im Controlling
🛡️ Nebenprozesse & Resilienz
  • Nachtragsmanagement bei unvorhergesehenen Mehraufwänden
  • Mängelrügen und Nacharbeiten vor endgültiger Schlussabnahme
  • Fahrzeuglager-Inventur und rollierende Bestandsauffüllung
  • Schnittstellenanbindung zu GAEB-Leistungsverzeichnissen (Bauabrechnung)
💡 No-Code Checkliste & Praxistipps
  • Stundensätze und Zuschläge (Überstunden, Nachtarbeit, Schmutzzulage) in Stammdaten pflegen
  • VOB/B-Vertragsoptionen je Projektkategorie aktivieren
  • Mobile Abnahmechecklisten für Techniker auf dem Tablet konfigurieren
  • No-Code Zusatzfelder für Bauleiter und Gewährleistungseinbehalt auf Project anlegen

🗄️ Data Models & Fields

TicketMessages ticket_messages RLS Aktiv
16 Fields / Columns

Tabelle ticket_messages

Feldname Data Type Required Schlüssel Functional Meaning
ticket_id UUID Ja * FK ➔ tickets.id Feld ticket_id
author_user_id UUID Nein FK ➔ users.id Feld author_user_id
author_name VARCHAR(255) Ja * - Feld author_name
author_email VARCHAR(255) Nein - Feld author_email
is_internal BOOLEAN Ja * - Feld is_internal
body TEXT Ja * - Feld body
attachments JSONB Nein - Feld attachments
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
TicketSlaPolicies ticket_sla_policies RLS Aktiv
16 Fields / Columns

Tabelle ticket_sla_policies

Feldname Data Type Required Schlüssel Functional Meaning
name VARCHAR(128) Ja * - Feld name
description TEXT Nein - Feld description
team_id UUID Nein FK ➔ ticket_teams.id Feld team_id
priority VARCHAR(16) Nein - Feld priority
target_response_hours NUMERIC(6, 2) Ja * - Feld target_response_hours
target_resolution_hours NUMERIC(6, 2) Ja * - Feld target_resolution_hours
is_active BOOLEAN Ja * - Feld is_active
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
TicketTeams ticket_teams RLS Aktiv
17 Fields / Columns

Tabelle ticket_teams

Feldname Data Type Required Schlüssel Functional Meaning
name VARCHAR(128) Ja * - Feld name
code VARCHAR(32) Ja * - Feld code
description TEXT Nein - Feld description
email_alias VARCHAR(128) Nein - Feld email_alias
assignment_method VARCHAR(32) Ja * - Feld assignment_method
lead_user_id UUID Nein FK ➔ users.id Feld lead_user_id
is_active BOOLEAN Ja * - Feld is_active
color VARCHAR(16) Ja * - Feld color
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
TicketTimeLogs ticket_time_logs RLS Aktiv
15 Fields / Columns

Tabelle ticket_time_logs

Feldname Data Type Required Schlüssel Functional Meaning
ticket_id UUID Ja * FK ➔ tickets.id Feld ticket_id
user_id UUID Nein FK ➔ users.id Feld user_id
work_date DATE Ja * - Feld work_date
hours NUMERIC(6, 2) Ja * - Feld hours
is_billable BOOLEAN Ja * - Feld is_billable
description TEXT Nein - Feld description
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
Tickets tickets RLS Aktiv
49 Fields / Columns

Tabelle tickets

Feldname Data Type Required Schlüssel Functional Meaning
ticket_number VARCHAR(32) Ja * - Feld ticket_number
title VARCHAR(255) Ja * - Feld title
description TEXT Nein - Feld description
status VARCHAR(48) Ja * - Feld status
priority VARCHAR(48) Ja * - Feld priority
category VARCHAR(48) Ja * - Feld category
channel VARCHAR(48) Ja * - Feld channel
team_id UUID Nein FK ➔ ticket_teams.id Feld team_id
assigned_user_id UUID Nein FK ➔ users.id Feld assigned_user_id
customer_id UUID Nein FK ➔ customers.id Feld customer_id
contact_name VARCHAR(255) Nein - Feld contact_name
contact_email VARCHAR(255) Nein - Feld contact_email
contact_phone VARCHAR(64) Nein - Feld contact_phone
project_id UUID Nein FK ➔ projects.id Feld project_id
work_order_id UUID Nein FK ➔ work_orders.id Feld work_order_id
contract_id UUID Nein FK ➔ contracts.id Feld contract_id
asset_id UUID Nein FK ➔ assets.id Feld asset_id
quote_id UUID Nein FK ➔ quotes.id Feld quote_id
invoice_id UUID Nein FK ➔ invoices.id Feld invoice_id
return_id UUID Nein FK ➔ return_orders.id Feld return_id
service_report_id UUID Nein FK ➔ service_reports.id Feld service_report_id
sla_policy_id UUID Nein FK ➔ ticket_sla_policies.id Feld sla_policy_id
sla_status VARCHAR(48) Ja * - Feld sla_status
response_due_at DATETIME Nein - Feld response_due_at
first_responded_at DATETIME Nein - Feld first_responded_at
resolution_due_at DATETIME Nein - Feld resolution_due_at
resolved_at DATETIME Nein - Feld resolved_at
closed_at DATETIME Nein - Feld closed_at
is_billable BOOLEAN Ja * - Feld is_billable
hourly_rate NUMERIC(14, 2) Nein - Feld hourly_rate
currency VARCHAR(3) Ja * - Feld currency
planned_hours NUMERIC(8, 2) Nein - Feld planned_hours
logged_hours NUMERIC(8, 2) Ja * - Feld logged_hours
csat_rating INTEGER Nein - Feld csat_rating
csat_comment TEXT Nein - Feld csat_comment
csat_submitted_at DATETIME Nein - Feld csat_submitted_at
resolution_summary TEXT Nein - Feld resolution_summary
tags JSONB Nein - Feld tags
custom_fields JSONB Nein - Feld custom_fields
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 GET /api/v1/tickets
list_tickets
Semantic binding: inventory_only; mutation=False
tickets
⚡ REST API GET /api/v1/tickets/sla-policies
list_sla_policies
Semantic binding: inventory_only; mutation=False
tickets
⚡ REST API GET /api/v1/tickets/stats
get_ticket_stats
Semantic binding: inventory_only; mutation=False
tickets
⚡ REST API GET /api/v1/tickets/teams
list_teams
Semantic binding: inventory_only; mutation=False
tickets
⚡ REST API GET /api/v1/tickets/{ticket_id}
get_ticket
Semantic binding: inventory_only; mutation=False
tickets
⚡ REST API GET /api/v1/tickets/{ticket_id}/messages
list_ticket_messages
Semantic binding: inventory_only; mutation=False
tickets
⚡ REST API GET /api/v1/tickets/{ticket_id}/timelogs
list_ticket_timelogs
Semantic binding: inventory_only; mutation=False
tickets
⚡ REST API GET /portal/{slug}/tickets
tickets_page
Semantic binding: inventory_only; mutation=False
tickets
⚡ REST API GET /portal/{slug}/tickets/{ticket_id}
ticket_detail
Semantic binding: inventory_only; mutation=False
tickets
⚡ REST API GET /tickets
tickets_page
Semantic binding: inventory_only; mutation=False
tickets
⚡ REST API GET /tickets/new
ticket_create_page
Semantic binding: inventory_only; mutation=False
tickets
⚡ REST API GET /tickets/{ticket_id}
ticket_detail_page
Semantic binding: inventory_only; mutation=False
tickets
⚡ REST API PATCH /api/v1/tickets/teams/{team_id}
update_team
Semantic binding: operator_surface; mutation=True
tickets
⚡ REST API POST /api/v1/tickets
create_ticket
Semantic binding: operator_surface; mutation=True
tickets
⚡ REST API POST /api/v1/tickets/sla-policies
create_sla_policy
Semantic binding: operator_surface; mutation=True
tickets
⚡ REST API POST /api/v1/tickets/teams
create_team
Semantic binding: operator_surface; mutation=True
tickets
⚡ REST API POST /api/v1/tickets/{ticket_id}/create-project
create_project_from_ticket
Semantic binding: operator_surface; mutation=True
tickets
⚡ REST API POST /api/v1/tickets/{ticket_id}/create-task
create_task_from_ticket
Semantic binding: operator_surface; mutation=True
tickets
⚡ REST API POST /api/v1/tickets/{ticket_id}/create-work-order
create_work_order_from_ticket
Semantic binding: operator_surface; mutation=True
tickets
⚡ REST API POST /api/v1/tickets/{ticket_id}/csat
submit_ticket_csat
Semantic binding: operator_surface; mutation=True
tickets
⚡ REST API POST /api/v1/tickets/{ticket_id}/messages
add_ticket_message
Semantic binding: operator_surface; mutation=True
tickets
⚡ REST API POST /api/v1/tickets/{ticket_id}/status
transition_ticket_status
Semantic binding: operator_surface; mutation=True
tickets
⚡ REST API POST /api/v1/tickets/{ticket_id}/timelogs
log_ticket_time
Semantic binding: operator_surface; mutation=True
tickets
⚡ REST API POST /portal/{slug}/tickets
ticket_create
Semantic binding: operator_surface; mutation=True
tickets
⚡ REST API POST /portal/{slug}/tickets/{ticket_id}/abschliessen
ticket_close
Semantic binding: operator_surface; mutation=True
tickets
⚡ REST API POST /portal/{slug}/tickets/{ticket_id}/antwort
ticket_reply
Semantic binding: operator_surface; mutation=True
tickets
⚡ REST API PUT /api/v1/tickets/{ticket_id}
update_ticket
Semantic binding: operator_surface; mutation=True
tickets

🛡️ Regulatory & Compliance

Dieses Modul unterliegt folgenden gesetzlichen, regulatorischen und Revisionsstandards:

  • ITIL Service Operation
  • SLA Fristenüberwachung
Related Modules:
➔ customers ➔ portal ➔ workorders