Rechnungen in PrestaShop anpassen: PDF-Vorlagen und rechtliche Anforderungen

Überprüft im Juni 2026. Die unten genannten Dateipfade und Backoffice-Menüs gelten für PrestaShop 1.7, 8 und 9 (Abweichungen in 1.6 werden direkt im Text erwähnt). Die länderspezifischen Rechtsgrundlagen — französischer Code de commerce, deutsches UStG/GoBD, polnischer Schwellenwert für Split Payment und die übrigen Hinweise — waren zum Zeitpunkt der Veröffentlichung korrekt, aber Gesetzgebung ändert sich; verstehen Sie sie als Orientierungspunkte und lassen Sie die aktuelle Anforderung für Ihren Markt von einem lokalen Steuerberater bestätigen. Dies ist keine Rechts- oder Steuerberatung, und die Installation eines Moduls macht Ihre Rechnungen nicht automatisch rechtskonform.

Den Großteil Ihres Shops können Sie frei gestalten. Die Rechnung nicht. Sie ist ein rechtlich verbindliches Dokument, und sobald einer Ihrer Kunden sie seinem Steuerberater vorlegt — oder ein Betriebsprüfer sie bei einer Prüfung anfordert — wird jedes fehlende Feld zu Ihrem Problem, nicht zu seinem. Eine deutsche Rechnung ohne Lieferdatum, eine französische ohne Entschädigungspauschale für Beitreibungskosten, eine polnische über 15.000 PLN ohne Split-Payment-Hinweis: Jeder dieser Mängel kann dazu führen, dass ein Vorsteuerabzug abgelehnt wird oder eine Strafe droht. Der Haken ist, dass PrestaShop Rechnungen automatisch aus einer festen PDF-Vorlage erzeugt, und diese Vorlage wurde so gebaut, dass sie allgemein korrekt ist, nicht zwingend korrekt für Ihre Rechtsordnung. In diesem Leitfaden geht es um den Teil, den Sie tatsächlich steuern können: was das Recht in den wichtigsten EU-Märkten auf der gedruckten Rechnung verlangt und wie Sie die PDF-Vorlage von PrestaShop genau so anpassen, dass diese Felder ergänzt werden, ohne dass die Arbeit beim nächsten Update verloren geht.

Eine kurze Einordnung, weil dieses Thema Nachbarn hat. Dieser Beitrag behandelt das PDF-Dokument — Layout, Felder und Compliance. Es geht nicht darum, wie Rechnungen nummeriert werden (das ist ein eigenes Thema — siehe Anpassung von Rechnungs- und Bestellnummern), auch nicht um strukturierte E-Rechnungsformate wie Italiens SDI oder Frankreichs Factur-X (behandelt in E-Rechnung in Europa) und nicht um die Konfiguration der Mehrwertsteuersätze selbst (Steuerkonfiguration in PrestaShop). Hier bleiben wir beim Dokument.

Was PrestaShop tatsächlich tut, wenn es eine Rechnung erzeugt

Wer die Mechanik zuerst versteht, bearbeitet später nicht versehentlich die falsche Datei. Wenn eine Bestellung einen Status erreicht, bei dem das Kennzeichen "Rechnung" aktiviert ist, erstellt PrestaShop einen order_invoice-Datensatz und vergibt die fortlaufende Nummer. Welche Status eine Rechnung erzeugen, ist nicht fest verdrahtet — es hängt vollständig von diesem statusbezogenen "Rechnung"-Kennzeichen ab, das unter Shop-Einstellungen → Bestelleinstellungen → Status konfiguriert wird; die Standardwerte unterscheiden sich je nach PrestaShop-Version und Konfiguration. Verlassen Sie sich nicht darauf, dass ein bestimmter Status standardmäßig eine Rechnung erzeugt: Öffnen Sie Ihre eigene Statusliste und prüfen Sie, bei welchen Einträgen das "Rechnung"-Kennzeichen gesetzt ist. Das PDF selbst wird nicht gespeichert — es wird bei jedem Klick auf Herunterladen dynamisch gerendert, über eine Kette aus drei Teilen:

• Die PHP-Klasse classes/pdf/HTMLTemplateInvoice.php — sammelt Bestell-, Adress-, Steuer- und Produktdaten und stellt sie der Vorlage bereit. Hier setzen Sie an, wenn Sie ein Feld hinzufügen müssen, das PrestaShop nicht bereits übergibt.
• Die Smarty-Vorlage pdf/invoice.tpl — das eigentliche Layout und Markup des Dokuments. Hier ändern Sie, was wo erscheint.
• Die Stilvorlage pdf/invoice.style-tab.tpl — das CSS. TCPDF (die Bibliothek, die HTML in ein PDF umwandelt) unterstützt nur einen begrenzten CSS-Teilumfang; erwarten Sie also Tabellen und Inline-Styles, kein Flexbox.

Was heißt das praktisch? Aus diesem Design ergeben sich zwei wichtige Konsequenzen. Erstens: Weil das PDF aus Live-Daten neu erzeugt wird, ändert sich eine Rechnung, die Sie im vergangenen März ausgestellt haben, stillschweigend, wenn Sie später die Vorlage oder die Bestelldaten bearbeiten — genau deshalb ist eine archivierte, eingefrorene Kopie wichtig (mehr dazu weiter unten). Zweitens zeigt Ihnen die Trennung zwischen PHP-Klasse und .tpl, welche Datei Sie anfassen müssen: Wenn die Daten bereits in der Bestellung vorhanden sind, bearbeiten Sie nur die Vorlage; wenn Sie Daten benötigen, die PrestaShop nie lädt, müssen Sie auch die Klasse anpassen.

Die Vorlage bearbeiten, ohne beim Update überschrieben zu werden

Der mit Abstand häufigste Fehler ist die direkte Bearbeitung von Core-Dateien — das nächste PrestaShop-Update oder die nächste Wiederherstellung einer sauberen Installation entfernt Ihre rechtlich erforderlichen Felder ohne Vorwarnung. Es gibt zwei sichere Wege, und sie gelten für unterschiedliche Dateien.

Die Vorlagendateien (.tpl) lassen sich sauber überschreiben, indem Sie sie in Ihr aktives Theme kopieren. PrestaShop sucht zuerst im pdf/-Verzeichnis des Themes, bevor es auf den Core-Ordner pdf/ zurückfällt:

• Kopieren Sie pdf/invoice.tpl nach themes/YOUR_THEME/pdf/invoice.tpl und bearbeiten Sie die Kopie.
• Dasselbe funktioniert für invoice.style-tab.tpl, order-slip.tpl (die Vorlage für Gutschrift / Stornorechnung) und delivery-slip.tpl.
• Im Core wird nichts geändert, Updates lassen Ihre Version also unangetastet — allerdings sollten Sie die Kopie nach einem größeren Versionssprung erneut prüfen, falls die Core-Vorlage neue Felder erhalten hat, die Sie übernehmen möchten.

Die PHP-Klasse nutzt stattdessen das Override-System von PrestaShop. Erstellen Sie override/classes/pdf/HTMLTemplateInvoice.php als Erweiterung der Core-Klasse und löschen Sie anschließend die kompilierte Klassenkarte, damit PrestaShop sie neu aufbaut:

• In 1.7/8/9 liegt die Cache-Datei unter var/cache/prod/class_index.php (und unter var/cache/dev/class_index.php, wenn Sie im Dev-Modus arbeiten). In älteren 1.6-Shops heißt sie cache/class_index.php.
• Überschreiben Sie getContent(), um zusätzliche Smarty-Variablen zuzuweisen, und lesen Sie diese anschließend in der invoice.tpl Ihres Themes aus.

Ein minimales Beispiel macht den Vorlagenweg greifbar. Wenn die Daten bereits in der Bestellung vorhanden sind — der häufigste Fall ist die USt-IdNr. des Kunden in der Adresse — genügt eine reine Vorlagenänderung. Kopieren Sie die Core-Datei in Ihr Theme und fügen Sie das Feld dort ein, wo es gedruckt werden soll:

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

Geben Sie dann in dieser kopierten invoice.tpl die Umsatzsteuer-Identifikationsnummer des Käufers in der Nähe des Adressblocks aus — abgesichert, damit sie nur erscheint, wenn sie vorhanden ist:

{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}

Für ein Feld, das PrestaShop nie lädt (ein aus order_history gezogenes Lieferdatum, Bankdaten wie IBAN/BIC, eine Bestellreferenz), holen Sie die Daten im Override von HTMLTemplateInvoice::getContent(), weisen sie Smarty zu und geben die Variable anschließend in derselben Vorlage aus — Datenermittlung gehört in PHP und Markup in die .tpl, niemals SQL direkt in die Vorlage. Erzeugen Sie immer eine echte Rechnung neu und prüfen Sie, ob das Feld korrekt gerendert wird, bevor Sie sich darauf verlassen.

Bewahren Sie eine Kopie beider Dateien außerhalb des Shops auf. Theme-Updates und aggressive Aktionen wie "Theme zurücksetzen" können den pdf/-Override entfernen, und ein Drittanbieter-Modul mit eigenem Override kann mit Ihrem kollidieren — behandeln Sie Ihre angepassten Vorlagen deshalb als Quellcode unter Versionskontrolle, nicht als Live-Änderungen, die Sie nie wieder anfassen müssen.

Welche Pflichtfelder die einzelnen Märkte auf dem Dokument erwarten

Unten steht, was auf der gedruckten Rechnung in den Märkten erscheinen muss, in die viele PrestaShop-Händler verkaufen. Das ist die Layout- und Feldperspektive — die Mehrwertsteuerlogik hinter diesen Zahlen behandeln wir in Mehrwertsteuer in der EU: OSS, IOSS, und ob Sie Netto- oder Bruttopreise anzeigen, ist ein eigener Regelbereich in Preisangaben in Europa. Lassen Sie die Details immer von einem lokalen Steuerberater bestätigen; Gesetze ändern sich.

Das Muster ist überall ähnlich: PrestaShop druckt zuverlässig Verkäufer- und Käufername, Adressen, Produktpositionen und die Steueraufschlüsselung. Was regelmäßig fehlt, sind die länderspezifischen rechtlichen Hinweise — das deutsche Lieferdatum, die französische Vertragsstrafen- bzw. Verzugsklausel, der polnische Split-Payment-Hinweis. Genau diese Punkte ergänzen Sie in der Vorlage.

Woher die fehlenden Felder tatsächlich kommen

Bevor Sie mit dem Coden beginnen: Zwei dieser Hinweise brauchen überhaupt keinen Eingriff in die Vorlage — PrestaShop bringt dafür bereits ein Feld mit:

• Statischer Rechtstext (Zahlungsbedingungen, französische Verzugsklausel, fester Hinweis auf Umsatzsteuerbefreiung) gehört in die Felder Freier Rechtstext und Fußzeilentext unter Bestellungen → Rechnungen. Diese erscheinen ohne Code auf jeder Rechnung. Wenn Ihre einzige Lücke ein gleichbleibender rechtlicher Textblock ist, sind Sie hier möglicherweise schon fertig.
• Dynamische Felder je Rechnung (deutsches Lieferdatum, B2B-Bestellreferenz, IBAN/BIC für Überweisungsbestellungen) sind nicht konstant und benötigen deshalb den unten beschriebenen Vorlagenweg.

Für die dynamischen Felder finden Sie hier die Datenquellen, aus denen Ihr Override lesen kann:

• Lieferdatum — das Feld delivery_date der Bestellung oder das Datum, an dem die Bestellung laut order_history in einen versendeten/gelieferten Status gewechselt ist. Übergeben Sie es in Ihrem HTMLTemplateInvoice.php-Override an die Vorlage.
• USt-IdNr. des Kunden — wird in der Adresse gespeichert (address.vat_number), nicht beim Kunden. PrestaShop stellt die Adresse bereits bereit, daher ist dies oft eine reine Vorlagenänderung.
• Bankdaten (IBAN/BIC) — diese liegen in der Konfiguration des Zahlungsmoduls Banküberweisung, nicht in der Bestellung; am saubersten ist es, die Modulkonfiguration im Override zu lesen und die Daten nur auszugeben, wenn die Zahlungsmethode der Bestellung Überweisung war.
• B2B-Bestellreferenz — wenn Sie eine Kunden-Bestellnummer erfassen, holen Sie sie aus der Bestellung und zeigen Sie sie in der Nähe des Kopfbereichs an, wo Buchhaltungen sie erwarten.

Gutschriften und Lieferscheine: dieselbe Mechanik, eigene Dokumente

Erstattungen und Lieferungen erzeugen eigene PDFs, die auf dieselbe Weise gebaut und angepasst werden — rechtlich sind es jedoch eigenständige Dokumente. Gehen Sie also nicht davon aus, dass eine Rechnungsänderung automatisch übernommen wird.

• Gutschriften (Stornorechnungen / avoirs) sind eigenständige Rechtsdokumente. Sie benötigen eine eigene fortlaufende Nummerierung getrennt von Rechnungen, einen Verweis auf die ursprüngliche Rechnungsnummer und die erstatteten Beträge mit ausgewiesener Mehrwertsteuer. PrestaShop nennt dieses Dokument intern "order slip"; die anzupassende Vorlage ist daher themes/YOUR_THEME/pdf/order-slip.tpl (Klasse HTMLTemplateOrderSlip), auch wenn es mit der Überschrift "Gutschrift" gedruckt wird.
• Lieferscheine (bons de livraison) enthalten keine Preise — sie sind Lager- und Zustellnachweisdokumente. Sie passen sie über themes/YOUR_THEME/pdf/delivery-slip.tpl an. Wenn Sie das deutsche Lieferdatum auf Rechnungen ergänzen, ist der Lieferschein oft der Ort, an dem das zugrunde liegende Datum entsteht; deshalb lohnt sich eine Abstimmung beider Dokumente.

Die Archivierungsfalle, die niemand bemerkt, bis eine Prüfung kommt

Das ist der Punkt, der leise zuschlägt. Weil PrestaShop jedes PDF beim Herunterladen aus der Datenbank neu erzeugt, ist eine Rechnung nie eingefroren. Bearbeiten Sie Ihre Vorlage, um das Lieferdatum hinzuzufügen, erhalten alle historischen Rechnungen dieses Feld stillschweigend ebenfalls — auch solche, die ausgestellt wurden, bevor Sie dazu verpflichtet waren. Ändern Sie einen Produktnamen oder eine Steuereinstellung, werden die Rechnungen des letzten Quartals anders gerendert. Im Alltag ist das harmlos. Für Compliance ist es ein echtes Risiko: Frankreich verlangt, dass Rechnungen 10 Jahre in einem unveränderbaren Format aufbewahrt werden, und die deutsche GoBD verlangt dieselbe Aufbewahrung mit Unveränderbarkeit.

Die Lösung besteht darin, im Moment der Ausstellung eine eingefrorene Kopie jeder Rechnung zu erfassen, statt sich auf die spätere Neuerzeugung zu verlassen. Praktisch heißt das:

• Archivieren Sie in dem Moment, in dem die Rechnung erstmals erstellt und nummeriert wird — nicht bei jedem PDF-Rendering. Lösen Sie die Archivierung über den Bestellstatuswechsel aus, der die Rechnung erzeugt (oder über einen dedizierten Hook/Service zur Rechnungserstellung), damit Sie das Dokument genau einmal erfassen, wenn seine Nummer vergeben wird. Den PDF-Render-Flow einzuhängen (z. B. actionPDFInvoiceRender) ist der falsche Anker: Er läuft beim Herunterladen und bei der Neuerzeugung, kann also Rechnungen verpassen, die nie erneut heruntergeladen werden, und Ihr Archiv mit später neu gerenderten Ausgaben überschreiben. Schreiben Sie genau dieses zuerst gerenderte PDF auf Datenträger oder in Objektspeicher.
• Speichern Sie es an einem unveränderbaren Ort — Cloud-Speicher mit Write-once-read-many-(WORM)-Richtlinie bietet sowohl Haltbarkeit als auch die Unveränderbarkeit, die GoBD und französisches Recht erwarten.
• Lassen Sie niemals die archivierte Kopie diejenige sein, die neu gerendert wird; der ganze Zweck besteht darin, dass sie sich nach der Ausstellung nicht mehr ändern kann.

Die Probleme, die tatsächlich Support-Tickets auslösen

Wenn Rechnungen in PrestaShop Probleme machen, ist fast immer einer dieser Punkte die Ursache — und die Lösung liegt selten in der Vorlage:

• Falsche Firmenadresse auf der Rechnung. Sie wird aus Shopname und Adresse aufgebaut (PS_SHOP_NAME, PS_SHOP_ADDR1 und die übrigen Werte), die Sie im Shop-Adressblock unter Shop-Einstellungen → Kontakt setzen, nicht aus Ihren allgemeinen Shop-/E-Mail-Kontaktdaten. Aktualisieren Sie sie dort.
• USt-IdNr. des Verkäufers fehlt. Hier gibt es keine Überraschung: Die Standardrechnung von PrestaShop druckt keine Umsatzsteuer- oder Steuernummer des Verkäufers — der Verkäuferblock wird nur aus Shopname und Adresse (den PS_SHOP_*-Werten) aufgebaut, ohne USt-Feld, und International → Steuern konfiguriert nur Steuersätze und Regeln, keine Verkäuferkennung. Damit Ihre USt-IdNr. erscheint, fügen Sie sie als konstanten Text in die Felder Freier Rechtstext / Fußzeilentext unter Bestellungen → Rechnungen ein oder geben Sie sie über Ihren Vorlagen-Override aus. Die Nummer des Käufers ist davon getrennt: Sie wird nur gedruckt, wenn der Kunde sie in seiner Adresse eingetragen hat.
• Sonderzeichen werden im PDF zerstört (polnische Zeichen wie ł/ą/ę, tschechische Diakritika, das Eurozeichen erscheint als Kästchen). TCPDF benötigt eine Schriftart, die diese Glyphen enthält — stellen Sie in den PDF-Einstellungen statt der Standardschrift eine Unicode-vollständige Schrift um (z. B. aus der DejaVu-/freefont-Familie).
• PDF-Erzeugung schlägt bei großen Bestellungen fehl. Meist liegt es am PHP-memory_limit — Rechnungen mit vielen Positionen und einer schweren Vorlage können es überschreiten. Erhöhen Sie es auf PHP-Seite auf 256M+.
• Lücken in der Nummerierung. Häufig ist eine stornierte Bestellung der Grund, für die bereits eine Rechnung erzeugt wurde. Manche Länder tolerieren Lücken, Frankreich nicht. Die Lösung ist eine Nummerierungsstrategie, keine Vorlagenkorrektur — genau darum geht es in Anpassung von Rechnungs- und Bestellnummern.

Multishop: eine Vorlage, viele rechtliche Identitäten

Wenn Sie mehrere Shops in einer Multishop-Installation betreiben, braucht jeder seine eigene Rechnungsidentität — anderer Firmenname, andere rechtliche Fußzeile, oft eine andere Sprache. PrestaShop behandelt den Großteil davon kontextbezogen: Wechseln Sie im Shop-Auswahlschalter des Backoffice vor dem Bearbeiten der Rechnungseinstellungen zum konkreten Shop, dann gelten Präfix, freier Rechtstext und Fußzeile nur für diesen Shop. Gefährlich ist das Bearbeiten im Kontext Alle Shops, weil jede Änderung auf alle Shops durchgereicht wird. Die Vorlagendateien selbst werden aus dem Theme gemeinsam genutzt; wenn zwei Shops wirklich unterschiedliche Layouts benötigen, steuern Sie die Unterschiede besser über eine Shop-ID-Bedingung innerhalb der .tpl, statt zwei geforkte Vorlagen zu pflegen.

Wo ein Modul Ihnen die Override-Arbeit abnimmt

Alles oben Beschriebene lässt sich von Hand umsetzen, und für einen einzelnen Shop in einem einzelnen Land kann das die richtige Entscheidung sein. Der Override-Weg wird teuer, wenn Sie eigenes PHP und Theme-Vorlagen über PrestaShop-Upgrades, mehrere Sprachen und mehrere Rechtsräume hinweg pflegen müssen — genau dann verdient ein gepflegtes Modul seinen Platz, weil die Kompatibilitätslast von Ihrem Tisch verschwindet.

In der Praxis zeigt sich das oft zuerst bei der Nummerierung, nicht beim Layout: jährliche Zurücksetzungen, getrennte Serien für Rechnungen und Gutschriften sowie Formate wie FA-2029-0001, die mehrere Rechtsordnungen faktisch erwarten. Unser Modul mprinvoicenumber erledigt das aus dem Backoffice heraus — automatische jährliche Zurücksetzungen, Nummerierung mit mehreren Serien und eigene Formate mit Jahr/Monat und nullaufgefüllten Sequenzen — damit Sie nicht jeden Januar manuell am Zähler arbeiten oder Lücken riskieren, die Frankreich nicht verzeiht. Was ist also der Nutzen? Die Nummerierung bleibt konform, und die Konfiguration liegt im Adminbereich, nicht in einer Override-Datei, die das nächste Update überschreiben könnte. Die vollständige Begründung, warum Standardnummern nicht ausreichen, finden Sie in warum Standardnummern nicht ausreichen.

Die ehrliche Kurzfassung: Die Rechnungs-Engine von PrestaShop ist solide, aber ihre Standardvorlage ist bewusst generisch, und "generisch" ist nicht dasselbe wie "in Ihrem Land rechtssicher". Passen Sie die .tpl in Ihrem Theme an, überschreiben Sie die PHP-Klasse nur für Felder, die PrestaShop nicht bereits lädt, hinterlegen Sie konstante Rechtstexte in den integrierten Freitextfeldern und — der Teil, den die meisten Händler überspringen, bis es zu spät ist — archivieren Sie am Tag der Ausstellung eine eingefrorene Kopie jeder Rechnung. Wenn diese Punkte einmal sauber sitzen, wird die Rechnungsstellung zu dem unsichtbaren, langweiligen Teil Ihres Shops, der sie sein sollte.

Häufig gestellte Fragen

Wo bearbeite ich die PrestaShop-Rechnungsvorlage?

Kopieren Sie pdf/invoice.tpl aus dem Core nach themes/YOUR_THEME/pdf/invoice.tpl und bearbeiten Sie die Kopie — PrestaShop prüft den pdf/-Ordner des Themes vor dem Core, sodass Updates Ihre Version unangetastet lassen. Die passende Stildatei ist invoice.style-tab.tpl. Nur wenn Sie Daten benötigen, die PrestaShop nicht bereits an die Vorlage übergibt, ergänzen Sie zusätzlich eine override/classes/pdf/HTMLTemplateInvoice.php. Bearbeiten Sie niemals die Core-Datei direkt.

Warum erscheint die USt-IdNr. meines Unternehmens nicht auf der Rechnung?

Weil die Standardrechnung von PrestaShop überhaupt keine Umsatzsteuernummer des Verkäufers druckt — der Verkäuferblock wird nur aus Shopname und Adresse (den PS_SHOP_*-Werten) aufgebaut, und International → Steuern legt Steuersätze fest, keine Verkäuferkennung. Fügen Sie Ihre USt-IdNr. als konstanten Text in die Felder Freier Rechtstext oder Fußzeilentext unter Bestellungen → Rechnungen ein oder geben Sie sie über einen Vorlagen-Override aus. Die Nummer des Käufers ist davon getrennt und erscheint nur, wenn der Kunde sie in seiner Adresse eingetragen hat.

Überstehen meine Vorlagenänderungen ein PrestaShop-Update?

Overrides auf Theme-Ebene im pdf/-Ordner überstehen Core-Updates, und Klassen-Overrides unter override/classes/ ebenfalls — aber ein Theme-Update oder eine Aktion wie "Theme zurücksetzen" kann die Theme-Kopie entfernen, und ein Drittanbieter-Modul mit eigener Vorlage oder eigenem Override kann mit Ihrem Code kollidieren. Bewahren Sie beide Dateien außerhalb des Shops in der Versionskontrolle auf und prüfen Sie sie nach einem größeren Versionssprung erneut, falls die Core-Vorlage neue Felder enthält, die Sie übernehmen möchten.

Werden Gutschriften und Lieferscheine genauso angepasst?

Gleiche Mechanik, andere Dateien. Die Gutschrift (Stornorechnung / avoir) ist intern der "order slip"; Sie passen daher themes/YOUR_THEME/pdf/order-slip.tpl an (Klasse HTMLTemplateOrderSlip). Der Lieferschein ist themes/YOUR_THEME/pdf/delivery-slip.tpl. Es sind rechtlich eigenständige Dokumente — eine Änderung an invoice.tpl wird nicht übernommen — bearbeiten Sie also jedes benötigte Dokument separat.

Warum werden polnische oder tschechische Zeichen im PDF zu Kästchen?

TCPDF, die Bibliothek für das PDF-Rendering, zeigt nur Glyphen an, die in der gewählten Schrift vorhanden sind. Die Standardschrift enthält möglicherweise ł/ą/ę oder andere Diakritika nicht. Stellen Sie die Rechnungsschrift in den PDF-Einstellungen auf eine Unicode-vollständige Familie um (eine DejaVu-/freefont-Variante), dann werden die Zeichen korrekt dargestellt. Dieselbe Korrektur behebt auch ein Eurozeichen, das als Kästchen gedruckt wird.

Verwandte Leitfäden

• Rechnungs- und Bestellnummern anpassen: Warum Standardnummern nicht ausreichen
• E-Rechnung in Europa: Welche Länder sie verlangen und wie Sie die Anforderungen erfüllen
• Steuerkonfiguration in PrestaShop: EU-Mehrwertsteuerregeln erklärt
• Mehrwertsteuer in der EU: OSS, IOSS und was Ihr PrestaShop-Shop beherrschen muss
• Preisangaben in Europa: Wann Netto-, Brutto- und Grundpreise angezeigt werden müssen