Bezdotykowy potok przetwarzania zamówień i faktur PDF/Excel do systemu ERP

1. Punkt wyjścia i diagnoza problemu biznesowego (Baseline)

Przedsiębiorstwo będące podmiotem wdrożenia to ogólnopolski dystrybutor komponentów technicznych i materiałów instalacyjnych, generujący ponad 45 milionów złotych obrotu rocznego przy wolumenie 1 500 zamówień hurtowych miesięcznie. Dział Obsługi Klienta (DOK) składał się z 4 pełnoetatowych pracowników, których podstawowym obowiązkiem operacyjnym było mechaniczne wprowadzanie danych z maili kontrahentów do systemu ERP (Comarch ERP XL oraz Subiekt GT).

Partnerzy handlowi i hurtownie przesyłali zamówienia w skrajnie zróżnicowanych formatach: od czystych plików PDF generowanych komputerowo, przez wieloarkuszowe pliki Excel (XLS/XLSX), aż po skany zamówień papierowych z pieczątkami i odręcznymi adnotacjami. Rejestracja pojedynczego dokumentu wymagała:

• Ręcznego odczytania pozycji i odnalezienia odpowiedników kodów towarowych klienta w wewnętrznej kartotece indeksów EAN,
• Weryfikacji aktualnych cenników hurtowych, poziomów rabatowych i matryc lojalnościowych przypisanych do danego NIP-u,
• Sprawdzenia bieżącego salda płatności oraz limitu kredytu kupieckiego w module finansowo-księgowym,
• Przeklikania każdej pozycji w interfejsie ERP w celu wystawienia dokumentu Zamówienia od Klienta (ZK/ZS).

Średni czas rejestracji wynosił 14 minut na zamówienie. Cały zespół DOK spędzał łącznie 350 roboczogodzin miesięcznie na mechanicznym przepisywaniu liczb. Zmęczenie powtarzalną pracą generowało błędy w 4,8% wszystkich zamówień (zamiana cyfry w kodzie EAN, pomylenie opakowania zbiorczego z jednostkowym, wpisanie błędnego rabatu). Błędy te skutkowały kosztownymi korektami faktur, blokadą wydań magazynowych, opóźnionym spływem należności i irytacją kluczowych odbiorców. Czas od nadejścia maila do skierowania dyspozycji na magazyn wynosił średnio 28 godzin, a bezpośredni koszt procesu przekraczał 38 500 PLN miesięcznie.

2. Architektura Systemu i Warstwy Inżynieryjne

Zaprojektowałem i wdrożyłem suwerenny, modularny potok inżynieryjny w architekturze kontenerowej Docker, odizolowany od bezpośredniego zapisu w bazie produkcyjnej ERP za pomocą deterministycznego bufora pośredniego SQL:

graph TD
  subgraph Ingestion["1. Warstwa Odbioru & Kolejkowania"]
    A[Skrzynki Pocztowe B2B / Hurtownie] -->|IMAP Webhook / n8n Core| B[Ekstrakcja Załączników PDF / XLS]
    B --> C[Azure Document Intelligence / OCR Pre-processing]
  end

  subgraph Extraction["2. Deterministyczna Ekstrakcja & Walidacja"]
    C --> D[Silnik Ekstrakcji LLM Python 3.12]
    D -->|Strukturyzacja JSON| E[Walidator Modeli Pydantic v2]
    E -->|Błąd strukturalny| F[Langfuse Telemetria & Auto-Retry]
  end

  subgraph Staging["3. Bufor Pośredni SQL & Logika Biznesowa"]
    E -->|Poprawny JSON| G[(PostgreSQL Staging Buffer)]
    G --> H[Silnik Reguł Biznesowych]
    H --> I[Mapowanie EAN / Kody Obce Klienta]
    H --> J[Weryfikacja Matrycy Rabatowej]
    H --> K[Weryfikacja Limitu Kupieckiego]
  end

  subgraph Decision["4. Brama Decyzyjna (HITL Routing)"]
    H --> L{Warunek Zgodności?}
    L -->|Odchylenie >2% LUB Przekroczenie Limitu| M[Kolejka Wyjątków: Slack Alert + DOK Dashboard]
    L -->|100% Zgodności - 88% Wolumenu| N[Comarch ERP XL API / Subiekt GT API]
  end

  subgraph Execution["5. Transakcyjna Egzekucja ERP & Magazyn"]
    N --> O[(Baza Produkcyjna ERP: Dokument ZS)]
    O --> P[Kolejka WMS: Kompletacja w Magazynie]
    M -->|Akceptacja 1-kliknięciem przez DOK| N
  end
        

Opis poszczególnych warstw technologicznych:

• Warstwa 1: Ingestion & Kolejkowanie (IMAP Webhook & Pre-processing): Skrzynki pocztowe B2B są monitorowane przez instancję orkiestratora n8n (self-hosted). Zdarzenie nadejścia nowej wiadomości wyodrębnia załączniki PDF i Excel, generuje unikalny hash kryptograficzny SHA-256 (blokada duplikatów) i kieruje plik do silnika Azure Document Intelligence w celu precyzyjnej ekstrakcji układu tabelarycznego i współrzędnych komórek.
• Warstwa 2: Deterministyczna Ekstrakcja z walidacją Pydantic v2: Skrypt w Pythonie 3.12 przetwarza wyekstrahowany układ za pomocą modelu LLM w trybie Structured Outputs. Dane nagłówka (NIP nabywcy, numer zamówienia, data dostawy, adres magazynu docelowego) oraz pozycje (kod artykułu klienta, opis, zamawiana ilość, jednostka, cena netto) są rygorystycznie mapowane na zdefiniowany schemat Pydantic. Jakiekolwiek odchylenie typów lub brak wymaganych pól powoduje automatyczne logowanie do Langfuse i przejście do procedury ponowienia (auto-retry).
• Warstwa 3: Bufor Pośredni SQL (PostgreSQL Staging Buffer): Zamiast bezpośredniego zapisu do tabel Comarch ERP XL, dane trafiają do izolowanego bufora PostgreSQL. Dedykowany silnik reguł biznesowych realizuje:
  • Asynchroniczne dopasowanie obcych indeksów klienta do wewnętrznych indeksów EAN w oparciu o historyczną tabelę powiązań i fuzzy matching o wysokim progu pewności (98%),
  • Rekalkulację cen jednostkowych w odniesieniu do indywidualnej matrycy rabatowej kontrahenta w ERP,
  • Sprawdzenie bieżącego zadłużenia przeterminowanego oraz dostępnego limitu kredytu kupieckiego.
• Warstwa 4: Brama Kwalifikacji i Human-in-the-Loop: Jeśli zamówienie jest w 100% spójne z cennikiem i nie przekracza limitu kredytowego, system klasyfikuje je do natychmiastowej wysyłki bezdotykowej (Zero-Touch). Jeśli wykryta zostanie rozbieżność cenowa powyżej 2%, nieznany indeks lub przekroczenie salda, rekord trafia do kolejki wyjątków, a dedykowany opiekun klienta otrzymuje alert na Slacku z linkiem do panelu zatwierdzenia 1-kliknięciem.
• Warstwa 5: Transakcyjna Egzekucja ERP (Comarch ERP XL / Subiekt GT API): Sprawdzone rekordy są rejestrowane w bazie produkcyjnej ERP za pośrednictwem oficjalnego interfejsu API / procedur transakcyjnych. Generowany jest formalny dokument Zamówienia Sprzedaży (ZS), następuje twarda rezerwacja stanów magazynowych, a dyspozycja kompletacji natychmiast pojawia się na terminalach WMS w magazynie.

3. Tabela Porównawcza KPI (Przed vs Po Wdrożeniu)

4. Granice Autonomii: Model Human-in-the-Loop

Kluczowym założeniem projektu było wyeliminowanie ryzyka halucynacji AI oraz ochrona integralności danych w systemie ERP. Architektura ściśle rozdziela zadania autonomiczne od decyzji wymagających autoryzacji człowieka:

Zadania realizowane w 100% autonomicznie przez AI:

• Parsowanie wielostronicowych tabel w plikach PDF i arkuszach kalkulacyjnych z zachowaniem hierarchii wierszy i kolumn,
• Identyfikacja danych podmiotu zamawiającego na podstawie numeru NIP i automatyczne pobranie kartoteki z Comarch ERP XL,
• Mapowanie kodów zamawiającego na wewnętrzne indeksy EAN za pomocą macierzy asocjacyjnej,
• Walidacja arytmetyczna: przeliczanie kwot netto, stawek VAT, wartości brutto oraz rabatów ilościowych,
• Automatyczny zapis dokumentu ZS w ERP dla 88% zamówień bez anomalii.

Zdarzenia kierowane do autoryzacji człowieka (12% wolumenu):

• Wykrycie rozbieżności pomiędzy ceną wskazaną w zamówieniu klienta a ceną z matrycy ERP przekraczającej 2%,
• Przekroczenie przyznanego limitu kredytu kupieckiego lub obecność nieuregulowanych faktur po terminie płatności,
• Pojawienie się nowego indeksu towarowego, którego kod nie występuje w bazie powiązań i wymaga zmapowania przez pracownika DOK,
• Nietypowe adnotacje tekstowe lub próby narzucenia niestandardowych warunków dostawy.

5. Trudny przypadek brzegowy (Edge Case Deep Dive)

6. Stack Technologiczny i Suwerenność Danych

Całość systemu została wdrożona na dedykowanej infrastrukturze serwerowej klienta. Żadne poufne dane handlowe, cenniki hurtowe ani bazy kontrahentów nie są współdzielone z publicznymi platformami chmurowymi. Rozwiązanie stanowi w 100% własność zamawiającego, gwarantując zerowy koszt licencji abonamentowych za pojedyncze dokumenty i brak uzależnienia od zewnętrznych dostawców (Zero Vendor Lock-in).

7. Głos Klienta