Zamówienia z pliku i przez API: jak duzi klienci chcą kupować

Mały klient hurtowy chce wygodnego sklepu. Duży klient nie chce sklepu w ogóle. Jego dział zakupów pracuje we własnym systemie ERP i oczekuje, że zamówienie z tego systemu trafi do Ciebie bez przepisywania, a potwierdzenie i faktura wrócą tą samą drogą. Jeśli tego nie umiesz, kupi u dostawcy, który umie. Poniżej cztery sposoby, w jakie duże firmy chcą kupować, od najprostszego do najbardziej wymagającego.

Dlaczego duży klient nie chce klikać w sklepie

W dużej firmie zakup to proces, nie czynność. Zapotrzebowanie powstaje w systemie, przechodzi akceptację, zamienia się w zamówienie z numerem, a faktura musi do tego numeru pasować, inaczej księgowość jej nie zapłaci. Każde ręczne przepisanie między systemami to ryzyko błędu i czas pracownika. Dział zakupów woli dostawcę, u którego zamówienie z ich systemu trafia prosto do realizacji, nawet jeśli jest kilka procent droższy.

Dla Ciebie to szansa: klient, który zintegrował się z Twoim systemem, nie zmienia dostawcy z powodu drobnej różnicy w cenie, bo zmiana oznacza kolejny projekt integracyjny. Lojalność wynika z wygody, nie z ceny.

Poziom 1: zamówienie z pliku CSV

Klient ma listę zakupów w Excelu: symbol, ilość, czasem swoja nazwa i numer zapotrzebowania. Sklep udostępnia stronę, na której wgrywa plik, a system dopasowuje symbole do produktów, pokazuje ceny, dostępność i problemy (symbol nieznany, ilość niezgodna z opakowaniem) i tworzy koszyk. Klient sprawdza, poprawia i składa zamówienie.

Co musi umieć dobry import

• Dopasowanie po Twoim symbolu, kodzie EAN i symbolu klienta (klient często ma własne kody, które możesz zapisać w jego koncie jako mapowanie).
• Tolerancja na format: separator przecinek lub średnik, nagłówek lub bez, spacje w symbolach, kropka lub przecinek w liczbach.
• Czytelna lista problemów przed dodaniem do koszyka, z możliwością poprawienia na stronie, bez wgrywania pliku od nowa.
• Zaokrąglanie do jednostek opakowania z informacją, co zostało zmienione.
• Pole na numer zamówienia klienta, który potem trafia na fakturę i WZ.

To rozwiązanie wdrażamy prawie zawsze jako pierwsze, bo załatwia 80% potrzeb średnich klientów, a zajmuje dni, nie tygodnie. Import CSV jest też dobrą „furtką” dla dużych klientów, zanim powstanie pełna integracja.

Poziom 2: zamówienia przez API

System klienta łączy się bezpośrednio z Twoim sklepem: pobiera katalog z cenami dla tego klienta i dostępnością, składa zamówienie, odbiera potwierdzenie z numerem, odpytuje o status i numer przesyłki, pobiera fakturę. Bez człowieka po żadnej stronie.

PrestaShop 9 wprowadził Admin API oparte na API Platform, a starsze wersje mają Webservice. Oba dają dostęp do produktów, klientów i zamówień, ale są zaprojektowane dla administratora sklepu, nie dla klienta. Dlatego w praktyce budujemy warstwę API pod klienta: osobne klucze dostępu per klient, widoczność tylko własnych cen i zamówień, uproszczone operacje („złóż zamówienie z listy symboli”), limity zapytań i dziennik wywołań. Ta warstwa korzysta z mechanizmów PrestaShop, ale odsłania klientowi tylko to, co powinien widzieć.

Operacja	Co dostaje system klienta	Uwagi
Pobranie katalogu	produkty, symbole, EAN, ceny klienta, dostępność, jednostki	przyrostowo, tylko zmiany od ostatniego pobrania
Sprawdzenie dostępności	stan i termin dla listy symboli	przed złożeniem zamówienia, w czasie rzeczywistym
Złożenie zamówienia	numer zamówienia, pozycje potwierdzone i odrzucone	z numerem zamówienia klienta i adresem dostawy
Status zamówienia	etap, numer przesyłki, data wysyłki	odpytywanie lub powiadomienie (webhook)
Faktura	PDF i dane strukturalne	z numerem zamówienia klienta

Poziom 3: EDI

EDI (elektroniczna wymiana danych) to wymiana standardowych dokumentów handlowych między systemami według ustalonego formatu i przez ustalony kanał. Typowy obieg: klient wysyła zamówienie (ORDERS), Ty odsyłasz potwierdzenie (ORDRSP), przed wysyłką awizo (DESADV), po wysyłce fakturę (INVOIC). Każdy dokument ma ściśle określoną strukturę, a klient oczekuje, że będzie się jej trzymać co do pola.

EDI wymagają przede wszystkim sieci handlowe i duże korporacje produkcyjne. Jeśli dostajesz od klienta „specyfikację EDI” na kilkadziesiąt stron, to właśnie to. W praktyce wdraża się je przez operatora EDI (firmę, która tłumaczy dokumenty między formatami i dostarcza je obu stronom) albo bezpośrednio, co ma sens tylko przy kilku dużych klientach o tym samym standardzie. Po Twojej stronie dokumenty EDI muszą trafiać do ERP, nie do sklepu: zamówienie EDI tworzy zamówienie w Subiekcie czy Optimie, a faktura EDI powstaje z faktury z ERP.

Kiedy EDI się opłaca

Gdy klient tego wymaga i jego obroty uzasadniają koszt operatora i wdrożenia, albo gdy kilku klientów używa tego samego standardu. Dla jednego klienta ze średnimi obrotami zwykle lepiej zaproponować API lub import CSV i wrócić do EDI, gdy relacja urośnie.

Poziom 4: punchout

Punchout spotkasz w korporacjach korzystających z platform zakupowych. Działa tak: kupiec w swoim systemie klika „katalog dostawcy X”, zostaje przeniesiony do Twojego sklepu z automatycznym logowaniem i swoimi cenami, składa koszyk, a zamiast płacić, klika „wróć do systemu”. Koszyk wraca do jego systemu, przechodzi tam akceptację i dopiero potem przychodzi do Ciebie jako zamówienie, często przez EDI lub API.

Dla Ciebie oznacza to dwie rzeczy: sklep musi umieć przyjąć sesję punchout (zalogować kupca na podstawie przekazanych danych i oddać koszyk w wymaganym formacie), a zamówienie przychodzi później, innym kanałem, więc koszyk z punchout nie jest zamówieniem i nie może rezerwować towaru. Punchout wdrażamy wyłącznie na życzenie konkretnego klienta, z jego specyfikacją w ręku.

Integracja z ERP klienta: od czego zacząć

Duży klient nie kupuje w Twoim sklepie. Kupuje w swoim systemie. Twoim zadaniem jest sprawić, żeby Twoja oferta była w tym systemie widoczna, a zamówienie wracało do Ciebie bez przepisywania.

Pytania, które słyszymy najczęściej

Czy Admin API w PrestaShop 9 wystarczy, żeby dać klientowi dostęp?

Jako fundament tak, jako gotowe rozwiązanie nie. Admin API jest dla administratora i daje dostęp do całego sklepu. Klient potrzebuje własnych kluczy, własnych cen i ograniczonego zakresu, co wymaga warstwy pośredniej.

Ile kosztuje wdrożenie EDI?

Zależy od operatora, liczby dokumentów i klientów. Policz to osobno dla każdego klienta, który wymaga EDI, i porównaj z jego rocznym obrotem. Konkretne widełki naszych prac są w cenniku.

Czy import CSV nie jest „za prosty” dla dużego klienta?

Dla działu zakupów korporacji tak, ale dla oddziałów i kierowników, którzy dziś wysyłają zamówienia mailem, jest ogromnym krokiem naprzód. Zacznij od niego, a API lub EDI dodaj dla tych, którzy faktycznie o nie proszą.

Co z zamówieniami przez API w kontekście stanów i rezerwacji?

Zamówienie przez API rezerwuje towar tak samo jak złożone w sklepie i wchodzi do tego samego obiegu w OMS i ERP. Koszyk z punchout nie rezerwuje, bo nie jest jeszcze zamówieniem.