Zmiana systemu magazynowo-księgowego na RAKS dla Firm nie musi oznaczać rozpoczęcia pracy od zera — dane z poprzedniego programu można przenieść, o ile migracja zostanie przeprowadzona metodycznie.

Na czym polega ta usługa

Migracja obejmuje eksport danych z dotychczas używanego systemu — kartotek towarowych, kontrahentów oraz historii dokumentów — a następnie ich import do RAKS dla Firm z zachowaniem spójności numeracji i powiązań między dokumentami.

Dla kogo ma sens

Usługa jest przeznaczona dla firm decydujących się na zmianę systemu na RAKS dla Firm, które chcą zachować historię sprzedaży i dane kontrahentów zgromadzone w poprzednim programie.

Ile to trwa

Migracja danych mieści się z reguły w standardowym czasie do 3 dni, w zależności od wielkości bazy do przeniesienia.

Warunki

Diagnoza wstępna i wycena migracji są bezpłatne. Dojazd na terenie Warszawy i okolic jest bezpłatny, a usługa objęta jest gwarancją do 12 miesięcy.

Zakres przenoszonych danych i struktura modułowa RAKS

Proces przenoszenia danych do oprogramowania RAKS dla Firm (zintegrowanego systemu zarządzania przedsiębiorstwem o budowie modułowej) wymaga podziału informacji na poszczególne obszary funkcjonalne. Struktura bazy danych programu RAKS obejmuje powiązane ze sobą rejestry, z których każdy odpowiada za określony wycinek działalności operacyjnej i finansowej.

Podstawowy zakres transferu danych obejmuje następujące grupy informacji:

Kartoteki kontrahentów: pełne dane teleadresowe odbiorców i dostawców, numery NIP (Numer Identyfikacji Podatkowej), numery REGON, rachunki bankowe w standardzie IBAN (międzynarodowy format numeru rachunku bankowego), indywidualne warunki płatności, domyślne terminy rozliczeń, limity kupieckie oraz przypisane grupy rabatowe.
Kartoteki towarowe i usługowe: indeksy asortymentowe, pełne nazwy artykułów, kody kreskowe EAN-13 (trzynastocyfrowe kody identyfikujące towary), jednostki miary podstawowe oraz przeliczniki jednostek pomocniczych, stawki podatku VAT, kody CN (Nomenklatura Scalona) oraz oznaczenia grup towarowo-usługowych GTU (symbole klasyfikacji towarów i usług wymagane w strukturze JPK_V7).
Cenniki i poziomy cenowe: zdefiniowane w dotychczasowym systemie poziomy cen hurtowych, detalicznych oraz walutowych wraz z przypisanymi marżami i walutami bazowymi.
Stany magazynowe i partie towarowe: ilościowo-wartościowe stany magazynowe wprowadzone na wyznaczony dzień odcięcia za pomocą dokumentów bilansu otwarcia magazynu, z zachowaniem przypisania do konkretnych magazynów oraz numerów partii i serii towarowych.
Rozrachunki i finanse: nierozliczone należności i zobowiązania (otwarte pozycje rozrachunkowe) z zachowaniem pierwotnych terminów płatności, numerów dokumentów źródłowych oraz kwot pozostałych do uregulowania.
Dane modułu płacowo-kadrowego: kartoteki osobowe pracowników, historia zatrudnienia, stawki zaszeregowania, przysługujące bilanse urlopowe oraz dane ewidencyjne niezbędne do sporządzania deklaracji do Zakładu Ubezpieczeń Społecznych.
Dane księgowe: plan kont, bilans otwarcia kont bilansowych i wynikowych, zapisy w rejestrach VAT oraz zestawienie obrotów i sald (ZOiS – raport podsumowujący obroty i salda wszystkich kont księgowych).

Warianty migracji danych do RAKS dla Firm

W zależności od profilu działalności przedsiębiorstwa, wielkości dotychczasowej bazy danych oraz momentu w roku obrachunkowym, w którym następuje wdrożenie, stosuje się odmienne procedury przenoszenia zasobów cyfrowych.

Wyróżnia się trzy główne warianty realizacji tego procesu:

Wariant kartotekowy ze stanami początkowymi (bilans otwarcia): model wdrażany najczęściej na przełomie roku obrachunkowego, kwartału lub miesiąca. Polega na wyeksportowaniu kartotek kontrahentów, cenników i towarów oraz wprowadzeniu do RAKS aktualnych stanów magazynowych i otwartych rozrachunków na wyznaczony dzień bilansowy. Pozwala to na rozpoczęcie pracy w nowym systemie bez obciążania bazy wieloletnią historią transakcyjną.
Wariant pełny z historią dokumentów transakcyjnych: obejmuje transfer baz danych wraz z historycznymi dokumentami sprzedaży, dokumentami magazynowymi (PZ – przyjęcie zewnętrzne, WZ – wydanie zewnętrzne, MM – przesunięcie międzymagazynowe) oraz dokumentami kasowo-bankowymi. Wymaga on precyzyjnego odtworzenia wszystkich powiązań referencyjnych i chronologii operacji gospodarczych.
Wariant konsolidacyjny (wielobazowy): stosowany w przedsiębiorstwach wielooddziałowych, które dotychczas prowadziły ewidencję w kilku rozproszonych programach lub oddzielnych bazach danych. Dane z różnych źródeł są ujednolicane, oczyszczane ze zdublowanych rekordów i łączone w jedną centralną bazę danych RAKS z podziałem na oddziały i magazyny lokalne.

Specyfika techniczna i różnice w architekturze bazodanowej

System RAKS dla Firm funkcjonuje w oparciu o relacyjne silniki bazodanowe, najczęściej Firebird lub Microsoft SQL Server. Wymusza to zachowanie spójności typów danych, unikalności kluczy głównych oraz integralności referencyjnej (zasady spójności danych wymagającej, aby każda relacja między tabelami odwoływała się do istniejącego rekordu nadrzędnego).

Przenoszenie danych ze starszych programów (na przykład opartych na plikach DBF, silnikach Pervasive PSQL czy innych generacjach systemów InsERT GT, Symfonia, WAPRO ERP lub Comarch) wiąże się z koniecznością rozwiązania specyficznych problemów technicznych:

Konwersja kodowania znaków: starsze bazy często wykorzystują przestarzałe standardy kodowania polskich znaków diakrytycznych, takie jak Mazovia, CP852 lub ISO-8859-2. Podczas migracji wszystkie ciągi tekstowe są konwertowane do standardu WIN1250 lub UTF-8, co zapobiega zniekształceniom w nazwach kontrahentów i towarów.
Formatowanie identyfikatorów podatkowych: numery NIP w systemie źródłowym bywają zapisywane z myślnikami, spacjami lub przedrostkami krajowymi. Schemat bazy RAKS wymaga jednolitego formatu, co wymaga automatycznego przefiltrowania i walidacji każdego numeru sumą kontrolną.
Różnice w algorytmach zaokrągleń: programy magazynowo-księgowe stosują odmienne metody liczenia wartości podatku VAT na dokumentach (metoda sumowania pozycji versus metoda wyliczania podatku od sumy wartości netto). Przy migracji dokumentów konieczne jest dopasowanie parametrów przeliczeniowych, aby sumy kontrolne w rejestrach były w pełni zgodne.
Ewidencja kosztu własnego sprzedaży: RAKS operuje na mechanizmach kolejkowania dostaw, takich jak metoda FIFO (First In, First Out – zasada rozchodu towaru, zgodnie z którą towar przyjęty najwcześniej jest wydawany jako pierwszy). Przeniesienie stanów magazynowych wymaga odtworzenia pierwotnych cen zakupu poszczególnych partii magazynowych.

Etapy realizacji procesu migracji danych do RAKS

Prawidłowe przeprowadzenie transferu danych wymaga metodycznego podejścia podzielonego na konkretne kroki techniczne:

Krok 1: Audyt środowiska źródłowego i analiza spójności logicznej: weryfikacja formatu plików bazy danych starego oprogramowania, wielkości zbiorów, poprawności indeksów oraz identyfikacja ewentualnych uszkodzeń tabel bazy źródłowej.
Krok 2: Przygotowanie tabel mapowania pól: określenie reguł konwersji, w których każdemu polu z bazy źródłowej przyporządkowuje się odpowiadające mu pole w docelowej strukturze bazy RAKS (na przykład powiązanie symboli grup towarowych, kodów stawek podatkowych i form płatności).
Krok 3: Oczyszczenie i normalizacja danych: eliminacja zduplikowanych kartotek kontrahentów o identycznym numerze NIP, usunięcie niedozwolonych znaków z nazw towarów, uzupełnienie brakujących jednostek miar oraz standaryzacja kodów pocztowych.
Krok 4: Wykonanie migracji testowej: import przetworzonych danych do tymczasowej bazy testowej RAKS. Na tym etapie generowane są zestawienia kontrolne porównujące stany magazynowe, salda rozrachunków oraz obroty kont z danymi w starym programie.
Krok 5: Weryfikacja i akceptacja wyników: weryfikacja poprawności zestawień przez osoby odpowiedzialne za księgowość i gospodarkę magazynową w przedsiębiorstwie.
Krok 6: Ostateczny import produkcyjny: transfer danych w uzgodnionym oknie czasowym (po zakończeniu pracy w starym systemie), utworzenie kopii bezpieczeństwa (backupu) i udostępnienie bazy RAKS do bieżącej pracy operacyjnej.

Błędy popełniane przy próbach samodzielnego transferu danych

Próby samodzielnego przenoszenia baz danych przy użyciu prostych arkuszy kalkulacyjnych lub niesprawdzonych skryptów konwertujących stwarzają ryzyko naruszenia spójności danych i powstania trudnych do wykrycia błędów księgowych.

Do najczęstszych problemów należą:

Obcinanie zer wiodących: otwieranie wyeksportowanych plików w programach biurowych bez wymuszenia formatu tekstowego skutkuje automatycznym usuwaniem początkowych zer w kodach pocztowych (na przykład zamiana kodu 00-950 na 950) lub numerach NIP i kodach EAN, co powoduje błędy walidacji w RAKS.
Zrywanie powiązań rozrachunkowych: zaimportowanie faktur sprzedaży bez jednoczesnego powiązania ich z wpłatami kasowymi i bankowymi prowadzi do sytuacji, w której kontrahenci figurują w nowym programie jako dłużnicy z nieuregulowanymi płatnościami.
Błędne zdefiniowanie jednostek miar: import towarów bez określenia przeliczników między jednostką magazynową a jednostką zakupu lub sprzedaży wywołuje błędy przy wyliczaniu stanów ilościowych i cen jednostkowych.
Powstanie ujemnych stanów magazynowych: zaimportowanie dokumentów rozchodowych przed dokumentami przychodowymi lub pominięcie bilansu otwarcia partii towarowych blokuje możliwość wystawiania dokumentów w systemie kontrolującym stany magazynowe.
Brak wykonania kopii bezpieczeństwa: przeprowadzanie importu bezpośrednio na działającej bazie bez zabezpieczenia stanu wyjściowego, co w przypadku wystąpienia błędu uniemożliwia przywrócenie poprzedniego stanu systemu.

Kiedy pełna migracja historii nie jest optymalnym rozwiązaniem

W wielu sytuacjach próba przeniesienia całościowej, wieloletniej historii transakcyjnej ze starego oprogramowania nie jest uzasadniona pod względem organizacyjnym i technicznym.

Przeniesienie wyłącznie bilansu otwarcia i aktywnych kartotek okazuje się lepszym wyborem w następujących przypadkach:

Duża liczba nieaktywnych rekordów: bazy danych użytkowane przez wiele lat zawierają tysiące jednorazowych kontrahentów oraz wycofanych towarów. Przeniesienie takich danych powoduje niepotrzebny rozrost bazy danych i utrudnia codzienne wyszukiwanie bieżących pozycji.
Błędy merytoryczne w starym systemie: jeśli w dotychczasowym programie występowały nieskorygowane rozbieżności magazynowe, błędy w stawkach podatkowych lub nieuzgodnione salda rozrachunków, import historii przeniesie te nieprawidłowości do nowego środowiska.
Zmiana planu kont lub struktury magazynowej: wdrożenie RAKS łączy się często z reorganizacją procesów magazynowych lub zmianą polityki rachunkowości. W takim przypadku dane historyczne nie odpowiadają nowemu schematowi dekretacji i podziałowi na działy.

W takich sytuacjach zaleca się zarchiwizowanie dotychczasowego programu w trybie tylko do odczytu (w celu zachowania wglądu do dokumentów na potrzeby kontroli skarbowych) oraz przeniesienie do RAKS wyłącznie zweryfikowanych stanów początkowych i aktualnych słowników.

Najczęściej zadawane pytania dotyczące migracji do RAKS

Czy podczas migracji danych przedsiębiorstwo musi wstrzymać sprzedaż i wystawianie faktur?

Nie ma konieczności długotrwałego wstrzymywania bieżącej pracy firmy. Główne prace analityczne, budowa tabel mapowania oraz migracja próbna odbywają się na kopii roboczej bez ingerencji w działający system. Ostateczny transfer danych planuje się zazwyczaj na godziny popołudniowe, nocne lub dni wolne od pracy, dzięki czemu ciągłość operacyjna zostaje zachowana.

Z jakich programów magazynowych i księgowych można przenieść dane do RAKS?

Dane można przenieść z dowolnego oprogramowania, które umożliwia wyeksportowanie informacji do formatów bazodanowych (takich jak SQL, DBF) lub plików strukturalnych (XML, CSV, XLS, TXT). Dotyczy to systemów takich jak InsERT GT i nexo, Symfonia, WAPRO ERP, Comarch ERP Optima, a także starszych programów dosowych oraz aplikacji dedykowanych.

W jaki sposób weryfikuje się poprawność zaimportowanych danych finansowych i magazynowych?

Weryfikacja opiera się na porównaniu raportów sum kontrolnych wygenerowanych niezależnie z systemu źródłowego oraz z bazy RAKS. Porównywane są między innymi: łączna wartość magazynu w cenach zakupu i sprzedaży, suma należności i zobowiązań na dany dzień, zgodność liczby zaimportowanych pozycji kartotekowych oraz zestawienie obrotów i sald.

Czy poufne dane handlowe i finansowe przedsiębiorstwa są chronione podczas migracji?

Wszelkie operacje na bazach danych wykonywane są z zachowaniem procedur bezpieczeństwa teleinformatycznego. Na życzenie zlecającego podpisywana jest umowa o zachowaniu poufności (NDA – Non-Disclosure Agreement), która formalnie zabezpiecza tajemnicę przedsiębiorstwa, bazy klientów oraz informacje finansowe.

Czy po migracji danych wymagana jest dodatkowa konfiguracja parametrów pracy RAKS?

Po zakończeniu importu kartotek i dokumentów bilansu otwarcia konieczne jest skonfigurowanie parametrów pracy systemu, takich jak serie numeracji dokumentów, domyślne schematy księgowania, uprawnienia użytkowników oraz wzorce wydruków dokumentów handlowych i magazynowych.

Bezpieczeństwo transferu danych i ciągłość procesów w RAKS dla Firm

Prawidłowo zaplanowana i przeprowadzona migracja danych z dotychczasowego oprogramowania do systemu RAKS dla Firm zabezpiecza przedsiębiorstwo przed utratą ciągłości ewidencji handlowo-magazynowej. Usunięcie błędów strukturalnych, standaryzacja kartotek kontrahentów oraz dokładne przeniesienie bilansu otwarcia pozwalają na płynne rozpoczęcie pracy w nowym środowisku bez zakłócania bieżącej obsługi zamówień i realizacji dostaw.

Wszystkie czynności wdrożeniowe i serwisowe realizowane są bezpośrednio w siedzibie klienta na terenie Warszawy oraz okolicznych powiatów (w tym grodziskiego, legionowskiego, otwockiego, piaseczyńskiego, pruszkowskiego, warszawskiego zachodniego oraz wołomińskiego), co zapewnia stały nadzór nad integralnością infrastruktury informatycznej firmy.

22 378 48 09

Migracja danych z innego systemu do RAKS dla Firm