Feedy XML z hurtowni – synchronizacja stanów i dropshipping

Feed XML z hurtowni to plik, w którym dostawca opisuje swój asortyment: co ma, po ile i ile sztuk zostało na magazynie. Brzmi banalnie, a jest jednym z częstszych źródeł cichych awarii w e-commerce. Sprzedajesz produkt, którego dawno nie ma. Ceny rozjeżdżają się z hurtownią. Połowa oferty znika w nocy, bo przyszedł ucięty plik. Ten wpis jest o tym, jak pracować z feedami tak, żeby to działało w tle i nie budziło Cię telefonem od klienta. Piszemy z perspektywy wdrożeń, w których takie synchronizacje utrzymujemy.

Czym jest feed i skąd się bierze

Hurtownia udostępnia plik pod stałym adresem (URL) albo na serwerze FTP. Twój system pobiera go cyklicznie, czyta i aktualizuje sklep: stany, ceny, czasem nowe produkty i opisy. W modelu dropshipping to serce operacji, bo nie masz własnego magazynu i całkowicie polegasz na tym, co mówi dostawca. Dlatego jakość synchronizacji przekłada się wprost na to, ile zamówień będziesz musiał anulować.

Warto od razu ustalić jedną rzecz: feed to dane wejściowe, a nie prawda objawiona. Traktujesz go jak dane od zewnętrznego systemu, którym nie zarządzasz, więc walidujesz, buforujesz i monitorujesz. Reszta wpisu to konkrety tego podejścia.

Formaty i częstotliwość

Najczęściej spotkasz XML, czasem CSV, rzadziej JSON albo dostęp przez API. XML jest u polskich hurtowni standardem, ale „XML” nie znaczy jeszcze „ten sam format”. Każdy dostawca ma własną strukturę: inne nazwy pól, inne zagnieżdżenie, inny sposób opisania wariantów i cen. Nie ma jednego parsera na wszystkich, każdą hurtownię mapujesz osobno.

Częstotliwość dobierasz do dwóch rzeczy: jak szybko rotuje towar i jak często hurtownia odświeża plik. Ciąganie feedu co pięć minut, gdy dostawca aktualizuje go raz dziennie, to marnowanie zasobów. Odwrotnie, pobieranie raz dziennie przy szybko schodzącym asortymencie to prosta droga do sprzedania czegoś, czego już nie ma. Rozsądny punkt wyjścia to synchronizacja stanów częściej (nawet co kilkanaście minut przy dropshippingu), a pełnego katalogu z opisami rzadziej, bo to cięższa operacja.

Osobno traktujesz pełną synchronizację i aktualizację różnicową. Pełna czyta cały katalog i nadaje się do rzadszego, nocnego przebiegu, bo jest ciężka. Różnicowa aktualizuje tylko to, co się zmieniło, najczęściej stany i ceny, i to ją puszczasz często w ciągu dnia. Rozdzielenie tych dwóch trybów odciąża zarówno Twój system, jak i serwer hurtowni, który też ma limity i nie lubi, gdy ktoś ciągnie od niego pełny plik co pięć minut.

Mapowanie: kategorie, atrybuty, ceny

To etap, na którym feed z pliku staje się Twoją ofertą. Trzy rzeczy wymagają decyzji.

Kategorie. Struktura kategorii hurtowni prawie nigdy nie pasuje do Twojej. Budujesz tabelę mapowania: kategoria dostawcy do Twojej kategorii. Robisz to raz, potem tylko dokładasz nowe pozycje, gdy hurtownia rozszerza asortyment. Bez tego produkty lądują w przypadkowych miejscach albo w ogóle poza drzewem kategorii.

Atrybuty. Kolor, rozmiar, materiał, waga, EAN. Do dopasowywania produktów i wariantów najlepiej opierać się na EAN albo SKU, bo nazwy bywają niespójne. EAN jest też Twoim kluczem, gdy ten sam produkt ciągniesz z dwóch hurtowni naraz.

Ceny. Feed zwykle podaje cenę zakupu netto. Twoją cenę sprzedaży wyliczasz regułą marży (per kategoria, per dostawca albo indywidualnie) i doliczasz VAT. Kluczowe jest oddzielenie danych wejściowych od reguł: hurtownia zmienia cenę zakupu, a Ty zachowujesz kontrolę nad polityką cenową. O pułapkach samego liczenia netto i brutto piszemy osobno w tekście ceny netto i brutto w hurtowni.

Buforowanie stanów magazynowych

Największy błąd dropshippingu to sprzedaż jeden do jednego ze stanem hurtowni. Feed nie jest w czasie rzeczywistym, między jego pobraniem a kolejną aktualizacją inny sklep może wykupić ostatnie sztuki. Dlatego stosuje się bufor bezpieczeństwa: jeśli hurtownia pokazuje 3 sztuki, w sklepie pokazujesz 1 albo 2, żeby nie sprzedać towaru, którego nagle zabraknie.

Drugi mechanizm to progi. Poniżej pewnej liczby sztuk oznaczasz produkt jako niedostępny, zamiast kusić klienta „ostatnia sztuka”, która realnie może już nie istnieć. Bufory i progi ustawiasz różne dla różnych dostawców, bo jedni aktualizują plik co kwadrans, a inni raz dziennie i ich danym trzeba ufać ostrożniej.

Dropshipping: gdzie feed to nie wszystko

W dropshippingu feed jest sercem, ale samo poprawne czytanie pliku nie wystarcza. Dochodzą trzy rzeczy, o których łatwo zapomnieć przy pierwszym wdrożeniu.

Czas dostawy. Feed mówi, czy towar jest, ale rzadko mówi wiarygodnie, kiedy dojedzie. Jeśli sprzedajesz z kilku hurtowni, ten sam produkt może mieć różny czas realizacji zależnie od tego, kto go wyśle. Klientowi trzeba pokazać uczciwy termin, a nie najbardziej optymistyczny.

Wiele źródeł tego samego produktu. Gdy ten sam towar ciągniesz z dwóch dostawców, potrzebujesz reguły: z którego brać, gdy obaj mają stan, i jak się zachować, gdy jeden pokazuje zero. Bez tej reguły stany i ceny zaczynają migotać.

Zwroty i reklamacje. W modelu bez własnego magazynu obieg zwrotu bywa inny niż w klasycznym sklepie. To nie jest problem samego feedu, ale wpada w ten sam proces i trzeba go ułożyć razem z synchronizacją.

Co się psuje

Feedy psują się w powtarzalny sposób. Warto znać te scenariusze, zanim uderzą.

• Kodowanie znaków. Klasyk. Feed w Windows-1250 albo ISO-8859-2 czytany jako UTF-8 zamienia polskie znaki w krzaki. Deklaracja kodowania w nagłówku XML bywa błędna, więc wykrywasz i konwertujesz kodowanie jawnie przy imporcie, zamiast ufać deklaracji.
• Częściowe albo ucięte feedy. Plik przychodzi krótszy niż zwykle (przerwane pobieranie, awaria po stronie hurtowni). Jeśli nadpiszesz stany w ciemno, połowa asortymentu pokaże zero i zniknie ze sprzedaży. Ratunkiem jest walidacja: porównujesz rozmiar i liczbę pozycji z poprzednim importem i wstrzymujesz aktualizację, gdy plik jest podejrzanie mały.
• Zmiana struktury bez uprzedzenia. Hurtownia dodaje pole albo zmienia nazwę węzła i parser się wykłada. Mapowanie musi to znosić łagodnie i zgłaszać, a nie kłaść całego importu.
• Duplikaty i braki EAN. Produkty bez identyfikatora albo z tym samym EAN dla różnych wariantów rozjeżdżają dopasowanie. Reguła obsługi takich przypadków musi być ustalona z góry.

Monitoring: żeby wiedzieć wcześniej niż klient

Synchronizacja bez monitoringu to bomba z opóźnionym zapłonem. Minimum, które warto pilnować:

• Czy każdy feed pobrał się o czasie i czy nie zwrócił błędu.
• Ile pozycji przyszło w porównaniu z poprzednim importem (nagły spadek to sygnał alarmowy).
• Ile produktów zmieniło stan na zero i czy to normalna rotacja, czy skutek zepsutego pliku.
• Alerty, gdy import się nie powiódł albo dane wyglądają podejrzanie, wysyłane do człowieka, zanim zareaguje klient.

Jedna rada z doświadczenia: loguj każdy import z jego wynikiem i trzymaj ten dziennik. Gdy klient zgłosi, że kupił niedostępny produkt, chcesz móc sprawdzić, jaki stan pokazywał feed w momencie zamówienia i o której przyszła ostatnia aktualizacja. Bez tego każda reklamacja to śledztwo bez dowodów, a z tym kilka sekund w logu.

Dobrze poprowadzona synchronizacja feedów jest niewidoczna: towar się zgadza, ceny się zgadzają, a Ty dowiadujesz się o problemie z alertu, nie z reklamacji. To dokładnie ten typ integracji systemów, które wdrażamy i utrzymujemy, często obok połączeń z ERP i narzędziami typu BaseLinker. Jeśli feedy z hurtowni spędzają Ci sen z powiek, automatyzacja procesów jest po to, żeby ten kawałek po prostu działał w tle.