Dostosowanie faktur w PrestaShop: szablony PDF i wymogi prawne

Zweryfikowano w czerwcu 2026 r. Ścieżki plików i menu panelu administracyjnego opisane poniżej dotyczą PrestaShop 1.6, 1.7, 8 i 9 (różnice w 1.6 wskazujemy w treści). Odniesienia do podstaw prawnych właściwych dla poszczególnych krajów, francuskiego Code de commerce, niemieckich UStG/GoBD, polskiego progu dla mechanizmu podzielonej płatności i pozostałych regulacji, były aktualne w chwili pisania, ale przepisy się zmieniają; traktuj je jako wskazówki i poproś lokalnego księgowego o potwierdzenie aktualnych wymagań dla Twojego rynku. To nie jest porada prawna ani podatkowa, a sama instalacja modułu nie sprawia automatycznie, że faktury są zgodne z przepisami.

Większość elementów sklepu możesz zaprojektować po swojemu. Faktura do nich nie należy. To dokument wywołujący skutki prawne, a gdy tylko jeden z Twoich klientów przekaże ją księgowemu, albo kontroler podatkowy wyciągnie ją podczas kontroli, każde brakujące pole staje się Twoim problemem, nie ich. Niemiecka faktura bez daty dostawy, francuska bez informacji o rekompensacie za koszty odzyskiwania należności, polska powyżej 15 000 PLN za towary lub usługi wymienione w ustawowym wykazie, bez adnotacji o mechanizmie podzielonej płatności: każdy taki brak może skończyć się zakwestionowaniem odliczenia VAT albo karą. Problem w tym, że PrestaShop generuje faktury automatycznie ze stałego szablonu PDF, a ten szablon powstał po to, żeby był ogólnie poprawny, niekoniecznie zgodny z przepisami Twojej jurysdykcji. Ten poradnik dotyczy części, nad którą faktycznie masz kontrolę: tego, czego prawo wymaga na wydrukowanej fakturze na głównych rynkach UE, oraz tego, jak dokładnie edytować szablon PDF PrestaShop, aby dodać te pola i nie stracić zmian przy kolejnej aktualizacji.

Krótka uwaga o zakresie, bo ten temat ma bliskich sąsiadów. Ten wpis dotyczy dokumentu PDF, jego układu, pól i zgodności z przepisami. Nie opisuje zasad numerowania faktur (to osobny, obszerny temat, zobacz dostosowanie numerów faktur i zamówień), ustrukturyzowanych formatów e-fakturowania, takich jak włoski SDI czy francuski Factur-X (omawiamy je w artykule e-fakturowanie w Europie), ani konfiguracji samych stawek VAT (konfiguracja podatków w PrestaShop). Tutaj zostajemy przy dokumencie.

Co PrestaShop faktycznie robi, gdy tworzy fakturę

Najpierw warto zrozumieć mechanizm, bo dzięki temu nie będziesz później edytować niewłaściwego pliku. Gdy zamówienie osiąga status z włączoną flagą "Faktura", PrestaShop tworzy w bazie danych wiersz order_invoice i nadaje numer sekwencyjny. To, które statusy generują fakturę, nie jest zapisane na stałe. Zależy wyłącznie od tej flagi "Faktura" ustawianej osobno dla każdego statusu w sekcji Parametry sklepu → Ustawienia zamówień → Statusy, a ustawienia domyślne różnią się w zależności od wersji i konfiguracji PrestaShop. Nie zakładaj, że konkretny status domyślnie wystawia fakturę: otwórz własną listę statusów i sprawdź, które z nich mają włączoną flagę "Faktura". Sam PDF nie jest zapisywany. Jest renderowany na żądanie za każdym razem, gdy ktoś kliknie pobieranie, przez łańcuch trzech elementów:

• Klasa PHP classes/pdf/HTMLTemplateInvoice.php, zbiera dane zamówienia, adresu, podatków i produktów oraz udostępnia je szablonowi. To tutaj dodajesz pole, którego PrestaShop jeszcze nie przekazuje.
• Szablon Smarty pdf/invoice.tpl, właściwy układ i znaczniki dokumentu. To tutaj zmieniasz, co ma się pojawić i w którym miejscu.
• Szablon stylów pdf/invoice.style-tab.tpl, CSS. TCPDF (biblioteka zamieniająca HTML na PDF) obsługuje tylko ograniczony podzbiór CSS, więc spodziewaj się tabel i stylów inline, nie flexboksa.

Co z tego wynika? Dwie praktyczne konsekwencje. Po pierwsze, ponieważ PDF jest odtwarzany z aktualnych danych, faktura wystawiona w marcu po cichu zmieni się, jeśli później edytujesz szablon albo dane zamówienia. Właśnie dlatego archiwizowanie zamrożonej kopii jest tak ważne (więcej o tym niżej). Po drugie, podział na klasę PHP i plik .tpl podpowiada, którego pliku dotknąć: jeśli dane już istnieją w zamówieniu, edytujesz tylko szablon; jeśli potrzebujesz danych, których PrestaShop nigdy nie ładuje, edytujesz także klasę.

Jak edytować szablon, żeby aktualizacja go nie nadpisała

Najczęstszy błąd to bezpośrednia edycja plików rdzenia, kolejna aktualizacja PrestaShop albo odtworzenie czystej instalacji potrafi bez ostrzeżenia usunąć pola wymagane prawem. Są dwie bezpieczne ścieżki i dotyczą różnych plików.

Pliki szablonów (.tpl) nadpisuje się czysto, kopiując je do aktywnego motywu. PrestaShop najpierw szuka w katalogu pdf/ motywu, a dopiero potem wraca do głównego folderu pdf/:

• Skopiuj pdf/invoice.tpl do themes/YOUR_THEME/pdf/invoice.tpl i edytuj kopię.
• Tak samo działa to dla invoice.style-tab.tpl, order-slip.tpl (szablonu korekty / faktury korygującej) oraz delivery-slip.tpl.
• Nie dotykasz niczego w rdzeniu, więc aktualizacje zostawiają Twoją wersję w spokoju, ale po dużym przeskoku wersji warto ponownie sprawdzić kopię, na wypadek gdyby szablon rdzeniowy dostał pola, które chcesz przejąć.

Klasa PHP korzysta natomiast z systemu override PrestaShop. Utwórz override/classes/pdf/HTMLTemplateInvoice.php rozszerzający klasę rdzeniową, a następnie usuń skompilowaną mapę klas, aby PrestaShop zbudował ją ponownie:

• W 1.7/8/9 plik cache to var/cache/prod/class_index.php (oraz var/cache/dev/class_index.php, jeśli pracujesz w trybie dev). W starszych sklepach 1.6 jest to cache/class_index.php.
• Nadpisz getContent(), aby przypisać dodatkowe zmienne Smarty, a potem odczytaj je w pliku invoice.tpl swojego motywu.

Minimalny przykład pokazuje konkretnie ścieżkę z szablonem. Jeśli dane już istnieją w zamówieniu, typowy przypadek to numer VAT klienta zapisany w adresie, zmiana dotyczy tylko szablonu. Skopiuj plik rdzeniowy do motywu i dodaj pole w miejscu, w którym ma być drukowane:

# Copy the core template into your active theme (PS 1.7/8/9)
cp pdf/invoice.tpl themes/YOUR_THEME/pdf/invoice.tpl

Następnie w skopiowanym pliku invoice.tpl wydrukuj numer VAT kupującego przy bloku adresu, z warunkiem, aby pojawiał się tylko wtedy, gdy istnieje:

{if $order->id_address_invoice}
  {assign var=invoiceAddress value=Address::initialize($order->id_address_invoice)}
  {if $invoiceAddress->vat_number}
    <p>{l s='VAT number:' pdf='true'} {$invoiceAddress->vat_number}</p>
  {/if}
{/if}

W przypadku pola, którego PrestaShop nigdy nie ładuje (data dostawy pobierana z order_history, IBAN/BIC banku, numer zamówienia zakupu), dane pobierasz w override HTMLTemplateInvoice::getContent() i przypisujesz do Smarty, a potem drukujesz zmienną w tym samym szablonie, zbieranie danych trzymaj w PHP, a znaczniki w .tpl, nigdy SQL w szablonie. Zawsze wygeneruj jedną prawdziwą fakturę i potwierdź, że pole się renderuje, zanim zaczniesz na nim polegać.

Przechowuj kopię obu plików poza sklepem. Aktualizacje motywu i agresywne akcje typu "reset motywu" mogą usunąć override w pdf/, a moduł zewnętrzny dostarczający własny override może wejść w konflikt z Twoim, traktuj więc dostosowane szablony jak kod źródłowy trzymany w kontroli wersji, a nie jak jednorazowe edycje na żywo, do których nigdy nie wrócisz.

Pola wymagane na dokumencie na poszczególnych rynkach

Poniżej znajdziesz elementy, które muszą pojawić się na wydrukowanej fakturze na rynkach, na które najczęściej sprzedają sprzedawcy korzystający z PrestaShop. To spojrzenie na układ i pola dokumentu. Mechanika stawek VAT stojąca za tymi kwotami jest opisana w VAT w UE: OSS, IOSS, a to, czy pokazujesz ceny netto czy brutto, ma własny zestaw reguł w artykule zasady prezentacji cen w Europie. Zawsze poproś lokalnego księgowego o potwierdzenie; przepisy się zmieniają.

Wzorzec jest wszędzie podobny: PrestaShop solidnie drukuje nazwy sprzedawcy i kupującego, adresy, pozycje produktów oraz rozbicie VAT. Rutynowo pomija natomiast krajowe adnotacje prawne, niemiecką datę dostawy, francuską klauzulę o karach za opóźnienie, polską informację o mechanizmie podzielonej płatności. To właśnie te elementy dodajesz w szablonie.

Skąd faktycznie pochodzą brakujące pola

Zanim zaczniesz pisać kod, pamiętaj, że dwie z tych adnotacji w ogóle nie wymagają pracy w szablonie. PrestaShop ma dla nich wbudowane miejsce:

• Stały tekst prawny (warunki płatności, francuska klauzula o karach, stała adnotacja o zwolnieniu z VAT) wpisujesz w polach Wolny tekst prawny i Tekst stopki w sekcji Zamówienia → Faktury. Są renderowane na każdej fakturze bez kodu. Jeśli jedyną luką jest stały blok tekstu prawnego, być może na tym kończy się praca.
• Dynamiczne pola przypisane do konkretnej faktury (niemiecka data dostawy, referencja zamówienia zakupu B2B, IBAN/BIC dla płatności przelewem bankowym) nie są stałe, więc wymagają ścieżki z szablonem opisanej niżej.

Dla pól dynamicznych poniżej znajdziesz miejsca, w których leżą dane, aby override mógł je pobrać:

• Data dostawy, pole delivery_date zamówienia albo data przejścia zamówienia do statusu wysłanego/dostarczonego z order_history. Przekaż ją do szablonu w override HTMLTemplateInvoice.php.
• Numer VAT klienta, zapisany w adresie (address.vat_number), nie w kliencie. PrestaShop już udostępnia adres, więc często jest to zmiana wyłącznie w szablonie.
• Dane bankowe (IBAN/BIC), znajdują się w konfiguracji modułu płatności Przelew bankowy, nie w zamówieniu; najczystsze podejście to odczytać konfigurację modułu w override i drukować ją tylko wtedy, gdy metodą płatności dla zamówienia był przelew bankowy.
• Referencja zamówienia B2B, jeśli pobierasz numer PO klienta, wyświetl go z zamówienia przy nagłówku, czyli tam, gdzie spodziewają się go księgowi.

Korekty i listy przewozowe: ten sam mechanizm, osobne dokumenty

Zwroty i wysyłki tworzą własne pliki PDF, budowane i dostosowywane w ten sam sposób, ale są to prawnie odrębne dokumenty, więc nie zakładaj, że zmiana faktury przeniesie się automatycznie.

• Korekty (faktury korygujące / avoirs / Gutschriften) są pełnoprawnymi dokumentami. Potrzebują własnej numeracji sekwencyjnej, oddzielonej od faktur, odniesienia do pierwotnego numeru faktury oraz zwracanych kwot z rozbiciem VAT. Wewnętrznie PrestaShop nazywa ten dokument "order slip", więc szablon do dostosowania to themes/YOUR_THEME/pdf/order-slip.tpl (klasa HTMLTemplateOrderSlip), nawet jeśli na wydruku widnieje nagłówek "Korekta".
• Listy przewozowe (bons de livraison) nie zawierają cen, to dokumenty magazynowe i potwierdzające dostawę. Dostosowujesz je przez themes/YOUR_THEME/pdf/delivery-slip.tpl. Jeśli dodajesz niemiecką datę dostawy do faktur, list przewozowy często jest miejscem, z którego pochodzi bazowa data, więc warto je ze sobą uzgodnić.

Pułapka archiwizacji, której nikt nie zauważa aż do kontroli

To problem, który działa po cichu. Ponieważ PrestaShop odtwarza każdy PDF z bazy danych przy pobieraniu, faktura nigdy nie jest zamrożona. Edytujesz szablon, żeby dodać datę dostawy, a wszystkie historyczne faktury po cichu dostają to pole, także te wystawione, zanim taki wymóg Cię dotyczył. Zmieniasz nazwę produktu albo ustawienie podatku, a faktury z poprzedniego kwartału renderują się inaczej. W codziennej pracy może to nie szkodzić. Dla zgodności z przepisami to realne ryzyko: Francja zasadniczo wymaga przechowywania faktur przez 10 lat, natomiast Niemcy zasadniczo wymagają przechowywania kopii faktur przez osiem lat; potwierdź ze swoim doradcą podatkowym obowiązujące wymogi dotyczące przechowywania i integralności, w tym niemieckie GoBD.

Rozwiązanie polega na zapisaniu zamrożonej kopii każdej faktury w momencie jej wystawienia, zamiast polegać na ponownym renderowaniu. W praktyce:

• Archiwizuj w chwili, gdy faktura jest tworzona po raz pierwszy i otrzymuje numer, nie przy każdym renderowaniu PDF. Uruchamiaj archiwizację z przejścia statusu zamówienia, które generuje fakturę (albo z dedykowanego hooka/usługi tworzenia faktury), aby uchwycić dokument raz, w momencie nadania numeru. Podpinanie się pod przepływ renderowania PDF (np. actionPDFInvoiceRender) to zły punkt zaczepienia: odpala się przy pobieraniu i ponownym generowaniu, więc może pominąć faktury, które nigdy nie zostaną pobrane ponownie, oraz nadpisać archiwum późniejszą, inaczej wyrenderowaną wersją. Zapisz dokładnie ten pierwszy wyrenderowany PDF na dysku albo w storage obiektowym.
• Przechowuj go w miejscu niezmienialnym, chmura z polityką jednokrotnego zapisu i wielokrotnego odczytu (WORM) daje zarówno trwałość, jak i niezmienialność oczekiwaną przez GoBD oraz prawo francuskie.
• Nigdy nie pozwól, aby archiwalna kopia była tą, która renderuje się ponownie; cały sens polega na tym, że po wystawieniu nie może się zmienić.

Problemy, które naprawdę generują zgłoszenia do wsparcia

Gdy faktury w PrestaShop zachowują się nieprawidłowo, niemal zawsze chodzi o jeden z poniższych przypadków, a poprawka rzadko leży w samym szablonie:

• Zły adres firmy na fakturze. Jest budowany z nazwy i adresu sklepu (PS_SHOP_NAME, PS_SHOP_ADDR1 i pozostałych wartości), które ustawiasz w bloku adresu sklepu w sekcji Parametry sklepu → Kontakt, nie z ogólnych danych kontaktowych sklepu ani adresu e-mail. Zaktualizuj go tam.
• Brakuje numeru VAT sprzedawcy. Nie ma tu niespodzianki: domyślna faktura PrestaShop w ogóle nie drukuje numeru VAT/podatkowego sprzedawcy. Blok sprzedawcy jest budowany wyłącznie z nazwy i adresu sklepu (wartości PS_SHOP_*), bez pola VAT, a sekcja Międzynarodowy → Podatki konfiguruje tylko stawki i reguły podatkowe, nie identyfikator sprzedawcy. Aby numer VAT pojawił się na fakturze, dodaj go jako stały tekst w polach Wolny tekst prawny / Tekst stopki w sekcji Zamówienia → Faktury albo wydrukuj go z override szablonu. Numer kupującego to osobna sprawa: pojawia się tylko wtedy, gdy klient wpisał go w swoim adresie.
• Znaki specjalne są uszkodzone w PDF (polskie ł/ą/ę, czeskie znaki diakrytyczne, znak euro renderowany jako prostokąty). TCPDF potrzebuje fontu zawierającego te glify, w ustawieniach PDF przełącz font faktury na pełny font Unicode (np. rodzinę DejaVu/freefont) zamiast domyślnego.
• Generowanie PDF kończy się błędem przy dużych zamówieniach. Zwykle winny jest PHP-owy memory_limit. Faktury z wieloma pozycjami i ciężkim szablonem mogą go przekroczyć. Podnieś go po stronie PHP do 256M+.
• Luki w numeracji. Często powoduje je anulowane zamówienie, dla którego faktura została już wygenerowana. Niektóre kraje tolerują luki; Francja nie. Lekarstwem jest strategia numeracji, nie poprawka w szablonie, to temat artykułu dostosowanie numerów faktur i zamówień.

Multistore: jeden szablon, wiele tożsamości prawnych

Jeśli prowadzisz kilka sklepów w instalacji multistore, każdy potrzebuje własnej tożsamości fakturowej, innej nazwy firmy, innej stopki prawnej, często innego języka. PrestaShop obsługuje większość tego kontekstowo: przełącz się na konkretny sklep w selektorze sklepu w panelu administracyjnym przed edycją ustawień faktur, a prefiks, tekst prawny i stopka będą dotyczyć tylko tego sklepu. Ryzyko pojawia się przy edycji w kontekście Wszystkie sklepy, gdzie każda zmiana spływa na wszystkie. Same pliki szablonów są współdzielone z motywu, więc jeśli dwa sklepy naprawdę potrzebują różnych układów, steruj różnicą warunkiem po ID sklepu w pliku .tpl zamiast utrzymywać dwa rozgałęzione szablony.

Kiedy moduł oszczędza pracę z override

Wszystko powyżej da się zrobić ręcznie i dla jednego sklepu w jednym kraju może to być właściwy wybór. Ścieżka z override robi się kosztowna, gdy utrzymujesz własny PHP i szablony motywu przez kolejne aktualizacje PrestaShop, kilka języków i kilka jurysdykcji naraz, dokładnie wtedy utrzymywany moduł zaczyna zarabiać na swoje miejsce, bo ciężar kompatybilności schodzi z Twoich barków.

Najczęściej problem pojawia się najpierw przy numeracji, nie przy układzie: roczne resety, osobne serie dla faktur i korekt oraz formaty takie jak FA-2029-0001, których kilka jurysdykcji w praktyce oczekuje. Nasz moduł mprinvoicenumber obsługuje to z panelu administracyjnego, automatyczne roczne resety, numerację wieloseryjną i własne formaty z rokiem/miesiącem oraz sekwencjami uzupełnianymi zerami, więc nie edytujesz ręcznie licznika co styczeń i nie ryzykujesz luk, których Francja nie wybacza. Jaka jest z tego korzyść? Numeracja pozostaje zgodna z wymogami, a konfiguracja żyje w panelu administracyjnym, nie w pliku override, który kolejna aktualizacja mogłaby nadpisać. Pełne omówienie tego, dlaczego domyślna numeracja nie wystarcza, znajdziesz w artykule dlaczego domyślne numery nie wystarczą.

Uczciwe podsumowanie: silnik faktur PrestaShop jest solidny, ale jego domyślny szablon jest celowo generyczny, a "generyczny" nie znaczy "zgodny z prawem w Twoim kraju". Dostosuj .tpl w motywie, nadpisuj klasę PHP tylko dla pól, których PrestaShop jeszcze nie ładuje, wpisz stały tekst prawny we wbudowanych polach wolnego tekstu i, to część, którą większość sprzedawców pomija, dopóki nie jest za późno, archiwizuj zamrożoną kopię każdej faktury w dniu jej wystawienia. Zrób to dobrze raz, a fakturowanie stanie się niewidoczną, nudną częścią sklepu, którą powinno być.

Najczęściej zadawane pytania

Gdzie edytować szablon faktury PrestaShop?

Skopiuj pdf/invoice.tpl z rdzenia do themes/YOUR_THEME/pdf/invoice.tpl i edytuj kopię, PrestaShop sprawdza folder pdf/ motywu przed rdzeniem, więc aktualizacje zostawiają Twoją wersję nietkniętą. Odpowiadający mu plik stylów to invoice.style-tab.tpl. Dopiero gdy potrzebujesz danych, których PrestaShop nie przekazuje jeszcze do szablonu, dodajesz także override/classes/pdf/HTMLTemplateInvoice.php. Nigdy nie edytuj bezpośrednio pliku rdzeniowego.

Dlaczego numer VAT mojej firmy nie pokazuje się na fakturze?

Bo domyślna faktura PrestaShop w ogóle nie drukuje numeru VAT sprzedawcy. Blok sprzedawcy jest budowany wyłącznie z nazwy i adresu sklepu (wartości PS_SHOP_*), a sekcja Międzynarodowy → Podatki ustawia stawki podatkowe, nie identyfikator sprzedawcy. Dodaj numer VAT jako stały tekst w polu Wolny tekst prawny albo Tekst stopki w sekcji Zamówienia → Faktury, albo wydrukuj go z override szablonu. Numer kupującego jest osobny i pojawia się tylko wtedy, gdy klient wpisał go w swoim adresie.

Czy zmiany w szablonie przetrwają aktualizację PrestaShop?

Override na poziomie motywu w pdf/ przetrwa aktualizacje rdzenia, podobnie jak override klas w override/classes/, ale aktualizacja motywu albo akcja "reset motywu" może usunąć kopię w motywie, a moduł zewnętrzny dostarczający własny szablon lub override może wejść z Twoim w konflikt. Trzymaj oba pliki w kontroli wersji poza sklepem i sprawdzaj je po dużym przeskoku wersji, na wypadek gdyby szablon rdzeniowy dostał pola, które warto włączyć.

Czy korekty i listy przewozowe dostosowuje się tak samo?

Ten sam mechanizm, inne pliki. Korekta (faktura korygująca / avoir) to wewnętrznie "order slip", więc dostosowujesz themes/YOUR_THEME/pdf/order-slip.tpl (klasa HTMLTemplateOrderSlip); list przewozowy to themes/YOUR_THEME/pdf/delivery-slip.tpl. To prawnie odrębne dokumenty, zmiana w invoice.tpl nie przenosi się automatycznie, więc edytuj każdy, którego potrzebujesz.

Dlaczego polskie albo czeskie znaki zamieniają się w PDF w prostokąty?

TCPDF, biblioteka renderująca PDF, pokazuje tylko glify dostępne w wybranym foncie. Domyślny font może nie zawierać ł/ą/ę ani innych znaków diakrytycznych. Przełącz font faktury w ustawieniach PDF na pełną rodzinę Unicode (wariant DejaVu/freefont), a znaki będą renderowane poprawnie. Ta sama poprawka rozwiązuje problem znaku euro drukowanego jako prostokąt.

Powiązane poradniki

• Dostosowanie numerów faktur i zamówień: dlaczego domyślne numery nie wystarczą
• E-fakturowanie w Europie: które kraje go wymagają i jak spełnić wymogi
• Konfiguracja podatków w PrestaShop: wyjaśnienie zasad VAT w UE
• VAT w UE: OSS, IOSS i co musi obsłużyć Twój sklep PrestaShop
• Zasady prezentacji cen w Europie: kiedy pokazywać ceny netto, brutto i jednostkowe