Trzy kanały, żadnej wspólnej kolejki
Zastrzeżenie: RAN-SIGMA to firma, którą zarządzam. Ten system powstał najpierw na własne potrzeby i dopiero sprawdzony trafił do oferty — tak samo testuję każde rozwiązanie, zanim zaproponuję je klientowi.
RAN-SIGMA specjalizuje się w odbiorze i przetwarzaniu olejów przepracowanych — każdego miesiąca przez firmę przepływa kilkaset faktur kosztowych. Problem w tym, że każda z nich trafiała innym kanałem: część mailowo na wspólną skrzynkę, część przez KSeF, część jako skan ręczny. Nie było jednego miejsca, jednej kolejki ani jednego procesu.
E-faktury drukowano, żeby wrzucić je do obiegu, duplikaty trafiały do akceptacji kilkukrotnie, weryfikacja właścicielska zdarzała się po miesiącu lub wcale, a archiwum zajmowało fizyczną przestrzeń biurową. Brak kontroli dostępu oznaczał, że każdy widział wszystko.
8 dysfunkcji, które zlikwidował system
| Obszar | Przed (AS-IS) | Po (TO-BE) |
|---|---|---|
| Odbiór e-faktur | Drukowanie dokumentów cyfrowych | Automatyczne przechwycenie z e-maila i KSeF |
| Odrzucenie dokumentu | Brak formalnej ścieżki odrzucenia | Workflow z wymaganym komentarzem i powiadomieniem |
| Weryfikacja właścicielska | Opóźniona o tygodnie lub miesiące | W czasie rzeczywistym — notyfikacja przy wpływie |
| Kanały wpływu | 3 niezależne, niepołączone kanały | Jedna kolejka bez względu na źródło |
| Duplikaty | Brak wykrywania, faktury akceptowane wielokrotnie | Automatyczna deduplikacja przy imporcie |
| Archiwum | Segregatory, fizyczna przestrzeń biurowa | Cyfrowe archiwum z przechowywaniem 5+ lat |
| Analityka | Brak danych o czasie przetwarzania i zaległościach | Panel admina z metrykami i eksportem CSV |
| Kontrola dostępu | Brak rozróżnienia ról, każdy widzi wszystko | Supabase RLS — każda rola widzi swój zakres |
Co zbudowaliśmy
Dedykowaną platformę EOD pod domeną EODSIGMA.PL — zbudowaną na Lovable i Supabase, wdrożoną w 10 tygodni. System obsługuje pełny cykl życia dokumentu: od wpływu przez OCR, akceptację wieloetapową, aż po cyfrowe archiwum.
Trzy kanały wpływu — jedna kolejka
Faktury trafiają z Gmaila (OAuth2, skrzynka faktury@ransigma.pl), z KSeF i z ręcznego uploadu, a niezależnie od źródła lądują w jednej kolejce.
OCR i deduplikacja przy imporcie
OCR wyciąga z pliku dane kontrahenta, numer faktury, kwotę i datę, a duplikat system blokuje na poziomie importu, zanim trafi do kolejki.
Workflow akceptacji i ścieżka odrzucenia
Dokument przechodzi skonfigurowany wieloetapowy workflow, a ścieżka odrzucenia wymaga komentarza i powiadamia nadawcę przez Resend.
Konto tylko z zaproszenia i Supabase RLS
Nie ma publicznej rejestracji, a Row Level Security ogranicza widoczność dokumentów do zakresu roli, która o nie pyta.
Panel admina i analityka
Liczba dokumentów w kolejce, średni czas akceptacji, zaległości według użytkownika i wolumen według miesiąca, z eksportem do CSV i wyszukiwarką kontrahentów.
Karta dokumentu ma wbudowany podgląd PDF, więc nikt nie pobiera pliku po to, żeby zobaczyć, co podpisuje. Każda zmiana statusu, komentarz, odrzucenie i akceptacja zapisują się ze znacznikiem czasu i użytkownikiem, a pełna historia zmian jest w jednym miejscu.
Zaakceptowane dokumenty lądują na Google Drive w zdefiniowanej strukturze folderów, przeglądanej z poziomu systemu. Powiadomienia Resend pilnują etapów — nowy dokument do akceptacji, odrzucenie z komentarzem, przekroczenie czasu oczekiwania, akceptacja — a szablony wiadomości noszą identyfikację wizualną klienta.
Rozstrzygnięcia, na których stoi ten obieg
Duplikat zatrzymuję przy imporcie, nie przy akceptacji. Kanały wpływu z zasady nic o sobie nie wiedzą, więc ten sam dokument może wejść dwiema drogami. Duplikat wychwycony dopiero przy podpisie zdążył już zająć czyjąś uwagę; odcięty przy imporcie nie wchodzi wcale. Przy webhookach tę samą robotę wykonuje klucz idempotencji.
O tym, kto podpisuje, decyduje typ dokumentu i jego wartość. Tabela kompetencji wiąże te dwie rzeczy ze ścieżką akceptacji, więc dopisanie nowego progu albo typu dokumentu jest w tej automatyzacji procesu zmianą wiersza w tabeli, nie zmianą kodu.
Ukrycie przycisku na ekranie nie jest kontrolą dostępu — wystarczy nowy widok albo zapytanie zadane poza tym ekranem i dane wracają. Uprawnienie w dedykowanej aplikacji webowej siedzi więc przy danych, nie w interfejsie: dokument spoza zakresu roli w ogóle nie wraca z zapytania.
Liczby, które opisują ten obieg
500 faktur i 125 h miesięcznie to wskaźniki przyjęte na etapie projektowania i potwierdzone w pierwszych tygodniach eksploatacji, nie średnia z długiego okresu.
Czego nie widać w liczbach
Przy kontroli widać w systemie, kto i kiedy zaakceptował dany dokument. Dostęp do dokumentów ogranicza reguła zapisana przy danych, więc zakres widoczności każdej roli da się pokazać w razie pytania o zgodność z RODO. Nikt też nie szuka dokumentów po katalogach, bo to system powiadamia, co czeka na akcję, a zarząd widzi zaległości i obciążenia w czasie rzeczywistym.
Architektura jest przygotowana na wzrost wolumenu bez zmian w infrastrukturze, a kod należy do klienta: pełne prawa majątkowe, repozytorium na jego GitHubie. To drugie brzmi jak formalność, ale przesądza, kto może rozwijać system za rok.
Harmonogram wdrożenia
Projekt zrealizowany w 10 tygodni — od analizy wymagań do startu produkcyjnego.
- Tyg. 1–2: Analiza procesów, mapowanie obiegu dokumentów, projekt architektury i bazy danych
- Tyg. 3–4: Backend Supabase, schematy tabel, RLS, logowanie wyłącznie z zaproszenia
- Tyg. 5–6: Główne ekrany — pulpit, lista dokumentów, karta dokumentu z podglądem PDF
- Tyg. 7–8: Integracje — Gmail OAuth2, KSeF API, Google Drive, OCR
- Tyg. 9: Powiadomienia Resend, panel admina, analityka, eksport CSV
- Tyg. 10: Testy całej ścieżki, szkolenie użytkowników (2×2 h), uruchomienie produkcyjne
Pytania o to wdrożenie i o metodę pracy
Ile trwa wdrożenie takiego obiegu dokumentów?
Ten powstał w 10 tygodni, od analizy wymagań do startu produkcyjnego. Kolejność ma znaczenie: najpierw baza i uprawnienia, potem interfejs, a integracje dopiero w tygodniach 7–8.
Co musi być po stronie firmy przed startem prac?
Przed startem proszę zwykle o cztery rzeczy: skrzynkę na faktury, dostęp do KSeF, miejsce na archiwum i odpowiedź, kto akceptuje jaki dokument. Ostatnia jest najtrudniejsza, bo bez niej tabela kompetencji zostaje pusta.
Czym to się różni od gotowego programu do faktur?
Tu nie ma gotowego modelu obiegu, do którego trzeba się dopasować. Model akceptacji opisuje tabela kompetencji klienta, a nie ścieżka wpisana na stałe w gotowy program; widoczność dokumentu ogranicza reguła po stronie bazy.
Skąd wzięły się liczby 500 faktur i 125 godzin miesięcznie?
Obie liczby przyjęliśmy na etapie projektowania i potwierdziliśmy w pierwszych tygodniach pracy systemu. Godziny liczymy osobno: ile razy proces się powtarza i ile minut trwa jedno przejście — liczba przejść razy minuty na jedno przejście, podzielone przez 60, daje godziny, które obieg ma przejąć. Po uruchomieniu tę samą wielkość czytamy z historii przebiegów: ile dokumentów przeszło, ile utknęło, ile razy ktoś wszedł ręcznie.
Czy zespół poradzi sobie bez działu IT?
Szkolenie 2×2 h wypada w ostatnim tygodniu, przed uruchomieniem produkcyjnym, i zostaje dokumentacja. Konto zakłada się wyłącznie z zaproszenia, a zaległości i średni czas akceptacji widać w panelu admina — taki widok rozkłada osobny artykuł.
Ostatnia aktualizacja: 8 września 2026
Chcesz ten sam obieg u siebie?
Zbuduję dla Ciebie system EOD dopasowany do procesów Twojej firmy — od kanałów wpływu i OCR, przez akceptację, po cyfrowe archiwum.
Szczegóły projektu
Technologie
Lovable · React · TypeScript · Supabase · Supabase RLS · Resend · KSeF API · Gmail OAuth2 · Google Drive API · OCR
