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