Odoo multi-sociétés : où importer les commandes des boutiques ?

Deux boutiques d’un groupe envoient leurs commandes vers la même base Odoo. Le compte du connecteur peut travailler pour les sociétés A et B, mais A reste son environnement habituel. Une commande de la boutique B arrive dans A avec un entrepôt trouvé par défaut. Les équipes découvrent l’écart au moment de préparer le colis ou de rapprocher les documents commerciaux, alors que la boutique a déjà confirmé la vente.

Le risque est de laisser la société habituelle du compte technique décider du vendeur. Une règle commerciale qualifiée doit attribuer la vente, puis conserver cette entité pendant la création et les reprises. Le pays de livraison, la langue du site et le dernier contexte utilisé par le compte technique ne remplacent pas cette règle. Un client partagé entre sociétés ne donne pas non plus l’autorité de facturer ou de réserver depuis n’importe quelle entité.

Pour une direction e-commerce, le problème est autant opérationnel que technique : préparation au mauvais dépôt, commande introuvable pour l’équipe concernée, reprise qui crée un second dossier ou correction tardive d’un rattachement. Vous allez comprendre comment relier canal, société, entrepôt et preuve de création, puis décider quels cas doivent attendre une qualification. Huit scénarios fictifs éprouvent le routage sans exécuter une vente dans Odoo.

Notre expertise en intégration API entre logiciels permet de cadrer ces échanges avec les équipes commerciales et logistiques. L’accompagnement Odoo API vérifie la version, les interfaces et les contrôles de la base avec votre installateur ERP. Le connecteur doit transmettre une intention attribuée, puis rapprocher le dossier obtenu avant d’en annoncer le traitement.

Pour qui sécuriser les ventes de plusieurs sociétés Odoo

Ce cadrage concerne un groupe qui utilise une base multi-sociétés et reçoit des commandes de plusieurs boutiques ou canaux externes. Les entités peuvent partager des clients et des références produit, tout en conservant leurs propres ventes et opérations logistiques. La question porte sur l’affectation d’une commande précise, avant de publier un statut exploitable au commerce.

Repérer le routage implicite dans les premiers incidents

Un premier signal faible apparaît lorsque le support demande de changer manuellement de société pour retrouver une commande de sa boutique. Un second se voit dans des bons de préparation utilisant un entrepôt différent du circuit convenu. Ces observations ne prouvent pas encore la cause, mais elles justifient de reconstruire la règle appliquée à l’import.

Demandez quelle information a désigné la société : identifiant du canal, profil client, table de correspondance ou valeur par défaut. Si la réponse dépend de la dernière sélection faite par un utilisateur, le flux comporte une dépendance qui n’a pas été attribuée au métier. Une nouvelle boutique risque de reproduire cette ambiguïté au lieu d’enrichir proprement le raccordement.

Différer le connecteur lorsque le vendeur reste indéterminé

Une marque, un domaine internet et une société Odoo ne constituent pas trois noms du même objet. Plusieurs marques peuvent relever d’une entité ; une même boutique peut aussi suivre des règles de vente différentes selon des contrats qualifiés. Le projet doit décrire la situation réellement retenue avant de proposer une correspondance automatique.

Différez l’ouverture du canal lorsque les équipes ne savent pas quelle société doit porter la vente ou quel dépôt doit préparer les lignes. Le développeur ne doit pas trancher ce choix depuis une adresse de livraison. Une règle provisoire peut être testée sur une population bornée, mais son auteur, ses exclusions et ses conditions de révision restent visibles.

Vérifier les possibilités natives avant de créer un routage

La documentation officielle consultée le 11 octobre 2026 décrit plusieurs fonctions utiles. Leur présence ne démontre pas que le parcours de votre base est déjà qualifié, ni qu’un module installé conserve exactement le comportement documenté. L’installateur Odoo doit vérifier les réglages applicables avant que le middleware reproduise une fonction existante.

Distinguer boutique Odoo et boutique externe

La documentation Multiple websites d’Odoo 19 décrit la possibilité d’associer un site à une société. Elle présente aussi des réglages propres au site et des comptes clients partageables. Lorsque vos boutiques utilisent ce parcours natif, examinez leur affectation et leur configuration avant d’ajouter une règle indépendante dans un logiciel externe.

Pour une boutique externe, il faut au contraire qualifier comment son identifiant commercial devient une intention pour Odoo. Un connecteur existant peut couvrir ce besoin ; vérifiez son contrat, ses correspondances et sa procédure d’exception. Le besoin de sur mesure apparaît lorsqu’une règle métier documentée reste sans traitement exploitable, et non parce que le groupe possède simplement deux sociétés.

Choisir une interface réellement accessible dans la base

La référence JSON-2 d’Odoo 19 présente cette interface comme nouvelle dans cette version. Elle précise que modèles, champs et méthodes disponibles dépendent de la base, et indique l’accès aux données par API externe sur le plan Custom. Version, hébergement, abonnement et extensions doivent être vérifiés pour votre installation ; aucun compte client n’est testé ici.

Une passerelle partenaire ou un module REST additionnel possède son propre contrat. Ne lui attribuez pas automatiquement les paramètres ou les contrôles de JSON-2. Avec votre installateur ERP, relevez la méthode retenue pour préparer la commande, les champs requis et les résultats qui permettent de retrouver le dossier créé. La documentation générale ne constitue pas une recette de cette méthode.

Rendre la correspondance canal-société explicable

La correspondance doit être attachée à une source identifiée et à une version de règle. Dans notre exemple fictif, le canal FR relève de la société A et du dépôt WA ; le canal BE relève de B et de WB. Ces lettres désignent des configurations commerciales fournies au test. Elles ne représentent aucune règle fiscale fondée sur le nom du pays.

Ne pas déduire le vendeur depuis le pays de livraison

Une commande du canal FR peut être livrée en Belgique tout en restant affectée à A dans la règle retenue. À l’inverse, le canal BE peut livrer en France et conserver B. Le lieu du destinataire constitue une donnée de la commande, pas l’autorité de rattachement de notre modèle. Les conditions commerciales et fiscales réelles nécessitent leur qualification propre.

Ce contre-exemple aide à repérer une logique implicite dans un export : pays, langue ou devise deviennent parfois une société sans décision documentée. Le connecteur doit refuser cette déduction lorsqu’aucune règle ne la prévoit. Si le groupe utilise réellement l’une de ces dimensions pour choisir son vendeur, le contrat doit exposer ses cas et ses exceptions avant l’import.

Le mapping canal-société-entrepôt appartient à la configuration métier versionnée. Le payload reçu de la boutique fournit notamment son identifiant de canal, sa référence et sa devise ; il ne choisit pas librement une société Odoo depuis une valeur non contrôlée. Si la commande arrive par webhook, la notification sert à retrouver et qualifier l’intention. Son arrivée ne prouve ni l’existence d’une vente ERP ni l’affectation correcte du dossier.

Garder l’identité du canal dans la clé de rapprochement

Deux boutiques peuvent chacune émettre une commande portant la référence 41. Cette égalité ne désigne pas un seul achat. Le raccordement conserve donc canal et référence externe pour retrouver l’intention. La société proposée complète le dossier, mais ne doit pas devenir un moyen de recréer une commande existante après une modification de règle.

La déduplication des clients, commandes et factures Odoo traite déjà les effets répétés. Ici, le contrôle supplémentaire porte sur l’entité de la vente. Une clé parfaitement unique peut encore créer une seule commande dans la mauvaise société ; l’absence de doublon ne prouve pas la justesse de l’affectation.

Séparer société attendue, droits du compte et entrepôt

La règle commerciale désigne une société, mais le compte du connecteur doit encore être autorisé à intervenir dans ce périmètre. L’entrepôt prévu doit également appartenir au parcours qualifié. Ces conditions sont nécessaires à la préparation de la commande ; elles ne prouvent pas à elles seules qu’une réservation, une facture ou une expédition peut être exécutée.

Ne pas prendre un accès à deux sociétés pour une décision de vente

Les directives multi-sociétés d’Odoo distinguent société courante, propriétés dépendantes de la société, cohérence des relations et règles d’accès. La référence JSON-2 confirme le contrôle des droits, des règles d’enregistrement et des accès aux champs du compte utilisé. Un connecteur autorisé sur A et B doit donc encore travailler dans le périmètre attendu pour chaque intention.

Contre-intuitivement, des droits plus larges peuvent masquer une correspondance incorrecte pendant une recette trop simple. L’appel ne rencontre pas nécessairement le refus qui aurait signalé l’autre entité. La preuve commerciale doit comparer société attendue et société obtenue, indépendamment du seul succès HTTP. Le compte administrateur n’est pas un remplacement du compte prévu pour le flux.

Qualifier le dépôt sans agréger les stocks des autres entités

Dans notre configuration, WA est qualifié pour A et WB pour B. Une règle A/WB est donc retenue en exception avant préparation. Cette décision interne ne certifie aucun modèle d’entrepôt Odoo. L’installateur vérifie les relations et les opérations de la base cible, notamment lorsqu’un circuit de préparation traverse plusieurs entités.

Un total global de stock peut afficher treize unités alors que la société vendeuse n’en promet que cinq dans son circuit. Le stock vendable Odoo par canal garde ses contrôles de réservation. Le routage ne doit pas utiliser les quantités d’un autre périmètre pour rendre la commande acceptable, ni transformer le compte technique en propriétaire commercial du stock.

Reconnaître les documents inter-sociétés déjà générés par Odoo

Une société peut vendre pendant qu’une autre intervient dans l’approvisionnement ou le parcours logistique. Ce fonctionnement demande une chaîne qualifiée. Le middleware doit savoir quels documents appartiennent à la vente externe et lesquels décrivent une contrepartie interne, sans les confondre parce qu’ils portent des lignes produit similaires.

Examiner le paramétrage avant de créer une seconde commande

La documentation Multi-company d’Odoo 19 décrit des transactions inter-sociétés pouvant générer des documents de contrepartie selon les réglages. Elle présente notamment des devis issus d’achats et des demandes d’achat issues de ventes. Ces fonctions doivent être examinées dans votre configuration avant qu’un connecteur crée lui-même des documents équivalents.

Demandez à l’installateur quel événement déclenche la contrepartie, quelle entité la reçoit et quelle preuve relie les documents. Un second document peut être attendu dans ce parcours ; il ne représente pas automatiquement un doublon de commande client. Inversement, créer une nouvelle vente externe pour compenser une mauvaise affectation peut ajouter un engagement au lieu de réparer le premier.

Distinguer produit partagé et stock utilisable

La même documentation distingue les fiches partagées et les enregistrements propres à une société. Elle indique que certaines propriétés d’un produit peuvent varier selon l’entité, même si sa référence est commune. Le connecteur doit donc retrouver la société du dossier avant d’interpréter une propriété dépendante de ce contexte.

Une référence produit commune facilite la correspondance du catalogue. Elle ne permet pas de reprendre sans examen les conditions de stock, la valorisation ou les documents d’une autre entité. Le projet garde la source et le périmètre de chaque propriété. Les réglages fiscaux et comptables restent qualifiés avec les responsables compétents ; le middleware ne les invente pas depuis le SKU.

Exercice : prévoir l’affectation de huit commandes

Les huit scénarios suivants ont été exécutés hors connexion sur une fonction de qualification interne. Le test reçoit des correspondances, propriétaires d’entrepôt, périmètres autorisés et reçus ERP déjà fournis. Il ne découvre pas les droits dans Odoo et ne crée aucun document. Les sorties « préparer » désignent une intention qualifiée, sans promettre son acceptation par l’ERP.

Comparer la décision avant tout effet ERP

FR désigne le canal affecté à A/WA et BE celui affecté à B/WB. Dans le scénario A, FR livre en Belgique ; dans B, BE livre en France. Les cas G et H reçoivent une preuve antérieure pour FR/41, rattachée à la commande SO-A-1001 de A. Chaque ligne repart de ses entrées, sans transmettre un engagement vers la suivante.

Lire les cas qui restent ouverts malgré une donnée complète

Le scénario H contient une société, un entrepôt et un périmètre autorisé cohérents pour B. Pourtant, la preuve antérieure désigne A. Notre politique retient donc le dossier au lieu de déplacer la commande ou d’en créer une autre. Le seuil est strict : une contradiction d’entité entre intention courante et reçu existant empêche toute nouvelle préparation automatique.

Le scénario F est également retenu alors que le compte fourni couvre les deux sociétés. L’accès ne suffit pas à qualifier le couple A/WB. Le contrôle exige un entrepôt rattaché au circuit déclaré, avec zéro correspondance ambiguë. Une procédure inter-sociétés réelle pourrait traiter ce besoin, mais elle doit être décrite et recettée ; le test ne l’invente pas.

Préserver l’entité d’une commande pendant les reprises

Une règle de routage peut évoluer après l’ajout d’une boutique ou la réorganisation du groupe. Les commandes déjà créées gardent pourtant leurs références et leur état ERP. Le raccordement distingue les intentions nouvelles des dossiers existants, afin qu’une modification de configuration ne réaffecte pas silencieusement l’historique commercial.

Rechercher le reçu avant de réappliquer la règle courante

Pour une réponse perdue après création, le middleware conserve canal, référence externe et corrélation d’origine. Il retrouve ensuite la preuve disponible côté Odoo et compare l’entité obtenue à celle attendue. La recherche et ses accès doivent être qualifiés avec l’installateur ; notre reçu fictif est fourni au test et ne démontre aucune capacité de recherche native.

Le dossier Odoo JSON-2, transactions et reprise approfondit cette frontière. Plusieurs appels ne forment pas une seule transaction JSON-2 selon la documentation officielle. La préparation du routage reste donc séparée de la preuve de création et de l’exécution d’une méthode métier. Un contrôle local favorable ne rend pas le parcours atomique.

Après un timeout, l’absence de réponse n’établit pas l’absence de commande. La recherche doit couvrir les résultats et sociétés autorisés nécessaires au rapprochement ; une pagination arrêtée trop tôt peut cacher le reçu attendu. La stratégie d’idempotence conserve canal et référence externe pendant ce diagnostic. Son efficacité dépend aussi du contrôle distant et de la concurrence : un journal local ne suffit pas à garantir une création unique.

Faire instruire les changements sur les ventes engagées

Si SO-A-1001 est déjà créé, le support examine son état et les documents liés avant une modification d’entité. Notre politique de reprise refuse une migration automatique depuis la nouvelle correspondance. Elle ne prétend pas qu’Odoo interdit tout changement : elle impose une décision qualifiée pour éviter de traiter un engagement existant comme une intention neuve.

La journalisation conserve version initiale, société obtenue, nouvelle proposition et responsable de l’arbitrage. Le monitoring expose ces dossiers dans une file distincte des erreurs de transport. Les responsabilités de correction restent chez le métier et l’installateur ERP ; un retry identique ne résout pas une contradiction commerciale. La reprise technique attend leur décision au lieu de changer les droits du compte.

Erreurs fréquentes qui changent le vendeur sans l’annoncer

Les erreurs d’affectation peuvent rester discrètes tant que les entités partagent les mêmes noms de clients et produits. Une recette doit donc vérifier la société du document obtenu, pas seulement la présence des lignes. Le rapprochement porte aussi sur le canal d’origine et le circuit logistique que les opérations avaient convenu d’utiliser.

Utiliser un contact partagé comme règle de société

La visibilité d’une fiche client ne désigne pas le vendeur de la commande. Un même contact peut être utilisable dans plusieurs contextes, tandis que chaque vente possède son affectation. Le contrat doit résoudre client, adresse de facturation et adresse de livraison dans le périmètre retenu, sans recopier un rattachement depuis le premier résultat d’une recherche.

Un résultat absent ne justifie pas non plus de créer immédiatement un nouveau contact. Il peut correspondre à un filtrage, à une référence mal qualifiée ou à un objet inaccessible au compte utilisé. Conservez la recherche et le contexte dans l’alerte. Le contrôle des identités client reste distinct du choix de société de la commande, même si les deux décisions se suivent dans le flux.

Regrouper les montants avant d’avoir qualifié les entités

Dans une illustration fictive, A porte une commande de 100 euros et B une commande de 150 euros. Le groupe peut afficher un total analytique de 250 euros, mais ce chiffre ne remplace pas les deux affectations de documents. La recette doit pouvoir retrouver chaque montant, son canal et sa société sans produire une facture ou un paiement à partir de cette seule somme.

Le coût caché apparaît dans les recherches manuelles, les préparations interrompues et les documents à corriger. Mesurez ces charges avec leurs causes. Une erreur de contexte et une décision commerciale encore absente ne demandent pas le même correctif. Le montant total importé peut rester juste alors que tous les dossiers d’une boutique ont été orientés vers la mauvaise entité.

Plan d’action : recetter deux canaux sur les mêmes références

Retenez deux canaux, leurs sociétés vendeuses et leurs entrepôts qualifiés. Le responsable e-commerce valide la correspondance ; l’exploitation confirme les circuits ; l’installateur relève les contrôles Odoo ; l’intégrateur décrit les échanges. Le contrat d’entrée fournit canal, référence, montant, devise et destinations. La sortie distingue intention préparée, dossier existant et exception, avec la société et la preuve pertinentes.

Tester les contradictions avant l’ouverture du second canal

Préparez des commandes portant la même référence sur les deux boutiques, des destinations croisées et une mauvaise correspondance d’entrepôt. Ajoutez un canal inconnu, une règle ambiguë, un compte insuffisant et une commande déjà créée avant révision du routage. Les huit cas internes donnent une première base, complétée par les interfaces et les opérations réellement utilisées dans votre recette.

Le seuil de passage du pilote est zéro affectation inexpliquée sur la population examinée. La journalisation garde entrée, règle appliquée, reçu et écart ; le repli suspend les intentions nouvelles si une société obtenue contredit la promesse. Le responsable revient au traitement qualifié sans supprimer les ventes engagées. Une validation de droits ou un résultat HTTP seul ne lève pas ce blocage.

L’observabilité sépare la latence entre émission et reçu ERP du temps passé à résoudre une affectation. Une queue dédiée peut isoler les intentions sans règle valide, avec leur motif et leur responsable, plutôt que multiplier les nouvelles tentatives. Son traitement ne doit pas libérer la commande sur le seul critère de son ancienneté : la société et le dépôt doivent être qualifiés avant toute création.

Choisir le périmètre rentable avant de généraliser

Par exemple, 48 enquêtes à 6 minutes représentent 288 minutes de charge fictive. Mesurez votre temps réel avant d’en déduire un budget : recherche du document, revue de rattachement, correction de correspondance et contrôle de reprise. Un connecteur peut réduire une enquête sans accélérer une préparation ou résoudre un choix commercial qui attend encore son décideur.

• Conserver le parcours natif Odoo lorsque ses sites et ses sociétés couvrent déjà les ventes concernées.
• Choisir un connecteur existant si ses correspondances et ses exceptions répondent au contrat qualifié.
• Développer une règle spécifique lorsque la décision métier reste documentée mais inexploitable dans les interfaces disponibles.
• Différer les transferts de ventes engagées tant que leurs documents et leurs autorités de correction restent incertains.

Étendez ensuite la recette à une nouvelle société ou à un nouveau dépôt selon ses propres contraintes. La réutilisation du transport API ne dispense pas de qualifier la correspondance commerciale. Le pilote doit démontrer une affectation explicable et une reprise maîtrisée, plutôt qu’un débit élevé obtenu en envoyant toutes les ventes vers le même environnement.

Projets liés : du parcours B2B aux commandes Odoo

1UP Distribution : faire arriver la décision commerciale dans l’ERP

Le portail B2B 1UP Distribution relié à Algolia et Odoo illustre une autre règle d’affectation métier. Son premier palier conserve le contexte du compte, ses tarifs et ses adresses lors de la transmission du panier. Lorsque disponible et reliquat coexistent, ils peuvent produire deux commandes distinctes, dont les références sont conservées pour le suivi. Le choix effectué dans le portail devient ainsi une structure explicable dans l’ERP.

Ce cas ne démontre pas un routage multi-sociétés. Il éclaire la méthode à appliquer ici : déterminer la règle commerciale, la traduire dans les documents et conserver leur identité après création. Le premier palier décrit aussi des protections de reprise partielles ; il ne constitue pas une garantie de transaction distribuée. Pour vos boutiques, société vendeuse et entrepôt demandent leur propre qualification avec l’installateur Odoo.

Guides complémentaires pour les dossiers Odoo multicanaux

Le choix d’entité précède plusieurs décisions qui gardent leur propre preuve : création unique, réservation, réception logistique et reprise après réponse incertaine. Ces approfondissements permettent de qualifier la prochaine étape sans attribuer au routage des garanties qu’il ne fournit pas.

Retrouver une création dont la réponse a disparu

Les contrats et transactions JSON-2 d’Odoo distinguent intention, effet et reçu. Une commande correctement affectée peut encore être mal reprise si le connecteur ne sait pas déterminer ce que l’ERP a effectué.

Dans le périmètre multi-sociétés, la preuve doit également conserver l’entité obtenue. Le support ne doit pas élargir une recherche au hasard ou recréer le document dans sa société courante pour faire disparaître un dossier en attente.

Conserver les références qui empêchent une seconde vente

Le traitement des doublons clients, commandes et factures Odoo examine les identités et les reprises. La clé canal-référence doit rester stable lorsque la table de correspondance change après création.

Le nouveau routage ne doit pas ouvrir une seconde intention pour la même vente simplement parce que sa société proposée diffère. L’équipe examine le reçu existant et la décision commerciale avant toute nouvelle mutation.

Qualifier les quantités que chaque boutique peut promettre

Le stock Odoo multicanal et ses réservations approfondit disponibilité et concurrence. Le rattachement d’une vente donne un périmètre à examiner, sans établir à lui seul une quantité promettable.

La publication au canal conserve son entrepôt, son unité et sa politique de réservation. Une commande adressée à B ne doit pas consommer un total de groupe qui inclut des quantités sans autorisation d’usage dans son circuit.

Rapprocher le logisticien dans le bon périmètre d’achat

Les réceptions fournisseurs partielles entre Odoo et un 3PL distinguent achat, quantité reçue, lot et reliquat. Une confirmation physique possède ses identités de société et de dépôt, au-delà du nom commun du produit.

Le rapprochement d’une réception ne doit pas utiliser la vente du canal comme raccourci vers le premier achat ouvert. Les deux documents peuvent appartenir à des chaînes différentes. Leur lien exige une référence logistique qualifiée et une décision dont les opérations retrouvent l’origine.

Conclusion : conserver la société de chaque vente e-commerce

Le canal doit transmettre une décision commerciale que le connecteur peut expliquer. Société attendue, entrepôt qualifié et droits du compte répondent à des contrôles différents. Les destinations croisées du test montrent pourquoi le pays de livraison ne remplace pas une correspondance fournie par les responsables du groupe.

Les huit scénarios isolent également les exceptions à garder ouvertes : canal inconnu, règles concurrentes, périmètre insuffisant et dépôt incohérent. Une commande déjà créée demande sa propre reprise. Une nouvelle configuration ne transforme pas automatiquement ce dossier en une vente neuve dans une autre société.

Le choix de solution commence par les fonctions natives et les connecteurs disponibles. L’installateur Odoo qualifie les réglages et les méthodes de la base ; les équipes métier attribuent les ventes et leurs circuits. Le développement spécifique devient utile lorsque cette décision reste sans traduction fiable entre les systèmes, avec des preuves qui permettent de contrôler le dossier obtenu.

Dawap peut préparer cette matrice avec votre installateur ERP, éprouver les échanges et construire les reprises nécessaires au commerce. Notre accompagnement en intégration API et middleware relie les commandes des boutiques aux sociétés et aux opérations qualifiées, pour que vos équipes retrouvent chaque vente dans le bon périmètre après une erreur, une réorganisation ou l’ouverture d’un nouveau canal.