Migration vers Odoo — socle (gratuit)

Guide utilisateur — Migration vers Odoo (socle)

Ce module conduit un job de migration. Il ne sait parler à aucune source tout seul : chaque source est apportée par un module satellite migration_<source>. Il sait en revanche lire un fichier CSV, JSON, XLSX ou FEC, et cela suffit à s'en servir dès l'installation.

1. Le chemin le plus court : l'assistant

Migration → Assistant de migration.

1. Source ou fichier. Choisissez la source d'origine. Si vous partez d'un export, prenez « Fichier CSV, JSON, XLSX ou FEC ». Le bouton Vérifier l'accès fait un appel léger avant d'aller plus loin — pour une source fichier, il n'y a rien à vérifier, c'est normal.
2. Périmètre. Cochez ce que vous voulez migrer. Un type ne peut pas être coché sans ce dont il dépend (les variantes sans les produits, par exemple) — le module le refuse à l'enregistrement, pas au milieu du job.
3. Correspondances. Le connecteur propose un mapping par défaut, modifiable. Pour un fichier, déposez-le d'abord sur le checkpoint correspondant (onglet du job, ou directement sur le menu Suivi → Checkpoints), puis cliquez Analyser : les colonnes trouvées, l'encodage et le séparateur détectés s'affichent.
4. Simulation à blanc. Un clic sur Lancer la simulation exécute réellement le job — lecture, mapping, écriture — dans un savepoint annulé. Vous obtenez le rapport complet sans qu'une seule ligne n'entre dans la base.
5. Exécution. Cochez la case de confirmation, puis Lancer l'exécution réelle. Le mode essai est décoché à ce moment précis, jamais avant : c'est un geste délibéré.
6. Rapprochement. Cette étape est un placeholder dans ce lot (L0-L2) : la comparaison des soldes migrés aux soldes de la source est réservée au lot L3, une fois l'écriture comptable réelle faite.
7. Rapport final. Exportez le CSV, ouvrez le job pour le détail.

L'assistant ne survit pas à un F5. C'est une fenêtre purement technique (un « assistant » Odoo, sans identifiant dans l'adresse du navigateur) : un rafraîchissement, un onglet déchargé ou une fermeture accidentelle la vide et la fait repartir de la première étape. Le job, lui, ne perd jamais rien : c'est un enregistrement normal. Pour reprendre là où vous en étiez, ouvrez Migration → Jobs, retrouvez votre job, et cliquez Reprendre l'assistant : il se rouvre à l'étape la plus probable (périmètre, mapping, simulation ou exécution selon l'état du job), jamais à la case départ.

1 bis. Qui a le droit d'écrire pour de vrai ?

Un opérateur (groupe Migration : Opérateur) peut préparer un job, déposer des fichiers, régler le mapping, lancer une simulation et lire les rapports — mais pas créer réellement des contacts, des produits ou des commandes : il lui manque les droits Odoo de création sur ces objets (« Contact / Création », gestion des produits, ventes). C'est volontaire : écrire des données métier réelles est un geste réservé au groupe Migration : Administrateur, qui porte ces droits en plus des siens.

Si vous cliquez Lancer (simulation ou exécution) sans ces droits, l'assistant refuse avant de faire quoi que ce soit, avec un message qui nomme précisément ce qui manque — plutôt qu'un job qui tourne en entier pour ne rien créer, en silence. Demandez le groupe Migration : Administrateur à votre administrateur Odoo, ou faites lancer l'exécution réelle par quelqu'un qui le porte déjà.

2. Le mode essai, et pourquoi il n'est pas une simulation

En mode essai, le module fait réellement l'écriture dans Odoo, puis l'annule. C'est plus lent qu'un simple calcul, et c'est voulu : une taxe absente, une devise inconnue, un champ rendu obligatoire par un autre module installé chez vous ne se devinent pas. Ils se constatent.

Aucune trace n'est laissée : ni enregistrement Odoo, ni ligne au registre d'idempotence. Un essai ne « consomme » rien, vous pouvez le relancer autant de fois que nécessaire.

3. Relancer sans rien casser

C'est la promesse centrale du module, et elle n'a pas d'astérisque.

Chaque enregistrement migré est inscrit dans un registre — menu Suivi → Ce qui a déjà été migré — qui associe l'identifiant de la source d'origine à l'enregistrement Odoo correspondant. Au second passage, le module retrouve et met à jour. Il ne recrée rien.

Ne supprimez le registre que si vous voulez réellement tout recréer.

4. Reprendre un job interrompu

Chaque checkpoint range son curseur après chaque page réellement écrite. Si un job de vingt mille enregistrements s'arrête à douze mille — coupure réseau, quota de la source, redémarrage du serveur —, il repart à douze mille.

• Le job passe en Suspendue et le message dit pourquoi.
• Corrigez la cause, puis cliquez Lancer : il reprend au curseur.
• Le bouton Curseur à zéro, sur un checkpoint, fait relire la source depuis le début. C'est sans danger : tout ce qui existe est mis à jour, rien n'est recréé.
• Si le serveur redémarre pendant qu'un lot est en cours, le job peut apparaître orphelin (bouton « Déverrouiller le lot » visible) : c'est un signal, pas une relance — vérifiez le rapport avant de relancer vous-même.

5. Lire le rapport

Une ligne par enregistrement traité, y compris les inchangés — sans eux, vous ne pourriez pas prouver au second passage que rien n'a été dupliqué.

6. Le lecteur FEC (comptabilité française)

Déposez le fichier FEC (18 colonnes normées DGFiP, séparateur | ou tabulation) sur le checkpoint « Écritures comptables ». Le module :

• vérifie que les 18 colonnes attendues sont présentes, et dit lesquelles manquent sinon ;
• groupe les lignes par écriture (JournalCode + EcritureNum) ;
• contrôle l'équilibre débit/crédit par écriture, jamais ligne à ligne : une écriture déséquilibrée est rejetée avant toute écriture, jamais tronquée ;
• recherche chaque compte cité dans le plan comptable Odoo — sans jamais en créer un absent, ce qui est une écriture réservée au lot L3.

Aucune écriture comptable réelle (account.move) n'est produite par ce module : c'est de la lecture, du contrôle et un rapport d'écarts.

7. Le lecteur XLSX

Nécessite la bibliothèque Python openpyxl, en dépendance douce : si elle n'est pas installée sur le serveur, un message clair le dit au moment de lire un fichier XLSX précis — l'installation du module elle-même n'est jamais bloquée. Le même export au format CSV se lit sans rien de plus.

8. Connecter une source par OAuth2 (lot L4)

Réservé au groupe « Migration : Administrateur » — brancher une source ne se délègue pas.

1. Sur la fiche migration.source, section « OAuth2 », renseignez oauth2_authorize_url, oauth2_token_url, les portées (oauth2_scopes), l'identifiant et le secret client (fournis par le fournisseur lors de l'enregistrement de votre application), puis oauth2_url_retour (l'adresse de ce serveur Odoo, suivie de /migration/oauth/retour/<id de la source> — l'identifiant n'existe qu'après le premier enregistrement de la fiche) : déclarez cette même adresse chez le fournisseur (« redirect URI »).
2. Sauvegardez la fiche.
3. Cliquez sur Connecter : un nouvel onglet s'ouvre sur le site du fournisseur. Autorisez l'accès.
4. Vous revenez sur une page de confirmation sobre ; la fiche source affiche désormais « Connecté (OAuth2) ».
5. Le jeton d'accès se renouvelle automatiquement, sans action de votre part, tant que le jeton de rafraîchissement reste valide chez le fournisseur.
6. Révoquer l'accès OAuth2 efface les jetons stockés côté Odoo (et, si le fournisseur expose une adresse de révocation, l'en informe aussi) — geste irréversible sans reconnecter la source.

Aucun secret (identifiant, jeton) n'apparaît jamais dans le journal réseau (migration.log) : les motifs reconnus (Authorization, refresh_token, client_secret, access_token) y sont systématiquement expurgés.

Trois profils de démonstration (Xero, QuickBooks Online, Exact Online) sont livrés en données de démonstration, non fonctionnels sans une application réelle enregistrée chez le fournisseur — ils montrent seulement comment paramétrer une source OAuth2, pas un accès prêt à l'emploi.