Zamówienia z maila i PDF do ERP: sześć decyzji, od których zależy, czy automatyzacja zadziała

Zamówienia, które przychodzą mailem, w PDF-ach i arkuszach, to w hurtowniach i firmach produkcyjnych częsty pierwszy kandydat do automatyzacji AI. Słusznie: powtarzają się codziennie, a ich ręczne przepisywanie do ERP, czyli systemu, w którym firma prowadzi zamówienia, zapasy i księgowość, zajmuje czas osób, które powinny rozmawiać z klientami. Odczytanie PDF-u to jednak najłatwiejsza część. Projektem jest dopasowanie tego, co napisał klient, do Twojej kartoteki towarów, czyli listy towarów w ERP: jego kodów, jednostek i opakowań do Twoich indeksów, czyli wewnętrznych kodów towarów. Do tego sprawdzenie dostępności i specyfikacji oraz decyzja, co się dzieje z zamówieniami, których system nie jest pewien. Jak w ploch.ai dobieramy procesy do automatyzacji i gdzie zostawiamy człowieka, opisaliśmy na stronie o automatyzacji AI w firmie.

Poniżej sześć decyzji, które trzeba podjąć przed zakupem, jedno przykładowe zamówienie pokazane w trzech formatach, to, co dochodzi w zakładzie produkcyjnym, i sytuacje, w których nie warto zaczynać. Zamówienia transportowe, z giełdami ładunków i oknami załadunku, to osobny temat — jest o nich strona AI dla firm transportowych.

Odczyt to najłatwiejsza część

Współczesny model językowy, czyli silnik, na którym działają narzędzia takie jak ChatGPT czy Claude, potrafi wyciągnąć z maila i PDF-u nazwę klienta, pozycje, ilości i termin. Jak dobrze robi to na Twoich dokumentach, pokaże pilotaż. Sam odczyt jednak nie wystarcza. Klient pisze „rękawice nitrylowe M, 10 op.”, a w Twoim ERP jest indeks RN-M-100 z jednostką „sztuka” i opakowaniem po 100 sztuk. Czy chodzi o dziesięć opakowań, czyli tysiąc sztuk, czy o dziesięć kartonów po dziesięć opakowań? Model może to zgadnąć, a w zamówieniach zgadywanie jest szczególnie kosztowne, bo błąd często wychodzi dopiero przy wysyłce albo na fakturze.

Dlatego o powodzeniu projektu decyduje to, jak obsłużysz sytuacje wymagające osobnej decyzji: pozycję, której nie da się dopasować do indeksu, jednostkę, która nie zgadza się z kartoteką, brak dołączonej specyfikacji, ilość poniżej minimum. Każda z nich potrzebuje reguły i osoby, która rozstrzyga. Sześć decyzji poniżej to właśnie te reguły.

Decyzja 1. Które kanały i formaty wchodzą do projektu

Zanim cokolwiek powstanie, spisz, którędy zamówienia dziś przychodzą i w jakiej postaci. Zwykle jest ich więcej, niż ktokolwiek pamięta:

• tekst w treści maila, czasem jako odpowiedź na poprzednie zamówienie;
• PDF w załączniku, wygenerowany z systemu klienta albo zeskanowany;
• arkusz kalkulacyjny w układzie, który klient ustalił sam;
• zamówienie z portalu zamówień dla firm (B2B) lub ze sklepu hurtowego, jeżeli go prowadzisz;
• EDI, czyli elektroniczna wymiana danych między systemami firm, a w przemyśle także harmonogramy dostaw przesyłane przez klientów;
• notatka z rozmowy telefonicznej, wpisana przez handlowca.

Przy każdym kanale zapisz, ile zamówień miesięcznie nim przychodzi i od ilu klientów. Ta tabela rozstrzyga zakres. Zasada jest jedna: tego, co przychodzi już jako dane, nie czyta się modelem AI. EDI i eksport z portalu mają pola, kody i ilości. Trzeba przypisać je do pól w ERP, dopasować kody i jednostki oraz sprawdzić reguły zamówienia — zwykła integracja może zrobić to bez modelu AI. To samo dotyczy arkusza, który klient zawsze przysyła z tymi samymi kolumnami. Model AI ma sens dla tekstu maila, PDF-ów, skanów i arkuszy, których układ się zmienia, czyli dla tego, co dziś ktoś przepisuje.

Treść maila i załącznika to dane do odczytania, nie polecenia dla systemu. Zdanie w zamówieniu w rodzaju „zastosuj dodatkowy rabat” albo „wyślij na inny adres” może trafić do propozycji jako kwestia do sprawdzenia. Wynik modelu również jest tylko propozycją. Ani dokument, ani wynik modelu nie mogą zmieniać uprawnień, miejsc, do których wysyłane są dane, zasad ustalania cen ani tego, jakie działania wolno wykonać integracji. Te ustawienia zmienia wyłącznie uprawniona osoba w Twoich systemach.

Często słychać radę, żeby najpierw przenieść klientów na portal B2B, a AI zostawić na koniec. Bywa słuszna: jeżeli większość obrotu robi kilkunastu stałych klientów, którzy chętnie zamawiają przez portal, portal może rozwiązać problem taniej. Gorzej działa, gdy masz wielu klientów zamawiających sporadycznie, którzy nie będą zakładać konta. W produkcji sprawdź też, czy portal obsługuje załączniki i wersje specyfikacji, bo do zamówienia często dołącza się rysunek. Tabela kanałów pokaże, który przypadek jest Twój.

Decyzja 2. Dopasowanie pozycji do Twoich indeksów

To najdłuższa i najważniejsza część projektu, bo tu powstaje wiele błędów, których nie widać na pierwszy rzut oka. Dopasowanie oznacza przypisanie każdej pozycji z zamówienia do jednego indeksu w Twojej kartotece towarów, z właściwą jednostką i ilością. Klienci opisują towar na trzy sposoby, często w jednym zamówieniu.

Kod klienta, kod kreskowy i opis słowny

Kod klienta. Duzi odbiorcy używają własnej numeracji towarów i piszą swój kod, nie Twój. Potrzebna jest tabela powiązań: kod klienta A odpowiada Twojemu indeksowi X. Jeżeli taka tabela istnieje w ERP albo w arkuszu handlowca, to najcenniejszy materiał do projektu.

Kod kreskowy (EAN). Numer z opakowania jest jednoznaczny, ale tylko wtedy, gdy w Twojej kartotece jest przypisany do właściwego indeksu i właściwego opakowania. Ten sam towar może mieć inny kod na sztuce, a inny na kartonie.

Opis słowny. „Rękawice nitrylowe M” albo „śruba M8x40 ocynk” wymagają porównania z nazwami w kartotece. Model AI może pomóc w porównaniu opisów, ale gdy kilka indeksów różni się jednym parametrem, rośnie ryzyko pomyłki. Dlatego przy opisie słownym system powinien pokazać proponowany indeks, cechy, które się zgadzają, i różnice, których nie rozstrzygnął, a przy kilku podobnych kandydatach — zapytać człowieka.

Jednostki i opakowania: karton to nie sztuka

Pomyłka w jednostce bywa trudniejsza do wychwycenia niż pomyłka w indeksie: zły indeks często widać od razu, a zawyżoną albo zaniżoną ilość — na przykład tysiąc sztuk zamiast stu — czasem dopiero przy kompletowaniu. Dla każdego towaru, który klienci zamawiają w różnych jednostkach, kartoteka musi znać przeliczniki: sztuka, opakowanie, karton, paleta. Jeżeli przeliczniki są tylko w głowie magazyniera, pierwszym zadaniem projektu jest ich spisanie, nie budowa automatyzacji.

To nie jest problem wyłącznie po stronie modelu. W dokumentacji Comarch ERP Optima (stan na 12 października 2026 r.) import dokumentów z pliku XML ma domyślnie zaznaczone zakładanie kart towarów, których nie ma w bazie, a gdy przelicznik jednostek w pliku różni się od tego na karcie towaru, na importowany dokument trafia przelicznik z pliku. Wniosek jest ogólny i dotyczy każdego systemu: pozycja niedopasowana na etapie odczytu nie powinna dojść do importu jako nowy towar ani ze swoim przelicznikiem — ma zatrzymać się u człowieka.

Tabela powiązań zasilana poprawkami

Część poprawek zatwierdzającego ujawnia stałą regułę: kod „RK-100” od tego klienta to Twój indeks RN-M-100, a „op.” u niego znaczy opakowanie po sto sztuk. Jeżeli uprawniona osoba zapisze takie powiązanie w tabeli, następne zamówienie tego klienta nie wymaga już tej samej decyzji. Jeżeli przepada, ten sam błąd wraca co tydzień. Poprawki dotyczące tylko jednego zamówienia — inny termin, inny adres, dopisana pozycja — zostają przy tym zamówieniu i nie stają się regułą. W projekcie trzeba więc ustalić, kto może dopisywać powiązania i jak wycofać błędne, bo jedna zła pozycja w tabeli powtórzy się w każdym kolejnym zamówieniu.

Decyzja 3. Dostępność, zamienniki i minimum zamówienia

Dopasowana pozycja to jeszcze nie pozycja do realizacji. Zanim zamówienie trafi do ERP jako gotowe, trzeba ustalić, co system sprawdza sam, a co zostawia człowiekowi:

• Dostępność. Czy towar jest na stanie w potrzebnej ilości i terminie? Jeżeli nie, czy potwierdzasz częściowo, czy czekasz na dostawę?
• Zamienniki. Czy wolno zaproponować zamiennik i kto go zatwierdza? Niektóre programy handlowe mają osobną obsługę zamienników — na przykład opis Subiekta nexo PRO wymienia obsługę zamienników i indywidualny termin realizacji każdej pozycji zamówienia (stan na 12 października 2026 r.). Decyzja o zaproponowaniu klientowi zamiennika należy jednak do handlowca, nie do automatu.
• Minimum zamówienia i warunki klienta. Minimalna ilość lub wartość, indywidualny cennik, limit kredytowy. Zamówienie, które łamie którąś z reguł, nie powinno wejść do ERP po cichu.

W firmie produkcyjnej dochodzą trzy rzeczy

W zakładzie produkcyjnym zamówienie często nie dotyczy towaru z półki, tylko wyrobu, który trzeba wykonać. Wtedy szczególnie ważne są sprawdzenia, które w hurtowni zdarzają się rzadziej:

• Specyfikacja albo rysunek. Czy zamówienie ma dołączoną specyfikację i czy jej wersja zgadza się z tą, na którą była oferta? Brak załącznika lub inna wersja rysunku to powód, żeby zamówienie zatrzymać u technologa, a nie wpisać je do ERP.
• Minimalna wielkość partii i czas wykonania. Ilość poniżej minimalnej partii produkcyjnej albo termin dostawy, który zostawia mniej czasu, niż wymaga produkcja, oznacza rozmowę z klientem, nie potwierdzenie.
• Harmonogram czy pojedyncze zamówienie. Klienci przemysłowi często przysyłają harmonogram dostaw, który zmienia się co tydzień. Jeżeli przychodzi przez EDI, nie jest zadaniem dla modelu AI (decyzja 1). Jeżeli przychodzi jako arkusz w mailu, system musi porównać go z poprzednią wersją i pokazać zmiany, zamiast tworzyć nowe zamówienie z każdego pliku.

„Niepewne” w zakładzie znaczy więc co innego niż w hurtowni: nie tylko „nie wiem, który to indeks”, ale też „nie wiem, czy da się to wykonać w tym terminie”. Tę drugą decyzję zawsze podejmuje człowiek. O tym, które procesy wokół produkcji nadają się na pierwszy projekt, piszemy na stronie AI dla firm produkcyjnych.

Decyzja 4. Pętla potwierdzenia: kto potwierdza i co widzi klient

Ogólne zasady umieszczania człowieka w procesie opisaliśmy w poradniku, jak wdrożyć AI w firmie, w kroku 4, a projekt samego ekranu zatwierdzania w tekście o nadzorze człowieka. Przy zamówieniach trzeba dodatkowo rozstrzygnąć cztery rzeczy:

1. Kto zatwierdza. Handlowiec opiekujący się klientem, dział obsługi zamówień czy — w produkcji — technolog dla pozycji ze specyfikacją? Zamówienie bez przypisanej osoby czeka w kolejce bez końca.
2. Co dostaje klient. Potwierdzenie całego zamówienia, potwierdzenie częściowe z listą pozycji oczekujących na dostawę, propozycję zamiennika do akceptacji? Wzory tych wiadomości warto ustalić przed pilotażem, a nie w jego trakcie.
3. Kto zatwierdza zamiennik i zmianę terminu. Takie decyzje tworzą zobowiązania wobec klienta, dlatego wymagają zatwierdzenia przez człowieka.
4. Co dzieje się z poprawką. Jeżeli poprawka ujawnia stałe powiązanie kodu lub jednostki, uprawniona osoba zapisuje je w tabeli powiązań (decyzja 2); pozostałe poprawki zostają przy zamówieniu.

Klient dostaje potwierdzenie od Twojej firmy, sprawdzone przez Twojego pracownika. Czy musi wiedzieć, że zamówienie odczytał system, zależy od tego, jak zbudowany jest proces. AI Act to unijne rozporządzenie o sztucznej inteligencji. Jego art. 50, stosowany od 2 sierpnia 2026 r., rozróżnia między innymi system, który rozmawia z człowiekiem bezpośrednio, jak chatbot, oraz techniczne oznaczanie treści generowanych przez AI, które należy do dostawców takich systemów; przy systemach wprowadzonych do obrotu przed 2 sierpnia 2026 r. dostawcy mają czas na spełnienie tego drugiego obowiązku do 2 grudnia 2026 r. (art. 111 ust. 4 w tekście skonsolidowanym AI Act na EUR-Lex, stan na 12 października 2026 r.). Odczyt zamówienia wewnątrz firmy i rozmowa klienta z asystentem AI to różne przypadki, które ocenia się osobno, a o tym, który obowiązek dotyczy Twojego procesu, rozstrzyga Twój prawnik. Terminy i zakres przepisów zebraliśmy w tekście o AI Act w Polsce.

Decyzja 5. Rodzaje błędów i dwie liczby z pilotażu

Na rynku łatwo znaleźć obietnice „zera błędów” albo dokładności podanej z przecinkiem. Takiej liczby nie da się uczciwie podać przed zobaczeniem Twoich zamówień, bo zależy od Twoich klientów, ich formatów i stanu Twojej kartoteki. Zamiast obietnicy potrzebna jest lista rodzajów błędów i dwie liczby, które zmierzysz sam.

Dwie liczby, które warto zapisywać od pierwszego dnia pilotażu:

• Minuty od wpływu zamówienia do zapisania zatwierdzonego zamówienia w ERP — liczone między dwoma momentami zapisanymi przez system, więc obejmują i czekanie w kolejce, i sprawdzanie. Czas pracy osoby sprawdzającej warto zapisywać osobno: jeżeli sprawdzanie trwa tyle, co przepisywanie, szybszy odczyt niczego nie zmienia.
• Udział zamówień wymagających poprawki — zamówienie liczy się, jeżeli zatwierdzający zmienił w nim cokolwiek. Policz go na pierwszych stu zamówieniach i zapisz, jakiego rodzaju były poprawki.

Przez pierwsze tygodnie system powinien działać obok dotychczasowej pracy, a nie zamiast niej — dlaczego, opisaliśmy w kroku 6 poradnika wdrożenia. Tabela rodzajów błędów pokaże wtedy, czy poprawiać tabelę powiązań, kartotekę, czy rozmawiać z klientem, którego zamówienia są najtrudniejsze.

Decyzja 6. Droga do ERP: interfejs albo import pliku

Ostatni krok to zapisanie zatwierdzonego zamówienia w ERP — przez API, czyli interfejs, przez który inne programy łączą się z systemem, albo przez import pliku. Możliwości zależą od systemu i licencji; kilka przykładów z dokumentacji producentów (stan na 12 października 2026 r.):

• Symfonia ERP WebAPI ma moduł „Zamówienia obce” do pobierania i tworzenia zamówień od klientów, a także moduły stanów magazynowych i rezerwacji. Wymagany jest też moduł główny, a całość jest dostępna w subskrypcji rocznej, wycenianej według zakresu.
• W enova365 wymianę danych zapewnia moduł Integrator, licencjonowany jako moduł dodatkowy.
• Comarch ERP Optima importuje z plików XML wybrane dokumenty, wśród nich rezerwację odbiorcy (RO); opis struktury tych plików dostają wyłącznie autoryzowani partnerzy Comarch.
• W Subiekcie nexo PRO jest Sfera, czyli mechanizm tworzenia własnych rozwiązań współpracujących z programem.

Niezależnie od systemu, zanim cokolwiek zostanie zapisane, integracja musi sprawdzić, czy to zamówienie już nie wpłynęło. Klient wysyła ponownie ten sam załącznik, poczta dostarcza wiadomość dwa razy albo to samo zamówienie przychodzi mailem i z portalu — a dwa osobne wpisy w kolejce zatwierdzania łatwo przeoczyć. Dlatego każde zamówienie dostaje identyfikator, który zwykle łączy numer nadany przez klienta z identyfikatorem klienta w ERP. To połączenie pozostaje takie samo przy ponownym wysłaniu i we wszystkich kanałach. System trwale zapisuje, na jakim etapie jest zamówienie i jaki dokument utworzył w ERP, dopuszcza tylko jeden zapis danego zamówienia naraz, a powtórkę kieruje do sprawdzenia zamiast tworzyć drugi dokument. Jeżeli po przerwanym połączeniu nie wiadomo, czy zapis się udał, najpierw sprawdza wynik w ERP. Zamówienie bez numeru albo w innej wersji niż przyjęte wcześniej trafia do człowieka.

Który sposób połączenia wybrać, jakie dane wychodzą przy nim z firmy i o co zapytać partnera ERP, rozpisaliśmy szczegółowo w tekście o integracji AI z ERP i CRM. Jest tam też przykład kosztów modelu AI dla zamówień z maila, więc nie powtarzamy go tutaj.

Jedno zamówienie w trzech formatach

Przykład jest zmyślony i służy wyłącznie ilustracji — nie pochodzi z wdrożenia u klienta.

Hurtownia artykułów BHP dostaje od tego samego klienta to samo zamówienie na trzy sposoby: rękawice nitrylowe w rozmiarze M, 10 opakowań po 100 sztuk; okulary ochronne, 24 sztuki; dostawa na adres magazynu klienta do piątku.

Treść maila. „Dzień dobry, proszę jak zwykle rękawice nitryl M x10 i okulary 24 szt., na magazyn, najpóźniej piątek.” Model odczyta obie pozycje i termin, ale „jak zwykle” i „na magazyn” znaczą coś tylko dla kogoś, kto zna klienta. System musi sięgnąć do jego poprzednich zamówień i adresów dostawy w ERP, a jeżeli magazynów jest kilka — zapytać. Do potwierdzenia: czy „x10” to dziesięć opakowań.

PDF z systemu klienta. W nagłówku są dwa adresy: siedziby i dostawy (magazyn), a także termin dostawy: piątek. Pozycje w tabeli:

Odczyt jest łatwy, ale bez tabeli powiązań kody „RK-100” i „OK-01” nic nie znaczą, „op.” trzeba przeliczyć według kartoteki, a system musi wybrać adres dostawy, nie siedziby. To typowe miejsce na błąd złego adresu.

Arkusz. Nad tabelą wiersze „Dostawa: magazyn” i „Termin: piątek”, a pod nimi:

Klient liczy okulary w kartonach po 12 sztuk. Jeżeli system weźmie samą kolumnę „Ilość”, potwierdzi dwie sztuki zamiast dwudziestu czterech. Do potwierdzenia: przelicznik kartonu w Twojej kartotece.

Trzy formaty, jedno zamówienie i trzy różne miejsca, w których może powstać błąd. Sam poprawny odczyt tekstu nie wystarcza: trzeba jeszcze rozpoznać właściwe pola, dopasować pozycje i uwzględnić kontekst klienta. Gdyby ten sam klient był zakładem produkcyjnym zamawiającym wyrób według rysunku, doszłoby jeszcze sprawdzenie wersji rysunku, minimalnej partii i czasu wykonania z decyzji 3.

Kiedy nie warto zaczynać — albo jeszcze nie

• Większość zamówień przychodzi już jako dane. Jeżeli EDI i portal B2B obsługują prawie cały obrót, wystarczy integracja tych kanałów bez modelu AI. Resztę można dalej przepisywać ręcznie, jeżeli policzysz, że kosztuje to mniej niż automatyzacja.
• Kartoteka towarów nie jest uporządkowana. Zdublowane indeksy, brak przeliczników jednostek, kody kreskowe przypisane do złych opakowań — dopasowanie nie będzie wiarygodne, dopóki dane nie zostaną poprawione, albo pilotaż trzeba zawęzić do uporządkowanej części kartoteki. Porządkowanie danych może być osobnym projektem, który warto zrobić najpierw.
• Zamówień jest za mało. Policz, ile godzin miesięcznie zajmuje dziś przepisywanie i sprawdzanie zamówień, i porównaj to z kosztem budowy i utrzymania. Próg zależy od Twoich liczb, nie od uniwersalnej reguły.
• Nikt nie ma czasu zatwierdzać. Pilotaż wymaga osoby, która przez kilka tygodni sprawdza propozycje i poprawia błędy. Bez niej nie powstanie ani tabela powiązań, ani dwie liczby z decyzji 5.

Co dalej

Zacznij od dwóch rzeczy, które nie wymagają żadnego narzędzia: tabeli kanałów z decyzji 1 i próbki pięćdziesięciu ostatnich zamówień w oryginalnej postaci, czyli maili, PDF-ów i arkuszy. Z tej próbki widać, ile pozycji ma kod klienta, ile tylko opis i w ilu jednostka różni się od Twojej kartoteki. Jak wygląda wdrożenie w czterech etapach — audyt, pilotaż, wdrożenie, przekazanie — opisaliśmy na stronie metodyki wdrożenia. Przykłady innych procesów, od których firmy zaczynają, zebraliśmy w przykładach automatyzacji AI, a jak wygląda przepływ z zatwierdzaniem zbudowany w programie n8n, pokazujemy w przewodniku po n8n. O procesach w firmach handlowych piszemy na stronie AI dla firm handlowych.

Opisz nam, którędy i w jakiej postaci przychodzą Twoje zamówienia. Odpowiemy, od którego kanału zaczęlibyśmy i czego potrzeba w Twojej kartotece — również wtedy, gdy odpowiedź brzmi „jeszcze nie warto”.