Ley antifraude 2021 (VERIFACTU) - Programas informáticos

[pablog2k]

Empezado por pablog2k

alguien me puede decir como habéis conseguido quitar los milisegundos en la fecha que se genera a partir de la variable TXSDateTime para rellenar el nodo FechaHoraHusoGenRegistro? o utilizáis otra tipo de variable?

me autorespondo, es utilizando el metodo XSToNative y poniendo 'a piñón' el valor que queramos

[seccion_31]

La AEAT sobre el error 4118:

Le confirmamos que no el problema no proviene por falta de autorización de ninguno de los NIFs incluidos en la presentación. En el fichero XML de respuesta podrá ver que la descripción del error 4118 es "Error técnico: la dirección no se corresponde con el fichero de entrada."

El error 4118 puede deberse al uso de un Endpoint incorrecto o un Envelope con errores. En su caso deben revisar el Envelope del fichero ya que no es correcto. Le recomendamos revisar los ejemplos de fichero incluidos en el documento "Documento de descripción de servicios web (v0.4.0) - Borrador" de la web de desarrolladores.

Saludos

[espinete]

Tiene pinta de que el error va a estar en que nuestro XML tiene repetido el nodo "RegFactuSistemaFacturacion".

Al recibir el XML, AEAT intenta buscar dentro de ese nodo los datos de la factura, pero lo que encuentra es otro nodo "RegFactuSistemaFacturacion".

No soy un experto en XML ni sé cómo AEAT interpreta el archivo, pero me da que el problema puede estar ahi.

Otra cosa que he notado en mi XML con respecto al que publicaron recientemente es que el que yo genero tiene dos nodos de más:

<SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<SOAP-ENV:Body xmlns:NS1="https://www2.agenciatributaria.gob.es/static_files/common/internet/dep/aplicaciones/es/aeat/tike/cont/ws/SuministroLR.xsd">
.....
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>

El otro XML que publicaron que sí se envía sin error no tiene esas dos líneas.

No sé qué hay que configurar en Delphi, o en el componente HTTPRIO, o en el wsdl importado, etc. para que no haga eso. Por si esa fuera la causa del problema.

Empezado por seccion_31

La AEAT sobre el error 4118:



Saludos

[seccion_31]

Tiene pinta de que el error va a estar en que nuestro XML tiene repetido el nodo "RegFactuSistemaFacturacion".

Si, tiene pinta de eso, pero creo que ayer envie un XML sin el nodo repetido y seguia diciendo lo mismo. ... (creo), en mi opinion, o estan mal importados los WSDL, mal creados, o delphi no los puede importar bien.

Probare mañana a enviar XMLS manuales, copiando algunos de los que han remitido por aqui.

Saludos!

[pablog2k]

De los que habéis podido enviar, que hay que poner exactamente en el campo FechaHoraHusoGenRegistro ??
Porque he probado:
2024-10-01T13:17:13+01:00 (error)
2024-10-01T13:17:13+02:00 (error)
2024-10-01T12:17:13+01:00 (restando una hora para que aplique el +01:00, error)
2024-10-01T11:17:13+02:00 (restando dos horas para que aplique el +02:00, error)
2024-10-01T15:17:13+02:00 (sumando dos horas para que aplique el +02:00, error)

[richidemola]

Empezado por pablog2k

De los que habéis podido enviar, que hay que poner exactamente en el campo FechaHoraHusoGenRegistro ??
Porque he probado:
2024-10-01T13:17:13+01:00 (error)
2024-10-01T13:17:13+02:00 (error)
2024-10-01T12:17:13+01:00 (restando una hora para que aplique el +01:00, error)
2024-10-01T11:17:13+02:00 (restando dos horas para que aplique el +02:00, error)
2024-10-01T15:17:13+02:00 (sumando dos horas para que aplique el +02:00, error)

A mi me sirvió con el +02:00 porque el +01:00 me daba error, varios mensajes más arriba hablábamos del tema, lo que si que hago, para curarme en salud, es redondear los segundos, es decir, si son las 13:36:17 yo pongo 13:36:00 para ir siempre un poco por debajo de la hora de la aeat, ten en cuenta que el margen que acepta la aeat es de máximo 5 minutos por debajo de su hora.

Comprueba también que la hora de tu equipo, si es una aplicación de escritorio, es igual a la hora de la aeat, en mi caso como la aplicación funciona en navegador web cojo la hora del servidor web que es la misma hora que la de la aeat porque la hora del servidor web está sincronizada y no tengo que andar mirando la hora del PC.

Saludos.

[sglorka]

Empezado por pablog2k

De los que habéis podido enviar, que hay que poner exactamente en el campo FechaHoraHusoGenRegistro ??
Porque he probado:
2024-10-01T13:17:13+01:00 (error)
2024-10-01T13:17:13+02:00 (error)
2024-10-01T12:17:13+01:00 (restando una hora para que aplique el +01:00, error)
2024-10-01T11:17:13+02:00 (restando dos horas para que aplique el +02:00, error)
2024-10-01T15:17:13+02:00 (sumando dos horas para que aplique el +02:00, error)

Te sería más fácil ejecutar este curl si quieres
# curl "http://worldtimeapi.org/api/timezone/Europe/Madrid" si estás en península.
Te va a devolver, entre otras cosas, "datetime": "2024-10-01T13:56:54.849406+02:00". Esta fecha es la que tienes que informar en el FechaHoraHusoGenRegistro, indica la hora actual y el +2 hace referencia al horario de verano.

Si estás en las Islas Canarias ejecutas
# curl "http://worldtimeapi.org/api/timezone/Atlantic/Canary", donde obtenemos "datetime": "2024-10-01T12:55:50.103145+01:00", donde el +1 indica horario de verano ya que en las Islas hay una hora menos.

[pablog2k]

Empezado por sglorka

Te sería más fácil ejecutar este curl si quieres
# curl "http://worldtimeapi.org/api/timezone/Europe/Madrid" si estás en península.
Te va a devolver, entre otras cosas, "datetime": "2024-10-01T13:56:54.849406+02:00". Esta fecha es la que tienes que informar en el FechaHoraHusoGenRegistro, indica la hora actual y el +2 hace referencia al horario de verano.

Si estás en las Islas Canarias ejecutas
# curl "http://worldtimeapi.org/api/timezone/Atlantic/Canary", donde obtenemos "datetime": "2024-10-01T12:55:50.103145+01:00", donde el +1 indica horario de verano ya que en las Islas hay una hora menos.

pero no se supone que hay que enviar la fecha actual + 2 horas??? porque estamos en +02:00??
De todas formas mi problema no es obtener la fecha actual, es saber que narices están esperando...
he probado todas las maneras habidas y por haber, restando y sumando horas.... y nada (tus ejemplos tampoco me funcionaron ,ni con milisegundos ni sin milisegundos)

[espinete]

Con el .pas generado al importar el WSDL como SOAP 1.2, solo tuve que añadir esta línea al .pas (gracias a pablog2k)

Código Delphi [-]
InvRegistry.RegisterInvokeOptions(TypeInfo(sfPortTypeVerifactu), ioLiteral);

La añadí justo después de la que viene por defecto:

Código Delphi [-]
InvRegistry.RegisterInvokeOptions(TypeInfo(sfPortTypeVerifactu), ioDocument);

Después de ese cambio, me daba otro error indicando que faltaba el campo "IDDestinatario", pero ese campo sí que estaba.
Lo que pasa es que en mi IDDestinatario había añadido el subnodo "IDOtro". Lo quité y ya pude hacer el envío.

Ahora bien, el envío me devuelve "Incorrecto", así que ahora tendré que ir poco a poco buscando los motivos, pero al menos el error anterior ya no me da. Supongo que ahora tendré que buscar en la respuesta (RespuestaBaseType) las causas de error que devuelve la AEAT.

Empezado por seccion_31

Si, tiene pinta de eso, pero creo que ayer envie un XML sin el nodo repetido y seguia diciendo lo mismo. ... (creo), en mi opinion, o estan mal importados los WSDL, mal creados, o delphi no los puede importar bien.

Probare mañana a enviar XMLS manuales, copiando algunos de los que han remitido por aqui.

Saludos!

[espinete]

Para poder ver el detalle del error, hay que hacer el envío usando "RespuestaRegFactuSistemaFacturacionType" para la respuesta, en vez de "RespuestaBaseType".

Por lo que el envío usando HTTPRIO hay que hacerlo así:

Código Delphi [-]
res := RespuestaRegFactuSistemaFacturacionType.Create;
SistemaFacturacion.RespuestaRegFactuSistemaFacturacion(res) := SistemaFacturacion.GetsfPortTypeVerifactu(false, 'https://prewww1.aeat.es/wlpl/TIKE-CONT/ws/SistemaFacturacion/VerifactuSOAP', Form1.HTTPRIO1).RegFactuSistemaFacturacion(veriFactu);

Solo así puedo ver el array de errores que devuelve Hacienda.

[delphiGar]

Empezado por espinete

Con el .pas generado al importar el WSDL como SOAP 1.2, solo tuve que añadir esta línea al .pas (gracias a pablog2k)

InvRegistry.RegisterInvokeOptions(TypeInfo(sfPortTypeVerifactu), ioLiteral);

La añadí justo después de la que viene por defecto:

InvRegistry.RegisterInvokeOptions(TypeInfo(sfPortTypeVerifactu), ioDocument);

Después de ese cambio, me daba otro error indicando que faltaba el campo "IDDestinatario", pero ese campo sí que estaba.
Lo que pasa es que en mi IDDestinatario había añadido el subnodo "IDOtro". Lo quité y ya pude hacer el envío.

Ahora bien, el envío me devuelve "Incorrecto", así que ahora tendré que ir poco a poco buscando los motivos, pero al menos el error anterior ya no me da. Supongo que ahora tendré que buscar en la respuesta (RespuestaBaseType) las causas de error que devuelve la AEAT.

Muchas gracias por compartir el arreglo que le habeis hecho al fichero generado con el Import WDSL.

[delphiGar]

Empezado por seccion_31

Si, tiene pinta de eso, pero creo que ayer envie un XML sin el nodo repetido y seguia diciendo lo mismo. ... (creo), en mi opinion, o estan mal importados los WSDL, mal creados, o delphi no los puede importar bien.

Probare mañana a enviar XMLS manuales, copiando algunos de los que han remitido por aqui.

Saludos!

Buenas seccion_31, haz el cambio este en el fichero generado de SOAP, es de Espinete y plabo2k

Añade esta linea:

InvRegistry.RegisterInvokeOptions(TypeInfo(sfPortTypeVerifactu), ioLiteral);

debajo de esta:

InvRegistry.RegisterInvokeOptions(TypeInfo(sfPortTypeVerifactu), ioDocument);  // fijate que pone ioDocument y no ioSOAP12

Con esto funciona correctamente, a mi ya me deja enviar sin problema.