ERP avec Verifactu connecté à PrestaShop : quelles données circulent et dans quel sens

Le règlement espagnol sur les systèmes informatiques de facturation (le Real Decreto 1007/2023, décret royal connu sous le nom de Verifactu, qui fixe les exigences des logiciels de facturation en Espagne) a obligé de nombreuses boutiques à se poser une question qu'elles ne se posaient pas avant : quel programme émet vraiment mes factures ? Si c'est PrestaShop, la boutique est le système de facturation et doit être conforme. Si c'est un ERP, c'est l'ERP qui doit l'être, et PrestaShop devient une source de données.

Cet article traite de ce second cas : un ERP avec Verifactu connecté à la boutique. Ce qu'il doit recevoir, ce qui peut revenir et où les choses cassent le plus souvent.

Ce qu'exige le règlement, pour ce qui touche à l'intégration

Sans entrer dans tous les détails, trois idées du règlement conditionnent la façon de connecter la boutique à l'ERP :

• Chaque facture génère un enregistrement de facturation chaîné au précédent, qui ne peut pas être modifié sans laisser de trace.
• La facture porte un code QR grâce auquel le destinataire peut la vérifier.
• Le système qui facture est le responsable. Il ne suffit pas qu'un programme soit conforme si les vraies factures sortent d'un autre.

La conséquence pratique est qu'une facture émise est définitive. Si elle sort avec une TVA erronée, on ne la corrige pas en la modifiant : on émet une facture rectificative (factura rectificativa en droit espagnol, qui annule ou ajuste la facture d'origine), elle aussi enregistrée. C'est pourquoi la qualité des données qui arrivent de la boutique compte plus qu'avant.

Une seule source de factures

La première erreur d'intégration n'est pas technique : c'est d'avoir deux systèmes qui émettent des factures pour la même vente. PrestaShop génère son PDF de facture quand la commande passe à un état configuré, et l'ERP génère la sienne. Le client en reçoit une, le cabinet comptable en voit une autre et les numérotations ne concordent pas.

Si c'est l'ERP qui facture, décidez ce que PrestaShop fait de son document : ne plus le générer, ou permettre au client de télécharger la facture de l'ERP à la place de la facture native. Ce qui ne doit pas arriver, c'est que deux factures différentes circulent pour une même vente.

De la boutique vers l'ERP

Ce dont l'ERP a besoin pour chaque commande afin de bien facturer :

• Client : nom ou raison sociale, NIF (numéro d'identification fiscale espagnol) s'il y en a un, adresse de facturation (pas celle de livraison) et pays.
• Lignes : référence, quantité, prix unitaire hors taxes, taux de TVA appliqué et remise de ligne.
• Frais de port et remises globales, chacun avec son taux de TVA. Un bon de réduction d'un montant fixe sur un panier contenant des produits à plusieurs taux est une source classique d'écarts.
• Total encaissé, le chiffre avec lequel tout ce qui précède doit concorder.
• État et moyen de paiement, pour savoir quand facturer et comment rapprocher l'encaissement.

Le problème des arrondis

PrestaShop calcule les taxes avec sa propre logique d'arrondi (par ligne, par produit ou sur le total, selon la configuration), et pour certaines combinaisons de quantités, de prix et de remises, la somme des bases et des montants de TVA ne correspond pas au centime près au montant encaissé. Si l'ERP recalcule de son côté, un écart d'un centime apparaît ; s'il recopie les montants tels quels, la facture peut afficher une TVA qui n'est pas exactement le pourcentage de la base. Dans les deux cas, cela finit en travail manuel. L'intégration doit choisir une règle et l'appliquer toujours : la plus courante consiste à respecter le total payé et à ajuster la base pour que tout concorde.

De l'ERP vers la boutique

Le sens inverse est facultatif et dépend de chaque activité :

• Factures et factures rectificatives pour que le client les télécharge depuis son compte.
• État de la commande si l'ERP gère l'expédition.
• Stock et prix si c'est l'ERP qui pilote le catalogue.

Pour chaque donnée, définissez qui en est le propriétaire. Si le stock peut être modifié des deux côtés, tôt ou tard l'un écrasera l'autre. Une donnée, un propriétaire, et l'autre système se contente de la lire.

Retours et factures rectificatives

C'est là que la plupart des intégrations échouent. Un remboursement partiel, un échange de produit ou un remboursement des frais de port dans PrestaShop génère (ou non) un avoir dans la boutique, mais ce qui a une valeur fiscale, c'est la facture rectificative émise par l'ERP, liée à la facture d'origine. Avant de mettre l'intégration en service, testez au moins ces cas avec de vraies commandes dans un environnement de test :

1. Commande avec plusieurs taux de TVA et un bon de réduction d'un montant fixe.
2. Retour d'une unité parmi plusieurs sur une même ligne.
3. Retour avec et sans frais de port.
4. Commande annulée avant facturation et après facturation.
5. Client qui demande une facture avec son NIF après avoir acheté.

Comment démarrer sans mauvaises surprises

Changer de système de facturation fait partie de ces opérations qu'il vaut mieux mener à un moment calme et avec une bascule nette :

1. Fixez une date de bascule. Jusqu'à ce jour, c'est l'ancien système qui facture ; à partir de ce jour, uniquement l'ERP. Pas de cohabitation « pendant quelques semaines ».
2. Clôturez l'ancienne numérotation et décidez des nouvelles séries avec votre cabinet comptable.
3. Passez en revue les commandes ouvertes à la date de bascule : celles qui seront encaissées après, est-ce déjà l'ERP qui les facture ?
4. Surveillez les premières semaines en comparant chaque jour les commandes encaissées et les factures émises. Tout écart se voit tout de suite et se corrige avant de s'accumuler.

Erreurs courantes

• Facturer à la création de la commande au lieu de l'encaissement : les commandes dont le paiement échoue génèrent des factures qu'il faut rectifier.
• Utiliser l'adresse de livraison comme adresse fiscale.
• Des intégrations qui relancent sans contrôle et créent deux factures pour la même commande.
• Plusieurs boutiques, une seule configuration, sans distinguer quelle société facture chaque boutique.
• Une boutique pas à jour avec d'anciens modules de paiement ou de taxes qui modifient des montants à l'insu de l'ERP. Avant d'intégrer, il est préférable d'avoir PrestaShop et ses modules dans des versions maintenues.

Comment le résoudre dans PrestaShop

CoreGest est l'ERP que nous développons chez Rekire. Il se connecte à PrestaShop, télécharge les commandes et enregistre chaque facture dans Verifactu sans aucune saisie. Il corrige les arrondis de TVA en ajustant les bases au total payé, avec un centime d'écart au maximum, et gère les factures rectificatives depuis l'ERP lui-même. Il accepte plusieurs boutiques et plusieurs sociétés dans un seul compte. L'offre CoreGest ERP · Verifactu con PrestaShop comprend le nécessaire pour être conforme à Verifactu depuis la boutique ; CoreGest ERP completo ajoute les autres modules de l'ERP : caisse avancée, IA avec les données de votre entreprise, comptabilité, trésorerie et remises de prélèvements.