Katalog sprzedawcy

Problem#

Katalog marketplace wygląda jak katalog sklepu z dodatkowym polem na sprzedawcę. Różnica jest głębsza: produkt ma właściciela, który nie jest operatorem, może istnieć równolegle w cudzym systemie i podlega moderacji, zanim stanie się widoczny.

Każda z tych trzech rzeczy osobno jest prosta. Razem przesądzają o tym, czy za rok da się podpiąć sklep sprzedawcy bez przepisywania katalogu.

Minimalna wersja#

• Produkt należy do sprzedawcy i bez tej relacji nie może istnieć.
• Produkt ma stan: roboczy, oczekujący na akceptację, opublikowany, wycofany.
• Warianty są osobnymi rekordami, nawet gdy produkt ma dziś jeden wariant.
• Kategoria decyduje o tym, jakie informacje są wymagane do publikacji.

Czego nie budować teraz#

• Katalogu kanonicznego, w którym oferty wielu sprzedawców podpinają się pod jeden wspólny produkt. To osobny produkt sam w sobie i ma sens dopiero przy realnym problemie z duplikatami.
• Dopasowywania po kodach kreskowych i globalnej deduplikacji.
• Generatora formularzy z dziesiątkami pól technicznych. Wymagaj tego, co blokuje publikację, resztę zostaw opcjonalną.
• Wersjonowania każdej zmiany produktu. Historia cen tak, pełna historia edycji dopiero przy sporze.

Zaplanuj z góry#

Trzy identyfikatory zamiast jednego#

Jeżeli istnieje choćby plan podpięcia sklepów sprzedawców, produkt potrzebuje miejsca na trzy rzeczy naraz: własny identyfikator, oznaczenie systemu źródłowego i identyfikator w tamtym systemie. Wrzucenie tego do jednego pola ogólnego przeznaczenia działa do momentu, w którym ten sam sprzedawca podepnie drugi sklep.

To samo dotyczy wariantu. Mapowanie na poziomie produktu nie wystarczy, bo synchronizacja stanów odbywa się na wariancie.

Źródło prawdy jako decyzja, nie skutek uboczny#

Dla każdego pola, które może przyjść z zewnątrz, musi być rozstrzygnięte, kto wygrywa: platforma czy system źródłowy. Najczęściej cena i opis zostają po stronie platformy, a stan magazynowy po stronie źródła. Ważne, żeby to była decyzja zapisana w modelu, a nie zachowanie wynikające z kolejności zapisów.

Dane zgodności przy produkcie, nie w opisie#

Informacje wymagane przez przepisy mają być polami, po których da się filtrować i sprawdzić kompletność. Wklejone w opis nie dadzą się wyegzekwować, a to one blokują publikację.

Wyzwalacze#

• pierwszy sprzedawca pyta, czy może zaciągnąć produkty ze swojego sklepu;
• ten sam produkt pojawia się u dwóch sprzedawców i kupujący to zauważa;
• pierwsza kategoria z wymaganiami dokumentowymi;
• moderacja produktów zaczyna zajmować więcej czasu niż akceptacja sprzedawców;
• sprzedawca prosi o masową zmianę cen albo stanów.

Następny etap#

Po pierwszym wyzwalaczu: mapowanie identyfikatorów i import jednorazowy. Po drugim: dopiero wtedy rozmowa o katalogu wspólnym, i to raczej jako grupowanie ofert niż pełna kanonizacja. Po piątym: import zbiorczy z pliku, zanim zbudujesz cokolwiek czasu rzeczywistego.

Częste błędy#

Co się sprawdza w praktyce#

Najwięcej późniejszej pracy oszczędziło mi rozdzielenie identyfikatora wariantu w platformie od identyfikatora w systemie źródłowym. Kiedy pojawiła się druga integracja, mapowanie było już na właściwym poziomie i nie trzeba było niczego odtwarzać.

Odwrotnie zadziałało odkładanie decyzji o tym, które informacje mają twardo blokować publikację. Dopóki brak danych był tylko ostrzeżeniem, niekompletne oferty trafiały do sprzedaży i wracały jako praca do nadrobienia na już istniejącym katalogu.

Checklista#

• Produkt nie może istnieć bez sprzedawcy.
• Warianty są osobnymi rekordami od pierwszego dnia.
• Produkt i wariant mają miejsce na identyfikator z systemu zewnętrznego wraz z oznaczeniem tego systemu.
• Dla każdego pola z zewnątrz wiadomo, kto jest źródłem prawdy.
• Informacje wymagane przepisami są polami, nie fragmentem opisu.
• Brak wymaganej informacji blokuje publikację.