Stały klient Growth Insider, firma z branży IT, stanął przed problemem, którego nie dało się rozwiązać zwykłym formularzem online ani prostym eksportem z bazy danych.
Firma współpracowała z ponad 10 000 wykonawców. Po kilku latach w systemie zgromadziły się dane o wypłatach, umowach i osobach, dla których trzeba było przygotować roczne informacje podatkowe IFT-1R, wygenerować poprawne pliki XML, wysłać je do systemu e-Deklaracje Ministerstwa Finansów i pobrać UPO.
Ręczna obsługa takiego procesu oznaczałaby miesiące pracy, wysokie ryzyko pomyłek i koszt liczony od każdej wysłanej deklaracji. Growth Insider przygotował na zamówienie lokalny system, który skrócił cały proces do dwóch dni i pozwolił zaoszczędzić około 20 000 zł.
To nie była standardowa usługa z oferty Growth Insider. To był projekt specjalny dla stałego klienta: custom business system do podatkowo-operacyjnego procesu, w którym liczyła się poprawność danych, kontrola statusów i formalne potwierdzenie przyjęcia dokumentów.
Szybkie podsumowanie case study
- Klient: stały klient Growth Insider
- Branża: IT
- Skala: ponad 10 000 wykonawców
- Problem: masowe przygotowanie, walidacja i wysyłka IFT-1R do administracji podatkowej
- Rozwiązanie: lokalny system do generowania XML IFT-1R, batchowej wysyłki przez bramkę MF i pobierania UPO
- Integracja: system e-Deklaracje / bramka Ministerstwa Finansów
- Wynik: proces skrócony z kilku miesięcy do dwóch dni
- Efekt finansowy: około 20 000 zł oszczędności
- Czas realizacji: 2–3 tygodnie
- Zakres Growth Insider: custom development, backend, web UI, batch processing, XML, XSD validation, SOAP integration, raportowanie
Punkt wyjścia
Klient miał dane. Miał historię wypłat, informacje o wykonawcach i dane potrzebne do rozliczeń. Nie miał jednak narzędzia, które potrafiłoby przejść przez cały proces od danych źródłowych do potwierdzonego przyjęcia dokumentu przez administrację podatkową.
Problem nie polegał na samym wygenerowaniu XML. Prawdziwe wyzwanie wyglądało tak:
dane o wypłatach roczne informacje IFT-1R XML walidacja podpisane pliki wysyłka do bramki MF statusy UPO raport końcowy.
Przy ponad 10 000 wykonawców każdy błąd w danych, brak statusu, zgubione potwierdzenie albo nieudana wysyłka mogły oznaczać setki ręcznych korekt. Dla księgowości i operacji byłby to proces trudny do kontrolowania.
Standardowe rozwiązania nie zamykały tego scenariusza w potrzebnej skali. Część narzędzi pozwalała pracować z formularzami, ale nie dawała oczekiwanej automatyzacji. Z kolei ręczna wysyłka każdego dokumentu osobno oznaczałaby zbyt duże obciążenie zespołu.
Dlatego potrzebne było narzędzie dopasowane do procesu klienta, a nie próba naginania firmy do ograniczeń gotowego systemu.
Strategia
Growth Insider potraktował projekt nie jak jednorazowy skrypt, ale jak zamknięty system operacyjny do powtarzalnego procesu.
Najważniejsze były trzy założenia.
Po pierwsze, system miał chronić klienta przed chaosem w danych. Jeśli rekord był niepełny albo zawierał krytyczny błąd, narzędzie nie miało tworzyć wadliwego dokumentu „na siłę”. Miało wskazać problem i pozwolić operatorowi go poprawić.
Po drugie, wysyłka nie mogła być czarną skrzynką. Operator musiał widzieć, co zostało wysłane, co czeka, co otrzymało UPO, co zakończyło się błędem i które elementy można bezpiecznie ponowić.
Po trzecie, sukcesem nie była sama wysyłka XML. Sukcesem było dopiero poprawne UPO, czyli formalne potwierdzenie odbioru dokumentu.
Techniczna integracja dotyczyła systemu e-Deklaracje oraz bramki Ministerstwa Finansów opisanej w sekcji bramka UBD i dokumentacja IT. Dla kontekstu użytkownika końcowego w tekście warto też wskazać e-Urząd Skarbowy, ponieważ formularz IFT-1R jest dostępny online w serwisie podatki.gov.pl.
Wdrożenie
1. Generator IFT-1R
Pierwszym elementem był generator, który przekształcał dane z bazy klienta w pliki XML IFT-1R.
System pobierał dane wykonawców, informacje o wypłatach, identyfikatory, adresy, daty urodzenia, kraje, kwoty i dane płatnika. Następnie sprawdzał obowiązkowe pola, normalizował formaty i budował dokument zgodny z wymaganą strukturą.
Po co: żeby z dużej bazy danych stworzyć komplet dokumentów podatkowych bez ręcznego przepisywania informacji.
Wpływ: mniej pracy operacyjnej, mniejsze ryzyko błędów i pełna kontrola nad rekordami, których nie dało się poprawnie przetworzyć.
2. Walidacja danych i XML
System nie zakładał, że dane wejściowe są idealne. Przy tej skali nawet niewielki procent błędnych rekordów oznaczał dziesiątki albo setki problemów.
Dlatego wdrożono kontrolę obowiązkowych pól, normalizację dat, obsługę krajów i miejsc urodzenia, zaokrąglanie kwot oraz XSD validation.
Po co: żeby zatrzymać błędne dokumenty przed wysyłką, a nie odkrywać problem dopiero po stronie bramki MF.
Wpływ: lepsza jakość dokumentów i prostsza praca z wyjątkami.
3. eDeklaracje Local Tool
Drugim elementem był lokalny system do masowej wysyłki podpisanych XML.
Narzędzie składało się z backendu, webowego interfejsu operatora i batch engine’u. Operator pracował w przeglądarce, a aplikacja działała lokalnie na komputerze, z dostępem do folderów wejściowych i wyjściowych.
System obsługiwał wybór środowiska TEST/PROD, sprawdzenie folderów, wyszukiwanie plików XML, kodowanie do base64, wysyłkę SOAP, pobieranie statusów, UPO, retry, raporty i logi.
Po co: żeby operator mógł obsłużyć tysiące dokumentów w kontrolowany sposób, bez ręcznego wysyłania każdego formularza.
Wpływ: proces, który ręcznie zająłby miesiące, został skrócony do dwóch dni.
4. Preflight check przed startem
Przed rozpoczęciem wysyłki system sprawdzał, czy proces można bezpiecznie uruchomić.
Kontrolowane były m.in. folder wejściowy, folder wynikowy, ścieżki plików, obecność XML, dostępne miejsce, lock procesu i potencjalny konflikt między input i output.
Po co: żeby nie uruchomić dużego batcha w złych warunkach technicznych.
Wpływ: mniej przerw, mniej błędów operatora i większe bezpieczeństwo procesu.
5. Batchowa wysyłka do bramki MF
Po uruchomieniu procesu system wysyłał dokumenty partiami do bramki Ministerstwa Finansów.
Dla każdego pliku wykonywał kodowanie XML do base64, wysyłkę metodą SOAP sendDocument, zapis numeru referencyjnego, kontrolę statusu i przejście do pobierania UPO.
Po co: żeby zautomatyzować powtarzalny, podatkowo istotny proces bez utraty kontroli nad pojedynczym dokumentem.
Wpływ: klient nie musiał wykonywać tysięcy osobnych operacji ręcznie.
6. Pobieranie i walidacja UPO
System nie traktował refId ani technicznego statusu jako końca procesu. Dokument był uznawany za poprawnie obsłużony dopiero po pobraniu i sprawdzeniu UPO.
UPO było weryfikowane pod kątem struktury, numeru referencyjnego, statusu przyjęcia, daty wpływu, kodu urzędu i kodu formularza.
Po co: żeby klient miał formalne potwierdzenie, że dokument został przyjęty.
Wpływ: mniejsze ryzyko fałszywego poczucia, że dokumenty są złożone, gdy w rzeczywistości proces nie został poprawnie zakończony.
7. Retry, pause, resume i raporty
Przy dużej liczbie dokumentów pojedyncze błędy są normalne. System musiał je obsłużyć bez zatrzymywania całego procesu.
Dlatego wdrożono retry dla błędów sieciowych, wymuszone ponowienie FAILED, pauzę, wznowienie, zatrzymanie procesu, manifest, lock, logi oraz eksport raportów do CSV i JSON.
Po co: żeby operator miał realny panel kontroli, a nie tylko informację, że „coś się nie udało”.
Wpływ: błędy można było rozdzielić na techniczne i wynikające z danych, a następnie obsłużyć je w uporządkowany sposób.
Wyniki
Growth Insider dostarczył lokalny system, który zamknął cały proces masowego przygotowania i wysyłki IFT-1R.
Najważniejsze efekty:
- ponad 10 000 wykonawców objętych procesem,
- skrócenie pracy z kilku miesięcy do dwóch dni,
- około 20 000 zł oszczędności,
- automatyczna generacja XML IFT-1R,
- walidacja obowiązkowych danych i struktury XML,
- lokalny interfejs operatora,
- batchowa wysyłka podpisanych XML do bramki MF,
- pobieranie i zapisywanie UPO,
- retry, pause, resume, stop,
- raporty CSV/JSON,
- kontrola statusu każdego dokumentu.
Nie dopisujemy tutaj efektów, których nie było w materiale: to nie był projekt sprzedażowy ani reklamowy. Jego wartość polegała na automatyzacji krytycznego procesu, ograniczeniu ryzyka operacyjnego i skróceniu pracy zespołu.
Najważniejszy wniosek
W projektach operacyjnych największy problem często nie leży w jednym pliku, formularzu czy integracji. Problemem jest cały proces: dane, błędy, statusy, potwierdzenia, powtarzalność i odpowiedzialność.
Ten case pokazuje, że przy dużej skali nie wystarczy „wysłać XML”. Trzeba zbudować system, który pozwala bezpiecznie przejść od danych źródłowych do potwierdzonego wyniku.
Dla klienta kluczowe było nie tylko to, że dokumenty zostały wysłane. Kluczowe było to, że można było sprawdzić, które dokumenty zakończyły się UPO, które wymagają ponowienia i gdzie wystąpił problem.
Co to oznacza dla podobnego biznesu
Podobne rozwiązanie ma sens wtedy, gdy firma wykonuje powtarzalny, administracyjny lub podatkowy proces w dużej skali.
Szczególnie wtedy, gdy występują:
- tysiące dokumentów,
- ścisły format XML,
- integracja z zewnętrznym systemem publicznym lub branżowym,
- konieczność pobierania potwierdzeń,
- duże ryzyko błędów ręcznych,
- wrażliwe dane,
- potrzeba lokalnego przetwarzania,
- brak gotowego narzędzia dopasowanego do procesu,
- konieczność raportowania każdego elementu.
W takich sytuacjach koszt ręcznej pracy szybko przewyższa koszt stworzenia własnego narzędzia. Ważniejsze jest jednak coś innego: własny system daje kontrolę nad procesem, statusem i odpowiedzialnością.
Naturalne połączenie z innymi działaniami
To nie jest usługa dostępna jako gotowy pakiet Growth Insider. Projekt został wykonany indywidualnie dla stałego klienta, który miał konkretny problem operacyjny i potrzebował rozwiązania szytego pod proces.
Najbliżej temu projektowi do obszaru tworzenia rozwiązań webowych i systemów dla firm, bo obejmował backend, lokalny interfejs, przetwarzanie danych, integrację z zewnętrzną bramką i raportowanie.
W takich projektach szczególnie ważny jest sposób prowadzenia prac: najpierw diagnoza procesu, potem architektura, następnie wdrożenie, testy i kontrola wyniku. Ten etapowy model opisujemy szerzej w sekcji jak pracujemy.
Jeśli firma ma podobny proces, którego nie da się efektywnie obsłużyć gotowym narzędziem, warto zacząć od rozmowy o danych, ryzykach i punktach awarii. Dopiero potem ma sens decyzja, czy potrzebny jest skrypt, integracja, lokalna aplikacja czy pełny system. W takim przypadku najlepiej omówić podobny projekt indywidualnie.
Podsumowanie
eDeklaracje Local Tool zamienił ręczny, kosztowny i trudny do kontroli proces w uporządkowany system lokalny.
Klient nie otrzymał „skryptu do XML”, tylko pełny kontur operacyjny: przygotowanie danych, generowanie IFT-1R, walidację, batchową wysyłkę, statusy, UPO, retry, logi i raport końcowy.
Projekt został zrealizowany w 2–3 tygodnie. W efekcie proces dla ponad 10 000 wykonawców został skrócony z kilku miesięcy do dwóch dni, a klient zaoszczędził około 20 000 zł na płatnych wysyłkach i ręcznej obsłudze.
Ten case pokazuje, że Growth Insider potrafi wejść w niestandardowy problem biznesowy, zrozumieć proces, zaprojektować narzędzie i doprowadzić pracę do mierzalnego efektu.
FAQ
Czy Growth Insider oferuje eDeklaracje Local Tool jako standardową usługę?
Nie. To był projekt specjalny, przygotowany na zamówienie dla stałego klienta. Nie jest to gotowa usługa z cennika ani publiczny produkt SaaS. Podobne rozwiązania mogą być omawiane indywidualnie, jeśli firma ma powtarzalny proces, którego nie da się dobrze obsłużyć gotowymi narzędziami.
Z czym dokładnie integrował się system?
System integrował się z bramką Ministerstwa Finansów w obszarze e-Deklaracje. W procesie wykorzystywano wysyłkę dokumentów XML i pobieranie UPO, czyli Urzędowego Poświadczenia Odbioru. Oficjalna dokumentacja e-Deklaracje opisuje m.in. wysyłkę z systemów finansowo-księgowych i pobieranie UPO, a specyfikacja IT wskazuje metody takie jak sendDocument i requestUPO.
Czy system podpisywał dokumenty elektronicznie?
Nie. Narzędzie do wysyłki pracowało na podpisanych plikach XML. Podpisywanie dokumentów było oddzielone od etapu batchowej wysyłki i kontroli statusów. Dzięki temu system miał jasny zakres odpowiedzialności: wysłać przygotowane dokumenty, pobrać statusy, zapisać UPO i pokazać operatorowi wynik.
Dlaczego UPO było ważniejsze niż sam status wysyłki?
Sama wysyłka XML nie oznacza jeszcze, że dokument został skutecznie przyjęty. Dopiero poprawne UPO daje formalne potwierdzenie odbioru dokumentu. Dlatego system uznawał dokument za zakończony sukcesem dopiero po pobraniu i sprawdzeniu UPO.
Czy podobny system można zbudować dla innych procesów?
Tak, jeśli proces ma powtarzalną strukturę: dane wejściowe, walidację, generowanie dokumentów, integrację, statusy, potwierdzenia i raportowanie. Podobne podejście może mieć sens nie tylko przy podatkach, ale też przy dużych procesach administracyjnych, księgowych, kadrowych lub operacyjnych.