SdITrasmissioneFile - Esito

Ciao,
sto facendo test di interoperabilità per trasmissione e ricezione fatture.
Non riesco a connettermi al web service SdITrasmissioneFatture che secondo documentazione tecnica prevede il metodo “esito” - tramite il quale sarebbe possibile recuperare, appunto,

l’esito dei file inviati dal trasmittente

(vedi “Istruzioni per il servizio SdI-Coop - Ricezione” a pag. 18).
Nel file di log errori di php trovo il seguente messaggio:

PHP Fatal error: Uncaught Exception: [HTTP:0] Failed to connect to servizi.fatturapa.it port 80 after 21003 ms

Il client viene creato il SdITrasmissioneFile_v2.0.wsdl
mentre la location punta a: http://servizi.fatturapa.it/SdITrasmissioneFile - così come si trova nel documento wsdl citato, al nodo <wsdl:service …>

Proprio la location del servizio web credo sia errata perchè:
a) è in http mentre il client tenta di accedervi in https … ma anche se lo modifico per accedere in http và in errore
b) pare un endpoint NON di test … mentre io sono in fase di test e quindi non credo mi sia consentito l’accesso… tuttavia in tal caso mi attenderei un messaggio di errore “unauthorized”

Qualcuno può aiutarmi nel merito?
L’intento sarebbe quello di chiedere a SdI l’esito di una fattura precedentemente inviata e della quale per qualche motivo potrei aver mancato di ricevere la notifica.

Grazie

SDI usa solo HTTPS, gli URL degli endpoint dentro il WSDL sono http:// ma devi modificarli tu in https:// (o cmq effettuare una connessione in HTTPS alla porta 443)

Ale

1 Mi Piace

Mi sa che stai cercando di usare il web service sbagliato!
Il web service descritto in SdITrasmissioneFile_v2.0.wsdl non serve a inviare le fatture elettroniche, ma per inviare i file “dati fatture transfrontaliere” (che credo sia il vecchio esterometro) e i dati liquidazione IVA.

Per la trasmissione delle fatture elettroniche, devi usare il web service esposto da SdI descritto in SdIRiceviFile_v1.0.wsdl ed esporre tu il web service descritto in TrasmissioneFatture_v1.1.wsdl (per ricevere le notifiche).

Per la ricezione delle fatture elettroniche, tu devi esporre il web service descritto in RicezioneFatture_v1.0.wsdl. Se ricevi fatture per conto della PA, devi anche usare il web service esposto da SdI descritto in SdIRiceviNotifica_v1.0.wsdl che serve per inviare gli esiti (accettazione/rifiuto) da parte della PA.
Quando abbiamo fatto l’accreditamento noi, era necessario poter ricevere fatture PA e inviare gli esiti, anche se non si aveva nessuna intenzione di gestire la fatturazione per le PA. Non so se nel frattempo hanno semplificato la procedura.

1 Mi Piace

@Vladan: grazie per il chiarimento

ma quindi, se per caso il mio web service fosse down quando SdI tenta di inviarmi una fattura - oppure una notifica relativa a fattura che io ho precedentemente trasmesso - esiste un modo per richiederle a posteriori?
Mi spiego meglio:
caso a: SdI mi invia una fattura sul mio web service RicezioneFatture - che per qualche motivo è down. Come posso richiedere le fatture che SdI ha tentato di inviarmi in un certo periodo temporale?
caso b: Io trasmetto una (o più) fatture a SdI e ne ottengo l’Id. Successivamente SdI tenta di inviarmi notifica dell’esito dei controlli eseguiti sulla fattura e dell’inoltro della stessa al destinatario, ma il mio server per qualche motivo è down e non li ricevo… Come posso richiedere a SdI tali notifiche - che non ho potuto ricevere?

Grazie

In caso di problemi di consegna (sia di fatture che di notifiche), SdI esegue più tentativi. Stando all’ultima versione (1.7.1) delle specifiche tecniche:

  • Per le fatture: 4 tentativi, uno ogni 6 ore
  • Per le notifiche: 6 tentativi, uno ogni 12 ore

Esiste inoltre la possibilità, sempre tramite web service, di richiedere il reinoltro sia delle fatture che delle notifiche. Se guardi i due documenti con le “Istruzioni per il servizio SDICoop…” sia Trasmissione che Ricezione, vedrai che c’è una sezione dedicata ai “Servizi massivi di quadratura e reinoltro”.
La quadratura ti permette di avere un elenco delle fatture/notifiche per un dato periodo (che puoi confrontare con quello che hai effettivamente ricevuto) mentre al servizio di reinoltro puoi chiedere di mandarti di nuovo fatture/notifiche specifiche.
Questo servizio soffre di un “piccolo” problema: l’intervallo di date per cui può essere fatta la richiesta è molto specifico (e diverso tra fatture B2B e B2G), nel senso che non puoi fare la richiesta finché non sono passati almeno X giorni e non puoi farla dopo che sono passati più di Y giorni.

1 Mi Piace

Ciao,
@vbato : Grazie.

sì, ho visto che da documentazione tecnica in vers. 3.2 esistono questi metodi il cui “piccolo” problema impedisce però il loro uso per gli scopi indicati. Inoltre, tra gli errori per i quali la richiesta può essere respinta si trova anche [E03] = “Richiesta troppo frequente” - lasciando intendere che devono essere usati solo in casi “sporadici”.

Aggiungo quindi un nuovo interrogativo con l’intento di chiarire ulteriormente la questione sottesa rispetto ai quesiti precedenti:

  • L’interfacciamento con SdI impone di tenere sempre aggiornato nel proprio server un database con
    a) tutte le fatture inviate a SdI, per le quali bisognerà salvare l’identificativoSdI e le notifiche che SdI ci comunica in riferimento ad esse
    b) tutte le fatture ricevute da SdI
    Corretto?
    Grazie.

In sostanza, diventi un postino virtuale che fa da tramite tra Sogei vs Cliente e da Cliente Vs Sogei.

Indubbiamente ti serve una struttura per immagazzinare i dati delle fatture emesse, ricevute e delle notifiche (consegna, scarto, rifiuto) che sono collegate tra loro tramite un id univoco (IndentificativoSDI)

Non andrebbe mai rifiutata la ricezione di una fattura (a volte SDI potrebbe inviare una fattura già inoltrata) e la duplicazione andrebbe gestita internamento.

Se il tuo sistema è down, come ti è stato indicato, hai un certo numero di tentativi per ricevere ugualmente le fatture.

se ne perdi qualcuna (e non ricordo male), puoi organizzare un meccanismo automatizzato (tramite invio di csv) che ogni giorno richiede lo scarico delle fatture che erano state inoltrate almeno 8 giorni prima, oppure farlo 2 volte al mese, indicando 15 giorni di estrazione (ovviamente dovrai gestire eventuali duplicati.
in pratica, il 31 luglio puoi chiedere le fatture di 7 giorni indietro ( dal 24 luglio) e un arco temporale massimo di 15 giorni a posteriori ( 10 luglio)
il 14 agosto chiederai quelle dal 25 luglio al 31 luglio
il 21 agosto dal 14 agosto al 1 agosto
e così via.

altro piccolo problema. Essendo un postino ricevi tutte le fatture con il codice SDI che ti è stato assegnato, quindi anche le fatture destinati a partite iva che non sono in tua gestione (se il destinatario non ha impostato il proprio codice nel proprio cassetto fiscale).

1 Mi Piace

Visto che ci siamo, aggiungo un’altra cosa a cui stare attenti (e a cui è meglio pensare in fase di progettazione).

Normalmente per abbinare le notifiche alle fatture inviate usi l’IdentificativoSdI, ma c’è un problema ricorrente con l’invio delle fatture, che in teoria non dovrebbe succedere, ma succede.
Periodicamente SdI ha dei problemi e le richieste al web service vanno in timeout. In questi casi la fattura che stavi cercando di inviare alle volte viene presa in carico dal sistema e alle volte no. Siccome però non ti arriva mai la risposta, non sai in quale dei due casi ti trovi e non sai nemmeno l’IdentificativoSdI.
Se la fattura è stata effettivamente presa in carico, ti arriveranno le notifiche, ma se ti affidi unicamente all’IdentificativoSdI, non sarai in grado di abbinarle. Essendo che nelle notifiche è presente anche il nome del file della fattura, puoi usare quello per gli abbinamenti (e a quel punto puoi recuperare anche l’identificativo).
Se non ti arriva nessuna notifica entro un giorno o due, vuol dire che la fattura non è mai partita e devi inviarla di nuovo. In alternativa puoi anche provare a inviarla di nuovo comunque e nel caso ti arriveranno degli scarti per fattura duplicata che potrai ignorare.

1 Mi Piace

Sì, questa cosa capita ogni tanto.

Faccio un’osservazione: magari è ovvio e magari no, ma il codice destinatario che dovranno usare gli utenti della tua piattaforma sarà uguale per tutti (puoi generarne di multipli, ma non un numero sufficiente se hai tanti clienti), quindi le fatture in arrivo le dovrai smistare in base alla P.IVA o al C.F.

Da qui il problema di cosa fare se ti arriva una fattura per una P.IVA che non è tra quelle presenti nel tuo sistema. Da quello che ho visto, ci sono diverse casistiche:

  1. Un tuo nuovo cliente che è talmente impaziente di iniziare che ha già usato il codice destinatario prima che tu abbia attivato la sua P.IVA sulla tua piattaforma. Puoi prevenire questo problema non comunicando il codice destinatario fino a quando non l’hai attivata. Oppure ti salvi le fatture e le abbini a posteriori.
  2. Persone legate ad uno dei tuoi clienti (titolare dell’azienda, presidente di un’associazione, ecc.) che pensa di poter usare il codice destinatario per ricevere fatture personali o destinate a partite IVA diverse da quelle che tu hai attivato sul tuo sistema. In questo caso è bene farglielo presente.
  3. Fornitori che usano per sbaglio il tuo codice destinatario per qualcuno che non è tuo cliente. La mia ipotesi è che questo succede quando fanno una fattura ad un tuo cliente usando il tuo codice destinatario (che ti arriva normalmente) e poi la duplicano per fare una fattura simile a qualcun altro (che non è tuo cliente), ma si dimenticano di cambiare il codice destinatario.
  4. Fornitori che in realtà volevano fare una fattura ad un tuo cliente (e quindi il codice destinatario era giusto), ma hanno sbagliato ad inserire la partita IVA. Spesso te ne accorgi perché il campo Denominazione contiene il nome di uno dei tuoi clienti ma la partita IVA non corrisponde. Questo è il caso peggiore, perché è la fattura stessa ad essere sbagliata (e non solo la destinazione a cui è stata consegnata) e va fatta la nota di credito e una nuova fattura corretta. In questo caso conviene che contatti tu il fornitore o il cliente per segnalargli il problema, altrimenti potrebbe passare parecchio tempo prima che se ne accorgano.

assolutamente.
per fortuna non mi è mai capitato il problema dei timeout usando l’SDI in modalità Soap.

per la ricezione il codice SDI per singolo cliente è solo questione di comodità (puoi averne al massimo 100) ma va letto sempre il contenuto della fattura ricevuta facendo un confronto con il codice fiscale/partita iva del cliente.
Specie perché la fattura potrebbe essere spedita senza un codice SDI.
se ad esempio il codice è impostato nel cassetto fiscale, arriverebbero dentro al server senza nessun codice SDI all’interno ma solo la partita iva.

Il codice destinatario a cui SdI sta consegnando la fattura lo trovi sempre nel file dei metadati, e può essere diverso da quello nella fattura (che può anche non esserci) perché, come giustamente hai osservato, ha precedenza il codice impostato nel cassetto fiscale.
Però concordo che bisogna sempre verificare la P.IVA/C.F. perché anche usando codici destinatario multipli, nulla impedisce che un codice destinatario venga usato per una P.IVA diversa da quella prevista.