Revisionato a giugno 2026. I percorsi dei file e i menu del back office indicati di seguito si applicano a PrestaShop 1.6, 1.7, 8 e 9 (le differenze della 1.6 sono segnalate nel testo). I riferimenti alle basi legali specifiche per Paese, Code de commerce francese, UStG/GoBD tedesche, soglia polacca per lo split payment e il resto, erano accurati al momento della pubblicazione, ma la normativa cambia; considerali come indicazioni e fai confermare il requisito aggiornato per il tuo mercato da un commercialista locale. Questo non è un parere legale o fiscale, e installare un modulo non rende di per sé le tue fatture conformi.

Gran parte del tuo negozio puoi progettarla come vuoi. La fattura no. È un documento giuridicamente vincolante e, nel momento in cui uno dei tuoi clienti la consegna al proprio commercialista, o un ispettore fiscale la richiede durante un controllo, ogni campo mancante diventa un problema tuo, non suo. Una fattura tedesca senza data di consegna, una francese senza indennità forfettaria per costi di recupero, una polacca sopra i 15.000 PLN per beni o servizi elencati dalla normativa, senza nota sullo split payment: ciascuna di queste omissioni può far respingere una detrazione IVA o attivare una sanzione. Il punto critico è che PrestaShop genera le fatture automaticamente da un template PDF fisso, pensato per essere genericamente corretto, non per essere corretto nella tua giurisdizione. Questa guida riguarda la parte che puoi controllare davvero: ciò che la legge richiede sulla fattura stampata nei principali mercati dell'UE e come modificare con precisione il template PDF di PrestaShop per aggiungere quei campi senza perdere il lavoro al prossimo aggiornamento.

Una breve nota di perimetro, perché questo tema ha diversi argomenti vicini. Questo articolo parla del documento PDF, layout, campi, conformità. Non parla di come vengono numerate le fatture (tema che merita un approfondimento a parte, vedi personalizzazione dei numeri di fattura e ordine), né di formati strutturati di fatturazione elettronica come lo SDI italiano o Factur-X in Francia (trattati in fatturazione elettronica in Europa), né della configurazione delle aliquote IVA (configurazione fiscale in PrestaShop). Qui restiamo sul documento.

Cosa fa davvero PrestaShop quando genera una fattura

Capire prima il meccanismo ti evita di modificare il file sbagliato più avanti. Quando un ordine raggiunge uno stato in cui il flag "Fattura" è abilitato, PrestaShop crea una riga nel database order_invoice e assegna il numero progressivo. Quali stati generano una fattura non è fisso: dipende interamente dal flag "Fattura" di ciascuno stato, configurato in Parametri negozio → Impostazioni ordine → Stati, e i valori predefiniti variano in base alla versione e alla configurazione di PrestaShop. Non dare per scontato che un certo stato generi fattura di default: apri il tuo elenco stati e verifica quali hanno il flag "Fattura" attivo. Il PDF in sé non viene salvato: viene renderizzato su richiesta ogni volta che qualcuno fa clic su download, attraverso una catena di tre elementi:

  • La classe PHP classes/pdf/HTMLTemplateInvoice.php, raccoglie i dati di ordine, indirizzo, imposte e prodotti e li espone al template. È qui che intervieni per aggiungere un campo che PrestaShop non passa già.
  • Il template Smarty pdf/invoice.tpl, il layout e il markup effettivi del documento. È qui che modifichi cosa appare e dove.
  • Il template di stile pdf/invoice.style-tab.tpl, il CSS. TCPDF (la libreria che trasforma l'HTML in PDF) supporta solo un sottoinsieme limitato di CSS, quindi aspettati tabelle e stili inline, non flexbox.

Quindi cosa cambia? Da questa architettura derivano due conseguenze pratiche. Primo: poiché il PDF viene rigenerato dai dati live, una fattura emessa lo scorso marzo cambierà silenziosamente se in seguito modifichi il template o i dati dell'ordine, ed è esattamente per questo che archiviare una copia congelata è importante (ne parliamo più sotto). Secondo: la separazione tra classe PHP e .tpl ti dice quale file toccare: se il dato esiste già nell'ordine, modifichi solo il template; se ti serve un dato che PrestaShop non carica mai, devi modificare anche la classe.

Modificare il template senza farsi sovrascrivere da un aggiornamento

Generatore di formato fattura PrestaShop che mostra il modello di numerazione del documento e i tag disponibili
Un generatore di formato ti consente di modellare il documento di fattura e la sua numerazione senza modificare i file di template del core.

L'errore più comune è modificare direttamente i file del core: il successivo aggiornamento di PrestaShop o il prossimo ripristino di un'installazione pulita cancella senza avviso i campi richiesti dalla legge. Ci sono due percorsi sicuri, e si applicano a file diversi.

I file template (.tpl) si sovrascrivono in modo pulito copiandoli nel tema attivo. PrestaShop cerca prima nella directory pdf/ del tema e solo dopo ripiega sulla cartella core pdf/:

  • Copia pdf/invoice.tpl in themes/YOUR_THEME/pdf/invoice.tpl e modifica la copia.
  • Lo stesso vale per invoice.style-tab.tpl, order-slip.tpl (il template della nota di credito / accredito) e delivery-slip.tpl.
  • Nel core non viene toccato nulla, quindi gli aggiornamenti lasciano intatta la tua versione, ma dopo un salto di versione importante devi comunque ricontrollare la copia, nel caso in cui il template core abbia acquisito campi che ti servono.

La classe PHP usa invece il sistema di override di PrestaShop. Crea override/classes/pdf/HTMLTemplateInvoice.php estendendo la classe core, poi elimina la mappa delle classi compilata affinché PrestaShop la ricostruisca:

  • Su 1.7/8/9 il file di cache è var/cache/prod/class_index.php (e var/cache/dev/class_index.php se sei in modalità dev). Nei negozi 1.6 più vecchi è cache/class_index.php.
  • Sovrascrivi getContent() per assegnare variabili Smarty aggiuntive, poi leggile nel tuo invoice.tpl del tema.

Un esempio minimo rende concreto il percorso via template. Se il dato esiste già sull'ordine. Il caso più comune è il numero di partita IVA del cliente nell'indirizzo, la modifica riguarda solo il template. Copia il file core nel tema e aggiungi il campo dove vuoi stamparlo:

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

Poi, dentro quel invoice.tpl copiato, stampa la partita IVA dell'acquirente vicino al blocco indirizzo, con una condizione, così viene mostrata solo quando esiste:

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

Per un campo che PrestaShop non carica mai (una data di consegna recuperata da order_history, IBAN/BIC bancari, un riferimento d'ordine del cliente), recuperi il dato nell'override di HTMLTemplateInvoice::getContent() e lo assegni a Smarty, poi stampi la variabile nello stesso template, mantieni la raccolta dati in PHP e il markup nel .tpl, mai SQL dentro il template. Rigenera sempre una fattura reale e verifica che il campo venga renderizzato prima di farci affidamento.

Tieni una copia di entrambi i file fuori dal negozio. Gli aggiornamenti del tema e le azioni aggressive di "reset tema" possono rimuovere l'override pdf/, e un modulo di terze parti che porta con sé un proprio override può entrare in conflitto con il tuo, quindi tratta i template personalizzati come codice sorgente da versionare, non come modifiche live che non rivedrai mai più.

I campi legali che ogni mercato si aspetta sul documento

Di seguito trovi ciò che deve comparire sulla fattura stampata nei mercati in cui vendono più spesso i commercianti PrestaShop. Questa è la vista su layout e campi: la meccanica delle aliquote IVA dietro questi numeri è trattata in IVA nell'UE: OSS, IOSS, mentre la scelta tra prezzi netti e lordi segue regole proprie in regole di visualizzazione dei prezzi in Europa. Fai sempre confermare da un commercialista locale: la normativa cambia.

MercatoCampi in fattura che il default di PrestaShop spesso non includeBase legale
Francia (Facture)SIREN/SIRET, città di iscrizione RCS, forma giuridica & capitale sociale, tasso degli interessi di mora e indennità forfettaria fissa di 40 EUR per costi di recupero nel B2BCode de commerce, Art. L441-9
Germania (Rechnung)Data di consegna / prestazione del servizio (distinta dalla data fattura, il campo più spesso dimenticato), Steuernummer o USt-IdNr e nota Kleinunternehmer (§19 UStG) in caso di esenzione IVAUStG §14 / §14a
Italia (Fattura)Codice Fiscale / Partita IVA di entrambe le parti; il B2B ormai richiede solo fatturazione elettronica via SDI, quindi il PDF serve per B2C e archiviazioneFatturazione elettronica (SDI)
Spagna (Factura)NIF/CIF, identificativo della serie della fattura e riga di maggiorazione Recargo de equivalencia per i rivenditori soggetti a quel regimeRD 1619/2012
Polonia (Faktura)NIP di entrambe le parti nel B2B e nota "Mechanizm podzielonej płatności" (split payment) sulle fatture oltre 15.000 PLN per beni/servizi elencati dalla normativaUstawa o VAT

Il modello è lo stesso in tutti questi Paesi: PrestaShop stampa in modo affidabile nomi e indirizzi di venditore/acquirente, righe prodotto e riepilogo IVA. Ciò che omette abitualmente sono gli avvisi legali specifici per Paese: la data di consegna tedesca, la clausola francese sulle penali, la nota polacca sullo split payment. Sono questi i campi da aggiungere nel template.

Da dove proviene davvero ogni campo mancante

Prima di iniziare a scrivere codice, due di questi avvisi non richiedono alcun intervento sul template: PrestaShop ha già uno spazio integrato per inserirli:

  • Testo legale statico (termini di pagamento, clausola francese sulle penali, nota fissa di esenzione IVA) va nei campi Testo legale libero e Testo piè di pagina in Ordini → Fatture. Vengono renderizzati su ogni fattura senza codice. Se l'unica lacuna è un blocco costante di testo legale, potresti aver già finito.
  • Campi dinamici per singola fattura (data di consegna tedesca, riferimento ordine B2B del cliente, IBAN/BIC per ordini con bonifico bancario) non sono costanti, quindi richiedono il percorso via template indicato sotto.

Per i campi dinamici, ecco dove si trovano i dati che il tuo override deve recuperare:

  • Data di consegna, il campo delivery_date dell'ordine, oppure la data in cui l'ordine è entrato in uno stato spedito/consegnato da order_history. Passala al template nel tuo override di HTMLTemplateInvoice.php.
  • Partita IVA del cliente, salvata sull'indirizzo (address.vat_number), non sul cliente. PrestaShop espone già l'indirizzo, quindi spesso è una modifica solo di template.
  • Dati bancari (IBAN/BIC), vivono nella configurazione del modulo di pagamento Bonifico bancario, non nell'ordine; l'approccio più pulito è leggere la configurazione del modulo nell'override e stamparla solo quando il metodo di pagamento dell'ordine era il bonifico bancario.
  • Riferimento ordine B2B, se raccogli un numero d'ordine del cliente, recuperalo dall'ordine e mostralo vicino all'intestazione, dove i contabili si aspettano di trovarlo.

Note di credito e documenti di consegna: stesso meccanismo, documenti separati

Rimborsi e spedizioni producono i propri PDF, costruiti e personalizzati nello stesso modo, ma sono documenti legalmente distinti, quindi non dare per scontato che una modifica alla fattura venga applicata anche lì.

  • Note di credito (credit notes / avoirs / Gutschriften) sono documenti legali a tutti gli effetti. Hanno bisogno di una numerazione progressiva propria, separata da quella delle fatture, di un riferimento al numero della fattura originale e degli importi rimborsati con IVA scorporata. Internamente PrestaShop chiama questo documento "order slip", quindi il template da personalizzare è themes/YOUR_THEME/pdf/order-slip.tpl (classe HTMLTemplateOrderSlip), anche se viene stampato con intestazione "Nota di credito".
  • Documenti di consegna (bons de livraison) non contengono prezzi: sono documenti di magazzino e prova di consegna. Si personalizzano tramite themes/YOUR_THEME/pdf/delivery-slip.tpl. Se aggiungi la data di consegna tedesca alle fatture, spesso il documento di consegna è il punto da cui quella data deriva, quindi vale la pena allinearli.

La trappola dell'archiviazione che nessuno nota fino a un controllo

È il problema che colpisce in silenzio. Poiché PrestaShop rigenera ogni PDF dal database al momento del download, una fattura non è mai congelata. Modifichi il template per aggiungere la data di consegna, e ogni fattura storica acquisisce silenziosamente quel campo, comprese quelle emesse prima che fossi tenuto a mostrarlo. Cambi il nome di un prodotto o un'impostazione fiscale, e le fatture del trimestre scorso vengono renderizzate in modo diverso. Nell'uso quotidiano può sembrare innocuo. Per la conformità è un'esposizione reale: la Francia richiede generalmente che le fatture siano conservate per 10 anni, mentre la Germania richiede generalmente che le copie delle fatture siano conservate per otto anni; verifica con il tuo consulente fiscale i requisiti di conservazione e integrità applicabili, comprese le norme GoBD tedesche.

La soluzione è acquisire una copia congelata di ogni fattura nel momento in cui viene emessa, invece di fare affidamento sulla rigenerazione. In pratica:

  • Archivia nel momento in cui la fattura viene creata e numerata per la prima volta, non a ogni renderizzazione del PDF. Attiva l'archiviazione dalla transizione di stato dell'ordine che genera la fattura (o da un hook/servizio dedicato alla creazione fattura), così acquisisci il documento una sola volta, quando gli viene assegnato il numero. Agganciarsi al flusso di renderizzazione del PDF (ad esempio actionPDFInvoiceRender) è il punto sbagliato: scatta al download e alla rigenerazione, quindi può perdere fatture che non vengono mai riscaricate e può sovrascrivere l'archivio con un output renderizzato più tardi. Scrivi quel PDF esatto della prima renderizzazione su disco o in object storage.
  • Conservalo in un luogo immutabile: uno storage cloud con policy write-once-read-many (WORM) ti offre sia durabilità sia l'inalterabilità richiesta dalla GoBD e dalla legge francese.
  • Non lasciare mai che la copia archiviata sia quella che si rigenera; il punto è proprio che non possa cambiare dopo l'emissione.

I problemi che generano davvero ticket di supporto

Quando le fatture si comportano male in PrestaShop, quasi sempre la causa è una di queste, e di rado la soluzione sta nel template:

  • Indirizzo aziendale sbagliato sulla fattura. Viene costruito dal nome e dall'indirizzo del negozio (PS_SHOP_NAME, PS_SHOP_ADDR1 e gli altri), che imposti nel blocco indirizzo negozio in Parametri negozio → Contatto, non dai contatti generali del negozio o dall'email. Aggiornalo lì.
  • Partita IVA del venditore mancante. Non c'è nessuna sorpresa: la fattura predefinita di PrestaShop non stampa affatto un numero IVA/fiscale del venditore, il blocco venditore viene costruito solo dal nome e dall'indirizzo del negozio (i valori PS_SHOP_*), senza campo IVA, e Internazionale → Tasse configura solo aliquote e regole fiscali, non un identificativo del venditore. Per far comparire la tua partita IVA, aggiungila come testo costante nei campi Testo legale libero / Testo piè di pagina in Ordini → Fatture, oppure stampala dal tuo override del template. Il numero dell'acquirente è separato: viene stampato solo se il cliente lo ha inserito nel proprio indirizzo.
  • Caratteri speciali rovinati nel PDF (ł/ą/ę polacche, diacritici cechi, simbolo euro renderizzato come quadrati). TCPDF ha bisogno di un font che contenga quei glifi: passa a un font completo Unicode (ad esempio una famiglia DejaVu/freefont) nelle impostazioni PDF invece di usare quello predefinito.
  • La generazione del PDF fallisce su ordini grandi. Di solito è il memory_limit di PHP: fatture con molte righe e un template pesante possono superarlo. Aumentalo a 256M+ lato PHP.
  • Buchi nella numerazione. Spesso si tratta di un ordine annullato che aveva già generato una fattura. Alcuni Paesi tollerano i buchi; la Francia no. La soluzione è una strategia di numerazione, non una modifica al template. È il tema di personalizzazione dei numeri di fattura e ordine.

Multinegozio: un template, molte identità legali

Se gestisci più negozi in un'installazione multistore, ciascuno ha bisogno della propria identità di fatturazione: ragione sociale diversa, piè di pagina legale diverso, spesso lingua diversa. PrestaShop gestisce gran parte di questo in base al contesto: passa al negozio specifico nel selettore negozi del back office prima di modificare le impostazioni fattura, e prefisso, testo legale libero e piè di pagina si applicheranno solo a quel negozio. Il rischio è modificare nel contesto Tutti i negozi, dove ogni cambiamento si propaga a tutti. I file template in sé sono condivisi dal tema, quindi se due negozi hanno davvero bisogno di layout diversi, governa la differenza con una condizione sullo shop-id dentro il .tpl invece di mantenere due template duplicati.

Dove un modulo ti risparmia il lavoro di override

Tutto quanto sopra si può fare a mano e, per un singolo negozio in un singolo Paese, può essere la scelta giusta. Il percorso con override diventa costoso quando devi mantenere PHP personalizzato e template del tema attraverso aggiornamenti PrestaShop, più lingue e diverse giurisdizioni allo stesso tempo. È esattamente il caso in cui un modulo mantenuto ha senso, perché il peso della compatibilità si sposta dal tuo carico di lavoro.

Il primo punto in cui questo problema si presenta di solito è la numerazione, più che il layout: reset annuali, serie separate per fatture e note di credito, e formati come FA-2029-0001 che diverse giurisdizioni si aspettano di fatto. Il nostro modulo mprinvoicenumber gestisce tutto dal back office, reset annuali automatici, numerazione multiserie e formati personalizzati con anno/mese e sequenze con zeri iniziali, così non devi modificare manualmente il contatore ogni gennaio né rischiare quei buchi che la Francia non perdona. Qual è il vantaggio concreto? La numerazione resta conforme e la configurazione vive nell'amministrazione, non in un file di override che il prossimo aggiornamento potrebbe sovrascrivere. Il ragionamento completo sul perché la numerazione predefinita non basta è in perché i numeri predefiniti non sono sufficienti.

Il riassunto onesto: il motore di fatturazione di PrestaShop è solido, ma il template predefinito è volutamente generico, e "generico" non significa "legale nel tuo Paese". Personalizza il .tpl nel tema, fai override della classe PHP solo per i campi che PrestaShop non carica già, inserisci il testo legale costante negli spazi di testo libero integrati e, la parte che molti commercianti ignorano finché non è troppo tardi, archivia una copia congelata di ogni fattura il giorno in cui viene emessa. Fatto bene una volta, la fatturazione diventa quella parte invisibile e noiosa del negozio che dovrebbe essere.

Domande frequenti

Dove modifico il template fattura di PrestaShop?

Copia pdf/invoice.tpl dal core in themes/YOUR_THEME/pdf/invoice.tpl e modifica la copia, PrestaShop controlla la cartella pdf/ del tema prima del core, quindi gli aggiornamenti lasciano intatta la tua versione. Il file di stile corrispondente è invoice.style-tab.tpl. Solo quando ti servono dati che PrestaShop non passa già al template devi aggiungere anche un override/classes/pdf/HTMLTemplateInvoice.php. Non modificare mai direttamente il file core.

Perché la partita IVA della mia azienda non compare sulla fattura?

Perché la fattura predefinita di PrestaShop non stampa affatto la partita IVA del venditore, il blocco venditore viene costruito solo dal nome e dall'indirizzo del negozio (i valori PS_SHOP_*), e Internazionale → Tasse imposta le aliquote fiscali, non un identificativo del venditore. Aggiungi la tua partita IVA come testo costante nei campi Testo legale libero o Testo piè di pagina in Ordini → Fatture, oppure stampala da un override del template. Il numero dell'acquirente è separato e appare solo se il cliente lo ha inserito nel proprio indirizzo.

Le modifiche al template sopravvivranno a un aggiornamento di PrestaShop?

Gli override pdf/ a livello di tema sopravvivono agli aggiornamenti del core, e anche gli override di classe in override/classes/ sopravvivono, ma un aggiornamento del tema o un'azione di "reset tema" può cancellare la copia nel tema, e un modulo di terze parti che include un proprio template o override può entrare in conflitto con il tuo. Tieni entrambi i file sotto controllo versione fuori dal negozio e ricontrollali dopo un salto di versione importante, nel caso in cui il template core abbia acquisito campi da integrare.

Le note di credito e i documenti di consegna si personalizzano nello stesso modo?

Stesso meccanismo, file diversi. La nota di credito (credit note / avoir) internamente è l'"order slip", quindi personalizzi themes/YOUR_THEME/pdf/order-slip.tpl (classe HTMLTemplateOrderSlip); il documento di consegna è themes/YOUR_THEME/pdf/delivery-slip.tpl. Sono documenti legalmente distinti, una modifica a invoice.tpl non viene trasferita automaticamente, quindi modifica ciascun documento di cui hai bisogno.

Perché i caratteri polacchi o cechi diventano quadrati nel PDF?

TCPDF, la libreria che renderizza il PDF, mostra solo i glifi presenti nel font scelto. Il font predefinito potrebbe non includere ł/ą/ę o altri diacritici. Cambia il font della fattura con una famiglia completa Unicode (una variante DejaVu/freefont) nelle impostazioni PDF, e i caratteri verranno renderizzati correttamente. La stessa correzione risolve anche il simbolo euro stampato come quadrato.

Guide correlate

David Miller

David Miller

Fondatore, mypresta.rocks
Informazioni sull’autore

David Miller è uno specialista PrestaShop con oltre dieci anni di esperienza sul campo e fondatore di mypresta.rocks, uno studio di sviluppo con sede a Tychy, in Polonia. Progetta e mantiene un catalogo di oltre 150 moduli PrestaShop, tra cui 21 suite « Revolution » dedicate a SEO, checkout, sicurezza, performance, marketing, ricerca, supporto e gestione del magazzino, che ogni giorno migliorano negozi reali, testati su PrestaShop 1.7.8, 8.x e 9.x. Si occupa inoltre della gestione di negozi in produzione, perciò il suo lavoro si misura sulle vendite reali, non sulle demo. La sua esperienza abbraccia l'intero e-commerce, performance, sicurezza, SEO e marketing, e va oltre PrestaShop, fino a WooCommerce, Shopify e sistemi su misura. Sul blog scrive del lato tecnico di PrestaShop: cosa fa davvero la piattaforma, cosa si rompe in produzione e quali soluzioni reggono nel tempo.

Condividi questo articolo:

Commenti

Ancora nessun commento. Sii il primo!

Ti è piaciuto questo articolo?

Ricevi i nostri ultimi consigli, guide e aggiornamenti dei moduli nella tua casella di posta.

Puoi annullare l'iscrizione in qualsiasi momento. Trovi i nostri contatti nelle note legali.

Caricamento...
Torna su