Ciao a tutti,
oggi lo sdi ci ha recapitato la seguente mail:
Gentile referente,
dal prossimo 4 aprile saranno efficaci le novità apportate al servizio SDIFTP, descritte nel documento specifiche tecniche in versione 1.4, allegato A al provvedimento del direttore dell’Agenzia delle Entrate del 30 aprile 2018.
Il documento è pubblicato sul sito dell’Agenzia delle Entrate, nella sezione specifiche tecniche Fatture e Corrispettivi, raggiungibile al seguente LINK .
Segreteria Tecnica SDI
ho provato a consultare il pdf (232 paginette…) e nella tabella di pag.6 trovo questa utile informazione:
1.4
26/02/2019
Indicati, per ciascun canale, i fattori non dipendenti dallo Sdi che incidono sui tempi di consegna delle fatture ai destinatari e delle notifiche ai mittenti.
Introdotta una regola per ottimizzare la trasmissione/ricezione attraverso il servizio SDIFTP (efficace del prossimo 4 aprile)
Dettagliati i tempi e i tentativi di consegna delle fatture al destinatario, per il servizio SDICOOP e di trasmissione delle ricevute al mittente per il servizio SDICOOP e per la PEC
peccato che i riferimenti finiscano qui… qualcuno di Voi è riuscito ad individuare quali sono le eventuali modifiche da fare (se ne esistono)?
Grazie
Una cosa che mi sembra cambiata è la seguente a pagina 14:
Esiste inoltre un vincolo alla eccessiva parcellizzazione dei file fattura all’interno dei supporti: è ammessa, per ogni accesso al server (che avviene ordinariamente ogni 10 minuti), la presenza sul nodo di scambio di un unico supporto con dimensione inferiore ai 15 megabyte, mentre eventuali ulteriori supporti presenti dovranno avere dimensioni comprese tra i 15 megabyte e i 150 megabyte.
Un mio collega ha fatto un diff tra il vecchio pdf e la nuova versione ed ha rilevato le seguenti modifiche:
Pag 14:
nell’ultimo capoverso si parla di variazioni sulle regole di prelievo dei supporti in base alla dimensione dei files prodotti
Pag. 25 e 26:
Nuove annotazione relative ai tempi di elaborazione previsti dallo SDi
Per quanto riguarda la parte SDIFTP le variazioni sembrano essere queste.
Sinceramente ci siamo concentrati sullo SDIFTP quindi modifiche relative ad altri canali non le abbiamo degnate di particolari attezioni.
Per quanto riguarda SDICoop, ho notato che hanno aggiunto il seguente testo a pag. 16 nella sezione “COOPERAZIONE APPLICATIVA SU RETE INTERNET (SERVIZIO SDICOOP - RICEZIONE)”:
In considerazione del fatto che, per motivi indipendenti dal SdI, il servizio potrebbe
essere temporaneamente indisponibile, il Sistema effettua fino ad un massimo di 3
tentativi di trasmissione, uno ogni 4 ore.
Nel vecchio documento non c’era scritto niente, ma mi pare che da qualche altra parte ci fosse scritto che facevano tre (o quattro) tentativi ogni mezz’ora. Adesso hanno allungato i tempi.
A completamento delle informazioni sopra riportate queste sono le modifiche apportate:
Pag. 16: PEC
Il SdI considera fallita la trasmissione se:
riceve dal gestore di posta del destinatario una notifica di mancata
consegna;
non riceve alcuna comunicazione da parte del gestore di posta del
destinatario entro un tempo massimo di 40 ore.
Pag. 24
In considerazione del fatto che, per motivi indipendenti dal SdI, il canale potrebbe
essere temporaneamente indisponibile, il Sistema:
per il canale web-services (Servizio SDICoop – Ricezione) effettua
fino ad un massimo di 6 tentativi di trasmissione distribuiti in tre
giorni (uno ogni 12 ore);
per il canale PEC effettua fino ad un massimo di 2 tentativi; il
secondo viene eseguito a distanza di:
o almeno un’ora dalla ricezione della notifica di mancata
consegna da parte del gestore PEC del destinatario;
o almeno 40 ore dal primo tentativo, in assenza di notifica da
parte del gestore PEC del destinatario.
Se dopo i tentativi previsti il relativo canale risulta ancora irraggiungibile, il
processo si chiude e il cedente/prestatore potrà verificare lo stato della fattura
attraverso le funzionalità di monitoraggio e di consultazione.
Preciso, per chi non abbia sottomano il documento, che questo si riferisce alle notifiche. La cosa dei tre giorni c’era anche prima, ma non diceva nulla riguardo alla PEC (o meglio, lasciava intendere che funzionasse uguale).
La parte a pagina 16 che avevo citato invece si riferisce alla consegna delle fatture.
Riassumendo:
Per quanto riguarda SDICoop, per le fatture fanno 3 tentativi ogni 4 ore, mentre per le notifiche fanno 6 tentativi ogni 12 ore.
Per quanto riguarda la PEC, per le fatture fanno un singolo tentativo e aspettano per max. 40 ore di ricevere conferma, mentre per le notifiche fanno due tentativi, a distanza di un’ora (se ricevono una notifica di mancata consegna) o 40 ore se non ricevono nulla.
Hanno aggiornato la documentazione SDIFTP alla versione 4.1
Il changelog riporta:
Aggiornamento delle verifiche previste in fase di test di interoperabilità e modifica relativa a crittografia e firma per i supporti di tipo EO
Dal 4 aprile2019, i file di esito (tipologia EO) prodotti dal SdI non saranno più crittografati né firmati.
Tuttavia ora mi sorge un dubbio…
Prima su SDIFTP SDI faceva questa cosa:
Mar 19 19:00:16 fe internal-sftp[17031]: posix-rename old “/DatiDaSdI/EO.XXXXXXXXXXX.2019078.1604.005.xml” new “/DatiDaSdI/EO.XXXXXXXXXXX.2019078.1604.005.xml.p7m.enc”
Prima scriveva un file con l’estensione XML e poi lo rinominava, in questo modo ero certo che solo quando si chiamava .xml.p7m.enc SDI aveva finito di scrivere…
Se implementassi ora la modifica leggendo un .xml in realtà leggerei un .p7m ancora da rinominare… (con conseguenze disastrose)
Ma quando implementeranno la modifica come si potrà essere certi in assenza di un semaforo che il file è chiuso ?
Oppure daranno un altro nome temporaneo e poi faranno il rename ?
Dalle specifiche non è dato saperlo (solite specifiche di m…a)
Immagino che non sia dato saperlo perchè non ci hanno pensato. Probabilmente se ne accorgeranno il 9/4 in seguito a lamentele varie ed il 6/7 introdurranno il rename con la versione 4.1.1
Sai la cosa divertente ?
Già nelle specifiche 4.0 veniva riportata la frase:
A titolo esemplificativo i file di esito corrispondenti ai supporti di tipo “FI” elencati al paragrafo 3.1.4 assumono i seguenti nomi:
-EO.01234567890.2012001.1700.001.xml
-EO.01234567890.2012001.1700.002.xml
Mentre invece erano poi .xml.p7m.enc
Tuttavia nelle specifiche 4.1a pagina 17 si continua a riportare:
DatiDaSdI(con permessi di put e rename):è la directory che ospita i supporti prodotti da SdI (tipologia FO) e i file di esito relativi ai supporti del flusso in ingresso della connessione precedente (tipologia EO). Lo SdI, per evitare che il Nodo acquisisca file non validi in quanto ancora in corso di elaborazione, effettua, una volta terminata la trasmissione e verificato il buon esito, una rename dei file trasferiti sulla directory DatiDaSdI aggiungendo il suffisso .p7m.enc.
Quindi li rinominano ugualmente anche se non sono più p7m.enc ??
anche io ricordavo i 30 minuti ma è probabile che ho fatto confusione tra le tempistiche in fase di test (che era ogni 30 minuti) e quello reale
effettivamente, se è permesso da contratto che il sistema può andare giù 3 volte al mese per un massimo di 8 ore continuative, se fossero 3 tentativi da 30 minuti, non ci sarebbe modo di recuperare le fatture. Mentre se sono 3 tentativi in 12 ore, almeno un invio lo ricevi.
Quindi se ho capito bene loro caricheranno i file con EO.XXXXXXX.xml.run ed al termine dell’upload procederanno ad un rename in EO.XXXXXXX.xml … Corretto ?
Se è così come dici tu mi auguro che il giorno i giorni 4/5 non vi siano situazioni “miste”… ovvero cosa mi devo aspettare ???
no esattamente il contrario… continueranno a nominarli .xml e alla fine come .xml.run
Ma gli ci voleva molto anche ora nominarli come .tmp e poi rinominarli nel modo corretto ?
Gli ho comunque riaperto il ticket chiedendo un aggiornamento ufficiale delle specifiche.
Questa è la risposta che ho ricevuto per email:
La soluzione proposta è la seguente:
Gentile utente,
dal 09/04 i file non saranno più rinominati .xml.p7m.enc bensì .xml.run, quando il file verrà rinominato .run starà a significare che file sarà pronto per essere prelevato dall’apposita cartella.
Per quanto riguarda l’altra “novità” relativa all’ottimizzazione dei supporti in uscita FI voi avete fatto qualcosa o già prima inviavate pacchetti contenenti fatture “eterogenee” ?
Purtroppo non mi piace molto questa cosa… ovvero mandare supporti di fatture che contengono dati di “tizio” e “caio”… proprio no… tanto loro non sbagliano mai… no no…
Io già ora mandavo un supporto con le fatture di tizio e caio…
Solo che lo preparavo ogni 10 minuti…
Ho cambiato lo scheduler e lo preparo ogni 30 minuti… se poi loro non lo prelevano ogni 10 sono cavoli loro. alla prima segnalazione che ricevo li ribalto…
