Salve. Dalle ore 16.04 non riceviamo più nulla sul canale SDICoop. Inoltre, se proviamo ad inviare qualcosa sul canale viene restituito un errore di timeout.
Qualcun’altro ha lo stesso problema?
Ciao anche noi stiamo riscontrando problemi di comunicazione dalle 15.59 di oggi
Ciao stesso problema con il cloud di SAP
Confermo che anche noi stiamo ricevendo errori di timeout
Confermo Timeout di connessione a SDI.
Confermo.
Ho ricevuto 4 messaggi alle17.10, ma e dalle 16 che ricevo errore quando invio 
Sembra che il problema sia rientrato 
Attualmente sembra rispondere a singhiozzo, alcune passano altre no
A noi ancora nulla. Tutto tace
Anche da me alcune passano, ma con tempi lunghi (di invio).
Ciao a tutti. Ci risiamo. Dalle ore 09.41 non riceviamo più nulla sul canale SDICoop e se proviamo ad inviare qualcosa sul canale viene restituito un errore di timeout.
E’ un ns. problema o anche a qualcuno di voi capita lo stesso?
Ciao purtroppo confermo, non riceviamo fatture passive dalle 8 e dalle 9.58 alle 10.28 abbiamo ricevuto timeout. Ora gli invii sembrano andare bene
Grazie Antonino. Dopo il tuo messaggio abbiamo riprovato e sembra che anche i ns. invii adesso abbiano successo. Speriamo bene
Ciao a tutti. Noi dalle ore 12.47 non riceviamo più nulla sul nostro canale. Inoltre, abbiamo provato ad inviare degli XML ma abbiamo ricevuto un timeout. Qualcuno ha gli stessi problemi?
Ilproblema è che alcuni documenti inviati SDI li ha processati e mi sono arrivate anche le notifiche di RicevutaConsegna … peccato che non ho ricevuto gli Identificativi per poterle tracciare
Si ho avuto notifiche di errore sull’invio a SdI dalle 13.15 alle 14.15 … il primo errore è stato un HTTP 500 (internal server error) poi chiusure forzate della comunicazione. Sto ancora attendendo il timeout di una 15ina di invii in quanto ho allungato parecchio il timeout delle chiamate a SDI dopo una chicchierata con l’assistenza.
E’ da stamattina che in trasmissione notifiche e file fatture non funziona.
https://servizi.fatturapa.it/ricevi_notifica?wsdl
restituisce 403 Forbidden
Questo è tipico. Un mese fa ci è pure successo che ci arrivasse la notifica mentre l’invio era ancora in attesa di una risposta (andato poi in timeout).
Noi finora questa cosa dei timeout non l’abbiamo mai gestita, pensando che fosse un caso raro. Ma ultimamente capita una o due volte al mese, e ogni volta è un casino, perché per il nostro programma la fattura risulta non inviata e gli utenti provano a inviarla di nuovo, ricevendo una notifica di scarto per fattura duplicata. E siccome non possiamo essere certi che non l’abbiano modificata nel frattempo, dobbiamo fargli scaricare dal cassetto fiscale la fattura effettivamente inviata.
A questo punto dobbiamo introdurre un nuovo stato per le fatture, “Forse inviata”. E farla tornare allo stato “da inviare” se non arriva nessuna notifica entro un paio di giorni.
Vladan, vi suggerisco di non fare giochi con nuovi stati. Se il cliente chiede l’invio è perché la vuole inviare. Se va in timeout l’invio, riprovate dopo 10 minuti e via dicendo, mantenendo intatto il nome del file, questo è fondamentale.
Quando una fattura viene messa in spedizione credo voi la blocchiate per l’editazione, altrimenti il cliente può spedirla mille volte, no? Bene… La cosa migliore quando la spedizione va in errore è, insieme al nuovo tentativo, mandare un alert sia a voi che al cedente prestatore del tipo “questa fattura sarà problematica”. Segnate a quel punto sulla fattura un qualcosa che impedisca di sbloccarla anche se arriva uno scarto. Più avanti le notifiche che per SDIID non entrano le riaccoppiate per nome del file, tanto il prefisso è sempre quello, escludendo gli scarti che contengano “DUPLICAT” (perché i tentativi di invio possono essere stati tantissimi).
Per come funziona il nostro sistema, la fattura non viene “messa in spedizione”. La spedizione avviene in tempo reale quando lo chiede l’utente (anche per più fatture insieme). Finora il SdI ha sempre funzionato bene e l’invio è sempre stato immediato, quindi non c’è mai stato bisogno di implementare un sistema che esegue gli invii in background e fa tentativi multipli.
In caso di errore, all’utente viene visualizzato un messaggio e può ritentare l’invio. Si era partiti dall’ipotesi che un eventuale errore di comunicazione con il SdI volesse dire che la fattura non è stata presa in consegna, ma così non è.
Nel caso di timeout sulla ricezione della risposta alla richiesta SOAP inviata, non va bene né che l’utente ritenti l’invio né che questo venga ritentato in automatico, in quanto nella quasi totalità dei casi visti finora (tutti tranne uno), il SdI aveva in realtà preso in consegna la fattura al primo tentativo e tutti quelli successivi non hanno fatto altro che produrre notifiche di scarto spurie.
Per questo volevamo bloccare sia l’invio che la modifica della fattura, in attesa di vedere se arrivano notifiche dal SdI.
Per fortuna questi eventi sono ancora piuttosto rari, quindi possiamo gestirli manualmente quando capitano, e il blocco degli invii multipli ci semplifica il lavoro.