SecureJPK
Zaloguj się

Walidacja JPK_KR_PD

Duplikaty S_1, T_1, D_1, Z_1 i brak D_3 w JPK_KR_PD

Objaw / komunikat błędu

Powtórzony numer konta S_1, kod T_1, numer D_1 albo Z_1. Kod D_3 nie występuje w Kontrahenci. Data D_8 jest poza okresem DataOd–DataDo.

JPK_KR_PD wymaga unikalnych kluczy w słownikach i w dzienniku. Powtórzone S_1 albo T_1, dwa dowody z tym samym D_1, brakujący kontrahent D_3 albo data operacji poza okresem nagłówka są odrzucane zanim bramka sprawdzi samą arytmetykę Ctrl.

Przyczyna techniczna

  • S_1 jest identyfikatorem konta w ZOiS. Drugi wiersz z tym samym S_1 nie jest „doprecyzowaniem analityki”, tylko złamaniem klucza. T_1 pełni tę rolę w Kontrahenci.
  • D_1 numeruje dowody w pliku, Z_1 numeruje zapisy na konto. Eksporter, który w każdym miesiącu startuje od 1 i potem skleja XML-e bez renumeracji, produkuje duplikaty legalne tylko wewnątrz osobnych plików.
  • D_3 w dzienniku musi wskazywać istniejące T_1. Kod wpisany ręcznie, ucięty przy eksporcie (spacja, inne zero wiodące) albo kontrahent obecny tylko w innym miesiącu daje odesłanie w pustkę.
  • D_8 jest datą operacji. Musi wpadać w domknięty zakres DataOd–DataDo z nagłówka. Dowód z 1 stycznia w pliku oznaczonym od 2 stycznia albo data z innego roku po scaleniu bez korekty nagłówka wypada poza oknem.

Jak naprawić błąd krok po kroku

  1. 1

    Zbuduj zbiory S_1 i T_1

    Pierwsze wystąpienie zostaje. Drugie z tą samą wartością wypisz z numerem pozycji. Nie porównuj nazw kont, tylko klucze.

  2. 2

    Pilnuj D_1 i Z_1 w całym pliku

    Liczniki mają być ściśle rosnące i unikalne w skali dokumentu, który wysyłasz. Po klejeniu miesięcy nadaj je od nowa.

  3. 3

    Rozwiąż D_3 dopiero po wczytaniu słownika

    Zbierz kody kontrahentów, potem sprawdź każde D_3. Brak T_1 dla D_3 oznacza albo literówkę, albo kontrahenta, który nie wszedł do unii.

  4. 4

    Porównaj D_8 z DataOd i DataDo jako daty

    Porównanie leksykograficzne działa dla ISO RRRR-MM-DD. Inny format z ERP (DD.MM.RRRR) trzeba znormalizować, zanim ocenisz, czy dzień leży w okresie.

Jak rozwiązuje to architektura SecureJPK

Worker prowadzi zbiory kluczy w trakcie jednego przejścia strumienia: powtórzone S_1, T_1, D_1 i Z_1 trafiają do żółtych ostrzeżeń razem z wartością klucza. D_3 i D_8 są odkładane do końca pliku, gdy słownik Kontrahenci i nagłówkowe daty są już znane, i dopiero wtedy powstaje komunikat „kod nie występuje” albo „data poza okresem”. Przy klejeniu unia T_1 i renumeracja D_1/Z_1 usuwają typowe duplikaty miesięcy. Treść nie opuszcza przeglądarki.

Najczęstsze pytania (FAQ)

Czy dwa konta o tej samej nazwie i różnym S_1 są błędem?
Nie z punktu widzenia klucza. Unikalne jest S_1. Ta sama nazwa przy różnych numerach może być świadomą analityką. Ten sam S_1 dwa razy jest błędem zawsze.
Czy D_3 może być puste?
Jeśli schemat i dowód wymagają kontrahenta, puste D_3 nie wskaże T_1. Walidator zgłasza kod, który nie występuje w Kontrahenci. Operacje bez kontrahenta nie powinny emitować fałszywego D_3.
Dlaczego błąd D_8 widać dopiero na końcu pliku?
DataOd i DataDo są w nagłówku, ale przy strumieniu bezpieczniej domknąć porównanie, gdy cały nagłówek jest już zebrany. Komunikat i tak wskazuje D_1 oraz konkretną datę D_8.