🎯 Ce que tu vas apprendre
- Configurer un produit service
delivered_timesheetqui crée projet et tâche automatiquement à la confirmation du bon de commande - Générer une facture client précise depuis les heures réellement saisies en feuilles de temps
- Activer l'alerte upsell native CE (
service_upsell_threshold) pour repérer les dépassements forfait avant qu'ils ne creusent la marge
1. Trois missions, trois modèles de facturation
Les plans analytiques posés en F11·4 vont enfin servir au pilotage P&L réel : chaque ligne timesheet et chaque facture s'imputent désormais sur Projet × Département. Reste à brancher la facturation client. La question fondatrice côté comptabilité est simple : trois missions en cours, trois contrats différents — comment Odoo facture chacune ?
Premier modèle, régie pure : la mission « Audit Réseau ». 50 heures vendues à 1 500 DA/h, le client paye exactement ce qui est livré. Les consultants saisissent leurs heures, la comptabilité facture ce qui est validé. Deuxième modèle, forfait pur : la mission « App Métier ». 200 000 DA fixes, peu importe les heures réellement consommées par l'équipe de développement. Le risque côté marge est interne. Troisième modèle, mix forfait + régie : la mission « Déploiement WiFi ». Un forfait initial absorbe les premières heures, puis chaque heure supplémentaire bascule sur une ligne « hors-forfait » facturée à 1 800 DA/h. La technicienne réseaux assure le terrain.
Trois contrats, un seul setup Odoo. La responsable comptable va configurer trois produits service distincts. Chacun porte une combinaison précise de service_policy et service_tracking qui détermine tout le comportement aval.
2. Le produit service delivered_timesheet — la pierre angulaire
Direction Inventaire > Produits > Nouveau. Création du premier produit, Consulting Audit Réseau, type Service. Onglet Ventes ouvert. Trois champs verrouillent le comportement : service_policy='delivered_timesheet' (facturé sur les heures livrées), service_tracking='task_global_project' (une tâche se crée automatiquement dans un projet existant à la confirmation du SO), et le projet cible pointe sur le projet Audit Réseau — l'un des trois projets créés en F11·1. Unité de mesure forcée à Heures, prix unitaire 1 500 DA.
service_policy='delivered_timesheet' (facturé sur heures livrées), service_tracking='task_global_project' (tâche créée à la confirmation SO dans le projet Audit Réseau), prix unitaire 1 500 DA/heure. Le compteur affiche 50,00 Heures vendues et 0,00 Heures achetées — soit le forfait initial commandé.📖 Définition — service_policy & service_tracking
Deux champs jumeaux qui définissent le contrat. service_policy dit quand facturer : delivered_timesheet = sur les heures livrées (timesheets propagent qty_delivered), ordered_prepaid = sur les heures commandées (forfait facturé à la confirmation), delivered_milestones = sur jalons validés. service_tracking dit quoi créer côté projet à la confirmation du SO : task_global_project = juste une tâche dans un projet pré-défini, task_in_project = projet et tâche créés ensemble, project_only = juste un projet. La combinaison delivered_timesheet + task_global_project est le couple roi pour la facturation au temps sur un projet existant.
La fiche est ensuite clonée deux fois. Le deuxième produit, Forfait App Métier, bascule en service_policy='ordered_prepaid', prix 200 000 DA, unité Unité(s) — le client paye le forfait à la confirmation, peu importe les heures. Le troisième, Heures hors-forfait WiFi, revient en delivered_timesheet mais avec un champ supplémentaire activé : service_upsell_threshold=0.8. Trois produits, trois logiques de facturation, prêts à être posés sur un devis.
3. Le SO confirmé déclenche projet, tâche, et lien timesheet — tout automatique
À la confirmation du bon de commande, Odoo enchaîne une mécanique invisible mais critique. La comptabilité saisit le devis « Audit Réseau » : une ligne Consulting Audit Réseau, quantité 50, prix 1 500. Confirmer. Le SO devient S00019 et passe à l'état sale. En coulisse, le moteur sale_project lit chaque ligne, repère service_tracking != 'no', et exécute la suite. Pour la mission « Audit Réseau », le service_tracking='task_global_project' déclenche la création d'une tâche dans le projet Audit Réseau — pas de nouveau projet, juste une tâche reliée. Sur le SO, deux smart buttons apparaissent en haut : Projet et Tâches. Sur la tâche créée, le champ sale_line_id pointe vers la ligne du SO.
Conséquence directe : quand un consultant saisit ensuite une feuille de temps sur cette tâche (ou sur n'importe quelle tâche du projet Audit Réseau), le timesheet hérite automatiquement de so_line. Le champ se remplit seul, sans intervention humaine. La ligne account.analytic.line créée par le timesheet pousse alors son unit_amount dans le calcul de qty_delivered de la SO line, via le compute _compute_qty_delivered du module sale_timesheet.
Pour la mission « Audit Réseau », ce sont les 26 heures déjà saisies en F11·3 (16h responsable IT + 10h technicienne réseaux) qui se retrouvent automatiquement comptabilisées comme livrées dès la confirmation du SO S00019. Mêmes mécaniques pour S00020 « App Métier » (forfait, projet App Métier) et S00021 « Déploiement WiFi » (heures hors-forfait, projet WiFi). Trois SO confirmés, trois projets reliés, propagation automatique. Zéro double saisie.
4. Générer la facture client depuis les heures livrées
Ouverture du SO S00019. Sur la ligne Consulting Audit Réseau s'affichent quatre quantités clés : 50,00 commandées, 26,00 délivrées, 0,00 facturées, 26,00 à facturer. C'est exactement la mécanique attendue : qty_to_invoice = qty_delivered − qty_invoiced. Le moteur de facturation et de paiements Odoo est détaillé dans l'article dédié ; ici l'angle est précis — générer la facture client depuis les heures livrées d'un SO au temps.
Clic sur Créer une facture. Le wizard sale.advance.payment.inv propose trois options : Facture régulière (par défaut), Acompte (pourcentage), Acompte (montant fixe). La première option facture exactement qty_to_invoice × price_unit — soit 26 × 1 500 = 39 000 DA. Validation. Une facture brouillon FAC/2026/00002 est créée. Vérification de la ligne, de la distribution analytique (déjà renseignée automatiquement sur Audit Réseau + IT-Réseaux grâce au mécanisme F11·4), puis clic Confirmer. La facture passe à l'état Comptabilisé. TVA 19 % = 7 410 DA. Total TTC 46 410 DA.
Côté SO, le compteur qty_invoiced passe à 26,00, qty_to_invoice retombe à 0. Les 24 heures restantes (50 commandées − 26 facturées) feront l'objet d'une seconde facture quand la suite de la mission aura été livrée.
⚠️ Piège v19 — produit mal configuré, facture vide
Sans service_policy='delivered_timesheet' sur le produit, le compute _compute_qty_delivered ne s'exécute pas. qty_delivered reste à 0 même après vingt heures de timesheet. Conséquence : Créer une facture propose une ligne à zéro et la facture sort vide. Vérifie le couple service_policy + service_tracking sur chaque produit service avant d'envoyer le devis client.
5. Forfait + dépassement — l'alerte upsell native
Le SO S00021 « Déploiement WiFi » mélange forfait et régie. Mais que se passe-t-il quand un forfait pur dérape ? Sur la mission « App Métier » — un forfait à 200 000 DA — au-delà d'un certain volume d'heures, la marge fond. Odoo CE intègre nativement un mécanisme d'alerte : le champ service_upsell_threshold sur la fiche produit service.
Le principe est simple. Sur un produit service_policy='ordered_prepaid' (ou sur la ligne delivered_timesheet mix), le seuil service_upsell_threshold représente un pourcentage de qty_delivered / qty_ordered au-delà duquel Odoo déclenche automatiquement une activité commerciale sur le SO. Valeur par défaut : 1.0 (100 % — déclenchement à la livraison complète). Réglée à 0.8 sur le produit Heures hors-forfait WiFi, l'alerte tombe dès 80 % de consommation. Le commercial reçoit la notification dans son tableau d'activités, prend contact avec le client, propose un avenant. La sortie de route est anticipée.
💡 Astuce — l'alerte d'upsell, seul mécanisme natif CE de dépassement
Pas d'alerte mail automatique, pas de notification chatter projet sans configuration manuelle. Le seul levier natif CE pour anticiper un dépassement de forfait est service_upsell_threshold côté produit. Réglé à 0.8 (80 %), il déclenche une activité commerciale sur le SO avant la sortie de route. À renseigner systématiquement sur chaque produit service forfait pour éviter de découvrir le débordement à la facture finale.
Pour la mission « Déploiement WiFi », le réglage à 0.8 sur Heures hors-forfait WiFi sert de garde-fou. Si le quota forfaitaire est consommé rapidement par les heures terrain, le commercial est alerté à temps pour cadrer la suite. Pas besoin de module additionnel, pas de script cron custom — juste un champ produit.
6. La marge projet sur la Vue Mise à jour
Direction la fiche projet Audit Réseau. La section Profitabilité n'est pas dans le form standard du projet. Elle se trouve derrière le bouton Dashboard en haut à droite — un smart button qui ouvre la Vue Mise à jour (project.update). Là, le suivi hebdomadaire S20 s'affiche : statut En bonne voie, Progression 52 % (26h livrées sur 50h vendues), Date d'échéance 13 mai.
📖 Définition — Vue Mise à jour
La section Profitabilité du projet n'apparaît pas dans le form standard. Elle est rendue dans la Vue Mise à jour, accessible via le bouton Dashboard sur la fiche projet. Cette vue ouvre un enregistrement project.update qui synthétise statut, progression, smart buttons (Tâches, Feuilles de temps, Factures clients, Burndown Chart) et jalons. C'est le tableau de bord projet officiel en CE.
Quatre smart buttons résument l'activité projet : Tâches 26 Heures, Feuilles de temps 26 Heures, Factures clients 1, Burndown Chart. La lecture est immédiate : 26h saisies, une facture client générée, mission livrée à un peu plus de la moitié. La progression 52 % est calculée mécaniquement sur le ratio qty_delivered / qty_ordered de la SO line liée.
Limite à connaître : la Vue Mise à jour n'affiche pas la marge brute chiffrée. Aucune ligne Marge = Revenus − Coûts ne s'y trouve nativement. Pour obtenir la marge réelle, le détour reste le pivot Écritures analytiques vu en F11·4 : filtrage par account_id = Audit Réseau, mesure Montant, somme algébrique des charges (timesheets valorisés + factures fournisseurs ventilées, en négatif) et des revenus (factures clients, en positif). Le solde affiché = marge brute du projet. C'est manuel mais ça fonctionne en pur CE.
7. Les trois KPI à lire chaque semaine
Trois indicateurs suffisent à piloter la rentabilité d'un projet de services en CE. La revue hebdo entre direction et comptabilité se concentre sur ces trois lignes, chaque vendredi.
KPI 1 — Taux facturable
Ratio des heures liées à un SO sur le total des heures saisies. Semaine 19 : 26h sur « Audit Réseau » (liées au SO S00019), 16h sur « App Métier » (liées au SO S00020 forfait). Soit 42h facturables sur 42 saisies = 100 % de taux facturable. Un projet sain affiche > 80 %. En-dessous, soit les consultants saisissent du temps sur des tâches internes non commercialisées, soit la mécanique service_tracking n'a pas relié le timesheet à un SO.
KPI 2 — Jours vendus / livrés
Sur le SO S00019, 50h vendues, 26h livrées. Soit 52 % de consommation. À croiser avec le calendrier de la mission. Mission prévue sur un mois : à mi-parcours, 52 % consommé, le ratio est sain. Mission prévue sur trois semaines : 52 % consommé à une semaine de la fin, alerte rouge. La Vue Mise à jour (§6) affiche directement ce pourcentage.
KPI 3 — Marge brute par projet
Revenus facturés (46 410 DA TTC sur FAC/2026/00002, soit 39 000 DA HT) minus coûts directs (timesheets valorisés × hr_employee.timesheet_cost + factures fournisseurs ventilées sur le projet — sur « Audit Réseau » les 12 000 DA Cisco de F11·4). Calcul à la main : 39 000 − (26 × coût horaire moyen) − 12 000 = marge brute. Si négatif, la mission perd de l'argent.
💡 Astuce KPI — le taux facturable se construit en pivot
Aucun champ natif CE n'affiche directement le taux facturable. Mais le pivot Écritures analytiques fait le travail. Filtre so_line != False versus total des écritures sur la période. Mesure unit_amount. Bascule en pivot, groupé par projet. Le ratio se lit en un coup d'œil. À industrialiser en favori partagé pour les revues hebdo.
8. La limite CE — et ce que la saison EE va débloquer
Le pilotage P&L est maintenant complet en pure Community : produits services configurés, SO confirmés, facturation au temps déclenchée, marge lisible en pivot. Pour franchir le palier suivant — anticipation, capacité, multi-projets coordonnés — il faudra l'édition Enterprise. Aucune extension communautaire ne remplit ce périmètre nativement.
🔵 Ce que la prochaine saison Enterprise va débloquer
Cette saison S11 a installé le pilotage projet complet en Community : structure, tâches, timesheets, analytique, facturation au temps, marge. Pour franchir le palier suivant — anticipation, capacité, multi-projets coordonnés — il faudra l'édition Enterprise. Aucune extension communautaire ne remplit ce périmètre nativement.
Ce que la saison EE à venir va couvrir :
- Vue Gantt (
<gantt>) sur Project, Task, Timesheet — la visualisation temporelle des dépendances et des charges, totalement absente du CE. - Module Planning complet — dispatch des ressources, capacité par employé, allocation glissante, conflits détectés automatiquement.
project_forecast— prévisionnel d'occupation par ressource, courbe d'occupation prévue versus réelle.- Budget analytique multi-période — budget vs réalisé par compte analytique avec alertes de dépassement automatiques.
- Dispatch ressources multi-projets — vue globale agence, ré-affectation drag&drop, simulation de scénarios.
- Rapport Rentabilité enrichi — marges chiffrées par projet, comparaison période, projection sur le reste à faire.
La saison EE traitera tout cela avec la même rigueur CE/EE — mêmes missions repères, même décor, juste les bonnes briques. La saison boucle où elle a commencé — démarrer ses projets en CE — avec maintenant un pilotage P&L complet à la clé.
9. Saison S11 complète — prochain palier : Enterprise
Cinq articles, cinq briques. F11·1 a posé la structure projet, kanban, équipes. F11·2 a sécurisé les tâches et leurs dépendances. F11·3 a câblé les feuilles de temps du chrono à la facturation. F11·4 a démystifié l'analytique multi-plans et la distribution. F11·5 boucle la boucle avec la facturation au temps et le pilotage de la marge. Le pipeline complet Idée → Devis → Livraison → Facture → Marge fonctionne maintenant en pur Odoo Community.
Pour franchir le palier — Gantt, Planning, forecast, budget multi-période, dispatch ressources — la saison Enterprise prend le relais. Pour être prévenu de son ouverture, l'inscription se fait via la newsletter OdooSkills.
Voir aussi dans ce hub Projet & Services
F11·5 — Facturer au temps & rentabilité projet
sale_timesheet, dashboard marge, KPI.
Articles complémentaires
#45 — Les ventes dans Odoo 19
Devis et bons de commande — l'amont de la facturation au temps passé.
#48 — Facturation et paiements dans Odoo 19
Facturation et paiements — pipeline complet O2C, suite logique de F11·5.