Tempi di consegna SdI

una notifica di scarto relativa ad una fattura scartata, inviata l’8/2/19 attraverso Aruba, mi è arrivata oggi 22/2/19

In questo report Aruba mi dice che una fattura inviata il 10/1/19 risulta consegnata il 12/2/19.
Non è vero perchè io avevo potuto verificare (dal cassetto fiscale del cessionario/committente) che era stata ricevuta il giorno dopo l’invio. Però evidentemente l’anomalia sta nel fatto che la “ricevuta di consegna” è arrivata tardi (per responsabilità di Sdi) oppure nel fatto che Aruba se ne accorge in notevole ritardo e poi me lo comunica oltre un mese dopo, il 12/2/19.
Boh!!

Dipende da dove prende quella data aruba, se la prende dalla ricevuta di consegna, la colpa è di sdi, se la prende dalla data in cui riceve la ricevuta di consegna la colpa è sempre di SDI, se la prende dal momento in cui elabora la ricevuta di consegna, allora la colpa è di Aruba…

Nel file RC infatti sono riportati i due seguenti valori:
Data Ora Ricezione:2018-12-20T17:11:02.000+01:00
Data Ora Consegna:2018-12-20T18:57:59.000+01:00

Mi auguro che Aruba riporti il dato dentro la RC, il che vuol dire che SDI ci ha messo un mese ad accorgersi che la fattura era stata consegnata, vedendo la data del resto era il periodo in cui SDI aveva dei casini…

@Paolo_Del_Romano
io ho flussi (precisamente 30) che risultano in F&C, comprensivi di notifiche, ma a sistema, la ricevuta non è mai arrivata. Alcuni file hanno un ritardo di 18 giorni… è possibile che tra circa 8 mesi partoriscano :face_with_raised_eyebrow:.
Incrociando tutti i dati pacchetto (FO), con relativi dati DB e relativi file in archivio clienti non risulta nessun file disallineato. Per questo ritengo che sia SDI a dover inviare ancora i pacchetti e non sarebbe la prima volta, purtroppo.

1 Mi Piace

La mia esperienza… è quando inviavo tramite PEC… tutto è stato veloce e tracciato.

Passando dagli intermediari, invece non sai mai quello che succede e di chi è colpa… in quanto non sono state gestite bene tutte le casistiche di file XML. Quindi fate attenzione a dire è colpa dello SDI… il problema è che nei flussi che invia lo SDI agli intermediari non hanno previsto un sistema di CONFERMA di RICEZIONE… quindi la verità mori fanciulla. Ognuno da la colpa a chi torna comodo… lo SdI agli intermediari… e gli intermediari allo SdI.

Io quanto di casi strani… chiamando l’intermediario… abbiamo visto che avevano dei casi non gestiti ed i file venivano messi in quarantena e non inviati ai miei clienti. Risolto il BUG e sono arrivati anche flussi che sembravano persi.

Personalmente da intermediario ti assicuro che traccio anche i respiri di ogni singolo flusso/fattura…
In questi giorni funziona tutto strabene… ma quando non funzionava la colpa era di SDI.
Posso dimostrarlo in qualsiasi sede, dato che ho log su tutti i passaggi.

2 Mi Piace

Infatti… io non ho detto tutti… ma solo di uno… che ha gestito le cose in maniera casalinga… ha fatto un prezzaccio ma siccome poi non rientrava allora ha lasciato tante falle nelle proprie procedure.

Per esempio non aveva gestito la ricezione SENZA PARTITA IVA… ma solo con CODICE FISCALE… Alcune fatture non arrivavano ed erano proprio quelle dove… per errore chi l’ha emesse ha inserito SOLO il CODICE FISCALE, ma essendo corrette lo SdI la recapitate all’intermediario… che non sapevo di chi erano e le ha parcheggiate.

Se uno controllava visivamente vedeva la PARTITA IVA e non leggeva l’etichetta CODICE FISCALE. :frowning:

Quindi dallo Fatture e Corrispettivi si vedeva la fattura e non arrivava dall’intermediario, quando mi hanno passato il caso ho visto che riportava solo CODICE FISCALE, ho chiamato e trovato l’inghippo.

In Italia ci sono molti sviluppatori e software house che farebbero bene a fare una ristrutturazione interna sui metodi di sviluppo e test. Speriamo nel futuro e che chi ha sbagliato abbia fatto esperienza degli errori ed ORRORI commessi.

Buon lavoro

@Andrea_Giusti
Confermo quanto detto da @Romolo_Manfredini, monitoro con i log tutto, le operazioni effettuate sulle directory, contenuto dei pacchetti inviati, mirroring dei dati etc… ed inoltre ho un sistema parallelo che verifica sempre i file presenti con match in DB… se questi dati mancanti fossero stati presenti ti assicuro li avrei scovati… ma tutto ciò che ho è perfettamente allineato.
Inoltre è già successo, che dopo aver fornito informazioni sui file mancanti, lo sdi li abbia inviati. Questa volta fatica a rispondere!
Poi se SDI, mi fornisse un file, di qualunque tipo, che indichi in quale pacchetto sono presenti i flussi, sarei ancora più contento ed il sistema spenderebbe meno risorse per effettuare calcoli ridondanti.
Già l’ho detto in precedenza, probabilmente il loro sistema è così articolato da non riuscire a fare concatenazioni di tabelle e restituire Utente->supporto->flusso->stato :tipping_hand_man:

1 Mi Piace

Sono perfettamente d’accordo con quanto dice @leonardo72 … Se poi in privato mi scrivete (@leonardo72 e @Romolo_Manfredini) per quale azienda lavorate almeno so cosa proporre hai nuovi clienti. :+1:

Basterebbe una file di conferma.

Buon lavoro

Dopo essere passato al lato oscuro dell’SDI, mi sentirei di esprimere un giudizio circa i due canali di trasmissione. SDICoop è mediamente più veloce per pacchetti da meno di 20 documenti e pressochè realtime in caso di trasmissione verso il nodo stesso, anche perchè lavoro con il flusso semplificato.
Ciononostante devo continuare a spezzare lance a favore di SDIFTP: con SDICOOP i file mi vengano trasmessi in chiaro ed io non posso essere sicuro della provenienza: in linea di principio si potrebbe rubare o contraffarre il certificato client del SDI ed inviare documenti. Io non avrei modo immediato di accorgermene.
In SDIFTP invece, vengo contattato da un server di cui riconosco la chiave, il quale mi fornisce un file cifrato con la mia chiave pubblica e firmato con la sua chiave privata. Non capisco perchè non si sia deciso di compiere, almeno quest’ultima parte di cifratura e firma anche per il canale SDICoop.

Ragionando così, vale la stessa cosa per SDIFTP: in linea di principio si potrebbe rubare la chiave che SDI usa per cifrare il file.

La vera differenza sta nel fatto che con SDIFTP hai un file firmato, che puoi a posteriori dimostrare essere stato firmato con quella chiave, mentre con SDICoop la verifica del certificato viene fatta durante la connessione SSL, ma non ti rimane niente per dimostrarlo a posteriori.

La soluzione peraltro sarebbe stata semplice: bastava che SdI firmasse il file metadati allegato alla fattura (che ne contiene il hash), cosa che per altro fa già per gli altri messaggi di notifica.

La chiave con cui cifra è la mia chiave pubblica quindi non deve nemmeno rubarla. :grimacing:
La differenza sta nel fatto che con SDIFTP ho necessità di impossessarmi di
1-chiave privata ssh di SDI
2-chiave privata di firma di SDI.

Con SDICOOP mi basta il certificato client di SDI

Ma anche per SDICoop c’e’ uno scambio di certificati no ? Se non mi ricordo male come ho configurato il sistema, io accetto solo connessioni che mi presentano un certificato valido e lo stesso SDI vuole un certificato valido quando rispondo.

Sì certamente. Con SDIFTP però, oltre allo scambio di chiavi ssh hai la cifratura e firma del contenuto con crittografia a chiave asimmetrica.

Ma SOAP è su https quindi pure quello è uno scambio crittografato… Diciamo che il certificato fa entrambe le cose…

sì basta rubare quel certificato, senza che il possessore se ne accorga. e poi rubare uno degli ip o san associati

Perché? SDICOOP effettua le chiamate da un solo ip? Da specifiche non mi pare.

Ragazzi, secondo voi perchè ho trovato questo file all’interno di un un supporto?
.IT0126XXXXXXX_0XXXXX_RC_002.xml.swp
Il file è generato da vim(sulle mie macchine è installato solo nano) ed è presente nel supporto di origine quindi arriva dallo SDI. :face_with_raised_eyebrow:

Ecco perchè SDI è lento: le ricevute vengono scritte a mano con vim!
Ahahahah scusa se rido ma questa è un’altra da bestiario :joy:

Ma guarda che ho pensato la stessa cosa… :rofl:

1 Mi Piace