Miesiąc: październik 2026

W Handlu jest jedna faktura sprzedaży, ale na liście faktur z KSeF widać dwie pozycje. Numer faktury, dane i numer referencyjny są identyczne. Taki widok może budzić obawę, że dokument został wysłany dwukrotnie.

W tej sytuacji rozróżniamy jednak duplikat na liście w programie od dwóch odrębnych dokumentów przyjętych przez KSeF. To ważne, ponieważ informacja o błędzie wyświetlania listy nie rozstrzyga sama w sobie o stanie dokumentów w KSeF.

Jakiego błędu dotyczy poprawka Comarch?

Opisany problem został rozpoznany jako błąd Comarch ERP Optima. Comarch wydał do niego poprawkę do wersji 2026.5.1, opisaną jako „KSeF – duplikaty na liście faktur z KSeF” (ID: 373023).

Nazwa poprawki wskazuje zakres problemu: powielone pozycje na liście faktur z KSeF. Nie należy zastępować tego opisu stwierdzeniem, że Optima na pewno wysłała fakturę dwa razy. To dwa różne rozpoznania, a potwierdzona informacja dotyczy pierwszego z nich.

Nie wyciągamy też z samego widoku listy wniosków o konieczności korygowania faktury. Informacja o tej poprawce nie zawiera instrukcji dotyczącej korekt ani postępowania z dwoma odrębnymi dokumentami w KSeF.

Co sprawdzić w używanej Optimie?

Najpierw sprawdzamy wersję programu oraz to, czy została zastosowana poprawka o ID 373023. Przy zgłoszeniu problemu warto podać jej pełną nazwę – pozwala to jednoznacznie wskazać, o który błąd chodzi.

Sama informacja o używaniu wersji 2026.5.1 nie zastępuje potwierdzenia zastosowania poprawki. Komunikat dotyczy poprawki do tej wersji, dlatego oba elementy trzeba rozpatrywać osobno. Jeśli używana jest inna wersja, sposób dalszego działania wymaga sprawdzenia przed zmianą programu.

Przykładowo osoba prowadząca księgowość widzi dwa identyczne wpisy i ustala, że firma pracuje na Optimie 2026.5.1. Następnym krokiem jest potwierdzenie obecności wskazanej poprawki, a nie uznanie, że sam numer wersji wyklucza opisany błąd.

Dostępna informacja nie określa procedury instalacji ani tego, co stanie się z duplikatami widocznymi przed zastosowaniem poprawki. Nie obiecujemy więc, że jej wdrożenie automatycznie uporządkuje istniejącą listę. Ten zakres trzeba potwierdzić przy obsłudze konkretnego zgłoszenia.

Perspektywa ELTE-S

Przed zmianą programu warto zanotować stan wyjściowy: w Handlu jest jeden dokument, a na liście faktur z KSeF są dwie identyczne pozycje. Taki opis ułatwi późniejsze sprawdzenie, czy zgłaszany objaw nadal występuje, bez mieszania go z innymi problemami dotyczącymi wysyłki.

Jeżeli po zastosowaniu poprawki duplikaty pozostają widoczne, warto kontynuować zgłoszenie z numerem poprawki i opisem aktualnego stanu. Nie zakładamy wówczas ani nieskuteczności poprawki, ani potrzeby ręcznego usuwania dokumentów bez dalszej weryfikacji.

Możemy pomóc ustalić stan aktualizacji Optimy i zakres dalszego sprawdzenia tej listy. Porozmawiajmy o usprawnieniach.

Próba przeniesienia faktur do rejestru VAT w Comarch ERP Optima może zakończyć się komunikatem: „Nie dodano dokumentu XYZ do rejestru VAT”. Gdy część dokumentów przechodzi poprawnie, a część nie, sam wynik operacji nie wyjaśnia jeszcze, co je różni.

Najpierw rozdzielamy dwie kwestie: informację o nieudanym dodaniu dokumentu oraz rozpoznanie przyczyny. Komunikat potwierdza pierwszą z nich, ale nie wskazuje jednego konkretnego błędu. Punktem wyjścia do dalszego sprawdzenia są więc dokumenty i ich porównanie.

Co wynika z komunikatu, a czego nie należy zakładać?

Nie ma podstaw, by na podstawie samej treści komunikatu uznać, że problem powoduje określona data, stawka VAT albo kontrahent. Przyczyna może zależeć od rodzaju faktury i konfiguracji programu. Każdy z tych obszarów wymaga weryfikacji, a nie przypisania mu z góry roli źródła błędu.

Najbardziej przydatnym punktem odniesienia będzie podobny dokument, który został poprawnie dodany do rejestru VAT. Porównanie przypadkowych faktur może pokazać wiele różnic, ale niekoniecznie pomoże ustalić, które z nich mają znaczenie dla analizowanej sytuacji.

Warto też ustalić zakres problemu. Czy nie przenoszą się dokumenty wybranych kontrahentów? Czy trudność dotyczy określonych faktur, podczas gdy inne dokumenty tych samych kontrahentów przechodzą poprawnie? Takie rozróżnienie pomaga uporządkować dalszą diagnostykę, lecz samo w sobie nie jest jeszcze rozpoznaniem przyczyny.

Jak porównać fakturę odrzuconą z poprawnie przeniesioną?

Zaczynamy od jednej faktury, której nie udało się dodać, i podobnej faktury przeniesionej poprawnie. Następnie sprawdzamy kolejno:

1. Typ dokumentu – ustalamy, czy porównywane faktury są tego samego rodzaju. Jeśli nie, uwzględniamy tę różnicę w dalszej analizie.
2. Daty – porównujemy daty na obu dokumentach. Nie zakładamy jednak, że wykryta różnica automatycznie wyjaśnia komunikat.
3. Stawki VAT – sprawdzamy, jakie stawki występują na fakturze, która się nie przenosi, i na dokumencie odniesienia.
4. Rejestr VAT – porównujemy rejestr, do którego mają trafić dokumenty, aby uwzględnić go w ocenie różnic.
5. Wcześniejsze zaksięgowanie – weryfikujemy, czy dokument objęty komunikatem nie został już wcześniej zaksięgowany.

To obszary do sprawdzenia, a nie lista potwierdzonych przyczyn. Samo znalezienie różnicy nie oznacza jeszcze, że należy zmienić dane faktury. Trzeba najpierw ocenić ją w kontekście rodzaju dokumentu i konfiguracji Optimy.

Przykładowo osoba prowadząca księgowość zauważa, że nie przeniosła się jedna z kilku podobnych faktur. Zamiast od razu zmieniać jej daty, wybiera poprawnie dodany dokument i porównuje wskazane elementy. Następnie sprawdza pozostałe nieprzeniesione faktury, aby ustalić, czy powtarza się w nich ta sama różnica.

Jeżeli porównanie nie wyjaśni sytuacji, dalsze sprawdzenie powinno uwzględnić konkretny rodzaj faktury i konfigurację programu. Bez tych informacji nie warto wskazywać jednej przyczyny ani proponować zmiany ustawień na próbę.

Perspektywa ELTE-S

Przed wprowadzaniem zmian warto zachować opis stanu wyjściowego: którego dokumentu dotyczył komunikat, z jaką poprawną fakturą go porównano i jakie różnice zauważono. Dzięki temu dalsza analiza nie opiera się wyłącznie na pamięci osoby wykonującej operację.

Nie traktujemy poprawnie przeniesionej faktury jako wzorca, do którego trzeba mechanicznie dopasować pozostałe. Dokumenty mogą zasadnie różnić się danymi. Porównanie ma pomóc znaleźć zależność, a nie zastąpić ocenę poprawności zapisów.

Możemy pomóc uporządkować porównanie dokumentów i sprawdzić konfigurację związaną z ich przenoszeniem do rejestru VAT. Porozmawiajmy o usprawnieniach.

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.