Lina, responsable e-commerce d’une marque qui a grandi plus vite que ses process. Le site tourne, les commandes tombent, les transporteurs défilent, mais chaque fin de mois ressemble à un sudoku géant, où l’on tente d’accorder factures, frais de port, remboursements PayPal et versements PSP. L’objectif de Lina est clair, brancher l’e-shop à Microsoft Dynamics 365 Business Central et faire en sorte que tout s’enchaîne, commande, réservation, expédition, facture, paiement, rapprochement, sans que l’équipe passe ses soirées à corriger.
La commande arrive, côté e-shop et côté Business Central :
Il est 9h12, la commande 47281 tombe, payée par carte via Stripe, devise EUR, livraison standard. Un webhook part du site et rejoint un endpoint d’intégration. Ce message porte un identifiant unique, il est horodaté, il contient le numéro de transaction PSP, la méthode de paiement, la devise, les lignes article, les frais de port, les taxes calculées côté boutique. Business Central crée alors une commande vente et ne laisse rien implicite, client final ou compte invité selon la politique, groupe comptable activité correct, groupe TVA aligné avec la classe de taxe de la boutique, frais de port ajoutés comme ligne distincte, devise verrouillée.
Côté stock, Lina veut que les meilleures ventes soient sécurisées dès la création de la commande. Dans Business Central, la réservation est réglée au niveau de la ligne ou de l’article. Pour les articles qui tournent fort, la réservation est systématique, pour le reste, on laisse l’ATP ou Order Promising proposer une date fiable. Résultat, l’équipe n’appelle plus les clients pour décaler les expéditions à la dernière minute.
La logistique se met en marche, avec un simple ou WMS avancé :
Dans un entrepôt simple, on ouvre l’expédition vente, on prépare, on valide l’envoi. Dans un entrepôt WMS, on suit le trio Warehouse Shipment, Warehouse Pick, scan, et Business Central applique les règles que Lina a déjà cadrées, Directed Put-away and Pick activé, emplacements fixes pour les A-items, capacités renseignées, rangs de priorité, zones froid ou dangereux si besoin, FEFO pour les lots à DLC. Si l’emplacement fixe est plein, l’ERP propose la réserve compatible, l’opérateur scanne, l’adresse est propre, le stock devient disponible là où le picking ira le chercher demain, sans détour.
Au moment du post ship, le connecteur transport récupère le tracking chez nShift, EasyPost ou ShipStation, renvoie l’information au site, et le client reçoit son mail avec numéro de suivi. Rien de héroïque, juste une chaîne qui respecte ce qui a été paramétré.
La facture sort au bon moment, et elle tombe juste :
Deux politiques existent, paiement déjà capturé au passage de commande, alors la facture est postée juste après l’expédition, paiement uniquement autorisé à la commande, alors la capture se déclenche au post ship, puis la facture est comptabilisée. Dans les deux cas, Business Central envoie le PDF, le site passe la commande en statut invoiced, le service client voit la même vérité que la compta. Les retours suivent une trame miroir, numéro de RMA côté boutique, réception retour en quarantaine si besoin, contrôle qualité, remise en stock si conforme, avoir lié à la facture d’origine, remboursement déclenché si la boutique l’a déjà opéré.
L’argent circule, la compta respire :
C’est souvent ici que tout se complique, chez Lina ce n’est plus le cas. À la facture, Business Central crédite ventes et TVA, il débite un compte de clearing PSP. Ce compte représente ce que Stripe ou PayPal doit encore verser. Lorsque le PSP envoie un payout, on importe le relevé, CSV, MT940, CAMT.053, ou via API, le rapprochement applique la ligne de banque au payout, débite la banque, crédite le clearing, comptabilise les frais et éventuels chargebacks. Si le clearing ressort à zéro après chaque payout, la chaîne est saine, sinon il reste une exception à traiter, remboursement partiel, litige, écart de conversion, l’intégration le signale, on corrige, on continue.
Le secret, la fonctionnalité rapprochement bancaire avec Copilot dans Business Central qui mappe l’identifiant de transaction PSP au document Business Central, numéro de commande, numéro de facture, montant, devise, date, et des règles d’appariement qui tolèrent les centimes de frais, qui groupent par payout, qui isole les cas litigieux. Carte et wallets avec autorisation puis capture, PayPal avec frais variables, BNPL avec versements échelonnés, virement SEPA avec End-to-End Id, carte cadeau traitée comme passif consommable, chaque méthode a sa règle, chaque règle a son compte.
Pourquoi ça tient, côté données et côté architecture :
Rien ne marche sans données maîtres propres. Les articles portent des unités de mesure cohérentes, des poids et des dimensions réalistes, des codes-barres fiables, des groupes comptables justes, des variantes correctement définies, les clients B2C et B2B sont bien classés, les entrepôts ont des capacités et des rangs sur les emplacements, les zones et types d’emplacements reflètent le terrain, froid, réserve, picking, qualité, danger. Côté taxes, OSS et IOSS quand il le faut, transport taxable ou non selon les pays, arrondis maîtrisés côté boutique et côté ERP pour éviter les écarts à répétition.
Côté connectivité, Lina utilise des files par nature d’événement, commandes, paiements, payouts, retours. Chaque message a un messageId idempotent, on peut le rejouer sans créer de doublon. Un journal d’intégration garde la preuve, contenu reçu, horodatage, document créé, statut, accepté, rejeté, en attente. Une surveillance envoie une alerte Teams quand une file se fige, cinq minutes suffisent pour réagir, plus jamais une journée perdue pour une virgule oubliée dans un JSON.
Les moments où l’on peut se tromper, et comment les éviter :
Des unités de mesure mal alignées, et les réservations se bloquent, une classe de taxe e-shop non mappée vers le bon groupe TVA dans l’ERP, et les factures divergent, des emplacements sans capacité ni rang, et les propositions de rangement deviennent farfelues, pas d’idempotence, et les doublons silencieux s’accumulent, pas de comptes de frais PSP dédiés, et la marge est faussée. La parade tient en quelques gestes, nettoyer les UoM et verrouiller les conversions, finir le mappage TVA dans les deux sens, compléter capacités et rangs, imposer le messageId et refuser les replays non signés, créer des comptes de frais par PSP et réviser mensuellement.
Ce que les experts Business Central reconnaîtront, ce que les équipes e-commerce retiendront :
Les experts verront le respect du standard, Sales Order propre, Reservation appliquée au bon niveau, Warehouse Shipment et Warehouse Pick quand le WMS est actif, Posted Sales Invoice qui alimente un compte de clearing PSP, Bank Reconciliation qui s’appuie sur des relevés normalisés, FEFO qui influence la mise à disposition, Order Promising qui stabilise les dates. Les équipes e-commerce retiendront une idée simple, chaque clic client doit correspondre à une pièce comptable traçable, chaque pièce comptable doit se solder par un versement réel, si ce lien est inviolable, la croissance n’écrase plus la finance.
Conclusion :
Automatiser un e-shop avec Business Central n’est pas une histoire de connecteur magique, c’est une chorégraphie où chaque pas compte, données fiables, règles logistiques claires, comptabilité des PSP maîtrisée, intégration observable, sécurité respectée. Quand la chorégraphie est en place, Lina ne court plus derrière les problèmes, elle pilote la performance, et son équipe finit ses journées avec des validations vertes plutôt qu’avec des tableurs rouges.