Ciao Paolo, Ciao Lucio, Ciao Neapolis,
noto che siete attivi anche di Domenica, (ed io non mi astengo).
vi rendo partecipi di questa frase:
“La stima del tempo intercorrente tra il momento T0 ed il momento T1 può essere
quantificata in un tempo medio di circa 48 ore, variabile in ragione della specificità
del canale scelto dal soggetto ricevente e della frequenza di afflusso delle fatture al
Sistema di Interscambio.”
presa a pagina 34 di: specifiche SDI , se notate dalla tabellina dei 3 canali si genera una matrice di 9 possibili combinazioni.
per cui le 48 di media , potrebbero … nella denegata ipotesi che trasmittente e ricevente siano entrambe sdiftp… un po’ di piu’.
io non mi sono mai interessato di SDIFtp ma a naso, (qui vado a cappella, per cui mi corrigerete) se è possibile via sdiftp comporre un invio multiplo di fatture in un unico files, ho la paura che abbiamo ritenuto di fare l’invio solo DOPO che l’ultimo dei mohicani dei riceventi abbia notificato.
Prendete questa mia ultima frase come una pura illazione in quanto di SDIFTP non ne capisco una f@va e potrei aver uscito una c@gata.
Buona serata, ed in bocca al lupo anche a voi per la SEMANA GRANDA
Caro @dscaravaggi Io non so per chi lavori e perchè continui a difendere l’operato di SDI, ma evidentemente non ti è chiaro un concetto.
Le 48 ore di cui parli sono relative alla fattura in se.
Qui c’è gente che non sta neanche ricevendo i file EO che riguardano i flussi di trasmissione.
Il fatto che SDI abbia poi di continuo problemi di decriptazione di file che risultano correttamente trasferiti dai log SFTP la dice lunga su come i flussi vengano gestiti all’interno di SDI.
L’invio dell’EO dovrebbe avvenire in contemporanea al prelievo da parte di SDI del flusso.
Il file EO dovrebbe solo dire al nodo SDIFTP che il file prelevato da SDI è leggibile e corrisponde alle specifiche.
Il flusso di lavorazione suppongo sia il seguente (o perlomeno così lo avrei implementato se lo avessi fatto io)
Prelevo il flusso
verifico la firma
testo lo ZIP contenente il pacchettone di fatture
se i punti sopra sono passati metto il file E0 nella coda di invio per il successivo controllo del nodo SDIFTP
In modo asincrono decompatto lo zip e passo le fatture ad un orchestrator per la distribuzione (come ogni fattura che entra ad esempio da webservice).
Raccolgo gli esiti e li invio quando disponibili al nodo con l’invio successivo insieme alle fatture destinate al nodo.
Marco tutte le fatture trasferite al nodo come consegnate e invio al mittente ricevuta di consegna.
Ora i punti dall’1-4 non dipendono dagli end point ma sono solo questioni interne di SDI.
La perdita di dati e i rallentamenti si verificano principalmente li…
Cosa stiano facendo non lo so, ma qualcosa di sicuro non va…
Grazie Romolo per la precisazione,
sai che io (da ignorante sdiftp) fino a questa sera non avevo capito,
quindi voi avete già problemi sul flusso di invio che genera il T0 ,
mentre cihi usa SDICoop il T0 è implicito nella response “Data e ora presenti all’interno della response del servizio esposto dal SdI”
io ero convinto che avevate problemi di ritardo sul T1 in ricezione,
onestamente in questo caso mi sembra autolesionistico da parte di SDI / Sogei continuare a dire che va tutto bene, oltretutto hanno anche le “sonde” di Tria infilate nel…
Diego nota che oltretutto il T0 non è nelle nostre volontà…
Io più che mettere un file in una cartella leggibile da SDI non posso fare…
Inoltre sono sicuro che SDI si connette perchè mi aggiorna di continuo un file nella cartella DatiVersoSdITest e oltretutto le loro connessioni sono tracciate dal mio server.
SDI sta negando l’evidenza o perlomeno la sta minimizzando.
Ovviamente il problema su SDIFTP si sta propagando anche a chi usa SDICOOP perchè tutti i problemi inerenti le comunicazioni verso SDIFTP provocano ritardi anche a loro.
La situazione è così ridicola che ultimamente sto ricevendo i flussi E0 dopo aver ricevuto T1…
Ovvero mi danno conferma di aver prelevato i pacchetti da elaborare dopo che li hanno elaborati e mi hanno dato già l’esito delle singole fatture contenute nel pacchetto.
Quando qualche post fa parlavo di problemi di scheduler (o di orchestrator, dato che non so cosa usino) non credo di essermi allontanato molto dalla realtà…
Anche i punti 6-7 non dipendono quindi da noi se SDI è in grado di consegnarmi le fatture.
Per darti ancor più evidenza posto le statistiche di uno dei miei clienti:
Come vedi sono 4 giorni che ho degli EO in sospeso (barre del grafico di sotto in giallo) ma nel frattempo mi arrivano fatture (queste sono le statistiche di un cliente nella media) In compenso in alcuni giorni nonostante SDI si collegasse non ho ricevuto una fattura che una (questo cliente ne riceve almeno 200 al giorno di media). Inutile dire che SDI ha preso tutto e che nella directory di invio non ho più neanche un file. Da domani si inizieranno a crearsi le code di invio ma ad oggi tutto quanto è smaltito…
Ulteriore dettaglio per farti capire che casini sta facendo SDI;
I file di invio che mi sono stati recapitati oggi recano come data di creazione il giorno 31 e 32 dell’anno ovvero 31 gennaio e 1 febbraio e tutte le fatture contenute hanno come attributo “tentativo invio” nel file dei metadati 1.
Ovvero è la prima volta che hanno provato a consegnarmeli e io me li sono presi senza problemi.
Se la colpa fosse nostra (ovvero per assurdo di tutti quelli che usando SDIFTP hanno fatto marchiani errori nella configurazione del nodo) allora tentativiinvio dovrebbe essere >1 e non 1.
Arrivata la mail…
evidenzia ritardi di oltre 5 giorni nonchè la famosa perdita di dati del giorno 9…
Ovviamente anche oggi SDI consegna le notifiche prima degli E0…
certamente la mancata conferma del T0 può essere una noia per voi che gestite con SDIFTP, ma arrivati a questo punto pragmaticamente io lo metterei come warning e non come errore nell’engine di invio, invece mi segnerei il 226 sul canale SFTP (226: Requested file action successful).
…poi sull’episodio del 9 Gennaio oramai sui forum sono stati scritti romanzi…
Infatti mi va in giallo (warning), e se poi ricevo notifiche relative alle fatture del flusso passa direttamente agli stati successivi senza passare da T0…
Quello che da fastidio della mancanza del T0 è tuttavia proprio legato agli eventi del 9, Teoricamente non posso essere certo della corretta ricezione da parte di SDI e posso trovarmi giorni dopo con richieste via email di reinvii flussi, richieste che non passando per i canali formali (esito ET02) ovviamente vanno gestite a mano, con clienti magari anche un po’ in*****ti per i ritardi.
La fattura di cortesia viene comunque inviata subito
Anche i muri sanno che la benedetta notifica può arrivare anche 120 ore dopo, le statistiche dicono che più o meno anche er chi usa sdiftp dopo 48 ore il 99% viene notificato
Tocchiamoci dove serve e scongiuriamo il ripetersi del fattaccio del 9 Gennaio
Ottimismo
P.S.: anche io mi sono beccato una notifica al limite delle 5gg … ed era di… Autogrill gestita da IBM, avvenuta dopo il 16 Gennaio, per cui tutti hanno i loro scheletri negli armadi.
risottolineo in taluni limitati casi, e se ci fai caso il giornale dei commercialisti ha scelto il disegno del foglio di carta con la presa di corrente.
In taluni casi sarebbe stato utile fare formazione e avrebbero dovuto utilizzare i 6 mesi di prova della fatturazione elettronica ai carburanti, come banco di prova ed esrciziario per arrivare preparati al 1° Gennaio.
“Come spiegato da Assosoftware, gli elementi che possono condizionare i tempi di consegna della fattura sono molteplici e non sono predeterminabili. Malfunzionamenti nelle elaborazioni dei file o nella comunicazione tra i diversi sistemi potrebbero addirittura comportare, in taluni limitati casi, sempre secondo Assosoftware, ritardi anche superiori a cinque giorni dalla data di invio tramite provider, in particolare in questa fase di avvio.”
sono i taluni limitati casi che sono opinabili…
ma come dicono a Napoli “Ogni scarraffone è bello a mammate soia”
io aggiungerei:“Ogni scarraffone è limitato a mammate soia”
Mi piacerebbe capire come quelli di Assosoftware hanno valutato la limitatezza dei casi…
Io dico che due episodi di disservizio (di 5gg cadauno) in 30gg a casa mia non sono proprio limitati dato che riguardano il 33% del periodo…
mi sono iscritto per lamentarmi che non mi era ancora arrivata una semplice notifica di esito EO dopo 12 ore…ora ho letto un po’ di messaggi e capisco che 12 ore è pochissimo!!!
Mah…
ahahah ok…ho capito…
pensavo che l’esito fosse una cosa quasi automatica che controlla solo la struttura delle fatture e del file di quadratura quindi quasi immediata…non pretendevo la notifica di accettazione o di consegna o altro…
vi racconto anche io un piccolo aggiornamento, in merito alle FE emesse ieri 4 Feb (dalle 08:00 alle 19:00)
quelle verso clienti che usano M5UXCR1( AGYO TeamS.) 670 emesse, 650 confermate ieri entro le 24 ore. 20 a scarto, ovvero 100% recapitate.
perde i colpi SUBM70N Zucchetti, su 340 fatture, 210 confermate ieri, 120 confermate oggi , 10 a scarto.
Chiaramente, non fanno testo con i problemi cha avete voi, era solo per darvi un aggiornamento su SDICOOP Web-service
P.S.: il vero tema sarebbe capire quante fatture smazza Zucchetti in generale, magari poi si scopre che per il volume che gestisce è tecnicamente più veloce. (e penso che abbia dei volumi tali, che il mio webserver si impianterebbe dopo 5 minuti)
Dato che mi sono rassegnato, ho richiesto l’accreditamento SDICoop. Secondo te, @dscaravaggi, quanto impiegheranno a produrmi i certificati? Giorni, settimane, mesi?
Almeno so di che morte debbo morire…
Ottimismo
