Jak zmienić system rozliczeniowy w zakładzie wod-kan bez utraty historii danych

Kiedy zakład decyduje się na zmianę systemu rozliczeniowego

Decyzja rzadko wynika z jednej przyczyny. Zwykle nakłada się na siebie kilka sygnałów: kończy się wsparcie dla używanej wersji oprogramowania, koszty utrzymania rosną szybciej niż zakres funkcji, pojawiają się nowe obowiązki sprawozdawcze, których dotychczasowe rozwiązanie nie obsługuje, albo zakład rozszerza działalność o obszary nieobjęte systemem, takie jak gospodarka mieszkaniowa czy odpady.

Osobną grupą są zakłady, które nie mają jednego systemu, tylko zestaw narzędzi i arkuszy obsługujących kolejne fragmenty procesu. Dla nich zmiana nie polega na wymianie oprogramowania, lecz na pierwszym uporządkowaniu procesu w jednym miejscu — moment, w którym to staje się konieczne, opisuje artykuł o tym, kiedy Excel przestaje wystarczać w rozliczeniach wod-kan.

Niezależnie od przyczyny warto rozdzielić dwie decyzje, które w rozmowach często się zlewają. Pierwsza dotyczy tego, jakich funkcji zakład potrzebuje — to temat wyboru systemu, opisany szerzej w artykule o tym, jak wybrać program dla wodociągów. Druga dotyczy tego, jak bezpiecznie przejść z jednego rozwiązania na drugie. Ten artykuł dotyczy wyłącznie drugiej.

Co właściwie znaczy „historia danych” w zakładzie wod-kan

Pytanie „czy stracimy historię” jest zbyt ogólne, żeby dało się na nie odpowiedzieć. Historia to kilka odrębnych zbiorów o różnym znaczeniu prawnym i różnym stopniu przenoszalności. Warto rozpisać je osobno, bo dopiero wtedy widać, o co realnie trzeba zawalczyć w rozmowie z dotychczasowym dostawcą.

Kartoteki odbiorców i obiektów

To fundament, bez którego nic innego nie ma sensu. Kontrahent z danymi adresowymi, identyfikatorami, parametrami rozliczeń, przypisaniem do grup, powiązanymi rachunkami oraz historią zmian. Obiekt z adresem, właścicielem, własnościami i powiązaniem z kontrahentem. Ten zbiór przenosi się jako dane robocze i jego kompletność decyduje o powodzeniu całości.

Trudność polega na tym, że w starym systemie te dane bywają zapisane w polach opisowych, uwagach i notatkach, a nie w strukturze. Adres wpisany w jedno pole tekstowe zamiast w rozbicie na miejscowość, ulicę i numer wymaga rozdzielenia, a nie przepisania.

Wodomierze i ich historia

Urządzenie to nie tylko numer fabryczny i data montażu. Pełny obraz obejmuje statusy, historię montaży, wymian, demontaży, plombowań, legalizacji i konserwacji, a przy odczytach zdalnych także powiązanie z nadajnikiem. Ta historia jest potrzebna przy reklamacjach i korektach rozliczeń, więc jej utrata jest odczuwalna od razu — pierwsza reklamacja po zmianie systemu zwykle dotyczy okresu sprzed migracji.

W praktyce jest to zbiór najczęściej niekompletny w systemie źródłowym, bo część operacji bywała dokumentowana protokołami papierowymi. Uporządkowanie tego obszaru opisuje strona o gospodarce wodomierzowej.

Odczyty i historia zużyć

Odczyty przenosi się zwykle w pełnym zakresie, bo są potrzebne do porównań, wykrywania nietypowych zużyć i wyjaśniania reklamacji. Kluczowe jest zachowanie powiązania odczytu z konkretnym urządzeniem i punktem rozliczeniowym, a nie tylko z odbiorcą. Odczyt oderwany od wodomierza traci wartość dowodową w momencie, gdy urządzenie zostało w międzyczasie wymienione.

Dokumenty sprzedaży, salda i wpłaty

Tu przebiega najważniejsza granica całej migracji. Dokumenty historyczne zwykle nie są przenoszone jako dokumenty do dalszego przetwarzania — pozostają w archiwum. Do nowego systemu trafiają natomiast stany: saldo odbiorcy na dzień przejęcia, nierozliczone dokumenty, zaległości i ewentualne nadpłaty. To rozróżnienie bywa źródłem nieporozumień, bo z perspektywy biura obsługi „mieć historię faktur” i „mieć poprawne saldo” to dwie różne rzeczy, a tylko druga jest warunkiem uruchomienia rozliczeń.

Umowy, zgody i dane wrażliwe

Umowy i aneksy przenoszą się zwykle jako rejestr z załącznikami, rzadziej jako edytowalne dokumenty. Osobnej uwagi wymagają zgody, oświadczenia i informacje o przetwarzaniu danych osobowych — one nie tyle się migrują, ile muszą zostać odwzorowane w nowym systemie zgodnie z tym, na co odbiorca faktycznie wyraził zgodę.

Czego zwykle nie da się przenieść — i co z tym zrobić

To sekcja, której brakuje w większości materiałów o wdrożeniach, a która najbardziej przydaje się przy planowaniu. Poniższe elementy w praktyce nie podlegają migracji jeden do jednego.

• Konfiguracja starego systemu. Układy list, definicje raportów, szablony wydruków, struktura uprawnień i przyzwyczajenia interfejsu są związane z konkretnym oprogramowaniem. Nowy system trzeba skonfigurować od nowa, a nie odtworzyć poprzedni.
• Historia operacji operatorów i logi systemowe. Zapis, kto i kiedy wykonał czynność w starym systemie, zostaje w starym systemie. Nowa historia zmian zaczyna się od dnia uruchomienia.
• Wydruki i wersje dokumentów w formatach zamkniętych. Wygenerowane dokumenty można zwykle zachować jako pliki, ale ich powiązanie z rekordami bywa tracone, a odtworzenie identycznego wyglądu wydruku nie jest celem migracji.
• Dane, których dotychczasowy dostawca nie wyda w czytelnej strukturze. Jeżeli eksport ma postać zbioru bez opisu struktury albo formatu, którego nie da się jednoznacznie zinterpretować, zakres migracji zawęża się niezależnie od możliwości nowego systemu. To jest realne ograniczenie i trzeba je zaadresować umową, o czym w następnej sekcji.
• Część załączników. Skany i zdjęcia zwykle da się przenieść jako pliki, ale powiązanie ich z właściwym dokumentem, operacją lub sprawą wymaga, aby w eksporcie znalazła się informacja o tym powiązaniu. Bez niej powstaje katalog plików, a nie dokumentacja.
• Nietypowe algorytmy naliczeń. Indywidualne sposoby rozliczania, ulgi, dopłaty czy struktury bilansowe o nietypowej konstrukcji odtwarza się od nowa jako konfigurację, a nie przenosi jako dane. To zwykle najbardziej pracochłonna część projektu i warto ją zidentyfikować na samym początku.

Praktyczna odpowiedź na te ograniczenia to podział wszystkich zasobów na trzy grupy, ustalony na piśmie przed startem prac: dane migrowane do kartotek nowego systemu, archiwum tylko do odczytu utrzymywane przez wymagany okres oraz elementy odtwarzane od nowa jako konfiguracja. Jeżeli ten podział powstaje dopiero w trakcie wdrożenia, każda niejasność zamienia się w spór o zakres.

Jak zabezpieczyć dostęp do własnych danych, zanim będzie potrzebny

Nie istnieje przepis, który sam z siebie nakazywałby dostawcy oprogramowania wydanie danych w formacie użytecznym do migracji. Podstawą jest umowa — i to jest najważniejsze zdanie w całym artykule. Moment na uregulowanie tej kwestii przypada na podpisywanie umowy z dowolnym dostawcą, a nie na dzień, w którym zakład planuje ją wypowiedzieć.

W praktyce warto zapisać w umowie utrzymania lub w klauzuli wyjścia co najmniej:

• zakres danych podlegających wydaniu, opisany rzeczowo, a nie hasłem „dane zamawiającego”,
• format eksportu, najlepiej otwarty i powszechnie czytelny, wraz z obowiązkiem przekazania opisu struktury danych,
• termin, w jakim dane mają zostać wydane po zakończeniu umowy,
• kto ponosi koszty przygotowania eksportu i czy są one ujęte w wynagrodzeniu podstawowym,
• obowiązek współpracy w okresie pomiędzy wypowiedzeniem a zakończeniem umowy,
• zasady postępowania z danymi po stronie dostawcy po zakończeniu współpracy: zwrot, zniszczenie albo dalsza archiwizacja.

Ostatni punkt ma dodatkowy wymiar prawny. Zakład jest administratorem danych osobowych odbiorców, a dostawca systemu podmiotem przetwarzającym, więc obowiązuje umowa powierzenia przetwarzania. Zgodnie z RODO po zakończeniu świadczenia usług przetwarzający — zależnie od decyzji administratora — usuwa albo zwraca dane osobowe i usuwa kopie, chyba że przepisy nakazują ich dalsze przechowywanie. Decyzja należy do zakładu, więc powinna zostać podjęta świadomie, a nie pozostawiona domyślnemu zachowaniu drugiej strony.

W zakładach kupujących oprogramowanie w reżimie zamówień publicznych temat ma jeszcze jeden wymiar. Urząd Zamówień Publicznych wydał rekomendacje dotyczące zamówień publicznych na systemy informatyczne, które wprost adresują przeciwdziałanie uzależnieniu od jednego wykonawcy. Typowe zaniedbania wskazywane w tym kontekście to brak wymogu przekazania pełnej dokumentacji technicznej oraz brak praw do procedur i informacji pozwalających odtworzyć działanie systemu. Warto podkreślić, że jest to ryzyko umowne występujące niezależnie od producenta — nie cecha konkretnego dostawcy.

Osobno trzeba rozstrzygnąć archiwum. Ustawa o rachunkowości wymaga przechowywania ksiąg rachunkowych przez co najmniej 5 lat, licząc od początku roku następującego po roku obrotowym, którego zbiory dotyczą, a zatwierdzonych rocznych sprawozdań finansowych przez co najmniej 5 lat od początku roku następującego po roku ich zatwierdzenia — art. 74 ustawy o rachunkowości. Równolegle Ordynacja podatkowa i ustawa o VAT nakazują przechowywanie ksiąg, ewidencji i faktur do czasu upływu przedawnienia zobowiązania podatkowego. Praktyczna konsekwencja jest taka, że starego systemu zwykle nie da się wyłączyć w dniu uruchomienia nowego. Trzeba zdecydować, czy dostęp do archiwum zapewnia utrzymywana instancja tylko do odczytu, czy wyeksportowany zbiór z opisem struktury, i kto odpowiada za jego czytelność przez cały wymagany okres.

Jak zaplanować przejście: etapy, praca równoległa i moment startu

Typowa sekwencja obejmuje analizę przedwdrożeniową, ustalenie zakresu danych do migracji, uporządkowanie danych źródłowych, mapowanie struktur, migrację próbną, testy akceptacyjne, migrację pełną, start produkcyjny i okres stabilizacji. Liczba etapów i czas ich trwania zależą od stanu danych oraz od zakresu wdrożenia, więc nie warto przyjmować z góry harmonogramu przepisanego z innego projektu.

Wybór momentu w roku

Najbezpieczniejsze są granice: koniec okresu rozliczeniowego, koniec roku obrotowego, początek nowego okresu taryfowego. Najgorszy jest środek okresu odczytowego. Powód jest prosty: część odczytów byłaby wtedy zarejestrowana w starym systemie, część w nowym, a naliczenie musiałoby powstać na dwóch niepełnych zestawach danych. Każda reklamacja z takiego okresu wymaga później sięgania do obu systemów.

Drugie kryterium to obciążenie działu rozliczeń. Przejście w szczycie fakturowania lub w okresie zamknięcia roku kumuluje ryzyko w momencie, w którym zespół ma najmniej czasu na testy.

Migracja próbna i testy akceptacyjne

Migracja próbna wykonywana na kopii danych służy nie tylko sprawdzeniu, czy import się powiódł. Jej właściwym celem jest porównanie: liczby kontrahentów, obiektów i wodomierzy, sumy sald, liczby aktywnych formuł rozliczeniowych i punktów bez przypisanego urządzenia. Rozbieżność w tych liczbach jest sygnałem, że mapowanie pominęło jakąś kategorię rekordów.

Testy akceptacyjne powinny prowadzić właściciele obszarów, a nie wyłącznie dział IT. Najlepszym testem jest przeliczenie kontrolne wybranej grupy odbiorców — najlepiej takich, których rozliczenie jest nietypowe: struktury bilansowe, ryczałty, odbiorcy z podlicznikami, przypadki z korektami. Zgodność wyniku w obu systemach na tej samej próbce mówi więcej niż zgodność sum globalnych.

Salda otwarcia i zamknięcie okresu

Zamiast przenosić całą historię księgową, ustala się dzień graniczny i wprowadza salda otwarcia. Zakres tej operacji trzeba uzgodnić z księgowością, bo to ona odpowiada za zgodność stanów z księgami. Wymaga to również decyzji, co dzieje się z dokumentami wystawionymi po dniu granicznym, ale dotyczącymi okresu wcześniejszego, oraz z wpłatami przypisanymi już po przejściu.

Ciągłość numeracji dokumentów

Numeracja faktur musi zapewniać ciągłość ewidencjonowania, więc przy zmianie systemu trzeba świadomie zdecydować, czy nowy system kontynuuje dotychczasowe serie i liczniki, czy zaczyna nową serię od wyraźnej granicy. Obie drogi są dopuszczalne, ale decyzja powinna być podjęta wspólnie z księgowością przed startem, a nie odkryta przy pierwszym dokumencie.

Podobnie należy potraktować dokumenty przekazywane do Krajowego Systemu e-Faktur. Uprawnienia i certyfikaty są przypisane do podatnika, a nie do konkretnego programu, a faktury już przesłane pozostają w systemie z nadanymi numerami. Przed startem warto jednak sprawdzić, czy nowe oprogramowanie ma nadany właściwy zakres uprawnień, i uzgodnić, od którego dokumentu wysyłkę realizuje nowy system.

Indywidualne rachunki i płatności masowe

To najczęstsza obawa w rozmowach i zwykle nadmierna. Wirtualny numer rachunku ma format NRB i składa się z części identyfikującej bank oraz maski powiązanej z rachunkiem rozliczeniowym zakładu, a także z części zmiennej zawierającej identyfikator odbiorcy. Maska jest nadawana przez bank i nie należy do oprogramowania.

Wniosek jest praktyczny: zmiana systemu nie musi oznaczać zmiany numerów rachunków, o ile nowy system odtworzy dotychczasowy sposób budowania identyfikatora odbiorcy. Numery zmienią się dopiero wtedy, gdy zmieni się zasada identyfikacji — i wtedy trzeba zaplanować powiadomienie odbiorców oraz liczyć się z tym, że część z nich ma ustawione zlecenia stałe. Ustalenie tego z bankiem należy do pierwszych czynności w projekcie, nie do ostatnich.

Praca równoległa i decyzja, który system jest źródłem prawdy

Praca równoległa bywa potrzebna, ale jest kosztowna i nie może trwać w nieskończoności. Najważniejsze jest jednoznaczne wskazanie momentu, od którego nowy system jest jedynym miejscem wystawiania dokumentów i rejestrowania wpłat. Bez tej decyzji powstają rozbieżności, których nikt nie potrafi później rozstrzygnąć, bo obie bazy są częściowo aktualne.

Osobno trzeba zaplanować integrację z systemem finansowo-księgowym. Wymiana danych musi działać od pierwszego dnia pracy produkcyjnej, więc jej testy należą do zakresu testów akceptacyjnych, a nie do etapu stabilizacji. Kontekst takiej wymiany opisuje artykuł o integracji z Comarch ERP Optima.

Jak wygląda przejęcie danych w systemie GW-MAX

Zakres i przebieg przejęcia danych zależą od stanu danych źródłowych oraz od tego, co uda się uzyskać z dotychczasowego systemu i w jakiej strukturze. Poniżej opisujemy, do czego dane trafiają po stronie GW-MAX i jakie narzędzia system udostępnia przy ich porządkowaniu — bez zakładania z góry, że każdy zbiór da się przenieść w całości.

Kartoteki jako punkt docelowy migracji

Podstawowym miejscem docelowym są kartoteki modułu Zarządzanie: kontrahenci z danymi, grupami, adresami, parametrami rozliczeń i rachunkami oraz obiekty z adresem, geolokalizacją, właścicielem i własnościami. To one pełnią rolę źródła prawdy dla pozostałych obszarów, dlatego ich kompletność ustala się jako pierwszą. Dalsze procesy rozliczeniowe opierają się już na tych danych, co opisuje strona o rozliczaniu wody i ścieków.

Szablony kartotek, słowniki i walidacje

System udostępnia szablony kartotek i kreatory oraz liczniki numeracji, a także walidacje NIP, PESEL i REGON oraz walidację rachunków płatności masowych. Przy przejmowaniu danych z innego systemu to właśnie walidacje ujawniają problemy, które wcześniej były niewidoczne: niepoprawne identyfikatory, duplikaty, rekordy bez wymaganych pól. Uruchomienie ich na danych próbnych jest tańsze niż wykrywanie tych samych błędów po starcie produkcyjnym.

Operacje seryjne przy porządkowaniu przejętych danych

Po wczytaniu danych zwykle trzeba je uporządkować grupowo, a nie rekord po rekordzie. Służą do tego operacje seryjne: masowe dopinanie do grup oraz podmiana parametrów rozliczeń według szablonu. To istotne przy zakładach z tysiącami odbiorców, gdzie ręczna korekta parametrów byłaby niewykonalna.

Urządzenia, formuły, struktury bilansowe i cenniki

Gospodarka Wodomierzowa prowadzi ewidencję wodomierzy i nadajników radiowych wraz z historią eksploatacji, plombowań i konserwacji oraz operacjami montażu, wymiany i legalizacji. Formuły obciążeń określają sposób rozliczania punktu — wodomierz, ryczałt lub inny — a struktury bilansowe opisują relację między zasilaniem a odbiorem wraz z algorytmem podziału. Cenniki prowadzone są z historią cen i stawek VAT, co ma znaczenie przy odtwarzaniu rozliczeń z okresów sprzed migracji.

Płatności masowe i wymiana danych z systemem finansowo-księgowym

System wspiera generowanie indywidualnych rachunków odbiorców na podstawie akronimu, identyfikatora lub licznika, wraz z walidacją i seryjnym nadaniem. To jest miejsce, w którym rozstrzyga się, czy dotychczasowe numery rachunków zostaną odtworzone, czy powstaną nowe. Dokumenty i wpłaty mogą być natomiast wymieniane z Comarch ERP Optima lub XL przez usługę synchronizacji, co należy przetestować przed startem, a nie po nim.

Historia zmian i obsługa danych osobowych

System prowadzi pełną historię zmian w kartotekach, a w obszarze danych osobowych udostępnia flagę oznaczającą rekordy zawierające dane osobowe, obsługę zgód i ankiet, dzienniki naruszeń oraz nieodwracalną anonimizację. Warto pamiętać, że historia zmian dotyczy operacji wykonanych w tym systemie — zapisy z poprzedniego oprogramowania pozostają po jego stronie.

Czego system nie rozstrzyga za zakład

Oprogramowanie nie zdecyduje, które zbiory podlegają migracji, a które pozostają archiwum, ani nie zastąpi ustaleń z dotychczasowym dostawcą co do zakresu i formatu eksportu. Nie rozstrzygnie też, na jaki dzień ustalić salda otwarcia, jak potraktować numerację i czy zmieniać numery rachunków odbiorców — to decyzje po stronie zakładu, jego księgowości i banku. Rola systemu zaczyna się tam, gdzie dane są już dostępne w czytelnej strukturze.

Lista kontrolna przed zmianą systemu

Przed rozpoczęciem projektu warto mieć odpowiedzi na poniższe pytania:

• co obecna umowa mówi o wydaniu danych po jej zakończeniu, w jakim zakresie, formacie i terminie oraz na czyj koszt,
• czy zakład dysponuje opisem struktury danych, a nie tylko samym zbiorem,
• jakie zbiory obejmuje zamówiony eksport: kontrahenci, obiekty, wodomierze z operacjami, odczyty, formuły, struktury bilansowe, cenniki, dokumenty, salda, wpłaty, umowy, załączniki,
• jak zostaną powiązane załączniki i skany z dokumentami, których dotyczą,
• które elementy zostaną odtworzone jako konfiguracja, a nie przeniesione jako dane,
• na jaki dzień ustalane są salda otwarcia i kto po stronie księgowości je zatwierdza,
• jak zostanie rozwiązana numeracja dokumentów po dniu przejścia,
• czy indywidualne numery rachunków pozostaną bez zmian, a jeśli nie — jak i kiedy powiadomieni zostaną odbiorcy,
• co ustalono z bankiem w sprawie maski i identyfikatorów w usłudze płatności masowych,
• w jakiej formie i przez jaki okres zapewniony będzie dostęp do archiwum wymaganego przepisami o rachunkowości i przepisami podatkowymi,
• jaka jest decyzja administratora danych co do losu danych osobowych po stronie dotychczasowego dostawcy,
• jaki zakres testów akceptacyjnych zostanie przeprowadzony i na jakiej próbce odbiorców nietypowych,
• od kiedy dokładnie nowy system jest jedynym źródłem prawdy i kto o tym informuje pracowników.

Lista nie zastępuje analizy prawnej ani ustaleń z księgowością. Pozwala jednak sprawdzić, czy projekt ma rozstrzygnięte kwestie, które najczęściej ujawniają się dopiero po starcie, gdy koszt ich naprawy jest najwyższy.

Podsumowanie

Zmiana systemu rozliczeniowego w zakładzie wod-kan udaje się wtedy, gdy zakład wcześniej rozstrzygnie, co jest danymi, co archiwum, a co konfiguracją do zbudowania od nowa. Utrata historii rzadko wynika z ograniczeń nowego oprogramowania — częściej z tego, że danych nie udało się uzyskać w czytelnej strukturze albo że nikt nie ustalił, czego właściwie zażądać.

• Historia danych to kilka odrębnych zbiorów, a każdy z nich przenosi się na innych zasadach.
• Część informacji nie podlega migracji i lepiej wiedzieć to przed rozpoczęciem projektu niż w jego trakcie.
• Prawo do eksportu danych zabezpiecza się w umowie z dostawcą, a nie w dniu jej wypowiedzenia.
• Obowiązki archiwizacyjne zwykle wymuszają utrzymanie dostępu do starego zbioru przez wymagany okres.
• Granica okresu rozliczeniowego lub roku obrotowego jest bezpieczniejszym momentem przejścia niż środek okresu odczytowego.
• Indywidualne numery rachunków nie muszą się zmienić, o ile nowy system odtworzy dotychczasowy sposób identyfikacji odbiorcy.
• GW-MAX przyjmuje dane do kartotek, waliduje je i udostępnia operacje seryjne, ale zakres przejęcia zależy od jakości i dostępności danych źródłowych.