Votre boutique Shopify est connectée à Pennylane. Les ventes apparaissent dans la comptabilité, mais l’équipe ne retrouve pas les factures clients qu’elle attendait. Elle active alors un second import depuis l’ERP. À la clôture, le chiffre d’affaires semble avoir augmenté sans commandes supplémentaires, tandis qu’un virement Shopify Payments reste inférieur au total des ventes. Ce problème bloque le rapprochement : la finance ne peut plus expliquer quelle population chaque import a comptabilisée.
Le responsable e-commerce cherche une connexion ; la finance attend des pièces, des écritures et des rapprochements. Ces besoins peuvent partager les mêmes commandes sans demander le même flux. Le vrai enjeu consiste à choisir qui comptabilise la vente et qui fournit ses documents, puis à traiter le règlement comme un événement distinct. Paradoxalement, importer davantage de pièces peut aggraver l’écart si deux chemins comptabilisent le même fait : la présence du document ne justifie pas une nouvelle vente.
Pennylane propose déjà une connexion Shopify par l’intermédiaire de Chift. Son périmètre doit être comparé à votre besoin avant de développer une intégration supplémentaire. L’absence d’une facture dans ce parcours ne prouve pas une panne : la synchronisation annoncée peut porter sur des écritures plutôt que sur les factures elles-mêmes.
Nous allons définir les responsabilités entre boutique, ERP et Pennylane, organiser les remboursements et les versements, puis vérifier sept contrôles dans un registre fictif. Dawap accompagne ce cadrage en intégration API. La prestation d’intégration Pennylane intervient lorsque vos pièces ou vos règles financières demandent un raccordement au-delà du service déjà disponible.
Pour qui ajouter un flux à la connexion Shopify–Pennylane
Le besoin concerne notamment une entreprise dont l’ERP produit déjà les factures, un groupe qui exploite plusieurs boutiques ou une activité qui utilise plusieurs prestataires de paiement. Le responsable finance doit alors retrouver le même dossier commercial malgré les regroupements et les calendriers propres à chaque outil.
Pour un e-commerçant dont le connecteur existant répond au besoin validé, ajouter une API spécifique peut être inutile. L’équipe commence par vérifier ses paramètres, ses accès aux pièces et sa méthode de rapprochement. Le passage au développement se justifie par une fonction manquante qualifiée, pas par le nombre d’outils disponibles.
Une reprise de facturation ERP exige aussi une coordination avec son installateur. Il doit préciser les pièces accessibles, leurs états et les identifiants qui survivent aux corrections. Ce périmètre devient le contrat du raccordement : un export de commandes ne doit pas être présenté comme un export de factures déjà émises.
Commencer par ce que la connexion Shopify remonte vraiment
Le mot « synchroniser » peut désigner la création d’une facture, l’import d’un PDF, une écriture de ventes ou la récupération d’une transaction bancaire. Demandez au fournisseur de nommer les objets transmis et ouvrez un dossier témoin dans Pennylane. Une ligne visible dans un tableau ne démontre pas la présence de tous les documents associés.
Distinguer le connecteur partenaire des fonctions de facturation
Le centre d’aide Pennylane sur les connexions e-commerce décrit une intégration Shopify réalisée avec Chift. Les ventes sont synchronisées sous forme d’écritures comptables ; les factures de vente ne sont pas remontées par ce parcours. La documentation recommande Chift pour les nouvelles connexions, plutôt que l’ancien accès Pennylane Connect depuis la page Connectivité.
Le même centre d’aide prévoit une fréquence quotidienne ou mensuelle et des choix de date pour la comptabilisation. Ces paramètres doivent être relus avec votre comptable et votre configuration. Ils servent à comprendre où chercher un regroupement et une correction ; ils ne garantissent pas que toute commande apparaîtra comme une facture individuelle dans Pennylane.
Si ce service couvre vos ventes et que vos pièces restent accessibles dans un autre outil autorisé, le paramétrage peut suffire. Un développement spécifique se justifie lorsque vous devez importer des factures existantes, traiter un ERP émetteur ou organiser des rapprochements hors du périmètre qualifié. Son devis porte sur ce manque réel, pas sur la reconstruction de la connexion déjà maintenue.
Décider où la facture client doit être produite
Le choix dépend du système qui porte vos documents de vente. Une application de facturation Shopify, un ERP ou Pennylane peut participer au parcours, mais leur coexistence demande une responsabilité explicite. Le projet commence par une facture normale, un avoir et une commande modifiée, avec les identifiants permettant de les retrouver.
Importer une pièce existante ou en créer une nouvelle
La présentation des cas d’usage de l’API Pennylane distingue la création d’une facture client depuis des données structurées et l’import d’une facture existante. Ce sont deux fonctions différentes. L’import d’une pièce doit conserver son identité ; la création suit le parcours choisi pour l’émetteur et ses données qualifiées.
Ne créez pas une deuxième facture pour remplacer un PDF simplement introuvable dans le connecteur e-commerce. Recherchez d’abord la pièce source et son statut. Si l’ERP en est l’émetteur, sa référence, sa date, ses lignes et sa devise doivent rester reliées au document transmis. Une commande Shopify ne devient pas automatiquement le document émis par cet ERP.
Les montants, taxes et règles documentaires sont validés avec finance et les intervenants compétents pour votre entreprise. L’intégrateur construit le contrat technique correspondant. Il ne déduit pas la conformité d’une pièce de la réussite d’un appel API, et il ne choisit pas silencieusement un autre émetteur pour faire disparaître un rejet.
Attribuer un seul chemin de comptabilisation à la vente
Le risque principal apparaît lorsqu’une écriture agrégée couvre déjà les ventes Shopify et qu’un second flux importe les mêmes factures avec un effet comptable supplémentaire. Les deux interfaces peuvent fonctionner correctement chacune dans son périmètre. Leur combinaison devient pourtant fausse si aucune règle ne distingue preuve documentaire et nouvelle comptabilisation.
Écrire la frontière entre lot de ventes et facture individuelle
Pour un modèle agrégé, le dossier indique la boutique, l’entité, la période, le moyen de paiement et les commandes couvertes. Pour un modèle fondé sur les factures, il indique les pièces qualifiées et leur chemin de comptabilisation. Ce choix se fait avec le comptable ; le middleware reçoit une politique, pas la liberté de cumuler les deux méthodes au fil des événements.
Une règle locale peut refuser la création d’une seconde comptabilisation lorsque la population de ventes est déjà couverte. Elle doit néanmoins conserver les références des factures nécessaires à la consultation. Le moyen d’attacher ou d’importer ces pièces, ainsi que son effet réel dans Pennylane, doit être vérifié avant activation. Un mode documentaire sans effet supplémentaire ne peut pas être supposé disponible partout.
Premier signal faible : le montant comptabilisé augmente à la date d’installation d’une application de facturation, sans évolution équivalente des commandes. Second signal : les doublons disparaissent lorsqu’un opérateur coupe manuellement un import, puis reviennent au prochain changement de période. Ces indices appellent une lecture des périmètres, plutôt qu’une suppression automatique de pièces au même montant.
Expliquer le virement sans le prendre pour le total des ventes
Un versement regroupe des mouvements financiers selon le prestataire et sa période. Il peut tenir compte de frais, remboursements ou ajustements. La finance doit retrouver sa composition avant de le rapprocher ; le net reçu en banque ne suffit pas à reconstituer les ventes ou leurs taxes.
Conserver brut, frais, net et source du mouvement
La référence Shopify Payments des mouvements de solde décrit montant, frais, net, nature et références associées. L’accès demande les droits prévus par Shopify. Ces objets concernent Shopify Payments ; ils ne décrivent pas automatiquement les opérations d’un compte PayPal ou d’un autre prestataire utilisé dans la boutique.
Par exemple, dans notre scénario entièrement fictif, 200 euros de ventes réglées via Shopify Payments, un remboursement de 40 euros et six euros de frais donnent un net de 154 euros. Le registre doit expliquer ces 46 euros de différence avant de fermer le rapprochement. Aucun de ces montants ne représente un tarif fournisseur ou un résultat client.
Les ventes réglées par PayPal restent dans leur propre circuit financier. Un total Shopify incluant plusieurs moyens de paiement ne doit pas être comparé uniquement au virement Shopify Payments. Le contrôle associe chaque règlement à son prestataire, son compte, sa devise et sa période, puis garde visible ce qui n’est pas encore rapproché.
Conserver les bonnes dates pour ventes, remboursements et banque
La commande peut être créée en septembre, modifiée plus tard et réglée dans un versement reçu en octobre. Une date unique appliquée à tous les objets déplace alors des faits entre périodes. Le rapprochement doit préserver leurs dates propres et la règle comptable choisie, sans transformer un décalage bancaire en vente manquante.
Qualifier la première reprise avant d’élargir l’historique
Le dossier distingue date source, date de synchronisation et date retenue pour le traitement. Une première reprise historique ne fonctionne pas nécessairement comme une modification reçue après cette reprise. Comparez une commande inchangée, une commande modifiée et un remboursement avec les paramètres du connecteur. Le livrable montre les périodes réellement produites.
Les périodes déjà clôturées demandent la procédure définie par finance. Un ancien événement reçu tardivement ne doit pas ouvrir une correction improvisée depuis le support. La file d’exception conserve le fait, sa date, la période affectée et le responsable de sa qualification. Reculer la date de début de synchronisation est une opération à recetter avant de l’appliquer à tout l’historique.
Le monitoring suit les populations couvertes et les montants encore inexpliqués, par période et devise. Un simple indicateur « dernier job réussi » ne montre pas qu’un remboursement de septembre a été correctement rattaché. Le contrôle doit aller du dossier commercial aux objets financiers réellement disponibles, avec une sortie claire pour les références absentes.
Matrice de recette : sept contrôles avant la première clôture
Nous avons exécuté ces sept contrôles sur un registre local en mémoire. Tous les montants sont fictifs et fournis TTC, sans calcul fiscal. Deux commandes payées via Shopify Payments valent 120 et 80 euros ; une troisième, réglée par PayPal, vaut 60 euros. Le registre représente des populations commerciales et leurs mouvements, pas une comptabilité complète ni une réponse obtenue de Chift.
Le choix pédagogique conserve un chemin agrégé pour les ventes et les pièces comme références de contrôle. Cette politique n’affirme pas qu’un import documentaire donné est sans effet dans Pennylane. Aucune API fournisseur, facture réelle, connexion bancaire ou opération financière n’est exécutée ; les cas vérifient seulement les décisions de notre modèle.
| Contrôle | Situation reçue | Résultat du registre | Décision de recette |
|---|---|---|---|
| A · lot de ventes | Deux commandes Shopify Payments de 120 et 80 euros | Un lot EUR de 200 euros avec les deux références | Conserver le périmètre couvert avant tout autre import |
| B · pièce individuelle | Une facture témoin de 120 euros pour la première commande | Référence documentaire ajoutée ; aucune nouvelle vente | Qualifier un parcours réel qui n’ajoute pas de comptabilisation en double |
| C · répétition du lot | La même population est présentée une seconde fois | Le lot existant est retrouvé ; total inchangé | Ne pas transformer un rejeu en nouveaux revenus |
| D · composition du net | 200 euros, remboursement de 40 et frais de 6 | Net Shopify Payments de 154 euros | Rapprocher la composition, pas uniquement le montant bancaire |
| E · autre prestataire | Une commande PayPal de 60 euros | Second lot EUR séparé ; aucun ajout au net de D | Garder le circuit PayPal distinct |
| F · arrivée en banque | Le versement de 154 euros est observé en octobre | Lien au versement ; aucune nouvelle vente d’octobre | Conserver les dates commerciales et bancaires |
| G · devise contradictoire | Une observation USD prétend clôturer le versement EUR | Rapprochement refusé ; les lots EUR restent inchangés | Qualifier devise et conversion avant tout regroupement |
Fermer la balance du scénario à la bonne frontière
Les ventes fictives couvertes valent 260 euros TTC avant remboursement : 200 et 60. Après le remboursement de 40, elles valent 220. Les règlements attendus valent 154 pour Shopify Payments et 60 pour PayPal, soit 214 ; les six euros de frais expliquent la différence avec 220. Cette balance commerciale ne constitue pas un calcul de chiffre d’affaires HT ni une proposition d’écriture fiscale.
Le seuil de réussite du test est zéro lot commercial supplémentaire après C et zéro nouvelle vente lors de F. Pour B, le contrôle exige une seule population comptabilisée malgré la présence d’une pièce individuelle. La contrainte appartient au registre local ; il reste à vérifier l’effet des imports et des paramètres réels dans les outils retenus.
G reste bloqué même si la valeur numérique semblait suffisante. Deux devises ne deviennent pas comparables par disparition de leur code. Le contrat doit fournir le montant source, la conversion qualifiée et les objets auxquels elle s’applique. La recette garde aussi un témoin de montant identique mais de population différente, pour refuser un rapprochement obtenu par simple égalité de somme.
Concevoir le raccordement supplémentaire avec l’ERP
Le connecteur reçoit un périmètre approuvé : pièces émises dans l’ERP, références client, lignes, montants et états attendus. L’installateur ERP qualifie la lecture disponible et le sens des documents ; le comptable valide la destination et l’effet souhaité. Dawap traduit ce contrat dans l’interface supportée, avec les droits strictement nécessaires.
Préparer la sortie avant de créer la première pièce
La sortie doit associer la référence source à l’objet effectivement retrouvé dans Pennylane. La documentation de création de facture client distingue notamment brouillon et finalisation, ainsi que les références propres à chaque entreprise. Le raccordement doit choisir ce comportement explicitement et qualifier son authentification pour le mode d’intégration concerné.
Après un timeout, l’absence de réponse ne prouve pas l’absence de création. Le journal conserve la demande, sa corrélation et les moyens de retrouver son résultat selon le contrat supporté. La clé d’idempotence du registre local associe entreprise, source et intention ; elle ne garantit pas une idempotence native de toute opération Pennylane. Une nouvelle création attend cette qualification. Un changement de numéro pour contourner un doublon présumé rendrait ensuite le rapprochement plus difficile, même si l’API répondait sans erreur.
Le cadrage d’un connecteur ERP exploitable complète ce travail sur les dépendances, les versions et la reprise. Le flux Pennylane possède ses propres références et capacités ; une architecture réutilisable ne dispense pas de vérifier les fonctions réelles de cette entreprise et de son ERP.
Traiter une tentative sans créer une seconde pièce
Les entrées de la file de traitement contiennent l’entreprise, la pièce source et la version du mapping. Le worker produit une sortie qui relie cette référence à l’objet relu dans la destination. Un retry attend la qualification d’un résultat incertain ; un backoff peut espacer une consultation en échec sans créer une nouvelle pièce. La journalisation garde la cause, la tentative et la décision.
Si l’interface choisie émet un webhook, sa réception peut signaler qu’un dossier doit être relu. Elle ne devient pas la preuve que toutes les pièces et tous les règlements sont déjà rapprochés. Le contrat précise les notifications disponibles, la lecture de contrôle et la reprise des événements manqués. Ces capacités doivent être vérifiées sur les interfaces effectivement retenues.
Plan d’action : choisir le flux avant de reprendre toutes les ventes
Commencez par une boutique, une entreprise Pennylane et une période représentative. Préparez les commandes, pièces et relevés nécessaires à la lecture commune. Le livrable initial attribue chaque responsabilité : comptabilisation, production documentaire, remboursement, collecte financière et validation d’un écart. Il nomme aussi les flux déjà actifs.
Ouvrir seulement le périmètre dont l’effet est compris
- Conserver la connexion existante si elle couvre le besoin approuvé, avec les pièces accessibles selon le parcours retenu.
- Documenter le manque précis avant d’ajouter un import ERP ; tester son effet sur une vente déjà couverte.
- Refuser une extension qui produit une seconde comptabilisation, mélange les devises ou ferme un versement sans population expliquée.
Finance possède la matrice de décision ; e-commerce explique les événements Shopify ; l’intégrateur conserve journalisation, mapping et monitoring. Le runbook indique comment rechercher un effet incertain et qui autorise la reprise. Le rollback suspend les nouvelles créations et restaure le parcours approuvé pour les dossiers non engagés, en conservant les pièces déjà produites et leurs corrections qualifiées.
Pour chiffrer le support, prenez une hypothèse explicite : vingt dossiers hebdomadaires demandant douze minutes représentent quatre heures. À 50 euros supposés par heure, le budget de traitement vaut 200 euros par semaine. Ce montant fictif sert à prioriser les causes récurrentes ; il ne prouve aucune économie acquise par un client ni la rentabilité d’un développement.
La première clôture pilote compare populations, pièces et règlements, avec les écarts laissés ouverts et leur prochaine décision. L’élargissement vient ensuite par boutique, période ou type de pièce. Une période complète comprise vaut davantage qu’un grand historique importé dont personne ne peut expliquer les doublons ou les montants restants.
Erreurs fréquentes quand la connexion devient un flux comptable
Le raccordement doit être relu depuis un dossier commercial jusqu’à la banque. Se limiter aux volumes importés encourage des corrections qui améliorent un compteur tout en créant un nouvel écart financier. Le propriétaire du flux doit retrouver ses décisions sans dépendre d’un export modifié à la main.
Reconnaître les confusions avant leur automatisation
- Attendre une facture individuelle d’une synchronisation annoncée comme agrégée : le périmètre doit être vérifié avant le diagnostic de panne.
- Importer les factures ERP sans examiner les écritures Shopify déjà présentes : deux sources peuvent couvrir les mêmes ventes.
- Employer le net bancaire comme total des ventes : frais et remboursements perdent leur explication.
- Rapprocher PayPal avec le seul versement Shopify Payments : le mauvais compte devient la référence financière.
- Reprendre l’historique après chaque écart : les périodes et corrections demandent un traitement qualifié.
Les décisions de rapprochement Shopify, Stripe et PayPal approfondissent la chronologie des paiements. Elles complètent le choix de flux vers Pennylane ; elles ne déterminent pas à elles seules où produire la facture ni comment votre comptable retient la période.
La méthode de transport des montants, devises et arrondis précise les valeurs à conserver dans les échanges. Une différence inexpliquée ne doit pas être effacée par une tolérance globale. Le dossier cherche d’abord la première transformation qui a changé la somme ou sa population.
Conclusion : relier les objets attendus par votre finance
La connexion Shopify–Pennylane doit être choisie à partir des objets dont l’entreprise a besoin : écritures, factures, avoirs, transactions et pièces. Le service partenaire disponible peut répondre à une partie importante du parcours. Ses écritures de ventes ne doivent pas être confondues avec une remontée automatique des factures individuelles.
Un raccordement ERP supplémentaire demande un seul chemin de comptabilisation par population de ventes. Les documents et leurs corrections gardent leur identité ; les règlements conservent leur prestataire, leur devise et leurs dates. Cette séparation permet d’expliquer un virement inférieur aux ventes sans créer un revenu supplémentaire lors de son arrivée en banque.
Les sept contrôles locaux éprouvent ces frontières sur des montants fictifs, sans API fournisseur ni acte comptable réel. La recette suivante doit vérifier les paramètres de votre connexion, l’effet des imports et les dossiers de votre période pilote. Finance ferme les écarts documentés et conserve les autres avec une responsabilité claire.
Dawap peut vous accompagner pour cadrer et construire ce raccordement dans votre projet d’intégration API : lecture du périmètre Shopify–Pennylane, qualification ERP, conception des échanges et passation aux équipes. Nous partons des fonctions existantes et du besoin financier restant pour livrer un flux dont chaque document et chaque montant peuvent être retrouvés.
