Archives du mot-clé Migration

ODOO 9/10 CE – échanges inter-sociétés (multi-société)

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é) 

ODOO 8 – test simple de migration depuis OpenERP 7 avec OpenUpgrade

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

Exemple d’import de client (4/4)

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.

Exemple d’import de produit (2/4)

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

   * colonnes suivantes

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

Import de Dolibarr vers OpenERP 7

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 :

  • traitement d'un fichier csv (produit par l'export Dolibarr) au format ISO-8859-1
  • concaténation des champs Nom et Prénom (avec encodage des infos en UTF-8)
  • transformation de la civilité en valeurs acceptées par OpenERP (Madam, Mister)
  • ajout d'une constante free_member=True pour caractériser un "partner" de type adhérent
  • écriture dans OpenERP

Interface Kettle 5.0 – OpenERP 7

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) :