Club Delphi  
    FTP   CCD     Buscar   Trucos   Trabajo   Foros

Retroceder   Foros Club Delphi > Proyecto SIF/Veri*Factu/Ley Antifraude > Registros de Facturacion y Eventos (XML)
Registrarse FAQ Miembros Calendario Guía de estilo Temas de Hoy

Respuesta
 
Herramientas Buscar en Tema Desplegado
  #1  
Antiguo Hace 2 Semanas
rci rci is offline
Miembro
 
Registrado: nov 2020
Posts: 416
Poder: 5
rci Va por buen camino
Question FechaHoraHusoGenRegistro y configuración de la zona horaria PC

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
Responder Con Cita
  #2  
Antiguo Hace 2 Semanas
rci rci is offline
Miembro
 
Registrado: nov 2020
Posts: 416
Poder: 5
rci Va por buen camino
nueva prueba

Hola, hemos seguido investigando y haciendo pruebas y tenemos otra opción, pero no tenemos claro que sea correcta.

Lo que hemos hecho ahora es al rellenar la propiedad de la fecha hora de generación, en el objeto le indicamos que ese DateTime tiene DateTimeKind.Utc para indicar que la hora representada es la hora UTC.
Para calcular la huella ahora la cadena para representar FechaHoraHusoGenRegistro en formato ISO 8601 no tiene un +01:00 al final sino que tiene una Z.

Luego tanto si envío ese registro de facturación desde un ordenador como desde otro con una configuración de zona horaria (huso) distinta, se envía el mismo valor y las facturas son aceptadas sin errores.

Pero tenemos la duda sobre si la hora de generación que estamos informando es la correcta.
Consultando por la web los datos de las facturas ya enviadas, tenemos
Fecha de presentación: 16-04-2025 13:28:49
Fecha de generación del registro: 2025-04-16T12:24:36Z


Estamos indicando la misma fecha y hora en los dos campos? (Los minutos y segundos varían un poco por el tiempo que he tardado entre generar el registro y enviar pero eso no me importa para este tema, solo la hora)

Preguntando a la IA me ha contestado lo siguiente:
Cita:
Cuando la fecha se marca como DateTimeKind.Utc, se establece que el valor se interpretará y se serializará en tiempo universal coordinado (UTC). Así, una fecha como 2025-04-16T12:24:36Z significa que realmente es las 12:24:36 en UTC.

Si tu otra referencia indica que la fecha de presentación es 16-04-2025 13:24:36 y esa fecha está en hora local con una configuración de huso horario de UTC+1 (como es típico en muchas zonas de Europa durante el horario estándar), entonces 12:24:36 UTC equivalen exactamente a 13:24:36.

Por tanto, aunque las cadenas de texto son diferentes (una con la "Z" y la otra con un formato local sin indicación explícita de offset), ambas representan el mismo instante en el tiempo. Este comportamiento es por lo que se espera: la fecha con el sufijo "Z" es una representación estándar para indicar que el valor está en UTC, mientras que la fecha en formato local refleja el ajuste según la configuración hora del sistema.
Me ha parecido una explicación bastante lógica pero no se si fiarme mucho.
Como podéis ver no domino demasiado en temas de horas y husos horarios pero podría ser que sea correcto lo que me ha dicho.

Por otra parte AEAT ha contestado como correcta pero no se si es que no lo valida o que.
En la definición del campo FechaHoraHusoGenRegistro a parte de indicar el formato, también dice:
Cita:
Fecha, hora y huso horario de generación del registro de facturació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.
No se yo si enviando una Z en lugar de +01:00 (o el que toque), estoy indicando bien el huso horario o no seria lo correcto....

En algún otro post de este foro he visto alguien que también enviaba una Z en FechaHoraHusoGenRegistro pero no encuentro el mensaje ni se si es correcto.

Vosotros que pensáis?

Muchas gracias!!
Responder Con Cita
  #3  
Antiguo Hace 2 Semanas
gcqZW gcqZW is offline
Miembro
 
Registrado: ene 2025
Ubicación: Zaragoza
Posts: 134
Poder: 1
gcqZW Va por buen camino
las dos son las mismas fechashoras, lo que no indicas el huso horario, Z entiendo que es por hora "Zulú" que es la hora sin ningún huso horario (o +0), por lo que entiendo que se las traga ahora pero si quieren que le pasemos el huso horario te dará problemas en el futuro entiendo.
__________________
La religión es personal e intransferible.
Responder Con Cita
  #4  
Antiguo Hace 2 Semanas
rci rci is offline
Miembro
 
Registrado: nov 2020
Posts: 416
Poder: 5
rci Va por buen camino
Cita:
Empezado por gcqZW Ver Mensaje
las dos son las mismas fechashoras, lo que no indicas el huso horario, Z entiendo que es por hora "Zulú" que es la hora sin ningún huso horario (o +0), por lo que entiendo que se las traga ahora pero si quieren que le pasemos el huso horario te dará problemas en el futuro entiendo.
Gracias gcqZW por la respuesta. podría ser
Responder Con Cita
  #5  
Antiguo Hace 2 Semanas
Avatar de Neftali [Germán.Estévez]
Neftali [Germán.Estévez] Neftali [Germán.Estévez] is offline
[becario]
 
Registrado: jul 2004
Ubicación: Barcelona - España
Posts: 18.874
Poder: 10
Neftali [Germán.Estévez] Es un diamante en brutoNeftali [Germán.Estévez] Es un diamante en brutoNeftali [Germán.Estévez] Es un diamante en bruto
Cita:
Empezado por rci Ver Mensaje
...
El problema lo tenemos cuando hay un ordenador con una configuración de zona horaria y otro con otra configuración.
En nuestro caso, que también trabajamos con un servidor (SQLServer y donde están los servicios de envío), tenemos una función que nos devuelve la fecha/hora del Servidor (SQLSerevr).
En algunos casos (no en todos) no cogemos la hora del equipo, sino la del servidor (para el tema de Ley antifraude lo hemos usado en varios sitios).
__________________
Germán Estévez => Web/Blog
Guía de estilo, Guía alternativa
Utiliza TAG's en tus mensajes.
Contactar con el Clubdelphi

P.D: Más tiempo dedicado a la pregunta=Mejores respuestas.
Responder Con Cita
  #6  
Antiguo Hace 2 Semanas
rci rci is offline
Miembro
 
Registrado: nov 2020
Posts: 416
Poder: 5
rci Va por buen camino
Cita:
Empezado por Neftali [Germán.Estévez] Ver Mensaje
En nuestro caso, que también trabajamos con un servidor (SQLServer y donde están los servicios de envío), tenemos una función que nos devuelve la fecha/hora del Servidor (SQLSerevr).
En algunos casos (no en todos) no cogemos la hora del equipo, sino la del servidor (para el tema de Ley antifraude lo hemos usado en varios sitios).
Muchas gracias Neftali.
Nosotros también usamos la fecha y hora del servidor SQL server, y procuramos que ese servidor siempre esté en la hora exacta. No usamos la hora local del ordenador porque pueden estar fuera de hora y tampoco consultamos la hora de internet (ROA) a cada factura para evitar tantas consultas.
Pero independientemente de esto, nos ocurre lo mencionado en el primer post. Porque esa fecha hora del servidor SQL, al pasarla a DateTime, no tiene el huso y luego depende de donde se utilice ese DateTime, genera una FechaHoraHusoGenRegistro distinta.

Para coger la hora del servidor SQL primero usábamos la consulta
Código SQL [-]
SELECT GETDATE()
Pero solo devuelve un DateTime (sin huso)
Luego probamos con la consulta
Código SQL [-]
SELECT SYSDATETIMEOFFSET()
Que devuelve un DateTimeOffset, este tipo si que tiene una propiedad Offset con el desplazamiento de la hora respecto de la hora universal coordinada (UTC).

Esto seria fantástico si en la clase de VeriFactu que se genera al importar el WSDL, el objeto FechaHoraHusoGenRegistro fuera DateTimeOffset, pero no lo es.
Y estamos con el mismo problema

Muchas gracias
Responder Con Cita
  #7  
Antiguo Hace 2 Semanas
Jarogo08 Jarogo08 is offline
Miembro
 
Registrado: ene 2025
Posts: 78
Poder: 1
Jarogo08 Va por buen camino
Cita:
Empezado por rci Ver Mensaje
SELECT SYSDATETIMEOFFSET()

Que devuelve un DateTimeOffset, este tipo si que tiene una propiedad Offset con el desplazamiento de la hora respecto de la hora universal coordinada (UTC).

Esto seria fantástico si en la clase de VeriFactu que se genera al importar el WSDL, el objeto FechaHoraHusoGenRegistro fuera DateTimeOffset, pero no lo es.
Y estamos con el mismo problema

¿y no puedes crear una función en el Visual que te devuelva un string, con el formato que necesita Verifactu?

si haciendo el "SYSDATETIMEOFFSET" obtienes algo como esto: "2025-04-16 16:44:01.6718891 +02:00"

y Verifactu necesita algo como esto: "2025-04-16T16:44:01+02:00"

entiendo que no sería difícil crear una función que haga la consulta, la ponga en el formato de Verifactu y la devuelva como string.

Y si la haces y la pones aquí, ya la aprovecho yo
Responder Con Cita
  #8  
Antiguo Hace 2 Semanas
Jarogo08 Jarogo08 is offline
Miembro
 
Registrado: ene 2025
Posts: 78
Poder: 1
Jarogo08 Va por buen camino
Venga... ya la hice yo, la pongo aquí que mañana es festivo y estoy de buenas

Código:
Function ObtenerFechaHora() As String
        Dim retorno As String = ""

        '-------------------------------------------
        '1 - COGEMOS LA HORA DE INTERNET
        '-------------------------------------------

        Try
            ServicePointManager.SecurityProtocol = CType(3072, SecurityProtocolType)    'TLS 1.2

            Dim webRequest As HttpWebRequest = CType(Net.WebRequest.Create("https://www2.roa.es/cgi-bin/horautc"), HttpWebRequest)
            webRequest.Method = "GET"
            Dim respuesta As HttpWebResponse = CType(webRequest.GetResponse(), HttpWebResponse)

            If respuesta.StatusCode = HttpStatusCode.OK Then
                Dim strmRespuesta As Stream = respuesta.GetResponseStream()
                Dim leeRespuesta As New StreamReader(strmRespuesta)
                Dim jsonRespuesta As String = leeRespuesta.ReadToEnd()
                Dim ticks As Long = Long.Parse(jsonRespuesta.Replace("\n", ""))
                Dim fechora As DateTime = Org.BouncyCastle.Utilities.Date.DateTimeUtilities.UnixMsToDateTime(ticks).ToLocalTime()
                retorno = fechora.ToString("yyyy-MM-dd'T'HH:mm:ssK")
            End If

        Catch Ex As Exception
            'MsgBox(Ex.Message, MsgBoxStyle.OkOnly, "ObtenerFechaHora - Internet")
        End Try


        '-------------------------------------------
        '2 - COGEMOS LA HORA DEL SERVIDOR SQL
        '-------------------------------------------

        If retorno = "" Then
            Try
                Dim DAHora As New SqlDataAdapter
                Dim DSHora As New DataSet
                Dim SqlHora As String = "SELECT SYSDATETIMEOFFSET() AS FechaActual"
                DSHora.Reset()
                DAHora = New SqlDataAdapter(SqlHora, Conexion)
                DAHora.Fill(DSHora, "Hora")

                If DSHora.Tables("Hora").Rows.Count = 1 Then
                    Dim RowHora As DataRow = DSHora.Tables("Hora").Rows(0)

                    Dim fechora As DateTime = RowHora.Item("FechaActual").ToString
                    retorno = fechora.ToString("yyyy-MM-dd'T'HH:mm:ssK")
                End If

                DAHora.Dispose()
                DSHora.Dispose()

            Catch Ex As Exception
                'MsgBox(Ex.Message, MsgBoxStyle.OkOnly, "ObtenerFechaHora - Servidor")
            End Try
        End If


        '-------------------------------------------
        '2 - COGEMOS LA HORA DEL EQUIPO
        '-------------------------------------------

        If retorno = "" Then
            retorno = DateTime.Now.ToString("yyyy-MM-dd'T'HH:mm:ssK")
        End If

        Return retorno
    End Function

Primero intenta cogerla de internet, si no es capaz del servidor sql y si no es capaz del equipo

La primera puede dar error si no hay internet o no responde ROA... la segunda debería devolver siempre (si no hay conexión al servidor ya no va a funcionar la aplicación)

Espero que te sirva!
Responder Con Cita
  #9  
Antiguo Hace 2 Semanas
rci rci is offline
Miembro
 
Registrado: nov 2020
Posts: 416
Poder: 5
rci Va por buen camino
Cita:
Empezado por Jarogo08 Ver Mensaje
¿y no puedes crear una función en el Visual que te devuelva un string, con el formato que necesita Verifactu?

si haciendo el "SYSDATETIMEOFFSET" obtienes algo como esto: "2025-04-16 16:44:01.6718891 +02:00"

y Verifactu necesita algo como esto: "2025-04-16T16:44:01+02:00"

entiendo que no sería difícil crear una función que haga la consulta, la ponga en el formato de Verifactu y la devuelva como string.
Hola Jarogo08, este no es exactamente el problema.
Si utilizo un string para almacenar la FechaHoraHusoGenRegistro al generar el registro, ya se guarda correctamente PERO, con las clases que se genera en Visual Studio al importar el WSDL, el campo no es string sino DateTime.

Para utilizar ese string tendría que hacer una de las opciones 2 o 3 que comento en el primer post y que intento evitar

Muchas gracias igualmente
Responder Con Cita
  #10  
Antiguo Hace 2 Semanas
Jarogo08 Jarogo08 is offline
Miembro
 
Registrado: ene 2025
Posts: 78
Poder: 1
Jarogo08 Va por buen camino
Cita:
Empezado por rci Ver Mensaje
Si utilizo un string para almacenar la FechaHoraHusoGenRegistro al generar el registro, ya se guarda correctamente PERO, con las clases que se genera en Visual Studio al importar el WSDL, el campo no es string sino DateTime.

pues a mi usando el objeto me deja asignarle un campo string:

Código:
CType(objectoFactEmitida.RegistroFactura(x).Item, RegistroFacturacionAltaType).FechaHoraHusoGenRegistro = Row.Item("FechaHoraHusoGenRegistro")
CType(objectoFactEmitida.RegistroFactura(x).Item, RegistroFacturacionAltaType).TipoHuella = TipoHuellaType.Item01
CType(objectoFactEmitida.RegistroFactura(x).Item, RegistroFacturacionAltaType).Huella = Row.Item("HuellaVerifactu")
donde "FechaHoraHusoGenRegistro" es un varchar(50) en la tabla del SQL Server
Responder Con Cita
  #11  
Antiguo Hace 2 Semanas
rci rci is offline
Miembro
 
Registrado: nov 2020
Posts: 416
Poder: 5
rci Va por buen camino
Cita:
Empezado por Jarogo08 Ver Mensaje
pues a mi usando el objeto me deja asignarle un campo string:

Código:
CType(objectoFactEmitida.RegistroFactura(x).Item, RegistroFacturacionAltaType).FechaHoraHusoGenRegistro = Row.Item("FechaHoraHusoGenRegistro")
CType(objectoFactEmitida.RegistroFactura(x).Item, RegistroFacturacionAltaType).TipoHuella = TipoHuellaType.Item01
CType(objectoFactEmitida.RegistroFactura(x).Item, RegistroFacturacionAltaType).Huella = Row.Item("HuellaVerifactu")
donde "FechaHoraHusoGenRegistro" es un varchar(50) en la tabla del SQL Server
Supongo que en tu caso, la propiedad FechaHoraHusoGenRegistro del objeto RegistroFacturacionAltaType es de tipo string y lo permite.
En nuestro caso es DateTime y no puedo hacer esa asignación directa sin convertir.

Al importar el WSDL dentro del fichero reference.cs genera el campo así:
Código:
    /// <remarks/>
    [System.Xml.Serialization.XmlElementAttribute(Order=25)]
    public System.DateTime FechaHoraHusoGenRegistro {
        get {
            return this.fechaHoraHusoGenRegistroField;
        }
        set {
            this.fechaHoraHusoGenRegistroField = value;
            this.RaisePropertyChanged("FechaHoraHusoGenRegistro");
        }
    }
y dentro del fichero SuministroInformacion.xsd también indica dateTime

Código:
<element name="FechaHoraHusoGenRegistro" type="dateTime" />

Gracias igualmente

Última edición por rci fecha: Hace 2 Semanas a las 17:58:53.
Responder Con Cita
  #12  
Antiguo Hace 2 Semanas
Jarogo08 Jarogo08 is offline
Miembro
 
Registrado: ene 2025
Posts: 78
Poder: 1
Jarogo08 Va por buen camino
a mi también me dice que es de tipo Date. Entiendo que a todo el mundo debería decirle lo mismo, porque estamos importando el mismo wsdl:


Código:
        '''<remarks/>
        Public Property FechaHoraHusoGenRegistro() As Date
            Get
                Return Me.fechaHoraHusoGenRegistroField
            End Get
            Set
                Me.fechaHoraHusoGenRegistroField = value
            End Set
        End Property

pero me traga cuando lo que le envío es un string:
Código:
CType(objectoFactEmitida.RegistroFactura(x).Item, RegistroFacturacionAnulacionType).FechaHoraHusoGenRegistro = Row.Item("FechaHoraHusoGenRegistro")
no sé a que puede ser debido, pero te facilitaría mucho si te dejara!
Responder Con Cita
  #13  
Antiguo Hace 2 Semanas
rci rci is offline
Miembro
 
Registrado: nov 2020
Posts: 416
Poder: 5
rci Va por buen camino
Cita:
Empezado por Jarogo08 Ver Mensaje
a mi también me dice que es de tipo Date. Entiendo que a todo el mundo debería decirle lo mismo, porque estamos importando el mismo wsdl:


Código:
        '''<remarks/>
        Public Property FechaHoraHusoGenRegistro() As Date
            Get
                Return Me.fechaHoraHusoGenRegistroField
            End Get
            Set
                Me.fechaHoraHusoGenRegistroField = value
            End Set
        End Property

pero me traga cuando lo que le envío es un string:
Código:
CType(objectoFactEmitida.RegistroFactura(x).Item, RegistroFacturacionAnulacionType).FechaHoraHusoGenRegistro = Row.Item("FechaHoraHusoGenRegistro")
no sé a que puede ser debido, pero te facilitaría mucho si te dejara!
Pues sí

Imagino que Visual Basic lo trata diferente que C#

De todas formas también afecta a la hora de enviar. Si el objeto es DateTime, no tiene información del huso horario y coge la configuración del ordenador que envía, y aquí viene el problema si no es la misma que el ordenador que generó el registro de facturación.

Gracias

Última edición por rci fecha: Hace 2 Semanas a las 18:27:17.
Responder Con Cita
  #14  
Antiguo Hace 2 Semanas
Avatar de bmfranky
bmfranky bmfranky is offline
Miembro
 
Registrado: may 2024
Ubicación: Gandia, Valencia
Posts: 599
Poder: 1
bmfranky Va por buen camino
Fechaora internet con uso horadio

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.
__________________
Uno se alegra de ser útil. (Isaac Asimov)
Responder Con Cita
  #15  
Antiguo Hace 2 Semanas
Avatar de bmfranky
bmfranky bmfranky is offline
Miembro
 
Registrado: may 2024
Ubicación: Gandia, Valencia
Posts: 599
Poder: 1
bmfranky Va por buen camino
Cita:
Empezado por rci Ver Mensaje
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.
__________________
Uno se alegra de ser útil. (Isaac Asimov)
Responder Con Cita
  #16  
Antiguo Hace 2 Semanas
rci rci is offline
Miembro
 
Registrado: nov 2020
Posts: 416
Poder: 5
rci Va por buen camino
Cita:
Empezado por bmfranky Ver Mensaje
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.

Cita:
Empezado por bmfranky Ver Mensaje
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
Responder Con Cita
  #17  
Antiguo Hace 1 Semanas
Avatar de bmfranky
bmfranky bmfranky is offline
Miembro
 
Registrado: may 2024
Ubicación: Gandia, Valencia
Posts: 599
Poder: 1
bmfranky Va por buen camino
Cita:
Empezado por rci Ver Mensaje
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.
__________________
Uno se alegra de ser útil. (Isaac Asimov)
Responder Con Cita
  #18  
Antiguo Hace 1 Semana
rci rci is offline
Miembro
 
Registrado: nov 2020
Posts: 416
Poder: 5
rci Va por buen camino
Cita:
Empezado por bmfranky Ver Mensaje
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
Responder Con Cita
  #19  
Antiguo Hace 1 Semana
FelixDL FelixDL is offline
Miembro
 
Registrado: ene 2025
Ubicación: Valladolid - España
Posts: 11
Poder: 0
FelixDL Va por buen camino
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
Responder Con Cita
  #20  
Antiguo Hace 1 Semana
rci rci is offline
Miembro
 
Registrado: nov 2020
Posts: 416
Poder: 5
rci Va por buen camino
Cita:
Empezado por FelixDL Ver Mensaje
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
Responder Con Cita
Respuesta



Normas de Publicación
no Puedes crear nuevos temas
no Puedes responder a temas
no Puedes adjuntar archivos
no Puedes editar tus mensajes

El código vB está habilitado
Las caritas están habilitado
Código [IMG] está habilitado
Código HTML está deshabilitado
Saltar a Foro

Temas Similares
Tema Autor Foro Respuestas Último mensaje
Consultas por franja horaria petercat SQL 2 17-04-2018 09:12:29
Obtener zona horaria en window 8 ingabraham Varios 0 28-08-2013 17:53:04
como caambiar la zona horaria desde delphi kurono Varios 4 19-08-2008 06:53:36
Zona Horaria palets API de Windows 2 23-10-2006 19:44:57
Zona horaria Genner Varios 1 17-04-2006 14:22:20


La franja horaria es GMT +2. Ahora son las 09:17:49.


Powered by vBulletin® Version 3.6.8
Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
Traducción al castellano por el equipo de moderadores del Club Delphi
Copyright 1996-2007 Club Delphi