Problem · integracja systemów B2B

Każdy kontrahent przysyła dane inaczej, a ktoś u Ciebie to przepisuje.

Integracja systemów B2B różni się od łączenia własnych programów jedną rzeczą: połowa decyzji nie należy do Ciebie. Format i tempo ustala się z drugą firmą, która ma swoje priorytety. Ta część zwykle decyduje o terminie, a dzieje się poza kodem.

Bogusław Tolarz · aktualizacja: 20 sierpnia 2026

Po czym poznać, że to Twój przypadek

Każdy większy kontrahent przysyła zamówienia po swojemu: jeden arkuszem, drugi PDF-em w mailu, trzeci przez własny portal, do którego ktoś u Ciebie codziennie się loguje.
Ktoś ma stały obowiązek: rano pobrać listę od partnera i przepisać ją do Waszego systemu.
Duży odbiorca zapowiedział wymianę elektroniczną od nowego okresu i przysłał specyfikację, której nikt u Was nie potrafi przeczytać.
Zdarza się spór „my wysłaliśmy” kontra „u nas tego nie ma” i nie da się rozstrzygnąć, po której stronie dokument zginął.
Plik przyszedł jak zwykle, ale z przestawionymi kolumnami — wjechał krzywo, a wyszło to dopiero przy rozliczeniu.
Statusy zamówień uzgadniacie telefonicznie, bo żaden system nie mówi drugiemu, że coś się zmieniło.

Skąd się to bierze

Nie ma jednego sposobu, w jaki firmy wymieniają się dokumentami. Standardy istnieją od dekad, ale jest ich kilka rodzin, każdy dostawca oprogramowania rozumie je nieco po swojemu, a obok nich wciąż płynie ogromny ruch na plikach i mailach. Twoja firma nie wybrała tego bałaganu — weszła w niego w chwili, gdy zaczęła pracować z drugą.

Drugi mechanizm jest czysto handlowy: format narzuca ten, kto ma większą siłę. Duży odbiorca przysyła specyfikację i termin, mniejszy dostawca dostosowuje się albo traci zamówienia. Po tamtej stronie stoi wielu partnerów, więc jedynym sensownym ruchem jest jeden wspólny format dla wszystkich.

I rzecz najczęściej pomijana: to połączenie przechodzi przez granicę dwóch firm. Nie ma wspólnego administratora, wspólnego okna serwisowego ani wspólnego priorytetu. Kontrahent zmieni coś u siebie i nikt Was nie uprzedzi, bo w jego głowie to była zmiana wewnętrzna.

Cztery rzeczy do ustalenia z kontrahentem, zanim padnie słowo „integracja”

W wymianie z drugą firmą technika jest najmniejszym problemem. Takie projekty rozsypują się na uzgodnieniach, które wyglądają na oczywiste i dlatego nikt ich nie spisał. Te cztery punkty próbuję domknąć, zanim w ogóle rozmawiamy o narzędziu.

Co dokładnie znaczą pola

Najtrudniejsze uzgodnienie nie brzmi „CSV czy XML”, tylko: czyj indeks towarowy jest wiodący, w jakiej jednostce podajecie ilość, po czym poznajecie ten sam produkt i ten sam punkt dostawy. Dopóki to nie jest spisane, obie strony rozumieją ten sam plik inaczej.

Kanał i rytm wymiany

Czy dane idą paczką o stałej porze, czy pojedynczo w chwili zdarzenia. Kto wysyła, a kto się po nie zgłasza. I co ma się stać, gdy jedna paczka nie przyjdzie.

Potwierdzenie odbioru

Osobna informacja: „dostałem, przyjąłem” albo „dostałem, odrzucam, bo brakuje pola”. Bez niej wymiana jest jednostronna, a każdy brak kończy się rozmową, w której obie firmy są pewne, że zrobiły swoje.

Kto odpowiada za błędny dokument

Gdy przyjdzie zamówienie z błędną ilością, ktoś musi wiedzieć, czy poprawia je u siebie, czy odsyła do korekty. Ustalenie tego zawczasu jest tańsze niż ustalanie przy pierwszej reklamacji, pod presją.

Żaden z tych punktów nie jest pytaniem programistycznym. To ustalenia operacyjne, które ktoś musi przeprowadzić z konkretną osobą po drugiej stronie — i właśnie dlatego zostają na później, a wracają jako spór o to, kto zawinił.

Gdzie to potrafi utknąć

Nie przesłanie pliku. Trudne jest uzgodnienie, co dane znaczą u obu stron — dwie firmy opisują ten sam towar, tę samą dostawę i tego samego klienta w innych układach pojęć. Ta praca jest żmudna, nie wygląda efektownie i schodzi na nią większość czasu, choć w rozmowach o integracji pojawia się na końcu.

Osobny kłopot to awaria, która zdarza się nie u Ciebie. Kanał wymiany działa albo milczy, a milczenie wygląda identycznie jak spokojny dzień bez zamówień. Dlatego sposób, w jaki wymiana zgłasza, że przestała działać, jest częścią tej roboty — w obu kierunkach, także tym, którym Ty wysyłasz.

Zostaje rozstrzyganie sporów. Prędzej czy później padnie „przecież wysłaliśmy”. Pomaga wtedy wyłącznie zapis po Twojej stronie: co dotarło, kiedy i w jakiej postaci. Robi się go na początku, bo dopisany po pierwszej awarii nie odtworzy tego, co już przepadło.

Pytania, od których zaczynam

Odpowiedzi na nie zmieniają rozwiązanie bardziej niż jakikolwiek wybór technologii. Dlatego zadaję je przed wyceną.

Kto tu jest silniejszą stroną?

Jeśli dostosowujecie się do dużego odbiorcy, przestrzeń negocjacyjna jest wąska i rozmowa dotyczy tego, jak najtaniej spełnić jego wymagania. Jeśli to Wy narzucacie format dostawcom — projekt wygląda inaczej i jest tańszy.

Ilu kontrahentów i jaka objętość?

Przy jednym partnerze z dużym wolumenem opłaca się dopasować wprost do niego. Przy kilkunastu drobnych opłaca się jeden własny format wewnętrzny i osobne tłumaczenie dla każdego — inaczej co nowy partner, to nowy system do utrzymania.

Co konkretnie ma płynąć i w którą stronę?

Zamówienie, potwierdzenie przyjęcia, awizo wysyłki, faktura, stany, cennik — to sześć różnych spraw. Firmy mówią „zintegrujmy się”, mając na myśli różne komplety dokumentów, i zauważają rozbieżność w połowie prac.

Co się dzieje, gdy dane nie przyjdą?

Cisza wygląda dokładnie tak samo jak brak zamówień. Pytam, po czym poznacie, że kanał stoi — i czy dowiecie się tego samego dnia, czy od kontrahenta, gdy zabraknie mu towaru.

Kto po drugiej stronie odbierze telefon?

Potrzebna jest konkretna osoba i informacja, czy to pracownik kontrahenta, czy dostawca jego systemu. Integracja bez kogoś technicznego po tamtej stronie to projekt bez drugiej połowy — i to ta połowa blokuje termin.

Czy ich system ma w ogóle czym się wymieniać?

Czasem okazuje się, że „ich system” to arkusz, który raz dziennie eksportuje jedna osoba. Wtedy nie ma czego łączyć po ich stronie i rozmowa przenosi się na to, jak uporządkować to, co i tak wysyłają.

Sposoby wymiany, od najprostszego

Przy mniejszych partnerach sprawa zamyka się zwykle na pierwszych dwóch pozycjach — bez pisania czegokolwiek.

1
Ustalenie stałego układu i jednego miejsca
Zanim ktokolwiek napisze linijkę kodu: ten sam układ kolumn, ta sama nazwa pliku, zawsze na ten sam adres. To rozmowa handlowa i bywa, że sama zamyka temat: praca brała się z tego, że każda przesyłka wyglądała inaczej.
2
Sprawdzenie, co już macie kupione
Systemy handlowe i magazynowe często mają moduł wymiany dokumentów, za który firma płaci, a nikt go nie uruchomił. Podobnie po drugiej stronie: portal partnera bywa, że potrafi udostępniać dane do automatycznego pobrania, a Wy logujecie się ręcznie, bo tak się zaczęło.
3
Tłumacz między ich formatem a Twoim
Warstwa, która odbiera to, co przysyła partner, przekłada na Wasze pola i wstawia do systemu. Da się to postawić na gotowym narzędziu w rodzaju n8n czy Make. Zasada jest jedna: tłumaczenie osobne dla każdego kontrahenta, ale wspólny format wewnętrzny.
4
Operator wymiany dokumentów
Firmy pośredniczące w wymianie B2B utrzymują gotowe połączenia z dużymi sieciami i biorą na siebie zgodność z ich wymaganiami. Sensowne, gdy trafiacie na partnera z rozbudowaną specyfikacją. Kosztem jest abonament i zależność od pośrednika.
5
Bezpośrednie połączenie systemów, pisane na miarę
Gdy współpraca jest stała, wolumen duży, a wymagania nie mieszczą się w gotowych rozwiązaniach. Najdroższy wariant, potrzebny przy naprawdę dużym wolumenie.

Na co bym się nie zgodził

Nie budowałbym osobnego rozwiązania dla każdego kontrahenta

Przy drugim partnerze wygląda to niewinnie, przy piątym firma ma pięć mechanizmów, z których każdy psuje się inaczej. Idę w stronę jednego formatu wewnętrznego i cienkiej warstwy tłumaczącej, nawet gdy przy pierwszym partnerze wydaje się to nadmiarem.

Nie ruszałbym wymiany, zanim uporządkujecie dane u siebie

Jeśli ten sam towar ma u Was trzy indeksy, a klient figuruje w dwóch kartotekach, integracja tego nie posprząta. Zacznie wciągać cudze dane w istniejący bałagan — szybciej i w większej ilości, niż robił to człowiek.

Nie zgadzałbym się na wymianę bez śladu

Musi zostać zapis: co przyszło, kiedy, w jakiej postaci i co system z tym zrobił. To jedyna rzecz, która rozstrzyga spór z kontrahentem. Bez niego wygrywa ten, kto jest bardziej pewny siebie.

Nie obiecywałbym terminu zależnego od tempa drugiej firmy

Połowa tej roboty dzieje się po stronie, na którą nie masz wpływu: ich informatyk, ich dostawca, ich kolejka zadań. Termin ma sens dla części, którą kontrolujecie; reszta zależy od drugiej strony i lepiej nazwać to na początku.

Czasem taniej jest dogadać się mailem.

Policz to u siebie, zanim ze mną porozmawiasz: ile dokumentów miesięcznie przychodzi od tego kontrahenta, razy ile minut zajmuje obsłużenie jednego, razy stawka osoby, która to robi. Jeśli wychodzi kilka dokumentów w miesiącu i pomyłka nic nie kosztuje, połączenie systemów będzie droższe niż ręczna obsługa — także dlatego, że po uruchomieniu ktoś musi je utrzymywać.

Odradzam też wtedy, gdy po drugiej stronie nie ma nikogo technicznego ani nikogo, kto może zdecydować o formacie. Projekt, w którym jedna firma jest gotowa, a druga odsyła do dostawcy, który odezwie się kiedyś, potrafi stać miesiącami — i płacisz wtedy za czekanie, nie za pracę.

Odwrotnie jest w dwóch sytuacjach. Gdy duży odbiorca warunkuje dalszą współpracę wymianą elektroniczną, nie chodzi już o oszczędność czasu, tylko o utrzymanie przychodu. I gdy błąd wychodzi na zewnątrz — zła ilość na dostawie, zła kwota na fakturze, towar pod złym adresem. Wtedy sam czas przepisywania jest najmniejszą częścią kosztu.

Opisz jednego kontrahenta i to, co od niego przychodzi.

Nie musisz wiedzieć, czy Wasze systemy mają API ani co znaczą skróty ze specyfikacji, którą dostałeś. Napisz, kto co wysyła, w jakiej formie i kto to u Was obsługuje — odpowiem, którą z pięciu dróg widzę u Ciebie i co trzeba ustalić z drugą stroną, zanim cokolwiek ruszy.

Opisz swoją sytuacjębez płatności i zobowiązań

Jeśli problemem nie są kontrahenci, tylko dwa Wasze własne programy: integracja systemów — kiedy się opłaca → A jeśli chcesz zobaczyć, jak wygląda pełna analiza takiego przebiegu: przeczytaj przykładową analizę →