PLURIX - e-dokumenty dla fiskusa

Początki JPK
Czy mnie to dotyczy
JPK - jak zacząć
HTML - podstawy języka znaczników
XML - plik docelowy
XSD - specyfikacja do XML
Programy do podglądania i edycji
Część prawie-stała JPK
Rejestry
Skąd wziąć JPK i co z nim zrobić
Wysyłka do skarbówki

Prolog (przed świtem)

   Jak na razie, kontrol ma prawo w trakcie czynności (Ordynacja Podatkowa, art. 286 par. 1 pkt 4) dokonać "udokumentowanego pobrania danych w formie elektronicznej". Wiadomo - mogą sobie potem wgrać to do swojego programu i analizować na wszystkie sposoby: czy stawki VAT są poprawne, czy zapłaty są w terminie (i nie ma powodu do korekty CIT albo i VAT), czy nie ma powtórzeń i przeskoków w numeracji faktur - i to wszystkie transakcje, a nie tylko losowo wybraną próbkę jak podczas tradycyjnej kontroli. Nawet zakupiono kilkaset licencji na zachodnie programy ACL (dla urzędów skarbowych) czy WinIDEA ("duże" urzędy) - ale i krajowe Ocean GenRap (Comarch dla UKS). A ileż było szkoleń (HM Customs & Excise) ! "Organy" zostały zobowiązane do wykonania co najmniej dwu e-kontroli kwartalnie na każdą posiadaną licencję. I to nie ogranicza się tylko do księgowości: weźmy np. konfrontację RCP (rejestracja czasu pracy) z terminami wyjazdów służbowych? A "krzyżowe" kontrole między firmami: porównajmy produkcję i sprzedaż u dostawcy ze zakupami u hurtowników czy detalistów (zwłaszcza np. żywność, papierosy, bilety komunikacji,...). Oczywiście - po pierwsze: urząd musiałby znać format tych danych (ale uwaga: firma powinna posiadać opis używanego oprogramowania, gdzie m.in. takie informacje muszą się znaleźć). Po drugie jednak: dane te musiałyby istnieć w postaci elektronicznej. Jeżeli np. firma korzysta z oprogramowania księgowego "we chmurze", wbija tam sobie swoje faktury pracowicie przez cały miesiąc, a potem drukuje (najlepiej na papier, ale można i do PDF-u zabezpieczonego przed edycją a jeszcze taką czcionką, żeby OCR nie przeskanował go do EXCELa) i wszystkie zapisy z tej chmury znikają bezpowrotnie - to NIE MA ŻADNYCH danych elektronicznych do pobrania (a - co najfajniejsze - wydruki istnieją tylko w jednym egzemplarzu ! Tak podobno dziesięciolecia temu koncern IBM pokonał jankeskie służby skarbowe: zwalili im na podwórze kilkanaście ciężarówek wydruków - i grzebcie sobie, jak potraficie). Wezwanie do przekazania danych powinno m.in. określać "typy plików" - a co, jeżeli firma nawet używa oprogramowania - ale ono nie obsługuje żądanych typów plików? Zawsze też może zdarzyć się awaria sprzętu komputerowego a hasła do zaszyfrowanych dysków zaginąć.
   Niestety, zaczynają się zbierać czarne chmury. "Resort" wymyślił sobie i przeforsował w parlamencie (prawie - po poprawkach Senatu ustawa jest ponownie w Sejmie) jednolity plik kontrolny (JPK). Tłumacząc z polskiego na nasze: wszystkie firmy mają zmienić swoje oprogramowanie księgowe tak, aby na żądanie "kontrola" wygenerowały i przekazały do skarbówki dokumenty w jednolitym formacie (chciałem napisać "ustalonym" - no, ale właśnie jeszcze nie ma nawet zarysów jak ten format miałby wyglądać, nie mówiąc o szczegółowej specyfikacji dla informatyków. Tzw. JPK ma się pojawić w IV kwartale 2015 r.). Ma to wejść od 1 VII 2016 (dla średnich, małych i mikro - dwa lata później. Nie jest prawdą - co twierdziła np. Rzeczpospolita - że opóźnienie nie dotyczy mikrofirm: każda mikrofirma spełnia także warunki bycia małym czy średnim przedsiębiorcą. I uwaga: w ustawie o rachunkowości jest inna, bardziej restrykcyjna definicja mikroprzedsiębiorcy). Korzyści, oczywiście, widać - dla skarbówki, a nie dla przedsiębiorców: musi ministerialnych informatykierów nie stać na napisanie filtrów wciągających do tego ACLa pliki z najpopularniejszych programów księgowych. Jak wypsnęło się Wyszyńskiemu Jarosławowi (z-ca dyr. administracji podatkowej) we wywiadzie w RzPL z 22 IX 2015 (str. I2) w odpowiedzi na pytanie, czy ministerium finansów udostępni bezpłatne oprogramowanie dla firm (jak ta wtyczka do tych e-deklaracji): To daleko bardziej (dop. mój: czysty rusycyzm) zaawansowane oprogramowanie <...> My określimy w przepisach jego specyfikację techniczną, a produkcję <...> zostawimy już rynkowi. Komentarz chyba zbyteczny...
   Czy jest jakaś zaleta? Tak - jeżeli nacisk przesunie się na kontrole "zdalne", to rzadziej w łapy kontrolerów wpadać będą prawdziwe, papierowe dokumenty stanowiące podstawę księgowań. Co prawda, to już nie te czasy nagonek na brak pieczątki, podpisu, albo zwrotu "ORGINAŁ" (pisownia bardzo popularna w wielu protokołach i dokumentach); ale "elekstroniczna kontrol" nie wychwyci, że fakturę zakupu transportera piwa zaksięgowano jako "napoje dla pracowników". No, chyba że będą każdą fakturę sprawdzać krzyżowo u kontrahenta. Morał: dokonywać zaopatrzenia w małych placówkach, nie prowadzących księgowości komputerowej.
   Ministerium powołało umyślną spółkę celową, która ma przygotować całe oprogramowanie i bazę sprzętową do przeczesywania tych informacji ze spływających JPKów. Ma m.in. powstać centralny rejestr wszystkich faktur VAT wystawianych w Polsce - gotowość operacyjna ma być od 2018 roku (nieprzypadkowo - wdrażać będą to sobie na większych firmach, od 2018 JPK stać ma się obowiązkowy dla wszystkich i wtedy zapuszczą na pełny gwizdek). Nie wiem, czy przyczyni się to do walki z karuzelami podatkowymi - raczej z tych karuzel powstanie wesołe miasteczko.

na górę strony

Od kiedy muszę się w to babrać

Nie pytaj: komu bije (na dekiel, w ministerstwie) - Jotpek ten bije w Ciebie ! Pytanie nie brzmi CZY - ale OD KIEDY mnie to czeka? Powiedzmy sobie najpierw, że w sumie nad głową wiszą DWA obowiązki "elekstroniczne": jeden to comiesięczne (jak deklaracja VAT-7 - do 25 następnego miesiąca) przekazywanie bez wezwania TYLKO rejestrów VAT (art.82 §1b ordynacji podatkowej); drugi - przekazywanie na żądanie skarbówki CAŁEJ księgowości (art. 193a ordynacji podatkowej): księgi rachunkowe, wyciągi bankowe, magazyn, faktury (sprzedaż i ZAKUP - choć tutaj komunikat ministerium finansów z 28 lipca 2016 głosi, że zakupu NIE: tylko sprzedaży) - a nawet książka przychodów i ewidencja przychodów (ciekawe, czemu zabrakło specjalnego formatu dla karty podatkowej - zbiór pusty; a na poważnie - jeszcze się fiskusowi informatykierzy nie zorientowali, że brakuje ewidencji środków trwałych z tabelą amortyzacji oraz kart wynagrodzeń z ewidencją czasu pracy). Weźmy jednak pod uwagę, że jest to tylko inny sposób przekazywania dokumentów posiadanych przez podatnika - przepis ten znajduje się w dziale 11 ordynacji: Dowody i nie może mieć wpływu na prawa i obowiązki materialne podatnika. W szczególności, organ wciąż może żądać postaci papierowej. Z drugiej strony, dotyczy to tylko podatników prowadzących księgi z użyciem programów komputerowych (uwaga: EXCEL czy WORD zdaniem skarbówki też podpadają !) i tylko okresów od momentu wejścia obowiązku (1 lipca 2018 dla firm średnich i mniejszych).
Więc od kiedy? To zależy od wielkości (w sensie ustawy o swobodzie działalności gospodarczej) działalności w ostatnich dwu latach obrotowych (dla osób prawnych nie musi to być rok kalendarzowy): biorąc pod uwagę średnioroczne zatrudnienie (wyłącznie umowy o pracę, bez urlopów, w przeliczeniu na pełne etaty) oraz obrót netto (bez VAT - sprzedaż towarów, wyrobów, usług plus operacje finansowe) lub suma bilansowa (pisze się o sumie aktywów, ale mnie uczono, ze jest ona równa sumie pasywów). Wystarczy, że choćby w jednym z tych lat:

mikro: miesięczny obowiązkowy od 1 stycznia 2018; na żądanie od 1 lipca 2018: zatrudnienie MNIEJ niż 10 etatów ORAZ obrót lub bilans NIEPRZEKRACZAJĄCY 2,000,000 EUR
średnia i mała: miesięczny obowiązkowy od 1 stycznia 2017 (kilkadziesiąt tys. firm); na żądanie od 1 lipca 2018: zatrudnienie MNIEJ niż 250 etatów ORAZ obrót NIEPRZEKRACZAJĄCY 50,000,000 EUR lub bilans NIEPRZEKRACZAJĄCY 43,000,00 EUR
duża: JUŻ musi ! - oba od 1 lipca 2016 (6 tys. firm): w każdym roku co najmniej 250 etatów albo obrót ponad 50,000,000 EUR (lub bilans ponad 43,000,000 EUR)

MNIEJ niż 10 etatów oznacza, że równo 10 już się "nie łapie". NIEPRZEKRACZAJĄCY znaczy, że równo 2,000,000 jeszcze też jest dobrze. ORAZ znaczy, że jeżeli w pierwszym roku miał 9 etatów i 3,000,000 obrotu - a w drugim 10 etatów i 1,000,000 obrotu - to nie było takiego roku, w którym spełniałby OBA warunki, więc się nie kwalifikuje do odroczenia. Na 1 lipca 2016 brało się lata 2014 i 2015; na 1 stycznia 2017 oczywiście patrzymy na 2015 i 2016 (firma mogła być mikro na 2016, ale stać się małą na 2017), a na 1 stycznia 2018 już niczego nie musimy badać - bo dotknie to wszystkich. Mówi się, że nowopowstałe firmy powinny wyszacować swoją wielkość (np. na podstawie jednego miesiąca - ale nie ma to żadnego oparcia ustawowego).
   Oczywiście, radosna tFUrczość fiskusa i tu musiała dojść do głosu - ministerium finansów opublikowało opinię, iż mikroprzedsiębiorca musi spełniać podane powyżej warunki w OBU poprzednich latach obrotowych. Firmy, które choćby w jednym roku mieściły się "pod kreską" mogą albo się karnie podporządkować i "dla świętego spokoju" wysyłać JPK_VAT - albo (w razie próby nałożenia sankcji przez skarbówkę) zaskarżyć najpierw do Izby a potem do WSA (co polecamy).
   Nie ma odpowiedzi na pytanie, czy dokonując korekty deklaracji za okres sprzed obowiązku wysyłania miesięcznego JPK podmiot może tą korektę wysłać papierowo czy musi wypichcić JPK.
   Ponieważ te pliki na żądanie większość firm dotkną dopiero w 2018, więc dalej skupimy się tylko na tym obowiązkowym comiesięcznym JPK_VAT. Dobra nowina: nie dotyczy to podmiotów:

nie prowadzących ewidencji VAT (w sensie art. 109 §3 ustawy VAT) - a więc zwolnieni podmiotowo (art. 109 ustawy VAT: sprzedaż <150,000 PLN, granica ma wzrosnąć do 200,000 PLN) lub przedmiotowo (art. 43 ust. 1 ustawy VAT - np. najem wyłącznie lokali mieszkalnych). Piszę podmiotów, bo to NIE ogranicza się tylko do firm prowadzących działalność gospodarczą, ale dotyczy w ogóle podatników VAT, więc np. najem prywatny na dużą skalę też podpada.
(uwaga: wyłączenie to NIE DOTYCZY późniejszego obowiązku przekazywania JPK na żądanie - to dotyczyć będzie także nie-podatników VAT).
nie prowadzących rejestrów przy uzyciu programów komputerowych: EXCEL także jest traktowany jako program komputerowy. Mówi się, że deklaracja VAT powinna być w 100% wypełniana informacją z komputera i jeżeli część danych obrabiam na papierze, to już też "nie podlegam", ale nie ma oficjalnej wykładni na dziś.
   Co więcej, od 1 stycznia 2018 ma obowiązywać art. 109 ust. 8a ustawy VAT nakazujący prowadzenie tej ewidencji (z art. 109 ust. 3) "elektronicznie przy użyciu programów komputerowych". (Pomijam pytanie: jak możnaby prowadzić ją "przy użyciu programów komputerowych" - ale NIE "elektronicznie"? Czy ministerium finansów ma na myśli komputery BIOLOGICZNE???) Otóż - przepisy dyrektywy UE dla ewidencji NIE przewidują możliwości takiego przymusu (tylko dla DEKLARACJI).
   Rozszerzono także (od 1 stycznia 2017) art. 109 ust. 3 ustawy VAT: ewidencja ma zawierać również dane niezbędne do sporządzenia informacji podsumowującej VAT-UE (oraz inne dane służące identyfikacji poszczególnych transakcji).
   To jednak dotyczy tylko rejestrów VAT do miesięcznego JPK_VAT. Firma prowadząca pozostałe ewidencje na papierze nie będzie musiała na żądanie skarbówki tworzyć innych JPK (np. książki przychodów).
wreszcie, może się zdarzyć cud: na wniosek podatnika do naczelnika USk może on odroczyć termin złożenia JPK_VAT.

Od 1 stycznia 2017 ma zniknąć deklaracja kwartalna VAT-7D (dla "dużych", ze zaliczkowym płaceniem VAT co miesiąc) - zostają tylko VAT-7K. No, i informacje podsumowujące (VAT-UE, VAT-27) mają się stać też tylko elektroniczne.

na górę strony

Nie taki Jotpek straszny, jak go drukują

   Prelegent zapowiedział: „Czy wiecie Państwo, jak wygląda JPK na stronach Ministerstwa Finansów? To jest 227 stron !” Miał rację – ale oczywiście okłamał.
   Tak, to prawda – w zerwaniu z jakimikolwiek konstytucyjnymi zasadami legislacji (art. 87 ustawy zasadniczej), obowiązek podatkowy w zakresie postaci informacji przekazywanej obligatoryjnie przez podatników do skarbówki nie został skonkretyzowany ani ustawą, ani aktem podustawowym (czytaj – rozporządzeniem ministerialnym) ale – przez podanie odnośnika do pliku na stronach internetowych ministerstwa. O ile zmiana ustawy wymaga decyzji Parlamentu, zmiana rozporządzenia co najmniej podpisu odnośnego ministra i publikacji w odpowiednim dzienniku urzędowym (tak jest np. z deklaracjami podatkowymi - zdefiniowanymi w rozporządzeniu z 24 grudnia 2007)– to postać tej informacji może zmienić się w nieuchwytny sposób nawet w czasie czytania tego tekstu (już zmieniła się TRZY razy). I nie ma tutaj zagwarantowanego odpowiedniego wyprzedzenia czasowego od momentu publikacji do wejścia w życie; a niezgodność z aktualnie objawioną Wysoką Specyfikacją powoduje odrzucenie przesłanego JPK i – w konsekwencji – potraktowanie go jako nie złożonego w terminie (i nałożenie stosownej kary, oczywiście). I ta to specyfikacja to odnośniki do kilku zbiorów, w tym jeden tekstowy (w formacie PDF) faktycznie liczący te ponad dwieście stron A4. Tyle, że ten wydruk zawiera np. spis wszystkich urzędów skarbowych w kraju (a każdy jeden zajmuje od razu pięć linijek) czy spis wszystkich kodów krajów UE. I na dodatek – to NIE JEST prawdziwy (ani nawet przykładowy) JPK – ale tylko opis (receptura): jak ma on wyglądać (a dokładnie – jak sprawdzić, czy jest OK). A czemu to takie rozwlekłe? Bo sama specyfikacja (maszynowa - XSD) liczy sobie tylko 460 linijek, tj. niepełne 7 stron A4. Bazuje to (podobno) na wymyśle EURochujerów XML OECD SAFT 2.0 Standard Audit File Tax
   Dobra zmiana: Oleśniewicz Jarosław z ministerstwa nauczył się już widać programu XMLSpy (firmy Altova, 400..800 EUR) i tworząc nowe wydruki do wersji JPK_VAT(2)_v1.0 "przeczesał" ten PDF - zajmuje on już TYLKO 70 stron A4 (choć wielkość samej specyfikacji maszynowej XSD wzrosła do 520 linijek, tj. niepełne 8 stron A4.

na górę strony

HTML czyli Bajki z 1001 Nocy

   Musimy zacząć od samego początku. Te kilka eonów po Wielkim Wybuchu (na początku był Chaos – a potem Bóg oddzielił Zera od Jedynek i nazwał je Bitami – i zobaczył, że to było dobre...) sobie pominiemy i przejdziemy od razu do epoki, kiedy komputery wszystkich krajów połączyły się (internetem). Niestety, chaos był jeszcze większy: nie było Jednego Obowiązującego Komputera, ale mnóstwo rodzajów: duże (ang. mainframes), stołowe, osobiste, kieszonkowe; bajtowe i słowowe (cokolwiek by to miało znaczyć), od dużego i małego końca (Big Endian i Little Endian – nie mylić z czerwonoskórymi), z alfabetem 6, 7 czy 8-bitowym... A na dodatek to oprogramowanie: Jabłka, Pingwiny, Windy, Roboty - Brrr ! I jak tu wprowadzić Jednolity Plik Kontrolny? (można było, oczywiście, jak w Płatniku – zadekretować, że tylko Windows, żadne tam Jabłko czy Pingwin).
   Na początku świata komputery służyły do obliczeń (łamania szyfrów, symulacji bomby atomowej, prognoz pogody, projektowania mostów...), ale wkrótce wykorzystano je jako inteligentne maszyny do pisania: z edytorów używanych do poprawiania plików z programami bez przepisywania i gumowania - wykształciły się programy do składania publikacji (wcięcia, akapity, justowanie, interlinie,...); a wraz ze zamianą dalekopisów na ekrany zaczęto używać różnych środków ekspresji: oprócz podkreślania stało się możliwe wytłuszczanie, kursywa, zmiana czcionek,... W plikach oprócz właściwej treści zagościły różne znaki sterujące wydrukiem i układem tekstu (popularnie zwane "kieliszkami", bo są to znaki spoza "normalnego" alfabetu i przy podglądzie zawartości takiego zbioru na ekranie wyświetlały się takie "krzaczki"). Jak długo posługiwaliśmy się tylko jednym komputerem – nie było sprawy; problem zaczynał się przy próbie podesłania jakiegoś pliku użytkownikowi INNEGO komputera. Owszem, zaczęły powstawać pewne reguły – oparte na alfabecie ASCII (pierwsze 64 albo 128 znaków) standardy CSV (dla arkuszy kalkulacyjnych = dzisiejszy EXCEL) czy RTF (dla dokumentów tekstowych = dzisiejszy WORD).
   Wraz z powstaniem internetu trzeba było to ujednolicić - i tak powstał standard HTML: system znaczników zanurzonych w naszym zbiorze tekstowym i służących do opisu sposobu wyświetlania i interpretacji tego tekstu. Przyjęto odmienną koncepcję odróżniania znaczników od tekstu: wszystkie litery w pliku mają być "drukowalne", a znaczniki rozpoznaje się po ich zamknięciu w nawiasy ostrokątne: otwierający "<" i zamykający ">" (np. <center> - wyśrodkowanie). Dzięki temu nie ma problemów z przesyłaniem plików HTML pomiędzy niekompatybilnymi komputerami czy systemami operacyjnymi, a i tworzyć można je nawet zwykłym Notatnikiem.
   Prawda jest oczywiście dokładnie odwrotna: to nie znaczniki są zanurzone w tekście - ale na szkielecie utworzonym przez te znaczniki powieszone są fragmenty tekstu, obrazki, animacje, formularze... Dokument w formacie HTML ma bowiem ściśle określoną strukturę - zaczyna się deklaracją (<!DOCTYPE...>), po której następuje hierarchicznie zagłębiające się drzewo elementów. Element znowuż - to konstrukcja składająca się ze znacznika otwierającego, pasującego do niego znacznika zamykającego i umieszczonej między nimi zawartości. Znacznik otwierający - jak już wiemy - zaczyna się od ostrokątnego nawiasu otwierającego po którym występuje nazwa (tego znacznika), np. <center>. Dodatkowo, wewnątrz tych ostrokątnych nawiasów mogą jeszcze występować dodatkowe określenia szczegółowe, tzw.atrybuty: oddzielone odstępami równości nazwaatrybutu="wartość atrybutu" (w nazwach znaczników ani nazwach atrybutów odstepy nie są dozwolone, w treści atrybutów - już tak, stąd ujmowana jest ona w cudzysłowy), np.

<table style="naglowek" SUMMARY="Zestawienie sprzedaży">.

Znacznik zamykający różni się od otwierającego tym, że jego nazwa poprzedzona jest ukośnikiem (i nie ma atrybutów), np. </center> (koniec wyśrodkowywania). Znowuż mamy pełne nawiasowanie: elementy nie mogą zachodzić na siebie częściowo - tylko jeden musi być mieścić się całkowicie w drugim (w jego zawartości mianowicie; może też być kilka elementów podrzędnych w zawartości jakiegoś nadrzędnego); zatem tak jest dobrze

<b>Bold = wytłuszczenie <u>plus Underline = podkreślenie</u> koniec podkreślenia</b> odtąd bez wytłuszczenia

a tak jest ŹLE

<b>wytłuszczenie <u>i podkreślenie </b> ??? </u>

Musi być tak, jak w Księdze z 1001 nocy: wewnątrz jednej bajki zaczyna się zagłębiona druga opowieść, w niej trzecia - kończy się trzecia (a nie żadna inna), może zacząć się czwarta (i zakończyć) albo i nie, teraz dopiero kończy się druga...
Musimy jeszcze wspomnieć o komentarzu - elemencie mającym dość wyróżniającą się postać:

<!-- dowolne znaki nie zawierające dwu sąsiadujących minusów -->

który można wstawiać wszędzie (respektując jednak zasadę pełnego nawiasowania). Jak każdy komentarz - jest on całkowicie pomijany i służy do zwiększenia czytelności tekstu dla człowieka (nie unikajcie komentarzy !!! Po [dwu]tygodniach sami już nie będziecie pamiętali "co autor miął na myśli").
:Są też elementy nie mające zawartości z definicji - niektóre z nich składają się tylko ze znacznika otwierającego (bez zamykającego): np. <br> - break (ang. nowa linijka); inne (to już głównie standard XHTML) mają równocześnie znacznik otwierający i zamykający (przed zamykającym nawiasem ostrokątnym jest ukośnik), np.:

<img src="http://www.plurix.com.pl/becher8.jpg" title="To już 7 becherovka"/>

Cóż więcej? A jeżeli chcemy wyświetlić wzór matematyczny (w którym mamy znaki "<")? Żeby nie zostały one rozpoznane jako początek znacznika otwierającego - trzeba je "opakować" (znieczulić) - zamiast "<:" piszemy "<". Znak "&" oznacza, że za nim - aż do średnika - jest NAZWA jakiegoś znaku. Podobnie ">" dla ">", czy wreszcie "&" dla samego "&" (jest to ustalona tabela nazw: lt = less than, ang mniejszy od; gt = greater than, ang większy niż; amp = ampersand, ang. etka albo handlowe "i").
I tak wygląda dokument zgodny ze standardem HTML: za deklaracją <!DOCTYPE...> występuje dokładnie jeden element - html, na którego zawartość składają się dokładnie dwa elementy - head oraz body. Zawartością elementu head (ang. nagłówek) są różne elementy opisujące sposób potraktowania naszej strony www; elementu body (ang. treść, zawartość) jest hierarchia elementów zawierających właściwą treść do wyświetlenia, np.

<!DOCTYPE html>
<html lang="pl">
 <head>
  <title>Nazwa okienka na pasku</title>
 </head>
 <body>
  <b>Witaj</b>, świecie ! <br>
  Wiadomo, co na pierwszej stronie
 </body>
</html>

na górę strony

XML dla opornych

Po co było to (przydługie) liźnięcie HTML (bo nie wchodziliśmy zbyt głęboko ! ) skoro mamy zająć się JPK? Ano, poznaliśmy pewne reguły rządzące językami znaczników - a prościej jest je zilustrować na przykładzie HTML: gdzie przekładają się one na poglądowe wizualizacje. JPK bowiem to plik w formacie XML - co to oznacza? Ano - jeżeli HTML jest językiem do określania JAK wyświetlać dane zawarte w pliku - to XML jest językiem do przechowywania i przesyłania DANYCH pomiędzy niekompatybilnymi komputerami. W ogóle w XML nie zajmujemy się JAK te dane mają być wyświetlane (bo NIE MAJĄ - adresat ma je tylko POPRAWNIE odebrać) - tylko CO chcemy przesłać.
Łatwo nam teraz będzie opisać poprawnie zbudowany (ang. well formed) plik XML. To TEŻ jest język znaczników, i powinien wyglądać tak - najpierw nagłówek:

<?xml version="1.0" encoding="UTF-8">
<?xml-stylesheet type="text/..." ...?><!-- zero lub kilka wpisów jak WYŚWIETLAĆ plik XML gdyby co -->
<!DOCTYPE ...><!-- opcjonalnie: definicje DTD - jakie TYPY danych mogą wystąpić w pliku -->

a po nim POJEDYNCZY element - albo prosty:

<?xml version="1.0" encoding="UTF-8">
<JPK/>

lecz częściej złożony:

<?xml version="1.0" encoding="UTF-8">
<JPK>
 <Naglowek> </Naglowek>
 <Podmiot1> </Podmiot1>
 <SprzedazWiersz> </SprzedazWiersz>
 <SprzedazCtrl> </SprzedazCtrl>
 <ZakupWiersz> </ZakupWiersz>
 <ZakupCtrl> </ZakupCtrl>
</JPK>

Nazwy znaczników mogą być wybierane dowolnie (prawie - nie mogą zawierać odstępu, ani tekstu "xml" - jest zarezerwowany, muszą zaczynać się od litery a potem mogą być tylko litery, cyfry i znaki ukośnik "\", minus "-", niska spacja "_", kropka "."; zaś dwukropek ":" ma specjalne znaczenie - odwołuje się do innej przestrzeni nazw - o tym poniżej); w przykładach powyżej jako "korzeń" drzewa elementów użyliśmy (nieprzypadkowo) nazwy "JPK", a podporządkowane elementy noszą nazwy "Naglowek", "Podmiot1", "SprzedazWiersz", "SprzedazCtrl", "ZakupWiersz", "ZakupCtrl". Oczywiście, znaczniki mogą zawierać atrybuty, dopuszczalne są komentarze, - i praktycznie nie ma innych ograniczeń. Ostrzegam - w nazwach znaczników czy atrybutów rozróżnia się duże i małe litery, zatem "ZakupWiersz" i "zakupwiersz" to DWA RÓŻNE znaczniki. Często programiści wymyślając te nazwy posługują się notacją "wielbłądzią" (ang. camelCase): w której kolejne wyrazy zlepia się razem bez odstępów, ale dając każdemu kolejnemu słowu składowemu dużą pierwszą literę (stąd taki wyrazZłożonyZWieluPojedynczych wygląda trochę jak ten wielogarbny wielbłąd), i to we wersji z języka Pascal (pierwsza litera całego słowa też duża). No, i wiadomo - polskich liter w nazwach unikamy jak ognia.

na górę strony

Hulaj dusza - piekła nie ma: ale jest XSD

   Ależ to by był dopiero chaos ! Pliki XML przeznaczone są do komunikacji komputera z komputerem - i ten adresat musi wiedzieć, czego ma się spodziewać (a nadawca przygotować zbiór XML zgodnie z oczekiwaniami). A jak zapiszemy te oczekiwania?
   Oczywiście (ponieważ ta specyfikacja zawartości zbioru XML jest przeznaczona bardziej dla komputerów niż dla człowieka) uzyjemy kolejnego języka komputerowego oznaczonego XSD (końcowe "D" - od ang. "description", pol. opis). TAK ! słusznie się domyślasz - to także język znaczników: każdy plik XSD musi być przede wszystkim poprawnym zbiorem XML. Zawartość zbioru XSD to jest jakby przepis kulinarny (receptura) - co i jak ma być w tym zbiorze XML, który zamierzamy przesyłać z jednego komputera na drugi.
   A CO ma być? Żeby "wypichcić" zbiór XML muszę znać w zasadzie dwie rzeczy - jakie ma być to hierarchiczne drzewo elementów (bo mogą być warianty - nie wszystkie liście czy gałęzie muszą występowac, także ilośc ich powtórzeń może się zmieniać), i co ewentualnie możemy wpisać jako zawartość konkretnego elementu. Plik XML musi być po pierwsze poprawnie zbudowany (ang. well formed - o tym było w poprzednim akapicie o XML); po drugie - dla plików takich jak ten JPK jego budowa i zawartość musi być zgodna z definiującym go zbiorem XSD.
   I tak dokładnie zbudowany jest zbiór XSD. XSD jest to "metajęzyk" - język (sztuczny) do opisu innego języka (też sztucznego - z grupy języków XML): konkretnego XML. Jeszcze prościej: każdy zbiór XSD jest (sformalizowanym) podręcznikiem gramatyki pewnego konkretnego języka XML (piszę: języka - bo jest potencjalnie wiele róznych plików XML zgodnych z daną specyfikacją XSD; choćby plik XSD dla JPK jest jeden - a poprawnych zbiorów JPK o wiele więcej, niż miesięcy i firm w kraju). XSD ma, niestety, o wiele bardziej sformalizowaną strukturę, niż XML (bo zbiór XSD jest całością "sam dla siebie" i każdy z komputerów musi wiedzieć, jak go odczytać; zaś zbiór XML jest sensowną całością dopiero z tym opisującym go zbiorem XSD) - ale nie martwmy się tym: o ile zbiory XML będziemy PISAĆ (tworzyć) - więc musimy wiedzieć JAK (aby były bezbłędne), to zbiory XSD będziemy jedynie CZYTAĆ (tworzy je ktoś inny - tutaj: Ministerstwo Finansów) - i nie musimy zastanawiać się nad ich poprawnością.
   Zbiór XSD zaczyna się - a jakże - nagłówkiem, po którym jest POJEDYNCZY element xsd:schema zawartością którego są elementy xsd:complexType (grupy pól formularza) oraz xsd:simpleType (pojedyncze pola) określające używane (dopuszczalne) w danym XML (w zawartości konkretnego elementu pliku XML) typy danych (w tym ewentualnie także elementy xsd:include doczytujące zewnętrzne, biblioteczne pliki definicji XSD) a także ew. POJEDYNCZY element xsd:element, którego zawartość określa (hierarchiczne) drzewo elementów danego pliku XML (jeżeli to jest finalny plik XSD, a nie taki do dołączenia do głównego pliku finalnego XSD):

<?xml version="1.0" encoding="UTF-8">
<xsd:schema ...><-- z reguły atrybut xmlns:xsd="http://www.w3.org/2001/XMLSchema", także inne przestrzenie nazw, jak xmlns:etd czy xmlns:tns-->
 <xsd:include schemaLocation="http://....xsd"/>
 <xsd:import namespace="http://..." schemaLocation="http://....xsd"/>
 <xsd:simpleType name="TKodFormularza"> <-- zawartość = opis pojedynczego pola TKOdFormularza --></xsd:simpleType>
 <xsd:complexType name="TNaglowek"> <-- zawartość = opis sekcji danych TNaglowek --></xsd:complexType>
 <xsd:element name="JPK"> <-- zawartość = opis hierarchii elementów podrzędnych, a głównym jest JPK --></xsd:element>
</xsd:schema>

Zawartość każdego z tych elementów może mieć element xsd:annotation (przypominam - to jest hierarchiczne drzewo i w jednym elemencie często są kolejne, podporządkowane) będący (przeznaczonym dla człowieka) opisem:

 <xsd:annotation>
  <xsd:documentation>Co to (i po co) to za pole</xsd:documentation>
 </xsd:annotation>

Element xsd:simpleType bazuje najczęściej na jakimś już opisanym wcześniej typie danych, ograniczając go dodatkowymi warunkami (niech będzie to liczba całkowita - ale nie więcej niż 14 cyfr, a wszystkie "białe" znaki usunięte z początku i końca, zaś we środku wielokrotne zredukowane do pojedynczego odstępu):

 <xsd:simpleType name="TCalkowity">
  <xsd:restriction base="xsd:int">
   <xsd:totalDigits value="14"/>
   <xsd:whiteSpace value="collapse"/>
  </xsd:restriction>
 </xsd:simpleType>

Ograniczenia (odróżniające nowy typ od bazowego) to wypisane w części xsd:restriction jego definicji elementy (ich nazwa oczywiście poprzedzona prefiksem xsd:, z atrybutem value, bez zawartości - tj. samozamykające - jak totalDigits czy whiteSpace w przykładzie powyżej) z poniższego wykazu:

minLength - minimalna ilość znaków (albo elementów listy)
maxLength - maksymalna ilość znaków (albo elementów listy)
length - dokładnie tyle znaków (albo elementów listy)
pattern - tzw. wyrażenie regularne: wzorzec opisujący pasujące do niego teksty (konkretne znaki oraz ich ilość i kolejność)
totalDigits - maksymalna ilość cyfr w liczbie
fractionDigits - maksymalna ilość cyfr "po przecinku"
minInclusive bądź minExclusive - wartość minimalna (przedział domknięty bądź otwarty)
maxInclusive bądź maxEclusive - wartość maksymalna
whiteSpace - co robić z "białymi" znakami: preserve, replace, collapse

Może też to być wyliczenie konkretnego wykazu wszystkich dopuszczalnych wartości typu prostego

 <xsd:simpleType name="TKodNaczUS">
  <xsd:restriction base="xsd:string">
   <xsd:enumeration value="0202 - NACZELNIK URZĘDU SKARBOWEGO W BOLESŁAWCU"/>
   <xsd:enumeration value="0203 - NACZELNIK URZĘDU SKARBOWEGO W BYSTRZYCY KŁODZKIEJ"/>
   <!-- i kolejne 397 podobnych linijek... -->
  </xsd:restriction>
 </xsd:simpleType>

Częste jest połączenie kilku róznych typów prostych w jeden (niech będzie albo kod krajów spoza MS albo z MS):

<xsd:simpleType name="CountryCode_Type">
 <xsd:union memberTypes="kck:CountryCodeExMS_Type kck:MSCountryCode_Type"/>
</xsd:simpleType>

W JPK występuje też konstrukcja

<xsd:simpleType name="TNrREGON">
 <xsd:union><!-- albo 9 albo 14 cyfr -->
  <xsd:simpleType>
   <xsd:restriction base="xsd:string"><xsd:pattern value="\d{9}"/></xsd:restriction>
  <xsd:simpleType>
  </xsd:simpleType>
   <xsd:restriction base="xsd:string"><xsd:pattern value="\d{14}"/></xsd:restriction>
  </xsd:simpleType>
 </xsd:union>
</xsd:simpleType>

Wreszcie, możemy zezwolić na podanie w XML całej listy dozwolonych wartości danego typu prostego (oddzielonych odstępami), np. 5 17 2 - w JPK nie występują takie typy:

<xsd:simpleType name="numerki"><xsd:list itemType="xsd:integer"/></xsd:simpleType>

tutaj prawidłową będzie dowolnej długości lista jakichkolwiek liczb cakowitych - gdybyśmy chcieli dopuścić listę np. co najwyżej 4 liczb, musimy (bazując na powyższym typie numerki) ograniczyć długość tej listy tworząc nowy typ numerki4:

<xsd:simpleType name="numerki4">
   <xsd:restriction base="numerki"><xsd:maxLength value="4"></xsd:restriction>
</xsd:simpleType>

Określając potem, że element zbioru XML (jaki akurat będziemy opisywać) ma być danego typu prostego definiujemy, iż w tym XML ma to być pojedynczy element, a w jego zawartości mogą wystąpić tylko znaki pasujące do opisu przedmiotowego typu.
Element xsd:complexType definiuje natomiast typ złożony (zawierający w sobie "dzieci" - inne typy proste lub też złożone), tj. przy użyciu go potem do określenia typu jakiegoś elementu zbioru XML - będzie w tym XML występowało całe drzewo: element otwierający z nazwą własnie określaną, zawartość na którą będą się składały elementy tych typów podporządkowanych (dzieci) i wreszcie element zamykający z nazwą właśnie określaną (wyjaśnią to może przykłady poniżej). Najczęstszym typem złożonym jest zestaw kilku kolejnych pól "podporządkowanych" należących do jednego działu:

<xsd:element name="Naglowek">
 <xsd:complexType>
  <xsd:sequence>
   <xsd:element name="IdentyfikatorPodmiotu" type="abc:Podmiot"/>
   <xsd:element name="AdresPodmiotu" type="abc:Adres"/>
  </xsd:sequence>
 </xsd:complexType>
</Naglowek>

co w XML będzie (w tej samej kolejności ! ) np.:

<Naglowek>
 <IdentyfikatorPodmiotu>Ministerstwo</IdentyfikatorPodmiotu>
 <AdresPodmiotu><!-- to może być znowuż typ złożony --></AdresPodmiotu>
</Naglowek>

Jeżeli zamiast "otuliny" sequence (kolejność) użyjemy choice (wybór) - to w XML musi być jedno i tylko jedno z tych typów podporządkowanych.

<xsd:choice>
 <xsd:element name="ImieNazwisko" type="..."/>
 <xsd:complexType>
  <xsd:sequence>
   <xsd:element name="Imie" .../><xsd:element name="Nazwisko" .../>
  </xsd:sequence>
 </xsd:complexType>
</xsd:choice>

wtedy w XML może być np.

<...><ImieNazwisko>Jan Kowalski</ImieNazwisko></...>

albo

<...><Imie>Jan</Imie><Nazwisko>Kowalski</Nazwisko><...>

Wreszcie "otulina" xsd:all mówi, że kolejność tych pól "podporządkowanych" może być dowolna.
Możemy też jako zawartość typu złożonego umieścić pojedynczy element xsd:simpleContent definiujący pojedynczy tekstowy element w XML (nie może on mieć już typów potomnych w sobie - ale może on mieć atrybuty, czego typy proste nie dozwalają). W ogóle, typy proste można tylko ograniczać - a nie rozszerzać. Natomiast xsd:complexContent "opakowuje" rozszerzenie (xsd:extension base="...") bądź ograniczenie innego typu złożnego: w zasadzie każdy typ złożony powinien zawierać simpleContent albo complexContent - tyle, że complexContent (i zawarty w nim xsd:restriction base=...) można pominąć (jako bazowy brany jest wówczas domyślnie xsd:anyType).
Mozna pójść jeszcze dalej - użycie w znaczniku xsd:complexType atrybutu mixed="true" powoduje, że w zawartości opisanego danym typem danych elementu pliku XML mogą pomiędzy elementami "potonmymi" występować dowolne teksty znakowe.
Podstawowe typy (wbudowane w standard języka XSD) mają nazwy zaczynające się oczywiście od przedrostka xsd:, po którym występuje łatwo czytelna (przynajmniej dla informatyka) nazwa: string (napis tekstowy), date, byte, integer (liczba całkowita),... Tworząc swoje (nowe) typy korzystamy albo z tych wbudowanyvch (xsd:...)- albo ze zaczerpniętych z jakiejś biblioteki (pliku XSD przygotowanego przez kogoś innego i zaimportowanego do naszego opisu poprzez include; zaczynają się one INNYM przedrostkiem, np. tns: czy etd: (w slangu informatycznym mówimy o przestrzeni nazw, ang, namespace). Aby znaleźć tą bibliotekę (i potrzebne nam definicje) człowiek patrzy na atrybuty xmlns:... w rozpoczynającym plik XSD elemencie xsd:schema (tns: natomiast to jest generalnie bieżący plik).
Może starczy o definiowaniu typów? Wszystkiego i tak nie powiem tutaj (polecam samokształcenie przez internet - jakby co), a - przypominam: nie będziemy definiować nowych typów (PISAĆ pliki XSD) - ale analizować już napisane definicje (CZYTAĆ poprawne pliki XSD). To teraz zdefiniujmy wreszcie jakiś element dla pliku XML (bo po to tę żabę jemy). Piszemy

<xsd:element name="Naglowek" type="tns:TNaglowek"/>

i już wiemy, że w pliku XML ma być

<Naglowek><!-- tu zawartość zgodna z typem tns:TNaglowek --></Naglowek>

Albo dodamy atrybut: DataSprzedazy może być albo nie być

<xsd:element name="DataSprzedazy" type="tns:TData" minOccurs="0"/>

czy wręcz: niech będzie od 2 do 7 razy, nie mniej i nie więcej

<xsd:element name="TrafionyNumerek" type="xsd:integer" minOccurs="2" maxOccurs="7"/>

(a maxOccurs="unbounded" oznacza - nieograniczona ilość razy).
Możemy oczywiście - zamiast posłużenia się wczesniej zdefiniowanym typem danych - zdefiniować dopuszczalną zawartość wprost w definicji elementu (jeżeli użyjemy jej tylko raz):

<xsd:element name="Brutto">
 <xsd:simpleType>
  <xsd:restriction base="xsd:decimal">
   <xsd:fractionDigits value="2">
  </xsd:restriction>
 </xsd:simpleType>
</xsd:element>

Do tej pory potrafimy zdefiniować tylko nazwy i zawartość elementów mających składać się na hierarchię zbioru XML; ale elementy mogą przecież mieć także i atrybuty - je też definiujemy w XSD (ale na końcu zawartości definicji typu), np.:

 <xsd:complexType>
  <!-- tutaj definicja zawartości tego elementu -->
  <xsd:attribute name="typ" use="required" fixed="G" />
 </xsd:complexType>

Gdy użyjemy tego typu danych do zdefiniowania elementu o nazwie np. SprzedazWiersz. to w poprawnym pliku XML jego wystąpienie musi mieć postać (atrybut type MUSI wystąpić i MUSI mieć wartość G):

 <SprzedazWiersz typ="G">
  <!-- tutaj jakaśtam zawartość tego elementu -->
 </SprzedazWiersz>

na górę strony

Żegnaj XSD - witaj drzewo

   Czy ja to muszę wszystko wiedzieć - pytasz? Formalnie - nie; to jest jednak tak, jak z nauką budowy silnika na kursie prawa jazdy: (prawie) nikt z kursantów nie będzie tego silnika rozbierał - ale dobrze jest wiedzieć JAK to działa (i DLACZEGO zatem do diesla nie tankujemy benzyny, a poprawny poziom oleju w karterze nie pomoże na piszczenie łozyska w rozruszniku). Nam też może pomóc możliwość sprawdzenia: co za informację w te pole trzeba wpisać? ile ma być tych cyfr czy znaków? numer domu musi być czy nie?
   Ledwo nauczyliśmy się czytać i pisać pliki w XSD - a (po mojemu) przyszedł czas, żeby to porzucić. Powód jest prosty - o ile informatycy nauczyli się już pisać oprogramowanie wydające wyniki w postaci tabel, wykresów - nawet udających 3- i więcej wymiarowe (zresztą, nie mieli chyba wyboru - inaczej inżynierowie, projektanci, ekonomiści,... masowo zaczęliby rezygnować z komputerów) - to w dziedzinie wprowadzanai dancyh do programów wciąż jesteśmy na etapie lampowego ENIACa wczytującego dalekopisową taśmę z dziurkami: rządek za rządkiem. Tu dygresja: prawda jest DUŻO GORSZA - nie tylko, że współczesne języki programowania wczytują dane do programu litera za literą (owszem, składając wyrazy i liczby) - ale porażąjąca większość języków programowania także drukuje w ten sam, "szeregowy" sposób: znak za znakiem, do końca linijki, i dalej (jak w maszynie do pisania) od nowego wiersza, a potem do końca strony. Dotyczy to także nowomodnych jężyków: wszystkie te Javy, Rusty, Pythony, Ruby (nie wspominając o antycznym C czy PERLu) w standardzie ignorują istnienie dwuwymiarowych ekranów. Skąd zatem te wykresy? Ano, tworzone są mnogie "pakiety" rozszerzające standardowy język właśnie o obsługę grafiki (trzeba je oczywiście doinstalowywać, a że są pisane przez różne grupy i niekompatybilne ze sobą - programy napisane dla jednego pakietu nie działają z innym i trzeba je przepisywać przy "przesiadce"). To się nawet "osobno" nazywa - GUI, Graphical User Interface, jakby to było wciąż coś niezwykłago w XXI wieku. Dla Javy jest to AWT oraz SWT; w przypadku Ubuntu mamy KDE i GNOME,... Językami, które w swoim podstawowym standardzie "znają" wyjście na ekran, był BASIC dla mikrokomputerów (bo każdy z nich miał klawiaturę i ekran - a nie drukarkę), niedościgniony dBase, wreszcie Tcl/Tk. Ale - wracajmy do XSD
   Zatem: choć zbiór XSD ma opisywać drzewo elementów - komputer musi czytać go "liniowo" (od lewej do prawej, jak tekst telegramu) - i dla niego taki format zbioru jest wygodny. My, ludzie, możemy sobie to drzewo narysować na kartce i jednym rzutem oka ogarnąć całą strukturę. Mało tego - możemy sobie niektóre gałęzie tego drzewa "zwinąć" (żeby nie rozrosło się to poza kartkę i żeby zobaczyć las spoza drzew). Pliki XML i XSD fajnie podgląda się w (bezpłatnych) programach:

XML Notepad (Microsoft, 2007) - wyświetla drzewo, które można dowolnie zwijać i rozwijać automatycznie przewijając w osobnym oknie treść rozwiniętych części zbioru
XML Tree Editor wyświetla tylko drzewo (XML czy XSD), które można dowolnie zwijać i rozwijać - oraz poprawiać (dodawać, usuwać, zmieniać). Kwintescencję aktualnie podświetlonego elementu wyświetla w okienku podglądu: ścieżkę od korzenia drzewa, nazwę, typ, atrybuty
XML Copy Editor wygląda jak poprzedni program, ale robi wiele więcej: sprawdza zarówno poprawność budowy (well formed) jak i zgodność ze schematem (można "dopiąć" XSD wybierając zbiór dyskowy), umożliwia ukrywanie nazw elementów i atrybutów. Podobnie XmlValidator
CAM Template Editor robi jeszcze więcej - generuje przykładowy zbiór XML wg danego XSD; a także ocenia plik XSD: VAT(2)_v1.0 dostał ocenę 8.5 (w skali do 10.0 - za 42 błędy i 20+2 ostrzeżenia); umożliwia wygenerowanie modelowego XSD z pliku XML, i wiele więcej
bardziej rozbudowany QXmlEdit wyświetla tak ślicznie graficznie drzewo zbioru XSD (można powiększć i pomniejszać, wybierać szczegółowość,... i drukować do PDF albo SVG) - ale i definiowane typy i elementy (okienka przewijają się synchronicznie), porównywać pliki ze sobą, edytować (z uwzględnieniem struktury i budowy zarówno XML jak i XSD)
Free Commander ma wbudowaną przeglądarkę rozpoznającą XML i XSD jako typ "Internet" - ładnie koloruje treść i umożliwia zwijanie i rozwijanie poszczególnych elementów - wszystko w jednym oknie (drzewa jako takiego nie wyświetla, aby zobaczyć numerację wierszy trzeba wybrać "Podgląd"-"Tekst"). Podobnie DSV PHP editor czy SciTE - w nich nie ma problemu z numeracją wierszy

Jeszcze taka (smutna) uwaga na koniec - o ile istnieją (jak widać) programy potrafiące zweryfikować, czy dany zbiór XML jest zgodny ze schematem XSD - to jest to tylko sprawdzenie formalne. To tak, jakby sprawdzić, czy utwór napisany jest po polsku - TAK, tylko, że sensu w nim nie ma (Maździory witosieją w terpentynie - przykład podany przez ś.p. Stanisława nieboszczka Lema). I tak, poprawny JPK musi spełniać wiele warunków, których nie da się zapisać w XSD (np. kwota VAT w stawce 5% w polu K_16 to musi być faktycznie 5% od kwoty netto w polu K_15). Więcej - cały ten JPK musi się sumować do deklaracji VAT-7 złożonej za dany okres (której plik XML "nie widzi"). Gorzej - "wtyczka" do naszego programu VAT może sprawdzić, że format JPK się zmienił - ale zmienionego JPK już nie wygeneruje (bo dodano nowe pole i chociaż dokładnie wiadomo, jak element ma się nazywać, jakie dozwolone ma wartości, atrybuty,.. - to skąd bezduszny program ma wiedzieć JAKĄ KONKRETNIE wartość tam wstawić i skąd ją właściwie wziąć). I tak np. poprzednia (pierwsza) wersja schematu miała obowiązywać do miesięcy od lipca do grudnia 2016. Tyle, że korekty - składane po 1 stycznia 2017 - już przyjmowane są wyłacznie we wersji kolejnej (drugiej).

na górę strony

Jak się Hania nauczyła Jotpeki wypiekać

Jesteśmy już tak naładowani wiedzą teoretyczną, że jeszcze jedna informacja - i możemy rozpęknąć się jak przepompowany balon. A wszystko to po to, aby przeczytać JEDEN plik XSD (krótszy, niż ten cały opis) i wypichcić z niego JEDEN plik XML (a XML jest o wiele prostszy, niż opisujący go XSD). Zacznijmyż więc wreszcie !
Aktualnie nam miłościwie panujący plik Schemat_JPK_VAT(2)_v1-0.xsd liczy sobie nieco ponad 500 linijek i na początku (poza przedstawieniem się Oleśniewicza Jarosława i reklamy używanego przez ministerstwo płatnego programu XMLSpy) "zaciąga" (też hierarchicznie) kilka bibliotek XSD z definicjami, z których importuje wykorzystywane typy:

wbudowane typy XSD

xsd:token - tekst w jednej linijce (litery, cyfry, znaki), bez odstępoów z przodu ani tyłu ani wielokrotnych odstępów wewnątrz: nazwijmy to wyrazy

xsd:decimal - liczba "z kropką"

StrukturyDanych

etd:TIdentyfikatorOsobyNiefizycznej złożony z NIP typu etd:TNrNIP, PelnaNazwa wyrazy 1..240 znaków, ew. REGON 9 lub 14 cyfr

który "dosysa":

ElementarneTypyDanych

etd:TData - rrrr-mm-dd od 1 I 1900 do 31 XII 2030 (widać, że "tFUrcy" liczą na max. 14 lat tej ekipy skarbowej)

etd:TDataCzas - rrrr-mm-ddTgg:mm:ss

etd:TNrIdentyfikacjiPodatkowej - tekst 1..30 znaków (wszystkie "białe znaki" zamienione na odstępy)

etd:TMiejscowosc - wyrazy 1..56 znaków

etd:TKodPocztowy - wyrazy 1..8 znaków

etd:TNrLokalu - wyrazy 1..10 znaków

etd:TNrBudynku - wyrazy 1..9 znaków

etd:TUlica - wyrazy 1..65 znaków

etd:TJednAdmin - wyrazy 1..36 znaków (nazwa województwa, powiatu bądź gminy)

etd:TNrNIP - 10 cyfr, nie ma zera ani na pierwszej, ani równocześnie na drugiej i trzeciej (sic ! ): bo pierwsze trzy cyfry to kod samego urzędu, na początku nie przewidywano tam zer - potem pula się wyczerpała (np. Kraków-Krowodrza ma DWA: 257 i 677); tabela jest np. tutaj

etd:TCelZlozenia - 1 (pierwsze złożenie) albo 2 (korekta za dany okres)

etd:TNaturalny - nieujemna liczba całkowita do 14 znaków

i biorący jeszcze z dwu zbiorów:

KodyUrzedowSkarbowych (to jest CO INNEGO, niż trzycyfrowe kody USk na początku NIP !!! ): etd:TKodUS - cztery cyfry od 0202 Bolesławiec do 3271 zachodniopomorski (w Szczecinie)
KodyKrajow: etd:TKodKraju - dwie litery drukowane od AD Andora do ZW Zimbabwe (249 krajów)

KodyCechKrajów:

kck:currCode - trzyliterowy kod waluty wg ISO 4217: PLN, EUR, USD, GBP, CZK...

zaś w samym tym pliku (JPK) definiuje dodatkowo:

tns:TKodFormularza - patrz niżej (to występuje tylko raz)

tns:TNaglowek - patrz niżej (to występuje tylko raz)

tns:TKwotowy - dwa miejsca po przecinku, max. 18 razem (czyli 15 bez znaku lub 14 ze znakiem plus lub minus)

tns:TNaturalnyJPK - liczba całkowita większa od zera (do 14 znaków)

tns:TZnakowyJPK - wyrazy 1..256 znaków

tns:TAdresJPK - patrz niżej (to występuje tylko raz)

   Zauważ, jaką tytaniczną pracę musieli wykonać ministerialni informatykierzy - np. odróżnienie dopuszczalnego TNrLokalu (max 10 znaków) od TNrBudynku (tylko 9 znaków). A ile wykonali zmian ! np. na początku typ TData dopuszczał zakres do roku 3000 (teraz widocznie dostali od hierarchów sprawdzone informacje o faktycznym terminie końca świata - do 14 lat). Znowuż dla pliku KodyKrajów przechodząc od v4-0E do v4-1E zmieniono JEDNĄ linijkę: w atrybucie xmlns:etd kartoteka zmieniła się z .../2011/06/21/... na .../2016/01/25/...
   Teraz największa hucpa - informatykierzy od fiskusa wymuszają, aby wszystkie nazwy wszystkich znaczników w JPK.XML były kwalifikowane przestrzenią nazw (to jest ten prefiks z dwukropkiem). Tłumacząc z polskiego na nasze: to jest jak numer kierunkowy w telefonie. Kiedyś dzwoniąc do sąsiada wykręcało się tylko numer lokalny, do innego miasta - trzeba było przed numerem nakręcić prefix (numer kierunkowy). Teraz wszystkie numery w kraju zawierają ten kierunkowy w sobie (i dzwoniąc na sąsiednią ulicę trzeba nakręcić DZIEWIĘĆ cyfr, tyle samo, co na drugi koniec kraju). Na szczęście, prefiksy międzynarodowe (numery krajów) JESZCZE nie są obowiązkowe (choć większość posiadaczy telefonów komórkowych i tak dodaje je do numerów w swojej ksiązce telefonicznej - aby nie mieć problemu po przekroczeniu granicy). I przy weryfikacji JPK wymaga sie, aby KAŻDA nazwa znacznika była poprzedzona tym przedrostkiem opisującym przestrzeń nazw: nie tylko te zdefiniowane w "zaciąganych" bibliotekach zewnętrznych (etd:), ale i ZDEFINIOWANE "lokalnie" W TYM pliku XSD - tns:. Tym niemniej, tak niestety jest, i pominięcie prefiksu tns: powoduje odrzucenie pliku JPK.XML przez program wysyłający fiskusa. W atrybutach otwierającego znacznika JPK trzeba też "zaciągnąć" wszystkie te przestrzenie nazw (xmlns:....)
   No i voila - w linijce 143 zaczyna się definicja właściwego pliku JPK - powinien się zaczynać tak (oczywiście, bez tych komentarzy):

<?xml version="1.0" encoding="UTF-8"?>
<tns:JPK xmlns:etd="http://crd.gov.pl/xml/schematy/dziedzinowe/mf/2016/01/25/eD/DefinicjeTypy/"
         xmlns:kck="http://crd.gov.pl/xml/schematy/dziedzinowe/mf/2013/05/23/eD/KodyCECHKRAJOW/"
         xmlns:tns="http://jpk.mf.gov.pl/wzor/2016/10/26/10261/"
         xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
 <tns:Naglowek>
  <tns:KodFormularza kodSystemowy="JPK_VAT (2)" wersjaSchemy="1-0">JPK_VAT</tns:KodFormularza>
  <tns:WariantFormularza>2</tns:WariantFormularza>
  <tns:CelZlozenia>1</tns:CelZlozenia><!-- albo 2 gdy składamy korektę -->
  <tns:DataWytworzeniaJPK>rrrr-mm-ddTgg:mm:ss</tns:DataWytworzeniaJPK><!-- oraz CZAS -->
  <tns:DataOd>rrrr-mm-dd</tns:DataOd><!-- początek okresu, za jaki ten JPK: raczej od pierwszego dnia m-ca -->
  <tns:DataDo>rrrr-mm-dd</tns:DataDo><!-- koniec okresu, za jaki ten JPK -->
  <tns:DomyslnyKodWaluty>PLN</tns:DomyslnyKodWaluty><!-- LOKALNEJ waluty - a może być inna, niż PLN??? -->
  <tns:KodUrzedu>0202</tns:KodUrzedu><!-- patrz TKodUS powyżej - ale akurat to pole nie ma OPISU annotation, więć nie wiadomo, o który urząd chodzi !!! -->
 </tns:Naglowek>
 <tns:Podmiot1><!-- tu już informatykierów zaczyna zawodzić słowotwórstwo: chodzi pewnie o składającego deklarację -->
  <tns:IdentyfikatorPodmiotu>
   <etd:NIP>1234567890</etd:NIP>
   <etd:PelnaNazwa>do 240 znaków</etd:PelnaNazwa>
   etd:REGON>123456789</etd:REGON><!-- może NIE BYĆ !!! -->
  </tns:IdentyfikatorPodmiotu>
  <tns:AdresPodmiotu>
   <tns:KodKraju>PL</tns:KodKraju>
   <tns:Wojewodztwo>do 36 znaków</tns:Wojewodztwo><!-- może NIE BYĆ -->
   <tns:Powiat>do 36 znaków</tns:Powiat><!-- może NIE BYĆ -->
   <tns:Gmina>do 36 znaków</tns:Gmina><!-- może NIE BYĆ -->
   <tns:Ulica>do 65 znaków</tns:Ulica><!-- może NIE BYĆ -->
   <tns:NrDomu>do 9 znaków</tns:NrDomu><!-- może NIE BYĆ -->
   <tns:NrLokalu>do 10 znaków</tns:NrLokalu><!-- może NIE BYĆ -->
   <tns:Miejscowosc>do 56 znaków</tns:Miejscowosc>
   <tns:KodPocztowy>do 8 znaków</tns:KodPocztowy><!-- może NIE BYĆ -->
   <tns:Poczta>do 56 znaków</tns:Poczta><!-- może NIE BYĆ -->
  </tns:AdresPodmiotu>
 </tns:Podmiot1>
 <!-- ciąg dalszy nastapi... -->

: Uff ! Mamy preambułę - w której zmieniać się będą z miesiąca na miesiąc tylko daty (DataWytworzeniaJPK i raportowany okres: DataOd i DataDo). Równocześnie doszliśmy do linijki 170 pliku XSD. Teraz zaczyna się właściwas treść JPK - rejestry zakupu i sprzedaży za dany miesiąc.

na górę strony

właściwa treść - zakup i sprzedaż

   OK - najpierw trochę podyskutujmy o tym, CO właściwie ma się w tym miesięcznym JPK znaleźć. Jeżeli chodzi o sprzedaż, to oprócz faktur mamy także paragony i dokumenty będące "fakturami uproszczonymi" oraz rejestry zwrotów paragonów czy faktury wewnętrzne na przekazanie - do rejestru sprzedaży często wprowadzamy je jednym dokumentem (np. raportem miesięcznym z kasy fiskalnej). Jest to zbiorczy dowód księgowy - mówi sie, że puste powinny być: NazwaKontrahenta, AdresKontrahenta, DataSprzedaży, oczywiście NrKontrahenta (UWAGA: nie można ani pominąć tego znacznika, ani pominąć zawartość - musi być brak); jakoDowodSprzedazy zaś nalezy podać numer tego raportu. Można czy należy ująć poszczególne dokumenty składowe (Straszy się, że powinno się osobno każdy jeden, a nie razem - choć i tak w nich nie ma ani nabywcy, ani numeru NIP - więc nie wiadomo, czemu miałoby to służyć. Inni głoszą, że jedna kasa = jeden wpis). Pojawiają się interpretacje, iż faktury wystawione do paragonów dla firm (tak jest np. w marketach czy na stacjach benzynowych) mają być ujmowane w osobnych pozycjach (oczywiście, z numerami NIP nabywcy). Jak zatem wprowadzić sam raport miesięczny z kasy fiskalnej - skoro część kwot będzie zdublowana (z raportu i z faktury)? Interpretacja dyrektora Krajowej Informacji Skarbowej sygn. 0115-KDIT1-1.4012.17.2017.1.MN (5 maja 2017) zarządza, iż Z dniem 1 stycznia 2017 r. rejestr sprzedaży powinien zawierać faktury VAT (ujmowane każda z osobna) dokumentujące określone czynności sprzedaży oraz powinien obejmować obrót wynikający z dobowych raportów fiskalnych (lub alternatywnie miesięcznego raportu fiskalnego) sprzedaży pomniejszony o sprzedaż udokumentowaną fakturami. Czyli - rejestr z kasy fiskalnej pomniejszamy o ujęte w nim faktury dla podmiotów gospodarczych (jeżeli Kowalski zażyczy sobie faktury VAT nie mając NIPu - np. dla jakiejś ulgi - to NIE pomniejszamy). No, a jeżeli faktura zostanie wystawiona tylko do części paragonu (oprócz segregatorów przedsiębiorca kupił jeszcze piwo)? No, a przy sprzedaży w trybie VAT-marża? Dopisujemy kwotę VAT i netto "ręcznie" (bo na paragonie czy fakturze jej NIE MOŻE być).
   W rejestrze zakupu ujmujemy tylko dokumenty, z których faktycznie ODLICZYLIŚMY VAT (bez tych, z których mogliśmy, ale nie skorzystalismy). No, i ujmujemy w tych miesiącach, w których faktycznie korzystamy z prawa do odliczenia (mamy wszak na to 3 miesiące).
   Jest wątpliwość, czy miesięczny JPK powinien obejmować usługi świadczone poza terytorium kraju: są one ewidencjonowane wg art. 109 ust. 3a ustawy o VAT - a JPK obejmuje dane z ewidencji na podstawie art. 109 ust. 3 (oczywiście, logika podpowiada, że TAK - ale jest to ewidentna niedoróbka sejmowych osłów). Bez tego zresztą JPK nie sumowałby się do deklaracji VAT-7.
   A jeżeli w danym miesiącu składamy "zerową" deklarację VAT-7? To nie musimy wysyłać zerowego JPK_VAT: jeżeli nie powstał obowiązek podatkowy (z tytułu żadnej transakcji) - to nie mamy obowiązku.
   Oczywiście - ponieważ w nagłówku podajemy DomyslnyKodWaluty PLN - więc wszystkie faktury zagraniczne ujmujemy w przeliczeniu na PLN.
   Dobra - co tam mamy w tym JPK? Ano - dwie podobne sekcje: każda z nich niezaleznie może być albo nie. Pierwsza to rejestr sprzedaży:

 <!-- ...jesteśmy dalej wewnątrz otwartego znacznika JPK -->
 <tns:SprzedazWiersz typ="G"><!-- co we środku - poniżej, atrybut typ="G" jest wymagany --></tns:SprzedazWiersz>
       <!-- tych wierszy może być jeden lub więcej -->
 <tns:SprzedazWiersz typ="G"><!-- kolejny wiersz rejestru sprzedaży --></tns:SprzedazWiersz>
 <tns:SprzedazCtrl>
  <tns:LiczbaWierszySprzedazy>do 14 cyfr</tns:LiczbaWierszySprzedazy>
  <tns:PodatekNalezny>kwota 18.2</tns:PodatekNalezny>
 </tns:SprzedazCtrl>

druga - rejestr zakupu:

 <tns:ZakupWiersz typ="G"><!-- co we środku - poniżej, atrybut typ="G" jest wymagany --></tns:ZakupWiersz>
       <!-- tych wierszy może być jeden lub więcej -->
 <tns:ZakupWiersz typ="G"><!-- kolejny wiersz rejestru sprzedaży --></tns:ZakupWiersz>
 <tns:ZakupCtrl>
  <tns:LiczbaWierszyZakupow>do 14 cyfr</tns:LiczbaWierszyZakupow>
  <tns:PodatekNaliczony>kwota 18.2</tns:PodatekNaliczony>
 </tns:ZakupCtrl>

i po tym już tylko (obowiązkowo)

</tns:JPK>

Logiczne, prawda? Pozostaje jeszcze tylko rozszyfrować zawartość pojedynczego wiersza każdego rejestru (generalnie - po jednym wierszu na każdą fakturę sprzedaży albo zakupu; nie trzeba - jak straszono - wpisywać osobno każdej POZYCJI z faktury, ani rozbijać faktury z kwotami w różnych stawkach VAT). Jest to ciąg kolejnych pól prostych (tj. znacznik otwierający, wartość, znacznik zamykający) - dlatego nie będę wypisywał tego w XML (bo traci się czytelność), ale zrobimy sobie tabelkę. Pamiętamy, oczywiście, że nazwa każdego znacznika otwierającego i zamykającego poprzedzona jest przedrostkiem tns:. Zaczniemy od sprzedaży:
na początku jest opis kontrahenta (i tam nazwy znaczników są "mnemoniczne") -

LpSprzedazy (liczba naturalna do 14 znaków) powinien zaczynać się od 1
NrKontrahenta (tekst 1..30 znaków), bo to NIP lub UE; jak nie ma - "brak" (wystawienia faktury może zażądać osoba fizyczna nie prowadząca działalności)
NazwaKontrahenta (wyrazy 1..256 znaków)
AdresKontahenta (wyrazy 1..256 znaków)
DowodSprzedazy (wyrazy 1..256 znaków) numer faktury (lub innego dokumentu)
DataWystawienia (rrrr-mm-dd)
DataSprzedazy (rrrr-mm-dd) jeżeli podana i RÓŻNA od datyWystawienia (inaczej - puste "pisze" w objaśnieniach, ale XSD wskazuje, że pola w ogóle może nie być)

a potem są dane kwotowe z faktury (tutaj nazwy znaczników mają postać K_nn, gdzie nn jest - cóż za zbiezność nieprzypadkowa - numerem pola w deklaracji VAT-7 wzór 17). Zawartość wszystkich elementów jest typu tns:TKwotowy (liczba dziesiętna "18.2"), i każdy z tych elementów można pominąć w całości: ale albo "indywidualnie" (jeżeli jest to jedno z pól podających samo netto bez VAT - albo sam VAT bez netto: K_10, K_11, K_12, K_13, K_14, K_21, K_22, K_31, K_36, K_37, K_38, K_39), albo "parami" (oba sąsiednie pola - netto i odpowiadający mu VAT: K_15 i K_16, K_17 i K_18, K_19 i K_20, K_23 i K_24, K_25 i K_26, K_27 i K_28, K_29 i K_30, K_32 i K_33, K_34 i K_35). Łatwiej to widać, gdy mamy tą deklarację przed oczyma -

K_10 netto kraj ZW
K_11 netto poza krajem
K_12 netto - w tym usługi art. 100 ust. 1 pkt 4
K_13 netto kraj 0%
K_14 netto - w tym art. 129
K_15 netto kraj 5%
K_16 VAT kraj 5%
K_17 netto kraj 7% / 8%
K_18 VAT kraj 7% / 8%
K_19 netto kraj 22% / 23%
K_20 VAT kraj 22% / 23%
K_21 netto WDT
K_22 netto eksport towarów
K_23 netto WNT
K_24 VAT WNT
K_25 netto import towarów art. 33a
K_26 VAT import towarów art. 33a
K_27 netto import usług - oprócz art. 28b
K_28 VAT import usług - oprócz art. 28b
K_29 netto import usług art. 28b
K_30 VAT import usług art. 28b
K_31 netto odwr.obciążenie art. 17 ust. 1 pkt 7 / 8 (dostawca)
K_32 netto odwr.obciążenie art. 17 ust. 1 pkt 5 (nabywca)
K_33 VAT odwr.obciążenie art. 17 ust. 1 pkt 5 (nabywca)
K_34 netto odwr.obciążenie art. 17 ust. 1 pkt 7 / 8 (nabywca)
K_35 VAT odwr.obciążenie art. 17 ust. 1 pkt 7 /8 (nabywca)
K_36 VAT rem.likwidacyjny art. 14 ust. 5
K_37 zwrot odliczenia za kasy art. 111 ust. 6
K_38 VAT od WNT aut - z K_24, wpłacany art. 103 ust. 3 w zw. ust. 4
K_39 VAT WNT paliw wpłacany art. 103 ust. 5a i 5b

Rozumiemy, że intencją autorów specyfikacji jest, aby w elemencie SprzedazCtrl zawartość LiczbaWierszySprzedazy odpowiadała faktycznej ilości elementów SprzedazWiersz (== dokumentów w rejestrze sprzedaży), a zawartość PodatekNalezny była sumą pól VAT z tych wierszy (K_16 + K_18 + K_20 + K_24 + K_26 + K_28 + K_30 + K_33 + K_35 + K_36 + K_37 minus K_38) - ale w XSD nie da się zawrzeć tego ograniczenia (jest to napisane w komentarzu do PodatekNalezny). Sumy tej nie powinno się zaokrąglać (bo typ zawartości dopuszcza grosze) - choć w deklaracji VAT-7 oczywiście jest ona w pełnych złotych.
Wiersze rejestru zakupu mają prostszą budową (bo ta część deklaracji jest "krótsza"). Znowuż na początku opis kontrahenta -

LpZakupu (liczba naturalna do 14 znaków) powinien zaczynać się od 1
NrDostawcy (tekst 1..30 znaków), bo to NIP lub UE
NazwaDostawcy (wyrazy 1..256 znaków)
AdresDostawcy (wyrazy 1..256 znaków)
DowodZakupu (wyrazy 1..256 znaków) numer faktury (lub innego dokumentu
DataZakupu (rrrr-mm-dd) data wystawienia faktury
DataWplywu (rrrr-mm-dd) pola może nie być (np. we WNT - obowiązek podatkowy powstaje na innych zasadach), zwłaszcza gdy nie mamy tej daty w swoim programie

W dalszej części są dane kwotowe z faktury, nazwy elementów podobnie mają postać K_nn (a nn jest numerem pola deklaracji VAT-7 wz. 17), a zawartość jest typu tns:TKwotowy (18.2); podobnie można pominąć każdy z tych elementów (K_47, K_48, K_49, K_50 "indywidualnie", a K_43 i K_44 albo K_45 i K_46 tylko "parami" -

K_43 netto nabycia środków trwałych
K_44 VAT nabycia środków trwałych
K_45 netto nabycia pozostałe
K_46 VAT nabycia pozostałe
K_47 VAT korekta nabycia środkó trwałych
K_48 VAT korekta pozostałych nabyć
K_49 VAT korekta art. 89b ust. 1
K_50 VAT korekta art. 89b ust. 4

Jeżeli z faktury nie odliczamy całego VATu (współczynnik, proporcja, samochód), to kwotę netto wpisujemy w całości (z dokumentu), VAT - tyle, ile odliczyliśmy faktycznie. I tu w elemencie ZakupCtrl zawartość LiczbaWierszyZakupow powinna zliczać ilość elementów ZakupWiersz, a w PodatekNaliczony - sumę VAT z tych wierszy (K_44 + K_46 + K_47 + K_48 + K_49 + K_50). Ponieważ jednak NIE MA w JPK pola 42 deklaracji (nadwyżka VAT z poprzedniej deklaracji, więc element PodatekNaliczony będzie się różnił od pola 51 deklaracji (uwagi odnośnie zaokrąglania - jak przy podatku należnym).
Mówi się, że z kwot netto (K_43, K_45) powinny zostać wyłączone te, które dotyczą stawek 0%, ZW oraz NP.

na górę strony

Mam już JPK - i co dalej

Dobrze by go tak było sprawdzić przed wysłaniem:

poprawność formalną

czy jest zgodny ze specyfikacją i fiskus nie odmówi w ogóle jego przyjęcia (w tym także sumy w polach SprzedazCtrl i ZakupCtrl);

spójność treści - na brak mniej lub bardziej ewidentnych bzdur (które staną się podstawą do wysłania kontroli przez skarbówkę - sprawdzają już od plików za II'2017 i mają wysyłać emaile z adresu jpk.analizy@ds.mofnet.gov.pl o sprawdzenie i skorygowanie), tj. czy:

pozycje sprzedaży i zakupu sumują się do wartości wykazanych w deklaracji VAT-7 i informacji podsumowujących VAT-UE oraz VAT-27
numeracja faktur w rejestrze sprzedaży nie ma luk ani powtórzeń (ale UWAGA: firma może mieć KILKA serii numeracji, np. "łamane" przez inicjały akwizytora, albo mające inny przedrostek i inny przyrostek, a numer kolejny raz z przodu a raz z tyłu; wydaje się, że tutaj nawet sztuczna inteligencja nie pomoże - jeżeli np. faktury numerowane sa kolejnymi liczbami RZYMSKIMI), luki mogą wynikać z anulowania faktury; w rejestrze zakupu można tylko sprawdzić, czy dla tego samego dostawcy (numer NIP !) numery faktur nie powtarzają się (jedna faktura powinna - nawet, jeżeli są na niej rózne operacje - mieć tylko jeden wpis w JPK: ale być może z wieloma polami K_nn. Co też nie jest do końca prawdą: dla metody kasowej może być kolejne wpisy dla każdorazowych płatności jednej faktury). Ale uwaga - jeżeli faktury w rejestrze zakupu noszą kolejne numery - to najprawdopodobniej zamiast numeru "z dokumentu" (nadanego przez sprzedawcę) użyliśmy naszych numerów nadanych przez program księgowy (to jest błąd);
korygujący JPK_VAT "idzie" razem z deklaracją korygująca (i czy się sumują do tych samych kwot): tu dobrze wychwycić, O CO zmieniły się rejestry: jakie faktury doszły, ew. wypadły - dlaczego, a Broń Boziu - zmieniły się)
faktury ujęte są we właściwym miesiącu (zwłaszcza faktury korekty sprzedaży - uwaga na datę sprzedaży, obligatoryjną gdy różna od daty wystawienia faktury, czyli zawsze, jeżeli korekta nie jest wystawiana tego samego dnia): data wystawienia lub data transakcji po stronie sprzedaży, w rejestrze zakupu data z nastepnych miesięcy albo wcześniejsza, niż 3 miesiące (ale pamietajmy, że data wystawienia faktury może być od 30 dni PRZED aż do 15go następnego miesiąca PO dacie dostawy).
przy odwrotnym obciążeniu (WNT, import usług, towary wrażliwe i budowlanka w kraju) odliczamy podatek naliczony dopiero razem z należnym (pozycja po pozycji dla faktur sprzedaży - szukamy w rejestrze zakupu)
rachunkowo jest poprawny (w tym kwoty VAT w odpowiednich stawkach - ale UWAGA: zawsze może to być faktura-korekta - albo ta błędna, do której jest ta korekta; albo sumują się różnice zaokrągleń przy wielopozycyjnej fakturze - ale w rozsądnych kwotach, a nie 123.45 PLN przy dwulinijkowej fakturze)
numery NIP są poprawne (bo one mają cyfrę kontrolną), a numery VAT-UE przynajmniej mają strukturę właściwą dla danego kraju
numer NIP/VAT-UE odpowiada rodzajowi transakcji (wg. pola rejestru sprzedaży): w kraju - polski NIP, przy WDT, WNT, imporcie usług z UE - VAT-UE, poza UE - bez VAT-UE
numery NIP oraz VAT-UE są aktywne (trzeba mieć robota odpytującego bazę Min.Fin. albo VIES)
jacyś kontrahenci nie wystawiają stosunkowo dużo faktur korekt
niektórzy kontrahenci nie mają aby za wiele faktur nie przekraczających 15,000 PLN (podejrzenie sztucznego rozbijania transakcji celem uniknięcia limitu zapłat gotówkowych)

Broń Cię Pani Boziu skorzystać z jakiegoś dostępnego na stronach internetowych bezpłatnego mechanizmu - oznacza to wysłanie wszystkich Twoich faktur zakupu i sprzedaży do nie wiadomo kogo: szyfry, adresy, kontakty,... wszystko na stół! Jeżeli już - to nalezy szukać programu sprawdzającego, który ściągniemy sobie na swój dysk (i nie w żadnej "chmurze"), a w czasie działania nie będzie potrzebował dostępu do internetu (bo i po co? nie ma co wysyłać za naszymi plecami). PLURIX, oczywiście, dostarcza taki program - można ściągnąć plik wykonywalny (działa od Visty wzwyż, pod XP niestety nie) albo jego kod źródłowy w języku Ruby (wciśnij "Zapisz jako plik").
Kolejnym problemem może być zadanie scalenia kilku plików JPK w jeden (bo od 2017 do skarbówki wysyłamy jeden na miesiąc, w całości a nie w "plasterkach"). Problem nie jest wcale wydumany - wystąpi jeżeli mamy kilka rejestrów sprzedaży (bądź zakupu) - gdyż jesteśmy firmą wielozakładową albo każdy dział samodzielnie rozlicza swoje zakupy (albo w rejestrach z systemu magazynowo-fakturowego nie ujmujemy zakupów kosztowych, a i przekazania na reprezentację idą przez osobną ewidencję). I co wtedy? Można znaleźć w internecie (najczęściej płatne) narzędzia - oczywiście też szukamy wyłącznie "wolnostojących" a nie "chmurowatych" - ale tak na dobrą sprawę w razie nagłej potrzeby (np. dopisanie pojedynczej faktury przekazania na potrzeby własciciela) wystarczy nam Notatnik - to są zbiory tekstowe, format (już - po przeczytaniu poprzednich rozdziałów) znamy doskonale, i trzeba tylko pamiętać o zachowaniu rosnącej numeracji kolejnych pozycji (LpSprzedazy lub LpZakupu) i uaktualnieniu podsumowań w elementach SprzedazCtrl lub ZakupCtrl (LiczbaWierszy... i Podatek...).

na górę strony

Farewell, JPK

   Nie - to nie my żegnamy się z JPK: to on żegna się z nami (mam nadzieję - na zawsze) i odjeżdża: do skarbówki. Od razu uwaga: Jotpek, jak już wiemy, ma pole CelZlozenia: jeżeli mamy korektę deklaracji VAT-7, powinniśmy zatem odesłać także Jotpek z kodem 2: podobno odrzuca, natomiast przechodzi, gdy składamy ponownie z kodem 1 (oczywiście, cały nowy - a nie tylko różnice). Jeżeli robimy korektę deklaracji VAT-7 za 2016 (wzór 16), to - mimo, iż wtedy obowiązywał JPK_VAT(1), to musimy krektę wysłać w formacie JPK_VAT(2) - bo starego formatu już nam bramka w skarbówce nie przyjmie.
   Instrukcja jest prosta: podobnie, jak przy deklaracjach elektronicznych - trzeba go podpisać (kwalifikowanym podpisem, oczywiście "elekstronicznym" - albo przez e-PUAP; n.b. pamiętajmy że podpis jest na osobę fizyczną i jeżeli nie jest to właściciel, to trzeba złożyć w skarbówce pełnomocnictwo UPL-1) i wysłać przez bramkę internetową po czym pobrać UPO (urzędowe potwierdzenie odbioru). Niby można było też nagrać i wysłać na informatycznym nośniku informacji (czytaj - płycie CD albo DVD) - o ile jest oznakowany, przystosowany, dostosowany i zapewnia... Kto wie, czy nie jest to sposób, jeżeli NIE UDA się wysłać przez tą bramkę (bo za niewysłanie jest kara porządkowa do 2,800 PLN w 2016; grzywna za utrudnianie chyba nie jest tu do nałożenia). A aplikacja ministerialna często odrzuca plik XML nie wskazując przyczyny błędu. Niestety, teraz już JPK_VAT tylko drogą elektroniczną, "fizyczna" pozostała tylko dla pozostałych struktur JPK na żądanie skarbówki. Mówi się także o grzywnach z art. 80 Kodeksu Karnego Skarbowego: 3,000,000 PLN za niezłożenie i 6,000,000 PLN za nieprawdziwe dane!
   Potem jest już tylko śmieszniej: kompresujemy ZIPem, dzielimy na kawałki po 60MB, każdy z osobna szyfrujemy (AES klucz 256 bitowy). Tworzymy "zbiorówkę" zawierającą nie tylko informację o pierwotnym pliku i jego "plasterkach", ale także klucz, którym je zaszyfrowaliśmy - zaszyfrowany z kolei kluczem publicznym RSA ministerium finansów.
To tą "zbiorówkę" wysyłamy na bramkę skarbówki - i w odpowiedzi dostajemy adresy internetowe do chmury Azure MiŚia, gdzie mamy po kolei wysyłac poszczególne "plasterki"; a na koniec ze chmury otrzymujemy numer, pod którym pobieramy z bramki ministerium owo UPO. O bezpieczeństwie tego wszystkiego nie będę się wypowiadał...
   Do wykonania tego wszystkiego skarbówka stworzyła specjalny program do bezpłatnego pobrania (jest dla Windy i dla Pingwina; zaleca się pobierać wersję 32-bitową nawet dla Windy 64-bitowej: chyba, że mamy 64-bitowy program do podpisu elektronicznego - nie jest to częste: 64-bitowy nie rozpoznaje 32-bitowej biblioteki podpisu elektronicznego więc wysłać się nie da). Kiedyś można było korzystać z testowej bramki w ministerstwie (do wysłania JPK "na próbę") - aktualna wersja ministerialnej aplikacji tego już nie ma (można wysłać JPK tylko "na serio").
   Korzystaliśmy także z bezpłatnej wersji programu Tax Machine - umożliwia on wczytanie gotowego pliku XML a potem jego podpisanie i wysyłkę, oraz pobranie UPO (działa na 64-bitowej Windzie 7 i na 32-bitowej Viście).

	PLURIX (od 26V1983) Jerzy Klaczak Biura Rachunkowe(od 1992) św. Min.Fin. 3374/97 kancelaria Doradcy Podatkowego (ubezpieczenie, licencja nr 4983) Pn..Pt: 8:30..14:45
	tel: (32)203 64 95 tel: (501)950 390
	> Nowości > eDokumenty
Przeprowadziliśmy się