bastava infatti aggiungere uno o due caratteri al progressivo per evitare ogni problema di esaurimento (4*10^12 per singolo codice trasmittente direi che è una bella cifra visto che anche facendo 60milioni di fatture al mese ci vogliono 5470 anni per esaurire il progressivo), vincolando tuttavia l’identificativo al cf del soggetto associato al canale…
Come si è detto più volte se uno vuole, allo stato attuale, può fare denial of services su identificativi altrui…
Si, giusta precisazione, grazie.
Vero, però rischi la collisione con altri che potrebbero avere usato lo stesso codice da te inventato. La specifica iniziale mi sembra quella più sensata, in quanto il proprio codice fiscale è univoco. Sul fatto del denial of services il problema esiste, perché potrei inviare nominando il file con il codice fiscale di un altro soggetto. Anche se l’identificativo usato per il nome del file non è soggetto a controlli di validità, esistenza o coerenza con i dati presenti in fattura, dovrebbe essere controllato che coincida con l’identificativo fiscale del titolare del canale accreditato utilizzato per l’invio e il problema del DDOS si risolverebbe.
Non avevo visto l’allegato A. Così hanno creato un problema che prima non c’era.
Infatti prima doveva esserci il codice fiscale del trasmittente e il problema non c’era.
Può darsi che abbiano fatto la modifica per ovviare ad un altro problema che si andava a creare, ovvero quello dell’esaurimento dei progressivi. Per i piccoli intermediari non è un problema, ma quelli grossi (tipo Aruba o InfoCert) si sarebbero ritrovati ad esaurire i progressivi in un anno o due.
Però può darsi che il motivo sia un altro, perché la soluzione di allungare il progressivo sarebbe stata molto più semplice ed efficace, con l’unico inconveniente di qualche problema di retrocompatibilità perché si aumenta la lunghezza massima del nome del file (ma essendo che la lunghezza era tarata su codici fiscali da 30 caratteri, non credo che nella pratica avrebbe creato problemi a nessuno).
Mettere nelle specifiche max 7 caratteri per il progressivo a mio giudizio non avrebbe cambiato le cose proprio a nessuno, del resto se volessero potrebbero sempre farlo.
L’id trasmittente presente nel file, se mi avvalgo di un intermediario, è il CF/PIVA dell’intermediario?
Piva del trasmittente che può esser diverso da chi emette fattura.
in realtà quella dicitura dice che il nome del file DEVE essere
- la partita iva del cedente/trasmittente (11 caratteri)
- il codice fiscale del cedente/trasmittente (16 caratteri)
poi dicono che non eseguono controlli per verificare che la partita iva o C.F sia valido (validità) o che sia presente all’interno del documento XML(esistenza/coerenza).
Infatti per passare non è che deve “assomigliare” ad un codice fiscale ma deve semplicemente lungo 11 o 16 caratteri
da qui i programmatori hanno detto: “ahhh non ci sono controlli? e allora anziché mettere quello che dicono, ci metto quello che voglio.”
e ci siamo ritrovati con nomi file di ogni genere.
se vuoi puoi inviare anche
ITVLADANBATO201901_1.XML
o
ITFATTUREDIVBATO_1.xml
e viene accettato.
l’ultimo test che avevo fatto 2 mesi era era
ITciaociaociao_1.xml
Veramente il cedente o trasmittente non sono menzionati da nessuna parte del testo. Dice semplicemente un soggetto. Potrebbe essere anche mia nonna 
Scherzi a parte, anche evitando forzature come quelle da te illustrate (che so che molti usano), non è necessario usare il codice fiscale del trasmittente. Si può tranquillamente mettere quello del cedente, tenendo però presente che la cosa potrebbe causare nomi duplicati in futuro (se le fatture vengono emesse da qualcuno che ignora i progressivi usati in precedenza).
Prima era richiesto di usare quello del trasmittente. Con le specifiche più recenti, consentendo di usare qualsiasi cosa, hanno aperto alla possibilità di DDoS sui nomi dei file. Infatti inviando molte fatture, anche da scartare, con l’identificativo univoco usato da altri, si possono esaurire i progressivi e bloccare il loro canale.
Ma quindi come gestite la nomenclatura del file? Io ho qualche cliente che emette ~50.000 fatture/anno e secondo le specifiche tecniche https://www.fatturapa.gov.it/export/fatturazione/sdi/Specifiche_tecniche_SdI_v1.6.pdf (pag. 9) ho a disposizione solo 5 caratteri
IT99999999999_00002.xml
Codice paese + Identificativo Fiscale _ XXXXX.xml
È vero, come suggerisce @simevo, che ci sono (26+10)^5-1 combinazioni possibili… però doversi “incasinare” per un progressivo limitato a 5 caratteri mi sembra incredibile. La soluzione migliore sarebbe quella di usare un progressivo numerico, anche perché 99999 per la stragrande maggioranza delle aziende è sufficiente. Il problema nasce solo perché questo numeratore non viene azzerato annualmente.
In ogni caso, voi come gestite la problematica?
Grazie
Le combinazioni possibili sono molte di più: hai 62^5+62^4+62^3+62^2+61= 931151401. Emettendone 50000 all’anno il tuo cliente esaurirebbe i progressivi in 18623 anni.
Anche volendosi limitare alle sole lettere quindi 26^5-1=11881375 il tuo cliente esaurirebbe i progressivi in 237 anni.
Si hanno poi a disposizione ulteriori 5 numeri per “giocare” con il nome del file nel caso abbia la forma di una partita iva perchè SDI accetta IT+16numeri. Quindi, in linea di principio, potresti azzerare il progressivo ogni anno costruendo il nomefile come IT+PIVA+2019_progr.xml
1 Mi Piace
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 
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 … 
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.