VAVANG Invoice RC
FR EN
VAVANG INVOICE / DOCS / EN

PDF and Factur-X generation

Vavang Invoice has two distinct PDF responsibilities. Keeping them separate is essential when customizing the rendering pipeline.

Source invoice PDF

The original visual invoice PDF is provided by Sylius InvoicingPlugin through its InvoiceFileProviderInterface, wired in the plugin as sylius_invoicing.provider.invoice_file.

Vavang Invoice does not expose a second visual-PDF renderer or numbering layer. If you need to change the appearance of the source invoice, customize the upstream Sylius InvoicingPlugin rendering path.

The compliance generator obtains the source bytes and passes them to:

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

Factur-X generation extension point

SyliusInvoicePlugin\FacturX\FacturXGeneratorInterface is the supported Vavang boundary for generating a Factur-X document from the mapped electronic invoice and source PDF bytes.

The default implementation is currently HorstoekoFacturXGenerator, but application code should depend on the interface, not that concrete class.

Decoration is appropriate for observability or project-specific pre/post checks. A complete replacement must return a valid GeneratedFacturXDocument and remain compatible with the downstream structured-XML recorder, integrity checks and validation pipeline.

Validation is a separate contract

Generation and validation are intentionally separate. SyliusInvoicePlugin\Validation\ElectronicDocumentValidatorInterface validates the structured XML generated by the compliance path.

Replacing the validator with a permissive implementation just to make a project pass is unsafe: downstream state transitions assume that a validated document really passed the configured electronic-document checks.

Immutability during regeneration

The compliance generator does not blindly overwrite issued artefacts. If a document already contains frozen structured XML, regenerated XML must match it. Existing Factur-X PDF integrity is also checked before reuse.

A custom generator must therefore be deterministic for the same frozen fiscal data and source PDF. A generator that produces materially different fiscal XML for an already stored document will cause regeneration to fail by design.

  1. Change the source invoice appearance upstream in Sylius InvoicingPlugin.
  2. Decorate FacturXGeneratorInterface for logging, metrics or additional non-mutating checks.
  3. Replace FacturXGeneratorInterface only when you own the complete Factur-X generation contract and test validation/integrity end to end.
  4. Do not bypass ElectronicDocumentValidatorInterface or the immutable-storage checks.