Salve,
a partire dalle 9:05 di questa mattina il servizio https://servizi.fatturapa.it/ricevi_file NON risponde più in seguito all’invio di una fattura (nei log è riportato l’errore “An error (The request was aborted: The request was canceled.) occurred while transmitting data over the HTTP channel.”), ma in verità le fatture inviate in questo lasso di tempo sono state ricevute dallo SDI perché nel frattempo stiamo ricevendo le Notifiche di Consegna, che però non riusciamo a registrare a sistema in quanto non sono associate ad alcuna fattura inviata con l’identificativo SDI specificato, non essendoci stato comunicato in seguito all’invio della fattura.
Qualcun altro sta riscontrando lo stesso problema?
Grazie
Confermo, stessi problemi a partire dalle 9:00, sono venuto sul forum proprio per vedere se anche altri riscontravano problemi.
Grazie per il riscontro, almeno così so che non si tratta di un nostro problema!
Chissà quale soluzione verrà proposta per riparare al danno arrecato, sempre che verrà fatta una comunicazione ufficiale…
Stesso problema… Speriamo comunichino qualcosa
Stesso problema, attualmente sembra rientrato. Per noi successo tra le 9.17 e le 10.32
Si confermo, anche per me il problema è risolto
Rispondeva errore, ma prendeva la fattura, assegnava un id sdi e poi mandava pure le notifiche. Siamo pieni di clienti con scarti per fattura doppia nel lotto … e risolvere è un casino, ci sta impegnando il fine settimana.
Qualcuno ha suggerimenti su modalità migliori per affrontare il problema (da inizio 2019 è già capitato almeno due volte)
Addirittura a volte capita che arriva prima la notifica rispetto alla risposta dell’invio della fattura che contiene l’ID SDI!
Noi abbiamo risolto parzialmente (in alcuni casi sporadici, come quello appena descritto, è necessario un intervento manuale!!) salvando comunque la notifica che riceviamo con ID SDI non presente a sistema e duplicando il record relativo alla fattura inviata tracciando quello che in effetti è un doppio invio della fattura, ma in questo modo abbiamo anche il riferimento all’invio andato a buon fine, a questo punto aggiornando lo stato della fattura inviata e trovando un invio andato a buon fine la fattura risulta inviata correttamente.
Inizialmente correggevamo anche noi a mano queste fatture “doppie” ma quando i casi sono diventati frequenti abbiamo attivato questa procedura automatica.
Sì, ogni tanto capita: invii, ti dà errore, invii di nuovo (come retry), ti arriva scarto, poi ti arriva invece la ricevuta di consegna/mancata consegna del primo tentativo di invio. A quel punto è un casino, perché magari tu hai già segnalato la fattura come scartata.
Al momento sistemiamo a mano. Mi sono fatto l’idea che bisognerebbe ritardare l’elaborazione degli scarti di qualche ora, almeno nel caso di problemi di invio della fattura, in modo tale per cui, se nel frattempo arriva una ricevuta, poi lo scarto venga scartato. Solo che non è così semplice, perché altrimenti si rischia di ritardare l’elaborazione di qualunque tipo di scarto, anche quelli che invece sarebbe bene elaborare velocemente.
Lo scarto anomalo però lo riconosci dal fatto che è uno scarto per fattura duplicata, quindi puoi ritardare solo questo tipo di scarti. Se i tuoi clienti inviano le fatture solo attraverso il tuo canale e verifichi l’univocità delle fatture a monte, uno scarto per fattura duplicata non dovrebbe capitarti mai in circostanze normali.
Questo tipo di verifica è impossibile. I clienti “arrivano” ed hanno già fatto fatture con altri software e/o usando altri canali, in più sono dei grandi pasticcioni e per sistemare problemi più o meno reali possono anche creare fatture con numeri duplicati e provare ad inviarle. Quindi non posso avere la certezza che la tal fattura non sia duplicata, sia a livello di nome di file che a livello di numero di documento. Scartare uno scarto a priori se è di quel tipo è troppo rischioso.
Forse abbiamo trovato la quadra che consiglierei a chiunque.
Quando inviamo un xml, il nome del file ci è noto sia in fase di invio che in fase di reinvio. Ed è uguale tra i due diversi tentativi.
Quando ci arriva una notifica, noi solitamente la abbiniamo per SdI id e se questo non risulta possibile mettiamo la notifica in una coda a parte.
A quel punto, la sera, recuperiamo le notifiche “parcheggiate” basandoci sul nome del file (la parte iniziale del nome di notifica è uguale al Nome file inviato) e non sull’ID SdI, cambiamo id SdI alla fattura mettendo quello nuovo, buttiamo via tutte le vecchie notifiche di scarto (per fattura duplicata) relative al vecchio SdI id perché non ha senso tenerle…
Questo risolve il problema di SdI intermittente tipo quello di una settimana fa: la condizione però è che internamente il nome file non si cambi nei retry…
Noi abbiniamo sempre per nome del file, anche perché l’identificativo SdI in generale potrebbe non essere noto finché non arriva la prima risposta dall’SdI (ricevuta, scarto o quant’altro): ad esempio questo è quanto accade nell’invio via PEC.
Il nome del file, del resto, è garantito essere univoco dall’SdI nei secoli dei secoli… in teoria.
Peccato che…
ci sia capitato già più di un caso di fatture DIVERSE con lo STESSO IDENTICO nome file (attenzione: non parlo di differenza di maiuscole/minuscole, che è pure una norma abbastanza fastidiosa), perché pare che nel 2016 abbiano ad un certo punto fatto un “reset” e quindi abbiano cominciato ad accettare fatture nuove con nomi di file già usati precedentemente.
Quindi, anche in questo caso, non è facile stabilire programmaticamente e senza alcun ombra di dubbio che una ricevuta di consegna con un determinato identificativo SdI debba invalidare uno scarto per una fattura con lo stesso nome ma identificativo SdI differente.
Io eventualmente questo criterio lo subordinerei sempre al fatto che ci sia stato un numero di tentativi di invii superiore ad 1 per la fattura a cui dovrebbe riferirsi.
Non sarebbe male che l’SdI fosse reso più solido da questo punto di vista: se il client riceve un ERRORE, perché la comunicazione si è interrotta o per qualunque altro motivo, l’SdI non dovrebbe committare l’acquisizione di quella stessa fattura. Ci saranno sempre dei corner case in cui magari l’errore si verifica nell’ultimissima fase di comunicazione tra client e server: in quel caso un meccanismo “pull” di verifica dell’acquisizione o meno della fattura, basato su nome ed hash della stessa, sarebbe estremamente utile per capire se l’errore precedente ha comportato la mancata acquisizione della fattura o meno.
1 Mi Piace
Stesso problema dalle 9:07 alle 10:34