Oprogramowanie firmowe
Rewizor GT — problemy przy zamknięciu miesiąca i okresu
Pierwsze czynności diagnostyczne na miejscu u klienta
Zgłoszenie dotyczące trudności z zamknięciem okresu obrachunkowego w programie Rewizor GT zazwyczaj pojawia się w ściśle określonym momencie roku lub miesiąca, gdy zbliżają się terminy rozliczeń podatkowych. Po przyjeździe na miejsce pierwszym krokiem jest zabezpieczenie aktualnego stanu systemu. Serwis rozpoczyna pracę od wykonania pełnej kopii zapasowej bazy danych w pliku archiwum. Kopia tworzona jest bezpośrednio z poziomu mechanizmów serwera bazodanowego, co uniezależnia proces od stanu samej aplikacji księgowej. Dopiero po potwierdzeniu integralności utworzonego pliku archiwalnego podejmowane są dalsze kroki sprawdzające.
Kolejną czynnością jest weryfikacja aktywnych połączeń z bazą danych. Zamknięcie miesiąca wymaga wyłącznego dostępu do określonych tabel lub wykonania operacji w trybie, który nie może być zakłócany przez równoległą pracę innych stanowisk. Serwis sprawdza, czy na innych komputerach w sieci lokalnej nie pozostały otwarte sesje programu, zawieszone procesy w tle lub aktywne połączenia ze stanowisk magazynowych i sprzedażowych współpracujących w ramach jednego pakietu oprogramowania. Następnie analizowany jest stan wolnego miejsca na dyskach komputera pełniącego funkcję serwera oraz poziom obciążenia pamięci operacyjnej.
Objawy trudności z zamknięciem okresu z perspektywy użytkownika
Próba zatwierdzenia okresu lub wygenerowania zestawień zamykających kończy się najczęściej nagłym zatrzymaniem działania aplikacji. Użytkownicy opisują tę sytuację jako nieskończone oczekiwanie, podczas którego program przestaje reagować na polecenia, a wskaźnik myszy sygnalizuje ciągłe przetwarzanie. W wielu przypadkach na ekranie pojawia się ogólny komunikat o braku odpowiedzi aplikacji lub przerwaniu połączenia z serwerem danych, co zmusza do wymuszonego zamknięcia programu za pomocą systemowego menedżera zadań.
Inny typowy scenariusz to odmowa wykonania operacji z powodu rzekomej edycji dokumentów przez innego użytkownika, mimo że w biurze nikt inny nie wykonuje w danym momencie żadnych operacji. Klienci zgłaszają również sytuacje, w których proces zamykania przechodzi pozornie do końca, lecz wygenerowane zestawienia obrotów i sald nie bilansują się, a część dokumentów księgowych pozostaje w stanie niezaksięgowanym lub częściowo przetworzonym. Zdarza się także, że po nieudanej próbie zamknięcia miesiąca program całkowicie blokuje możliwość wprowadzania nowych zapisów do kolejnego okresu obrachunkowego.
Przyczyny techniczne blokad i błędów operacji
Źródła problemów z zamknięciem miesiąca w programie Rewizor GT leżą głównie w infrastrukturze bazodanowej, uprawnieniach systemowych oraz stabilności lokalnej sieci komputerowej. Można je uszeregować od występujących najczęściej do przypadków rzadszych i bardziej złożonych:
- Blokady rekordów w bazie danych (deadlock) — najczęstsza przyczyna wynikająca z jednoczesnego żądania dostępu do tych samych tabel przez różne procesy. Jeśli jedno ze stanowisk rozpoczęło edycję dekretu lub rozliczenia i nie zwolniło blokady, procedura zamykająca okres nie może zaktualizować statusu powiązanych zapisów.
- Zablokowane lub osierocone sesje użytkowników — w wyniku wcześniejszego nieprawidłowego wyłączenia komputera, zaniku zasilania lub awarii połączenia sieciowego serwer bazy danych może nadal traktować danego użytkownika jako aktywnego, uniemożliwiając wykonanie operacji wymagających wyłączności.
- Brak wystarczającej przestrzeni dyskowej lub ograniczenia plików bazy — operacja zamykania okresu generuje dużą liczbę wpisów w dzienniku transakcji. Gdy na dysku serwera kończy się miejsce lub plik dziennika osiągnie limit rozmiaru, silnik bazy danych natychmiast przerywa operację w celu ochrony integralności danych.
- Niestabilność połączenia sieciowego między stanowiskiem a serwerem — w środowiskach wielostanowiskowych korzystających z sieci przewodowej lub bezprzewodowej nawet chwilowy pakiet strat danych może zerwać połączenie w trakcie wieloetapowej transakcji zamykającej, pozostawiając bazę w stanie niespójnym.
- Niewystarczające uprawnienia konta systemowego lub użytkownika programu — brak uprawnień do zapisu w katalogach tymczasowych, brak praw do modyfikacji plików wymiany lub ograniczenia na poziomie ról w samej bazie danych mogą zablokować tworzenie tabel tymczasowych niezbędnych do przeliczeń.
- Uszkodzenia logiczne struktury bazy danych — rzadsza, lecz poważna przyczyna, powstała na skutek nagłego wyłączenia serwera bez poprawnego zamknięcia usług. Błędne indeksy lub uszkodzone wskaźniki w tabelach księgowych uniemożliwiają wykonanie pełnego bilansu.
Warianty tego samego problemu
Trudności związane z zamknięciem miesiąca i okresu manifestują się w różny sposób, w zależności od specyfiki pracy danego biura oraz konfiguracji technicznej. Wyróżnia się trzy główne warianty tego zjawiska.
Wariant 1: Blokada wielostanowiskowa w sieci lokalnej
Występuje w firmach, gdzie z jedną bazą danych pracuje równolegle kilku księgowych lub gdzie baza połączona jest z modułami handlowymi. Problem polega na konfliktach dostępu. Nawet jeśli pracownicy deklarują zakończenie pracy, usługi tła, procesy synchronizujące lub zawieszone wątki sieciowe utrzymują blokady na tabelach rozrachunków. W tym wariancie kluczowe jest zidentyfikowanie źródła blokady na poziomie procesów serwerowych, a nie tylko weryfikacja fizycznej obecności użytkowników przy komputerach.
Wariant 2: Naruszenie integralności transakcji po awarii zasilania
Ten przypadek pojawia się, gdy wcześniejsza próba zamknięcia została przerwana przez reset komputera, zanik prądu lub twarde wyłączenie aplikacji. Baza danych znajduje się wówczas w stanie zawieszenia transakcji — część tabel została oznaczona jako zablokowana do przeliczeń, ale proces nie dotarł do etapu zatwierdzenia. Standardowe ponowienie procedury z poziomu menu programu jest wtedy odrzucane przez mechanizmy bezpieczeństwa bazy danych.
Wariant 3: Niewydolność zasobów komputera pełniącego funkcję serwera
Dotyczy sytuacji, gdy baza danych rozrosła się przez lata pracy do znacznych rozmiarów, a komputer obsługujący silnik bazy posiada zbyt małą ilość pamięci operacyjnej lub mocno pofragmentowany dysk twardy. Zamknięcie roku lub podsumowanie wielu miesięcy wymaga wykonania ogromnej liczby operacji wejścia-wyjścia. Silnik bazy danych przekracza wówczas domyślne limity czasowe na wykonanie zapytania i operacja zostaje automatycznie anulowana z powodu przekroczenia limitu czasu.
Przebieg diagnozy i działań serwisowych
Prace naprawcze realizowane są w sposób ustrukturyzowany, z zachowaniem pełnego bezpieczeństwa przetwarzanych danych księgowych. Po wykonaniu wstępnej kopii zapasowej serwis przystępuje do weryfikacji spójności logicznej i fizycznej bazy danych przy użyciu dedykowanych narzędzi administracyjnych silnika bazy.
Pierwszym krokiem technicznym jest wykonanie procedury kontroli integralności bazy danych. Sprawdzana jest poprawność alokacji stron oraz struktura wszystkich tabel powiązanych z modułem finansowo-księgowym programu Rewizor GT. W przypadku wykrycia błędów indeksowania przeprowadzana jest odbudowa indeksów — proces reorganizujący strukturę danych w celu przywrócenia optymalnej wydajności wyszukiwania i eliminacji błędnych wskaźników.
Następnie analizowane są aktywne blokady i transakcje. Z poziomu konsoli zarządzania bazą danych identyfikowane są identyfikatory procesów, które przetrzymują zasoby. Serwis w sposób kontrolowany zamyka osierocone połączenia, dbając o to, aby żadna niezapisana transakcja nie uszkodziła wpisów w powiązanych tabelach. Kolejnym elementem jest weryfikacja uprawnień użytkowników systemowych do folderów roboczych i tymczasowych oraz kontrola konfiguracji zapory sieciowej, która w pewnych warunkach potrafi blokować pakiety transmisyjne podczas długotrwałych operacji bazodanowych.
Po wyczyszczeniu środowiska i przywróceniu pełnej spójności bazy, operacja zamknięcia miesiąca lub okresu jest uruchamiana ponownie w kontrolowanych warunkach, z bieżącym monitorowaniem obciążenia procesora, pamięci oraz operacji dyskowych. Po pomyślnym zakończeniu procedury weryfikowane są podstawowe zestawienia finansowe, aby upewnić się, że stan księgowy jest w pełni spójny.
Czego nie robić samodzielnie i co warto sprawdzić przed przyjazdem serwisu
W przypadku wystąpienia błędu podczas zamykania okresu kluczowe jest unikanie działań, które mogą pogłębić problem lub doprowadzić do trwałego uszkodzenia struktury plików:
- Nie należy wielokrotnie wymuszać zamknięcia programu poprzez twardy reset komputera lub odłączanie zasilania w trakcie trwania operacji zamykania. Przerywanie zapisu w połowie transakcji to najprostsza droga do uszkodzenia plików bazy danych.
- Nie wolno usuwać ręcznie plików z folderów programu ani modyfikować plików bazodanowych za pomocą nieznanych narzędzi pobranych z internetu.
- Nie należy ignorować komunikatów ostrzegawczych i próbować wielokrotnie uruchamiać tej samej operacji bez usunięcia przyczyny pierwotnej, gdyż może to doprowadzić do nadpisania poprawnych wpisów błędnymi danymi tymczasowymi.
Przed przyjazdem serwisu warto wykonać kilka prostych i bezpiecznych czynności weryfikacyjnych:
- Upewnić się, że wszyscy pozostali pracownicy w biurze wylogowali się z programu Rewizor GT oraz programów współpracujących i wyłączyli swoje komputery.
- Sprawdzić, czy komputer główny (serwer) ma stabilne połączenie z siecią i czy na dysku systemowym oraz dysku z bazą danych znajduje się wolne miejsce.
- Zapisać treść pojawiającego się komunikatu lub zanotować dokładny moment, w którym proces ulega zatrzymaniu.
Organizacja pomocy serwisowej i model współpracy
Obsługa zgłoszeń technicznych dotyczących oprogramowania biurowego realizowana jest bezpośrednio w siedzibie klienta. Dojeżdżamy do firm i biur rachunkowych na terenie Warszawy oraz okolicznych powiatów, co pozwala na bezpośrednią diagnozę całej infrastruktury — serwera, stacji roboczych, połączeń kablowych oraz urządzeń sieciowych. Prace prowadzimy przez całą dobę, siedem dni w tygodniu, co ma szczególne znaczenie w okresach sprawozdawczych, gdy każda godzina przestoju opóźnia rozliczenia.
Przed przystąpieniem do jakichkolwiek modyfikacji konfiguracji lub naprawy bazy danych klient otrzymuje indywidualną wycenę usługi i podejmuje decyzję o rozpoczęciu prac. Diagnoza odbywa się z zachowaniem pełnego bezpieczeństwa informacji. Na życzenie klienta bezpłatnie podpisujemy umowę o poufności (NDA), gwarantującą ochronę tajemnicy przedsiębiorstwa oraz danych finansowych. Wszystkie czynności wykonują bezpośrednio nasi serwisanci, bez angażowania zewnętrznych podwykonawców. W sytuacjach, gdy problem wynika z poważniejszej usterki sprzętowej komputera pełniącego funkcję serwera i naprawa na miejscu nie jest możliwa, odbieramy sprzęt do warsztatu i odwozimy go po usunięciu awarii własnym transportem.
W przypadku problemów z zamknięciem miesiąca w programie Rewizor GT lub konieczności pilnej interwencji technicznej w infrastrukturze biurowej, prosimy o kontakt telefoniczny pod numerem 22 257 87 54.
Nie wiesz, od czego zacząć? Zadzwoń.
Porada telefoniczna nic nie kosztuje, a część usterek udaje się rozwiązać bez dojazdu — zwłaszcza tych, w których winne są ustawienia albo zasilanie. Jeżeli trzeba przyjechać, dojazd, odbiór i zwrot sprzętu są bezpłatne, a diagnoza laptopa przy odbiorze — również. Wizyta serwisanta u klienta jest płatna; sam dojazd i tak nic nie kosztuje.
Telefon odbieramy całą dobę, siedem dni w tygodniu — także w weekendy i święta. Dojeżdżamy na terenie Warszawy i siedmiu przyległych powiatów.