Se io chiamo il metodo “InvioDE815” con un XML firmato e verificato, il sistema mi risponde con un tipo di dato “Risposta” così composto:
-IUT: lo IUT dato dal sistema
-codiceEsito: “20”
-messaggio esito: “Acquisito a sistema”
-data: vuoto
-data registrazione: “la data di invio”
Segnandomi lo IUT assegnatomi e invocando il metodo “recuperaEsito” passandogli lo IUT appena ottenuto, ottengo sempre un tipo “Risposta” cosi strutturato:
-IUT: sempre lo stesso
-codiceEsito: null
-messaggioEsito: null
-data: null
-data registrazione: “01/01/0001 00:00:00”
Non credo di sbagliare nulla, anche perchè il sistema non mi restituisce nessun errore, e la comunicazione avviene in maniera corretta…
Risposta.recuperaesitoReturnesito.IUT
Risposta.recuperaesitoReturn.esito.codice etc.
Riesci a salvare direttamente la risposta su file senza passare per “risposta”?
Inoltre puoi testarlo anche da browser (vedi il pdf DocumentazioneMovimentazioniDAS pag. 13)
La prova indicata nella documentazione funziona solo per l’ambiente reale, per quello di prova, nonostante abbia i certificati (sia server che client) non va… Il WSDL “InteropService” ha un solo metodo(“recuperaEsito”), che restituisce questo tipo di dato “Risposta”…
Sono andato in debug ma il server risponde come ho indicato prima, con NULL nei vari campi che dovrebbero essere pieni… Ho anche provato ad usare curl da console, ma restituisce sempre “Forbidden”, nonostante indichi sia il certificato client che server…
Ho il sospetto che dia problemi l’ambiente di test…
I campi da te indicati, che in teoria dovrebbero essere pieni, a me sono NULL… Ci fosse almeno un errore, invece sembra che vada tutto bene…
Aggiornamento. Mi sono collegato sul sito delle dogane usando lo SPID del cliente, ed in ambiente di prova vedo solo i das RICEVUTI dal mio cliente (delle prove di invio fatte da suoi fornitori)… Di quelli INVIATI da me (e che, ripeto, sono stati correttamente “acquisiti a sistema”, nemmeno l’ombra)… C’è qualcosa che non torna (vi allego la risposta al lancio di cUrl come indicato nel PDF delle dogane)…
Ennesimo aggiornamento: copiando il seguente link nel browser “https://interoptest.adm.gov.it/InteropRServiceWeb/services/InteropRService/selezionaStato/20201001M5000685758”, il sistema richiede il certificato dell’ambiente di test. Una volta fornito, mi risponde con 198. Quindi il servizio InteropRServiceWeb funziona. Ora, utilizzando lo stesso IUT ma invocando InteropServiceWeb, non dovrebbe funzionare? Magari qualcuno che ci è passato prima di me sa come risolvere (io infatti mi ero fermato al solo invio, senza recupero esito)…
Anche a me funziona da browser. Il problema si pone quando provo ad invocarlo “da codice”… Dovrebbe restituire i campi pieni, ma li da vuoti…
Comunque ok, aspetto il link… grazie
Comunque se invoco il metodo RecuperaEsito da SoapUI, funziona, restituendomi la stringa in “data” che poi sarebbe il PDF.
Peccato che da codice non vada, nonostante l’impostazione del canale di comunicazione sia fatta esattamente nello stesso modo di quella del canale per l’invio…
Beh, se ti funziona da browser inutile che ti mando il link (lo hai già).
Se da codice non ti funziona (non so cosa usi) potrebbe essere un problema di analisi del wsdl
Si. Uso Windev 25. Se ti può aiutare ti incollo qui il mio codice (iut è la stringa iut che devo recuperare):
r is InteropService.recuperaEsitoResponse //InteropService è il wsdl importato
q is InteropService.recuperaEsito
q.iut = iut
HTTPCertificate(CertTrns_Name) //CertTrns_Name è in nome del cert di trasmissione
r = InteropService.recuperaEsito(q)
//a questo punto in 'r.recuperaEsitoReturn ho i dati di esito
info(r.recuperaEsitoReturn.esito.messaggio) //as esempio
Funziona, finalmente! Anche se ho dovuto creare una classe a partire dal WSDL e usare quella per invocare i vari metodi.
Come ultimo chiarimento, nel campo “Data”, in base all’esito (nel mio caso 198) dovrebbe esserci, da quanto si legge nel documento rilasciato dalle dogane, un file sigillato elettronicamente. Ora, per chi lo ha già gestito, che tipo di file è? Un PDF? Un file di testo?
Questo errore lo ottieni qualora la verifica del tuo XML, basato sull’XSD fornito dalle Dogane, presenta degli errori. (ad esempio l’XSD si aspetta un codice fiscale da 16 cifre ma tu gli passi un campo da 10… Inoltre c’è anche il controllo sulla coerenza, sempre basandomi sull’esempio del Codice Fiscale, l’XSD verifica che i primi 6 caratteri siano lettere, poi 2 numeri, poi una lettera e così via)… Controlla anche maiuscole/minuscole, alcuni campi sono OBBLIGATORIAMENTE minuscoli (come la lingua)… Se apri l’XSD con un editor di testo, puoi tranquillamente verificare ciascun campo come deve essere affinchè la verifica passi…
Buonasera a tutti, inviando i DAS in ambiente di test, ottengo sempre l’errore A004, “I dati del messaggio non si riferiscono al Dichiarante della trasmissione”.
Ho il sospetto che questo errore sia dovuto ad una differenza tra il codice fiscale del dichiarante (che è la persona delegata dalla ditta ad inviare i DAS) e l’intestatario della firma con la quale l’XML viene firmato (infatti sono due persone diverse).
Qualcuno si è già trovato di fronte a questo errore e mi può dare qualche informazione in più?
I due certificati (almeno in prova) sono indipendenti. Trasmette Pippo ma firma Pluto e va benissimo.
Nella trasmissione, oltre al XML, devi indicare il “dichiarante”. Il tuo certificato di trasmissione dovrebbe essere (come file) -EXT.p12 e il tuo dichiarante è “partitaIvaDitta”
In pratica per generare il certificato, ho nominato come gestore della ditta il titolare della stessa, e poi la ditta ha delegato tale persona fisica come autorizzato ad inviare i documenti.
Il problema è che il campo “DeclaratorIdentifyCode” vuole un codice fiscale, e se inserisco quello del gestore nominato, mi dà errore A004. Se invece ci metto la P.IVA, fallisce la verifica XSD perchè appunto in quel campo il sistema si aspetta un dato in formato CF(AAABBB00A000A000A) mentre io gli passo una P.IVA… Ho aperto un ticket con SOGEI, e mi hanno dato la tua stessa risposta… Vediamo che dicono…
