Connecter plusieurs boutiques à Sage ne revient pas à répéter le même import. Chaque canal peut avoir sa devise, ses remises, ses références et ses règles de livraison. Une vente doit conserver cette identité jusqu’à la pièce ERP.
Le danger apparaît lorsqu’un rapprochement fondé sur le seul numéro de commande mélange deux boutiques, ou lorsqu’une disponibilité commune ignore les engagements déjà pris ailleurs. L’automatisation amplifie alors une ambiguïté qui restait gérable manuellement.
Ce scénario décrit une architecture d’intégration à adapter à la version et aux interfaces Sage. Les décisions proposées ne sont pas des fonctionnalités natives garanties. Nous ne publions pas de routes fictives sous le nom d’une API officielle.
Notre offre d’intégration de Sage à votre SI relie les boutiques et l’application métier à l’ERP. Les opérations commerciales sont validées avec l’ADV, la logistique et le partenaire Sage. Nous raccordons ces boutiques à leur SI dans le cadre de notre offre d’intégration API et middleware.
Identifier une vente par boutique et par société
Conservez le canal, la boutique et l’identifiant de commande d’origine. Associez ensuite la société et le dossier cible. Deux ventes portant le numéro 10482 doivent rester différentes si elles viennent de boutiques distinctes.
La table de rapprochement doit conserver la référence source, la pièce ERP et le dernier résultat confirmé. Une correction d’adresse ne doit pas supprimer l’identité de la vente. L’historique permet de distinguer enrichissement et nouvelle création.
Rapprocher SKU, variantes et unités
Une référence vendue à l’unité et un lot de plusieurs pièces peuvent partager une désignation. Définissez la correspondance avec l’article Sage et l’unité attendue. Une quantité commercialisée en lot ne peut pas être importée comme une quantité physique sans conversion validée.
Traitez le SKU inconnu comme un rejet explicite. La création automatique d’un article provisoire peut sembler pratique mais affecter la valorisation, la logistique et les taxes. Le métier doit décider quand cette création est autorisée.
Définir qui possède le prix affiché et le prix facturé
La boutique peut calculer une promotion et Sage appliquer des conditions commerciales. Choisissez si la pièce reprend le prix de vente confirmé ou si l’ERP recalcule selon ses règles. Une double application de remise rend la marge incompréhensible.
La recette doit comparer total des lignes, frais de livraison, remises et arrondis. Faites valider les taxes et devises par les responsables concernés. Le connecteur doit conserver les montants source nécessaires au rapprochement, pas masquer un écart dans une ligne de correction générique.
Calculer la disponibilité vendable au bon périmètre
La quantité physique ne constitue pas toujours la quantité vendable. Réservations, préparation, stock de sécurité et engagements d’autres boutiques réduisent la disponibilité. Identifiez également les dépôts réellement capables d’expédier vers le client.
L’organisation doit choisir si la réservation est faite dans l’ERP, le WMS ou une application intermédiaire. Elle doit éviter que deux systèmes retranchent le même engagement. En cas de retard de synchronisation, affichez ou appliquez une politique conservatrice définie avec le commerce.
Transmettre une commande complète et connaître son état
Le middleware normalise la vente puis traduit les données vers l’interface Sage retenue. Il doit vérifier le tiers, les lignes et les frais avant l’écriture. Les mécanismes disponibles sont décrits dans le guide de raccordement Sage 100.
Séparez commande reçue, en contrôle, créée et rejetée. La confirmation affichée dans la boutique ne doit pas prétendre que l’ERP a validé la pièce si le traitement attend encore. Le support doit retrouver la vente avec une seule référence.
Faire vivre annulations, retours et remboursements
Une annulation avant préparation et un retour après livraison ne produisent pas la même opération. Le stock peut être disponible, en contrôle qualité ou non revendable. La finance doit déterminer la pièce corrective et le rattachement au document initial.
Un remboursement PSP n’est pas un ordre de réintégration physique. Le middleware conserve les liens entre événement de paiement, retour logistique et avoir. Le guide de rapprochement finance approfondit ces distinctions.
Scénario de recette : une création réussie sans réponse
Dans ce scénario illustratif, la boutique envoie la vente, l’interface crée la pièce puis la connexion est interrompue. La vente reste incertaine dans le middleware. Le bon test vérifie qu’une recherche ou un rapprochement retrouve la pièce avant une éventuelle nouvelle tentative.
Si le fournisseur ne permet pas cette vérification, le traitement passe en contrôle manuel. Il faut aussi tester un article inconnu, un rejet de taxe et un événement reçu deux fois. Le plan de reprise des commandes aide à organiser les états sans confondre panne de transport et correction métier.
NetMinds : l’application interne autour des ventes multicanales
Pour Pixminds, NetMinds associait Sage 100c à des flux de vente et à un pilotage interne sur mesure. Le partenaire exposait une API REST sur Sage ; Dawap construisait les échanges et l’application métier. Le projet précédait Ciama.
La présentation métier de NetMinds montre le rôle de la DSI, du commerce et de la logistique. Elle ne transforme pas les imports e-commerce archivés en une promesse de connecteur natif pour toute plateforme actuelle.
Livrer boutique par boutique avec un rapprochement quotidien
Commencez par une boutique et une société, avec des ventes représentatives. Comparez quotidiennement les commandes source, les pièces créées et les cas en attente. L’ADV doit pouvoir corriger une correspondance puis autoriser la reprise du seul dossier concerné.
Élargissez lorsque les montants et les états sont compris. La maintenance doit couvrir les évolutions des API e-commerce, de la passerelle et du paramétrage Sage. Le volume de ressaisies évitées n’est utile que si les exceptions restent maîtrisables.
Conclusion : Préserver l’identité de chaque vente
Une intégration multi-boutiques repose sur des références, des montants et des responsabilités cohérents. La synchronisation ne peut pas arbitrer seule un prix ou une disponibilité.
Les retours et les remboursements font partie du périmètre dès la conception. Ils relient des décisions logistiques et financières qui ne doivent pas être fusionnées.
La recette doit prouver qu’une réponse perdue ne provoque pas une seconde commande. Le rapprochement protège les ventes aussi bien que le transport.
Dawap réalise ces flux et leurs outils de suivi avec son offre d’intégration API. Nous construisons un premier périmètre boutique et ERP que vos équipes peuvent vérifier.
