Jak AI tłumaczy odrzucone dokumenty EDI i pilnuje zamówień od sieci handlowych w Comarch EDI, Infinite i EDISON?

AI podłączone do platformy EDI odczytuje surowe komunikaty EDIFACT: ORDERS, ORDRSP, DESADV, INVOIC i APERAK, i zamienia je na zrozumiałe informacje dla działu obsługi sieci. Nie trzeba codziennie wchodzić do portalu Comarch EDI, Infinite ani EDISON, żeby wiedzieć co zostało odrzucone, co czeka na potwierdzenie i gdzie sieć zakwestionuje fakturę. Raport trafia do konkretnych ludzi w formie, na której da się od razu działać.

Skąd w ogóle biorą się problemy z EDI i dlaczego ręczne śledzenie przestaje wystarczać

Każda sieć handlowa, z którą pracujesz jako dostawca, wysyła i odbiera dokumenty przez swoją platformę EDI. Jedne sieci korzystają z Comarch EDI, inne z Infinite, jeszcze inne z EDISON. Każda platforma ma własny portal, własne statusy, własne komunikaty błędów. Jeśli obsługujesz kilka sieci naraz, masz kilka portali do sprawdzania każdego ranka.

Typowo wygląda to tak, że ktoś z biura wchodzi do Comarch EDI Portal, sprawdza czy ORDERS z poprzedniego dnia dostały potwierdzenie, potem do Infinite żeby zobaczyć czy INVOIC nie zostało odrzucone, potem do EDISON po to samo. Jeśli coś jest nie tak, musi zrozumieć komunikat błędu: na przykład "APERAK z kodem 27" albo "niezgodność GLN odbiorcy w segmencie NAD". To nie są rzeczy czytelne dla osoby bez technicznego przygotowania w EDI.

Do tego dochodzi czas. Potwierdzenie zamówienia (ORDRSP) do wielu sieci trzeba wysłać w ciągu kilku godzin od otrzymania ORDERS. Jak ktoś to przegapi albo sprawdzi za późno, sieć może traktować zamówienie jako nieodebrane.

Co konkretnie wyciągamy z platform EDI i które pola mają znaczenie

Żeby AI mogło działać na tych danych, najpierw musi mieć do nich dostęp. Z Comarch EDI, Infinite i EDISON pobieramy przez API lub przez odczyt plików EDIFACT następujące typy dokumentów:

• ORDERS: zamówienia od sieci, z polami EAN/GTIN produktu, żądaną ilością w segmencie QTY, numerem GLN miejsca dostawy, datą dostawy w DTM i numerem zamówienia zakupu
• ORDRSP: potwierdzenie lub częściowa odmowa zamówienia ze statusem każdej linii produktowej
• DESADV: awizo dostawy wysyłane przed przyjazdem towaru, z numerami NVE/SSCC palet i ilościami per linia
• INVOIC: faktura elektroniczna z segmentami LIN (linie produktów), QTY (ilości), MOA (kwoty), PRI (ceny jednostkowe), TAX (podatek)
• APERAK: komunikat odrzucenia dokumentu z kodem błędu i wskazaniem segmentu EDIFACT, w którym problem wystąpił
• RECADV: potwierdzenie odbioru towaru przez sieć, często z rozbieżnościami w ilości przyjętej vs. awizowanej

Surowy EDIFACT wygląda jak ciąg zaszyfrowanych segmentów. Przykład początku komunikatu: UNH+1+ORDERS:D:96A:UN'BGM+220+PO-5543+9'DTM+137:20241015:102'. AI parsuje ten format i wyciąga wartości, które mają znaczenie dla biznesu.

Jak AI tłumaczy odrzucony dokument EDI na konkretny powód i co z tym zrobić

Odrzucenie dokumentu przychodzi jako komunikat APERAK. Zawiera kod błędu w standardzie EANCOM i wskazanie segmentu, w którym problem wystąpił. Kody takie jak 7 (błąd danych w dokumencie), 27 (niezgodność numeru GLN) albo ZZZ (błąd zdefiniowany przez nadawcę) nic nie mówią osobie, która nie siedzi w EDI zawodowo.

AI odczytuje kod błędu, numer dokumentu, którego dotyczy, i segment z problemem, po czym generuje konkretną informację:

"Faktura INVOIC nr INV-2024-1532 została odrzucona przez Carrefour. Powód: niezgodny numer GLN sprzedającego w segmencie NAD+SE. W dokumencie jest 5906123400001, a oczekiwany to 5906123400018. Sprawdź konfigurację GLN w ustawieniach konta Comarch EDI i wyślij fakturę ponownie."

To jest instrukcja, nie techniczny żargon. Osoba obsługująca konto sieci wie co zrobić bez dzwonienia do helpdesku EDI.

U jednego z naszych klientów, dostawcy artykułów spożywczych do kilku sieci dyskontowych, odrzucenia INVOIC pojawiały się cyklicznie i przez kilka tygodni nikt nie wiedział dlaczego. Pracownik widział w portalu status "odrzucono", nie rozumiał APERAK i czekał na kontakt z sieci. Po podłączeniu AI okazało się, że problem leży w polu DTM+35 (termin płatności): format daty był niezgodny z wymaganiami tej konkretnej sieci. Jedna zmiana w szablonie dokumentu i odrzucenia przestały się pojawiać.

ORDERS bez ORDRSP: jak AI śledzi terminy potwierdzeń i co robi, gdy czas ucieka

Każde ORDERS, które wpłynęło, powinno dostać ORDRSP w czasie wymaganym przez daną sieć. Wymagania różnią się: niektóre sieci dają kilka godzin, inne do końca dnia roboczego. Jeśli termin minie bez potwierdzenia, sieć może anulować zamówienie albo naliczyć karę.

AI sprawdza listę odebranych ORDERS i porównuje ją z listą wysłanych ORDRSP. Dla każdego ORDERS bez odpowiedzi wylicza, ile czasu pozostało do terminu na podstawie reguł danej sieci. Gdy zbliża się deadline, wysyła alert do odpowiedniej osoby:

"Zamówienie PO-5543 od Makro Cash, planowana dostawa 18.10, brak ORDRSP. Deadline na potwierdzenie mija o 15:00. Przypisane do: Anna Kowalska."

Taki alert może trafiać mailem, przez Teams albo Slacka. Ważne, że trafia zanim jest za późno, a nie po fakcie. AI może też sygnalizować, które linie zamówienia będą problematyczne do potwierdzenia, jeśli ma dostęp do stanów magazynowych: zanim ktoś wyśle ORDRSP na ślepo.

Gdzie AI wychwytuje rozbieżności między zamówieniem a fakturą przed wysyłką

W obsłudze sieci handlowych prędzej czy później pojawia się sytuacja, gdy faktura nie zgadza się z zamówieniem. Sieć zamówiła 240 kartonów, dostałeś 230, a faktura idzie na 240. Cena jednostkowa w INVOIC nie zgadza się z tym, co sieć ma u siebie. Albo EAN produktu zmienił się przy relaunchu i nowy kod nie jest jeszcze zaktualizowany u kupca.

AI zestawia dane pole po polu: numer EAN z segmentu LIN w ORDERS kontra LIN w INVOIC, ilości z QTY, ceny jednostkowe z PRI, kwoty zbiorcze z MOA. Tam gdzie jest rozbieżność, raport pokazuje konkretną linię:

"Linia 3, EAN 5901234567890: zamówiono 480 szt. po 2,40 zł netto (MOA = 1 152,00), zafakturowano 480 szt. po 2,52 zł netto (MOA = 1 209,60). Różnica w cenie jednostkowej. Sprawdź czy sieć ma aktualny cennik z PRICAT wysłanego 01.10."

Zamiast czekać na notę obciążeniową, dział obsługi może proaktywnie wysłać korektę albo wyjaśnienie do kupca. Sieć widzi, że problem jest pod kontrolą, zanim sam go zauważy.

Raport dla działu obsługi sieci: co dostają każdego ranka i jak to wygląda

Wszystko powyższe spina się w jeden codzienny raport, generowany automatycznie przed godziną pracy. Trafia mailem albo do kanału Teams do osoby odpowiedzialnej za dany account sieci.

Raport zawiera sekcje:

• Odrzucenia do obsługi dzisiaj: lista APERAK z ostatnich 24 godzin, przetłumaczona na opis po polsku, z nazwą sieci, numerem dokumentu i wskazaniem co poprawić
• ORDERS bez ORDRSP: zamówienia czekające na potwierdzenie, posortowane według pilności z liczbą godzin do terminu
• Rozbieżności ORDERS vs INVOIC: zestawienie linii produktowych, gdzie coś się nie zgadza przed wysyłką faktury
• DESADV do wysłania: awiza wymagane przed nadchodzącymi dostawami, z datami i numerami SSCC
• RECADV z różnicami: potwierdzenia odbioru od sieci, gdzie ilość przyjęta różni się od awizowanej i wymaga wyjaśnienia

Nie ma ogólników, nie ma zbiorczych liczb bez kontekstu. Każda pozycja to konkretny dokument, konkretna sieć i konkretna akcja do wykonania.

Od czego zaczynamy, zanim AI zacznie działać na danych EDI

Pierwsze pytanie brzmi zawsze: czy mamy dostęp API do portalu EDI? Comarch EDI udostępnia API do pobierania i wysyłania komunikatów EDIFACT. Infinite i EDISON mają własne mechanizmy: część wersji działa przez SFTP, część przez webservice. Na start sprawdzamy jaki typ dostępu mamy i czy posiadamy aktualne dane uwierzytelniające.

Drugi krok to lista sieci, które obsługujemy przez EDI, i zebranie wymagań każdej z nich: jakie typy dokumentów, jakie terminy na ORDRSP, jakie specyficzne reguły walidacji. Ta wiedza rzadko jest zapisana w jednym miejscu. Zwykle siedzi w głowie jednej osoby w firmie albo w mailu sprzed kilku lat od koordynatora EDI z sieci.

Kwestia infrastruktury: jeśli zależy Ci na tym, żeby komunikaty EDIFACT z zamówieniami sieci nie opuszczały Twojej infrastruktury, model AI uruchamiamy on-premise. Jeśli to nie jest wymóg, można działać przez chmurę. Efekt dla użytkownika jest taki sam: raport rano, alerty na bieżąco przez Teams lub mail.

Jeśli chcesz zobaczyć, które procesy EDI w Twojej firmie dałoby się objąć jako pierwsze i co taka integracja wymaga po stronie dostępów, umów się na bezpłatny audyt. Możesz też zajrzeć do realnych wdrożeń, żeby zobaczyć jak podobne firmy korzystają z AI przy obsłudze sieci handlowych.