Réparation : types, modèles, reconditionnement et temps passé

L'application Réparation d'Odoo consomme des pièces et retourne un appareil. Elle ne connaît ni les types de réparation, ni la main-d'œuvre facturable, ni le temps passé, ni le produit reconditionné issu d'une remise en état.

Dix-huit modules communautaires font de la réparation une activité pilotable, et terminent le dépôt repair.

Résumé

Quatre modules traitent la structure : des réglages généraux pour l'application, des types de réparation, la destination du produit selon le type, et des modèles d'ordre de réparation évitant de ressaisir une intervention courante.

Quatre modules traitent l'organisation du travail : des groupes d'ordres synchronisés entre eux, leur extension aux services, le réordonnancement des lignes, et la sélection du produit par son numéro de lot.

Quatre modules traitent le stock et le produit : la création d'un produit reconditionné pendant la réparation, le lien au stock, le transfert du produit réparé vers un autre emplacement directement depuis l'ordre, et la création de contrôles qualité depuis un ordre.

Six modules enfin traitent l'argent et le temps : les services facturables devenant lignes de commande, la répartition analytique sur l'ordre, la ventilation des coûts de temps par cette répartition, les feuilles de temps, une vue calendrier par date planifiée, et un bouton de réparations sur la fiche contact.

L'essentiel

• Des types de réparation, et la destination du produit selon le type.
• Des modèles d'ordre de réparation.
• Des groupes d'ordres synchronisés entre eux.
• La sélection du produit par son numéro de lot.
• Un produit reconditionné créé pendant la réparation.
• Des services facturables devenant lignes de commande.
• Les feuilles de temps et la ventilation analytique de leur coût.
• Des contrôles qualité créés depuis un ordre.

Ce que ces modules ajoutent à l'instance

Les menus : Réparations ▸ Configuration ▸ Settings, Repair Orders Templates et Repair Groups.

Structurer l'activité

Une réparation sous garantie, une réparation payante, un diagnostic sans suite et une remise en état pour revente sont quatre activités différentes, avec quatre destinations de produit et quatre traitements financiers. Le standard les traite toutes comme un ordre de réparation.

repair_type ajoute des types de réparation, et repair_type_product_destination définit la destination du produit selon le type — retour au client, mise au rebut, stock de reconditionné. Son README est réduit à sa catégorie.

base_repair_config fournit les réglages généraux de l'application, sous Réparations ▸ Configuration ▸ Settings. Quatre modules en dépendent.

repair_order_template permet de créer un ordre depuis un modèle, avec son référentiel sous Repair Orders Templates. Sur une activité où les mêmes interventions reviennent — remplacement d'une pièce d'usure, révision standard —, c'est le gain le plus direct.

Organiser le travail

repair_order_group (version 18.0.2.0.1) permet de grouper plusieurs ordres de réparation et de les maintenir synchronisés, avec un référentiel de groupes. repair_order_group_services étend le groupement aux services.

Le groupe d'ordres répond au cas du lot : un client renvoie quinze appareils du même modèle. Les traiter comme quinze ordres indépendants multiplie la saisie ; les grouper permet de décider une fois et de propager.

• repair_order_line_sequence permet de réordonner les lignes d'un ordre — l'ordre des opérations compte dans une intervention.
• repair_order_product_by_lot permet de sélectionner le produit par son numéro de lot, et non par sa référence.

La sélection par lot est le geste naturel au comptoir d'un atelier : l'appareil porte un numéro de série, et c'est par là qu'on le retrouve — pas par le nom du modèle.

Le stock, le reconditionné et la qualité

repair_refurbish permet de créer un produit reconditionné pendant la réparation : l'appareil entre comme produit défectueux et sort comme produit reconditionné, référence distincte.

La distinction entre le produit neuf et le produit reconditionné n'est pas cosmétique : ce sont deux références, deux prix, deux garanties et deux valorisations de stock. Les confondre fausse la marge et le stock disponible à la vente.

• repair_stock relie la réparation au stock. Son README est réduit à sa catégorie.
• repair_picking_after_done permet de transférer le produit réparé vers un autre emplacement directement depuis l'ordre. Il dépend des réglages généraux, du lien stock, des types de réparation et de la destination par type — quatre modules pour un geste.
• repair_quality_control permet de créer des contrôles qualité depuis un ordre de réparation, en s'appuyant sur le module de contrôle qualité du stock.

Le contrôle qualité après réparation est ce qui distingue un atelier d'un bricolage : vérifier avant de rendre, et garder la trace de la vérification.

Facturer et mesurer

repair_service (version 18.0.1.2.4, la plus mûre du dépôt) ajoute des services aux ordres de réparation, de façon à ce qu'ils deviennent des lignes de commande de vente.

Sans ce module, une réparation ne facture que des pièces. La main-d'œuvre — qui représente souvent la majorité du prix — doit être ajoutée à la main sur une commande séparée, et la rentabilité d'une intervention se calcule de tête.

• repair_timesheet ajoute les feuilles de temps à l'ordre de réparation. Son README est réduit à sa catégorie.
• repair_analytic ajoute une répartition analytique sur l'ordre.
• repair_analytic_timesheet ventile les coûts de temps selon cette répartition analytique.

Les trois ensemble donnent le coût réel d'une intervention : pièces consommées, temps passé valorisé, imputé sur l'axe d'analyse choisi. C'est ce qui permet de savoir si une réparation sous garantie coûte plus que le remplacement.

• repair_scheduled_date_calendar_view ajoute une vue calendrier des ordres par date planifiée — la charge de l'atelier, vue comme un planning.
• partner_repair_button ajoute un bouton réparations sur la fiche contact.

L'analytique et ses répartitions sont traitées dans la comptabilité analytique reprise.

Limites connues

• Trois modules ont un README réduit à leur catégorie : repair_type_product_destination, repair_stock et repair_timesheet.
• repair_picking_after_done dépend de quatre modules : réglages, stock, types et destination par type. La chaîne est à installer entière.
• repair_quality_control dépend du module de contrôle qualité du stock : une application de plus à paramétrer.
• Le produit reconditionné est une référence distincte : son prix, sa garantie et sa valorisation sont à définir avant d'en créer un.
• Les groupes d'ordres synchronisent : une modification se propage, y compris une erreur.
• repair_service crée des lignes de commande de vente : la facturation de la main-d'œuvre suppose un circuit commercial, pas seulement un atelier.
• Les feuilles de temps de réparation dépendent de l'application de temps (hr_timesheet), et leur ventilation analytique de deux modules supplémentaires.

Identité technique

Les dix-huit modules viennent du dépôt OCA repair, branche 18.0 — dont tous les modules sont désormais documentés ici —, tous en licence AGPL-3. Les dépendances : repair pour tous, base_repair_config pour quatre d'entre eux, analytic et hr_timesheet pour les coûts et le temps, quality_control_stock_oca pour la qualité.

Voir aussi planifier et exécuter la maintenance et la comptabilité analytique reprise.

Questions fréquentes

Peut-on facturer la main-d'œuvre d'une réparation dans Odoo ?

Pas en standard : une réparation ne facture que des pièces. repair_service ajoute des services à l'ordre, qui deviennent des lignes de commande de vente. Sans lui, la main-d'œuvre — souvent la majorité du prix — s'ajoute à la main sur une commande séparée et la rentabilité se calcule de tête.

Peut-on gérer des produits reconditionnés issus de réparations ?

Oui, avec repair_refurbish : l'appareil entre comme produit défectueux et sort comme produit reconditionné, référence distincte. Ce n'est pas cosmétique — deux références, deux prix, deux garanties, deux valorisations. Les confondre fausse la marge et le stock disponible à la vente.

Peut-on retrouver un appareil par son numéro de série au comptoir ?

Oui : repair_order_product_by_lot permet de sélectionner le produit par son numéro de lot plutôt que par sa référence. C'est le geste naturel en atelier — l'appareil porte un numéro de série, et c'est par là qu'on le retrouve.

Peut-on traiter quinze appareils renvoyés par le même client en une fois ?

Avec repair_order_group, oui : plusieurs ordres groupés et maintenus synchronisés, avec repair_order_group_services pour les services. Attention, la synchronisation propage aussi les erreurs.

Comment connaître le coût réel d'une intervention ?

Trois modules s'y combinent : repair_timesheet (temps passé), repair_analytic (répartition analytique sur l'ordre) et repair_analytic_timesheet (ventilation des coûts de temps selon cette répartition). C'est ce qui permet de savoir si une réparation sous garantie coûte plus que le remplacement.

Se faire accompagner

La réparation est l'activité où le coût réel est le plus souvent inconnu : les pièces se suivent, le temps non, et la main-d'œuvre se facture au forfait parce que personne ne sait ce qu'elle coûte. Trois modules suffisent à le savoir.

Nous posons donc le temps et l'analytique avant le reste, puis les types de réparation — parce qu'une réparation sous garantie, une payante et une remise en état pour revente ne se traitent ni ne se mesurent de la même façon. Voir les prestations d'Atalios Consulting ou demander un rappel.

Pour aller plus loin

• Planifier et exécuter la maintenance
• La comptabilité analytique reprise

En résumé

L'application Réparation d'Odoo consomme des pièces et retourne un appareil. Elle ne connaît ni les types de réparation, ni la main-d'œuvre facturable, ni le temps passé, ni le produit reconditionné. Dix-huit modules en font une activité pilotable. Parlons de votre atelier.