PunchOut czy portal B2B: kiedy dostawca powinien wdrożyć katalog PunchOut

Czym jest PunchOut?

PunchOut to sklep internetowy dostawcy otwierany z wnętrza systemu zakupowego klienta. Pracownik działu zakupów albo zwykły pracownik firmy klika dostawcę w swoim systemie, trafia do jego sklepu od razu zalogowany jako swoja firma, widzi asortyment i ceny z kontraktu, kompletuje koszyk i przenosi go z powrotem. Koszyk staje się zapotrzebowaniem w systemie klienta, przechodzi wewnętrzną akceptację i wraca do dostawcy jako zamówienie zakupu.

PunchOut istnieje, bo duże firmy chcą, żeby każdy zakup szedł jedną ścieżką: budżet, akceptacje, centra kosztów i ślad w jednym systemie. Dział zakupów nie jest jednak w stanie utrzymywać pełnego katalogu każdego dostawcy. PunchOut daje kupującemu aktualny katalog dostawcy, a akceptacja zostaje po stronie klienta.

W Polsce określenie „platforma zakupowa” często oznacza narzędzie do zapytań ofertowych i przetargów. To inny proces: dostawca odpowiada na zapytanie ofertą, a PunchOut obsługuje bieżące zakupy z ustalonego wcześniej katalogu i cennika. Jeśli klient pisze o „platformie zakupowej”, dopytaj, czy chodzi o przetargi, czy o zakupy z katalogu.

Dla dostawcy PunchOut to dodatkowy kanał obok zamówień składanych bezpośrednio. Kanał bezpośredni, czyli portal, w którym klient firmowy sam zamawia po swoich cenach, opisujemy w tekście o tym, jaka platforma B2B pasuje do producenta i hurtowni.

Jak działa PunchOut w cXML krok po kroku?

Sesja PunchOut w cXML ma pięć kroków, a sklep dostawcy bierze udział w czterech z nich. Nazwy poniżej to dokumenty standardu cXML, najczęstszego protokołu w Ariba i Coupa.

1. Otwarcie sesji. Kupujący klika twój katalog w swoim systemie zakupowym. System wysyła do twojego sklepu PunchOutSetupRequest z danymi, które identyfikują klienta, identyfikatorem sesji (BuyerCookie) i adresem, na który trzeba odesłać koszyk (BrowserFormPost).
2. Odpowiedź sklepu. Sklep sprawdza dane, otwiera sesję dla tej firmy i odsyła PunchOutSetupResponse z adresem strony startowej. Przeglądarka kupującego otwiera tę stronę.
3. Zakupy. Kupujący przegląda produkty i kompletuje koszyk w twoim sklepie, w cenach i asortymencie swojej firmy. Zamiast kasy sklep pokazuje przycisk przeniesienia koszyka.
4. Zwrot koszyka. Sklep odsyła koszyk przez przeglądarkę kupującego jako PunchOutOrderMessage: każda pozycja z twoim indeksem, opisem, ilością, jednostką miary, ceną i, jeśli klient tego wymaga, kodem klasyfikacji, na przykład UNSPSC. Koszyk staje się zapotrzebowaniem w systemie klienta.
5. Zamówienie. Po akceptacji, która może trwać minuty albo dni, system zakupowy wysyła do ciebie OrderRequest. To jest wiążące zamówienie, które trzeba dopasować do danych z sesji i przekazać do ERP.

Po zamówieniu cXML może przenosić dalszą część cyklu: potwierdzenie zamówienia, awizację wysyłki i fakturę. Czy klient oczekuje tych dokumentów tym samym kanałem, to jedno z pierwszych pytań do niego.

W Polsce fakturę krajową dla firmy i tak wystawiasz w KSeF: od 1 lutego 2026 roku obowiązek objął największych podatników, a od 1 kwietnia 2026 roku pozostałych, z przejściowym wyjątkiem do końca 2026 roku (zakres obowiązkowego KSeF). Jeśli klient chce dodatkowo faktury w swoim systemie zakupowym, ustal, czy to kopia do dopasowania, czy osobny dokument, i jaki numer zamówienia ma się na niej znaleźć.

cXML czy OCI: o który protokół poprosi klient?

Protokół wybiera klient, bo wynika on z jego systemu zakupowego. cXML jest typowy dla SAP Ariba, Coupa i systemów Oracle. OCI, czyli Open Catalog Interface od SAP, spotkasz u klientów, którzy kupują bezpośrednio w SAP (SRM albo S/4HANA).

OCI łatwiej uruchomić, a trudniej domknąć: zwrot koszyka to krótki formularz, ale zamówienie przychodzi kanałem wybranym przez klienta i nadal trzeba je dopasować do koszyka. Sklep, który obsługuje jeden protokół, może dołożyć drugi później, bo oba korzystają z tej samej sesji klienta, cen kontraktowych i koszyka.

PunchOut, portal B2B, katalog statyczny czy EDI: czego potrzebuje klient?

PunchOut to jeden z czterech sposobów przyjmowania zamówień od firm i każdy pasuje do innego klienta. Pytanie nie brzmi, który kanał jest nowocześniejszy, ale gdzie klient akceptuje zakupy i kto utrzymuje katalog.

Jeden sklep może obsługiwać kilka kanałów. Hurtownia zamawia w portalu, a korporacja wchodzi PunchOutem do tego samego katalogu z tymi samymi cenami. Dlatego radzimy budować PunchOut na sklepie B2B z kontami firmowymi i cenami klientów, a nie jako osobny katalog.

Część systemów zakupowych obsługuje też tak zwany PunchOut poziomu 2: kupujący wyszukuje twoje produkty w swoim systemie i wchodzi od razu na stronę wybranego produktu. Wymaga to pliku indeksu twoich produktów w systemie klienta, więc traktuj go jako kolejny krok, nie pierwszą wersję.

Kiedy PunchOut się opłaca, a kiedy to zły wybór?

PunchOut opłaca się wtedy, gdy wymaga go konkretny klient, a zamówienia od niego uzasadniają pracę. Taki wymóg zwykle pojawia się w przetargu, przy rejestracji dostawcy albo przy odnowieniu umowy, a klient mówi o nim wprost: „kupujemy tylko przez Aribę” albo „potrzebujemy katalogu OCI”.

Sygnały, że PunchOut ma sens:

• Konkretny klient o niego prosi i podaje system oraz protokół.
• Klient regularnie kupuje u ciebie szeroki asortyment, więc przeglądanie aktualnego katalogu przydaje się jego pracownikom.
• Klient ma ceny kontraktowe, które już trzymasz per klient albo możesz trzymać.
• Brak kanału oznacza utratę klienta, bo jego zasady nie pozwalają kupować poza systemem zakupowym.

Kiedy PunchOut to zły wybór

• Żaden klient o niego nie pytał. PunchOut nie jest funkcją marketingową. Bez kupującego, który używa systemu zakupowego, nikt go nie otworzy.
• Klient kupuje kilka stałych pozycji. Plik katalogu z cenami kontraktowymi jest tańszy w utrzymaniu, a do powtarzalnych zamówień znanych pozycji lepiej pasuje EDI.
• Klient to hurtownia albo mała firma. Zamawia bezpośrednio, więc lepiej obsłuży go portal B2B z szybkim zamówieniem po indeksie i ponowieniem zamówienia.
• Ceny i stany w sklepie nie zgadzają się z ERP. PunchOut pokazuje kupującemu dane ze sklepu w chwili zakupu. Jeśli są błędne, błędne będą też zapotrzebowanie i zamówienie. Najpierw popraw dane.
• Wystarczy moduł B2B z ERP. Jeśli żaden klient nie wymaga PunchOutu, a proces mieści się w gotowym module, zacznij od niego. Porównanie modułu z własną platformą znajdziesz w tekście Comarch B2B czy własna platforma.

Co musi zbudować dostawca?

Dostawca potrzebuje pięciu elementów dla jednego klienta PunchOut i tylko dwa pierwsze dotyczą protokołu. Najwięcej czasu zajmują dane i dopasowanie zamówień, a nie obsługa XML.

1. Przyjęcie sesji. Punkt końcowy, który odbiera otwarcie sesji, sprawdza dane klienta i otwiera sesję przypiętą do konta firmy. Sesja nie może zależeć od zwykłego logowania, bo kupujący nie loguje się do twojego sklepu.
2. Katalog i ceny klienta. Kupujący widzi tylko asortyment i ceny kontraktowe swojej firmy. Jeśli sklep obsługuje już konta firmowe i cenniki klientów, to kwestia konfiguracji. Jeśli nie, to największa część projektu.
3. Przeniesienie koszyka zamiast kasy. W sesji PunchOut sklep ukrywa płatność i dostawę i pokazuje przycisk przeniesienia koszyka. Pozycje koszyka muszą mieć jednostki miary, indeksy i kody klasyfikacji, których oczekuje klient.
4. Przyjęcie zamówienia. Zamówienie przychodzi później, czasem kilka dni po sesji. System musi je przyjąć, sprawdzić ceny i produkty, utworzyć zamówienie i przekazać je do ERP z numerem zamówienia klienta. Zamówienie ma powstać raz, nawet jeśli system klienta wyśle ten sam komunikat dwa razy.
5. Testy z klientem. Systemy zakupowe mają środowiska testowe i instrukcje onboardingu dostawców. Przygotuj się na kilka sesji i zamówień testowych, zanim dział zakupów klienta włączy katalog.

Sprawdź też koszty po stronie sieci, w której działa klient. SAP opisuje katalogi PunchOut jako funkcję konta enterprise dostawcy w SAP Business Network, z abonamentem i opłatami od transakcji, choć część kupujących pokrywa te opłaty za swoich dostawców. Zapytaj klienta, zanim zaplanujesz budżet.

Jeśli twoje ERP to Comarch, enova albo Subiekt, PunchOut nie zależy od niego bezpośrednio: sesję i koszyk obsługuje sklep, a do ERP trafia gotowe zamówienie z numerem zamówienia klienta. Warunek jest jeden: ceny kontraktowe i stany w sklepie muszą się zgadzać z ERP.

Przykład: zwrot koszyka w OCI w sklepie na Medusie

Medusa nie ma gotowego modułu PunchOut. Buduje się go jako własne endpointy API dla sesji i zamówienia oraz tryb sklepu, który zamiast kasy pokazuje przeniesienie koszyka. W OCI przeniesienie koszyka to formularz HTML z ukrytymi polami, który przeglądarka wysyła na HOOK_URL otrzymany przy otwarciu sesji. Uproszczone mapowanie pozycji koszyka na pola OCI:

type PunchoutLine = {
  sku: string
  title: string
  quantity: number
  unitPrice: number
  currency: string
  unitCode: string // kod jednostki uzgodniony z klientem, na przykład "PCE"
}

function toOciFields(lines: PunchoutLine[]): Record<string, string> {
  const fields: Record<string, string> = {}
  lines.forEach((line, index) => {
    const n = index + 1
    fields[`NEW_ITEM-DESCRIPTION[${n}]`] = line.title.slice(0, 40)
    fields[`NEW_ITEM-VENDORMAT[${n}]`] = line.sku
    fields[`NEW_ITEM-QUANTITY[${n}]`] = String(line.quantity)
    fields[`NEW_ITEM-UNIT[${n}]`] = line.unitCode
    fields[`NEW_ITEM-PRICE[${n}]`] = line.unitPrice.toFixed(2)
    fields[`NEW_ITEM-CURRENCY[${n}]`] = line.currency
  })
  return fields
}

To jedno mapowanie, a nie kompletna integracja OCI. Limit 40 znaków opisu pochodzi ze specyfikacji OCI 4.0; klient może wymagać kolejnych pól, na przykład grupy materiałowej albo czasu dostawy. Sprawdzenie sesji, walidację cen i osobny kanał zamówień trzeba zbudować i przetestować na systemie klienta.

Jak zaplanować pierwsze wdrożenie PunchOut

Pierwsze wdrożenie PunchOut planuj dla jednego klienta, jednego protokołu i jednego scenariusza zamówień, a przed startem zadaj klientowi siedem pytań.

1. Jaki system zakupowy i jaki protokół? cXML czy OCI i w której wersji.
2. Poziom 1 czy 2? Kupujący otwiera cały katalog czy najpierw szuka twoich pozycji w swoim systemie?
3. Jaki asortyment i jakie ceny? Cały katalog czy asortyment z umowy, ceny katalogowe czy kontraktowe.
4. Jakie kody w pozycjach koszyka? Jednostki miary, kody klasyfikacji (na przykład UNSPSC), indeksy materiałowe klienta.
5. Jak przychodzi zamówienie? OrderRequest w cXML, EDI, e-mail czy inny kanał, i kto je potwierdza.
6. Jakie dokumenty po zamówieniu? Potwierdzenie, awizacja i faktura tym samym kanałem czy mailem, obok faktury w KSeF.
7. Kto płaci opłaty sieci i kiedy będzie środowisko testowe? To ustala budżet i kalendarz.

Jeśli sklep ma już konta firmowe i ceny klientów, warstwa PunchOut to zamknięty projekt integracyjny. Jeśli sklepu jeszcze nie ma, zacznij od sklepu B2B: klienci PunchOut i klienci zamawiający bezpośrednio korzystają z tego samego katalogu, cen i obsługi zamówień. Budujemy sklepy i portale B2B na Medusie połączone z ERP, co opisujemy na stronach platforma B2B i integracje e-commerce. Konta firmowe dla klientów biznesowych obok sklepu detalicznego pokazuje realizacja ImpregnatyBC.

Źródła

• cXML.org, standard cXML z opisem PunchOut. Sprawdzone 30 października 2026.
• SAP, dokumentacja Open Catalog Interface (OCI) i specyfikacja OCI 4.0. Sprawdzone 30 października 2026.
• SAP, cennik konta dostawcy w SAP Business Network. Sprawdzone 30 października 2026.
• Ministerstwo Finansów, zakres obowiązkowego KSeF. Sprawdzone 30 października 2026.