Rozpoznawanie dokumentów zamówień
AI LAB

Rozpoznawanie dokumentów zamówień

PDF zamówienia wchodzi, ustrukturyzowane dane wychodzą webhookiem do n8n.

PROJECT
AI-055
OCR
docTR (PyTorch)
RASTERYZACJA
POPPLER / pdf2image
INTERFEJS
CUSTOMTKINTER
WYJŚCIE
WEBHOOK n8n
STATUS
PROTOTYP
DATA
08 sierpnia 2026

Aplikacja desktopowa rasteryzująca dokumenty zamówień, przepuszczająca je przez OCR, dopasowująca klienta do lokalnej bazy i wypychająca wynik do przepływu automatyzacji n8n. Rozpoznawanie działa lokalnie, na GPU jeśli jest dostępne.

ORDER.OCRDOKUMENTY ZAMÓWIEŃ → n8n
AUTOMATYZACJA
WEJŚCIENARZĘDZIEDECYZJAMAGAZYNPRZETWARZANIEWYJŚCIE01PDF ZAMÓWIENIA02RASTERYZACJApoppler03OCRdocTR04DOPASOWANIEKLIENTA05BAZA KLIENTÓW06EKSTRAKCJAPOZYCJI07WEBHOOK n8n08ZAMÓWIENIE
docTR + poppler LOKALNIE · WYNIK WYPYCHANY WEBHOOKIEM DO n8n, KTÓRY PROWADZI DALSZY WORKFLOW
01

PROBLEM

Zamówienia przychodzą jako PDF-y o różnym układzie, część z nich to skany. Przepisywanie pozycji do systemu jest pracą powtarzalną i podatną na literówki, a przy kilkudziesięciu dokumentach dziennie pochłania cały etat.

02

POMYSŁ

Rozdzielić rozpoznawanie od automatyzacji. Program robi jedną rzecz: zamienia dokument na dane. Co się z nimi dalej dzieje — trafiają do systemu, generują powiadomienie, uruchamiają kolejny krok — decyduje n8n, gdzie przepływ da się zmienić bez dotykania kodu.

03

PROJEKT

PDF jest najpierw rasteryzowany przez poppler, bo docTR pracuje na obrazach. Rozpoznawanie działa na modelach PyTorch z akceleracją GPU, gdy jest dostępna — w repozytorium leży osobny skrypt testujący dostępność karty.

Dopasowanie klienta odbywa się względem lokalnej bazy SQLite. To krok, który najbardziej podnosi jakość wyniku: nazwa firmy odczytana przez OCR bywa zniekształcona, ale dopasowana do listy istniejących klientów staje się jednoznaczna.

Wynik trafia do katalogu wyjściowego i równolegle do webhooka n8n. Adres jest konfigurowalny, a domyślnie wskazuje na instancję lokalną.

Jakość rozpoznawania zależy w praktyce bardziej od przygotowania obrazu niż od samego modelu. Rozdzielczość rasteryzacji, prostowanie skanu i kontrast wpływają na wynik silniej niż wybór między dwoma modelami OCR — dlatego etap rasteryzacji ma własne parametry, a nie wartości domyślne z biblioteki.

04

REALIZACJA

Interfejs zbudowano na CustomTkinter — wybór typowy dla narzędzia wewnętrznego, gdzie liczy się czas powstania, a nie wygląd. Operator wybiera plik, widzi podgląd i rozpoznany wynik, może go poprawić przed wysłaniem.

Obok głównej aplikacji w tym samym katalogu leży druga: monitor pytań o produkty w IdoSell, opisany osobno. Obie łączy ta sama filozofia — mały program pilnujący jednego procesu i wypychający wynik dalej.

W tym samym katalogu leżą też eksperymenty z modelem CLIP oraz test dostępności GPU. To ślad po etapie rozpoznawczym: sprawdzaniu, czy dopasowanie obrazu do opisu tekstowego nadaje się do klasyfikowania zdjęć produktowych. Wnioski z tych prób trafiły później do osobnych projektów wizyjnych.

Katalog zawiera także dane robocze n8n oraz materiały z integracji z IdoSell, co pokazuje faktyczny charakter tego miejsca: jest to warsztat automatyzacji, w którym powstają narzędzia sklejające istniejące systemy, a nie pojedyncza aplikacja.

05

EFEKT

Rozpoznawanie działa lokalnie i nie wymaga wysyłania dokumentów handlowych do usług zewnętrznych. Integracja z n8n zdejmuje z programu odpowiedzialność za logikę biznesową, która i tak zmienia się częściej niż sam OCR.

07

WNIOSKI

Podział „program rozpoznaje, n8n decyduje” sprawdził się lepiej, niż zakładałem. Zmiana ścieżki obiegu dokumentu nie wymaga ani jednej linijki kodu, a to właśnie ta część procesu zmienia się najczęściej.

Drugi wniosek dotyczy zakresu odpowiedzialności programu: nie próbuje on rozumieć zamówienia, tylko je odczytać. Interpretacja — czy pozycja jest dostępna, jaka jest cena, co zrobić z brakiem — należy do systemu sprzedażowego, który i tak ma na to reguły.