Dev API prestashop
Bonjour, Nous sommes en train de développer notre module pour gérer nos différents sites prestashop et j'ai une série de questions suite à la première lecture des docs API : E-reporting (B2C et international) Les factures B2C importées via l’API (/customer_invoices/import, PDF classique) sont-elles automatiquement incluses dans l’e-reporting transmis par Pennylane en tant que plateforme agréée ? Sinon, quel endpoint ou quel format utiliser ? Est-il possible, ou préférable, de transmettre des totaux B2C agrégés par jour plutôt que facture par facture ? Même question pour les ventes à des clients professionnels étrangers, UE et hors UE (e-reporting international). Les données de paiement à déclarer sont-elles déduites automatiquement, ou faut-il les signaler via l’API (par exemple Mark as paid) ? Import Factur-X et envoi à la plateforme agréée Quel profil Factur-X est requis : EN 16931, ou BASIC / EXTENDED acceptés ? Où placer dans le XML les nouvelles mentions obligatoires (SIREN client, nature de l’opération biens / services / mixte, adresse de livraison) pour qu’elles soient correctement prises en compte ? Existe-t-il un moyen de valider un fichier avant envoi (contrôle par règles Schematron, mode test) ? L’environnement sandbox permet-il de tester send_to_pa de bout en bout ? Quels sont les statuts possibles de e_invoicing.status ? Existe-t-il un événement webhook à chaque changement (rejet, acceptation, etc.) ? Que se passe-t-il si le client destinataire n’est pas trouvé dans l’annuaire ou n’a pas de plateforme de réception ? Pour les avoirs Factur-X (type 381), sont-ils liés automatiquement à la facture d’origine, ou faut-il appeler l’endpoint Link a credit note ? Clients et doublons Lors de l’import Factur-X, Pennylane rapproche-t-il ou crée-t-il automatiquement le client à partir du SIREN contenu dans le XML ? Ou faut-il toujours transmettre customer_id ? Plusieurs boutiques alimentant la même société, quelle est la méthode recommandée pour éviter les doublons de clients (référence externe, SIREN, email) ? Plusieurs boutiques sur une même société Confirmez-vous qu’il est possible de créer un token API par boutique sur la même société, avec une limite de débit propre à chaque token ? Plusieurs séries de numérotation (un préfixe par boutique) dans une même société posent-elles un problème côté Pennylane : contrôle des doublons, conformité, numérotation interne ? Une facture déjà transmise à la plateforme peut-elle encore être catégorisée en analytique via l’API (une catégorie par boutique), ou est-elle verrouillée ? D'avance merci pour votre aide et vos réponses, Belle journée3Vues0like0CommentaireAPI EBP GESCOM
Bonjour, pour être sûr d'avoir bien compris, un client qui utilise EBP cloud ne peut pas connecter ce dernier à pennylane pour transférer ses factures de vente par exemple ? La liaison via chift ne fonctionne que si le client utilise une version "physique" d'EPB, c'est bien ça ? Merci pour vos retour.Répondu68Vues0like1CommentairePennylaneConnect / Salesforce : statut non actualisé, erreur 403 Cloudflare
Bonjour, Je teste le connecteur officiel PennylaneConnect entre Salesforce et Pennylane, dans des environnements sandbox. La création d’une facture finalisée depuis Salesforce fonctionne correctement. En revanche, les changements de statut effectués ensuite dans Pennylane ne sont pas répercutés dans Salesforce. Test réalisé Je crée une facture depuis Salesforce en sélectionnant Finalisée. La facture apparaît dans Pennylane au statut À venir. Salesforce affiche le bon numéro de facture et le statut À encaisser. Dans Pennylane, je passe manuellement la facture au statut Encaissée. Dans Salesforce, j’utilise l’action Actualiser, puis je recharge la page. Le statut reste À encaisser. Le sens Salesforce → Pennylane fonctionne donc pour la création. La mise à jour du statut dans le sens Pennylane → Salesforce ne fonctionne pas dans ce test. Diagnostic obtenu Les journaux Salesforce montrent que l’action InvoiceUtility.refreshInvoice appelle : GET https://connect.pennylane.com/api/invoices/{id}/hard-refresh Cet appel reçoit : HTTP 403 Forbidden Une réponse HTML, au lieu des données attendues Une page de vérification Cloudflare « Just a moment… » Les autres appels répondent HTTP 200. La vérification de connexion renvoie isSetupWorking: true et isInvoicingSetupWorking: true. Cependant, la consultation des factures renvoie toujours status: "VALIDATED" et payment_status: "DUE". Version installée PennylaneConnect 3.2 — June 2026, package Salesforce non géré. Ma demande Quelqu’un a-t-il déjà rencontré ce blocage Cloudflare sur l’actualisation des factures ? Existe-t-il une correction ou une version plus récente du connecteur ? Je souhaite également connaître le mécanisme et le délai de remontée des statuts de paiement vers Salesforce. Le chatbot support me renvoie vers mon intégrateur. Or, mon intégrateur actuel ne maîtrise pas le fonctionnement technique de PennylaneConnect. J’ai besoin que ce diagnostic puisse être examiné par l’équipe technique Pennylane responsable du connecteur, notamment concernant le blocage sur connect.pennylane.com. Merci pour votre aide.Répondu76Vues0like1CommentaireMise à jour des connexions fournisseurs
Serait-il possible de mettre à jour les connecteurs fournisseur disponible via powens afin que les factures puissent remonter automatiquement ? Cela serait un vrai gain de temps et évitera de se connecter sur chaque site à la recherche d'une factureRépondu232Vues0like6CommentairesIntegration Pennylane Connect - shopify
Bonjour, nous essayons de mettre en place l'intégration Pennylane Connect - Shopify, mais rencontrons plusieurs manquements remontée partielle des factures pennylane vers shopify Cette intégration déclenche la génération de la facture Pennylane correspondant à la commande shopify. Nous arrivons par ailleurs à faire remonter dans la majeure partie des cas la facture ainsi générée sur pennylane vers le backoffice shopify, au niveau de la commande correspondante. exemple : Cependant, pour certaines ventes cette facture pennylane ne remonte pas vers la commande shopify correspondante, pour une raison que nous ignorons. Exemple : =>Certains parmi vous ont ils réussi à obtenir cette remontée de manière systématique ? 2. Pas de rapprochement automatique des transactions stripe correspondantes/ suggestions de facture ? Nous essayons par ailleurs d'avoir un rapprochement automatique dans pennylane des transactions correspondant aux montants encaissés via ces ventes (principalement via stripe) avec les factures de vente correspondant dans pennylane. Mais aucune suggestion automatique nest proposée dans pennylane, ou alors de manière très rare et très partielle (pas de suggestion ou alors rare suggestion d'une seule facture parmi plusieurs dans le cas d'une transaction stripe shopify incluant les montants de plusieurs factures de vente shopify, pas de suggestion au niveau des commissions,...) . => Ya til quelquechose que nous avons raté dans les paramétrages de cette intégration ? merci pour vos lumièresRépondu774Vues0like6CommentairesAccès API au validateur
Bonjour, Actuellement il est possible d'utiliser l'url ....../invoices/e_invoice_validator pour uploader un pdf et avoir le compte-rendu détaillé des anomalies qui ont été détectée. Est-ce qu'il est possible d'avoir la même fonctionnalité en API lorsqu'un fichier est déposé par https://app.pennylane.com/api/external/v2/customer_invoices/import => { "type": "cii", "profile": "facturx_en16931", "valid": false, "validation_results": { "XSD Structure": { "valid": true, "errors": [], "warnings": [] }, "Factur-X": { "valid": true, "errors": [], "warnings": [] }, "French Rules (BR-FR)": { "valid": true, "errors": [], "warnings": [] }, "PPF Portal": { "valid": false, "errors": [ { "rule_id": "G6.25", "message": "Value must be greater than 2026-09-04", "locations": [ "BT-74 - billing_period_attributes.end_date" ] } ], etc... MerciRépondu94Vues0like3CommentairesAPI v2 : tag ou custom field sur les factures fournisseurs, pour les outils de conformité
Bonjour, Je suis DAF d'un groupe de PME (7 sociétés sur Pennylane) et éditeur d'un outil de vigilance fournisseurs (obligation de l'article L.8222-1 du Code du travail : attestation URSSAF tous les 6 mois, Kbis, etc.) connecté à l'API v2 de Pennylane. Le besoin : afficher l'état du dossier de vigilance de chaque fournisseur directement sur ses factures dans Pennylane, pour que la personne qui prépare les règlements le voie au moment de payer, sans changer d'outil. Concrètement, une mention du type « Dossier de vigilance : aucune anomalie au 16/09/2026 » ou « Attestation URSSAF manquante », mise à jour par l'API quand l'état change. Aujourd'hui, aucun champ des factures fournisseurs ne peut porter cette information sans écraser une donnée du client : le libellé est celui du comptable, external_reference est la clé d'intégration d'autres outils, les catégories analytiques sont remplacées en bloc par l'endpoint. Les custom header fields récemment ajoutés ne concernent que les factures client. La demande : un champ dédié aux intégrateurs sur les factures fournisseurs (custom field, tags, ou une « note d'intégration » propre à l'application), modifiable par l'API, visible et si possible filtrable dans l'écran de règlement. Un champ par application connectée éviterait que deux intégrations s'écrasent. Ce besoin est commun à tous les outils de conformité fournisseurs (vigilance, LCB-FT, RSE) : c'est l'information dont le service comptable a besoin exactement au moment du paiement. Merci, Loïc AssuiedRépondu50Vues0like1Commentaire