Centurio System & Module Documentation
🏛️ Platform Architecture 🔑 Login
All Modules / manufacturing_execution / Arbeitsaufträge & Werkstatt
🧰

Arbeitsaufträge & Werkstatt

workorders manufacturing_execution 🛡️ RLS Protected

Fertigungs- und Werkstattaufträge, Arbeitsschritte, Materialbedarfsermittlung (BOM) und Zeiterfassung.

Fachliche Bestimmung: Koordiniert die physische Ausführung in Werkstatt, Fertigung und Baustelle. Wird bei Angebotsannahme automatisch aus dem Angebot generiert. Hält Auftragspositionen und Stücklistenbedarfe vor (wobei Streckengeschäfte explizit von internem Materialbedarf ausgenommen sind). Ermöglicht Zeiterfassung, Statusfortschritt und Übergabe zur Abrechnung.

⚡ Workflows & Lifecycles

Werkstattauftrags-Abwicklung workorder_execution

Vom geplanten Auftrag über Arbeitsvorbereitung und Fertigung bis zur Abnahme.

stateDiagram-v2 [*] --> SCHEDULED: Aus Angebot konvertiert SCHEDULED --> IN_PROGRESS: Techniker startet Arbeit IN_PROGRESS --> QUALITY_CHECK: Montage beendet QUALITY_CHECK --> COMPLETED: Abnahme erfolgt COMPLETED --> [*]: Übergabe an Schlussrechnung
1. SCHEDULED
Eingeplant
Auftrag liegt vor, Ressourcen und Termine werden disponiert.
Aktionen: Materialreservierung prüfen
2. IN_PROGRESS
In Ausführung
Mitarbeiter startet die Bearbeitung und erfasst Arbeitszeiten.
Aktionen: Zeiterfassung buchen
3. QUALITY_CHECK
Qualitätskontrolle
Abschlussprüfung nach Werksnormen oder Kundenkriterien.
Aktionen: Prüfprotokoll hinterlegen
4. COMPLETED
Abgeschlossen
Auftrag fertiggestellt, Rückmeldung an Projekt und Abrechnung.
Aktionen: Fakturierung freischalten

Benutzerbefehl: extra work agent plan:command_extra_work_agent

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

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

Benutzerbefehl: site documentation agent plan:command_site_documentation_agent

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

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

Benutzerbefehl: time capture agent plan:command_time_capture_agent

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

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

Benutzerbefehl: unbilled work agent plan:command_unbilled_work_agent

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

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

Benutzerbefehl: work completion agent plan:command_work_completion_agent

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

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

Benutzerbefehl: workorder crud subagent plan:command_workorder_crud_subagent

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

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

Benutzerbefehl: workorder general agent plan:command_workorder_general_agent

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

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

Arbeitsauftrag abgeschlossen plan:unbilled_check

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

1. unbilled_work_agent
unbilled_work_agent
{"key": "step_0", "label": "Nicht abgerechnete Stunden finden", "adapter": "agent.execute", "agent": "unbilled_work_agent", "condition_fact": null}
Aktionen: unbilled_work_agent

Arbeitsauftrag als fertig gemeldet plan:work_completed

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

1. extra_work_agent
extra_work_agent
{"key": "step_0", "label": "Zusatzleistungen erkennen", "adapter": "agent.execute", "agent": "extra_work_agent", "condition_fact": null}
Aktionen: extra_work_agent
2. service_history_agent
service_history_agent
{"key": "step_1", "label": "Wartungseintrag fuer Anlage", "adapter": "agent.execute", "agent": "service_history_agent", "condition_fact": "asset_id"}
Aktionen: service_history_agent
3. billing_agent
billing_agent
{"key": "step_2", "label": "Rechnungsentwurf erstellen", "adapter": "agent.execute", "agent": "billing_agent", "condition_fact": "billable"}
Aktionen: billing_agent

Auftrag status:work_order

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

1. draft
draft
Status «draft» der Zustandsmaschine Auftrag.
2. scheduled
scheduled
Status «scheduled» der Zustandsmaschine Auftrag.
3. active
active
Status «active» der Zustandsmaschine Auftrag.
4. waiting_customer
waiting_customer
Status «waiting_customer» der Zustandsmaschine Auftrag.
5. waiting_vendor
waiting_vendor
Status «waiting_vendor» der Zustandsmaschine Auftrag.
6. completed
completed
Status «completed» der Zustandsmaschine Auftrag.
7. approved
approved
Status «approved» der Zustandsmaschine Auftrag.
8. invoiced
invoiced
Status «invoiced» der Zustandsmaschine Auftrag.
9. cancelled
cancelled
Status «cancelled» der Zustandsmaschine Auftrag.

⚙️ Fachprozesse & Capabilities (System-Fachlogik)

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

Gesamt: 26 manual_entry: 1 engine: 12 operator_surface: 2 engine_step: 1 durable_plan: 9 observable_only: 1
Capability & Schlüssel Fachliche Bezeichnung Ausführung / Coverage Risikostufe & Freigabe Effekte & Kaskaden
Agent-Einstieg workorder_crud_subagent agent_entry:workorder_crud_subagent
Agent-Einstieg workorder_crud_subagent
Quelle: code:module_agent_map
manual_entry
✓ Auto
Keine Seiteneffekte deklariert
Complete Work Order capability:complete_work_order
Op: complete_work_order
Objekt: work_order
Quelle: code:capability_registry
⚙️ Engine
✓ Auto Risiko: business_record
  • engine:complete_work_order
Auftrag abschließen capability:work_order.complete
Op: complete_work_order
Intent: complete_work_order
Quelle: code:capability_registry
⚙️ Engine
✓ Auto Risiko: business_record
  • work_order.status.completed
Arbeitsauftrag anlegen capability:work_order.create
Op: work_order.create
Intent: create_work_order
Quelle: code:capability_registry
⚙️ Engine
✓ Auto Risiko: business_record
  • work_order.created
Auftragsmaterial reservieren capability:workorder.material.reserve
Op: workorder.material.reserve
Objekt: work_order
Quelle: code:capability_registry
⚙️ Engine
✓ Auto Risiko: business_record
  • work_order.material_reserved
Termine optimieren capability:workorder.schedule.optimize
Op: workorder.schedule.optimize
Objekt: work_order
Quelle: code:capability_registry
⚙️ Engine
✓ Auto Risiko: business_record
  • workorder.schedule.optimize
Work Log: record capability:workorders.work_log.record
Op: workorders.work_log.record
Objekt: work_log
Quelle: code:capability_registry
⚙️ Engine
✓ Auto Risiko: business_record
  • work_log.record
Work Order: add item capability:workorders.work_order.add_item
Op: workorders.work_order.add_item
Objekt: work_order
Quelle: code:capability_registry
⚙️ Engine
✓ Auto Risiko: business_record
  • work_order.add_item
Work Order: cancel capability:workorders.work_order.cancel
Op: workorders.work_order.cancel
Objekt: work_order
Quelle: code:capability_registry
⚙️ Engine
✓ Auto Risiko: business_record
  • work_order.cancel
Work Order: complete capability:workorders.work_order.complete
Op: workorders.work_order.complete
Objekt: work_order
Quelle: code:capability_registry
⚙️ Engine
✓ Auto Risiko: business_record
  • work_order.complete
Work Order: create capability:workorders.work_order.create
Op: workorders.work_order.create
Objekt: work_order
Quelle: code:capability_registry
⚙️ Engine
✓ Auto Risiko: business_record
  • work_order.create
Work Order: delete item capability:workorders.work_order.delete_item
Op: workorders.work_order.delete_item
Objekt: work_order
Quelle: code:capability_registry
⚙️ Engine
✓ Auto Risiko: business_record
  • work_order.delete_item
Work Order: update item capability:workorders.work_order.update_item
Op: workorders.work_order.update_item
Objekt: work_order
Quelle: code:capability_registry
⚙️ Engine
✓ Auto Risiko: business_record
  • work_order.update_item
work_order: create form form_surface_anchor:work_order.create
Objekt: work_order
Quelle: code:erp_form_surface
operator_surface
✓ Auto
Keine Seiteneffekte deklariert
work_order: edit form form_surface_anchor:work_order.edit
Objekt: work_order
Quelle: code:erp_form_surface
operator_surface
✓ Auto
Keine Seiteneffekte deklariert
work order complete gateway:work_order_complete
Op: complete_work_order
work order complete
Quelle: code:engine_facade
⚙️ Engine
✓ Auto
Keine Seiteneffekte deklariert
Benutzerbefehl: extra work agent plan:command_extra_work_agent
Benutzerbefehl: extra work agent
Quelle: code:reviewed_execution_plan
durable_plan
✓ Auto
Keine Seiteneffekte deklariert
Benutzerbefehl: site documentation agent plan:command_site_documentation_agent
Benutzerbefehl: site documentation agent
Quelle: code:reviewed_execution_plan
durable_plan
✓ Auto
Keine Seiteneffekte deklariert
Benutzerbefehl: time capture agent plan:command_time_capture_agent
Benutzerbefehl: time capture agent
Quelle: code:reviewed_execution_plan
durable_plan
✓ Auto
Keine Seiteneffekte deklariert
Benutzerbefehl: unbilled work agent plan:command_unbilled_work_agent
Benutzerbefehl: unbilled work agent
Quelle: code:reviewed_execution_plan
durable_plan
✓ Auto
Keine Seiteneffekte deklariert
Benutzerbefehl: work completion agent plan:command_work_completion_agent
Benutzerbefehl: work completion agent
Quelle: code:reviewed_execution_plan
durable_plan
✓ Auto
Keine Seiteneffekte deklariert
Benutzerbefehl: workorder crud subagent plan:command_workorder_crud_subagent
Benutzerbefehl: workorder crud subagent
Quelle: code:reviewed_execution_plan
durable_plan
✓ Auto
Keine Seiteneffekte deklariert
Benutzerbefehl: workorder general agent plan:command_workorder_general_agent
Benutzerbefehl: workorder general agent
Quelle: code:reviewed_execution_plan
durable_plan
✓ Auto
Keine Seiteneffekte deklariert
Arbeitsauftrag abgeschlossen plan:unbilled_check
Arbeitsauftrag abgeschlossen
Quelle: code:reviewed_execution_plan
durable_plan
✓ Auto
Keine Seiteneffekte deklariert
Arbeitsauftrag als fertig gemeldet plan:work_completed
Arbeitsauftrag als fertig gemeldet
Quelle: code:reviewed_execution_plan
durable_plan
✓ Auto
Keine Seiteneffekte deklariert
Auftrag status:work_order
Objekt: work_order
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 workorders

Prüfkatalog Standards-Registry v2026.10.1. Dieser Abschnitt ordnet Prüfreferenzen zu und stellt nicht fest, dass das Modul eine Norm einhält; keine Kataloganforderung ist als PASS bewertet.

Geführte Prüfreferenzen:

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

Im Auditauftrag zusätzlich genannt und nicht im Prüfkatalog v2026.10.1: ISO 55001, EN 13306, EN 15341. 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

WorkLogs work_logs RLS Aktiv
16 Fields / Columns

Tabelle work_logs

Feldname Data Type Required Schlüssel Functional Meaning
work_order_id UUID Nein FK ➔ work_orders.id Feld work_order_id
project_id UUID Nein FK ➔ projects.id Feld project_id
user_id UUID Nein FK ➔ users.id Feld user_id
started_at DATETIME Nein - Feld started_at
ended_at DATETIME Nein - Feld ended_at
duration_minutes INTEGER Ja * - Feld duration_minutes
description TEXT Nein - Feld description
billable BOOLEAN Ja * - Feld billable
hourly_rate NUMERIC(14, 2) Nein - Feld hourly_rate
source VARCHAR(48) Ja * - Feld source
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
metadata JSONB Ja * - Feld metadata
WorkOrders work_orders RLS Aktiv
55 Fields / Columns

Tabelle work_orders

Feldname Data Type Required Schlüssel Functional Meaning
work_order_number VARCHAR(32) Ja * - Feld work_order_number
project_id UUID Nein FK ➔ projects.id Feld project_id
customer_id UUID Nein FK ➔ customers.id Feld customer_id
asset_id UUID Nein FK ➔ assets.id Feld asset_id
location_id UUID Nein FK ➔ locations.id Feld location_id
title VARCHAR(255) Ja * - Feld title
description TEXT Nein - Feld description
order_type VARCHAR(32) Ja * - Feld order_type
priority VARCHAR(16) Ja * - Feld priority
contract_id UUID Nein - Feld contract_id
ticket_id UUID Nein FK ➔ tickets.id Feld ticket_id
status VARCHAR(48) Ja * - Feld status
scheduled_start DATETIME Nein - Feld scheduled_start
scheduled_end DATETIME Nein - Feld scheduled_end
started_at DATETIME Nein - Feld started_at
completed_at DATETIME Nein - Feld completed_at
assigned_user_id UUID Nein FK ➔ users.id Feld assigned_user_id
customer_signature_document_id UUID Nein FK ➔ documents.id Feld customer_signature_document_id
completion_summary TEXT Nein - Feld completion_summary
billable BOOLEAN Ja * - Feld billable
currency VARCHAR(3) Ja * - Feld currency
subtotal NUMERIC(14, 2) Ja * - Feld subtotal
tax_total NUMERIC(14, 2) Ja * - Feld tax_total
total NUMERIC(14, 2) Ja * - Feld total
invoice_policy VARCHAR(12) Ja * - Feld invoice_policy
invoice_status VARCHAR(12) Ja * - Feld invoice_status
invoice_customer_id UUID Nein FK ➔ customers.id Feld invoice_customer_id
payment_terms VARCHAR(128) Nein - Feld payment_terms
payment_term_code VARCHAR(32) Nein - Feld payment_term_code
payment_term_days INTEGER Nein - Feld payment_term_days
skonto_days INTEGER Nein - Feld skonto_days
skonto_percent NUMERIC(5, 2) Nein - Feld skonto_percent
customer_reference VARCHAR(128) Nein - Feld customer_reference
cost_center VARCHAR(64) Nein - Feld cost_center
cost_object VARCHAR(64) Nein - Feld cost_object
tax_exemption_reason VARCHAR(255) Nein - Feld tax_exemption_reason
prepayment_percent NUMERIC(5, 2) Nein - Feld prepayment_percent
invoice_note TEXT Nein - Feld invoice_note
delivery_address TEXT Nein - Feld delivery_address
delivery_method VARCHAR(64) Nein - Feld delivery_method
delivery_note TEXT Nein - Feld delivery_note
incoterm VARCHAR(16) Nein - Feld incoterm
incoterm_place VARCHAR(128) Nein - Feld incoterm_place
carrier VARCHAR(128) Nein - Feld carrier
tracking_number VARCHAR(128) Nein - Feld tracking_number
semantic_attributes JSONB Nein - Feld semantic_attributes
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/workorders/{work_order_id}/items/{item_id}
delete_workorder_item
Semantic binding: operator_surface; mutation=True
workorders
⚡ REST API GET /api/v1/extra-work/projects/{project_id}/open
list_open_for_project
Semantic binding: inventory_only; mutation=False
workorders
⚡ REST API GET /api/v1/jobflow/projects/{project_id}/flow
project_flow
Semantic binding: inventory_only; mutation=False
workorders
⚡ REST API GET /api/v1/jobflow/reports/{report_id}/briefing
visit_briefing
Semantic binding: inventory_only; mutation=False
workorders
⚡ REST API GET /api/v1/jobflow/reports/{report_id}/flow
report_flow
Semantic binding: inventory_only; mutation=False
workorders
⚡ REST API GET /api/v1/jobflow/staff
staff
Semantic binding: inventory_only; mutation=False
workorders
⚡ REST API GET /api/v1/jobflow/work-orders/{work_order_id}/dossier/download
download_latest_dossier
Semantic binding: inventory_only; mutation=False
workorders
⚡ REST API GET /api/v1/jobflow/work-orders/{work_order_id}/dossier/versions
dossier_versions
Semantic binding: inventory_only; mutation=False
workorders
⚡ REST API GET /api/v1/jobflow/work-orders/{work_order_id}/dossier/{document_id}
download_dossier_version
Semantic binding: inventory_only; mutation=False
workorders
⚡ REST API GET /api/v1/jobflow/work-orders/{work_order_id}/flow
work_order_flow
Semantic binding: inventory_only; mutation=False
workorders
⚡ REST API GET /api/v1/workorders
list_workorders
Semantic binding: inventory_only; mutation=False
workorders
⚡ REST API GET /api/v1/workorders/stats
workorder_stats
Semantic binding: inventory_only; mutation=False
workorders
⚡ REST API GET /api/v1/workorders/{work_order_id}
get_workorder
Semantic binding: inventory_only; mutation=False
workorders
⚡ REST API GET /api/v1/workorders/{work_order_id}/compatible-parts
workorder_compatible_parts
Semantic binding: inventory_only; mutation=False
workorders
⚡ REST API GET /api/v1/workorders/{work_order_id}/delivery-note.pdf
work_order_delivery_note
Semantic binding: inventory_only; mutation=False
workorders
⚡ REST API GET /api/v1/workorders/{work_order_id}/invoicing
order_invoicing_overview
Semantic binding: inventory_only; mutation=False
workorders
⚡ REST API GET /api/v1/workorders/{work_order_id}/items
list_workorder_items
Semantic binding: inventory_only; mutation=False
workorders
⚡ REST API GET /api/v1/workorders/{work_order_id}/logs
list_worklogs
Semantic binding: inventory_only; mutation=False
workorders
⚡ REST API GET /api/v1/workorders/{work_order_id}/material-requirements
list_material_requirements
Semantic binding: inventory_only; mutation=False
workorders
⚡ REST API GET /api/v1/workorders/{work_order_id}/materials
list_materials
Semantic binding: inventory_only; mutation=False
workorders
⚡ REST API GET /portal/{slug}/auftraege
workorders_page
Semantic binding: inventory_only; mutation=False
workorders
⚡ REST API GET /workorders
workorders_page
Semantic binding: inventory_only; mutation=False
workorders
⚡ REST API GET /workorders/new
workorders_new_page
Semantic binding: inventory_only; mutation=False
workorders
⚡ REST API GET /workorders/{work_order_id}
workorder_detail_page
Semantic binding: inventory_only; mutation=False
workorders
⚡ REST API GET /workorders/{work_order_id}/edit
workorder_detail_page
Semantic binding: inventory_only; mutation=False
workorders
⚡ REST API PATCH /api/v1/workorders/{work_order_id}
update_workorder
Semantic binding: operator_surface; mutation=True
workorders
⚡ REST API PATCH /api/v1/workorders/{work_order_id}/items/{item_id}
update_workorder_item
Semantic binding: operator_surface; mutation=True
workorders
⚡ REST API POST /api/v1/extra-work/{candidate_id}/decide
decide
Semantic binding: operator_surface; mutation=True
workorders
⚡ REST API POST /api/v1/extra-work/{candidate_id}/invoiced
mark_invoiced
Semantic binding: operator_surface; mutation=True
workorders
⚡ REST API POST /api/v1/extra-work/{candidate_id}/quote
create_change_quote
Semantic binding: operator_surface; mutation=True
workorders
⚡ REST API POST /api/v1/jobflow/projects/{project_id}/manager
assign_project_manager
Semantic binding: operator_surface; mutation=True
workorders
⚡ REST API POST /api/v1/jobflow/projects/{project_id}/status
set_project_status
Semantic binding: operator_surface; mutation=True
workorders
⚡ REST API POST /api/v1/jobflow/reports/{report_id}/create-order
create_order_for_visit
Semantic binding: operator_surface; mutation=True
workorders
⚡ REST API POST /api/v1/jobflow/reports/{report_id}/schedule
schedule_report
Semantic binding: operator_surface; mutation=True
workorders
⚡ REST API POST /api/v1/jobflow/work-orders/{work_order_id}/assign
assign_work_order
Semantic binding: operator_surface; mutation=True
workorders
⚡ REST API POST /api/v1/jobflow/work-orders/{work_order_id}/dossier
create_dossier
Semantic binding: operator_surface; mutation=True
workorders
⚡ REST API POST /api/v1/jobflow/work-orders/{work_order_id}/plan-visit
plan_visit
Semantic binding: operator_surface; mutation=True
workorders
⚡ REST API POST /api/v1/jobflow/work-orders/{work_order_id}/start
start_work_order
Semantic binding: operator_surface; mutation=True
workorders
⚡ REST API POST /api/v1/workorders
create_workorder
Semantic binding: operator_surface; mutation=True
workorders
⚡ REST API POST /api/v1/workorders/{work_order_id}/complete
complete_workorder
Semantic binding: operator_surface; mutation=True
workorders
⚡ REST API POST /api/v1/workorders/{work_order_id}/create-invoice
create_invoice_from_workorder
Semantic binding: operator_surface; mutation=True
workorders
⚡ REST API POST /api/v1/workorders/{work_order_id}/documents
upload_workorder_document
Semantic binding: operator_surface; mutation=True
workorders
⚡ REST API POST /api/v1/workorders/{work_order_id}/invoice
create_order_invoice
Semantic binding: operator_surface; mutation=True
workorders
⚡ REST API POST /api/v1/workorders/{work_order_id}/items
add_workorder_item
Semantic binding: operator_surface; mutation=True
workorders
⚡ REST API POST /api/v1/workorders/{work_order_id}/logs
add_worklog
Semantic binding: operator_surface; mutation=True
workorders
⚡ REST API POST /api/v1/workorders/{work_order_id}/material-requirements
add_material_requirement
Semantic binding: operator_surface; mutation=True
workorders
⚡ REST API POST /api/v1/workorders/{work_order_id}/material-requirements/{requirement_id}/purchase
purchase_material_requirement
Semantic binding: operator_surface; mutation=True
workorders
⚡ REST API POST /api/v1/workorders/{work_order_id}/material-requirements/{requirement_id}/reserve
reserve_material_requirement
Semantic binding: operator_surface; mutation=True
workorders
⚡ REST API POST /api/v1/workorders/{work_order_id}/materials
consume_material
Semantic binding: operator_surface; mutation=True
workorders
⚡ REST API POST /api/v1/workorders/{work_order_id}/signature
save_signature
Semantic binding: operator_surface; mutation=True
workorders
⚡ REST API PUT /api/v1/workorders/{work_order_id}/invoice-settings
save_invoice_settings
Semantic binding: operator_surface; mutation=True
workorders
⚡ REST API PUT /api/v1/workorders/{work_order_id}/items/{item_id}/delivered
set_item_delivered
Semantic binding: operator_surface; mutation=True
workorders
🖥️ WEB-UI GET /auftraege
Auftragsübersicht
Liste aller Werkstatt- und Montageaufträge
workorders:read
⚡ REST API PATCH /api/v1/workorders/{id}/status
Status ändern
Schaltet Auftragsstatus weiter
workorders:write

🛡️ Regulatory & Compliance

Dieses Modul unterliegt folgenden gesetzlichen, regulatorischen und Revisionsstandards:

  • Arbeitszeitgesetz (ArbZG Dokumentationspflicht)
  • Handwerksordnung (HwO) Meisterabnahme
Related Modules:
➔ finance ➔ projects ➔ fieldservice ➔ assembly