Fatturazione Elettronica WHMCS Trasmissione XML SdI AdE

Indietro   Pubblicato 29 ottobre 2018 / Aggiornato 28 maggio 2021
Tempo di lettura 48 minuti

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.

Casistiche Spiegazione
Fattura emessa verso il consumatore finale I soggetti privati non hanno l'obbligo di munirsi di una casella PEC piuttosto che di un canale telematico per la ricezione delle fatture elettroniche
Operazioni comunitarie ed extra comunitarie Per ovvi motivi un cliente francese piuttosto che canadese non può in alcun modo ricevere fatture elettroniche

È 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.

Livello Spiegazione
Globale Concetti come le note di credito piuttosto che l'applicazione delle tasse sul credito, la gestione pagamenti in eccesso, il blocco dei dati di fatturazione, l'archiviazione automatica delle fatture e il gestore di cassa sono comuni a tutti i paesi del mondo
Unione Europea La verifica delle partite IVA nel VIES, la legge sui cookie, l'esenzione dalle tasse dipendentemente dalla forma giuridica e quan'altro sono comnuni a tutti i paesi Membri dell'Unione Europea
Nazionale Al livello nazionale ci siamo occupati dettagliatamente di Italia, Australia, Slovenia, Finlandia e Germania

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.

Termine Definizione
XML

La fattura elettronica altro non è che un file XML che contiene al suo interno tutti i dati relativi alla fattura. Grosso modo si tratta degli stessi contenuti nella versione cartacea:

  • Dati dell'emittente (ditta, denominazione, partita IVA, indirizzo)
  • Dati del cliente
  • Voci fattura con relativi importi
  • Natura dell'operazione (intra/extra EU, estente IVA, split payment ecc.)

Billing Extension si occupa di elaborare i dati necessari alla creazione dell'XML nonché di verificare la loro correttezza con controlli formali (es. codice fiscale, CAP) e sostanziali (es. VIES)

Lotto di fatture Un singolo file XML può contenere più fatture. In questo caso si parla di lotto di fatture. Tra un XML contenente una singola fattura ed uno contenente un lotto, non vi è alcuna differenza sostanziale
Progressivo invio / prefisso progressivo

Il nome di ogni file XML segue una particolare nomenclatura che permette di individuarlo univocamente. Facendo un'analogia con le fatture cartacee, è lo stesso concetto del numero di fattura che nell'ambito della fatturazione elettronica prende il nome di progressivo invio.

Diciamo fin da subito che il progressivo invio non è fatto per essere "bello" e non corrisponde al numero della fattura. La buona notizia è che di tutto questo non devi occuparti. L'unica cosa da tenere a mente è che il progressivo invio è case sensitive ("A" è diverso da "a").

Nota di credito elettronica

Il rovescio di una fattura si definisce nota di credito. La nota di credito non è altro che una fattura negativa dove si registrata una fuoriuscita di soldi (es. un rimborso al cliente) invece che un incasso.

Di riflesso nella fatturazione elettronica è prevista la presenza delle note di credito elettroniche. Come per i lotti di fatture, non vi sono sostanziali differenze tra fatture e note di credito. Cambia solo la "direzione" del flusso di denaro

Specifichiamo che un XML può contenere un lotto sia di fatture che note di credito.

Nodo FTP I file XML creati da Billing Extension, vengono memorizzati in una cartella FTP di tua scelta. In gergo tecnico tale cartella viene definita con il termine nodo FTP
SdI Con SdI (Sistema di Interscambio) si intende il sistema informatico gestito dall'Agenzia delle Entrate in grado di ricevere le fatture elettroniche
Intermediario

Gli XML devono essere trasmessi all'Agenzia delle Entrate che a sua volta si occuperà di recapitarle al cliente. La figura preposta all'invio degli XML è quella dell'intermediario che:

  • Preleva gli XML dal nodo FTP o da un file uploader
  • Li firma digitalmente e consegna all'Agenzia delle Entrate
  • Attende risposta da parte dell'Agenzia delle Entrate circa l'esito della trasmissione
  • In caso di risposta positiva, si occupa della conservazione sostitutiva
Conservazione sostitutiva Gli XML trasmessi hanno valore legale pertanto devono essere memorizzati per un periodo non inferiorie a 10 anni. Al fine di evitare possibili manomissioni o modifiche, i file vengono anche firmati digitalmente. Di tutto questo si occupano gli intermediari in modo del tutto automatico
Codice destinatario

Nella fatturazione elettronica l'Agenzia delle Entrate svolge il ruolo di "postino". Tutti gli XML trasmessi vengono recapitati all'intestatario della fattura (solo se questo è italiano).

Per rendere possibile l'invio, l'Agenzia delle Entrate ha bisogno di un "recapito" denominato codice destinatario. Dipendentemente dal tipo di attività svolta, il codice potrà essere di 7 o 6 caratteri oppure coincidere con la PEC

PEC Posta elettronica certificata la cui funzione è quella dare ad un messaggio di posta elettronica lo stesso valore legale di una tradizionale raccomandata con avviso di ricevimento. Nell'ambito della fatturazione elettronica, la PEC può essere utilizzata come codice destinatario
Split Payment

La Pubblica Amministrazione, le aziende partecipate o controllate dallo stato e quelle quotate in borsa, funzionano secondo il principio dello split payment o scissione dei pagamenti.

A un cliente soggetto a split payment che acquista un prodotto sul tuo sito, non dovrai far pagare l'IVA in quanto questa sarà direttamente versata allo Stato per altre vie

Forma giuridica, entità, tipo di soggetto

Lo stato italiano riconosce diversi tipi di forme impenditoriali:

  • Ditta individuale
  • Società in nome collettivo (S.n.c.)
  • Società in accomandita semplice (S.a.s.)
  • Società a responsabilità limitata (S.r.l.)
  • Società per azioni (S.p.A.)
  • Società in accomandita per azioni (S.a.p.A.)

A queste forme si aggiungono:

  • Privati
  • Pubblica Amministrazione
  • Associazioni
  • Organizzazioni

Nell'ambito della fatturazione elettronica, sussistono differenze sostanziali tra le succitate tipologie di soggetto. La bella notizia è Billing Extension gestisce automaticamente il tutto

Codice CUP/CIG

Quando si emette una fattura elettronica verso una Pubblica Amministrazione (una scuola, un ospedale...) questa deve essere messa nelle condizioni di poter fornire due codici:

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

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.

Casistiche Descrizione
Intermediario integrato in Billing Extension Se utilizzi un intermediario integrato in Billing Extension, la trasmissione degli XML dal nodo FTP all'Agenzia delle Entrate è automatica come anche la notifica degli esisti di trasmissione
Intermediario alimentabile via nodo FTP

Gli intermediari sprovvisti di integrazione con il modulo possono comunque essere automatizzati nel caso in cui supportino il formato di trasmissione via nodo FTP come da specifiche dello SdI.

In tal caso è sufficiente fornire all'intermediario le credenziali FTP. In seguito a questo, l'intermediario si connetterà al server una o due volte al giorno per prelevare gli XML e trasmetterli

Trasmissione manuale

Questo è lo scenario più diffuso che consiste nell'inviare manualmente mediante file uploader tutti gli XML in attesa di trasmissione in un'unica soluzione.

Tale operazione deve essere svolta almeno una volta la settimana per evitare di incorrere in sanzioni per invito tardivo.

Benché a prima vista possa sembrare un'operazione complicata, è in realtà semplice e sbrigativa. Billing Extension permette di scaricare tutti gli XML in pochi click in un unico archivio Zip da caricare sulla piattaforma intermediaria. In pochi secondi è possibile inviare centinaia di fatture

Soluzioni personalizzate

Nel caso in cui desideri integrare WHMCS e Billing Extension con un software di contabilità piuttosto che con un intermediario di tua scelta, puoi utilizzare il Web Service integrato nel modulo

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.

Entità Dati richiesti
Privato
  • Codice fiscale
  • Codice destinatario (facoltativo)
  • Indirizzo PEC (facoltativo)
Ditta individuale, professionista
  • Denominazione
  • Codice fiscale personale
  • Partita IVA
  • Codice destinatario (facoltativo)
  • Indirizzo PEC (facoltativo)
Azienda (società di persone o capitali)
  • Denominazione
  • Codice fiscale azienda
  • Partita IVA
  • Codice destinatario (facoltativo)
  • Indirzzo PEC (facoltativo)
  • Split Payment (facoltativo)
Associazione
  • Denominazione
  • Codice fiscale personale o dell'associazione
  • Partita IVA (facoltativo)
  • Codice destinatario (facoltativo)
  • Indirizzo PEC (facoltativo)
Pubblica Amministrazione
  • Denominazione
  • Codice fiscale
  • Partita IVA (facoltativo)
  • Codice destinatario
  • Indirizzo PEC (facoltativo)
  • Split Payment
Privato intra EU Nessuno
Privato extra EU Nessuno
Azienda intra EU
  • Vat Number iscritto al VIES
Azienda extra EU Nessuno

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.

Parametro Obbligatorio Note
Partita IVA Si

Può essere condiviso con quello utilizzato dai clienti esteri per inserire i VAT Number (l'equivalente estero della partita IVA). Dal momento che ogni persona scrive la partita IVA in modo diverso, precisiamo che Billing Extension riconosce tutti i formati:

  • IT01230456078
  • 01230456078
  • IT-01230456078
  • IT 01230456078

Di seguito mostriamo come deve essere configurato il Custom Client Field.

Importante: a partire da WHMCS 7.7, è stato aggiunto il campo Tax ID che tuttavia noi non consideriamo perché inattendibile.

Codice fiscale Si

Con codice fiscale si intende:

  • Per le persone fisiche è il codice fiscale personale
  • Per le aziende spesso corrisponde alla partita IVA. È tuttavia possibile che le due cose non coincidano. È il caso delle aziende che hanno trasferito il domicilio fiscale da una provincia all'altra. In questo caso viene attribuito un nuovo numero di partita IVA ma il codice fiscale resta lo stesso
  • Alcune associazioni dispongono di codice fiscale

Di seguito mostriamo come deve essere configurato il Custom Client Field.

Codice destinatario Si

Può assumere 4 diversi formati:

  • Codice SdI a 7 caratteri per privati/aziende
  • Codice iPA a 6 caratteri per la Pubblica Amministrazione
  • Indirizzo email PEC per privati/aziende sprovvisti di Codice SdI
  • Nessun valore per clienti esteri o soggetti privati italiani sprovvisti di PEC o Codice SdI

Di seguito mostriamo come deve essere configurato il Custom Client Field.

PEC No

Si consiglia comunque di richiedere questo dato in quanto può sempre tornare utile avere a disposizione la PEC dei clienti. Di seguito mostriamo come deve essere configurato il Custom Client Field.

Causale cliente No

Necessario solo se hai a che fare con clienti esportatori abituali che operano con lettera di intento. Diversamente dagli altri campi, questo è visibile/impostabile solo dagli amministratori di WHMCS. Nel capitolo successivo forniremo maggiori dettagli.

Di seguito mostriamo come deve essere configurato il Custom Client Field.

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). Successivamente utilizza lo strumento di verifica della dichiarazione di intento. La verifica è importante in quanto stai permettendo ad un cliente di non pagare l'IVA.

Se il check ha esito positivo, puoi attivare l'esenzione dalle tasse per il cliente in oggetto. 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. Il valore da inserire deve rispettare un formato prestabilito che è formato da 4 sezioni separate dal carattere "|":

  • La prima parte deve essere esattamente L. INTENTO
  • La seconda LETTERA D'INTENTO
  • La terza corrisponde al numero della lettera fornita dal cliente
  • La quarta è la data della lettera nel formato YYYY-MM-DD

Di seguito forniamo un esempio. 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, rispetto a tutte altre funzionalità del modulo, la gestione della lettera di intento è un po' macchinosa. Il motivo è che in WHMCS non si ha a che fare con prodotti fisici ed esportatori abituali ma raramente alcuni clienti ce lo richiedono e quindi abbiamo ci siamo adoperati di conseguenza.

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.

Errore Descrizione
WebService Disabled Non hai attivato il web service da Addons > Billing Extension > Settings > Fatturazione elettronica > Webservice.
No Token Set Non hai impostato un token di sicurezza in Addons > Billing Extension > Settings > Fatturazione elettronica > Token.
Invalid Token Il token in uso non corrisponde a quello presente nel modulo
Unrecognized action L'unico comando al momento supportato è GetInvoices.
Date not specified Non hai indicato una data, un range di date o un periodo di riferimento

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

Commenti (0)

Dì ciò che pensi Cancella Risposta