Génération PDF et Factur-X

Vavang Invoice distingue deux responsabilités PDF. Les séparer est essentiel avant toute personnalisation de la chaîne de rendu.

PDF source de la facture

Le PDF visuel d’origine est fourni par Sylius InvoicingPlugin via son InvoiceFileProviderInterface, câblé dans le plugin sous sylius_invoicing.provider.invoice_file.

Vavang Invoice n’expose ni second moteur de rendu visuel PDF ni couche de numérotation concurrente. Pour modifier l’apparence de la facture source, personnalisez le chemin de rendu du Sylius InvoicingPlugin en amont.

Le générateur de conformité récupère les octets du PDF source et les transmet à :

FacturXGeneratorInterface::generate(ElectronicInvoice $invoice, string $sourcePdfContent)

Point d’extension de génération Factur-X

SyliusInvoicePlugin\FacturX\FacturXGeneratorInterface constitue la frontière Vavang supportée pour générer un document Factur-X à partir de la facture électronique mappée et des octets du PDF source.

L’implémentation par défaut est actuellement HorstoekoFacturXGenerator, mais le code applicatif doit dépendre de l’interface et non de cette classe concrète.

La décoration convient pour l’observabilité ou des contrôles pré/post propres au projet. Un remplacement complet doit retourner un GeneratedFacturXDocument valide et rester compatible avec l’enregistrement du XML structuré, les contrôles d’intégrité et la chaîne de validation en aval.

La validation est un contrat séparé

La génération et la validation sont volontairement séparées. SyliusInvoicePlugin\Validation\ElectronicDocumentValidatorInterface valide le XML structuré produit par la chaîne de conformité.

Remplacer le validateur par une implémentation permissive uniquement pour faire passer un projet est dangereux : les transitions en aval supposent qu’un document validé a réellement passé les contrôles de facture électronique configurés.

Immutabilité lors d’une régénération

Le générateur de conformité n’écrase pas aveuglément les artefacts déjà émis. Si un document contient déjà un XML structuré figé, le XML régénéré doit lui correspondre. L’intégrité du PDF Factur-X existant est également vérifiée avant réutilisation.

Un générateur personnalisé doit donc être déterministe pour les mêmes données fiscales figées et le même PDF source. Un générateur qui produit un XML fiscal matériellement différent pour un document déjà stocké provoquera volontairement l’échec de la régénération.

Ordre de personnalisation recommandé

1. Modifiez l’apparence de la facture source en amont dans Sylius InvoicingPlugin.
2. Décorez FacturXGeneratorInterface pour le logging, les métriques ou des contrôles additionnels non mutatifs.
3. Remplacez FacturXGeneratorInterface uniquement si vous maîtrisez l’intégralité du contrat de génération Factur-X et testez validation/intégrité de bout en bout.
4. Ne contournez ni ElectronicDocumentValidatorInterface ni les contrôles de stockage immuable.