Gestion des notes de frais avec Odoo : un cas pratique

Gestion des notes de frais avec Odoo : un cas pratique

À Anybox nous avons eu l'occasion de mettre en place une gestion des notes de frais pour une très grande association (l'APF), et nous utilisons nous-mêmes le module de notes de frais dans OpenERP 7 (hr_expense) . La gestion des dépenses des employés est un cas typique de projet qui semble simple mais qui apporte, comme toujours, son lot d'interrogations et de problématiques. Celles-ci sont ici de deux ordres

  • des problématiques comptables
  • de la gestion des processus de l'entreprise

Comptabilité des notes de frais

Au niveau comptable tout d'abord, se pose la question de savoir quels types de dépenses autoriser, comment les classifier, comment les orienter vers les bons comptes généraux, et éventuellement les ventiler en compta analytique. Une bonne pratique consiste tout d'abord à créer simplement des articles correspondant aux grandes catégories de dépenses autorisées. À titre d'exemple voici celles que nous avons créées dans notre propre ERP :

Référence Nom Type d'unité
NDFB Petites fournitures bureau Unit(s)
NDFD Frais déplacement Unit(s)
NDFH Frais hébergement Unit(s)
NDFI Petit matériel informatique Unit(s)
NDFK Frais kilométriques km
NDFP Frais postaux Unit(s)
NDFR Frais restauration Unit(s)
NDFT Frais télécommunication Unit(s)

L'exercice n'est pas du tout évident, car certaines dépenses ont de la TVA récupérable, d'autres non, le compte général n'est pas forcément toujours le même, certains frais peuvent être refacturés au client. L'intitulé doit aussi être suffisamment clair pour que l'employé n'hésite pas au moment de remplir sa note de frais.

Les comptes à utiliser sont variables selon les plans comptables et les pratiques, et doivent vous être indiquées par votre expert comptable. Par exemple pour les articles ci-dessus, on peut utiliser les comptes

  • 606400 (Fournitures administratives),
  • 625100 (Voyages et déplacement),
  • 626100 (Frais postaux),
  • 625700 (Réceptions),
  • 626200 (Frais télécom).

Mais attention, une même dépense de restauration peut aller soit en 625100 si elle s'inscrit dans le cadre d'une mission pour un client, ou bien en 625700 s'il s'agit d'un repas d'affaire. Dans ce cas il vaut mieux créer deux articles et bien les différencier par leur nom pour qu'il n'y ait pas d'ambiguïté.

Au niveau TVA, étant donné que l'employé remplit sa note de frais avec des montants TTC, c'est à dire en fonction de ce qu'il a lui-même payé, il faut créer des taxes de type « incluses dans le prix », si elle n'existent pas déjà après l'installation d'Odoo, pour que la charge affectée automatiquement à l'entreprise soit bien calculée comme le montant HT.

Il faut aussi considérer qu'il peut y avoir des limites sur la dépense. Par exemples pour les « petites fournitures de bureau » l'employé peut très bien faire passer un petit matériel informatique, à condition que le prix n'excède pas 500€HT, sinon il doit être enregistré comme une immobilisation.

Et enfin, il peut être utile d'activer la compta analytique pour les notes de frais, de façon que les employés puissent affecter leur dépense à un projet ou un contrat en particulier (nous rappelons ici qu'un projet ou contrat Odoo est aussi un compte analytique par héritage), et que ces dépenses puissent être automatiquement refacturées au client par l'intermédiaire des écritures analytiques.

Ingénierie des processus

L'autre problématique intéressante est celle du flux de traitement de la note de frais. Le cas standard d'Odoo est de laisser les employés remplir leurs dépenses pendant le mois, puis les confirmer pour demander leur approbation. La note de frais est ensuite validée par le responsable RH. Une fois que tout est validé, on peut générer les écritures comptables, qui vont enregistrer la dette de l'entreprise à l'employé via un compte de tiers. (À ce sujet, un problème présent dans OpenERP 7 est qu'il n'y a qu'un compte de tiers pour l'employé, un compte 401 ou 421, et qu'il est difficile sans un peu de code spécifique de différencier par exemple le compte des notes de frais de celui des rémunérations.).

Les étapes successives de traitement sont visibles dans le widget d'avancement. La première étape est la demande d'approbation de  la note de frais par l'employé (qui est la date de confirmation, en fait le champ date_confirm) :

Il se trouve que la date de confirmation est utilisée pour déterminer la date de la pièce comptable générée par la note de frais, et donc la période fiscale. Si les employés confirment leur note de frais un peu trop tard c'est-à-dire après la fin du mois, celle-ci est alors comptée sur la période fiscale suivante. Dans une entreprise comme la notre, c'est la même personne qui va faire l'ensemble des opérations, y compris la confirmation des notes de frais si les employés ont oublié de le faire. Ce mois-ci nous avons d'ailleurs été confrontés à un cas typique de problème de workflow métier, très facile à corriger grâce à la souplesse d'un ERP open-source comme Odoo : les notes de frais de juin étant confirmées en retard, elles étaient comptées pour le mois de juillet, mais le paiement était quand-même effectuée début juin. Ce n'est pas fondamentalement grave car il est possible de modifier les pièces comptables avant leur validation, mais ça aurait pu introduire un décalage d'un mois entre le paiement et son échéance, et fausser les statistiques mensuelles sur les notes de frais.

Sur ce cas précis, il y a en réalité trois problèmes à corriger :

  1. La responsable RH ne devrait pas pouvoir confirmer elle-même les notes de frais, mais seulement les valider : si les notes de frais ne sont pas confirmées par les employés, cela peut être dû à un oubli, mais aussi peut-être à une raison valable. La dépense doit être confirmée par celui qui l'a faite, et pas par quelqu'un d'autre.
  2. Les employés ne devraient pas confirmer leur note de frais en retard, mais devraient le faire en fin de mois.
  3. Le remboursement des dépenses ne devrait avoir lieu que sur la base des dettes enregistrées en compte de tiers, et non pas sur l'objet Note de Frais lui-même. En effet, entre la note de frais et le remboursement, il y a un certain nombre d'opérations, dont le travail éventuel de correction d'un comptable qui peut avoir modifié entre temps la pièce comptable correspondante.

Pour corriger ces erreurs et veiller à ce qu'elles ne se reproduisent pas, il suffit souvent d'apporter juste quelques petites corrections à l'ERP !

La correction du 1er point est une simple question de permission. Dans le workflow de l'objet expense, il suffit d'interdire la première transition par le responsable RH :

Dans Odoo, l'idéal est de faire ceci avec un peu de code Python, de façon à pouvoir afficher un message d'erreur clair et explicite sur la raison du blocage. Une précaution qui prend juste 1 minute à développer, et qui peut ensuite éviter des énervements, incompréhensions et pertes de temps.

Pour corriger le 2ème point, une bonne idée est d'envoyer automatiquement un e-mail de rappel 2 ou 3 jours avant la fin du mois, afin de demander à tout le monde de confirmer leurs dépenses (ou éventuellement juste à ceux qui en ont créé une). Ceci peut être réalisé grâce à une « action planifiée ».

Une autre idée serait d'utiliser les « actions automatisées » pour envoyer un mail d'explication et de rappel après la création de la note de frais. Dans tous les cas, il est préférable de réaliser ceci dans un module, en prenant soin d'écrire des tests automatisés en simulant le temps qui passe, grâce à notre module Python anybox.testing.datetime.

Enfin, le 3ème point est un peu plus difficile à corriger via l'ERP, car il implique encore plus les processus métier : quelle personne déclenche le remboursement effectif ? Quand ? Et en se basant sur quel montant ? Si on va jusqu'au bout de l'idée, le remboursement devrait être calculé et déclenché via l'ERP, grâce à des « ordres de paiement » transformés en fichier SEPA et envoyés à la banque. De cette façon il ne peut pas y avoir d'erreur de saisie, le remboursement correspond exactement à la dette enregistrée en compte de tiers, et on suit exactement le workflow prévu par l'ERP, moyennant quelques ajouts de modules communautaires pour la gestion du SEPA. C'est un peu plus lourd à mettre en place mais cela se justifie quand les volumes deviennent un peu plus important.

Conclusion

Un outil de gestion aussi souple qu'Odoo est un avantage important pour une entreprise qui souhaite mettre en place une amélioration continue des processus. Les retouches possibles sont nombreuses, faciles et rapides à réaliser et peuvent être appliquées au fil du temps, dès qu'on découvre un problème ou une optimisation possible. Ces améliorations doivent être envisagées quelle que soit l'application : gestion des notes de frais, gestion du recrutement, gestion des adhésions ou des cotisations d'une association ou n'importe quelle autre application web, et pourront fluidifier le fonctionnement de l'organisation.