Zum Inhalt springen

Verplanung von Projekt-Tasks mit estimierter Zeit in Odoo

25. März 2026 durch
Verplanung von Projekt-Tasks mit estimierter Zeit in Odoo
Dietmar Hamm

In Odoo werden Projekt-Tasks mit estimierten Stundenumfängen nicht automatisch in der Planung verplant. Stattdessen erstellt der Planer auf Basis der Task-Informationen und des zugewiesenen Mitarbeiters manuell entsprechende Planungsslots. Die Verplanung erfolgt dabei projekt- und mitarbeiterbezogen, um Ressourcenkonflikte und Auslastungen transparent zu verwalten.

🔍 Recherchiert mit grep_code, grep_code, find_files, grep_code, list_directory, list_directory, list_directory, list_directory, read_file, read_file, read_file, read_file, grep_code, grep_code, grep_code, grep_code, grep_code, grep_code, read_file, read_file, read_file, grep_code, read_file, grep_code, grep_code

Jetzt habe ich genug Kontext. Ich kann eine vollständige, präzise Antwort geben.

Projekt-Tasks mit estimierter Zeit → Verplanung in Planning

Ich habe den kompletten Zusammenhang zwischen project.task, planning.slot und den beteiligten Enterprise-Modulen durchleuchtet. Hier ist meine vollständige Erklärung:

⚠️ Wichtig vorab: Tasks und Slots sind NICHT direkt verknüpft!

Das ist der entscheidende Punkt, den ich im Code klar sehen kann: Eine project.task hat keinen direkten planning.slot-Bezug und umgekehrt. Die Verbindung läuft ausschließlich über das Projekt (project_id). Es gibt keine automatische Konvertierung "Task → Slot". Der Planer muss den Slot manuell erstellen.

🧩 Fachlicher Prozess: Wie wird ein Task-Mitarbeiter verplant?

Schritt 1: Task anlegen mit Zeiten

Am project.task gibt es das Feld allocated_hours (odoo_17/addons/project/models/project_task.py:165) – das ist die geschätzte Zeit ("Geplante Stunden") die der Mitarbeiter für diese Aufgabe braucht. Außerdem subtask_allocated_hours (Zeile 166), das die Summe der Subtasks enthält.

Diese Zahl bleibt zunächst rein informativ auf dem Task. Sie fließt nicht automatisch in Planning.

Schritt 2: Projekt als Brücke – project_forecast Modul

Das Modul project_forecast (Enterprise) erweitert planning.slot um das Feld project_id:

enterprise_17/project_forecast/models/project_forecast.py:15-18 → PlanningShift.project_id – Many2one auf project.project, computed aus template_id.project_id. So kann ein Planning-Slot direkt einem Projekt zugeordnet werden.

Das Projekt seinerseits bekommt total_forecast_time (enterprise_17/project_forecast/models/project.py:15-26): Summiert alle allocated_hours aller Slots, die zu diesem Projekt gehören → der Manager sieht auf dem Projekt, wie viele Stunden bereits verplant sind.

Schritt 3: Planer erstellt manuell Slots pro Mitarbeiter

Der Planer öffnet im Projekt den Button "Geplant" (X Stunden), kommt zum Gantt-View von Planning (via action_project_forecast_from_project(), Zeile 28-45) und erstellt dort Schichten mit:

  • project_id → das Projekt
  • resource_id → der Mitarbeiter
  • allocated_hours → wie viele Stunden dieser Mitarbeiter in diesem Zeitraum am Projekt arbeitet

Schritt 4: Stundenkontrolle – Remaining Hours Logik

Hier kommt die intelligente Budget-Kontrolle ins Spiel. Die Methode _init_remaining_hours_to_plan() (enterprise_17/project_timesheet_forecast_sale/models/planning_slot.py:12-21) berechnet beim Kopieren von Slots (Vorwoche kopieren):

remaining = project.allocated_hours - project.total_forecast_time

D.h.: Wie viele Projektstunden sind noch nicht verplant? Wenn nichts mehr übrig ist → der Slot wird nicht kopiert (return False).

_update_remaining_hours_to_plan_and_values() (Zeilen 23-35) schneidet den kopierten Slot sogar automatisch auf die verbleibenden Stunden zu, wenn das Budget knapp ist.

Schritt 5: Ist-Zeit vs. Plan – project_timesheet_forecast Modul

Wenn der Mitarbeiter tatsächlich arbeitet und Timesheets erfasst, gleicht das Modul ab:

enterprise_17/project_timesheet_forecast/models/project_forecast.py:58-66 → _compute_timesheet_ids() – Sucht alle Timesheets des zugewiesenen Mitarbeiters (employee_id), im Zeitraum des Slots (start_datetime bis end_datetime), im gleichen Projekt. Diese Stunden landen in effective_hours.

enterprise_17/project_timesheet_forecast/models/project_forecast.py:26-32 → _compute_percentage_hours() – Berechnet den Fortschritt = effective_hours / allocated_hours * 100. Im Gantt-View wird ein Fortschrittsbalken angezeigt.

⚙️ Technisches Zusammenspiel der Module

project.task
  └── allocated_hours       ← geschätzte Stunden am Task (rein informativ)
  └── project_id ─────────────────────────────────────────────────┐
                                                                    │
project.project                                                     │
  └── allocated_hours       ← Budget des Projekts gesamt            │
  └── total_forecast_time   ← Summe aller Slot-Stunden ←──────┐   │
                                                                │   │
planning.slot (project_forecast erweitert)                      │   │
  └── project_id ────────────────────────────────────────────────┘  │
  └── resource_id           ← der Mitarbeiter                        │
  └── allocated_hours       ← geplante Stunden dieses Slots          │
  └── effective_hours       ← tatsächlich gebuchte TS-Stunden        │
  └── percentage_hours      ← Fortschritt (effective/allocated)      │
  └── timesheet_ids ────────── account.analytic.line (Timesheets)   │

📌 Was es NICHT gibt (wichtig zu wissen!)

Was man erwarten könnte Realität
Task → automatisch ein Slot wird erstellt ❌ Kein Auto-Slot aus Tasks
allocated_hours am Task fließt in den Slot ❌ Keine direkte Übernahme
Mitarbeiter am Task = Mitarbeiter im Slot ❌ Manager muss Slot manuell anlegen
Task-Zeiten steuern Slot-Zeiten ❌ Nur über Projekt-Budget indirekt

📎 Quellreferenzen

Oddy
Oddy
Odoo-Expertin bei Detalex GmbH

Oddy ist ein Produkt der Detalex GmbH. Wir unterstützen unsere Kunden mit Custom-Entwicklung, Beratung und Hosting für Odoo.

Termin vereinbaren
Nächsten Beitrag lesen
Mitarbeiter-Verplanung in Odoo Planning – Fachliche und technische Grundlagen