Wstęp

Celem niniejszego raportu jest przedstawienie aktualnego stanu prac nad projektem Krajowego Systemu e-Faktur (KSeF), ze szczególnym uwzględnieniem zagadnień zgłaszanych przez użytkowników oraz zespoły integracyjne. Analiza została opracowana na podstawie komunikacji wewnętrznej, dokumentacji technicznej oraz zgłoszeń dotyczących funkcjonalności, błędów i oczekiwań wobec systemu. Raport ma na celu uporządkowanie kluczowych tematów, zidentyfikowanie obszarów wymagających dalszych działań oraz wsparcie decyzyjne dla zespołów odpowiedzialnych za rozwój i wdrożenie systemu.

Raport przygotował i udostępnił zespół analityczny SoftCream Software zajmujący się integracją usług KSeF z systemami klasy ERP.

Autoryzacja i uwierzytelnianie

Wielu użytkowników zgłasza problemy z uzyskaniem tokena dostępowego, błędami HTTP 403 i 415, oraz nieprawidłowym szyfrowaniem kluczy. Wskazano, że pierwsze logowanie na poziomie root musi odbywać się z użyciem certyfikatu zawierającego pole 2.5.4.97 z NIP-em, co umożliwia późniejsze tworzenie użytkowników z innymi metodami autoryzacji. Pojawiły się też sugestie, że po wycofaniu tokenów jedyną metodą uwierzytelnienia będzie podpis XAdES.

Migracja z KSeF 1.0 do 2.0

Zespół CIRFMF wyjaśnia, że migracja „po mapie” nie jest możliwa. Zamiast tego udostępniono dokumentację, samplowe kody, klientów w C# i Javie oraz kontrakt OpenAPI. Podkreślono, że nie powstanie osobny dokument migracyjny ze względu na złożoność i różnorodność ścieżek integracji.

Obsługa faktur i tryb offline

Wielokrotnie poruszano temat obsługi faktur w trybie offline, szczególnie w kontekście rozbieżności czasowych między generacją, wysyłką i pobraniem statusu. Pojawiły się pytania o oznaczanie faktur jako offline przy wysyłce na przełomie dni (np. o 23:59:59) oraz o generowanie wizualizacji w tym trybie.

Obsługa błędów i duplikatów

Zgłoszono potrzebę zwracania numeru faktury (invoiceNumber) również w przypadku błędów, aby uniknąć dodatkowych zapytań i przekroczenia limitów API. Przykładowo, w przypadku duplikatu faktury system zwraca tylko numer sesji, co wymusza kolejne zapytania w celu identyfikacji problemu.

Testowanie i środowiska

Użytkownicy zgłaszają potrzebę dynamicznego przełączania się między środowiskami w aplikacjach klienckich. Wskazano na ograniczenia wynikające z rejestrowania ustawień jako singletonów oraz brak wsparcia dla wielu środowisk w jednej instancji aplikacji. Pojawiły się propozycje zmian w bibliotekach, np. udostępnienie BaseUrl jako delegata.

Problemy techniczne i błędy SDK

Zgłoszono błędy związane z niezgodnością modeli danych między wersjami SDK a środowiskiem testowym, brak wsparcia dla page_offset w metodzie getSessionInvoices, oraz błędy przy otwieraniu sesji interaktywnej (np. 401 - [no body]).