Sviluppatore in difficoltà con l'integrazione di SDICoop

Buonasera a tutti!
In azienda mi è stato chiesto di inviare le fatture XML da un nostro gestionale custom all’agenzia delle entrate.

Qualcuno mi potrebbe cortesemente spiegare, una volta che ho un XML valido, come inviarlo senza utilizzare il canale FTP?
Sto usando per il gestionale .NET Core 3.1, ma probabilmente dovrò fare questo procedimento anche per altri gestionali in NodeJS.

So che se non uso FTP posso farlo tramite SOAP (che non conosco come protocollo ma posso studiarlo), ma qual’è il giro che devo gestire?

Grazie

Luigi

Una risposta esaustiva alla tua domanda sarebbe molto lunga. Sarebbe effettivamente molto utile se qualcuno dedicasse del tempo a scrivere una guida su come si implementa un canale di trasmissione per la fatturazione elettronica.

Quello che posso fare io è indirizzarti verso la documentazione ufficiale e segnalarti alcune cose a cui stare attento.

Per prima cosa, è da notare che la documentazione è sparpagliata in tre posti diversi:

Il primo link contiene la documentazione tecnica allegata alla legge che aveva originariamente introdotto la fatturazione elettronica verso la PA.
Il secondo link contiene la documentazione tecnica del Sistema di Interscambio.
Il terzo link contiene la documentazione tecnica allegata alla legge che ha introdotto la fatturazione elettronica B2B.
Da notare che le specifiche tecniche al terzo link integrano, ma non sostituiscono, quelle del primo. Data la notevole sovrapposizione tra i documenti, non capisco perché non li unifichino. Immagino ci siano questioni legali dovute al fatto che si tratta di allegati a leggi diverse.

In particolare i documenti che dovresti leggere sono:

  • Specifiche tecniche del formato della FatturaPA versione 1.3.2 (dal primo link)
  • Allegato A - Specifiche tecniche vers 1.7.1 (dal terzo link)
  • Specifiche tecniche relative al Sistema di Interscambio versione 1.8.2 (dal secondo link)
  • Istruzioni per il servizio SDICoop - Trasmissione versione 3.2 (dal secondo o terzo link)
  • Istruzioni per il servizio SDICoop - Ricezione versione 3.2 (dal secondo o terzo link)

Gli ultimi due documenti contengono le specifiche dei web service SOAP con cui ti dovrai interfacciare.
Non hai spiegato se devi solo inviare le fatture o anche riceverle, ma anche se ti limiti all’invio, devi comunque poter ricevere le notifiche relative alle fatture inviate, quindi dovrai in ogni caso avere un server che espone dei web service SOAP che verranno richiamati dal SdI.

I web service SOAP (sia client che server) sono relativamente facili da implementare in .NET Framework partendo dai file .wsdl. Nel caso di .NET Core le cose sono più complicate. Il client è fattibile con le stesso classi (ma configurandolo da codice invece che da file .config), mentre implementare un server non è possibile senza librerie esterne. In aggiunta a questo c’è il problema che il SdI usa l’estensione MTOM di SOAP che non è supportata in .NET Core.
Noi abbiamo “risolto” il problema facendo passare il tutto attraverso un proxy implementato in .NET Framework.

Altra cosa a cui stare attenti è la questione dei certificati SSL. Il tuo client che si collega al SdI dovrà autenticarsi con un certificato client che ti firmerà il SdI in fase di accreditamento del canale. Analogamente il tuo server dovrà esporre un certificato server firmato dal SdI. Purtroppo la loro CA non è universalmente riconosciuta, quindi il certificato non sarà ritenuto valido dai browser. Il consiglio quindi è di dedicare un indirizzo IP e un hostname alla comunicazione con il SdI e usare un indirizzo diverso per collegamento da browser/api.

La documentazione (e i siti) spiegano come fare per accreditarsi, ma la versione breve è che dovrai compilare una richiesta (e firmarla digitalmente) indicando gli url degli endpoint SOAP. Da notare che dovrai avere sia gli endpoint di produzione che di test.
Infatti, per poter attivare il canale, dovrai prima superare dei test. Credo che ultimamente li abbiano semplificati, ma mi ricordo che non erano semplicissimi, soprattutto per quanto riguarda la ricezione (perché era necessario gestire anche la fatturazione PA, che per le aziende non serve).

Spero che queste informazioni ti siano utili per partire. Per problemi specifici puoi provare a cercare qui sul forum perché la maggior parte dei problemi è già stata affrontata da qualcuno.

1 Mi Piace

Devo solamente inviare delle fatture, non riceverle.
.NET Framework purtroppo non potrò utilizzarlo in quanto i server sono Ubuntu, non abbiamo un windows server con IIS.
Sono d’accordo con la tua soluzione del proxy, ma appunto non è possibile usare .NET Framework, potrei farlo magari in un’altro linguaggio come NodeJS oppure PHP o Python, quale mi consigli (se conosci qualche libreria e/o esempio da vedere)?

I test che fanno che tipi di test sono? Solamente di avvenuta connessione oppure bisogna gestire un payload e restituire una risposta per loro corretta?

Detto ciò, ti ringrazio moltissimo per la risposta che mi hai dato, adesso sono su altri progetti ma quando ci ritornerò sopra spero di saltarci fuori…

L’ultima spiaggia è quella di inviare gli xml con la pec, ma al cliente piacerebbe evitare questo approccio

Su quale linguaggio usare per implementare il proxy non saprei dirti. Mi pare ci fosse una libreria open source in php. SOAP, ed in particolare le estensioni tipo MTOM, sono considerati “enterprise” e quindi li trovi in .NET (Framework) e Java, ma raramente nelle librerie standard di altri linguaggi. Persino la Microsoft ha rinunciato ad implementarli in .NET Core.

Non so se è cambiato qualcosa, ma i test di interoperabilità che chiedevano di fare coprivano tutte le casistiche. In pratica devi inviare delle fatture (sia corrette che errate) e ricevere le corrispondenti notifiche (ricevuta consegna, mancata consegna, notifica di scarto, notifica di esito PA, ecc.).
Volendo è possibile superare i test (almeno quelli del servizio trasmissione) senza implementare veramente il client e il server SOAP. Per l’invio puoi usare qualche tool per i test dei web service (o costruisci a mano il payload), mentre al server puoi far restituire una risposta fissa, dato che i metodi che ricevono le notifiche non restituiscono dati. Ovviamente sarebbe meglio fare i test avendo implementato il protocollo SOAP, così sei sicuro che funzioni.
Altro avvertimento: una volta che hai completato i test e ti attivano il canale, l’ambiente di test viene disattivato. Se vuoi continuare ad usarlo devi fare richiesta perché te lo riattivino.

Un’alternativa a tutto questo è utilizzare delle API REST a pagamento, messe a disposizione da aziende che sono già accreditate con il SdI. So che per esempio Aruba offre delle API, ma ci sono svariate aziende più o meno grandi che lo fanno.

1 Mi Piace

Ciao,
per il nostro gestionale noi ci siamo appoggiati come intermediario a Trust Technologies (società del gruppo TIM).
Quando nel 2017 ci stavamo preparando per la gestione della FE abbiamo provato a contattare:

  • Trust Technologies
  • Aruba
  • Team System

Indovina chi ha fornito la risposta più convincente, a tempo di record, ovvero in poche ore, tra l’altro allegando direttamente alla e-mail il manuale di integrazione ?

Esatto, Trust Technologies!

Abbiamo iniziato a studiare il manuale ed abbiamo verificato che in effetti l’implementazione era piuttosto semplice, con scambio di dati in formato json.

Ci sono stati forniti immediatamente i contatti telefonici (cellulari diretti!) dei responsabili del progetto, tutte persone veramente preparate e sempre “sul pezzo” che ci sono state molto vicine durante le fasi iniziali dello sviluppo (e anche dopo!).

Tutto il personale con il quale abbiamo dovuto interloquire si è sempre rivelato molto, molto disponibile, professionale ed estremamente efficiente, nonché rapido nelle risposte, ed in ultimo, cosa niente affatto spiacevole, anche simpatico.

Mai avuto un livello di supporto così diretto e veramente risolutivo anche per ogni piccola questione, anche in pieno lockdown non abbiamo avuto alcun problema ad ottenere dal supporto la solita tempestività ed efficienza.

C’è anche un ambiente di test, ma noi abbiamo fatto di più, ovvero ci siamo costruiti un emulatore delle procedure dal loro lato per effettuare tutte le prove del caso, compresa la ricezione delle FE, quest’ultima cosa un po’ più macchinosa utilizzando quanto da loro messo a disposizione per gli esperimenti.

Se ti affidi ad un servizio come il loro eviti tutte le complicazioni dello sviluppo della comunicazione SOAP con SDI, che non è roba di poco conto!

Marco

Al momento il servizio più completo ed economico per utilizzo Api è sicuramente Aruba. (900 primo anno e 600 dal secondo)+iva anche se c’è la limitazione di 12 fatture al minuto che si possono inviare o scaricare.
Altrimenti un altro partner molto buono è MySond.

Negli ultimi anni ho implementato l’invio e ricezione da diversi partner:
Aruba 4/5 (API REST)
Mysond 4/5 (API REST)
Fatturapa 3/5 (API Azure)
FatturaPro teamsystem 3/5 (API REST)
DigitalHub Zucchetti 2/5 ( dopo 90gg non puoi scaricare le fatture e protocollo SOAP)

Buongiorno, aggiungo alla lista, in quanto diretto interessato A-Cube API

Ciao, consiglio di valutare le API di fatturapertutti Le API di fatturapertutti - Fattura Per Tutti - La Fattura Elettronica Gratis

Ciao nuovamente!
Vi aggiorno:
Ho messo in piedi questo emulatore: GitHub - italia/fatturapa-testsdi: Sistema d'Interscambio di test (con alcune modifiche mie per farlo partire con Docker + supporto a MTOM)

Come è stato suggerito uso un proxy tra il gestionale e questo emulatore.
Riesco con successo a inviare la fattura all’SdI

Adesso con Postman sto provando a inviarmi una notifica (AttestazioneTrasmissioneFattura) ma ricevo un errore.

Richiesta: view-source:https://www.fatturapa.gov.it/export/documenti/messaggi/v1.0/IT01234567890_11111_AT_001.xml

Risposta:

Il codice del server è il seguente:

A parte che il foreach non stampa nulla, ma, io di php sono un niubbo e probabilmente sto sbagliando qualcosa.

Quello che mi stampa la console di Docker:

UPDATE del 23/09/2022:

Ho trovato un xml della notifica di AttestazioneTrasmissioneFattura che a quanto pare funziona, perchè non ricevo nessun errore, è il seguente:

Qualcuno riesce a spiegarmi come mai questo xml funziona e l’altro no?

Arrivato a questo punto, posso cominciare a richiedere l’accreditamento?