Electronic Invoicing

Quadro normativo

Dal 1° gennaio 2019 in Italia è scattato l'obbligo di emissione di fatture in formato elettronico. Il cartaceo della fattura, ovverosia il PDF emesso da WHMCS, conserva la sua validità di legge e pieno valore fiscale unicamente nei seguenti casi.

È importante sottolineare che la versione cartacea della fattura, meglio nota come copia cortesia, deve comunque avere come pezza d'appoggio una fattura elettronica. In parole povere dovrai sempre emettere la fattura elettronica a prescindere dal fatto che i clienti abbiano o meno bisogno della versione cartacea.

Al fine di semplificare le cose, è sufficiente emettere sempre sia la fattura elettronica che la copia cortesia in PDF. Starà a cliente utilizzare l'una o l'altra versione dipendentemente della sua forma giuridica e/o nazionalità.

Quanto alle tempistiche, la fattura elettronica deve essere emessa entro 12 giorni dal momento di effetturazione dell'operazione. Le sanzioni per ciascuna tardiva emissione della fattura elettronica sono cospique.

Concludiamo questo capitolo con un appunto sul regime dei forfettari. Se la tua attività rientra in questo regime, la legge ti lascia libero di scegliere se aderire o meno alla fatturazione elettronica. Se scegli di non aderire, tieni presente che nessun cliente può obbligarti ad emettere comunque la fattura elettronica.

La fatturazione elettronica in WHMCS

Cominciamo col dire che WHMCS non rispetta le più basilari norme fiscali e manca di concetti fondamentali in materia di fatturazione. Lavoriamo con WHMCS dal 2007 e la situazione è sempre rimasta la stessa. In un contesto del genere sarebbe del tutto inutile anche solo pensare alla fatturazione elettronica.

È importante comprendere che lo staff di WHMCS non ha alcun interesse ad entrare nel merito della fatturazione. Avendo clienti in tutto il mondo, dovrebbe mettersi in regola rispetto a centinaia di diverse regole fiscali di altrettanti paesi del mondo. Senza considerare che spesso le normative cambiano di anno in anno.

Se WHMCS dovesse star dietro a tutte le leggi di bilancio, le regole di fatturazione ed i sistemi di fatturazione elettronica di tutto il mondo, non potrebbe più occuparsi del suo core business ovverosia l'hosting, i domini e tutto quanto concerne la gestione di un hosting provider.

In fin dei conti basta fermarsi un attimo a ragionare sui software di contabilità. Ci sarà un motivo se un software di contabilità italiano non può essere utilizzato in Germania e viceversa. La fatturazione è un argomento troppo ampio e variegato affinché possa essere sviluppato un software "globale".

Tutto ciò premesso, nel corso degli anni abbiamo sviluppato Billing Extension, un modulo che completa tutte le mancanze di WHMCS in materia di fatturazione. Chiaramente anche noi non potevamo occuparci della fatturazione di centinaia di paesi pertanto abbiamo dovuto effettuare delle scelte strutturato il modulo in 3 livelli.

Grazie a questa struttura, Billing Extension è un modulo che può tornare utile in modo più o meno marcato alle aziende di tutto il mondo. Dal momento che qui stiamo parlando di fatturazione elettronica italiana, i benefici sono triplicati in quanto si andranno a sfruttare tutti i livelli del modulo.

Tra l'altro ricordiamo che il modulo dispone anche di molte funzionalità ad alto valore aggiunto come l'integrazione con Facebook Pixel, LinkedIn Insight Tag, la fatturazione mensile, la Customer Retention con relativa analisi del Churn Rate (tasso di abbandono) ed un Web Service per qualsivoglia integrazione personalizzata.

Soluzioni alternative

È opportuno dedicare un capito alle possibili alternative di Billing Extension. Come puoi osservare nella nostra guida introduttiva a WHMCS, non abbiamo problemi nel fare i nomi dei nostri competitor né nel consigliare ai nostri clienti soluzioni sviluppate da altri. Quando però si parla di fatturazione, non esistono alternative a Billing Extension.

Nessuno dei nostri competitor né WHMCS si è mai spinto in questo argomento. Le ragioni le abbiamo spiegate nel precedente capitolo e le ribadiamo. La fatturazione è un argomento spinoso che può cambiare dal giorno alla notte con una legge finanziaria.

Ad oggi e sin dal 2007, solo noi abbiamo avuto la voglia e il coraggio di affrontare questa sfida. Ecco spiegato il perché nessuna delle funzioni di Billing Extension può essere trovata in altri software.

Glossario fatturazione elettronica

Se non sai come funziona la fatturazione elettronica, sappiamo quanto possa essere difficile da capire specialmente per via della particolare terminologia utilizzata.

Per aiutarti a comprendere al meglio i concetti che ci apprestiamo ad introdurre, abbiamo realizzato un glossario. Nei capitoli successivi saranno forniti maggiori dettagli. Cominciamo.

Panoramica generale

L'immagine sopra riportata descrive il flusso che seguono le fatture elettroniche. Si comincia da WHMCS dove il cliente effettua normalmente l'acquisto di nuovi servizi piuttosto che il rinnovo di servizi già in essere.

Ad ogni fattura emessa da WHMCS corrisponde una fattura elettronica che viene elaborata e generata Billing Extension. La generazione degli XML può avvenire:

• Automaticamente contestualmente al cron giornaliero di WHMCS
• Manualmente generando gli XML uno alla volta o massivamente

È bene precisare che un'opzione non esclude l'altra. Per intenderci è sempre possibile emettere manualmente le fatture indipendentemente dalla presenza o meno dell'automazione.

Tutti gli XML generati vengono archiviati nel nodo FTP da te scelto. A questo punto le fatture elettroniche prendono un percorso diverso dipendentemente dall'intermediario da te utilizzato.

Una volta trasmessi gli XML, nella stragrande maggioranza dei casi non è richiesto alcun altro intervento da parte tua. L'unico caso in cui è necessario intervenire è quando uno o più XML vengono scartati dall'Agenzia delle Entrate. In tal caso dovrai effettuare le dovute correzioni e trasmettere nuovamente l'XML.

Fatture elettroniche scartate

L'Agenzia delle Entrate effettua centinaia di controlli sui dati inseriti negli XML. Nel caso in cui fossero presenti problemi o difformità, la fattura viene scartata. Quando questo si verifica, viene sempre indicata la motivazione.

Nelle prime release di Billing Extension, la percentuale di scarto si aggirava intorno all'8%. Oggi questa percentuale rasenta lo zero in quanto nel modulo abbiamo anticipato tutti i controlli formali e sostanziali che svolge l'Agenzia.

Per fare un esempio, se il codice fiscale fornito non è formalmente corretto, il modulo evita di generare l'XML che di lì a poco sarebbe sicuramente scartato dall'Agenzia. In questo modo si blocca il problema sul nascere.

Precisiamo che le rare volte in cui si verifica uno scarto, nel 99% dei casi si tratta dell'errata applicazione delle tasse in fattura. Ad esempio un cliente di Tenerife deve essere esente da IVA in quanto si tratta di una regione a regime di tassazione speciale. Probabilmente hai dimenticato di configurare questa eccezione nel modulo.

Motivo dello scarto

Billing Extension riporta a schermo la motivazione dell'errore il che permette una facile correzione. Nell'immagine in basso è possibile osservare un paio di errori consultabili dal centro notifiche.

Ricordiamo che il centro notifiche è una pagina in Billing Extension dove vengono riportati tutti gli errori (in rosso) ed avvisi (in giallo) relativi alla fatturazione. Se esegui WHMCS v8, tali errori vengono messi in risalto nell'interfaccia amministrativa.

Se si utilizza il cellulare o comunque la versione ridotta dell'interfaccia, le stesse informazioni vengono riportate nella sidebar.

Per le versioni di WHMCS fino alla v7, gli errori vengono riportati in cima alla pagina subito dopo i ticket in attesa di risposta.

Oltre a tutto questo, molto più semplicemente il modulo riporta gli errori direttamente sopra la fattura interessata.

Esiste infine un terzo luogo dove Billing Extension riporta gli errori oltre che a tutta una serie di altre informazioni. Ci riferiamo al Widget integrato nel modulo che è consultabile nell'home page di WHMCS.

Precisiamo che tutti gli errori nonché tutto il modulo nella sua interezza è disponibile in lingua italiana che si attiva automaticamente quando se il tuo account amministratore è impostato sulla lingua italiana.

Controlli sui dati

Come detto in precedenza, abbiamo anticipato nel modulo tutte le verifiche che svolge l'Agenzia delle Entrate e che possono determinare uno scarto. Ci sono tuttavia un paio di controlli che non è in alcun modo possibile integrare nel modulo. Ci riferiamo ad esempio alla validità effettiva del codice fiscale.

Solo l'Agenzia delle Entrate ha accesso all'Anagrafe Tributaria e può stabilire con assoluta certezza l'effettiva validità di un codice fiscale. In tal senso il massimo che possiamo fare in Billing Extension è la verifica formale.

In questo caso sarà l'intermediario a notificare l'errore. Starà a te eliminare l'XML scartato, correggere l'errore e rigenerarlo affinché l'XML venga di nuovo trasmesso.

Fattura elettronica scartata: cosa fare?

Ti ricordiamo che Billing Extension blocca i dati di fatturazione su ogni fattura nel momento in cui queste vengono emesse. In gergo tecnico diciamo che il modulo effettua degli snapshot sulle fatture. Questo assicura l'integrità dei dati. Ad esempio se il cliente dovesse cambiare indirizzo, la modifica non si ripercuoterebbe sulle fatture già emesse.

Nel momento in cui si verifica uno scarto, non dovrai fare altro che eliminare l'XML scartato. Questa operazione può essere svolta dalla vista fattura. È sufficiente premere l'icona della matita per visualizare l'opzione Delete.

Alternativamente si può fare lo stesso da Billing Extension > Invoices in modo massivo utilizzando il menu in alto a destra e selezionando la modalità Delete XML.

Una volta eliminato l'XML, puoi procedere alla correzione (come modificare uno snapshot). Se l'errore è nei dati del cliente, non dimenticare di ripetere la correzione anche sul suo profilo "live" in modo che le successive fatture saranno emesse con i dati corretti.

Se l'errore riguarda l'applicazione delle tasse, assicurati di aver configurato correttamente le regioni a tassazione speciale (es. Las Palmas e Santa Cruz De Tenerife per la Spagna, Isle of Man per l'Inghilterra ecc.) in Billing Extension > Settings > Tax Rules.

Fatta la modifica, è possibile richiedere a Billing Extension di ricalcolare le aliquote IVA corrette utilizzando l'opzione sotto riportata che è presente nella vista fattura (tab Client Details).

Nota di credito elettronica

Può capitare di accorgersi di un errore negli importi quando ormai la fattura è già stata trasmessa all'Agenzia delle Entrate. In questo caso devi ricorrere alla nota di credito elettronica che funziona proprio come una fattura. L'unica differenza è nella direzione del flusso di denaro.

Le note di credito devono essere utilizzate anche quando rimborsi un pagamento al cliente. Per maggiori informazioni rimandiamo alle guide quando emettere una nota di credito e come emettere una nota di credito.

Il ciclo di vita di una fattura elettronica

La generazione delle fatture elettroniche ha inizio da una tradizionale fattura di WHMCS. Il modulo riconosce automaticamente i documenti per i quali è necessario generare l'XML ovverosia le fatture e le note di credito.

In questi documenti è presente la possibilità di generare l'XML in un click premendo l'apposito pulsante arancione Generate XML. Ti ricordiamo che il modulo può generare automaticamente gli XML con il cron giornaliero di WHMCS.

Per ovvi motivi le proforma e/o i documenti in status Draft (non accessibili ai clienti) non presentano la possibilità di generare l'XML. Le proforma infatti non devono essere trasmesse all'Agenzia delle Entrate perché non hanno valore fiscale.

Salvo errori, nello step successivo si otterrà l'XML contrassegnato dal colore blu che simboleggia una fattura elettronica in attesa di tarasmissione oppure in corso di elaborazione da parte dell'intermediario.

Al click sullo status/esito della fattura, è possibile visualizzare a schermo informazioni aggiuntive. Se l'intermediario utilizzato è integrato con Billing Extension, le informazioni qui contenute provengono direttamente dall'Agenzia delle Entrate.

Nel giro di qualche ora, l'XML da blu diventerà verde colore che rappresenta la corretta elaborazione e trasmissione della fattura elettronica. Come puoi osservare dall'immagine sotto riportata, in questo caso non è presente la possibilità di eliminare l'XML.

Diversamente se l'XML è stato scartato, viene contrassegnato dal colore rosso ed è possibile eliminarlo per permetterti di correggere i dati. Ad eliminazione avvenuta, puoi di nuovo generare l'XML.

Precisiamo che facendo click sui pulsanti blu (in attesa), verde (trasmesso con successo) e rosso (scartato), puoi scaricare l'XML direttamente sul computer. Nel caso in cui l'XML non fosse più presente nel nodo FTP, il pulsante assumerà il colore bianco. In questo caso al click ti verrà chiesto se vuoi eseguire il detach della fattura dal database.

Specifichiamo che Billing Extension non cancella mai gli XML dal nodo FTP nè modifica alcuno status e/o informazione. Al contrario ogni azione viene memorizzata nel log accessibile dal centro notifiche in modo che siano chiare le azioni eseguite da ogni amministratore.

Tutte le funzionalità che abbiamo appena mostrato sono replicate anche nella pagina Billing Extension > Invoices. L'unica differenza è che da qui è possibile svolgere le medesime operazioni in modo massivo su più XML alla volta.

In più sono disponibili oltre 40 filtri facilmente accessibili grazie alla tecnologia SorTables. Puoi spostare, aggiungere, eliminare e comprimere le colonne in tempo reale nonché esportare il tutto su un foglio di calcolo Excel.

Approfondimenti sulla fatturazione elettronica

Arrivato a questo punto della guida, avrai compreso il viaggio che intraprendono gli XML. Questi nascono in WHMCS grazie a Billing Extension e vengono archiviati nel nodo FTP. Da qui l'intermediario li trasmette all'Agenzia delle Entrate che infine li recapita al cliente (se necessario).

Analogamente esiste anche una sorta di viaggio di ritorno con l'Agenzia delle Entrate che notifica l'esito della trasmissione che può essere sia positivo che negativo. Nei capitoli successivi analizzeremo con maggior dettaglio i concetti salienti che devi necessariamente conoscere.

Installazione e configurazione

Dopo aver installato, integrato e configurato Billing Extension secondo le tue specifiche esigenze, puoi procedere all'attivazione del plugin relativo alla fatturazione elettronica italiana. Il modulo è infatti talmente ampio che al suo interno ha plugin aggiuntivi installabili dipendentemente dal paese nel quale si opera.

Visita Addons > Billing Extension > Settings dopo di che premi il pulsante "+" nella barra di navigazione del modulo. Qui trovi la pagina dei plugin. Cerca e attiva la fatturazione elettronica italiana.

Successivamente all'attivazione, torna nei Settings del modulo dove in fondo sono comparse tutte le impostazioni del plugin della fatturazione elettronica.

Espandendo la sezione ti renderai subito conto che è necessario leggere e configurare un lunga serie di parametri la maggior parte dei quali riguarda i dati della tua attività (denominazione, numero REA, sede amministrativa ecc.).

Al netto delle informazioni aziendali, ci sono parametri che potrebbero non essere altrettanto semplici da comprendere. In questa fase ti suggeriamo concentrarti su quello che riesci ad impostare. Per tutto il resto troverai maggiori dettagli proseguendo nella lettura dell'articolo.

Punto di avvio fatturazione elettronica

Quando avrai completato la configurazione, il sistema inzierà a generare gli XML a partire dalla data di installazione del plugin. Una data di "inizio" è sempre richiesta per evitare che il modulo vada a generare XML per fatture emesse negli anni precedenti.

Hai facoltà di spostare tale data dal campo Addons > Billing Extension > Settings > Fatturazione elettronica > Limita per data. Il campo si rivela particolarmente utile per pianificare eventuali "switch" da un sistema di fatturazione esterno a quello integrato in WHMCS.

Lotti di fatture

Si parla di lotto di fatture quando un XML contiene al suo interno più fatture. Precisiamo che un lotto può essere anche "misto" ovvero contenere sia fatture che note di credito. Il vantaggio dei lotti è che si possono trasmettere più documenti relativi ad uno stesso cliente in una sola volta.

Per esempio se nell'arco della giornata uno stesso cliente salda 3 fatture, viene emesso un unico XML contenente un lotto di 3 fatture. Questo facilita leggermente il lavoro amministrativo. I lotti vengono evidenzati nell'interfaccia dalla presenza di un numero.

Qui abbiamo un XML contenente un lotto di 2 fatture. Dalla vista fattura è possibile espandere i dettagli per visualizzare di quali fatture o note di credito si tratta (premi l'icona indicata).

In questo caso il secondo documento del lotto è una nota di credito. Le note di credito diversamente dalle fatture presentano un piccolo talloncino giallo nell'angolo in basso a destra.

È possibile attivare o disattivare la creazione dei lotti da Addons > Billing Extension > Settings > Fatturazione elettronica > Nodo FTP > Lotti fatture. Personalmente consigliamo di lasciare l'opzione attiva. Due considerazioni finali:

• L'eliminazione di un lotto ha effetto su tutti documenti collegati
• È raro ma alcuni intermediari non supportano i lotti

Creazione massiva XML

Se hai attivato l'opzione Addons > Billing Extension > Settings > Fatturazione elettronica > Supporto Cron Job, il modulo giorno per giorno crea automaticamente gli XML per le fatture e note di credito che lo richiedono. Ciò avviene durante il cron giornaliero di WHMCS.

Parallelamente all'automazione è sempre possibile generare gli XML manualmente. Come abbiamo visto in precedenza, si può fare dalla vista fattura premendo il tasto Generate XML. Oppure puoi generarle massivamente da Addons > Billing Extension > Invoices da questo menu.

Di seguito lo scopo di ogni funzione:

• Genera & Verifica XML. Il modulo crea gli XML per tutte le fatture e note di credito "aperte"
• Esegui scansione. Serve a scansionare il nodo FTP per correggere gli status degli XML dipendentemente dalla cartella nella quale si trovano. La funzione è utile nel caso tu voglia importare XML da un sistema esistente
• Modalità senza restrizioni. Non dovrai mai utilizzare questa funzione se non espressamente richiesto da noi. Si tratta di una modalità che consente di effettuare operazioni sugli XML normalmente non consentite

Profilazione clienti

Non farti trarre in inganno dalla tabella mostrata in basso che riporta le diverse tipologie di soggetto, forme giuridiche ed entità gestite dalla fatturazione elettronica. Salvo rare eccezioni, è tutto automatico.

Billing Extension è un software intelligente che ti solleva dal compito di dover stabilire cosa sia ogni cliente. Il modulo sa quali sono i fattori che determinano la differenza tra ditta individuale piuttosto che azienda o privato.

In base ai dati disponibili e alla loro correttezza, il modulo si adopererà di conseguenza emettendo gli XML nel modo corretto. Nel caso in cui dovessero esserci "intoppi" (es. partita IVA errata), si applica la logica del fallback descritta nel capitolo successivo.

L'unica parte non gestibile automaticamente riguarda situazioni particolari:

• Per alcune associazioni non c'è un modo intellegibile per distinguerle da un'azienda
• La Pubblica Amministrazione deve avere Split Payment (intervento manuale richiesto)
• Stesso discorso per le aziende controllate/partecipale dallo stato e/o quotate in borsa

In questo caso viene in aiuto la funzione Addons > Billing Extension > Settings > Fatturazione elettronica > Profilazione assistita che aggiunge nella sidebar di WHMCS la seguente sezione per i soli clienti italiani.

I clienti posssono spontaneamente completare un semplice form che certifica nero su bianco la loro entità. Si tratta di una pagina che richiederà più o meno informazioni dipendentemente dalla tipologia del soggetto.

I dati forniti non vengono ciecamente presi per buoni ma verificati. Se così non fosse un cliente potrebbe profilarsi come Pubblica Amministrazione e richiedere lo Split Payment al solo scopo di "scontarsi" l'IVA sulle tue spalle. Se la profilazione ha esito positivo, la sidebar riflette il cambiamento.

Spesso putroppo ti capiterà di dover completare la profilazione per conto del cliente utilizzando il Login as Client di WHMCS. Questo perché la pigrizia è estremamente diffusa. Alcuni clienti è già tanto se si ricordano di rinnovare i domini.

Fallback

Nel precedente capito abbiamo evidenziato la facoltatività del codice destinatario e della PEC. Questo può sembrare strano in quanto i titolari di partita IVA sono obbligati per legge ad avere la PEC. In genere sono anche muniti di codice destinatario.

Il motivo è presto detto. Al netto della legge, ogni ditta e azienda fa quello che vuole. Come fai ad emettere la fattura elettronica a chi non ti fornisce i dati? Glielo si chiede in ginocchio? Tra l'altro ricordiamo che se non trasmetti la fattura entro 12 giorni, sono previste sazione per invio tardivo.

È ovvio che la tua fatturazione non può fermarsi. Non è possibile restare in balia di questa o quell'altra azienda fino anche a rischiare di dover pagare multe cospicue. Da questo punto di vista, l'unica cosa che davvero conta è che la tua azienda sia in regola con l'Agenzia delle Entrate. Quello che fanno o non fanno i tuoi clienti non deve diventare una tua responsabilità.

Alla luce di questo, il codice destinatario e la PEC sono facoltativi. Le fatture elettroniche possono essere trasmesse all'Agenzia delle Entrate anche in loro assenza. Semplicemente mancherà la parte di recapito all'intestatario della fattura ma ciò che conta è che tu sei a posto.

Veniamo adesso alla logica del fallback spiegandola con un esempio. Ad una ditta individuale che ti fornisce la partita IVA errata, verrà emessa una fattura elettronica verso un soggetto privato. Questo perché, per i motivi precedentemente descritti, la tua fatturazione non può fermarsi. Diversamente l'errore del tuo cliente si tradurrebbe in sanzioni per te.

Può capitare che a distanza di settimane, mesi se non addirittura anni, il cliente si renda conto di non poter dedurre le fatture in quanto non intestate all'azienda. Ribadiamo che non è un tuo problema. Sta a te e al tuo commercialista decidere se andare in contro al cliente annullando le fatture con note di credito e riemettendone ex novo.

Split Payment

Lo split payment o scissione dei pagamenti è una forma di liquidazione IVA che riguarda:

• Pubbliche Amministrazioni che trovi nell'indice delle Pubbliche Amministrazioni
• 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 completo è consultabile nel sito del Dipartimento delle Finanze. Lo split payment prevede che i soggetti indicati siano esentati dal versamento dell'IVA alla tua azienda. Questi infatti versano l'IVA direttamente nelle casse dell'Erario.

Detto in parole semplici significa che ad un cliente della Pubblica Amministrazione piuttosto che una società controllata dallo stato non devi addebitare l'IVA in fattura. Chiarito questo aspetto ci sono un paio di considerazioni da fare.

Due capitoli fa abbiamo parlato della pagina di profilazione dalla quale i clienti che lo desiderano possono completare un processo di verifica che permette loro di qualificarsi come:

• Privato
• Ditta individuale o professionista
• Azienda
• Associazione
• Pubblica Amministrazione

Nella sezione dedicata alle aziende e alla Pubblica Amministrazione è presente un messaggio che indica la possibilità di richiedere l'attivazione dello split payment mediante l'apertura di un ticket.

Precisiamo sin da ora che non è possibile automatizzare la procedura. Devi verificare le richieste manualmente utilizzando gli strumenti precedentemente elencati:

• Indice delle Pubbliche Amministrazioni
• Dipartimento delle Finanze

La ragione è semplice. Stiamo parlando di concedere a determinati soggetti di non pagarti l'IVA. Se accettassi ogni richiesta senza fare controlli, chiunque potrebbe millantare di essere una scuola statale e richiedere lo split payment per scontarsi l'IVA sulle tue spalle. IVA che poi saresti tenuto a pagare di tasca tua.

Completata la verifica, attivare lo split payment è questione di un click. Amesso che il cliente si sia profilato con successo come azienda o Pubblica Amministrazione, posizionati sul suo profilo ed attiva lo split payment premendo il pulsante indicato.

Alla pressione del pulsante, questo diventa verde "Yes". La stessa sorte tocca al Tax Exempt. Complimenti, hai attivato con successo lo split payment. Il cliente può verificare lo status della richiesta dalla pagina di profilazione.

Allo stesso modo lo status dello split payment è visibile dalla sidebar nell'area clienti.

Il risultato è che le fatture emesse verso questo cliente non riportano l'IVA. In altri termini se devi ricevere un pagamento di 100 euro + 22 euro di IVA, incassi solo l'imponibile.

Diversamente nell'XML della fattura elettronica l'IVA di 22 euro è indicata come è indicato il fatto che si tratta di un'operazione soggetta a split payment.

Codice CUP e CIG

I clienti della Pubblica Amministrazione potrebbero aver bisogno che tu apponga nell'XML dei codici denominati CUP e CIG da loro forniti. In loro assenza non è possibile per una Pubblica Amministrazione procedere al pagamento. Vediamo i codici:

• CUP (Codice Unitario Progetto) gestito dal CIPE che caratterizza ogni progetto di investimento pubblico
• CIG (Codice Identificativo Gara) per tracciare i flussi finanziari

Tali codici devono essere applicati a determinate voci fattura che sono oggetto del codice CUP o CIG. Quando il cliente ti comunica il codice, non devi fare altro che apporlo in fattura utilizzando i toggle di seguito indicati.

In questo caso vediamo che il primo dei toggle è attivo (verde) il che significa che è già stato applicato un codice CUP o CIG. Al click si apre un modale dal quale è possibile visualizzare e configurare i codici.

È interessante notare come sia possibile rendere i codici ricorrenti. Questo è possibile solo su voci fattura che hanno un qualche genere di ricorrenza (es. hosting, domini, billable items). In questo modo i codici non dovranno essere aggiunti manualmente ad ogni successivo rinnovo.

Riferimenti normativi personalizzati

Se c'è una cosa che abbiamo capito in tanti anni in cui ci occupiamo di fatturazione, è che fare la stessa domanda a 10 commercialisti produce 10 risposte diverse... oppure 12. È per questo che Billing Extension è altamente configurabile.

Quando una fattura elettronica non presenta l'IVA (es. azienda intra-EU iscritta al VIES, cliente extra-EU), l'Agenzia delle Entrate ha bisogno di conoscere la motivazione. La "spiegazione" è contenuta nell'XML.

Senza entrare troppo nei dettagli, nell'XML devono essere apposte delle diciture prestabilite che rimandano a determinate leggi finanziarie. Benché si tratti di formule standard, alcuni clienti preferiscono modificare i testi.

A questo scopo la sezione Addons > Billing Extension > Settings > Fatturazione elettronica > Riferimenti normativi personalizzati permette di sovrascrivere le diciture predefinite.

Nuovo tracciato 2021

Nel 2021 il tracciato XML delle fatture elettroniche è stato modificato. A partire dal 1° gennaio 2021 il precedente formato non sarà più utilizzato. Ricordiamo che:

• Il nuovo formato di trasmissione è disponibile a partire dalla versone 2.2.133 del modulo
• Se hai la versione 2.2.145, il modulo effettua automaticamente lo switch alle 00:00
• Nel 2021 non potrai più utlizzare il vecchio formato

Regime MOSS

Nella maggior parte dei casi dovrai tenere questa opzione disattivata. L'unico caso in cui deve essere attivata è se la tua attività si avvale dell'opzione regime MOSS. La seguente infografica fornisce una panoramica generale (clicca per ingrandire).

Qui ci limitiamo a dire che nella pratica consiste nell'applicare al cliente privato intra-EU le tasse del suo paese di residenza. In altre parole al cliente privato tedesco sarà addebitata l'IVA tedesca, al francese quella francese e via discorrendo.

Il regime MOSS non si applica alle aziende intra-EU (quelle regolarmente iscritte al VIES), alle operazioni extra-EU (es. Stati Uniti, Russia, Giappone) e a tutti i soggetti italiani privati e non. In caso di dubbi, parlane con con il tuo commercialista.

Fatturazione elettronica clienti esteri

Non sussiste alcun obbligo di emissione della fattura elettronica verso soggetti esteri sia extra che intra-EU. Ciononostante è consigliabile emetterle ugualmente perché puoi beneficiare di una lunga serie di vantaggi:

• Tutte le fatture che emetti sono già informatizzate il che semplifica notevolmente la contabilità
• Nell'ambito della fatturazione elettronica, i dati sono per forza di cose completi e esatti
• In caso di accertamenti, l'Agenzia delle Entrate ha già accesso a tutte le fatture
• Non è più necessario stampare e conservare le fatture cartacee per 10 anni
• Le fatture vengono contabilizzate giorno per giorno automaticamente

Da quando ci occupiamo di fatturazione elettronica, per quella che è la nostra esperienza nessuna azienda ha mai optato per la soluzione "ibrida" dove la fatturazione elettronica viene adoperata solo per le operazioni nazionali.

Se ci pensi bene, che senso ha privarsi dei vantaggi della fatturazione elettronica? Perché dovresti utilizzare una doppia gestione che è automatica per gli italiani e manuale per i clienti esteri con centinaia di fogli da stampare, conservare ed informatizzare?

IBAN in fattura elettronica

Se hai già provato a generare degli XML, avrai senz'altro notato che l'IBAN non compare nonostante siano stati inseriti tutti i dati richiesti (ABI, CAB, BIC/SWIFT ecc.). Questo è un comportamento voluto che ha le sue radici nel lontano febbraio 2019.

Per quanto i dati presenti nell'XML siano uno standard nazionale, ogni piattaforma intermediaria è libera di mostrare i dati come meglio crede all'interno dei propri portali. Relativamente all'IBAN, alcuni intermediari lo espongono in un modo tale da determinare confusione nel cliente che riceve la fattura.

Nella nostra prima implementazione della fatturazione elettronica, inserivamo sempre le coordinate bancarie nell'XML. In una seconda fase siamo dovuti tornare sui nostri passi in seguito ai numerosi feedback ricevuti.

In buona sostanza, alcuni intermediari interpretano la presenza dell'IBAN nell'XML come segno che la fattura non è ancora stata pagata. Su questo viene posto l'accento. Alcuni colorano in rosso l'IBAN mentre altri arrivano a scrivere espressamente "Fattura non pagata".

Come senz'altro saprai, di norma WHMCS emette le fatture solo a saldo avvenuto. Ne consegue che ogni XML è sempre riferito ad una fattura pagata.

In questo contesto, gli intermediari che interpretano la presenza dell'IBAN come una "Fattura non pagata" causano non poca confusione nel cliente che riceve la fattura elettronica. Le conseguenze possibili sono tre:

• Il cliente crede di non aver pagato ed invia un secondo pagamento. Ciò determina un pagamento in eccesso che dovrà essere rimborsato con l'emissione di una nota di credito o accreditato come credito nell'account
• Il cliente ti contatta per richiedere spiegazioni portando ad inutili perdite di tempo
• Il cliente crede si tratti di un tentativo di truffa in quanto gli stai addebitando importi non dovuti

Non possiamo entrare nel merito delle decisioni fatte da alcuni intermediari all'interno dei loro portali. In seguito ai numerosi feedback ricevuti, abbiamo scelto di nascondere l'IBAN nell'XML onde evitare problemi con il cliente finale.

Tutto ciò premesso, nel modulo non abbiamo mai rimosso la possibilità di indicare l'IBAN in quanto in futuro speriamo si possa ripristinare la funzionalità.

Client Custom Field

Per l'emissione della fattura elettronica, è necessario mettere i clienti italiani nelle condizioni di indicare una serie di dati riportati nella tabella in basso. Per ciascuno di questi parametri devi creare un apposito campo in Setup > Client Custom Fields.

Per agevolare la compilazione dei campi, aggiungi delle descrizioni esaustive. Dal momento che anche i clienti esteri vedranno a schermo i suddetti campi, ti suggeriamo attivare Setup > General Settings > Localisation > Dynamic Field Transation. Così facendo potrai tradurre sia i Field Name che le Description.

A tal proposito raccomandiamo di rendere esplicito ai clienti esteri che la compilazione di questi campi, fatta eccezione per le aziende intra-EU dove il VAT Number è necessario, non è richiesta.

Causale cliente

Agli esportatori abituali lo Stato dà la possibilità di effettuare acquisti senza dover corrispondere il pagamento dell'IVA. Se nella tua clientela non c'è questa tipologia di azienda puoi passare al prossimo capitolo.

Al cliente che si qualifica come esportatore abituale devi chidere copia della lettera di intento (o dichiarazione di intento) e più precisamente del documento Ricevuta di presentazione dichiarazione d'intento (mod. IVI15).

Successivamente utilizza lo strumento di verifica della dichiarazione di intento. La verifica è fondamentale in quanto stai consentendo ad un cliente di non pagare l'IVA.

Se il check ha esito positivo devi attivare l'esenzione dalle tasse per il cliente in questione. Come mostrato nell'immagine in basso, nel profilo del cliente imposta il Tax Exempt su Yes (1). Aggiorna la pagina ed assicurati che in alto a destra la casellina indicata (2) sia diventata Yes in verde.

Fatto questo apri il tab Profile ed individua il campo Causale Cliente precedentemente creato (vedi Client Custom Field). Il valore da inserire deve rispettare un formato prestabilito che è costituito da 4 sezioni separate dal carattere "|":

• La prima parte deve essere esattamente INTENTO
• La seconda LETTERA D'INTENTO
• La terza corrisponde al numero protocollo (17 cifre) seguito da un segno "/" o "-" e il numero progressivo (6 cifre) senza spazi
• La quarta è la data della lettera nel formato YYYY-MM-DD

Di seguito forniamo un esempio. Si prega di ignorare "L. INTENTO". La dicitura correntemente utilizzata dall'Agenzia delle Entrate è semplicemente "INTENTO".

Precisiamo che la lettera di intento ha una data di validità prestabilita e che pertanto il cliente di volta in volta dovrà fornirti il numero e la data aggiornati. Generalmente questo accade su base annuale.

Concludiamo il capitolo precisando che ci rendiamo perfettamente conto che questa funzionalità rispetto a tutte le altre del modulo è un po' macchinosa.

Il motivo è che vista la categoria merceologica trattata in WHMCS (hosting e domini) di norma non si ha a che fare con soggetti beneficiari di lettera di intento. Ciononostante abbiamo comunque inserito il supporto per i pochi che ne hanno bisogno.

Configurazione Nodo FTP

Abbiamo spesso parlato di nodo FTP. Vediamo nella pratica come è strutturato. Qui in basso puoi vedere un'anteprima di un nodo FTP al quale ci siamo collegati con FileZilla. Come puoi osservare, nella root del nodo vengono memorizzati gli XML.

Specifichiamo che non dovrai mai collegarti al nodo con un client FTP se non la prima volta per eseguire una semplice operazione. Per il resto si fa tutto dall'interfaccia di WHMCS grazie a Billing Extension.

L'unica cosa che devi fare è creare due cartelle nelle quali saranno spostati gli XML distinguendoli tra trasmessi e scartati. Come da specifiche dello SdI, raccomandiamo di utilizzare i nomi INVIATE e NON_INVIATE.

Ciò detto, alcuni intermediari potrebbero utilizzare nomi differenti per le cartelle. Quello che conta è saperlo ed adattarsi di conseguenza. La struttura può essere riassunta come segue:

• Nella root ci sono gli XML in attesa di trasmissione
• Nella cartella INVIATE ci sono gli XML trasmessi con successo all'Agenzia
• In NON_INVIATE ci sono gli XML scartati

Per completezza di informazioni, ogni volta che manualmente o automaticamente un XML viene contrassegnato come inviato piuttosto che scartato o in attesa di trasmissione, la modifica si riflette nel nodo FTP. L'XML si sposta da una cartella all'altra dipendentemente dal suo status.

Dopo aver creato le cartelle di cui sopra, è necessario "comunicarlo" a Billing Extension in modo che sappia dove spostare gli XML in base dall'esito della trasmissione. Questo può essere fatto da Addons > Billing Extension > Settings > Fatturazione Elettronica > Intermediario selezionando l'opzione Manuale.

Nota bene: se come intermediario utilizzi Digiting (maggiori informazioni più avanti), seleziona Digiting. Non è necessario indicare i nomi delle cartelle in quanto il modulo già sa come comportarsi (si usa la forma standard INVIATE e NON_INVIATE).

Scelta dell'intermediario

Qui apriamo un capito delicato che riguarda un certo tipo di scelte che la maggior parte degli intermediari ha compiuto e che non condividiamo nel modo più assoluto. Ancora oggi abbiamo portiamo le "cicatrici". Ci teniamo particolarmente a parlarne poiché spiega il motivo per il quale il modulo non è integrato con gli intermediari più noti.

La fatturazione elettronica, prima che nel 2019 diventasse obbligatoria, era già in uso da diversi anni per le operazioni verso la Pubblica Amministrazione. Ne consegue che sia la struttura del nodo FTP che quella degli XML era già stata ampiamente provata sul campo.

Le specifiche tecniche erano note da tempo. Tra l'altro lo SdI non si era limitato a descrivere una sola possibilità di implementazione ma diverse con l'obiettivo di rendere tutto più semplice.

Quando abbiamo iniziato a lavorare all'integrazione con WHMCS, ci siamo subito resi conto che quasi tutti gli intermediari, specialmente i più pubblicizzati ed economici (es. Fatture In Cloud, Fattura24), hanno intenzionalmente complicato le cose principalmente in 3 modi.

1) XML inventati

Anziché attenersi allo standard come era auspicabile fare, molti intermediari si sono inventati dal nulla degli XML proprietari che non avevano alcuna attinenza con l'XML della fatturazione elettronica. L'utente medio senza esperienza di programmazione, era portato a credere che si trattasse della stessa cosa.

Per fare un'analogia, è come se un produttore di periferiche per PC creasse un connettore USB di forma triangolare invece di attenersi allo standard già ampiamente diffuso da anni.

A che scopo si dovrebbe creare una presa USB triangolare piuttosto che un XML proprietario? Semplicissimo. Per vincolare i clienti alle proprie soluzioni. Come potresti mai cambiare intermediario quando hai tra le mani una soluzione che non può essere utilizzata da nessuna altra parte?

Al livello commerciale questa strategia ha sicuramente pagato visto che tante aziende si sono adoperate per uniformarsi a questi XML convinti che si trattasse di quelli standard dello SdI. A distanza di anni e dopo tutti gli investimenti fatti, cambiare intermediario significherebbe gettare via tutto il lavoro fatto e ricominciare da zero.

2) Funzioni extra ma tante limitazioni

Un altro modo con il quale diversi intermediari hanno raggiunto lo scopo di incatenare i propri clienti, è stato quello "ubriacarli" con funzionalità accattivanti. App per telefono, gestori di magazzino fino anche a piattaforme e-commerce.

Tutto molto bello se non fosse che questi intermediari obbligavano i clienti a trasferire i propri processi aziendali da WHMCS alla loro piattaforma. Alcuni richiedevano addirittura che la vendita fosse esternalizzata.

Era semplicemente improponibile doversi mettere ad integrare l'intero WHMCS (clienti, prodotti, vendita, carrello, fatture, preventivi, metodi di pagamento...) con suddette piattaforme.

3) Secondo fine

Nel 2018 abbiamo contattato decine di intermediari con l'obiettivo di realizzare delle integrazioni complete. Avevamo pianificato di completare non meno di 3 integrazioni per offrire una scelta più ampia ai nostri clienti.

Come sai, Billing Extension genera l'XML pronto per per la trasmissione all'Agenzia delle Entrate quindi il grosso del lavoro è già fatto. L'intermediario non deve fare altro che adempiere al suo ruolo e trasmetterlo.

Alla nostra richiesta, come anche a quella di tanti altri sviluppatori di software, abbiamo trovato solo porte chiuse. La spiegazione ufficiale era che gli XML generati da software terzi non potevano essere accetati perché... boh.

È decisamente strano se si pensa che l'unico ostacolo è un semplice file uploader. La triste verità era che questi intermediari volevano utilizzare l'espediente della fatturazione elettronica per veicolare ben altri prodotti:

• Assistenza fiscale ed i propri software di contabilità
• Visure camerali, accesso agli atti...
• Firma digitale, hosting, VoIP e quant'altro

Questo era vero al punto che la fatturazione elettronica ed il servizio di conservazione sostitutiva erano addirittura offerti gratuitamente. Il guadagno per queste aziende era altrove.

Integrazione con Digiting

L'integrazione con Digiting è nata nel contesto che abbiamo descritto nel precedente capitolo. Nel 2018 la stragrande maggioranza degli intermediari più noti si era barricato dietro un muro di totale chiusura.

Ogni intermediario creava un sistema fuori standard obbligando i clienti a sviluppare soluzioni ad-hoc. Di conseguenza l'eventuale passaggio ad un competitor sarebbe stato troppo costoso. Risultato: cliente fidelizzato.

Il 1° gennaio 2019 si avvicinava e non abbiamo avuto altra scelta che rivolgerci all'unico intermediario "aperto" che aveva rispettato gli standard ovvero Digiting. Ad oggi questo è l'unico intermediario che permette la completa automazione:

• Gli XML vengono prelevati dal nodo FTP
• A seconda dall'esito della trasmissione, i file vengono spostati nelle opportune cartelle
• Lo spostamento si riflette anche nell'interfaccia di WHMCS & Billing Extension
• In un click è possibile visualizzare le risposte dell'Agenzia delle Entrate direttamente in WHMCS

Il vantaggio di questa soluzione è che la fatturazione elettronica va avanti da sola. In caso di scarti le motivazioni sono consultabili in WHMCS. A quel punto correggere e ritrasmettere l'XML è questione di un paio di click.

Per poterti avvalere di questa soluzione devi aquistare il servizio su Digiting seguendo le indicazioni consultabili in Addons > Billing Extension > Settings > Fatturazione Elettronica > Intermediario come da screenshot.

Alcune doverose precisazioni:

• Non abbiamo una partnership con Digiting. Katamaze non guadagna nulla se acquisti i loro servizi
• I prezzi di Digiting indicati nel modulo sono indicativi. Per molto tempo abbiamo cercato di capire quali fossero i prezzi definitivi ma in tutta franchezza dopo aver chiesto più volte ci abbiamo rinunciato
• Il sito web di Digiting non è aggiornato (sembra abbandonato) e riporta informazioni confuse

Al netto di questo, il servizio funziona. Cerchiamo sempre di proporre ai nostri clienti il meglio che c'è sul mercato ma per i motivi precedentemente descritti in questo caso ci siamo dovuti accontentare di quello che c'era.

Il consiglio che ci sentiamo di dare è quello di utilizzare Digiting solo se si generano più di 24.000 fatture l'anno. In tutti gli altri casi è preferibile utilizzare la trasmissione manuale descritta di seguito.

Trasmissione manuale fatturazione elettronica

Se generi un numero contenuto di fatture o comunque sotto le 24.000 annue, consigliamo di occuparsi manualmente della trasmissione delle fatture elettroniche. È più semplice di quello che puoi immaginare.

Le fatture elettroniche devono essere trasmesse entro 12 giorni dall'effettuazione dell'operazione (ricezione del pagamento). Ciò significa che devi trasmetterle preferibilmente una volta la settimana.

Posizionati in Addons > Billing Extension > Invoices ed assicurati che la colonna Status XML sia visibile. Applica un filtro in modo che siano visibili solo gli XML Da trasmettere. Se ci sono risultati (XML in blu), utilizza il menu in alto a destra per attivare la modalità Download XML.

Seleziona tutti gli XML e premi il pulsante Download in fondo alla pagina.

Riceverai un file zip con all'interno gli XML suddivisi per fatture singole e lotti di fatture. Spesso infatti gli intermediari non supportano il caricamento simultaneo di lotti e fatture singole. Grazie alla separazione puoi agevolmente caricarle in due tranche.

Estrai il contenuto dello zip sul computer avendo cura di selezionare l'opzione Rinomina tutti (se richiesto). È estremamente importante in quanto nella fatturazione elettronica i nomi dei file sono case sensitive ("A" è diverso da "a").

Sistemi operativi come Windows non supportano nativamente i nomi file case sentitive. Ne consegue che tutti i nomi di XML sotto indicati risulterebbero in un unico file. Le altre versioni vengono sovrascritte.

• IT00159560366_AA.xml
• IT00159560366_Aa.xml
• IT00159560366_aa.xml
• IT00159560366_aA.xml

Supponiamo di utilizzare Aruba come intermediario. Accedi con le tue credenziali a fatturazioneelettronica.aruba.it e clicca su Carica fattura. Trascina gli XML nella finestra e conferma. Se avevi da inviare sia lotti che fatture singole, ripeti l'operazione per la parte che non hai ancora inviato.

Se tutte le fatture sono state accettate, torna su Addons > Billing Extension > Invoices (la pagina che hai utilizzato per scaricare lo zip). Questa volta attiva la modalità Mark as Sent che serve a contrassegnare gli XML come inviati.

Alla conferma gli XML blu (da trasmettere) diventeranno verdi (inviati). Precisiamo che al ricaricamento della pagina non vedrai gli XML oggetto della modifica in quanto il filtro Da trasmettere nella colonna Status XML è ancora attivo.

Se da Aruba ricevi errori e/o scarti, correggi le fatture interessate dal problema. Se sono molte o vuoi che se ne occupi un'altra persona, potresti contrassegnarle manualmente come scartate utilizzando il Mark as Rejected. Una volta fatte le correzioni reigenera l'XML e trasmettilo.

È un'operazione molto semplice che richiede davvero pochi minuti specialmente dopo averci preso la mano. Abbiamo centinaia di clienti che ogni settimana inviano centinaia di fatture. La quantità di scarti/errori rasenta lo zero.

Invio tramite SdI

Esiste un terzo modo per inviare gli XML all'Agenzia delle Entrate. Tra tutte le soluzioni questa è la più difficile da attuare. Viene utilizzata da grandi aziende che hanno accreditato un canale trasmissivo presso il SdI. In breve consiste nel diventare l'intermediari di sé stessi.

Le implicazioni tecniche sono elevate e non saranno trattate in questo capitolo. Ci limitiamo a dire che Billing Extension può applicare la firma digitale con relativa crittografia nei file XML tramite OpenSSL. Per questa soluzione non offriamo assistenza poiché la configurazione del canale di trasmissione non riguarda Billing Extension.

Progressivo invio

Il capitolo contiene dettagli riguardanti il progressivo invio che è un dato che indentifica univocamente un XML. Se lo desideri puoi evitare la lettura di questo capitolo. Di seguito riportiamo le informazioni fondamentali:

• Un esempio di progressivo invio è IT0015960366_4.xml
• La prima parte corrisponde al tuo numero di partita IVA
• Un underscore svolge il ruolo di separatore
• Nella seconda parte abbiamo il progressivo invio con le seguenti caratteristiche:
  • Da 1 a 5 caratteri alfanumerici
  • Case sensitive ("A" è diverso da "a")
• Infine troviamo l'estensione del file

Se ti interessa conoscere maggiori dettagli, prosegui nella lettura altrimenti puoi passare al capitolo successivo. L'Agenzia delle Entrate ha stabilito che ogni file XML debba assumere la nomenclatura precedentemente descritta.

Ad una prima analisi per questioni di semplicità si potrebbe pensare di utilizzare un progressivo invio numerico (1, 2, 3...). Così facendo però si potrebbero emettere solo 99.999 XML per via del limite di 5 caratteri.

Dal momento che la conservazione sostitutiva impone che gli XML vengano archiviati per un periodo di almeno 10 anni, ciò significherebbe poter emettere in media solo 9.999 XML all'anno. I progressivi già utilizzati vengono liberati solo quando gli XML vengono eliminati decorsi i termini di legge.

Non abbiamo la sfera di cristallo per vedere cosa da qui a 10 anni faranno le varie piattaforme intermediarie. Alcune potrebbero "dimenticarsi" di cancellare gli XML oppure decidere di conservare i file per un periodo di tempo più lungo.

In questo caso il limite dei 9.999 XML annuali si abbasserebbe drasticamente. Senza considerare due altri fattori:

• Le fatture scartate "bruciano" comunque un progressivo numerico
• Se hai altri cilci attivi (es. negozi fisici, un altro e-commerce), tutti andranno ad "intaccare" le stesse combinazioni disponibili

Per evitare problemi, si potrebbe quindi immaginare di utilizzare un generatore casuale di progressivi invio. Anche in questo caso l'opzione non è percorribile. All'aumentare degli XML aumenta la possibilità che si verifichi una collisione di nomi e quindi scarti.

Ciò premesso, abbiamo ideato un sistema che permette di ottenere il massimo numero possibile di combinazioni senza possibilità di collisioni. Parliamo di 931 milioni di XML, più precisamente 931.151.402.

Se pensiamo che in Italia in tutto il 2019 sono state emesse 2 miliardi di fatture elettroniche, possiamo affermare con certezza che 931 milioni di XML (il 45% del totale nazionale) sono più che sufficienti per qualsiasi azienda.

Di tanto in tanto alcuni clienti ci chiedono se non sia possibile rendere più "bello" il progressivo invio. Dopo aver letto questo capitolo, comprenderai che il progressivo invio è il fondamento stesso della fatturazione elettronica. Non si tratta di un dato che può piegarsi a logiche puramente estetiche.

Cicli attivi multipli

Questo capitolo è dedicato alle aziende che si trovano a gestire più di un ciclo attivo ovverosia che emettono XML da più sistemi, negozi, e-commerce e quant'altro. Se non rientri in questa casistica, puoi saltare il capitolo.

Se hai più cicli attivi, assicurati di aver letto e compreso quanto descritto nel capitolo precedente. Per evitare che i diversi sistemi, negozi e siti web si "rubino" i progressivi invio a vicenda, è sufficiente che ciascuno utilizzi un prefisso dedicato come nel seguente esempio:

• A per WHMCS
• B per un altro WHMCS
• C per un e-commerce Magento
• D per un negozio fisico

Puoi scegliere liberamente le lettere da utilizzare ma è fondamental tenere a mente tre cose:

• Il prefisso deve essere di una sola lettera
• Il valore è case sensitive ("A" è diverso da "a")
• La K maiuscola non può essere utilizzata come prefisso in quanto svolge il ruolo di separatore

Se hai due WHMCS (potresti trovare interessante l'Invoice Sync) in entrambi devi specificare il prefisso che hai scelto da Addons > Billing Extension > Settings > Fatturazione elettronica > Prefisso progressivo.

Riprendendo l'esempio di cui sopra, indicherai la "A" per il primo WHMCS e "B" per l'altro. Così facendo i due WHMCS genereranno XML con progressivi del genere:

• 1° WHMCS: AK0, AK1, AK2, AK3...
• 2° WHMCS: BK0, BK1, BK2, BK3...

Qui puoi osservare il ruolo di separatore che svolge la lettera K maiuscola. Compreso il funzionamento, replicalo su eventuali altri sistemi. Riprendendo l'esempio di cui sopra avremo:

• Magento: CK0, CK1, CK2, CK3...
• Negozio fisico: DK0, DK1, DK2, DK3...

L'ultimo passaggio riguarda il numero della fattura (quello visibile nel PDF in WHMCS) che deve essere reso "univoco". Per intenderci se emetti la fattura #150 su WHMCS e poi anche su Magento, l'intermediario scarterà una delle due fatture in quanto duplicata.

In questo caso puoi liberamente intervenire sul formato della numerazione fattura agendo su Addons > Billing Extension > Settings > Invoices > Number Format. Di seguito una possibile implementazione:

• 1° WHMCS: Red-2020-1, Red-2020-2, Red-2020-3...
• 2° WHMCS: Blue-2020-1, Blue-2020-2, Blue-2020-3...
• Magento: Ecom-2020-1, Ecom-2020-2, Ecom-2020-3...
• Negozio fisico: Store-2020-1, Store-2020-2, Store-2020-3...

Web Service fatturazione elettronica

Per integrazioni personalizzate puoi utilizzare il web service integrato nel modulo che fornisce tutti i dati utili alla creazione di un XML.

Per questioni di sicurezza è richiesta la generazione di un token segreto reperibile da Addons > Billing Extension > Settings > Fatturazione elettronica > Token (è necessario attivare il Webservice).

Il funzionamento del web service è subordinato alla corretta configurazione della fatturazione elettronica. Qui è disponibile un codice PHP di esempio. Di seguito elenchiamo i possibili errori che può riportare il web service.

Nel codice d'esempio precedentemente fornito è presente anche il file response.json al cui interno è riportato un esempio di risposta da parte del web service.

Possiamo osservare la presenza di fatture relative a due clienti rispettivamente con ID 3 e 1 (gli user ID di WHMCS tblinvoices.id). Se IdFiscaleIVA è true, il cliente in oggetto è un'azienda. Nel caso di soggetti intra-EU l'informazione è veritiera al 100% in quanto proveniente direttamente dal VIES.

Nell'immagine che segue abbiamo espanso il nodo invoices del cliente #1. Ciascuno di questi ID corrisponde ad una fattura o ad una nota di credito (ID fattura WHMCS tblinvoices.id).

In quest'ultima immagine vediamo il dettaglio di una fattura ed una nota di credito. Al loro interno troviamo sia i dati della fattura che delle le voci contenute al loro interno (gli ID delle voci corrispondono a quelli di WHMCS in tblinvoiceitems.id).

Il web service fornisce sia i dati formattati che quelli originali sui quali non è stato applicato alcun controllo. Tali valori vengono contrassegnati dal prefisso raw_.

Come per la generazione degli XML, anche le richieste inviate al web service riportano gli eventuali errori presenti nel centro notifiche. Gli errori sono contenuti nel nodo error in fondo al json. Gli ID sono quelli delle fatture. Se non trovi il nodo error significa che non ci sono errori.

Alcune considerazioni finali:

• FormatoTrasmissione
  • FPR12 (privati, aziende, associalzioni...)
  • FPA12 (Pubblica Amministrazione)
• TipoDocumento
  • TD01 per le fatture
  • TD04 per le note di credito

Overriding fatturazione elettronica

Oltre al nodo FTP, agli XML, al web service e tutte le diverse possibili integrazioni, mettiamo a disposizione anche la possibilità di fare l'overriding dello script che genera gli XML. Tutte le informazioni sono contenute nel seguente script.

modules/addons/BillingExtension/core/BlillingExtension_Admin/resources/einvoiceit/__Overrides.php