Czy awaryjny internet w sklepie stacjonarnym wystarczy, by kasa i magazyn pracowały bez przerwy?

Sklep ma światłowód, zapasowy internet LTE i router automatycznie przełączający połączenie. Mimo to podczas awarii kasjer nie może zakończyć sprzedaży, terminal odrzuca próbę płatności, a magazyn nie aktualizuje stanów towarowych. Taki scenariusz jest możliwy, ponieważ internet awaryjny nie gwarantuje ciągłości pracy całego sklepu. Zabezpiecza jedynie jeden z elementów infrastruktury. O tym, czy sprzedaż będzie kontynuowana, decydują również konfiguracja sieci, dostępność serwerów, sposób działania systemu POS i ERP oraz zasilanie urządzeń.

Największym zagrożeniem nie zawsze jest całkowity brak internetu. Często więcej problemów powoduje kilkunastosekundowe zerwanie sesji, niepotwierdzona płatność albo zamówienie zapisane lokalnie, które nie dotarło do centralnego magazynu. Dlatego przed zakupem dodatkowego abonamentu trzeba ustalić, jakie operacje sklep musi wykonywać podczas awarii i które systemy rzeczywiście potrafią pracować po zmianie łącza.

Internet zapasowy w sklepie – jak dobrać łącze, które naprawdę zadziała podczas awarii?

Najczęściej stosowanym rozwiązaniem jest router dual-WAN, wykorzystujący dwa niezależne połączenia internetowe. Pierwszym może być światłowód, drugim LTE lub 5G. Gdy podstawowy dostęp przestaje działać, router uruchamia mechanizm failover i przekierowuje nowy ruch przez łącze zapasowe.

Problem zaczyna się wtedy, gdy oba połączenia są niezależne tylko na fakturach. Dwie usługi światłowodowe, nawet od różnych sprzedawców, mogą korzystać z tej samej infrastruktury. Uszkodzenie wspólnego odcinka sieci potrafi wyłączyć obie usługi jednocześnie. Podobnie dwie karty SIM różnych marek nie zapewniają niezależności, jeżeli korzystają z tej samej sieci infrastrukturalnej.

Najbezpieczniejszy praktyczny układ to dwa różne media transmisyjne i możliwie niezależni operatorzy. Przykładowo światłowód lokalnego dostawcy i LTE/5G innego operatora infrastrukturalnego zmniejszają ryzyko wspólnej awarii. Nie eliminują go całkowicie, ponieważ obie sieci mogą zależeć od lokalnego zasilania lub współdzielonych elementów infrastruktury.

Przykład hipotetyczny: sklep z trzema stanowiskami kasowymi i niewielkim magazynem korzysta ze światłowodu 300 Mb/s. Podczas testów zapasowe LTE zapewnia 25 Mb/s pobierania oraz 8 Mb/s wysyłania. Takie parametry mogą wystarczyć do komunikacji systemu sprzedażowego z serwerem, przesyłania dokumentów i aktualizacji niewielkich porcji danych magazynowych. Nie oznacza to jednak, że można bez ograniczeń prowadzić wideokonferencje, pobierać aktualizacje i wykonywać kopie zapasowe w chmurze. Podczas awarii te operacje mogą odebrać przepustowość usługom sprzedażowym.

Oprócz szybkości transmisji znaczenie mają opóźnienia, utrata pakietów i stabilność sygnału. W sklepie z metalowymi regałami, chłodniami lub magazynem w piwnicy modem 5G może działać znacznie gorzej niż telefon sprawdzany przed wejściem. Zasięg trzeba mierzyć w docelowym miejscu instalacji, również w godzinach największego obciążenia sieci.

Przy wyborze rozwiązania należy sprawdzić pięć kwestii:

• Kontrola sprawności łącza. Router powinien badać rzeczywistą osiągalność zewnętrznych usług, a nie tylko sprawdzać, czy kabel WAN jest podłączony. Możliwa jest sytuacja, w której interfejs pozostaje aktywny, ale dostęp do internetu już nie działa.
• Przełączanie WAN. Czas reakcji zależy od interwału testów, liczby nieudanych prób i sposobu zestawienia zapasowego połączenia. Nie istnieje jeden czas przełączenia właściwy dla wszystkich routerów.
• DNS i VPN. Po zmianie operatora urządzenia muszą nadal rozwiązywać nazwy serwerów. Jeżeli ERP korzysta z VPN, trzeba sprawdzić, czy tunel może zostać ponownie zestawiony z nowego adresu IP i czy zapasowy operator nie blokuje wymaganej komunikacji.
• Trwałość sesji. Standardowy failover często powoduje zerwanie istniejących połączeń TCP/TLS, ponieważ zmienia się publiczny adres IP. Utrzymanie sesji wymaga odrębnych mechanizmów, obsługiwanych przez odpowiednią infrastrukturę.
• Zasilanie. UPS powinien podtrzymywać router, modem lub ONT, niezbędny przełącznik sieciowy oraz urządzenia wymagane do zakończenia sprzedaży. Sam router podłączony do UPS nie pomoże, jeśli wyłączy się komputer kasowy albo terminal.

Dobór UPS najlepiej zacząć od pomiaru poboru mocy. Jeśli przykładowe urządzenia sieciowe zużywają łącznie 40 W, a użyteczna energia zgromadzona w zasilaniu awaryjnym wynosi 240 Wh, orientacyjny czas podtrzymania to 6 godzin. W praktyce wynik będzie zależał od sprawności urządzenia, charakterystyki akumulatora i obciążenia. Pojemność nominalna nie jest tym samym co energia faktycznie dostępna na wyjściu UPS.

Istotny jest też powrót połączenia podstawowego. Zbyt szybkie automatyczne przełączanie z LTE z powrotem na niestabilny światłowód może powodować serię ponownych rozłączeń. Pomaga ustawienie okresu potwierdzania sprawności podstawowego WAN, a w wybranych instalacjach kontrolowane przełączenie dopiero po zakończeniu rozpoczętych operacji.

Automatyczny failover ma największy sens w sklepach o dużym ruchu, wykorzystujących centralne systemy sprzedażowe i wymagających stałego dostępu do usług operatorów płatności. W małym punkcie z samodzielną kasą oraz udokumentowanymi lokalnymi funkcjami POS można rozważyć tańsze połączenie zapasowe uruchamiane ręcznie. Trzeba wtedy zaakceptować czas reakcji pracownika i sprawdzić, czy ręczna procedura rzeczywiście działa.

Nie należy natomiast kupować drogiego routera klasy biznesowej wyłącznie po to, aby rozwiązać problem z aplikacją, która nie potrafi wznowić połączenia po zmianie adresu IP. Najpierw trzeba potwierdzić wymagania systemu. Rozbudowa sieci nie zastąpi poprawnej konfiguracji oprogramowania.

Kasa fiskalna, terminal i magazyn – dlaczego każde urządzenie inaczej reaguje na brak internetu?

Na stanowisku sprzedaży pracuje zwykle kilka powiązanych systemów: kasa rejestrująca lub drukarka fiskalna, aplikacja POS, terminal płatniczy oraz oprogramowanie magazynowo-księgowe. Dla pracownika tworzą jeden proces, ale technicznie są to odrębne elementy. Awaria internetu może zatrzymać każdy z nich na innym etapie.

W przypadku kas online trzeba przede wszystkim oddzielić ewidencjonowanie sprzedaży od komunikacji z Centralnym Repozytorium Kas (CRK). Zgodnie z art. 111 ust. 3a pkt 12 ustawy o VAT podatnik ma obowiązek zapewnić połączenie umożliwiające przesyłanie danych między kasą a CRK. Nie oznacza to jednak, że każda chwilowa przerwa internetowa automatycznie uniemożliwia wystawienie paragonu.

Art. 111 ust. 3ab tej ustawy rozróżnia dwa przypadki:

• Czasowa niemożność zapewnienia połączenia z przyczyn niezależnych od podatnika. Podatnik nadal prowadzi ewidencję sprzedaży i zapewnia połączenie niezwłocznie po ustaniu przeszkody.
• Trwała niemożność zapewnienia połączenia z przyczyn niezależnych od podatnika. Podatnik prowadzi ewidencję, a po uzyskaniu zgody właściwego naczelnika urzędu skarbowego zapewnia połączenie w ustalonych z nim odstępach czasu.

Nie należy więc zakładać uniwersalnego limitu kilkunastu minut, kilku godzin lub jednego dnia na przesłanie danych po awarii. Przepisy określają odrębne zasady zależnie od charakteru niemożności zapewnienia połączenia. Trzeba też uwzględnić właściwą dokumentację urządzenia fiskalnego.

Inna sytuacja występuje, gdy kasa przestaje w ogóle prawidłowo ewidencjonować sprzedaż. Art. 111 ust. 3 ustawy o VAT przewiduje wówczas, przy niemożności prowadzenia ewidencji z przyczyn niezależnych od podatnika, zastosowanie kasy rezerwowej. Gdy nie można prowadzić ewidencji również na kasie rezerwowej, sprzedaży nie wolno dokonywać. Braku możliwości fiskalizacji nie można zastąpić samym zapisaniem transakcji w ERP.

Przykład hipotetyczny: sklep wyposażono w samodzielną kasę online oraz komputer z systemem magazynowym. Podczas awarii internetu kasa pozostaje sprawna i pozwala wystawiać paragony, ale program magazynowy traci połączenie z centralnym serwerem. Sprzedaż fiskalna może być nadal możliwa, lecz rozchód magazynowy nie musi zostać od razu odnotowany w ERP. Jeżeli pracownik nie sprawdzi statusu dokumentu po przywróceniu połączenia, system może wykazywać nieprawidłowe stany.

W przypadku stanowiska korzystającego z drukarki fiskalnej sterowanej przez POS sytuacja może być mniej korzystna. Jeśli aplikacja nie potrafi utworzyć ani przekazać dokumentu bez serwera, sprawna drukarka nie oznacza automatycznie możliwości zakończenia sprzedaży. Wymaga to weryfikacji integracji oraz zasad pracy offline określonych przez dostawcę oprogramowania.

Osobny problem stanowią płatności kartą. Terminal zazwyczaj komunikuje się z infrastrukturą operatora płatności w celu obsługi autoryzacji. Jeżeli korzysta z sieci lokalnej sklepu, przełączenie WAN może przerwać trwającą komunikację. Terminal z własną kartą SIM może natomiast wykorzystywać osobną drogę transmisji, o ile urządzenie i umowa przewidują taką konfigurację.

Przykład hipotetyczny: klient płaci kartą 249 zł. Terminal wysłał żądanie autoryzacji, ale przed otrzymaniem odpowiedzi router przełączył internet na LTE. Na ekranie pojawia się komunikat o błędzie. Kasjer nie powinien automatycznie rozpoczynać drugiej identycznej transakcji. Pierwsza płatność mogła zostać zatwierdzona mimo braku potwierdzenia na terminalu. Należy sprawdzić jej status zgodnie z procedurą operatora, aby uniknąć podwójnego obciążenia.

Niektóre rozwiązania płatnicze obsługują określone formy przyjmowania transakcji offline, ale nie jest to funkcja uniwersalna. Warunki mogą obejmować ograniczenia kwotowe, typ urządzenia, rodzaj karty i ryzyko późniejszej odmowy autoryzacji. Transakcja przyjęta do późniejszego przetworzenia nie jest równoznaczna z ostatecznie zatwierdzoną płatnością. Jeżeli operator nie udostępnia takiego trybu, nie wolno zakładać, że terminal samodzielnie zapisze płatność do późniejszego rozliczenia.

Jeszcze bardziej skomplikowana bywa obsługa magazynu. W systemach ERP działających centralnie istotne są nie tylko przepustowość i dostęp do internetu, lecz także stan serwera, aktywna sesja użytkownika, VPN oraz sposób potwierdzania operacji.

Przykład hipotetyczny: ostatnia sztuka produktu znajduje się w magazynie sklepu. Kasjer rozpoczyna jej sprzedaż, a pracownik realizujący zamówienie internetowe próbuje równocześnie zarezerwować ten sam towar. Jeśli oba stanowiska pracują offline i lokalnie zatwierdzają operacje, po synchronizacji może ujawnić się konflikt. System musi mieć określone zasady rozstrzygania takich sytuacji, na przykład blokowania części operacji, przydzielania rezerwacji lub oznaczania dokumentów wymagających ręcznej kontroli.

Tryb offline jest użyteczny tylko wówczas, gdy został przewidziany i udokumentowany przez producenta konkretnego programu. Trzeba sprawdzić, czy obsługuje sprzedaż, rezerwacje, przyjęcia dostaw, zwroty, ceny promocyjne i aktualizację stanów. Niektóre aplikacje pozwalają wyłącznie na podgląd wcześniej pobranych danych, ale nie zapisują nowych operacji.

Decyzja zależy więc od modelu działania sklepu. Przy jednej kasie i lokalnej bazie produktów można skoncentrować się na sprawnym ewidencjonowaniu sprzedaży i kontroli płatności. Przy kilku sklepach korzystających z jednego ERP większe znaczenie ma spójność centralnych stanów, odporność VPN i bezpieczna synchronizacja. Nie ma sensu uruchamiać swobodnej sprzedaży offline, jeśli system nie potrafi później rozstrzygnąć, komu faktycznie przysługiwała ostatnia sztuka towaru.

Jak przetestować internet awaryjny, żeby po powrocie połączenia nie powstały błędy w zamówieniach i stanach magazynowych?

Najbardziej miarodajnym sprawdzianem nie jest test prędkości ani kontrolka aktywnego LTE na routerze. Trzeba przeprowadzić rzeczywistą operację sprzedaży i sprawdzić jej pełny przebieg – od utworzenia zamówienia, przez ewidencję fiskalną i płatność, aż po zapis w magazynie. Test powinien być zaplanowany poza godzinami szczytu i uzgodniony z osobami odpowiedzialnymi za system POS, ERP oraz urządzenia fiskalne.

Przykładowa procedura obejmuje sześć etapów:

1. Zapisz stan początkowy. Wybierz produkt testowy, sprawdź jego dostępny stan magazynowy, zanotuj numer zamówienia lub identyfikator operacji. Potwierdź, że kasa, terminal, POS i ERP pracują prawidłowo na podstawowym łączu.
2. Odłącz podstawowe WAN. Zasymuluj awarię internetu bez wyłączania routera i lokalnej sieci. Zmierz czas potrzebny na wykrycie problemu, przejście na LTE oraz ponowne działanie aplikacji. Osobno sprawdź DNS i zestawienie tunelu VPN.
3. Wykonaj zamówienie testowe. Utwórz operację na rzeczywistym stanowisku, stosując procedury systemu. Sprawdź rezerwację towaru, zapis sprzedaży i działanie urządzenia fiskalnego. Transakcje kartowe wykonuj wyłącznie według zasad dopuszczonych przez operatora płatności, najlepiej w przewidzianym środowisku testowym.
4. Sprawdź magazyn. Zweryfikuj, czy zamówienie jest widoczne na drugim stanowisku oraz czy rozchód został prawidłowo odnotowany. Jeśli program oficjalnie obsługuje offline, sprawdź kolejkę synchronizacji i zachowanie podczas konfliktu operacji.
5. Przywróć łącze podstawowe. Ustal, czy router powrócił na właściwą trasę, czy VPN działa ponownie oraz czy aplikacje prawidłowo odnowiły sesje. Nie zakładaj, że samo pojawienie się internetu oznacza zakończenie wszystkich wcześniejszych operacji.
6. Uzgodnij dokumenty. Porównaj liczbę zamówień, dokumentów fiskalnych, płatności i zmian magazynowych. Każda operacja powinna mieć jednoznaczny status: zatwierdzona, odrzucona, anulowana albo wymagająca wyjaśnienia.

Najczęściej pomijanym problemem jest operacja, której wynik pozostaje nieznany. Pracownik naciska „Zapisz”, połączenie się urywa, a program wyświetla błąd. Nie wiadomo, czy żądanie dotarło do serwera. Ponowne kliknięcie może utworzyć drugi dokument albo podwójnie zmniejszyć stan magazynowy.

W poprawnie zaprojektowanych integracjach ogranicza się takie ryzyko poprzez unikalne identyfikatory transakcji oraz idempotencję operacji. Mechanizm idempotencji pozwala rozpoznać powtórzone żądanie i uniknąć ponownego wykonania tej samej operacji, o ile system został do tego odpowiednio przygotowany. Gdy aplikacja nie ma takiej funkcji, potrzebna jest procedura sprawdzania statusu dokumentu przed jego ponownym wystawieniem.

Nie wolno też bezrefleksyjnie usuwać rzekomych duplikatów. Dwa podobne wpisy mogą oznaczać podwójne zamówienie, ale mogą również reprezentować różne etapy jednego procesu. Dokumenty fiskalne, płatności i zapisy księgowe wymagają właściwych procedur korekty. Ręczne kasowanie rekordów bez analizy zależności potrafi pogorszyć sytuację.

W większych instalacjach przydatne jest ustalenie konkretnych celów technicznych. Przykładowo sklep może przyjąć wewnętrzne wymaganie, aby nową operację sprzedaży można było rozpocząć najpóźniej 60 sekund po utracie podstawowego łącza. To cel projektowy, a nie gwarantowana właściwość routera czy wymóg prawny. Trzeba zmierzyć wynik podczas testów i potwierdzić, że wszystkie wymagane aplikacje odzyskują dostęp w tym czasie.

Osobno należy określić dopuszczalny czas przerwy i zakres danych, których utrata jest akceptowalna. W zarządzaniu ciągłością działania stosuje się pojęcia RTO, czyli docelowego czasu przywrócenia procesu, oraz RPO, czyli dopuszczalnego punktu odtworzenia danych. Dla dokumentów sprzedaży wymagających prawidłowej ewidencji i rozliczenia nie można jednak swobodnie przyjąć, że utrata kilku ostatnich transakcji jest normalnym kosztem awarii.

Trzeba również sprawdzić odporność na brak zasilania. Router LTE może działać na UPS, ale stanowisko kasowe przestanie funkcjonować, jeśli komputer, urządzenie fiskalne lub wymagany element sieci lokalnej pozostaną bez prądu. Terminal z własnym akumulatorem może pracować dłużej niż reszta stanowiska, lecz jego autonomia nie rozwiązuje problemu niedostępnego POS. W praktyce należy zasilać awaryjnie cały minimalny zestaw urządzeń potrzebnych do zakończenia transakcji, niekoniecznie wszystkie komputery i urządzenia w sklepie.

Testy należy powtarzać po zmianie operatora internetu, routera, konfiguracji sieci, serwera ERP oraz istotnych aktualizacjach oprogramowania. W sklepie o dużym ruchu kwartalne ćwiczenie awaryjne może być uzasadnione. Przy stabilnej, rzadko zmienianej instalacji częstotliwość można dobrać inaczej, na podstawie kosztu przestoju i ryzyka operacyjnego.

Najpierw trzeba usunąć pojedynczy punkt awarii, który faktycznie zatrzymuje sprzedaż. Jeśli problemem jest brak zasilania routera, zakup kolejnego abonamentu nie pomoże. Jeśli po przełączeniu WAN przestaje działać VPN, najpierw trzeba poprawić konfigurację tunelu. Jeżeli POS zapisuje podwójne zamówienia, priorytetem jest kontrola ponawiania i synchronizacji operacji. Dopiero po takim teście można uzasadnić zakup kolejnego urządzenia lub dodatkowej usługi internetowej.

FAQ – najczęstsze pytania o internet zapasowy w sklepie

Czy kasa fiskalna online może wystawiać paragony bez internetu?
Tak, czasowa utrata połączenia z CRK nie oznacza automatycznie zakazu ewidencjonowania sprzedaży. Kasa musi jednak działać prawidłowo, a podatnik ma obowiązek przywrócić połączenie zgodnie z art. 111 ust. 3ab ustawy o VAT. Możliwości konkretnego urządzenia i integracji z POS należy sprawdzić w dokumentacji.

Czy dwie karty SIM wystarczą, aby zabezpieczyć sklep przed awarią?
Niekoniecznie. Dwie karty mogą korzystać z tej samej sieci infrastrukturalnej. Lepszą niezależność zwykle daje połączenie różnych mediów, na przykład światłowodu z LTE lub 5G innego operatora. Konieczne jest również przetestowanie zasięgu i automatycznego przełączania.

Czy terminal płatniczy działa bez internetu?
Zależy od terminala, operatora i konfiguracji. Urządzenie może korzystać z alternatywnego łącza albo obsługiwać określony tryb offline. Nie każdy dostawca udostępnia taką funkcję, a transakcje przetwarzane później mogą zostać odrzucone. Warunki należy potwierdzić u operatora płatności.

Czy magazyn automatycznie zsynchronizuje sprzedaż po awarii?
Tylko wtedy, gdy używany program obsługuje taki mechanizm. Trzeba sprawdzić zasady przechowywania lokalnych operacji, ich kolejność, wykrywanie konfliktów oraz zabezpieczenia przed wielokrotnym zapisaniem dokumentu. Sam powrót internetu nie gwarantuje poprawnych stanów magazynowych.

Jak szybko router powinien przełączać się na internet zapasowy?
Nie ma jednego uniwersalnego czasu. Wynik zależy od ustawień kontroli łącza, konfiguracji WAN, czasu zestawienia połączenia zapasowego i zachowania aplikacji. Sklep powinien ustalić własny dopuszczalny czas przerwy i zweryfikować go w rzeczywistym teście.

Co sprawdzić jako pierwsze przed zakupem internetu awaryjnego?
Ustal, które urządzenia i usługi są niezbędne do zakończenia sprzedaży. Następnie zasymuluj awarię podstawowego WAN i sprawdź działanie POS, urządzenia fiskalnego, płatności oraz aktualizacji magazynu. Dopiero wynik tego testu pokaże, czy potrzebujesz nowego łącza, zmiany konfiguracji czy poprawy działania oprogramowania.

Więcej informacji na: https://speimex.pl