Miesiąc: październik 2026

Przy kolejnym logowaniu Comarch ERP Optima może poprosić o wybór modułów, mimo że wcześniej odbywało się to automatycznie. Jeśli po ich wskazaniu pojawia się informacja o braku dostępu, sam ponowny wybór nie wyjaśnia problemu.

W opisanej sytuacji korzystamy z fizycznego klucza HASP podłączanego do USB. Punktem wyjścia jest rozróżnienie między działającym Menadżerem Kluczy a widocznymi w nim modułami odczytanymi z klucza.

Najpierw sprawdzamy, czy Menadżer Kluczy widzi moduły

Przed kolejną próbą logowania sprawdzamy w Comarch Menadżer Kluczy, czy są widoczne moduły odczytane z HASP. Chodzi o potwierdzenie ich obecności, a nie jedynie o to, że sam Menadżer jest uruchomiony.

<screen>

Informacja „Menadżer Kluczy działa” nie rozstrzyga więc jeszcze, czy odczyt modułów przebiega prawidłowo. To ważne rozróżnienie: pozwala ustalić, co faktycznie zostało sprawdzone, zanim ponowimy logowanie do Optimy.

Przykładowo osoba prowadząca księgowość może uznać klucz za sprawny, ponieważ jest podłączony, a Menadżer działa. W takiej sytuacji kolejnym krokiem jest sprawdzenie widoczności modułów. Dopiero ten wynik daje konkretną informację do dalszej diagnostyki.

Restart po podłączeniu HASP i ponowna próba logowania

Zalecana kolejność działań jest następująca:

1. Włóż klucz HASP do portu USB.
2. Uruchom ponownie Comarch Menadżer Kluczy.
3. Sprawdź, czy widoczne są moduły odczytane z klucza.
4. Spróbuj ponownie zalogować się do Comarch ERP Optima.

Istotna jest kolejność: restart Menadżera wykonujemy po podłączeniu HASP. Po tej czynności sprawdzamy rezultat, zamiast zakładać, że samo ponowne uruchomienie przywróciło dostęp.

Jeżeli Optima nadal nie rozpoznaje modułów, opisane działania nie wystarczają do ustalenia przyczyny. W dalszej weryfikacji warto wyraźnie rozdzielić dwa wyniki: czy moduły są widoczne w Menadżerze oraz czy po restarcie udało się zalogować do programu.

Uszkodzenie klucza pozostaje możliwością, a nie rozpoznaniem. HASP jest urządzeniem fizycznym i może ulec awarii. Nie oznacza to jednak, że prośba o wybór modułów lub odmowa dostępu sama w sobie potwierdza uszkodzenie.

Perspektywa ELTE-S

Przed wykonaniem restartu warto zanotować wynik pierwszego sprawdzenia, a potem porównać go ze stanem po ponownym uruchomieniu Menadżera. Dzięki temu przy dalszej pomocy możemy odróżnić sytuację, w której odczyt modułów się zmienił, od tej, w której problem pozostał bez zmian.

Nie zaczynamy od założenia, że klucz trzeba wymienić. Najpierw wykorzystujemy prostą sekwencję sprawdzenia i restartu, a jeśli nie przyniesie efektu, opieramy dalszą weryfikację na jej wynikach.

Jeśli po tych czynnościach dostęp do modułów nadal jest niedostępny, pomożemy sprawdzić problem z odczytem klucza i logowaniem do Optimy. Porozmawiajmy o usprawnieniach.

Duża baza danych, długo generowany raport i niewielkie wykorzystanie zasobów serwera mogą sugerować, że wystarczy udostępnić programowi więcej mocy. Gdy proces zajmuje jeden rdzeń, a pamięć i dysk pozostają słabo obciążone, naturalnym pytaniem jest możliwość przyspieszenia pracy przez zmianę ustawień.

W Analizach BI współpracujących z Comarch ERP Optima samo obserwowanie wolnych zasobów nie wystarcza jednak do wyboru rozwiązania. Najpierw rozdzielamy dwa obszary: operację wykonywaną w BI oraz zapytania obsługiwane przez SQL Server.

Najpierw ustalamy, co ogranicza generowanie raportu

Nie ma ogólnego sposobu na wymuszenie wielordzeniowej pracy Analiz BI. Możliwość wykorzystania zasobów zależy od tego, gdzie występuje ograniczenie. Nie należy więc traktować ustawienia w Windows Server 2022 jako uniwersalnego rozwiązania dla każdego długo wykonywanego raportu.

Pierwszym celem diagnostyki jest ustalenie, czy czas zajmuje sama operacja w BI, czy zapytania wykonywane na bazie. Bez tego łatwo skupić się na ustawieniach serwera, mimo że sprawdzenia wymaga przede wszystkim konstrukcja raportu. Sam fakt, że Optima została już dostrojona, nie rozstrzyga jeszcze tej kwestii.

Przy długo generowanym raporcie najbardziej prawdopodobnym obszarem do weryfikacji jest ilość przetwarzanych danych. Warto porównać zakres potrzebny odbiorcy z zakresem faktycznie pobieranym przez raport. Szczególnie istotne jest to, czy obejmuje on konkretny okres, czy przetwarza całą dostępną historię.

Drugim punktem jest zawartość raportu. Sprawdzamy, czy ładowane elementy są rzeczywiście potrzebne do uzyskania oczekiwanego wyniku. Nie chodzi o usuwanie informacji na próbę, lecz o oddzielenie danych wymaganych do analizy od tych, które nie służą jej celowi. To mocna wskazówka diagnostyczna, ale bez sprawdzenia konkretnego raportu nie przesądza jeszcze o przyczynie opóźnienia.

Jak sprawdzić raport, pamięć SQL i utrzymanie bazy?

Zaczynamy od określenia oczekiwanego wyniku: jaki okres ma obejmować analiza i jakie informacje muszą się w niej znaleźć. Dopiero z takim punktem odniesienia można ocenić, czy raport wykonuje potrzebną pracę, czy przetwarza dane wykraczające poza rzeczywiste zapotrzebowanie.

1. Porównujemy okres analizy z zakresem danych raportu. Jeżeli potrzebny jest wybrany miesiąc, sprawdzamy, czy raport nie przetwarza również pozostałej historii.
2. Weryfikujemy potrzebne elementy. Ustalamy, które z nich są wykorzystywane w wyniku i czy raport nie ładuje dodatkowych, zbędnych informacji.
3. Sprawdzamy limit pamięci SQL Server. To osobny obszar względem samej operacji wykonywanej w BI.
4. Weryfikujemy utrzymanie bazy. Sprawdzamy, czy cyklicznie wykonywane są prace optymalizujące, takie jak reindeksacja.

W SQL Server można określić maksymalną ilość pamięci RAM. Warto zweryfikować ten limit, ale nie utożsamiać go z poleceniem wykorzystania całej dostępnej pamięci. Samo podniesienie wartości nie jest potwierdzeniem, że raport zacznie działać szybciej. Nie podajemy też jednej właściwej wartości bez sprawdzenia konkretnego środowiska.

<screen>

Przykładowo osoba przygotowująca miesięczne zestawienie może korzystać z raportu, który przetwarza dane ze wszystkich lat. Najpierw porównujemy jego zakres z potrzebnym miesiącem, następnie oceniamy przydatność ładowanych elementów. Dopiero wynik takiego sprawdzenia daje podstawę do dalszych decyzji, zamiast zakładania z góry, że brakuje rdzeni lub pamięci.

Osobno sprawdzamy cykliczne prace optymalizujące bazę. Reindeksacja jest wskazanym obszarem weryfikacji, a nie gwarancją usunięcia opóźnienia. Potwierdzenie, że takie prace są wykonywane, pozwala uwzględnić stan utrzymania bazy w dalszej ocenie problemu.

Perspektywa ELTE-S

Przed ograniczeniem zakresu raportu warto uzgodnić z jego odbiorcą, jakie dane rzeczywiście są potrzebne. Szybszy wynik nie będzie użyteczny, jeśli po zmianie zabraknie informacji wymaganych do analizy. Najpierw ustalamy więc kryteria poprawności, a potem oceniamy czas wykonania.

Rekomendujemy również rozdzielenie prób dotyczących raportu od zmian po stronie SQL Server. Wprowadzanie kilku zmian jednocześnie utrudni ustalenie, która z nich wpłynęła na czas generowania. Przy porównaniu zachowujemy ten sam oczekiwany wynik, aby nie pomylić poprawy wydajności ze zmianą zakresu analizy.

Jeśli chcesz ustalić, od czego zacząć sprawdzanie konkretnego raportu BI i jego zaplecza SQL, możemy pomóc uporządkować diagnostykę. Porozmawiajmy o usprawnieniach.

Raport sprzedaży zawierający serię, numer dokumentu, wartość i marżę pozwala przeglądać szczegóły sprzedaży. Gdy jednak zwijamy numery dokumentów, potrzebujemy innego widoku: podsumowania dla każdej serii, a nie kolejnych szczegółowych wierszy.

W takim zestawieniu chcemy uzyskać dwie dodatkowe informacje: ile dokumentów obejmuje dana seria oraz jaka jest ich średnia wartość sprzedaży. Sposób przygotowania tych wyników zależy od raportu, z którego korzystamy.

Funkcje agregacji a zmiana definicji raportu

Punktem wyjścia są funkcje agregacji dostępne w używanym raporcie. To w ich ustawieniach warto sprawdzić możliwość uzyskania oczekiwanych podsumowań. Nie należy z góry zakładać, że każda taka zmiana wymaga przebudowania zapytania.

Istotne jest rozróżnienie między szczegółem a podsumowaniem. Numer dokumentu służy do przeglądania poszczególnych dokumentów, natomiast liczba dokumentów i średnia wartość mają opisywać grupę, w tym przypadku serię. Dlatego rezultat trzeba ocenić również po zwinięciu numerów, a nie jedynie przy rozwiniętej liście.

Inną sytuacją jest konieczność zmiany definicji raportu standardowego i dodania w niej potrzebnych kolumn. Taka praca wymaga znajomości SQL oraz tabel Optimy. Sam opis oczekiwanego wyniku nie wystarcza do przygotowania właściwej zmiany bez sprawdzenia konkretnego raportu.

Jak sprawdzić agregacje i bezpiecznie ocenić wynik?

Na liście pól po prawej stronie kliknij prawym przyciskiem myszy i wybierz funkcje agregacji. To wskazane miejsce, od którego można rozpocząć pracę nad podsumowaniami.

<screen>

Następnie dobierz ustawienia agregacji pod kątem liczby dokumentów oraz średniej wartości sprzedaży dla serii. Nie podajemy jednej uniwersalnej konfiguracji: bez wglądu w raport nie można wskazać dokładnego zestawu ustawień, który zapewni oczekiwany rezultat.

<screen>

Weryfikację warto prowadzić w niewielkich krokach:

1. Zapisz wersję raportu przed rozpoczęciem zmian.
2. Sprawdź najpierw wynik dla jednej serii, której dokumenty możesz łatwo porównać z podsumowaniem.
3. Oceń osobno liczbę dokumentów i średnią wartość sprzedaży.
4. Zwiń numery dokumentów i sprawdź, czy podsumowanie nadal odpowiada oczekiwanemu widokowi.
5. Dopiero potem sprawdź zachowanie raportu przy większej liczbie poziomów zagłębienia.

Przykładowo osoba analizująca sprzedaż może zacząć od jednej serii i porównać wyświetloną liczbę z dokumentami widocznymi po rozwinięciu. Następnie może zweryfikować średnią na podstawie ich wartości. Taki test pozwala ocenić wynik przed zastosowaniem ustawień do szerszego zestawienia.

Przy większych zagłębieniach mogą pojawiać się błędy. Poprawny wynik na prostym poziomie grupowania nie daje więc pewności, że bardziej rozbudowany układ zachowa się tak samo. Zapisuj kolejne wersje, aby w razie problemu móc wrócić do wcześniejszego stanu.

Perspektywa ELTE-S

Przed zleceniem zmiany definicji raportu warto przygotować konkretny wzór oczekiwanego wyniku: wskazać serię, jej dokumenty oraz oczekiwaną liczbę i średnią. Dzięki temu możemy porównać rezultat z jednoznacznym przykładem, zamiast oceniać go jedynie po wyglądzie kolumn.

Jeżeli błąd pojawi się po rozbudowaniu grupowania, warto zachować także ostatnią poprawnie działającą wersję i odnotować zmianę, po której wystąpił problem. Ułatwia to rozdzielenie dwóch kwestii: poprawności samych obliczeń oraz zachowania raportu przy kolejnych poziomach zagłębienia.

Możemy wspólnie sprawdzić, czy oczekiwane podsumowanie da się uzyskać agregacjami, czy potrzebna jest praca nad definicją raportu. Porozmawiajmy o usprawnieniach.

Przy pobieraniu faktur zakupu z KSeF w Comarch ERP Optima może pojawić się problem wielokrotnego pobrania tego samego dokumentu. W takiej sytuacji naturalne jest pytanie, czy można włączyć blokadę, która zapobiegnie powtórzeniom.

W tym przypadku punktem wyjścia jest jednak sprawdzenie aktualizacji programu. Nie należy utożsamiać poprawki działania pobierania z dodatkowym ustawieniem, które użytkownik musi sam odnaleźć i włączyć.

Poprawka w automatycznych aktualizacjach Optimy

Comarch wydał w automatycznych aktualizacjach poprawkę eliminującą wielokrotne pobieranie tych samych dokumentów z KSeF. To do niej odnosimy dalsze działania przy opisanym problemie.

Najpierw sprawdzamy, czy poprawka została faktycznie zastosowana w używanej Optimie. Sama informacja o jej udostępnieniu nie potwierdza jeszcze stanu konkretnej instalacji. Bez tego sprawdzenia trudno ocenić, czy obserwowane powtórzenia dotyczą działania programu przed poprawką, czy występują również po jej zastosowaniu.

Następnie warto ustalić, czy problem nadal pojawia się przy kolejnym pobieraniu dokumentów. Jeśli tak, potrzebna jest dalsza weryfikacja konkretnego przypadku – nie należy z góry przypisywać mu przyczyny ani zakładać, że wystarczy zmienić niepotwierdzony parametr.

Przykładowo osoba prowadząca księgowość może zauważyć powtórzone dokumenty już po zastosowaniu aktualizacji. Warto wtedy rozróżnić dokumenty pobrane wcześniej od nowych powtórzeń. Sam widok istniejących duplikatów nie pozwala ocenić działania poprawki przy kolejnym pobieraniu.

Perspektywa ELTE-S

Przed porządkowaniem wcześniej pobranych dokumentów zalecamy oddzielić dwa zadania: sprawdzenie aktualnego działania pobierania oraz ocenę dokumentów, które już znajdują się w programie. Dzięki temu nie mieszamy weryfikacji poprawki z pracą nad skutkami wcześniejszego problemu.

Informacja o wydanej poprawce nie określa sposobu postępowania z istniejącymi powtórzeniami. Nie traktujemy jej więc jako potwierdzenia, że aktualizacja automatycznie je usunie lub uporządkuje.

Jeśli chcesz sprawdzić zastosowanie poprawki i ustalić dalsze kroki dla swojej instalacji Optimy, możemy pomóc w tej weryfikacji. Porozmawiajmy o usprawnieniach.

Przy księgowaniu zakupów w Comarch ERP Optima można zauważyć różnicę między informacją zapisaną w rejestrze VAT a danymi przeniesionymi do Księgi. Numer KSeF jest uzupełniony przy zakupie, ale brakuje go w zapisie księgowym.

Wątpliwości są zrozumiałe, szczególnie gdy przy sprzedaży numer pojawia się prawidłowo. W tej sytuacji trzeba jednak rozdzielić obsługę zakupów i sprzedaży, zamiast zakładać, że oba procesy działają identycznie.

Co wiadomo o przenoszeniu numerów KSeF z zakupów?

Zapisy w Księdze tworzone z rejestrów zakupu VAT nie przenoszą numerów dokumentów KSeF. Opisany przypadek dotyczy więc ograniczenia po stronie tego procesu w Optimie, a nie samego braku numeru na dokumencie źródłowym.

Obecność numeru w rejestrze zakupu VAT nie oznacza jeszcze, że zostanie on przeniesiony do Księgi. To dwa odrębne etapy pracy z dokumentem. Uzupełnienie danych na pierwszym etapie nie potwierdza obsługi ich przenoszenia na kolejnym.

Przykładowo osoba prowadząca księgowość może porównać zakup i sprzedaż, dla których numery KSeF są już zapisane w rejestrach VAT. Jeżeli po zaksięgowaniu numer pojawia się przy sprzedaży, a przy zakupie go brakuje, sama ta różnica nie uzasadnia szukania błędu we wprowadzeniu zakupu.

Jaki jest status rozwiązania problemu?

Problem został zgłoszony do Comarch, a jego realizacja jest przewidziana w następnych wersjach Optimy. Jest to informacja o planowanej zmianie, nie potwierdzenie, że została już udostępniona.

Nie ma potwierdzonego numeru wydania ani terminu wprowadzenia tej obsługi. Z tego powodu nie wskazujemy konkretnej aktualizacji jako rozwiązania i nie obiecujemy, że instalacja najnowszej dostępnej wersji usunie opisane ograniczenie.

Przed podjęciem działań warto sprawdzić, czy informacja o danym wydaniu programu potwierdza właśnie przenoszenie numerów KSeF z rejestrów zakupu VAT do Księgi. Ogólna informacja o zmianach dotyczących KSeF nie rozstrzyga jeszcze tego konkretnego przypadku.

Perspektywa ELTE-S

Przy planowaniu aktualizacji najpierw ustalamy, czy oczekiwana zmiana rzeczywiście obejmuje proces zakupowy. Pozwala to uniknąć sytuacji, w której aktualizacja zostaje potraktowana jako pewne rozwiązanie, mimo że nie potwierdzono zakresu poprawki.

Do późniejszej weryfikacji warto zachować przykład dokumentu, przy którym występuje rozbieżność. Po udostępnieniu odpowiedniej zmiany można na nim porównać rezultat, zamiast oceniać działanie zakupów na podstawie prawidłowego księgowania sprzedaży.

Jeśli chcesz ustalić, czy używana wersja Optimy obejmuje już tę zmianę, możemy pomóc w weryfikacji. Porozmawiajmy o usprawnieniach.