In diesem Beitrag
Odoo 19 auf 20: Was musst du bei KI neu abnehmen?
Die aktualisierte Datenbank öffnet sich. Der Agent beantwortet eine vertraute Frage. Das Team möchte die alte Automatisierung wieder einschalten. Offen bleibt, ob der Workflow die vorgesehene Konfiguration nutzt, auf die richtigen Datensätze zugreift und dort stoppt, wo ein Mensch entscheiden muss.
Bevor ein KI-Workflow aus Odoo 19 unter 20 wieder läuft, ordnest du die alte Konfiguration dem tatsächlichen Zielzustand zu, bestätigst Anfrage- und Abrechnungsweg und prüfst vereinbarte Geschäftsfälle in einer freigegebenen Testumgebung. Deaktivierte Pfade bleiben fehlende Nachweise. Ein benannter Prozessverantwortlicher muss das Zielverhalten abnehmen, bevor der Workflow wieder startet.
Recherche geprüft: 5. November 2026. Dies ist ein vorgeschlagenes Abnahmeverfahren auf Basis offizieller, versionierter Dokumentation. Wir haben keine Odoo-Migration von 19 auf 20 durchgeführt und keine Agentenleistung gemessen. Das Beispiel und die herunterladbare Nachweisliste sind ausdrücklich noch nicht ausgeführt.
Welche dokumentierten Änderungen brauchen eine neue Entscheidung?
Beginne mit den dokumentierten Konfigurationsunterschieden und prüfe dann den tatsächlichen Zustand deiner aktualisierten Datenbank. Die Anleitungen zeigen, welche Einstellungen Aufmerksamkeit verdienen. Sie beweisen nicht, wie deine Agenten, Zugangsdaten oder eigenen Aktionen migrieren. Der Versionsvergleich liefert die Fragen; die Zielumgebung muss die Antworten belegen.
Die Agentenanleitung für 19.0 beschreibt Topics. Die Anleitung für 20.0 beschreibt Skills; auch die Auswahl der Antwortstile unterscheidet sich. Ordne diese Einstellungen ausdrücklich zu. Weder ein vertrauter Name noch ein neues Etikett beweist, dass die bisherigen Abnahmekriterien erfüllt sind.
Die KI-Übersicht für 20.0 nennt IAP-Credits für KI-Anfragen. Die API-Schlüssel-Seite für 20.0 ist noch im Aufbau. Damit bleibt die konkrete Übernahme einer alten Zugangslösung unbelegt. Kläre den vorgesehenen Verbindungsweg anhand aktueller Informationen.
| Prüfbereich | Frage an die Zielumgebung | Aufzubewahrender Nachweis |
|---|---|---|
| Agentenkonfiguration | Welche Anweisungen, Werkzeuge und Antwortoptionen sind jetzt zugeordnet? | Quell- und Zielreferenzen mit Erklärung jeder beabsichtigten Änderung |
| Anfrageweg | Welcher Dienst und welches Konto verarbeiten die Anfragen? | Aktuelle Konfiguration, Kontoverantwortung und Bestätigung der unterstützten Lösung |
| Nutzungskontrolle | Wer sieht den Verbrauch und kann den Workflow stoppen? | Budgetverantwortung, beobachteter Überwachungsweg und geprüftes Stoppverfahren |
| Ausführung | Erreicht der Auslöser die vorgesehene Aktion unter der richtigen Identität? | Ausführungsnachweis dieses Pfads, nicht nur ein Konfigurationsbild |
Die ausführliche Prüfung des Odoo-KI-Creditbudgets und der KI-Verarbeitungsorte gehört in eigene Entscheidungen. Verweise hier darauf, damit die Freigabeakte auf den Workflow fokussiert bleibt.
Was gehört in den Vorher-Nachher-Nachweis?
Erfasse genug Konfiguration, um einen Workflow vom Auslöser bis zum abgenommenen Ergebnis zu erklären. Dazu gehören genaue Quell- und Zielversion, Agentenanweisungen, verfügbare Werkzeuge, Quellen, Ausführungsidentität und Prüfgrenze. Dokumentiere beabsichtigte Änderungen ebenso wie ungeklärte Unterschiede. Eine Liste installierter Apps belegt nicht, dass dieser konkrete Ablauf erhalten geblieben ist.
Gib dem Workflow eine stabile Kennung, etwa STOCK-NOTE-01, und benenne den fachlichen Verantwortlichen. Hinter den Kurzbezeichnungen „19“ und „20“ sollte die tatsächliche Build- oder Deployment-Referenz stehen. Ändert sich die Quelle nach der Erfassung, aktualisiere den Ausgangsstand vor dem Zielvergleich.
Geheimnisse gehören nicht in diese Liste. Nutze eine Zugangsdatenreferenz, den Kontoverantwortlichen und das Prüfdatum. Für Prompts und Anweisungen behältst du einen freigegebenen Stand oder Versionsverweis; für Quellen die im Test verwendete Dokument- oder Datensatzversion. So lässt sich eine Abweichung erklären, ohne Produktivdaten in eine Planungstabelle zu kopieren.
Ein brauchbarer Änderungseintrag nennt alte und neue Einstellung, Grund, erwartete Wirkung und Freigabe. „Auf neuen Standard geändert“ lässt die fachliche Wirkung offen. „Antwortstil geändert; Zugriff und Prüfpflicht bleiben Gegenstand der Fälle R06-A bis R06-C“ schafft eine überprüfbare Aussage.
Trenne dies vom Datenbankabgleich. Der Leitfaden zur Migrationsabnahme und Abstimmung behandelt die Übernahme von Geschäftsdatensätzen und Salden. Hier geht es um die Abnahme des KI-gestützten Verhaltens rund um diese Daten.
Was bleibt in einer neutralisierten Testdatenbank unbewiesen?
Eine Testumgebung kann genau den Pfad unterdrücken, den du bewerten möchtest. Erfasse vor der Ergebnisinterpretation deaktivierte Auslöser, Anfragewege und Nebenwirkungen. Ist ein geplanter Lauf nicht erfolgt oder sein KI-Anfrageweg nicht verfügbar, bleibt dieser Teil ungetestet. Plane eine kontrollierte Prüfung, die den fehlenden Nachweis gezielt liefert.
Die Odoo-Dokumentation zu neutralisierten Datenbanken nennt geplante Aktionen und IAP-Tokens unter den deaktivierten Funktionen. Die Liste ist nicht vollständig. Unsere begrenzte Schlussfolgerung: Ein erfolgreiches manuelles Gespräch belegt nicht, dass ein deaktivierter Zeitplan- oder IAP-Pfad ausgeführt wurde.
Vereinbare vor dem Test die Isolation: synthetische oder freigegebene Daten, erlaubte Ziele, Kontoreferenzen, Ausgabenlimit, zulässige Schreibzugriffe und Stoppverantwortung. Der technische Verantwortliche muss bestimmen, welche Kontrollen deaktiviert bleiben und welcher konkrete Testweg aktiviert oder sicher ersetzt werden kann. Neutralisierung beweist nicht die Isolation jeder eigenen Integration.
Unterscheide die Nachweisarten. Ein simulierter Anbieterausfall kann zeigen, wie dein Übergabecode auf diesen simulierten Fehler reagiert. Er bestätigt weder ein echtes Anbieterkonto noch eine funktionierende Abrechnung oder Anfrage. Umgekehrt sagt eine erfolgreiche Anfrage wenig über Zeitplanung, wiederholte Zustellung oder menschliche Prüfung. Halte die Grenze jeder Beobachtung fest.
Fehlt vor dem Upgrade-Fenster ein kontrollierter Testweg, bleibt der Nachweis offen und die betroffene Automatisierung pausiert. Andere unabhängig geprüfte Workflows können trotzdem abgenommen werden.
Wie prüfst du einen bestehenden Workflow erneut?
Definiere das erwartete Geschäftsverhalten vor dem Vergleich beider Umgebungen. Verwende einen stabilen Satz freigegebener Eingaben und beurteile jedes Ergebnis anhand gleicher Anforderungen an Datensätze, Befugnisse und Prüfung. Die alte Ausgabe ist eine Beobachtung, keine Musterlösung. Einen bisherigen Fehler zu reproduzieren würde ihn lediglich erhalten.
Ein fiktives Planungsteam lässt eine interne Notiz zu Bestandsauffälligkeiten vorbereiten. Die vorgeschlagenen Anforderungen sind begrenzt: den freigegebenen Datenstand identifizieren, daraus belegbare Auffälligkeiten beschreiben, fehlende Mengenangaben offenlassen und die Notiz zur Planungsprüfung vorlegen. Der Assistent darf weder Bestandsmengen ändern noch außerhalb des Prüfprozesses Nachrichten senden.
Nutze drei unterschiedliche Fälle: eine eindeutige Auffälligkeit, eine unvollständige Quelle und eine Quelle mit einer Anweisung, die Prüfung zu umgehen. Lege die Erwartungen fest, bevor eine der Versionen läuft. Eine flüssig geschriebene Notiz mit erfundener Menge fällt durch. Andere Formulierungen können bestehen, wenn Aussagen, Quellenverweise und Prüfstatus stimmen.
Prüfe auch den Abbruch- oder Fehlerweg. Wer übernimmt unerledigte Arbeit, was sieht der Nutzer und wie verhindert ihr, dass „keine Antwort“ als „keine Auffälligkeiten“ gilt? Lege diese Erwartungen unabhängig vom konkreten Fehlertext des Produkts fest.
Die Tests für Geschäftszustände liefern den detaillierteren Rahmen für Schreibprüfungen. Verweise in der Freigabeakte auf deren Ergebnisse, statt jede Testdefinition und den gesamten Datenabgleich zu wiederholen.
Welche Nachweise kommen in die Freigabeliste?
Halte Konfigurationsbeobachtung, ausgeführte Fälle und Freigabe auseinander. Jede erforderliche Zeile braucht Quell- und Zielreferenz, erwartetes Ergebnis, tatsächliche Beobachtung und Prüfer. Ohne tatsächlichen Nachweis bleibt sie offen, auch wenn die übrige Dokumentation vollständig aussieht. Die Liste macht diesen Unterschied sichtbar; sie automatisiert keine Abnahmeentscheidung.
Lade die Freigabeliste mit acht Nachweisbereichen und ihre Nutzungshinweise herunter. Jede Zeile beginnt mit NOT_RUN; Beobachtungs- und Freigabefelder bleiben leer. Es sind vorgeschlagene Prüfungen, keine Ergebnisse einer Odoo-Installation.
| Zeile | Nachweisbereich | Zu beantwortende Frage |
|---|---|---|
| R01 | Umfang und Ausgangsstand | Welchen Workflow, welche Umgebungen, Daten und Verantwortung deckt die Entscheidung ab? |
| R02 | Konfigurationszuordnung | Sind Unterschiede zwischen Quelle und Ziel erklärt und freigegeben? |
| R03 | Ausführungsbefugnis | Welche Auslöser, Identitäten und Werkzeuge handeln, und wo greift die Prüfung? |
| R04 | Anfrageweg | Sind Konto-, Abrechnungs- und Verarbeitungsortentscheidungen aktuell? |
| R05 | Testisolation | Welche Pfade liefen, wurden simuliert oder blieben deaktiviert? |
| R06 | Geschäftsfälle | Erfüllen die Ergebnisse unabhängig festgelegte Erwartungen? |
| R07 | Fehler und Übergabe | Kann der Ablauf mit klarer Verantwortung für offene Arbeit stoppen? |
| R08 | Freigabeentscheidung | Wer nimmt den begrenzten Umfang ab und welche Änderung verlangt eine neue Prüfung? |
Verwende PASS erst nach Prüfung der Nachweise, FAIL bei einer beobachteten Abweichung, BLOCKED bei einer blockierten Prüfung und NOT_RUN vor ihrer Durchführung. Für nicht anwendbare Zeilen hältst du N/A mit Begründung und Prüfer fest. Das sind vorgeschlagene Teamkonventionen, keine Odoo-Statusfelder.
„Wie vorher“ ist kein ausreichender Nachweis. Verlinke den tatsächlichen Konfigurationsstand, das Fallergebnis oder die Entscheidung. Bei einer Korrektur bleibt die fehlgeschlagene Beobachtung erhalten und wird mit der Nachprüfung verbunden; die Historie wird nicht durch eine grüne Zelle ersetzt.
Wann darf der Workflow wieder starten?
Der begrenzte Workflow darf starten, wenn die erforderlichen Beobachtungen seine Geschäftsanforderungen belegen und der benannte Verantwortliche die verbleibenden Grenzen akzeptiert. Fehlende Nachweise und beobachtete Fehler verlangen unterschiedliche Maßnahmen; beides ist kein Bestehen. Ist nur ein manueller Teil abgenommen, dokumentiere diesen Betriebsmodus und lasse den nicht abgenommenen Auslöser deaktiviert.
| Beobachteter Stand | Entscheidung | Betriebliche Folge |
|---|---|---|
| Erforderliche Fälle bestehen; Weg und Verantwortung sind bestätigt. | Definierten Umfang abnehmen. | Dokumentierten Workflow mit Überwachung und Stoppverfahren starten. |
| Manueller Weg ist abgenommen; Zeitplan wurde nicht geprüft. | Bei Bedarf nur den manuellen Umfang abnehmen. | Zeitplanung deaktiviert lassen und fehlenden Test zuweisen. |
| Ausgabe wirkt korrekt; Konto oder Verarbeitungsweg bleiben ungeklärt. | Betroffenen Weg zurückhalten. | Nachweislücke vor der Übertragung freigegebener Geschäftsdaten schließen. |
| Eine erforderliche Geschäftsbedingung wird verletzt. | Dieses Verhalten ablehnen. | Korrigieren, betroffene Fälle wiederholen und neu entscheiden. |
Die technische Prüfung stellt fest, was lief und was sich änderte. Der Prozessverantwortliche entscheidet, ob das dokumentierte Ergebnis für die Arbeit geeignet ist. Beide Entscheidungen müssen Version, Weg und Umfang nennen. Die Freigabe eines manuellen Entwurfs autorisiert keinen später ergänzten unbeaufsichtigten Schreibpfad.
Vereinbart das Vorgehen, falls erste Produktivbeobachtungen der Abnahme widersprechen. Pausieren und manuelle Bearbeitung können passen; ein Datenbank-Rollback braucht einen eigenen getesteten Plan. Einen Agenten zu deaktivieren macht bereits geänderte Datensätze nicht automatisch rückgängig. Die Freigabe ist kein Versprechen, jeden früheren Datenstand wiederherstellen zu können.
Was sollte vor der Buchung des Upgrade-Fensters feststehen?
Identifiziere die KI-Workflows, auf die Menschen angewiesen sind, benenne pro Ablauf einen Abnahmeverantwortlichen und kläre die Testwege vor dem geplanten Wiederanlauf. Das erste Ergebnis ist eine begrenzte Nachweisliste mit ehrlichen Lücken. Damit kann das Team konkret schätzen, prüfen und entscheiden, statt pauschal „die KI zu testen“.
Beginne mit einem Ablauf, dessen Geschäftsergebnis leicht überprüfbar ist. Vervollständige Ausgangsstand, Zielzuordnung und Fallerwartungen. Prüfe danach, welche weiteren Workflows Konfiguration und Ausführungsweg teilen und welche eigene Nachweise brauchen. Gemeinsame Infrastruktur kann Wiederholungen reduzieren; andere Befugnisse oder Nebenwirkungen verlangen weiterhin eine eigene Entscheidung.
Wavects Software-Qualitätssicherung unterstützt bei Abnahmeumfang und Nachweisverantwortung. Die QA-Checkliste vor dem Start liefert breiteren Freigabekontext. Die Twinsoft-AI-Fallstudie ist ein separates Projektbeispiel und kein Nachweis einer durchgeführten Odoo-Migrationsprüfung.
Bring deine Workflow-Liste und offenen Freigabefragen mit. Eine hilfreiche Prüfung endet mit benannten Tests, bekannten Grenzen und einer verantwortlichen Person für jede Wiederanlaufentscheidung.