Na krótko przed upływem terminu (26 lutego 2018) upowszechnienia wśród przedsiębiorców obowiązku wnoszenia Jednolitego Pliku Kontrolnego (dalej: JPK) dokonano wielu istotnych zmian. Tym samym kilka problemów, o których wspomniałem w poprzednim wpisie zostało rozwiązanych, ale jednocześnie powstały kolejne. Ogólnie mam wrażenie, że bilans ostatnich zmian jest negatywny. Powstało więcej nowych problemów niż rozwiązano starych. Nadto dodatkowo skomplikowano system.

Na marginesie wyjaśniam, że już wcześniej niektórzy przedsiębiorcy mieli obowiązek wnoszenia JPK. Jednak teraz objął on również tzw. mikroprzedsiębiorców. Często są to zaś osoby, które nierzadko nie korzystają z pomocy profesjonalnych przedsiębiorstw księgowo-rachunkowych. Tym samym muszą własnymi siłami przesłać JPK.

Zagadnienie jest o tyle ciekawe, że ukazuje, że niezbyt dopasowane do realiów wymogi technologiczne stają się ogromnym problemem dla realizacji obowiązków nałożonych przez prawo. Zresztą, kwestie można ujmować jeszcze inaczej – jako odpowiedz organów publicznych na częste narzekania, że urzędy są niedostatecznie nowoczesne (ja akurat tak nie uważam, ale często spotykam się z takimi opiniami). A zatem mamy teraz bardzo innowacyjne rozwiązanie, ale jak się okazuje, trochę chyba za nowoczesne i być może wiele osób nieporadzi sobie z rodzącymi się problemami technicznymi.

Autoryzacja i e-bramka dla JPK

W ostatnich tygodnia przed upływem wspomnianego na początku terminu na złożenie JPK złagodzono wiele wymogów technologicznych. Nie oczekiwałem nawet takich zmian. Przynajmniej o dwóch modyfikacjach warto wspomnieć.

Po pierwsze, oprócz posłużeniem się jako metodą identyfikacji kwalifikowanym podpisem elektronicznym lub profilem zaufanym, można posłużyć się swoimi historycznymi danymi podatkowymi (konkretnie chodzi o podanie danych personalnych i wysokości przychodu z zeszłego roku, co określa się ogólnie mianem „danych autoryzacyjnych”). Prawdopodobie stwierdzono, że pomimo nawoływań wciąż zbyt mała liczba przedsiębiorćów wyrobiła profil zaufany lub nabyła kwalifikowany podpis elektroniczny. Z założenie ma to być rozwiązanie tymczasowe, gdyż już w 2019 r. ma nastąpić powrót do pierwotnego modelu z tylko dwoma wskazanymi metodami identyfikacji.

Po drugie, wsłuchując się w głosy przedsiębiorców używających innych systemów operacyjnych niż Windowsa, stworzona specjalną bramkę webową. Innymi słowy, oprócz aplikacji „e-mikrofirma” i aplikacji „Klient” (działających jedynie na Windowsie), można skorzystać z tej e-bramki. Oczywiście oprócz tych publicznych i darmowych rozwiązań możliwe jest wykorzystywanie komercyjnego oprogramowania.

Trzecia wersja JPK

Sporym zaskoczeniem jest nowa wersja urzędowego szablonu JPK. Należy podać w nim znacznie mniej danych niż w poprzednich wersjach. Rodzi to pytanie, czy zatem wskazywane w dawnych wersjach dane okazały się zbędne? Co jednak najważniejsze stworzenie JPK w wersji nr 3 wymaga rygorystycznego przestrzegania instrukcji. Najprostszy przykład: nie mozna otworzyć urzędowego szablonu JPK (wersja 3) poprzez zwykle kliknięcie. Trzeba go otworzyć w dość „okrężny” sposób wskazany w instrukcji. JPK  w wersji nr 2 był mniej wymagający pod tym względem.

Konwersja na format xml’owym

W mojej ocenie źródłem wielu problemów jest takie skonstruowanie modelu JPK, że podatnik samodzielnie konwertuje i przesyła plik w wersji xml’owej, a nie jedynie podaje konkretne informacje. Z punktu widzenia mojej praktyki zawodowej i naukowej takie rozwiązanie jest jednak bardzo ciekawe. Prawodawca jednoznacznie określił, że wnosi się nie jakiś wniosek, deklarację, zeznanie, albo że nawet dokument, lecz że przesyła się „plik”. Jednak wydaje mi się, że system powinien być tak skonstruowany, że podatnicy powinni raczej jedynie przesyłać informacje. Potocznie ujmując, poukładanie tych informacji w określony sposób, powinno leżeć w gestii organów. Podatkim powinien jedynie ułatwiać organowi takie działanie. Obecnie zaś podatnik jest obciążony takim obowiązkiem w całości, a rolą organu jest jedynie przyjęcie gotowego pliku xml’owego.

Kilka miesięcy temu we wpisie „Informatyzacja w praktyce” poruszyłem kwestię „user experience” w kontekście urzędowych systemów teleinformatycznych (w tym aplikacji) służących wnoszeniu e-pism. Od tego roku w zasadzie wszyscy przedsiębiorcy zaś muszą przesyłać elektronicznie do organów skarbowych Jednolity Plik Kontrolny. W najprostszym wariancie czynności tej dokonać można poprzez stworzenie pliku w Excelu, a następnie wysłaniu go za pomocą darmowej ministerialnej aplikacji „Klient JPK 2.0”. Na potrzeby identyfikacji wystarczy posłużyć się profilem zaufanym ePUAP.

Alternatywnie można wykorzystać komercyjne aplikację i kwalifikowany podpis elektroniczny. Nadto niedługo o moduł Jednolitego Pliku Kontrolnego ma zostać rozbudowana ministerialna aplikacja e-mikrofirma. W tym wpisie poprzestanę jednak na analizie wskazanego najprostszego wariantu, ponieważ chciałbym poruszyć kilka kwestii z zakresu komfortu korzystania z publicznych rozwiązań informatycznych.

Od razu przy tym zaznaczę, że nawiążę do banalnych problemów, które jednak mogą stać się trudno przezwyciężalną barierą dla skutecznego wniesienia Jednolitego Pliku Kontrolnego. Na szerszą ocenę jeszcze za wcześnie. Trzeba też wyraźnie podkreślić, że z technicznego punktu widzenia chodzi o bardzo prostą operację – przesłanie excelowskiego pliku (precyzyjniej to przesyła się właściwie plik XML). Zatem wydawałoby się, że przeszkód technicznych być nie powinno. W końcu nie ma obecnie nic niezwykłego w przesyłaniu za pomocą maili lub komunikatorów internetowych ogromnych plików graficznych i video, a w przypadku Jednolitego Pliku Kontrolnego chodzi jedynie o plik o niewielkich rozmiarach (składający się jedynie z liczb i liter).

Instrukcje obsługi

W przywołanym na wstępie dawnym wpisie wskazałem, że zbyt skomplikowane instrukcje obsługi korzystania z rozwiązań informatyzujących podmioty publiczne w gruncie rzeczy są sygnałem, że dane narzędzie nie jest przyjazne dla użytkownika. Jednolity Plik Kontrolny został zaś obudowany kilkoma wielostronicowymi instrukcjami obsługi, w szczególności:

• podręcznikiem użytkownika Klient JPK 2.0 (liczącym 44 strony, konkretnie 43 bez strony tytułowej),
• broszurą informacyjną JPK VAT(2) (14 stron, 13 bez strony tytułowej),
• specyfikacją formatu CSV dokumentów JPK (4 strony, 3 bez strony tytułowej).

Nadto do aplikacji e-mikrofirma instrukcja ma 32 strony. Z tej aplikacji jednak w ogóle nie korzystałem. Właściwie to nie dało się jej zainstalować. Nastąpiły u mnie komplikacje ze środowiskiem JAVA. Może jak się ta aplikacja rozbuduje o moduł „Jednolity Plik Kontrolny” to do niej wrócę i podejmę trud instalacji.

Każda z powyższych instrukcji nie jest zbytnio przyjazna dla potencjalnego użytkownika. Przydatne, jasne i przejrzyste były za to informacje zamieszczone bezpośrednio na ministerialnej stronie internetowej. Ze wskazanymi instrukcjami jest natomiast taki problem, że z jednej strony są zbyt skomplikowane (zatem kompletnie nieprzydatne dla osób o niepełnych zdolnościach informatycznych), a z drugiej strony osoby obeznane z tego typu oprogramowaniem mogą obsłużyć aplikację Klient JPK bez ich czytania, a kierując się jedynie intuicją.

W mojej ocenie instrukcje powinny w większym stopniu ukazywać jak poprawnie stworzyć Jednolity Plik Kontrolny – w sensie jaką powinien mieć merytoryczną treść, jaką powinien mieć kompozycję treści i jaki format danych. Samo przesłanie nie musi być aż tak dokładnie opisywane. Ewentualnie można zrobić krótką animację video modelowego wniesienia i uzupełnić ją o opisowy dokument wskazujący potencjalne błędy techniczne.

Klikanie w Jednolity Plik Kontrolny

Kluczowy obecnie problem wynika z konieczności posłużenia się Windowsem lub Linuxem na potrzeby Jednolitego Pliku Kontrolnego. Nie wymagam aby była apka na IOS, ale chociaż na Maki jakby coś było to byłoby bardziej użytkowo. Jednak nie jestem zaskoczony – zazwyczaj podmioty publiczne preferują Windowsa. Jest jednak informacja na stronie ministerialnej, że planowane jest zmiana tego stanu rzeczy.

Stworzenie i wysłanie Jednolitego Pliku Kontrolnego wymaga mnóstwa kliknięć. Nieporównanie więcej niż przy znanej aplikacji „e-Deklaracja”. Umożliwia to wprawdzie kontrolowanie każdego etapu procesu, jednak prowadzi do automatyzmu w klikaniu. Zrozumiałem jest, że kliknięć wymaga skorzystanie z „zewnętrznego” profilu zaufanego ePUAP. Jednak wszystkie pozostałe czynności mogłyby zostać uproszczone, w tym konwersja do formatu XML mogłaby zostać zintegrowana z samym wysłaniem, a nie stanowić odrębny proces.

Z profilem zaufanym ePUAP związany jest również budzący wątpliwości etap procesu. Po skorzystaniu z tego instrumentu strona informująca o sukcesie operacji „podpisywania” wygląda jakby doszło do awarii. Witryna staje się całkowicie biała z niewielkim tekstem w rogu, co mocno odbiega wizualnie od wcześniejszych kolorowych witryn obsługujących profil zaufany ePUAP.

Wskazane powyżej instrukcje obsługi w kilku miejscach informują, że dany element stanowi „pole opcjonale” do wypełnienia. Nie wiadomo co to znaczy – kto przesądza o tej opcjonalności? Jest wątpliwość czy oznacza to, że użytkownik ma pełną swobodę i może tych danych informacji nie podawać, czy może też zależne to jest od jakiś uwarunkowań?

Co ciekawe, w zakresie określenia czterocyfrowego kodu urzędu skarbowego instrukcje obsługi posługują się linkiem do jakieś witryny. Link ten nie jest aktywny (przynajmniej u mnie nie był aktywny, może zależy to od czytnika PDF).  Nie można go też skopiować. Trzeba przepisać własnoręcznie do przeglądarki. A adres jest długi i dość skomplikowany.

Format liczb

Najbardziej przyziemny problem z Jednolitym Plikiem Kontrolnym dotyczy „zer”.  Właściwie był to jedyny błąd, który pojawił się przy przesyłaniu przeze mnie Jednolitego Pliku Kontrolnego. Mianowicie ukazał się komunikat, że wpisane przeze liczby nie są akceptowane (chodziło o czterocyfrowy kod urzędu skarbowego i REGON).

Problem wziął się z faktu, że choć dane te wpisałem prawidłowo, to Excel (czyli tak jakby Jednolity Plik Kontrolny) automatycznie usunął zera z początku wpisanych liczb. Czyli przykładowo z wpisanych „0123”, Excel zrobił „123”.

W pierwszym momencie pomyślałem, że to problem nie do rozwiązania. Od razu wiedziałem, że zmiana tych liczb na format tekstowy nic nie da, ponieważ choć umożliwi wyświetlenie zer na początku liczb, to jednak te liczby muszą mieć status „liczb”, a nie „tekstu”. Powątpiewałem też czy wystarczy zmiana formatowania liczb (poprzez stworzenie niestandardowego typu formatu), poprzez wymuszenie wyświetlania tych zer (opcje: Format / Formatowanie komórek / kategoria: Niestandardowe / i ręczne sformułowanie „Typ”-u, przykładowo poprzez zadanie „0###” dla ukazania zera na początku czterocyfrowej liczby). Wydawało mi się, że to może być bardziej tylko kwestia prezentacji i nie wpływać na samą „wartość” liczby. Na szczęście jednak udało się.

Kwestia zer wiodących jest wprawdzie wskazana w jednej z wyżej przywołanych instrukcji obsługi, jednak mowa tam tylko o nakazie ich stosowania. Nie wyjaśniono w jaki sposób uchronić się przez automatycznym ich usuwanie. Choć wskutek narzucenia Windowsa racjonalnym było przyjęcie, że do wyprowadzenia pliku XML posłuży Excel. Niemniej nie  mam wiedzy czy każda wersja Excela automatycznie ucina zera, czy tylko posiadana przeze mnie. Ewentualnie być może inne wersja Excela pozwalają na poczynienie odpowiedniego ustalenia opcji, w tym zakresie. U mnie jednak takiej opcji w ustawieniach nie było.