Usuwanie zamówień testowych: porządki w PrestaShop przed startem sklepu

Sprawdzone i zaktualizowane w czerwcu 2026 — zweryfikowano w PrestaShop 1.7, 8 i 9 brak natywnej akcji usuwania zamówień oraz reset licznika faktur.

Dzień przed startem baza danych Twojego PrestaShop przypomina miejsce przestępstwa, które sam przygotowałeś. Składałeś zamówienia, żeby sprawdzić ceny przewoźników, dwukrotnie przepuściłeś kartę przez bramkę płatności dla pewności, utworzyłeś konto „asdf asdf”, aby przetestować formularz adresowy, i uruchomiłeś każdy status zamówienia, żeby zobaczyć, czy maile wychodzą prawidłowo. Wszystko zadziałało — i właśnie w tym tkwi problem. Każde z tych zamówień testowych jest już wpisane w statystyki, numerację faktur i listę klientów, a pierwszego poranka prawdziwej sprzedaży będzie po cichu kłamać o kondycji sklepu. Ten poradnik dotyczy jednego konkretnego zadania: czystego usunięcia zamówień testowych przed startem, w sklepie, który nie przyjął jeszcze żadnego prawdziwego zamówienia — bo gdy istnieją już rzeczywiste zamówienia i faktury, PrestaShop celowo utrudnia ich usuwanie ze względów prawnych i księgowych.

Zakres jest celowo wąski. Czyszczenie koszyków, logów i tabel połączeń pod bieżącą wydajność to inna procedura — różnica między „startuję w przyszłym tygodniu” a „moja baza danych rosła przez dwa lata” — i rozdzielamy te tematy, żeby usuwać tylko to, czego faktycznie wymaga start sklepu.

Dlaczego pozostawione zamówienie testowe kosztuje więcej, niż się wydaje

Usunięcie zamówienia może brzmieć jak kosmetyka. Nie jest nią. W PrestaShop zamówienie nie jest jednym rekordem — to mały graf rekordów rozrzuconych po kilkunastu tabelach, z których kilka zasila raporty i liczniki, na których będziesz polegać od pierwszego dnia. Jeśli je zostawisz, konkretnie psują się następujące rzeczy:

• Pierwszy wynik sprzedaży jest błędny, a Ty nie masz jak tego od razu zauważyć. Kokpit i strony Statystyk sumują ps_orders (oraz ps_order_detail), nie wiedząc, które rekordy powstały podczas testowania cen przewoźników. Przychód z pierwszego dnia, średnia wartość zamówienia i współczynnik konwersji są zawyżone przez zamówienia, które nigdy realnie nie miały miejsca, więc dokładnie w chwili, gdy najbardziej potrzebujesz czystego sygnału — „czy nowy sklep rzeczywiście sprzedaje?” — Twoje dane są najmniej wiarygodne.
• Pierwsza prawdziwa faktura ma numer #38. Numery faktur w PrestaShop pochodzą z bieżącego licznika, a nie z zamówienia. Czterdzieści zamówień testowych, które wygenerowały faktury, zużywa czterdzieści numerów, więc pierwsza rzeczywista faktura dla księgowego ma niesekwencyjny numer z połowy trzydziestki i trzydziestu siedmiu niewidocznych poprzedników. To dokładnie taki brak ciągłości, o który pyta kontrola skarbowa.
• Lista klientów jest zaśmiecona fikcyjnymi kontami. „Test User”, „asdf asdf” i Twoje trzy tymczasowe konta leżą w ps_customer obok prawdziwych osób. Każdy segment, eksport i statystyka „liczby klientów” je uwzględnia. Wyeksportuj taką listę do narzędzia mailingowego, a adresy testowe — jeśli użyłeś prawdziwych — dostaną marketingowe wiadomości.
• Stany magazynowe zmieniły się przez sprzedaż, której nigdy nie było. Jeśli zamówienia testowe dotyczyły prawdziwych produktów przy włączonym zarządzaniu stanem magazynowym, każde z nich zapisało rekord w ps_stock_mvt i zmniejszyło ilość. Usuń zamówienie w zły sposób, a ruch magazynowy zostanie, więc stan magazynu w dniu startu będzie po cichu nieprawidłowy. (Uzgodnienie tego to osobne zadanie na danych magazynowych — zobacz zarządzanie magazynem, gdy arkusze kalkulacyjne przestają wystarczać.)

I co z tego? Zamówienie testowe, którego zapomnisz usunąć, nie tylko zaśmieca ekran — psuje trzy rzeczy, które start sklepu ma Ci dać: uczciwą liczbę przychodu, czystą sekwencję faktur i listę klientów, której można ufać. Usunięcie ich to piętnaście minut pracy, dzięki którym dostajesz bazę danych, którą da się naprawdę czytać.

Nie ma prostego przycisku „usuń zamówienie” — i to ma znaczenie

Pierwsze zaskoczenie: natywny PrestaShop (1.7, 8, 9) nie daje w panelu administracyjnym zwykłej akcji usunięcia zamówienia. Zamówienia są traktowane jak dokumentacja finansowa i mają być zachowane ze względu na integralność prawną oraz księgową, dlatego menu akcji masowych i menu wiersza, po które naturalnie sięgniesz, po prostu nie oferują opcji „Usuń” tak jak listy produktów czy klientów. To celowe działanie, nie przeoczenie.

Właśnie dlatego jedynym bezpiecznym momentem na usunięcie zamówień testowych jest czas przed pojawieniem się jakichkolwiek prawdziwych zamówień. Realne opcje są następujące:

• Przywróć czystą kopię zapasową sprzed startu. Najprostszy i najbezpieczniejszy reset: weź migawkę sprzed testów i wróć do niej. Wszystko poniżej zakłada, że wolisz tego nie robić, ale to opcja bez ryzyka osieroconych rekordów.
• Pracuj na bazie testowej. Testuj na kopii, a potem wdroż czystą produkcyjną bazę danych, która nigdy nie widziała zamówienia testowego.
• Użyj dedykowanego modułu lub skryptu do czyszczenia zamówień. Poprawne usunięcie zamówienia oznacza przejście przez cały graf powiązanych rekordów, dlatego to zadanie dla narzędzia przetestowanego na danej wersji, a nie dla ręcznie klikanej akcji administracyjnej. Uruchamiaj je tylko w sklepie z zerową liczbą prawdziwych zamówień.

A nawet gdy zamówienie zostanie usunięte (przez moduł albo przez własną logikę obiektu Order::delete() w PrestaShop), nie czyści wszystkiego, co krąży wokół niego o jeden stopień dalej:

• Klient (ps_customer) i jego adresy (ps_address) — usunięcie zamówienia nigdy nie usuwa osoby, która je złożyła. Fałszywi klienci zostają.
• Źródłowy koszyk (ps_cart, ps_cart_product) — koszyk, który stał się zamówieniem, zostaje jako koszyk „porzucony”.
• Rekord faktury (ps_order_invoice) i licznik numerów faktur — usunięcie zamówienia nie cofa numeru, który został zużyty.
• Każdy ruch magazynowy (ps_stock_mvt) zapisany już dla prawdziwych produktów.

Usunięcie zamówienia jest więc dopiero pierwszym krokiem, a nie całym zadaniem. Schemat, który faktycznie zostawia po sobie porządek, wygląda tak: usuń zamówienia w sklepie przed startem, potem usuń ich klientów i koszyki, a następnie jawnie ustaw kolejny numer faktury. Poniżej znajdziesz deterministyczny opis każdej części.

Czyszczenie przed startem, krok po kroku

1. Najpierw zrób kopię zapasową bazy danych — bez dyskusji. Wykonaj prawdziwy zrzut bazy: narzędziem backupu u dostawcy hostingu, przez phpMyAdmin lub Adminer, albo poleceniem mysqldump, jeśli masz dostęp do powłoki. (Uwaga: Menedżer SQL w Parametrach zaawansowanych służy do uruchamiania zapisanych zapytań na danych, a nie do wykonywania pełnej kopii zapasowej — nie polegaj na nim w tym celu.) Usuwanie zamówień jest destrukcyjne i nie ma cofania. Jeśli cokolwiek poniżej Cię zaskoczy, przywracasz kopię i próbujesz ponownie.
2. Przygotuj ostateczną listę ID zamówień testowych. W Zamówienia → Zamówienia posortuj po dacie i wskaż każde zamówienie sprzed startu. Zanotuj zakres ID — prawie zawsze jest to ciągły blok od początku (od 1 do jakiejś wartości). Pułapką jest tu miękki start: jeśli przyjąłeś już jakiekolwiek prawdziwe wczesne zamówienia, ich ID są wymieszane z testami. Wypisz prawdziwe zamówienia osobno, żeby nigdy nie usunąć płacącego klienta.
3. Usuń zamówienia. Ponieważ natywny PrestaShop nie ma w panelu administracyjnym akcji usuwania zamówień, ten krok wymaga dedykowanego modułu czyszczącego albo małego skryptu wywołującego Order::delete() dla każdego testowego ID — albo, najprościej, przywrócenia czystej kopii zapasowej sprzed startu. Rób to wyłącznie w sklepie bez prawdziwych zamówień.
4. Usuń klientów testowych. Przejdź do Klienci → Klienci, znajdź oczywiście fałszywe konta i usuń je — to usunie również ich adresy. Ponownie uważaj na kupujących z miękkiego startu, których chcesz zachować.
5. Ustaw kolejny numer faktury jawnie na 1. Przejdź do Zamówienia → Faktury i w Opcjach faktur ustaw Kolejny dostępny numer faktury na 1 — zrób to tylko w sklepie, w którym nigdy nie wystawiono prawdziwej faktury, i upewnij się, że nie rozpoczęła się już legalna sekwencja faktur. (To ustawia numer początkowy wprost; nie oczekuj, że ustawienie 0 „automatycznie zacznie od 1”). Zrób to samo z numeracją dokumentów dostawy, jeśli testowałeś dostawy (Zamówienia → Dokumenty dostawy). To krok, o którym zapominają prawie wszyscy, i ten, który zauważy Twój księgowy — ale jeśli prawdziwe faktury już istnieją, zostaw sekwencję w spokoju i sprawdź wymagania księgowe.
6. Wyczyść pamięć podręczną. Parametry zaawansowane → Wydajność → Wyczyść pamięć podręczną. Liczniki i widoki list są cache'owane; bez tego panel administracyjny może nadal pokazywać nieaktualne sumy.
7. Zweryfikuj liczby, a nie swoją pamięć. Otwórz Zamówienia → Zamówienia (powinno być pusto albo powinny zostać tylko prawdziwe zamówienia z miękkiego startu), Klienci oraz kokpit. Jeśli przychód nie wynosi zero (albo nie odpowiada prawdziwej kwocie z miękkiego startu), coś się nie usunęło — wróć do kopii zapasowej i listy, zanim wystartujesz na brudnych danych.

Gdy masz dziesiątki zamówień testowych: ścieżka SQL

Przeklikiwanie pięćdziesięciu zamówień jedno po drugim jest żmudne i podatne na błędy. Jeśli swobodnie pracujesz w Parametry zaawansowane → Baza danych → Menedżer SQL (co jest w porządku przy zapytaniach diagnostycznych tylko do odczytu), możesz przynajmniej precyzyjnie wyznaczyć zakres danych testowych — ale, jak wyjaśnia następna sekcja, samo usuwanie powinno przejść przez sprawdzony kod, a nie ręcznie napisane DELETE. Powód leży w schemacie PrestaShop: wiele tabel nie ma kaskadowych kluczy obcych, więc usunięcie rekordu nadrzędnego najpierw osieroca rekordy podrzędne zamiast je usunąć, a pełny zestaw powiązanych tabel bardzo łatwo zaniżyć.

Najpierw znajdź zamówienia testowe, żeby pracować na rzeczywistych ID, a nie na domysłach. Na przykład wszystko złożone przed datą startu:

SELECT id_order, reference, total_paid, date_add FROM ps_orders WHERE date_add < '2026-06-13 00:00:00' ORDER BY id_order;

Zdecydowanie lepiej pozwolić, aby własna logika Order::delete() w PrestaShop obsłużyła rekordy podrzędne (uruchom ją z małego skryptu dla testowych ID), niż pisać usuwanie ręcznie. Prawdziwe zamówienie PrestaShop dotyka znacznie więcej niż oczywistych kilku tabel — szczegółów i historii zamówienia, ale też przewoźników zamówienia, wiadomości, zwrotów i dokumentów, personalizacji, faktur, podatków oraz rekordów ps_order_payment, które są powiązane przez referencję zamówienia, a nie przez wygodny podrzędny link id_order — plus wszystkich tabel należących do modułów dodanych w Twojej instalacji. Właśnie dlatego ręcznie napisana lista DELETE jest niebezpieczna: każda tabela, o której zapomnisz, zostaje niewidocznym osieroconym rekordem.

Dlatego ten poradnik celowo nie daje częściowego przepisu SQL w stylu „usuń te N tabel w tej kolejności” — taki przepis byłby niekompletny w prawie każdym prawdziwym sklepie. Użyj logiki obiektu (Order::delete()) albo przetestowanego pod daną wersję skryptu czyszczącego, który wylicza każdą powiązaną tabelę, w tym rekordy płatności wyszukiwane po referencji. Następnie osobno posprzątaj satelity — klientów, koszyki i licznik faktur.

I co z tego? Pominięcie powiązanej tabeli to nie pedanteria — jeśli się pomylisz, zostawisz niewidoczne osierocone rekordy, które nadal zanieczyszczają raporty, choć w panelu administracyjnym wygląda to tak, jakby zostały usunięte. To dokładnie ten tryb awarii, któremu ma zapobiec całe ćwiczenie, i dlatego opieramy się na sprawdzonym kodzie, a nie na kopiowanym bloku SQL.

Jedno uczciwe zastrzeżenie: czyszczenie przez truncowanie tabel zamówień (TRUNCATE ps_orders i pokrewnych) to brutalna opcja, którą zobaczysz w internecie. Jest szybka i resetuje identyfikatory auto-increment do 1 — co przed startem sklepu wygląda kusząco — ale omija wszystkie zabezpieczenia, nie dotyka tabel satelitarnych i bez wahania zniszczy zamówienie z miękkiego startu. Rozważaj ją tylko w sklepie bez jakichkolwiek prawdziwych danych i wyłącznie z kopią zapasową, której przywracanie zostało sprawdzone.

Porządkowanie danych demo przy okazji

Zamówienia testowe blokują start, ale jeśli zainstalowałeś PrestaShop z danymi demo, przykładowy katalog jest osobnym problemem przed uruchomieniem — i warto zająć się nim w tej samej sesji. PrestaShop zainstalowany z danymi demo może zawierać przykładowe produkty, kategorie, dostawców, marki i strony CMS (placeholdery typu „Dostawa”, „Informacja prawna”, „O nas”) — dokładny zestaw zależy od wersji, dystrybucji i języka. Pozostawienie ich niesie dwa ryzyka: prawdziwy produkt może przypadkiem znaleźć się w kategorii demo, a Google może zaindeksować stronę „Regulamin”, która nadal jest wypełniona tekstem Lorem ipsum.

Usuń albo przepisz w Katalogu oraz Wygląd → Strony: produkty i kategorie demo oraz placeholdery stron CMS (zastąp je prawdziwymi tekstami prawnymi, nie tylko ukrywaj). Zrób to przez panel administracyjny albo kontrolowany proces importu — nie usuwaj ręcznie plików z /img, bo ten katalog przechowuje obrazy aktywnych produktów, kategorii, marek, dostawców, motywu i systemu, a nie tylko pliki demo. Usunięcie produktów demo przez panel administracyjny czyści ich rekordy obrazów w bezpieczny sposób; jeśli potem chcesz odzyskać miejsce na dysku, regeneruj albo przycinaj nieużywane obrazy tylko z kopią zapasową pod ręką. Jeśli startujesz z dużego katalogu demo i importujesz prawdziwy, czyste wykonanie tego przez CSV to osobne zadanie — zobacz import i eksport produktów w PrestaShop.

Prewencja: nie twórz tego bałaganu następnym razem

Będziesz testować ponownie — przy każdej zmianie motywu, aktualizacji modułu płatności i aktualizacji PrestaShop. Celem jest to, aby przyszłe testy nie zostawiały śladów w danych produkcyjnych:

• Testuj na kopii stagingowej, nie w sklepie produkcyjnym. Duplikat instalacji, w którym każde zamówienie testowe, zwrot i zmiana statusu dzieją się z boku. To największa pojedyncza korzyść: produkcyjne ps_orders zawiera wyłącznie prawdziwą sprzedaż, więc nie ma czego czyścić.
• Używaj trybu sandbox dla płatności. Stripe, PayPal i większość bramek oferują klucz testowy/sandbox, który obsługuje fikcyjne transakcje bez rzeczywistego obciążenia. Testuj ścieżkę finalizacji zakupu bez dotykania prawdziwej karty — i pamiętaj, żeby przed startem przełączyć każdą bramkę z powrotem w tryb produkcyjny (zapomniany klucz sandbox to lustrzany błąd startowy).
• Oznacz nieunikniony test na produkcji. Jeśli musisz testować na produkcji, użyj rozpoznawalnego znacznika — klienta o nazwie ZZ-TEST, dedykowanego wzorca adresu e-mail, notatki w zamówieniu — żeby jeden sortowalny filtr pokazał wszystkie rekordy testowe do usunięcia. Sens wyraźnie oznaczonych zamówień testowych łączy się z ogólną obsługą statusów zamówień; jeśli wielokrotnie testujesz maile statusowe, automatyzację tych przejść omawiamy w dostosowaniu i automatyzacji przepływu statusów zamówień.

Najczęściej zadawane pytania

Jak usunąć zamówienie testowe w PrestaShop?

Natywny PrestaShop (1.7, 8, 9) nie ma w panelu administracyjnym akcji „Usuń zamówienie” — zamówienia są traktowane jak dokumentacja finansowa i celowo zachowywane. Jedyny bezpieczny sposób usunięcia zamówień testowych to zrobić to przed pojawieniem się jakichkolwiek prawdziwych zamówień: przywrócić czystą kopię zapasową sprzed startu, wdrożyć bazę stagingową, która nigdy nie widziała zamówienia testowego, albo uruchomić moduł/skrypt czyszczący przetestowany na danej wersji, który wywołuje Order::delete() dla testowych ID. Najpierw zrób kopię zapasową bazy; usuwanie zamówień jest destrukcyjne i nie ma cofania.

Dlaczego moja pierwsza prawdziwa faktura zaczyna się od numeru 38 zamiast 1?

Numery faktur pochodzą z bieżącego licznika, a nie z zamówienia, więc każde zamówienie testowe, które wygenerowało fakturę, zużyło numer. Po usunięciu testów przejdź do Zamówienia → Faktury → Opcje faktur i ustaw Kolejny dostępny numer faktury na 1 — ale tylko w sklepie, w którym nigdy nie wystawiono prawdziwej faktury. Ustawienie 0 nie sprawi, że system „automatycznie zacznie od 1”; ustaw numer startowy wprost. Jeśli prawdziwe faktury już istnieją, zostaw sekwencję bez zmian.

Czy usunięcie zamówienia usuwa także klienta i koszyk?

Nie. Usunięcie zamówienia nigdy nie usuwa osoby, która je złożyła (ps_customer), ani jej adresów (ps_address), a koszyk, który stał się zamówieniem, zostaje jako koszyk „porzucony” (ps_cart). Nie cofa też licznika numerów faktur ani żadnego zapisanego już ruchu magazynowego. Dlatego usunięcie zamówienia to pierwszy krok, a nie całe zadanie — potem osobno usuwasz klientów testowych i koszyki oraz resetujesz licznik.

Czy mogę po prostu uruchomić zapytanie DELETE albo TRUNCATE na tabelach zamówień?

Unikaj tego. Prawdziwe zamówienie dotyka znacznie więcej niż oczywistych kilku tabel — szczegółów i historii zamówienia, przewoźników, wiadomości, zwrotów, dokumentów, personalizacji, faktur, podatków oraz rekordów ps_order_payment powiązanych przez referencję zamówienia, a nie przez id_order — plus tabel należących do modułów. Ręcznie napisany DELETE, który pominie jedną z nich, zostawia niewidoczne osierocone rekordy, które dalej zanieczyszczają raporty, choć wyglądają na usunięte. TRUNCATE jest szybsze i resetuje ID do 1, ale omija wszystkie zabezpieczenia i zniszczy zamówienie z miękkiego startu. Zamiast tego użyj Order::delete() albo sprawdzonego skryptu czyszczącego. Zapytanie SELECT tylko do odczytu, żeby najpierw znaleźć testowe ID, jest w porządku.

Jak uniknąć takiego bałaganu następnym razem?

Testuj na kopii stagingowej, a nie w sklepie produkcyjnym — wtedy produkcyjne ps_orders zawiera tylko prawdziwą sprzedaż. Do testów płatności używaj trybu sandbox/testowego każdej bramki (i pamiętaj, żeby przed startem przełączyć wszystkie bramki z powrotem na tryb produkcyjny). Jeśli musisz testować na produkcji, oznacz zamówienia rozpoznawalnym znacznikiem (nazwą klienta ZZ-TEST albo dedykowanym wzorcem adresu e-mail), żeby jeden sortowalny filtr pokazał wszystkie rekordy testowe do usunięcia.

Jak to się wpisuje w większy obraz

Usuwanie zamówień testowych to jednorazowa bramka przed startem. Nawyki, które utrzymują bazę zamówień w czystości i wiarygodności po uruchomieniu, są osobną, stałą dyscypliną — poprawianie sporadycznego prawdziwego zamówienia, które wyszło źle, przez edycję zamówień, ponowne wysłanie potwierdzenia klientowi, który je zgubił, przez ponowne wysyłanie potwierdzeń zamówień, wyciąganie czystych danych dla księgowego dzięki eksportom CSV zamówień i faktur oraz codzienna rutyna, która utrzymuje wszystko w ruchu, opisana w przepływach zarządzania zamówieniami, które oszczędzają godziny.

Zasada na dzień startu jest prosta: jedyne zamówienia w bazie danych powinny być tymi, które naprawdę złożył klient. Usuń zamówienia testowe — we właściwej kolejności, ze zresetowanym licznikiem faktur i bezpiecznie odłożoną kopią zapasową — a pierwsza liczba przychodu w sklepie powie Ci prawdę. Potem każdy czysty raport, który czytasz, jest małą nagrodą za piętnaście minut poświęconych teraz. Jeśli uporządkowana baza danych i dokładne statystyki mają znaczenie dla prowadzenia sklepu, właśnie taką zakulisową niezawodność mają chronić nasze moduły PrestaShop.