21 grudnia 2018 MF rozpoczęło konsultacje podatkowe nowej schemy JPK_VAT w związku z planowanym połączeniem JPK_VAT z deklaracją VAT. Konsultacje będą trwały do 15 stycznia 2019 r.

https://www.mf.gov.pl/ministerstwo-finansow/dzialalnosc/konsultacje-podatkowe/-/asset_publisher/M1vU/content/zawiadomienie-o-rozpoczeciu-konsultacjach-podatkowych-w-sprawie-nowej-schemy-jpk_vat?redirect=https%3A%2F%2Fwww.mf.gov.pl%2Fministerstwo-finansow%2Fdzialalnosc%2Fkonsultacje-podatkowe%3Fp_p_id%3D101_INSTANCE_M1vU%26p_p_lifecycle%3D0%26p_p_state%3Dnormal%26p_p_mode%3Dview%26p_p_col_id%3Dcolumn-2%26p_p_col_count%3D1

Jak się wydaje projektanci nowej schemy nieco poszli na skróty i połączenie odbyło się po prostu przez dopisanie do poprzedniej (n-1) wersji schemy pól z deklaracji VAT. W związku z tym powstał lekki bałagan i niepotrzebne powielanie informacji.

Nasza Kancelaria przygotowała uwagi do schemy i przesłała je do MF. Poniżej treść uwag. Jeśli chcieliby Państwo również przygotować uwagi do MF zapraszamy do wykorzystywania naszych uwag w swoich wypowiedziach. Udostępniając nasze uwagi kierujemy się wspólnym interesem do jak najbardziej optymalnego dostosowania plików JPK do celów im stawianych.

I. Uwagi generalne

1. Brak jest w obu schemach e-maila, który mógłby służyć do komunikacji z podatnikiem – w wersji obecnej istnieje to pole i nie widać powodu do rezygnacji z tego pola.

2. Część danych jest nieopisana szczególnie w elemencie JPK_VDEK/Naglowek w związku z tym nie można odnieść się do ich zawartości.

3. Niepotrzebnie wprowadzona jest redundancja obliczeń: z jednej strony mamy linie faktur, które są rozbite na poszczególne tytuły podatku a z drugiej strony wprowadzamy kilkukrotne sumowanie tych tytułów co wprowadza zupełnie niepotrzebne dodatkowe walidacje tak na poziomie produkcji JPK_VAT jak i na poziomie późniejszego sumowania. Techniczne pomyłki w programie sumującym będą rzutowały w związku z tym na merytoryczną ocenę jakości dostarczonego do KAS pliku JPK_VAT. Wydaje się to być nadmiernym i niepotrzebnym obowiązkiem generującym jedynie błędy po stronie wytwórców oprogramowania a nie wpływającym kompletnie na poprawność przygotowania danych przez przedsiębiorstwa.

II.Uwagi szczegółowe do zaproponowanych pól w obu schemach:

1. Diagram element JPK_VDEK/Naglowek zawiera wycofany z obecnej wersji JPK kod urzędu – proponujemy utrzymać usunięcie tego pola.

2. element JPK_VDEK/Podmiot1, attribute JPK_VDEK/Podmiot1/@rola – proponujemy usunięcie ze schem pól, które są stałe – ich wartość jest niezmienna, więc program wczytujący pliki z tej schemy może uzupełnić to automatycznie – nie ma potrzeby obciążania kilkudziesięciu producentów oprogramowania generowaniem pól stałych.

3. element JPK_VDEK/SprzedazWiersz/TerminPlatnosci – proponujemy usunięcie tego pola – termin płatności jest terminem jednoznacznym. W schemie zostało oznaczone, że może wystąpić tylko jedna wartość. Natomiast w rzeczywistości gospodarczej mamy do czynienia z np. harmonogramami płatności (przy sprzedaży telefonów komórkowych na przykład) – nie jest, więc możliwe jednoznaczne i poprawne uzupełnienie tylko jednej wartości. Ponadto należy zwrócić uwagę, że termin płatności może być przez strony umowy handlowej zmieniany bez zmiany treści faktury. W związku z tym to, co zostaje zapisane w fakturze jest wersją pierwotną uzgodnienia i nie musi być w przypadku zmian przekazywane do KAS.

4. element JPK_VDEK/SprzedazWiersz/Formaplatnosci – proponujemy usunięcie tego pola. Zaproponowane oznaczenia są niejednoznaczne i mogą budzić duże wątpliwości interpretacyjne (np. czy bon pieniężny kupiony za gotówkę będzie traktowany jako G czy jako I itp.). Ponadto forma płatności może być przez strony umowy zmieniona w stosunku do zapisów na fakturze w efekcie późniejszych uzgodnień. Zmiana formy płatności nie stanowi podstawy do wystawiania faktury korekty a co za tym idzie nie stanowi podstawy do przekazywania informacji do KAS. Faktyczna realizacja płatności może być, więc rozbieżna w stosunku do pierwotnych zapisów faktury

5. element JPK_VDEK/SprzedazWiersz/KodTypuDOkumentu – proponujemy usunięcie tego pola. Aby miała sens analiza kodów typu dokumentu powinno być to skodyfikowane na poziomie całego kraju w sposób zamknięty. Obecnie schemy zawierają jedynie przykładowe typy, które nie pozwalają na ocenę, do jakiego celu może być to zastosowane. Z drugiej strony kodyfikacja typu dokumentu wprowadzałaby duże zmiany do systemów księgowych bądź do ich parametryzacji – wprowadzenie tego wiązałoby się prawdopodobnie z dużymi nakładami.

6. element JPK_VDEK/SprzedazWiersz/KodGrupyTowarowej – proponujemy usunięcie tego pola. Zwracamy uwagę, że kod grupy towarowej ma odniesienie do linii faktury a nie do faktury, jako całości. Rozważając dla przykładu banalny zakup w sklepie spożywczym sera (kod 03) i wina (kod 04) uzyskalibyśmy na poziomie całej faktury brak możliwości określenia kodu. Zwracamy uwagę, że takie kody mogą znaleźć się natomiast na poziomie schemy JKP_FA.

7. element JPK_VDEK/SprzedazCtrl – proponujemy usunięcie pola ze schemy. W chwili obecnej pole to znajduje się w schemie natomiast tak jak napisaliśmy w punkcie I.3 powyżej jest to redundancja obliczeń i nie wprowadza nowych informacji do danych merytorycznych a jedynie sprawdza czy programiści piszący oprogramowanie do eksportu potrafią policzyć sumę.

8. element JPK_VDEK/SprzedazCtrl/LiczbaWierszySprzedazy – proponujemy usunięcie pola ze schemy. W chwili obecnej pole to znajduje się w schemie natomiast tak jak napisaliśmy w punkcie I.3 powyżej jest to redundancja obliczeń i nie wprowadza nowych informacji do danych merytorycznych a jedynie sprawdza czy programiści piszący oprogramowanie do eksportu potrafią policzyć liczbę wierszy.

9. element JPK_VDEK/SprzedazCtrl/PodatekNalezny – proponujemy usunięcie pola ze schemy. W chwili obecnej pole to znajduje się w schemie natomiast tak jak napisaliśmy w punkcie I.3 powyżej jest to redundancja obliczeń i nie wprowadza nowych informacji do danych merytorycznych a jedynie sprawdza czy programiści piszący oprogramowanie do eksportu potrafią policzyć sumę.

10. element JPK_VDEK/ZakupWiersz/KodTypuDokumentu – proponujemy usunięcie tego pola. Aby miała sens analiza kodów typu dokumentu powinno być to skodyfikowane na poziomie całego kraju w sposób zamknięty. Obecnie schemy zawierają jedynie przykładowe typy, które nie pozwalają na ocenę do jakiego celu może być to zastosowane. Z drugiej strony kodyfikacja typu dokumentu wprowadzałaby duże zmiany do systemów księgowych bądź do ich parametryzacji – wprowadzenie tego wiązałoby się prawdopodobnie z dużymi nakładami.

11. element JPK_VDEK/ZakupCtrl – proponujemy usunięcie pola ze schemy. W chwili obecnej pole to znajduje się w schemie natomiast tak jak napisaliśmy w punkcie I.3 powyżej jest to redundancja obliczeń i nie wprowadza nowych informacji do danych merytorycznych a jedynie sprawdza czy programiści piszący oprogramowanie do eksportu potrafią policzyć sumę.

12. element JPK_VDEK/ZakupCtrl/LiczbaWierszyZakupow – proponujemy usunięcie pola ze schemy. W chwili obecnej pole to znajduje się w schemie natomiast tak jak napisaliśmy w punkcie I.3 powyżej jest to redundancja obliczeń i nie wprowadza nowych informacji do danych merytorycznych a jedynie sprawdza czy programiści piszący oprogramowanie do eksportu potrafią policzyć liczbę wierszy.

13. element JPK_VDEK/ZakupCtrl/PodatekNaliczony – proponujemy usunięcie pola ze schemy. W chwili obecnej pole to znajduje się w schemie natomiast tak jak napisaliśmy w punkcie I.3 powyżej jest to redundancja obliczeń i nie wprowadza nowych informacji do danych merytorycznych a jedynie sprawdza czy programiści piszący oprogramowanie do eksportu potrafią policzyć sumę.

14. element PozycjeSzczegolowe/P_10 do P_35 oraz P_43 – P_48 – proponujemy usunięcie tych pól ze schemy. Tak jak napisaliśmy w punkcie I.3 powyżej jest to redundancja obliczeń i nie wprowadza nowych informacji do danych merytorycznych a jedynie sprawdza czy programiści piszący oprogramowanie do eksportu potrafią policzyć sumę z JPK_VDEK/SprzedazWiersz.”