Arbeitsgänge in der App: Ein geplanter Start ist noch keine Erlaubnis zum Beginn

Ein Arbeitsgang kann einen geplanten Starttermin haben und trotzdem auf einen anderen Vorgang warten. Diese Unterscheidung sollte Ihre App verständlich zeigen. Bestimmen Sie, welcher Vorgänger abgeschlossen sein muss, was Abschluss im Betrieb bedeutet und ob danach noch eine vorgeschriebene Wartezeit läuft.

Das ist etwas anderes als ein freier Maschinenplatz. Hier geht es um Beziehungen zwischen Arbeitsschritten, auch wenn sie verschiedene Ressourcen nutzen. Technische Bedingungen und Sicherheitsvorgaben müssen Fachpersonen festlegen; ein Pfeil im Kalender ersetzt sie nicht.

Die Voraussetzung beschreiben, nicht nur Zeilen sortieren

Ein erfundenes Beispiel: Ein Bauteil wird vorbereitet und anschließend montiert. Muss die Vorbereitung vollständig beendet sein, oder erlaubt der fachlich geprüfte Ablauf eine Teilübergabe? Die Reihenfolge der Bildschirmzeilen beantwortet das nicht.

Odoo 19 dokumentiert dafür eine Blocked-By-Beziehung zwischen Arbeitsgängen einer Stückliste. In der Arbeitsauftragsliste steht bei abhängiger Arbeit Blocked. Nach Abschluss der blockierenden Arbeitsaufträge wechselt die Kennzeichnung zu To Do. Das zeigt eine konkrete Produktfunktion, belegt aber nicht die Durchsetzung Ihrer betrieblichen Voraussetzungen in einer individuellen App.

Wenn die erste Version bei einem verfrühten Start lediglich warnt, muss sie so beschrieben werden. Ein übergehbarer Hinweis ist weder eine verbindliche Sperre noch eine technische Sicherheitsverriegelung.

Schätztermin und Fertigmeldung trennen

Die Odoo-Anleitung beschreibt außerdem, dass ein abhängiger Arbeitsauftrag hinter der erwarteten Dauer seines Vorgängers eingeplant wird. Das geschätzte Ende hilft also bei der Planung. Die tatsächlich gemeldete Fertigstellung ist eine andere Information.

Fragen Sie im Briefing, was das Team sieht, wenn der geschätzte Endtermin verstreicht und der Vorgänger noch läuft. Der nächste Arbeitsgang darf nicht allein wegen seines erreichten Kalendereintrags als betrieblich freigegeben erscheinen. Ist eine Startsperre vereinbart, muss sie vorgeführt werden. Zeigt das System nur einen Hinweis, muss genau diese Grenze sichtbar sein.

Definieren Sie auch die Fertigmeldung selbst. Reicht eine Meldung der ausführenden Person, braucht es eine abgenommene Ausgabemenge oder eine gesonderte Prüfung? Das sind Prozessentscheidungen, zwischen denen die Anwendung nicht stillschweigend wechseln darf. Dieser Beitrag legt keine konkrete Prüfpflicht fest und erlaubt nicht deren Umgehung.

Verschiebbare Reserve von notwendiger Wartezeit unterscheiden

Odoo dokumentiert Planungsmodi, die einen Puffer erhalten oder nutzen, und warnt vor dessen Verkürzung. Ihre Umsetzung muss wissen, warum eine Lücke existiert, bevor Arbeit hineingeschoben wird.

Eine vorsorgliche Terminreserve ist nicht dasselbe wie eine technisch erforderliche Wartezeit. In einem fiktiven Verfahren kann nach einem Schritt eine fachlich festgelegte Zeitspanne nötig sein. Schreiben Sie auf, ab welchem Ereignis sie läuft, welche Dauer gilt und wer die Vorgabe ändern darf. Ein gewünschter Liefertermin macht daraus keine freie Planungsreserve.

Die Pufferfunktion der Quelle ist ein Planungsmechanismus. Sie bestätigt weder die physische Bereitschaft eines Werkstücks noch ein Aushärtungsergebnis oder einen sicheren Zustand Ihres Verfahrens.

Eine Warnung beseitigen heißt nicht, die Regel löschen

Laut Odoo-Anleitung trennt das Abbrechen einer Abhängigkeitsverbindung in der Planung die Beziehung, weil das Produkt eine Ausnahme annimmt. Das ist etwas anderes als eine Neuplanung, bei der die Abhängigkeit erhalten bleibt.

Legen Sie für Ihre App fest, wer eine Voraussetzung entfernen darf und wo die Begründung sichtbar bleibt. Lassen Sie die Beziehung vor und nach dem Eingriff zeigen. Wer einen roten Pfeil aufräumen möchte, muss erkennen, ob er einen Termin korrigiert oder eine fachliche Voraussetzung löscht.

Schwierige Fälle bei der Abnahme zeigen

Nutzen Sie erfundene Aufträge in den Akzeptanzkriterien: einen verspäteten Vorgänger, einen abgeschlossenen Vorgänger mit noch laufender Wartezeit, einen verschobenen Arbeitsgang und einen unberechtigten Löschversuch an der Abhängigkeit. Zeigen Sie auch unabhängige parallele Arbeit, damit nicht versehentlich alles eine einzige Kette bildet.

Prüfen Sie Plantermin, tatsächlichen Abschluss, Sperrgrund und verbleibende Wartezeit getrennt. Wird eine Fertigmeldung nach Beginn des Nachfolgers korrigiert, braucht es einen ausdrücklich vereinbarten Ausnahmeweg statt einer lautlosen Änderung der Vergangenheit.

Bringen Sie die fachlich festgelegten Beziehungen zu einem Gespräch über eine Fertigungs-App mit. Das Ergebnis soll ein erklärbarer Ablauf mit ehrlichen Durchsetzungsgrenzen sein, nicht bloß eine Zeitleiste mit verbundenen Blöcken.

Quelle

Odoo 19: Work order dependencies, englische Dokumentation, gelesen am 26. Oktober 2026. Die Produktbeschreibung stammt aus der Dokumentation; die vorgeschlagenen Abnahmefälle sind kein durchgeführter Implementierungstest.