- Kierowca dostępny teraz
- całą dobę, 7 dni w tygodniu
- Dojazd do 1 h w promieniu 40 km
- Diagnoza laptopa 0 zł
Wymiana komputera używanego do rozliczeń z ZUS wymaga przeniesienia nie tylko samego programu, ale przede wszystkim bazy danych z historią wszystkich dotychczasowych dokumentów.
Firma wymienia komputer, na którym dotychczas pracował program Płatnik, i chce zachować pełną historię rozliczeń — zgłoszonych dokumentów, danych płatnika i pracowników — bez zaczynania od zera na nowym stanowisku.
Typowe powody migracji: awaria dotychczasowego komputera, planowa wymiana sprzętu na nowszy, albo przeniesienie stanowiska księgowego do innego pomieszczenia lub oddziału firmy.
Migracja obejmuje instalację programu na nowym komputerze oraz przeniesienie bazy danych zawierającej pełną historię dokumentów. Jeśli firma korzysta z podpisu elektronicznego, przenoszony jest też certyfikat wraz z jego konfiguracją. Po migracji wykonywany jest test poprawności — sprawdzenie, czy historia dokumentów jest kompletna i czy program prawidłowo łączy się z systemami ZUS z nowego stanowiska.
Migracja na nowy komputer to zwykle sprawa jednej wizyty lub sesji zdalnej, w zależności od wielkości bazy danych do przeniesienia.
Warto nie odinstalowywać programu ze starego komputera przed potwierdzeniem, że migracja na nowy zakończyła się powodzeniem — to zabezpieczenie na wypadek, gdyby coś wymagało ponownego sprawdzenia.
Czego nie robić: nie warto samodzielnie kopiować plików bazy danych „na oko" bez wiedzy, gdzie dokładnie program przechowuje swoje dane — łatwo przy tym pominąć część istotnych plików konfiguracyjnych.
Migracja wyceniana jest indywidualnie. Dane firmowe i kadrowe traktowane są z zachowaniem pełnej poufności przez cały proces przenoszenia.
Proces przenoszenia danych zależy w głównej mierze od formatu bazy, w jakim program przechowuje informacje o ubezpieczonych i dokumentach. Występują dwa podstawowe rozwiązania techniczne.
Pierwszym formatem jest baza danych Microsoft Access. Jest to rozwiązanie spotykane najczęściej w mniejszych firmach, obsługujących ograniczoną liczbę pracowników. Baza w tym formacie ma postać pojedynczego pliku z rozszerzeniem MDB. Przeniesienie takiej bazy polega na zlokalizowaniu tego pliku na starym dysku twardym i skopiowaniu go w bezpieczne miejsce na nowym stanowisku. Należy jednak pamiętać, że plik bazy zabezpieczony jest hasłem, a sam proces wymaga wskazania nowej ścieżki dostępu w ustawieniach programu instalowanego na nowym komputerze.
Drugim, znacznie bardziej zaawansowanym formatem, jest baza MS SQL (Microsoft Structured Query Language — system zarządzania relacyjnymi bazami danych). To rozwiązanie serwerowe, z reguły stosowane przez biura rachunkowe oraz duże przedsiębiorstwa posiadające rozbudowaną historię dokumentów i wielu pracowników. W tym wariancie dane nie znajdują się w jednym łatwym do skopiowania pliku, lecz zarządzane są przez osobną usługę serwerową działającą w tle. Przeniesienie bazy SQL wymaga utworzenia kopii zapasowej w formacie BAK przy użyciu odpowiednich narzędzi administracyjnych, przeniesienia tego pliku, instalacji silnika bazy danych na nowym sprzęcie, a następnie wykonania procedury odtwarzania (tzw. restore). Proces ten jest technicznie wymagający i wiąże się z koniecznością konfiguracji odpowiednich poświadczeń logowania do serwera oraz ustawienia reguł w zaporze sieciowej systemu Windows, jeśli stanowisko pracuje w sieci wielostanowiskowej.
Przed wykonaniem jakichkolwiek modyfikacji na sprzęcie źródłowym oraz docelowym kluczowe jest przygotowanie bezpiecznego środowiska testowego. Bazy danych programu zawierają dokumenty wrażliwe (dane osobowe, wysokości składek, numery identyfikacyjne ubezpieczonych), co wymaga traktowania ich zgodnie z zaostrzonymi procedurami bezpieczeństwa. W ramach przygotowań tworzona jest dodatkowa, niezależna kopia zapasowa danych, która jest szyfrowana w celu ochrony przed nieautoryzowanym dostępem. Takie archiwum gwarantuje możliwość powrotu do działającego środowiska w sytuacji nagłej przerwy w dostawie zasilania czy problemów z odczytem plików ze starszych nośników podczas procesu przenoszenia. Weryfikowana jest także spójność logiczna tej kopii pod kątem integralności struktur, co pozwala uniknąć migracji bazy, w której występowały wcześniejsze błędy z zapisem danych na starym stanowisku pracy.
Samo skopiowanie bazy to niepełny proces. Do prawidłowego funkcjonowania i wysyłania zestawień do Zakładu Ubezpieczeń Społecznych wymagany jest certyfikat kwalifikowany. Procedura instalacji podpisu elektronicznego zależy od stosowanego przez klienta rozwiązania kryptograficznego.
Podpisy fizyczne, zapisane na karcie kryptograficznej umieszczanej w czytniku, wymagają zainstalowania właściwych sterowników czytnika (programu zarządzającego sprzętem zewnętrznym) oraz aplikacji dostarczanej przez wystawcę certyfikatu. Bez tego oprogramowania system operacyjny rozpozna urządzenie jedynie jako nieznany sprzęt USB, a Płatnik nie uzyska dostępu do klucza prywatnego niezbędnego do szyfrowania i podpisywania dokumentów. Podczas konfiguracji weryfikuje się zgodność architektury sterownika (wersje 32-bitowe i 64-bitowe) z architekturą systemu Windows na nowym stanowisku.
W przypadku podpisów chmurowych, które nie posiadają nośnika fizycznego w postaci czytnika i karty, konieczna jest instalacja specjalnej aplikacji wirtualizującej (programu imitującego obecność karty w systemie operacyjnym). Wymaga to posiadania danych do logowania na platformie wydawcy podpisu. W każdej z tych sytuacji program musi zostać ponownie wskazany jako aplikacja uprawniona do korzystania ze ścieżki weryfikacji certyfikatu. Po instalacji podpisu przeprowadza się procedurę rejestracji certyfikatu w centralnym rejestrze systemu Windows, by aplikacja rozliczeniowa widziała go w oknie wyboru podczas wysyłki zestawień.
Próby przeprowadzenia przenosin bez przygotowania technicznego często skutkują utratą dostępu do wieloletniej historii firmy. Najczęstszym błędem jest skopiowanie samego folderu instalacyjnego. Program Płatnik nie przechowuje swoich danych w folderze, w którym zainstalowane są pliki wykonawcze. Z reguły baza znajduje się w specjalnym katalogu roboczym. Skopiowanie samych plików aplikacji prowadzi do uruchomienia pustego programu, proszącego o założenie pierwszej kartoteki.
Kolejną komplikacją jest zignorowanie uprawnień systemu plików (NTFS, czyli formatu plików systemu Windows). Baza Access przeniesiona na inny komputer za pomocą nośnika zewnętrznego często dziedziczy uprawnienia przypisane do konta użytkownika ze starego środowiska. Skutkuje to zablokowaniem dostępu do bazy dla profilu na nowym komputerze, a program komunikuje błąd przy próbie otwarcia kartoteki. Rozwiązaniem jest zaawansowana edycja uprawnień do pliku i przejęcie własności (nadanie pełnych praw kontroli aktualnemu użytkownikowi maszyny).
Poważnym problemem jest także zagubienie haseł. Oprogramowanie wymaga hasła administratora służącego do logowania do interfejsu (hasła głównego) oraz oddzielnego hasła dostępowego, szyfrującego sam plik bazy danych. Brak wiedzy na temat hasła do bazy uniemożliwia jej podpięcie. Klienci, u których poświadczenia były automatycznie zapamiętane na starym stanowisku, zazwyczaj nie pamiętają znaków potrzebnych do konfiguracji od zera. Próba użycia niewłaściwych kluczy skutkuje zablokowaniem autoryzacji.
Niewłaściwa kolejność wykonywania zadań potrafi doprowadzić do nieodwracalnego uszkodzenia pliku MDB. Kopiowanie pliku na nośnik pamięci zewnętrznej podczas gdy aplikacja nadal działa w tle, skutkuje przechwyceniem zablokowanego pliku tymczasowego, w którym operacje wejścia i wyjścia nie zostały poprawnie sfinalizowane. Taka struktura po przeniesieniu zostaje oznaczona przez bazę jako uszkodzona.
Aplikacja służąca do wymiany danych z systemem ubezpieczeń społecznych oparta jest o specyficzne biblioteki operacyjne (tzw. środowisko uruchomieniowe framework). Nowoczesne stacje robocze często nie posiadają wbudowanych pakietów wymaganych przez te technologie. Proces instalacji zakłada doinstalowanie wstecznie kompatybilnych bibliotek (na przykład starszych pakietów .NET Framework). Brak wymaganych technologii środowiskowych uniemożliwia instalatorowi odpowiednie skonfigurowanie rejestru systemowego i prawidłowy odczyt zaszyfrowanych pakietów.
Szczególną uwagę kładzie się na słowniki i status elementów pomocniczych. Po poprawnym podłączeniu bazy, przed jakimkolwiek przeliczeniem deklaracji wymagane jest przeprowadzenie procedury aktualizacji słowników ubezpieczeniowych oraz komponentów programu. Uruchomienie przestarzałej aplikacji na aktualnej bazie prowadzi do błędów w przetwarzaniu logiki certyfikatów i weryfikacji metryki dokumentu.
Użytkownicy niejednokrotnie decydują się na wymianę komputera z powodu skrajnie wolnego działania interfejsu programu. Klienci diagnozują to jako problem starego sprzętu, zlecają przeniesienie środowiska, po czym obserwują te same opóźnienia na nowoczesnej jednostce. Tego typu zawieszanie się programu, powolne wyliczanie raportów RMUA czy bardzo długie wczytywanie listy pracowników rzadko wynika z problemów sprzętowych.
Taki objaw najczęściej wskazuje na techniczne przepełnienie pliku bazy w formacie Access. Format ten posiada limit wielkości pojedynczego pliku do dwóch gigabajtów pojemności. Zbliżanie się do tego surowego limitu wpływa na wydajność. Przeniesienie ogromnej bazy w tym samym formacie po prostu przenosi kłopoty w inne miejsce. Odpowiednim działaniem jest optymalizacja pliku (tzw. kompaktowanie bazy, czyli programowe usunięcie pustych przestrzeni wynikających ze skasowanych wpisów, połączone z weryfikacją jej struktury). Przy gigantycznych archiwach wymagana bywa konwersja do środowiska serwerowego SQL, co trwale eliminuje spowolnienia na nowym komputerze.
Istnieją specjalistyczne techniki pozwalające na zresetowanie lub odczytanie klucza szyfrującego bazę zapisaną w formacie Access. Jeśli środowisko jest nadal aktywne i w pełni działa na starym stanowisku, klucz deszyfrujący wyodrębnia się bezpośrednio z aktywnych rejestrów maszyny źródłowej. W przypadku systemów opartych na serwerach SQL, blokady autoryzacyjne nadpisuje się na poziomie konsoli konfiguracyjnej silnika bazy danych, po uwierzytelnieniu za pomocą kont administratora Windows.
Jeżeli architektura rozliczeniowa korzysta z jednego centralnego pliku z obsługą wielu płatników (tzw. rozwiązanie wielofirmowe w jednej bazie), cały proces przeprowadzany jest spójnie dla wszystkich podmiotów jednocześnie. W przypadku trzymania osobnych plików dla każdej z obsługiwanych firm (np. z uwagi na odmienne polityki bezpieczeństwa i ograniczenia praw dostępu dla pracowników), migracja wymaga ręcznego skopiowania, a następnie oddzielnego dodania ścieżek do każdego pliku po stronie nowej stacji, co znacznie wydłuża procedurę integracji.
W tradycyjnej architekturze opartej na plikach nie jest to możliwe. Skopiowanie danych do nowego środowiska tworzy ich odrębną kopię (tzw. rozwidlenie bazy). Wszelkie operacje i raporty wygenerowane na nowym stanowisku nie zaktualizują archiwum na starym urządzeniu. Próba pracy równoległej doprowadzi do chaosu i utraty ciągłości w numeracji wysyłanych dokumentów rozliczeniowych do ZUS. Bezpieczna praca z kilku komputerów jednocześnie na tym samym zasobie dokumentów wymaga instalacji silnika sieciowego.
Taka operacja wiąże się ze zmianą parametrów sterowników pośredniczących (sterowników OBDC - odpowiedzialnych za stabilne łączenie oprogramowania klienckiego z silnikiem bazy). Instalator musi zaaplikować kompatybilne wersje mechanizmów dostępu, w przeciwnym razie system operacyjny zablokuje połączenia sieciowe jako pochodzące z nieobsługiwanej architektury oprogramowania.
Bezpieczne uruchomienie stanowiska kadrowego na nowym sprzęcie wykracza poza samo przeniesienie plików instalacyjnych programu i sprowadza się do precyzyjnego odtworzenia poświadczeń, struktury bazy danych oraz zabezpieczeń kryptograficznych. Poprawne wdrożenie wymaga uwzględnienia limitów używanego silnika oraz spójności środowiska systemowego i wdrożenia niezawodnych mechanizmów szyfrujących do odczytywania pełnej historii ubezpieczeń.