buenos dias pablog2k !

gracias, incluso con ese cambio, sigue generando dos lineas.

¿Puedes postear x fa, tu importacion del wsdl ? a ver si con eso acertamos.

Saludos !

Os paso un ejemplo de XML que funciona, tendréis que cambiar algunas cosas, a saber:

NOMBRE_EMISOR_FACTURA: Es el nombre de la persona o empresa que emite la factura, debe ser el mismo que figura en el certificado electrónico con el que se firma el envío.
NIF_EMISOR_FACTURA: Es el nif de la persona o empresa que emite la factura, debe ser el mismo que figura en el certificado electrónico con el que se firma el envío.

NOMBRE_CLIENTE: Nombre del cliente, debe ser un nombre real.
NIF_CLIENTE: Es el nif del cliente, debe ser el nif real del nombre del cliente.
Ojo porque si te inventas los dos valores anteriores dará error aunque sea un nif válido, no te puedes inventar los dos valores anteriores.

NOMBRE_EMPRESA_SOFTWARE: Nombre de la empresa o persona que ha hecho el software de facturación, debe ser real.
NIF_EMPRESA_SOFTWARE: Nif de la empresa o persona que ha hecho el software de facturación, también debe ser real y el que corresponda con el nombre anterior.
Ojo porque si te inventas los dos valores anteriores dará error aunque sea un nif válido, no te puedes inventar los dos valores anteriores.

Y ya por si a alguien le interesa, este es el código que uso para enviar el fichero xml al web service hecho en php:

Espero que os sirva. Saludos.

Gracias Richidemola, lo probaré

Hola, prefiero postearlo cuando consiga que me funcione todo, porque ahora me está dando problemas con los nodos IdDestinatario y DetalleDesglose .... :mad:

Sí. Después del 27 habrá que poner +01:00, o +00:00 si estás en Canarias.

A ver. Primero la hora del ordenador, también la hora de los señales GPS y NTP, y mucho otros, corren en hora UTc, también conocida como hora GMT (la que he marcado Z).
Por tanto lo más próximo adónde buscar para tal consulta es el propio ordenador, por qué tiene esta información.
Delphi lo expone a través de varias vías, por ejemplo System.DateUtils.TTimeZone (desde XE); probablemente usando .
A nivel de Windows, lo normal es que acabe en una llamada a GetTimeZoneInformation (antiguo pero suficiente para el propósito) o GetDynamicTimeZoneInformation (desde Vista, necesitará una versión no demasiada antigua de Delphi). Hay equivalente en los demás sistemas operativos.

Online hay un montón de sitios con esta información. Te recomiendo https://www.timeanddate.com/time en inglés, es corto pero acierta. Verás que los husos horarios son realmente una cosa de los políticos, aplicado por algunos laboratorios. Por tanto la respuesta correcta a tu pregunta es probablemente el Real Observatorio de la Armada.

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?

¿Pero entonces tenemos que darnos de alta en algún sitio para poder hacer los envíos? ¿Donde notificamos el NIF y/o el certificado para que admitan el envío de VeriFactu? No recuerdo haber leído nada de eso.

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

La AEAT sobre el error 4118:

Saludos

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.

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!

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.

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)

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.

Mis ejemplos no te funcionaron porque han sido generados en Canarias UTC+1 en horario de verano.
Si miras esta página de Wikipedia https://es.wikipedia.org/wiki/UTC%2B...opedia%20libre
podrás ver que España se rige en la zona horaria UTC+1 ya que tiene una hora más que las situadas en el meridiano de Greenwich.
Como además, tenemos una hora adelantada debido al cambio horario de verano, entonces la hora de expresa como UTC+2. Cuando se vuelva a cambiar la hora a la de invierno, atrasaremos una y volveremos a UTC+1. En Canarias sería UTC+0.
De todas maneras, como el ordenador donde va estar tu programa debe tener conexión a Internet sí o sí, debes tener activada la sincronización horaria con el reloj de Microsoft o cualquier otro, cualquier librería de cualquier lenguaje puede obtener la hora del sistema y expresarla en formato Iso8601 que es la que nos atañe.

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.

ChatGPT me hizo un favor:

XSDatetime.FractionalSeconds := 0;

Con eso se elimina el .000 de la fecha/hora

Increíble pero cierto.....
resulta que estaba poniendo como pruebas la fecha de una factura de hace unos días..... y no se puede hacer eso
tienes que poner la fecha de facturas de HOY para los envíos de hoy .....
ya podrían indicarlo claramente en el mensaje de error , en vez de decir todo el rato El valor del campo FechaHoraHusoGenRegistro no está dentro del umbral establecido sobre la fecha del sistema de la AEAT
:(

A mi en c#, solo me deja insertar un DateTime.Now, no puedo cambiarle nada, asi que me sale con milisegundos y todo...


Alguien ha usado el sistema de envio que implementa el XSD, sin httprio, es que no consigo conectar, simpre me dice que no puede establecer conexion, no se si estare pasando mal los parametros.

ya hice edit de lo que me estaba pasando ... :mad:
edit: no me enfadé!! mi enfado viene de la poca claridad que tiene Verifactu para devolver los errores

Hola, perdona, estaba escribiendo miestras lo editabas, ño siento si te ofendi de alguna forma.

Ojo con el NIF que se usa para las pruebas...

Algunos errores que me ha devuelto al hacer el envío:

- En el bloque Destinatarios si se identifica mediante NIF, el NIF debe estar identificado y ser distinto del NIF ObligadoEmision.
- Error en el bloque Destinatario.. El NIF no está identificado en el censo de la AEAT.. NIF:(un NIF real). NOMBRE_RAZON: (un nombre real)

Conclusiones:
- no se puede usar el mismo nif como emisor y como destinatario
- hay que usar un NIF dado de alta en el censo de la AEAT. Lo curioso es que mi NIF está dado de alta, pero quizás es porque me inventé el nombre y puse otra cosa?

Ahora estoy obteniendo este otro error:

El cálculo de la huella no coincide con la huella facilitada.

¿A alguien más le ha pasado?

Prueba Qr
 

Aquí os dejo adjunto un QR, aunque no he subido factura, por si le sirve a alguien

No sé si lo ha subido alguien.

Hola unomasmas,
Sí, lo tengo en producción sin problemas.
Lo de iniciar sesión se hace a través del programa SimplySign Desktop donde introduces el código de seguridad recibido en la app del móvil SimplySign.
Una vez aceptado el código, se queda la sesión del programa abierta durante dos horas para firmar lo que necesites. Digamos que se habilita la clave privada del certificado que tienes instalado en el PC.
Pasadas las dos horas, se cierra la sesión y el certificado que tienes en el PC no te permite firmar (como si estuviera instalado sin la clave privada).
Tampoco puedes exportarlo ya que la clave privada parece que está en la nube de Certum.
Puede parecer complicado, pero es más fácil de lo que parece.

Saludos,
David M.

Has probado a enviarlo vomo incidencia?
Tiene pinta que si pasa cierto tiempo ya debe ser considerado como incidencia, pruébalo y nos dices, por que habrá que tenerlo en cuenta

por si a alguien le sirve, cuando modificamos una factura ya subida (rellenando el nodo Subsanacion) , se puede modificar la huella y el FechaHoraHusoGenRegistro.
Porqué digo esto? porque si os ha pasado como a mi, de haber subido unas cuantas pruebas con errores, probalbmente estos campos os hayan dado error, y para generar la huella correctamente, se necesitan ambos campos 'bien'.
Yo he conseguido subsanar la primera factura que subí, diciendole la FechaHoraHusoGenRegistro de ahora (pese a que fecha factura sea anterior), y calculando a raiz de ahí la huella, y me ha contestado OK.

Ahora utilizaré ese hash para la huella de la siguiente factura , a ver si cuela.... :rolleyes:

Gracias, toda información es buena.
Te importaría probar si te deja enviar un registro como subsanacion aunque no se haya enviado?

Y más pruebas que había pensado.
Mandas del 1 al 10 y el 5 te pide subsanacion, mandas el 5 y el siguiente (el 11) encadenado con el subsanado. Por lógica sería ok

Pues también me salta este error.
El valor del campo FechaHoraHusoGenRegistro no está dentro del umbral establecido sobre la fecha del sistema de la AEAT.

La hora de mi reloj (hora peninsular España) es 2024-10-01 18:25.

He probado con estos valores
2024-10-01T18:03:04+02:00
2024-10-01T16:03:04+02:00
2024-10-01T16:22:04+02:00
2024-10-01T18:20:04+01:00

Hola, todas las horas estan mas alla de los 5 minutos.
2024-10-01T18:20:04+02:00 esta igual colaria

Este ha entrado (bueno, he cambiado algún que otro dato para anonimizarlo). Me da problemas con la etiqueta FechaHoraHusoGenRegistro

Sí, es ese el problema. bmfranky, muchas gracias :-). He cambiado a una hora dos minutos menos y ha colado. Obviamente, me ha dado un error lógico:
El cálculo de la huella no coincide con la huella facilitada.

Ayer tuve problemas con la identificación. No sé cuál era exactamente el mensaje pero parece que debe coincidir, por supuesto el CIF del emisor con el del certificado y, además, al menos, parcialmente el nombre y algún apellido (el certificado que uso es de persona física). Yo tenía como nombre del emisor el de una empresa. Me pasó también con los datos de destinatario: no aceptaba una falta de correspondencia con CIF de persona física y nombre que no tuviera apariencia de persona física (yo tenía en el nombre algo como S.L.) No sé si esto te puede ayudar.

Ayuda envio
 

Hola, he coseguido rellenar todos los campos, al serializar se ve la estructura correcta, menos las cabeceras SOAP, puesto que en Visual c#, no se como crearlas sin enviarlas.
el problema lo tengo en que no me aclaro al enviar, siempre me da error " No se puede crear un canal seguro SSL/TLS." , he probado con web request y me pasa lño mismo.
Lo tengo asi, alguien sabria decirme que me puede faltar?

C#
Si pudierais orientarme os estari a muy agradecido.

Uso un certificado de representante, puede ser por eso?

Creo que te falta activar seguridad Tls

Estoy usando el servicio generado desde el xsd.



Si sabeis decirme como o donde configurar lo , agradeceria cualquier tipo de ayuda.

XML generado
 

El xml creo que si me lo genera bien, he cambiado mis datos...