Migracja danych z Subiekta GT do systemu magazynowego innej marki

Lata historii do przeniesienia

Zmiana systemu magazynowo-sprzedażowego budzi obawę o utratę dokumentów zgromadzonych przez lata. Przy dobrze zaplanowanej migracji tego ryzyka da się uniknąć — pod warunkiem, że dane zostaną uporządkowane przed przeniesieniem, a nie po nim.

Co zwykle da się przenieść

• Kartoteki towarów wraz z kodami, jednostkami i cenami.
• Kontrahentów z danymi adresowymi i warunkami handlowymi.
• Stany magazynowe na dzień przejścia.
• Rozrachunki: nierozliczone należności i zobowiązania.
• Cenniki i rabaty.

Czego zwykle nie przenosi się w całości

Pełnej historii dokumentów sprzed lat. Systemy różnią się strukturą, więc przeniesienie każdego dokumentu z zachowaniem powiązań bywa niewykonalne albo nieopłacalne. Częstszym i sensowniejszym rozwiązaniem jest zachowanie starego systemu w trybie do odczytu — historia pozostaje dostępna, a nowy system startuje czysto.

Porządkowanie przed migracją

Dane w starym systemie bywają niespójne: ten sam kontrahent wpisany kilka razy, towary bez kodów, kartoteki nieużywane od lat. Przeniesiony bałagan pozostaje bałaganem — i to już w systemie, za który firma dopiero zapłaciła.

Sprawdzenie po przeniesieniu

Porównujemy stany magazynowe, salda rozrachunków i liczbę kartotek z systemem źródłowym. Migracja bez tego porównania jest niedokończona.

Moment przejścia

Najlepiej na przełomie okresu rozliczeniowego i w weekend. Przez pierwsze dni pracy pozostajemy dostępni, bo większość trudności ujawnia się przy prawdziwych dokumentach.

Najpierw ustala się zakres migracji

Przed rozpoczęciem prac potrzebna jest lista danych, które muszą być dostępne w nowym systemie od pierwszego dnia. Innego podejścia wymaga przeniesienie samych kartotek i stanów początkowych, a innego migracja obejmująca rozrachunki, zamówienia, indywidualne ceny oraz dodatkowe pola używane przez firmę. Zakres powinien wynikać z rzeczywistego sposobu pracy, a nie tylko z technicznych możliwości eksportu.

Warto wskazać dane krytyczne, czyli takie, bez których sprzedaż, magazyn albo księgowość nie mogą poprawnie rozpocząć pracy. Osobno określa się informacje potrzebne wyłącznie do wglądu. Taki podział ogranicza ryzyko, że czas zostanie poświęcony na przenoszenie nieużywanych zapisów, podczas gdy istotne zależności nie zostaną sprawdzone.

Analizowane są również rozwiązania dodatkowe współpracujące z Subiektem GT. Mogą to być integracje ze sklepem internetowym, Allegro, BaseLinkerem, programem księgowym, drukarką etykiet albo systemem kurierskim. Integracja, czyli automatyczna wymiana danych między programami, może korzystać z własnych identyfikatorów towarów i kontrahentów. Po zmianie systemu takie powiązania trzeba odtworzyć lub skonfigurować ponownie.

Różne warianty przenoszenia danych

Najprostszy wariant polega na wyeksportowaniu wybranych danych z Subiekta GT do pliku, uporządkowaniu ich i zaimportowaniu do programu docelowego. Import oznacza wczytanie przygotowanych informacji do nowego systemu. Ta metoda sprawdza się przede wszystkim przy kartotekach towarowych, kontrahentach oraz prostych cennikach, o ile program docelowy udostępnia odpowiedni mechanizm wczytywania.

Bardziej złożony wariant wymaga przygotowania mapowania pól. Mapowanie to przypisanie konkretnej informacji ze starego systemu do odpowiadającego jej miejsca w nowym. Przykładowo symbol towaru może trafić do indeksu, nazwa skrócona do nazwy podstawowej, a dodatkowy opis do osobnego pola tekstowego. Jeżeli system docelowy nie ma odpowiednika danego pola, trzeba zdecydować, czy informacja zostanie połączona z inną, zapisana w uwagach, czy pozostawiona wyłącznie w archiwum.

Osobnym wariantem jest rozpoczęcie pracy od bilansu otwarcia, czyli zestawu początkowych stanów magazynowych i nierozliczonych sald. Dawne dokumenty pozostają wtedy w Subiekcie GT do odczytu. Rozwiązanie jest często czytelniejsze od próby odtwarzania całej historii w programie, który inaczej buduje dokumenty, rozlicza magazyny albo zapisuje korekty.

Znaczenie identyfikatorów i jednostek miary

Nazwa towaru nie zawsze wystarcza do jednoznacznego rozpoznania kartoteki. Ten sam produkt może występować pod podobnymi nazwami, a jedna nazwa może zostać użyta dla kilku wariantów. Dlatego przed migracją sprawdzane są symbole, kody kreskowe i inne identyfikatory, czyli oznaczenia pozwalające rozróżnić poszczególne pozycje. Duplikaty wymagają wyjaśnienia przed importem, ponieważ ich automatyczne połączenie mogłoby zmienić stany lub historię rozrachunków.

Kontroli wymagają także jednostki miary. Towar może być kupowany w opakowaniach, sprzedawany w sztukach i ewidencjonowany w kartonach. Przelicznik jednostek określa zależność między tymi wartościami. Jeżeli program docelowy obsługuje jednostki inaczej, samo przeniesienie liczby bez prawidłowego przelicznika może dać pozornie poprawny, ale faktycznie błędny stan magazynowy.

Podobna zasada dotyczy wariantów produktów, numerów seryjnych oraz partii dostaw. Najpierw sprawdza się, czy nowy system ma odpowiadające im mechanizmy. Dopiero potem wybierany jest sposób przeniesienia. Nie należy zastępować ważnej cechy przypadkowym polem tylko dlatego, że import zostanie dzięki temu zakończony bez komunikatu o błędzie.

Stany magazynowe i rozrachunki wymagają osobnej kontroli

Liczba kartotek może zgadzać się po migracji, a mimo to wartości magazynowe mogą być nieprawidłowe. Kontrola obejmuje nie tylko łączną liczbę pozycji, lecz także stan konkretnych towarów w poszczególnych magazynach. Jeżeli firma korzysta z kilku magazynów, przeniesienie wszystkiego do jednej lokalizacji w nowym programie zmieni obraz zapasów i utrudni dalszą pracę.

Rozrachunki wymagają rozróżnienia należności i zobowiązań. Należność to kwota, którą kontrahent powinien zapłacić firmie, natomiast zobowiązanie to kwota pozostająca do zapłaty przez firmę. Znaczenie mają również terminy, waluty, częściowe spłaty oraz przypisanie salda do właściwego kontrahenta. Sama zgodność łącznej kwoty nie potwierdza jeszcze poprawności migracji.

Przed ostatecznym przejściem ustala się moment graniczny. Wszystkie operacje wykonane do tego momentu pozostają w starym systemie, a kolejne są rejestrowane już w nowym. Jeżeli dokumenty będą równolegle wystawiane w obu programach bez jasno określonej zasady, szybko powstaną różnice trudne do jednoznacznego wyjaśnienia.

Próba migracji przed właściwym przejściem

Bezpieczne przygotowanie obejmuje migrację testową, czyli próbne przeniesienie danych do środowiska, w którym nie prowadzi się jeszcze bieżącej sprzedaży. Pozwala to sprawdzić formaty, mapowanie oraz sposób obsługi nietypowych zapisów. Na tym etapie można poprawić dane źródłowe lub reguły importu bez zakłócania pracy firmy.

Test nie powinien ograniczać się do otwarcia listy towarów. Warto wyszukać kilka kartotek o różnych cechach, sprawdzić kontrahentów, przygotować przykładowy dokument sprzedaży i zweryfikować działanie rabatów. Jeżeli używane są integracje, potrzebna jest również kontrola wymiany danych z systemami zewnętrznymi. Próba powinna odpowiadać codziennym czynnościom wykonywanym przez pracowników.

Wyniki kontroli dobrze jest zapisać w protokole migracji, czyli zestawieniu porównującym dane źródłowe i docelowe. Dokument może obejmować liczbę aktywnych kartotek, stany wybranych towarów, salda oraz wykryte wyjątki. Dzięki temu wiadomo, które różnice są zamierzone, a które wymagają poprawy przed uruchomieniem produkcyjnym.

Archiwum Subiekta GT po zakończeniu zmiany

Pozostawienie starego programu do odczytu wymaga czegoś więcej niż zachowania skrótu na pulpicie. Potrzebna jest kopia bazy danych oraz sprawdzone środowisko, w którym będzie można otworzyć wcześniejsze dokumenty. Kopia zapasowa to dodatkowy zapis danych przeznaczony do odtworzenia po awarii lub utracie plików. Powinna być zweryfikowana, ponieważ samo istnienie pliku nie potwierdza jeszcze, że da się z niego odzyskać bazę.

Należy także ustalić, kto będzie miał dostęp do archiwum i w jaki sposób będą wykonywane późniejsze wyszukania. Stary system nie powinien przypadkowo służyć do wystawiania nowych dokumentów po dniu przejścia. Tryb tylko do odczytu oznacza w praktyce, że historia pozostaje dostępna, ale bieżące operacje prowadzone są wyłącznie w nowym rozwiązaniu.

Jeżeli archiwum ma działać na osobnym komputerze lub serwerze, trzeba uwzględnić możliwość późniejszej awarii tego urządzenia. Dane firmowe nie powinny zależeć od jednego dysku. Przygotowanie kopii oraz opisanie sposobu uruchomienia starego systemu ułatwia dostęp do dokumentów także wtedy, gdy do historii trzeba wrócić po dłuższym czasie.

Błędy popełniane przy samodzielnej migracji

Częstym błędem jest rozpoczęcie importu bez kopii bazy i bez zachowania pierwotnego pliku eksportowego. Każda kolejna ręczna poprawka utrudnia wtedy ustalenie, z którego etapu pochodzi błąd. Bezpieczniej pracować na kopii i zachować niezmieniony materiał źródłowy, do którego można wrócić.

Problemem bywa również poprawianie danych bezpośrednio w dużym pliku bez kontroli formatów. Program arkuszowy może potraktować kod towaru jak liczbę, usunąć początkowe zera albo zmienić zapis daty. Na ekranie wartość może wyglądać podobnie, ale system docelowy odczyta ją inaczej. Przed zapisem trzeba więc sprawdzić typy pól, czyli zasady określające, czy dana wartość jest tekstem, liczbą, datą lub innym rodzajem informacji.

Nie należy wielokrotnie importować tego samego zestawu do docelowej bazy bez wcześniejszego sprawdzenia skutków. Program może utworzyć duplikaty zamiast zaktualizować istniejące kartoteki. Próby powinny odbywać się w środowisku testowym, które można odtworzyć do stanu początkowego.

Ryzykowne jest też ręczne korygowanie stanów wyłącznie po to, aby zgadzała się suma. Taka zmiana może ukryć nieprawidłowe przypisanie towaru lub magazynu. Najpierw ustala się przyczynę różnicy, a dopiero potem poprawia regułę migracji albo konkretny zapis.

Kiedy problem nie wynika z samej migracji

Brak danych w nowym programie nie zawsze oznacza, że nie zostały przeniesione. Przyczyną może być aktywny filtr, czyli ustawienie ograniczające widoczną listę, brak uprawnień użytkownika albo wybór niewłaściwego magazynu. Zanim import zostanie powtórzony, sprawdza się sposób wyświetlania i zakres dostępu.

Inna cena na dokumencie nie musi świadczyć o błędnym przeniesieniu kartoteki. System docelowy może mieć odmienną kolejność stosowania cenników, rabatów i indywidualnych warunków kontrahenta. W takim przypadku porównuje się nie tylko wartość końcową, lecz także reguły, według których została wyliczona.

Wolne działanie po uruchomieniu nowego programu również jest osobnym zagadnieniem. Może wynikać z konfiguracji sieci, serwera, uprawnień lub integracji, a nie z jakości przeniesionych danych. Diagnoza powinna rozdzielać problemy z zawartością bazy od problemów z działaniem całego środowiska.

Dodatkowe pytania przed zmianą systemu

Czy można przenieść wszystkie dokumenty jeden do jednego?

Zależy to od budowy programu docelowego i dostępnych mechanizmów importu. Dokument zawiera nie tylko pozycje i kwoty, ale również powiązania z magazynem, płatnością, korektami oraz kontrahentem. Gdy oba systemy zapisują te zależności inaczej, pełne odwzorowanie może nie być możliwe. Wtedy historia pozostaje w Subiekcie GT, a nowy system rozpoczyna pracę od uzgodnionych danych początkowych.

Czy w czasie migracji można nadal wystawiać dokumenty?

Do ustalonego momentu granicznego można pracować w starym systemie. Po wykonaniu końcowego eksportu nowe operacje powinny być już rejestrowane zgodnie z uzgodnionym planem. Dopisywanie dokumentów do Subiekta GT po pobraniu danych końcowych spowoduje, że nie znajdą się one automatycznie w nowym programie.

Czy nieaktywne towary i dawni kontrahenci też muszą zostać przeniesieni?

Nie zawsze. Kartoteki potrzebne wyłącznie do odczytu mogą pozostać w archiwum, o ile nie są wymagane przez otwarte rozrachunki, zamówienia albo inne przenoszone dane. Decyzję podejmuje się po analizie zależności. Usunięcie pozycji tylko dlatego, że od dawna nie była używana, może przerwać powiązanie z ważnym zapisem.

Jak sprawdzić, czy migracja rzeczywiście się udała?

Potrzebne jest porównanie uzgodnionych danych po obu stronach. Sprawdza się między innymi kartoteki, stany magazynowe, otwarte rozrachunki, ceny i wybrane przypadki nietypowe. Następnie wykonuje się próbne czynności odpowiadające codziennej pracy. Brak komunikatu o błędzie podczas importu nie jest wystarczającym potwierdzeniem poprawności.

Czy po przejściu trzeba od razu usuwać Subiekta GT?

Nie. Zachowanie sprawnej kopii starego środowiska umożliwia dostęp do wcześniejszych dokumentów i wyjaśnianie różnic ujawnionych po rozpoczęciu pracy. Program źródłowy można pozostawić jako archiwum, z jasno określoną zasadą, że nie służy już do rejestrowania nowych operacji.

Dobrze przygotowana migracja kończy się uzgodnieniem danych

Zmiana programu magazynowego nie polega wyłącznie na przekopiowaniu tabel. Trzeba zachować znaczenie danych, zależności między nimi oraz możliwość sprawdzenia historii. O wyniku decydują ustalony zakres, uporządkowane kartoteki, migracja testowa, kontrola stanów i sald oraz bezpieczne archiwum Subiekta GT. Dopiero gdy wartości są uzgodnione, a codzienne operacje działają zgodnie z przyjętym sposobem pracy, można uznać przejście do nowego systemu za zakończone.