Już wiemy, kto jest winny ewentualnej porażki

Po niemal miesiącu milczenia dostarczono nam nową, świeżą wersję API KSeF - RC6! Czyli jednak po stronie MF nie zapadli w sen zimowy ☺️ No to zobaczmy, co nam ten kolejny kandydat do stabilnej wersji przynosi. A poza tym obszerny wywiad z kierownictwem KSeF - i od razu wiemy, kto jest winny ewentualnej porażki. Przedsiębiorcy! I integratorzy! A jak! 👿

Czas do godziny K: -57d18h30m. Czy leci z nami pilot? ✈️

We wtorek, 2 grudnia wieczorem, dostaliśmy nową wersję środowiska testowego KSeF - RC 6. Poprzednia wersja, RC 5.7, publikowana była 7 listopada, więc tym razem mieliśmy niemal miesięczną przerwę w zmianach. Już tliła się nadzieja, że może 3 miesiące przed startem mamy coś na kształt stabilnego (nie w sensie działania, ale kontraktu) API, ale nie - mniej niż 2 miesiące przed startem dostajemy nową wersję. Nawet numerycznie wskazuje ona na jakieś większe zmiany, a nie tylko kosmetykę.

No i tak w istocie jest - co prawda podobno zmiany są kompatybilne wstecznie, przynajmniej w zakresie kontraktów, ale w sensie merytorycznym są one istotne. Dotykają bowiem kluczowej funkcji systemu - pobierania faktur. Temat ten od samego początku był bardzo niedopieczony. Najpierw było API, każdy podchodził do niego na własny sposób, po 3 miesiącach - na koniec września dostaliśmy wraz z informacją o limitach wytyczne: dokumenty należy pobierać w paczkach i KSeF należy traktować jako źródło prawdy do synchronizacji danych do własnych systemów. Czyli już nie traktujemy systemu jako repozytorium dokumentów, mamy to sobie pobrać do siebie i dalej u siebie tym operować. No i zaczęły się implementacje zgodnie z wytycznymi. A z nimi pojawiało się coraz więcej pytań i wątpliwości. Synchronizacja danych to w istocie rzeczy nie jest trywialne zadanie implementacyjne, mimo że może się takie wydawać. Jednak implementacje muszą zakładać, że źródło ciągle żyje, więc trzeba wymyślić mechanizm, który zapewni nam spójność zakresu synchronizowanych danych. I z tym był cały czas problem. No i teraz, po 5 miesiącach od publikacji dokumentacji, 2 miesiącach od uruchomienia tego API i niecałe 2 miesiące do startu - chyba mamy finalne rozwiązanie. Wprowadzono do systemu wzorzec High-Water Mark, abstrahując od szczegółów technicznych, jest to wzorzec, który pozwala w systemach rozproszonych (a tak należy traktować połączenie klient-KSeF) zapewnić spójną synchronizację danych.

No więc 2 miesiące przed uruchomieniem największej rewolucji gospodarczej w Polsce w ostatnich latach mamy mechanizm, który pozwala zachować nam spójność danych. Teraz tylko trzeba go zaimplementować i można udać się na święta i spać spokojnie 😂

Mechanizm, który nie został zaimplementowany od razu, wymyślony wcześniej - mechanizm, który jest wynikiem współpracy zespołu API KSeF z integratorami! To idealnie pokazuje, jak ważna jest współpraca i czas, który jest potrzebny, by różne mankamenty zostały wykryte. W tym przypadku, w podstawowym mechanizmie tego systemu, potrzebne było aż 5 miesięcy! Ile takich mankamentów kryje się jeszcze w KSeF - ano wiele. Widać to po zgłoszeniach technicznych do API. Wciąż np. nie do końca jasne jest, jak postąpić z fakturą wysyłaną w trybie online do KSeF, która utyka (a to się zdarza) w statusie 150 - trwa przetwarzanie. Kolejny podstawowy mechanizm, może jeszcze bardziej kluczowy, a budzi spore problemy. Póki co, oficjalna odpowiedź brzmi - trzeba czekać. Ale to nie jest biznesowe podejście. Technicznie - spoko. Ale te technikalia mają służyć biznesowi, a nie kreować rzeczywistość.

I żeby nie było, jestem fanem tego systemu - uważam, że pełna cyfryzacja jest potrzebna i przydatna, ale nie w taki sposób. KSeF 1.o się skompromitował, KSeF 2.o (a w zasadzie 2.6) - nie jest gotowy. Upieranie się przy terminie 1 luty/kwiecień to jest po prostu głupota.

W ostatnim wywiadzie dla Gazety Prawnej Ministerstwo Finansów: Firmy otrzymały wystarczająco dużo czasu na przygotowania do KSeF mogliśmy usłyszeć, że KSeF jest gotowy, że wszyscy mają/mieli dużo czasu na przygotowanie się, ale to nie jest prawda. Już w samym tytule tego wywiadu mamy manipulację. Od 2 grudnia mamy - być może, bo jeszcze nie sprawdzony - mechanizm spójnego pobierania danych. To nie jest dużo czasu, a już na pewno nie wystarczająco. Cały ten wywiad pokazuje, jak bardzo od rzeczywistości oderwane jest Ministerstwo, na ile nie zna, albo nie rozumie, sposobu działania biznesu. Jak nie rozumie, że przedsiębiorcy są różni, mniej i bardziej zanurzeni w nowoczesny świat.

No to może kilka przykładów z artykułu, z moimi komentarzami. Lecimy! 🚀

W czerwcu br. została opublikowana dokumentacja API oraz produkcyjna wersja struktury logicznej. Dokumentacja API jest innowacyjna, a jej udostępnienie z dużym wyprzedzeniem umożliwiło wczesne przygotowanie się do testów.

No, ale uczciwie wypadałoby przyznać, że to było coś innego niż teraz. Wtedy nie było 2 rodzajów certyfikatów, wtedy nie były znane limity i zalecane sposoby odbioru i wysyłki. Wtedy nie było w API wszystkiego, co potrzebne do sprawnej synchronizacji. Wtedy w API wiele elementów było oznaczonych jako zaślepka i potem zmienionych. Wtedy nie wiedzieliśmy, jak będą dostarczane certyfikaty przez Aplikację Podatnika/MCU. Teraz mamy KSeF 2.6, a nie 2.0. Jeśli dobrze liczę, to jest to chyba 12 wersja tego API - zmiany większe czy mniejsze, ale jednak ciągle są. A coś czuję, że to wcale nie koniec.

Jesteśmy przekonani, że firmy otrzymały wystarczająco dużo czasu na przygotowania.

Pewnie! I pewnie z tego nadmiaru wiedzy teraz ciągle widzimy pytania: jak nadać uprawnienia, jakie nadać uprawnienia, jak się zalogować, itd. Teoretycznie wiedza jest, ale to nie znaczy, że odpowiednio rozpropagowana. I nie znaczy też, że ma jakość odpowiednią. Edukację dźwigają na swoich barkach producenci, integratorzy, księgowi, doradcy i anonimowi dobroczyńcy na Facebooku czy Linkedinie.

Oczywiście trzeba przyznać, że MF się stara. Może i ma dobre chęci, ale wiadomo - tymi to piekło jest wybrukowane.

Tu na pewno potrzeba czasu, a tego nie ma.

1 lutego 2026 r. system zadziała zgodnie z oczekiwaniami.

🍿 😀

W połowie 2026 r. będziemy wiedzieć, czy należy dokonać zmian. Jeżeli będą konieczne, zostaną wprowadzone z odpowiednio długim vacatio legis w 2027 r,

Takim vacatio legis jak teraz? A jak tam podpis pod rozporządzeniami? Szczególnie tym najważniejszym, regulującym działanie KSeF? Bo chyba nie ma, a teraz też mieliśmy obiecane 6 miesięcy.

Wiadomo - obiecanki cacanki…

- Kiedy w Dzienniku Ustaw zostaną opublikowane rozporządzenia wykonawcze dotyczące funkcjonowania KSeF?

T.T.: Chcielibyśmy, aby stało się to na początku grudnia.

Aaa, czyli takie pół roku vacatio legis 😡 Rozumiem, że MF dysponuje innym kalendarzem niż reszta śmiertelników?

Na fakturze ustrukturyzowanej można podać identyfikator wewnętrzny. Firma może więc przyznać taki identyfikator każdemu pracownikowi. Jeżeli sprzedawca wpisze go, generując fakturę, to firma będzie wiedziała, którego pracownika ona dotyczy.

Halo halo, ziemia do MF: a jak przekonać sprzedawcę do wykonania dodatkowej pracy i wpisania tego numeru? W różowe słonie też tam wierzycie? 🐘

A co, jak nie wpisze? Wtedy “Panie kochany, sam sobie radź”?

To zewnętrzni dostawcy oprogramowania mogą oferować pewne rozwiązania, tak aby wszystkie faktury wystawione na danego klienta trafiały do tzw. poczekalni i przedsiębiorca mógł następnie określić, czy są one związane z działalnością gospodarczą i czy należy je ująć w rozliczeniu. To powinno ułatwić pracę także biurom rachunkowym.

Tak, a potem przedsiębiorcy pytają: A czemu ci dostawcy każą sobie płacić za KSeF, to powinno być darmowe! Przecież MF daje za darmo!
No właśnie daje, taki momentami półprodukt.

A wystarczy pozwolić wydawać faktury po staremu, tylko z kodami - i my to sobie już ogarniemy u nas. Pracownik weźmie, zeskanuje telefonem. To się zapisze w naszym ERP/CRM/WTF i potem to sobie ładnie połączymy z fakturką pobraną z KSeF.

Żadnych dziwnych IdWew na potrzeby pracowników, żadnego koślawego dyktowania tego kodu sprzedawcy. Łatwo, prosto i przyjemnie 🙂

W tym zakresie pomoże przede wszystkim edukacja. Skupimy się m.in. na tym, jak prawidłowo postępować z kodami QR, na co zwracać uwagę, aby być pewnym, że system należy do Ministerstwa Finansów. Pamiętajmy, że kod QR daje możliwość zweryfikowania faktury, a nie jej opłacenia, więc nie będzie np. przycisku „opłać fakturę”.

Jasne, że KSeF nie daje możliwości opłacania FV, ale jak 65-latek (z całym szacunkiem do osób starszych), prowadzący mały sklepik, gdzieś tam trafi na link, który będzie przypominać ten od MF, i tam zobaczy napis “Faktura jest w KSeF”, a obok “Możesz opłacić bezpiecznie FV” - to niejeden to zrobi. Ludzi potrafi naciągnąć fałszywy wnuczek, fałszywy policjant, a co dopiero strona przypominająca KSeF. W czasie rewolucji fakturowej. No bez jaj, że tu edukacja pomoże. Banki od lat (od LAT!) uczą klientów, by nie wpisywać haseł na podróbkach stron logowania, od lat wymyślają zabezpieczenia, a to nadal działa.

System powinien być stworzony w taki sposób, by nie sprzyjał oszustwom - a teraz dokładnie jest odwrotnie.

Jest też druga część wywiadu, tam krócej, ale też fajnie 🌸

Podam przykład: otóż token generowany np. przez Krzysztofa Rogowskiego (że posłużę się swoim imieniem i nazwiskiem) był rozdawany księgowym i pracownikom. Wówczas, co do zasady, był wykorzystywany NIP Krzysztofa Rogowskiego, mimo że przez całkiem inną osobę. Nie chcemy utrwalać takich scenariuszy.

Tak tak, i teraz z certyfikatami z jakiegoś powodu to samo się nie stanie? A co z systemami webowymi? W obecnym stanie rzeczy robi się w zasadzie jeszcze mniej bezpiecznie. Ale tak, edukacja wystarczy. Zróbmy źle, a potem nauczmy, jak obejść to zło.

MF żyje w innym świecie, spieszy się, bo wszyscy już chcą tą tragikomedię doprowadzić do końca, to jasne - ale teraz to już przypomina drogę “po trupach do celu”. Choćby świat miał spłonąć, to my przetniemy wstęgę KSeF.

Inni nie spieszą się z odpowiednikami KSeF u siebie. Więc dlaczego my się spieszymy? Myślę, że inni po prostu odkrywają, że to nie jest takie proste - nie da się tego zrobić w tak krótkim czasie, na tak dużą - powszechną - skalę. Dają sobie czas.

Ostatnio wspominałem o tym, że (planowany) brak tokenów to spory problem. Między innymi dla usług chmurowych, które mają działać w oderwaniu od bezpośredniej interakcji użytkownika. Obecnie to oznacza, że taki użytkownik musi do chmury wgrać własny certyfikat - wraz z kluczem prywatnym (i hasłem do niego). Co de facto znaczy, że klucz prywatny nie jest już prywatny i nie powinno się tak robić. Cała idea certyfikatów tu się rozbija o mur. Tokeny ten problem zasadniczo rozwiązywały dość dobrze.

No i być może w poszukiwaniu radzenia sobie z takim problemem na wątkach technicznych pojawiło się ciekawe jego obejście. W uproszczeniu pomysł polega na tym, że użytkownik uprawnia dostawcę oprogramowania do pracy w KSeF w jego imieniu, a ten dostawca, używając już swojego certyfikatu, sobie z KSeF w kontekście firmy klienta rozmawia. Na pierwszy rzut oka pomysł jest dość szalony, ale na drugi już tak całkiem źle nie wygląda.

Klient nie wgrywa nigdzie swojego certyfikatu, który najczęściej (w przypadku JDG) będzie oznaczać pełne uprawnienia do firmy i brak kontroli nad tym, co się dzieje (co dało się tokenem ograniczyć). Zamiast tego uprawnia dostawcę do rozmowy z KSeF i może te uprawnienia ograniczyć do tylko wysyłki, albo tylko odbioru dokumentów - względnie to i to. Ale nie przekazuje dostawcy żadnych uprawnień administracyjnych. I to jest znacznie bezpieczniejsze - certyfikat mam nadal u siebie, a dostawca usługi może zrobić tylko tyle, ile mu pozwolę.

W gruncie rzeczy to przypomina złożenie formularza UPL-1 i umożliwienie dostawcom typu wfirma.pl, ifirma.pl czy podobnym składania deklaracji elektronicznie, w imieniu podatnika.

Ciekaw jestem, czy więcej dostawców pójdzie taką drogą, skoro na powrót tokenów chyba się nie zapowiada.

Rzutem na taśmę MF zapowiedziało, że do MCU zostanie wprowadzona możliwość generowania tokenów. Od 10 grudnia, zamiast 1 lutego. No, ruch w dobrą stronę - tylko że teraz nasila jeszcze bardziej panujące zamieszanie. Już teraz widać, że ludzie generują tokeny gdzieś, wklejają je gdzieś indziej i dziwią się, że nic nie działa. A tu token 1.o pomieszają z 2.o, a tu ten z demo chcą użyć w aplikacji, a tu jeszcze coś innego.
Teraz dostaną nowy wymiar pomyłek 🙂

Dobrze, że chociaż w komunikacie mówią o tym, że te z 1.o nie są przeniesione do 2.o, a te z 2.o nie zadziałają na 1.o.

Przy okazji MF jest wyjątkowo tymi tokenami wystraszone i uczula, by ich pilnować - podobnie jak certyfikatów. To oczywiście słuszna potrzeba, tylko ciekawe, z czego wynika takie mocne podkreślanie tego faktu - poprzednio o tokeny aż tak bardzo się nie martwiono. W zasadzie w ogóle nikt się o nie nie martwił.

Podobno udostępnienie tego to wsłuchanie się w głos potrzeb.

To jak już tak MF się mocno wsłuchuje, to może jeszcze usłyszy potrzebę pozostawienia tokenów na dłużej, niż tylko do końca 2026. Oby 🙏

No ale - to ruch zdecydowanie na plus. Doceniam.

Jak widać MF dzielnie walczy z problemami, które samo tworzy. Najpierw mnożenie trybów offline, bo nie dało się wymyślić jednego, spójnego trybu. Potem jakieś lewe “potwierdzenie transakcji”, zamiast zezwolenia wydawania faktury - po prostu z kodami, co przy okazji daje pewne zabezpieczenie integralności dokumentów wprowadzonych do obiegu. Teraz edukacja bezpieczeństwa zamiast budowania systemu secure by design od samego początku. Ciągła walka. A wystarczy czasem zejść do ludzi i zobaczyć, czego potrzeba. I zapytać, czego potrzeba.

Może MF szuka jakiegoś łącznika z Ziemią? Jak coś, zgłaszam się na ochotnika. Serio 😀