TD28 per fatture da San Marino (da 1 ottobre 2022): contraddizione nelle specifiche?

Ho cominciato a guardare le nuove specifiche 1.2.2 (documenti 1.7.1 o FatturaPA 1.3.2) per la fatturazione elettronica, in vigore dal 01/10/2022, dove viene introdotto il nuovo tipo di documento TD28.

Nella descrizione dei casi d’uso del TD28, sembrerebbe proprio essere un caso di autofattura, in cui vado a rendere elettronica una fattura che ricevo cartacea da San Marino. Tuttavia, noto le seguenti inconsistenze:

  • nell’elenco delle modifiche del documento Allegato A - Specifiche tecniche in versione 1.7.1 non si fa accenno alla modifica dei controlli effettuati con codice d’errore 00404 e 00409, sebbene il corrispondente paragrafo includa ora anche TD28 nei tipi di documento che causano l’inversione del controllo di univocità su data/numero della fattura (in capo al C/C anziché al C/P)
  • nel documento Elenco dei controlli effettuati sul file fattura del Sistema di Interscambio in versione 1.8, per i codici di errore 00404 e 00409 ancora non si fa accenno al controllo sui tipi di documento per l’inversione del controllo di univocità di data/numero fattura (in capo al C/C anziché al C/P), ma si fa ancora solo riferimento al campo SoggettoEmittente; si tratta di un’ambiguità già presente, che dunque non è stata sanata; tenendo conto che il Sistema di Interscambio è unico, a mio parere dovrebbero chiarirla (si tratta di un refuso, oppure effettivamente per le fatture in formato PA si usa SoggettoEmittente ignorando i tipi di documento e per le fattura in formato PR si usano i tipi di documento ignorando SoggettoEmittente???)
  • sempre nel documento Allegato A - Specifiche tecniche in versione 1.7.1 (e qui sta il problema principale che mi ha spinto ad aprire questo post), quando si descrivono le modalità di compilazione delle fatture con documento TD28 si dice che:

Campo 2.1.1.4 [nota mia: si tratta del numero del documento] : deve essere riportato la numerazione progressiva indicata nella fattura cartacea ricevuta ed emessa dal fornitore sammarinese.

Ma allora, se nel numero del documento devo metterci il numero assegnato dal fornitore sammarinese, e non una numerazione su cui io ho il controllo, come può SdI effettuare un controllo di univocità di data/numero in capo a me che sono il C/C, secondo quanto indicato nel paragrafo relativo ai codici di errore 00404 e 00409?

Non avrebbe più senso che, come per le altre autofatture, il numero del documento sia assegnato da me e che data e numero della fattura originale sammarinese siano indicati nello spazio dedicato alle fatture collegate?

Qualcuno ha informazioni in merito?

Sinceramente non ho ancora letto nulla circa le nuove specifiche,
concordo su quanto dici, circa il numero del documento emesso da chi lo fa, e di mettere il riferimento della fattura del fornitore in “fatture collegate”

1 Mi Piace

Per logica dovrebbe comportarti come le autofatture e dunque seguire la numerazione assegnata al documento e non quella del fornitore, ovviamente indicando la fattura in fatture collegate.

In ogni caso mi sembra che non è stato pubblicato ancora il foglio di stile nella versione 1.2.2, quindi dalle simulazione fatte ovviamente non riconosce il TD28.

Avete novità sul foglio di stile?

Io mi sono modificato quello vecchio, è piuttosto banale.

Ormai con questi fogli di stile che ogni tanto pubblicano, ogni tanto no, è un marasma nel marasma.

Avevo pensato anche io di modificare la parte inerente i documenti :slight_smile:

lo faccio in via provvisoria che diventerà definitiva;)

Io uso il foglio di stile Assoinvoice, sicuramente lo modificheranno a breve.

Considerato che hanno modificato molti controlli, chiedo:
tu utilizzi un programma di “xsd validator” ?
Esiste un programma di validator richiamabile da “linea di comando” ?

Chiedo perchè: scaricando il nuovo file .xsd (quello in vigore dal 1^ Ottobre), il tutto si risolve facilmente.

A livello di schema non è cambiato praticamente nulla, hanno solo aggiunto il TD28.
I controlli fatti da SdI vanno oltre lo schema e controllano la coerenza dei dati secondo logiche fiscali, semantiche o quant’altro.

Scusate, ma questo documento TD28 serve solo per dematerializzare la fattura cartacea che proviene da un acquisto da San Marino? Cioè un po’ la stessa cosa che si fa con il ‘nuovo esterometro’ dove si crea una fattura con i dati del fornitore?

Si in pratica è solo una “dematerializzazione” della fattura cartacea con IVA esposta che sostituisce l’esterometro.
Il fornitore di San Marino versa l’IVA direttamente all’erario italiano quindi in questo caso non c’è niente da integrare perchè l’IVA “italiana” è già esposta sulla fattura cartacea
E’ solo una “comunicazione”.

La rottura di scatole è quella di dover indicare il originale della fattura del fornitore sanmarinese nel campo 2.1.1.4 invece che una propria numerazione interna come per le fatture di integrazione TD16, TD17, TD18 e TD19

Non avrebbe più senso che, come per le altre autofatture, il numero del documento sia assegnato >da me e che data e numero della fattura originale sammarinese siano indicati nello spazio >dedicato alle fatture collegate?
Certo che avrebbe più senso

1 Mi Piace

Stando così come sono le specifiche in revisione 1.7.1, non è solo una scocciatura, ma è proprio una contraddizione, perché poi i controlli 00404 e 00409 controllano l’univocità di numero e data fattura in capo al cessionario/committente.
Per cui, o è sbagliata la richiesta di indicare il numero originale della fattura, o sono sbagliate le indicazioni riportate per i controlli 00404 e 00409.

Speriamo che prima o poi qualcuno chiarisca ufficialmente.

Ho riletto le specifiche v.1.7.1
E’ vero, si contraddicono.
Prima si dimenticano del caso delle fatture cartacee con IVA da San Marino e poi sbagliano le specifiche
… e li pagano pure profumatamente !
Stiamo a vedere di sicuro correggeranno il tiro
:slight_smile:

1 Mi Piace

Chiaro tutto,
ma dicevo, se tu utilizzi ( o meno ) un xsd validator,
cosi’ facendo, prendendoti il file xsd con le nuove specifiche, puoi controllare se il tuo documento generato, sia o meno conforme ai nuovi controlli di cui parli.
Io non ho mai utilizzato un xsd validator (richiamabile da line a di comando, quindi non da web [ce ne sono diversi])

La validazione della fattura contro lo schema è parte integrante della soluzione software che ho sviluppato per la mia azienda, ma come ti dicevo la differenza rispetto allo schema precedente è minima, hanno solo aggiunto un enumerato per il TD28.

1 Mi Piace

Chiarissimo,
io ti chiedevo proprio che software hai utilizzato per effettuare la validazione,
io ad oggi, i controlli li ho fatti tutti “dentro” il mio programma,
e quindi,
avrei intenzione di utilizzare la validazione, cosi’ da poter integrare TUTTI i controlli che Ade effettua.
In rete ho trovato diverse soluzioni on-line, ma mai nessuna che possa lavorare “standalone” richiamabile da linea di comando

Trovi qualcosa qui:

Però, come ti dicevo, attenzione: la verifica di conformità allo schema copre solo una minima parte dei controlli che fa l’AdE. Se un file XML non rispetta lo schema, viene scartato con (se non erro) l’errore 00200 o 00201. Tutti gli altri codici di errore di scarto delle fatture sono dovuti a controlli extra schema.

1 Mi Piace

Grazie, ci do una occhiata…

Questo però non lo puoi fare con la sola validazione xsd! La validazione di un file fattura elettronica si compone di due parti:

  • La validazione dello schema XML, che verifica che la struttura del file XML corrisponda all’xsd.
  • Le altre verifiche sul contenuto che sono specificate da AdE nell’elenco dei controlli (inclusi i codici di errore 00404 e 00409), che non possono essere espressi in termini di schema XML.
    La non conformità all’xsd è solo uno di questi errori (00200).

Per quanto riguarda la verifica dello schema, è una funzione abbastanza standard delle librerie che gestiscono l’XML (è inclusa in .NET, per dire). Un po’ più complicato se vuoi gestire anche la verifica della firma.
Per quanto riguarda i controlli extra xsd, non credo ci siano in giro librerie o tool standalone.

1 Mi Piace

direi, che questo mi basta.
In sintesi, è il controllo che molti siti web (online ) effettuano.
è chiaro che, su il file xml, contiene una partita iva (formalmente valida, ovvero che rispecchia tutti i controlli formali della stessa), e poi la ADE, verifica che quella partita iva non esiste, o meglio, è cessata qualche anno fa, … ok, questo tipo di controllo solo ADE potrà effettuarlo…

Sì, ma ci sono un sacco di controlli (la maggior parte di quelli dell’elenco) che si potrebbero fare anche senza l’aiuto dell’AdE.
Prendi per esempio i controlli 00429 e 00430, che verificano che venga specificata la natura nel caso di aliquota IVA pari a 0 e che non venga specificata la natura in caso aliquota IVA diversa da 0. E’ una regola che non c’è nel file xsd, ma che sarebbe semplice da implementare nel proprio programma.
Il guaio è che senza una libreria o un programma già pronti, le regole bisogna implementarsele una per una.