Aide à 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.
registration_number outdated
Hi, we found a bug: the `registration_number` column seems to be completely out of sync for our accounts. We have many examples where the value in this Redshift database doesn't match the value in the "Supplier ID" field of the UI: This is problematic because we are trying to prepare for the e-invoice reporting obligations. We can't rely on the current state of the "Verification" feature of Pennylane, as it only covers French customers or suppliers, but we barely do any business in France; we are only incorporated there, so we need to support the other EU and non-EU countries. We waited +48 h, so the problem is not a sync delay between the Pennylane database and the Redshift database.
API - 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,
