Demo con código Verifactu.dll para (delphi 7)

[Carlos]

Empezado por DarkDudae

Te invito a que hagas una mínima tarea de investigación leyendo al menos unas páginas de este hilo. Ya en el segundo mensaje del hilo tienes el enlace al FTP del grupo donde puedes encontrar el componente. Allí lo puedes descargar junto con la demo donde verás qué hace y cómo lo hace. Si no sabes ni para qué es el componente, es que estás muy perdido...

Voy a ver la descarga.

No la instalaré por que creo que Veri*factu lo tengo solucionado, pero aún así miro información al respecto y de paso aprendo o detecto detalles que se me han escapado; y si puedo aportar algo donde esté mejor para todos.

Entiendo que el componente es para generar XML y enviarlo a Veri*factu, lo que pasa es que pueden exsitir muchos detalles a tener en cuenta.

¿Habéis probado a enviar con un certificado expirado?
Hasta hace poco la respuesta que daba Veri*factu en esta circumstancia era muy interesante.

Muchas gracias,

[Matorral]

Empezado por Carlos

Voy a ver la descarga.

No la instalaré por que creo que Veri*factu lo tengo solucionado, pero aún así miro información al respecto y de paso aprendo o detecto detalles que se me han escapado; y si puedo aportar algo donde esté mejor para todos.

Buenas Carlos.

Aprovechando que no utilizas el componente, has probado a enviar más de 16 facturas en un solo xml? (si haces el favor de probar con 20 pues perfecto)
En este foro y en otros donde no usan el componente se dio el caso de que al enviar mas de 16 facturas en un solo XML (17 en mi caso), saltaba un error de certificado...

Error Al Enviar
(ESOAPHTTPException)-Se requiere un certificado para completar la autenticación de cliente - URL:https://prewww1.aeat.es/wlpl/TIKE-CONT/ws/SistemaFacturacion/VerifactuSOAP - SOAPAction:""

En cambio si ese xml lo envias desde la web de la AEAT se lo traga sin problemas.

¿Habéis probado a enviar con un certificado expirado?
Hasta hace poco la respuesta que daba Veri*factu en esta circumstancia era muy interesante.

Yo no probe. Que pasa?

Gracias¡¡

[Carlos]

Empezado por Matorral

Buenas Carlos.

Aprovechando que no utilizas el componente, has probado a enviar más de 16 facturas en un solo xml? (si haces el favor de probar con 20 pues perfecto)
En este foro y en otros donde no usan el componente se dio el caso de que al enviar mas de 16 facturas en un solo XML (17 en mi caso), saltaba un error de certificado...

Error Al Enviar
(ESOAPHTTPException)-Se requiere un certificado para completar la autenticación de cliente -

En cambio si ese xml lo envias desde la web de la AEAT se lo traga sin problemas.



Yo no probe. Que pasa?

Gracias¡¡

No se recibía una respuesta de error estándar de Veri*factu, lo cual obligaba a tratarla como una excepción.

La respuesta era estándar dentro de hacienda (para diferentes aplicativos) pero como respuesta a páginas web, no a los envíos tipo Veri*factu.

[Carlos]

Empezado por Carlos

No se recibía una respuesta de error estándar de Veri*factu, lo cual obligaba a tratarla como una excepción.

La respuesta era estándar dentro de hacienda (para diferentes aplicativos) pero como respuesta a páginas web, no a los envíos tipo Veri*factu.

Desconozco si hoy en día aún sigue así.

[Matorral]

Empezado por Carlos

Desconozco si hoy en día aún sigue así.

El mío caduca a finales del mes que viene, probare entonces.

Puedes hacer la prueba de un envío de más de 16 facturas?

Gracias¡¡

[Carlos]

Empezado por Matorral

El mío caduca a finales del mes que viene, probare entonces.

Puedes hacer la prueba de un envío de más de 16 facturas?

Gracias¡¡

Acabo de enviar 28 registros de facturación; todos se corresponden con 28 diferentes facturas, todos enviados como subsanación.

23 fueron enviados INICIALMENTE al entorno de pruebas, 5 al de 'Real.

Los he enviado de nuevo (ahora, por tanto son "subsanación") al entorno de pruebas; 23 aceptados "Correcto", 5 rechazados "Incorrecto".

[Carlos]

Empezado por Carlos

Acabo de enviar 28 registros de facturación; todos se corresponden con 28 diferentes facturas, todos enviados como subsanación.

23 fueron enviados INICIALMENTE al entorno de pruebas, 5 al de 'Real.

Los he enviado de nuevo (ahora, por tanto son "subsanación") al entorno de pruebas; 23 aceptados "Correcto", 5 rechazados "Incorrecto".

"Incorrecto" por que en en entorno al que los he enviado no existe el registro a subsanar (Error 3002).

[seccion_31]

Por descartar:

Acabo de probar con una version inicial del componente, que NO usaba la DLL, usando para el envio la aplicacion servidora y da el mismo error:

El Envio No Ha Podido Ser Realizado
Error Al Enviar
(ESOAPHTTPException)-Se requiere un certificado para completar la autenticación de cliente - URL:https://prewww1.aeat.es/wlpl/TIKE-CO.../VerifactuSOAP - SOAPAction:""

Saludos !

[jguso]

( Por un lado ).
Supongo que la mayoria de los que estamos, tenemos mantenimientos que pasamos al cobro a nuestros clientes.
Según está diseñado esto de VERIFACTU, ahora hay que estar el día q se vayan a facturar estos mantenimientos delante del ordenador para realizarlos. Si andas de vacaciones, tendrás q conectarte en remoto para poder lanzarlos xq como el sistema te obliga a que la fecha de emisión sea la del día, además de que esta fecha debe de coincidir con la fecha de factura de emisión de factura de mantenimiento.



( Por otro lado ).
Pero que ocurre si se te pasa el momento de lanzarlos. Pues que la fecha de emisión de factura irá con retraso de los días hasta que hagamos el lanzamiento ... entonces, todo lo que lanzes te tiene que dar "INCORRECTO", puesto que la fecha de emisión tiene que ser la del día actual, pero la fecha que tiene la fra. de mantenimiento tendrá la que le tocaba, por lo q, tendrás q ir cambiando las fecha de los mantenimientos 1 a 1. xq como tiene que coindicir con la fecha actual.


bueno, se me ocurren más cosas que pueden ocurrir, pero no me voy a extender más.

[Carlos]

Empezado por jguso

( Por un lado ).
Supongo que la mayoria de los que estamos, tenemos mantenimientos que pasamos al cobro a nuestros clientes.
Según está diseñado esto de VERIFACTU, ahora hay que estar el día q se vayan a facturar estos mantenimientos delante del ordenador para realizarlos. Si andas de vacaciones, tendrás q conectarte en remoto para poder lanzarlos xq como el sistema te obliga a que la fecha de emisión sea la del día, además de que esta fecha debe de coincidir con la fecha de factura de emisión de factura de mantenimiento.

Yo tengo algo parecido con unos alquileres, y no sé como resolverlo.

Empezado por jguso

( Por otro lado ).
Pero que ocurre si se te pasa el momento de lanzarlos. Pues que la fecha de emisión de factura irá con retraso de los días hasta que hagamos el lanzamiento ... entonces, todo lo que lanzes te tiene que dar "INCORRECTO", puesto que la fecha de emisión tiene que ser la del día actual, pero la fecha que tiene la fra. de mantenimiento tendrá la que le tocaba, por lo q, tendrás q ir cambiando las fecha de los mantenimientos 1 a 1. xq como tiene que coindicir con la fecha actual.

Los envías indicando 'incidencia'.

Otra opción es enviarlos, los rechaza, los vuelves a enviar como 'subsanación' (1)
(es lo que he hecho con los 28 registros que he enviado hace un rato, eran de junio y julio).

(1) Si los ha rechazado 'Incorrecto', 'subsanación debe ser 'X' (no 'S' si no recuerdo mal).

[Matorral]

Empezado por Carlos

"Incorrecto" por que en en entorno al que los he enviado no existe el registro a subsanar (Error 3002).

Gracias por contestar Carlos¡¡

Perdona por ser tan insistente, Solo es para confirmar que "hablamos" de lo mismo.

Has hecho UN SOLO envío con esas 28 facturas (un xml que contiene los 28 RF)?? y has hecho el envío desde tu aplicación ?

[Carlos]

Empezado por Matorral

Gracias por contestar Carlos¡¡

Perdona por ser tan insistente, Solo es para confirmar que "hablamos" de lo mismo.

Has hecho UN SOLO envío con esas 28 facturas (un xml que contiene los 28 RF)?? y has hecho el envío desde tu aplicación ?

Si desde mi aplicación.

Exacto, un solo XML con los 28 registros.

Ojo, yo no utilizo Verifactu.dll.
Que luego nos volvemos un poco locos buscando fantasmas.

[Matorral]

Empezado por Carlos

Ojo, yo no utilizo Verifactu.dll.
Que luego nos volvemos un poco locos buscando fantasmas.

Por eso te preguntaba.

[seccion_31]

Empezado por Carlos

Si desde mi aplicación.

Exacto, un solo XML con los 28 registros.

Ojo, yo no utilizo Verifactu.dll.
Que luego nos volvemos un poco locos buscando fantasmas.

¿ utilizas httprio ?

Aqui hay alguien con el mismo problema. (de otro tema, que nada tiene que ver), hasta 150 elementos. mas alla. error. El mismo error.

Solucion: no la encontró: dividio los envios en paquetes de 150 items.

[Carlos]

Empezado por seccion_31

¿ utilizas httprio ?

No, no sé que es httprio.

Envío el XML con CURL.EXE

[seccion_31]

Empezado por Carlos

No, no sé que es httprio.

Envío el XML con CURL.EXE

es un componente de delphi webservices, creo que ahi esta el asunto.

Slds !

[Carlos]

Empezado por seccion_31

es un componente de delphi webservices, creo que ahi esta el asunto.

Slds !

Una prueba a realizar sería generar el XML en fichero e intentar enviarlo con esta sentencia:

C:\Desarrol\Treball\AMPA2506\Exe\Utilitats\CURL\BIN\curl.exe -k --connect-timeout 60 -m 300 -s -S -L --header "Content-Type: text/xml;charset=UTF-8" --cert C:\Particular\Ampa\Ampa32\firma_digital\MiCertificadodogital.pem --key C:\Particular\Ampa\Ampa32\firma_digital\MiCertificadodogital.pem --data @C:\DESARROL\TREBALL\AMPA2506\EXE\BD\BL\VERIFACTU\2025\MiFicheroXML.xml https://prewww1.aeat.es/wlpl/TIKE-CO.../VerifactuSOAP -v --output C:\DESARROL\TREBALL\AMPA2506\EXE\BD\BL\VERIFACTU\2025\MiFicheroXML.xml-Resposta_01.XML

Así se sabría si es cosa del XML o del componente de delphi webservices httprio; obteniendo un fichero XML de respuesta de Veri*factu.

Notas:

-El CURL.EXE de Windows (tengo W10) no me funcionaba, bajé otro de www.

-El Certificado Digital era originalmente .p12 , lo convertí a .pem con:

"C:\Program Files\OpenSSL-Win64\bin\openssl" pkcs12 -in MiCertificadoDigital.pfx -out MiCertificadoDigital.pem -nodes

-No se dejen la '@' precediendo el nombre del XML

[seccion_31]

Empezado por Carlos

Una prueba a realizar sería generar el XML en fichero e intentar enviarlo con esta sentencia:

C:\Desarrol\Treball\AMPA2506\Exe\Utilitats\CURL\BIN\curl.exe -k --connect-timeout 60 -m 300 -s -S -L --header "Content-Type: text/xml;charset=UTF-8" --cert C:\Particular\Ampa\Ampa32\firma_digital\MiCertificadodogital.pem --key C:\Particular\Ampa\Ampa32\firma_digital\MiCertificadodogital.pem --data @C:\DESARROL\TREBALL\AMPA2506\EXE\BD\BL\VERIFACTU\2025\MiFicheroXML.xml https://prewww1.aeat.es/wlpl/TIKE-CO.../VerifactuSOAP -v --output C:\DESARROL\TREBALL\AMPA2506\EXE\BD\BL\VERIFACTU\2025\MiFicheroXML.xml-Resposta_01.XML

Así se sabría si es cosa del XML o del componente de delphi webservices httprio; obteniendo un fichero XML de respuesta de Veri*factu.

Notas:

-El CURL.EXE de Windows (tengo W10) no me funcionaba, bajé otro de www.

-El Certificado Digital era originalmente .p12 , lo convertí a .pem con:

"C:\Program Files\OpenSSL-Win64\bin\openssl" pkcs12 -in MiCertificadoDigital.pfx -out MiCertificadoDigital.pem -nodes

-No se dejen la '@' precediendo el nombre del XML

gracias, el XML lo envia bien atraves de los endpoint de la AEAT, el XML no es el problema, seguro que con CURL.exe lo enviara bien.

El problema creo que viene por el keep-alive del httprio para mantener el certificado activo en el envio. Estoy buscando x ahi.

[Carlos]

Empezado por Carlos

Una prueba a realizar sería generar el XML en fichero e intentar enviarlo con esta sentencia:

C:\Desarrol\Treball\AMPA2506\Exe\Utilitats\CURL\BIN\curl.exe -k --connect-timeout 60 -m 300 -s -S -L --header "Content-Type: text/xml;charset=UTF-8" --cert C:\Particular\Ampa\Ampa32\firma_digital\MiCertificadodogital.pem --key C:\Particular\Ampa\Ampa32\firma_digital\MiCertificadodogital.pem --data @C:\DESARROL\TREBALL\AMPA2506\EXE\BD\BL\VERIFACTU\2025\MiFicheroXML.xml https://prewww1.aeat.es/wlpl/TIKE-CO.../VerifactuSOAP -v --output C:\DESARROL\TREBALL\AMPA2506\EXE\BD\BL\VERIFACTU\2025\MiFicheroXML.xml-Resposta_01.XML

Así se sabría si es cosa del XML o del componente de delphi webservices httprio; obteniendo un fichero XML de respuesta de Veri*factu.

Notas:

-El CURL.EXE de Windows (tengo W10) no me funcionaba, bajé otro de www.

-El Certificado Digital era originalmente .p12 , lo convertí a .pem con:

"C:\Program Files\OpenSSL-Win64\bin\openssl" pkcs12 -in MiCertificadoDigital.pfx -out MiCertificadoDigital.pem -nodes

-No se dejen la '@' precediendo el nombre del XML

OpenSSL lo bajo de:
https://slproweb.com/products/Win32OpenSSL.html

Versión 64b reducida:
https://slproweb.com/download/Win64O...ight-3_4_1.msi
https://slproweb.com/download/Win64O...ight-3_4_0.msi

Versión 64b completa:
https://slproweb.com/download/Win64OpenSSL-3_5_0.msi
https://slproweb.com/download/Win64OpenSSL-3_4_1.msi

[bmfranky]

Empezado por seccion_31

Lo que quiere jguso es fecha de operación superior a expedición. Hay algun hilo del foro general donde se trata este tema, y creo que en este al principio tambien.

Aunque mi mensaje es algo confuso, esta correcto. En La demo excel, hay operaciones iguales a expediciones e inferiores, y pasan sin problema.

Es lo que hay y lo que hace. El componente no falla.

Por cierto bmfranky ¿has podido enviar mas de 16 facturas a la vez?

Saludos !

Hola, no te puedo responder, porque como comente en su día, no uso la dll, trabajo en C#, ademas que por conveniencia solo facturo si hay conexión, aunque visto lo visto voy a tener que curarme un modulo de reenvío de los registros de alta, y encolado de los mismos si no hay conexión.
Un saludo.