Forum Discussion
magicminimoi
Première note
Première noteDev 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
Bonjour magicminimoi
E-reporting (B2C et international) — Les factures B2C importées via l'API n'ont pas besoin d'une transmission séparée : Pennylane, en tant que plateforme agréée (PA), génère automatiquement les données d'e-reporting à partir des factures, encaissements et paiements déjà enregistrés, dès lors que la facture est complète, non brouillon/non archivée, datée dans la période, et que le client est de type particulier (B2C) (source). Il n'y a pas d'option « totaux agrégés par jour » : l'agrégation se fait par bloc taux de TVA/catégorie, pas par jour — rien à pré-agréger côté partenaire (source). Pour les ventes à des clients professionnels étrangers (UE/hors UE), chaque facture reste une ligne distincte, sans fusion (même source). Les données de paiement sont déduites automatiquement des encaissements bancaires rapprochés à la facture ; pas besoin d'un appel explicite type « Mark as paid » (seule la TVA exigible sur encaissement — services/acomptes — est concernée) (source).
Import Factur-X et envoi à la plateforme agréée — Les profils Factur-X supportés incluent BASIC (WL), EN16931/CIUS et EXTENDED (profil étendu France/CTC) — ce n'est donc pas limité à EN16931. L'emplacement XML exact des nouvelles mentions obligatoires (SIREN client, nature de l'opération, adresse de livraison) n'est pas documenté dans les sources consultées — à vérifier. Plusieurs couches de validation existent au traitement (XSD, règles EN16931, Factur-X, BR-FR, règles du portail PPF), mais aucune source ne confirme un mode sandbox ou un endpoint de test partenaire pour valider un fichier ou tester send_to_pa de bout en bout avant envoi réel — non confirmé. Les statuts e_invoicing.status identifiés : accepted, approved, collected, in_dispute, partially_collected, refused, rejected, sent, submitted. .Clients et doublons — Aucune source ne confirme un rapprochement/création automatique du client à partir du SIREN contenu dans le XML Factur-X.
Plusieurs boutiques sur une même société — Aucune des sources consultées ne documente ce point.Je vous invite à ajouter cette recommandation dans la “Liste d’idées” du Forum. Cette liste vous permet de faire des suggestions aux équipes Pennylane, qui seront priorisées en fonction des votes des autres utilisateurs. Vous avez donc également la possibilité d’y voter pour les fonctionnalités suggérées par d’autres utilisateurs
1 Réponse
- Angélique_
Pennylaneur
Bonjour magicminimoi
E-reporting (B2C et international) — Les factures B2C importées via l'API n'ont pas besoin d'une transmission séparée : Pennylane, en tant que plateforme agréée (PA), génère automatiquement les données d'e-reporting à partir des factures, encaissements et paiements déjà enregistrés, dès lors que la facture est complète, non brouillon/non archivée, datée dans la période, et que le client est de type particulier (B2C) (source). Il n'y a pas d'option « totaux agrégés par jour » : l'agrégation se fait par bloc taux de TVA/catégorie, pas par jour — rien à pré-agréger côté partenaire (source). Pour les ventes à des clients professionnels étrangers (UE/hors UE), chaque facture reste une ligne distincte, sans fusion (même source). Les données de paiement sont déduites automatiquement des encaissements bancaires rapprochés à la facture ; pas besoin d'un appel explicite type « Mark as paid » (seule la TVA exigible sur encaissement — services/acomptes — est concernée) (source).
Import Factur-X et envoi à la plateforme agréée — Les profils Factur-X supportés incluent BASIC (WL), EN16931/CIUS et EXTENDED (profil étendu France/CTC) — ce n'est donc pas limité à EN16931. L'emplacement XML exact des nouvelles mentions obligatoires (SIREN client, nature de l'opération, adresse de livraison) n'est pas documenté dans les sources consultées — à vérifier. Plusieurs couches de validation existent au traitement (XSD, règles EN16931, Factur-X, BR-FR, règles du portail PPF), mais aucune source ne confirme un mode sandbox ou un endpoint de test partenaire pour valider un fichier ou tester send_to_pa de bout en bout avant envoi réel — non confirmé. Les statuts e_invoicing.status identifiés : accepted, approved, collected, in_dispute, partially_collected, refused, rejected, sent, submitted. .Clients et doublons — Aucune source ne confirme un rapprochement/création automatique du client à partir du SIREN contenu dans le XML Factur-X.
Plusieurs boutiques sur une même société — Aucune des sources consultées ne documente ce point.Je vous invite à ajouter cette recommandation dans la “Liste d’idées” du Forum. Cette liste vous permet de faire des suggestions aux équipes Pennylane, qui seront priorisées en fonction des votes des autres utilisateurs. Vous avez donc également la possibilité d’y voter pour les fonctionnalités suggérées par d’autres utilisateurs
