Pcc 3 Deklaracja Laravel Package

Technical Evaluation

Architecture fit. Despite the "Laravel package" label, this is a framework-agnostic Composer library of DTO/domain classes that describes a Polish PCC-3 declaration and serializes it to XML via JMS Serializer annotations. There is no service provider, config, facade, or migration. From a product-architecture standpoint that is actually convenient: the capability it represents is a narrow, well-bounded compliance artifact (taxpayer → transaction basis → tax calculation → declaration document), which maps cleanly onto a single domain module behind an application service. It is a poor fit only if the roadmap expectation is a plug-and-play Laravel component; it is a good fit as the seed of an internally owned PCC-3 generator capability.

Integration feasibility. Low without remediation. Last release October 2017, 1 star, 0 dependents, no issue traffic. The code almost certainly targets PHP 5.6/7.x and JMS Serializer 1.x-era annotations. A Laravel 10/11 application on PHP 8.2+ will hit Composer constraint conflicts, Doctrine annotation-reader deprecations, and possible @SerializedName/type-handling changes. Realistic path: fork, upgrade, validate against the current Ministry of Finance XSD — or rebuild the small DTO surface directly from the schema. Either way the effort is measured in days, not weeks, which is the key input to a build-vs-borrow decision.

Technical risk.

Mitigating factor: MIT license with no CLA or copyleft — forking into an internal VCS and re-licensing internally is legally clean, which materially lowers the "borrow" risk.

Key questions.

• Which PCC-3 schema version does it emit, and does that match the current e-deklaracje specification?
• Does it only assemble declared fields, or also compute tax? If the latter, who signs off on correctness?
• Is there any fixture XML plus XSD validation in the test suite we can lean on as a spec?
• Was this a production system at KredytyChwilówki, or a one-off internal utility?
• Which PCC variant is actually in scope for our product (PCC-1, PCC-2, PCC-3, PCC-3/D)? This package covers one.
• Who owns the annual schema-update obligation — engineering, finance, or an external accounting partner?

Integration Approach

Stack fit. Treat it as an isolated domain dependency, not a Laravel first-class citizen. Vendor it into a bounded namespace, put an internal interface (Pcc3Generator) in front of it, and confine JMS Serializer to that adapter so the rest of the application is insulated from annotation-era code. If the host app cannot tolerate legacy constraints at all, containerize the generator as a small CLI/sidecar service exchanging JSON in and XML out — this also gives a clean upgrade boundary.

Migration path. Recommended: fork into internal VCS, tag 1.0.0-internal, upgrade PHP and JMS constraints, convert annotations to attributes or explicit metadata, add golden-file regression tests, and validate output against the official PCC-3 XSD. Decision gate: if fork-and-harden exceeds ~2–3 engineering days, stop and rebuild the DTOs from the schema — the domain surface is small enough that a rewrite is competitive and leaves a much cleaner long-term asset. Do not install upstream unmodified into any customer-facing service.

Compatibility. Expect friction with PHP 8.x, JMS Serializer 3.x, and Laravel 10/11. On PHP 7.4 / Laravel 6–8 it may install with pinned constraints, but that anchors the product to an unsupported runtime and is not an acceptable long-term posture. Containerization is the cleanest compatibility escape hatch and doubles as a testable unit for CI.

Sequencing. Each step has a product decision attached:

1. Due diligence (0.5d) — inspect code size, tests, license headers, schema version. Decide: worth a spike?
2. Spike (1–2d) — install in a throwaway project, generate a sample declaration, XSD-validate it. Decide: fork vs. rebuild vs. vendor.
3. Harden — dependency upgrade, XSD validation in CI, golden files, versioned output contract. Gate: engineering sign-off.
4. Integrate behind the internal interface, feature-flagged, with audit logging of every generated XML.
5. Validate externally — submit one sample through the e-deklaracje sandbox; obtain tax/legal review of output. Gate: compliance sign-off.
6. Roll out to a limited cohort of transactions before general availability.

Operational Impact

Maintenance. Upstream is dead; internal ownership is mandatory and permanent. Budget recurring effort for annual PCC-3 schema and tax-rule changes, PHP/JMS major upgrades, and dependency patching. The code volume is small, so the work is tractable — but it is a compliance-adjacent component, so "we'll get to it next quarter" is not a viable maintenance strategy. Name an owner.

Support. No vendor, no community, no issue triage, no knowledge base. Support must be internal: a runbook covering generation, validation, submission, and failure recovery, plus a documented escalation path to a tax/legal reviewer. Expect to rely directly on Ministry of Finance e-deklaracje documentation and the official XSD as your primary references.

Scaling. XML generation is stateless and CPU-light; horizontal scaling is trivial and JMS Serializer will not be the bottleneck. Throughput is governed by surrounding workflow — data entry, persistence, submission to the tax portal. The only real scaling concern is operational: batch generation for a loan portfolio should be queued, rate-limited against the portal, and validated asynchronously rather than inline. Do not share serializer state across requests.

Failure modes. Highest impact first: (1) portal rejection from stale schema — mitigation: XSD validation in CI plus a sandbox submission check on every release; (2) silent serialization drift after a JMS upgrade producing well-formed but semantically wrong XML — mitigation: golden-file regression fixtures and field-level assertions; (3) Composer resolution failures blocking deploys — mitigation: internal fork with pinned constraints and a lockfile; (4) PHP runtime upgrades blocked by abandoned constraints — mitigation: containerized generator; (5) incorrect tax amounts if computation is in scope — mitigation: independent recomputation in tests and finance review.

Ramp-up. A mid-level PHP developer can read the code in under a day; JMS Serializer familiarity is the main prerequisite. The larger cost is domain ramp-up on Polish PCC-3 rules and e-deklaracje submission mechanics — plan one to two weeks for a developer plus a tax/legal reviewer to reach production confidence on a fork-and-harden path. For TPM planning: ~2 dev-days for the spike and fork/build decision, ~1–2 sprint-weeks to hardened, signed-off output, and a standing annual maintenance line item thereafter. The value of the package is that it converts an unknown compliance requirement into a scoped, estimable capability — it is a cheap discovery instrument, not a dependency.