Fatturazione elettronica

Introduzione

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 (Intra/Extra EU) ma non ha più alcun valore per quelle che si svolgono tra soggetti residenti o attivi in Italia.

È importante sottolineare sin da ora che benché non sussista alcun obbligo di fatturazione elettronica per le operazioni Intra/Extra EU, è comunque consigliabile emetterle anche per questi soggetti in quanto:
  • Semplifica la contabilità ed i controlli fiscali
  • Abbatte i costi di gestione
  • Garantisce maggiore flessibilità
Inoltre sarebbe svantaggioso adottare un doppio sistema per l'invio delle fatture all'Agenzia delle Entrate.

Elaborazione fatture

WHMCS non è compatibile con la fatturazione elettronica in quanto non dispone né dei dati né dei concetti necessari all'elaborazione di questo tipo di documento. È per questo motivo che in Billing Extension abbiamo sviluppato un'integrazione che permette di generare le fatture elettroniche in WHMCS.



Nel diagramma sopra riportato, abbiamo riassunto il funzionamento della nostra soluzione. Con il cron giornaliero di WHMCS, tutte le fatture e note di credito emesse dal sistema nel corso del giorno precedente saranno convertite in fatture elettroniche. Come vi abbiamo accennato in precedenza, WHMCS ignora concetti come il VIES, l'iscrizione REA, lo stato di liquidazione, la PEC, la firma digitale, il regime fiscale, lo split payment, l'esigibilità IVA e soprattutto non gestisce le note di credito. Grazie a Billing Extension tutto questo diventa possibile.

Il modulo arricchisce e perfeziona le informazioni gestite da WHMCS, effettua oltre 70 tra controlli e validazioni per ogni fattura riportando eventuali errori nel centro notifiche come indicato nell'immagine d'esempio in basso.



Dal centro notifiche è possibile rendersi subito conto dei problemi e "saltare" direttamente alla fattura incriminata per correggerla cliccando semplicemente sul messaggio. Queste fatture, una volta corrette, possono essere nuovamente riemesse in formato elettronico sia manualmente che automaticamente attendendo il successivo cron giornaliero.

L'ampia gamma di errori che il modulo prende in esame corrisponde agli stessi errori gestiti dall'Agenzia delle Entrate. Abbiamo infatti integrato questi controlli direttamente nel software al fine di interrompere sul nascere, nei limiti del possibile, la creazione di una fattura elettronica non corretta evitando inutili attese e scambi di dati con il Sistema di Interscambio (SdI). Nei capitoli successivi sono riportati i dettagli riguado le validazioni effettuate dal modulo.

Superati tutti i controlli, le informazioni vengono elaborate per la creazione della fattura elettronica in formato XML. Anche durante la creazione dei file XML vengono fatti ulteriori controlli che garantiscono l'integrità delle informazioni.

Nel caso in cui utilizzi WHMCS in italiano, precisiamo che tutti i contenuti saranno in lingua italiana. Questa caratteristica si applica ad ogni sezione del modulo. Le immagini che vedi nel presente articolo sono state prese in inglese solo per questioni di praticità.

Vogliamo sottolineare che per noi è sempre sempre stata una priorità fare in modo che WHMCS generasse il minor numero di fatture. Il modulo già evita l'emissione di fatture obsolete ed è munito di meccanismi che possono portare ad una riduzione fino all'80% secondo il nostro case study.

Nell'implementazione della fattura elettronica abbiamo mantenuto lo stesso obbiettivo. Le fatture e le note di credito di uno stesso utente vengono inviate in lotti anziché singolarmente in un unico file XML. Ciò riduce ulteriormente i tempi di attesa e le spese di gestione.

Nodo FTP

Terminata l'elaborazione delle FatturePA, 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 memorizzati. Precisiamo che la trasmissione dei dati avviene sfruttando una connessione sicura e che la password di accesso è criptata nel database.



Nell'immagine sopra riportata possiamo osservare un esempio di FatturePA archiviate in un nodo FTP. Da qui sei libero di scaricare, inviare ed importare i file XML nel tuo software di contabilità o nella piattaforma da te scelta che svolge il ruolo di intermediariotra la tua azienda e l'Agenzia delle Entrate. Nei capitoli successivi spiegheremo tutti i dettagli al riguardo.

WebService

Nel caso in cui non volessi utilizzare il nodo FTP oppure se hai bisogno di sviluppare un'integrazione personalizzata con un gestionale interno piuttosto che con un intermediario, è possibile utilizzare il WebService integrato nel modulo. Questo se interrogato risponde fornendo tutte le informazioni necessarie per una corretta gestione delle fatture elettroniche.
 
Di seguito descriviamo il funzionamento del WebService. Questa parte della guida è puramente tecnica ed è indirizzata agli sviluppatori. Se non sei uno sviluppatore ti consigliamo di passare al capitolo successivo.

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.



Per una corretta elaborazione delle richieste inviate al WebService, tutte le comunicazioni dovranno avvenire riportando sempre questo token. Inoltre, anche se non utilizzi Billing Extension per la generazione degli XML, è comunque 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. Per maggiore chiarezza il codice è commentato. In basso abbiamo elencato 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 la sua 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.

Trasmissione

Grazie a Billing Extension hai creato creato un nodo FTP e/o puoi utilizzare il WebService per integrazioni avanzate. Ora però bisogna dare un senso a questi dati e trasmetterli all'Agenzia delle Entrate completando il percorso unico standardizzato verso il Sistema di Interscambio (SdI) che può essere riassunto nello schema riportato in basso. Per questioni di praticità partiamo dalla soluzione con nodo FTP.



Gli XML, ovverosia le fatture e le note di credito che hai emesso in WHMCS, vengono firmati digitalmente e trasmessi a SdI che, agendo come un postino, li recapitara al soggetto a cui sono indirizzati (privato, azienda o Pubblica Amministrazione) o li rifiuta (scarto) fornendo le motivazioni entro un certo numero di giorni. Al termine del percorso la fattura elettronica viene memorizzata per un periodo di 10 anni (conservazione sostitutiva).

Sottolineiamo che di tutto questo non si occupa Billing Extension ma intervengono piattaforme intermediarie sviluppate da aziende terze. L'argomento a questo punto può diventare complesso pertanto tracciamo un grande spartiacque per aiutarti a capire meglio di cosa hai bisogno.

Intermediari

Se quanto descritto nei capitoli precedenti non ti è ancora chiaro o hai una conoscenza frammentaria oppure non hai alcuna intenzione di cimentarti nello sviluppo di soluzioni ad hoc, questa parte della guida fa al caso tuo.

La fatturazione elettronica, ovvero il dare un senso ai file XML generati da Billing Extension, è un processo molto complesso dal punto di vista tecnico. Non tutti, visti i costi e le conoscenze richieste, possono o vogliono affrontare la questione internamente.

In nostro soccorso vengono servizi sviluppati da aziende terze che svolgono il ruolo di intermediario tra la tua azienda e l'Agenzia delle Entrate. Questi si occupano non solo di processare il ciclo attivo (gli XML delle fatture da te emesse in WHMCS) ma anche il ciclo passivo (le fatture dei fornitori) mettendoti a disposizione un'interfaccia dalla quale poter gestire l'intera contabilità. Sempre all'interno di tali piattaforme viene adempiuto l'obbligo di conservazione delle fatture per un periodo di 10 anni (conservazione sostitutiva).

Per maggiore completezza specifichiamo che la stessa Agenzia delle Entrate può fornire suddetto servizio svolgendo di fatto il ruolo di intermediario a mezzo della sua piattaforma SdI. Per maggiori informazioni sull'attivazione del servizio ed i requisiti per l'accreditamento, rimandiamo alla pagina dedicata sul sito dell'Agenzia. Prima aprire il link ti invitiamo tuttavia a completare la lettura di questo articolo in quanto ci sono ancora alcuni punti critici da affrontare. Come si collega l'intermediario a WHMCS? In base a quale criterio dovrei sceglierne un intermediario piuttosto che l'altro? Iniziamo col rispondere al primo quesito.

Il collegamento tra WHMCS e l'intermediario consiste nel dare accesso a quest'ultimo al tuo nodo FTP. Al resto penserà lui alimentandosi giorno per giorno dei nuovi XML archiviati da Billing Extension nel nodo (il ciclo attivo). Il concetto di nodo FTP non è una nostra invenzione ma uno dei 5 percorsi percorsi standardizzati verso il SdI. 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.

Il nodo FTP è quindi uno standard ideato dall'Agenzia delle Entrate che alcuni intermediari tra i quali SdI supportano. Non dovrebbe essere impossibile riuscire a trovare più di un intermediario al quale agganciare WHMCS. Ciononostante precisiamo che molti tra i più famosi ed economici hanno scelto sviluppare soluzioni proprietarie che possono richiedere integrazioni più o meno complesse.

Nella malaugurata ipotesi di non poter cambiare gestore né di completare l'integrazione, puoi sempre importare manualmente gli XML caricandoli da interfaccia web in archivi compressi. Questa possibilità generalmente è presente nella maggior parte degli intermediari. A titolo puramente esemplificativo, soluzioni come FattureInCloud piuttosto che Fattura24 non vanno bene a meno che tu non voglia creare un'integrazione mediante WebService. In tal caso dovrai importare anche le anagrafiche ed i prodotti di WHMCS direttamente in queste piattaforme.

Una volta che gli XML sono stati elaborati e memorizzati dall'intermediario, quelli contenuti nel nodo FTP teoricamente possono anche essere cancellati. La loro eventuale perdita infatti non comporta alcun rischio in quanto la copia legale è archiviata dall'intermediario. Raccomandiamo tuttavia di non eliminare gli XML dal nodo in quanto Billing Extension collega ogni fattura di WHMCS al relativo XML permettendo sia a te che al cliente una gestione più semplice.

Per quanto concerne il ciclo passivo, ogni intermediario è munito di un proprio codice destinatario di 7 caratteri da te utilizzabile per ricevere le fatture dai tuoi fornitori.

Sconsigliamo alle PMI di cimentarsi nello sviluppo di un sistema di intermediazione ad uso interno per le difficoltà realizzative, il processo di accreditamento e per la necessità di continuare supportare il sistema nel corso degli anni. È molto più rapido, economico e indolore affidarsi ad una soluzione già pronta.

Posto che la scelta dell'intermediario è assolutamente libera, Billing Extension è già integrato con uno di essi. Nel giro di pochi minuti potrai liberarti della questione fatturazione elettronica. Maggiori informazioni sulle piattaforma e sui costi saranno riportate direttamente in Billing Extension entro la fine del 2018.

Soluzioni personalizzate

Se hai bisogno di integrare Billing Extension con una piattaforma specifica oppure se ti occupi internamente di adempiere agli obblighi della fatturazione elettronica, puoi utilizzare il WebService.

Strumenti

Abbiamo ideato diversi sistemi che permettono di individuare agevolmente l'associazione tra le fatture di WHMCS ed i file XML. Se utilizzi il nodo FTP, il modulo non si limita a memorizzare gli XML nel server remoto ma fornisce informazioni e funzionalità aggiuntive come evidenziato nell'immagine sotto riportata.



Nella vista fattura di WHMCS è possibile effettuare il download del file XML correlato che si trova nel nodo FTP. È anche possibile, premendo sull'icona della matita, rendere visibile l'opzione per l'eliminazione del file dal nodo.



Una volta eliminato l'XML dal nodo FTP, sarà possibile generarne un nuovo XML premendo sull'apposito pulsante. Alternativamente è sufficiente attendere il successivo cron giornaliero di WHMCS per lasciare che intervenga l'automazione.



In quest'ultima immagine vediamo un caso particolare di lotto di fatture elettroniche. Per il cliente in oggetto, essendo state emesse nell'arco della stessa giornata 2 note di credito (segnalate dall'iconcina blu con il talloncino giallo) ed 1 fattura oltre a quella correntemente visualizzata, è stato generato un'unico XML contenente l'intero lotto di fatture. È possibile navigare tra tutti documenti coinvolti semplicemente cliccando su di essi.

Le novità non finiscono qui. Abbiamo inserito il riferimento agli XML nella pagina di elenco fatture di Billing Extension. In tal modo è possibile ricercare e scaricare gli XML nonché renderli parte dell'esportazione su Excel sfruttando la nostra tecnologia SorTables.

Numero progressivo

L'Agenzia delle Entrate ha stabilito che ogni file XML trasmesso deve assumere una nomenclatura particolare. Questa consiste nel codice paese (esempio: IT) seguito dal tuo numero di partita IVA. Dopodiché va inserito un underscore "_" al quale segue un parametro denominato ProgressivoInvio.

Il ProgressivoInvio, come suggerisce il nome, è un valore alfanumerico di massimo 5 caratteri che identifica univocamente ogni documento XML trasmesso. Questo valore deve essere sempre diverso per ogni invio anche quando ti appresti a rigenerare un XML precedentemente scartato da SdI.

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 da SdI.

Abbiamo ideato un sistema che permette di ottenere, sempre 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 è infatti il fondamento stesso della fatturazione elettronica che 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. La numerazione progressiva delle fatture è riportata 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 (i due WHMCS, Prestashop ed il negozio fisico).

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 andassi ad utilizzare per tutti e 4 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 inviate a SdI vengono recapitate all'intestatario della fattura ovverosia il cliente finale su WHMCSovviamente 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 dell'entità 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
A partire dal 1° gennaio 2019, tutti i clienti italiani dovranno essere messi nelle condizioni di fornire il proprio Codice Destinatario. Ciò può essere fatto creando degli appositi Client Custom Field in WHMCS collegandoli successivamente a Billing Extension dalle impostazioni.
 
Probabilmente a questo punto 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 denominato "Codice Destinatario" nel quale i clienti potranno inserire liberamente proprio recapito qualunque esso sia. Billing Extension penserà al resto distinguendo lo SdI da 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 "PEC, SdI or iPA. Leave empty if you're not italian".

Profilazione assistita

Negli ultimi anni ci siamo quasi abituati all'idea di ricevere email massive da ogni azienda riguardo a concetti come la legge sui cookie prima e GDPR dopo. Ormai essere bombardati da pop-up è diventata la norma. C'è il rischio che anche la fatturazione elettronica diventi un qualcosa di insopportabile per i consumatori che visitano il tuo sito.

Abbiamo posto molta attenzione a quello che sarà il rapporto con i clienti a partire dal 1° gennaio 2019 e crediamo di aver trovato una soluzione semplice e poco invasiva. Attivando l'apposita funzione Profilazione assistita di Billing Extension, nella sidebar dell'area clienti in WHMCS ai soli clienti italiani sarà aggiunta automaticamente una nuova sezione visibile l'immagine sottostante.



Il cliente può rendersi subito conto dell'incompletezza dei dati attualmente forniti (immagine a sinistra). Dopo aver completato il suo profilo dalla pagina dedicata, la corretteza del nuovo profilo sarà subito evidente (immagine a destra). Per semplificare uleriormente la procedura, la pagina fornisce informazioni chiare sugli errori effettuati in fase di compilazione.

Billing Extension effettua le seguenti validazioni:
  • Controllo formale partita IVA compresivo di codice di controllo più VIES
  • Controllo formale codice fiscale anche in base al nome e cognome
  • Controllo validità codice destinatario
  • Completezza dei dati forniti
Precisiamo che tali controlli sono puramente formali in quanto solo l'Agenzia delle Entrate è in grado di verificare l'effettiva validità del codice fiscale e del codice destinatario. Aver compilato correttamente tutti i dati non è quindi garanzia di assenza di errori.

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. Infatti non esiste un modo per impedire che utenti malintenzionati si spaccino per soggetti tenuti 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. Lo split payment pertanto non si applica.