Fatturazione Elettronica - Nomenclatura file da trasmettere

Sì su questo sono d’accordo con te, ho già fatto anche io questi calcoli ed ho già visto di rientrarci. Volevo solo evitare di avere una nomenclatura di questo tipo IT99999999999_AAAAB. Preferirei appunto avere IT9999999999919_12345. Appunto mi chiedevo come avevate gestito voi la problematica… tu hai preferito il primo approccio?

puoi usare una nomenclatura sfruttando 16 caratteri al posto di 11 per l’identificativo iva

IT {partita iva 11 car} A { anno} _ { progressivo }

IT 99999999999 A2019 _ 12345 . xml/p7m

oppure lo puoi gestire in base ai clienti { AA -> ZZ } { AA [anno] } { N progressivo di invio}
IT 99999999999 AB191 _ 12345 . xml/p7m

quindi usi 16 caratteri al posto di 11, viene interpretato come campo alfanumerico ma non essendoci un controllo sulla sua eventuale validità , puoi ricomporlo a tuo piacere.

per mio conto preferisco qualcosa di questo genere.
{ ID PAESE }{ identificativo fiscale 11 numeri } _ { progressivo interno documento convertito in 0-9a-zA-Z }

e in caso di scarto
{ ID PAESE }{ identificativo fiscale 11 numeri } { T + progressivo invio, filler 0} _ { progressivo interno documento convertito in 0-9a-zA-Z }

in questo modo l’identificativo iva riporta sempre al cliente, mentre il progressivo del file riporta al “ID” univoco del documento. Ovviamente questo vale per me che tengo fatture e note di variazione una sola tabella.
Anche tenendo i documenti su diverse tabelle, si può risolvere la cosa aggiungendo un progressivo.

allo stato attuale probabilmente è accettato :
ITCL0154FT00015A19 _ xxxxx.xml
IT CL (cliente) { codice cliente } { codice documento FT, NC, ND }{ numero documento }A { anno }

Capito, grazie per il tuo feedback.
La mia idea era quella di lasciare sempre uguale il nome del file sia in caso di esito positivo sia in caso di esigo negativo: in poche parole, creo il file e qualora venisse scartato perdo quel numero e ri-invio il documento con un nuovo numero.
Prenderò in considerazione il “trucco” di far sembrare un codice fiscale, ma confesso che non mi fa impazzire l’idea :slight_smile:

nemmeno a me faceva impazzire all’inizio ma lasciando in mano la cosa all’utente finale, dopo aver tolto tutte le possibili casistiche di errore, avevo ancora scarti.
Ho scoperto che non riesco a bloccare/convertire eventuali copia e incolla di caratteri speciali presi da documenti word…
Inoltre, inizialmente l’identificativo iva doveva essere del trasmittente… cosa che per fortuna è cambiata.
Quindi la soluzione più opportuna che ho trovato per non dover “cercare il progressivo”, farlo slittare in caso di scarto, è stato fare quello che fa l’agenzia delle entrate nelle notifiche.
ovvero riportare il numero di tentativi di invio.
In questo modo lo scarto non mi fa perdere il progressivo (nonostante ce ne siano da sprecare)

1 Mi Piace

io in questo momento me ne frego degli scarti, quando ho uno scarto perdo il numero.

Non sai quanto ti capisco … :frowning:

1 Mi Piace

È un poco off-topic ma quel che mi preoccupa veramente è che la mancanza di una standardizzazione per la nomenclatura del file impedisce de facto la migrazione tra piattaforme diverse. Secondo me qualche authority presto o tardi solleverà la questione.

Anche noi! Abbiamo dovuto mettere i controlli su tutti i campi in fase di salvataggio con un messaggio del tipo: “carattere ‘€’ non valido in posizione 10”.
Una cosa che aiuta è la conversione automatica delle virgolette e degli apostrofi non ASCII, che è la casistica più frequente, dovuta appunto alla correzione automatica in Word.

Non è una cosa così difficile da fare. Noi nel database teniamo per ogni fattura due campi: uno intero, con il progressivo numerico, e uno stringa, con il progressivo convertito in base 36 (perché evitiamo di usare le minuscole), che viene usato per creare il nome del file.

1 Mi Piace

Cosa intendi per “migrazione tra piattaforme diverse” ?
Se parliamo di database, il campo deve comunque rispettare i limiti del formato dell’agenzia delle entrate. quindi alfanumerico fino a 40 caratteri (mi sembra)
Inoltre i dati fattura puoi migrarli semplicemente con un esportazione dal sistema di interscambio.

Al fine della conservazione, una volta messo in conservazione non è che puoi estrarre chissà cosa, sentivo alcune aziende che in caso generano dei DVD.

Al fine del salvataggio su PC del file il problema è per quei sistemi windows che non supportano il key sensitive ma quello è un problema sugli ultimi 5 caratteri.

Al fine di generare nuove fattura, dopo la migrazione, maggiore è la personalizzazione da parte di un’azienda meglio è in realtà
Il problema è se tutti seguono lo standard.

mettiamo caso dello standard
IT01234597890_aS.xml
aS può essere generato dal progressivo del documento, dal progressivo di invio, dal progressivo di invio condiviso da più clienti, da numero di fattura + riferimento cliente

In base al tipo di metodo per generare il progressivo del file, in caso di migrazione, potresti trovare dei conflitti in quanto la parte dell’identificativo iva è fissa

ma se il nome del file non è standard
IT01234597890_aS.xml
nel tuo gestionale può diventare
IT01234597890BBAAS_aS.xml
quindi a parità di progressivo, il prefisso ( identificativo iva/codice fiscale) essendo diverso, supera comunque i controlli del caso e può essere inoltrato.

probabilmente l’identificativo iva migliore sarebbe un codice alfanumerico a 8 caratteri per identificare l’intermediario e uno per l’azienda rilasciato direttamente dall’agenzia delle entrate.
IT XU78SD9 (intermediario) DFRTOEL4 (mittente) _ XXXXXX (progressivo)

in questo modo non ci sarebbero rischi di conflitto in quanto ogni file avrebbe nel nome la versione in base36 della “partita iva intermediario” + “partita iva mittente”

1 Mi Piace

sono d’accordo che non è così difficile da fare, ci mancherebbe :slight_smile:
alla fine basta fare una conversione dal progressivo numerico (base10) a base36
Volevo solo collezionare un po’ di vostre esperienze per capire come gestire al meglio il problema :slight_smile:

In ogni caso, grazie per tutti i consigli!

1 Mi Piace

Salve,
riprendo questo thread perché stiamo ricevendo flussi di fatture passive con una nomenclatura file SDI già arrivata, per altre fatture, negli anni trascorsi.
Qualcuno conosce dopo quanto tempo è ammesso da SDI il transito degli stessi nomi file , è una info che non riesco a trovare nelle specifiche tecniche.

Grazie 1000

1 Mi Piace

Che date hanno le fatture omonime? Il soggetto trasmittente è lo stesso?

Ciao, e scusa il ritardo…
Sì, il trasmittente è lo stesso.
Le fatture sono diverse nel numero,e nella data, nel primo caso è del 2015, nel secondo del 2020, ma con stesso nome file di arrivo.

Grazie

Alessandro ho letto ora di non averti mai risposto. Secondo me, con l’avvento della fattura elettronica obbligatoria del 1 gennaio 2019 hanno resettato il discorso dell’univocità del nome.
Ne approfitto per augurare a tutti buone feste, anche a quelli che usano maiuscole e minuscole nel nome del file, e che non si rendono conto che quando poi un commercialista deve fare un export e import massivo, usando i nomi originali, e passando da uno zip, quando scompatta lo zip poi si trova in errore perché, coi sistemi Windows, l’omonimia in scompattazione non è consentita. Buone feste!

Buonasera, nelle specifiche tecniche SDI vers. 1.8.1 (01/10/2020) c’è scritto che nel nome del file deve essere indicato l’identificativo univoco del trasmittente. E’ ancora valida questa regola? Se no, c’è scritto da qualche parte?

C’è incongruenza tra le specifiche tecniche del SdI e le specifiche tecniche della fattura elettronica (Allegato A).
Nelle prime c’è in effetti scritto “identificativo univoco del soggetto trasmittente” che deve corrispondere al codice fiscale del trasmittente, mentre nelle specifiche della fattura elettronica è indicato un generico “identificativo univoco”, così descritto:

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:

  • 11 caratteri (minimo) e 16 caratteri (massimo) nel caso di codice paese IT;
  • 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.

Nella pratica il SdI applica questa seconda specifica, nel senso che l’identificativo univoco può essere qualsiasi cosa che “assomigli” a un codice fiscale e non c’è bisogno che corrisponda al trasmittente. Questa modifica è stata fatta perché alcuni grossi provider di fatturazione elettronica avrebbero presto esaurito i progressivi di 5 caratteri.
Noi per esempio (come trasmittenti), non mettiamo il nostro codice fiscale, ma quello del cedente/prestatore.

Perché ci sia questa discrepanza tra le specifiche, e perché non l’abbiano ancora corretta, non lo so.

Vladan, una curiosità.
Se un vostro cliente cambia e va da un altro, o se un cliente nuovo arriva da voi da un altro fornitore che adotta lo stesso tipo di nomenclatura, che cosa succede in caso dì omonimia del file trasmesso rispetto a uno creato e trasmesso dall’altro fornitore in precedenza?
Vi siete mai posto questo dubbio e, nel caso, avete una risposta?

Il dubbio ce lo siamo posto, ma non abbiamo una risposta. Non siamo mai riusciti a capire se la verifica di univocità del nome del file viene fatta globalmente o a livello di trasmittente. Bisognerebbe fare degli esperimenti, ma ci vogliono due trasmittenti disposti a farlo e non so nemmeno se un test in ambiente di collaudo darebbe gli stessi risultati.
Noi facciamo partire i nostri progressivi da I0000 invece che 00000 proprio per ridurre la probabilità che si presenti questo problema.
Nel caso un cliente passi a noi, abbiamo la possibilità di modificare manualmente il progressivo da cui partire in modo da evitare sovrapposizioni con eventuali fatture inviate in precedenza.
Se un nostro cliente passa ad un altro fornitore che usa lo stesso schema e non è in grado di modificare il progressivo, potrebbe essere un problema.

Da una rapida analisi, ho visto che alcuni grossi fornitori di fatturazione elettronica mettono comunque il proprio codice fiscale (per esempio Aruba), mentre altri mettono quello del cedente/prestatore (per esempio Zucchetti).

@vbato il tuo ragionamento è quello dì chiunque altro, ma c’è un vuoto: non esiste un algoritmo che garantisca la sequenza. Considerando la possibilità di mescolare numeri e lettere fino a 5 caratteri, non esiste un “partiamo da qui”.
Sarebbe bello avere una risposta ufficiale di AdE/SdI sul tema, anche per fare in modo che la migrazione di un cliente sia più possibile indolore

Ormai per chi ha iniziato in questo modo, c’è poco da fare.
Per chi sta appena partendo come trasmittente, e non prevede di dover trasmettere milioni di fatture, la cosa migliore da fare è usare la propria partita IVA nel nome del file. In questo modo è praticamente certo che nessun altro genererà nomi di file che vanno in conflitto.
L’unico vantaggio dell’usare la partita IVA del cliente è che consente di “decentralizzare” la generazione dei nomi dei file.