Odoo et 3PL : expliquer chaque réception partielle

Deux cartons arrivent chez votre logisticien, alors que le bon de commande fournisseur en prévoit trois. Le 3PL confirme la réception de huit pièces. Dans Odoo, douze pièces deviennent pourtant reçues, ou la réception reste ouverte sans explication. L’équipe achats cherche le carton manquant, le service commercial promet une disponibilité et le support compare deux écrans qui ne racontent plus la même livraison.

En pratique, le raccordement doit conserver la quantité réellement reçue, son lot et la suite attendue. Une réception partielle ne ferme pas nécessairement l’achat fournisseur. Un colis arrivé au quai ne prouve pas non plus que le rangement interne est terminé. Ces différences deviennent des problèmes quotidiens quand les acheteurs ne peuvent plus expliquer un reliquat ou que le même message logistique ajoute deux fois les unités.

Vous allez qualifier le parcours d’une réception fournisseur entre le 3PL et Odoo, puis corriger neuf situations fictives : cartons convertis en pièces, lot absent, mauvais dépôt, choix de reliquat et accusé perdu. Vous pourrez décider ce que le connecteur peut confirmer, ce qu’il doit mettre en attente et quelle pièce permettra de reprendre le dossier sans inventer une livraison complète.

Dawap réalise cette coordination dans ses prestations d’intégration API entre logiciels métier. Le raccordement de votre ERP Odoo se construit avec votre administrateur ou votre installateur ERP : il faut connaître le processus de réception installé, les interfaces disponibles et les droits accordés au middleware avant de modifier les entrées.

Pour qui les réceptions du 3PL désorganisent les achats

Ce parcours concerne une marque ou un distributeur qui achète ses produits et confie leur stockage à un prestataire logistique. Odoo suit les commandes fournisseurs ; le WMS du 3PL décrit ce qui arrive, ce qui est contrôlé et ce qui est rangé. Les deux applications peuvent partager une référence tout en comptant des unités différentes ou en fermant leurs documents à des moments différents.

Retrouver les symptômes dans un dossier réel

Choisissez une livraison incomplète récente. L’acheteur doit pouvoir retrouver la quantité commandée, les avis de réception du logisticien, les lots concernés et ce qui reste attendu. Si l’enquête exige de demander une capture d’écran à chaque service, commencez par documenter ce parcours. Un tableau de stock total ne remplacera pas les liens entre les documents.

Repérez aussi le moment de la divergence. Une saisie Odoo peut avoir repris automatiquement la quantité prévue ; le 3PL peut avoir transmis un total cumulé que le connecteur interprète comme un nouvel apport. Le problème peut enfin se limiter à un transfert interne encore ouvert. Ces trois causes demandent des corrections différentes, même si le commercial voit chaque fois une disponibilité incohérente.

Délimiter la responsabilité de chaque intervenant

L’entrepôt atteste le comptage et les observations physiques. L’acheteur décide si le fournisseur doit encore livrer ou si le solde est abandonné. L’équipe ERP qualifie les opérations Odoo autorisées. Le middleware transporte les faits, conserve les correspondances et restitue les exceptions ; il ne transforme pas un carton absent en quantité reçue pour fermer une tâche.

Attribuez les exceptions à ces rôles dès le pilote. Une unité inconnue rejoint le responsable du référentiel ; un carton contesté rejoint l’exploitation ; une interface indisponible rejoint l’équipe technique. Le dossier conserve le dernier fait confirmé et la personne attendue. L’acheteur ne doit pas corriger une permission ERP pour résoudre une différence de comptage.

Qualifier l’interface Odoo et le contrat du logisticien

Demandez d’abord la version, le mode d’hébergement, les modules de stock et les développements spécifiques installés. La présence d’un ERP Odoo ne suffit pas à établir qu’une interface externe utilisable existe dans votre contrat. Vérifiez séparément la lecture des réceptions, l’écriture des quantités, l’affectation des lots et la validation, avec un compte dédié au périmètre convenu.

Choisir une méthode adaptée à la version installée

La documentation officielle Odoo 19 de l’API JSON-2 décrit les appels de méthodes et leur authentification par clé API. Elle réserve l’accès externe aux offres Custom dans son cadre tarifaire. Pour une installation hébergée autrement, votre administrateur confirme l’interface, ses modules et ses conditions d’accès. Ce choix ne se déduit pas d’un exemple prévu pour une autre version.

Chaque appel JSON-2 a sa propre transaction. Une succession de lectures et d’écritures ne constitue donc pas une seule opération atomique. Si le projet exige une validation indivisible de plusieurs changements, une méthode serveur adaptée doit être qualifiée avec l’équipe ERP. Une lecture préalable et une promesse dans le middleware ne suffisent pas à garantir ce comportement face à des modifications concurrentes.

Obtenir les preuves côté 3PL

Le contrat logistique précise si une réception est transmise par événement, interrogation API ou fichier. Si un webhook est disponible, qualifiez son payload, ses renvois et l’authentification prévue. Pour une collecte par polling, vérifiez la pagination et la manière de retrouver les corrections après la première lecture. Demandez un exemple partiel, un exemple corrigé et un exemple de renvoi. Faites préciser si les quantités sont cumulées ou incrémentales, si les unités refusées figurent dans le total et si un identifiant de réception reste stable quand le message est réémis.

Une interface partenaire peut offrir seulement une partie des opérations du WMS. Notez les droits, la fréquence accessible et les identifiants réellement présents. Le cadrage d’un flux WMS, OMS et stock doit suivre cette interface contractuelle, avec ses limites. Il ne peut pas emprunter les fonctions d’un portail interne auxquelles votre compte n’a pas accès.

Relier l’achat, le dépôt et l’unité réellement reçue

La correspondance commence par une ligne d’achat identifiable, un produit, une société et un entrepôt autorisés. Un numéro de bon peut être réutilisé dans deux comptes logistiques. Une référence produit ne désigne pas nécessairement le même conditionnement chez le fournisseur et dans le WMS. La réception doit conserver son origine avant d’être convertie dans l’unité attendue par Odoo.

Convertir les cartons sans effacer leur preuve

Dans notre scénario fictif, un carton contient quatre pièces et la commande attend trois cartons, soit douze pièces. La première réception porte sur deux cartons : huit pièces. Le connecteur garde la quantité source, son unité et la règle de conversion appliquée. L’écran d’enquête peut ainsi expliquer pourquoi le document du logisticien affiche deux alors que l’ERP affiche huit.

Une palette sans composition connue reste en attente. Il serait dangereux de réutiliser le coefficient d’un autre produit ou celui d’un conditionnement modifié depuis l’achat. Si une commande porte sur des unités décimales, la règle doit également fixer la précision et le traitement des arrondis. L’exercice utilise seulement des pièces entières ; il n’établit aucune règle universelle pour le vrac.

Écarter les rapprochements ambigus

Une ligne de réception peut correspondre à plusieurs achats ouverts du même article. Ne choisissez pas le premier résultat d’une recherche pour résoudre cette ambiguïté. Demandez le lien logistique prévu ou une décision attribuée. La personne qui rapproche le dossier doit retrouver les documents candidats et le motif de son choix, sans réaffecter silencieusement la marchandise d’une autre société.

Conservez aussi la réception externe indépendante du numéro de message transport. Le logisticien peut renvoyer le même fait avec une nouvelle enveloppe technique. À l’inverse, une correction de quantité portant sur la même réception nécessite un parcours de correction explicite. Mélanger ces deux situations fabrique soit un doublon de stock, soit une correction perdue.

Conserver les lots pendant une réception incomplète

Pour un produit suivi par lot, le raccordement doit porter la quantité réellement reçue sur le bon lot. Deux cartons peuvent appartenir au lot L2403 et le dernier carton attendu à un autre lot. Fusionner la réception entière sous une seule valeur commode peut empêcher de retrouver les unités concernées par un contrôle ou une reprise fournisseur.

Vérifier le paramétrage avant l’écriture

La documentation Odoo 19 sur les lots décrit l’activation du suivi, l’affectation des quantités reçues et les options de création ou d’utilisation de lots sur le type d’opération. Pour un produit suivi, un lot manquant empêche la validation prévue. Créer une fiche de lot ne suffit pas à établir sa quantité en stock.

Le compte du connecteur doit être autorisé à utiliser le lot dans la société et l’opération concernées. Une valeur absente déclenche une demande de qualification, avec la pièce du 3PL. Elle ne devient pas un lot « inconnu » partagé entre toutes les livraisons simplement pour obtenir une réponse favorable de l’ERP.

Ranger les écarts de qualité dans leur propre parcours

Si un carton arrive endommagé, l’entrepôt peut l’avoir compté physiquement tout en le plaçant dans un emplacement ou un statut de contrôle. Le contrat de réception doit expliquer ce fait. Le volume arrivé, la quantité acceptée et la quantité commercialement disponible ne s’obtiennent pas forcément depuis un seul champ du message.

Une réserve photographiée ne modifie pas automatiquement l’achat. L’acheteur peut demander un remplacement, maintenir le reliquat ou accepter une autre issue documentée. La pièce jointe et la décision suivent la réception concernée. Elles ne doivent pas réécrire l’historique d’un lot sain reçu auparavant.

Décider du reliquat sans compléter la quantité reçue

Après huit pièces reçues sur douze, quatre restent attendues dans notre exemple. La réception physique et l’engagement fournisseur doivent rester explicables séparément. Si le fournisseur annonce l’envoi du solde, le dossier conserve une prochaine réception attendue. S’il ne peut plus livrer, l’acheteur décide de la suite ; aucune unité supplémentaire n’est ajoutée au comptage.

Identifier le choix installé dans Odoo

Le code officiel de la branche Odoo 19 consultée prévoit des politiques de création de reliquat : demander, toujours créer ou ne pas créer. La validation peut retourner une action de confirmation avant l’exécution finale. Votre configuration et vos extensions doivent être éprouvées sur une réception partielle de recette.

Le connecteur doit connaître la politique autorisée et restituer les cas qui demandent une décision. Il ne peut pas supposer que la fermeture du document implique la réception de toute la commande. Paradoxalement, une réception fermée peut encore laisser des marchandises non livrées lorsque son solde a été annulé. L’acheteur doit retrouver cette décision, même si la liste des tâches n’affiche plus de réception ouverte.

Garder un lien entre les arrivages successifs

Le second arrivage reçoit sa propre identité externe et rejoint la suite du dossier fournisseur prévue par le processus installé. Il ne doit pas recréer la commande initiale ni compléter artificiellement le premier bon. Dans la fiction, R2 apporte quatre pièces du lot L2404 : le total atteint alors douze, avec deux faits de réception et deux lots distincts.

Une quantité supérieure à l’attendu demande une règle spécifique. Notre modèle de démonstration la met en attente pour décision ; ce refus est une politique choisie pour le pilote, pas une limitation universelle d’Odoo. Faites qualifier les tolérances, les autorisations et les conséquences sur l’achat avant d’accepter automatiquement une surlivraison.

Confirmer l’état obtenu après la demande de validation

Une réponse technique réussie ne suffit pas à conclure que la réception est terminée. L’adaptateur doit interpréter le résultat de la méthode appelée et retrouver l’état du document concerné. Dans Odoo, une action retournée peut notamment ouvrir une confirmation de reliquat ; d’autres actions peuvent intervenir après validation. La seule forme de la réponse ne fournit donc pas un verdict universel.

Séparer demande, décision et état final

Le support doit distinguer la réception préparée, le choix de reliquat encore requis et la réception effectivement validée. Une attente de décision doit montrer les quantités comptées et le solde concerné. La personne habilitée peut alors poursuivre le processus sans répéter une opération déjà terminée dans l’ERP.

La recette vérifie aussi un échec fonctionnel : lot absent, mauvais contexte, document déjà clos ou quantité incompatible avec la politique retenue. Chaque refus conserve un dossier et une prochaine action. Un message d’erreur copié dans un journal technique ne suffit pas si l’acheteur ne peut pas retrouver la réception qui reste à traiter.

Retrouver un succès dont l’accusé a disparu

Si l’ERP a validé la réception mais que la connexion se coupe avant le retour, le connecteur possède un résultat incertain. Il recherche l’opération déjà liée à cette réception externe et son état. Si la preuve établit l’effet attendu, il confirme cette opération ; il n’ajoute pas les huit pièces une seconde fois pour obtenir un nouvel accusé.

Cette reprise exige une correspondance durable et des garanties adaptées côté serveur. Notre exercice démontre une règle séquentielle dans une simulation locale. Il ne certifie ni l’unicité native d’un champ Odoo personnalisé ni deux validations concurrentes. Ces propriétés restent des essais distincts à réaliser sur l’interface et la méthode retenues.

Distinguer l’arrivée au quai du rangement terminé

La réception en deux étapes décrite par Odoo 19 sépare l’arrivée du fournisseur vers l’emplacement d’entrée et le transfert interne vers le stock. La première réception terminée ne prouve pas l’achèvement du second mouvement. D’autres installations utilisent une seule étape ou un parcours supplémentaire.

Nommer les quantités affichées au commerce

Une marchandise à l’entrée peut déjà compter dans certaines lectures ERP tout en restant exclue de la disponibilité promise par votre politique commerciale. Définissez les emplacements, contrôles et réservations pris en compte. Il serait trompeur d’affirmer que toute réception à l’entrée doit produire zéro stock dans Odoo, quelle que soit sa configuration.

Dans la fiction, huit pièces ont atteint l’entrée, aucune n’a encore été transférée vers l’emplacement de stockage. La colonne « rangé » vaut zéro jusqu’à l’opération distincte de rangement. Ce choix rend le scénario lisible ; il ne décrit pas une formule native universelle de disponibilité vendable.

Attribuer l’étape encore attendue

Le dossier indique qui termine le transfert interne et quelle observation le confirme. Si le WMS du prestataire porte cette opération, l’interface doit pouvoir transmettre le fait approprié ou permettre sa vérification. Sans cette preuve, le middleware garde l’étape ouverte et le support sait qu’il doit solliciter l’exploitation, plutôt que demander au fournisseur de relivrer les pièces.

Ajoutez une vérification des transferts qui restent ouverts après la réception. Le seuil de délai se définit avec l’exploitation selon ses créneaux et ses contrôles, pas depuis une constante copiée d’un autre entrepôt. L’alerte montre l’entrée déjà confirmée, le transfert attendu et son responsable. Elle ne doit pas déclencher une seconde réception fournisseur.

Exercice corrigé : neuf situations sur douze pièces attendues

Scénario entièrement fictif : la société A attend douze pièces à Lyon, avec suivi par lot et un parcours en deux étapes. R1 annonce deux cartons de quatre pièces du lot L2403. Notre modèle local exige une décision explicite pour conserver le solde. Les cas A à C se suivent ; D à I repartent chacun d’un dossier neuf.

Prévoir l’effet avant de lire le corrigé

Pour chaque ligne, indiquez si le connecteur peut confirmer une réception, combien de pièces il peut compter et quelle action reste nécessaire. La décision « conserver le solde » est donnée dans les cas valides, sauf G. En I, elle permet la réception à l’entrée mais aucun transfert de rangement n’a encore été exécuté.

Vérifier les deux contre-exemples positifs

En G, une décision autorisée de conserver le solde permet ensuite de recevoir huit pièces et d’en maintenir quatre attendues. Le dossier n’est donc pas bloqué définitivement. Après I, le transfert de huit pièces termine le rangement de R1. R2 apporte alors quatre pièces du lot L2404 ; leur transfert porte le total reçu et rangé à douze, avec un solde nul.

Les neuf groupes et ces suites ont été exécutés dans un modèle Python local, sans appel Odoo ni écriture chez un logisticien. Ils vérifient les règles choisies, la conversion et les reprises séquentielles. La validation native, les droits effectifs et la concurrence restent à éprouver en recette ERP. Le corrigé ne constitue pas une certification d’un connecteur commercial existant.

Plan d’action : raccorder une famille de réceptions avant généralisation

Décrire un dossier complet avec les deux équipes

Retenez un fournisseur, un entrepôt, une société et une famille de produits. Reconstituez une réception complète puis une réception partielle avec les documents sources. Relevez les identifiants qui relient achat, réception logistique, lots et opérations ERP. L’acheteur valide les décisions de solde ; l’exploitation décrit le comptage, les contrôles et le rangement. Les ambiguïtés deviennent des questions attribuées avant l’écriture.

L’administrateur Odoo confirme les versions, les extensions, les types d’opérations et les permissions du compte dédié. Le 3PL fournit le contrat accessible et des exemples représentatifs. Le livrable doit distinguer ce qui existe nativement, ce qu’un partenaire expose et ce qui demande un développement de middleware. Une capture de portail prouve une information visible, pas nécessairement une méthode d’écriture accessible.

Éprouver les refus et les reprises en recette

Exécutez une première réception de huit pièces puis la suite de quatre, en contrôlant les lots et les documents réellement créés. Ajoutez un lot manquant, une unité inconnue, un mauvais dépôt et un choix de reliquat requis. Un essai réussi doit montrer les états obtenus et les effets absents dans les cas refusés, plutôt que seulement une trace HTTP favorable.

Provoquez ensuite un accusé perdu dans un environnement prévu pour ces essais. Vérifiez la recherche de l’opération antérieure et le nombre d’effets réellement enregistrés. Les essais simultanés suivent les garanties retenues côté ERP. Si une méthode serveur spécifique porte l’opération indivisible, sa recette doit inclure les conflits et les refus ; le modèle séquentiel présenté ici ne remplace pas ces essais.

Ouvrir le pilote avec une reprise exploitable

Avant l’ouverture, nommez qui traite chaque attente et comment arrêter les écritures en cas d’écart inexpliqué. Les observations entrantes restent consultables ; les opérateurs retrouvent les derniers effets confirmés. La reprise manuelle suit le même dossier et conserve ses décisions, afin qu’un traitement par le support ne soit pas ensuite doublé par le connecteur.

Les entrées du pilote portent identité logistique, unité, lot et contexte autorisé ; les sorties conservent document ERP et résultat confirmé. Le mapping garde sa version pour la traçabilité. La journalisation relie les deux côtés sans enregistrer les secrets. Le support retrouve ainsi la conversion utilisée et les responsabilités de la reprise sur le dossier précis.

Le monitoring sépare un timeout d’appel et une décision de reliquat encore attendue. Les seuils d’escalade sont convenus avec les équipes. Un circuit de repli suspend les écritures dont le résultat reste incertain tout en conservant les observations reçues. L’idempotence et la réconciliation sont éprouvées sur les réceptions déjà liées ; un retry technique ne suffit pas à établir l’absence de doublon.

• Ouvrir : tester un flux dont l’interface, le comptage, les lots et la reprise sont qualifiés avec les deux équipes.
• Différer : documenter l’unité, la décision de solde ou l’autorisation encore manquante avant d’activer les écritures.
• Refuser : bloquer une attribution au mauvais client ou une confirmation qui invente la quantité reçue.

Étendez le périmètre quand les réceptions du pilote sont rapprochées et les exceptions expliquées. Une nouvelle société, un dépôt différent ou un produit suivi par numéro de série nécessite sa propre qualification. Le connecteur peut réutiliser son organisation, mais il ne doit pas copier aveuglément le coefficient de carton, le traitement de reliquat ou la disponibilité commerciale d’un autre flux.

Mesurer les enquêtes évitées et les écarts encore ouverts

Le résultat commercial attendu est une équipe capable d’expliquer ce qui a été reçu et ce qui manque, avec moins de recherches manuelles. Mesurez les dossiers de réception qui demandent une enquête, leur temps de traitement, les doublons corrigés et les soldes sans prochaine action. Un grand nombre de messages traités ne prouve pas que ces quatre problèmes diminuent.

Calculer un coût de référence explicable

Exemple de calcul fictif : vingt-quatre écarts prennent chacun dix-huit minutes d’enquête. Cela représente 432 minutes, soit 7,2 heures. Ce total décrit une hypothèse de départ, pas un gain client mesuré. Après le pilote, comparez des dossiers de difficulté comparable et conservez le temps consacré aux exceptions encore ouvertes, y compris celles renvoyées au 3PL.

Suivez séparément le délai de traitement automatique et le délai de résolution métier. Une réception peut être mise en attente très vite, puis attendre longtemps une décision fournisseur. Le responsable achats doit voir cette dépendance ; l’équipe technique doit voir un incident d’interface. Les regrouper dans un seul temps moyen rend les améliorations difficiles à attribuer.

Reconnaître les erreurs qui faussent le bilan

• Compter comme closes les réceptions dont le choix de reliquat reste requis.
• Présenter un renvoi technique comme une nouvelle livraison fournisseur.
• Comparer des unités WMS et ERP sans appliquer le conditionnement validé.
• Exclure les dossiers transmis au support du temps réellement consacré aux écarts.

Une baisse des alertes peut masquer une règle devenue trop permissive. Vérifiez aussi les unités effectivement reçues et les décisions de solde. Le pilote doit conserver des refus utiles ; leur présence n’est pas un échec si le dossier est retrouvé et traité par la bonne personne.

Lectures complémentaires selon votre organisation

Si vous éditez le logiciel qui reçoit les observations, le parcours de connexion d’un SaaS à l’ERP de ses clients aide à délimiter le socle commun et les différences d’installation. Le comportement d’une seule base Odoo ne suffit pas à promettre le même raccordement à tous les clients de l’éditeur.

Pour une architecture utilisant Shippingbo et un autre ERP, le raccordement Shippingbo et SAP Business One traite les rôles des interfaces et les documents logistiques. Les méthodes ERP doivent être qualifiées pour ce système ; les options de reliquat Odoo ne lui sont pas attribuées.

Si vos clients demandent où en est un arrivage, le portail client 3PL pour stocks et demandes logistiques décrit la restitution des observations et l’attribution des demandes. Cet espace peut expliquer une attente à l’acheteur, mais il ne transforme pas une consultation en validation ERP.

Enfin, quand les réceptions proviennent d’achats déclenchés par les ventes, l’automatisation des achats fournisseurs pour les commandes marketplace traite l’engagement en amont. Le lien entre ces commandes et l’achat rend l’écart reçu compréhensible jusqu’au dossier vendeur, sans confondre réception fournisseur et expédition client.

Conclusion : faire de chaque réception partielle un dossier explicable

Avant de raccorder Odoo à votre 3PL, prenez une réception fournisseur incomplète et demandez aux deux équipes d’en expliquer la quantité, le lot, le solde et le rangement. Les désaccords révèlent les règles à établir. Une écriture qui ferme un document mais efface le carton manquant ne résout pas le travail de l’acheteur.

Le premier périmètre utile est celui où les faits reçus, les décisions autorisées et les effets confirmés restent liés. Une reprise retrouve l’opération déjà réalisée ; un lot absent attend sa qualification ; un reliquat reçoit une suite attribuée. Cette capacité à terminer et expliquer les dossiers fonde l’extension du raccordement à d’autres dépôts et fournisseurs.

Pour cadrer ce premier flux, Dawap vous accompagne dans l’intégration des réceptions logistiques à votre ERP, avec votre logisticien et votre installateur Odoo. Un dossier partiel, les interfaces autorisées et les règles de solde donnent les éléments nécessaires pour définir le raccordement et sa recette avant d’élargir le périmètre.