Synchronizacja cenników między sklepem a systemem sprzedażowym

Dwie ceny tego samego produktu

Rozbieżność między ceną w sklepie internetowym a ceną w systemie sprzedażowym to prosta droga do pomyłek: klient widzi jedną kwotę, dokument sprzedaży pokazuje inną. Przy promocjach i przy sprzedaży dla stałych klientów problem narasta jeszcze szybciej.

Jedno źródło ceny

Podstawowa zasada: cena ustalana jest w jednym systemie i przekazywana do drugiego, a nie wprowadzana ręcznie po obu stronach. Zwykle źródłem jest system sprzedażowy, bo to w nim prowadzone są cenniki i rabaty.

Co synchronizujemy

• Ceny podstawowe i ceny promocyjne wraz z okresem obowiązywania.
• Poziomy cen przypisane do grup klientów.
• Ceny wariantów produktów, jeśli różnią się między sobą.
• Ceny przekreślone, pokazujące wysokość obniżki.
• Koszty wysyłki i progi darmowej dostawy.

Ceny dla zalogowanych klientów

Sklepy sprzedające również hurtowo wymagają przekazywania poziomów cen przypisanych do konkretnych kontrahentów. To bardziej złożona konfiguracja, ale usuwa konieczność prowadzenia dwóch osobnych cenników.

Promocje czasowe

Ustawiane wyłącznie po stronie sklepu wymagają ręcznego pilnowania po stronie systemu. Ustawiane w jednym miejscu z datą początku i końca — działają same. To najczęstszy powód, dla którego promocja obowiązuje dzień dłużej, niż miała.

Kontrola

Po wdrożeniu porównujemy ceny wybranych produktów w obu systemach, także w wariantach promocyjnych.

Rozbieżności nie zawsze dotyczą ceny podstawowej

Problem może występować tylko w określonym kanale sprzedaży, grupie klientów albo wariancie produktu. Cena podstawowa widoczna dla niezalogowanego użytkownika bywa poprawna, podczas gdy po zalogowaniu pojawia się nieaktualny poziom cenowy. Innym wariantem jest zgodna cena produktu głównego i błędna cena jednego rozmiaru, koloru lub opakowania zbiorczego. Dlatego sprawdzenie pojedynczej karty produktu nie wystarcza do oceny całej integracji.

Osobną grupę tworzą rozbieżności wynikające z rabatów. Rabat może być zapisany jako stała cena, wartość odejmowana od ceny podstawowej albo reguła procentowa. Są to różne mechanizmy, mimo że dla klienta końcowy wynik może wyglądać podobnie. Integracja powinna jednoznacznie określać, czy przekazuje gotową cenę po rabacie, czy zestaw reguł potrzebnych do jej obliczenia.

Różnica może też dotyczyć sposobu prezentowania kwot brutto i netto. Cena brutto zawiera podatek, a cena netto jest wartością przed jego doliczeniem. Jeżeli jeden system przekazuje cenę netto, a drugi interpretuje ją jako brutto, błąd pojawi się na całej grupie produktów. Konfiguracja musi zatem wskazywać rodzaj przesyłanej ceny oraz zasady jej wyświetlania w sklepie.

Identyfikacja produktu i wariantu

Synchronizacja wymaga poprawnego powiązania tych samych pozycji w obu systemach. Najczęściej służy do tego identyfikator, czyli unikalne oznaczenie rekordu, albo symbol produktu używany w firmowej kartotece. Sama nazwa nie jest bezpiecznym kluczem powiązania. Może zostać zmieniona, zawierać dodatkowy opis albo występować w kilku podobnych wersjach.

Szczególnej uwagi wymagają warianty. Sklep może przechowywać każdy wariant jako osobną pozycję, podczas gdy system sprzedażowy zapisuje produkt główny i jego cechy. Integracja musi wtedy przetłumaczyć jedną strukturę danych na drugą. Błędne mapowanie, czyli przypisanie pól lub rekordów do niewłaściwych odpowiedników, może spowodować zamianę cen między wariantami mimo prawidłowej transmisji danych.

Przed uruchomieniem automatycznej wymiany warto wykryć duplikaty, produkty bez symbolu oraz pozycje usunięte tylko w jednym systemie. Taki przegląd ogranicza ryzyko, że nowa cena trafi do podobnego, ale innego produktu. Istotne jest również ustalenie, co ma się wydarzyć po dodaniu nowego wariantu: czy zostanie powiązany automatycznie, czy będzie oczekiwał na sprawdzenie.

Kolejność stosowania rabatów i promocji

W sklepach obsługujących sprzedaż detaliczną i hurtową kilka reguł może dotyczyć tego samego produktu jednocześnie. Klient może należeć do grupy z własnym cennikiem, posiadać dodatkowy rabat i kupować produkt objęty promocją czasową. Trzeba wtedy ustalić priorytet, czyli kolejność rozstrzygania konkurujących reguł.

Możliwe jest wybranie najniższej dostępnej ceny, zastąpienie ceny grupowej ceną promocyjną albo naliczenie rabatu od wcześniej obniżonej kwoty. Każdy z tych modeli daje inny wynik. Nie należy zakładać, że sklep internetowy i system sprzedażowy domyślnie wykonują obliczenia w tej samej kolejności. Zasada powinna zostać opisana, skonfigurowana i sprawdzona na przykładach obejmujących nakładające się warunki.

Znaczenie mają także daty obowiązywania. Systemy mogą inaczej interpretować godzinę rozpoczęcia promocji, strefę czasową lub brak wpisanej godziny zakończenia. Strefa czasowa określa, według jakiego czasu system odczytuje zapisaną datę. Niespójna konfiguracja może uruchomić albo zakończyć ofertę w nieplanowanym momencie, mimo że sama cena została przesłana poprawnie.

Synchronizacja natychmiastowa i cykliczna

Dane mogą być przekazywane po każdej zmianie albo w ustalonych cyklach. Pierwszy model korzysta często ze zdarzenia, czyli informacji wysyłanej po zapisaniu nowej ceny. Drugi uruchamia zadanie okresowe, które pobiera zmiany partiami. Wybór zależy od możliwości obu systemów, liczby produktów oraz sposobu prowadzenia sprzedaży.

Przy synchronizacji cyklicznej trzeba uwzględnić opóźnienie między zapisaniem ceny źródłowej a jej publikacją. Nie każda chwilowa różnica oznacza awarię. Może być naturalnym skutkiem oczekiwania na kolejne wykonanie zadania. Jeżeli jednak proces nie zapisuje czasu ostatniej udanej wymiany, odróżnienie opóźnienia od zatrzymanej integracji staje się trudne.

Przy wymianie natychmiastowej potrzebna jest obsługa ponowień. Ponowienie oznacza kolejną próbę przesłania danych po chwilowym błędzie połączenia lub niedostępności systemu. Próba nie może jednak tworzyć sprzecznych wpisów ani cofać nowszej ceny. Pomaga w tym znacznik czasu zmiany lub numer wersji rekordu, dzięki któremu można rozpoznać, która informacja jest aktualna.

Błędy podczas ręcznego poprawiania cen

Najczęstszą reakcją na rozbieżność jest poprawienie kwoty bezpośrednio w sklepie. Taka zmiana może usunąć widoczny objaw, ale nie naprawia przyczyny. Przy kolejnym uruchomieniu integracji cena ze źródła może ponownie nadpisać ręczną korektę. Powstaje wtedy wrażenie, że system samoczynnie przywraca błędne dane.

Ryzykowne jest również zmienianie kierunku wymiany bez sprawdzenia dotychczasowych reguł. Jeżeli sklep zacznie zapisywać ceny w systemie sprzedażowym, można nadpisać poprawny cennik danymi, które miały być jedynie prezentowane klientom. Przed taką zmianą trzeba ustalić właściciela danych, czyli system odpowiedzialny za tworzenie i zatwierdzanie konkretnej informacji.

Innym błędem jest masowy import pliku bez sprawdzenia identyfikatorów, separatorów i formatu liczb. Separator dziesiętny oddziela część całkowitą kwoty od części ułamkowej. Jego błędna interpretacja może zmienić wartość lub spowodować odrzucenie rekordu. Przed pełnym importem potrzebna jest próba na ograniczonym, dobrze rozpoznanym zestawie produktów.

Nie należy też usuwać historii błędów przed ustaleniem przyczyny. Log, czyli techniczny dziennik działania programu, może wskazać produkt, czas operacji i etap, na którym wymiana została przerwana. Sam komunikat wymaga interpretacji, ale pozwala odróżnić błąd danych od problemu z połączeniem lub uprawnieniami.

Kiedy problem nie wynika z synchronizacji cennika

Poprawna cena w panelu sklepu i nieaktualna kwota na stronie mogą wskazywać na pamięć podręczną. Pamięć podręczna przechowuje wcześniej przygotowaną wersję strony, aby szybciej ją wyświetlić. W takim przypadku dane dotarły do sklepu, lecz klient nadal otrzymuje starszy widok. Trzeba wtedy sprawdzić mechanizm odświeżania strony, a nie ponownie wysyłać cennik.

Różnica między kartą produktu a koszykiem może wynikać z reguły rabatowej naliczanej dopiero po spełnieniu warunku, na przykład po zalogowaniu lub osiągnięciu określonego progu zamówienia. Jeżeli cena zmienia się dopiero na dokumencie sprzedaży, przyczyną może być sposób przypisania kontrahenta, waluty albo rodzaju dokumentu. Nie jest to automatycznie dowód, że transmisja ceny została zerwana.

Trzeba też odróżnić błąd cennika od błędu przypisania podatku, jednostki miary lub wielkości opakowania. Cena za sztukę może wyglądać na inną niż cena za komplet, mimo że oba systemy przechowują prawidłowe wartości. Diagnoza obejmuje zatem nie tylko samą kwotę, lecz także kontekst, w którym jest stosowana.

Jak kontrolować poprawność po wdrożeniu

Test powinien obejmować produkty reprezentujące różne zasady sprzedaży. Warto uwzględnić pozycję bez promocji, produkt przeceniony, wariant z osobną ceną, ofertę dla zalogowanej grupy oraz przypadek, w którym kilka reguł obowiązuje jednocześnie. Dla każdej pozycji porównuje się wartość źródłową, dane zapisane w sklepie, cenę widoczną na stronie, kwotę w koszyku i wynik na dokumencie.

Kontrola powinna objąć również zmianę i cofnięcie zmiany. Pozwala to sprawdzić, czy system poprawnie publikuje nową wartość, a następnie usuwa nieaktualną promocję lub przywraca cenę podstawową. Istotne są także produkty wyłączone ze sprzedaży oraz nowe pozycje, których wcześniej nie było w obu bazach.

Przydatny jest raport wyjątków, czyli zestawienie rekordów, których nie udało się przetworzyć. Raport nie powinien ograniczać się do ogólnej informacji o błędzie. Powinien umożliwiać rozpoznanie produktu i przyczyny odrzucenia danych. Dzięki temu pojedyncza niezgodna pozycja nie pozostaje niezauważona tylko dlatego, że pozostała część cennika została przesłana.

Dodatkowe pytania o wymianę cen

Czy ceny można zmieniać zarówno w sklepie, jak i w systemie sprzedażowym?

Technicznie bywa to możliwe, ale wymaga jasnych reguł rozwiązywania konfliktów. Konflikt powstaje, gdy ta sama cena została zmieniona niezależnie po obu stronach. Bez wskazania systemu nadrzędnego jedna aktualizacja może nadpisywać drugą. Bezpieczniejszy model przewiduje jedno miejsce edycji oraz kontrolowany przepływ do pozostałych kanałów.

Czy każda promocja musi być przechowywana w systemie sprzedażowym?

Nie zawsze. Niektóre akcje mogą być realizowane wyłącznie przez sklep, szczególnie gdy zależą od zawartości koszyka lub kodu rabatowego. Trzeba jednak określić, która wartość ma później trafić na dokument sprzedaży. Jeśli system sprzedażowy nie zna mechanizmu promocji, powinien przynajmniej otrzymać prawidłową cenę końcową lub rabat zapisany w obsługiwanej postaci.

Co zrobić, gdy tylko część produktów ma nieaktualne ceny?

Najpierw sprawdza się cechy wspólne tych pozycji: brak identyfikatora, konkretną kategorię, osobny poziom cenowy, warianty albo datę ostatniej modyfikacji. Częściowa niezgodność częściej wskazuje na problem z mapowaniem lub danymi produktu niż na całkowite zatrzymanie połączenia. Ważne jest zachowanie przykładów przed ręcznym poprawieniem kwot.

Czy po zmianie ceny trzeba odświeżać cały katalog?

Nie zawsze. Integracja może przekazywać tylko rekordy zmienione od ostatniego poprawnego wykonania. Pełna synchronizacja bywa potrzebna po zmianie reguł, naprawie mapowania albo dłuższej przerwie, ale nie powinna być pierwszą reakcją na każdy pojedynczy błąd. Przed jej uruchomieniem trzeba sprawdzić kierunek wymiany i zakres danych, które mogą zostać nadpisane.

Jak rozpoznać, że promocja zakończyła się poprawnie?

Należy sprawdzić nie tylko usunięcie ceny promocyjnej z karty produktu. Kontrola obejmuje przywrócenie właściwej ceny podstawowej, brak dawnej obniżki w koszyku oraz prawidłową kwotę na nowym dokumencie sprzedaży. Warto też upewnić się, że stara wersja strony nie jest nadal podawana z pamięci podręcznej.

Spójny cennik wymaga kontroli całej drogi ceny

Skuteczna synchronizacja nie kończy się na przesłaniu liczby z jednego pola do drugiego. Obejmuje identyfikację produktu, rodzaj ceny, kolejność rabatów, terminy promocji, obsługę błędów oraz sposób prezentacji danych klientowi. Dopiero sprawdzenie całej drogi — od zapisu w systemie źródłowym po koszyk i dokument sprzedaży — pozwala potwierdzić, że ten sam produkt rzeczywiście ma właściwą cenę na każdym etapie zamówienia.