Kategoria: Baza wiedzy

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.

Zmiana biura rachunkowego nie zawsze oznacza, że poprzedni zespół kończy wszystkie czynności przed rozpoczęciem pracy następnego. Gdy nowe biuro przejmuje kadry i płace od października, poprzednie może jeszcze naliczać i sprawdzać wynagrodzenia za wrzesień.

W Comarch ERP Optima SaaS trzeba wtedy rozdzielić dwie kwestie: przekazanie aktualnych danych oraz organizację pracy w okresie przejściowym. Samo udostępnienie pliku kopii nie rozstrzyga, kto i gdzie będzie wprowadzał kolejne zmiany.

Niepełna kopia czy niewidoczne listy płac?

Jeżeli po odtworzeniu kopii nowe biuro widzi dane tylko do 2024 roku, nie przesądzamy od razu, że brakuje nowszych rozliczeń. Najpierw sprawdzamy, z której bazy wykonano kopię i jaki plik został odtworzony. Chodzi o potwierdzenie, że obie strony pracują z właściwym zestawem danych, a nie o szukanie winy po którejkolwiek stronie.

Następnie sprawdzamy filtry na listach płac: wybrany rok oraz ukrywanie list zamkniętych i zaksięgowanych. Nowsze listy mogą znajdować się w bazie, ale nie być widoczne przy aktualnych ustawieniach listy. Dopiero po tej kontroli można ocenić, czy problem dotyczy zawartości przekazanego pliku.

<screen>

Osobną kwestią jest rodzaj przekazywanej bazy. Podstawą przekazania jest baza firmowa. Przenoszenie bazy konfiguracyjnej warto wcześniej uzgodnić z administratorem, ponieważ zawiera ona ustawienia wspólne dla instalacji biura. Nie należy traktować jej jako kolejnego pliku do przekazania bez ustalenia zakresu takiej operacji.

Największe ryzyko powstaje jednak wtedy, gdy każde biuro zaczyna wprowadzać dane do własnej kopii. Te bazy nie będą się same synchronizować. Późniejsza kopia od poprzedniego biura nie oznacza więc automatycznego połączenia jego zmian z wpisami wykonanymi przez nowe biuro.

Jak przygotować kopię i sprawdzić jej odbiór?

Najpierw ustalamy moment przekazania. Zalecanym rozwiązaniem jest zakończenie naliczania i kontroli wrześniowych wynagrodzeń, wykonanie końcowej kopii i rozpoczęcie bieżącej pracy nowego biura na tej podstawie. Jeśli przez około 30 dni obie strony muszą wprowadzać dane, warto wcześniej uzgodnić z administratorem pracę na jednej wspólnej bazie, na osobnych operatorach. Administrator powinien też sprawdzić zgodność wersji Optimy i SQL Server przed odtworzeniem danych.

Kopię wykonujemy z poziomu Narzędzia → Kopia bezpieczeństwa → Utwórz teraz kopię na dysku lokalnym, z włączoną weryfikacją. Ten krok powinien dotyczyć bazy, której aktualność została wcześniej potwierdzona, już po sprawdzeniu wrześniowych naliczeń.

<screen>

Odbiór danych przez nowe biuro warto przeprowadzić w następującej kolejności:

1. Odtworzyć kopię najpierw pod nową nazwą. Pozwala to sprawdzić przekazany zestaw bez zastępowania bazy, do której mogły już trafić nowe wpisy.
2. Potwierdzić obecność bieżących danych. Sprawdzamy pracowników, ostatnie listy płac oraz historię rozliczeń, a następnie porównujemy ostatnie listy i ich kwoty z danymi poprzedniego biura.
3. Sprawdzić dane potrzebne do kolejnych wypłat. Kontrola powinna objąć urlopy, nieobecności i historię potrzebną do dalszego naliczania. Sama obecność ostatniej listy płac nie zastępuje tej weryfikacji.
4. Przekazać materiały spoza bazy. Dokumentację i pliki przechowywane osobno trzeba uwzględnić w przekazaniu niezależnie od kopii firmowej.

Przykładowo nowe biuro może rozpocząć wprowadzanie październikowych danych, podczas gdy poprzednie kończy jeszcze wrzesień na własnej kopii. Jeżeli następnie nowe biuro odtworzy kolejną kopię na tej samej bazie, może stracić swoje wpisy. Dlatego przed rozpoczęciem pracy trzeba uzgodnić, która baza będzie podstawą dalszej obsługi i jak zakończy się okres przejściowy. Kopie baz oraz przekazywane pliki mogą zawierać dane wrażliwe – nie należy ich publikować ani przesyłać bez zabezpieczenia.

Perspektywa ELTE-S

Przy przekazaniu kadr i płac rekomendujemy rozpisanie odpowiedzialności według konkretnych czynności, nie tylko według miesiąca obsługi. Szczególnie ważne są wrześniowe wynagrodzenia wypłacane w październiku. Trzeba ustalić, kto zajmuje się deklaracjami, przelewami, korektami i rozliczeniami rocznymi, aby żadnej czynności nie pominąć ani nie wykonać jej dwukrotnie.

Na zakończenie warto zapisać, jaką bazę przekazano, z jakiego dnia pochodziła i na jakim etapie były rozliczenia. Takie potwierdzenie porządkuje punkt przejęcia obsługi: obie strony mają wspólne odniesienie przy wyjaśnianiu późniejszych różnic lub ustalaniu, które zadania pozostały jeszcze do wykonania.

Jeśli planujesz zmianę biura, możemy pomóc uporządkować przekazanie danych i zasady pracy w okresie przejściowym. 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.