Polish VAT-registered companies must submit their VAT records in the government's JPK (Jednolity Plik Kontrolny) structured format — today the combined JPK_V7M (monthly) or JPK_V7K (quarterly) file that merges the VAT return and the VAT register into one signed XML. Odoo core accounting computes VAT correctly and shows a tax report on screen, but it has no native path to the Polish Ministry of Finance schema: there is no built-in model mapping each account.move.line tax entry to the required GTU commodity codes, procedure markers (TP, MPP, FP), and document-type flags (RO, WEW, VAT_RR), nor the exact element ordering the XSD demands. Finance teams end up exporting to spreadsheets and hand-building XML against a filing deadline, which is slow and audit-risky.

ECOSIRE builds a dedicated JPK VAT module for your database. At its core is a new declaration model (models.Model) that gathers the period's posted tax lines, aggregates them into the JPK_V7 declarative fields (P_10 through P_69) using @api.depends computed fields, and serialises the sales and purchase evidence sections element-by-element to match the current published schema. We add the Poland-specific fields your invoices need — GTU codes, procedure and document markers — onto account.move and account.move.line through a clean inheriting model, surface them in the invoice views (XML/OWL) so accountants set them at source, and drive sensible defaults with automated actions where the source data is unambiguous. The generated file is validated against the XSD before it is offered for download, so structural errors surface inside Odoo rather than at the government gateway.

Technically, the module ships its own __manifest__.py declaring dependencies on account (and l10n_pl where your localization uses it), a mapping layer that ties each Odoo tax to its JPK declarative box, and QWeb-driven summary reports so a controller can review the return before submission. Access is locked down with ir.model.access.csv plus record rules so only the finance role can generate or view declarations, and every generated file is stored as an immutable attachment for audit. The generator is exposed over the standard XML-RPC / JSON-RPC API, so an external e-signature or e-Deklaracje submission step can be automated if that is in scope. It targets Odoo 17.0, 18.0 and 19.0, and we confirm Community vs Enterprise behaviour for your edition during scoping (the accounting reporting engine differs between them).

Because this is build-to-order, nothing is shipped blind. We start with a short scoping call to confirm your Odoo version and edition, tax configuration, which JPK variant you file (V7M or V7K), and how GTU/marker data should be captured for your product catalogue. We then build against your requirements, run UAT on a staging copy of your database, and hand over installable source, documentation and a git repository. Typical delivery is one working week from confirmed scope. Pricing starts from $999 (indicative, single-company base scope); multi-company filing, custom GTU auto-classification, data migration of historical periods, or automated e-Deklaracje submission increases the quoted scope.