Problemy z komunikacją Comarch Optima z KSeF
Problemy z komunikacją Comarch Optima ↔ KSeF (od 22 września 2026)
Od 22 września 2026 u części użytkowników systemu Comarch ERP Optima wystąpiły poważne problemy z wymianą danych z Krajowym Systemem e-Faktur (KSeF). Dotyczy to zarówno wysyłania, jak i odbierania faktur. Szczególnie uciążliwe jest to w przypadku faktur terminowych, których nie da się przesłać do KSeF.
Komunikat błędu w Optimie
W programie pojawia się komunikat zbliżony do następującego:
„Upłynęła data ważności pakietu KSeF dla xxx dokumentów. Funkcja wymiany z KSeF została zablokowana. W celu wykupienia licencji kliknij w link.”
Licencja / pakiet KSeF został już wcześniej zakupiony i opłacony, mimo to system nadal blokuje komunikację. Problem leży po stronie oprogramowania Comarch – błąd w obsłudze aktywacji lub weryfikacji pakietu uniemożliwia prawidłowe odblokowanie funkcji wymiany z KSeF.
Skutki problemu
- Brak możliwości wysyłania faktur sprzedażowych (w tym faktur terminowych) do KSeF.
- Brak możliwości odbierania faktur zakupowych z KSeF.
- Ryzyko opóźnień w obiegu dokumentów i rozliczeniach VAT.
- Konieczność ręcznego monitorowania statusów i ewentualnego korzystania z trybów awaryjnych / offline (jeśli są dostępne w danej wersji Optimy).
Co robić w takiej sytuacji?
- Sprawdź status pakietu
W Optimie wejdź w konfigurację KSeF (najczęściej: System → Konfiguracja → Firma → Dane firmy → KSeF lub sekcja Pakiet KSeF na liście faktur). Zweryfikuj numer klucza/pakietu i liczbę wykorzystanych dokumentów. - Zaktualizuj program
Upewnij się, że pracujesz na wspieranej wersji (zalecane są aktualne wersje z serii 2026.x, m.in. 2026.4.1 / 2026.5.1 lub nowsze poprawki). Starsze wersje mogą niepoprawnie obsługiwać mechanizm pakietów. - Skontaktuj się z pomocą techniczną Comarch
Zgłoś problem, podając:- dokładną treść komunikatu błędu,
- numer pakietu / klucza KSeF,
- datę zakupu i aktywacji,
- wersję programu Optima,
- datę wystąpienia problemu (22.09.2026 i później).
- Tymczasowe rozwiązania
W przypadku braku możliwości wysyłki sprawdź, czy system pozwala na oznaczenie dokumentu w trybie awaryjnym / offline (zgodnie z aktualnymi zasadami KSeF i dokumentacją Comarch). Pamiętaj o terminach dosyłania faktur po ustaniu awarii.
Aktualny status
Problem ma charakter systemowy po stronie Comarch i dotyczy weryfikacji ważności pakietów KSeF mimo ich wcześniejszego zakupu. Pracujemy nad zebraniem zgłoszeń od klientów i przekazaniem ich do producenta. W razie potrzeby pomożemy w przygotowaniu zgłoszenia lub weryfikacji konfiguracji.
Jeśli napotkałeś ten błąd – skontaktuj się z nami. Podaj numer NIP firmy, wersję Optimy oraz dokładną treść komunikatu, a postaramy się jak najszybciej pomóc.
B1S – wsparcie systemów Comarch ERP Optima i integracji z KSeF.
Cyber Attack on MyDr – One of the Largest Data Breaches in Polish History. Detailed Incident Analysis
Cyber Attack on MyDr – One of the Largest Data Breaches in Polish History. Detailed Incident Analysis
In August 2026, Poland experienced one of the most serious cybersecurity incidents in the country’s history. The victim was MyDr, a provider of Electronic Medical Records (EDM) software used by thousands of healthcare facilities. According to official confirmations from the Ministry of Digital Affairs and findings of the Joint Cybersecurity Operations Center, unauthorized access affected data relating to nearly 19 million people (approximately 18,814,422 unique PESEL numbers according to the attackers’ claims) and more than 12,000 medical facilities.
Scale and Nature of the Breach
MyDr processes around 3 million visits and 2.7 million e-prescriptions monthly. The historical data (up to April 2024) stored in the company’s systems included, among other things:
- PESEL numbers,
- visit histories,
- prescription and medication information,
- contact details,
- potentially information about medical conditions.
The stolen database is estimated at over 2 TB (up to 2.5 TB according to the attackers). The data is historical — current operations of healthcare facilities, prescription issuance, and patient care were not disrupted. Systems were isolated, and the company is cooperating with authorities.
How the Incident Unfolded
- Detection and first signals – Around 10 August 2026, MyDr announced it was investigating a security incident. At the same time, individuals claiming to be the perpetrators contacted the cybersecurity site Zaufana Trzecia Strona, providing evidence (screenshots containing data of politicians and journalists).
- Official confirmation – On 12 August 2026, following a meeting of the Joint Cybersecurity Operations Center, Digital Affairs Minister Krzysztof Gawkowski officially confirmed the scale of the breach as “extraordinary.” The case is being handled by the Central Bureau for Combating Cybercrime, the National Prosecutor’s Office, the Personal Data Protection Office (UODO), special services, and the Ministry of Health.
- Response – Data is being progressively transferred to the bezpiecznedane.gov.pl portal, where citizens can check whether their information was affected. Immediate freezing of the PESEL number (e.g., via the mObywatel app) is strongly recommended.
How Did the Hackers Gain Access? (Attackers’ Version – Officially Unconfirmed)
According to the account given by the alleged perpetrators to Zaufana Trzecia Strona (not yet confirmed by authorities or MyDr), the initial attack vector was an XXE (XML External Entity) vulnerability related to the handling of PKCS#12 certificates. This allegedly allowed remote code execution (RCE). The attackers then obtained a GitHub API key leading to the system’s source code and subsequently gained access to the infrastructure running on AWS. They also demonstrated control over company tools (Jira, HubSpot CRM) and the ability to send SMS messages from the official company account.
Important note: The above scenario comes solely from the alleged attackers and has not been publicly confirmed by law enforcement or the company. A detailed investigation is ongoing. The motive appears to be financial (medical data is highly valuable on the black market for targeted phishing and identity theft) rather than sabotage.
Consequences and Recommendations
The incident highlights the risks associated with concentrating sensitive medical data with external software providers. Individual medical facilities remain the data controllers, while MyDr acted as a processor. Citizens should:
- check their status on bezpiecznedane.gov.pl,
- freeze their PESEL number,
- exercise heightened caution with emails/SMS related to medical services (phishing risk).
The investigation continues. We will update this article as official findings become available.
Źródła: komunikaty Ministerstwa Cyfryzacji, MyDr, raporty Zaufanej Trzeciej Strony, Business Insider, Spidersweb i inne wiarygodne media (stan na 13 sierpnia 2026).
Cyberatak na MyDr – jeden z największych wycieków danych w historii Polski. Szczegółowa analiza incydentu
Cyberatak na MyDr – jeden z największych wycieków danych w historii Polski. Szczegółowa analiza incydentu
W sierpniu 2026 roku Polska doświadczyła jednego z najpoważniejszych incydentów cyberbezpieczeństwa w historii kraju. Ofiarą ataku padła firma MyDr – dostawca oprogramowania do Elektronicznej Dokumentacji Medycznej (EDM) dla tysięcy placówek medycznych. Według oficjalnych potwierdzeń Ministerstwa Cyfryzacji oraz ustaleń Połączonego Centrum Operacyjnego Cyberbezpieczeństwa, nieuprawniony dostęp objął dane dotyczące blisko 19 milionów osób (dokładnie ok. 18 814 422 unikatowych numerów PESEL według deklaracji sprawców) oraz ponad 12 tysięcy placówek medycznych.
Skala i charakter wycieku
MyDr obsługuje systemy, przez które przechodzi około 3 mln wizyt i 2,7 mln e-recept miesięcznie. Dane historyczne (do kwietnia 2024 r.) przechowywane w systemach firmy zawierały m.in.:
- numery PESEL,
- historie wizyt,
- informacje o receptach i przyjmowanych lekach,
- dane kontaktowe,
- potencjalnie informacje o schorzeniach.
Objętość skradzionej bazy szacowana jest na ponad 2 TB (według sprawców nawet 2,5 TB). Dane mają charakter historyczny – bieżące funkcjonowanie placówek, wystawianie recept i opieka zdrowotna nie zostały zakłócone. Systemy zostały odizolowane, a firma współpracuje ze służbami.
Jak przebiegał incydent?
- Wykrycie i pierwsze sygnały – około 10 sierpnia 2026 r. MyDr poinformowała o prowadzeniu postępowania wyjaśniającego w sprawie incydentu bezpieczeństwa. Równolegle osoby podające się za sprawców skontaktowały się z redakcją serwisu Zaufana Trzecia Strona, przedstawiając dowody (zrzuty ekranu z danymi m.in. polityków i dziennikarzy).
- Potwierdzenie przez władze – 12 sierpnia 2026 r., po posiedzeniu Połączonego Centrum Operacyjnego Cyberbezpieczeństwa, minister cyfryzacji Krzysztof Gawkowski oficjalnie potwierdził skalę wycieku jako „nadzwyczajną”. Sprawą zajęły się Centralne Biuro Zwalczania Cyberprzestępczości, Prokuratura Krajowa, UODO, służby specjalne oraz Ministerstwo Zdrowia.
- Reakcja – dane sukcesywnie trafiają do serwisu bezpiecznedane.gov.pl, gdzie obywatele mogą sprawdzić, czy ich informacje zostały objęte incydentem. Zalecane jest natychmiastowe zastrzeżenie numeru PESEL (np. przez aplikację mObywatel).
Jak hakerzy dostali się do systemu? (wersja sprawców – niepotwierdzona oficjalnie)
Według relacji osób podających się za sprawców (przekazanej Zaufanej Trzeciej Stronie i niepotwierdzonej jeszcze przez służby ani MyDr) początkowym wektorem ataku była podatność typu XXE (XML External Entity) związana z obsługą certyfikatów PKCS#12. Miała ona umożliwić zdalne wykonanie kodu (RCE). Następnie atakujący mieli uzyskać klucz API do GitHuba, gdzie znajdował się kod źródłowy systemu, a później dostęp do infrastruktury działającej w chmurze AWS. Dodatkowo wykazali kontrolę nad narzędziami firmowymi (Jira, HubSpot CRM) oraz możliwość wysyłania SMS-ów z oficjalnego konta firmy.
Uwaga: Powyższy scenariusz pochodzi wyłącznie od rzekomych sprawców i nie został publicznie potwierdzony przez organy ścigania ani firmę. Trwa szczegółowe śledztwo. Motyw wydaje się finansowy (dane medyczne są szczególnie cenne na czarnym rynku do precyzyjnego phishingu i kradzieży tożsamości), a nie sabotażowy.
Skutki i rekomendacje
Incydent pokazuje ryzyko koncentracji wrażliwych danych medycznych u zewnętrznych dostawców oprogramowania. Administratorami danych pozostają poszczególne placówki medyczne, a MyDr działał jako procesor. Obywatele powinni:
- sprawdzić status na bezpiecznedane.gov.pl,
- zastrzec PESEL,
- zachować szczególną ostrożność wobec wiadomości e-mail/SMS związanych z leczeniem (ryzyko phishingu).
Sprawa jest w toku. Będziemy aktualizować informacje w miarę pojawiania się oficjalnych ustaleń.
Najprostszy i najlepszy sposób na uruchomienie lokalnego AI na Rocky Linux to Ollama.
Najprostszy i najlepszy sposób na uruchomienie lokalnego AI na Rocky Linux to Ollama.
Ollama pozwala szybko odpalać modele językowe (Llama, Gemma, Qwen, DeepSeek, Mistral itd.) lokalnie, bez chmury. Działa na CPU (wolniej) i automatycznie wykrywa GPU NVIDIA/AMD, jeśli masz sterowniki.
1. Instalacja Ollamy (1 komenda)
# Zaktualizuj system (opcjonalnie, ale zalecane)
sudo dnf update -y
# Na Rocky Linux 10 czasem potrzebne zstd
sudo dnf install -y zstd curl
# Instalacja oficjalna
curl -fsSL https://ollama.com/install.sh | sh
Po instalacji usługa startuje automatycznie. Sprawdź:
ollama --version
systemctl status ollama
2. Uruchomienie pierwszego modelu
# Mały i szybki model (dobry na start, nawet na CPU)
ollama run gemma3:4b
# albo inne popularne:
ollama run llama3.2 # 3B
ollama run qwen2.5:7b
ollama run deepseek-r1:8b # dobre rozumowanie
ollama run llama3.1:8b
Przy pierwszym uruchomieniu model się pobierze. Potem możesz z nim normalnie rozmawiać w terminalu. Wyjście: /bye lub Ctrl+D.
3. Przydatne komendy
ollama list # lista zainstalowanych modeli
ollama pull nazwa_modelu # tylko pobierz, bez uruchamiania
ollama rm nazwa_modelu # usuń model
ollama serve # jeśli chcesz ręcznie odpalić serwer
API działa na http://127.0.0.1:11434 (kompatybilne z OpenAI).
4. GPU (NVIDIA) – opcjonalnie, ale mocno przyspiesza
Jeśli masz kartę NVIDIA:
# EPEL + CRB
sudo dnf install -y epel-release
sudo dnf config-manager --set-enabled crb
# Repo NVIDIA (dostosuj do swojej wersji Rocky – 9 lub 10)
# Dla Rocky 9:
sudo dnf config-manager --add-repo https://developer.download.nvidia.com/compute/cuda/repos/rhel9/x86_64/cuda-rhel9.repo
# Dla Rocky 10:
# sudo dnf config-manager --add-repo https://developer.download.nvidia.com/compute/cuda/repos/rhel10/x86_64/cuda-rhel10.repo
sudo dnf install -y kernel-devel-matched kernel-headers
sudo dnf install -y nvidia-open # lub cuda-drivers
sudo reboot
Po restarcie sprawdź:
nvidia-smi
Ollama powinna sama wykryć GPU.
Alternatywy
| Narzędzie | Poziom trudności | Kiedy wybrać |
|---|---|---|
| Ollama | Najłatwiejsze | Szybki start, chat, API |
| LM Studio | Łatwe (GUI) | Preferujesz graficzny interfejs |
| llama.cpp | Średnie | Maksymalna optymalizacja na CPU |
| vLLM / TGI | Zaawansowane | Produkcja, wiele użytkowników |
Strona 2 z 126
