e-Deklaracje i JPK w enova365: status Do potwierdzenia odbioru i luka, której nikt nie liczy

Dwa przyciski i jedno założenie

W enova365 złożenie e-deklaracji to dwie osobne akcje. Wyślij wysyła podpisany plik na bramkę Ministerstwa Finansów. Potwierdź służy do tego, żeby później zapytać, co się z nim stało. Program ma nawet wariant łączony, Wyślij, potwierdź — i to wiele mówi. Producent wie, że ludzie naciskają pierwszy przycisk i zapominają o drugim.

Wczoraj pisałem o kontroli braku UPO, którą biuro powinno robić po każdym terminie — o luce między wysłano a złożono i o tym, że dowodem jest dopiero status 200 i UPO. Tamten tekst nie dotyczył żadnego konkretnego programu. Ten jest o enova365, a tu lukę widać gorzej niż w większości programów. Jest rozbita na dwa rejestry. Ma dwie różne nazwy. A w biurze, które prowadzi kilkadziesiąt baz klientów, rozkłada się jeszcze na każdą z nich.

Statusy, tak jak nazywa je enova365

e-Deklaracja w enova365 (CIT, PIT i inne formularze obsługiwane przez moduł e-Deklaracje) przechodzi przez kilka krótkich, jednoznacznie nazwanych statusów:

• (puste) — deklaracja przeliczona, zatwierdzona i zapisana, ale jeszcze niewygenerowana jako e-deklaracja;
• Do podpisania — wygenerowana, czeka na podpis (certyfikatem kwalifikowanym albo podpisem nieweryfikowanym z kwotą przychodu, tam gdzie formularz na to pozwala);
• Do wysłania — podpisana, niewysłana;
• Do potwierdzenia odbioru — wysłana, odpowiedź nieodebrana;
• Potwierdzona — weryfikacja w Ministerstwie wypadła pozytywnie, a numer UPO pojawia się na wydruku deklaracji (pole 2, Nr dokumentu).

Pliki JPK obsługuje się w innym miejscu. Generuje się je z listy Ewidencja dokumentów, filtrowanej po okresie i rodzaju JPK, i mają własne stany: nieokreślona dla świeżego pliku, Przetwarzanie po wysłaniu, Pobrano UPO po odebraniu potwierdzenia.

Na pierwszej liście liczy się status Do potwierdzenia odbioru. Na drugiej — Przetwarzanie. Znaczą to samo: enova365 jeszcze nie wie. To nie jest werdykt Ministerstwa. To tylko informacja, że nikt nie zapytał. Deklaracja może tam stać już przyjęta, wciąż w przetwarzaniu albo odrzucona z kodem 401, bo plik nie przeszedł walidacji schematu. Dopóki ktoś nie uruchomi Potwierdź, wszystkie trzy wyglądają na liście identycznie.

Dlaczego w enova365 luka jest większa, niż wygląda

Trzy cechy typowej konfiguracji enova365 sprawiają, że tę lukę łatwo przeoczyć.

1. Dwa rejestry, dwa słowniki. VAT wychodzi jako JPK_V7 z Ewidencji dokumentów. Deklaracje podatku dochodowego — przez e-Deklaracje. Inne listy, inne nazwy statusów, często inne osoby. Biuro, które wyrobiło sobie nawyk przy jednej liście (zwykle JPK, bo jest co miesiąc i o tym terminie pamiętają wszyscy), sprawdza połowę wysyłek i jest pewne, że sprawdza wszystkie.

2. Jedna baza na klienta. Biura rachunkowe na enova365 zwykle trzymają każdego klienta w osobnej bazie i korzystają z dodatku Praca na wielu bazach, żeby generować i wysyłać e-deklaracje hurtowo. Około 25. to naprawdę oszczędza czas. Tylko że hurtowa wysyłka nie oznacza hurtowego potwierdzania. Przeglądanie po terminie pięćdziesięciu baz, jednej po drugiej, to dokładnie ta robota, którą się odkłada, a potem pomija. Wysyłkę da się zrobić hurtem. Sprawdzanie — nie, dopóki go nie zautomatyzujecie.

3. Bramka testowa. enova365 pozwala wybrać bramkę testową albo oficjalną. Plik wysłany na testową przechodzi cały proces, a dane nigdy nie trafiają do Ministerstwa. Zdarza się to rzadko. Jeśli już, to zwykle po zmianie konfiguracji albo przy nowej bazie klienta sklonowanej z testowej. Nie trzeba się tym martwić codziennie. Trzeba to sprawdzić raz dla każdej bazy, zapisać wynik i powtórzyć po każdej migracji. To jedyna awaria, którą lista statusów potrafi ukryć całkowicie.

Jak to policzyć w enova365

Kontrola wygląda tak samo jak we wczorajszym tekście: jeden wiersz na wysyłkę i jedna liczba, która trzy dni robocze po 25. ma wynosić zero. W enova365 wiersze pochodzą z dwóch miejsc:

Źródło	Stany „niezałatwione”	Stan „załatwione”
e-Deklaracje	Do podpisania, Do wysłania, Do potwierdzenia odbioru	Potwierdzona
JPK (Ewidencja dokumentów)	nieokreślona, Przetwarzanie	Pobrano UPO

Dla każdej bazy klienta: wszystkie deklaracje i pliki JPK za okres, ich status i ustawienie bramki. Najważniejsza liczba to wszystko, co wysłano, a co nie jest w stanie „załatwione”. Do podpisania i Do wysłania idą do osobnej kolumny. To nie jest problem z UPO. To plik, który w ogóle nie wyszedł. Sytuacja gorsza, choć dużo łatwiej ją wyłapać — o ile ktoś w ogóle zajrzy.

Biuro z czterdziestoma klientami ma około stu takich wierszy miesięcznie. Męczy nie liczba wierszy, tylko liczba baz, które trzeba otworzyć.

Jak wyciągnąć dane bez otwierania pięćdziesięciu baz

Tu zaczynają się techniczne szczegóły samej enova365. Realne sposoby są trzy — te same, które opisałem w tekście o danych KSeF i JPK w enova365:

• WebAPI, baza po bazie. Konto serwisowe tylko do odczytu w każdej bazie klienta i skrypt, który pobiera statusy deklaracji i JPK za okres. Czy Wasza wersja udostępnia przez API wszystkie pola statusów w czytelnej postaci? To trzeba sprawdzić na własnej instalacji, zanim komukolwiek obiecacie dashboard. Co przetestować najpierw, opisuje przewodnik programisty po WebAPI. Konto ma móc czytać i nic więcej — co w enova365 naprawdę znaczy „tylko do odczytu”, wyjaśnia tekst o koncie serwisowym.
• Eksport z harmonogramu. Jeśli droga przez API jest niewygodna, zadanie w Harmonogramie zadań może cyklicznie eksportować listy do pliku. Mniej eleganckie, ale działa na każdej wersji. Haczyk jest ten sam co przy każdym zadaniu cyklicznym: zadanie, które po cichu przestało tworzyć pliki, wygląda dokładnie tak jak miesiąc bez problemów. Dlatego eksport musi osobno meldować, że działa.
• Ktoś otwiera każdą bazę. Wariant podstawowy. I właśnie on sypie się w okolicach 25.

Niezależnie od wybranego sposobu na każdym wierszu musi być numer referencyjny i nazwa bazy. Bez nazwy bazy wiersza z problemem nie przypiszecie do klienta.

Co robi tu agent

Granica jest ta sama co wczoraj, z jednym niuansem enova365: Potwierdź to nie jest złożenie dokumentu. Ta akcja pyta bramkę o coś, co już wysłano, i zapisuje odpowiedź. Dlatego agent może ją bezpiecznie uruchamiać według harmonogramu we wszystkich bazach. To zapis w enova365, poziom 3 według poziomów uprawnień z tekstu o odpowiedzialności, ale nie wysyła do urzędu niczego nowego.

Agent może więc:

• uruchamiać Potwierdź dla wszystkiego, co od ponad 24 godzin stoi w Do potwierdzenia odbioru albo Przetwarzanie, we wszystkich bazach;
• zgłaszać każde odrzucenie zwykłym językiem, z bazą, klientem, formularzem i okresem;
• dzień przed terminem wyłapywać pozycje w Do wysłania, póki jest jeszcze czas;
• raz w miesiącu i po każdej migracji sprawdzać ustawienie bramki w każdej bazie;
• podawać jedną liczbę, na którą patrzy właściciel biura: ile par klient–miesiąc nie ma UPO.

Nie podpisuje i nie wysyła ponownie. Podpis w enova365 to z definicji czynność człowieka — albo certyfikat kwalifikowany, albo podpis z kwotą przychodu przypisany do konkretnego podatnika — a ponowna wysyłka to nowe złożenie. Zamiast tego przekazuje człowiekowi gotową sprawę: co poszło, co wróciło, co jest prawdopodobnie nie tak, ile dni zostało.

Gdzie to pasuje

Jeśli prowadzicie biuro z klientami na kilku systemach ERP, część tej kontroli dotyczącą enova365 zwykle najłatwiej zautomatyzować: statusy są jawne, a dane leżą w porządnej bazie, a nie w folderze plików XML. To też dobry pierwszy projekt na enova365, z tego samego powodu co wczoraj: prawie wyłącznie odczyt, o tym, co jest „poprawne”, zdecydowało już Ministerstwo, a liczbę macie pierwszego dnia. Jak podchodzę do takich wdrożeń, opisuję na stronach integracja enova365 z AI i agenci AI dla firm.

Chcecie wiedzieć, ile zeszłomiesięcznych wysyłek w Waszych bazach enova365 wciąż czeka na potwierdzenie? Odezwijcie się. Zwykle wystarczy jedno sprawdzenie w trybie tylko do odczytu.