Archives par mot-clé : Exemple

ODOO 8 – exemple de gestion multi-sociètés

Non classé, ,

Objectif
Gestion d'un réseau de franchises qui propose des services à des particuliers.

Nous nous limiterons à un périmètre fonctionnel restreint : gestion des ventes et comptabilité.

Les franchises sont autonomes et indépendantes les unes des autres.
La socièté mère via un coordinateur, a un accès total aux franchises et en particulier, peut réaliser des opérations pour le compte d'une franchise (création client, devis, facture ...).
Ces opérations doivent être ensuite accessibles en accès total par la franchise concernée ... sans que les autres franchises y aient accès.

Description
Nous partons d'une base ODOO v8 vierge ...

- Installation des modules gestion des vents (sales) et comptabilité France (I10n_fr)
- Installation de toutes les fonctions "comptabilité"

 - Configuration de l'utilisateur "Administrator" à Multi-sociètés (menu Configuration>Utilisateurs)

- Création des sociètés SM (Socièté Mère), Franchise1 et Franchise2

- Rattacher les franchises à la société mère

- Création du plan comptable pour chaque franchise

- Création d'un utilisateur par franchise, rattaché à sa franchise et avec comme sociètés autorisées SM et Franchise1 (ou Franchise2) et droits d'accès "responsable ventes" et "comptable" :

- Création du coordinateur de la socièté mère avec comme sociètés autorisées Franchise 1 et Franchise 2 en plus de SM et droits d'accès "responsable ventes" et "responsable finances" :

- Création de l'article "Service1" rattaché à aucune socièté

Remarque: ne pas cocher l'option "gérer plusieurs sociétés" dans "paramètres généraux" (cette option est nécessaire pour des produits "stockables", elle n'est pas nécessaire pour des services)

>>> Il faut maintenant intervenir sur les règles d'enregistrement (record rules) pour modifier les droits d'accès sur certains objets.

Ces règles vont permettre à une franchise d'accèder totalement aux objets créés par le coordinateur de la socièté mère pour son compte.

Pour cela, il faut se rendre dans le menu "Configuration>Technical>Sécurité>Règles sur les enregistrements" :

- Devis/Bon de commande :
Modifier la règle "Sales Order multi-company" avec la valeur :
['|','|',('company_id','=',False),('company_id','child_of',[user.company_id.id]),('partner_id.parent_id.company_id','in',[user.company_id.id])]

 - Facture
Modifier la règle "Invoice multi-company" avec la valeur :
['|','|',('company_id','=',False),('company_id','child_of',[user.company_id.id]),('commercial_partner_id.company_id','in',[user.company_id.id])]

- Client
Modifier la règle "res.partner company" avec la valeur :
['|','|',('company_id','=',False),('company_id','child_of',[user.company_id.id]),('parent_id.company_id','in',[user.company_id.id])]

- Détail facture (account.move)
Modifier la règle "Account Entry" avec la valeur :
['|','|',('company_id','=',False),('company_id','child_of',[user.company_id.id]),('partner_id.company_id','in',[user.company_id.id])]

Bien entendu, nous nous limitons à ces quelques règles car nous n'utilisons ici que les 2 modules "ventes" et "comptabilité". 
Il faudrait effectuer le même type de modification sur d'autres règles si d'autres modules étaient installés.

Pour terminer, précisons que ces règles peuvent être modifiées directement en base de données sans risque d'écrasement par un update de module, grâce à la clause "data noupdate=1" présente à la création des règles :

extrait fichier "sale_security.xml"

 

Création auto-entreprise – réaliser un achat ou une vente (6/6)

Non classé,

Je ne documente que l'exemple d'un achat  car la vente est quasiment identique.

Nous allons réaliser l'achat du nom de domaine pour le site web (ex: monae79.fr).

Cet achat étant de  fréquence annuelle, nous allons créer un article

... et le fournisseur

puis créer un bon de commande

ensuite, confirmer la commande, réceptionner puis valider la facture

Les 2 écritures comptables suivantes ont été réalisées automatiquement dans le journal des achats

Nous payons ensuite la facture

... ce qui crée 2 nouvelles écritures dans le journal de banque

Création auto-entreprise – apport personnel (4/6)

Non classé,

Cet article peut être considéré comme un "brouillon" car je ne suis pas sûr que la solution proposée soit la bonne. Avis aux experts en comptabilité pour me corriger !!

Avant de démarrer l'activité de l'auto-entreprise, il est généralement nécessaire de réaliser un apport personnel pour pouvoir payer les 1er frais.
Dans notre cas, nous allons réaliser un apport personnel de 1000 euros.

Aller dans le menu "Comptabilité/écritures comptables", sélectionner le journal de notre compte bancaire (que nous avons créé précédemment) et saisir les 2 écritures suivantes :

Nb : une auto-entreprise n'ayant pas légalement de capital, nous affectons l'apport personnel au compte de l'exploitant.

Création auto-entreprise – initialisation de la comptabilité (3/6)

Non classé,

Tout d'abord, précisons 2 particularités comptables d'une auto-entreprise :

Installer le module "comptabilité"

La fenêtre suivante s'affiche, choisir le package "France - comptabilité"

La fenêtre suivante s'affiche, cliquer sur "appliquer" (nous reviendrons ensuite sur les taux de taxe)

Le module "comptabilité est alors installé

Se rendre ensuite dans le menu "comptabilité/configuration/taxes pour créer des taxes à 0% dédiées aux auto-entreprises.

Rechercher la taxe dont le code est "EXO-0" puis dupliquer cette taxe

Renommer le nom et le code de la taxe

Rechercher la taxe dont le code est "IMPORT-0" puis dupliquer cette taxe

Renommer le nom et le code de la taxe

Se rendre dans le menu "configuration/comptabilité" et renseigner ces 2 taxes nouvellement créées dans les 2 champs "taxes ... par défaut"

Création auto-entreprise – création BD et société (2/6)

Non classé,

Nous partons d'une installation OpenERP 7.0 déjà réalisée sous Debian 7.

Créer une nouvelle base de données

Affecter le droit "caractéristiques techniques" à l'utilisateur "admin"

Renseigner les informations concernant la société

Créer le compte courant bancaire

Les informations concernant le compte bancaire apparaîtront dans certains documents  (devis, facture ...).
La valorisation du champ "code de l'identification bancaire" (=code SWIFT) conduit à créer un nouveau journal des comptes lié à ce compte bancaire (pas nécessaire dans le cas d'une auto-entreprise).

Appli YD – filtrage/recherche des adhérents (7/7)

Non classé,

Pour conclure, j'aimerai apporter 2 améliorations :

  1. être sûr de n'afficher que les adhérents dans la vue "adhérent"
  2. aménager la recherche des adhérents

1 - Affichage uniquement des adhérents
Notre notion d'adhérent étant héritée de l'objet "Partner" qui peut aussi bien désigner un client, un fournisseur, un employé qu'un adhérent, il faut s'assurer que nous n'affichons dans la vue "adhérent" que des adhérents.
Pour cela, nous allons ajouter un attribut à l'objet 'Partner' qui précisera notre notion d'adhérent.

Nous allons modifier la classe "yd_member" en ajoutant cet attribut appelé "ydmember"

extrait fichier "yd.py"

 ... puis la vue en ajoutant un filtre "... domain ..." sur cet attribut

extrait fichier "yd_view.xml"

2- aménager la recherche des adhérents

... en ajoutant un filtre "Tarif réduit"

... en recherchant soit par le nom de l'adhérent, soit par le nom des cours

Pour cela, nous ajoutons une vue spécifique de type "search"

extrait fichier "yd_view.xml"

et nous la référençons dans l'action par la ligne "... search_view_id ..."

extrait fichier "yd_view.xml"

Appli YD – envoi de courriel – 3ème version (6/7)

Non classé,

L'objectif de cette nouvelle version est de pouvoir créer et envoyer un courriel à un ou plusieurs adhérents.
Nous allons tout d'abord ajouter le module "mail" à notre configuration.

Pour cela nous modifions notre fichier __openerp__.py en ajoutant "mail" dans les dépendances

Cela a comme conséquence de :

  • ajouter "messagerie" dans le menu général OpenERP

  • ajouter le choix "mass mailing"  lorsque l'on sélectionne un ou plusieurs adhérents dans le menu "tree"

Ensuite nous allons dans le menu "Configuration/Paramètres généraux" pour paramétrer notre serveur sortant de courriels

En théorie, ces opérations auraient dû suffire pour permettre d'envoyer des mails grâce au wizard "mail.compose.message" appelé par le choix "Mass Mailing"

Malheureusement, il y a un bug (corrigé en V8) dans la version actuelle et nous appliquerons le contournement proposé ici
Ce qui se traduit par la création du modèle de courriel suivant

en précisant dans l'onglet "avancé", notre serveur de courriels sortant

Ensuite, dans le formulaire d'envoi (wizard), il faut utiliser le modèle "YD bug send mail" créé pour l'occasion

Appli YD – gestion des adhérents – héritage de classe (5/7)

Non classé,

Dans la 1ère version de l'appli, nous avons utilisé une variante d'héritage appelé "héritage de prototype" (à droite sur le schéma ci-dessous) qui consiste à dupliquer l'objet "hérité", en l'occurence "Partner".
Cela interdit ensuite de réutiliser les vues, wizard, workflow (etc ...) existants en lien avec l'objet d'origine.

Pour cette 2ème version de l'appli, nous utilisons la variante "héritage de classe".
Elle nous donnera la possibilité de réutiliser la vue "form" de l'objet Partner et ultérieurement, le wizard d'envoi de mail.
Nous nous attardons uniquement sur les fichiers "yd.py" et "view".

Dans le 1er fichier, seule la valeur de "_name" est modifiée.

impact dans fichier "yd.py"

Dans le 2ème fichier , 2 possibilités :
  1- Pas d'héritage de vue :
pour la vue "form", on modifie la valeur "model" avec "res.partner"  et on rend cette vue (eval ... priority...) plus prioritaire que la vue par défaut "view_partner_form"

extrait fichier "yd_view.xml"

   ... et pour la vue "tree"

extrait fichier "yd_view.xml"

  2- héritage de la vue "view_partner_form" :
avec modifications apportées pour supprimer des champs et onglets affichés dans l'objet de base et ajouter les champs spécifiques à "yd.member" (cf documentation officielle)

extrait fichier "yd_view.xml"

Personnellement dans notre cas, les modifications par rapport à la vue "view_partner_form" étant assez importantes, je préfère ne pas utiliser l'héritage de cette vue.

Appli YD – gestion des adhérents – 1ère version (4/7)

Non classé,

Passons maintenant à la gestion des adhérents.
Nous avons uniquement à modifier des fichiers existants :

  1. le fichier view
  2. le fichier yd.py
  3. le fichier csv de droits d'accès
  4. le fichier de traduction

Pour chacun des 4 fichiers, voici les modifications apportées :

Lignes ajoutées dans fichier "yd_view.xml" (1/2)
Lignes ajoutées dans fichier "yd_view.xml" (2/2)
Lignes ajoutées dans fichier "yd.py"

Lignes ajoutées dans fichier "ir.model.access.csv"

 Le fichier de traduction "fr.po" lui, a été regénéré selon la procédure habituelle

Après ces modifications, nous arrivons au résultat suivant :