Product Decisions This Supports
- Polish market-entry compliance scoping. Any product that issues loans, credit, leases, or facilitates movable-property sales in Poland inherits PCC (tax on civil law transactions) obligations. This package models the PCC-3 declaration end to end — taxpayer, transaction basis, tax calculation, and XML output — which is precisely the artifact a finance/ops team will eventually ask engineering to produce. It lets a PM scope that requirement concretely instead of discovering it mid-build.
- Build vs. buy vs. borrow analysis for tax-filing workflows. Treat it as a free, MIT-licensed reference implementation rather than a runtime dependency. It reveals what fields a PCC-3 declaration actually requires and how the XML is shaped, which materially cuts the discovery cost of a bespoke build and sharpens any vendor quote.
- Roadmap signal for lending-adjacent features. Polish consumer-lending operators (the repo's origin, KredytyChwilówki) need PCC-3 for loan agreements. If the roadmap includes BNPL, leasing, factoring, or movable-asset sales in PL, PCC-3 generation is a pre-requisite capability, not a nice-to-have — this package is a cheap way to size it.
- Internal tooling prioritization. Batch declaration generation for a loan portfolio, audit-trail artifacts, and reconciliation against tax-office acknowledgements are concrete internal-tool use cases whose shape this package's object model maps onto directly.
- Vendor due-diligence anchor. It gives the team enough domain vocabulary to challenge the scope, effort, and price of an outsourced "PCC integration."
When to Consider This Package
Consider it when:
- You are building (or scoping) a Laravel/PHP backend for a Polish lending, leasing, or movable-property-sales product and need to understand the PCC-3 XML contract.
- You want a starting schema / domain object model to fork, modernize, and validate against the current official XSD before committing to your own serializer layer.
- You need a fast proof-of-concept to show compliance/legal that the backend can emit a PCC-3 declaration — before funding a build.
- Your team already uses JMS Serializer and wants to reuse annotation-driven XML mapping conventions.
Look elsewhere (or plan to replace) when:
- Production dependency is the goal. Effectively abandoned: last release October 2017, one star, zero dependents. It predates multiple major PHP and
jms/serializer versions, and the PCC-3 schema has likely moved since. Treat every line as unverified.
- You need guaranteed schema conformance — you must validate output against the current official XSD and Ministry of Finance e-filing rules, which this package cannot attest to.
- You need support, security patching, or SLAs — none exist.
- Your stack isn't PHP/Laravel — the value is the domain reading, not the code.
- Your transaction type isn't a loan or movable-property purchase: PCC-3 scope is narrow, and sibling variants (PCC-1, PCC-2, PCC-3/D) aren't covered.
Net PM position: adopt as read-only reference material; budget a 1–2 day spike to diff its model against the live XSD, then decide build-in-house vs. vendor.
How to Pitch It (Stakeholders)
For executives: This is a small, MIT-licensed open-source package from a Polish lender that shows how to generate Poland's PCC-3 tax declaration as XML. It is not something we should ship to production — last updated in 2017, essentially no community, and never validated against the current tax-office schema. Its value is strategic, not operational: for roughly a day of engineering time it de-risks our understanding of a mandatory Polish compliance requirement, informs the build-vs-buy estimate for a lending or BNPL feature, and gives us the vocabulary to challenge vendor quotes. Cost of evaluation is near zero; cost of depending on it is high. Recommendation: approve a short spike, not adoption.
For engineering: A JMS Serializer–based reference model of the PCC-3 declaration (taxpayer, transaction, tax-calculation entities). Useful as a schema crib sheet and starting object model. Expect to fork it, bump PHP and jms/serializer to current versions, regenerate mappings against the live XSD, and add XSD validation plus golden-file regression tests. Do not add it as a Composer dependency in any customer-facing service — vendor it into an internal compliance module behind a Pcc3Generator interface, ideally run in an isolated service/CLI worker to contain legacy dependencies, and secure tax/legal sign-off on sample output before rollout.