v0.34.0 — Filing a JPK declaration works end to end: a signature you can actually give, and a screen that tells the truth
External signing (Trusted Profile) was unreachable, and a period that reached it had no way out. We went through the whole filing path and rebuilt the screen: a five-step checklist, refusals that name their reason, and a rejected correction you can rebuild.
The tax module could compute the registers and build the JPK file, but the filing itself could not be walked to the end. The "Trusted Profile" method — the default for most companies — was blocked in every state at once, and a period that reached "awaiting signature" anyway had no exit left: cancelling was forbidden, regenerating was refused, uploading the signature was disabled. Alongside that, the tax settings screen would not save for companies that already had a date stored, and a declaration missing the tax-office code failed to build without saying what was missing. We went through the whole path from settings to the receipt (UPO) and rebuilt the filing screen.
- Both signing branches work. The chosen method now reaches the server and binds: what you pick is what goes. "Authorisation data" stays for natural persons; "Trusted Profile" walks through downloading the metadata, signing at podpis.gov.pl and uploading the signed file back — validated as genuinely the signed counterpart of what we prepared. A period sitting in "awaiting signature" now has a way out: cancelling rolls back the frozen register composition and the bad-debt relief.
- The filing screen is a five-step checklist, not a wizard with a trap. Each step — Figures, Check, Signature, Filing, Receipt — shows its own state and expands in place, driven by the keyboard too (arrows, Home/End). Returning to an already-reviewed step used to leave the user with no interactive element on the page at all; the only way out was a reload.
- A refusal names its reason and leads to where it is fixed. A missing tax-office code has its own message and a link into tax settings, instead of a generic "could not build". Blocking warnings are numbered, carry a hint, and list the documents they are about.
- An XML file we will not hand over says why. Pressing download on a period with a blocking warning used to give a bare 404. Now it answers in a sentence: the file has not been produced yet, the file is unavailable, or the period is blocked — and which of the three it is.
- A rejected correction can be rebuilt. Until now "Generate again" aimed at the period's original declaration and ended in "locked" — a correction the office refused could not be put right from the app at all. The rebuild now applies to that document and keeps its number: a file the office refused never entered its records, so the next attempt is still the same correction. It works for the annual JPK_EWP too, which has no month to be asked for by.
- A filed declaration prints what actually went to the office. The figures are read from the stored snapshot rather than recomputed on every visit; if the registers moved after filing, a note about the divergence stands beside them with a link to the correction. The document's history has its own timestamps, and an office refusal and a local failure are now two different things rather than one date in one column.
- The flat-rate percentage of a closed period is frozen. It used to be resolved afresh on every read, so adding a rate with a past date recomputed every closed month. A period now holds the rate it was computed with, and the schedule can only be corrected up to the point the file reached the office.
- You can see which server the file goes to. The "Test environment" marker stands at the signature, the filing and the receipt itself — so a test UPO is never mistaken for proof that a declaration was filed.