Erreur Zapier création de facture
Bonjour, Je teste actuellement Pennylane dont l’avantage pour moi vs Tiime serait de pouvoir générer des factures depuis un tableur Google Sheets en utilisait les connecteurs Zapier. Sauf que, impossible de faire fonctionner le Zap. Je rencontre systématiquement l’erreur suivante : Failed to create a customer invoice in Pennylane Oops an error 400 occurred. Message: The schema of the object invoice.line_items isn't any of the following 'Line item Without Product (including taxes)', 'Line item Without Product (excluding taxes)', 'Line item with existing product', 'Line item with new product' Tout semble pourtant bien configuré. Et je ne suis pas le seul à rencontrer ce problème. --> https://community.zapier.com/troubleshooting-99/pennylane-invoice-generation-zap-fails-due-to-missing-customer-type-28244 Que dois-je corriger ?Répondu202Vues1like1CommentaireNouvelle API Organilog & Pennylane
Bonjour, une nouvelle intégration avec un logiciel de facturation métier a vu la lumière du jour : https://www.linkedin.com/posts/celinegosset_collaboration-api-organilog-activity-7115593217126916096-69A-?utm_source=share&utm_medium=member_desktop Merci @Céline Gosset 👍 Comment vous avez réussi à convaincre l’équipe PL ?Répondu111Vues1like1CommentaireAide à l'utilisation de l'API
Bonjour, J’essaye désespérément de connecter notre CRM avec PennyLane via votre API. Mon but: Avoir les même clients sur le CRM que sur PennyLane. Créer des factures grâce aux devis émis depuis mon CRM. Voir l’avancé des paiements disponible sur PennyLane depuis mon CRM. J’ai l’habitude d’utiliser les API en programmation mais je dois avouer que la votre est particulièrement capricieuse. Problèmes : Il m’est impossible de faire une requête depuis le front (via fetch ou axios en JS) à cause des CORS-POLICY. Je dois implémenter un middleware pour toutes mes requêtes, ce qui est long. Je peux comprendre qu’ils s’agissent d’un impératif de sécurité, mais cela n’est absolument pas avancé dans la documentation, et vous donnez même des exemples de code possible en JavaScript, qui ne marche du coup pas. [Rencontré pour la création d’un custumer] J’utilise l’exemple de la documentation pour créer mon middleware en PHP (voir photo) J’envoie via Javascript, à mon middleware mon objet Custumer formaté avec JSON.stringify() qui ressemble à ce dernier: "{\"customer\":{\"customer_type\":\"company\",\"name\":\"CYNO PRO\",\"address\":\"6 Rue Industrielle\",\"postal_code\":\"67310\",\"city\":\"Wasselonne\",\"country_alpha2\":\"FR\",\"recipient\":\"Fabrice Braun\",\"source_id\":1930,\"emails\":[\"[email protected]\"],\"payment_conditions\":\"custom\"}}" (Soit l’exact même format que nécéssaire pour requêtes en PHP cURL) Pourtant, j’obtiens la réponse suivante: "{\"message\":\"{\\\"customer_type\\\"=>\\\"company\\\", \\\"emails\\\"=>[\\\"[email protected]\\\"], \\\"name\\\"=>\\\"CYNO PRO\\\", \\\"payment_conditions\\\"=>\\\"custom\\\", \\\"source_id\\\"=>1930, \\\"postal_code\\\"=>\\\"67310\\\", \\\"recipient\\\"=>\\\"Fabrice Braun\\\", \\\"notes\\\"=>\\\"Keleve (1000€ Keleve) – Plus grande boutique bouffe/objet animaux de France. Juste échange par mail. Entretenir la relation commerciale (14/04)\\\", \\\"city\\\"=>\\\"Wasselonne\\\", \\\"address\\\"=>\\\"6 Rue Industrielle\\\", \\\"country_alpha2\\\"=>\\\"FR\\\", \\\"delivery_address\\\"=>\\\"\\\", \\\"phone\\\"=>\\\"\\\"} isn't one of in #/paths/~1api~1external~1v1~1customers/post/requestBody/content/application~1json/schema/properties/customer\"}" L’objet customer semble bon car sinon j’ai une erreur plus conventionnel. J’avoue arrivé au bout de toutes les idées possible de formatage de mon objet Customer. Et j’avou aussi être particulièrement perplexe de certains choix que vous avez faits pour votre API (pourquoi devoir utiliser JSON.stringify pour envoyer un objet ?) Je suis à l’écoute de tout retour et vous remercie pour le temps que vous prendrez à me lire. Très cordialement, Tristan.Répondu1 kVues1like2CommentairesChangelog et catégorisation en batch
Bonjour, utilisant le endpoint /'changelogs/customer_invoices' j'ai remarqué que quand un utilisateur catégorisait les factures en batch dans la plateforme pennylane, ça ne créait aucun évènement au niveau du changelog. (une facture catégorisée toute seule en revanche déclenche bien un update) est ce que c'est quelque chose que vous faites ailleurs ? j'entend par batch quand on sélectionne plusieurs factures pour les catégoriser du même tagRépondu14Vues1like2Commentairestag_label et tag_weight dans l'API
Nous utilisons Pennylane pour nos 2 entreprises, et nous alimentons notre outil interne de gestion avec vos données : l'API v2 pour les factures et les catégories, et le Data Sharing pour la partie analytique. Nous souhaitons ne plus dépendre du Data Sharing et tout passer par l'API, mais il nous manque un élément : la ventilation analytique par ligne d'écriture. Ce que nous avons testé la semaine dernière sur nos deux comptes (226 lignes de juillet 2026) : GET /ledger_entry_lines → 200, on récupère bien id, date, debit/credit, journal, ledger_account. Le champ categories est présent mais toujours vide. GET /ledger_entry_lines/{id}/categories → 200 avec items: [] sur toutes les lignes testées. POST /exports avec export_type: analytical_general_ledger → 404. Alors que côté Data Sharing, la table analytical_ledger nous donne pour chaque ligne : tag_group, tag_label, analytical_code et surtout tag_weight — la pondération quand une écriture est répartie sur plusieurs axes (par ex. 50/50 entre deux projets). C'est précisément cette pondération qui nous est indispensable. Mes questions : Existe-t-il un moyen de récupérer par API les axes analytiques et leurs poids par ligne d'écriture ? Quelle est la bonne route pour l'export « grand livre analytique » ? /v2/exports nous renvoie un 404.Répondu62Vues1like3CommentairesRenseigner le “Type de vente” via API v2 lors de la création d’une facture client brouillon
Bonjour, Je crée des factures clients brouillon via l’API Pennylane v2 avec l’endpoint : POST /api/external/v2/customer_invoices La facture est bien créée en brouillon, avec le client, les lignes produits, la date, l’échéance, external_reference et pdf_invoice_free_text. Dans l’interface Pennylane, sur le brouillon, il existe un champ “Type de vente” avec les choix suivants : - Livraisons de biens - Prestations de services - Livraisons de biens et prestations de services Je souhaite renseigner automatiquement : "Livraisons de biens et prestations de services" lors de la création du brouillon via API. J’ai vérifié : - la réponse de GET /api/external/v2/customer_invoices/{id} - l’endpoint /api/external/v2/customer_invoices/{id}/custom_header_fields Mais je ne vois pas ce champ dans les données retournées. Quel champ faut-il ajouter au payload de création, ou quel endpoint faut-il appeler, pour renseigner ce Type de vente via API ? Merci d’avance.Répondu84Vues1like4CommentairesAPI - Accès en écriture aux modules de révision (dossier de travail) et endspoints correspondant
Bonjour, Cabinet utilisateur de Pennylane, je voulais ouvrir une discussion sur la couverture fonctionnelle de l'API publique par rapport à ce qui est disponible dans l'interface. L'API permet aujourd'hui de faire beaucoup de choses très bien (écritures, lettrage, factures, etc.). En revanche, plusieurs modules clés restent inaccessibles en lecture/écriture programmatique, notamment : le dossier de travail / révision (commentaires sur comptes, statuts de révision, diligences) le rapprochement bancaire (matching transactions / écritures, statut de rapprochement) … probablement d'autres ? (module emprunt / immo etc...) Pour les cabinets qui gèrent plusieurs dossiers, ces modules sont au cœur du travail quotidien. Pouvoir y interagir en API ouvrirait pas mal de possibilités (outillage interne, intégrations métier, automatisation des tâches répétitives, mutualisation de règles cabinet…). Y a-t-il une roadmap publique sur l'élargissement de la couverture API ? ou des tokens plus permissif qui peuvent être accordé permettant des accès étendus ? Sauf erreur de ma part les autres méthodes d'automatisation en UI ne sont pas autorisés par les CGU. Merci d'avance,58Vues1like1CommentaireFEC & GLA exports
Bonjour, Je constate des variations parfois importantes dans les temps de préparation des exports FEC et Grand Livre Analytique lors de l’utilisation de l’API. J’ai également l’impression que ces variations se retrouvent dans l’interface Pennylane. Pouvez-vous m’expliquer l’origine de ces écarts de durée ? Travaillez-vous à améliorer la stabilité de ces endpoints ? MerciRépondu81Vues1like1CommentaireMise à jour des contacts sur les customers
Bonjour, Je me posais une question concernant la gestion des contacts dans Pennylane. Est-ce qu’il existe un moyen de mettre à jour les contacts par API en renseignant le rôle, nom, téléphne et pas seulement via des emails bruts ? L’idée serait d’avoir quelque chose de plus proche de ce qui est possible dans l’interface Pennylane, mais via API. Merci d’avance pour votre aide !Répondu134Vues1like3Commentaires