Wymagania techniczne systemów sprzedażowo-magazynowych i architektura baz danych

Oprogramowanie handlowo-magazynowe, takie jak systemy z linii InsERT (w tym Subiekt GT oraz Subiekt nexo) czy pakiety Asseco WAPRO (między innymi WAPRO Mag), opiera swoje działanie na architekturze klient-serwer. Sercem całego środowiska jest motor bazy danych Microsoft SQL Server, który odpowiada za integralność transakcji, blokady rekordów, indeksowanie oraz bezpieczny zapis stanów magazynowych, dokumentów handlowych i rozliczeń. Każde stanowisko robocze łączy się z tą centralną bazą poprzez sieć lokalną przy użyciu protokołu TCP/IP lub nazwanych potoków (Named Pipes). Wszelkie operacje handlowe — wystawienie dokumentu sprzedaży, przyjęcie dostawy czy synchronizacja z urządzeniem fiskalnym — wymagają stabilnej komunikacji, odpowiednich uprawnień systemowych oraz spójności struktur tabelarycznych.

W praktyce gospodarczej przedsiębiorstw działających w Milanówku i sąsiednich miejscowościach powiatu grodziskiego, systemy te pracują na zróżnicowanej infrastrukturze. Niejednokrotnie jedno stanowisko pełni jednocześnie funkcję serwera bazodanowego i kasy, podczas gdy inne komputery w sieci lokalnej pełnią rolę końcówek magazynowych lub biurowych. W momencie, gdy którykolwiek z elementów tego łańcucha — od podsystemu dyskowego, przez usługi sieciowe Windows, po konfigurację zapory sieciowej — ulegnie awarii bądź rozregulowaniu, ciągłość sprzedaży zostaje natychmiast zablokowana. Prawidłowa obsługa techniczna tych pakietów wymaga precyzyjnej wiedzy o mechanizmach bazodanowych, a nie wyłącznie znajomości samego interfejsu użytkownika.

Objawy problemów zgłaszane przez użytkowników

Gdy dochodzi do usterki lub nieprawidłowości w działaniu środowiska sprzedażowego, osoby obsługujące programy napotykają konkretne bariery uniemożliwiające codzienną pracę. Podczas kontaktu telefonicznego użytkownicy najczęściej opisują sytuację prostymi, codziennymi słowami, wskazując na nagłe zatrzymanie procesów handlowych:

  • Program w ogóle się nie uruchamia, a po kliknięciu ikony pojawia się komunikat o braku możliwości połączenia z serwerem bazy danych lub informacja, że podany serwer nie istnieje bądź odmówiono dostępu.
  • Stanowisko główne działa poprawnie, ale dodatkowe komputery w biurze lub na magazynie zgłaszają błąd sieciowy przy próbie zalogowania do podmiotu.
  • Aplikacja uruchamia się, lecz operacje trwają bardzo długo — wystawienie pojedynczego dokumentu, wyszukiwanie towaru po kodzie kreskowym czy zatwierdzenie paragonu zajmuje kilkadziesiąt sekund, a na ekranie pojawia się komunikat „Brak odpowiedzi".
  • Podczas aktualizacji programu do nowszej wersji proces konwersji bazy danych zatrzymuje się z błędem krytycznym, pozostawiając strukturę w stanie niekompletnym, co blokuje dostęp wszystkim użytkownikom.
  • Nie można wydrukować dokumentu na drukarce fiskalnej — program zgłasza błąd sterownika, przekroczenie limitu czasu odpowiedzi urządzenia (timeout) lub brak komunikacji na przypisanym porcie COM/USB.
  • Pojawiają się błędy integralności danych, na przykład nieprawidłowo naliczony podatek, rozbieżności w stanach magazynowych po nagłym wyłączeniu zasilania bądź komunikaty o uszkodzeniu indeksów tabeli.

Przyczyny awarii i nieprawidłowego działania programów

Problemy z systemami Subiekt i WAPRO rzadko wynikają z wad samego kodu aplikacji. Zdecydowanie częściej źródłem są zakłócenia w środowisku operacyjnym, sprzęcie lub infrastrukturze sieciowej. Przyczyny układają się w pewną powtarzalną hierarchię, od najczęstszych do bardziej złożonych:

1. Zatrzymanie lub błędna konfiguracja usług bazy danych Microsoft SQL Server. To najpowszechniejsza przyczyna nagłego braku dostępu do programu. Usługa SQL Server może zostać zatrzymana na skutek braku wolnego miejsca na dysku systemowym, kolizji po aktualizacji systemu Windows, uszkodzenia plików dziennika transakcji (.ldf) lub nieprawidłowych uprawnień konta systemowego.

2. Blokady komunikacji sieciowej i reguł zapory ogniowej (firewall). W konfiguracjach wielostanowiskowych zapora sieciowa Windows Defender lub oprogramowanie antywirusowe na komputerze pełniącym rolę serwera potrafi samoczynnie zablokować porty domyślne dla SQL Server (zwykle port TCP 1433) oraz usługę SQL Browser (port UDP 1434). Skutkuje to odcięciem stanowisk klienckich mimo pełnej sprawności samej bazy.

3. Konflikty portów i sterowników urządzeń peryferyjnych. Drukarki fiskalne, czytniki kodów kreskowych czy wagi kalkulacyjne komunikują się przez wirtualne porty szeregowe COM. Aktualizacja systemu operacyjnego potrafi zmienić numerację portów USB lub podmienić sterownik konwertera USB-RS232, co zrywa komunikację programu z urządzeniem fiskalnym.

4. Fragmentacja i uszkodzenia logiczne struktury bazy danych. Nagły zanik zasilania w trakcie trwania transakcji dyskowej, błędy na nośniku pamięci lub gwałtowne zamknięcie procesu potrafią doprowadzić do niespójności logicznej (database corruption). Baza przechodzi wtedy w tryb awaryjny (Suspect lub Recovery Pending), uniemożliwiając logowanie.

5. Niewydolność podsystemu pamięci masowej i sprzętu komputerowego. Bazy danych generują intensywny ruch wejścia/wyjścia (I/O). Praca na wyeksploatowanych dyskach talerzowych, zapełnionych nośnikach SSD bez włączonej funkcji TRIM lub komputerach z niewystarczającą ilością pamięci RAM powoduje dławienie zapytań SQL i blokowanie transakcji między stanowiskami.

6. Błędy procedur archiwizacji i konwersji. Próba podniesienia wersji programu bez wcześniejszej weryfikacji spójności bazy danych narzędziem DBCC CHECKDB może skutkować przerwaniem migracji w połowie i unieruchomieniem systemu.

Kiedy to nie jest ta usterka

Zanim podejmie się działania ukierunkowane na naprawę bazy danych lub rekonfigurację programu handlowego, należy wykluczyć inne źródła problemów, które dają łudząco podobne objawy zewnętrzne, lecz leżą poza oprogramowaniem sprzedażowym:

  • Usterka sprzętowa samego urządzenia fiskalnego: Jeśli program zgłasza błąd wydruku, a na wyświetlaczu drukarki fiskalnej widnieje komunikat o zablokowaniu mechanizmu tnącego, zacięciu papieru, konieczności wykonania raportu dobowego, wyczerpaniu pamięci fiskalnej bądź błędzie zegara czasu rzeczywistego (RTC), problem leży wewnątrz modułu fiskalnego. Tego typu błędy wymagają interwencji uprawnionego serwisu urządzeń fiskalnych (serwisu z plombą), a nie modyfikacji bazy danych.
  • Fizyczna awaria okablowania lub przełącznika sieciowego (switcha): Komunikat o braku połączenia ze stanowiska podrzędnego może wynikać ze zwykłego uszkodzenia wtyku RJ45, uszkodzenia zasilacza w przełączniku sieciowym lub rozłączenia sieci Wi-Fi, a nie z awarii programu Subiekt czy WAPRO.
  • Zawieszenie platformy integracyjnej zewnętrznego operatora: Brak synchronizacji ze sklepem internetowym lub zewnętrznym systemem kurierskim często bywa spowodowany zmianami w interfejsie programistycznym (API) zewnętrznego portalu lub wygaśnięciem kluczy autoryzacyjnych, podczas gdy lokalny program magazynowy działa bez zarzutu.
  • Kwestie merytoryczno-księgowe: Jeśli dokument nie pozwala się zapisać z uwagi na brak przypisanej stawki podatkowej, niepoprawny numer NIP kontrahenta czy zablokowany okres obrachunkowy, jest to blokada wynikająca z logiki biznesowej programu i przepisów podatkowych, a nie usterka techniczna oprogramowania czy bazy SQL.

Diagnostyka, naprawa i wdrożenie rozwiązań na miejscu u klienta

Prace serwisowe realizowane z dojazdem w Milanówku przebiegają według usystematyzowanej procedury technicznej, mającej na celu jak najszybsze przywrócenie sprawności operacyjnej przy zachowaniu pełnego bezpieczeństwa danych handlowych.

W pierwszej kolejności wykonywana jest diagnostyka stanu dysków i struktury plików. Zanim zostaną podjęte jakiekolwiek modyfikacje, tworzona jest kopia bezpieczeństwa surowych plików bazy danych (.mdf i .ldf) lub kopia zapasowa na poziomie serwera SQL (plik .bak). Pozwala to zabezpieczyć historię operacji przed ryzykiem pogłębienia uszkodzeń.

Następnie sprawdzany jest stan instancji SQL Server przy użyciu konsoli zarządzającej SQL Server Management Studio (SSMS) oraz wbudowanych narzędzi diagnostycznych programu. Serwisant uruchamia procedury sprawdzające integralność strukturalną, takie jak polecenia DBCC CHECKDB z odpowiednimi parametrami, identyfikując ewentualne uszkodzone alokacje tabel czy indeksów. W przypadku drobnych niespójności wykonywana jest naprawa logiczna danych. W razie poważniejszych uszkodzeń struktury tabele są odzyskiwane z ostatnich poprawnych kopii zapasowych lub rekonstruowane z zachowaniem relacji.

Kolejnym etapem jest optymalizacja środowiska sieciowego. Konfigurowane są stałe adresy IP dla komputera centralnego, włączany jest protokół TCP/IP w konfiguracji SQL Server Configuration Manager oraz tworzone są reguły ruchu przychodzącego i wychodzącego w zaporze sieciowej Windows, dedykowane dla procesu sqlservr.exe oraz portów komunikacyjnych. Weryfikowana jest poprawność translacji nazw sieciowych NetBIOS oraz konfiguracja aliasów SQL na stacjach roboczych, co zapewnia stabilne łączenie się końcówek z bazą nawet przy zmianach w sieci lokalnej.

W ramach obsługi systemów Subiekt i WAPRO realizowane są również zadania wdrożeniowe i modernizacyjne:

  • Bezpieczne przenoszenie baz danych na nowo zakupiony sprzęt lub szybsze dyski półprzewodnikowe, wraz z rekonfiguracją wszystkich stacji klienckich.
  • Instalacja i parametryzacja oprogramowania po zmianach struktury firmy lub dodaniu nowych stanowisk sprzedaży.
  • Przeprowadzanie zaległych konwersji i aktualizacji wersji programów z kontrolą poprawności przeliczeń danych historycznych.
  • Konfiguracja sterowników i mapowanie połączeń do urządzeń peryferyjnych (czytniki kodów, drukarki etykiet, sprawdzarki cen, terminale płatnicze zintegrowane przez protokoły programowe).
  • Automatyzacja cyklicznego tworzenia kopii zapasowych (backupów) z harmonogramem zadań, z zapisem na zewnętrzny nośnik sieciowy lub wydzieloną przestrzeń pamięci, co zabezpiecza przedsiębiorstwo przed skutkami awarii sprzętu.

Czego nie robić samodzielnie i wstępne kroki weryfikacyjne

Próby samodzielnej, nieskoordynowanej naprawy środowiska bazodanowego mogą doprowadzić do bezpowrotnej utraty wprowadzonych dokumentów lub całkowitego zablokowania bazy. Należy bezwzględnie unikać następujących działań:

  • Nie wolno ręcznie kasować plików z rozszerzeniem .ldf (plik dziennika transakcji) w nadziei na zwolnienie miejsca na dysku — plik ten zawiera niezapisek transakcji i jego usunięcie uniemożliwi podmontowanie bazy danych.
  • Nie należy uruchamiać skryptów naprawczych SQL pobranych z niesprawdzonych źródeł internetowych z parametrem zezwalającym na utratę danych (REPAIR_ALLOW_DATA_LOSS), jeśli nie ma wykonanej pewnej, pełnej kopii zapasowej. Polecenie to potrafi usunąć całe uszkodzone tabele wraz z historią sprzedaży, zamiast je naprawić.
  • Nie należy wielokrotnie wymuszać restartu komputera przyciskiem zasilania podczas trwania konwersji bazy lub jej indeksowania — grozi to przerwaniem zapisu na poziomie sektorów nośnika.
  • Nie wolno instalować programu na nowo „na ślepo" na tym samym dysku bez wcześniejszego skopiowania folderu z danymi, gdyż instalator może nadpisać istniejące struktury podmiotów pustymi plikami szablonów.

Przed przyjazdem serwisu można natomiast bezpiecznie wykonać kilka podstawowych czynności sprawdzających:

  • Sprawdzić, czy komputer pełniący funkcję bazy danych jest włączony, zalogowany do systemu i ma aktywne połączenie z siecią lokalną.
  • Upewnić się, czy na dysku C: serwera oraz na dysku z bazą danych nie skończyło się całkowicie wolne miejsce (brak miejsca natychmiast zatrzymuje silnik bazy).
  • Zrestartować router lub przełącznik sieciowy, jeśli żadne ze stanowisk nie widzi pozostałych komputerów w sieci lokalnej.
  • Sprawdzić, czy kable sygnałowe USB od drukarki fiskalnej lub czytnika kodów nie zostały przypadkowo poluzowane lub przepięte do innych gniazd w obudowie.

Organizacja wsparcia technicznego i zasady realizacji usług

Obsługa techniczna dla przedsiębiorstw i punktów handlowych w Milanówku oraz na całym obszarze powiatu grodziskiego prowadzona jest w formule bezpośredniego dojazdu do siedziby klienta. Serwis funkcjonuje przez całą dobę, 7 dni w tygodniu, co pozwala na usuwanie awarii i przeprowadzanie prac modernizacyjnych również w godzinach wieczornych lub w dni wolne, bez konieczności przerywania bieżącej sprzedaży w ciągu dnia.

Każde zgłoszenie rozpoczyna się od wywiadu technicznego i ustalenia zakresu problemu. Po dotarciu na miejsce specjalista przeprowadza wstępną diagnozę infrastruktury i przedstawia dokładny kosztorys prac do akceptacji przed przystąpieniem do jakichkolwiek działań w systemie. Diagnoza odbywa się bez ingerencji w poufne dane biznesowe — prace prowadzone są bez wglądu w hasła użytkowników, chyba że specyfika uprawnień administracyjnych bazy danych wymaga ich podania w ściśle określonym celu konfiguracyjnym. Na życzenie klienta podpisywana jest bezpłatna umowa o poufności danych (NDA).

W sytuacjach, w których źródłem problemu z oprogramowaniem okazuje się głęboka usterka sprzętowa komputera (na przykład degradacja układów zasilania płyty głównej, uszkodzenie struktury nośnika pamięci czy awaria mostków logicznych), sprzęt może zostać odebrany do warsztatu stacjonarnego na warszawskim Bemowie, gdzie dysponujemy zapleczem mikrolutowniczym i aparaturą pomiarową. Po zakończonej naprawie i zweryfikowaniu spójności baz danych, komputer jest odwożony i ponownie integrowany z siecią oraz urządzeniami w firmie klienta. Na wykonane naprawy i zamontowane wyłącznie nowe podzespoły udzielana jest gwarancja do 12 miesięcy, a rozliczenie dokumentuje faktura bez VAT.

W przypadku problemów z funkcjonowaniem systemów Subiekt lub WAPRO, błędów bazy SQL bądź potrzeby konfiguracji stanowisk sprzedażowych na terenie Milanówka i okolic, zachęcamy do kontaktu telefonicznego pod numerem 22 257 87 54.