Cały silnik automatyzacji stoi na firmowym serwerze klienta, a baza ERP nigdy nie zostaje wystawiona do internetu. System sam pobiera faktury ze skrzynki, porównuje każdą pozycję z zamówieniem w Comarch ERP Optima i zgłasza różnice w cenie, numerze zamówienia i kaucji.
Moto-Remo sprzedaje, regeneruje i serwisuje turbosprężarki. Kupuje bezpośrednio od producentów, a sprzedaż i magazyn prowadzi w Comarch ERP Optima. Firma składa zamówienie po ustalonej cenie, a fakturę dostaje kilka tygodni później. Między jednym a drugim cena może się zmienić, może dojsć kaucja za rdzeń, a numer zamówienia może zostać przepisany inaczej.
Kontrola wyglądała wtedy tak: ktoś otwierał PDF, odczytywał numer zamówienia i indeks, wchodził do Optimy, znajdował zamówienie, porównywał cenę, i to samo dla każdej kolejnej pozycji.
Faktury przychodzą przez cały miesiąc, część w paczkach po kilka naraz, a każda potrafi mieć kilkanaście pozycji.
Porównywanie kolumn liczb to dokładnie ta praca, przy której człowiek po dwudziestej minucie przestaje patrzeć uważnie.
Niezauważona podwyżka ceny jednostkowej albo doliczona kaucja nie wywołują żadnego alarmu. Po prostu zostają zapłacone.
Kontrola co do zasady odbywała się wyrywkowo, bo na pełną nie było czasu.
Do tego przeszkody czysto techniczne. Dane zamówień siedzą w bazie SQL Server na serwerze w firmie, niedostępnej z zewnątrz. Trzej dostawcy mają trzy różne układy dokumentu i trzy konwencje zapisu numeru zamówienia.
To była pierwsza decyzja projektowa, nie ozdobnik doklejony na końcu. Bazy Optimy nie wolno było otworzyć na świat, a firma nie chciała, żeby kontrola jej faktur zależała od cudzej subskrypcji.
Skrypt czytający Optimę działa lokalnie na firmowym serwerze i łączy się z bazą przez ODBC. Nic nie sięga do tej bazy przez internet, więc nie ma czego atakować z zewnątrz.
System loguje się do bazy użytkownikiem bez uprawnień do zapisu. Nie ma technicznej możliwości zmiany czegokolwiek w ERP, nawet w razie błędu w kodzie.
n8n działa na serwerze Windows klienta, pod własną domeną, obok skryptów i folderu z fakturami. Nie ma zewnętrznej usługi pośredniczacej, na której subskrypcji opierałby się cały proces.
Panel administracyjny nie jest wystawiony do internetu bez ochrony. Wejście wymaga uwierzytelnienia, a integracje maszynowe korzystają z osobnych tokenów serwisowych.
Automatyzacja reaguje wyłącznie na wiadomości z domen trzech dostawców i o określonych tematach. Reszta korespondencji firmowej jest dla systemu niewidoczna.
Usługi zewnętrzne działają na kontach firmy, nie wykonawcy, a poświadczenia są trzymane poza treścią procesów. Zakończenie współpracy nie odcina dostępu do niczego.
Uczciwie o granicy tego rozwiązania. Z serwera wychodzą dwie rzeczy. Do arkusza pośredniego trafiają wyłącznie te pola zamówień, które są potrzebne do porównania, wybrane celowanym zapytaniem, a nie zrzutem bazy. Treść faktury jest wysyłana do modelu językowego, który zamienia PDF na listę pozycji. Poza tym proces nie opuszcza firmowej infrastruktury.
Baza ERP jest wewnątrz sieci firmowej i nie wolno jej wystawiać do internetu, więc dane tylko z niej wychodzą. Poczta jest usługą zewnętrzną, a logika porównania zmienia się najczęściej ze wszystkich trzech warstw, bo to ona uczy się kolejnych wyjątków.
Pozycja odnaleziona w ERP, cena się zgadza. Wiersz trafia do rejestru i nikt nie jest powiadamiany.
Numeru zamówienia lub indeksu produktu nie ma w ERP. Sygnał, że coś zamówiono poza systemem albo numer zapisano inaczej.
Zamówienie odnalezione, ale cena na fakturze różni się od ceny w ERP. Podane są obie wartości.
Cena zgadza się z zamówieniem, ale jest inna niż przy poprzednim zakupie. To nie błąd, tylko sygnał do działu zakupów.
Faktura zawiera kaucję za rdzeń, której nie oczekiwano, albo nie zawiera tej, której się spodziewano.
Rozróżnienie między niezgodnością a zmianą historyczną jest tu sednem. Pierwsze to błąd do reklamacji u dostawcy. Drugie to informacja handlowa: producent podniósł cenę, więc trzeba przeliczyć własną marżę. Wrzucenie obu do jednego worka alert sprawiłoby, że po tygodniu nikt by tych maili nie czytał.
Opis porównaj cenę z faktury z ceną z zamówienia brzmi na jedno popołudnie pracy. Nie jest, i warto wiedzieć dlaczego, bo dokładnie te same pułapki czekają w każdym podobnym procesie.
U jednego numer jest w nagłówku, a przy fakturze wielopozycyjnej powtarza się przy każdym wierszu. U drugiego siedzi w ramce, poprzedzony literą i ukośnikiem, które trzeba odciąć. U trzeciego obowiązuje aż do następnego wystąpienia, a wiersze bez niego trzeba pominąć.
Na fakturze bywa cena za sztukę i wartość pozycji, a w ERP raz tak, raz tak. Bez uwzględnienia tego każda pozycja z liczbą sztuk większą niż jeden zgłasza fałszywy alarm. Do tego waluty obce przeliczane po kursie z dnia dokumentu.
Ten sam produkt potrafi występować w dwóch wariantach zapisu, różniących się jedną cyfrą. System normalizuje kody i dopuszcza dopasowanie częściowe, bo inaczej odrzucałby prawidłowe pozycje.
Informacja o kaucji nie jest osobnym polem. To akapit drobnym drukiem pod pozycją. Model rozpoznaje tę klauzulę i zamienia ją na flagę, zestawianą z tabelą oczekiwanych kaucji.
Kwoty są porównywane z dokładnością do grosza, a nie na równość. Banał, o którym łatwo zapomnieć i produkować alarmy przy różnicy rzędu setnych części grosza.
Żadnej z nich nie da się wymyślić z góry. Wszystkie powstały z rozmów z działem zakupów i z przeglądania prawdziwych faktur, jedna po drugiej.
Najlepsi kandydaci do automatyzacji rzadko wyglądają efektownie. To zwykle zadania powtarzalne, nudne i takie, w których błąd nie robi hałasu, tylko po cichu kosztuje. Jeśli ktoś u Ciebie regularnie zestawia dokument z systemem, prawdopodobnie da się to zrobić tak, żeby człowiek oglądał wyłącznie przypadki, które faktycznie tego wymagają.
Umów bezpłatną konsultację
Copyright © 2025 FlowSync
