Pcc 3 Deklaracja Bundle Laravel Package

Product Decisions This Supports

• Feature scoping for Polish tax compliance. If the roadmap includes anything where a user owes civil-law transaction tax (PCC) — used-car purchases, loan/credit agreements, marketplace sales contracts, leasing — this bundle is a concrete reference for what a PCC-3 declaration actually contains: payer data, transaction type, tax base, rate, and the XML payload the Polish Ministry of Finance expects.
• Build vs. buy vs. borrow. Still not a "buy" (0 stars, 0 dependents, no community), but the "borrow" case is now stronger, not weaker: v5.1.0 explicitly targets declaration version PCC-3(5) v1-0E, which is a current-generation form revision rather than the 2017-era schema our earlier read assumed. That means the package has tracked at least one schema migration and its 5.x major line implies deliberate versioning against form revisions. The estimate for an in-house build ("a few hundred lines of XML mapping plus validation") still holds — but the spike is now cheaper because we can diff a schema-current reference implementation instead of reconstructing one.
• Roadmap prioritization. The existence of a versioned-but-unloved package in this space is a signal: PCC-3 generation is solved but unowned. That argues for treating it as a small, well-bounded ticket rather than an epic — and for scheduling a schema-verification spike before committing to any date.
• Schema-lifecycle planning (new). The single-line release note is itself informative: this project's release trigger is a Ministry form revision. That is the same maintenance burden we would inherit. Budget for it explicitly — PCC-3 form versions roll over on a statutory cadence, and any generator (ours or vendored) needs a re-verification ticket each cycle, not a one-off build.
• Buyer/user-facing decisions. Whether to surface "we generate your PCC-3 for you" as a product differentiator versus a link-out to the official e-declaration portal is a positioning decision this package helps frame: generation is cheap, submission and liability are not.
• Vendor and partner conversations. When evaluating a Polish accounting/tax SaaS, having this as a baseline lets you ask precise questions ("do you produce PCC-3(5) v1-0E XML, and who signs the declaration?") instead of accepting vague compliance claims.

When to Consider This Package

Adopt (as reference, fork, or vendored snippet) when:

• You are building for the Polish market and PCC-3 is a genuine user need, not a hypothetical.
• You need to target the PCC-3(5) / v1-0E declaration version specifically — v5.1.0 is the release that declares that target, so it is the version to read if you are starting today.
• You are on Symfony, or are willing to isolate the logic behind your own Laravel service class — note the description says Symfony bundle, not Laravel package; there is no service provider, no facade, no Laravel-native config here. In a Laravel codebase you would be porting, not installing. Nothing in v5.1.0 changes this.
• You have in-house PHP capacity and a compliance owner who can validate output against the current Ministry of Finance schema. The release note tells you which form version the code claims to produce; it does not tell you the XML is accepted by the e-declaration gateway. Verify, don't assume.
• You need a starting point or sanity check, not a maintained dependency. Fork it, pin it, own it.
• Budget is tight and the alternative is a multi-week discovery phase with a tax advisor.

Look elsewhere when:

• You require maintained, patched, security-reviewed dependencies. A v5.1.0 release is a positive signal that the project is not abandoned, but with zero dependents and no visible community there is still no support contract, no CVE process, and no guarantee of a v5.2.0 when the next form revision lands.
• You need Laravel-native ergonomics (package discovery, config publishing, queue integration) — you'd be writing that layer yourself, which changes the build estimate substantially.
• You need end-to-end filing: authentication with the e-declaration system, UPO receipt handling, corrections/amendments, audit trails, or multi-entity support. This bundle stops at generation.
• You need multi-version output (supporting both PCC-3(4) and PCC-3(5) during a filing transition window). A release note naming a single target version suggests single-version output; confirm before assuming backwards compatibility.
• Your jurisdiction is outside Poland, or your transactions fall outside PCC scope.
• You are in a regulated or audited environment where dependency provenance and maintenance status are gating criteria — a one-line release note with no changelog detail is thin evidence for an audit file.
• You need typed, tested, documented code you can hand to a new hire. A release note that names a schema version and nothing else is a strong indicator that documentation and change communication are minimal.

How to Pitch It (Stakeholders)

To executives: We re-reviewed the open-source component for generating Polish PCC-3 tax declarations. New information: it shipped v5.1.0, explicitly targeting the current declaration version PCC-3(5) v1-0E. That partially retires our earlier "stale since 2017" concern — the project tracks statutory form revisions — but it remains a small, permissively licensed (MIT) library with no users, no dependents, and no support commitment. Recommendation unchanged: do not adopt it as a dependency. Use it as a free, schema-current reference design to sharpen our build estimate and to brief a tax advisor. Expected outcome is either a small, well-scoped in-house build (days, not weeks, pending gateway validation) or a clear specification to take to a compliance vendor. Add one standing line item to the roadmap: a recurring re-verification ticket each time the Ministry publishes a new form version — that cost exists whoever writes the code.

To engineering: It's a Symfony bundle, not a Laravel package — treat any use as a port, not an install. v5.1.0 targets declaration version PCC-3(5) v1-0E, so read that tag rather than an older branch. The release note is one line and says nothing about breaking changes, so diff v5.0 → v5.1 before assuming anything about the API surface, and do not assume older form versions are still producible. Expect to extract the XML mapping and domain model, rewrite the service-provider/config layer for Laravel, and add tests. Verify output against the Ministry of Finance schema and a real submission path before writing a single line of our own. Isolate it behind an interface so we can swap implementations if we later buy.

To legal/compliance: We are not relying on third-party code to determine tax liability. The v5.1.0 release indicates the library now targets the PCC-3(5) v1-0E form version, which is useful evidence that the domain is tractable and current — but a version declaration in a release note is not a compliance attestation. Any generation logic we build will be reviewed and signed off by a qualified advisor, and the question of who files and who is liable remains a product decision, not a library one.