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ée
API 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 dolores
API 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.
import facturx - duplication invoice_number
j'utilise le endpoint j'utilise le endpoint `customer_invoices/e_invoices/imports` pour importer des fichiers facturx. Il est bien impossible d'importer deux fois le même fichier par contre il est possible d'importer deux facturx différents avec le même numéro de facture <rsm:ExchangedDocument> <ram:ID>FAC34305</ram:ID> ce qui donne (ce ne sont pas les mêmes factures): est-ce qu'il ne serait pas possible de permettre de spécifier un external_reference pour la facture, par exemple via l'objet invoice_option pour permettre un dédoublonnage comment il me semble que cela fonctionne sur: POST: customer_invoices, POST: customer_invoices/importimport facturx - xml invalide
Bonjour, j'utilise le endpoint `customer_invoices/e_invoices/imports` pour importer des fichiers facturx. Mon problème est que l'import fonctionne dans tous les cas, y compris quand le xml du facturx est invalide. La seule différence c'est que dans ce cas j'obtiens une facture avec: "schematron_validation_status":"invalid" et un message (dans l'ihm) comme quoi je dois archiver la facture et l'importer à nouveau. Est-il possible que l'api refuse l'import en cas de xml invalide ?
