Wejście w życie obowiązku raportowania umów do Centralnego Rejestru Umów (CRU) MF od 1 lipca 2026 r. stawia każdą jednostkę sektora finansów publicznych przed pytaniem operacyjnym, które wcześniej nie istniało: jak dane o umowach mają trafiać z istniejącego systemu finansowo-księgowego do CRU MF bez ręcznego dublowania pracy?

Odpowiedź ma wymiar nie tylko ergonomiczny (czas pracownika sekcji ekonomicznej), ale też zgodności — każde podwójne wprowadzanie tych samych danych zwiększa ryzyko rozbieżności między księgowością a tym, co zgłoszone do MF. Rozbieżność widoczna w kontroli RIO/NIK to problem, którego unika się architekturalnie, nie procedurami.

W tym artykule przedstawiamy dwa realne modele integracji Medulis z systemami F-K używanymi w polskich SPZOZ i JST — od synchronizacji okresowej (REST API) po pełną synchronizację dwukierunkową (webhook). Każdy model ma swoje miejsce w zależności od skali jednostki i możliwości technicznych po stronie dostawcy systemu finansowego.

Problem: dlaczego nie wystarczy „przepisać ręcznie"

Średniej wielkości szpital publiczny zawiera około 200-500 umów rocznie (umowy z dostawcami sprzętu, leków, usług zewnętrznych, umowy o pracę, kontrakty z lekarzami, umowy najmu, etc.). Większość z nich jest już zaewidencjonowana w systemie F-K — jako kontrahent w księdze głównej, z wartością netto/brutto, terminami płatności, klasyfikacją VAT.

CRU MF wymaga podzbioru tych samych danych (NIP kontrahenta, wartość umowy, daty, typ umowy) plus kilku dodatkowych pól które systemu F-K zwykle nie ma (typ umowy w klasyfikacji MF, organ założycielski po stronie JSFP, oznaczenie aneksu).

Wybór modelu obsługi:

Model	Czas pracownika / umowa	Ryzyko rozbieżności F-K vs CRU	Koszt wdrożenia
Ręczne dublowanie (Excel + formularz MF)	15-25 min	Wysokie — każdy błąd kopiowania	Zerowy nakład IT, wysoki etat
REST API integracja	poniżej 30 sek (automatyczna)	Niskie — jedno źródło prawdy	Średni — wymaga API po stronie F-K
Webhook bi-directional	0 sek (real-time)	Najniższe	Średni-wysoki — wymaga współpracy dostawcy F-K

Wybór modelu zależy od dostawcy systemu F-K, jakim dysponuje Państwa jednostka. Poniżej omawiamy każdy model praktycznie.

Model 1: REST API integracja — automatyczna synchronizacja

Podstawowy model integracji systemowej. Medulis odpytuje API systemu F-K w określonych interwałach (np. co 15 minut) lub na żądanie i sam pobiera nowe umowy do zgłoszenia.

Jak to wygląda technicznie:

Dostawca F-K udostępnia REST API (lub SOAP) z endpointem „lista umów od daty X".
Administrator Medulis konfiguruje dane dostępowe (URL, klucz API, certyfikat klienta, jeśli wymagany) w panelu integracji.
Co 15 minut (interwał konfigurowalny) Medulis pyta F-K: „daj mi listę umów zawartych od ostatniego sync-a".
Nowe rekordy trafiają do bufora „do zatwierdzenia" w Medulis.
Sekcja widzi panel z czerwonym znacznikiem „X umów oczekuje na zatwierdzenie" — akceptuje hurtowo lub indywidualnie.
Wysyłka do CRU MF — automatyczna.

Zalety modelu REST API:

Brak manualnego eksportu — pracownik tylko zatwierdza, nie szuka, nie eksportuje, nie wgrywa.
Synchronizacja prawie real-time — opóźnienie maks. 15 minut.
Aneksy w F-K są wykrywane automatycznie i dodawane do bufora.
Audytowalność — Medulis loguje każde zapytanie do F-K (kiedy, co odebrał, kto zatwierdził).

Wady modelu REST API:

Wymaga API po stronie F-K — nie wszystkie systemy je mają. Część nowoczesnych rozwiązań (zwłaszcza wersji Enterprise) udostępnia takie API, starsze systemy zazwyczaj nie.
Wymaga konfiguracji uprawnień — dostawca F-K musi wystawić klucz API z odpowiednim zakresem.
DPA dodatkowy — Medulis staje się dodatkowym sub-procesorem danych F-K. Wymaga umowy powierzenia.

Dla kogo: średnie i większe jednostki z nowoczesnym systemem F-K (najpopularniejsze rozwiązania w wersjach z ostatnich lat oraz część dostawców regionalnych).

Model 2: Webhook bi-directional — pełna synchronizacja real-time

Najwyższy poziom integracji. System F-K sam powiadamia Medulis, że pojawiła się nowa umowa (lub aneks) — przez webhook HTTP. Brak interwałów, brak opóźnień, prawdziwy real-time.

Jak to wygląda technicznie:

W systemie F-K rejestrujemy URL webhooka Medulis (np. https://api.medulis.pl/integrations/incoming/<klucz_jednostki>).
Gdy w F-K powstaje nowy rekord umowy, system automatycznie wysyła POST request do Medulis z danymi tej umowy.
Medulis odbiera, waliduje sygnaturę kryptograficzną, tworzy kartę umowy.
Opcjonalnie: po zgłoszeniu do CRU MF Medulis odsyła numer systemowy z powrotem do F-K (synchronizacja dwukierunkowa) — w celu zapisania go w kartotece umowy w systemie księgowym.

Zalety modelu webhook:

Zero opóźnień — rekord pojawia się w Medulis w ciągu sekund od zapisu w F-K.
Pełna synchronizacja — numer systemowy CRU wraca do F-K, co eliminuje problem rozbieżności.
Idealnie dla dużych jednostek — wojewódzkie szpitale z 50+ umowami tygodniowo.

Wady modelu webhook:

Wymaga współpracy dostawcy F-K — konfiguracja webhooka, format payloadu, retry mechanizm w razie chwilowej niedostępności.
Złożoność testowania — wymaga środowiska sandbox po obu stronach.
Dodatkowe wymagania bezpieczeństwa — uwierzytelnianie webhook podpisem kryptograficznym, białe listy adresów IP, monitoring nieautoryzowanych prób.

Dla kogo: duże jednostki (wojewódzkie szpitale, agencje, uczelnie) z dedykowanym IT i nowoczesnym systemem F-K. W mniejszych jednostkach overkill — Model 1 (REST API) wystarcza.

Bezpieczeństwo i RODO przy integracji

Integracja systemów oznacza, że dane przepływają między dwoma podmiotami przetwarzającymi. To wymaga uwagi w trzech aspektach:

1. Umowa powierzenia (DPA)

Każdy podmiot, do którego trafiają dane osobowe (kontrahentów, pracowników jednostki), musi mieć podpisaną z administratorem (jednostką) umowę powierzenia przetwarzania danych zgodną z art. 28 RODO. To znaczy:

Medulis jako podmiot przetwarzający — DPA pomiędzy jednostką a Medulis.
Dostawca infrastruktury hostingowej jako sub-procesor Medulis — DPA „back-to-back".
Jeśli używasz integracji z F-K, dostawca F-K też musi mieć DPA z jednostką (zwykle już go ma, ale warto sprawdzić zakres).

2. Bezpieczne kanały komunikacji

Wszystkie integracje Medulis używają TLS 1.3 (HTTPS) — żadnych połączeń niezaszyfrowanych.
Klucze API i hasła SMTP — przechowywane w postaci zaszyfrowanej, nie w postaci jawnej w bazie.
Webhook autoryzowany podpisem kryptograficznym — przeciwko nieautoryzowanym wysyłkom.

3. Minimalizacja danych

Do CRU MF trafia podzbiór danych z umowy — nie cała treść, nie załączniki. Medulis pobiera z F-K tylko niezbędne pola (zgodnie z zasadą minimalizacji z art. 5(1)(c) RODO). Pełna treść umowy nigdy nie trafia do MF — jest tylko opis i wartości.

Co Medulis oferuje dziś — i co planujemy

Dostępne na 1 lipca 2026:

✅ REST API endpoint w Medulis do przyjmowania umów z systemów zewnętrznych (Model 1 — strona Medulis).
✅ Integracja z API MF — pełna synchronizacja z Centralnym Rejestrem Umów.
✅ Webhook do odbierania powiadomień z systemów F-K (Model 2 — strona Medulis).

Planowane (roadmap 2026-2027):

🔄 Pre-konfigurowane konektory dla najpopularniejszych systemów F-K — przyspieszające wdrożenie z 1-2 dni do poniżej 1 godziny.
🔄 Synchronizacja zwrotna numerów CRU do systemu F-K (Model 2 dwukierunkowy).
🔄 Auto-mapping typów umów F-K → klasyfikacja MF — uczy się na podstawie wcześniejszych zgłoszeń w jednostce.

Pytania, które warto zadać dostawcy F-K przed wdrożeniem CRU MF

Lista kontrolna dla kierownika IT lub głównego księgowego prowadzącego rozmowy z dostawcą systemu finansowego:

Czy macie REST API z endpointem „lista umów od daty X"? Jeśli tak — jaki format autoryzacji (klucz API, OAuth, certyfikat)?
Czy obsługujecie webhook out na konfigurowalny URL przy zapisie nowej umowy?
Jak wygląda DPA pomiędzy nami a Wami? Czy obejmuje przekazanie danych do trzecich systemów na nasze polecenie?
Czy planujecie własny moduł CRU MF? (Częste pytanie — niektórzy dostawcy F-K dorzucają go „w pakiecie", inni rekomendują integrację z dedykowanym systemem jak Medulis. Sprawdź ich roadmap i cennik.)

Odpowiedzi na te pytania pozwolą wybrać optymalny model integracji dla Państwa konkretnej konfiguracji.

Co dalej

Niezależnie od tego, jaki system F-K wykorzystuje Państwa jednostka, Medulis można zintegrować. Pytanie nie brzmi „czy", tylko „który model będzie dla nas optymalny przy obecnej infrastrukturze".

Najlepszą drogą do odpowiedzi jest krótka rozmowa techniczna — pokażemy konkretne ścieżki integracji, wymagania, harmonogram wdrożenia dla Państwa. Mile widziana jest obecność osoby z działu IT oraz przedstawiciela sekcji ekonomicznej — różne perspektywy na ten sam proces.

Zapraszamy do zapoznania się z modułem CRU i do złożenia wniosku o dostęp do wersji demonstracyjnej z notatką „chcielibyśmy omówić integrację z systemem [nazwa Państwa F-K]".

Praktyczne błędy operacyjne przy obsłudze CRU MF opisaliśmy w osobnym artykule: Najczęstsze błędy zgłaszania umowy do CRU MF. Strukturę odpowiedzialności organizacyjnej w jednostce — w artykule Kto odpowiada za CRU MF w jednostce?. Pełny proces zgłaszania od podstaw opisaliśmy w przewodniku Centralny Rejestr Umów krok po kroku, a zakres umów podlegających rejestracji — w artykule Centralny Rejestr Umów — jakie umowy zgłaszać?.