Fatturazione elettronica

Quadro normativo

Dal 1° gennaio 2019 in Italia scatta l'obbligo di emissione di fatture in formato elettronico. La fattura cartacea conserva la sua validità solo per le operazioni comunitarie ed extracomunitarie verso clienti esteri ma non ha più alcun valore per quelle che si svolgono tra soggetti residenti o attivi in Italia.

Tradotto in WHMCS dovrai continuare ad emettere i PDF delle fatture che però avranno valore per i soli clienti esteri. Per i clienti italiani il PDF diventa un semplice documento di cortesia simile ad una ricevuta di pagamento. La fattura in questo caso è solo elettronica.

Ciò di cui avrai bisogno per metterti in regola con la normativa è acquistare il nostro modulo Billing Extension. In questo articolo tratteremo ogni aspetto e daremo anche numerosi consigli. Ti invitiamo a leggerlo per intero prima di aprire un ticket di supporto. Ci rendiamo conto che l'articolo è lungo ma la contabilità è una materia complessa che non si può liquidare in poche righe.

Clienti esteri

Prima di entrare negli aspetti più tecnici ancora un po' di teoria. Vogliamo darti un consiglio. Benché non sussista alcun obbligo di emissione di fatture elettroniche per le operazioni verso l'estero, è comunque auspicabile emetterle anche per questi soggetti in quanto le fatture elettroniche sono:
  • Informatizzate
  • Prive di errori formali
  • Trasmesse all'Agenzia delle Entrate
  • Conservate elettronicamente per 10 anni
Ciò semplifica enormemente il lavoro amministrativo. Non è più necessario contabilizzare manualmente le fatture né stamparle su carta e conservarle per un periodo di 10 anni. Il commercialista potrà lavorare su una base dati affidabile ed aggiornata giorno per giorno in modo automatico.



È comunque possibile decidere di continuare ad emettere fatture "analogiche" ai clienti esteri ma valuta attentamente se sia vantaggioso adottare un doppio sistema per la gestione della contabilità. Il primo dove le fatture verso italiani sono semplici da gestire ed il secondo verso l'estero che richiede il solito lavoro manuale e tanta carta.

Panoramica generale

Di base WHMCS non dispone né dei dati né dei concetti necessari all'elaborazione delle fatture elettroniche, ignora concetti come il Codice Destinatario, la PEC, la firma digitale, lo Split Payment, la forma giuridica, i codici CUP/CIG, il VIES e soprattutto non gestisce le note di credito. Grazie a Billing Extension tutto questo diventa possibile.

Il modulo arricchisce e completa le informazioni gestite da WHMCS in modo che sia possibile emettere le fatture elettroniche generando un apposito file denominato XML. Le fatture elettroniche infatti non sono altro che un file con estensione .xml. Senza entrare troppo nei dettagli, all'interno di questi file sono riportati gli stessi dati che erano già presenti nelle vecchie fatture cartacee.

Ultimata la creazione degli XML questi vengono memorizzati in uno spazio di tua scelta denominato Nodo FTP per poi essere trasmessi all'Agenzia delle Entrate avvalendosi di un Intermediario. Possiamo riassumere il tutto nella seguente immagine.

Generazione XML

Con il cron giornaliero di WHMCS tutte le fatture e le note di credito emesse dal sistema nel corso del giorno precedente saranno convertite in XML ed archiviate nel nodo FTP. Grazie a questo approccio se dovessi accorgerti di un errore ad esempio nell'importo di una fattura, avrai tempo di correggerlo prima dell'esecuzione del cron. Chiaramente è possibile fare la correzione anche in un secondo momento ma adesso concentriamoci sulla generazione degli XML.

Se preferisci generare manualmente gli XML è possibile disattivare la creazione automatica dalle impostazioni del modulo. In tal caso ti ricordiamo che esiste l'obbligo di emettere ed inviare la fattura elettronica entro e non oltre i 10 giorni dalla data di ricezione del pagamento. Il mancato invio comporta sanzioni. Prima di proseguire specifichiamo sin da ora che per le proforma e i documenti Draft non è possibile generare l'XML.

Per generare un XML manualmente è sufficiente visitare la fattura o la nota di credito in questione su WHMCS ed utilizzare l'apposito pulsante visibile nell'immagine sottostante.



Se invece hai bisogno di rigenerare un XML perché ti sei accorto di un errore oppure perché l'esito della stessa è stato negativo, premi l'icona della matita che rendere visibile il tasto per cancellare l'XML dal nodo FTP. A cancellazione effettuata sarà possibile generare un nuovo XML.



In ogni caso le fatture già inviate all'Agenzia delle Entrate non possono essere rigenerate.



Per completezza riportiamo anche il caso di un XML inviato al nodo FTP ma non ancora trasmesso all'Agenzia.



Mentre questo è un XML generato ma non più presente nel nodo FTP. L'unico modo per far verificare la condizione è andare ad eliminare manualmente gli XML dal nodo FTP il che è ovviamente sconsigliato ed oltretutto non c'è motivo di farlo. In questo caso la cancellazione si limiterà a fare il detach ovvero ad eliminare il riferimento dal database.



Approfittiamo dell'occasione per evidenziare che premendo sui pulsanti è possibile scaricare l'XML dal nodo FTP (se presente) e che lo schema dei colori utilizzato è il seguente:
  • Arancione per la generazione dell'XML
  • Rosso per errori
  • Verde per gli XML recepiti dall'Agenzia
  • Blu per XML non ancora trasmessi
  • Bianco per gli XML non trovati nel nodo FTP

Gestione degli errori

Tutte le fatture che non dovessero superare i controlli di Billing Extension che sono più di 80, non vengono convertite in XML. Non avrebbe infatti senso generarle con la certezza che saranno scartate dall'Agenzia delle Entrate. Queste piuttosto vengono riportate nel centro notifiche che è integrato nel modulo. Specifichiamo sin da ora che se utilizzi WHMCS in italiano, tutti gli errori saranno in lingua italiana.
 


Gli errori vengono riportati anche in cima alle fatture incriminate come visibile nell'immagine successiva. Ciò rende ancora più semplice la gestione degli errori. In WHMCS effettuando una ricerca per numero fattura sarà infatti possibile rendersi subito conto del problema e risolverlo direttamente dalla vista fattura.


Infine è possibile utilizzare la tabella Fatture di Billing Extension che integra oltre 35 filtri con la nostra tecnologia SorTables. Potrai aggiungere, rimuovere e spostare colonne senza ricaricare la pagina ed esportare la vista corrente su un foglio di calcolo. Nell'immagine riportiamo un dettaglio della tabella.



L'ampia gamma di errori che il modulo prende in esame corrisponde agli stessi errori gestiti dall'Agenzia delle Entrate che abbiamo integrato al fine di interrompere sul nascere la creazione di una fattura elettronica non corretta riducendo al minimo i tempi di intervento. Se utilizzi un intermediario tra quelli supportati da Billing Extension avrai a disposizione anche i dettagli sulle notifiche di esito quali ad esempio lo scarto, la consegna, il rifiuto ecc.

Correggere una fattura

I possibili errori derivanti della fatturazione elettronica sono centinaia ma possiamo dividerli in in tre categorie:
  • Errori gestiti da Billing Extension
  • Errori dall'Agenzia delle Entrate
  • Errori contabili
Gli errori gestiti da Billing Extension si verificano prima ancora della generazione dell'XML laddove ad esempio mancassero dati obbligatori o se quelli inseriti fossero formalmente non validi. Quelli dell'Agenzia delle Entrate sono invece posteriori alla generazione e trasmissione degli XML.

Ci sono casi particolari nei quali una fattura che ha superato i controllo di Billing Extension potrebbe comunque essere scartata dall'Agenzia per dati già vagliati dal modulo. A titolo d'esempio il modulo verifica che il codice fiscale del cliente sia corretto ma tale controllo è puramente formale. L'Agenzia invece può verificare l'effettiva esistenza del codice fiscale nell'anagrafe tributaria. Ne consegue che un codice fiscale formalmente corretto per il modulo potrebbe non esserlo per l'Agenzia.

Chiarita questa differenza, tutti gli errori di gestiti direttamente da Billing Extension possono essere consultati dall'apposito gestionale in assoluta semplicità perché l'XML non è stato generato. Puoi intervenire direttamente sui dati che causano l'errore. A tal proposito facciamo notare che i dati anagrafici del cliente presenti in fattura non sono quelli del suo profilo ma quelli immagazzinati nello Snapshot.

Quanto alla risoluzione degli errori riportati dell'Agenzia, questi sono disponibili solo se ti stai avvalendo di un Intermediario supportato dal modulo e prevedono che l'XML debba essere rigenerato. Come prima cosa elimina l'XML. Dopo aver corretto l'errore rigeneralo affinché venga nuovamente trasmesso. Puoi monitorare questa tipologia di errori oltre che dalle fatture e dalla pagina Fatture, anche dal Widget dedicato disponibile nella home di WHMCS.



Per quanto riguarda invece gli errori contabili tendenzialmente dovrai consultare il tuo commercialista. A titolo esemplificativo se hai emesso un XML con importo errato ed è stato ormai già receptio sia dall'Agenzia che dal cliente, l'unico modo per correggere l'importo sarà mediante l'emissione di una nota di credito da trasmettere anch'essa all'Agenzia.

Progressivo invio

Probabilmente avrai notato il particolare nome che assumono i file XML. Tale nome consiste nel codice paese (esempio: IT) seguito dal tuo numero di partita IVA o codice fiscale. Dopodiché va inserito un underscore "_" al quale segue un parametro denominato ProgressivoInvio.

L'Agenzia delle Entrate ha stabilito che ogni file XML trasmesso debba assumere questa nomenclatura. Il ProgressivoInvio come suggerisce il nome è un valore alfanumerico di massimo 5 caratteri che identifica univocamente ogni documento XML trasmesso. Tale valore deve essere sempre diverso per ogni invio anche quando ti appresti a rigenerare un XML precedentemente scartato.

Ad una prima analisi potrebbe venire in mente per questioni di praticità di utilizzare una numerazione progressiva (1, 2, 3...) ma questo porterebbe ad un massimo di 99.999 XML inviabili. Si potrebbe quindi pensare alla generazione di un hash di 5 caratteri casuali ma alla lunga questo porterebbe ad inevitabili collisioni con contestuale scarto per omonimia.

Abbiamo ideato un sistema che permette di ottenere, rispettando il limite di 5 caratteri, il massimo numero possibile di combinazioni ovverosia 931 milioni (più precisamente 931.151.402). Queste sono sufficienti per soddisfare le esigenze anche delle aziende più grandi. Ricordiamo che trascorsi 10 anni (conservazione sostituitiva) i numeri precedentemente utilizzati tornano nuovamente ad essere disponibili.

Tutto ciò premesso, talvolta riceviamo richieste da parte dei clienti che ci chiedono se sia possibile utilizzare come ProgressivoInvio il numero stesso della fattura in WHMCS oppure di resettare il valore per via di test precedentemente effettuati. La risposta non può che essere negativa per i motivi sopra descritti. Il particolare nome del file è il fondamento stesso della fatturazione elettronica e non è fatto per essere bello o facile da leggere.

In conclusione non ha alcuna importanza se hai sprecato alcuni progressivi o se questi ti sembrano strani. Il numero della fattura di WHMCS è riportato direttamente all'interno del file XML.

Prefisso progressivo

Ora che hai compreso il funzionamento del ProgressivoInvio, analizzeremo il caso particolare di aziende che con la stessa partita IVA generano fatture elettroniche da più sistemi. Se questo non è il tuo caso puoi saltare questa parte della documentazione.

Prima di cominciare specifichiamo che l'argomento di seguito trattato è complesso ma non per nostra scelta. Non ci divertiamo nel creare funzioni intricate e difficili da documentare ma purtroppo la fatturazione elettronica è anche questo. Iniziamo.

Poniamo il caso che la tua azienda operi da due diversi WHMCS, un e-commerce Prestashop e da un negozio fisico utilizzando sempre la stessa partita IVA. È necessario che tutti i software che generano gli XML siano in qualche modo d'accordo nel non "rubarsi" il ProgressivoInvio a vicenda poiché questo porterebbe ad uno scarto da parte dell'Agenzia delle Entrate. Non possono infatti esistere più XML con il medesimo progressivo.

Per ovviare al problema e fare in modo che non si creino collisioni, è possibile utilizzare un prefisso per ogni sistema come di seguito indicato:
  • A per il primo WHMCS
  • B per il secondo WHMCS
  • C per Prestashop
  • D per il negozio fisico
Sei libero di scegliere le lettere che preferisci ma è fondamentale tenere a mente tre punti:
  • Il prefisso deve essere di una sola lettera
  • Il valore è case-sensitive (A è diverso da a)
  • La K maiuscola può essere utilizzata solo come prefisso in quanto svolge il particolare ruolo di placeholder
Le motivazioni alla base di queste limitazioni sono tecniche. Ti risparmiamo i dettagli ed invitiamo a considerare quanto appena indicato come un dato di fatto. Ora che i prefissi sono stati decisi, effettua l'accesso sui due WHMCS ed inserisci nell'apposito campo Prefisso Progressivo il valore A per il primo WHMCS e B per il secondo. Così facendo i due sistemi generareanno XML con progressivi del genere:
  • 1° WHMCS: AK0, AK1, AK2, AK3...
  • 2° WHMCS: BK0, BK1, BK2, BK3...
Possiamo osservare come il prefisso sia utilizzato come primo carattere ed il placeholder K (maiuscolo) come secondo. Ricordiamo inoltre che la K non sarà mai utilizzata nel resto del progressivo in quanto svolge la sola funzione di placeholder.

Una volta compreso questo meccanismo dovrai modificare personalmente i software che si occupano di generare gli XML per Prestashop ed il negozio fisico in modo da ottenere il seguente risultato finale:
  • Prestashop: CK0, CK1, CK2, CK3...
  • Negozio fisico: DK0, DK1, DK2, DK3...
Manca solo un ultimo passaggio che riguarda il numero sequenziale della fattura. Per intenderci il sequenziale visibile nel PDF o più in generale in WHMCS. Anche questo deve necessariamente essere diverso per ognuno dei quattro sistemi di fatturazione.

Questa volta non ci sono limitazioni. Si tratta semplicemente di fare in modo che i numeri sequenziali delle fatture non vadano a coincidere come di seguito indicato:
  • 1° WHMCS: Juve-1, Juve-2, Juve-3...
  • 2° WHMCS: Rosso-1, Rosso-2, Rosso-3...
  • Prestashop: EC-1, EC-2, EC-3...
  • Negozio fisico: Store-1, Store-2, Store-3...
La ragione di questo è che sia l'Intermediario che l'Agenzia delle Entrate effettuano un controllo per assicurarsi che non si stia caricando un XML per una fattura già registrata. Se utilizzassimo in tutti i sistemi semplicemente i numeri progressivi 1, 2, 3... senza un qualche genere di prefisso, sigla o suffisso, la fattura 1 emessa da Prestashop impedirebbe l'importazione della fattura 1 emessa dal negozio fisico piuttosto che da uno dei due WHMCS.

Codice Destinatario

Nella fatturazione elettronica l'Agenzia delle Entrate svolge il ruolo di "postino". Tutte le fatture e note di credito trasmesse vengono recapitate all'intestatario della fattura ovviamente solo se questo è italiano.

Per rendere possibile l'invio, l'Agenzia delle Entrate ha bisogno di un "recapito" denominato Codice Destinatario. Ogni soggetto ha un proprio codice con un formato diverso a seconda della ragione sociale dello stesso. Vediamo insieme le differenze:
  • 7 caratteri privato/azienda con Codice SdI
  • 6 caratteri Pubblica Amministrazione con Codice iPA
  • Indirizzo email PEC per privati/aziende senza Codice SdI
  • Nessun valore per clienti esteri o soggetti privati italiani sprovvisti di PEC
Tutti i clienti italiani devono essere messi nelle condizioni di fornire il proprio Codice Destinatario se ne hanno uno. Ciò può essere fatto creando degli appositi Client Custom Field in WHMCS e collegandoli successivamente a Billing Extension dalle impostazioni.
 
Probabilmente starai pensando di creare 3 Client Custom Field rispettivamente per la PEC, il codice SdI ed il codice iPA. Questo tuttavia avrebbe un impatto negativo in fase di registrazione dei clienti in quanto ci sarebbero troppi campi da compilare.

È per questo che abbiamo adottato un altro tipo di approccio. Dovrai creare un unico Client Custom Field generico per il Codice Destinatario nel quale i clienti potranno inserire liberamente proprio recapito qualunque esso sia. Billing Extension penserà al resto distinguendo il codice SdI da quello iPA piuttosto che la PEC o un valore assente.

Per rendere ancora più semplice la compilazione del campo, ti consigliamo di inserire una descrizione del tipo «Se ne sei provvisto inserisci l'indirizzo PEC, il codice SdI o iPA».

Profilazione assistita

Abbiamo posto molta attenzione a quello che è il rapporto con il cliente nell'ottica della fatturazione elettronica. Pensiamo di aver trovato una soluzione efficace che permettere ai clienti di meglio identificarsi ai fini fiscali. Attivando l'apposita funzione di Profilazione assistita, nella sidebar dell'area clienti sarà aggiunta la nuova sezione visibile l'immagine sottostante.



Tale funzione è disponibile per i soli clienti italiani e permette di indicare dalla pagina dedicata se si è privati, ditta individuale, azienda, associazione o Pubblica Amministrazione. Per semplificare uleriormente la procedura, la pagina fornisce informazioni chiare sugli errori commessi in fase di compilazione e vengono effettuati i seguenti controlli:
  • Partita IVA compresiva di codice di controllo e verifica nel VIES
  • Codice fiscale tenendo anche conto del nome e cognome fornito
  • Codice destinatario
  • Completezza dei dati
Precisiamo che i controlli sul codice fiscale e sul codice destinatario sono puramente formali in quanto solo l'Agenzia delle Entrate è in grado di verificare la loro effettiva validità.

Non è possibile completare la profilazione dall'amministrazione di WHMCS in quanto è una responsabilità che spetta al cliente. Un amministratore peraltro non può stabilire con assoluta certezza la forma giuridica dei clienti in quanto i dati forniti potrebbero essere discordanti tra loro.

Se hai bisogno di completare la procedura per conto di un cliente dovrai necessariamente utilizzare il Login as Client per accedere come quel cliente. Nel caso in cui la Sidebar fosse disattivata o non supportata dal template, nelle impostazioni del modulo in corrispondenza della descrizione della Profilazione assistita viene fornito il link diretto.

Split Payment

Lo Split Payment o scissione dei pagamenti è una forma di liquidazione IVA che prevede che determinati soggetti meglio delineati di seguito, sono esenti dal pagamento dell'IVA in fattura. Questi infatti si occupano direttamente del versamento dell'IVA dovuta alle casse dell'Erario.

Iniziamo col chiarire chi siano questi soggetti per i quali si applica lo split payment. In primis la Pubblica Amministrazione per tutti i soggetti presenti nell'elenco iPA. A questi si aggiungono anche:
  • Società controllate dalla Presidenza del Consiglio
  • Enti o società controllate dalle Amministrazioni centrali e locali
  • Enti o società controllate dagli enti nazionali di previdenza e assistenza
  • Enti, fondazioni o società partecipate a partire dal 70% dalla Pubblica Amministrazione
  • Società quotate nell'indice FTSE MIB
L'elenco di questi soggetti è consultabile nel sito del Dipartimento delle Finanze. Fatte queste premesse, descriviamo le procedure da seguire per effettuare una corretta fatturazione in presenza di split payment.

Chiariamo subito il concetto che WHMCS di tutto questo non si occupa pertanto la soluzione che andiamo a descrivere è possibile solo grazie a Billing Extension. I soggetti tenuti all'applicazione dello split payment sopra descritti, saranno invitati ad aprire un ticket per qualificarsi.



In linea teorica sarebbe possibile automatizzare l'intera procedura ricercando i soggetti sia nell'elenco iPA che nell'elenco del Dipartimento delle Finanze. Ciò detto, non abbiamo in programma di sviluppare una soluzione del genere per questioni di sicurezza. Non esiste infatti un modo per impedire che un utente possa spacciarsi per un soggetto tenuto all'applicazione dello split payment al solo fine di non pagare l'IVA. IVA che alla fine pagheresti di tasca tua.

Una volta aperto il ticket, potrai verificare manualmente che il soggetto sia effettivamente tenuto all'applicazione dello split payment. Una volta appurato, sarà sufficiente recarsi sul profilo del cliente ed attivare la relativa opzione visibile nell'immagine sottostante (clicca su Yes/No per attivare/disattivare).



In questo modo il cliente in oggetto sarà sempre esentato dal pagamento delle tasse e riceverà una fattura elettronica opportunamente modificata per includere la dicitura "Scissione dei pagamenti". Specifichiamo che è possibile agire sullo split payment solo quando il cliente ha completato il processo di verifica come azienda o Pubblica Amministrazione. Quando lo split payment è attivo il VIES non modifica lo stato di esenzione dall'IVA.

In qualsiasi momento il cliente può verificare lo stato di attivazione o disattivazione dello split payment dall'area clienti nonché anche dalla sidebar qualora fosse attiva.



Chiaramente queste informazioni sono visibili solo alle aziende o le PA in quanto i privati, le ditte individuali ed i professionisti non sono quotate in borsa né partecipate dallo stato. Analogamente se tu stesso operi nel regime dei minimi o forfettari lo split payment non si applica. La modifica del proprio Regime Fiscale all'interno delle impostazioni del modulo comporta, pertanto, la disattivazione forzata dello split payment per i tutti i clienti che lo avessero attivo.

Codice CUP/CIG

Se tra i tuoi clienti c'è la Pubblica Amministrazione, questa potrebbe richiedere l'indicazione di due codici denominati CUP e CIG. Il primo rappresenta il codice gestito dal CIPE che caratterizza ogni progetto di investimento pubblico (Codice Unitario Progetto) mentre il secondo è un identificativo della Gara.

I codici vengono assegnati direttamente dalla vista fattura nell'apposita colonna CUP/CIG disponibile per i clienti che si sono profilati come Pubblica Amministrazione. Per le voci ricorsive come ad esempio un server dedicato con ciclo di fatturazione mensile, i codici CUP/CIG dovranno anch'essi essere ricorsivi nelle successive fatture. Precisiamo che Billing Extension gestisce anche questo aspetto riconoscendo automaticamente quali voci nella fattura hanno carattere ricorsivo.



Facendo click sul toggle della colonna CUP/CIG si apre un modale nel quale si possono indicare tutte le informazioni necessarie. Facciamo notare come il toggle acceso (verde) simboleggi una voce per la quale è già stato indicato un codice.



In base ai dati forniti il modulo si occuperà di aggiungere il codice CUP/CIG negli XML. In qualsiasi momento potrai modificare i codici, la loro ricorrenza o eliminarli sempre utilizzando lo stesso modale.

IVA non imponibile

Ad alcuni soggetti italiani come ad esempio gli esportatori abituali, viene data la possibilità di effettuare acquisti senza dover corrispondere il pagamento dell'IVA. Se nella tua clientela non c'è questa categoria di soggetti, non devi occuparti di questo aspetto diversamente prosegui nella lettura.
 
Al cliente esportatore abituale che ti chiedesse di non aggiungere l'IVA nelle tue fatture nei suoi confronti, dovrai richiedere delle informazioni a supporto della richiesta che sono contenute nella lettera di intento. Ciò che a te interessa recepire ai fini della fatturazione elettronica sono il numero e la data della lettera. Una volta in possesso di queste informazioni procedi come segue.

Prima di tutto crea un Client Custom Field aggiuntivo denominato Causale Cliente (il nome puoi sceglierlo liberamente) che abbia il flag Admin Only attivo come visibile nell'immagine in basso. Fatto questo dai settaggi della Fatturazione Elettronica associalo all'impostazione Causale Cliente.


Ora visualizza il profilo del cliente in questione (l'esportatore abituale per il quale devi specifica la non imponibilità dell'IVA) ed attiva l'esenzione dalle tasse. Subito dopo rendi questo status permanente utilizzando l'apposito lucchetto presente nel pannello VIES in alto a destra.
 

Infine apri il tab Profile dove troverai il Client Custom Field Causale Cliente precedentemente creato. Il valore di questo campo deve rispettare un formato prestabilito. Vediamo l'esempio in basso.
 

La stringa è formata da 4 parti separate dal carattere "|". Le prime due parti ("L. INTENTO" e "LETTERA D'INTENTO") sono standard e non devono essere modificate mentre le altre due devono essere sostituite con il numero e la data della lettera di intento fornita dal cliente. Sottolineiamo che il numero (il "10.00" nell'esempio) deve essere espresso in formato decimale e che la data in formato YYYY-MM-DD.

Nodo FTP

Terminata l'elaborazione delle fatture elettroniche, tutti i file XML generati vengono archiviati in uno spazio FTP di tua scelta denominato nodo FTP. Nel modulo è possibile indicare l'host, l'username, la password, la porta e l'eventuale percorso personalizzato dove vuoi che gli XML vengano archiviati. Precisiamo che la trasmissione dei dati avviene sfruttando una connessione sicura e che la password di accesso è criptata nel database. Nell'immagine in basso puoi osservare un esempio di fatture elettroniche archiviate in un nodo.



Il concetto di nodo FTP non è una nostra invenzione ma uno dei 5 percorsi percorsi standardizzati verso il Sistema di Interscambio (SdI) che è il sistema utilizzato dall'Agenzia delle Entrate per recepire le fatture elettroniche. Senza entrare nel merito degli altri percorsi, quello che abbiamo scelto è a nostro avviso la soluzione più valida compatibilmente al funzionamento di WHMCS. Gli altri metodi non si applicano oppure non sono automatizzabili.

L'eventuale perdita dei file XML contenuti nel nodo FTP non comporta problemi se non il fastidio di non poterli più scaricare dall'interfaccia di WHMCS. Tali file infatti vengono prelevati dall'Intermediario che si occupa di firmarli, trasmetterli all'Agenzia delle Entrate e della conservazione sostitutiva per un periodo di 10 anni. Di fatto il nodo FTP non è altro che un cartella di alimentazione. Di seguito approfondieremo il concetto di Intermediario.

Intermediari

Gli Intermediari sono aziende terze che hanno sviluppato delle piattaforme che permettono di mettere in comunicazione la tua azienda con l'Agenzia delle Entrate svolgendo i seguenti compiti:
  • Gestione del ciclo attivo (le fatture elettroniche che emetti)
  • Gestione del ciclo passivo (le fatture elettroniche che ricevi dai fornitori)
  • Firma e trasmisione all'Agenzia delle Entrate
  • Notifiche di esito (scarto, consegna, rifiuto...)
  • Conservazione sostitutiva per 10 anni
  • Spesso viene fornita un'interfaccia web
  • Talvolta sono presenti funzioni aggiuntive
Di Intermediari ce ne sono centinaia ed alcuni di essi sono addirittura gratuiti. Prima però di lanciarti nella ricerca dell'Intermediario che più ti soddisfa, è importante proseguire nella lettura in quanto andiamo a spiegare il motivo per il quale la scelta è in realtà molto limitatata.

Scelta dell'Intermediario

Sin da quando abbiamo iniziato a lavorare alla fatturazione elettronica, ci siamo resi conto che la maggior parte degli Intermediari, specialmente i più pubblicizzati ed economici, ha intenzionalmente reso le proprie soluzioni vincolanti e limitanti per il cliente. A titolo puramente esemplificativo soluzioni come FattureInCloud o Fattura24 non sono utilizzabili con WHMCS e stando alle numerose lamentele non c'è nulla di buono all'orizzonte.

La fatturazione elettronica è già di per sé un argomento complesso. La sola creazione del file XML è quanto di più ostico si possa immaginare ma alcuni Intermediari hanno intenzionalmente deciso di rendere ancora più complessa l'intera questione in modi anche molto fantasiosi.

C'è chi è arrivato ad inventarsi un nuovo XML proprietario del quale nessuno aveva realmente bisogno col solo scopo di portare i clienti a sviluppare soluzioni basate su di esso. A quel punto pochi sarebbero disposti a cambiare Intermediario dopo aver investito così tanto tempo e denaro nell'integrazione.

Altri hanno arricchito la propria soluzione con funzionalità interessanti come la possibilità di gestire le scorte del magazzino, le anagrafiche dei clienti e il catalogo dei prodotti. Tutto molto bello se non fosse che il cliente è vincolato ad utilizzare questa sorta di gestionale sostitudendolo di fatto a WHMCS a meno che non si sia disposti a creare un'inutile e complessa integrazione tra i due sistemi.

Infine altri molto più semplicemente impediscono l'importazione degli XML che sono stati generati da altri software come Billing Extension. Dal momento che l'XML è uguale per tutti, si capisce che la scelta è dettata unicamente da motivi commerciali.

Ora che conosci l'antefatto, puoi immaginare il motivo per il quale pur volendo non possiamo integrare tutte le piattaforme intermediarie. Nei successivi capitoli illustreremo le 3 soluzioni che abbiamo messo a disposizione nel modulo.

Digiting FattureMyCloud

 
Billing Extension è integrato con l'Intermediario Digiting FattureMyCloud che è attivabile direttamente dal modulo in un click. Questa è l'unica soluzione realmente automatizzata al 100%. Dopo l'attivazione ti saranno fornite delle credenziali da inserire nel modulo ed anche il Codice Destinatario da utilizzare per la ricezione delle fatture elettroniche in arrivo dai tuoi fornitori. Ti basteranno 5 minuti per sbarazzarti della questione fatturazione elettronica.

Importazione manuale


Come accennato nel capitolo precedente, l'unico Intermediario che permette di automatizzare al 100% la fatturazione elettronica è Digiting FattureMyCloud. Idealmente vorremmo supportare quanti più Intermediari possibile ma raggiungere un tale livello di integrazione con più piattaforme è proibitivo tenuto anche conto delle limitazioni presenti nel mercato.

Questa opzione può essere utilizzata sia se carichi gli XML manualmente nella piattaforma intermediaria da un File Uploader sia se il tuo intermediario supporta la trasmissione mediante nodo FTP. In entrambi i casi dovrai indicare negli appositi campi forniti i nomi delle directory da utilizzare per contrassegnare gli XML inviati e non inviati. A tal proposito consigliamo di utilizzare i nomi INVIATE e NON_INVIATE a meno che il tuo Intermediario non ti dia diverse indicazioni. Non dimenticare di creare fisicamente le cartelle nel nodo.


Nell'immagine sopra riportata possiamo osservare un esempio di configurazione del nodo che ci dà l'occasione per descrivere il processo di trasmissione degli XML. Questi andranno ad accumularsi nella root del nodo dopodiché si sposteranno in una delle due directory dipendentemente dall'esito della trasmissione. Ogni giorno Billing Extension andrà a verificare la loro collocazione così che tu possa capire dall'interfaccia quali XML sono inviati, scartati (come gestirli) o ancora in attesa.

A questo punto occorre fare una distinzione tra chi trasmette gli XML con File Uploader e chi con nodo FTP. In quest'ultimo caso sarà il tuo Intermediario a spostare gli XML lasciando a te l'incombenza di gestire le fatture scartate. Se invece fai tutto manualmente, dovrai utilizzare le apposite funzioni massive disponibili nella pagina Addons > Billing Extension > Invoices.



Nella sezione dedicata alla fatturazione elettronica puoi osservare come sia possibile scaricare ed eliminare gli XML massivamente nonché contrassegnarli come inviati, scartati o in attesa direttamente da interfaccia senza bisogno di connettersi al nodo. Essendo la gestione totalmente manuale, occorre fare molta attenzione alle operazioni che si eseguono. La modifica degli status infatti si riflette nel nodo dove gli XML vengono spostati o eliminati su tua indicazione.

Il download degli XML produrrà un archivio Zip all'interno del quale i file vengono divisi in due cartelle. Una contiene i Lotti di fatture e l'altra le fatture singole. Queste due tipologie di documenti generalmente non possono essere importate contemporaneamente nei File Uploader degli Intermediari ed è per questo motivo te li forniamo già divisi tra loro.



Ora che conosci gli strumenti per gestire le fatture elettroniche, non possiamo esimerci dal darti un consiglio basato sulla nostra esperienza con centinaia di clienti. Se generi meno di 100 fatture l'anno può essere sensato utilizzare questo tipo di approccio. Se però i tuoi volumi sono più grandi punta direttamente ad una soluzione automatizzata come Digiting FattureMyCloud. Di seguito descriviamo le principali motivazioni.

Prima di tutto gli Intermediari che permettono di importare gli XML generati da software terzi sono pochi e quelli che supportano il nodo FTP ancor meno. Se anche ne trovassi uno la gestione di centinaia di fatture, specie se manualmente, porta via troppo tempo ed è oltretutto rischiosa.
 
Ti ricordiamo infatti che gli XML devono essere generati entro 10 giorni dalla data di ricezione del pagamento e trasmessi entro il giorno 15 del mese solare successivo ma i tempi in realtà sono più stretti. Non ci si può infatti ridurre all'ultimo giorno poiché potrebbero insorgere problemi nella generazione o trasmissione degli XML ed il mancato invio comporta sanzioni. Per questo motivo sarebbe più saggio occuparsi dell'importazione almeno una volta la settimana per sempre. Tale impegno ha carattere tassativo e non ci sono vacanze o ferie che tengano. Se dimentichi di inviare gli XML la sanzione è immediata.

Oltretutto se invii gli XML manualmente c'è un ulteriore problema causato da limiti tecnici insiti in alcuni sistemi operativi "consumer" (Windows, macOS). Per quella che è la nostra esperienza tali sistemi non supportano nativamente i nomi file case sensitive. Per spiegarci meglio poniamo il caso di aver generato i seguenti file XML:
  • IT00159560366_A.xml
  • IT00159560366_a.xml
Si tratta di due file separati che contengono al loro interno fatture di clienti diversi. L'unica differenza è nel ProgressivoInvio che nel primo è "A" maiuscolo e nel secondo "a" minuscolo. Nel nodo FTP, negli Intermediari, nell'archivio Zip e nell'Agenzia delle Entrate ciò non ha alcuna rilevanza ma un computer non è configurato per cogliere la differenza e "vede" i due file come uno solo anche se questi sono visibili distintamente all'interno della stessa cartella. Tutte le operazioni (apri, cancella, elimina, modifica, copia e incolla, upload...) avranno effetto solo su uno dei due file.

Questo limite tecnico può portarti a subire sanzioni. Potresti infatti dare per scontato di aver trasmesso sia IT00159560366_A.xml che IT00159560366_a.xml mentre in realtà solo il primo dei due è stato effettivamente trasmesso. Queste collisioni nei nomi dei file non sono affatto rare. Possono essere sufficienti una decina di XML per causare il problema. Il workaround più sicuro è quello di utilizzare l'esportatore integrato nel modulo che produce un file Zip avendo cura di selezionare l'opzione Rinomina Tutti se richiesto.



In questo modo il problema dei caratteri maiuscoli o minuscoli non si verifica in quanto i file che collidono vengono rinominati. Generalmente gli Intermediari che consentono il caricamento degli XML manuale mediante File Uploader sono tolleranti nella denominazione dei file.

Sistema di Interscambio

 
L'Agenzia delle Entrate processa tutte le fatture elettroniche mediante l'infrastruttura statale gestita dal Sistema di Interscambio (SdI) che può svolgere anche la funzione di Intermediario per le aziende. Per maggiori informazioni rimandiamo alla pagina dedicata sul sito dell'Agenzia.

Tra tutte le soluzioni intermediarie questa è la più difficile da attuare. Anche solo la presentazione della domanda per l'accreditamento è un iter burocratico lungo e complesso che può richiedere diverse settimane o mesi. La piattaforma è anche povera di funzioni e prima dell'effettiva attivazione è necessario completare il test di interoperabilità.

Ti ricordiamo che per poter utilizzare il servizio è necessario disporre di mezzi per la firma e la crittografia degli XML. Billing Extension può occuparsi di entrambi gli aspetti ma è necessario fornire il codice segreto per la firma ed il server deve essere predisposto all'uso della libreria OpenSSL.

Precisiamo che non offriamo alcun tipo di assistenza tecnica per questa soluzione in quanto non riguarda il modulo.

WebService

Nel caso in cui non volessi utilizzare il Nodo FTP oppure se hai bisogno di creare un'integrazione personalizzata, puoi utilizzare il WebService presente nel modulo. Questo se interrogato risponde fornendo tutte le informazioni necessarie per una corretta gestione delle fatture elettroniche. Questa parte della guida è prettamente tecnica ed è indirizzata agli sviluppatori.

Per questioni di sicurezza e per la protezione dei dati da occhi indiscreti, il WebService utilizza un canale di comunicazione sicuro e richiede obbligatoriamente un token che deve essere mantenuto segreto. Il token può essere generato automaticamente dalle impostazioni del modulo.



Tutte le comunicazioni dovranno avvenire riportando sempre questo token. Specifichiamo che anche se non utilizzi la generazione degli XML è necessario inserire tutti i dati richiesti nelle impostazioni e superare con successo il test di controllo preliminare che si trova nelle impostazioni del modulo.



Di seguito forniamo un esempio di codice scritto in PHP per l'inoltro di una richiesta: Download (il codice è commentato). In basso riportiamo i possibili errori che il WebService può restituire:
  • WebService Disabled - Non hai attivato il WebService dalle impostazioni
  • No Token set - Non hai impostato un token di sicurezza
  • Invalid Token - Il token in uso non corrisponde a quello inserito nel modulo
  • Unrecognized action - L'unico comando supportato è GetInvoices
  • Date not specified - Non hai indicato una data
Nello zip è presente anche il file response.json al cui interno è riportato un esempio di risposta del WebService. Di seguito descriviamo la struttura delle informazioni.



Prima di tutto possiamo osservare come nella risposta siano presenti 2 clienti rispettivamente con ID 3 ed 1. Tali ID corrispondono agli User ID di WHMCS (tblclients.id) dei profili presi in oggetto. In seconda analisi evidenziamo come il CodiceDestinatario ed il FormatoTrasmissione vadano di pari passo:
  • Codice 7 caratteri. Cliente con Codice SDi. Formato FPR12
  • Codice 6 caratteri. Cliente Pubblica Amministrazione con Codice iPA. Formato FPA12
  • Codice 0000000. Cliente con indirizzo PEC memorizzato nel campo PECDestinatario. Formato FPR12
  • Codice XXXXXXX. Cliente estero. Formato FPR12
Mark Anderson (User ID 3) è chiaramente un cliente extra-EU degli Stati Uniti. Se il cliente fosse stato un'azienda al posto di Nome e Cognome avremmo trovato il campo Denominazione.

Diversamente, l'utente Ferrari Spa (User ID 1) è un'azienda italiana con partita IVA. Specifichiamo che il cliente può essere considerato un'azienda non perché abbia una Denominazione quanto perché il valore IdFiscaleIVA è true (true = azienda, false = privato) come da risposta del VIES.

Nell'immagine sopra riportata l'array invoices è stato collassato per questioni di spazio. Al suo interno sono riportate sia le fatture che le note di credito. In basso analizziamo sua la struttura.



All'interno di invoices troviamo 4 array collassati sempre per questioni di spazio. Ciascuno di essi rappresenta una fattura in WHMCS. Le chiavi 322, 323, 324 e 325 non sono altro che gli ID delle fatture di WHMCS (tblinvoices.id). Nota bene: non si tratta degli invoice number ma dei veri e propri ID delle fatture nel database. Espandiamo la 322 e 323.



TipoDocumento può assumere i valori TD01 (fattura) o TD04 (nota di credito). Il valore einvoiceit se presente identifica l'eventuale nome dell'XML già generato da Billing Extension. Tutti gli altri campi non necessitano di spiegazioni. Facciamo solo notare come l'array items contenga le singole voci della fattura e che le chiavi (3271 e 3272) corrispondano agli ID di WHMCS (tblinvoiceitems.id).

Non a caso abbiamo preso come riferimento questi due documenti. Il primo (Invoice ID 322) è una fattura mentre il secondo (Invoice ID 323) è la sua nota di credito collegata che indica un rimborso parziale del pagamento.



Negli esempi che abbiamo riportato non sono visibili, ma comunque sempre presenti, i dati che noi definiamo raw (sporchi) delimitati per l'appunto dal prefisso "raw_". Tali dati sono ad esempio il nome, il cognome, la ragione sociale, la partita IVA (...) in breve tutti i dati del clienti esattamente come riportati in WHMCS senza alcuna formattazione o controllo applicato da parte di Billing Extension.

Proprio come avviene per la generazione dei file XML, anche le richieste al WebService possono generare errori che saranno indicati sia nel centro notifiche che nella risposta.



Nell'immagine sopra riportata possiamo vedere la sezione error al cui interno 3 documenti, rispettivamente con ID 326, 326 e 351, hanno generato degli errori. Grazie a questo sistema puoi gestire programmaticamente l'errore oppure attivarti per correggere manualmente i dati in WHMCS.

Precisiamo che per i documenti che generano errori, il WebService non restituisce alcun dato e che la sezione error compare solo in presenza di errori.

Overriding

Oltre al Nodo FTP ed al WebService mettiamo a dispozione un terzo metodo per lo sviluppo di soluzioni avanzate che è basato sull'overriding. Tale approccio può essere utilizzato solo da programmatori esperti. Maggiori informazioni possono essere repertite nel file modules/addons/BillingExtension/core/BlillingExtension_Admin/resources/einvoiceit/__Overrides.php.