Ernest Frankowski, partner w ITNINE
ikona lupy />
Ernest Frankowski, partner w ITNINE / Materiały prasowe / Wojtek Lesiak wojteklesiak.net

- Im bliżej 1 lutego, tym więcej słychać głosów, że należy przesunąć wejście w życie obowiązkowego Krajowego Systemu e-Faktur. Niepokojące jest to, że takie postulaty pojawiają się ze strony programistów. Na jednym z portali napisał pan, że przesunięcie nie musiałoby być radykalne. Wystarczyłoby, aby KSeF wszedł w życie od 1 lutego w trybie fakultatywnym, a od 1 kwietnia stał się obowiązkowy dla wszystkich podatników. Skąd taki postulat?

Obiektywnie, nie ma pewnie takiej możliwości z uwagi na liczbę komunikatów i przekazów dotyczących obecnego harmonogramu. Sam od dawna byłem zwolennikiem podejścia, aby wreszcie wdrożyć KSeF, tak jak implementuje się inne duże systemy, nawet jeśli na moment wdrożenia nie są one idealne. Nie można ciągnąć w nieskończoność procesu wdrożeniowego. Mocno jednak zaskoczyło mnie to, że na obecnym etapie są jeszcze wprowadzane zmiany programistyczne do KSeF. Nie spodziewałem się, że takie rzeczy mogą się dziać na tygodnie przed 1 lutego. To wprowadza niepotrzebne komplikacje tuż przed godziną zero.

- Daty wdrożenia KSeF od ponad półtora roku. Nie powinny być dla nikogo zaskoczeniem.

Od strony legislacyjnej to prawda. Ale w przeciwieństwie do innych zmian w prawie, wdrożenie KSeF nie polega tylko na zaznajomieniu się z nowymi przepisami. To także, a może przede wszystkim, wdrożenie interfejsu programistycznego, który pozwoli zaimplementować nowe technologiczne rozwiązanie i zintegrować z nim systemy finansowo-księgowe. A tutaj można było zrealizować to trochę lepiej.

Należy wyciągnąć wnioski na przyszłość

- Może więc słuszna jest pana sugestia, by obowiązek lekko przesunąć.

Wielkich nadziei nie mam, chciałem się raczej „przebić” z komunikatem, że tak się nie robi. Nie przy tej skali, nie przy tak długim projekcie. Na końcu zawsze musi być okres, w którym projekt programistyczny osiąga stabilizację i nie wprowadza się w nim już żadnych zmian. Tylko to daje szansę - w tym przypadku podatnikom - aby w miarę spokojnie zintegrować swoje systemy z rozwiązaniem centralnym. Moim celem było więc zwrócenie uwagi na to, że przy takim projekcie, stabilizacja na poziomie przepisów i dat to nie wszystko. Prawdziwa złożoność jest ukryta w oprogramowaniu. Oczywiście nie pomijam licznych konsultacji przy projektowaniu KSeF, tego, że uwzględniano głosy podatników itp. Nie zmienia to jednak faktu, że są obszary do poprawy na przyszłość. Być może uda się wykorzystać to doświadczenie przy kolejnych podobnych projektach digitalizacji administracji publicznej.

- Chyba nie powie pan, że programiści zajmują się dopiero teraz wdrażaniem KSeF?

Oczywiście, że nie. Programiści zajmują się KSeF od lat i trochę na zasadzie krok do przodu, krok do tyłu. Zbudowaliśmy KSeF 1.0, zmieniamy na 2.0, wdrożyliśmy tokeny, za chwilę wdrażamy certyfikaty. W efekcie cierpi testowanie. A na koniec mamy zmiany „porządkujące” w kodzie, które wobec skali projektu mają charakter dezorganizujący prace na ich finiszu.

Konieczny jest okres zamrożenia KSeF

- Jaki widzi pan na to sposób?

Nie od dziś w projektach informatycznych publicznych postuluję odpowiednio długi okres zamrożenia, w którym nie są już wprowadzane żadne zmiany w systemie, nawet jeśli obiektywnie można byłoby go jeszcze udoskonalić. Data 1 lutego powinna być datą dla podatników, a nie datą dla partnera publicznego. Partner publiczny powinien być gotowy sporo wcześniej.

- Ile powinien trwać taki okres zamrożenia?

Przy KSeF postulowałem 6 do 12 miesięcy. Oczywiście, od dawna nie było to możliwe. Raczej jest to więc głos na przyszłość.

- A teraz?

Teraz byłbym zadowolony chociaż z miesiąca albo trzech więcej. Z czegokolwiek w tym zakresie. Jak pani widzi, moje nadzieje są naprawdę minimalistyczne.

Zmian w kodzie nie należy robić na „5 minut” przed godziną zero

- Czy ostatnie zmiany w KSeF naprawdę wymagają czasu? Proszę o uczciwą odpowiedź.

Oczywiście, można dyskutować, czy zaadoptowanie ostatnich zmian w kodzie jest technicznie trudne. Można nawet zgodzić się, że nie jest. Ale przy tej skali, jaką jest KSeF, w tym momencie i przy sposobie komunikacji takiej zmiany (GitHub), implementacja tych zmian – choć może nie jest trudna – to na pewno jest czasochłonna. A akurat czasu nie mamy za dużo.

- Nie będzie jeszcze sankcji za niewystawianie faktur przy użyciu KSeF.

Co z tego? Proszę sobie wyobrazić taką sytuację: ktoś pracuje nad KSeF w technologii, w której daną zmianę trudno jest wykonać na ostatniej prostej i w efekcie taki ktoś nie zdąży „dowieźć” zmian na 1 lutego. Tego dnia jego system finansowo-księgowy nie będzie w pełni gotowy. To oznacza, że przez pewien czas (kilka dni?) firma nie ma dostępu do KSeF i w rezultacie wstrzymuje wystawianie faktur albo wysyła je po staremu. W pierwszym przypadku naraża się na problemy finansowe. W drugim może natknąć się na opór kontrahentów, którzy powiedzą, że czekają na faktury wystawione tylko w KSeF. W takiej sytuacji brak sankcji jest tylko częściową ulgą. Musimy pamiętać, że przy tej skali, sytuacja, o której tu dyskutujemy, jest jak kamyk wrzucony do wody, który powoduje rozchodzenie się kręgów na wodzie. Albo – gdyby użyć innego porównania – jest jak pierwsza przewrócona kostka domina. Poza wszystkim, uniwersalną zasadą jest, że zmian w kodzie nie robi się na „5 minut” przed terminem. Taka jest zasada, koniec, kropka.

Rozmawiała: Katarzyna Jędrzejewska