Czym jest PunchOut? Kompletny poradnik dla dostawców

Jak działa PunchOut

PunchOut łączy dwa systemy, które nie zostały zaprojektowane do komunikacji ze sobą: system zakupowy klienta i Państwa sklep online. Duże organizacje kupują przez systemy eProcurement takie jak SAP Ariba, Coupa lub SAP S/4HANA, gdzie każdy zakup podlega regułom zatwierdzania i trafia do właściwego budżetu. Zamiast kopiować produkty do tego systemu, proszą o katalog PunchOut: link otwierający Państwa sklep z ich systemu zakupowego.

Sesja PunchOut ma cztery etapy:

1. Konfiguracja. Osoba wnioskująca klika katalog w systemie zakupowym. System wysyła do Państwa żądanie konfiguracji z danymi uwierzytelniającymi i adresem zwrotnym.
2. Zakupy. Państwa sklep otwiera się w ich przeglądarce, już zalogowany z rolą tego klienta, z jego katalogiem i cenami kontraktowymi.
3. Zwrot koszyka. Osoba wnioskująca wypełnia koszyk i klika „zwrot” (lub „złóż zamówienie”). Zamiast standardowego procesu składania zamówienia koszyk wraca do systemu zakupowego jako ustrukturyzowany komunikat.
4. Zatwierdzenie i zamówienie. Koszyk przechodzi wewnętrzne zatwierdzanie klienta. Po zatwierdzeniu zamówienie zakupu trafia do Państwa i jest obsługiwane jak każde inne zamówienie.

Dla klienta Państwa sklep staje się częścią procesu zakupowego: widzi aktualne ceny i stany magazynowe, a każde zamówienie podlega jego regułom. Do Państwa zamówienia trafiają z numerem zamówienia zakupu klienta i bez ręcznego wprowadzania danych po obu stronach.

PunchOut a katalog statyczny

Niektórzy klienci proszą też dostawców o statyczny plik katalogu (często CIF lub indeks cXML) ładowany do ich systemu. Te dwa modele się uzupełniają:

Przy niewielkim, stabilnym asortymencie plik może wystarczyć. Przy tysiącach produktów, artykułach konfigurowalnych lub cenach indywidualnych klienci zwykle wolą PunchOut.

Dwa protokoły: cXML i OCI

Każda sesja PunchOut używa jednego z dwóch protokołów, a wyboru dokonuje system klienta. cXML (Commerce eXtensible Markup Language) wymienia dokumenty XML przez HTTPS i jest używany przez SAP Ariba, Coupa, Jaggaer, Ivalua, Oracle, Workday i większość systemów source-to-pay. Przesyła też samo zamówienie zakupu jako OrderRequest. OCI (Open Catalog Interface) to protokół SAP, używany przez SAP S/4HANA, SRM i ECC: sklep jest otwierany z HOOK_URL, a koszyk wraca jako pola formularza HTML o nazwach NEW_ITEM-*. Zamówienie zakupu dociera osobnym kanałem.

Poradnik cXML a OCI porównuje oba protokoły komunikat po komunikacie, z przykładami.

Dlaczego klienci proszą o PunchOut

Z perspektywy klienta PunchOut rozwiązuje jednocześnie trzy problemy. Po pierwsze kontrola: każdy zakup zaczyna się w systemie zakupowym, więc podlega regułom zatwierdzania, budżetom i preferowanym dostawcom. Po drugie dokładność: ceny, kody produktów i opisy pochodzą ze sklepu, więc nikt ich nie przepisuje, a faktury odpowiadają zamówieniom. Po trzecie wygoda osób kupujących: korzystają z prawdziwego sklepu z wyszukiwaniem, filtrami i konfiguracją zamiast statycznej listy.

Dla dostawcy prośba zwykle wiąże się z terminem: nowym kontraktem, umową ramową lub przetargiem wymagającym PunchOut. Dostawcy, którzy potrafią szybko odpowiedzieć, utrzymują klienta; pozostali często są zastępowani konkurentem, który spełnia wymaganie.

Kto uczestniczy

Projekt PunchOut angażuje kilka osób po obu stronach. Wczesne ich wskazanie oszczędza tygodnie:

PunchOut Level 1 i Level 2

Można spotkać dwa poziomy PunchOut. Level 1 otwiera stronę główną sklepu: klient tam wyszukuje i przegląda produkty. Level 2 pozwala szukać w systemie zakupowym, do którego załadowano skrócony indeks produktów, a następnie otwiera sklep bezpośrednio na wybranym produkcie lub kategorii. Level 2 wymaga statycznego indeksu oprócz sklepu działającego na żywo, dlatego warto zapytać klienta o oczekiwany poziom; większość zaczyna od Level 1.

Jakie systemy zakupowe używają PunchOut

Praktycznie wszystkie. SAP Ariba to najczęstsza prośba od dostawców, następnie SAP przez OCI i Coupa. Jaggaer, Ivalua, GEP SMART, Oracle, Workday i dziesiątki narzędzi procure-to-pay dla średnich firm także obsługują PunchOut. Zobacz pełną listę obsługiwanych systemów.

O co poprosi klient

Dział zakupów klienta zwykle wysyła dokumentację dla dostawców lub email wdrożeniowy. Warto przeczytać go najpierw: dokładnie opisuje oczekiwania. Zwykle zostaną Państwo poproszeni o następujące informacje lub je otrzymają:

• Dane uwierzytelniające: dla cXML tożsamości (dla SAP Ariba — Ariba Network ID, czyli ANID obu firm) i shared secret; dla OCI parametry logowania do katalogu.
• Adresy URL: adres konfiguracji udostępniany przez Państwa i adres zwrotny (cXML) lub HOOK_URL (OCI) po stronie klienta.
• Reguły katalogu: produkty i ceny widoczne dla klienta, jednostki miary oraz standard klasyfikacji (UNSPSC lub ECLASS) na określonym poziomie.
• Plan testów: środowisko testowe i terminy testów akceptacyjnych użytkownika (UAT).
• Dokumenty, w przetargach i u dużych klientów: informacje o bezpieczeństwie i hostingu, umowa powierzenia przetwarzania danych, referencje.

Odpowiedzi różnią się według systemu; szczegóły znajdują się na stronach SAP Ariba, SAP OCI i Coupa.

Co zmienia się w sklepie

PunchOut wymaga od sklepu działań, których zwykli internauci nigdy nie wykonują. Typowe blokady to:

• Otwieranie w innej witrynie. Wiele systemów zakupowych pokazuje sklep w ramce lub kontrolowanym nowym oknie. Nagłówki bezpieczeństwa takie jak X-Frame-Options i pliki cookie bez SameSite=None; Secure przerywają sesję. Zobacz poradnik o błędzie iframe.
• Logowanie na właściwe konto klienta, aby widział swój asortyment i ceny kontraktowe bez hasła.
• Zwrot koszyka zamiast standardowego składania zamówienia, w formacie oczekiwanym przez system klienta.
• Dane produktów: jednostki miary mapowane na kody klienta i kod klasyfikacji każdego produktu. Zobacz kategorie PunchOut.
• Odbiór zamówienia: import zatwierdzonego zamówienia zakupu do sklepu.

Wtyczka i bramka PunchOut obsługują te elementy w standardowy sposób, więc obecny sklep, motyw i proces składania zamówień nadal działają dla pozostałych klientów.

Realistyczny plan na 30 dni

Techniczna konfiguracja połączenia PunchOut na obsługiwanej platformie zajmuje godziny, nie tygodnie. Czasu wymaga koordynacja z klientem. Typowy plan:

Kolejka testów klienta wyznacza ostateczny termin: niektóre działy zakupów planują UAT z kilkutygodniowym wyprzedzeniem. Warto wcześnie zapytać o terminy, a przy bliskim terminie rozważyć konfigurację przez specjalistów, np. w ramach Go-Live Assist.

Ile kosztuje PunchOut

Istnieją trzy typowe sposoby spełnienia wymagania PunchOut, o bardzo różnych kosztach:

• Dedykowany projekt integracyjny tworzony przez programistę lub agencję dla sklepu. Płacą Państwo za rozwój i testy każdego protokołu i klienta oraz za utrzymanie po zmianach platformy lub systemu klienta.
• Usługa z opłatą za klienta, zwykle miesięczna opłata za każdego podłączonego klienta plus koszty konfiguracji. Tania dla jednego, droga po dodaniu kolejnych.
• Wtyczka z zarządzaną bramką, jak PunchOut Rocket: stała roczna cena za witrynę. PunchOut Rocket kosztuje 1950 € rocznie dla WooCommerce i 2950 € dla Magento, PrestaShop, nopCommerce lub REST API, z maksymalnie 10 klientami w cenie.

Pełne ceny i kalkulator porównawczy są w cenniku.

Lista kontrolna przed testami klienta

• Dane dostępowe i adresy URL środowiska testowego są skonfigurowane, a sesja testowa działa od początku do końca.
• Klient widzi tylko produkty i ceny uzgodnione w umowie.
• Każdy produkt w asortymencie klienta ma wymagany kod klasyfikacji i jednostkę miary.
• Zwracany koszyk zawiera kody produktów, ceny, ilości i walutę zgodne z oczekiwaniami klienta.
• Wiedzą Państwo, jak dotrze zamówienie zakupu (cXML OrderRequest lub inny kanał uzgodniony z klientem) i kto je obsłuży.
• Mają Państwo kontakt do zespołu klienta na dzień testów, a klient ma kontakt do Państwa.

Typowe pułapki

• Rozpoczęcie od sklepu przed przeczytaniem dokumentacji klienta dla dostawców: często zawiera reguły pól zmieniające konfigurację.
• Testowanie tylko w systemie produkcyjnym klienta: zawsze należy najpierw poprosić o środowisko testowe.
• Pominięcie jednostek miary i klasyfikacji: koszyki są odrzucane, gdy kody nie odpowiadają kodom klienta.
• Niedoszacowanie kalendarza klienta: terminy UAT mogą być dostępne dopiero za kilka tygodni. Warto zarezerwować je po otrzymaniu danych dostępowych.
• Obiecywanie potwierdzeń, awiz wysyłki lub faktur przez cXML bez właściwej opcji: potwierdzenia i awiza wymagają OC & ASN, a faktury są wyceniane na życzenie.