Archives par mot-clé : Exemple

Description technique du scénario fonctionnel (4/5) – workflow

Il s'avère que la création de l'instance de l'objet "account.invoice" déclenche aussi une nouvelle instance du workflow "account.invoice.basic".
En effet, un workflow est configuré sur l'objet "account.invoice" (avec l'état initial "draft")

account_invoice_workflow.xml

Ce workflow est aussi visible graphiquement

Revenons à notre facture d'avance dans l'état "brouillon"

et voyons ce qui se passe techniquement lors du click sur le bouton "Valider".
 Dans le fichier "view", le choix "valider" est associé au bouton nommé "invoice_open"  ...

account_invoice_view.xml

et dans le fichier "workflow", le bouton "invoice_open" déclenche une transition avec le passage dans l'état "open" ...

et l'exécution de l'activité suivante ...

qui déclenche l'appel des méthodes suivantes :
   - action_date_assign() met à jour les conditions de réglement (objet account.payment.term)
   - action_move_create() réalise les écritures dans les journaux comptables
   - action_number() met à jour les lignes comptables avec la référence de la facture
   - invoice_validate() met à jour l'état de la facture à "ouverte"

Nous détaillerons la partie "écriture comptable" dans le prochain article ...

Description technique du scénario fonctionnel (3/5) – détail du wizard

Dans la vue du wizard, qui s'affiche, 4 types d'avance sont possibles

Cette vue est dynamique car elle s'adapte au choix retenu.
Par exemple, si l'on choisit "Pourcentage", la vue va se modifier dynamiquement en ajoutant le champ de saisie "Montant anticipé"

Techniquement, cela repose sur l'utilisation de l'attribut "on_change" d'un champ et sur les possibilités dynamiques des vues.
Le positionnement de l'attribut "on_change" permet l'exécution d'une méthode au changement de valeur du champ.

Dans notre exemple, le libellé  "Que voulez vous facturer ?" est associé au champ "advance_payment_method"

Mode "développeur"

L'attribut "on_change" de ce champ permet d'appeler la méthode "onchange_method"

sale_make_invoice_advance.xml

Cette méthode permet ici d'affecter une valeur à "amount"

sale_make_invoice_advance.py

Concernant l'affichage dynamique des champs (et/ou libellés), cela est géré par l'attribut "invisible"

sale_make_invoice_advance.xml

Enfin, le click sur le bouton "Créer facture / Create Invoice" ...

Mode "développeur"

... déclenche l'appel de la méthode "create_invoices" ...

sale_make_invoice_advance.py

... qui appelle la méthode "_create_invoices"

sale_make_invoice_advance.py

 ... qui crée une nouvelle instance de l'objet "account.invoice" (facture)

La facture est créée dans l'état "brouillon" (attribut "state" avec valeur "draft").

Description technique du scénario fonctionnel (2/5) – appel de wizard

Tout d'abord, pour faciliter notre découverte technique, nous allons nous connecter d'une part avec un utilisateur configuré en langue anglaise et d'autre part, passer en mode "développeur".

Fonctionnellement, l'écran de création d'une facture enchaîne sur un autre écran permettant la création d'une avance.

Dans le 1er écran, nous allons pointer la souris sur le bouton "Create Invoice".

Mode "développeur"

L'objet manipulé étant "sale.order", nous en déduisons que la vue est "sale.order.form" .
Nous pouvons vérifier cette info en croisant le no de vue 495 affiché

et une lecture de la table "ir_ui_view" de la BD qui indique la vue "sale.order.form"

Nous allons ensuite dans le fichier source "sale_view.xml" (module "sale") dans la partie décrivant la vue "sale.order.form"

 Nous voyons à travers la séquence
<button name="%(action_view_sale_advance_payment_inv)d"
que le click du bouton "Create Invoice" va exécuter une action "wizard" "action_view_sale_advance_payment_inv" décrite dans le fichier "sale_make_invoice_advance.xml" (dans répertoire "wizard" du module "sale").

Cette action va afficher la vue "action_view_sale_advance_payment_inv" que l'on décrira plus tard.

Qu'est ce qu'un wizard dans OpenERP ?
Un wizard est une séquence de vues (écrans) qui interagissent avec le serveur OpenERP . Il peut être représenté ainsi :

Un wizard OpenERP est exécuté dans une fenêtre "modale". On ne peut revenir au menu OpenERP qu'en annulant ou en terminant les actions demandées dans le wizard.

Scénario fonctionnel "Facture avec avance" (1/5)

Aucune réponse ne m'ayant été apportée sur le problème d'écriture comptable dans le cas d'une avance client, je vais tenter de trouver la solution en profitant de cette recherche pour pénétrer un peu plus les entrailles du logiciel.

Avant de rentrer dans la technique, rappelons le scénario fonctionnel qui conduit au problème.

La création du devis suivie de la confirmation de la vente génère le bon de commande.

Nous demandons la création de la facture puis une avance de 25% de la commande. Cette facture est dans l'état "brouillon".

Nous allons ensuite dans le menu "comptabilité" pour valider la facture "avance"

La validation de la facture...

... conduit à inscrire les 2 écritures suivantes dans le journal des ventes

... avec le problème de l'écriture dans le compte "707100 - Marchandises ..." alors que l'on vend du service !!

Ecritures comptables suite à une avance : est ce normal ?

Je m'interroge sur les écritures comptables réalisées par OpenERP dans le cas d'avance client pour la vente d'un service.
Prenons le cas fictif de la vente d'un service (montant TTC de 23€) à un client avec demande d'avance de 25%.
Lors de la la validation de la facture d'avance, les écritures suivantes sont inscrites dans le journal des ventes :

Lors de la validation de la facture finale, les écritures suivantes sont inscrites dans le journal des ventes :

Je suis surpris que l'avance soit débitée sur le compte 707100 (Marchandises) au lieu du 706000 (Services).
Je tiens à préciser que j'ai bien configuré l'article avec comme compte de revenus "706000 Prestations de services".

J'ai posté cette demande dans le forum français de OpenERP

Nous verrons plus tard l'origine du problème.

Introduction à la comptabilité sous OpenERP

Ayant des connaissances sommaires en comptabilité, je souhaite utiliser OpenERP pour m'améliorer sur ce sujet et en particulier, pour mieux comprendre les écritures comptables dans les différents comptes et journaux.
En partant d'une nouvelle base vierge de toute donnée, je vais simuler une vente de service à un client et voir l'impact dans la comptabilité.

1ère étape : Préparation des données
Création nouvelle base de données

Installation du module "Ventes"

Ce qui entraîne aussi l'installation et la configuration minimale du module "Comptabilité"

Je vais ensuite dans la configuration du module "Comptabilité" dans laquelle je choisis le modèle "Plan comptable général (France)" et je coche le choix "Fonctionnalités de comptabilité complète ..."

 J'ajoute aussi la TVA par défaut pour les clients

Les journaux suivants sont créés par défaut

 Création d'un article "dépannage 1h"

Puis mise à jour de l'onglet "Comptabilité"

Création d'un client (nous remarquons que les infos "compte client" et "compte fournisseur" sont remplis par défaut)

2ème étape : vente d'une prestation "dépannage 1h" au client "J. Bigoud" (sans acompte)

Passons rapidement sur la création d'un devis/bon de commande puis sa validation pour arriver à la création de facture

Cliquons sur "Créer facture" puis à nouveau sur la fenêtre suivante

Enfin, validons la facture

=> Cette dernière action a déclenché la création de 3 écritures comptables consignées dans le journal des ventes

Le compte client est débité du montant total (dont TVA).
Les 2 autres comptes (Tva et "prestations de service") sont eux crédités.

Considérons ensuite que la prestation et le paiement ont été faits , nous cliquons sur "Enregistrer le règlement"

et que le règlement est de type "bancaire"

=> création de 2 écritures comptables dans le journal de Banque

Le compte client est crédité alors que le compte "banque" est débité.

PS: Pour en savoir plus sur la comptabilité générale, je vous invite à voir cette vidéo

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