Przed przystąpieniem do aktualizacji wersji oprogramowania Comarch ERP oraz Comarch Retail należy zapoznać się ze zmianami, które zostały wprowadzone między wersjami.

W tym artykule zostały opisane zmiany które powinny zostać zweryfikowane przed podniesieniem wersji.

W artykule Proces aktualizacji są opisane procesy oraz zmiany, które powinny zostać wykonane lub zweryfikowane w celu prawidłowego działania oprogramowania.

Dodatkowo zalecane jest zapoznanie się z:

• Artykułami w kategorii Nowości i zmiany – w tym miejscu można znaleźć istotne zmiany wprowadzone w oprogramowaniu oraz opis nowych funkcjonalności
• Artykułami w kategorii Skalowalność sprzętowa. Wymagania sprzętowe oraz informacje na temat wymaganego oprogramowania aktualizowane są co wersję.
• Biuletynem technicznym Wydajność i praca terminalowa dostępnym na stronach walidowanych dla Partnerów.

Podniesienie testowe

Przed aktualizacją wersji na środowisku produkcyjnym zalecane jest przeprowadzenia testowego podniesienia środowiska na testowych serwerach oraz dokładna weryfikacja działania systemu wraz z rozszerzeniami.

Najnowsze poprawki

Przed podniesieniem środowiska należy poprosić Asystę Techniczną o udostępnienie najnowszych poprawek do wersji, na którą będzie aktualizowane oprogramowanie. Dostarczone poprawki należy w pierwszej kolejności przetestować na przygotowanym środowisku testowym.

Aktualizacja Microsoft SQL Server oraz sprawdzenie collation

Przed migracją należy zweryfikować, czy posiadana wersja MS SQL Server jest zgodna z wymaganiami instalowanej wersji.

Każda instancja Microsoft SQL Server, z której korzysta system Comarch ERP Altum lub Comarch Retail powinna być zaktualizowana o najnowsze Service Packi. Dotyczy to zarówno środowiska bazodanowego Comarch ERP Altum jak i stanowisk Comarch Retail POS.

Należy upewnić się, że wartość collation serwera SQL jest taka sama jak wartość collation firmowej bazy danych i jest to Latin1_General_CI_AS lub Polish_CI_AS. Jeżeli collation serwera i bazy danych różnią się, to mogą występować błędy, za które firma Comarch nie ponosi odpowiedzialności.

Migracja środowiska na nowy serwer SQL.

Po przeniesieniu baz na nową instalację MS SQL Server należy pamiętać, że nowa instalacja jest czystym środowiskiem, a bazy danych nie przechowują takich obiektów m.in. jak job, maintenance plan, użytkownicy, role czy uprawnienia. Następstwem migracji na nowy serwer jest przeprowadzenie pełnej konfiguracji serwera SQL łącznie z dodaniem użytkowników będących na bazie danych do serwera SQL oraz ponowne zmapowanie ich z wybraną bazą danych.

Zmiany związane z konwersją bazy konfiguracyjnej i firmowej

Od wersji 2015.5 systemu Comarch ERP Altum dodana została informacja o dacie produkcji. Jest ona dostępna z poziomu System Konfiguracja O programie.

Od wersji 2015.5 przed rozpoczęciem konwersji bazy konfiguracyjnej wyświetlane jest okno informacyjne, w którym użytkownik ma możliwość uzyskania szczegółowych informacji na temat dokonywanej konwersji.

Przed wykonaniem konwersji bazy firmowej również wyświetlane jest okno dotyczące konfigurowania przebiegu konwersji.

Użytkownik ma do wyboru:

• wykonanie kopii bezpieczeństwa i konwersji bazy (wartość domyślna)
• konwersji bazy – w tym przypadku nie zostanie wykonania kopia bezpieczeństwa
• oraz reindeksacji bazy danych po zakończeniu konwersji (zalecane)

Istnieje możliwość sprawdzenia daty ważności licencji poprzez wybranie przycisku [Sprawdź datę ważności]. Po uzupełnieniu serwera oraz numeru klucza i wybraniu przycisku [Sprawdź] wyświetlona zostanie data ważności.

Po wybraniu przycisku [Kontynuuj] zapisane zostaną parametry logowania a okno zostanie zamknięte. Użytkownik powróci do okna konwersji. Aby dokonać konwersji bazy danych, należy wybrać przycisk [Wykonaj].

Podczas logowania do systemu weryfikowana jest data ważności systemu określona w kluczu licencyjnym:

Jeżeli data ważności w kluczu jest wcześniejsza od daty aplikacji, użytkownik nie zaloguje się do systemu. Po zamknięciu okna automatycznie otwarte zostanie okno Wybór serwera licencji, w którym użytkownik powinien wskazać inny serwer/klucz do zalogowania.

Jeśli podany klucz posiada datę ważności wcześniejszą od daty produkcji, ponownie wyświetli się okno z informacją.

Nowa usługa licencjonowania

Począwszy od wersji 2015 obowiązuje nowy sposób licencjonowania. Przed migracją należy skontaktować się z Asystą Comarch w celu pobrania nowych kluczy licencyjnych.

Od wersji 2018.2 konieczna jest aktualizacja Menadżera Kluczy do najnowszej wersji ze względu na dodane procedury dotyczące podpisu elektronicznego, który jest weryfikowany przy sprawdzaniu licencji POS.

Weryfikacja działania wydruków

Ze względu na zmiany między wersjami, należy zweryfikować poprawność działania niestandardowych wydruków na testowym zaktualizowanym środowisku.

Zmiana w tabeli [Dictionaries].[TranslationValues]

Od wersji 2018.1.1 zmieniono ilość przechowywanych znaków w polu Value w tabeli [Dictionaries].[TranslationValues] z 1000 do 2000 znaków. Przed konwersją bazy należy zweryfikować widoki oraz rozszerzenia pod kątem tej zmiany.

Poniżej znajduje się opis czynności, które należy wykonać w trakcie aktualizacji Comarch ERP Altum do najnowszej wersji. Dodatkowo wykazane są zmiany, które mogą mieć wpływ na dotychczasowe działanie systemu.

Aktualizacja Comarch ERP Auto Update do najnowszej wersji na wszystkich stanowiskach

1. Należy włączyć usługę Comarch ERP Auto Update Service (jeśli jest wyłączona)
2. W celu pobrania nowej wersji agenta, musi być dostępne połączenie do serwera update.comarch.com na odpowiednim porcie zależnym od wersji językowej:
   1. Wersja polska/angielska na porcie 8466
   2. Wersja niemiecka na porcie 8539
   3. Wersja francuska na porcie 8460
3. Agent automatycznie zostanie pobrany do folderu pobierania (standardowo C:\Comarch ERP Auto Update\Downloads\AgentVersions\)
4. Po restarcie Comarch ERP Auto Update jest możliwość zaktualizowania go do nowej wersji. Agent zostanie zaktualizowany do następujących wersji:
   1. Wersja polska/angielska do wersji numer_wersji.xxxx.1 (np. 2019.0.3665.1)
   2. Wersja niemiecka do wersji numer_wersji.xxxx.2
   3. Wersja francuska do wersji numer_wersji.xxxx.3
5. Aktualizację agentów trzeba przeprowadzić zgodnie z hierarchią, zaczynając od agenta głównego
6. Aktualizację agentów trzeba przeprowadzić na wszystkich stanowiskach: Centrali oraz POS
7. Przed instalacją nowej wersji należy uzupełnić konfigurację (o ile nie została wcześniej uzupełniona) komponentów Centrala Serwer i Comarch Retail POS o nazwy baz konfiguracyjnej i firmowej (Konfiguracja -> wybór odpowiedniego komponentu na drzewie produktów -> przycisk [Konfiguracja] w menu głównym)

Aktualizacja wersji Comarch ERP Altum / Comarch Retail za pomocą Comarch ERP Auto Update na wszystkich stanowiskach

Zaleca się przeprowadzenie aktualizacji w następującej kolejności:

• Centrala Serwer
• Centrala Stanowisko
• Comarch Retail POS

Konwersja wartości cech i atrybutów

W czasie aktualizacji systemu Comarch ERP Altum może pojawić się komunikat o konieczności wykonania konwersji cech baz danych – firmowej i konfiguracyjnej. Konwersję można również uruchomić ręcznie.

Przed wykonaniem konwersji cech należy wykonać jej konfigurację. Można jej dokonać za pomocą przycisku [Konfiguracja] znajdującego się w sekcji Komponent bądź klikając prawym przyciskiem myszy na pozycji komponentu na liście i wybierając opcję Konfiguracja.

Następnie w sekcji Konfiguracja konwersji cech i atrybutów można przejść do konfiguracji konwersji cech i atrybutów za pomocą przycisku [Konfiguruj].

W oknie konfiguracji konwersji wartości należy określić kulturę językową wprowadzania wartości. Można ją zdefiniować dla każdego obiektu osobno lub dla wszystkich jednocześnie. Do wyboru jest 5 języków: polski, angielski, niemiecki, francuski i hiszpański.

Taka konfiguracja jest możliwa do wykonania wyłącznie na agencie głównym, na agentach podrzędnych jest ona pobierana z agenta nadrzędnego.

Proces aktualizacji

Po wybraniu opcji Pobierz i instaluj na ekranie głównym Comarch ERP Auto Update zostanie przeprowadzona aktualizacja systemu do bieżącej wersji. Aplikacja umożliwia zaktualizowanie całego środowiska – Centrali wraz ze stanowiskami POS z poziomu Centrali.

W narzędziu Comarch ERP Auto Update sprawdzana jest również ważność licencji. Jednakże informacja o dacie ważności licencji wyświetlana jest jedynie w celach informacyjnych, tzn. nie blokuje aktualizacji produktu do nowszej wersji.

Konwersja struktury firmy

W trakcie konwersji do wersji 2015 bazy firmowej Comarch ERP Altum, pojawi się pytanie o konwersję struktury praw. Po uważnym przeczytaniu wyświetlonego tekstu pomocniczego należy wybrać jedną z dwóch dostępnych opcji:

Pozostaw węzeł główny bez zmian – istniejące magazyny, rejestry VAT oraz rejestry kasowo-bankowe po konwersji oznaczone zostaną jako dedykowane dla firmy głównej.

Skonwertuj węzeł główny na centrum typu Firma – istniejące magazyny, rejestry VAT oraz rejestry kasowo-bankowe po konwersji zostaną automatycznie dołączone do utworzonego centrum typu firma i nie będą mogły być wykorzystywane do pracy operacyjnej w firmie głównej (parametr Dedykowany dla firmy głównej na tych obiektach będzie odznaczony i zablokowany do zaznaczenia).

Konwersja zgód

W wersji Comarch ERP Altum 2018.1.1 zostały wprowadzone funkcje wspomagające zarządzanie danymi osobowymi przechowywanymi w systemie. Podczas pierwszej konwersji firmowej bazy danych programu Comarch ERP Altum do wersji co najmniej 2018.1.1 pojawi się okno wyboru sposobu konwersji dotychczasowych zgód przechowywanych w programie zawierające dwie opcje – Konwertuj zgody do nowego formatu na podstawie ustalonych parametrów oraz Usuń dotychczas wprowadzone zgody w konwersji.

Wybranie opcji Konwertuj zgody do nowego formatu na podstawie ustalonych parametrów spowoduje wyświetlenie poniższego okna:

Zatwierdzenie powyższego okna spowoduje zapisanie informacji podanych w powyższych polach i rozpoczęcie proces instalacji. Na podstawie treści tych opcji zostanie wygenerowany wzorzec zgód, a dotychczasowe zgody na otrzymywanie informacji handlowych zostaną zastąpione zgodami w nowym formacie. Po nadaniu tytułu oraz treści zgód skonwertowane zgody zostaną dodane do kategorii Marketing.

Wybranie opcji Usuń dotychczas wprowadzone zgody w konwersji spowoduje usunięcie kolumny Zgoda na informacje handlowe z kart kontrahentów i osób kontaktowych i rozpoczęcie procesu instalacji.

Dostępność wymiarów w strukturze wielofirmowej

Po konwersji systemu z wersji wcześniejszych niż 2016.5.5:

1. Na wszystkich podwymiarach oraz elementach wymiarów w polu Właściciel ustawiana jest wartość Wszystkie. Można pozostawić takie ustawienia lub zdecydować, iż dany element będzie dostępny tylko w konkretnej firmie
   Uwaga

   Wymiary analityczne oraz predefiniowane podwymiary wymiaru Kategoria finansowa są wspólne dla całej grupy firm
2. Na poziomie elementu wymiaru należy zweryfikować  powiązanie z kontem księgowym.

W celu zwiększenia ergonomii pracy użytkownika, na liście wymiarów dodano dwie dodatkowe kolumny widoczne na liście ukrytych kolumn, tj.: Właściciel i Konto. W kolumnie Właściciel wyświetlana jest firma będąca właścicielem elementu lub podwymiaru analitycznego, a w kolumnie Konto wyświetlane jest konto wskazane na formularzu elementu lub podwymiaru w danej firmie.

Począwszy od wersji 2016.5, podczas dokonywania opisu analitycznego na obiekcie lub dokumencie, na liście wartości wymiarów analitycznych wyświetlane są wyłącznie elementy, dla których jako właściciela wskazano firmę, w kontekście której zalogowany jest operator lub wartość Wszystkie.

Precyzja wartości procentowej opisu analitycznego

Od wersji 2018.1.1 wartość procentowa opisu analitycznego jest zapisywana i wyświetlana z większą precyzją, tj. z dokładnością do czterech miejsc po przecinku. Zwiększenie tej precyzji podyktowane jest eliminacją rozbieżności między wartością kwotową, a procentową opisu analitycznego.

Przeliczenie wartości opisu analitycznego z dokładnością do czterech miejsc po przecinku odbywa się wyłącznie dla nowych rekordów. Podczas konwersji bazy do wersji 2018.1.1 wartości procentowe opisu analitycznego na dotychczasowych dokumentach nie są ponownie przeliczane według nowej precyzji, dodawane są tylko zera dla zachowania zgodności formatu.

W celu aktualizacji wartości procentowych opisu analitycznego na dokumentach dodanych w systemie, dla wersji niższych niż 2018.1.1 należy uruchomić na bazie skrypt dla wymaganego zakresu danych, który jest dostępny na Stronach Walidowanych dla Partnerów.

Konfiguracja nowego licencjonowania

W trakcie aktualizacji Comarch ERP Auto Update do wersji 2016.2 automatycznie zostanie dodany nowy produkt do zainstalowania o nazwie Comarch ERP Menadżer Kluczy.

Przed uruchomieniem instalacji należy skonfigurować ten produkt. W tym celu, należy przejść do okna Konfiguracja.

Następnie należy wpisać odpowiednie dane dotyczące produktu tj.: instancja SQL, użytkownik SQL (wymagany jest użytkownik dodany do roli serwerowej sys_admin), dane dotyczące klucza licencyjnego ID klienta, PIN, Numer klucza. W celu otrzymania informacji na temat nowego klucza licencyjnego należy skontaktować się z Asystą Techniczną.

Po wprowadzeniu prawidłowych danych w oknie konfiguracji należy zainstalować produkt.

Weryfikacja ustawień dotyczących licencjonowania

Konfigurację usługi licencjonowania można przeprowadzić za pomocą narzędzia Konfigurator. Ustawienia dotyczące licencjonowania są dostępne na zakładce Klucz licencyjny. Należy podać nazwę serwera, gdzie znajduje się zainstalowany produkt Comarch ERP Menadżer Kluczy oraz klucz licencyjny.

Logowanie do Comarch ERP Altum – nowe okno wyboru serwera licencji

Podczas pierwszego logowania do Comarch ERP Altum po migracji, pojawi się okno wyboru serwera licencji. Należy podać nazwę serwera klucza oraz numer klucza.

Nazwa serwera klucza jest zapisywana w pliku Altum.exe.config w sekcji <add key=”LicenseServer” value=”NAZWA SERWERA” />. Poszczególne klucze licencyjne są zapisywane wraz z informacjami o operatorach na bazie danych.

Z poziomu listy użytkowników można zdefiniować klucze dla wszystkich operatorów w systemie.

Zmiana nazw usług

Od wersji 2015.0 zostały ustandaryzowane i zmienione nazwy usług.

Ustawienia timeoutu

Po aktualizacji wersji wartość timeoutu w konfiguracji systemu zostanie ustawiona na wartość domyślną, czyli 1 godzina. Ustawienia timeoutów są dostępne w menu System -> Konfiguracja -> Komputer.

Weryfikacja migracji ustawień BPM

Aby to zrobić należy uruchomić Konfigurator BPM, szczegółowy opis konfiguracji BPM znajduje się w kategorii BPM.

Aktualizacja procesów

Po migracji systemu do wyższej wersji należy zaktualizować wersje procesów, które zostały zmodyfikowane do danej wersji systemu. Procesy można zaktualizować w Edytorze Procesów BPM. W tym celu, należy usunąć w edytorze obecne procesy standardowe i zaimportować nowe definicje procesów, które dostarczane są z nową wersją programu. Szczegółowy opis zmian w procesach znajduje się w artykule Zmiany funkcjonalne wprowadzone w Comarch ERP Altum i Comarch Retail do każdej wersji systemu.

Weryfikacja uprawnień do obiektów księgowych

W wersji 2015 ewidencja księgowa w modelu wielofirmowym jest prowadzona w obrębie wydzielonych ksiąg rachunkowych poszczególnych jednostek. Przeglądanie oraz wprowadzanie danych księgowych odbywa się po wskazaniu firmy, w ramach zdefiniowanego dla niej okresu obrachunkowego oraz planu kont.

1. Okresy obrachunkowe, dzienniki cząstkowe i plan kont

Okresy obrachunkowe, dzienniki cząstkowe i plany kont są odrębne dla każdego centrum struktury typuFirma. Podczas konwersji z wersji poprzedniej użytkownik może wybrać dwie różne metody konwersji:

• dotychczasowe centrum typu firma pozostaje węzłem głównym. Dzienniki cząstkowe oraz konta księgowe przyporządkowane zostaną wówczas na poziomie firmy nadrzędnej lub węzła głównego (co odpowiada strukturze firmy sprzed wersji 2015).
• związana z wyodrębnieniem dodatkowego centrum typu Firma. Dzienniki cząstkowe oraz konta księgowe przypisywane są na poziomie firmy podrzędnej, nie będą widoczne z poziomu węzła głównego\firmy nadrzędnej.

Po migracji do wersji 2015 należy zatem zweryfikować ustawienie okresów obrachunkowych, dzienników cząstkowych oraz planów kont dla poszczególnych firm (węzła głównego lub firmy podrzędnej).

Po konwersji należy również zweryfikować dostępność kont księgowych w poszczególnych centrach – domyślnie są one dostępne we wszystkich centrach danej firmy.

2. Zapisy księgowe, storno, noty memoriałowe, bilans otwarcia

Począwszy od wersji 2015 wyświetlanie dokumentów księgowych podlega standardowym ograniczeniom w oparciu o pole Właściciel na dokumencie oraz reguły związane z udostępnianiem dokumentu danego typu (zakładka Widoczność w definicji dokumentu).

Na formularzu tych obiektów dostępne jest pole Właściciel. Podczas konwersji z wersji poprzedniej użytkownik może wybrać dwie różne metody konwersji:

• dotychczasowe centrum typu firma pozostaje węzłem głównym. Wyżej wymienione obiekty księgowe przyporządkowane zostaną wówczas na poziomie firmy nadrzędnej lub węzła głównego (co odpowiada strukturze firmy sprzed wersji 2015).
• związana z wyodrębnieniem dodatkowego centrum typu: Firma. Wyżej wymienione obiekty księgowe przypisywane są na poziomie firmy podrzędnej, nie będą widoczne z poziomu węzła głównego lub firmy nadrzędnej.

Dodatkowo podczas konwersji, na definicji wyżej wymienionych obiektów księgowych widocznych w strukturze uprawnień, dla każdego z centrów ustalana jest widoczność we wszystkich centrach struktury firmy. Dzięki temu konwersja nie powoduje odebrania widoczności użytkownikom, którzy wcześniej widzieli te obiekty księgowe. Po migracji do wersji 2015 należy zatem zweryfikować widoczność w/w obiektów księgowych dla poszczególnych centrów struktury firmy.

3. Schematy księgowe, schematy księgowań okresowych, zestawienia księgowe

Dostępność schematów księgowych, schematów księgowań okresowych oraz zestawień księgowych można skonfigurować w menu Konfiguracja → (Struktura firmy) → Dostępność obiektów. Wyżej wymienione obiekty księgowe dostępne są w konkretnej firmie oraz w podrzędnych centrach jej struktury. Po migracji do wersji 2015 należy zatem zweryfikować dostępność obiektów księgowych dla poszczególnych centrów struktury firmy. W tym miejscu odbywa się również wskazanie domyślnego schematu księgowań obowiązującego w danym centrum przy księgowaniu konkretnego typu dokumentu.

4. Rejestry VAT

Na definicji rejestru VAT został udostępniony parametr Dedykowany dla firmy głównej. Podczas konwersji z wersji poprzedniej użytkownik może wybrać dwie różne metody konwersji:

• dotychczasowe centrum typu Firma pozostaje węzłem głównym. Wówczas na wszystkich rejestrach parametr będzie zaznaczony.
• związana z wyodrębnieniem dodatkowego centrum typu Firma. Wówczas na wszystkich rejestrach parametr będzie odznaczony.

Podczas konwersji do definicji każdego ze zdefiniowanych centrów struktury firmy przypisywana jest pełna lista rejestrów VAT.

Po migracji do wersji 2015 należy zatem zweryfikować dostępność rejestrów VAT dla poszczególnych centrów struktury firmy oraz ustawienia parametru Dedykowany dla firmy głównej.

5. Rejestry kasowo-bankowe

Na definicji rejestru kasowo-bankowego został udostępniony parametr Dedykowany dla firmy głównej. Podczas konwersji z wersji poprzedniej użytkownik może wybrać dwie różne metody konwersji:

• dotychczasowe centrum typu Firma pozostaje węzłem głównym. Wówczas na wszystkich rejestrach parametr będzie odznaczony.
• związana z wyodrębnieniem dodatkowego centrum typu Firma. Wówczas na wszystkich rejestrach parametr będzie zaznaczony.

Po migracji do wersji 2015 należy zatem zweryfikować dostępność rejestrów kasowo-bankowych dla poszczególnych centrów struktury firmy oraz ustawienia parametru Dedykowany dla firmy głównej.

6. Wpłaty i wypłaty kasowo-bankowe

Podczas konwersji użytkownik może wybrać dwie różne metody konwersji:

• pierwsza – dotychczasowe centrum typu Firma pozostaje węzłem głównym. Właścicielem wpłat i wypłat kasowych zostanie wówczas na poziomie firmy nadrzędnej/węzła głównego (co odpowiada strukturze firmy sprzed wersji 2015).
• druga – związana z wyodrębnieniem dodatkowego centrum typu Firma. Właścicielem wpłat i wypłat kasowych zostanie firma podrzędna.

Dodatkowo przy konwersji, na definicjach wpłaty i wypłaty kasowo/bankowej widocznych w strukturze uprawnień z poziomu firmy, zostanie ustawiona widoczność we wszystkich centrach podrzędnych w stosunku do tej firmy, żeby po konwersji nie odebrano widoczności użytkownikom, którzy wcześniej widzieli operacje. Należy zweryfikować zatem uprawnienia dla widoczności operacji w centrach firmy.

Weryfikacja uprawnień do obiektu Deklaracja

W wersji 2015 rozbudowano system uprawnień o typ obiektu Deklaracja i dodano  możliwość ograniczenia grupie operatorów uprawnień do modyfikacji, dodawania, usuwania i odczytu deklaracji. Wszystkie grupy operatorów otrzymały domyślnie pełne uprawnienia.

Po migracji do wersji 2015 należy zatem zweryfikować uprawnienia do deklaracji VAT dla poszczególnych grup operatorów.

Zmiana nazwy zmiennych w schematach księgowych

Od wersji 2015.0 zmieniono nazwy zmiennych w schematach księgowych:

@KodTowaru na @KodArtykułu

@NazwaTowaru na @NazwaArtykułu

Należy zwrócić uwagę , że jeżeli definicja schematu księgowego została wyeksportowana w którejś z poprzednich wersji programu, to po imporcie należy zweryfikować zmienne i zmienić ich nazwy zgodnie z nowym nazewnictwem. Stare zmienne będą przez system wskazywane jako błędne.

Dostosowanie Layoutów użytkownika

Między wersjami Comarch ERP ALtum wprowadzane są zmiany interfejsu. Po migracji należy ponownie dostosować spersonalizowane formularze użytkownika do nowej wersji. Szczegółowy opis konfiguracji layoutu znajduje się w kategorii artykułów Zarządzanie wyglądem.

Migracja profili użytkownika Altum

Profile wstążki w systemie Comarch ERP Altum nie są konwertowane automatycznie z wyjątkiem profilu Standard. Wszystkie pozostałe profile należy konwertować za pomocą narzędzia Menadżer konwersji. Narzędzie znajduje się w Menadżerze baz na zakładce Konfiguracja.

Szczegółowy opis konwersji profili znajduje się w artykule Menadżer Konwersji 

Domyślny rodzaj bonu

W przypadku, gdy istnieje kilka rodzajów bonów o typie Wewnętrzny wydany oznaczonych jako Aktywny i żaden z nich nie jest oznaczony jako Domyślny, to po konwersji bazy do wersji 2016.5 jeden z nich zostanie oznaczony jako Domyślny. Użytkownik powinien zweryfikować, czy nadane ustawienie odpowiada jego oczekiwaniom i czy wskazany rodzaj jest wykorzystywany domyślnie w systemie i jest oznaczony jako Domyślny.

Migracja wersji Comarch e-Sklep

Wraz z migracją systemu Comarch ERP Altum/Comarch Retail należy zmigrować także produkt
Comarch ERP e-Sklep. Przed wykonaniem migracji obu systemów do nowszej wersji zaleca się zsynchronizować dane (takie jak zamówienia czy kontrahenci) z Comarch ERP e-Sklep do Comarch ERP Altum. Synchronizacja powinna zostać uruchomiona dopiero po zmigrowaniu obu produktów do właściwych wersji.

W przypadku Comarch ERP e-Sklep w wersji online należy przesłać zgłoszenie za pośrednictwem Systemu Obsługi Zgłoszeń (SOZ) z prośbą o wykonanie migracji. W zgłoszeniu jako produkt należy wybrać Comarch ERP e-Sklep.

W przypadku posiadania Comarch ERP e-Sklep w wersji stacjonarnej należy uruchomić narzędzie WAMC i za jego pośrednictwem wykonać migrację.

Migracja wersji Comarch B2B

Wraz z migracją systemu Comarch ERP Altum / Comarch Retail należy zainstalować dedykowaną wersję produktu Comarch B2B (kiedyś Comarch ERP Pulpit Kontrahenta). Instrukcja instalacji Comarch ERP Pulpit Kontrahenta znajduje się na stronach walidowanych dla Partnerów w obszarze E-commerce.

Migracja POS1.0 do Comarch Retail POS2.0

Migracja Comarch Retail POS do edycji 2.0 jest możliwa tylko w przypadku, gdy stanowisko POS w edycji 1.0 jest dołączone do bazy firmowej Centrali Altum/Retail. Oznacza to, że nie ma możliwości migracji POS2.0, jeżeli stanowisko POS1.0 jest dołączone do Comarch Retail Backoffice.

Szczegółowy opis instalacji aplikacji Comarch Retail POS 2.0 znajduje się na stronie: https://pomoc.comarch.pl/retail/pl/

Przy pierwszym uruchomieniu Comarch Retail POS2.0 oraz usługi DS wykonana zostanie synchronizacja wszystkich niezbędnych obiektów do POS2.0.

W celu przełączenia edycji z Comarch Retail POS1.0 na Comarch Retail POS2.0 należy zmienić parametr Wersja w systemie Comarch ERP Altum przy wybranych stanowiskach.

W tym celu należy przejść do konfiguracji firmy: Konfiguracja (Struktura firmy) Firma. Na formularzu należy wybrać zakładkę Stanowiska POS. Przy każdym stanowisku POS w kolumnie Wersja widnieje numer edycji programu Comarch Retail POS. Po wybraniu na liście stanowiska POS, które ma zostać zaktualizowane do edycji 2.0, należy wybrać przycisk [Edytuj].

W edycji stanowiska POS w polu Wersja należy wybrać opcję POS2.0.

Przy zmianie stanowiska POS z edycji 1.0 na 2.0 system wyświetli komunikat o treści: „Czy podpiąć automatycznie definicje raportów dla danej wersji stanowiska POS?”. Należy go potwierdzić, po czym zapisać konfigurację stanowiska oraz konfigurację firmy.

Reset licencji dla Retail POS2.0

Jeżeli kod stanowiska POS był zapisany z użyciem małych liter np. Pos01 to po migracji do Comarch Retail w wersji 2017.5 nie będzie możliwe pobranie licencji dla takiego stanowiska POS. W przypadku stanowisk POS z takim zapisem należy zresetować klucz licencyjny dla licencji 16140 Retail POS. W tym celu należy wysłać zgłoszenie do Asysty Technicznej.

Profil fiskalny w konfiguracji POS2.0

Po migracji do wersji 2017.5 należy zweryfikować czy w konfiguracji stanowiska POS 2.0 po stronie Altum został ustawiony prawidłowy profil fiskalny. W przypadku braku ustawienia tego pola, nie będzie działać fiskalizacja na stanowiskach POS.

Podniesienie protokołu TLS do wersji 1.2

Administratorzy serwera ze względów bezpieczeństwa mogą wyłączyć obsługę protokołu TLS w wersji 1.0 oraz 1.1 zarówno dla funkcji serwera jak i klienta. W takiej sytuacji może pojawić się potrzeba aktualizacji instancji Microsoft SQL Server do takiej, która wspiera obsługę protokołu TLS 1.2.

1.Instalacja wersji TLS 1.2 dla usługi SQL Server

Należy zweryfikować czy posiadana wersja SQL Server obsługuje TLS 1.2. W tym celu, należy sprawdzić czy posiadana wersja SQL Server wspiera protokół TLS 1.2 należy posłużyć się odpowiednią tabelą dostępną na stronach Microsoftu: https://support.microsoft.com/pl-pl/help/3135244/tls-1-2-support-for-microsoft-sql-server

Należy zainstalować komponent SQL Server Native Client dla odpowiedniej wersji serwera. Instalator ten znajdziemy na stronach Microsoft: https://support.microsoft.com/pl-pl/help/3135244/tls-1-2-support-for-microsoft-sql-server

2.Włączanie i wyłączanie wersji TLS

W celu wyłączenia lub włączenia obsługi wersji protokołu TLS na serwerze należy otworzyć Edytor Rejestru (regedit.exe) i zweryfikować, czy w ścieżce:

\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols

istnieją klucze o nazwie ‘TLS 1.0’, ‘TLS 1.1’ oraz TLS ‘1.2’.Jeśli takie klucze nie istnieją, należy je utworzyć. Każdy powyższy klucz powinien posiadać po dwa klucze: Client oraz Server.

Klucze Client oraz Server powinny posiadać po trzy wartości:

• (Domyślna)
• DisabledByDefault (typ DWORD)
• Enabled (typ DWORD)

Jeśli dana wersja protokołu ma być wyłączona, powinna posiadać wartości: DisabledByDefault = 1 oraz
Enabled = 0.

Jeśli wersja protokołu ma być włączona, klucz rejestru powinien posiadać wartości: DisabledByDefault = 0 oraz Enabled = 1.

Wyposażenie jako środek trwały

Wyposażenie od wersji 2019 to środek trwały o typie Wyposażenie. Wyposażenie w nowej lokalizacji znajduje się w menu Księgowość -> Środki Trwałe w drzewie Główne\Wyposażenie.

Dane z tabel aktualnie przechowujących informacje o wyposażeniu, czyli [Equipment].[Equipment] oraz [Equipment].[EquipmentGroups] zostały przeniesione do nowych tabel w schemacie FixedAssets oraz SecFixedAssets. Tabele w schemacie Equipment pozostaną tymczasowo na bazie, jednak nie będą wykorzystywane.

Do nowych tabel zostanie przeniesiona struktura grup wyposażenia. Każda z przeniesionych grup, będzie posiadała dotychczasową nazwę, zostanie jej nadany typ Wyposażenie oraz zostanie ustalona wartość metody amortyzacji na Nie podlega.

Na nowe karty wyposażenia zostaną przeniesione pola:

• Kod – Pole jest unikalne. Uzupełniane nazwą wyposażenia. W przypadku kilku wystąpień tej samej nazwy dopisywane są kolejno numery poprzedzone znakiem pokreślenia np. Nazwa_1
• Nazwa
• Numer inwentarzowy
• Typ
• Miejsce użytkowania
• Osoba odpowiedzialna
• Data nabycia
• Data przyjęcia
• Dokument nabycia
• Data likwidacji
• Dokument likwidacji
• Przyczyna likwidacji
• Metoda amortyzacji
• Wartość początkowa
• Atrybuty i Załączniki – W czasie konwersji obiekty te zostają przepięte na odpowiadające im obiekty Środków Trwałych

Usunięcie tabeli Sales.DocumentSubitemRelations

W archiwalnych wersjach systemu relacja między subelementem a elementem zapisywana była w tabeli Sales.DocumentSubitemRelations. W bieżących wersjach systemu odwołanie do elementu Sales.Items zapisane jest bezpośrednio na subelemencie w tabeli Sales. Subitems.
W wersji 2019.5 tabela Sales.DocumentSubitemRelations została usunięta. Wszystkie dodatki opierające się na tej tabeli nie będą działać po aktualizacji sytemu do wersji 2019.5.

Modyfikacja zapytań

Obecnie zamiast typowego złączenia:

SELECT TOP 1 *
FROM SecSales.Headers SSH
INNER JOIN Sales.Items SI ON SI.HeaderID = SSH.ID
INNER JOIN Sales.DocumentSubItemRelations DSR ON DSR.ItemID = SI.ID
INNER JOIN Sales.Subitems SSUB ON SSUB.ID = DSR.SubItemID

należy łączyć się w następujący sposób:

SELECT TOP 1 *
FROM SecSales.Headers SSH
INNER JOIN Sales.Items SI ON SI.HeaderID = SSH.ID
INNER JOIN Sales.Subitems SSUB ON SSUB.ItemID = SI.ID

Obiekty wymagające weryfikacji

Wszystkie autorskie rozwiązania (dedykowane dla Klienta) występujące m.in. w niżej wymienionych obiektach należy zweryfikować i zmodyfikować zgodnie za powyższym przykładem:

• Rozszerzenia
• Wydruki
• Schematy księgowe
• Opisy analityczne
• Atrybuty SQL
• Deklaracje
• Filtry użytkownika
• Procesy BPM korzystające z aktywności SQL
• Widoki
• Procedury
• Triggery

Miejsca w bazie (np. wydruki, schematy księgowe, rozszerzenia, widoki, procedury itp.), gdzie tabela
występuje można sprawdzić uruchamiając następujący skrypt:

;with AllFunc as(
SELECT
o.object_id
,s.name as 'Schema'
,o.name as 'Table'
,m.definition
,o.type_desc
,dbo.regexMatch(m.definition, N'DocumentSubitemRelations',1)
as IsPatternMatched
--,*
FROM sys.sql_modules m
INNER JOIN sys.objects o
ON m.object_id=o.object_id
INNER JOIN sys.schemas s
ON s.schema_id= o.schema_id
)
select * from AllFunc
where IsPatternMatched=1
order by 'Schema','Table'

Do weryfikacji wystąpienia tabeli w aktywnościach BPM można użyć poniższego zapytania:

SELECT
T.InternalName AS "Nazwa procesu"
,Charindex( 'Sales.DocumentSubItemRelations',Cast(Cast(Data AS xml) AS
nvarchar(max)),0) AS "Miejsce użycia"
,Cast(Data AS xml) AS "Dane"
FROM Workflow.FileItems FI
JOIN Workflow.WorkflowDefinitions WD ON FI.FolderItemId = WD.FileId
JOIN Workflow.Workflows W ON WD.WorkflowId = W.WorkflowId
JOIN Workflow.Translations T ON W.TranslationId = T.TranslationId
WHERE Charindex( 'Sales.DocumentSubItemRelations',Cast(Cast(Data AS xml) AS
nvarchar(max)),0)>0

Zmiany w zapisie adresów

Od wersji 2019.5 systemu Comarch ERP Altum informacja o wybranym adresie kontrahenta na
dokumencie została przeniesiona z tabeli Sales.DocumentCustomers do tabeli SecSales.Headers.

Zmiany w bazie danych

W tabeli SecSales.Headers zostały dodane 2 nowe kolumny: Customer1AddressDataId oraz Customer2AddressDataId. Podczas konwersji bazy danych informacja o wybranym adresie kontrahenta na dokumencie zostanie przeniesiona do w/w kolumn wg poniższego schematu:

• wartości z kolumny AddressDataId z tabeli Sales.DocumentCustomers zostaną przeniesione do kolumny Customer1AddressDataId w tabeli SecSales.Headers dla wierszy, które w kolumnie CustomerTypeId miały wartość 0 lub 2
• wartości z kolumny AddressDataId z tabeli Sales.DocumentCustomers zostaną przeniesione do kolumny Customer2AddressDataId w tabeli SecSales.Headers dla wierszy, które w kolumnie CustomerTypeId miały wartość 1 lub 3

Modyfikacja zapytań

Dotychczas stosowane złączenie konieczne do wybrania danych adresowych kontrahenta z
dokumentu:

SELECT TOP 1 AD.*
FROM SecSales.Headers H
LEFT OUTER JOIN Sales.DocumentCustomers DC ON DC.DocumentId = H.ID AND
DC.CustomerTypeID IN (0,2) -- First customer
LEFT OUTER JOIN Address.AddressData AD ON AD.AddressDataId =
DC.AddressDataID

Należy zastąpić przez:

SELECT TOP 1 AD.*
FROM SecSales.Headers H
LEFT OUTER JOIN Address.AddressData AD ON AD.AddressDataId =
H.Customer1AddressDataId -- First customer

Planowane usunięcie tabeli Sales.DocumentCustomers

Tabela Sales.DocumentCustomers nie zostanie usunięta w wersji 2019.5. W przyszłych wersjach systemu po zakończeniu zaplanowanych prac w obszarze Adresów i Kontrahentów tabela zostanie usunięta. Informacje o terminie usunięcia tabeli oraz o dodatkowych zmianach w tym obszarze zostaną przekazane przed udostępnieniem wersji zawierającej ww modyfikacje.

Dodanie stałego typu dokumentu

W wersji 2019.5 został dodany stały typ dokumentu- DocumentKindId. Stały typ dokumentu pozwoli konstruować bardziej wydajne zapytania, zastępując dotychczas stosowane odwołanie do DT.DocumentTypes.NamespaceEntry.

Zmiany w bazie danych

Na bazie zostały dodane kolumny:

• DT.DocumentTypes.DocumentKindId
• SecSales.Headers.DocumentKindId
• Sales.DocumentHeaderRelations ChildDocumentKindId i ParentDocumentKindId
• SecBanksRegisters.Operations.DocumentKindId
• BanksRegisters.Dunning.DocumentKindId
• AccountingDocuments.OpeningBalanceDocuments.DocumentKindId
• SecBanksRegisters.PlannedPayments.DocumentKindId

Modyfikacja zapytań

DocumentKindId jest stałym id typu dokumentu (w przeciwieństwie do DocumentTypeId), więc jest takie samo niezależnie od języka bazy. W nowych widokach/procedurach należy używać stałych jego wartości, analogicznie do użycia NamespaceEntry.

Zamiast zapytania:

SELECT HE.Id FROM SecSales.Headers HE
LEFT JOIN DT.DocumentTypes DT ON DT.Id = HE.DocumentTypesID
WHERE DT.NamespaceEntry IN
('Comarch.B2.Sales.Documents.SalesOrderManager','Comarch.B2.Sales.Documents
.PurchaseOrderManager')

Należy używać:

SELECT HE.Id FROM SecSales.Headers HE
WHERE HE.DocumentKindId IN /*(ZS/ZZ)*/ (11,10)

DocumentTypeId nie jest nigdzie usuwane, więc wszystkie wcześniej stworzone z nim zapytania będą działały prawidłowo. Niemniej jednak zalecamy aby stopniowo modyfikować istniejące oraz tworzyć nowe zapytania przy użyciu DocumentKindId aby optymalizować czas wykonania zapytań. Aby wygenerować prawidłowe DocumentKindId z NamespaceEntry można użyć poniższego zapytania:

SELECT 'DocumentKindId IN '
+'/*(' + dbo.GROUP_CONCAT(Code, '/') + ')*/ '
+ '(' + dbo.GROUP_CONCAT(DocumentKindId, ',') + ')'
FROM DT.DocumentTypes
WHERE NamespaceEntry IN
('Comarch.B2.Sales.Documents.SalesOrderManager','Comarch.B2.Sales.Documents
.PurchaseOrderManager'

Przy dodawaniu nowego typu dokumentu (dodawanie wpisu do tabeli DT.DocumentTypes) należy w kolumnie DocumentKindId ustawić identyfikator o wartości nie mniejszej niż 10000, gdyż wartości te są zarezerwowane dla obiektów zawartych w API. Identyfikator można wygenerować poniższym zapytaniem:

DECLARE @DocumentKindId INT
SELECT @DocumentKindId = ISNULL(MAX(DocumentKindId), 0) + 1 FROM
DT.DocumentTypes
IF @DocumentKindId < 10000 SET @DocumentKindId = 10000

Zmiany w API

Enum DocumentKind został przeniesiony z Comarch.B2.Sales.Interfaces.Documents do Comarch.B2.Core.Interfaces i uzupełniony o wszystkie typy dokumentów (poprzednie wartości zostały zachowane). Na głównej encji biznesowej (Comarch.B2.Sales.Interfaces.Documents.Dokument) została dodana wirtualna właściwość DocumentKind, która została przeciążona w dziedziczących po niej encjach tak by zwracała właściwą wartość dla danej encji.

Dostępne są następujące mapowania enuma DocumentKind:

• na DT.DocumentTypes.NamespaceEntry np.
  var namespaceEntry = DocumentKind.SalesInvoice.ToNamespaceEntry();
• z DT.DocumentTypes.NamespaceEntry np.
  var documentKind = DocumentKindExtension.ParseNamespaceEntry
  („Comarch.B2.Sales.Documents.SalesInvoiceManager”);
• na DT.DocumentTypes.Id np.
  var documentTypeId = PermissionService.GetDocumentTypeId
  (DocumentKind.SalesInvoice);
• z DT.DocumentTypes.Id np.
  var documentKind = PermissionService.GetDocumentKind(header.DocumentTypeId);

Migracja .Net Framework

System Comarch ERP Altum począwszy od wersji 2019.5 będzie kompilowany w oparciu o platformę Microsoft .NET Framework w wersji 4.7.2. Tym samym aby stworzone rozszerzenia działały poprawnie z najnowszą wersją systemu należy dokonać migracji na wersję Microsoft .NET Framework 4.7.2.

Zmiany w bibliotekach

W wersji 2019.5 nie będą już wykorzystywane biblioteki PostSharp, PostSharp.Sdk, PostSharp.Sdk.XmlSerializers, PostSharp.Settings i BFsharp.AOP.
Zastąpione zostały bibliotekami MethodBoundaryAspect oraz PropertyChanged, które są bibliotekami Fody i są wykorzystywane w wewnętrznej infrastrukturze. Podczas migracji można usunąć nieużywane już biblioteki.