SecureJPK
Zaloguj się

Walidacja JPK_KR_PD

Jak połączyć miesięczne pliki JPK_KR_PD w jeden plik roczny

Objaw / komunikat błędu

Dwanaście poprawnych plików miesięcznych nie składa się w jeden roczny: powtórzone T_1, S_1, D_1, Z_1 albo Ctrl z jednego miesiąca przy treści całego roku.

Roczny JPK_KR_PD nie jest sklejeniem dwunastu dokumentów jeden pod drugim. Słowniki trzeba zwinąć po kluczach, dziennik przenumerować, a Ctrl policzyć od nowa. Zrobienie tego DOM-em na dwunastu dużych plikach kończy się brakiem pamięci.

Przyczyna techniczna

  • Kontrahenci są unią po T_1. Ten sam kod w kolejnych miesiącach zostaje raz, z pierwszego wystąpienia. Doklejenie dwunastu sekcji Kontrahenci daje duplikaty T_1, które walidator zgłasza jako złamanie unikalności.
  • ZOiS scala się po S_1. Bilans otwarcia S_4 i S_5 pochodzi z pierwszego pliku, w którym konto wystąpiło. Obroty S_6–S_9 i znaczniki S_12 albo bierzemy z ostatniego wystąpienia (narastająco, tak wystawia część ERP), albo sumujemy miesiące, gdy każdy plik niesie tylko ruch danego miesiąca.
  • D_1 w dzienniku i Z_1 w KontoZapis są licznikami w skali pliku wynikowego, nie miesiąca. Po złączeniu trzeba je nadać od nowa, ciągle przez cały rok. Inaczej luty znowu zaczyna się od D_1=1.
  • D_2 bywa unikalnym numerem dowodu tylko wewnątrz miesiąca. Przy kolizji między plikami klucz dostaje prefiks miesiąca M02_, M03_ (M i numer pliku w kolejności DataOd, od 01). Bez tego roczny plik ma dwa dowody o tym samym D_2.
  • Ctrl z grudnia opisuje grudzień. Po scaleniu C_1–C_5 muszą wyjść z policzonych węzłów i sum groszowych całego roku. DataDo w nagłówku bierze się z ostatniego pliku, DataOd z pierwszego.

Jak naprawić błąd krok po kroku

  1. 1

    Ułóż miesiące po DataOd, nie po nazwie pliku

    Kolejność wyboru w oknie systemu plików jest przypadkowa. Sortowanie po DataOd ustala, który bilans otwarcia jest „pierwszy” i który prefiks M01_–M12_ dostanie kolizja D_2.

  2. 2

    Zwiń Kontrahenci po T_1 i ZOiS po S_1

    Zostaw pierwsze wystąpienie kontrahenta. Na koncie weź S_4 i S_5 z pierwszego pojawienia się, a obroty albo z ostatniego pliku, albo jako sumę miesięcznych S_6–S_9, zależnie od tego, jak wystawia je ERP.

  3. 3

    Przenumeruj D_1 i Z_1 przez cały rok

    Każdy Dziennik dostaje kolejne D_1, każdy KontoZapis kolejne Z_1 w skali pliku wynikowego. Nie zachowuj liczników z plików źródłowych.

  4. 4

    Prefiksuj tylko kolidujące D_2 i przelicz Ctrl

    Jeśli D_2 już wystąpił, dopisz prefiks M02_ (numer pliku w sortowaniu). Na końcu zapisz nowe C_1–C_5 z BigInt. Wynik ląduje w OPFS jako jeden XML UTF-8, bez trzymania dwunastu DOM-ów.

Jak rozwiązuje to architektura SecureJPK

START_MERGE w workerze czyta każdy miesiąc strumieniem, trzyma słowniki jako mapy kluczy, a dziennik przepisuje oknami 4 MB do OPFS (createSyncAccessHandle). Unia T_1, scalenie S_1, ciągła numeracja D_1 i Z_1 oraz prefiks M01_ przy kolizji D_2 dzieją się bez składania całego roku w RAM. Nowe Ctrl jest liczone w groszach. NIP z Podmiot1 zostaje z plików. Pobranie sklejonego XML i wysyłka produkcyjna wymagają pakietu obejmującego rozmiar wyniku.

Najczęstsze pytania (FAQ)

Czy wolno skleić pliki o różnych NIP-ach?
Nie. Przed zapisem pliki muszą mieć ten sam NIP i ten sam KodFormularza oraz rozłączne okresy DataOd–DataDo. Inny NIP oznacza inną księgę, nie kolejny miesiąc.
Kiedy sumować S_6–S_9, a kiedy brać ostatni miesiąc?
Gdy ERP w każdym pliku podaje obroty narastające, ostatnie wystąpienie konta jest już sumą roku. Gdy każdy XML niesie tylko obrót danego miesiąca, te pola trzeba dodać. Zła strategia podwaja albo gubi obrót.
Czy prefiks M02_ zmienia numer dowodu w księgach?
Zmienia klucz D_2 w pliku JPK, żeby spełnić unikalność w strukturze rocznej. Nie księguje ponownie operacji. Stosuje się tylko tam, gdzie ten sam D_2 przyszedł z dwóch miesięcy.