Fatturazione Elettronica - Nomenclatura file da trasmettere

Salve a tutti leggevo quello che avevate scrittto e mi chiedevo se secondo voi per la numerazione in futuro si può pensare di impiegare caratteri di codifica utf8 in senso più ampio (esempio : codici latin extended A , ITXXXXXXXXXXX_Ā0000).

Lo dico, 5 caratteri è veramente un po’ poco.

Usando anno e numero 18001, il limite è 1000 fatture (con l’anno solo nelle ultime cifre che già mi dà fastidio).
Usando solo i numeri, 00001 il limite è 10000 fatture (totali).
Codificando tutto su base 36 (numeri e lettere minuscole), il limite si alza di parecchio (certo a scapito della leggibilità), e si arriva a un decente 60 milioni (totali)…

…però vi voglio far notare che codificando su base 36 una stringa contenente l’anno, es 20180001= 3c59vl SI SFORANO I 5 CARATTERI, E DUNQUE IL LIMITE VA ALLE 10000 FATTURE ANNUE…

Insomma, 5 è poco.
Se avessero messo 10 caratteri, avremmo potuto usare un chiarissimo annonumerofattura es 2018000001 con limite a un milione di fatture all’anno… oppure infilarci dentro anche i sezionali, es B2018000001 con limite da centomila fatture all’anno.

In base alle specifiche attuali no. Gli unici caratteri ammessi sono [a-z], [A-Z], [0-9]. È possibile che in futuro modifichino le specifiche per venire incontro alle aziende che fanno centinaia di milioni di fatture all’anno, ma vedo più probabile un allungamento del progressivo univoco, anche perché nel nome del file bisogna stare molto attenti a evitare caratteri che potrebbero non essere validi su qualche file system.

Scusate quindi per i nomi dei file si possono usare le partite iva dei clienti mentre nel campo codice IdTrasmittente del file xml devo usare il codice del canale?

Buongiorno,
Volendo trasmettere allo Sdi un file compresso contenente un lotto di file XML, non mi é chiaro l’esempio riportato nella documentazione:

Nel caso di file archivio deve essere rispettata la stessa nomenclatura usata per il file FatturaPA utilizzando l’estensione .zip.
Esempio: ITAAABBB99T99X999W_00001.zip che al suo interno contiene, a titolo di esempio:
• ITAAABBB99T99X999W_00001.xml
• ITAAABBB99T99X999W_00002.xml
• ITAAABBB99T99X999W_00003.xml.p7m

Mentre mi é chiara la nomenclatura dello zip non capisco cosa siano _00001, _00002 e _00003 nella nomenclatura dei file XML visto che l’invio degli stessi é unico ed il progressivo é quello indicato nello zip cioè _00001.

Grazie

Ciao a tutti, sono nuovo di questo forum!

Ho scoperto questa vostra discussione non appena ho cominciato a dubitare che la numerazione ripartisse da zero ogni anno.

Ma penso di aver trovato una soluzione, sono stato ispirato dai file che ricevo personalmente per l’acquisto di carburante.

Guardate questi nomi file, sono fatture di acquisto di carburante che ricevo mensilmente:
IT0526289001418214_04KAG.xml
IT0526289001418247_0E6V9.xml
IT0526289001418276_0J09Y.xml

Sfruttano i cinque caratteri dopo la Partita IVA, che nel loro caso non è del fornitore ma dell’intermediario.

Loro non usano il numero della fattura, ma la mia soluzione si, e ho anche lo spazio per gestire eventuali reinvii.

Esempio:
IT05262890014018FA_00001.xml
IT05262890014118FA_00001.xml reinvio

  • due posizioni per IT
  • undici posizioni per la Partita IVA
  • una posizione con uno zero fisso che incremento di uno in caso di reinvio dello stesso documento, sono possibili ben nove reinvii usando base 10
  • due posizioni per l’anno 18
  • due posizioni per il sezionale FA
  • una posizione per l’underscore
  • cinque posizioni pulite per numerare le fatture ripartendo da zero ogni anno 00001

In questo modo possiamo gestire fatture fino a 99.999 in base 10 (non so quante in base 26+10) all’anno.

La parte da dopo IT all’underscore può essere lunga 11 o 16, non lunghezze intermedie.
Può essere un libero mix di lettere e numeri, no underscore o altri simboli.
Quindi se il vostro sezionale è di una sola lettera, dovete scegliere un’altra lettera o cifra come riempitivo.

Ho testato questa nomenclatura nei tre modi seguenti:

Strumenti / Controllare la FatturaPA (non sono necessarie credenziali)
https://sdi.fatturapa.gov.it/SdI2FatturaPAWeb/AccediAlServizioAction.do?pagina=controlla_fattura

Simulazione / Inviare e ricevere la fattura elettronica (sono necessarie credenziali)
https://sdi.fatturapa.gov.it/SdI2FatturaPAWeb/sicurezza/AccediAlServizioAction.do?pagina=invia_ricevi_fattura

Controlla fattura (sono necessarie credenziali)
https://ivaservizi.agenziaentrate.gov.it/ser/fatturewizard/#/controllo
Previo login a questa pagina:
https://ivaservizi.agenziaentrate.gov.it/portale/

Per favore controllatela anche in altri ambienti di test, io ho accesso solo a questi per ora.

Che ne pensate?

5 Mi Piace

Ciao Gianni,
quindi tu sfrutti i caratteri rimanenti da 11 a 16 per “allungare” il progressivo.
un dubbio! così facendo modifichi l’Identificativo univoco del Trasmittente, quindi la fattura dovrebbe essere scartata. per certo posso dirti che lo strumento “controllare la fatturaPA” non verifica l’esattezza della nomenclatura del file xml. alla pagina che tu indichi leggo " I soli controlli che non vengono eseguiti da questa applicazione, rispetto a quelli che effettua il Sistema di Interscambio, riguardano l’unicità del nome del file FatturaPA, l’unicità dell’identificativo progressivo della fattura e l’esistenza o meno del CodiceDestinatario".

Nel mio caso il problema è reale in quanto faccio circa 10000 fatture l’anno, quindi facendo 2 conti veloci potrei esaurire i progressivi univoci in circa 10 anni utilizzando solo numeri, 10 anni numeri e lettere(solo maiuscole) e 20 anni utilizzando numeri e lettere sia maiuscole che minuscole. il tutto senza considerare i rinvii. potrei procedere in questo modo ma sposterei solo il problema di qualche anno.

Tu hai avuto altri riscontri con la tua soluzione?

Nessuno ha fatto test ulteriori.
La cosa certa però è che le fatture di carburante che ricevo sono impostate così da mesi.

In “Controlla la FatturaPA” se carichi un file con la parte fra IT e l’underscore di lunghezza diversa da 11 o 16 oppure se vengono utilizzati caratteri diversi da sole lettere e numeri, da errore.

Ciao Gianni,
il tuo metodo è interessante e sto facendo dei test.
Se tutto va bene, pubblicherò un articolo su Medium menzionando il tuo metodo ed un altro che ritengo possa ulteriormente migliorare la situazione.
Se me lo permetti vorrei menzionare il tuo nome e il tuo metodo nell’articolo.

Fate attenzione che chi già emette fatture non significa che sia nel giusto.

la nomenclatura del file è dichiarata per o la partita iva (11 caratteri) o il codice fiscale(16 caratteri)
la partita iva o il codice fiscale possono essere di chi trasmette o di chi emette.

il fatto che attualmente l’unica verifica fatta sia quella che la prima parte del nome del file abbia la lunghezza minima di 13 caratteri (IT + 11 caratteri)
non significa che in futuro non eseguano un controllo se non sia la partita iva di un’azienda inesistente oppure che sblocchino tutto.
NB. a novembre funzionava anche se il nome file era ITciaoCiaoCaraAde_1.xml

per quanto riguarda quello che scrivevo prima sul fatto che non è detto che chi invia le fatture è nel giusto:
il campo RiferimentoNormativo nel riepilogo iva è opzionale ma sarebbe obbligatorio nel caso in cui il campo Natura è presente.

Obbligatorietà: SI, ma solo se risulta valorizzato il campo Natura
(2.2.2.2) e quindi nei casi di operazioni che non rientrano tra quelle
imponibili o nei casi di inversione contabile

Attualmente però SDI non blocca se il campo è vuoto o non presente…
Sto usando il servizio di fatturazione online di Aruba e quel campo non viene mai compilato nel XML indipendentemente dal tipo di natura.
A mio avviso quello è un campo importante tanto quanto la descrizione di un bene e l’omissione la ritengo un errore, poi ovviamente si può sempre ripiegare sul possibile allegato o sulla fattura consegnata a mano o via mail…

Ciao Mattia, fai pure.

Ciao Daniele,
si, ancora oggi si può usare un nome di fantasia basta che rispetti lunghezza e caratteri consentiti.
Onestamente mi sembrerebbe davvero sciocco da parte di SDI fare questo controllo sul nome del file quando l’unica cosa davvero importante è che non sia duplicato nel proprio flusso di file ed inoltre i dati davvero significativi sono contenuti nel file stesso.

Grazie Gianni,
ho riassunto tutto in questo link, che espone come dicevo un ulteriore metodo che potrebbe risolvere i problemi di limite indicati da qualcuno, usando un nome basato su timestamp.

4 Mi Piace

Questo non è più vero. Una volta nel nome file andava messa la partita IVA del trasmittente, ma poi hanno tolto questo vincolo. Nelle specifice tecniche versione 1.3, c’è scritto:

l’identificativo univoco, è rappresentato dall’identificativo fiscale (codice fiscale nel caso di soggetto residente in Italia, identificativo proprio del paese di appartenenza nel caso di soggetto residente all’estero) di un soggetto persona fisica o persona giuridica diversa da persona fisica; la lunghezza di questo identificativo è di:
o 11 caratteri (minimo) e 16 caratteri (massimo) nel caso di codice paese IT;
o 2 caratteri (minimo) e 28 caratteri (massimo) altrimenti;
l’identificativo usato per il nome del file non è soggetto a controlli di validità, esistenza o coerenza con i dati presenti in fattura.

Quello che non so è se il nome del file deve essere univoco a livello di tutto il SdI. Se la gente comincia a usare codici a vanvera nei nomi dei file c’è il concreto rischio di creare un nome file uguale a qualcun altro che non c’entra niente.

Comunque secondo me saranno costretti ad allungare la parte del progressivo univoco perché grosse aziende che fatturano a privati (compagnie di telecomunicazioni, energia, ecc.) con milioni di clienti, finiranno per esaurire i progressivi univoci in pochissimo tempo (a meno che anche loro non usino codici a vanvera al posto del codice fiscale/partita IVA).

1 Mi Piace

Veramente le combinazioni possibili con 5 caratteri [A-Za-z0-9] sono 916.132.832, quasi un miliardo!

1 Mi Piace

In effetti molti trasmittenti stanno usando sia lettere maiuscole che minuscole nei nomi dei file. Questo però potrebbe creare problemi per chi salva le fatture su sistemi case-insensitive (tipo Windows o Mac), anche se le probabilità di collisione sono basse.
Facendo così, le aziende più grosse avranno un paio di anni di autonomia. Per esempio Telecom Italia ha circa 10 milioni di clienti sul fisso, quindi presumibilmente emette almeno 120 milioni di fatture all’anno. Con 916 milioni di possibili progressivi sono a posto per 7 anni.

Con case insensitive sono comunque 60.466.176 combinazioni, oltre 60 milioni di fatture.

Se il file system è case insensitive si può superare il problema con SDICoop, perché il nome del file inviato allo SdI non deve necessariamente coincidere con il nome del file salvato sul disco: il nome del file trasmesso è un attributo della chiamata SOAP, compilato dal software che effettua l’invio; basta avere nel proprio database una tabella con due colonne che associa il nome inviato a SdI con quello su disco.

Da ricordare che esiste la possibilità di inviare su tutti i canali un lotto di fatture (un unico file, quindi un unico nome, contiene più fatture), utile per chi ne emette tante come un gestore telefonico o comunque in batch e soprattutto più efficiente da gestire per il SdI rispetto ai file singoli. Secondo me la scelta di limitare a 5 caratteri è ragionata e volta a incoraggiare un particolare modo d’uso efficiente del sistema da parte dei grossi contribuenti, in quanto necessario per garantire il funzionamento.

Per i rinvii si può utilizzare lo stesso nome file.
I calcoli non sono corretti, con 10000 fatture l’anno, anche usando solo numeri e lettere case insensitive sono 6.000 anni! :sweat_smile:

Veramente il lotto di fatture deve avere lo stesso cedente/prestatore e cessionario/committente per tutte le fatture (la sezione FatturaElettronicaHeader è comune a tutte), quindi è utile solo se si emettono più fatture verso lo stesso cliente.

2 Mi Piace

Si hai ragione forse calza meglio l’esempio del distributore di carburante, o chi ha accordi di fatturazione mensili.