Sulu Swiss Qr Bill Bundle Laravel Package

Product Decisions This Supports

• Swiss market entry / compliance-driven feature work. The package generates Swiss QR-bills (QR-Rechnung / QR-facture) — the payment-slip format that has been the standard for Swiss invoicing since the 2020 rollout and the 2022 retirement of the orange/red slips. If Swiss billing is on the roadmap, this is the kind of component that turns "we can sell to Swiss customers" into a shippable feature rather than a research project.
• Build vs. buy for document generation. QR-bill output requires a specific payload structure, reference number handling (QRR/SCOR), QR-IBAN rules, and a print layout with a defined 210×105 mm payment section. That is a well-bounded, standards-defined problem — a strong candidate to adopt rather than build, provided the integration surface stays thin.
• Scope decision: which invoicing use cases ship first. The package's value is highest for recurring CHF invoicing in an existing Sulu-backed site (subscriptions, B2B invoices with QR-IBAN + QRR reference, portal-generated bills). It is not a fit for multi-currency, multi-country billing engines.
• Reality check on the brief: this is a Sulu CMS bundle (Symfony), not a Laravel package. That is a material PM-level constraint, because it ties the buy decision to a CMS choice. If the product is on Laravel, this package is not an option and the decision becomes "pick an equivalent library" (e.g. a standalone Swiss QR-bill library) rather than "adopt this bundle."
• Risk posture on a pre-1.0, single-maintainer dependency. Versions 0.2.3 → 0.2.3.1 indicate pre-stable API and a very small community. That argues for treating it as an accelerator behind an internal abstraction, not as a platform commitment.

When to Consider This Package

Consider it when:

• You are running Sulu CMS / Symfony and need QR-bill generation inside the CMS (e.g. attached to Sulu documents or order confirmations) without standing up a separate service.
• The requirement is genuinely Swiss-domestic payment slips in CHF, with standard QR-bill output, and you can tolerate a small, pre-1.0 dependency.
• You want the cheapest path to a demonstrable prototype of Swiss invoicing for a market-validation exercise.

Look elsewhere when:

• You are on Laravel — this bundle will not install or integrate cleanly; evaluate a framework-agnostic Swiss QR-bill library and wrap it.
• You need SLAs, security review evidence, long-term maintenance guarantees, or a vendor to escalate to. A single-author 0.2.x package will not clear most enterprise procurement gates.
• Requirements extend beyond the QR-bill itself: dunning, VAT/MWST handling, multi-currency, e-invoicing formats (e.g. Swiss E-Invoicing / ISO 20022), or legacy ESR/VESR support.
• You need a supported, versioned API surface — 0.2.x means minor releases may break you.

On the 0.2.3.1 release itself: the release notes contain no substantive changelog beyond a diff link between 0.2.3 and 0.2.3.1, which is consistent with a patch-level bump. No new capabilities, no declared breaking changes, no deprecations. It does not change the adoption calculus in either direction; it is a routine version bump to track, not a trigger for a decision review.

How to Pitch It (Stakeholders)

For executives: Swiss invoicing has a hard formatting standard, and this package is a shortcut to meeting it inside a Sulu-based site. It is a small, low-cost component that de-risks a market-entry feature — but it is a young, single-maintainer open-source dependency, so we should treat it as a fast accelerator rather than a long-term platform bet, and keep our own invoicing logic independent of it so we can swap it out.

For engineering: It is a Symfony bundle for Sulu, not Laravel — confirm stack fit before estimating. Integration is deliberately thin: register the bundle, feed it invoice data, get QR-bill output. Recommended guardrails: pin the exact version, wrap the call site behind our own interface/adapter, add tests that validate the generated QR payload and reference numbers against the Swiss standard, and review the licence and upstream activity before committing. The 0.2.3.1 patch carries no documented behaviour changes, so no migration work is implied.

Recommendation: Proceed to a time-boxed spike if we are on Sulu and Swiss billing is a near-term roadmap item; otherwise select a standalone QR-bill library that is not coupled to a CMS. Revisit this assessment when the package reaches 1.0 or when the changelog shows substantive feature or breaking-change content.