Czy jesteśmy gotowi na KSeF – podsumowanie pierwszych testów API KSeF 2.0

Dziś mamy dokumentację na GitHub, otwarte repozytorium z kodem źródłowym SDK KSeF, dla dwóch wiodących języków programowania, przykłady użycia i środowisko testowe, które faktycznie odpowiada na żądania w sposób przewidywalny i wydajny. To duży krok naprzód.

Z drugiej strony jednak widać poważne problemy systemowe i organizacyjne:

1. Chaotyczne podejście do planowania i komunikacji

   Środowisko testowe zostało wyłączone na 30 dni – informacja pojawiła się w piątek po południu, a w poniedziałek system już nie działał.

2. Brak kompletnej dokumentacji.

   Choć dokumentacja i OpenAPI są dostępne na GitHubie, ich zawartość wciąż się zmienia. Nadal brakuje kompletnej listy kodów błędów i ich opisów. To element absolutnie kluczowy dla każdego, kto tworzy systemy produkcyjne.

3. Problematyka tokenów.

   Najczęściej zgłaszane problemy przez społeczność, to

   1. niekompatybilność nowego API z poprzednią wersją
   2. ogłoszone wartości limitów na zapytania, dla środowiska produkcyjnego
   3. brak kompatybilności starych tokenów. Oznacza to, że 1 lutego – nawet jeśli system księgowy zostanie w pełni dostosowany do nowej wersji API – komunikacja z KSeF będzie niemożliwa bez wygenerowania nowych tokenów. A te można wygenerować dopiero w produkcyjnej wersji KSeF 2.0. To niemal pewny przepis na chaos pierwszych dni obowiązkowego KSeF.
4. SDK

   Oficjalne SDK dla Javy w obecnym kształcie wymaga wprowadzenia szeregu poprawek we własnym zakresie, aby dało się je wykorzystać w projektach. Binarna wersja nie jest opublikowana w publicznych repozytoriach, co utrudnia automatyczne użycie w procesach CI/CD. W repozytorium nadal otwartych jest wiele zgłoszeń – w tym dotyczących bezpieczeństwa. Obecna wersja SDK nie jest zgodna z najnowszą wersją API – SDK jest aktualizowane rzadziej niż API na środowisku testowym.

5. Wydajność i limity.

   Samo środowisko testowe odpowiada relatywnie sprawnie, choć widać różnice między nocą a godzinami szczytu. Problemem jest jednak koncepcja sztucznych limitów dla środowiska produkcyjnego – jak np. możliwość wysłania 180 faktur na godzinę w trybie interaktywnym. To nie jest nowoczesne podejście do systemów chmurowych, które z założenia skalują się horyzontalnie. Limity nie rozwiązują problemu wydajności, a jedynie przerzucają ciężar na podatników i dostawców oprogramowania. W chwili udostępnienia KSeF 1.0, wysyłka interaktywna była jedyną sensowną formą komunikacji z KSeF, a Ministerstwo tłumaczyło, że faktury powinny być wysyłane do KSEF natychmiast (tak naprawdę wystawiane w KSeF), bo dokument nie był uznawany za fakturę, jeśli nie otrzymał numeru KSeF. Teraz narracja się zmienia i fakturę podatnik wystawa w swoim systemie, ma ją buforować, a do KSeF wysyłać, najlepiej w nocy, w dużych paczkach, żeby przypadkiem nie przeciążyć systemu. Jeśli do tego dodamy to, że KesF został przyłożony z obawy przez problemami z wydajnością, to wygląda na to, że problem został „rozwiązany” przez wprowadzenie limitów, a nie faktyczną poprawę wydajności systemu.

6. Brak migracji uprawnień do nowego modułu MCU.

   Ministerstwo Finansów zapowiedziało, że wszystkie uprawnienia nadane elektronicznie w KSeF 1.0 nie zostaną zmigrowane do nowego modułu uprawnień (MCU). W praktyce oznacza to, że firmy, które już zbudowały i wykorzystują strukturę uprawnień w KSeF 1.0, będą musiały odtworzyć ją od zera w nowym systemie. Co więcej – nie ma jasnej informacji, czy będzie można to zrobić z wyprzedzeniem, czy dopiero po 1 lutego, kiedy uruchomione zostanie API KSeF 2.0 w produkcji. To rodzi ryzyko paraliżu organizacyjnego w pierwszych dniach obowiązkowego KSeF.

7. Niestandardowe uwierzytelnianie i certyfikaty KSeF.

   Ministerstwo Finansów zdecydowało się na autorskie rozwiązanie w zakresie uwierzytelniania, oparte na podpisywaniu cyfrowym plików XML, zamiast wykorzystania powszechnie stosowanych standardów (jak OAuth2 z certyfikatami X.509). Certyfikaty zastąpią tokeny KSeF od stycznia 2027. Dla integratorów i producentów systemów ERP, zwłaszcza SAP, oznacza to konieczność dodatkowych nakładów na wdrożenie mechanizmów kryptograficznych, które normalnie nie byłyby potrzebne. Efekt jest taki, że integracja z KSeF staje się bardziej kosztowna, czasochłonna i podatna na błędy niż gdyby oparto ją o standardowe rozwiązania znane z bankowości czy chmur publicznych.

8. QR Cody

   Mimo, że jest już dostępna dokumentacja opisująca w jaki sposób można generować QR Cody, które podatnicy muszą umieszczać na wizualizacji faktury, środowisko do ich weryfikowania nie zostało jeszcze udostępnione. MF nie poinformowało o tym fakcie integratorów w żadnym z oficjalnych komunikatów. Zdaniem przedstawicieli Ministerstwa, integratory mają do dyspozycji w pełni działające środowisko testowe, które pozwala mi dostosować swoje rozwiązania do nowej wersji API KSeF. Jest to informacja daleka od prawdy.

Podsumowanie

Ministerstwo Finansów miało niemal dwa lata od momentu odroczenia obowiązkowego KSeF, aby przygotować system i komunikację z integratorami w sposób bardziej uporządkowany. Tymczasem wiele kluczowych decyzji zapada w ostatnich miesiącach, a zmiany są wprowadzane w sposób zaskakujący i nieprzewidywalny.

Moja ocena jest taka: technicznie KSeF 2.0 działa znacznie lepiej niż wersja 1.0, ale organizacyjnie projekt wciąż wygląda na chaotyczny i nieprzemyślany. Brakuje stabilnej dokumentacji, przejrzystej komunikacji i rozwiązań zgodnych z dobrymi praktykami IT. Dodatkowo – brak migracji uprawnień i zmiana zasad autoryzacji mogą spowodować, że 1 lutego czeka nas duże zamieszanie – nie tylko z powodu faktur, ale i problemów z dostępami i uprawnieniami.