Dernières nouveautés + Follow + Idée
Dernières questions
Questions récentes
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 - Confirmation manuelle obligatoire d'une facture envoyée
Bonjour à tous, Je développe une intégration n8n qui génère et envoie automatiquement des factures Factur-X vers Pennylane depuis ma propre application de facturation, sans aucune intervention humaine dans le flux. Voici le fonctionnement exact de l'automatisation, pour contexte : Génération d'une facture Factur-X (PDF/A-3b + XML EN16931). Résolution/création du client Pennylane via GET/POST /customers et /company_customers, avec mise en cache de l'id client Pennylane renvoyé (customer_id) dans ma propre base, réutilisé à chaque facture suivante pour ce client — pas de recréation de client à chaque envoi. Import de la facture via POST /customer_invoices/e_invoices/imports, en passant explicitement le customer_id déjà connu dans invoice_options. Mise en cache de l'id de facture Pennylane renvoyé, pour éviter tout ré-import en cas de nouvel essai (idempotence côté intégration, puisque l'API ne la garantit pas nativement). Appel POST /customer_invoices/{id}/send_to_pa. Le problème : à l'étape 5, j'obtiens systématiquement : 422 - {"status":422,"error":"The invoice is not eligible for electronic invoicing."} Jusqu'à ce que j'aille cliquer manuellement sur Confirmer dans l'interface Pennylane sur cette facture (statut À traiter, avec la mention Client identifié automatiquement à partir de votre facture importée — alors même que le customer_id était pourtant transmis explicitement, pas déduit automatiquement). Mes questions : Est-ce que ce passage systématique par À traiter est un comportement normal/documenté de e_invoices/imports, indépendant de la qualité des données transmises ? Quelqu'un a-t-il trouvé un moyen d'automatiser cette confirmation (endpoint API dédié, paramètre à l'import, réglage de compte) ? Alternative envisagée : passer par l'endpoint structuré POST /customer_invoices (JSON, sans import de fichier) — quelqu'un a-t-il confirmé que cette route évite l'étape À traiter et reste compatible avec send_to_pa ensuite ? Merci d'avance pour votre aide 🙏RéponduEmilieDEL82il y a 1 jourPremière note156Vues0like4CommentairesAPI ODOO
Bonjour j'ai un client qui utilise ODOO pour sa gestion commerciale et la saisie de toute sa comptabilité. il effectue aussi le lettrage nous avons effectué la connexion avec Pennylane en utilisant l'api existant nous avons juste les factures clients qui viennent de remonter avec l’écriture comtpable ni les factures fournisseurs ni la banque ne remontent est ce que quelqu'un connait et utilise cette connectivité ? en vous remerciant pour votre aide doloresDOLORES19il y a 1 jourPremière note9Vues0like0CommentaireAPI v2 customer_invoices : ajout des scheme ID 0088 et correction du 0225 dans le Factur-X (CII)
Bonjour, Je génère des factures clients via l'API v2 (POST https://app.pennylane.com/api/external/v2/customer_invoices) et j'ai envoyé les fichiers Factur-X (PDF + XML CII) à un client pour test, en vue de la réforme de la facturation électronique. Le retour bloquant de ce client (Leclerc via leur PA Logilec) sur la facture porte sur les identifiants des parties dans le XML CII : 1. Ajouter le scheme ID 0088 (GLN) dans le vendeur (SellerTradeParty) et dans l'acheteur (BuyerTradeParty), au niveau de GlobalID. 2. Corriger le scheme ID 0225 de l'acheteur, dont la valeur doit être au format SIREN_GLN. D'après la documentation de l'API, ni l'endpoint customer_invoices ni la création de client (company_customers) n'exposent de champ pour le GLN, le scheme ID ou l'adresse de facturation électronique. Je ne peux donc pas corriger ces éléments de mon côté. Pouvez-vous m'indiquer : - s'il est possible d'ajouter le GLN (0088) du vendeur et de l'acheteur dans le CII généré, et par quel moyen (champ API, fiche client, paramètres de l'entreprise dans l'interface) ; - comment faire générer l'adresse électronique de l'acheteur (0225) au format SIREN_GLN ; Merci d'avance pour votre aide.SébastienArtytyil y a 3 joursPremière note23Vues0like0CommentaireAPI 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épondu68Vues0like1Commentaire[API] Transaction (non) facultative et archivage de factures fournisseurs
Bonjour, J'ai besoin d'automatiser via API : l'archivage de factures fournisseur (par exemple, stripe envoie facture+reçu identiques, que je dois supprimer à la main - chronophage et automatisable) le passage des transactions en "Non facultatif" (par exemple, tous les achats paypal sont actuellement en facultatif par défaut et je dois les changer 1 par 1, ce qui est extrêmement chronophage et également automatisable) Merci pour votre retourRéponduSiteWil y a 9 joursÉcho naissant51Vues0like1CommentaireJEFACTURE
Bonjour, Je n'arrive pas à connecter notre PA jefacture à PENNYLANE. Quelqu'un a le meme probleme ?RéponduMariec68il y a 11 joursÉcho naissant43Vues0like1CommentairePennylaneConnect / 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éponduChakibElil y a 11 joursPremière note76Vues0like1CommentaireDépôt automatique des factures sur chorus pro
Bonjour, Avez-vous une solution pour faire un dépôt automatique de facture sur Chorus pro en utilisant Pennylane ? Aujourd’hui je le fais manuellement ce qui est extrêmement chronophage... Merci pour votre aide !RéponduEMMANUEL_GOURGAUDil y a 17 joursÉcho naissant714Vues2likes10Commentaires
Filtres
- API102 Publications
- connecteurs60 Publications
- connecteurs logiciel de facturation36 Publications
- connecteurs e-commerce13 Publications
- Connecteur caisse (PoS)6 Publications
- Facturation1 Publication