FechaHoraHusoGenRegistro y configuración de la zona horaria PC

[bmfranky]

Empezado por rci

Hola, nosotros trabajamos en c#, importamos el wsdl y este genera unas clases con los objetos y sus propiedades.
Para crear un registro de facturación, creamos un objeto y lo rellenamos.
Para enviar ese registro, creamos otro objeto con todos los registros de facturación a enviar y lo enviamos directamente con las funciones que se generaron al importar el wsdl, pasándole el objeto para enviar.
No creamos el XML a pelo, de hecho no haría falta serializar el objeto a XML, si no fuera para guardarlo (en fichero o en base de datos).

Esto ya nos funciona pero hemos encontrado un caso que no funciona correctamente.

El tema está en el campo FechaHoraHusoGenRegistro, al importar el wsdl ese campo se crea como un DateTime.
En la documentación ese campo es una fecha en formato YYYY-MM-DDThh:mm:ssTZD (ej: 2024-01-01T19:20:30+01:00) (ISO 8601)
Al rellenar la propiedad en el objeto le indicamos que ese DateTime tiene DateTimeKind.Local para indicar que la hora representada es la hora local.
Para calcular la huella necesitamos esa fecha en formato de cadena y lo convertimos de forma que aparezca la información de la zona horaria.

Hemos visto que estas dos operaciones, utilizan la configuración de la zona horaria del ordenador donde se ejecuta.

Hasta aquí todo bien. En condiciones normales funciona perfectamente.

El problema lo tenemos cuando hay un ordenador con una configuración de zona horaria y otro con otra configuración.
Hemos visto que si el registro de facturación lo genera y lo envía el mismo ordenador, no hay problema.
Pero si el registro de facturación lo genera un ordenador y lo envía otro (con configuración de zona horaria distinta) luego la factura es aceptada con errores y el error es de la huella.
2000 El cálculo de la huella suministrada es incorrecta.

Puntualizar que en nuestro caso cada ordenador genera registros de facturación, se guardan en una BD central de un servidor, y en ese servidor hay un servicio que va enviando los RFs.

Imaginamos que el error ocurre porque el tipo de datos DateTime de c# no tiene información del desplazamiento respecto UTC y mira la configuración de zona horaria del ordenador donde se ejecuta. Pensamos que la función para enviar el objeto, también utiliza esa configuración y depende del ordenador envía una cosa u otra.
Por ejemplo desde un ordenador envía 2025-04-15T15:57:46+01:00 desde el otro envía 2025-04-15T15:57:46+02:00
Y claro cuando hacienda hace las validaciones y genera la huella, si la FechaHoraHusoGenRegistro no es la correcta, la huella cambia.

Hemos estado haciendo varias pruebas y buscando varias posibilidades pero no hemos encontrado la forma de solucionarlo.

Pensamos que tenemos varias opciones:

1. No permitir que varios ordenadores tengan distintas configuraciones de zona horaria.

2. Modificar las clases que se generan al importar el wsdl, cambiar el tipo del campo FechaHoraHusoGenRegistro para que sea una cadena y hacer el tratamiento nosotros del valor de la zona horaria

3. Para el envió, no trabajar con los objetos, sino utilizar una cadena con el XML y enviar ese string directamente haciendo un POST. (y controlar el valor de la zona horaria del campo).

Seguramente haremos la opción 1, no se si algún cliente nuestro requerirá configuraciones distintas.
Sobre la opción 2, no nos gusta demasiado porque cada vez que se actualice el wsdl se tendrá que volver a cambiar.
Sobre la opción 3, pensamos que en general es mejor para nosotros trabajar con los objetos, para rellenarlos y para tratar las respuestas obtenidas.

No se si alguno de vosotros trabaja en c# y se ha encontrado con este problema o si tenéis alguna otra idea para afrontar ese caso.

Muchas gracias

Hola, habeis probado a pasar el Date, como un parametro al mismo tiempo que enviais el registro y usarlo para generar la huella, asi seguro que es el mismo....

Osea que consultais la fecha hora al ordenador que hace el envio y la usais para generar el registro y la huella, asi seguro que es la misma, con unos segundos de diferencia.
El ordenador que hace el envio a su vez la consulta con la base de datos o internet o lo que sea.

[rci]

Empezado por bmfranky

Hola @rci, Prueba esto.


public System.DateTime(System.DateTime currentDateTime)
{
return new DateTime(currentDateTime.Year, currentDateTime.Month, currentDateTime.Day, currentDateTime.Hour, currentDateTime.Minute, currentDateTime.Second, DateTimeKind.Local);
}
Si la hora no es local la convierte a local.

Hola bmfranky, esto es exactamente lo que hago
Pero esto solo crea un DateTime indicando que DateTimeKind es local, luego cuando el serializador o "quien" sea coge ese DateTime para obtener la fecha hora real con el huso, utiliza la configuración de la zona horaria del ordenador donde se ejecuta. y si no es el mismo que el que generó el registro de facturación, pues no indica la misma hora/huso.

Empezado por bmfranky

Hola, habeis probado a pasar el Date, como un parametro al mismo tiempo que enviais el registro y usarlo para generar la huella, asi seguro que es el mismo....

Osea que consultais la fecha hora al ordenador que hace el envio y la usais para generar el registro y la huella, asi seguro que es la misma, con unos segundos de diferencia.
El ordenador que hace el envio a su vez la consulta con la base de datos o internet o lo que sea.

Si hago esto funcionaria pero no cumpliría la ley Generar el registro y la huella se tiene que hacer al emitir la factura y no al enviar.

Pero gracias de todas formas.

De momento he prohibido que haya configuraciones de zona horaria distintas en todos los ordenadores que ejecutan el programa con la misma base de datos.
Si no encuentro otra solución lo dejaré así.

Saludos

[bmfranky]

Empezado por rci

Hola bmfranky, esto es exactamente lo que hago
Pero esto solo crea un DateTime indicando que DateTimeKind es local, luego cuando el serializador o "quien" sea coge ese DateTime para obtener la fecha hora real con el huso, utiliza la configuración de la zona horaria del ordenador donde se ejecuta. y si no es el mismo que el que generó el registro de facturación, pues no indica la misma hora/huso.



Si hago esto funcionaria pero no cumpliría la ley Generar el registro y la huella se tiene que hacer al emitir la factura y no al enviar.

Pero gracias de todas formas.

De momento he prohibido que haya configuraciones de zona horaria distintas en todos los ordenadores que ejecutan el programa con la misma base de datos.
Si no encuentro otra solución lo dejaré así.

Saludos

Si, lo entiendo, pero la fecha hora seria la misma, la del sistema que envia, es lo mismo que consultar la hora a la base de datos, pero en este caso es el servidor horario es el ordenador que envia, no incumples ninguna ley, creo que no me he explicado bien
A lo que me refiero es a que implementeis la funcion que consulta la hora solo en el ordenador que envia y que los demas se la pidan a el.

[rci]

Empezado por bmfranky

A lo que me refiero es a que implementeis la funcion que consulta la hora solo en el ordenador que envia y que los demas se la pidan a el.

Ah perdona, no había entendido.

Si, de esta forma también funcionaria, pero es un poco mas complicado. Lo tendré en cuenta.

Gracias

[FelixDL]

Yo para obtener el valor de "FechaHoraHusoGenRegistro" en SQL Server uso:

select @ls_valor = left(convert(nvarchar(33), sysdatetimeoffset(), 126), 19) + right(convert(nvarchar(33), sysdatetimeoffset(), 126), 6)

Saludos

[rci]

Empezado por FelixDL

Yo para obtener el valor de "FechaHoraHusoGenRegistro" en SQL Server uso:

select @ls_valor = left(convert(nvarchar(33), sysdatetimeoffset(), 126), 19) + right(convert(nvarchar(33), sysdatetimeoffset(), 126), 6)

Saludos

Muchas gracias por la respuesta FelixDL
De esta forma se obtiene directamente una cadena, pero trabajando con objetos tengo el mismo problema

[bmfranky]

Empezado por rci

Muchas gracias por la respuesta FelixDL
De esta forma se obtiene directamente una cadena, pero trabajando con objetos tengo el mismo problema

Hola, @rci , prueba a crear desde esa cadena el System.DateTime, y se lo pasas al componente a ver si soluciona tu problema.