Masowe aktualizacje cen: jak zmienić setki cen i nie zwariować

Dostawca wysyła wiadomość, której obawia się każdy właściciel sklepu: ceny rosną o 8% od pierwszego dnia miesiąca. Masz 400 produktów. Otwieranie każdego z nich w panelu administracyjnym PrestaShop, ręczne wpisywanie ceny, klikanie zapisu i czekanie na przeładowanie strony to cały dzień pracy — i dzień, w którym jedna źle wpisana cyfra po cichu sprzedaje produkt za €269 w cenie €26.90. Dobra wiadomość: PrestaShop daje kilka realnych sposobów, by zmienić setki cen naraz. Zła wiadomość: każdy z nich inaczej ingeruje w dane, a zły wybór może rozjechać marże, prezentację podatku albo pliki produktowe szybciej, niż zdążysz powiedzieć „cofnij”. Ten poradnik pokazuje, jak robić to na dużą skalę bezpiecznie — która metoda pasuje do którego zadania i jakie pułapki typowe dla PrestaShop zamieniają szybką aktualizację w weekend sprzątania.

Ostatnia aktualizacja: czerwiec 2026.

Jedną rzecz trzeba ustalić od razu: pod hasłem „zmień moje ceny” kryją się dwa zupełnie różne zadania. Trwałe podniesienie cen bazowych (scenariusz podwyżki u dostawcy) to inna operacja niż uruchomienie tymczasowej wyprzedaży lub promocji. Metody poniżej są uporządkowane według tego, do jakiego zadania zostały stworzone — pomylenie ich to najczęstszy sposób, w jaki sprzedawcy robią sobie bałagan.

Cztery ścieżki — i do czego służy każda z nich

Zanim zaczniesz klikać, uporządkuj mapę. PrestaShop oferuje cztery praktyczne sposoby na zmianę wielu cen naraz, ale nie są one zamienne:

I co z tego? Jeśli sięgniesz po regułę koszyka, gdy tak naprawdę chcesz trwale podnieść ceny bazowe, katalog nadal będzie wszędzie pokazywał starą cenę — na listach produktów, w plikach produktowych, w porównywarkach — a rabat pojawi się dopiero na ostatnim etapie. Jeśli zmienisz ceny bazowe, gdy celem była dwutygodniowa wyprzedaż, wyrzucasz pierwotne liczby i nie masz do czego wrócić. Wybór właściwego wiersza na początku to połowa bezpieczeństwa.

Metoda 1: import/eksport CSV — najpewniejsze narzędzie do trwałych zmian

Przy prawdziwej, trwałej zmianie cen bazowych na setkach produktów CSV jest metodą stworzoną właśnie do tego. Ścieżka importu to Parametry zaawansowane → Import w PrestaShop 1.7, 8 i 9. Uzyskanie początkowego pliku CSV na zewnątrz jest mniej jednolite: przycisk Eksport na liście produktów istnieje w niektórych wersjach i siatkach panelu administracyjnego, ale nie we wszystkich. Jeśli Twoja siatka go nie oferuje, użyj eksportu z bazy danych, webservice albo dedykowanego modułu eksportu. Schemat pracy:

• Najpierw wyeksportuj katalog. W sekcji Katalog → Produkty użyj przycisku Eksport, jeśli siatka produktów w Twojej wersji go udostępnia; jeśli nie, pobierz dane przez eksport bazy danych, webservice albo moduł eksportu. Tak czy inaczej potrzebujesz pliku CSV ze wszystkimi produktami jako obrazu stanu sprzed zmian — zapisz go bez modyfikacji. Jeśli coś pójdzie nie tak, ponowny import tego pliku przywróci stare ceny.
• Edytuj w arkuszu kalkulacyjnym. Najważniejsze kolumny to ID (albo Referencja jako klucz dopasowania), Cena netto oraz opcjonalnie Cena hurtowa, jeśli śledzisz marżę. Aby podnieść wszystko o 8%, jedna kolumna z formułą — =B2*1.08 — obsłuży cały katalog. PrestaShop przechowuje i oczekuje ceny bez podatku; kwota brutto widoczna dla klientów jest wyliczana z reguły podatkowej, dlatego zawsze pracuj na cenach netto i pozwól PrestaShop doliczyć podatek.
• Zaimportuj ponownie z opcją „aktualizuj istniejące”. Wróć do Parametry zaawansowane → Import, wybierz typ encji Produkty, zmapuj kolumny i koniecznie zaznacz „Aktualizuj istniejące produkty” oraz dopasowanie po ID albo Referencji. Jeśli pominiesz to pole, zależnie od mapowania identyfikatorów PrestaShop może utworzyć duplikaty produktów zamiast zaktualizować istniejące (albo po prostu odrzucić wiersze) — to naprawdę bolesny błąd do odkręcania, dlatego najpierw testujesz mały plik.

Krytyczny krok bezpieczeństwa: nigdy nie uruchamiaj od razu pełnego importu. Przytnij CSV do 5–10 produktów, zaimportuj je, potem otwórz w panelu administracyjnym i potwierdź, że ceny trafiły dokładnie tak, jak trzeba — razem z prezentacją brutto. Dopiero gdy ta próbka jest poprawna, uruchom pełny plik. Przesunięty przecinek albo formuła, która złapała złą kolumnę, może ustawić setki cen na €0 albo €999999 w czasie potrzebnym na przeczytanie tego zdania, a import CSV zrobi to bez drugiego ekranu potwierdzenia.

Jedna pułapka typowa dla PrestaShop: standardowy import produktów aktualizuje cenę bazową, ale nie dotyka wpływów cen kombinacji ani cen specyficznych. Jeśli warianty mają własne korekty ceny, zobacz uwagę o kombinacjach niżej.

Metoda 2: ceny specyficzne — do wyprzedaży, nie do trwałych zmian

Jeśli naprawdę chcesz zrobić tymczasową promocję — wiosenną wyprzedaż, czyszczenie magazynu, ceny tylko dla B2B — nie ruszaj cen bazowych. W PrestaShop funkcja ceny specyficznej istnieje dokładnie po to. Możesz zastosować ją masowo przez Katalog → Rabaty (reguły cen katalogu) albo dla pojedynczego produktu w zakładce Cennik:

• Zastosuj rabat procentowy albo kwotowy do całej kategorii, producenta lub dostawcy jedną regułą.
• Ustaw zakres dat od/do, żeby cena wróciła automatycznie — bez przypomnienia w kalendarzu i bez pytania „czy zapomniałem przywrócić ceny?” w poniedziałek po wyprzedaży.
• Kieruj rabat do konkretnej grupy klientów (hurt, próg lojalnościowy), aby był niewidoczny dla wszystkich pozostałych.

Warto tu doprecyzować narzędzie masowe, bo łatwo oczekiwać od niego za dużo: reguła cen katalogu (Katalog → Rabaty → Reguły cen katalogu) tworzy cenę specyficzną dla wycinka katalogu wybranego według waluty, kraju, grupy klientów, producenta, dostawcy, kategorii lub atrybutu — z datą od/do oraz redukcją procentową albo kwotową. To, czego nie robi, to przepisywanie cen bazowych: dokłada rabat na ich wierzchu. Właśnie dlatego to właściwe narzędzie do wyprzedaży i niewłaściwe do trwałej podwyżki od dostawcy. Jeśli uruchomisz regułę cen katalogu, oczekując zmiany cen bazowych, w ps_product nic się nie przesunie — dodasz tylko tymczasową obniżkę, która z czasem wygaśnie zgodnie z datami od/do.

Zysk jest taki, że ceny bazowe zostają nienaruszone. Nie musisz pamiętać, jaka była pierwotna liczba, kalkulacje marży i kosztów pozostają uczciwe, a strona produktu pokazuje właściwe przekreślone „było/teraz”, które sygnalizuje realną okazję. Wiele nakładających się cen specyficznych może współistnieć bez ręcznego śledzenia czegokolwiek. To, czy i jak pokazywać przekreśloną cenę, łączy się bezpośrednio z psychologią cen — omawiamy ją osobno tutaj.

Metoda 3: reguły koszyka — do promocji „X% taniej na wszystko”

Przy prostej promocji obejmującej cały sklep („20% taniej na cały sklep w ten weekend”) jedna reguła koszyka w Katalog → Rabaty → Reguły koszyka jest prostsza niż dotykanie jakiegokolwiek produktu:

• Utwórz jedną regułę, z kodem promocyjnym albo bez niego (zostaw kod pusty, jeśli rabat ma działać automatycznie).
• Ustaw procent i zakres dat; opcjonalnie ogranicz go do wybranych kategorii lub produktów.

Zaletą jest to, że to jeden obiekt — rekordy produktów się nie zmieniają, a całą promocję wyłączasz przez dezaktywację jednej reguły. Jest też kompromis, na którym sprzedawcy często się potykają: reguła koszyka stosuje się w koszyku/finalizacji zakupu, więc rabat nie pojawia się na listach produktów ani na stronie produktu. Klienci widzą pełną cenę aż do koszyka. Jeśli chcesz, aby obniżona cena była widoczna na samej stronie produktu, potrzebujesz ceny specyficznej (Metoda 2), a nie reguły koszyka.

Metoda 4: bezpośredni SQL — szybki, mocny, bezlitosny

Bezpośrednia edycja bazy danych to najszybszy możliwy sposób przesunięcia cen i najłatwiejszy sposób na uszkodzenie sklepu. W Parametry zaawansowane → Baza danych → Menedżer SQL (albo bezpośrednio w bazie danych, jeśli ktoś lubi ryzyko) jedno polecenie wykonuje pracę tysiąca kliknięć:

UPDATE ps_product SET price = price * 1.08 WHERE id_category_default = 5;

Podnosi ono o 8% wszystkie produkty, których domyślna kategoria ma ID 5, mniej więcej w sekundę — ale jest też niekompletne, i to jest pułapka opisana niżej: w każdej instalacji z multisklepem część sklepu widoczna dla klienta czyta cenę z ps_product_shop, więc musisz uruchomić analogiczne polecenie także na tej tabeli, inaczej witryna nadal pokaże stare ceny:

UPDATE ps_product_shop SET price = price * 1.08 WHERE id_category_default = 5;

I nigdzie nie ma przycisku cofania. Zanim uruchomisz cokolwiek, co zapisuje do bazy danych:

• Zrób pełną kopię zapasową bazy danych. To Twoja jedyna droga powrotu. Sam Menedżer SQL Cię nie uratuje — zanim cokolwiek zapiszesz, użyj Parametry zaawansowane → Baza danych → Kopia zapasowa DB (albo prawdziwego zrzutu od hostingu).
• Najpierw uruchom SELECT. Zamień UPDATE...SET na SELECT id_product, price z tą samą klauzulą WHERE i przeczytaj wynik — potwierdź, że trafiasz w te produkty, w które myślisz, i tylko w nie.
• Nie zapomnij o ps_product_shop. To klasyczna pułapka PrestaShop: cena jest przechowywana zarówno w ps_product, jak i w ps_product_shop. W instalacji multisklepowej część sklepu widoczna dla klienta czyta z ps_product_shop, więc aktualizacja samego ps_product nie zmienia niczego, co widzą klienci. Zaktualizuj obie tabele.
• Po wszystkim wyczyść pamięć podręczną. PrestaShop mocno buforuje dane produktów; stare ceny zostają w pamięci podręcznej Smarty i pełnej pamięci podręcznej strony, dopóki ich nie opróżnisz (zobacz checklistę niżej).

Ta ścieżka jest naprawdę dla deweloperów, którzy dobrze znają model danych PrestaShop. Jeśli „ps_product_shop” było dla Ciebie nowością, użyj CSV — jest prawie tak szybkie, a nie potrafi po cichu rozsynchronizować tabel.

Pułapka kombinacji, którą pomija większość masowych aktualizacji

Produkty sprzedawane w wariantach — rozmiarach, kolorach, modelach — przechowują swoje wpływy na cenę osobno, w ps_product_attribute (oraz w ps_product_attribute_shop przy multisklepie). Kiedy podnosisz cenę bazową, wpływ kombinacji pozostaje stały: podbijasz bazę o 8%, a dopłata „XL to +€2” nadal wynosi równe +€2, nie +€2.16. To, czy jest to poprawne, zależy od Twojego sposobu wyceny, ale decyzję trzeba podjąć świadomie — import CSV z cenami bazowymi nie przeskaluje tych wpływów za Ciebie, a zapomnienie o nich sprawia, że „skończona” aktualizacja zostawia połowę wariantów z błędnymi cenami. Jeśli wciąż decydujesz, czy katalog powinien w ogóle używać kombinacji zamiast osobnych produktów, to osobny wybór — opisujemy go tutaj.

Zaokrąglanie: zdecyduj przed importem, nie po nim

Podwyżka procentowa tworzy brzydkie liczby — €24.99 × 1.08 = €26.9892 — a PrestaShop przechowa większą precyzję, niż kupujący kiedykolwiek zobaczy (wyświetlana cena jest ograniczona precyzją waluty i ustawieniami zaokrągleń, więc klientom zwykle nie pokaże się surowe „26.9892”). Mimo to ustal regułę zaokrąglania w arkuszu, przed importem, żeby samodzielnie kontrolować końcową cenę widoczną dla klienta, zamiast liczyć, że platforma ją „posprząta”: zaokrąglaj do .99 przy psychologicznych progach cenowych, do najbliższych .50 dla czytelnych etykiet albo do pełnej kwoty. Ma to znaczenie nie tylko estetyczne, bo konkretny punkt cenowy realnie wpływa na konwersję — psychologia cen to osobny temat, a „26.9892” nikomu nie pomaga.

Uważaj też na kierunek podatku. Ponieważ edytujesz ceny netto, a klienci widzą ceny brutto, wzrost bazy o 8% może dać nieco inną widoczną zmianę zależnie od reguły podatkowej przypisanej do produktu. Po każdej masowej zmianie rzuć okiem na cenę brutto widoczną dla klienta przy kilku produktach, a nie tylko na kwotę w panelu administracyjnym.

Moment i komunikacja podwyżki cen

Poza samą mechaniką podwyżka cen to moment relacji z klientem, a kilka nawyków pomaga ograniczyć utratę zaufania:

• Poinformuj klientów B2B i subskrybentów z wyprzedzeniem — „ceny rosną od 1., zamów teraz po obecnych stawkach” łagodzi zmianę i przesuwa część zamówień wcześniej.
• Uruchom aktualizację w godzinach małego ruchu, żeby jak najmniej klientów przeglądało sklep w chwili, gdy ceny zmieniają się pod nimi.
• Uszanuj koszyki będące już w toku przez krótki okres przejściowy — klient, który dodał produkt po starej cenie i wraca do wyższej podczas finalizacji zakupu, najpewniej porzuci koszyk.
• Odśwież pliki dla porównywarek natychmiast. Nieaktualne ceny w Google Shopping lub porównywarkach sprawiają, że klienci klikają starą, niską cenę i trafiają na wyższą — to uderza w zaufanie i coraz częściej grozi odrzuceniem pliku. Ta sama dyscyplina danych dotyczy statystyk pokazywanych w sklepie, takich jak liczniki sprzedaży i wyświetleń na żywo.

Checklista po aktualizacji

Niezależnie od użytej metody nigdy nie uznawaj masowej zmiany cen za „gotową”, dopóki nie przejdziesz tej listy:

• Ręcznie sprawdź 10–15 produktów z różnych kategorii, od różnych producentów i z różnych przedziałów cenowych.
• Sprawdź zarówno kwoty netto (panel administracyjny), jak i brutto (część sklepu widoczna dla klienta).
• Potwierdź, że ceny kombinacji nadal są poprawne — to pułapka opisana wyżej.
• Wyczyść używane warstwy pamięci podręcznej: pamięć podręczną PrestaShop i pamięć podręczną Smarty, a także każdą pamięć podręczną motywu, modułu, serwera, CDN lub warstwę pełnej pamięci podręcznej strony, z której korzystasz — stare ceny przetrwają w pamięci podręcznej, dopóki jej nie opróżnisz.
• Wygeneruj ponownie pliki produktowe (Google Shopping i wszystkie porównywarki).
• Po kilku dniach przejrzyj raporty finansowe, żeby potwierdzić, że marże trafiły tam, gdzie planowałeś.

Gdy robisz to co miesiąc

Ścieżki CSV i SQL są w porządku przy corocznej podwyżce całego katalogu. Szybko robią się męczące, jeśli stale zmieniasz ceny — sezonowe zmiany u dostawców, wahania walut, strojenie marż według dostawcy. Właśnie tę powtarzalność oraz pułapki kombinacji, zaokrągleń i podatków, które czynią każdy przebieg ryzykownym, usuwa nasz moduł Mass Price Updater. Co dokładnie robi dla Ciebie? Stosuje zmiany procentowe albo kwotowe, wybraną regułę zaokrąglania i selektywny wybór produktów według kategorii, producenta lub dostawcy — z jednego ekranu w panelu administracyjnym, z obsługą tabel kombinacji i multisklepu po stronie modułu, a nie zostawioną jako pułapka. Nie chodzi o samą szybkość: chodzi o to, że operacja, która mogłaby ustawić 400 cen na zero, staje się czymś, co możesz wykonać w przerwie na kawę bez wstrzymywania oddechu.

Najczęściej zadawane pytania

Jaki jest najbezpieczniejszy sposób trwałego podniesienia setek cen bazowych? Import/eksport CSV. Najpierw wyeksportuj katalog i zachowaj ten plik bez zmian jako obraz stanu sprzed aktualizacji, edytuj ceny w arkuszu (jedna kolumna =B2*1.08 robi podwyżkę o 8%), a potem zaimportuj ponownie z zaznaczoną opcją „Aktualizuj istniejące produkty” i dopasowaniem po ID albo Referencji. Zawsze przetestuj 5–10 produktów przed uruchomieniem pełnego pliku — import CSV stosuje zmiany bez ekranu potwierdzenia.

Czy użyć reguły koszyka, ceny specyficznej czy zmienić cenę bazową? Dopasuj narzędzie do zadania. Trwała podwyżka od dostawcy = cena bazowa (CSV albo SQL). Tymczasowa wyprzedaż lub rabat dla grupy = cena specyficzna / reguła cen katalogu, która automatycznie wygasa w dniu zakończenia i pokazuje przekreślone „było/teraz”. Prosta promocja „X% taniej na wszystko” = jedna reguła koszyka, ale pamiętaj, że stosuje się dopiero w koszyku, więc rabat nie pojawia się na listach ani stronach produktów.

Dlaczego moja zmiana cen przez SQL nie pojawiła się w sklepie? Prawie zawsze dlatego, że zaktualizowano ps_product, ale nie ps_product_shop. Cena żyje w obu tabelach, a w instalacji multisklepowej część sklepu widoczna dla klienta czyta z ps_product_shop. Zaktualizuj obie tabele, a potem wyczyść pamięć podręczną PrestaShop i Smarty — stare ceny zostają w pamięci podręcznej, dopóki jej nie opróżnisz.

A co z cenami wariantów (kombinacji)? Import CSV z cenami bazowymi nie skaluje wpływów kombinacji na cenę. Jeśli „XL to +€2”, podniesienie bazy o 8% zostawi tę dopłatę jako równe +€2, a nie +€2.16. To, czy jest to poprawne, zależy od Ciebie, ale musi być świadomą decyzją — wpływy kombinacji żyją w ps_product_attribute (i ps_product_attribute_shop), a zapomnienie o nich sprawia, że „skończona” aktualizacja zostawia połowę wariantów z błędnymi cenami.

Jak podejść do zaokrąglania? Zdecyduj o nim w arkuszu przed importem, nie po nim — zaokrąglaj do .99 przy psychologicznych progach cenowych, do .50 dla czytelnych etykiet albo do pełnych kwot. Potem sprawdź wzrokowo cenę brutto (widoczną dla klienta) na kilku produktach, bo edytujesz ceny netto, a klienci widzą brutto, więc widoczny skok różni się zależnie od reguły podatkowej produktu.

Powiązane moduły i materiały

Jeśli często zmieniasz ceny — sezonowe zmiany u dostawców, wahania walut, strojenie marż — ręczne ścieżki CSV/SQL szybko stają się męczące i ryzykowne. Nasz moduł Mass Price Updater stosuje zmiany procentowe albo kwotowe z wybraną regułą zaokrąglania oraz selektywnym wyborem produktów według kategorii, producenta lub dostawcy z jednego ekranu panelu administracyjnego, obsługując tabele kombinacji i multisklepu po stronie modułu, zamiast zostawiać je jako pułapkę (jawna informacja: to nasz własny moduł PrestaShop). Po każdej masowej zmianie potwierdź, że marże trafiły tam, gdzie trzeba, za pomocą Financial Revolution, i utrzymuj rzetelne liczby w sklepie — nieaktualne ceny podważają wiarygodność Product Sales & Views Live Stats oraz plików produktowych, które czytają klienci i Google.

Niezależnie od wybranej ścieżki zasada w PrestaShop jest ta sama: wiedz, jakie zadanie wykonujesz (trwała cena bazowa kontra tymczasowy rabat), pamiętaj, że cena mieszka w większej liczbie tabel, niż mogłoby się wydawać, testuj na kilku produktach przed właściwą operacją i zachowaj obraz stanu sprzed zmian, żeby „cofnij” zawsze istniało. Zrób to, a zmiana setek cen przestaje być dniem, którego się boisz, i staje się dziesięciominutowym zadaniem, któremu możesz ufać.