Centurio System & Module Documentation
🔍
🏛️ Platform Architecture
🇩🇪 Deutsch 🇬🇧 English 🇫🇷 Français 🇪🇸 Español 🇮🇹 Italiano 🇳🇱 Nederlands 🇵🇱 Polski 🇵🇹 Português 🇨🇿 Čeština 🇸🇰 Slovenčina 🇭🇺 Magyar 🇷🇴 Română 🇧🇬 Български 🇬🇷 Ελληνικά 🇩🇰 Dansk 🇫🇮 Suomi 🇸🇪 Svenska 🇱🇹 Lietuvių 🇱🇻 Latviešu 🇪🇪 Eesti 🇭🇷 Hrvatski 🇸🇮 Slovenščina 🇲🇹 Malti 🇮🇪 Gaeilge 🇷🇺 Русский 🇺🇦 Українська 🇹🇷 Türkçe 🇳🇴 Norsk bokmål 🇷🇸 Српски 🇮🇸 Íslenska 🇨🇭 Schwiiz/Suisse 🇹🇲 Türkmençe
🔑 Login
All Modules / manufacturing_execution / Außendienst & Kundendienst
🚐

Außendienst & Kundendienst

fieldservice manufacturing_execution 🛡️ RLS Protected

Techniker-Einsatzplanung, Dispatch-Board, mobile Arbeitsberichte mit Fotodokumentation und digitaler Signatur.

Fachliche Bestimmung: Digitalisiert den mobilen Kundendienst. Disponenten planen Termine auf einem visuellen Dispatch-Board. Techniker sehen Aufträge auf Smartphones/Tablets, erfassen Arbeitszeiten und verbrauchtes Material, dokumentieren Schäden per Kamera und lassen den Kunden direkt auf dem Touchscreen unterschreiben. Der fertige Servicebericht wird sofort als PDF archiviert.
Fachprozess-Erzählung & KI-Architektur Workflows & Lifecycles (5) Fachprozesse & Capabilities (39) Data Models & Fields (1) Entry Points (UI & APIs) (53) Regulatory & Compliance

⚡ Workflows & Lifecycles

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

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

Außendienst / Servicebericht anlegen cascade_target:business.fieldservice.create

Kaskade (review_gated).

1. cascade
Außendienst / Servicebericht anlegen

Benutzerbefehl: field service agent plan:command_field_service_agent

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

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

Servicebericht status:service_report

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

1. draft
draft
Status «draft» der Zustandsmaschine Servicebericht.
2. scheduled
scheduled
Status «scheduled» der Zustandsmaschine Servicebericht.
3. en_route
en_route
Status «en_route» der Zustandsmaschine Servicebericht.
4. on_site
on_site
Status «on_site» der Zustandsmaschine Servicebericht.
5. in_progress
in_progress
Status «in_progress» der Zustandsmaschine Servicebericht.
6. completed
completed
Status «completed» der Zustandsmaschine Servicebericht.
7. cancelled
cancelled
Status «cancelled» der Zustandsmaschine Servicebericht.

⚙️ Fachprozesse & Capabilities (System-Fachlogik)

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

Gesamt: 39 manual_entry: 1 reviewed: 1 engine: 30 review_gated: 3 operator_surface: 1 engine_step: 1 durable_plan: 1 observable_only: 1
Capability & Schlüssel Fachliche Bezeichnung Ausführung / Coverage Risikostufe & Freigabe Effekte & Kaskaden
Agent-Einstieg field_service_agent agent_entry:field_service_agent
Agent-Einstieg field_service_agent
Quelle: code:module_agent_map
manual_entry
✓ Auto
Keine Seiteneffekte deklariert
Außendienst / Servicebericht anlegen capability:create_service_report
Op: create_service_report
Objekt: service_report
Quelle: code:capability_registry
reviewed
🔒 Freigabe nötig Risiko: business_record
  • cascade:business.fieldservice.create
Checkliste capability:fieldservice.checklist.from_template
Op: fieldservice.checklist.from_template
Objekt: service_report
Quelle: code:capability_registry
⚙️ Engine
✓ Auto Risiko: business_record
  • fieldservice.checklist.from_template
ETA senden capability:fieldservice.customer.notify_eta
Op: fieldservice.customer.notify_eta
Objekt: service_report
Quelle: code:capability_registry
⚙️ Engine
✓ Auto Risiko: business_record
  • fieldservice.customer.notify_eta
Field: add material capability:fieldservice.field.add_material
Op: fieldservice.field.add_material
Objekt: field
Quelle: code:capability_registry
⚙️ Engine
✓ Auto Risiko: business_record
  • field.add_material
Field: add photo capability:fieldservice.field.add_photo
Op: fieldservice.field.add_photo
Objekt: field
Quelle: code:capability_registry
⚙️ Engine
✓ Auto Risiko: business_record
  • field.add_photo
Field: add signature capability:fieldservice.field.add_signature
Op: fieldservice.field.add_signature
Objekt: field
Quelle: code:capability_registry
⚙️ Engine
✓ Auto Risiko: business_record
  • field.add_signature
Field: add time entry capability:fieldservice.field.add_time_entry
Op: fieldservice.field.add_time_entry
Objekt: field
Quelle: code:capability_registry
⚙️ Engine
✓ Auto Risiko: business_record
  • field.add_time_entry
Field: assign technician capability:fieldservice.field.assign_technician
Op: fieldservice.field.assign_technician
Objekt: field
Quelle: code:capability_registry
⚙️ Engine
✓ Auto Risiko: business_record
  • field.assign_technician
Field: cancel capability:fieldservice.field.cancel
Op: fieldservice.field.cancel
Objekt: field
Quelle: code:capability_registry
⚙️ Engine
✓ Auto Risiko: business_record
  • field.cancel
Field: complete capability:fieldservice.field.complete
Op: fieldservice.field.complete
Objekt: field
Quelle: code:capability_registry
⚙️ Engine
✓ Auto Risiko: business_record
  • field.complete
Field: complete validated capability:fieldservice.field.complete_validated
Op: fieldservice.field.complete_validated
Objekt: field
Quelle: code:capability_registry
⚙️ Engine
✓ Auto Risiko: business_record
  • field.complete_validated
Field: create capability:fieldservice.field.create
Op: fieldservice.field.create
Objekt: field
Quelle: code:capability_registry
⚙️ Engine
✓ Auto Risiko: business_record
  • field.create
Field: create checklist template capability:fieldservice.field.create_checklist_template
Op: fieldservice.field.create_checklist_template
Objekt: field
Quelle: code:capability_registry
⚙️ Engine
✓ Auto Risiko: business_record
  • field.create_checklist_template
Field: delete time entry capability:fieldservice.field.delete_time_entry
Op: fieldservice.field.delete_time_entry
Objekt: field
Quelle: code:capability_registry
⚙️ Engine
✓ Auto Risiko: business_record
  • field.delete_time_entry
Field: dispatch board capability:fieldservice.field.dispatch_board
Op: fieldservice.field.dispatch_board
Objekt: field
Quelle: code:capability_registry
⚙️ Engine
✓ Auto Risiko: business_record
  • field.dispatch_board
Field: update acceptance capability:fieldservice.field.update_acceptance
Op: fieldservice.field.update_acceptance
Objekt: field
Quelle: code:capability_registry
⚙️ Engine
✓ Auto Risiko: business_record
  • field.update_acceptance
Field: update checklist results capability:fieldservice.field.update_checklist_results
Op: fieldservice.field.update_checklist_results
Objekt: field
Quelle: code:capability_registry
⚙️ Engine
✓ Auto Risiko: business_record
  • field.update_checklist_results
Field: update status capability:fieldservice.field.update_status
Op: fieldservice.field.update_status
Objekt: field
Quelle: code:capability_registry
⚙️ Engine
✓ Auto Risiko: business_record
  • field.update_status
Field: update status validated capability:fieldservice.field.update_status_validated
Op: fieldservice.field.update_status_validated
Objekt: field
Quelle: code:capability_registry
⚙️ Engine
✓ Auto Risiko: business_record
  • field.update_status_validated
Field: update summary capability:fieldservice.field.update_summary
Op: fieldservice.field.update_summary
Objekt: field
Quelle: code:capability_registry
⚙️ Engine
✓ Auto Risiko: business_record
  • field.update_summary
Ersatzteil capability:fieldservice.parts.request
Op: fieldservice.parts.request
Objekt: service_report
Quelle: code:capability_registry
⚙️ Engine
✓ Auto Risiko: business_record
  • fieldservice.parts.request
Techniker zuweisen capability:fieldservice.report.assign_technician
Op: fieldservice.report.assign_technician
Objekt: service_report
Quelle: code:capability_registry
⚙️ Engine
✓ Auto Risiko: business_record
  • service_report.technician_assigned
Servicebericht stornieren capability:fieldservice.report.cancel
Op: fieldservice.report.cancel
Objekt: service_report
Quelle: code:capability_registry
⚙️ Engine
✓ Auto Risiko: business_record
  • service_report.cancelled
Servicebericht abschließen capability:fieldservice.report.complete
Op: fieldservice.report.complete
Objekt: service_report
Quelle: code:capability_registry
⚙️ Engine
🔒 Freigabe nötig Risiko: business_record
  • service_report.completed
Servicebericht anlegen capability:fieldservice.report.create
Op: fieldservice.report.create
Objekt: service_report
Quelle: code:capability_registry
⚙️ Engine
✓ Auto Risiko: business_record
  • service_report.created
SLA verlängern capability:fieldservice.sla.extend
Op: fieldservice.sla.extend
Objekt: service_report
Quelle: code:capability_registry
⚙️ Engine
✓ Auto Risiko: business_record
  • fieldservice.sla.extend
Serviceaufträge aus Vertrag erzeugen capability:generate_service_orders
Op: generate_service_orders
Intent: generate_service_orders
Quelle: code:capability_registry
⚙️ Engine
✓ Auto Risiko: business_record
  • engine:generate_service_orders
Servicebericht: Unterwegs capability:service_report.mark_en_route
Op: service_report.mark_en_route
Intent: update_service_report_status
Quelle: code:capability_registry
⚙️ Engine
✓ Auto Risiko: business_record
  • service_report.status.en_route
Servicebericht: Vor Ort capability:service_report.mark_on_site
Op: service_report.mark_on_site
Intent: update_service_report_status
Quelle: code:capability_registry
⚙️ Engine
✓ Auto Risiko: business_record
  • service_report.status.on_site
Servicebericht-Status wechseln capability:service_report.transition_status
Op: service_report.transition_status
Intent: update_service_report_status
Quelle: code:capability_registry
⚙️ Engine
✓ Auto Risiko: business_record
  • service_report.status_changed
Maschinen-Telemetrie erfassen capability:uip.telemetry.ingest
Op: uip.telemetry.ingest
Intent: ingest_machine_telemetry
Quelle: code:capability_registry
⚙️ Engine
✓ Auto Risiko: business_record
  • telemetry.reading_recorded
Wartung / Instandsetzung cascade:business.maintenance.cycle
Wartung / Instandsetzung
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
Außendienst / Servicebericht anlegen cascade_target:business.fieldservice.create
Op: create_service_report
Außendienst / Servicebericht anlegen
Quelle: code:cascade_target
review_gated
🔒 Freigabe nötig
Keine Seiteneffekte deklariert
service_report: edit form form_surface_anchor:service_report.edit
Objekt: service_report
Quelle: code:erp_form_surface
operator_surface
✓ Auto
Keine Seiteneffekte deklariert
Serviceaufträge aus Vertrag erzeugen gateway:service_order_generation
Op: generate_service_orders
Serviceaufträge aus Vertrag erzeugen
Quelle: code:reviewed_gateway
⚙️ Engine
✓ Auto
Keine Seiteneffekte deklariert
Benutzerbefehl: field service agent plan:command_field_service_agent
Benutzerbefehl: field service agent
Quelle: code:reviewed_execution_plan
durable_plan
✓ Auto
Keine Seiteneffekte deklariert
Servicebericht status:service_report
Objekt: service_report
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 fieldservice

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.
  • 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 55001. 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

ServiceReport service_reports RLS Aktiv
7 Fields / Columns

Digitale Serviceberichte mit Arbeitszeiten, Materialeinsatz und Kundenunterschrift.

Feldname Data Type Required Schlüssel Functional Meaning
id UUID Nein PK Berichts-ID
tenant_id UUID Nein - Mandanten-ID (RLS)
report_number VARCHAR(100) Ja * - Berichtsnummer
customer_id UUID Nein FK ➔ customers.id Kunde
technician_id UUID Nein FK ➔ users.id Ausführender Techniker
customer_signature TEXT Nein - Base64-kodierte Unterschrift
status VARCHAR(50) Nein - Status (draft, signed, invoiced)

🔌 Entry Points (UI & APIs)

Art Method Endpoint / Path Titel & Zweck Required Role
⚡ REST API DELETE /api/v1/field-service/reports/{report_id}/time-entries/{entry_id}
delete_time_entry
Semantic binding: operator_surface; mutation=True
 fieldservice
⚡ REST API GET /api/v1/field-service/checklist-templates
list_checklist_templates
Semantic binding: inventory_only; mutation=False
 fieldservice
⚡ REST API GET /api/v1/field-service/checklist-templates/{template_id}
get_checklist_template
Semantic binding: inventory_only; mutation=False
 fieldservice
⚡ REST API GET /api/v1/field-service/dispatch
dispatch_board
Semantic binding: inventory_only; mutation=False
 fieldservice
⚡ REST API GET /api/v1/field-service/my-reports
list_my_reports
Semantic binding: inventory_only; mutation=False
 fieldservice
⚡ REST API GET /api/v1/field-service/reports
list_reports
Semantic binding: inventory_only; mutation=False
 fieldservice
⚡ REST API GET /api/v1/field-service/reports/{report_id}
get_report
Semantic binding: inventory_only; mutation=False
 fieldservice
⚡ REST API GET /api/v1/field-service/reports/{report_id}/materials
list_materials
Semantic binding: inventory_only; mutation=False
 fieldservice
⚡ REST API GET /api/v1/field-service/reports/{report_id}/pdf
download_pdf
Semantic binding: inventory_only; mutation=False
 fieldservice
⚡ REST API GET /api/v1/field-service/reports/{report_id}/photos
list_photos
Semantic binding: inventory_only; mutation=False
 fieldservice
⚡ REST API GET /api/v1/field-service/reports/{report_id}/time-entries
list_time_entries
Semantic binding: inventory_only; mutation=False
 fieldservice
⚡ REST API GET /api/v1/field-service/reports/{report_id}/timer
get_timer
Semantic binding: inventory_only; mutation=False
 fieldservice
⚡ REST API GET /api/v1/field-service/timesheet
timesheet_csv
Semantic binding: inventory_only; mutation=False
 fieldservice
⚡ REST API GET /api/v1/field-service/timesheet/pdf
timesheet_pdf
Semantic binding: inventory_only; mutation=False
 fieldservice
⚡ REST API GET /aussendienst
fieldservice_page
Semantic binding: inventory_only; mutation=False
 fieldservice
⚡ REST API GET /aussendienst/dispatch
fieldservice_dispatch_page
Semantic binding: inventory_only; mutation=False
 fieldservice
⚡ REST API GET /aussendienst/meine-einsaetze
fieldservice_meine_page
Semantic binding: inventory_only; mutation=False
 fieldservice
⚡ REST API GET /aussendienst/neu
fieldservice_new_page
Semantic binding: inventory_only; mutation=False
 fieldservice
⚡ REST API GET /aussendienst/new
fieldservice_new_page
Semantic binding: inventory_only; mutation=False
 fieldservice
⚡ REST API GET /aussendienst/verwaltung
fieldservice_management_page
Semantic binding: inventory_only; mutation=False
 fieldservice
⚡ REST API GET /aussendienst/{report_id}
fieldservice_detail_page
Semantic binding: inventory_only; mutation=False
 fieldservice
⚡ REST API GET /aussendienst/{report_id}/edit
fieldservice_detail_page
Semantic binding: inventory_only; mutation=False
 fieldservice
⚡ REST API GET /fieldservice
fieldservice_page
Semantic binding: inventory_only; mutation=False
 fieldservice
⚡ REST API GET /fieldservice/dispatch
fieldservice_dispatch_page
Semantic binding: inventory_only; mutation=False
 fieldservice
⚡ REST API GET /fieldservice/meine
fieldservice_meine_page
Semantic binding: inventory_only; mutation=False
 fieldservice
⚡ REST API GET /fieldservice/new
fieldservice_new_page
Semantic binding: inventory_only; mutation=False
 fieldservice
⚡ REST API GET /fieldservice/verwaltung
fieldservice_management_page
Semantic binding: inventory_only; mutation=False
 fieldservice
⚡ REST API GET /portal/{slug}/serviceberichte
service_reports_page
Semantic binding: inventory_only; mutation=False
 fieldservice
⚡ REST API GET /portal/{slug}/serviceberichte/{report_id}/pdf
service_report_pdf_download
Semantic binding: inventory_only; mutation=False
 fieldservice
⚡ REST API PATCH /api/v1/field-service/reports/{report_id}
update_report
Semantic binding: operator_surface; mutation=True
 fieldservice
⚡ REST API POST /api/v1/field-service/checklist-templates
create_checklist_template
Semantic binding: operator_surface; mutation=True
 fieldservice
⚡ REST API POST /api/v1/field-service/reports
create_report
Semantic binding: operator_surface; mutation=True
 fieldservice
⚡ REST API POST /api/v1/field-service/reports/{report_id}/assign
assign_technician
Semantic binding: operator_surface; mutation=True
 fieldservice
⚡ REST API POST /api/v1/field-service/reports/{report_id}/cancel
cancel_report
Semantic binding: operator_surface; mutation=True
 fieldservice
⚡ REST API POST /api/v1/field-service/reports/{report_id}/complete
complete_report
Semantic binding: operator_surface; mutation=True
 fieldservice
⚡ REST API POST /api/v1/field-service/reports/{report_id}/complete-validated
complete_report_validated
Semantic binding: operator_surface; mutation=True
 fieldservice
⚡ REST API POST /api/v1/field-service/reports/{report_id}/documents
upload_report_document
Semantic binding: operator_surface; mutation=True
 fieldservice
⚡ REST API POST /api/v1/field-service/reports/{report_id}/email-pdf
email_pdf
Semantic binding: operator_surface; mutation=True
 fieldservice
⚡ REST API POST /api/v1/field-service/reports/{report_id}/escalate-ticket
escalate_report_to_ticket
Semantic binding: operator_surface; mutation=True
 fieldservice
⚡ REST API POST /api/v1/field-service/reports/{report_id}/material-pick
prepare_material_pick
Semantic binding: operator_surface; mutation=True
 fieldservice
⚡ REST API POST /api/v1/field-service/reports/{report_id}/materials
add_material
Semantic binding: operator_surface; mutation=True
 fieldservice
⚡ REST API POST /api/v1/field-service/reports/{report_id}/photos
upload_photo
Semantic binding: operator_surface; mutation=True
 fieldservice
⚡ REST API POST /api/v1/field-service/reports/{report_id}/signature
add_signature
Semantic binding: operator_surface; mutation=True
 fieldservice
⚡ REST API POST /api/v1/field-service/reports/{report_id}/status
update_status
Semantic binding: operator_surface; mutation=True
 fieldservice
⚡ REST API POST /api/v1/field-service/reports/{report_id}/status-validated
update_status_validated
Semantic binding: operator_surface; mutation=True
 fieldservice
⚡ REST API POST /api/v1/field-service/reports/{report_id}/time-entries
add_time_entry
Semantic binding: operator_surface; mutation=True
 fieldservice
⚡ REST API POST /api/v1/field-service/reports/{report_id}/timer/discard
discard_timer
Semantic binding: operator_surface; mutation=True
 fieldservice
⚡ REST API POST /api/v1/field-service/reports/{report_id}/timer/start
start_timer
Semantic binding: operator_surface; mutation=True
 fieldservice
⚡ REST API POST /api/v1/field-service/reports/{report_id}/timer/stop
stop_timer
Semantic binding: operator_surface; mutation=True
 fieldservice
⚡ REST API PUT /api/v1/field-service/reports/{report_id}/acceptance
update_acceptance
Semantic binding: operator_surface; mutation=True
 fieldservice
⚡ REST API PUT /api/v1/field-service/reports/{report_id}/checklist
update_checklist
Semantic binding: operator_surface; mutation=True
 fieldservice
⚡ REST API PUT /api/v1/field-service/reports/{report_id}/summary
update_summary
Semantic binding: operator_surface; mutation=True
 fieldservice
⚡ REST API POST /api/v1/fieldservice/reports
Bericht speichern
Speichert Servicebericht samt Zeiten und Unterschrift
 fieldservice:write

🛡️ Regulatory & Compliance

Dieses Modul unterliegt folgenden gesetzlichen, regulatorischen und Revisionsstandards:

  • GoBD Revisionssichere Dokumentenarchivierung
  • BGB Werkvertragsabnahme (§640)
Related Modules:
➔ workorders ➔ customers ➔ calendar ➔ finance