Migracja z Subiekta GT do nexo: co dzieje się z Waszą integracją

Zdanie, które wszyscy czytają i mijają

Stoi na stronie InsERT-u o Subiekcie nexo, w części o przenoszeniu danych ze starszej linii: nie ma możliwości przeniesienia dokumentów.

Pięć słów, bez gwiazdki, opublikowane przez producenta. I w każdej rozmowie o migracji, jaką odbyłem z firmą mającą integrację wpiętą w Subiekta GT, to zdanie było albo nieprzeczytane, albo przeczytane jak formalność — coś, do czego na pewno znajdzie się obejście, albo co dotyczy kogoś z bardziej zabałaganioną bazą.

Nie znajdzie się i nie dotyczy. To główny fakt całego przedsięwzięcia. Kiedy potraktujecie go poważnie, projekt zmienia kształt: migracja zaplanowana na jeden weekend zamienia się w coś, co ma „przed", „po" i trwały środek.

To migracyjna połowa przewodnika po Sferze w Subiekcie nexo, napisana dla tego samego czytelnika — dla kogoś, kto musi utrzymać integrację przy życiu przez całą tę przeprowadzkę. Zasada jak zawsze: każde twierdzenie o tym, co robi narzędzie, pochodzi z materiałów samego InsERT-u. W tym kawałku rynku pewny siebie domysł kosztuje kogoś produkcyjny weekend.

Co faktycznie przechodzi

Przenoszenie danych nie jest osobnym narzędziem, które uruchamiacie, kiedy chcecie. To etap zakładania nowego podmiotu w Kreatorze wdrożeniowym. Raz, na początku. To nie jest synchronizacja, którą powtórzycie za miesiąc, gdy ktoś zauważy, że czegoś brakuje.

Cztery etapy: wskazanie bazy źródłowej i serwera, eksport do pośrednich plików wymiany, wybór zakresu importu, na końcu import z kontrolą poprawności i raportem błędów.

Co przechodzi:

• kartoteka asortymentu — towary, usługi, komplety, opakowania zwrotne
• kartoteka kontrahentów
• słowniki: grupy, cechy, kasy, magazyny, kraje, użytkownicy, rabaty, stawki VAT, formy płatności, waluty, województwa, rachunki bankowe
• dane podmiotu i parametry
• cenniki i ceny
• stany początkowe kas i rachunków bankowych
• inwentaryzacja
• nierozliczone rozrachunki — i tylko ta ich część, która pozostaje otwarta

Zatrzymajcie się na ostatniej pozycji. To jedyny kawałek rzeczywistości transakcyjnej, który przechodzi przez tę szczelinę. Cała reszta listy to dane podstawowe: rzeczy opisujące firmę, a nie rzeczy, które się jej przydarzyły. Do nexo wchodzicie wiedząc, kim są Wasi klienci, co sprzedajecie i ile ktoś Wam jest winien. I nie wiedząc nic o tym, jak to wszystko powstało.

Dwa drobiazgi, na których ludzie się potykają: hasła użytkowników nie przechodzą, a przy scalaniu kartotek powtarzający się kontrahenci rozpoznawani są po symbolu. To drugie zapamiętajcie — wróci dalej jako najdroższe zdanie w tym tekście.

Historia jest oknem, nie kopią

Tu większość opracowań robi się mglista i tu leżą pieniądze.

Dostępu do starych dokumentów nie tracicie. Subiekt nexo potrafi je pokazać przez mechanizm, który InsERT nazywa danymi archiwalnymi, i można do nich wystawiać korekty oraz zwroty. Brzmi jak problem rozwiązany.

Nie jest rozwiązany, tylko przesunięty. Te rekordy nadal leżą w bazie Subiekta GT, a Subiekt nexo czyta je dokładnie tam, gdzie leżą. Konsekwencję InsERT opisuje wprost: jeśli baza GT zostanie usunięta, zostaną usunięte one również w programie Subiekt nexo. A dokumenty dodane w GT już po migracji trafiają do tego samego archiwum — czyli połączenie jest żywe, a nie jednorazową migawką.

Uczciwy opis migracji z GT do nexo brzmi więc tak: od teraz utrzymujecie dwie bazy i tej starszej nie wyłączycie już nigdy. To nie jest serwer, który zgasicie po zamknięciu okresu kontroli. To zależność systemu, który właśnie kupiliście.

Ma to swoją linijkę w budżecie — hosting, licencja SQL Servera, kopie zapasowe i ktoś, kto pamięta o istnieniu tej bazy, gdy w 2029 roku maszyna pod nią pójdzie do przebudowy. Nikt tego nie wpisuje do kosztorysu, bo kosztorys pisano pod słowo „migracja", które sugeruje zakończenie.

Dlaczego strony integratorów mówią co innego

Wystarczy poszukać, żeby trafić na firmy reklamujące przeniesienie wszystkiego, z pełną historią dokumentów włącznie, w jeden do trzech dni roboczych. To przeczy zdaniu, od którego zacząłem ten artykuł. Obie rzeczy stoją w publicznym internecie, więc lepiej to rozstrzygnąć, niż obejść bokiem.

Trzy wyjaśnienia, od najczęstszego. Pierwsze: „wszystko" oznacza opisany wyżej mechanizm archiwum plus bilans otwarcia, opisane hojnie. Drugie: ktoś zbudował własny import poza kreatorem, wpisujący rekordy historyczne do nexo jako dokumenty albo do pól własnych — możliwe, płatne i nieodtwarzające oryginalnych przeliczeń kosztów, czyli dokładnie z tego powodu kreator tego nie robi. Trzecie: tekst pisał ktoś, kto takiej migracji nigdy nie przeprowadził.

Nie musicie zgadywać, które. Wystarczy jedno pytanie: czy po migracji mogę skasować bazę Subiekta GT? Odpowiedź rozdziela te trzy przypadki w sekundę, a i tak jest to odpowiedź, na której stoi Wasza architektura.

Problem identyfikatorów, którego nikt nie wycenia

Teraz część, która należy konkretnie do Was — i powód, dla którego wolałbym, żebyście przeczytali to przed projektem, a nie w jego połowie.

Nowa baza nadaje własne identyfikatory. Każdy system poza Subiektem, który zapisał u siebie identyfikator z GT, rano po przełączeniu wskazuje na nic. Albo gorzej: na coś. Portal B2B trzymający identyfikator towaru przy pozycji katalogu. Sklep mapujący SKU na identyfikatory wewnętrzne. WMS. Hurtownia raportowa. Automat przyjmujący zamówienia. Wszystko, co kiedykolwiek wpisało id_towaru do własnych tabel.

InsERT daje Wam dokładnie jeden most: powtarzających się kontrahentów kreator rozpoznaje po symbolu. Przydatne — i na tym pomoc się kończy. Obejmuje kontrahentów, nie towary, i działa o tyle, o ile klient pilnował porządku w symbolach. Przy bazie pracującej od 2014 roku to pytanie, na które odpowiada się empirycznie, najlepiej przed wyceną.

Zostaje więc do zrobienia tabela mapowania, towar po towarze i kontrahent po kontrahencie, stary identyfikator na nowy. Zbudujcie ją z plików wymiany w trakcie migracji, kiedy obie strony są jeszcze czytelne i nic się nie ruszyło. Odtwarzanie jej później to uzgadnianie po nazwach i symbolach między dwoma systemami, które już się ze sobą nie zgadzają — najpewniejszy znany mi sposób na zamianę dwudniowego przełączenia w dwa tygodnie.

Wpiszcie ją do planu migracji jako nazwany produkt z właścicielem. Nie jako zadanie w czyimś tygodniu.

Kod Sfery nie jedzie z Wami

Pisałem o tym w przewodniku po nexo, więc krótko: model połączenia jest odwrócony. Sfera w Subiekcie GT tworzy obiekt COM i podłącza się do działającego subiekt.exe. Sfera w nexo dodaje referencje do bibliotek InsERT.Moria.* z katalogu instalacji i łączy się z bazą bezpośrednio — a istnieje wyłącznie w wersji nexo PRO, wycenianej per stanowisko w całej instalacji, a nie raz, dla programisty.

Na potrzeby planowania: warstwę połączenia piszecie od nowa, a do tego dochodzi rozmowa o licencjach, którą prowadzi się z właścicielem firmy, nie z działem IT. Szczegóły wersji ma porównanie trzech systemów dla integratorów, jeśli akurat wyceniacie.

Całkowicie nietknięte przechodzi wszystko powyżej tej warstwy: logika decydująca o tym, co ma znaleźć się w dokumencie. Jeśli mieszka w Waszym kodzie Sfery, piszecie ją całą od nowa. Jeśli mieszka za Waszym własnym interfejsem, wymieniacie jeden komponent, a reszta w ogóle nie zauważa, że ERP pod spodem się zmienił.

Ta sama rada, którą powtarzam przy każdym ERP na tej stronie. Tym razem z konkretną datą.

Kolejność, w której bym to prowadził

1. Najpierw spis powiązań. Każdy system zewnętrzny, każde miejsce, w którym utrwalono identyfikator z GT. Jeden dzień pracy i jedyny krok, po którym reszta w ogóle daje się wycenić.
2. Tabela mapowania z plików wymiany, w trakcie pracy kreatora, nie po niej.
3. Warstwa połączenia z nexo przepisana przed przełączeniem, na testowym podmiocie założonym z kopii bazy GT. Integracja ma działać na nexo wtedy, gdy systemem produkcyjnym jest jeszcze GT.
4. Ustalona blokada wystawiania. Bilans otwarcia powstaje z remanentu na dzień bieżący. Ktoś musi w tym momencie przestać wystawiać dokumenty i nie będzie to inicjatywa magazynu.
5. Ręczne uzgodnienie otwartych rozrachunków pierwszego dnia. Przeszła tylko część nierozliczona, a tego, czy kwota się zgadza, kreator Wam nie powie.
6. Zachowanie bazy GT i notatka, dlaczego, żeby za trzy lata nikt nie odzyskał tego dysku.

Gdzie automatyzacja pomaga, a gdzie nie

Żaden agent nie przeprowadzi tej migracji. To kreator, uruchamiany raz, przez człowieka, który bierze na siebie konsekwencje — a kto sprzedaje Wam do tego kroku AI, sprzedaje coś innego.

Automatyzacja zarabia po obu stronach tego kroku. Na wyjściu: uzgadnianie. Porównanie stanu zamknięcia w GT ze stanem otwarcia w nexo, pozycja po pozycji i rozrachunek po rozrachunku — kilka tysięcy porównań, których nikt nie lubi, więc wszyscy je próbkują zamiast doprowadzić do końca. Na wejściu: utrzymywanie tabeli mapowania w zgodzie z rzeczywistością, dopóki oba systemy przyjmują jeszcze zmiany.

I trzecia rzecz, ta, która naprawdę płaci: praca nad przyjmowaniem zamówień w Subiekcie GT, którą opisywałem — czytanie maila, decyzja, co należy do dokumentu — przechodzi migrację bez jednej poprawki, bo nigdy nie wiedziała, która linia InsERT-u leży pod spodem. To nie przypadek. To projekt, który spłaca się w tym jednym dniu, na który był pomyślany.

Po czym poznać, że proces nadaje się do oddania maszynie, opisałem przy okazji agentów AI dla firm. Wariant z enova365 zamiast Subiekta pod spodem rozbiera integracja enova365 z AI.

Planujecie przejście z GT na nexo z integracją wpiętą w system? Napiszcie do mnie. Godzina spędzona na wypisaniu, co trzyma u siebie identyfikator z Subiekta, jest warta więcej niż jakakolwiek wycena migracji napisana z listy funkcji.