W styczniu 2016 roku Ministerstwo Finansów zorgranizowało konsulatacje społeczne w sprawie formatu Jednolitego Pliku Kontrolnego.
Poniżej zamieszczam uwagi, które zostały wysłane do ministerstwa.
Wstęp
Podstawowym celem formatu Jednolitego Pliku Kontrolnego jest przyspieszenie i częściowa automatyzacja procesu kontroli podatkowej. Format będzie obligatoryjny, co wymusi na producentach oprogramowania jego implementacje.
W związku z tym rodzi się szansa, na stworzenie powszechnego formatu e-faktury, który nie będzie służył jedynie do kontroli podatkowej, ale również ułatwi obrót gospodarczy i zmniejszy koszty księgowości w firmach poprzez częściową automatyzację księgowania faktur zakupowych.
Proponowany format niestety nie mógłby zostać wykorzystany w tym celu, ze względu na pewne niedoskonałości, które opiszę w dalszej części dokumentu.
Ogólne uwagi do JPK
Podstawową wadą proponowanego formatu są nieopisowe nazwy węzłów. Proponuję zmianę nazw w rodzaju <P_1>, <P_2a> na nazwy <DataWystawienia>, <NumerFaktury>. Pozwoli to na łatwe odczytanie danych przez człowieka z poziomu przeglądarki czy edytora tekstu, bez potrzeby użycia dedykowanych do tego celu narzędzi.
Numerowane pola utrudnią również implementowanie kolejnych wersji formatu w oprogramowaniu księgowym i systemach administracji publicznej. W przypadku dodania lub usunięcia pola konieczne byłoby przenumerowywanie kolejnych.
Część węzłów ma opisowe nazwy węzłów, ale w konwencji nazewniczej brakuje konsekwencji - wymieszane są nazwy w języku polskim i angielskim. Uważam, że należałoby zdecydować się na jeden z tych języków. Zaletą języka polskiego jest zwiększenie czytelności faktury w przypadku przeglądania przez przeglądarkę lub edytor tekstu. Język angielski może być przydatny jeśli format będzie również używany do transgranicznej wymiany danych.
Szczegółowe uwagi
Faktury VAT - JPK_FA
Stawki są określone w formacie na sztywno - wymusi to zmianę formatu w przypadku zmiany stawek VAT. Zalecam wprowadzenie katalogu stawek takich jak “nie podlega VAT", “zwolnione z VAT", “VAT rozlicza nabywca" oraz stawka procentowa (dowolna wartość).
W okresie przejściowym przy zmianie stawek VAT w jednym czasie będą obowiązywać stare i nowe stawki VAT. Mogą się zdarzyć przypadki faktur korygujących zawierających zarówno stare jak i nowe stawki.
Proponuję by podsumowanie VAT było przechowywane w wierszach zamiast osobnych węzłach dedykowanych dla każdej ze stawek. Takie rozwiązanie jest bardziej elastyczne i szczególnie dobrze się sprawdzi w okresach przejściowych zmiany stawek.
Nie jest jasne w jaki sposób przedstawić w proponowanym formacie faktury korygujące, faktury zaliczkowe czy końcowe. Faktury korygujące mogą zawierać pozycje przed i po korekcie. Faktury końcowa powinna zawierać co namniej numery faktur zaliczkowych.
Ustawa o VAT dopuszcza możliwość wyliczenia podatku od sumy sprzedaży netto (brutto) lub od wartości netto (brutto) każdej z pozycji osobno. Proponuję wprowadzić węzeł określający który z powyższych algorytmów został użyty.
Obowiązek podatkowy zwykle powiązany jest z datą sprzedaży, dokonania dostawy lub zakończeia usługi. Nie ma takiego pola w proponowanym formacie.
Adres nabywcy z węzła <P_3b> w elemencie zlepiony jest w jednej wartości tekstowej. Lepszym rozwiązaniem byłaby struktura w której wydzielona jest ulica, kod pocztowy, miasto i opcjonalnie numer domu, lokalu, poczta czy dane dotyczące jednostek administracyjnych kraju.
W węźle <P_4> opis sugeruje, że można w tym polu wpisać tylko NIP. Może to stanowić problem w przypadku faktury sprzedaży z kontrahentem z zagranicy posiadającym numer VAT lub innym identyfikator podatkowy.
Węzły <P_18> i <P_19> wymuszają stosowanie odwrotnego obciążenia i zwolnienia z VAT dla całej faktury. Mogą się zdażyć przypadki, w których część pozycji faktury będzie opodatkowana w sposób szcegóny a reszta na zasadach ogólnych. Lepszym rozwiązaniem byłoby przeniesienie tych oznaczeń na poziom stawek VAT.
W pozycjach faktury brakuje węzła z danymi PKWiU.
Z uwagi na potencjalną możliwość stosowania formatu do wymiany danych między firmami zalecam dodanie opcjonalnego pola z kodem towaru. Można również zdefiniować opcjonalne atrybuty do określenia jaki to rodzaj kodu.
W węźle <P_2b> w pozycjach faktury w którym powinna być liczba porządkowa, podany jest błędny opis (dotyczący numeracji faktur)
Format faktury nie ma informacji o walucie. Kod waluty podany jest globalnie dla całej listy faktur, co wymusi tworzenie osobnych eksportów. Dodatkowo uniemożliwi wykorzystanie formatu do wymiany danych między firmami.
Zalecam również wprowadzenie kursu, według którego przeliczone zostało podsumowanie VAT (faktura w EUR wystawiona dla polskiego podmiotu musi mieć kwotę podatku przeliczoną na PLN). Można dać informację z jakiego dnia to kurs i czy jest to kurs NBP czy ECB.
Należałoby również się zastanowić czy nie dodać informacji o walucie jako dodatkowy atrybut podsumowania VAT.
Rejestry VAT - JPK_VAT
Podobnie jak w przypadku faktur zalecam zastosowanie bardziej elastycznej struktury z informacją o poszczególych stawkach VAT:
Opisy rejestru zakupów sugerują że z fakturą zakupu powiązany jest jeden wpis. Nie zawsze tak jest. Przykładowo w metodzie kasowej może być wiele wpisów utworzonych dla kolejnych płatności.
W rejestrze VAT zakupów mogą znaleźć się też inne dokumenty (np dokumenty celne), nie tylko faktury, dlatego zamiast opisu Nr faktury, powinien być Numer dokumentu
W polu <K_3> jest NIP wystawcy faktury - w przypadku księgowania zakupu zagranicznego nie ma NIP-u, tylko jest inny typ identyfikatora.
Z uwagi na kasowe rozliczanie podatku VAT zalecam zmianę opisu pola <K_5> na data wpisu.
Moment powstania obowiązku podatkowego może być różny w fakturach sprzedaży i nie musi zależeć od daty sprzedaży i wystawienia (np w metodzie kasowej w zależności od daty zapłaty). W związku z tym również w tym rejestrze powinno być ogólne pole data wpisu.
W celu uproszczenia formatu można rozważyć połączenie rejestru sprzedaży i zakupów w jedną strukturę z typem rejestru.
KPiR - JPK_PKPIR
opis pozycji <P_1> i <P_2> może być mylący w przypadku rozpoczęcia lub zakończenia działalności w trakcie roku.
W opisach są drobne literówki (brak spacji przed -)
Proponuję dodać podsumowanie wszystkich kolumn (zgodnie ze wzorem KPiR). Ułatwi to analizę danych bez konieczności wczytywania pliku w dedykowanym oprogramowaniu.
Wzór JPK KPiR nie jest zgodny z aktualnym rozporządzeniem dotyczącym prowadzenia Podatkowej Księgi Przychodów i Rozchodów.
Ewidencja Przychodów - JPK_EWP
Podobnie jak w przypadku KPiR proponuję dodać podsumowanie wszystkich kolumn.
Dokumenty magazynowe - JPK_MAG
Zamiast tworzyć osobne struktury dla kolejnych typów dokumentów magazynowych, prościej by było stworzyć jeden ogólny format dokumentu z węzłem typ np <typ>PZ</typ>.
Może być problem z wyliczeniem ceny towaru w przypadku faktur zakupowych określonych w cenach brutto z wyliczeniem podatku od sumy sprzedaży brutto (powstaną groszowe różnice).
Przykład zalecanej struktury faktury
Poniższy przykład nie uwzględnia wszystkich możliwych i koniecznych przypadków, pokazuje jedynie proponowany styl formatu.