TL;DR — Résumé Rapide

Erreur de validation addenda CFDI: corrigez les erreurs XML, namespace incorrect et rejet PAC lors de la génération de factures avec addenda dans Aspel SAE.

Lors de l’envoi d’une facture électronique à Walmart, Liverpool ou Volkswagen de México, le système renvoie “Error de validación en la addenda” (erreur de validation de l’addenda), ou le portail fournisseur rejette le CFDI en indiquant que l’addenda ne correspond pas au schéma attendu. Cette erreur est fréquente lors de la première configuration de l’addenda d’un nouveau client ou lorsque le client met à jour ses exigences. Cet article explique ce que sont les addendas, pourquoi elles échouent et comment résoudre le problème étape par étape dans Aspel SAE et d’autres systèmes de facturation.

L’Erreur

Les messages d’erreur liés aux addendas apparaissent à différentes étapes du processus de facturation:

  • “Error de validación en la addenda” — message générique dans Aspel SAE lors de la tentative de génération du CFDI
  • “Namespace non déclaré” ou “Prefix not bound” — le XML de l’addenda fait référence à un namespace non défini dans l’en-tête du CFDI
  • “L’élément ‘Addenda’ n’est pas valide selon son DTD/Schéma” — la structure XML ne correspond pas au XSD attendu par le client
  • “CFDI rejeté par le portail — addenda non reconnue” — le CFDI est correctement timbré par le PAC, mais le portail client le rejette lors de sa propre validation
  • “Champ obligatoire absent dans l’addenda” — un élément obligatoire défini dans le XSD du client est absent (par exemple, le numéro de bon de commande dans l’addenda de Walmart)
  • “Version d’addenda non prise en charge” — le client a mis à jour son XSD et votre système génère encore la version précédente

Ces erreurs apparaissent lors de la génération de factures depuis Facturation > Factures lorsque le client a une addenda configurée, ou lors du chargement du XML sur le portail fournisseurs du client après le timbrado.

Cause du Problème

Les addendas sont des extensions XML facultatives que les grands acheteurs corporatifs exigent de leurs fournisseurs pour inclure des informations supplémentaires non couvertes par la norme SAT: numéro de bon de commande, numéro de fournisseur, département des achats, informations logistiques, entre autres. Le SAT permet leur inclusion dans l’élément <cfdi:Addenda>, mais ne les valide pas; la responsabilité de leur structure correcte incombe au fournisseur.

Namespace incorrect ou non déclaré. Chaque addenda d’entreprise possède son propre namespace XML (une URI qui identifie le schéma). Si le namespace dans votre XML ne correspond pas exactement à celui défini dans le XSD du client, la validation échoue. Même une barre oblique finale ou un numéro de version différent dans l’URL l’invalide.

XSD obsolète. Les clients mettent périodiquement à jour leurs exigences en matière d’addenda. Si votre modèle dans Aspel SAE ou votre système a été configuré avec la version précédente du XSD, les nouveaux champs obligatoires seront absents et la validation échouera.

Champs obligatoires manquants ou format incorrect. Chaque client définit ses propres champs obligatoires. Walmart México exige un numéro de fournisseur à 10 chiffres et un numéro de commande à 10 caractères alphanumériques. Liverpool exige le numéro de département. Volkswagen exige le code matériel Audi/VW dans un format spécifique. Si un champ est absent ou dans un format différent de celui attendu, le XSD le rejette.

Position incorrecte de l’addenda dans le XML. L’addenda doit être le dernier élément dans <cfdi:Comprobante>, après tous les compléments. Certains systèmes de facturation l’insèrent à la mauvaise position, ce qui invalide l’intégralité du XML.

Incompatibilité de version entre l’addenda et la version du CFDI. Lors de la migration de CFDI 3.3 à CFDI 4.0, certains XSD d’addenda ont dû être mis à jour pour assurer la compatibilité. Si le client n’a pas mis à jour son XSD ou si vous n’avez pas mis à jour le modèle, des conflits de version apparaîtront.

Solution Étape par Étape

1. Obtenir le XSD et la documentation à jour du client

Avant toute configuration, connectez-vous au portail fournisseurs de votre client et téléchargez:

  • Le XSD officiel de l’addenda (il peut y en avoir un par type de document: facture, avoir, etc.)
  • La documentation des champs obligatoires et leurs formats
  • Un exemple de CFDI avec une addenda correctement formée

Si vous n’avez pas accès au portail, contactez l’équipe fournisseurs du client pour qu’elle vous fournisse les documents mis à jour. Ne configurez jamais une addenda à partir de documents non officiels de tiers.

2. Configurer l’addenda dans Aspel SAE

Dans Aspel SAE, allez à Configuration > Facturation électronique > Addendas:

  1. Vérifiez si votre client figure dans la liste des addendas prédéfinies
  2. Si oui, sélectionnez-la et remplissez les champs demandés
  3. Sinon, utilisez Addenda personnalisée et importez le modèle XML du client
  4. Assurez-vous que les champs mappés correspondent aux données correctes de vos documents

Pour les addendas non prises en charge nativement par Aspel SAE, de nombreux prestataires du client (ou le client lui-même) proposent des modèles préconfigurés ou des modules complémentaires installables dans SAE.

3. Valider le XML généré par rapport au XSD

Générez une facture de test et localisez le fichier XML généré (généralement dans le dossier des justificatifs de SAE). Validez-le avec ces outils:

Avec xmllint (ligne de commande):

xmllint --schema addenda_client.xsd mon_cfdi_avec_addenda.xml --noout

Avec Notepad++ et XML Tools:

  1. Ouvrez le XML dans Notepad++
  2. Allez dans Plugins > XML Tools > Validate Now
  3. Sélectionnez le XSD du client lorsqu’il vous le demande

En ligne:

  • FreeFormatter.com > XML Validator — vous permet de télécharger le XML et le XSD pour une validation immédiate

Corrigez chaque erreur signalée: éléments manquants, types de données invalides, attributs obligatoires absents ou namespace mal défini.

4. Vérifier la déclaration du namespace

Ouvrez le XML du CFDI avec n’importe quel éditeur de texte et localisez l’élément <cfdi:Addenda>. L’addenda doit déclarer son namespace dans l’élément racine du CFDI (<cfdi:Comprobante) ou dans l’élément addenda lui-même:

<cfdi:Addenda>
  <wmm:WalmartMexico xmlns:wmm="http://www.walmart.com.mx/esquemas/..." version="1.0">
    <wmm:NumProveedor>1234567890</wmm:NumProveedor>
    <wmm:NumOrden>OC-2026-001</wmm:NumOrden>
  </wmm:WalmartMexico>
</cfdi:Addenda>

Comparez l’URI du namespace (http://www.walmart.com.mx/esquemas/...) avec celle figurant dans le XSD téléchargé auprès du client. Elles doivent être identiques, caractère par caractère.

5. Tester dans le sandbox du PAC

Avant d’émettre le CFDI en production, téléchargez-le dans l’environnement de test de votre PAC:

  • Finkok: portail de test sur sandbox.finkok.com
  • SW Sapien: environnement démo disponible sur leur portail développeur
  • Edicom: sandbox disponible avec vos identifiants de production en mode test

Le PAC validera le CFDI complet. Si l’addenda provoque un XML malformé, le PAC le rejettera avec l’erreur 301 (XML malformé). Si le PAC l’accepte mais que le client le rejette, le problème réside dans la validation interne du portail client (règles métier, pas de structure XML).

Solution Alternative

Si vous ne pouvez pas modifier directement la configuration d’Aspel SAE, une alternative est de générer le CFDI sans addenda depuis SAE et d’ajouter ensuite l’addenda par programmation avant le timbrado, à l’aide d’un script ou d’un outil de transformation XML (XSLT). Certains intégrateurs et cabinets comptables utilisent ce flux lorsque l’addenda du client est trop complexe ou que SAE ne la prend pas en charge nativement.

Une autre option est de travailler directement avec le prestataire technologique agréé du client. Par exemple, Walmart México collabore avec des prestataires EDI tels que GS1 México, Soltec et TCI Commerce, qui proposent des solutions d’addenda pré-validées et mises à jour avec les dernières exigences.

Prévention

  • Téléchargez le XSD mis à jour chaque fois que le client vous notifie des changements. Les grands acheteurs envoient des avis à leurs fournisseurs lorsqu’ils mettent à jour leurs exigences; abonnez-vous à leurs bulletins fournisseurs.
  • Validez le XML de chaque nouvelle addenda avant la mise en production. Ne supposez jamais que la configuration précédente fonctionne avec une nouvelle version du XSD.
  • Conservez une copie du XSD avec lequel l’addenda a été configurée. Vous pourrez ainsi comparer les versions lorsque le client signale des rejets.
  • Testez toujours dans le sandbox du PAC avant la production. Un CFDI avec une addenda malformée rejeté en production peut retarder le paiement de votre facture.
  • Maintenez Aspel SAE à jour. Aspel publie des mises à jour incluant de nouvelles versions d’addendas pour les clients fréquents comme Walmart, Liverpool et les OEM automobiles.
  • Documentez les mappages de champs. Enregistrez quel champ de SAE correspond à chaque élément de l’addenda du client, pour faciliter les mises à jour futures.

Problèmes Connexes

Le CFDI est timbré mais le portail client le rejette. Cela se produit lorsque l’addenda est un XML valide selon le XSD, mais que les valeurs des champs ne passent pas les règles métier du client (par exemple, un numéro de commande qui n’existe pas dans leur ERP). Solution: demandez à l’équipe fournisseurs du client l’erreur spécifique affichée dans son système.

Aspel SAE ne génère pas l’addenda même si elle est configurée. Vérifiez que le champ “Addenda” ou “Client avec addenda” est coché dans le document (facture). Certains clients doivent être configurés individuellement dans le catalogue clients de SAE pour que l’addenda soit générée automatiquement.

Le PAC rejette avec l’erreur “301 - XML malformé” uniquement lorsqu’il y a une addenda. Cela indique que l’addenda introduit des caractères invalides en XML (comme &, <, > non échappés) ou que le namespace n’est pas correctement déclaré. Exportez le XML, ouvrez-le dans un éditeur et vérifiez que le bloc <cfdi:Addenda> est un XML bien formé.

L’addenda VW ou d’un OEM automobile contient des champs inconnus. Les OEM automobiles (Volkswagen, General Motors, Stellantis) exigent généralement des addendas avec des données d’ordre de production, de matériaux et de codes d’usine. Leur documentation technique est volumineuse; contactez directement le service fournisseurs de l’OEM ou son prestataire EDI agréé pour obtenir la spécification complète et des exemples.

Résumé

  • Les addendas sont des extensions XML que les grands clients exigent dans le CFDI pour des données supplémentaires non couvertes par le SAT
  • Les erreurs les plus courantes sont: namespace incorrect, champs obligatoires absents, XSD obsolète et position incorrecte dans le XML
  • Téléchargez toujours le XSD officiel depuis le portail fournisseurs du client avant de configurer l’addenda
  • Validez le XML généré par rapport au XSD avec xmllint, Notepad++ ou un validateur en ligne avant le timbrado
  • Testez dans le sandbox du PAC avant l’émission en production pour éviter des rejets qui retardent le paiement
  • Si Aspel SAE ne prend pas en charge l’addenda de votre client, envisagez un flux d’addenda externe ou contactez le prestataire EDI du client

Articles Connexes