O projekcie
Panel na pulpicie sprzedawcy, w którym powstaje pełna oferta — opis, cechy, zdjęcia, warianty, cena — i z którego jednym przebiegiem trafia na Allegro i na Temu. Przed publikacją każdą ofertę ogląda agent: sprawdza, czy jest kompletna i zgodna z wymaganiami wybranej kategorii, i wypisuje usterki razem z propozycją poprawki.
Rzecz, którą trzeba powiedzieć na wstępie, bo od niej zależy cała reszta: WYSTAWIENIE NA DWIE PLATFORMY TO NIE JEST TA SAMA OFERTA DWA RAZY. Allegro i Temu mają osobne taksonomie, osobne zestawy cech obowiązkowych zależnych od kategorii, inne reguły tytułu, inne wymagania wobec zdjęć i inne obowiązki formalne. Kopiowanie treści z jednej na drugą kończy się albo odrzuceniem, albo ofertą, która przechodzi, ale nie wyświetla się tam, gdzie powinna, bo brakuje jej cech, po których platforma filtruje.
Dlatego w środku jest jeden model produktu, a nie dwie bliźniacze karty. Produkt ma swoje cechy, zdjęcia i warianty raz; adaptery odwzorowują go na taksonomię każdej platformy i dociągają aktualną listę cech obowiązkowych z jej API. To ważne, że z API, a nie z pamięci: kategorie i wymagane parametry zmieniają się po stronie platformy bez uprzedzenia, a lista wpisana kiedyś do kodu jest cichą bombą — działa, dopóki nie przestanie, i wtedy nie wiadomo dlaczego.
Agent stoi przed publikacją, nie po. Sprawdza kompletność cech obowiązkowych dla wybranej kategorii, tytuł pod kątem długości i fraz, których regulamin nie dopuszcza, zdjęcia pod kątem rozmiaru, liczby i tego, czego nie wolno na nich umieszczać, obecność i poprawność numeru GTIN, a także zgodność opisu z cechami — bo opis mówiący „bawełna 100%” przy cesze „poliester” to nie literówka, tylko przyszła reklamacja. Do tego dane producenta i osoby odpowiedzialnej w Unii, których brak potrafi zdjąć ofertę już po wystawieniu.
Agent nie publikuje i nie poprawia po cichu. Wynikiem jest lista usterek z rozdziałem na te, które blokują wystawienie, i te, które są ostrzeżeniem — plus propozycja poprawki przy każdej. Decyzję podejmuje człowiek, bo to jego konto odpowiada za to, co na nim stoi. Model czyta opisy i cechy oraz proponuje uzupełnienia; twarde reguły — długości, formaty, listy dopuszczalnych wartości — sprawdza kod, który da się przetestować i który nie zmienia zdania między jednym uruchomieniem a drugim.
Publikacja jest osobnym problemem i traktowana jest jak operacja, która może się nie udać w połowie. Oferty idą przez kolejkę z limitami zapytań platformy, ponowieniami i stanem zapisanym po każdym kroku — bo wystawienie stu ofert to sto niezależnych rozmów z API, z których część odpowie błędem przejściowym. Każda kończy się wpisem w dzienniku: co poszło, kiedy, z jaką odpowiedzią platformy i jaki identyfikator oferty wrócił.
Pulpit zamiast aplikacji webowej ma dwa powody, oba praktyczne. Klucze API sprzedawcy zostają na jego maszynie, a nie na cudzym serwerze. I zdjęcia — kilkanaście plików na ofertę, każdy w kilku wariantach — nie muszą krążyć w obie strony po sieci, żeby trafić na platformę.
Problem
Ta sama oferta na Allegro i na Temu to dwie różne oferty: inne taksonomie, inne cechy obowiązkowe zależne od kategorii, inne reguły tytułu i zdjęć, inne obowiązki formalne. Sprzedawca dowiaduje się o brakach dopiero po odrzuceniu — a przy wystawianiu setek ofert to nie jest pojedyncza wpadka, tylko stały koszt.
Rozwiązanie
Jeden model produktu w środku i adaptery, które odwzorowują go na obie platformy, z listą cech obowiązkowych dociąganą z ich API. Agent sprawdza ofertę przed publikacją i zwraca usterki blokujące oraz ostrzeżenia, każdą z propozycją poprawki. Publikuje kolejka z limitami, ponowieniami i dziennikiem odpowiedzi.
Funkcje
- jeden produkt w środku, dwie pełne oferty na wyjściu — bez przepisywania
- cechy obowiązkowe dociągane z API kategorii, nie z listy wpisanej do kodu
- kontrola przed publikacją z podziałem na usterki blokujące i ostrzeżenia
- propozycja poprawki przy każdej usterce, decyzja po stronie człowieka
- sprawdzenie zgodności opisu z cechami — sprzeczność to przyszła reklamacja
- GTIN i dane podmiotu odpowiedzialnego pilnowane przed wystawieniem
- publikacja setek ofert w kolejce, odporna na błędy przejściowe platformy
- dziennik: co poszło, kiedy, z jaką odpowiedzią i jakim identyfikatorem oferty
Moduły
mp-produkt
model źródłowyJeden produkt z cechami, zdjęciami i wariantami — wspólne źródło dla obu platform.
- cechy, opis, zdjęcia i warianty utrzymywane raz, niezależnie od platformy
- zdjęcia przygotowywane lokalnie: kadr, rozmiar i warianty pod wymagania każdej platformy
- warianty jako siatka cech, nie jako osobne produkty — rozmiar i kolor nie mnożą kart
- szablony opisu z polami wypełnianymi z cech, żeby opis i cechy nie mogły się rozjechać
mp-adaptery
warstwa platformOdwzorowuje produkt na taksonomię Allegro i Temu wraz z ich cechami obowiązkowymi.
- mapowanie kategorii per platforma, z zapamiętanym wyborem dla kolejnych produktów tego typu
- lista cech obowiązkowych dociągana z API kategorii przy każdym wystawieniu
- reguły tytułu, opisu i zdjęć trzymane osobno dla każdej platformy, nie uśredniane
- zmiana po stronie platformy widoczna jako brak cechy, a nie jako odrzucona oferta
mp-kontroler
agent kontroliOgląda ofertę przed publikacją i zwraca usterki blokujące oraz ostrzeżenia.
- kompletność cech obowiązkowych dla wybranej kategorii
- tytuł: długość, format i frazy, których regulamin nie dopuszcza
- zdjęcia: rozmiar, liczba i to, czego nie wolno na nich umieszczać
- GTIN: obecność, poprawność sumy kontrolnej, zgodność z produktem
- sprzeczność opisu z cechami oraz braki w danych podmiotu odpowiedzialnego
- twarde reguły sprawdza kod; model czyta treść i proponuje uzupełnienia
mp-kolejka
warstwa publikacjiWystawia setki ofert jako operację, która może się nie udać w połowie.
- kolejka z limitami zapytań platformy i ponowieniami błędów przejściowych
- stan zapisywany po każdym kroku — przerwana publikacja wznawia się, nie zaczyna od nowa
- identyfikator oferty zwrócony przez platformę wiązany z produktem w panelu
- dziennik odpowiedzi: co poszło, kiedy i co platforma odpowiedziała
- aktualizacja istniejącej oferty tą samą drogą co wystawienie, bez drugiej ścieżki kodu
Architektura
- Podstawa
- aplikacja desktopowa w TypeScripcie; klucze API i zdjęcia zostają na maszynie sprzedawcy
- Model danych
- jeden produkt źródłowy, dwie oferty wyjściowe — platformy nie mają własnych kopii treści
- Cechy obowiązkowe
- dociągane z API kategorii przy każdym wystawieniu; lista wpisana do kodu byłaby cichą bombą
- Zakres agenta
- sprawdza i proponuje — nie publikuje i nie poprawia bez decyzji człowieka
- Podział kontroli
- twarde reguły (długości, formaty, dopuszczalne wartości) w kodzie; model czyta treść i proponuje
- Publikacja
- kolejka ze stanem po każdym kroku, limitami zapytań i ponowieniami błędów przejściowych
- Zgodność formalna
- GTIN oraz dane producenta i podmiotu odpowiedzialnego pilnowane przed wystawieniem, nie po
- Zdjęcia
- przygotowywane lokalnie do wymagań każdej platformy; nie krążą po sieci w obie strony
- Dziennik
- każde wystawienie i każda aktualizacja z odpowiedzią platformy i zwróconym identyfikatorem
- Aktualizacje
- zmiana oferty idzie tą samą ścieżką co wystawienie — jedna droga kodu zamiast dwóch
Technologie
- TypeScript
- Electron
- SQLite
- REST API
- Claude
Autor
Mariusz PerzyńskiClient Relations & Operations