Error 2004 en VeriFactu: FechaHoraHusoGenRegistro fuera de sincronización

[Jarogo08]

Casualmente, ese es el único error que se excepciona de ser subsanado.


De todas maneras, estaría bien saber porque te da. En el ejemplo que pones, el registro se crea a las 12:51:58. ¿realmente no era esa hora? ¿la hora del pc estaba atrasada o adelantada? Porque sino no debería darte.

[francescofera]

Gracias por tu respuesta, justo por eso me desconcierta más este error.

La hora del sistema es totalmente correcta. El valor de FechaHoraHusoGenRegistro era:
2025-06-18T12:51:58+02:00
y fue generado literalmente segundos antes de ser enviado a la AEAT (mi sistema tiene una cola que lo transmite automáticamente en menos de 10 segundos).

Lo que más me confunde es la diferencia entre:

El mensaje del error 2004, que dice que el campo debe ser la fecha actual del sistema de la AEAT, lo cual suena como si esperaran una coincidencia casi exacta.

vs.

Lo que dice la documentación técnica, es decir:

"Se validará que la FechaHoraHusoGenRegistro sea menor o igual que la fecha del sistema de la AEAT, admitiéndose un margen de error."

y también:

"El huso horario es el que está usando el sistema informático de facturación en el momento de generación del registro de facturación."

Así que no me queda claro si:

el WebService realmente respeta el huso horario informado (como +02:00)

o si internamente espera que se le envíe el valor en UTC (con sufijo Z) o huso horario +1:00.

Estoy considerando hacer una prueba forzando UtcNow con zona Z para descartar eso, pero no me parece consistente con lo que la documentación dice.

¿A ti te ha pasado algo parecido? ¿Tienes idea de cómo lo interpreta realmente la AEAT?

[rci]

Revisa si en este hilo encuentras alguna información que pueda ayudarte.

https://www.clubdelphi.com/foros/showthread.php?t=97445

[ermendalenda]

Empezado por francescofera

Gracias por tu respuesta, justo por eso me desconcierta más este error.

La hora del sistema es totalmente correcta. El valor de FechaHoraHusoGenRegistro era:
2025-06-18T12:51:58+02:00
y fue generado literalmente segundos antes de ser enviado a la AEAT (mi sistema tiene una cola que lo transmite automáticamente en menos de 10 segundos).

Lo que más me confunde es la diferencia entre:


vs.

Lo que dice la documentación técnica, es decir:


y también:


Así que no me queda claro si:

el WebService realmente respeta el huso horario informado (como +02:00)

o si internamente espera que se le envíe el valor en UTC (con sufijo Z) o huso horario +1:00.

Estoy considerando hacer una prueba forzando UtcNow con zona Z para descartar eso, pero no me parece consistente con lo que la documentación dice.

¿A ti te ha pasado algo parecido? ¿Tienes idea de cómo lo interpreta realmente la AEAT?

Es raro ese error nunca me ha dado sin haber xometido un error en la programación del control de flujos.
Revisa que la hora de tu sistema esté correctamente sincronizada con un servicio fiable. Algunos servicios de sincronizacion juegan malas pasadas y te ponen horas +-2 horas de diferencia en tu sistema. Supongo que además la hora que has puesto no le habrás quitado las 2 horas, que es una función que te la tal que así.

[bmfranky]

Hola, ese error en c# se origina al enviarle el DateTime, incluye los milisegundos, hemos posteado bastante al respecto, revisa lo.

public System.DateTime dateTimeSinMilisegundos(System.DateTime currentDateTime)
        {
           return new DateTime(currentDateTime.Year,  currentDateTime.Month, currentDateTime.Day, currentDateTime.Hour,  currentDateTime.Minute, currentDateTime.Second, DateTimeKind.Local);
         }

Esto quita los milisegundos.