File xml Agenzia delle Entrate

di il
90 risposte

90 Risposte - Pagina 4

  • Re: File xml Agenzia delle Entrate

    Paolo64 ha scritto:


    Potresti provarlo anche tu ...

    Firmando l'xml con questo codice non ho più l'errore 406 ma passa a errore 415.
    Però rileggendo meglio la pagina "Utilizzare Api Rest" dell'ADE
    dice:

    Solamente come esempio per l'apposizione della firma viene messa a disposizione l'applicazione java contenuta nel file "EsempioFirmaDispositivo.zip".

    Per utilizzarla basta modificare le variabili seguenti (righe da 41 a 44 del file) con i valori appropriati:

    String p12file = "path_certificato_di_firma.p12";
    String p12pass = "password del certificato di firma";
    String infile = "path_file_da_firmare.xml";
    String signedfile = "path_file_firmato.xml".

    secondo voi quale sarebbe la "password del certificato di firma" ???
    visto anche che nella generazione del csr la password non va specificata ??
    E' il contenuto del file .key ?

    Paolo
    Non c'è nessuna password da indicare.
    In merito alla verifica di validità dei file xml io una grossa mano l'ho avuta da XMLSpy, c'è la versione trial che si può utilizzare per 30 giorni se non ricordo male, poi è da acquistare.
    Caricate il file, firmato o no, e validatelo con lo schema, vi segnalerà le anomalie. Io ho fatto così ed ho risolto con tutti i file xml, inclusi quelli dei corrispettivi.
    Ciao
  • Re: File xml Agenzia delle Entrate

    geremiah ha scritto:


    Paolo64 ha scritto:


    Potresti provarlo anche tu ...

    Firmando l'xml con questo codice non ho più l'errore 406 ma passa a errore 415.
    Però rileggendo meglio la pagina "Utilizzare Api Rest" dell'ADE
    dice:

    Solamente come esempio per l'apposizione della firma viene messa a disposizione l'applicazione java contenuta nel file "EsempioFirmaDispositivo.zip".

    Per utilizzarla basta modificare le variabili seguenti (righe da 41 a 44 del file) con i valori appropriati:

    String p12file = "path_certificato_di_firma.p12";
    String p12pass = "password del certificato di firma";
    String infile = "path_file_da_firmare.xml";
    String signedfile = "path_file_firmato.xml".

    secondo voi quale sarebbe la "password del certificato di firma" ???
    visto anche che nella generazione del csr la password non va specificata ??
    E' il contenuto del file .key ?

    Paolo
    Non c'è nessuna password da indicare.
    In merito alla verifica di validità dei file xml io una grossa mano l'ho avuta da XMLSpy, c'è la versione trial che si può utilizzare per 30 giorni se non ricordo male, poi è da acquistare.
    Caricate il file, firmato o no, e validatelo con lo schema, vi segnalerà le anomalie. Io ho fatto così ed ho risolto con tutti i file xml, inclusi quelli dei corrispettivi.
    Ciao
    Si in effetti hai ragione, non ci va nessuna password, perchè non avevo specificato nessuna password nella conversione da DER a PEM e da PEM a PFX 12. Sto provando con xmlspy. Caricando lo schema sull'xml firmato, riformatta la disposizione del testo aggiungendo spazi. Però poi il digest non torna più.... e il server risponde 406 >XML con Firma non integra<.

    Caricando invece xml non firmato, riformattandolo con xmlspy e firmandolo in java sempre errore 415
  • Re: File xml Agenzia delle Entrate

    Sembra un problema di generazione del digest o della firma
  • Re: File xml Agenzia delle Entrate

    Paolo64 ha scritto:



    Gine: si infatti la riga che uso fa terminale è
    curl -v -k --header 'Content-Type: application/xml' "https://apid-ivaservizi.agenziaentrate.gov.it/v1/dispositivi/" --data-binary @RichiestaCertificatoDispositivo_Firmato.xml --verbose

    Però ho un dubbio: mettiamo che xml sia corretto, questo comando curl scarica poi il file certificatodispositivo.xml direttamente o bisogna fare qualcosa altro?
    In teoria non ti torna subito il certificatodispositivo.xml. Secondo specifica che trovi nel file ApiRestDispositivi.pdf, alla chiamata /dispositivi puo' tornare una serie di valori. Ad esempio puo' tornare 202, ovvero il file sta venendo processato.

    C'e' anche scritto che va fatta la stessa chiamata piu' volte fino al ritorno di un 201 e:
    Restituisce un file xml firmato con il certificato del sistema conforme all'elemento `EsitoRichiestaCertificatoDispositivo` dello schema `CorrispettiviMessaggiType_1.0.xsd` contenente l'identificativo operazione e il certificato X.509
    Io al momento sono riuscito a far andare il coso in java che AE ha messo a disposizione, ho da circa 20 minuti un 202.

    Spero di ottenere un 201 presto per poter cosi' esser sicuro di come si firmano le cose(cosa va dove e come ci va).

    Non so pero', e non c'e' scritto da nessuna parte, in che tempi rispondano. Non mi sembra normale che occorre attendere per 20 min e piu'

    Forse dovro' chiamare l'assistenza per capire cosa sta succedendo.

    Se risolvo ti elenco i progressi. Poi mi dovro' mettere a far funzionare questa cosa in js.
  • Re: File xml Agenzia delle Entrate

    geremiah ha scritto:


    Non uso java se è questo che vuoi sapere.
    Che linguaggio di programmazione usi? C#? php? perl? Quale libreria?

    Magari leggendo le specifiche ne capisco qualcosa in piu'. Ad esempio il file java dell'AE a me e' servito a fare qualche passo in avanti.
  • Re: File xml Agenzia delle Entrate

    geremiah ha scritto:


    Sembra un problema di generazione del digest o della firma
    415 e' il content type sbagliato. E' scritto nelle specifiche. Non c'entra nulla il file xml che stai caricando, ne le firme che applichi o i digest.
  • Re: File xml Agenzia delle Entrate

    gine ha scritto:


    Io al momento sono riuscito a far andare il coso in java che AE ha messo a disposizione, ho da circa 20 minuti un 202.

    Spero di ottenere un 201 presto per poter cosi' esser sicuro di come si firmano le cose(cosa va dove e come ci va).

    Non so pero', e non c'e' scritto da nessuna parte, in che tempi rispondano. Non mi sembra normale che occorre attendere per 20 min e piu'

    Forse dovro' chiamare l'assistenza per capire cosa sta succedendo.

    Se risolvo ti elenco i progressi. Poi mi dovro' mettere a far funzionare questa cosa in js.
    A causa dell'errore 202 ho aperto due ticket nel giro di una settimana con Sogei e ci ho pure parlato.
    Nella prima occasione, 1 febbraio, mi è stato detto che avevano problemi sui loro sistemi e tutte le richieste ( CSR ) erano andate perse.
    Si sarebbe dovuto generare una nuova CSR e inoltrare nuovamente la richiesta per avere un nuovo certificato, e così ho fatto.
    Il problema però non si è risolto ma si è riproposto, e, di conseguenza, ho chiamato nuovamente Sogei dove ho aperto un nuovo ticket.
    Ieri pomeriggio ho parlato nuovamente con Sogei, dove hanno verificato con il codice Imei del telefono che tentavo di censire ed anche i loro log.
    La sorpresa è stata che il telefono risulta censito addirittura dal 21 gennaio che è domenica, data plausibile perchè il sabato sera precedente ero riuscito finalmente a risolvere i problema dell'errore 406 che anch'io avevo.
    Quindi la risposta dell'API di Sogei, in caso di dispositivo censito è errata. Da istruzioni dovrebbe rispondere 409 e restituire l'XML con il certificato, invece pare che inizi un eterno loop con codice 202 non restituisca mai il certificato. Dai log di Sogei risulta a loro un codice 00004 della codelist, ovvero, dispositivo già censito. Al momento sono in attesa di risposta da parte di Sogei.
    Vi consiglio di provare a chiamare anche voi ed aprire il ticket per l'errore 202, magari questo li spinge a risolvere il problema.
  • Re: File xml Agenzia delle Entrate

    gine ha scritto:


    geremiah ha scritto:


    Non uso java se è questo che vuoi sapere.
    Che linguaggio di programmazione usi? C#? php? perl? Quale libreria?

    Magari leggendo le specifiche ne capisco qualcosa in piu'. Ad esempio il file java dell'AE a me e' servito a fare qualche passo in avanti.
    Object Pascal.
  • Re: File xml Agenzia delle Entrate

    geremiah ha scritto:


    A causa dell'errore 202 ho aperto due ticket nel giro di una settimana con Sogei e ci ho pure parlato.
    Nella prima occasione, 1 febbraio, mi è stato detto che avevano problemi sui loro sistemi e tutte le richieste ( CSR ) erano andate perse.
    Si sarebbe dovuto generare una nuova CSR e inoltrare nuovamente la richiesta per avere un nuovo certificato, e così ho fatto.
    Il problema però non si è risolto ma si è riproposto, e, di conseguenza, ho chiamato nuovamente Sogei dove ho aperto un nuovo ticket.
    Ieri pomeriggio ho parlato nuovamente con Sogei, dove hanno verificato con il codice Imei del telefono che tentavo di censire ed anche i loro log.
    La sorpresa è stata che il telefono risulta censito addirittura dal 21 gennaio che è domenica, data plausibile perchè il sabato sera precedente ero riuscito finalmente a risolvere i problema dell'errore 406 che anch'io avevo.
    Quindi la risposta dell'API di Sogei, in caso di dispositivo censito è errata. Da istruzioni dovrebbe rispondere 409 e restituire l'XML con il certificato, invece pare che inizi un eterno loop con codice 202 non restituisca mai il certificato. Dai log di Sogei risulta a loro un codice 00004 della codelist, ovvero, dispositivo già censito. Al momento sono in attesa di risposta da parte di Sogei.
    Vi consiglio di provare a chiamare anche voi ed aprire il ticket per l'errore 202, magari questo li spinge a risolvere il problema.
    Nel CN del CSR dispositivo si deve mettere l'IMEI del dispositivo se presente o altrimenti un codice composto dalla stringa 'AD' partita_iva_gestore e indice_univoco_per_device(6 cifre). Io sto usando quest'ultimo, quindi posso provare a generare un altro indice che per ora per me era 000001, ma per il quale avevo fallito con un po' di 406.

    Provo ad usare 000002 e vedere se la procedura va in porto.

    Nel frattempo vorrei provare anche a chiamare l'assistenza o aprire un ticket, c'è un sito? mi indirizzi verso il posto giusto dove trovare numero di telefono?
  • Re: File xml Agenzia delle Entrate

    gine ha scritto:


    geremiah ha scritto:


    A causa dell'errore 202 ho aperto due ticket nel giro di una settimana con Sogei e ci ho pure parlato.
    Nella prima occasione, 1 febbraio, mi è stato detto che avevano problemi sui loro sistemi e tutte le richieste ( CSR ) erano andate perse.
    Si sarebbe dovuto generare una nuova CSR e inoltrare nuovamente la richiesta per avere un nuovo certificato, e così ho fatto.
    Il problema però non si è risolto ma si è riproposto, e, di conseguenza, ho chiamato nuovamente Sogei dove ho aperto un nuovo ticket.
    Ieri pomeriggio ho parlato nuovamente con Sogei, dove hanno verificato con il codice Imei del telefono che tentavo di censire ed anche i loro log.
    La sorpresa è stata che il telefono risulta censito addirittura dal 21 gennaio che è domenica, data plausibile perchè il sabato sera precedente ero riuscito finalmente a risolvere i problema dell'errore 406 che anch'io avevo.
    Quindi la risposta dell'API di Sogei, in caso di dispositivo censito è errata. Da istruzioni dovrebbe rispondere 409 e restituire l'XML con il certificato, invece pare che inizi un eterno loop con codice 202 non restituisca mai il certificato. Dai log di Sogei risulta a loro un codice 00004 della codelist, ovvero, dispositivo già censito. Al momento sono in attesa di risposta da parte di Sogei.
    Vi consiglio di provare a chiamare anche voi ed aprire il ticket per l'errore 202, magari questo li spinge a risolvere il problema.
    Nel CN del CSR dispositivo si deve mettere l'IMEI del dispositivo se presente o altrimenti un codice composto dalla stringa 'AD' partita_iva_gestore e indice_univoco_per_device(6 cifre). Io sto usando quest'ultimo, quindi posso provare a generare un altro indice che per ora per me era 000001, ma per il quale avevo fallito con un po' di 406.

    Provo ad usare 000002 e vedere se la procedura va in porto.

    Nel frattempo vorrei provare anche a chiamare l'assistenza o aprire un ticket, c'è un sito? mi indirizzi verso il posto giusto dove trovare numero di telefono?
    800 299 940 è il numero della fatturazione elettronica ma forniscono assistenza anche sui corrispettivi, anche se, quando sono problemi tecnici, girano la cosa a Sogei.
    Ieri ho parlato di nuovo con Sogei e mi è stato confermato che quando il dispositivo è già censito, e, come è successo anche a me, nelle varie fasi dello sviluppo è andata persa la chiave, per fare disattivare il dispositivo, bisogna contattare l'Agenzia delle Entrate.
    Anch'io ho generato un dispositivo con il codice alternativo, e, al momento, è quello che ho funzionante.
    Ciao.
  • Re: File xml Agenzia delle Entrate

    Oggi mi ha chiamato un tizio Sogei perchè avevo aperto un ticket di secondo livello. Mi ha detto che quello che vede è tutto corretto (xml richiesta dispositivo, firma). In effetti il mio dispositivo mobile risulta censito e attivato già da tempo. Il fatto che non riesca a ricevere il certificatodispositivo, secondo lui dipende dalla configurazione di CURL, oppure che il certificato viene scaricato in una directory temporanea che io non vedo . Il fatto che io riceva un errore 415 a lui non risulta. Boh ... a me sembra un loro bug. Cioè se il certificato è già generato e lo ri-richiedo, il loro sistema va in tilt. Lui dice che se il certificato è già creato, la chiamata curl dovrebbe scaricarne un altra copia. Copio sotto il log trasmissione ... E' scritto chiaramente 415 Processed. Voi cosa ne dite ??
    
    C:\Users\PAOLO2\Desktop\VendingMachine>curl -v -k --header 'Content-Type: application/xml' "https://apid-ivaservizi.agenziaentrate.gov.it/v1/dispositivi/" --data-binary @RichiestaCertificatoDispositivo_Firmato.xml --verbose
    * Could not resolve host: application
    * Closing connection 0
    curl: (6) Could not resolve host: application
    *   Trying 217.175.50.83...
    * TCP_NODELAY set
    * Connected to apid-ivaservizi.agenziaentrate.gov.it (217.175.50.83) port 443 (#1)
    * schannel: SSL/TLS connection with apid-ivaservizi.agenziaentrate.gov.it port 443 (step 1/3)
    * schannel: disabled server certificate revocation checks
    * schannel: verifyhost setting prevents Schannel from comparing the supplied target name with the subject names in server certificates.
    * schannel: sending initial handshake data: sending 193 bytes...
    * schannel: sent initial handshake data: sent 193 bytes
    * schannel: SSL/TLS connection with apid-ivaservizi.agenziaentrate.gov.it port 443 (step 2/3)
    * schannel: failed to receive handshake, need more data
    * schannel: SSL/TLS connection with apid-ivaservizi.agenziaentrate.gov.it port 443 (step 2/3)
    * schannel: encrypted data got 1460
    * schannel: encrypted data buffer: offset 1460 length 4096
    * schannel: encrypted data length: 210
    * schannel: encrypted data buffer: offset 210 length 4096
    * schannel: received incomplete message, need more data
    * schannel: SSL/TLS connection with apid-ivaservizi.agenziaentrate.gov.it port 443 (step 2/3)
    * schannel: encrypted data got 169
    * schannel: encrypted data buffer: offset 379 length 4096
    * schannel: sending next handshake data: sending 158 bytes...
    * schannel: SSL/TLS connection with apid-ivaservizi.agenziaentrate.gov.it port 443 (step 2/3)
    * schannel: encrypted data got 51
    * schannel: encrypted data buffer: offset 51 length 4096
    * schannel: SSL/TLS handshake complete
    * schannel: SSL/TLS connection with apid-ivaservizi.agenziaentrate.gov.it port 443 (step 3/3)
    * schannel: stored credential handle in session cache
    > POST /v1/dispositivi/ HTTP/1.1
    > Host: apid-ivaservizi.agenziaentrate.gov.it
    > User-Agent: curl/7.58.0
    > Accept: */*
    > Content-Length: 5649
    > Content-Type: application/x-www-form-urlencoded
    > Expect: 100-continue
    >
    * schannel: client wants to read 102400 bytes
    * schannel: encdata_buffer resized 103424
    * schannel: encrypted data buffer: offset 0 length 103424
    * schannel: encrypted data got 75
    * schannel: encrypted data buffer: offset 75 length 103424
    * schannel: decrypted data length: 46
    * schannel: decrypted data added: 46
    * schannel: decrypted data cached: offset 46 length 102400
    * schannel: encrypted data buffer: offset 0 length 103424
    * schannel: decrypted data buffer: offset 46 length 102400
    * schannel: schannel_recv cleanup
    * schannel: decrypted data returned 46
    * schannel: decrypted data buffer: offset 0 length 102400
    < HTTP/1.1 100 Continue
    < X-Note: Gateway Ack
    * We are completely uploaded and fine
    * schannel: client wants to read 102400 bytes
    * schannel: encrypted data buffer: offset 0 length 103424
    * schannel: encrypted data got 853
    * schannel: encrypted data buffer: offset 853 length 103424
    * schannel: decrypted data length: 824
    * schannel: decrypted data added: 824
    * schannel: decrypted data cached: offset 824 length 102400
    * schannel: encrypted data buffer: offset 0 length 103424
    * schannel: decrypted data buffer: offset 824 length 102400
    * schannel: schannel_recv cleanup
    * schannel: decrypted data returned 824
    * schannel: decrypted data buffer: offset 0 length 102400
    < HTTP/1.1 415 Processed
    < X-Backside-Transport: FAIL FAIL
    < Connection: Keep-Alive
    < Transfer-Encoding: chunked
    < Date: Mon, 12 Feb 2018 21:50:42 GMT
    < X-Powered-By: Servlet/3.0
    < Access-Control-Allow-Origin: *
    < Access-Control-Allow-Methods: GET, POST, DELETE, PUT
    < Access-Control-Allow-Headers: Content-Type
    < Content-Language: en-US
    < Set-Cookie: LtpaToken2=RC3HSVR/hjOvRLWZyncgdCQTya1ftyZVhJKdk1us8IZGB1uuVKFSHihfy2Wu1oBtsW8j4YJ5GRLvujdhQMRJ0BznWH3d+579DxFbD3mU7ZpqrP2iT+Eguv7f1BdNrM2QxdwSnn6RlzHTOIeycdilOhSf6SKRI/4+HX3I/CdXKC0s8M6Gq9IyiEi9yTflzu52ZdbqJDV8AX8FBYmkoIuBLxs/YDwM9dkoGOHXjO15xE7jLWT9BEYHSVEPSYBwm52tdZ3bdbxwS4OBKp7CbpULX2X3K9/r85JGWNYlxW0pe8hfujDUaNtDdJlSiqPPhK9jFnvdQ4JK2Gj7u5/ogQI4VOja0/r2WsWm4uOrlEAQq1LOs4bP/Yoa5ji4tU5bHlXppkmswuo/+hq+iX7s/xOdIA==
    < X-Global-Transaction-ID: 1515569119
    < Content-Type: text/xml
    <
    * schannel: client wants to read 102400 bytes
    * schannel: encrypted data buffer: offset 0 length 103424
    * schannel: encrypted data got 34
    * schannel: encrypted data buffer: offset 34 length 103424
    * schannel: decrypted data length: 5
    * schannel: decrypted data added: 5
    * schannel: decrypted data cached: offset 5 length 102400
    * schannel: encrypted data buffer: offset 0 length 103424
    * schannel: decrypted data buffer: offset 5 length 102400
    * schannel: schannel_recv cleanup
    * schannel: decrypted data returned 5
    * schannel: decrypted data buffer: offset 0 length 102400
    * Connection #1 to host apid-ivaservizi.agenziaentrate.gov.it left intact
    
    C:\Users\PAOLO2\Desktop\VendingMachine>
    Comunque domani fa degli accertamenti e mi richiama
  • Re: File xml Agenzia delle Entrate

    Paolo64 ha scritto:


    Oggi mi ha chiamato un tizio Sogei perchè avevo aperto un ticket di secondo livello. Mi ha detto che quello che vede è tutto corretto (xml richiesta dispositivo, firma). In effetti il mio dispositivo mobile risulta censito e attivato già da tempo. Il fatto che non riesca a ricevere il certificatodispositivo, secondo lui dipende dalla configurazione di CURL, oppure che il certificato viene scaricato in una directory temporanea che io non vedo . Il fatto che io riceva un errore 415 a lui non risulta. Boh ... a me sembra un loro bug. Cioè se il certificato è già generato e lo ri-richiedo, il loro sistema va in tilt. Lui dice che se il certificato è già creato, la chiamata curl dovrebbe scaricarne un altra copia. Copio sotto il log trasmissione ... E' scritto chiaramente 415 Processed. Voi cosa ne dite ??

    Comunque domani fa degli accertamenti e mi richiama
    Io invece ho una situazione diversa.
    Invio la richiesta di emissione certificato per un nuovo dispositivo mobile, al primo invio il sistema risponde con errore 500, poi entra nell'eterno loop del codice 202.
    Anche a me hanno dato la stessa risposta, ovvero, il dispositito risulta già censito ecc. ecc quando ho aperto il primo ticket della segnalazione dell'errore 202. La mia risposta è stata, che, se il dispostivio è già censito, deve rispondere con codice 409 e restituire il certificato nel file xml così come dicono le istruzioni, quindi, effettivamente il sistema di rilascio dei certificati dispositivo sembra avere più di un problema.
    Ho un certificato che mi ritrovo per grazia ricevuta che sto utilizzando per l'invio dei miei corrispettivi, l'invio funziona senza problemi.
    Paolo quando fai l'invio successivo al primo, mandi sempre lo stesso XML ?
  • Re: File xml Agenzia delle Entrate

    geremiah ha scritto:


    Paolo64 ha scritto:


    Ho un certificato che mi ritrovo per grazia ricevuta che sto utilizzando per l'invio dei miei corrispettivi, l'invio funziona senza problemi.
    Paolo quando fai l'invio successivo al primo, mandi sempre lo stesso XML ?
    Si, mando sempre lo stesso XML. Ho provato a fare un nuovo XML con CSR AD+piva+codice6cifre ma non solo NON mi registra il nuovo dispositivo, ma continua a darmi lo stesso errore 415 Processed. Non ci capisco più nulla. Il tizio di Sogei che doveva richiamarmi non l'ho più sentito. Percui dovrò richiamare per aprire nuovo TK. Che casino..
  • Re: File xml Agenzia delle Entrate

    Novità ? Qualche risposta da parte di Sogei ?
    A me niente, nonostante il sollecito oramai giornaliero del ticket aperto.
  • Re: File xml Agenzia delle Entrate

    geremiah ha scritto:


    Novità ? Qualche risposta da parte di Sogei ?
    A me niente, nonostante il sollecito oramai giornaliero del ticket aperto.
    Stamattina ho provato a lanciare il comando curl da ubuntu invece che da windows, e l'errore 415 si è trasformato in errore 202. Dopo mezz'ora rimane sempre 202 e non cambia mai in 201. Oggi richiamo sogei per capire cosa si può fare. Però io mi chiedo: guardando su google ci sono una decina di app in vendita e quindi già pronte e funzionanti. Come hanno fatto questi a superare questo scoglio dell'errore 202? Forse prima che cominciassimo noi a sviluppare non c'era l'errore?
Devi accedere o registrarti per scrivere nel forum
90 risposte