Program Płatnik rzadko działa w oderwaniu od pozostałych systemów firmowych — najczęściej współpracuje z programem kadrowo-płacowym, z którego eksportowane są dane do rozliczeń z ZUS.

Objaw

Zgłoszenia dotyczą błędów przy eksporcie danych z programu kadrowo-płacowego (Gratyfikant, WAPRO Gang i inne) do programu Płatnik, niezgodności danych między systemami, a także konfiguracji tej współpracy przy pierwszym wdrożeniu.

Możliwe przyczyny

Niezgodny format eksportowanych danych między dwoma systemami.
Nieaktualne wersje programów, powodujące niekompatybilność formatu wymiany danych.
Błędy w danych źródłowych w systemie kadrowo-płacowym, przenoszone automatycznie do eksportu.
Brak skonfigurowanej ścieżki eksportu przy pierwszym uruchomieniu współpracy między programami.

Co robimy

Diagnoza obejmuje sprawdzenie zgodności wersji obu programów oraz poprawności danych w systemie kadrowo-płacowym przed eksportem. Konfigurowana jest ścieżka i format wymiany danych między systemami, a przy błędach wykonywana jest korekta ustawień eksportu albo aktualizacja jednego lub obu programów do zgodnych wersji. Po konfiguracji wykonywany jest test eksportu na przykładowych danych przed pierwszym rzeczywistym rozliczeniem.

Ile to trwa

Konfiguracja współpracy między systemami to zwykle sprawa jednego dnia pracy, diagnoza pojedynczego błędu bywa szybsza.

Co można zrobić samemu, zanim przyjedzie serwisant

Warto sprawdzić, jakie wersje obu programów są obecnie zainstalowane, oraz zanotować dokładny komunikat błędu pojawiający się przy eksporcie danych.

Czego nie robić: nie warto ręcznie poprawiać wyeksportowanego pliku w celu naprawienia błędu — poprawka powinna nastąpić u źródła danych, inaczej problem powtórzy się przy kolejnym rozliczeniu.

Warunki

Konfiguracja i wsparcie przy integracji systemów wyceniane są indywidualnie, zależnie od zakresu potrzebnej pracy.

Warianty problemów z importem dokumentów

Problemy z przesyłaniem informacji między systemami kadrowymi a aplikacją Płatnik przyjmują różne formy. Zależą one od tego, na którym etapie przetwarzania pliku wystąpił błąd oraz jaki jest jego charakter. Identyfikacja konkretnego wariantu usterki pozwala na szybsze ustalenie przyczyny.

Pierwszym wariantem jest odrzucenie pliku ze względu na błąd struktury dokumentu elektronicznego (na przykład pliku w formacie XML lub w starszym standardzie KEDU). Taka sytuacja ma miejsce, gdy system kadrowy generuje plik z układem znaczników, którego używana wersja Płatnika nie potrafi odczytać. Najczęściej jest to wynik zmiany przepisów, po której jeden z programów został zaktualizowany, a drugi nie. Aplikacja Płatnik wyświetla wtedy komunikat o błędzie parsowania (czyli błędu analizy składniowej pliku) lub o niezgodności ze schematem ustrukturyzowanym.

Drugi przypadek to błędy sum kontrolnych i weryfikacji numerów identyfikacyjnych (takich jak PESEL, NIP czy REGON). System kadrowy może pozwolić na wprowadzenie danych z literówką, jednak Płatnik weryfikuje ich poprawność na podstawie matematycznych algorytmów sprawdzających. Jeśli cyfra kontrolna w numerze PESEL pracownika nie zgadza się z resztą cyfr, plik importowy zostanie przetworzony, ale dany ubezpieczony i jego dokumenty zostaną oznaczone w rejestrze ZUS jako błędne.

Kolejnym wariantem są problemy z kodowaniem znaków. Objawiają się one tym, że polskie litery (takie jak ą, ś, ć) są zastępowane przez niezrozumiałe symbole lub pytajniki. Zjawisko to występuje, gdy system eksportujący używa innego zestawu znaków (na przykład ogólnoświatowego standardu UTF-8) niż oczekuje tego aplikacja docelowa (najczęściej lokalnego standardu Windows-1250). Błędne kodowanie powoduje nie tylko nieczytelność nazwisk, ale często blokuje możliwość weryfikacji tożsamości pracownika w elektronicznych rejestrach urzędu.

Zdarzają się również sytuacje, w których Płatnik importuje dokumenty bez błędów formalnych, ale tworzy zduplikowane kartoteki ubezpieczonych. Dzieje się tak, gdy parametry identyfikacyjne wyeksportowane z programu kadrowego różnią się w minimalnym stopniu (na przykład poprzez dodatkową spację w nazwisku dwuczłonowym) od danych zapisanych już w bazie programu Płatnik. Aplikacja traktuje taki rekord jako nową, nierozpoznaną wcześniej osobę.

Kiedy problem nie leży w integracji

Nie każdy problem ujawniający się podczas importu dokumentów oznacza błąd w systemie kadrowym lub usterkę w mechanizmie eksportu. Zdarza się, że wygenerowany plik z danymi jest całkowicie poprawny, a źródło problemu znajduje się bezpośrednio w aplikacji Płatnik lub środowisku systemu operacyjnego.

Jedną z takich sytuacji jest brak pobranych aktualnych komponentów programu i słowników z serwerów Zakładu Ubezpieczeń Społecznych. Płatnik weryfikuje importowane dane z własną, zapisaną na dysku bazą reguł. Jeśli baza ta nie została uaktualniona po zmianie przepisów, aplikacja odrzuci prawidłowo naliczone składki lub nowe kody tytułu ubezpieczenia, uznając je za nieznane i błędne. Diagnostyka tego przypadku polega na wymuszeniu ręcznej aktualizacji danych słownikowych w Płatniku i ponownej próbie zaimportowania tego samego pliku wymiany.

Innym zjawiskiem są błędy wynikające z uszkodzenia bazy danych samego programu Płatnik. Jeśli plik bazy (zazwyczaj w formacie Microsoft Access - z rozszerzeniem pliku MDB, lub serwerowa baza Microsoft SQL Server) uległ fragmentacji podczas awarii zasilania lub zawiera niespójne wewnętrznie tabele, import nowych dokumentów kończy się komunikatem o błędzie krytycznym bazy danych, zamknięciem aplikacji, lub zawieszeniem procesu przetwarzania. Błąd ten nie ma związku z zawartością przesyłanego pliku i będzie występował niezależnie od tego, jakie oprogramowanie kadrowe wygenerowało eksport.

Błędy podczas prób samodzielnej naprawy

Kiedy wymiana danych przestaje funkcjonować, na przykład w okresie zbliżającego się terminu wysyłki deklaracji miesięcznych, często podejmowane są próby doraźnego rozwiązania problemu. Niektóre z nich komplikują sytuację infrastruktury informatycznej i wydłużają czas potrzebny na przywrócenie właściwej pracy środowiska.

Jednym z najczęstszych błędów jest ręczna ingerencja użytkownika w zawartość plików wymiany (na przykład edycja pliku wyjściowego XML w standardowym Notatniku systemu Windows). Modyfikacja kwot czy kodów bezpośrednio w pliku może pozwolić na zaimportowanie dokumentu w danym miesiącu, ale omija spójność danych. Rozliczenie wysłane z Płatnika nie będzie zgadzało się z danymi historycznymi zapisanymi w programie kadrowo-płacowym. Z upływem czasu taka praktyka prowadzi do trudnych do wykrycia rozbieżności przy rocznych podsumowaniach podatkowych. Rozwiązanie zawsze powinno opierać się na usunięciu błędu w tym systemie, w którym pierwotnie wprowadza się dane.

Kolejnym nietrafionym działaniem jest próba celowego powrotu do starszej wersji systemu kadrowego lub oprogramowania Płatnik (operacja określana w branży IT jako downgrade). O ile w standardowym oprogramowaniu biurowym przywrócenie starszej wersji bywa czasami pomocne, o tyle w przypadku programów rozliczających finanse z instytucjami jest to niezalecane. Struktury wewnętrznych baz danych podlegają trwałym modyfikacjom podczas każdej aktualizacji oprogramowania. Uruchomienie starszej wersji programu na zaktualizowanej już bazie często kończy się całkowitym brakiem dostępu do danych firmy z powodu niezgodności struktury tabel.

Złym rozwiązaniem jest również tymczasowe rezygnowanie z automatycznego eksportu i ręczne przepisywanie danych do Płatnika z kartki papieru dla całego personelu. Oprócz dużego ryzyka pomyłek związanych z ręcznym wprowadzaniem (tak zwanego błędu czeskiego przy przepisywaniu cyfr), powoduje to często rozsynchronizowanie wewnętrznych identyfikatorów ukrytych w bazie danych między oboma systemami. Gdy mechanizm cyfrowego eksportu zostanie naprawiony, kolejne przesyłane dokumenty z systemu płacowego mogą nie powiązać się w Płatniku z historią, która została wprowadzona ręcznie przez operatora.

Kwestie techniczne środowiska informatycznego

Wymiana informacji cyfrowych między oddzielnymi programami jest silnie uzależniona od stabilności środowiska używanego systemu operacyjnego. Czasami w pełni poprawna konfiguracja samej aplikacji bywa niewystarczająca z powodu blokad narzuconych na poziomie uprawnień systemu Windows lub ograniczeń sieci lokalnej przedsiębiorstwa.

Najbardziej podstawowym wymaganiem systemowym jest odpowiednia konfiguracja uprawnień konta użytkownika. Program kadrowy w momencie uruchomienia eksportu tworzy plik w określonej lokalizacji na dysku twardym (na przykład w specjalnym folderze dokumentów). Użytkownik zalogowany do programu musi posiadać pełne prawa zapisu do tego konkretnego folderu, a aplikacja Płatnik musi z kolei dysponować prawami do odczytu z tej samej ścieżki. Brak nadanych praw dostępu (wynikający z rygorystycznych polis bezpieczeństwa wprowadzonych w firmie) skutkuje zazwyczaj ogólnym komunikatem o braku możliwości utworzenia pliku na dysku docelowym.

Kolejnym elementem środowiska mającym bezpośredni wpływ na sprawną współpracę programów jest działające w tle oprogramowanie antywirusowe. Pakiety ochronne stale weryfikują operacje wejścia i wyjścia na dyskach twardych. Program antywirusowy potrafi zablokować plik generowany automatycznie przez system kadrowy, ponieważ interpretuje masową operację zapisu pliku o nieznanej strukturze jako działanie podejrzane. Skutkuje to umieszczeniem pliku eksportu w bezpiecznej kwarantannie, zanim program docelowy zdąży go pobrać do przetworzenia. Standardowym postępowaniem informatycznym w tej sytuacji jest dodanie specyficznych rozszerzeń plików (najczęściej KDU, XML) oraz używanych katalogów roboczych do tak zwanej listy wyjątków programu zabezpieczającego.

W biurach rachunkowych lub firmach, w których program kadrowy i oprogramowanie Płatnik zainstalowane są na różnych komputerach zlokalizowanych w jednej sieci lokalnej, pojawia się bezwzględna konieczność skonfigurowania odpowiedniego udostępniania katalogów sieciowych. Ustawienia te są niezwykle podatne na wszelkie zmiany adresacji sieciowej punktów dostępu oraz regularne zmiany haseł dla poszczególnych profili użytkowników. Chwilowa utrata uprawnień do nawiązania połączenia z dyskiem sieciowym oznacza natychmiastowe unieruchomienie procedury przesyłania deklaracji ubezpieczeniowych.

Proces poprawnej integracji systemów w środowisku IT

Rozpoczęcie bezbłędnej wymiany danych pomiędzy nowo zainstalowanym programem kadrowo-płacowym a istniejącą instalacją aplikacji Płatnik wymaga metodycznego przygotowania parametrów na poziomie obu programów. Zmiany te dzieli się na etapy, które weryfikuje się pod kątem kompatybilności technologicznej przed właściwą produkcją dokumentów.

Na początkowym etapie weryfikowane są podstawowe parametry identyfikujące płatnika składek w obydwu środowiskach aplikacyjnych. Ważne numery ewidencyjne, takie jak NIP, REGON, a przy działalności jednoosobowej również PESEL przedsiębiorcy, wymagają w stu procentach identycznego formatu zapisu. Jakikolwiek brak zgodności (nawet obecność spacji zamiast jej braku) spowoduje automatyczne odrzucenie zlecenia importu, gdyż mechanizm wewnętrzny Płatnika zinterpretuje plik zewnętrzny jako dane innej osoby prawnej. Równolegle sprawdzeniu podlegają dokładne ścieżki dostępowe do bazodanowych instancji serwerowych oraz docelowych folderów przesyłania plików.

Dalszym krokiem jest utworzenie mapowania (czyli wirtualnego połączenia pojęć) pomiędzy składnikami wynagrodzeń w systemie kadrowym, a sztywnymi kodami tytułu ubezpieczenia obsługiwanymi przez elektroniczny system instytucji państwowej. Systemy płacowe korzystają często ze zmiennych nazw wewnętrznych dla różnorodnych dodatków, potrąceń i premii regulaminowych. Moduły integrujące umożliwiają precyzyjne przyporządkowanie każdego lokalnego elementu do właściwej, odgórnie ustalonej przez ZUS kategorii ze słownika państwowego. Brak pełnego lub poprawnego mapowania stanowi główną i najczęstszą przyczynę rozbieżności w kwotach podsumowujących raporty.

Ostatnim punktem prac integracyjnych jest wymuszony eksport techniczny. Jest on wykonywany wyłącznie na danych testowych, korzystając ze zarchiwizowanych miesięcy lub wydzielonego zbioru informacji, w celu zabezpieczenia bieżących operacji. Przesłane dokumenty ulegają wtedy sprawdzeniu w module weryfikacyjnym Płatnika. Odnotowane ostrzeżenia pełnią rolę dokumentacji dla technika wsparcia, pomagając odszukać brakujące parametry w systemie kadrowym. Konfigurację uznaje się za prawidłowo zakończoną w momencie wygenerowania pełnego raportu pozbawionego alertów o błędach w strukturze lub składni przetwarzanego piku.

Dodatkowe pytania klientów

Czy wdrożenie nowszego oprogramowania kadrowego wymaga od firmy zakładania świeżej bazy w programie Płatnik?

Zmiana silnika oprogramowania kadrowo-płacowego (na przykład z rozwiązania desktopowego na platformę chmurową) nie narzuca obowiązku archiwizacji i tworzenia nowej bazy danych w instalacji Płatnika. Odpowiednio skonfigurowany nowy system wymiany danych przekaże deklaracje do funkcjonującej już bazy centralnej. Kompletna historia zatrudnienia oraz wprowadzonych dokumentów pracowników pozostaje nienaruszona na dysku. Podstawowym wymaganiem informatycznym pozostaje precyzyjne dostosowanie danych ewidencyjnych firmy w nowym systemie, aby zapewnić ciągłość powiązań rekordów bazy danych z historią wcześniejszą.

Dlaczego aplikacja urzędowa odrzuca nagle pliki, które jeszcze w poprzednim cyklu rozliczeniowym działały poprawnie?

Takie zachowanie oprogramowania zazwyczaj ma związek z aktualizacjami prawa, wchodzącymi w życie z początkiem nowego miesiąca lub roku podatkowego. Instytucje administracji państwowej modyfikują elektroniczne schematy przesyłu informacji (tak zwane schemy XML), regulujące dopuszczalne formaty i proporcje kwot. Płatnik zmusza wtedy użytkownika do pobrania najświeższej wersji słowników (metryki), aktualizując weryfikator. Z kolei producenci oprogramowania kadrowego mogą potrzebować dodatkowego czasu na udostępnienie odpowiedniej poprawki do swojego narzędzia. W okresie przejściowym stary plik generowany w systemie kadrowym spotyka się ze zaktualizowanym weryfikatorem Płatnika, co owocuje odrzuceniem importowanych paczek dokumentów.

Czy istnieje opcja w pełni automatycznego przesyłu bez interfejsu wizualnego Płatnika?

W dobie cyfryzacji wiele systemów klasy ERP działa na procesach przeprowadzanych automatycznie w tle. W przypadku programu Płatnik środowisko to w dalszym ciągu operuje na formie odrębnej aplikacji obsługiwanej przez człowieka. Eksport danych z części kadrowej podlega zazwyczaj głębokiej automatyzacji (pliki są tworzone o ustalonej porze lub kopiowane w odpowiednie ścieżki za pomocą skryptów wymiany), niemniej autoryzacja wysyłki wymaga ingerencji użytkownika. Zgodnie z procedurami zabezpieczeń, osoba rozliczająca musi samodzielnie uruchomić interfejs programu Płatnik w celu autoryzacji sesji podpisem kryptograficznym. System Płatnik w wersji stacjonarnej nie oferuje modułu bezpośredniej, bezobsługowej wysyłki deklaracji na bramki rządowe w pełni w tle.

Co należy zrobić, kiedy system kadrowy pracuje w środowisku 32-bitowym, a główny komputer z Płatnikiem korzysta z instalacji 64-bitowej?

Z punktu widzenia podstawowej wymiany opartej o pliki tekstowe, różnice w środowiskach bitowych procesora i systemu Windows pozostają niezauważalne dla procesu. Dokumenty ustrukturyzowane w formacie e-XML zapisane na fizycznym nośniku są standardem niezależnym, który w jednakowy sposób przetwarza zarówno procesor operujący na kodzie 32-bitowym, jak i układ 64-bitowy. Problem niezgodności bitowej występuje tylko przy instalacjach korzystających z zaawansowanych sterowników pośrednich (na przykład mechanizmów połączeniowych ODBC) do bezpośredniego wpisywania danych w strukturę bazy SQL. Przy takiej architekturze wymiany proces integracyjny wymaga zainstalowania dokładnie dopasowanych mostów komunikacyjnych łączących rozbieżne biblioteki systemowe oprogramowania.

Podsumowanie prawidłowego działania środowiska eksportu

Skuteczna wymiana paczek informacyjnych pomiędzy oprogramowaniem Płatnik a zróżnicowanymi systemami zarządzania kadrami wymaga bezbłędnej konfiguracji po stronie środowiska informatycznego przedsiębiorstwa. Utrzymanie płynności przetwarzania opiera się na restrykcyjnej zgodności parametrów dostępowych, regularnym instalowaniu najnowszych aktualizacji struktur bazy dla obu narzędzi oraz poprawnym mapowaniu elementów technicznych. Rozwiązywanie przestojów polega na sprawnej synchronizacji tych wskaźników przez administratora systemu, bez uciekania się do doraźnych metod ingerowania w pojedyncze kody dokumentów źródłowych.

22 378 48 09

Współpraca programu Płatnik z systemami kadrowo-płacowymi