Structurer et administrer le socle d'un système d'information de gestion Odoo

• Distinguer les trois natures de paramétrage : irréversible (devise de société, plan comptable, données de démonstration), coûteux à modifier (unités de mesure, structure des contacts, référencement produit), ajustable à tout moment (modèles de documents, listes de sélection).
• Conséquences d'une installation d'application : dépendances implicites, données créées automatiquement, caractère non réversible en pratique d'une désinstallation.
• Le piège de la base créée avec données de démonstration : identification, et pourquoi une base démo ne peut pas devenir une base de production.
• Activation et usage du mode développeur : lecture des métadonnées d'un enregistrement, identification des modèles et des champs techniques, accès au menu Technique.

• Fiche société : identifiants légaux, coordonnées, éléments repris automatiquement sur les documents émis.
• Devise de société et devises secondaires ; principe des taux de change et de leur mise à jour.
• Langues installées et langue par utilisateur : incidence sur les libellés de données (champs traduisibles) et sur les documents adressés aux tiers.
• Module de localisation comptable : plan de comptes, taxes, positions fiscales. Effet de cadrage sur tous les modules en aval.
• Multi-société : conditions dans lesquelles le multi-société est la bonne réponse, et cas où il complexifie inutilement (traitement des règles d'accès inter-sociétés).

• Typologie des utilisateurs : interne, portail, public. Incidence économique et fonctionnelle du choix.
• Architecture des habilitations : groupes → droits d'accès aux modèles (lecture / écriture / création / suppression) → règles d'enregistrement filtrant les lignes visibles.
• Principe fondamental : les habilitations sont cumulatives. Appartenir à plusieurs groupes additionne les droits ; un groupe ne retire jamais un droit accordé par un autre. Conséquence directe sur la méthode de conception d'une matrice d'habilitations.
• Lecture d'une règle d'enregistrement : domaine, portée globale ou par groupe, articulation avec le multi-société.
• Anti-modèles courants : attribution des droits d'administration des paramètres pour contourner un blocage ; création de groupes ad hoc non documentés ; comptes génériques partagés.
• Méthode de vérification : contrôler un profil par la connexion effective plutôt que par la lecture de la configuration.

Contacts

• Modèle unifié tiers : un même enregistrement peut porter les rôles client, fournisseur et contact.
• Structuration parent / enfant : société, contacts rattachés, adresses de livraison et de facturation. Effets sur les documents et sur les processus de vente et d'achat.
• Champs à valeur structurante : identifiants fiscaux, position fiscale, conditions de règlement, commercial responsable.
• Prévention et traitement des doublons : convention de nommage, contrôle à la saisie, fusion et ses limites.

Produits

• Nature du produit : bien stockable, consommable, service. Choix engageant qui conditionne la gestion des stocks et la comptabilisation.
• Catégorisation : catégorie de produit et son rôle dans les paramètres comptables et logistiques, distinction avec les étiquettes.
• Référence interne : rôle de clé fonctionnelle, règles de construction d'un plan de codification.
• Unités de mesure : catégorie d'unité, unité de référence, unité d'achat distincte de l'unité de vente ; caractère structurant du choix initial.
• Variantes de produit ou produits distincts : critères de décision et conséquences sur le catalogue et les stocks.

• Préparation du fichier source : encodage, séparateurs, formats de date et de décimales, colonnes obligatoires.
• Identifiant externe : principe et usage. Pourquoi un import sans identifiant externe est un import à usage unique, et pourquoi un import avec identifiant externe est rejouable et devient un outil de mise à jour.
• Renseignement des champs relationnels : par libellé, par identifiant externe, par identifiant de base — avantages et fragilités de chaque méthode.
• Ordonnancement d'une reprise : dépendances entre jeux de données (catégories avant produits, sociétés avant contacts rattachés).
• Lecture et diagnostic des erreurs d'import ; stratégie de test sur base dupliquée avant exécution en production.
• Contrôle post-reprise : comptages, vérification par échantillon, points de contrôle à définir avant l'import et non après.

À partir d'un cas d'entreprise fourni, le participant identifie les paramètres structurants à arbitrer avant ouverture de la base, et justifie chaque choix. Restitution collective et confrontation des arbitrages.

Le participant traduit trois profils métier en groupes et habilitations, les applique, puis vérifie par connexion effective ce que chaque profil voit et peut faire. L'atelier est conçu pour faire apparaître l'effet cumulatif des groupes.

Construction d'une arborescence de contacts (société, contacts rattachés, adresses distinctes) et d'un extrait de catalogue produits appliquant un plan de codification défini par le participant.

Import d'un fichier produits comportant des erreurs volontaires : diagnostic, correction, import avec identifiants externes, puis ré-import du même fichier modifié pour constater la mise à jour plutôt que la duplication.

Vérification croisée de la base configurée : un point de contrôle par bloc du module, formalisé sous forme de liste de vérification réutilisable en contexte professionnel.