Anche a noi è successo che alcune fatture, per le quali la richiesta è andata in timeout, in realtà siano state trasmesse (alcune più volte) e le relative notifiche sono arrivate ieri. Il nostro sistema purtroppo non le gestisce (essendo che per noi la fattura non risulta mai inviata).
Per quanto riguarda la ricezione delle fatture, a noi funziona tutto normalmente. Non abbiamo avuto più problemi dopo il pomeriggio del 1/6.
Io ho implementato un meccanismo per cui le notifiche di scarto con codice 00404 (fattura duplicata) vengono elaborate con 6 ore di ritardo in attesa di ricevere un altro tipo di notifica che attesti viceversa l’avvenuta trasmissione della fattura. Al contrario, se uno scarto di quel tipo viene ricevuto dopo una notifica che attesta l’avvenuta trasmissione della fattura, viene semplicemente ignorato e scartato. Ma con il disastro dei giorni scorsi ho anche dovuto implementare un meccanismo per cui se arriva una notifica che testimonia l’avvenuta trasmissione dopo che una fattura è stata marcata come scartata (superate le 6 ore), allora il sistema cambia lo stato della fattura in maniera opportuna: è il tipico caso di ricezione di notifiche out-of-order… e purtroppo ci sono stati diversi casi di questo tipo in questi giorni (tipo: ricevute di consegna ricevute con un giorno di ritardo, probabilmente a causa di problemi di consegna dall’altra parte). Ovviamente quest’ultimo meccanismo va in crisi se nel frattempo il cliente, avendo visto lo scarto, ha già provato a ritrasmettere la fattura, con un nuovo codice di trasmissione e tutto il resto… a quel punto non resta che chiamare il cliente e provare a risolvere a meno, recuperando l’invio originale… insomma, un casino.
Che poi, mi dico: quando ricevono una ritrasmissione, non possono controllare l’hash della fattura e, se corrisponde, evitare di assegnarmi un nuovo identificativo SdI e mandarmi poi un inevitabile scarto per “fattura duplicata”??? Si eviterebbero un sacco di problemi e di inutili scarti.
A me è tornata a funzionare ieri alcune decine di minuti dopo che ho aperto, non senza fatica (*), una segnalazione al call center. Lato nostro era tutto ok, con certificati sostituiti da una quindicina di giorni, ma su uno dei due canali (quello di ricezione delle fatture passive) avevamo smesso di ricevere notifiche e messaggi dal pomeriggio del 31/05. Devono aver combinato qualche casino con il fatto che ci hanno chiesto di generare una nuova CSR a maggio (peraltro però per l’altro canale, quello di ricezione delle notifiche per le fatture attive, che invece ha continuato a funzionare…).
Adesso devo segnarmi tra 1-2 settimane di controllare con il servizio di quadratura se ci siamo persi qualcosa per strada…
(*) = primo tentativo: apro segnalazione per iscritto. Mi rispondono per mail chiedendomi un recapito telefonico, che io pure avevo fornito. Il corpo della mail contiene il pulsante per riaprire la segnalazione (in modo da poter rispondere), ma non funziona, l’HTML nella mail è completamente sbagliato ed anche provando ad analizzarne il codice ed a copia-incollare il link nel browser, non va, probabilmente a causa dell’encoding di parte dell’URL (peraltro molto lungo…)… Provo quindi a telefonare: “risponde l’operatore numero XYZ”… silenzio assoluto. Aspetto un minuto, nulla. Metto giù, richiamo il numero “tutti gli operatori sono occupati, richiamare più tardi”… A questo punto apro nuovo ticket per iscritto, citando il precedente e mettendo il recapito telefonico anche nel corpo del testo… A quel punto dopo circa un quarto d’ora finalmente sono riuscito a parlare con un operatore, fortunatamente gentile e che ha capito il problema (anche perché appunto mi ha confessato che c’è stato un problema a livello nazionale…).
Però, ecco, ogni volta è un calvario…
Confermo, identico accaduto. Il link sul bottone si apre solo da alcuni client (per esempio, da Gmail web funziona). Le nuove CSR comunque non stanno arrivando. Noi chiederemo se possibile la ritrasmissione senza passare dal servizi di quadratura perché hanno un massimo di 100k documenti/mese (che superiamo ampiamente) e non si possono usare finche non sono trascorsi 15 giorni dall’incidente.
Occhio che quelli che erano sul “canale veloce” sono messi peggio che quelli che erano sul “canale lento”.
In questo caso essere sfigati è un vantaggio.
A intermediari vip era stato destinato un canale veloce, come i treni dell’alta velocità
Chi veicola 100-200 Mila fatture al giorno per esempio
Su quei binari grossi pasticci coi certificati lato sdi
Su quelli lenti della plebe invece molto meglio
Comunque, alla fine della fiera, in azienda da me ci stiamo interrogando se non sia più sensato dismettere il canale di trasmissione web service in favore dell’uso di una casella PEC dedicata, visti i numerosi problemi e le criticità che ha mantenere questo tipo di canale…
Sono un po’ di giorni che non mi arriva nessun esito, ma riesco ad inviare senza problemi, qualcuno può darmi una mano a capire il problema, il call center mi deve ancora dare una risposta.
Se ti colleghi al tuo endpoint dove dovresti ricevere le notifiche con un browser e guardi le proprietà del certificato SSL, sono corrette? O è scaduto?
Buongiorno,
credevo di aver fatto tutto bene seguendo mano mano questo thread e utilizzando i comandi di qualche pagina fà con openssl.
Mettendo il nuovo certificato server dopo la relativa trasformazione in pfx e la nuova CA inviata insieme, navigando su fattu.miosito.it:443 , firefox mi restituisce un errore “SEC_ERROR_UNKNOWN_ISSUER” come se ci fosse il solo certificato “server” non legato alla CA dell’Agenzia entrate (quella con scad il 2038). Su mmc però questo legame sembra esserci senza problemi.
Come posso rimediare ?
A meno che tu non abbia caricato la CA dell’AdE in Firefox è normale che ti dia l’errore. La CA dell’AdE non è tra quelle riconosciute da Firefox (o dai sistemi operativi).
L’errore della mia applicazione è che non riesce piu a creare un canale sicuro SSL quando si connette con il certificato SERVER di SDI da quando ho aggiornato i certificati.
Se provo con openssl s_client -connect miosito.it:443 mi genera i seguenti 2 errori
verify error:num=20:unable to get local issuer certificate
verify error:num=21:unable to verify the first certificate
altresi se invece aggiungo il parametro -CA CaEntrate.der funziona. In fase di creazione dei pfx ho usato il solo CaEntrate.der fornito insieme ai 2 certificati client /server come opzione -CertFile eppure sembrerebbe fregarsene.
Qualcuno che ha installato i certificati server di Produzione con IIS può dirmi che concatenazione di certificati ha usato ??
Se passi anche l’opzione -showcerts al comando openssl che hai usato per testare il server, quanti certificati vengono fuori? Dovrebbero essere due, quello CA e il tuo certificato server.
Se ti viene fuori solo il certificato server (come sospetto), vuol dire che hai sbagliato qualcosa nell’installazione dei certificati in IIS, ma su questo non so aiutarti perché noi non usiamo IIS (o per essere precisi, lo usiamo, ma dietro un load balancer che gestisce il protocollo TLS).
Io il pfx l’ho creato così, non so se può esserti utile: openssl pkcs12 -export -out c:\SdiCoop\SDI-xxxxxxxxxxx-server.pfx -inkey c:\SdiCoop\server.key -in c:\SdiCoop\SDI-xxxxxxxxxxx-server.pem -certfile c:\SdiCoop\CAEntrate_prod.der
Buongiorno a tutti, anche io sto riscontrando problemi da inizio maggio, da quando sono stati cambiati i certificati. La nostra infrastruttura, che utilizza il canale SDICoop è funzionante da anni. Da quando ci sono state modifiche ai certificati continua a funzionare ma continuano ad esserci fatture in ricezione che non vengono consegnate (e quindi messe a disposizione sui cassetti fiscali dei clienti) o ritardi nel contattare lo SdI per inviare fatture trasmesse. State riscontrando anche voi problemi di questo tipo? Grazie mille.
Quello che mi hanno mandato non era _prod (scadenza 2038) mi pare comunque ho usato lo stesso procedimento e installato come era il precedente in account del computer in personal, mi aveva messo la CA anche lì e io l ho messa in Trusted Root ma niente…
Domani saprò dirti meglio