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 / crm_office / Aufgabenmanagement
📘

Aufgabenmanagement

tasks crm_office 🛡️ RLS Protected

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

Fachliche Bestimmung: Projekte, Arbeitsaufträge & Außendienst steuert die operative Dienstleistung und Projektabwicklung: Projektstrukturpläne (PSP) mit Phasen und Meilensteinen nach VOB/B und DIN 69901, Disposition mobiler Techniker, mobile Zeiterfassung und Materialentnahme aus Fahrzeuglagern vor Ort, rechtssichere digitale Abnahmeprotokolle mit Kundensignatur und lückenlose Übergabe an Abschlags-, Teil- und Schlussrechnungen.
Fachprozess-Erzählung & KI-Architektur Workflows & Lifecycles (10) Fachprozesse & Capabilities (35) Data Models & Fields (3) Entry Points (UI & APIs) (28) Regulatory & Compliance

⚡ Workflows & Lifecycles

Vertragslebenszyklus cascade:business.contract.lifecycle

Kaskade (review_gated).

1. contract
Vertrag anlegen
contracts
Aktionen: contract.create
2. task
Fristen / Kündigungsüberwachung
tasks
Aktionen: create_task

Korrespondenz → CRM cascade:business.correspondence.crm

Kaskade (review_gated).

1. lead
CRM-Lead / Anfrage anlegen
crm
Aktionen: crm.lead.create
2. task
Anfrage nachfassen
tasks
Aktionen: create_task

Kundenauftrag → Abwicklung cascade:business.customer_order.fulfill

Kaskade (review_gated).

1. order
Verkaufsauftrag anlegen / bestätigen
sales
Aktionen: sales.create
2. issue
Warenausgang als Entwurf buchen
inventory
Aktionen: stock.issue.create
3. tour
Auslieferungstour einplanen
logistics
Aktionen: create_tour
4. project
Projekt / Kostenstelle zuordnen
projects
Aktionen: link_project
5. task
Auftrag ausführen / abrechnen
tasks
Aktionen: create_task

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

Auftragsbestätigung prüfen cascade:business.order_confirmation.check

Kaskade (review_gated).

1. match
AB ↔ Bestellung abgleichen
purchasing
Aktionen: order_confirmation.match
2. project
Projekt / Kostenstelle zuordnen
projects
Aktionen: link_project
3. task
Liefertermin / Preise überwachen
tasks
Aktionen: create_task

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

Eingangsrechnung → Abrechnung cascade:business.supplier_invoice.p2p

Kaskade (review_gated).

1. booking
Buchungssatz erstellen
accounting
Aktionen: accounting.entry
2. project
Projektkosten verbuchen
projects
Aktionen: link_project
3. task
Frist / Skonto überwachen
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

Aufgabe / Wiedervorlage cascade_target:business.task.followup

Kaskade (review_gated).

1. cascade
Aufgabe / Wiedervorlage

Aufgabe status:task

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

1. todo
todo
Status «todo» der Zustandsmaschine Aufgabe.
2. open
open
Status «open» der Zustandsmaschine Aufgabe.
3. in_progress
in_progress
Status «in_progress» der Zustandsmaschine Aufgabe.
4. blocked
blocked
Status «blocked» der Zustandsmaschine Aufgabe.
5. review
review
Status «review» der Zustandsmaschine Aufgabe.
6. done
done
Status «done» der Zustandsmaschine Aufgabe.
7. cancelled
cancelled
Status «cancelled» der Zustandsmaschine Aufgabe.

⚙️ Fachprozesse & Capabilities (System-Fachlogik)

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

Gesamt: 35 manual_entry: 1 reviewed: 1 engine: 22 review_gated: 9 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
Aufgabe / Wiedervorlage capability:create_task
Op: create_task
Objekt: task
Quelle: code:capability_registry
reviewed
🔒 Freigabe nötig Risiko: business_record
  • cascade:business.task.followup
Für jedes Ticket eine Folgeaufgabe anlegen capability:sales_order.ticket.create_followup_task
Op: sales_order.ticket.create_followup_task
Objekt: sales_order
Quelle: code:capability_registry
⚙️ Engine
✓ Auto Risiko: business_record
  • task.created
Aufgabe zuweisen capability:task.assign
Op: task.assign
Intent: assign_task
Quelle: code:capability_registry
⚙️ Engine
✓ Auto Risiko: business_record
  • task.assigned
Checklistenpunkt capability:task.checklist.complete_item
Op: task.checklist.complete_item
Objekt: task
Quelle: code:capability_registry
⚙️ Engine
✓ Auto Risiko: business_record
  • task.checklist.complete_item
Aufgabe blockieren capability:task.dependency.block
Op: task.dependency.block
Objekt: task
Quelle: code:capability_registry
⚙️ Engine
✓ Auto Risiko: business_record
  • task.dependency.block
Wiederkehrende Aufgabe capability:task.recurring.spawn
Op: task.recurring.spawn
Objekt: task
Quelle: code:capability_registry
⚙️ Engine
✓ Auto Risiko: business_record
  • task.recurring.spawn
Aufgabenstatus setzen capability:task.transition
Op: task.transition
Intent: update_task
Quelle: code:capability_registry
⚙️ Engine
✓ Auto Risiko: business_record
  • task.status
Task: add checklist item capability:tasks.task.add_checklist_item
Op: tasks.task.add_checklist_item
Objekt: task
Quelle: code:capability_registry
⚙️ Engine
✓ Auto Risiko: business_record
  • task.add_checklist_item
Task: add dependency capability:tasks.task.add_dependency
Op: tasks.task.add_dependency
Objekt: task
Quelle: code:capability_registry
⚙️ Engine
✓ Auto Risiko: business_record
  • task.add_dependency
Task: assign capability:tasks.task.assign
Op: tasks.task.assign
Objekt: task
Quelle: code:capability_registry
⚙️ Engine
✓ Auto Risiko: business_record
  • task.assign
Task: cancel capability:tasks.task.cancel
Op: tasks.task.cancel
Objekt: task
Quelle: code:capability_registry
⚙️ Engine
✓ Auto Risiko: business_record
  • task.cancel
Task: cancel for context capability:tasks.task.cancel_for_context
Op: tasks.task.cancel_for_context
Objekt: task
Quelle: code:capability_registry
⚙️ Engine
✓ Auto Risiko: business_record
  • task.cancel_for_context
Task: cancel for entity capability:tasks.task.cancel_for_entity
Op: tasks.task.cancel_for_entity
Objekt: task
Quelle: code:capability_registry
⚙️ Engine
✓ Auto Risiko: business_record
  • task.cancel_for_entity
Task: complete capability:tasks.task.complete
Op: tasks.task.complete
Objekt: task
Quelle: code:capability_registry
⚙️ Engine
✓ Auto Risiko: business_record
  • task.complete
Task: complete for context capability:tasks.task.complete_for_context
Op: tasks.task.complete_for_context
Objekt: task
Quelle: code:capability_registry
⚙️ Engine
✓ Auto Risiko: business_record
  • task.complete_for_context
Task: complete for entity capability:tasks.task.complete_for_entity
Op: tasks.task.complete_for_entity
Objekt: task
Quelle: code:capability_registry
⚙️ Engine
✓ Auto Risiko: business_record
  • task.complete_for_entity
Task: create capability:tasks.task.create
Op: tasks.task.create
Objekt: task
Quelle: code:capability_registry
⚙️ Engine
✓ Auto Risiko: business_record
  • task.create
Task: delete capability:tasks.task.delete
Op: tasks.task.delete
Objekt: task
Quelle: code:capability_registry
⚙️ Engine
✓ Auto Risiko: business_record
  • task.delete
Task: delete checklist item capability:tasks.task.delete_checklist_item
Op: tasks.task.delete_checklist_item
Objekt: task
Quelle: code:capability_registry
⚙️ Engine
✓ Auto Risiko: business_record
  • task.delete_checklist_item
Task: remove dependency capability:tasks.task.remove_dependency
Op: tasks.task.remove_dependency
Objekt: task
Quelle: code:capability_registry
⚙️ Engine
✓ Auto Risiko: business_record
  • task.remove_dependency
Task: update checklist item capability:tasks.task.update_checklist_item
Op: tasks.task.update_checklist_item
Objekt: task
Quelle: code:capability_registry
⚙️ Engine
✓ Auto Risiko: business_record
  • task.update_checklist_item
Task: update status capability:tasks.task.update_status
Op: tasks.task.update_status
Objekt: task
Quelle: code:capability_registry
⚙️ Engine
✓ Auto Risiko: business_record
  • task.update_status
Task: update task capability:tasks.task.update_task
Op: tasks.task.update_task
Objekt: task
Quelle: code:capability_registry
⚙️ Engine
✓ Auto Risiko: business_record
  • task.update_task
Vertragslebenszyklus cascade:business.contract.lifecycle
Vertragslebenszyklus
Quelle: code:cascade_process
review_gated
✓ Auto
Keine Seiteneffekte deklariert
Korrespondenz → CRM cascade:business.correspondence.crm
Korrespondenz → CRM
Quelle: code:cascade_process
review_gated
✓ Auto
Keine Seiteneffekte deklariert
Kundenauftrag → Abwicklung cascade:business.customer_order.fulfill
Kundenauftrag → Abwicklung
Quelle: code:cascade_process
review_gated
✓ Auto
Keine Seiteneffekte deklariert
Lieferschein-Vollverarbeitung cascade:business.delivery_note.intake
Lieferschein-Vollverarbeitung
Quelle: code:cascade_process
review_gated
✓ Auto
Keine Seiteneffekte deklariert
Auftragsbestätigung prüfen cascade:business.order_confirmation.check
Auftragsbestätigung prüfen
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
Eingangsrechnung → Abrechnung cascade:business.supplier_invoice.p2p
Eingangsrechnung → Abrechnung
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
Aufgabe / Wiedervorlage cascade_target:business.task.followup
Op: create_task
Aufgabe / Wiedervorlage
Quelle: code:cascade_target
review_gated
🔒 Freigabe nötig
Keine Seiteneffekte deklariert
task: edit form form_surface_anchor:task.edit
Objekt: task
Quelle: code:erp_form_surface
operator_surface
✓ Auto
Keine Seiteneffekte deklariert
Aufgabe status:task
Objekt: task
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 tasks

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:

  • apqc-pcf-8.0, APQC Process Classification Framework (PCF) – Cross-Industry, Ausgabe PCF Cross-Industry v8.0 (2026-02-27). Art: reference_process. Nur öffentliche Zusammenfassung. Keine Volltextprüfung. Keine modulspezifische Kataloganforderung. Die Zuordnung bleibt eine Prüfreferenz.

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

TaskChecklistItems task_checklist_items RLS Aktiv
12 Fields / Columns

Tabelle task_checklist_items

Feldname Data Type Required Schlüssel Functional Meaning
task_id UUID Ja * FK ➔ tasks.id Feld task_id
title VARCHAR(255) Ja * - Feld title
is_done BOOLEAN Ja * - Feld is_done
position INTEGER Ja * - Feld position
assigned_user_id UUID Nein FK ➔ users.id Feld assigned_user_id
completed_at DATETIME Nein - Feld completed_at
completed_by UUID Nein FK ➔ users.id Feld completed_by
id UUID Nein PK Feld id
tenant_id UUID Ja * FK ➔ organizations.id Feld tenant_id
created_at DATETIME Ja * - Feld created_at
updated_at DATETIME Ja * - Feld updated_at
metadata JSONB Ja * - Feld metadata
TaskDependencies task_dependencies RLS Aktiv
11 Fields / Columns

Tabelle task_dependencies

Feldname Data Type Required Schlüssel Functional Meaning
task_id UUID Ja * FK ➔ tasks.id Feld task_id
predecessor_id UUID Ja * FK ➔ tasks.id Feld predecessor_id
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
Tasks tasks RLS Aktiv
32 Fields / Columns

Tabelle tasks

Feldname Data Type Required Schlüssel Functional Meaning
title VARCHAR(255) Ja * - Feld title
description TEXT Nein - Feld description
status VARCHAR(48) Ja * - Feld status
priority VARCHAR(48) Ja * - Feld priority
due_at DATETIME Nein - Feld due_at
started_at DATETIME Nein - Feld started_at
completed_at DATETIME Nein - Feld completed_at
estimated_hours NUMERIC(14, 2) Nein - Feld estimated_hours
logged_hours NUMERIC(14, 2) Nein - Feld logged_hours
tags JSONB Nein - Feld tags
assigned_user_id UUID Nein FK ➔ users.id Feld assigned_user_id
customer_id UUID Nein FK ➔ customers.id Feld customer_id
project_id UUID Nein FK ➔ projects.id Feld project_id
work_order_id UUID Nein FK ➔ work_orders.id Feld work_order_id
asset_id UUID Nein FK ➔ assets.id Feld asset_id
ticket_id UUID Nein FK ➔ tickets.id Feld ticket_id
milestone_id UUID Nein FK ➔ project_milestones.id Feld milestone_id
entity_type VARCHAR(64) Nein - Feld entity_type
entity_id UUID Nein - Feld entity_id
action_url VARCHAR(512) Nein - Feld action_url
created_by_agent VARCHAR(64) Nein - Feld created_by_agent
source_event_id UUID Nein - Feld source_event_id
idempotency_key VARCHAR(128) Nein - Feld idempotency_key
id UUID Nein PK Feld id
tenant_id UUID Ja * FK ➔ organizations.id Feld tenant_id
created_at DATETIME Ja * - Feld created_at
updated_at DATETIME Ja * - Feld updated_at
created_by UUID Nein - Feld created_by
updated_by UUID Nein - Feld updated_by
source_type VARCHAR(32) Nein - Feld source_type
source_id UUID Nein - Feld source_id
metadata JSONB Ja * - Feld metadata

🔌 Entry Points (UI & APIs)

Art Method Endpoint / Path Titel & Zweck Required Role
⚡ REST API DELETE /api/v1/tasks/checklist/{item_id}
delete_checklist_item
Semantic binding: operator_surface; mutation=True
 tasks
⚡ REST API DELETE /api/v1/tasks/{task_id}
delete_task
Semantic binding: operator_surface; mutation=True
 tasks
⚡ REST API DELETE /api/v1/tasks/{task_id}/dependencies/{predecessor_id}
remove_dependency
Semantic binding: operator_surface; mutation=True
 tasks
⚡ REST API GET /api/v1/tasks
list_tasks
Semantic binding: inventory_only; mutation=False
 tasks
⚡ REST API GET /api/v1/tasks/board
get_task_board
Semantic binding: inventory_only; mutation=False
 tasks
⚡ REST API GET /api/v1/tasks/context/{entity_type}/{entity_id}
list_tasks_for_context
Semantic binding: inventory_only; mutation=False
 tasks
⚡ REST API GET /api/v1/tasks/count
open_count
Semantic binding: inventory_only; mutation=False
 tasks
⚡ REST API GET /api/v1/tasks/my
my_tasks
Semantic binding: inventory_only; mutation=False
 tasks
⚡ REST API GET /api/v1/tasks/{task_id}
get_task
Semantic binding: inventory_only; mutation=False
 tasks
⚡ REST API GET /api/v1/tasks/{task_id}/dependencies
list_dependencies
Semantic binding: inventory_only; mutation=False
 tasks
⚡ REST API GET /aufgaben
tasks_page
Semantic binding: inventory_only; mutation=False
 tasks
⚡ REST API GET /aufgaben/neu
task_create_page
Semantic binding: inventory_only; mutation=False
 tasks
⚡ REST API GET /aufgaben/{task_id}
task_detail_page
Semantic binding: inventory_only; mutation=False
 tasks
⚡ REST API GET /tasks
tasks_page
Semantic binding: inventory_only; mutation=False
 tasks
⚡ REST API GET /tasks/new
task_create_page
Semantic binding: inventory_only; mutation=False
 tasks
⚡ REST API GET /tasks/{task_id}
task_detail_page
Semantic binding: inventory_only; mutation=False
 tasks
⚡ REST API PATCH /api/v1/tasks/checklist/{item_id}
update_checklist_item
Semantic binding: operator_surface; mutation=True
 tasks
⚡ REST API PATCH /api/v1/tasks/checklist/{item_id}/toggle
toggle_checklist_item
Semantic binding: operator_surface; mutation=True
 tasks
⚡ REST API PATCH /api/v1/tasks/{task_id}
update_task
Semantic binding: operator_surface; mutation=True
 tasks
⚡ REST API PATCH /api/v1/tasks/{task_id}/status
update_task_status
Semantic binding: operator_surface; mutation=True
 tasks
⚡ REST API POST /api/v1/tasks
create_task
Semantic binding: operator_surface; mutation=True
 tasks
⚡ REST API POST /api/v1/tasks/context/{entity_type}/{entity_id}
create_task_for_context
Semantic binding: operator_surface; mutation=True
 tasks
⚡ REST API POST /api/v1/tasks/{task_id}/assign
assign_task
Semantic binding: operator_surface; mutation=True
 tasks
⚡ REST API POST /api/v1/tasks/{task_id}/cancel
cancel_task
Semantic binding: operator_surface; mutation=True
 tasks
⚡ REST API POST /api/v1/tasks/{task_id}/checklist
add_checklist_item
Semantic binding: operator_surface; mutation=True
 tasks
⚡ REST API POST /api/v1/tasks/{task_id}/complete
complete_task
Semantic binding: operator_surface; mutation=True
 tasks
⚡ REST API POST /api/v1/tasks/{task_id}/dependencies
add_dependency
Semantic binding: operator_surface; mutation=True
 tasks
⚡ REST API POST /api/v1/tasks/{task_id}/log-time
log_task_time
Semantic binding: operator_surface; mutation=True
 tasks

🛡️ Regulatory & Compliance

Dieses Modul unterliegt folgenden gesetzlichen, regulatorischen und Revisionsstandards:

  • GoBD Nachvollziehbarkeit
  • Mandanten-Isolation (PostgreSQL RLS)