Documentation9 min de lecture

Expédier au quotidien : chauffeurs, zones, créneaux et contrôles

Le module OCA `partner_delivery_schedule` (dépôt `delivery-carrier`, version 18.0.1.0.1, licence AGPL-3) crée un référentiel de **créneaux de livraison** — jours de la semaine et plage horaire — rattachés au client, et `partner_delivery_zone` ajoute une **zone de livraison** reprise sur la commande, le transfert et le mouvement de stock. Treize autres modules traitent les chauffeurs, les contrôles de conformité transporteur et le transport sur achats.

Chauffeur livreur devant son camion en tournée

Une PME qui livre avec ses propres camions n'a pas les mêmes besoins qu'un expéditeur de colis. Il lui faut des chauffeurs, des tournées, des zones, et savoir que ce client-là ne reçoit que le mardi matin.

Quinze modules communautaires couvrent cette organisation — et les contrôles qui évitent qu'un camion parte pour rien.

Résumé

Deux modules traitent les chauffeurs : un chauffeur par défaut sur le mode d'expédition, repris sur le transfert et la ligne de mouvement, et sa reprise dans les lots de préparation.

Trois modules traitent le client : des créneaux de livraison par jour et par plage horaire, une zone de livraison propagée jusqu'au mouvement de stock, et des consignes de livraison transmises au transporteur.

Quatre modules traitent l'attribution automatique : le mode d'expédition déduit de l'entrepôt, l'entrepôt déduit du mode d'expédition, le transporteur déduit de la règle de stock utilisée, et un contact rattaché au transporteur.

Trois modules traitent les contrôles : la vérification qu'un transfert respecte les exigences du transporteur — avec un volet marchandises dangereuses s'appuyant sur le référentiel ADR —, et une politique d'expédition par transporteur. Trois modules enfin complètent les flux : l'exclusion des services du calcul de date de livraison, une étape de pré-expédition, et le transport sur les achats.

L'essentiel

  • Des créneaux de livraison par client : jours de la semaine et plage horaire.
  • Une zone de livraison propagée jusqu'au mouvement de stock.
  • Des chauffeurs sur le mode d'expédition, le transfert et les lots.
  • Le transporteur déduit de la règle de stock utilisée.
  • Le contrôle de conformité d'un transfert aux exigences du transporteur.
  • Les marchandises dangereuses vérifiées contre les restrictions du transporteur.
  • Les services exclus du calcul de la date de livraison.
  • Le transport sur les achats : mode et prix sur la commande fournisseur.

Ce que ces modules ajoutent à l'instance

FamilleModulesNombre
Chauffeursdelivery_driver, delivery_driver_stock_picking_batch2
Clientpartner_delivery_schedule, partner_delivery_zone, partner_delivery_info3
Attributiondelivery_carrier_warehouse, sale_order_warehouse_from_delivery_carrier, stock_picking_carrier_from_rule, delivery_carrier_partner4
Contrôlesdelivery_carrier_picking_valid, delivery_carrier_picking_valid_dangerous_goods, delivery_carrier_shipping_policy3
Fluxdelivery_date_exclude_service, delivery_pre_shipping, delivery_purchase3

Les menus ajoutés : Inventaire ▸ Configuration ▸ Livraison ▸ Delivery Schedule et Delivery Indications by Customer to Carrier, Ventes ▸ Configuration ▸ Commandes clients ▸ Delivery Schedule, Contacts ▸ Configuration ▸ Delivery Zones.

Le client : créneau, zone, consignes

partner_delivery_schedule crée un modèle créneau de livraison : un nom, les sept jours de la semaine en cases à cocher, une plage horaire, une couleur. Les créneaux se rattachent au contact — et aussi aux sites de dépôt, si les points relais sont installés.

Un client qui ne reçoit que le mardi de 8 h à 12 h est une information de production, pas une note commerciale. Tant qu'elle vit dans un commentaire de fiche contact, le camion se présente le jeudi et repart chargé.

partner_delivery_zone crée un référentiel de zones de livraison — nom et code — rattaché au contact, puis propagé sur la commande, le transfert et le mouvement de stock. C'est cette propagation qui compte : elle permet de regrouper les préparations par zone et de construire des tournées.

partner_delivery_info gère les consignes de livraison du client à destination du transporteur — code de portail, étage, horaires de quai — avec un référentiel dédié et un envoi à l'expéditeur depuis n'importe quelle opération.

Les chauffeurs et les tournées

delivery_driver marque des contacts comme chauffeurs, leur rattache des modes d'expédition, et ajoute un chauffeur par défaut sur le mode d'expédition ainsi qu'un chauffeur sur le transfert et sur la ligne de mouvement.

delivery_driver_stock_picking_batch reprend ces chauffeurs dans les lots de préparation : un lot correspond alors à une tournée, avec son chauffeur.

Les deux modules sont en LGPL-3, ce qui les rend combinables avec du code sous licence plus permissive — une différence qui compte si vous développez des extensions propres.

Les lots de préparation eux-mêmes sont traités dans regrouper, scinder et suivre les transferts.

L'attribution automatique du transporteur

  • delivery_carrier_warehouse déduit le mode d'expédition utilisé sur une commande de l'entrepôt choisi.
  • sale_order_warehouse_from_delivery_carrier fait l'inverse : l'entrepôt se déduit du mode d'expédition. Les deux sens existent, et le bon dépend de votre organisation — il faut en choisir un.
  • stock_picking_carrier_from_rule renseigne le transporteur sur le transfert quand la règle de stock utilisée pointe vers une adresse de contact porteuse d'un mode d'expédition. C'est le cas du dépôt intermédiaire ou du prestataire logistique.
  • delivery_carrier_partner ajoute simplement un contact sur le mode d'expédition : le transporteur devient une entité joignable, pas seulement un tarif.

Choisir le transporteur à la main sur chaque commande est une tâche que personne ne revendique et que tout le monde oublie. Les quatre modules d'attribution n'enlèvent pas la décision : ils enlèvent la saisie.

Les contrôles avant départ

delivery_carrier_picking_valid vérifie qu'un transfert respecte les exigences du transporteur — il dépend du module de volume des transferts, donc le volume fait partie des critères contrôlés.

delivery_carrier_picking_valid_dangerous_goods étend ce contrôle aux restrictions de marchandises dangereuses, en s'appuyant sur le référentiel ADR européen des produits.

Un contrôle de conformité avant départ se rentabilise au premier refus évité. Un camion qui se présente avec un colis hors gabarit, ou un transporteur qui découvre une matière ADR non déclarée, c'est une journée de livraison perdue et une pénalité.

delivery_carrier_shipping_policy ajoute une politique d'expédition sur le transporteur — livrer dès que possible ou tout en une fois — et la reprend sur la commande. Son README est minimal ; les deux champs sont relevés sur instance.

Trois compléments de flux

  • delivery_date_exclude_service exclut les produits de type service du calcul de la date de livraison. Une prestation d'installation ne doit pas repousser la date d'expédition de la marchandise.
  • delivery_pre_shipping ajoute une étape de pré-expédition. Son README est minimal et son relevé n'ajoute aucun champ : à évaluer sur instance avant de s'y engager.
  • delivery_purchase porte le transport sur les achats : un mode de livraison et un prix de livraison sur la commande fournisseur, et sur ses lignes un marqueur de ligne de transport avec le transfert d'origine.

Le dernier comble un manque réel : Odoo gère le transport à la vente, pas à l'achat. Or le port facturé par un fournisseur est un coût d'approvisionnement qu'il faut rapprocher de sa facture.

Limites connues

  • delivery_pre_shipping et delivery_carrier_shipping_policy ont des READMEs réduits à leur catégorie ; le premier n'ajoute aucun champ au relevé.
  • Les deux modules d'attribution entrepôt/transporteur vont en sens inverse : installer les deux crée une boucle de décision.
  • Les créneaux de livraison n'empêchent rien par eux-mêmes : ils renseignent, l'organisation décide.
  • Le contrôle de conformité suppose des exigences renseignées par transporteur : sans paramétrage, il ne contrôle rien.
  • Le volet marchandises dangereuses exige le référentiel ADR européen, qui est un module à part et un travail de classification produit.
  • Les zones de livraison doivent être propagées avant usage : une zone posée sur le contact après coup ne remonte pas sur les commandes existantes.

Identité technique

Les quinze modules viennent du dépôt OCA delivery-carrier, branche 18.0 — dont les 60 modules sont désormais tous documentés ici. Ils sont en licence AGPL-3, sauf delivery_driver et delivery_driver_stock_picking_batch, en LGPL-3. Les dépendances notables : stock_picking_batch pour les lots, stock_picking_volume pour le contrôle de conformité, l10n_eu_product_adr_dangerous_goods pour les marchandises dangereuses, purchase pour le transport sur achats.

Les trois autres fiches du dépôt : grilles tarifaires et contraintes, étiquettes et colis, connecteurs et suivi.

Questions fréquentes

Peut-on enregistrer qu'un client ne reçoit que le mardi matin ?

Oui : partner_delivery_schedule crée des créneaux de livraison — jours de la semaine en cases à cocher et plage horaire — rattachés au contact. Tant que cette information vit dans un commentaire de fiche, le camion se présente le jeudi et repart chargé.

Comment organiser des tournées de livraison avec ses propres camions ?

Trois modules s'y combinent : partner_delivery_zone propage une zone jusqu'au mouvement de stock, delivery_driver marque les chauffeurs et les pose sur le transfert, et delivery_driver_stock_picking_batch les reprend dans les lots de préparation — un lot devenant une tournée.

Peut-on affecter le transporteur automatiquement ?

Quatre modules le font selon des critères différents : depuis l'entrepôt (delivery_carrier_warehouse), depuis la règle de stock et l'adresse qu'elle utilise (stock_picking_carrier_from_rule), ou en sens inverse en déduisant l'entrepôt du transporteur. N'installez pas les deux sens : cela crée une boucle.

Comment vérifier qu'une expédition respecte les contraintes du transporteur ?

delivery_carrier_picking_valid contrôle la conformité du transfert — volume compris — avant départ, et delivery_carrier_picking_valid_dangerous_goods y ajoute les restrictions de marchandises dangereuses via le référentiel ADR européen. Un refus évité rembourse le paramétrage.

Odoo gère-t-il les frais de port sur les commandes fournisseur ?

Pas en standard. delivery_purchase ajoute un mode de livraison et un prix de livraison sur la commande d'achat, et marque les lignes de transport avec leur transfert d'origine. Le port facturé par un fournisseur est un coût d'approvisionnement à rapprocher de sa facture.

Se faire accompagner

Une PME qui livre elle-même a besoin de trois choses dans son ERP : savoir quand le client peut recevoir, savoir quel camion passe où, et savoir avant le départ que le chargement est conforme. Le reste est du confort.

Nous paramétrons donc les créneaux et les zones avant les connecteurs, et nous posons les contrôles de conformité avant d'automatiser l'affectation. Une tournée qui part juste vaut mieux qu'une tournée qui part vite. Voir les prestations d'Atalios Consulting ou demander un rappel.

Pour aller plus loin

En résumé

Livrer avec ses propres camions : créneaux de livraison par client, zones propagées jusqu'au mouvement de stock, chauffeurs et tournées, contrôles de conformité avant départ, et le transport enfin géré sur les achats. Parlons de votre organisation de livraison.

Documentation OCALogistiqueTransport

Partager

Fiches connexes

Équipe au travail sur des ordinateurs portables autour d'une table
Le module OCA `account_invoice_en16931` (dépôt `fr-einvoicing`, version 18.0.1.0.0, licence AGPL-3) est le socle qui fabrique le fichier de facture électronique conforme à la norme européenne **EN 16931** : Factur-X (PDF/A-3 avec XML CII embarqué), XML UBL, XML CII ou PDF accompagné d'un UBL — et il ajoute des **contrôles bloquants à la validation** d'une facture client. Les quatre modules qui s'y greffent pour la France, et ce que le socle ne fait pas.
Lire la suite
Documentation OCA, Facturation électronique
Réunion d'approbation autour d'un document de travail
Relevé sur une instance Odoo 18 Community, le module OCA `base_tier_validation` (dépôt `server-ux`, version 18.0.3.5.1, licence AGPL-3) ajoute 1 modèle, 101 champs et 3 menus, mais ne s'active sur aucun document métier par lui-même : il lui faut un module d'implémentation. C'est le point qui surprend le plus — voici ce qu'il fait réellement, et comment le mettre en service.
Lire la suite
Documentation OCA, Odoo