Es ist Freitagnachmittag. Du willst mehrere Mandanten von Odoo migrieren. Die Aufgabe scheint simpel: Kontenpläne exportieren, Buchungen sichern, Webseiten-Bilder downloaden. Dann die Realität: Fast 2000 Bilder müssen einzeln gespeichert werden, Buchhaltungs-Transaktionen vergangener Jahre werfen Fehlermeldungen, manuelle Exports kosten Stunden.
Genau diese Situation hatte ich letzte Woche. Fünf Mandanten in Odoo Online, alle mit vollständigen Buchhaltungen und hunderten von Webseiten-Bildern. Der Plan: Alles exportieren für die Migration.
Was schief lief beim manuellen Export
Ich versuchte es zunächst konventionell über die Odoo-Oberfläche:
Bilder: Fast 2000 Bilder sollten von den Webseiten gesichert werden. Ich entdeckte gerade keinen Massen-Download. Die Alternative: Bild für Bild per Rechtsklick speichern. Zeitaufwand: Stunden.
Kontenpläne: Export über das Accounting-Modul möglich, aber für jeden Mandanten einzeln. Keine Batch-Funktion.
Buchungen: Hier kamen die ersten Fehlermeldungen. Beim Versuch, Transaktionen vergangener Jahre zu exportieren, brach Odoo mit wirren Fehlermeldungen ab.
Die Frustration war spürbar. Es musste einen besseren Weg geben.
Der KI-Vorschlag: Datenbank statt UI
Ich startete einen Chat mit Claude Sonnet 4.5 – ohne grosse Erwartungen. Parallel fragte ich auch ChatGPT, Gemini und meine lokale KI. Meine einfache Frage: “Gibt es einen besseren Weg für die Migration und den Export?”
Die Antwort von Claude, mit der ich weiterarbeitete, überraschte mich:
“Warum exportierst du nicht die gesamte Odoo-Datenbank? Daraus kannst du direkt alles auslesen – Bilder, Kontenpläne, Buchungen. Ich kann dir Python-Scripts schreiben, die das automatisieren.”
Ich zögerte. Eine PostgreSQL-Datenbank? Dateiverzeichnisse mit kryptischen Hash-Namen? Das klang nach mehr Aufwand, nicht weniger.
Aber Claude beruhigte: “Kein Stress. Ich analysiere die Struktur und extrahiere alles automatisch.”
Claude zeigte mir dann Schritt für Schritt, wo und wie ich die Datenbank in Odoo Online downloaden konnte. Das war bereits der erste Mehrwert – ich wusste nicht einmal, dass diese Funktion existiert.
Das Besondere: KI analysiert Datenbankstruktur selbständig
Hier wurde es spannend. Ich lud das Odoo-Backup herunter (ein ZIP mit der PostgreSQL-Datenbank und dem Filestore). Die Datenbank war voller kryptischer Verzeichnisse und nicht gerade intuitiv nachvollziehbar, zumindest nicht für mich. Dann passierte etwas Bemerkenswertes:
Ich gab Claude KEINE Informationen über die Datenbankstruktur. Keine Schema-Definitionen, keine Tabellen-Namen, keine Spalten-Beschreibungen.
Doch Claude übernahm und liess mich einige Python-Skripte ausführen, deren Output ich ihm dann zurück gab. Claude analysierte das dump.sql-File selbständig:
- Erkannte CREATE TABLE Statements
- Identifizierte relevante Tabellen (ir_attachment, account_account, account_move, account_move_line, res_company, res_partner)
- Parsed JSON-Felder (z.B.
{"de_CH": "Bank", "en_US": "Bank"}) - Verstand die Relationen zwischen Filestore-Hashes und Originalnamen
- Erkannte die PostgreSQL COPY-Syntax und INSERT-Statements
Das war kein simples Code-Generieren. Claude musste die Datenbank-Architektur verstehen, ohne dass ich sie erklärte. Die KI analysierte die Struktur durch die Script-Outputs, die ich zurückkopierte.
Python-Script in drei Iterationen
Claude schrieb mir ein Python-Script. Das Ziel war klar:
- Bilder extrahieren – aus dem Filestore mit Originalnamen
- Kontenpläne exportieren – für jeden Mandanten einzeln
- Buchungen strukturieren – mit Soll/Haben, Datum, Belegnummern
- Alles in Excel – pro Mandant eine Datei mit drei Tabs
Erste Version: Funktionierte nicht. Das Parsing der COPY-Statements war fehlerhaft. Claude suchte nach COPY public.ir_attachment, fand aber zuerst Relation-Tabellen.
Zweite Version: Besseres Parsing, aber immer noch leere Resultate. Claude erkannte das Problem selbst: Die Daten waren in INSERT-Statements statt im COPY-Format. Die Regex-Patterns mussten angepasst werden.
Dritte Version: Perfekt. Das Script lief durch.
Was mir auffiel: Ich musste Claude nicht debuggen. Ich kopierte einfach die Fehlermeldung oder den Script-Output zurück, und Claude korrigierte sich selbst. Kein manuelles Code-Anpassen meinerseits. Claude debuggte sich selbst durch die Rückmeldungen, die ich gab.
Der proaktive Vorschlag: Excel mit drei Tabs
Als wir zum Export der Buchhaltungs-Transaktionen kamen, passierte etwas Unerwartetes. Claude fragte mich von selbst:
“Soll ich dir die Buchungen gerade in einem Excel exportieren? Vielleicht in einem ersten Tab gerade den Kontoplan, in einem zweiten die effektiven Buchungen und im dritten die Saldobilanzen?”
Das hatte ich nicht verlangt. Claude schlug proaktiv eine sinnvolle Struktur vor, die für Finance-Leute sofort nutzbar ist:
- Tab 1: Kontenplan – Kontonummer, Kontobezeichnung, Kontotyp
- Tab 2: Buchungen – Datum, Beleg-Nr., Journal, Partner, Soll-Konto, Haben-Konto, Betrag
- Tab 3: Summenbilanz – Aggregierte Saldi pro Konto
Diese Struktur ist genau das, was ein Controller oder CFO für eine Migration braucht. Claude “verstand” den Anwendungsfall.
Das Resultat nach 10 Minuten
Das finale Script lief etwa 5 Minuten. Danach hatte ich:
1976 Bilder – sauber in Ordner sortiert (Produkte, Kontakte, Sonstiges), mit Originalnamen statt kryptischen Hashes
5 Excel-Dateien – eine pro Mandant:
Jede Datei mit den drei Tabs: Kontenplan, Buchungen, Summenbilanz. Alles strukturiert, bereit zur Weiterverarbeitung. Kein manuelles Copy-Paste, keine Fehlermeldungen, keine Timeout-Errors.
Datenschutz: Was Claude NICHT gesehen hat
An diesem Punkt ist es wichtig, Transparenz zu schaffen. Viele CFOs fragen sich: “Hat die KI jetzt alle unsere Finanzdaten?”
Die Antwort: Nein. Hier ist genau, was Claude NICHT gesehen hat:
❌ Die vollständige Datenbank ❌ Das dump.sql oder ZIP-File selbst ❌ Meine Buchungen, Beträge oder sensible Geschäftsdaten ❌ Direkten Zugriff auf meinen Computer oder OneDrive
Was Claude gesehen hat:
- Die Script-Outputs (Fehlermeldungen, Struktur-Infos), die ich zurückkopierte
- Code-Snippets aus den CREATE TABLE Statements
- Die Logik der Datenbank-Architektur
Wie das funktioniert: Die Python-Scripts liefen lokal in Spyder auf meinem PC. Claude schrieb den Code, ich führte ihn aus, und nur die Konsolenausgabe (Fehlermeldungen, Bestätigungen) ging zurück an Claude für die nächste Iteration.
Die eigentlichen Daten (Buchungen, Beträge, Kundennamen) blieben auf meinem Rechner.
Der Haken: Wenn man Claude das komplette dump.sql hochlädt für direktes Debugging, landen Daten bei Anthropic. Das wäre bei Mandanten-Daten problematisch. In meinem Fall habe ich das vermieden, indem ich nur Script-Outputs zurückgab.
