Finansowa rewolucja: zaawansowane raportowanie dla właścicieli sklepów PrestaShop

Ostatnia weryfikacja: czerwiec 2026, poniższe ścieżki pól w panelu administracyjnym i nazwy tabel dotyczą PrestaShop 1.7, 8 i 9; etykiety menu różnią się nieznacznie między wersjami, więc dokładne nazwy w Twoim panelu mogą być inne.

PrestaShop bez problemu pokaże Ci, ile udało się sprzedać. Otwórz Statystyki (kontroler AdminStats, w menu Kokpit / Statystyki, zależnie od wersji), a zobaczysz sprzedaż w czasie, najlepiej sprzedające się produkty, podział według przewoźników, pulpit sprzedaży i zamówień oraz sortowalną listę bestsellerów. Żaden z tych ekranów nie pokaże jednak jednej liczby, która decyduje, czy Twój sklep naprawdę jest biznesem: ile pieniędzy faktycznie zostaje u Ciebie. Przychód to wartość, którą PrestaShop mierzy domyślnie. Zysk to wartość, którą realnie zabierasz do domu, a te dwie liczby rozjeżdżają się znacznie bardziej, niż zakłada większość sprzedawców. Ten wpis jest o zamknięciu tej luki: o raportowaniu finansowym, którego sklep PrestaShop potrzebuje, aby zarządzać marżą zamiast obrotem, o tym, co daje panel administracyjny, gdzie się kończy i jak dojść do rzeczywistego zysku na produkt, zamówienie i klienta.

Najpierw jedna granica, żeby ten tekst pozostał przy swoim temacie. To jest raportowanie finansowe, pieniądze wpływają, pieniądze wypływają, coś zostaje. To nie jest analityka internetowa. Skąd przychodzą odwiedzający, jak zachowują się na stronie, które źródło ruchu konwertuje, to osobna dziedzina, którą omawiamy w tekstach co śledzić, a co ignorować oraz metryki GA4, które naprawdę mają znaczenie. Tutaj zostajemy przy rachunku zysków i strat.

Dlaczego natywne statystyki PrestaShop nie powiedzą Ci, czy sklep jest rentowny

Natywny silnik statystyk jest zbudowany wokół przychodu i wolumenu, bo właśnie te dane są uporządkowane w tabelach zamówień. Gdy PrestaShop zapisuje sprzedaż, przechowuje cenę zapłaconą przez klienta, podatek, koszt wysyłki naliczony klientowi oraz status zamówienia. Nie przechowuje natomiast, w żadnej użytecznej formie raportowej, ile to zamówienie kosztowało Ciebie. Ten koszt jest rozproszony po miejscach, których ekrany Statystyk nigdy nie łączą:

• Cena hurtowa. PrestaShop ma na nią pole, wholesale_price w produkcie, ustawiane w Katalog → Produkty → [produkt] → Ceny → Cena kosztu, zapisywane w ps_product i kopiowane do ps_order_detail.original_wholesale_price w momencie sprzedaży. Problem polega na tym, że prawie nikt go nie uzupełnia, a nawet gdy jest uzupełnione, natywne miejsca, w których się pojawia, wskaźnik marży w Statystyki → Statystyki katalogu oraz kolumna zysku na produkt w Statystyki → Najlepiej sprzedające się produkty / Szczegóły produktu, pokazują widoki uśrednione albo zagregowane po produkcie, nigdy po pojedynczym zamówieniu czy kliencie.
• Opłaty za obsługę płatności. 1,4–3%, które zatrzymuje Stripe, PayPal albo operator kart, w ogóle nie trafia do PrestaShop. Zamówienie na 100 € jest zapisane jako 100 € przychodu, choć na Twoje konto wpływa 97,10 €.
• Rzeczywisty koszt wysyłki. Zamówienie przechowuje to, ile klient zapłacił za wysyłkę, nigdy to, ile przewoźnik naliczył Tobie. Zaoferuj darmową dostawę, a natywne podsumowanie pokaże przychód z wysyłki równy zero i koszt równy zero, mimo że kurierowi zapłaciłeś 6 €.
• Zwroty i reklamacje. Zwrócone zamówienie nadal może mieć status wliczany do „ważnego” przychodu, zależnie od konfiguracji statusów zamówień, po cichu zawyżając sprzedaż na górze rachunku.

Dlatego natywna liczba „Marża zysku” wystarcza najwyżej do szybkiej kontroli kierunku, ale nie do podejmowania decyzji. Nie powie Ci, który z dwóch produktów promować, bo nie widzi, że jeden niesie ze sobą 2 € opłaty kartowej i 30% zwrotów, a drugi sprzedaje się bez tych obciążeń.

Przychód to najbardziej myląca liczba w Twoim sklepie

Porównajmy dwa sklepy PrestaShop. Sklep A robi 50 000 € obrotu miesięcznie; sklep B robi 20 000 €. Natywny pulpit sprawia, że A wygląda na oczywistego zwycięzcę. Teraz dodajmy koszty, których PrestaShop nie śledzi: A sprzedaje elektronikę na niskiej marży, ma 12% zwrotów, płaci 1,9% prowizji kartowej i dopłaca do wysyłki; B sprzedaje produkty własnej marki z marżą 60% i prawie bez zwrotów. Po policzeniu realnych liczb B zostawia sobie więcej euro każdego miesiąca. Sprzedawca patrzący tylko na natywny ekran Statystyk optymalizowałby dokładnie zły sklep.

To cały sens raportowania finansowego w jednym przykładzie. Metryki, które naprawdę poruszają sklep, są drugiego rzędu, istnieją dopiero wtedy, gdy odejmiesz koszt od przychodu:

• Marża brutto na produkcie, cena sprzedaży minus cena hurtowa, minus opłata płatnicza, dopłata do wysyłki oraz proporcjonalny narzut kosztów przypisany do tej pozycji. Produkt, który wygląda jak bohater listy bestsellerów, czasem po uwzględnieniu opłat i zwrotów po cichu traci pieniądze.
• Kontrybucja na zamówieniu, kwota, którą pojedyncze zamówienie zostawia po swoich kosztach zmiennych. Dwa zamówienia po 80 € nie są równe, jeśli jedno wysłano za darmo na drugi koniec kraju, a drugie odebrano w punkcie.
• Zysk według segmentu klientów, połączenie wartości klienta w czasie z kosztem jego pozyskania. Relacja między tym, ile klient jest wart, a ile kosztuje jego zdobycie, to osobny temat; nie będziemy go tutaj wyprowadzać od nowa, dane o wartości klienta kontra koszcie pozyskania omawiamy w tekście co śledzić, a co ignorować.
• Rzeczywisty wskaźnik zwrotów według produktu i kategorii, 30% zwrotów to nie bestseller, tylko wada produktu albo mylący opis, który zjada marżę dwa razy: płacisz za wysyłkę do klienta, ponosisz koszt odesłania, a towaru możesz już nie sprzedać ponownie.

Co możesz dziś uzyskać z PrestaShop, i ściana eksportów

Zanim sięgniesz po cokolwiek dodatkowego, warto dokładnie wiedzieć, jak daleko zaprowadzi Cię sam system, bo przy małym katalogu może to wystarczyć.

W tym ostatnim wierszu kończy większość sprzedawców, eksportują zamówienia do arkusza, ręcznie doklejają cenniki prowizji i faktury za wysyłkę, a potem co miesiąc odtwarzają tę samą tabelę przestawną. Raz to działa. Jako cotygodniowy nawyk już nie, a raport uruchamiany dopiero wtedy, gdy coś Cię niepokoi, wykrywa problemy o miesiąc za późno. Uczciwy natywny limit wygląda tak: PrestaShop potrafi pokazać przychód na pulpicie oraz koszt tylko wtedy, gdy przekopiesz się przez Menedżera SQL z własnymi zapytaniami. Połączenie tych danych w stały, planowany raport z możliwością wejścia w szczegóły zysku to ściana, przez którą panel administracyjny Cię nie przeprowadza.

Jeśli dobrze czujesz się w Menedżerze SQL, naprawdę możesz dojść daleko, zapytanie łączące ps_orders, ps_order_detail i original_wholesale_price da Ci rzeczywistą marżę brutto na zamówieniu. Tego, czego nie zrobisz tam łatwo, to włączenie zewnętrznych danych kosztowych (cennika prowizji Stripe, faktur od przewoźnika), zaplanowanie raportu albo przekazanie go nietechnicznej osobie z zespołu. To właśnie granica między sprytnym zapytaniem a systemem raportowym.

Zapytanie Menedżera SQL, które daje rzeczywistą marżę brutto na zamówieniu

Oto zapytanie startowe, które możesz wkleić w Zaawansowane parametry → Baza danych → Menedżer SQL. Sumuje przychód każdego zamówienia względem ceny hurtowej zapisanej w momencie sprzedaży, dzięki czemu otrzymujesz marżę brutto na zamówieniu, czyli rzecz, której natywne ekrany Ci nie pokażą. Dostosuj prefiks tabel (ps_), jeśli u Ciebie jest inny, oraz filtr ważnych zamówień do swoich statusów:

SELECT
    o.id_order,
    o.reference,
    o.total_paid_tax_excl                              AS revenue_excl_tax,
    SUM(od.product_quantity * od.original_wholesale_price) AS cost_of_goods,
    o.total_paid_tax_excl
        - SUM(od.product_quantity * od.original_wholesale_price) AS gross_margin,
    ROUND(
        100 * (o.total_paid_tax_excl
            - SUM(od.product_quantity * od.original_wholesale_price))
        / NULLIF(o.total_paid_tax_excl, 0)
    , 1)                                               AS margin_pct
FROM ps_orders o
JOIN ps_order_detail od ON od.id_order = o.id_order
WHERE o.valid = 1
GROUP BY o.id_order
ORDER BY gross_margin ASC;

Dwa uczciwe zastrzeżenia. To tylko marża brutto, odejmuje koszt towaru, ale nie opłaty za płatność, rzeczywistego kosztu wysyłki ani zwrotów, bo PrestaShop ich nie przechowuje (i o to właśnie chodzi w tym artykule). Jest też tak prawdziwa, jak Twoje dane w original_wholesale_price: zamówienia złożone wtedy, gdy pole kosztu było puste, pokażą 100% marży i zniekształcą listę. Sortowanie rosnące (gross_margin ASC) umieszcza najgorsze zamówienia na górze, czyli zwykle dokładnie tam, gdzie warto spojrzeć najpierw.

Od danych do decyzji: co zmienia się, gdy widzisz zysk

I co z tego? Celem nie jest ładniejszy pulpit, chodzi o to, że cztery codzienne decyzje przestają być zgadywaniem:

• Ceny. Podniesienie ceny o 5% na produkcie ze zdrową marżą i stabilnym popytem jest spokojną decyzją, gdy widzisz jego obecną rzeczywistą marżę obok trendu sprzedaży. Bez kosztów w tle ta sama decyzja jest rzutem monetą.
• Co promować. Raportowanie zysku regularnie przestawia kolejność bestsellerów. Lider wolumenu i lider zysku często są różnymi produktami, a miejsce na stronie głównej, budżet reklamowy i oferty pakietowe chcesz kierować na ten drugi.
• Magazyn. Decyzje o uzupełnieniu, wycofaniu albo wyczyszczeniu zapasu powinny wynikać z marży, nie z wolumenu. Wolno rotujący produkt z marżą 65% może zasługiwać na większą widoczność; szybko rotujący przy 4% może wymagać podwyżki ceny albo cichego wycofania.
• Strategia rabatowa. Błyskawiczna promocja, która zapisuje 10 000 € przychodu, ale po rabacie, opłatach i wysyłce zostawia 500 € zysku, nie jest sukcesem sugerowanym przez wykres przychodów. Raportowanie z uwzględnieniem marży mówi Ci to następnego ranka, a nie na koniec kwartału.

Domknięcie luki z modułem Financial Revolution

Dokładnie po to istnieje nasz moduł Financial Revolution: bierze przychód, który PrestaShop już zapisuje, pozwala uchwycić koszty i wydatki, których platforma w ogóle nie śledzi, i zamienia wynik w stały widok rachunku zysków i strat w panelu administracyjnym, bez comiesięcznego arkusza i bez ręcznego SQL-a. Co konkretnie dzięki temu zyskujesz?

• Rzeczywisty widok rachunku zysków i strat, nie tylko pulpit przychodów, przychód, zapisane przez Ciebie koszty i wydatki operacyjne, podatek/VAT oraz wynikowy zysk, rozbite według kategorii, dzięki czemu widzisz wynik, który naprawdę zostaje u Ciebie, a nie sam obrót.
• Śledzenie kosztów i wydatków, na które PrestaShop nie ma miejsca, zapisuj koszty i narzuty, których platforma nigdy nie przechowuje (opłaty operatorów płatności, rzeczywista wysyłka, wydatki operacyjne), i automatycznie odejmuj je od przychodu zamiast doklejać je w arkuszu.
• Przepływy pieniężne, podatki i VAT w jednym miejscu, ruchy cash-flow, raporty podatkowe i VAT, faktury oraz korekty obsługiwane w panelu administracyjnym zamiast ręcznego uzgadniania po fakcie.
• Działa w Twoim panelu, czytasz raport w back office w tym samym cotygodniowym rytmie, w którym sprawdzasz zamówienia, zamiast eksportować i budować wszystko od nowa; gdy trzeba przekazać liczby księgowości, masz eksport CSV.

Uczciwa granica: moduł raportowy raportuje, nie ustawia cen za Ciebie i nie zwraca prowizji kartowych. Jego zadaniem jest sprawić, by prawdziwej liczby nie dało się przeoczyć, abyś to Ty mógł na niej działać. A będzie tak dokładny, jak dane kosztowe, na których się opiera. To prowadzi do następnego punktu.

Zadbaj o wiarygodność: najpierw uzupełnij dane kosztowe

W raportowaniu finansowym obowiązuje zasada: śmieci na wejściu, śmieci na wyjściu. Najczęstszy powód, dla którego raport zysku wygląda źle, to puste pola kosztów. Zanim zaufasz jakiejkolwiek marży, natywnej albo z modułu, wykonaj mniej efektowną pracę u podstaw:

• Uzupełnij cenę hurtową / cenę kosztu przy każdym produkcie (Katalog → Produkty → Ceny → Cena kosztu). Jeśli masz setki SKU, użyj edycji masowej albo importu katalogu; raport marży oparty na w połowie pustych polach kosztowych jest gorszy niż brak raportu, bo wygląda wiarygodnie, a taki nie jest.
• Znaj swój rzeczywisty cennik opłat, faktyczny procent oraz opłatę za transakcję naliczaną przez operatora płatności, odczytane z wyciągu Stripe lub PayPal, a nie z reklamowej stawki.
• Zdobądź rzeczywiste koszty przewoźników, nie cenę wysyłki widoczną dla klienta, z faktur kurierskich, szczególnie jeśli oferujesz darmową albo ryczałtową dostawę, gdzie kwota zapłacona przez klienta nic Ci nie mówi.
• Uporządkuj statusy zamówień, aby zwrócone i anulowane zamówienia nie były po cichu liczone jako ważny przychód. Sprawdź, które statusy są oznaczone jako logable/opłacone w Parametry sklepu → Ustawienia zamówień → Statusy.

Zbuduj nawyk pracy z raportami

Najdokładniejszy raport świata jest bezwartościowy, jeśli nikt go nie otwiera. Sklepy, które rosną procent składany, to te, w których spór kończy liczba, a nie przeczucie, i dzieje się to tylko wtedy, gdy pracujesz w rytmie:

• Co tydzień: łączny zysk (nie przychód), najlepsi i najsłabsi wykonawcy według marży oraz każda zmiana warta drugiego spojrzenia. Pięć minut z panelu administracyjnego.
• Co miesiąc: trendy i sezonowość oraz odpowiedź na pytanie, czy konkretne działanie, zmiana ceny, nowy dostawca, promocja, faktycznie poruszyło zysk, a nie tylko przychód.
• Co kwartał: cała strategia zestawiona z danymi. Które kategorie zasługują na miejsce w ofercie, których klientów warto utrzymywać, gdzie w katalogu leży martwy ciężar.

PrestaShop mierzy przychód od razu po instalacji, bo przychód jest łatwą liczbą do zapisania. Zysk jest liczbą, która prowadzi biznes, a dojście do niego wymaga odjęcia kosztów, które platforma rozprasza albo ignoruje, ceny hurtowej, opłat, rzeczywistej wysyłki, zwrotów. Niezależnie od tego, czy dojdziesz tam starannym zapytaniem w Menedżerze SQL, zdyscyplinowanym arkuszem czy modułem, który łączy dane za Ciebie, zasada jest ta sama: zarządzaj tym, co zostaje, nie tym, co się obraca, i czytaj te dane na tyle często, by zobaczyć spadek, zanim będzie miał kwartał.

Najczęściej zadawane pytania

Dlaczego natywna marża zysku w PrestaShop wygląda źle albo jest pusta?

Prawie zawsze dlatego, że pole ceny kosztu jest puste. Marża w Statystyki → Statystyki katalogu w PrestaShop jest obliczana z wholesale_price, a jeśli nigdy nie uzupełniłeś tego pola w produktach, liczba jest bez znaczenia. Nawet gdy pole jest wypełnione, natywna wartość to jeden uśredniony globalny procent, który ignoruje opłaty za płatności, rzeczywisty koszt wysyłki i zwroty, więc nadaje się do ogólnej kontroli, ale nie do decyzji, który produkt promować. Najpierw uzupełnij ceny kosztu; potem zdecyduj, czy natywny widok wystarcza, czy potrzebujesz szczegółów na poziomie zamówienia.

Czy mogę obliczyć rzeczywisty zysk na zamówieniu bez modułu?

Tak, w zakresie marży brutto, powyższe zapytanie Menedżera SQL łączy ps_orders i ps_order_detail po original_wholesale_price i daje marżę na zamówieniu. Tego, czego nie zrobisz w Menedżerze SQL bez dużego wysiłku, to włączenie kosztów zewnętrznych (cennika prowizji Stripe, faktur przewoźników), zaplanowanie raportu albo przekazanie go nietechnicznej osobie. Ta luka, połączenie zewnętrznych danych kosztowych w stały rachunek zysków i strat z możliwością wejścia w szczegóły. Jest granicą między sprytnym zapytaniem a systemem raportowym takim jak Financial Revolution.

Gdzie PrestaShop przechowuje cenę kosztu i jak uzupełnić ją masowo?

Cena kosztu znajduje się w wholesale_price w ps_product (oraz na poziomie kombinacji, jeśli tam ją ustawiasz), edytowana w Katalog → Produkty → Ceny → Cena kosztu. W momencie sprzedaży PrestaShop kopiuje ją do ps_order_detail.original_wholesale_price, dlatego historyczne zamówienia zachowują koszt aktualny w chwili ich złożenia. Przy setkach SKU uzupełnij ją przez import CSV katalogu zamiast ręcznie, i pamiętaj, że zamówienia złożone przed uzupełnieniem tej wartości nie pokażą kosztu, więc nie ufaj marży na starych zamówieniach.

Czy Financial Revolution automatycznie śledzi opłaty za płatności i koszty wysyłki?

Daje Ci miejsce do ich zapisania i automatycznie odejmuje je od przychodu, gdy już zostaną wprowadzone, ale nie odczyta za Ciebie wyciągu Stripe ani faktury kurierskiej. Zadaniem modułu jest uchwycenie kosztów, których PrestaShop nie ma gdzie przechować (opłat operatorów, rzeczywistej wysyłki, wydatków operacyjnych), i włączenie ich do rachunku zysków i strat w back office, żebyś przestał odbudowywać arkusz kalkulacyjny. Dokładność nadal zależy od tego, czy wpiszesz rzeczywisty cennik opłat i koszty przewoźników; zasada „śmieci na wejściu, śmieci na wyjściu” obowiązuje tutaj tak samo jak wszędzie.

Czy to jest to samo co dane z GA4 albo analityki?

Nie, i mylenie tych rzeczy to częsty błąd. To jest raportowanie finansowe: pieniądze wpływają, pieniądze wypływają, coś zostaje. GA4 i podobne narzędzia to analityka internetowa: skąd przychodzą odwiedzający, jak się zachowują, który kanał konwertuje. Odpowiadają na inne pytania i jedno nie zastępuje drugiego. Od strony analityki zacznij od tekstu co śledzić, a co ignorować oraz metryki GA4, które naprawdę mają znaczenie.