Salta ai contenuti

Invio di file XML

La conformità TicketBAI prevede la creazione di due tipi di file XML:

  • File di registrazione: File XML creato quando viene emessa una nuova fattura.

  • File di cancellazione: File XML creato quando una fattura viene annullata, ad esempio per transazioni non effettuate.

TicketBAI richiede che questi file vengano inviati all’autorità fiscale competente, a seconda di dove è dichiarato l’indirizzo legale del contribuente che emette le fatture.

SIGN ES esegue l’invio automaticamente in Araba e Gipuzkoa. Le fatture inviate da SIGN ES vengono utilizzate come “Libro delle fatture emesse” del sistema SII (Suministro Inmediato de Información) per i contribuenti soggetti ad esso. Tuttavia, se sono richieste informazioni aggiuntive come previsto dal SII, come riferimenti esterni, trasferimenti immobiliari soggetti a IVA, tra gli altri, queste dovranno essere inviate tramite un servizio aggiuntivo chiamato OSATU, non previsto nelle specifiche TicketBAI (vedere i requisiti del servizio OSATU disponibili in spagnolo).

Il processo di invio dei file TicketBAI viene eseguito nel componente di firma dell’API SIGN ES. Il componente di firma sincronizza lo stato dei file TicketBAI dal server SIGN ES al server dell’autorità fiscale spagnola. Questa sincronizzazione è implementata sul modello di richiesta/risposta fornito dall’autorità fiscale spagnola.

Quando un file viene inviato, i sistemi delle autorità fiscali eseguono automaticamente varie validazioni, e i risultati di queste verifiche sono inclusi nella risposta.

Lo stato di registrazione ideale è REGISTERED. SIGN ES aiuta a ridurre i rifiuti garantendo che i file XML siano correttamente strutturati e che i dati siano formattati accuratamente attraverso i suoi processi di validazione.

Tuttavia, se lo stato di registrazione di una fattura appare come REQUIRES_CORRECTION, potrebbe essere necessario reinviare il file, a condizione che le normative di fatturazione spagnole non richiedano l’emissione di una fattura correttiva.

SIGN ES consente il reinvio delle fatture negli stati di registrazione REGISTERED, REQUIRES_CORRECTION e REQUIRES_INSPECTION tramite fatture REMEDY a Zuzendu nei seguenti casi:

  • i file di registrazione sono stati rifiutati
  • i file di registrazione sono stati accettati con errori ma NON richiedono una correzione per legge
  • file accettati da TicketBAI, dove il contribuente deve modificare informazioni che non richiedono una correzione per legge

Se viene ricevuto un errore perché il contribuente non ha registrato il certificato dispositivo in Araba o ha superato il periodo di accettazione di 30 giorni in Gipuzkoa, il contribuente deve prontamente registrare o accettare il certificato dispositivo, a seconda del territorio pertinente.

Il reinvio delle fatture con stato di registrazione PENDING o STORED non è consentito. Queste fatture sono in attesa di presentazione da parte di SIGN ES o sono archiviate perché la trasmissione all’autorità fiscale non è necessaria.

L’invio viene effettuato utilizzando un certificato dispositivo che deve essere registrato presso DFB/BFA dal contribuente obbligato. Questo deve essere fatto prima che il dispositivo inizi a generare fatture per conto del contribuente.

Inviando le fatture in tempo reale garantiamo il rispetto delle scadenze imposte da BATUZ.

AZIENDE: SIGN ES esegue l’invio automatico delle fatture TicketBAI nella sottosezione 1.1 del LROEFatture emesse con software garante (Modello 240). Questa presentazione è in tempo reale.

PERSONE FISICHE: una volta fornito il codice di attività, SIGN ES esegue l’invio delle fatture TicketBAI nella sottosezione 1.1 del LROEEntrate con fatture emesse con software garante (Modello 140).

Idealmente, l’activity_code dovrebbe essere fornito al momento della creazione della fattura. Questo consente la trasmissione in tempo reale della fattura alle autorità fiscali. In caso contrario, la fattura rimarrà in stato STORED e verrà inoltrata alle autorità fiscali solo dopo che la fattura è stata aggiornata con il codice di attività.

Per le persone fisiche, ci sono due campi opzionali aggiuntivi: income_tax_amount e pay_collect, che insieme all’activity_code formano un insieme raggruppato di dati. Se questi campi vengono lasciati vuoti mentre viene fornito il codice di attività, verranno automaticamente contrassegnati come ‘No’ per impostazione predefinita.

Se la base IVA è diversa dai redditi IRPF del contribuente, il contribuente dovrà compilare il campo income_tax_amount. Per indicazioni su come calcolarlo, è possibile consultare il nostro articolo Come calcolare l’importo del reddito IRPF su una fattura?

Il campo pay_collect indica se il contribuente ha scelto di aderire al criterio di incassi e pagamenti.

Il campo vat_withholding nella nostra API potrebbe applicarsi sia alle persone fisiche che alle aziende, in particolare alle transazioni B2B che includono fatture complete e le relative correzioni. Questo campo riguarda uno specifico scenario del sistema fiscale che coinvolge lavoratori autonomi che, quando emettono fatture ad aziende o altri lavoratori autonomi, sono tenuti a trattenere una parte dell’IRPF (imposta sul reddito delle persone fisiche) sui loro redditi. In questo sistema, è l’acquirente, non il venditore, a versare direttamente una parte dell’imposta all’autorità.

Al ricevimento di una richiesta, i sistemi dell’autorità fiscale di Bizkaia eseguono automaticamente validazioni, e il risultato di queste validazioni si riflette nella risposta, come nelle altre province.

Idealmente, lo stato di registrazione dovrebbe essere REGISTERED. SIGN ES aiuta a minimizzare i rifiuti garantendo la corretta struttura dei file XML e il corretto formato dei dati inseriti attraverso le validazioni applicate.

Tuttavia, se lo stato di registrazione di una fattura mostra REQUIRES_INSPECTION, è probabile che i file debbano essere reinviati al sistema dell’autorità fiscale di Bizkaia, a condizione che la normativa di fatturazione spagnola non richieda una fattura correttiva. A seconda del caso, questo può essere fatto tramite il reinvio della sottosezione 1.1 per fatture emesse con software garante o tramite la sottosezione 1.2 per fatture emesse senza software garante.

SIGN ES consente il reinvio delle fatture in stato di registrazione REQUIRES_INSPECTION tramite fatture REMEDY attraverso le sottosezioni 1.1 e 1.2. Il reinvio delle fatture con stato di registrazione PENDING e STORED non è consentito. Queste fatture sono in attesa di presentazione da parte di SIGN ES o sono archiviate perché la trasmissione all’autorità fiscale non è richiesta o mancano informazioni importanti.

Il reinvio tramite la sottosezione 1.1 è possibile se:

  • l’errore è dovuto a dati non validi inseriti nei campi del blocco annotations
  • il certificato dispositivo non era registrato o era registrato in modo errato dal contribuente al momento della trasmissione

Il reinvio tramite la sottosezione 1.2 è possibile se:

  • la sottosezione 1.1 è stata rifiutata e il reinvio tramite 1.1 non è possibile
  • se la fattura è già stata corretta e inviata tramite 1.2. È anche possibile correggere la fattura corretta se la fattura di rimedio è nello stato REGISTERED

Le fatture emesse offline a Bizkaia sono classificate come “emesse senza software garante” e devono essere trasmesse alla sottosezione 1.2 del LROE.

Per trasmettere queste fatture, è necessario prima registrarle nel sistema SIGN ES come fatture esterne, utilizzando il tipo di fattura EXTERNAL. Questo passaggio è essenziale per assegnare un UUID alla fattura generata offline.

Quando la fattura viene caricata come fattura EXTERNAL, non verrà trasmessa all’agenzia fiscale. Invece, come qualsiasi altra fattura esterna, avrà uno stato di registrazione INVALID.

Per trasmettere la fattura, il passaggio successivo richiede la creazione di una fattura di tipo REMEDY, con riferimento all’UUID precedentemente assegnato alla fattura esterna.

L’ambiente di test a Bizkaia richiede NIF, numero IVA e certificato dispositivo specifici per evitare errori di rifiuto. Presso fiskaly, abbiamo formalmente richiesto e ottenuto queste informazioni dalle autorità. Questi dettagli specifici sostituiranno automaticamente i dati di test forniti durante la creazione dei file XML, SOLO NELL’AMBIENTE DI TEST. In questo modo, garantiamo un flusso di lavoro di test fluido con risposte di trasmissione efficaci.

Was this page helpful?