JSON umowy wysłany do CRU — historia i identyfikatory

CRU JSFP/13.10.2026

Gdy pojawia się pytanie o błędną publikację, sama aktualna wersja rekordu nie wystarcza. Jednostka powinna móc odtworzyć, jakie dane przygotowano, kto je sprawdził, co wysłano, jaki był wynik i dlaczego wykonano późniejszą zmianę. W Asystent Chmura szczególnie użyteczny jest ślad samej transmisji: JSON umowy może zostać pokazany przed wysyłką, a po udanej operacji zapisany jako załącznik przy lokalnym rekordzie.

Historia biznesowa i techniczna

Historia biznesowa opisuje zmianę umowy, jej statusu, stron lub wartości. Historia techniczna pokazuje wywołania API, odpowiedzi i identyfikatory. Obie warstwy należy powiązać, ale nie mieszać: błąd sieciowy nie jest zmianą umowy, a aneks nie jest tylko kolejnym wpisem w logu.

Sprawdzone funkcje budują JSON z lokalnej kartoteki: osobno numer i daty umowy, okres obowiązywania, przedmiot, wartość, strony oraz — przy aktualizacji — rodzaje zmian. W JSON są `externalSystemId` z identyfikatorem rekordu Asystenta i `agreementId` zwrócony wcześniej przez CRU. Te dwa identyfikatory pełnią różne role; nie należy traktować numeru umowy jako zamiennika któregokolwiek z nich.

Minimalny ślad operacji

Dla każdej publikacji lub aktualizacji warto zachować identyfikator umowy lokalnej i CRU, czas, użytkownika, typ operacji, wersję danych, wynik i przyczynę. Przydatny jest skrót treści wysłanego zestawu, który pozwala potwierdzić wersję bez przechowywania sekretów w logu.

W obecnej ścieżce Asystenta Pascal pokazuje podgląd JSON przed przyciskiem wysyłki. Po odpowiedzi zakończonej sukcesem silnik zapisuje status i identyfikator CRU, dopisuje zdarzenie do raportu zmian oraz tworzy załącznik o nazwie zawierającej lokalne ID, rodzaj operacji i czas. Zawartością załącznika jest JSON przygotowany do tej operacji. Jeśli zapis załącznika nie powiedzie się, program sygnalizuje problem — nie należy wtedy zakładać, że ślad jest kompletny.

Raport dla kontroli

Czytelny raport powinien łączyć etapy przygotowania, akceptacji i transmisji. Pozwala to odróżnić błąd procesu od błędu technicznego, wykazać terminowość oraz wskazać rekordy, których stan lokalny różni się od informacji w CRU.

Przykład kontroli: umowa po aneksie ma inną wartość niż w chwili pierwszej publikacji. Porównaj stary załącznik JSON, aktualną kartotekę, wpis zmiany CRU i odpowiedź rejestru. Zmiana danych źródłowych bez nowej transmisji nie oznacza aktualizacji publicznej informacji. Również obecność załącznika JSON nie dowodzi, że każda decyzja merytoryczna i prawna była poprawna; odpowiedzialność za kwalifikację danych pozostaje po stronie jednostki.

Najczęstsze pytania

Czy zwykły log serwera wystarczy jako historia CRU?

Nie. Log serwera nie opisuje akceptacji merytorycznej ani przyczyny zmiany i może być zbyt techniczny lub nietrwały.

Czy historia powinna przechowywać klucz API?

Nie. Sekrety uwierzytelniające nie powinny trafiać do historii operacji ani raportów użytkowych.

Czy wysłany JSON jest zachowany przy lokalnej umowie?

Po udanej operacji analizowana ścieżka zapisuje JSON jako załącznik do umowy; trzeba sprawdzić wynik zapisu i uprawnienia dostępu.

Źródła i weryfikacja

Opis funkcji programu sprawdzono w dokumentacji modułów Asystent. Niepubliczne pliki produktowe nie są udostępniane jako linki.

Kontakt z nami

System zgłoszeń najszybszą formą komunikacji z Nami

Obsłużonych zgłoszeń

24 373

Średnia ilość minut oczekiwania

Programów w ofercie

107

W przypadku chęci wykonania wdrożenia aplikacji u klienta prosimy kontakt pod nr tel. 504 946 478 w celu umówienia szczegółów oraz terminu z technikiem.

Panel Klienta

Panel Pracownika