Co zrobić, gdy w CRU JSFP opublikowano błędne dane? Korekta, aktualizacja i wycofanie z publikacji

Najkrótsza odpowiedź

Jeżeli jednostka wykryje nieprawidłowość, powinna przejść przez cztery pytania kontrolne.

1. Po pierwsze: czy błąd został wykryty przed wysyłką do CRU JSFP?
   Jeżeli tak, najbezpieczniej cofnąć rekord z kolejki publikacji do kwalifikacji, poprawić dane lokalnie i wysłać publikację dopiero po ponownej weryfikacji.
2. Po drugie: czy umowa nadal powinna być opublikowana w CRU JSFP?
   Jeżeli tak, co do zasady właściwą ścieżką będzie aktualizacja informacji o umowie, a nie wycofanie publikacji.
3. Po trzecie: czy błąd dotyczy pól wpływających na zakres jawności, strony umowy, przedmiot, wartość, status albo historię zmian?
   Jeżeli tak, korekta powinna wrócić do procesu kwalifikacji i zakończyć się kontrolowaną aktualizacją informacji w CRU JSFP.
4. Po czwarte: czy informacja nie powinna dalej pozostawać publicznie dostępna w obecnym zakresie?
   Jeżeli tak, trzeba rozważyć wycofanie z publikacji i dopiero potem ponowną kwalifikację albo ponowną publikację w prawidłowym zakresie.

Nie każdy błąd oznacza wycofanie publikacji

To jest najważniejszy punkt praktyczny. Wiele zespołów intuicyjnie utożsamia błąd z koniecznością „ściągnięcia” wpisu z rejestru. Tymczasem w wielu przypadkach problem polega po prostu na tym, że opublikowana informacja jest niepełna, zawiera omyłkę albo wymaga odzwierciedlenia późniejszej zmiany umowy.

Ustawa przewiduje udostępnianie i aktualizowanie informacji o umowie w CRU JSFP. Zakres tych informacji obejmuje m.in. numer umowy, datę zawarcia, okres obowiązywania, oznaczenie stron, przedmiot, wartość, status umowy, podstawę nieudostępnienia informacji oraz podstawę dokonania aktualizacji, jeżeli aktualizacja została dokonana.

Dlatego logika działania powinna być następująca:

• jeżeli umowa nadal podlega CRU JSFP, należy dążyć do aktualizacji danych,
• jeżeli sama publikacja była błędną decyzją albo ujawniono dane, które nie powinny dalej być publiczne, należy rozważyć wycofanie z publikacji,
• jeżeli błąd wykryto przed wysyłką, nie „naprawia się CRU JSFP”, tylko porządkuje lokalny rekord i kolejkę publikacji.

Z punktu widzenia zgodności najgorszym rozwiązaniem jest mieszanie tych trybów. Jednostka powinna odróżniać poprawę danych źródłowych, aktualizację wpisu w rejestrze centralnym i wycofanie już opublikowanej informacji.

Kiedy mówimy o korekcie lokalnej

Korekta lokalna jest właściwa wtedy, gdy błąd dotyczy danych pomocniczych, organizacyjnych albo takich pól, które nie zmieniają zakresu informacji przekazywanych do CRU JSFP.

W praktyce może to dotyczyć na przykład:

• uporządkowania danych wewnętrznych jednostki,
• poprawy pola potrzebnego lokalnie do obiegu pracy,
• uzupełnienia braków wymaganych do dalszej obsługi procesu,
• korekty integralności rekordu przed wysyłką do CRU JSFP,
• poprawienia danych roboczych, które nie są elementem informacji publikowanej w rejestrze centralnym.

Lokalny system obsługi umów zwykle musi przechowywać także dane procesowe, robocze i audytowe, które nie są przekazywane do CRU JSFP, ale są potrzebne do wykazania, kto, kiedy, na jakiej podstawie i z jakim skutkiem dokonał kwalifikacji, korekty, aktualizacji albo wycofania.

To ważne, bo CRU JSFP jest rejestrem centralnym służącym publikacji określonego zakresu informacji o umowach. Nie zastępuje lokalnego procesu zarządzania umowami, kontroli danych, kwalifikacji, akceptacji i audytu.

Kiedy potrzebna jest aktualizacja informacji w CRU JSFP

Aktualizacja jest właściwa wtedy, gdy sama umowa nadal podlega ujawnieniu w CRU JSFP, ale opublikowany stan przestał odpowiadać rzeczywistości albo od początku zawierał błąd.

Dotyczy to w szczególności sytuacji, gdy trzeba skorygować albo odzwierciedlić:

• numer umowy albo informację o braku numeru,
• datę zawarcia lub okres obowiązywania,
• dane stron umowy,
• przedmiot umowy,
• wartość umowy,
• dane dotyczące opcji i wznowień,
• podstawę ograniczenia jawności albo zakres nieudostępnienia określonych informacji,
• zmianę statusu umowy po aneksie, wypowiedzeniu, rozwiązaniu, odstąpieniu, cesji albo wygaśnięciu,
• korektę błędu w informacji już przekazanej do CRU JSFP.

Przy aktualizacji nie powinno chodzić o zwykłe „nadpisanie pola”. Rozporządzenie w sprawie CRU JSFP wskazuje, że przyczyna aktualizacji obejmuje w szczególności powołanie się na zmianę umowy, wypowiedzenie umowy, cesję praw lub korektę błędu, wraz ze zwięzłym opisem aktualizacji oraz wskazaniem daty, od której zaistniała ta przyczyna.

Kiedy trzeba rozważyć wycofanie z publikacji

Wycofanie z publikacji jest rozwiązaniem mocniejszym niż aktualizacja. Nie powinno być traktowane jako standardowa reakcja na każdą pomyłkę.

Warto je rozważyć wtedy, gdy problem nie polega już na zwykłej korekcie treści wpisu, tylko na tym, że informacja nie powinna dalej pozostawać publicznie dostępna w obecnym zakresie.

W praktyce może to dotyczyć na przykład sytuacji, gdy:

• umowę błędnie zakwalifikowano do CRU JSFP mimo ustawowego wyłączenia,
• opublikowano informacje, które powinny były zostać objęte ograniczeniem jawności, a zwykła aktualizacja wpisu nie usuwa wystarczająco szybko lub skutecznie skutku nieprawidłowej publikacji,
• ujawniono dane, które nie powinny były trafić do publikacji,
• opublikowano rekord niewłaściwej umowy,
• opublikowano rekord w kontekście niewłaściwej jednostki,
• jednostka chce najpierw zdjąć publiczny wpis, a dopiero potem przeprowadzić ponowną kwalifikację i ewentualną publikację w prawidłowym zakresie.

Trzeba przy tym pamiętać, że w CRU JSFP nie udostępnia się informacji o umowie, co do których prawo do informacji publicznej podlega ograniczeniu na podstawie art. 5 ust. 1 i 2–2b ustawy o dostępie do informacji publicznej. Jeżeli więc problem dotyczy zakresu jawności, nie powinien być traktowany wyłącznie jako problem techniczny.

Wycofanie z publikacji nie jest też „skasowaniem problemu”. To odrębna operacja procesowa, która powinna mieć uzasadnienie i pozostawiać ślad w historii działań.

Co wynika z API MF

Na dzień 4 lipca 2026 r. oficjalny dokument OpenAPI środowiska testowego MF wskazuje wersję 1.3.2. Kontrakt techniczny przewiduje m.in. publikację i aktualizację umów przez POST /v1/api/publish/agreements, wycofanie opublikowanych umów przez POST /v1/api/publish/withdraw, pobieranie szczegółów umowy przez GET /v1/api/publish/{agreementId}, pobieranie podsumowań przez GET /v1/api/publish/summary oraz pobieranie statusów przez GET /v1/api/publish/status.

Z opisu endpointu POST /v1/api/publish/withdraw wynika, że operacja wycofania dotyczy umów opublikowanych, niebędących w trakcie modyfikacji. Dla każdej umowy wymagane jest przekazanie uzasadnienia wycofania, a operacja jest rejestrowana w historii zmian umowy wraz z przekazanym komentarzem.

To pokazuje bardzo ważną zasadę praktyczną: wycofanie nie powinno być używane jako skrót dla każdej pomyłki. To osobna operacja, z uzasadnieniem, historią i warunkami biznesowymi po stronie API.

Natomiast walidacja danych przed wysyłką, rejestrowanie żądań i odpowiedzi, obsługa ponowień, kontrola statusów oraz rozliczalność procesu powinny być zapewnione przez system lokalny integrujący się z CRU JSFP. API MF udostępnia kontrakt techniczny i operacje integracyjne, ale to po stronie jednostki oraz jej systemu lokalnego pozostaje organizacja procesu, kwalifikacja danych i audyt działań.

Co zrobić, gdy błąd wykryto jeszcze przed publikacją

Wiele problemów da się zatrzymać zanim staną się problemem publicznym. Jeżeli umowa jest dopiero w lokalnej kolejce publikacji albo oczekuje na kwalifikację, zwykle lepiej:

1. cofnąć wpis do kwalifikacji,
2. poprawić dane lokalnie,
3. ponownie przejść przez ocenę CRU JSFP,
4. dopiero potem wysłać rekord do MF.

To bezpieczniejsze niż wysyłanie rekordu „żeby zdążyć”, a następnie gaszenie skutków w rejestrze centralnym.

Trzeba też pamiętać o terminach. Informacje o umowie udostępnia się i aktualizuje w CRU JSFP bez zbędnej zwłoki, nie później jednak niż w terminie 30 dni odpowiednio od dnia zawarcia umowy albo od dnia zaistnienia zmiany informacji o umowie, z wyłączeniem dni awarii systemu, o której mowa w ustawie. Termin nie powinien jednak prowadzić do publikowania danych bez kontroli, jeżeli błąd został wykryty jeszcze przed wysyłką.

Błąd dotyczący danych osobowych albo ograniczenia jawności

Jeżeli błąd dotyczy danych osobowych albo zakresu informacji wyłączonych z jawności, sprawa nie powinna być traktowana wyłącznie jako problem techniczny.

W takim przypadku decyzja o aktualizacji albo wycofaniu powinna być udokumentowana także pod kątem:

• podstawy jawności lub ograniczenia jawności,
• zakresu ujawnionych danych,
• przyczyny błędu,
• czasu trwania nieprawidłowej publikacji,
• osoby lub komórki odpowiedzialnej za kwalifikację,
• działań naprawczych.

Ma to znaczenie również dlatego, że kierownik jednostki jest administratorem danych w zakresie informacji o umowie zamieszczonych przez tego kierownika w CRU JSFP, a obowiązki administratora danych w tym zakresie wykonuje wyłącznie kierownik jednostki.

Dlatego błędna publikacja danych nie powinna być zostawiona bez notatki, uzasadnienia i śladu decyzyjnego. Nawet jeżeli technicznie da się szybko wykonać aktualizację albo wycofanie, jednostka powinna umieć później wykazać, dlaczego wybrała taki tryb działania.

Jak wspiera to system „Ewidencja Umów JSFP”

System „Ewidencja Umów JSFP” wspiera te scenariusze na kilku poziomach.

1. Po pierwsze, rozdziela korektę lokalną od workflow zmian wpływających na CRU JSFP.
   Oznacza to, że nie każda poprawka jest traktowana jak zwykła edycja, ale też nie każda wymaga od razu wycofania z publikacji.
2. Po drugie, pozwala cofnąć wpis z kolejki publikacji do kwalifikacji, jeżeli błąd wykryto przed wysyłką do MF.
   To szczególnie przydatne wtedy, gdy operator zauważy nieprawidłowość jeszcze na etapie przygotowania danych do publikacji.
3. Po trzecie, wspiera kontrolowaną aktualizację danych po zmianie umowy albo po korekcie błędu.
   Jeżeli zmiana dotyczy pól wpływających na informacje przekazywane do CRU JSFP, system przywraca umowę do kwalifikacji, czyści poprzednią decyzję CRU i prowadzi rekord przez ponowną ocenę oraz publikację typu update.
4. Po czwarte, obsługuje wycofanie z publikacji z poziomu workflow.
   Dla umów opublikowanych system wymaga wskazania daty i uzasadnienia, blokuje operację przy aktywnej kolejce publikacji i zapisuje całą operację w audycie.
5. Po piąte, zapewnia ślad rozliczalności.
   System przechowuje historię publikacji, logi żądań i odpowiedzi, statusy kolejki, decyzje kwalifikacyjne i audyt działań użytkowników. Dzięki temu jednostka może później odtworzyć nie tylko to, że „coś poprawiono”, ale też kto, kiedy i dlaczego podjął określoną decyzję.
6. Po szóste, system zapewnia mechanizmy kontrolne dla przypadków technicznych.
   Dotyczy to sytuacji, w których konieczna jest weryfikacja spójności identyfikatorów, historii publikacji albo statusów integracyjnych. Takie działania powinny być dostępne wyłącznie dla uprawnionych użytkowników i objęte pełnym audytem.
7. Po siódme, wspiera porównanie stanu lokalnego z odpowiedzią z CRU JSFP.
   To pomaga odróżnić błąd danych od błędu integracji albo rozjazdu statusów.

Praktyczna ścieżka postępowania po wykryciu błędu

Najbezpieczniejszy model działania wygląda następująco:

1. Ustal, czy rekord został już faktycznie opublikowany, czy tylko czeka w kolejce.
2. Określ, czy błąd dotyczy danych lokalnych, danych publikowanych czy samej podstawy publikacji.
3. Zdecyduj, czy potrzebna jest korekta lokalna, aktualizacja w CRU JSFP czy wycofanie z publikacji.
4. Udokumentuj przyczynę zmiany, osobę odpowiedzialną i datę zdarzenia.
5. Jeżeli błąd dotyczy jawności albo danych osobowych, udokumentuj również podstawę decyzji.
6. Wykonaj operację w systemie tak, aby pozostał ślad audytowy i historia publikacji.
7. Po zakończeniu sprawy zweryfikuj zgodność stanu lokalnego z odpowiedzią z CRU JSFP.

Najważniejszy wniosek

Jeżeli w CRU JSFP opublikowano błędne dane, nie należy automatycznie zakładać, że jedynym rozwiązaniem jest wycofanie wpisu. Bardzo często prawidłową drogą będzie aktualizacja informacji o umowie, a część błędów da się zatrzymać jeszcze przed wysyłką przez cofnięcie sprawy do kwalifikacji i poprawę danych lokalnych.

Dopiero wtedy, gdy informacja nie powinna dalej pozostawać publiczna w obecnym zakresie albo sama publikacja była błędną decyzją, trzeba rozważyć wycofanie z publikacji.

Właśnie dlatego jednostka potrzebuje nie tylko dostępu do CRU JSFP, ale też lokalnego systemu, który rozdziela te tryby, prowadzi audyt, wspiera integrację przez API i pozwala wykazać, dlaczego w danej sprawie wybrano korektę lokalną, aktualizację albo wycofanie z publikacji.

Źródła prawne i techniczne

1. Ustawa z dnia 27 sierpnia 2009 r. o finansach publicznych, w zakresie art. 34a–34d dodanych i zmienionych ustawą opublikowaną w Dz.U. 2025 poz. 1844.
2. Rozporządzenie Ministra Finansów i Gospodarki z dnia 30 marca 2026 r. w sprawie Centralnego Rejestru Umów Jednostek Sektora Finansów Publicznych, Dz.U. 2026 poz. 440.
3. Oficjalny dokument OpenAPI MF dla środowiska testowego CRU JSFP, wersja 1.3.2.

Akty i dokument techniczny:

• Ustawa o finansach publicznych – DU/2009/1240
• Nowelizacja CRU JSFP – DU/2025/1844
• Rozporządzenie CRU JSFP – DU/2026/440
• OpenAPI MF – środowisko testowe CRU JSFP