Migracja danych między różnymi systemami księgowo-magazynowymi

Obawa o historię jest uzasadniona

Przejście na inny system budzi pytanie o dokumenty zgromadzone przez lata. Przy dobrze zaplanowanej migracji ryzyka ich utraty da się uniknąć — pod warunkiem, że plan powstanie przed przejściem, a nie w jego trakcie.

Co zwykle przenosimy

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

Czego zwykle nie przenosimy w całości

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

Porządkowanie przed migracją

Zdublowani kontrahenci, towary bez kodów, kartoteki nieużywane od lat — to wszystko przenosi się razem z danymi. Bałagan przeniesiony do nowego systemu pozostaje bałaganem, tylko w miejscu, za które 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

Na przełomie okresu rozliczeniowego i w weekend. Przez pierwsze dni pracy pozostajemy dostępni — większość trudności ujawnia się przy prawdziwych dokumentach, a nie przy testowych.

Najpierw ustala się zakres migracji

Nie każda firma potrzebuje przeniesienia tego samego zestawu informacji. Zakres zależy od sposobu prowadzenia sprzedaży, magazynu, księgowości oraz rozrachunków. Innych danych potrzebuje firma usługowa wystawiająca dokumenty sprzedaży, a innych przedsiębiorstwo prowadzące kilka magazynów, obsługujące rezerwacje i korzystające z rozbudowanych cenników. Przed rozpoczęciem prac przygotowuje się więc listę danych obowiązkowych, przydatnych oraz takich, które mogą pozostać wyłącznie w archiwum.

Na tym etapie sprawdza się również, które procesy będą kontynuowane w nowym systemie. Dotyczy to między innymi numeracji dokumentów, sposobu identyfikowania towarów, przypisania kontrahentów do grup oraz obsługi płatności. Sama możliwość zaimportowania pola nie oznacza jeszcze, że jego znaczenie w obu programach jest identyczne. Pole określane jako grupa, status albo kategoria może sterować innymi funkcjami w systemie źródłowym i docelowym.

Różne warianty przenoszenia danych

Najprostszy wariant obejmuje kartoteki kontrahentów i towarów oraz wartości początkowe potrzebne do rozpoczęcia pracy. W takim przypadku wcześniejsze dokumenty pozostają w starym programie. Rozwiązanie ogranicza liczbę zależności, które trzeba odwzorować, ale wymaga zachowania dostępu do dotychczasowej bazy danych.

Bardziej rozbudowany wariant obejmuje dodatkowo stany magazynowe, otwarte rozrachunki, cenniki i informacje wykorzystywane podczas bieżącej obsługi klientów. Wymaga on ustalenia dnia odcięcia, czyli momentu, po którym nowe dokumenty powstają już wyłącznie w systemie docelowym. Dane z obu programów nie powinny być wtedy zmieniane równolegle bez wyraźnej procedury, ponieważ łatwo doprowadzić do różnic w saldach lub stanach.

Najbardziej złożona jest próba odtworzenia historii dokumentów wraz z pozycjami, korektami, płatnościami i wzajemnymi powiązaniami. Dokument sprzedaży nie jest jedynie wydrukiem. Może wpływać na magazyn, rozrachunki, rejestry i raporty. Jeżeli system docelowy inaczej przechowuje takie zależności, import widocznego dokumentu nie musi oznaczać poprawnego odtworzenia całej operacji. Dlatego pełną migrację historii ocenia się osobno, zamiast traktować ją jako domyślny element przejścia.

Eksport nie jest jeszcze gotową migracją

System źródłowy może udostępniać eksport do arkusza, pliku tekstowego albo innego formatu wymiany danych. Taki plik jest dopiero materiałem wejściowym. Trzeba sprawdzić nazwy kolumn, kolejność informacji, sposób zapisu dat, oznaczenia walut i reguły dotyczące pustych pól. Konieczne bywa również ujednolicenie znaków specjalnych oraz polskich liter, aby nazwy kontrahentów i towarów nie zostały zniekształcone.

Istotne jest mapowanie pól, czyli przypisanie informacji ze starego programu do odpowiednich miejsc w nowym. Kod towaru może trafić do symbolu, indeksu albo dodatkowego pola, zależnie od konstrukcji systemu. Podobnie adres kontrahenta może być rozdzielony na kilka elementów lub zapisany jako jeden ciąg. Błędne mapowanie nie zawsze zatrzymuje import. Czasem dane zostają przyjęte, ale pojawiają się w niewłaściwych miejscach, co utrudnia wykrycie problemu.

Kopia danych i migracja próbna

Przed zmianami wykonuje się kopię bazy oraz plików związanych z używanym systemem. Kopia powinna umożliwiać powrót do stanu sprzed importu. Samo skopiowanie skrótu do programu albo folderu z raportami nie zabezpiecza danych przechowywanych przez silnik bazy, czyli oprogramowanie odpowiedzialne za zapis i odczyt informacji.

Właściwe przejście powinien poprzedzać import próbny. Przeprowadza się go na kopii lub w środowisku testowym, czyli oddzielnym miejscu, w którym operacje nie wpływają na bieżącą pracę firmy. Próba pokazuje, czy kartoteki są kompletne, czy znaki wyświetlają się prawidłowo i czy wartości trafiają do właściwych pól. Pozwala też ocenić, które dane trzeba oczyścić przed importem właściwym.

Test nie powinien ograniczać się do sprawdzenia, czy program uruchamia się bez komunikatu o błędzie. Należy otworzyć przykładowe kartoteki, wyszukać kontrahentów po różnych danych, sprawdzić jednostki towarów oraz porównać podsumowania. Przydatne jest także wystawienie dokumentów testowych, aby upewnić się, że przeniesione ustawienia nie utrudniają codziennych czynności.

Typowe błędy przy samodzielnym przenoszeniu

Częstym błędem jest importowanie całego pliku bez wcześniejszego przejrzenia danych. W efekcie do nowego programu trafiają nieaktywne kartoteki, powtórzone rekordy i dawne oznaczenia, których znaczenia nikt już nie pamięta. Późniejsze usuwanie takich wpisów może być trudniejsze, zwłaszcza gdy zdążą zostać powiązane z nowymi dokumentami.

Problemy powoduje też wielokrotne uruchamianie tego samego importu. Jeżeli system nie rozpoznaje istniejących rekordów według jednoznacznego identyfikatora, czyli wartości pozwalającej bez pomyłki wskazać konkretny wpis, mogą powstać duplikaty. Samo podobieństwo nazw nie wystarcza. Ten sam kontrahent może występować pod nazwą pełną, skróconą albo zapisaną z innymi znakami.

Nie należy poprawiać danych jednocześnie w pliku eksportowym, starym programie i nowym systemie bez ustalenia, która wersja jest nadrzędna. Prowadzi to do sytuacji, w której każda kopia zawiera inne informacje. Bezpieczniej najpierw zamknąć etap porządkowania, ponownie wykonać eksport, a następnie przeprowadzić kontrolowany import.

Ryzykowne jest również wyłączenie starego środowiska natychmiast po uruchomieniu nowego. Część informacji jest potrzebna dopiero podczas rozliczania późniejszej korekty, reklamacji albo płatności dotyczącej wcześniejszego dokumentu. Dostęp do archiwum pozwala zweryfikować takie sprawy bez przenoszenia całej historii do nowej bazy.

Kiedy problem nie wynika z migracji

Brak dokumentu w nowym systemie nie zawsze oznacza, że został utracony podczas importu. Przyczyną może być filtr daty, wybrany oddział, inny magazyn albo brak uprawnienia do podglądu danego rodzaju dokumentów. Uprawnienia to zestaw reguł określających, jakie dane użytkownik może zobaczyć lub zmienić. Przed ponownym importem warto więc sprawdzić ustawienia widoku i konto, na którym wykonywana jest kontrola.

Różnica w stanie magazynowym również nie musi wynikać z błędnego przeniesienia kartoteki. Może być skutkiem dokumentu wystawionego już po wykonaniu eksportu albo operacji zapisanej z wcześniejszą datą. Podobnie rozbieżność w saldzie kontrahenta może wynikać z płatności zaksięgowanej pomiędzy przygotowaniem danych a dniem przejścia. Dlatego porównanie powinno dotyczyć tego samego momentu i tego samego zakresu.

Wolne działanie nowego programu jest natomiast osobnym zagadnieniem. Może zależeć od konfiguracji stanowisk, sieci, serwera lub bazy, a nie od treści zaimportowanych kartotek. Takiego objawu nie powinno się automatycznie naprawiać przez kasowanie danych. Najpierw ustala się, czy opóźnienie występuje na wszystkich stanowiskach i przy wszystkich operacjach.

Dodatkowe pytania dotyczące migracji

Czy stary program trzeba zachować?

Najczęściej warto pozostawić go w trybie do odczytu, szczególnie gdy pełna historia nie została przeniesiona. Trzeba zachować nie tylko samą aplikację, lecz także bazę, wymagane składniki środowiska i możliwość legalnego uruchomienia programu. Dostęp archiwalny powinien zostać sprawdzony po zakończeniu migracji, zanim dotychczasowy komputer lub serwer zostanie wycofany.

Czy można pracować jednocześnie w obu systemach?

Podczas prób jest to możliwe, jeżeli dane testowe są wyraźnie oddzielone od rzeczywistych. Po dniu odcięcia równoległe wystawianie prawdziwych dokumentów w obu programach zwykle powoduje niespójność. Jeżeli okres przejściowy jest konieczny, trzeba dokładnie określić, które czynności wykonuje się w każdym środowisku i gdzie znajduje się obowiązująca wersja danych.

Co zrobić z dokumentami wystawionymi przed przejściem, które później trzeba skorygować?

Sposób postępowania zależy od zasad działania obu programów i przyjętego zakresu migracji. Takie przypadki należy uwzględnić przed dniem odcięcia. W praktyce potrzebny może być dostęp do dokumentu źródłowego oraz ustalona procedura wprowadzenia skutków korekty do bieżących rozliczeń. Nie powinno się tworzyć sztucznej kopii dokumentu tylko po to, aby pojawił się w nowym systemie.

Czy dane można przenieść bez udostępniania haseł pracowników?

W wielu przypadkach wystarcza dostęp administracyjny zapewniony na czas uzgodnionych czynności, bez przekazywania prywatnych haseł użytkowników. O hasło prosi się tylko wtedy, gdy wykonanie niezbędnej operacji nie jest możliwe w inny sposób, oraz po wyjaśnieniu celu. Na życzenie może zostać zawarta bezpłatna umowa NDA, czyli zobowiązanie do zachowania poufności.

Po czym poznać, że przejście zostało zakończone?

Migrację można uznać za zakończoną po uzgodnieniu danych kontrolnych, sprawdzeniu codziennych operacji oraz potwierdzeniu dostępu do archiwum. Powinno być również wiadomo, od jakiej daty system docelowy stanowi główne źródło danych. Ostatnim krokiem jest zabezpieczenie kopii stanu sprzed przejścia i opisanie miejsca, w którym przechowywana jest historia.

Dobra migracja kończy się uzgodnieniem danych, nie samym importem

Przeniesienie informacji między systemami księgowo-magazynowymi jest połączeniem porządkowania, mapowania, testowania i kontroli. Najważniejsze decyzje dotyczą nie technicznego uruchomienia importu, lecz wyboru danych potrzebnych do dalszej pracy oraz sposobu zachowania historii. Gdy zakres jest ustalony, próba wykonana na kopii, a wyniki porównane ze źródłem, zmiana programu nie musi oznaczać utraty ciągłości. Nowy system rozpoczyna wtedy pracę z uporządkowanymi danymi, a wcześniejsze dokumenty pozostają dostępne w świadomie przygotowanym archiwum.