Mi dispiace, questo può essere ovvio, ma non ero sicuro al 100,00%.
Il campo CodiceFiscale sotto CessionarioCommittente è sempre obbligatorio per i clienti privati italiani? Oppure c’è la possibilità di permettere ai clienti italiani di non inserirlo nel carrello o nel proprio account?
Preferiamo non trasportare più informazioni di quante ne abbiamo, e più informazioni le persone devono fornire, più è probabile che abbandonino il check-out.
Grazie!
Per
Obbligatorio.
Il vostro è un problema comune a molti…
Se hai tempo per un’altra domanda.
Dobbiamo convalidare anche il codice fiscale, come una Partita IVA? Sto trovando molte librerie per calcolare il codice fiscale da nome + data di nascita/città/sesso, ma mi sembra molto raccogliere tutte queste informazioni personali per un acquisto casuale. Non ho mai visto un negozio online italiano che raccolga tutto questo, anche se tutti chiedono il codice fiscale di un privato.
Come si convalida un codice fiscale conoscendo solo nome e cognome?
Potrei trovare due modi per farlo, in primo luogo convalidare solo i campi nome/cognome effettivi nel codice fiscale. Il secondo modo sarebbe generare ciascuna delle 75.000 possibili combinazioni di tutti gli altri campi e dichiarare che il successo è una corrispondenza. Ciò convaliderebbe anche i numeri di controllo.
Sembra che nessuno si occupi di convalidare il codice fiscale, o almeno c’è qualche trucchetto che non capisco.
Qualsiasi approfondimento sarebbe molto apprezzato!
Non ho capito bene la domanda, ma due punti sono fissi e immutabili.
Partendo solo da nome e cognome non si puo’ per questo dedurre nulla riguardo il C.F. Ma se uno si chiama Mario Rossi e le lettere del nome nel suo Codice Fiscale sono ABC DEF, allora si puo’ ragionevolmente concludere che il codice e’ sbagliato.
Grazie per aver risposto. Vorrei chiarire:
Per un cliente aziendale dell’UE, convalideremo la sua Partita IVA con un’API VIES. Esiste una validazione simile per il codice fiscale di un privato italiano?
Capisco che siamo tenuti a ritirare il codice fiscale quando il cliente configura il proprio account durante il pagamento. Ma senza chiedere loro la data di nascita, il luogo e il sesso, non possiamo convalidarli. Temo che quando poi inviamo il codice fiscale inserito nell’XML per SDI, possa essere errato e l’XML fallirà.
La domanda quindi è quanto impegno dobbiamo mettere per verificare la correttezza del codice fiscale inserito al momento del pagamento.
A.) Ci limitiamo a ritirare il codice fiscale, controlliamo che sia della giusta lunghezza e lo inviamo nell’XML in buona fede che sia corretto?
B.) Lo convalidiamo al meglio delle nostre capacità utilizzando solo il nome, il cognome e il checksum? Ciò può essere fatto convalidando ogni combinazione dei campi mancanti, ovvero circa 75.000 combinazioni che dovremmo scorrere. Sembra sciocco, ma si potrebbe fare.
C.) Siamo tenuti a raccogliere tutte le informazioni personali per formare un codice fiscale completo che possiamo essere quasi sicuri che corrisponda a una persona reale quando il codice fiscale viene inviato a SDI?
Non vedo negozi online italiani che facciano altro che raccogliere il codice fiscale e il nome/cognome. Non mi è mai stato chiesto data di nascita, provincia e sesso mentre compravo qualcosa in un web shop italiano.
Allora sto cercando di sapere come convalidano il codice fiscale, o addirittura se lo convalidano.
Capisco il problema. Il fatto e’ pero’ che anche conoscendo Cognome, Nome, data e luogo esatto di nascita non e’ detto che il Codice Fiscale calcolato sia quello effettivo. Nel caso di persone con nome e cognome simili, non necessariamente uguali, nate nello stesso Comune lo stesso giorno risulta lo stesso Codice Fiscale che deve quindi venire riassegnato centralmente. Oppure una donna con cognome da nubile e sposata, se ha preso quello del marito, prima Rossi e ora Neri. Io non rischierei a giocare con un codice autocalcolato che probabilmente nel 99% dei casi va bene, ma dove manca la certezza piena.
Tra l’altro in questo Forum discutiamo spesso su come trattare il Codice di chi e’ nato in paesi che alcuni decenni fa formalmente non esistevano, tipo Lettonia o Kazakhstan, o che allora esistevano ma adesso non piu’ , Cecoslovacchia, URSS, Yugoslavia. Non di rado vengono commessi errori da parte centrale, tipo prendere Russia per URSS, e assegnare C.F. non corretti. Tutti aspetti conosciuti ma che complicano la questione. In conclusione, il C.F. e’ quello ufficiale e assegnato dalla AE. Presupponiamo inoltre che cittadini adulti conoscano il loro C.F. o come minimo sappiano dove trovarlo sulla CIE o sulla Tessera Sanitaria.
Probabilmente, senza accesso a un registro centrale, non vengono convalidati. Forse altri partecipanti al Forum vogliono commentare questo punto.
Grazie. Sembra essere il fatto centrale che non possiamo sapere quale sia il codice fiscale effettivo, anche se abbiamo tutti i dati personali, perché AdE può modificarlo per renderlo univoco, e può riferirsi a paesi che erano sconosciuti ad AdE quando è stato creato il sistema.
Ciò significa che non possiamo realmente convalidarlo, oltre a convalidare la formattazione e forse il checksum.
La mia paura principale è che vedremo XML rifiutato da SDI a causa di un codice fiscale sconosciuto. Questo errore si verificherà nel profondo dell’elaborazione dei dati e potrebbero volerci più di 12 giorni per correggerlo, compreso contattare il cliente e ottenere il vero codice fiscale, e il ritardo nell’accettazione dell’XML potrebbe comportare sanzioni.
Quindi la vera domanda qui è quanto sia critico l’SDI per la qualità del codice fiscale, se vogliono solo che sia sintatticamente corretto o se deve essere mappato su una persona reale affinché l’XML sia accettabile.
Deve essere mappato su una persona reale.
La verifica dell’esistenza in questo senso è attualmente in fase di test, ma non si sa per chi è non si sa per quanto ancora
Ma allora non sembra un problema impossibile?
Ho capito bene?
proprio cosi’
Personalmente non lo so, e’ quello di cui stiamo discutendo. Una API di questo tipo potrebbe incontrare problemi di riservatezza, in pochi hanno piacere che il proprio C.F. sia accessibile a persone non autorizzate. Una API renderebbe possibile questo accesso.
L’ente che lo rifiuta ha accesso al database AdE? Non e’ che si trova nella stessa situazione di non potere verificare via API?
Se invece l’ente e’ statale e ha accesso al database, allora spetta al cliente comunicare il C.F. corretto per potere procedere. Una situazione nel quale il cittadino rifiutasse o non fosse in grado di comunicare il proprio C.F. ad AdE o alla ASL sarebbe paradossale.
Ho sempre dato per scontato che SDI avrebbe avuto accesso per convalidare il C.F. dell’acquirente, o almeno verificare che il C.F. è in uso effettivo.
SDI non sarebbe in grado di verificare che si tratti della persona giusta, perché non raccogliamo data di nascita/località/sesso durante il pagamento e non c’è modo di inviarli nell’XML (sotto CessionarioCommittente/DatiAnagrafici/CodiceFiscale).
Quindi tutto dipende dal fatto che SDI accetterà qualsiasi C.F. correttamente formattato, se verificherà che il C.F. esiste affatto e se almeno corrispondono anche al nome.
Quindi non sono sicuro di cosa fare. Qui l’esperienza aiuterebbe molto.
Coglieremo l’occasione e considereremo il C.F. valido se può essere decodificato da una delle librerie su GitHub, che convaliderebbe il checksum, la lunghezza e il set di caratteri.
Questa azienda ha la fortuna che, anche se è stata costituita in Italia perché il proprietario vive lì, relativamente pochi clienti provengono dall’Italia. Quindi possiamo permetterci di perdere qualche vendita italiana mentre cerchiamo di capire cosa accetta SDI.
Sarò sicuro di postare di nuovo qui come va.
Grazie profondamente per il tempo che ci hai dedicato discutendo di questo.
In effetti l’unica verifica realistica e’ che il C.F. sia correttamente formattato.
Forse questo puo’ servire?
https://telematici.agenziaentrate.gov.it/VerificaCF/Scegli.do?parameter=verificaCfPf
L’unico problema è che si tratta di un passaggio manuale, quindi non può essere integrato con un server. Non vedo un’API e anche altri hanno commentato che non esiste alcuna API.
In ogni caso, a meno che non raccogliamo data/luogo/sesso di nascita, non potremmo farlo nemmeno con un’API. Si tratta di ordini da 5,99 euro, e sono praticamente certo che un consumatore italiano preferirebbe abbandonare il nostro sito piuttosto che inserire tutte queste informazioni. E non vedo nessun negozio online raccogliere queste informazioni, quindi deve esserci qualche conoscenza che non ho.
Mi affiderò a una convalida formale utilizzando ad es. GitHub - DavidePastore/codice-fiscale: A PHP library to calculate and check the italian tax code (codice fiscale).
Aggiornerò il post non appena avremo trasmesso a SDI alcuni ordini di privati italiani.
Le API dell’AdE per la verifica del codice fiscale sono in fase di test e dovrebbero essere rilasciate a “breve”. L’ho scritto tra virgolette perché in teoria dovevano esserci già ma per ora solo pochi fortunati lo stanno testando.
Se ne discute qui:
N.B. Presumibilmente le API offriranno gli stessi servizi che ora sono disponibili per l’uso manuale, quindi non solo la verifica della corrispondenza tra codice fiscale e dati anagrafici, ma anche quello della mera validità del codice fiscale ( Verifica codice fiscale di persona fisica o di soggetto diverso da persona fisicaVerifica del codice fiscale di persona fisica o di soggetto diverso da persona fisica ). Questo non richiede di raccogliere i dati anagrafici della persona.
Più in generale, anche senza il servizio di verifica, se si chiede all’utente di inserire il codice fiscale, fare il confronto con i dati anagrafici serve a poco.
Se l’utente inserisce il proprio codice fiscale, la verifica della validità formale (codice di controllo) è probabilmente sufficiente, perché è difficile che un errore di battitura produca un codice fiscale formalmente valido.
Se l’utente fa il furbo e inserisce un codice fiscale inventato, ci vuole poco a inventare anche i dati anagrafici corrispondenti (o piuttosto il contrario), creando un’identità+c.f. formalmente validi ma del tutto fasulli. In questo caso solo una verifica nel database dell’AdE può stabilire se il c.f. è valido o no.
Buon punto. Allora, per il momento effettueremo una convalida formale e rimarremo attenti agli avvisi su questa nuova API. Grazie!
È ora possibile iscriversi al sistema di API per la verifica del codice fiscale e della partita IVA. Almeno, io ci sono riuscito, accedendo all’area riservata con l’identificativo fiscale di una società, non con un’utenza di persona fisica.
L’unica “pecca” è che il rate limiting è molto limitante. Capisco l’esigenza di prevenire abusi, ma 2 richieste massime per minuto rendono impraticabile usare il servizio per una verifica in tempo reale dei dati di fatturazione immessi, ad esempio, da un utente di un e-commerce in fase d’acquisto.
Grazie!
Per ora, stiamo eseguendo una convalida formale con GitHub - DavidePastore/codice-fiscale: A PHP library to calculate and check the italian tax code (codice fiscale). (utilizzando $validator->isFormallyValid();).
Tra un paio di giorni renderemo operativo lo storefront dell’UE e inizieremo a inviare XML a SDI. Pubblico qui quale è la risposta ai codici fiscali convalidati solo formalmente.
Ci sono altre situazioni, del tutto slegate dalla fatturazione, in cui la verifica del codice fiscale sarebbe utile.
Vi faccio due esempi (che conosco):
Legare quindi il rate limiting al numero di fatture inviate non ha molto senso secondo me. E in ogni caso 2 al minuto è ridicolo.
Concordo. Capisco l’idea che sta dietro al rate limiting, per prevenire abusi del sistema o, peggio, veri e propri scraping di tipo “brute force” per crearsi un’anagrafica di tutti i codici fiscali italiani.
Capisco anche che sia difficile trovare un criterio per proporzionare il rate limiting in base all’azienda.
Però a mio avviso il rate limiting dovrebbe essere orario o giornaliero anziché al minuto. Anziché 2 richieste al minuto potrebbero impostare massimo 2880 richieste al giorno.
Sarebbe molto più utile dal mio punto di vista pratico.