Pobieranie ofert i synchronizacja cen

Pobieranie ofert — marketplace do nas

Żądania pobrania trafiają do kolejki pobrań, przetwarzanej co minutę. Osobny mechanizm co kilka godzin planuje pobrania zbiorcze.

Pozycje mają priorytet — od krytycznego po tło — oraz źródło: czy ktoś kliknął ręcznie, czy poszło z harmonogramu, czy jest to weryfikacja po zmianie ceny.

Tryby pobrania

• pełne — cały listing,
• przyrostowe — tylko zmiany,
• pojedyncza oferta,
• tylko ceny — dostępne wyłącznie dla części kanałów,
• tylko stany,
• dopasowanie ofert do produktów.

Zadanie pobrania i jego stan

Każde uruchomienie tworzy zadanie ze statusem, licznikami i sygnałem życia. Dzięki temu zadanie, które padło w połowie, da się odróżnić od tego, które po prostu długo trwa.

Zadania bez sygnału życia są uznawane za zawieszone i cyklicznie sprzątane. Jeśli widzisz zadanie „w trakcie" od wielu godzin — sprzątanie się nim zajmie, ale to sygnał, że coś po stronie kanału nie odpowiada.

Ceny — od nas do marketplace'u

Zmiana ceny produktu trafia do kolejki cen, przetwarzanej co minutę, a stamtąd do kolejki zmian widocznej przy ofertach (Zmiany i alerty — kolejka wypychania oraz rozbieżności stanu).

Konfiguracja cenowa jest osobna dla każdej pary kanał + kraj i to na niej siedzi przełącznik automatycznej synchronizacji, jego tryb i częstotliwość. Jest tam też Tryb testowy, pozwalający zobaczyć, co poleciałoby, bez wysyłania.

To ustawienie nie jest ustawieniem połączenia. Automatyczna synchronizacja cen włącza się na konfiguracji cenowej, nie w formularzu integracji. Szukanie jej wśród ustawień połączenia to częsta pomyłka — i częsta przyczyna „ceny nigdy nie poszły".

Empik: cena wysyłana razem z całą ofertą

Empik (Mirakl) przy zmianie oferty nadpisuje każde pole, którego nie dostanie — stan spada do zera, trwająca promocja znika. Dlatego zmiana ceny na Empiku najpierw odczytuje ofertę z Empiku i odsyła ją w całości, zmieniając tylko cenę (a przy promocji — rabat). Zmiana zwykłej ceny w trakcie promocji zostawia promocję. Jeśli Empik odrzuci cenę szybko (np. poniżej minimum kategorii), zmiana kończy się błędem z powodem od Empiku — widać go w kolejce zmian przy ofercie. Gdy Empik przetwarza import dłużej, o wyniku decyduje późniejsza weryfikacja: porównuje cenę widoczną na Empiku, ale bez powodu odrzucenia.

Oferty z cenami per kanał albo z progami ilościowymi rabatu nie są zmieniane — wysłanie ich bez tych danych skasowałoby je. Taka zmiana kończy się błędem z prośbą o zmianę w panelu Empiku.

W trakcie promocji Empik pokazuje w polu ceny kwotę po rabacie. Pobieranie ofert zapisuje ją jako cenę promocyjną, a jako zwykłą — cenę sprzed rabatu.

Oferty bez kraju

Kanały jednorynkowe (PrestaShop, Allegro) zapisują oferty bez kraju, nawet gdy w konfiguracji cenowej wybrano kraj. To, która konfiguracja je wycenia, ustawiasz w ustawieniach połączenia, na etapie cen: Oferty bez kraju: która konfiguracja cen je wycenia.

• Automatycznie (domyślnie) — konfiguracja bez kraju, a gdy jej nie ma, jedyna aktywna konfiguracja połączenia, także z ustawionym krajem.
• Kraj (np. PL) — konfiguracja cen tego kraju. Lista pokazuje tylko kraje, dla których połączenie ma aktywną konfigurację.
• Nie synchronizuj — ceny ofert bez kraju nie są wysyłane (powód countryless_offers_off).

Gdy nie da się wskazać konfiguracji — „Automatycznie” przy kilku konfiguracjach krajowych i żadnej bez kraju albo kraj bez aktywnej konfiguracji — oferta jest pomijana z powodem offer_country_unknown.

Konfiguracja ma też zabezpieczenia ograniczające skalę jednorazowej zmiany — chronią przed wypchnięciem błędnego cennika na cały asortyment.

Netto czy brutto — jedna baza przed porównaniem

Nie każdy kanał trzyma cenę w tej samej bazie podatkowej. PrestaShop zapisuje w products.price cenę netto i sam dolicza VAT z grupy reguł podatkowych produktu; Ceneo raportuje brutto; większość marketplace'ów konsumenckich nie deklaruje nic i cena jest brana tak, jak przyszła. Po naszej stronie o bazie grupy cenowej mówi pole Baza ceny źródłowej (netto / brutto) na konfiguracji cenowej.

Gdy obie strony deklarują różną bazę, system przelicza cenę oferty do bazy WMS po stawce VAT zapisanej przy ofercie (pobranej razem z ceną — w PrestaShopie z reguł podatkowych produktu dla domyślnego kraju sklepu, ustawienie Domyślny kraj sklepu). Dotyczy to wszystkich miejsc naraz:

• lista i szczegóły oferty — przy cenie marketplace widać jej bazę (np. 1300,80 zł netto) oraz przeliczenie ≈ 1599,98 zł brutto; kolumna Δ Cena i filtr rozbieżności liczą się od przeliczonej kwoty, więc oferta netto 1300,80 przy grupie brutto 1599,99 to zgodność, a nie „‑19 %". Znak „≈" jest celowy: sklep trzyma cenę z sześcioma miejscami po przecinku, a Noxti zapisuje ją do grosza, więc po przeliczeniu może brakować grosza — różnica do jednego grosza liczy się jako zgodność (w liście, w filtrach eq/ne/gt/lt i w przebiegu),
• przebieg synchronizacji — porównuje w bazie WMS, a do kanału wysyła kwotę w bazie kanału (do PrestaShopu idzie netto, choć w grupie jest brutto); progi i limity obniżki/podwyżki liczą się po przeliczeniu,
• zlecenie zmiany przy ofercie — zapisuje kwotę i bazę, w jakiej kanał ją dostanie.

Oferta bez stawki VAT (PrestaShop nie odpowiedział na /tax_rules, klucz webservice nie ma uprawnień do /taxes) przy różnych bazach nie jest porównywana: szczegóły oferty pokazują ostrzeżenie zamiast „Ceny zgodne", filtr rozbieżności ją pokazuje, a przebieg pomija ją z powodem Brak stawki VAT do przeliczenia netto/brutto (tax_basis_unknown). Lek to odświeżenie ofert po nadaniu kluczowi uprawnień — nie ręczne wpisanie ceny.

PrestaShop: rozmiary mają jedną cenę — cenę modelu

W sklepie z rozmiarami każda oferta PrestaShop to kombinacja (id w postaci 129018-1306: model + rozmiar). Cena kombinacji w PrestaShopie to tylko dopłata do ceny modelu, więc Noxti zmienia cenę modelu — jedna zmiana przestawia naraz wszystkie jego rozmiary. Szczegóły oferty takiego rozmiaru mówią to wprost.

Przebieg synchronizacji pilnuje, żeby to było bezpieczne:

• na model idzie jedno aktywne zlecenie zmiany — niezależnie od źródła: ręcznie, zbiorczo czy z automatyzacji. Drugie zlecenie dla innego rozmiaru tego samego modelu, zanim pierwsze się wykona, jest odrzucane; pozostałe rozmiary są pomijane z powodem Objęte zmianą ceny modelu — to nie błąd, ich cena zmieni się razem z modelem,
• jeśli rozmiary modelu mają w grupie cenowej WMS różne ceny, model jest pomijany z powodem Rozmiary modelu mają różne ceny w WMS — jednej ceny modelu nie da się z nich ustalić; wyrównaj ceny rozmiarów w katalogu,
• jeśli któryś rozmiar jest wykluczony z synchronizacji, pomijany jest cały model (Rozmiar modelu jest wykluczony z synchronizacji) — zmiana i tak by go przestawiła,
• jeśli w panelu sklepu rozmiary mają ustawione dopłaty (różne ceny per rozmiar), zlecenie jest odrzucane z opisem, które kombinacje mają dopłatę — Noxti ich nie nadpisuje,
• próg „poniżej kosztu” liczy się od najdroższej ceny zakupu spośród rozmiarów modelu — cena modelu obejmuje je wszystkie,
• jeśli oferta pobrana jako zwykły produkt dostała w sklepie rozmiary, zlecenie jest odrzucane z prośbą o ponowne pobranie ofert — inaczej zmiana przestawiłaby wszystkie nowe rozmiary,
• jeśli integracja wysyła cenę do kolumny wholesale_price, zmiana ceny rozmiaru jest odrzucana — w tej kolumnie kombinacja ma własną cenę, nie dopłatę, więc zmiana ceny modelu jej nie obejmuje.

Cena, którą klient widzi na sklepie, może się jeszcze różnić od przeliczonej — PrestaShop nakłada na nią własne ceny specyficzne (promocje, rabaty procentowe). Noxti nimi nie zarządza; taką różnicę trzeba usunąć w panelu sklepu.

Co przebieg porównuje — tylko zmienione czy wszystkie ceny

Domyślnie przebieg bierze tylko to, co zmieniło się w katalogu od ostatniego razu (kolejka cen). Cena poprawiona ręcznie po stronie marketplace'u albo rozjazd sprzed włączenia synchronizacji nie trafi do kolejki i nie zostanie wyrównany.

Przełącznik Porównuj wszystkie ceny, nie tylko zmienione na konfiguracji cenowej zmienia to: przebieg czyta cały katalog — każdy produkt z ofertą na tym kanale — porównuje cenę z grupy cenowej z ostatnią znaną ceną oferty i wysyła różnice. Katalog przechodzony jest stronami („Limit / cykl" produktów na przebieg) i pozycja jest pamiętana, więc:

• przebieg automatyczny (co interwał) robi jedną stronę na tick i po kilku tickach obchodzi cały katalog,
• Wyślij ceny teraz w tym trybie zaczyna od początku katalogu i idzie stroną po stronie do końca — jedno kliknięcie sprawdza wszystko, także grupę promocyjną, jeśli jest ustawiona. Drugie kliknięcie w trakcie zostanie odrzucone: przebieg już trwa.

Porównanie idzie do ostatniej pobranej ceny oferty, nie do żywego zapytania na marketplace — jest tak świeże jak ostatnie pobranie ofert tego kanału. Progi, limity obniżki/podwyżki i ochrona ceny zakupu działają tak samo jak przy zmianach z kolejki.

Postęp przebiegu na żywo

Na etapie Ceny, pod przyciskiem Wyślij ceny teraz, każda konfiguracja ma kartę przebiegu. W trakcie pokazuje etap (kolejka / katalog), pasek postępu z pozycją w katalogu, liczbę stron i liczniki: wysłane zmiany, pominięte — z podziałem na powody (cena bez zmian, poniżej progu, obniżka ponad limit, poniżej kosztu, brak oferty…) — i błędy. Po zakończeniu karta zostaje jako wynik ostatniego przebiegu. Karta z napisem Przestał odpowiadać to przebieg, który nie ruszył się od pół godziny — przetwarzanie zostało przerwane; kolejne kliknięcie zacznie nowy.

Dwa komunikaty na karcie tłumaczą przebieg, który wygląda na pusty:

• Nie porównano żadnej ceny — konfiguracja wysyła tylko zmienione ceny, a w katalogu nic się nie zmieniło od ostatniego razu. „Wysłane 0, pominięte 0" nie znaczy wtedy, że ceny się zgadzają. Włącz Porównuj wszystkie ceny, nie tylko zmienione, zapisz i kliknij Wyślij ceny teraz,
• Czeka w kolejce — przebieg czeka na zakończenie pobierania ofert innego kanału. Ruszy sam; ponowne kliknięcie nic nie przyspieszy.

Gdzie sprawdzić, które ceny poszły

Na integracji, etap Ceny. Ten sam zestaw liczników co przy stanach:

• Ostatnia wysłana cena — kiedy naprawdę coś doleciało do kanału,
• Wysłane (24 h) — ile zmian kanał przyjął,
• W kolejce — ile czeka; obok wiek najstarszej pozycji, bo to on mówi, czy kolejka stoi,
• Pominięte (24 h) — ile pozycji zamknięto bez wysyłki.

Niżej lista ostatnich zmian: produkt, cena była/jest, status i powód pominięcia.

Zielony status ostatniego przebiegu nie znaczy, że cena poszła. Mówi tylko, że przebieg się zakończył. Kolejka cen nie ma statusu „błąd" — pozycja, której nie dało się wysłać, kończy jako pominięta z powodem (najczęściej „brak pasujących ofert albo poniżej progu"). Licznik „wysłane" liczy się z kolejki zmian przy ofertach, nie z kolejki cen, właśnie po to, żeby tej różnicy nie zamazać.

Trzy stany, które wyglądają spokojnie, a znaczą „nic tu nie poleci", panel nazywa wprost:

• żadna konfiguracja nie może wysyłać — nie ma takiej, która jest jednocześnie włączona, wskazuje zwykłą grupę cenową i jest skierowana do kanału. Sama grupa promocyjna albo kierunek „z kanału do katalogu" to za mało — ręczne „Wyślij ceny teraz" też takiej odmówi,
• ceny nie są wysyłane automatycznie — konfiguracja mogłaby wysłać, ale przełącznik automatu jest wyłączony; zmiany rosną w kolejce i idą dopiero po ręcznym wysłaniu,
• tryb testowy — przebieg porównuje katalog z kanałem i nie wysyła nic.

Liczniki obejmują grupy cenowe, na których sprzedaje ten kanał — kolejka cen nie wie nic o kanałach. Jeśli tę samą grupę ma drugi kanał, panel to napisze: ta sama zmiana liczy się obu.

Przetworzone pozycje kolejki są sprzątane po 7 dniach, więc starszych zmian tam nie znajdziesz. Historię pojedynczego produktu daje wyszukiwarka po EAN w konsoli synchronizacji.

Kolejność przy podłączaniu kanału

1. Pobierz oferty.
2. Dopasuj je do produktów (Powiązanie oferty z produktem — bez niego nic nie jedzie).
3. Sprawdź mapowanie magazynu (Mapowania — magazyny, kurierzy, cenniki, kategorie).
4. Dopiero teraz włącz wysyłkę stanów i cen.

Odwrotna kolejność kończy się wysyłaniem stanów donikąd.