KSeF 2026 ujawnia luki w infrastrukturze ERP w MŚP
Data: 2 grudnia, 2025
Artykuł sponsorowany
Od lutego 2026 Krajowy System e-Faktur jest obowiązkowy dla większości polskich firm. Od tego momentu tempo aktualizacji systemów ERP w polskich MŚP wzrosło skokowo – Soneta dla enova365 wydała w pierwszym kwartale cztery wersje przepisowe, Comarch dla ERP Optima utrzymuje kwartalny cykl wydań i dokłada hotfixy między nimi, kolejne zmiany w schemie FA(3) są zapowiedziane na drugą połowę roku. Dla firmy zatrudniającej kilkanaście osób i używającej ERP do fakturowania oznacza to, że w ciągu roku infrastruktura pod system księgowy przechodzi średnio pięć-sześć aktualizacji. W 2022 były to dwie-trzy.
Od kilkunastu lat pracuję z firmami z sektora MŚP nad ich infrastrukturą IT – głównie pod systemy finansowo-księgowe. Pierwszy kwartał 2026 był z tej perspektywy kwartałem weryfikacji: u jednych klientów wszystko przeszło bez zgrzytu, u innych kolejne wersje przepisowe odsłoniły zaniedbania, które przez lata były niewidoczne. Przy pierwszej, drugiej wersji przepisowej wszystko jeszcze działało. W marcu i kwietniu 2026 zaczęły się telefony, które w mojej branży określa się mianem „sezonu nagłych spraw”: księgowa nie może zalogować się do systemu dzień przed terminem JPK, konwersja bazy przerywa się w połowie z błędem, którego nikt wcześniej nie widział, integracja z KSeF po aktualizacji pokazuje pustą listę faktur. Po dwóch miesiącach obserwacji u nowych klientów, którzy zgłaszali się właśnie wtedy, wyłoniły się cztery konkretne wzorce.
Wzorzec 1: baza SQL Express – gdzie zaczyna boleć brak wsparcia IT
Scenariusz z marca 2026 u klienta obsługującego magazyn średniej wielkości: Optima w wersji 2025.3 działa poprawnie, baza produkcyjna zajmuje 8,4 GB. Rozpoczęcie aktualizacji do 2026.0 z nową obsługą KSeF. Po około czterdziestu minutach konwersja zatrzymuje się z komunikatem o braku miejsca w pliku bazy. Baza nie urosła gwałtownie – po prostu konwersja tworzy pliki tymczasowe, przebudowuje indeksy i chwilowo potrzebuje więcej miejsca niż sama baza. Twardy limit 10 GB dla pojedynczej bazy w SQL Server Express sprawił, że operacja została przerwana w połowie.
Efekt: baza w stanie niespójnym, system nie startuje, z backupu sprzed 14 godzin (robionego w nocy) zostały stracone wszystkie faktury wystawione od porannego logowania. Rozwiązanie – migracja silnika na SQL Server Standard i ponowienie aktualizacji z backupu – zajęło sześć godzin w oknie od 15:00 do 21:00. Dla firmy oznaczało to pół dnia księgowości na telefonach z klientami, tłumaczącej im, dlaczego faktury przyjdą dzień później.
Do tego klienta mój zespół dołączył dopiero po incydencie – był jednym z tych, gdzie ktoś wewnątrz firmy „ogarniał IT sam”, bo „to proste, działa od lat”. W instalacjach objętych stałą obsługą informatyczną limit SQL Express jest standardowym elementem monitoringu od pierwszego dnia. Migrację na Standarda planuje się, gdy baza przekracza 7 GB, a nie gdy wali się konwersja.
Mechanika SQL-owa jest identyczna w enovie i w Optimie – problem ten sam, różne tylko nazwy tabel w komunikatach błędów. Szczegółowe omówienie limitów SQL Express i momentu, w którym zaczynają boleć pod konkretnym ERP, znajdzie czytelnik w naszym osobnym materiale o infrastrukturze pod enova365.
Wzorzec 2: Menadżer Kluczy i reguła firewalla, której nikt nie pamiętał
Comarch ERP Optima ma komponent, który wielu klientów traktuje jako element instalacji „na raz” – Menadżera Kluczy. Jest to osobna usługa Windows (techniczna nazwa: ComarchML), odpowiedzialna za autoryzację licencji. Klucze wirtualne, które dziś są standardem, wymagają kontaktu z serwerami Comarchu (ml.comarch.pl, erp.comarch.pl) co najmniej raz na 24 godziny. Jeżeli Menadżer Kluczy nie może się połączyć, moduły przestają być pobierane, a aplikacja przechodzi w tryb startowy z ograniczeniem 30 dni rozpiętości dat – czyli praktycznie nie da się wystawiać nowych dokumentów.
Luty 2026: klient, u którego zewnętrzna firma zrobiła „przegląd bezpieczeństwa sieci” i wdrożyła politykę firewalla „domyślnie blokuj ruch wychodzący”. Optima działała normalnie jeszcze przez dwa dni, bo moduły były w cache. Trzeciego dnia rano – pięć stanowisk nie może się zalogować, w logu Menadżera Kluczy od 48 godzin komunikat o braku połączenia z serwerami Comarchu. Przyczyną było blokowanie portów TCP 80 i 443 w wychodzących regułach, bez wyjątku dla adresów Comarchu.
Ta sytuacja pokazuje typową lukę we wsparciu IT firm, w których cyberbezpieczeństwo prowadzi jedna osoba lub firma, a utrzymanie aplikacji biznesowych – druga. Zmiana na firewallu była sensowna sama w sobie; brak koordynacji z osobą odpowiedzialną za aplikacje spowodował, że sensowna zmiana zatrzymała firmę.
Najboleśniejszy przypadek z tej wiosny: średniej wielkości firma handlowa, enova365 na SQL Server Standard, baza o wielkości 70 GB z kilkuletnią historią dokumentów handlowych i kadr. Aktualizacja 2512.x, nieudana konwersja spowodowana konfliktem z dodatkiem partnerskim na module magazynowym. Rozwiązanie standardowe – odtworzenie bazy z backupu sprzed aktualizacji, aktualizacja dodatku, ponowna konwersja. Na papierze proste.
Okazuje się, że backup był wykonywany codziennie, ale trafiał na ten sam dysk serwera, na którym leży baza. Dysk pełny od kilku tygodni (wcześniej nikt nie zauważył, bo zadanie backupu raportowało „Success” przy każdej próbie, mimo że plik nie powstawał poprawnie). Ostatni kompletny backup – sprzed siedmiu tygodni. Dwie doby pracy z partnerem wdrożeniowym, żeby doprowadzić aktualną bazę do stanu, w którym konwersja w ogóle przechodzi – plus koszty asysty producenta.
Ten scenariusz jest typowy dla firm, w których backupy robi się „bo się robi”, a nikt ich nie testuje. Zasada 3-2-1 (trzy kopie, na dwóch nośnikach, jedna offsite), monitoring stanu zadań, okresowe testy odtwarzania – to minimum, które trzeba mieć zweryfikowane zanim przyjdzie pierwsza trudna aktualizacja. Temat nowoczesnego backupu rozwinąłem w osobnym materiale; tutaj wystarczy uwaga, że backup, którego nie sprawdzono, nie jest backupem – jest fałszywym poczuciem bezpieczeństwa.
Wzorzec 4: brak osoby odpowiedzialnej
Ostatni wzorzec nie jest techniczny. To rozmowa, którą przeprowadziłem w kwietniu z właścicielką firmy zatrudniającej 18 osób.
„Kto u Państwa odpowiada za infrastrukturę pod system?” – „Adam, nasz handlowiec, zna się na komputerach.” „Adam jest w firmie na etat?” – „Tak, ale on ma swoje zadania handlowe.” „Co się dzieje, gdy Adama nie ma?” – „Trudniej.”
Dopóki aktualizacje ERP w polskich MŚP wydarzały się raz-dwa razy w roku, tego rodzaju wsparcie IT ad hoc sprawdzało się wystarczająco. W rytmie pięciu-sześciu aktualizacji rocznie, z których każda wiąże się z konwersją bazy, oknem serwisowym, koordynacją z partnerem wdrożeniowym i ryzykiem cofnięcia do backupu – model „handlowiec, który zna się na komputerach” przestał wystarczać.
Decyzja, kto realnie odpowiada za infrastrukturę ERP, nie musi oznaczać zatrudniania administratora na etat. Realne opcje dla firmy z sektora MŚP to: wewnętrzny informatyk (jeden etat, obsługuje też stacje, sieć, serwery, drukarki), outsourcing IT (zewnętrzny zespół, który przejmuje rolę działu IT w całości), albo model hybrydowy (wewnętrzny helpdesk + zewnętrzna obsługa IT dla infrastruktury i projektów). Która z tych opcji ma sens, zależy od wielkości firmy, budżetu i stopnia złożoności środowiska – ale każda z nich jest lepsza niż brak jasno wskazanej odpowiedzialności.
Co można zrobić teraz
Infrastruktura ERP w 2026 roku przestała być „zainstaluj raz, aktualizuj raz w roku”. Tempo wymuszonych zmian przepisowych, rosnąca złożoność integracji z KSeF i większe znaczenie ciągłości działania (firma, która nie wystawi faktur przez trzy dni, realnie traci klientów) sprawiają, że infrastrukturą trzeba się zajmować aktywnie, nie reaktywnie.
Trzy rzeczy, które zarząd firmy z sektora MŚP może zweryfikować bez konsultacji z IT:
Kto odpowiada u Was za infrastrukturę ERP z imienia i nazwiska. Jeżeli odpowiedź zaczyna się od „chyba” albo „zazwyczaj”, to jest pierwszy sygnał do zmiany. Odpowiedzialność za infrastrukturę biznesową wymaga jasnego właściciela, nie rozproszonej nadziei.
Kiedy ostatnio ktoś w firmie odtworzył bazę z backupu na drugi serwer i sprawdził, czy system na niej startuje. Jeżeli nigdy – nie macie backupu, macie plik o takiej nazwie. Różnica między jednym a drugim ujawnia się w momencie, w którym jest już za późno.
W jakiej wersji SQL Server stoi Wasza baza i ile ona zajmuje. Jeżeli SQL Server Express i baza ponad 7 GB – planujcie migrację. Jeżeli SQL Server 2016 i wsparcie rozszerzone kończy się 14 lipca 2026 – planujcie migrację. Jeżeli nie wiecie, w jakiej wersji – to odpowiedź sama w sobie.
Z tych trzech odpowiedzi bardzo szybko wynika, czy obecna obsługa informatyczna wystarczy pod rytm aktualizacji ERP w 2026, czy warto z kimś usiąść i zaplanować zmiany zanim przyjdzie kolejna wersja przepisowa.
O autorze
Damian Cikowski – współzałożyciel Helpwise IT, firmy świadczącej obsługę informatyczną i outsourcing IT dla polskich MŚP. Pełne bio: helpwise.pl/team/damian-cikowski.
Źródła
Ministerstwo Finansów, Krajowy System e-Faktur – harmonogram obowiązkowego wdrożenia, gov.pl
Microsoft Learn, Editions and supported features of SQL Server 2022, learn.microsoft.com
Soneta, Aktualne wersje systemu enova365, enova.pl
