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.