Cette migration a été faite avec l'outillage OCA OpenUpgrade .
La migration s'est faite du serveur 1 (Odoo 11 CE) vers le serveur 2 (Odoo 12 CE).
Cette migration a été faite avec l'outillage OCA OpenUpgrade .
La migration s'est faite du serveur 1 (Odoo 11 CE) vers le serveur 2 (Odoo 12 CE).
Voici un extrait de documentation récupérée sur upgrade.odoo.com qui synthétise les différentes commandes de dump et restauration d'une BD Postgresql :
/!\ Cet article est rédigé en anglais car il est référencé dans un échange sur github/OCA/OpenUpgrade .
I would like to test an upgrade from Odoo CE 10.0 to Odoo CE 11.0 with a simple database (Server 1 -> Server 2).
This upgrade will be done with OCA OpenUpgrade tool.
Continuer la lecture de ODOO 10 CE – migration en version 11.0
En version Odoo 8, nous pouvions utiliser le module inter_company_rules pour automatiser les échanges (achats/ventes/factures) entre plusieurs sociétés gérées dans une instance Odoo configurée en multi-société.
Depuis la version 9 et le changement de licence, l'éditeur met à disposition cette fonctionnalité "inter-company" uniquement dans l'édition entreprise et non plus dans l'édition communautaire.
Heureusement, cette fonctionnalité va être intégrée bientôt dans l'édition CE (Community Edition) car une Pull Request a été ouverte sur le sujet.
Associé à cette PR, un fork issu du module v8 semble en bonne voie pour être mergé prochainement sur la version 9.
Continuer la lecture de ODOO 9/10 CE – échanges inter-sociétés (multi-société)
La solution la plus simple pour effectuer une migration OpenERP v7 vers ODOO v8 est de prendre un contrat de maintenance auprès de l'éditeur ODOO SA qui sur votre demande, assure cette migration.
Une autre solution est d'utiliser l'outillage OpenUpgrade développé par la communauté.
J'ai tenté un 1er essai en partant d'une base de données v7 alimentée par les données de démonstration mais cela s'est terminé par un échec.
J'ai essayé ensuite une migration avec seulement les modules ventes et comptabilité associé à un jeu de données simple : quelques devis, bons de commande, factures et écritures comptables.
Environnement technique
- 1er serveur virtualisé Debian 7.7 -32 bits sur lequel est installé OpenERP7
- 2ème serveur virtualisé Debian 7.7 -32 bits sur lequel est installé ODOO 8
Description
* Phase 1 : opérations sur le serveur OpenERP 7
- supprimer l'éventuel répertoire /var/tmp/openupgrade
- arrêter le serveur OpenERP 7
- installation de git
apt-get install git
- installation de librairies python complémentaires
apt-get install python-pip
pip install openerp-client-lib
pip install decorator
pip install requests
pip install pyPdf
pip install passlib
- récupération et exécution du script migrate.py
wget https://raw.githubusercontent.com/OpenUpgrade/OpenUpgrade/HEAD/scripts/migrate.py
python migrate.py --config=<votre openerp.conf> --database=<db origine> --run-migrations=8.0
- exemple de <votre openerp.conf>
[options]
db_host = localhost
db_port = 5432
db_user = openerp
db_password = xxx
- l'exécution du script prend un certain temps et affiche les traces suivantes :
linking server/addons to /var/tmp/openupgrade/8.0/addons
getting git://github.com/OpenUpgrade/OpenUpgrade.git
Cloning into '/var/tmp/openupgrade/8.0/server'...
remote: Counting objects: 15667, done.
remote: Compressing objects: 100% (12284/12284), done.
remote: Total 15667 (delta 3669), reused 9653 (delta 2539)
Receiving objects: 100% (15667/15667), 69.70 MiB | 1.66 MiB/s, done.
Resolving deltas: 100% (3669/3669), done.
Checking out files: 100% (13826/13826), done.
copying database upgrade1 to upgrade1_migrated...
Copying the database using 'with template'
running migration for 8.0
- le résultat du script est la création d'une nouvelle base <db origine>_migrated et la production de logs sous /var/tmp/openupgrade/migration.log
- dans mon cas, tout semble bien se passer à l'exception d'une erreur affichée dans le fichier log :
2015-01-22 14:21:09,363 3842 ERROR sale-demo-1_migrated OpenUpgrade: Invalid value 'tree_account_reconciliation' in the table 'ir_ui_view' for the field 'type'. (1 rows).
... je choisis pour l'instant de passer outre cette erreur et de poursuivre le processus
- sauvegarde de la base "migrée" <db origine>_migrated dans un fichier zip
* Phase 2 : opérations sur le serveur Odoo 8
- restauration de la base "migrée"sur ce serveur
- mise à jour de la base
./openerp-server -u all -d <nom BD> --logfile=/tmp/xxx.log
- arrêt puis relance de Odoo 8
- dans mon cas extrêmement simple, l'opération de migration s'est déroulée sans problème (l'erreur vue en phase 1 n'a pas eu de répercussion apparente) ...
Je retrouve bien toutes mes données.
J'essaierai ultérieurement de réaliser cette migration dans un contexte plus représentatif (plus de modules officiels et plus de données) et encore plus tard avec des modules non inclus dans la liste des modules couverts par l'outillage OpenUpgrade
Environnement
- OpenERP v8
- modules "ventes", "entrepôt" et "achats" installés
- Dans le menu "Configuration/Paramètres généraux", autoriser l'import CSV
Description
J'ai appliqué la même procédure que précédemment pour le produit
Le fichier csv est disponible ici
Quelque temps après la rédaction de cette série d'articles, la société Anytech a produit un article intéressant sur l'import des employés.
Environnement
- OpenERP v8
- modules "ventes", "entrepôt" et "achats" installés
- Dans le menu "Configuration/Paramètres généraux", autoriser l'import CSV
- 2 fournisseurs créés : fournisseur1 , fournisseur2
Description
- Préparer le fichier csv d'import (les relations sont en fond "vert"):
* 1ères colonnes
Le fichier CSV est accessible ici
- aller dans le menu "articles", se mettre dans la vue "liste" et cliquer sur "importer"
- sélectionner le fichier d'import
- cliquer sur "valider"
- après click sur "importer", l'article est créé
Points importants relatifs à l'import
- même si cela n'est pas obligatoire, il est judicieux de renseigner l'identifiant externe "id" pour servir d'identifiant unique et :
* permettre le rejeu du chargement (en cas d'ajout/ modification d'informations) sans faire de doublon
* pour faciliter les mises en relation avec d'autres tables chargées ultérieurement (après avoir chargé les articles, on peut charger la nomenclature en faisant référence à ces "id")
- cas d'une relation Many2One (ex: catégorie produit, compte de revenus et compte de dépenses)
* il faut que la table en relation soit déjà chargée dans OpenERP et ensuite, on utilise soit l'identifiant externe, soit le champ fonctionnel qui sert d'identifiant (s'il existe)
- cas d'une relation One2Many (ex: fournisseurs du produit)
* sauf pour la 1ère, il faut ajouter 1 ligne à chaque relation, avec uniquement les infos de la relation renseignées
- cas d'une relation Many2Many (ex: taxes à la vente et à l'achat)
* les différentes valeurs sont séparées par une virgule
Nous allons aborder la problématique de reprise initiale de données dans OpenERP.
Ces données sont généralement issues d'un autre logiciel.
Nous prendrons dans un 1er temps, l'exemple des produits (articles) dont les données principales sont représentées dans le schéma suivant :
Le symbole "sens interdit" indique les champs obligatoires.
J'ai repris l'exemple de la migration Dolibarr vue précédemment pour le reproduire avec Pentaho-Kettle.
J'arrive à la transformation Kettle suivante :
Les étapes ("step") sont les suivantes :
Je ne vais finalement pas utiliser la solution TerminatOOOR pour interfacer Kettle (Pentaho Data Integration) à OpenERP.
En effet cette solution nécessite de développer des scripts en Ruby. Venant juste d'apprendre Python, je ne souhaite pas dans l'immédiat, apprendre un autre langage. Je verrai si besoin cette solution, ultérieurement.
Après recherche d'autres solutions s'interfaçant aux API OpenERP, je décide de retenir le plugin "OpenERP" qui va être fourni dans la prochaine version (v5.0) de Kettle.
Pour cela, je me procure cette version en cours de développement .
Le plugin OpenERP contient 3 nouveaux steps (au sens de Kettle) : input , output et delete .
Après avoir lancé l'interface graphique "spoon", nous voyons ces 3 nouveaux steps
L'import, export ou suppression dans OpenERP est alors grandement facilitée ... sachant que l'interface graphique Spoon est assez intuitive.
* Exemple d'import (à partir d'un fichier texte) :
* Exemple d'export (vers un fichier texte) :
Nous avons vu précédemment une 1ère méthode pour importer des données d'un système externe vers OpenERP.
Nous allons regarder maintenant une solution de type ETL.
En effet, cette 1ère méthode a l'inconvénient :
J'ai retenu dans un 1er temps, le logiciel libre "Pentaho Data Integration" (appelé aussi Kettle) plutôt que Talend pour les raisons suivantes :
Je vais donc passer quelques jours sur ce sujet en partant du wiki Pentaho.
A suivre ...