Koszyk PunchOut a zamówienie: czym się różnią?

Użytkownik wybiera produkty w katalogu dostawcy i klika przycisk powrotu do systemu swojej firmy. Pozycje trafiają do aplikacji zakupowej. Z perspektywy zwykłego sklepu wygląda to jak zakończenie zakupów, ale w PunchOut ten moment często dopiero rozpoczyna wewnętrzną akceptację.

Jeżeli dostawca potraktuje taki koszyk jak gotowe zamówienie, może rozpocząć realizację czegoś, czego klient jeszcze nie zatwierdził. Dlatego w integracji trzeba wyraźnie rozdzielić wybór produktów od zlecenia ich dostawy.

Jak przebiega zakup

Typowy scenariusz można podzielić na cztery części:

1. Wejście z platformy zakupowej. System kupującego uruchamia sesję w katalogu dostawcy. Katalog rozpoznaje klienta i udostępnia właściwą ofertę.
2. Kompletowanie koszyka. Użytkownik wybiera produkty w interfejsie dostawcy.
3. Powrót z pozycjami. Wybrane produkty są przekazywane do platformy zakupowej. Mogą posłużyć do utworzenia zapotrzebowania.
4. Dalsze decyzje i zamówienie. Kupujący wykonuje własne kroki, a finalne zamówienie trafia do dostawcy uzgodnionym kanałem.

Szczegóły ostatniego etapu zależą od organizacji klienta. Nie zawsze występuje wielostopniowa akceptacja, ale nie wolno zakładać jej braku tylko dlatego, że powrót koszyka zakończył się poprawnie.

Co oznaczają nazwy komunikatów cXML

W połączeniu opartym na cXML rozpoczęcie sesji wiąże się z PunchOutSetupRequest. Koszyk wraca w PunchOutOrderMessage. Mimo słowa „Order” w nazwie ten drugi komunikat nie jest tym samym co zamówienie zakupu przekazywane przez OrderRequest.

To rozróżnienie jest ważne także w rozmowie z wykonawcą. Zakres „obsługa PunchOut” może obejmować uruchomienie sesji i powrót koszyka, ale nie automatycznie wszystkie komunikaty zamówień, potwierdzeń czy dostaw. OCI ma własne zasady przekazywania danych katalogowych; nie należy przypisywać mu nazw komunikatów cXML.

Przykład: ilość zmienia się po powrocie

Pracownik wybiera 20 opakowań produktu. Koszyk wraca do platformy, ale osoba zatwierdzająca zgadza się na 10. Dla dostawcy podstawą realizacji powinno być finalne zamówienie zgodnie z umówionym procesem, a nie pierwotny wybór pracownika.

Podobny problem dotyczy ceny i dostępności. Między wyborem a zatwierdzeniem może minąć czas. Trzeba ustalić, czy warunki są utrzymywane przez określony okres, czy wymagają ponownej weryfikacji, oraz jak obsłużyć rozbieżność. Sam powrót koszyka nie jest gwarancją rezerwacji towaru.

Jak połączyć oba etapy w danych

Przydatne są identyfikatory pozwalające powiązać sesję, pozycje katalogowe i późniejsze zamówienie. Nie należy opierać takiego powiązania wyłącznie na nazwie produktu lub adresie e-mail użytkownika. Zakres pól i referencji trzeba uzgodnić z odbiorcą.

Osobno zapisuje się statusy: „koszyk przekazany”, „zamówienie odebrane”, „zamówienie przyjęte do realizacji”. Techniczne potwierdzenie otrzymania komunikatu również nie musi oznaczać handlowej akceptacji zamówienia. Znaczenie potwierdzeń powinno wynikać z dokumentacji i umowy procesu.

Ponowne przesłanie koszyka lub zamówienia nie może bez kontroli tworzyć kolejnych dokumentów. W przypadku zamówień potrzebna jest ochrona przed duplikatami, a zmiana zamówienia musi być odróżniana od ponowienia tej samej wiadomości.

Jak odebrać taką integrację

Nie kończ testu na ekranie „koszyk przesłany”. Sprawdź, co rzeczywiście pojawiło się w platformie kupującego, czy można przejść jego ścieżkę akceptacji i co trafia do dostawcy na końcu. Porównaj ilości, jednostki, walutę, ceny oraz identyfikatory pozycji.

Jeżeli odbiór zamówienia nie jest częścią wdrożenia, zapisz to wprost i wskaż, jak firma otrzyma je w innym kanale. Listę materiałów potrzebnych do takich ustaleń znajdziesz w poradniku co przygotować przed wdrożeniem PunchOut lub OCI.

Źródło: cXML.org — dokumentacja standardu i Reference Guide.