Gdy zamówienie, dostawa albo faktura ma przejść między firmami bez ręcznego przepisywania danych, sama wymiana plików nie wystarczy. Potrzebne są zgodne standardy, poprawne mapowania i dobrze skonfigurowany system ERP. SAP EDI łączy procesy biznesowe w SAP z komunikatami partnerów, dlatego w tym artykule pokazuję, jak działa ten mechanizm, jakie dokumenty obejmuje, co trzeba skonfigurować i gdzie najczęściej pojawiają się problemy.
Sprawna wymiana danych zależy bardziej od konfiguracji niż od samego formatu
- EDI w SAP automatyzuje wymianę zamówień, potwierdzeń, awizacji dostaw i faktur.
- IDoc jest typowym formatem pośrednim, który łączy procesy SAP z zewnętrznym tłumaczem EDI lub middleware.
- WE20, WE21, typy komunikatów i mapowania tworzą podstawę konfiguracji partnera.
- EDIFACT, X12, XML i cXML mogą działać w jednym środowisku, jeśli zostaną poprawnie przekształcone.
- KSeF nie zastępuje całego EDI, ponieważ obsługuje przede wszystkim krajowy obieg faktur ustrukturyzowanych.
Czym jest EDI w systemie SAP
Electronic Data Interchange oznacza elektroniczną wymianę danych biznesowych między firmami w uzgodnionym, maszynowo czytelnym formacie. W środowisku SAP rozwiązanie służy przede wszystkim do automatyzacji procesów zakupowych, sprzedażowych, logistycznych i finansowych. Zamiast otrzymywać załącznik i ręcznie wprowadzać jego zawartość, system może sam utworzyć zamówienie, dostawę albo dokument księgowy.
Trzeba jednak rozdzielić dwie rzeczy. EDI jest sposobem wymiany komunikatów, natomiast SAP musi te komunikaty zrozumieć i powiązać z konkretnymi obiektami biznesowymi. Do tego często wykorzystuje się IDoc, czyli wewnętrzny format SAP przeznaczony do przesyłania danych pomiędzy systemami.
Przykładowo komunikat EDIFACT ORDERS albo X12 850 może zostać przekształcony do IDoc zamówienia. W drugą stronę system SAP może wygenerować IDoc faktury, a middleware zamieni go na format wymagany przez odbiorcę. Najważniejsza praca odbywa się na styku procesu biznesowego, danych podstawowych i mapowania, a nie w samym przesłaniu pliku.
Co daje automatyzacja
- ogranicza ręczne przepisywanie danych i ryzyko pomyłek,
- skraca czas obsługi zamówień i dostaw,
- ułatwia śledzenie statusu dokumentu,
- pozwala obsługiwać dużą liczbę partnerów bez proporcjonalnego zwiększania zespołu,
- zapewnia lepszą spójność danych między sprzedażą, logistyką i finansami.
Z mojego doświadczenia największą korzyść widać nie przy pojedynczym partnerze, lecz przy powtarzalnych procesach i dużym wolumenie dokumentów. Jeżeli firma wymienia kilkanaście zamówień miesięcznie, ręczna obsługa może jeszcze działać. Przy tysiącach dokumentów zaczyna generować opóźnienia, reklamacje i koszty, których nie widać w pierwszym arkuszu kalkulacyjnym.
Jak wygląda przepływ komunikatu od partnera do SAP
Typowy proces ma kilka warstw. Partner wysyła dokument w uzgodnionym standardzie, na przykład EDIFACT, X12 albo XML. Następnie translator EDI lub platforma integracyjna sprawdza strukturę, wykonuje mapowanie i przekazuje dane do SAP jako IDoc, API albo inny obsługiwany komunikat.
- Utworzenie dokumentu biznesowego u partnera, na przykład zamówienia zakupu.
- Transmisja przez AS2, SFTP, VAN, API lub inny uzgodniony kanał.
- Walidacja i mapowanie, czyli sprawdzenie składni oraz zamiana pól na strukturę SAP.
- Przetworzenie w SAP i utworzenie dokumentu, na przykład zamówienia sprzedaży.
- Potwierdzenie i monitoring, dzięki któremu można sprawdzić, czy komunikat dotarł i został zaksięgowany.
Przy komunikacji wychodzącej kierunek jest odwrotny. Zdarzenie w SAP, takie jak utworzenie dostawy, uruchamia komunikat wyjściowy. IDoc trafia do warstwy integracyjnej, gdzie jest tłumaczony na format partnera i wysyłany na zewnątrz.
| Kierunek | Przykład | Efekt w SAP |
|---|---|---|
| Przychodzący | ORDERS lub X12 850 | Utworzenie zamówienia sprzedaży albo zakupu |
| Wychodzący | ORDRSP | Wysłanie potwierdzenia zamówienia |
| Wychodzący | DESADV lub X12 856 | Awizacja wysyłki i danych logistycznych |
| Wychodzący | INVOIC lub X12 810 | Przekazanie danych faktury |
W monitoringu można spotkać statusy IDoc, które pomagają szybko znaleźć miejsce awarii. Status 51 zwykle oznacza błąd aplikacyjny po stronie SAP, a status 53 informuje o poprawnym zaksięgowaniu komunikatu przychodzącego. Dla komunikatów wychodzących często analizuje się statusy 03 lub 12, ale ich znaczenie trzeba zawsze odczytywać razem z logiem middleware i wymaganiami konkretnego scenariusza.
Jakie dokumenty i standardy obsługuje integracja
EDI nie jest jednym formatem. Każdy partner może wymagać innego standardu, wersji dokumentu, kodów jednostek, identyfikatorów produktów czy reguł walidacji. Dlatego dwa komunikaty dotyczące tej samej faktury mogą wyglądać zupełnie inaczej, mimo że przenoszą podobne dane.
| Standard lub dokument | Typowe zastosowanie | Na co uważać |
|---|---|---|
| UN/EDIFACT | Handel międzynarodowy, logistyka i przemysł | Wersja katalogu, segmenty obowiązkowe i kody partnera |
| ANSI X12 | Popularny szczególnie w Ameryce Północnej | Wymagania odbiorcy, kwalifikatory i wersja transakcji |
| XML | Integracje systemowe i dokumenty strukturalne | Schema, namespace’y oraz walidacja danych |
| cXML | Zakupy i platformy procurementowe | Reguły konkretnej sieci zakupowej |
| ORDERS, DESADV, INVOIC | Zamówienia, awizacje i faktury | Nie zakładać, że identyczna nazwa oznacza identyczne mapowanie |
W praktyce często spotykam błąd polegający na traktowaniu nazwy dokumentu jako kompletnej specyfikacji. Samo „INVOIC” nie mówi jeszcze, jakie pola są wymagane, jak zapisuje się rabaty, w jaki sposób identyfikuje się pozycje ani gdzie należy przekazać numer zamówienia. Decydująca jest specyfikacja partnera, nazywana często MIG, czyli Message Implementation Guideline.
Warto też odróżnić dokument handlowy od kanału komunikacji. AS2, SFTP, OFTP2 czy VAN opisują sposób przesłania danych, a EDIFACT, X12 lub XML opisują ich strukturę. Dzięki temu można zmienić kanał bez przebudowy całego procesu, choć zwykle wymaga to ponownego testu bezpieczeństwa i monitoringu.
Co trzeba skonfigurować po stronie SAP
Konfigurację najlepiej zacząć od procesu, a nie od transakcji. Najpierw trzeba ustalić, jaki dokument powstaje, kto go wysyła, kto odbiera, jakie dane są obowiązkowe i co ma się stać po błędzie. Dopiero potem można dobrać typ IDoc, komunikat, port i reguły wyjściowe.
Dane podstawowe i identyfikacja partnera
System musi znać partnera, jego numer, role, adresy, jednostki organizacyjne oraz identyfikatory używane w komunikacji. Szczególne znaczenie mają numery materiałów, jednostki miary, kody podatkowe i identyfikatory lokalizacji. Dwie firmy mogą używać różnych numerów tego samego produktu, dlatego mapowanie indeksów jest jednym z najczęstszych źródeł problemów.
Profile partnerów i porty
W klasycznym modelu SAP profile partnerów konfiguruje się między innymi w transakcji WE20. Określa się tam komunikaty przychodzące i wychodzące, typy IDoc, tryb przetwarzania, kody procesów oraz parametry odbiorcy. Transakcja WE21 służy natomiast do definiowania portów, przez które komunikaty opuszczają system albo trafiają do warstwy integracyjnej.
Konfiguracja musi obejmować obie strony. Profil wyjściowy bez poprawnego portu nie zapewni wysyłki, a profil wejściowy bez właściwego kodu procesu nie utworzy dokumentu biznesowego. Najczęściej problem nie leży w samym IDoc, tylko w niedopasowaniu partnera, komunikatu i reguły wyjściowej.
Przeczytaj również: System BPM w firmie produkcyjnej - jak wdrożyć go z głową?
Mapowanie i obsługa wyjątków
Mapowanie określa, skąd pobrać dane z SAP i do którego segmentu komunikatu je wstawić. Obejmuje nie tylko proste kopiowanie pól, lecz także konwersję jednostek, formatów dat, kodów podatkowych, identyfikatorów kontrahentów i danych logistycznych.
Nie należy projektować wyłącznie ścieżki sukcesu. Trzeba określić, co dzieje się przy braku materiału, błędnym numerze zamówienia, nieznanej jednostce miary albo niedostępnym partnerze. W dobrym rozwiązaniu błąd trafia do kolejki lub monitoringu, a użytkownik dostaje informację pozwalającą poprawić dokument bez ręcznego odtwarzania całej transakcji.
Jaka architektura ma sens w 2026 roku
Wybór technologii zależy od istniejącego krajobrazu SAP, liczby partnerów, wymagań bezpieczeństwa i planu migracji do chmury. Nie ma jednej architektury dobrej dla każdej firmy. Inaczej projektuje się połączenie z jednym dużym odbiorcą, a inaczej sieć obejmującą kilkuset dostawców.
| Model | Kiedy pasuje | Ograniczenie |
|---|---|---|
| SAP ERP lub S/4HANA z PI/PO | Istniejące środowisko on-premise z rozbudowanymi integracjami | Większy ciężar utrzymania i modernizacji |
| SAP Integration Suite | Środowiska hybrydowe, B2B, integracje cloud i centralny monitoring | Wymaga kompetencji integracyjnych oraz kontroli kosztów użycia |
| Zewnętrzny dostawca EDI lub VAN | Duża liczba partnerów i potrzeba szybkiego onboardingu | Zależność od dostawcy i dodatkowy koszt abonamentowy |
| Bezpośrednie API | Partner ma dojrzałe interfejsy i niewielką liczbę uzgodnionych scenariuszy | Nie zawsze zastępuje standardowe dokumenty EDI |
Platforma SAP Integration Suite może obsługiwać scenariusze B2B, mapowania, profile partnerów i różne kanały komunikacji. SAP opisuje w tym obszarze między innymi Cloud Integration, Integration Advisor oraz Trading Partner Management. W praktyce takie narzędzia skracają start projektu, ale nie zdejmują z firmy odpowiedzialności za jakość danych i uzgodnienie procesu.
W polskich projektach trzeba dodatkowo oddzielić klasyczne EDI od KSeF. Według informacji Ministerstwa Finansów w 2026 roku obowiązek korzystania z KSeF jest wdrażany etapami, a do końca 2026 roku najmniejsi podatnicy mogą korzystać z przejściowego limitu 10 000 zł brutto miesięcznie dla faktur wystawianych poza systemem. KSeF dotyczy krajowego obiegu faktur, ale nie zastępuje zamówień, awizacji, potwierdzeń ani całej komunikacji logistycznej EDI.
Dlatego faktura może mieć dwa niezależne tory. Dane z SAP są wysyłane do partnera jako INVOIC, a równolegle faktura jest przekazywana do KSeF w wymaganej strukturze. Projekt, który miesza te cele w jednym interfejsie bez jasnego podziału odpowiedzialności, szybko staje się trudny w utrzymaniu.
Jak testować i diagnozować problemy
Testy powinny obejmować cały łańcuch, nie tylko sprawdzenie, czy plik został wysłany. Komunikat może mieć poprawną składnię, przejść przez kanał transmisji, a mimo to nie utworzyć dokumentu w SAP z powodu błędnego materiału, brakującego partnera lub niezgodnego kodu podatkowego.
- Test jednostkowy sprawdza pojedyncze mapowanie i wartości pól.
- Test end-to-end obejmuje system partnera, kanał, middleware i SAP.
- Test negatywny celowo używa błędnych danych, aby zweryfikować obsługę wyjątków.
- Test wolumenowy pokazuje, czy rozwiązanie działa przy dużej liczbie dokumentów.
- Test ponowienia sprawdza, czy komunikat można bezpiecznie przetworzyć ponownie.
- Uzgodnienie biznesowe porównuje liczbę, wartości i statusy dokumentów po obu stronach.
Przy awarii analizuję kolejno trzy miejsca: SAP, warstwę integracyjną i kanał komunikacji. Jeżeli IDoc ma status błędny, trzeba sprawdzić jego rekord kontrolny, dane segmentów oraz log aplikacyjny. Jeżeli SAP potwierdza wysyłkę, ale partner niczego nie otrzymał, problem może leżeć w tłumaczeniu, certyfikacie AS2, serwerze SFTP albo regułach po stronie odbiorcy.
Najczęstsze błędy wynikają z braku właściciela procesu. IT pilnuje transmisji, dział sprzedaży zna zamówienia, logistyka zna dostawy, a księgowość faktury. Jeżeli nikt nie odpowiada za całość, komunikaty technicznie przechodzą, lecz dokumenty biznesowe nadal wymagają ręcznej korekty.
Co sprawdzić przed uruchomieniem kolejnego partnera
Przed rozpoczęciem prac warto przygotować krótką kartę partnera. Powinna zawierać rodzaje dokumentów, standard, wersję, kanał, identyfikatory, terminy, zasady potwierdzeń i osoby odpowiedzialne za błędy. Taki dokument ogranicza liczbę założeń, które później wychodzą dopiero podczas testów produkcyjnych.
- sprawdź, czy dane podstawowe SAP odpowiadają słownikom partnera,
- ustal, który system jest źródłem prawdy dla zamówienia, dostawy i faktury,
- zdefiniuj regułę numeracji i korekt dokumentów,
- ustaw monitoring z powiadomieniami, a nie tylko log techniczny,
- przetestuj błędne dane i ponowne przetwarzanie,
- zaplanuj obsługę zmian wersji standardu i wymagań partnera.
Moja praktyczna rekomendacja jest prosta: zacząć od jednego procesu o wysokim wolumenie, na przykład zamówień lub awizacji dostaw, a dopiero później rozszerzać zakres. Lepsze jest jedno stabilne połączenie z pełnym monitoringiem niż kilka uruchomionych na skróty, które wymagają codziennego ręcznego ratowania.
Dobrze zaprojektowane EDI w SAP nie jest pojedynczym interfejsem, lecz powtarzalnym procesem obejmującym dane, reguły biznesowe, bezpieczeństwo i odpowiedzialność za wyjątki. Kiedy te elementy są spójne, system przestaje być tylko kanałem przesyłania plików i staje się realnym wsparciem zakupów, produkcji, logistyki oraz finansów.
