Personalmente uso ftp per inviare dato che faccio invii massivi…
Ricevo le fatture dai clienti (stato=0)
Le fatture rimangono in attesa per circa 30minuti (in questo periodo il cliente può ancora ripensarci e cancellare/modificare), dopo questo tempo passano a stato=1 (bloccate e pronte per essere impacchettate per SDI), subito dopo essere state messe in stato 1 vengono impacchettate e passano in stato=2 (uso due stati per evitare eventuali cancellazioni concorrenti durante l’impacchettamento)
appena SDI preleva il file passano a stato=3
appena SDI mi manda il file EO passano in stato=4
quando ottengo una ricevuta passano negli stati corrispondenti
Nel mio caso non c’è possibilità che un cliente cancelli una fattura che sia già stata messa a disposizione di SDI… inoltre dato che ogni passaggio di stato ha il suo timestamp il mio cliente sa dove viene perso il tempo…
So che Zucchetti aveva molti problemi anche sugli invi.
Comunque anche secondo me devi emettere Nota di accredito e rifare la fattura con una nuova numerazione.
Non so appunto se questo (a fattura emessa ed accettata, è necessaria la sua cancellazione e la riemissione di una nuova con una nuova numerazione per la medesima transazione) è un requisito di AAEE/SDI o dell’applicativo. Comunque, per evitare questi errori, si potrebbe presentare una pagina di riepilogo ed una richiesta di conferma a procedere, prima dell’effettivo invio.
Come ho già scritto in fondo, si potrebbe migliorare la situazione con una pagina di riepilogo e la successiva richiesta di conferma all’invio, prima di procedere.
Salve, ho inserito nella fattura elettronica il codice fiscale generato automaticamente (in base a cognome, nome e data e luogo di nascita del cliente), ma la fattura è stata scartata perchè “codice fiscale non valido”. Verificando sul tesserino del codice fiscale del cliente ed in Anagrafe Tributaria, effettivamente l’ultimo carattere è diverso. Probabilmente si tratta di un caso di “omocodia”, in cui sono nati nella stessa data e luogo due soggetti con cognome e nome simili (probabilmente due gemelli) ed in questo caso, per evitare la generazione di due codici fiscali identici, ad uno dei due viene attribuito un codice fiscale con l’ultimo carattere modificato.
Il problema è che tentando il reinvio della fattura elettronica con il codice fiscale corretto, l’invio viene impedito perchè il codice fiscale risulta formalmente invalido.
Come risolvo?
La generazione dei codici fiscali soggetti ad omocodia non avviene come hai scritto tu.
Non varia solo l’ultimo carattere. C’è un algoritmo che ne fa variare almeno anche un altro secondo una regola molto precisa per quanto complessa.
Purtroppo, per quanto detto, non esiste e non può esistere nessun generatore automatico “standalone” che ti garantisca che il codice fiscale sia quello corretto di una persona dati i suoi dati anagrafici. Sarà giusto nel 99,99% e più dei casi, ma non nel 100%. Perché non potrà risolvere e neanche individuare le omocodie.
Cosa fare? Beh, la sola soluzione è farsi dare il codice fiscale direttamente dal cliente. Ma questa è una regola aurea da applicare sempre e comunque.
Per sintetizzare e risolvere il tuo caso: riguarda bene. Non è solo l’ultimo carattere ad essere diverso rispetto allo standard, per quanto detto.
Grazie per la risposta. Ho nuovamente verificato e confermo che il c.f. realmente corretto (cioè quello attribuito dall’Agenzia delle Entrate, riportato sul tesserino e in anagrafe tributaria) ed il c.f. solo formalmente corretto (cioè quello generato con gli applicativi comunemente disponibili on line) sono diversi solo per l’ultimo carattere. Non so quale sia il motivo della divergenza e l’omocodia era solo una ipotesi.
Il problema è un altro. Come faccio a inviare la fattura elettronica? Se inserisco il c.f. realmente corretto, il software che uso (Fatture in Cloud) non mi consente di inviarla perchè rileva che trattasi di codice invalido, se inserisco il c.f. solo formalmente corretto, riesco a inviarla, ma viene poi (giustamente) scartata perchè quel codice fiscale risulta inesistente.
Spero di aver spiegato meglio qual è il problema.
Come ti ha già detto da @Morris,
non può essere “solo l’ultimo carattere”,
l’ultimo carattere essendo il “check” non puo’ che essere quello e solo quello (in base ai precedenti 15).
Apri una segnalazione di assistenza a Fatture in Cloud: arrivati fin qui, siamo di fronte a una limitazione specifica del software e non a una tematica di dominio pubblico. Fermo restando che secondo me in mezzo a quei 16 caratteri c’è qualcosa di disallineato tra ciò che dovrebbe essere, ciò che è scritto, e ciò che è letto.
ok perfetto, grazie!
Alla fine che problema c’era???
Avevi ragione tu, se si fosse trattato di un caso di omocodia non sarebbe stato diverso solo il carattere di controllo (ossia l’ultimo).
Infatti, i c.f. generati dall’Agenzia delle Entrate in casi di omocodia modificato uno degli altri caratteri e, di conseguenza, anche il carattere di controllo, in modo da risultare formalmente corretti, come quelli generati normalmente.
Nel mio caso, molto banalmente, era solo sbagliato il c.f. che mi avevano dato!
Grazie dell’aiuto 
salve,
vi scrivo perché vedo l’argomento
lavoro in un negozio e abbiamo un caso di omocodia perché la penultima lettera invece di esserci un numero c’è una lettera e poi il cliente ce lo ha confermato dunque il mio problema e che la fattura elettronica ci torna sempre indietro e il gestore del nostro programma ci dice di verificare il c.f. a qualcuno é capitato? sapete come fare? grazie a tuti
se il codice fiscale è giusto, a te poco importa se esiste o meno una omocodia.
Il Codice Fiscale viene generato dalla Agenzia, e quello deve essere …