Ojo con el TimeStamp de Respuesta

[ermendalenda]

Empezado por Rja750

En mi caso no uso la fecha del sistema ni de la AEAT, porque la AEAT va a estar muchas veces caida y el registro deberiamos grabarlo si o si en nuestros SIF y darle la factura verificable al cliente final. Si no quieres seguir facturando sin tener conexion a la AEAT pues un control en nuestro registro a modo de campo y aviso en pantalla y no seguimos facturando hasta que se restablezca la conexion con la AEAT (Bucle Timer), Una vez restablecida la comunicacion se envia el ultimo registro como se tenga que enviar y a seguir facturando. Pero la hora tiene que ser exacta, de lo contrario nos va a dar mucho dolor de cabeza tener registros rechazados por fechas, horas y huellas que no coinciden apilados en los clientes. Si tenemos un cliente que no se ha dado cuenta de que tiene la fecha y hora mal ¿que hacemos? Le podemos poner un control y decirle que cambie la pila de la CPU o pasamos de eso y mientras que su SO funcione y tenga internet, calculamos la fecha y hora fuera del Sistema, calculamos si estamos en invierno o verano para aplicar a la UTC el horario que tenemos en España(península) UTC + 1 o nó, pero todo fuera del sistema y de la AEAT que tambien cojera la hora por servidores sincronizados por satélite como Nopuedoponerenlaces.roa.es/cgi-bin/horautc
Este codigo está en VB.net para el que le venga bien. Esta comentado
Try
'Puede que tengas que ponerlo para asegurarte que el servidor no te rechaza por falta de seguridad
ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12

Dim url As String = "Nopuedoponerenlaces.roa.es/cgi-bin/horautc"

Dim request As WebRequest = WebRequest.Create(url)
request.Timeout = 5000 ' Tiempo de espera de 5 segundos creo que sobrado

Dim response As WebResponse = request.GetResponse() ' obtengo la respuesta del servidor

Dim responseText As String
Using stream As Stream = response.GetResponseStream()
Using reader As New StreamReader(stream)
responseText = reader.ReadToEnd().Trim() ' Limpiar espacios o caracteres extra
End Using
End Using

' Tenemos una respuesta en una cadena de numeros(String) y hay que convertirla a un número de milisegundos
Dim timestamp As Long
If Long.TryParse(responseText, timestamp) Then 'Esta comprobacion la podemos omitir porque responseText siempre sera una cadena de numeros convertible a long pero bueno...
Dim utcTime As DateTime = DateTimeOffset.FromUnixTimeMilliseconds(timestamp).UtcDateTime

'Determinar si estamos en horario de verano o invierno en España
Dim year As Integer = utcTime.Year
Dim ultimoMarzo As DateTime = New DateTime(year, 3, DateTime.DaysInMonth(year, 3))

' Buscamos el último domingo de marzo que es cuando entra el horario de verano)
While ultimoMarzo.DayOfWeek <> DayOfWeek.Sunday
ultimoMarzo = ultimoMarzo.AddDays(-1)
End While
ultimoMarzo = New DateTime(year, 3, ultimoMarzo.Day, 2, 0, 0, DateTimeKind.Utc)

' Buscamos el último domingo de octubre que es cuando termina el horario de verano
Dim ultimoOctubre As DateTime = New DateTime(year, 10, DateTime.DaysInMonth(year, 10))

While ultimoOctubre.DayOfWeek <> DayOfWeek.Sunday
ultimoOctubre = ultimoOctubre.AddDays(-1)
End While
ultimoOctubre = New DateTime(year, 10, ultimoOctubre.Day, 1, 0, 0, DateTimeKind.Utc)

' Si estamos entre marzo y octubre estamos en horario de verano si no estamos en horario de invierno
Dim esHorarioVerano As Boolean = utcTime >= ultimoMarzo AndAlso utcTime < ultimoOctubre

' Aplicamos 2 o 1 segun sea
Dim offsetEspaña As Integer = If(esHorarioVerano, 2, 1)

' Calculamos la hora en España sin tener en cuenta el sistema
Dim horaLocalEspaña As DateTime = utcTime.AddHours(offsetEspaña)

' lo muestro para que se vea, pero cada cual aplica a su forma
MsgBox("Hora ajustada en España (Península): " & horaLocalEspaña.ToString("yyyy-MM-dd HH:mm:ss") & " (UTC+" & offsetEspaña & ")")
Else
MsgBox("Error: No se pudo interpretar el timestamp del servidor.")
End If

Catch ex As Exception
MsgBox("Error al obtener la hora UTC: " & ex.Message)
End Try

Hola
Ya cada uno que diseñe como crea más conveniente, pero no acabo de entender algunas cuestiones que planteas, por ejemplo la hora se coge del ROA(armada) no es de la aeat.
Otra cosa 3s el timestamp de la respuesta del ultimo envio.
Por otro lado dices como de darle la posibilidaf(supongo que te refieres a parametrizae) la decisión de que si no se puede enviar no se puede facturar, cosa que particularmente veo un error por varios motivos, primero que el vendedor tiene que tener instrucciones de que hacer en ese caso(se lo anota?, le dice al valiente que no se factura?, se vende pero sin facturar?) Otra cosa que tu sistema dependa de Internet para generar los qr, so no no tiene sentido, se acumula y se envía como incidencia cuando vuelva imternet, pararlo es más negativo que positivo. No sé, cada uno vé claro su operativa según su soft2are y el tipo de clientes.

[ermendalenda]

Otra cosa, octubre de 2026 es, presumiblemente, el último cambio de horario, com lo cual nos quedarimos con horario de invierno eternamente( a mi particularmente me gusta mas el horario de verano incluso para invierno). Me lo he dejado previsto, incluso parametrizado por si vuelven a cambiar de idea, y esa fecha está ahí al lado.
Por otro lado si vas a controlar las horas es recomendable desactivar de Windows/linux/otros cualquier intención de estos de cambios automáticos

[Rja750]

Empezado por ermendalenda

Hola
Ya cada uno que diseñe como crea más conveniente, pero no acabo de entender algunas cuestiones que planteas, por ejemplo la hora se coge del ROA(armada) no es de la aeat.
Otra cosa 3s el timestamp de la respuesta del ultimo envio.
Por otro lado dices como de darle la posibilidaf(supongo que te refieres a parametrizae) la decisión de que si no se puede enviar no se puede facturar, cosa que particularmente veo un error por varios motivos, primero que el vendedor tiene que tener instrucciones de que hacer en ese caso(se lo anota?, le dice al valiente que no se factura?, se vende pero sin facturar?) Otra cosa que tu sistema dependa de Internet para generar los qr, so no no tiene sentido, se acumula y se envía como incidencia cuando vuelva imternet, pararlo es más negativo que positivo. No sé, cada uno vé claro su operativa según su soft2are y el tipo de clientes.

Me refiero a que cuando no haya conexión con la AEAT se puede seguir haciendo facturas proformas igualmente verificable y encadenadas sin intentar de nuevo enviarlas hasta que no se restablezca la conexión y entonces enviarlas con incidencia pero exactamente igual o en el caso que tengas que hacer 20 facturas hoy en la mañana, si no tengo conexión facturo por la tarde. Imagínate que alguien ha hecho una remesa a sus clientes y debe enviarle las facturas a sus correspondientes email, puede hacerlo por la mañana o por la tarde. Es según a lo que este enfocado el SIF y el negocio que se gestiona.
He hablado con algunos gestores y me comentan que tienen muchos problemas con la conexión con la AEAT en el envío de documentación y no es nuevo de ahora, imagino que cuando estemos todos atacando a sus servidores va a ser lo más. Bueno el tema del desfase horario si lo van a quitar simplificaría más el código pero tendremos que tenerlo en cuenta.

[ermendalenda]

Empezado por Rja750

Me refiero a que cuando no haya conexión con la AEAT se puede seguir haciendo facturas proformas igualmente verificable y encadenadas sin intentar de nuevo enviarlas hasta que no se restablezca la conexión y entonces enviarlas con incidencia pero exactamente igual o en el caso que tengas que hacer 20 facturas hoy en la mañana, si no tengo conexión facturo por la tarde. Imagínate que alguien ha hecho una remesa a sus clientes y debe enviarle las facturas a sus correspondientes email, puede hacerlo por la mañana o por la tarde. Es según a lo que este enfocado el SIF y el negocio que se gestiona.
He hablado con algunos gestores y me comentan que tienen muchos problemas con la conexión con la AEAT en el envío de documentación y no es nuevo de ahora, imagino que cuando estemos todos atacando a sus servidores va a ser lo más. Bueno el tema del desfase horario si lo van a quitar simplificaría más el código pero tendremos que tenerlo en cuenta.

No te creas, el SII está funcionando bien.
Sigo sin entender muy bien tu prodecimiento, pero el que la lleva...Las proformas no llevan QR y las facturas normales se pueden generar e intentar enviar al momento , y se teintenta hasta que se pueda, si el problema es de ellos ya lo identificarán.

[Rja750]

Empezado por ermendalenda

No te creas, el SII está funcionando bien.
Sigo sin entender muy bien tu prodecimiento, pero el que la lleva...Las proformas no llevan QR y las facturas normales se pueden generar e intentar enviar al momento , y se teintenta hasta que se pueda, si el problema es de ellos ya lo identificarán.

Si yo envío una factura y no hay conexión no obtengo respuesta ¿no? simplemente no se ha enviado. Guardo esa factura como registro de mi SIF en mi BD y marco que no ha habido conexión, pero el cliente se lleva su factura verifactu, claro que al comprobar el QR obtendrá esta respuesta "En estos momentos no tenemos ese registro, inténtalo mas tarde" o algo así. Se sigue trabajando y emitimos la factura que le sigue con toda la operativa como si no hubiese pasado nada y ahora si hay conexión. ¿Que es lo que ocurre? ¿entra esa factura sin haber metido la anterior? imagino que no porque hay un salto y por ende un rechazo. Entonces ¿cual es la operativa? ¿dejamos de facturar para volver a enviar las dos factura con incidencia? y cuando hayamos acabado de enviar, ya podemos seguir facturando la siguiente? no tengo eso claro.

[Neftali [Germán.Estévez]]

Actualizo el mensaje #2 con la recopilación de códigos.
Gracias por compartirlos.

[ermendalenda]

Empezado por Rja750

Si yo envío una factura y no hay conexión no obtengo respuesta ¿no? simplemente no se ha enviado. Guardo esa factura como registro de mi SIF en mi BD y marco que no ha habido conexión, pero el cliente se lleva su factura verifactu, claro que al comprobar el QR obtendrá esta respuesta "En estos momentos no tenemos ese registro, inténtalo mas tarde" o algo así. Se sigue trabajando y emitimos la factura que le sigue con toda la operativa como si no hubiese pasado nada y ahora si hay conexión. ¿Que es lo que ocurre? ¿entra esa factura sin haber metido la anterior? imagino que no porque hay un salto y por ende un rechazo. Entonces ¿cual es la operativa? ¿dejamos de facturar para volver a enviar las dos factura con incidencia? y cuando hayamos acabado de enviar, ya podemos seguir facturando la siguiente? no tengo eso claro.

Hola
No puedes/debes poner el envío de la factura como parte de la operativa del cobro de la factura, o sea, hay unos controles definidos en la norma que te obligan a que esos envíos lo hagas en segundo plano, por ejemplo, hay que respetar unos tiempos de espera entre envios, también por el escenario que pones de ejemplo, si en un momento dato no hay conexión puedes seguir emitiendo y encadenando y cuando haya conexión tienes que volver. A comenzar el control de flujos, ver cuantas tienes pendientes de enviar, y enviarlas juntas en un soloenvio(máximo 1000 facturas), pero no puedes hacer saltar en los envíos, tiene que ser secuencialmente r3specto a su generación cronológica y encadenamiento.
Creo que te tienes que repasar la documentación de verifactu empezando por la Orden Ministerial.
Saludos

[rci]

Empezado por Rja750

Si yo envío una factura y no hay conexión no obtengo respuesta ¿no? simplemente no se ha enviado. Guardo esa factura como registro de mi SIF en mi BD y marco que no ha habido conexión, pero el cliente se lleva su factura verifactu, claro que al comprobar el QR obtendrá esta respuesta "En estos momentos no tenemos ese registro, inténtalo mas tarde" o algo así. Se sigue trabajando y emitimos la factura que le sigue con toda la operativa como si no hubiese pasado nada y ahora si hay conexión. ¿Que es lo que ocurre? ¿entra esa factura sin haber metido la anterior? imagino que no porque hay un salto y por ende un rechazo. Entonces ¿cual es la operativa? ¿dejamos de facturar para volver a enviar las dos factura con incidencia? y cuando hayamos acabado de enviar, ya podemos seguir facturando la siguiente? no tengo eso claro.

Yo creo que si que "entra la siguiente" y sin rechazo. Pero teóricamente vas reintentando enviar hasta que ya tienes conexión y cuando ya la tienes, empiezas a enviar por orden.

Exacto, eso que ha dicho ermendalenda

[Rja750]

Empezado por rci

Yo creo que si que "entra la siguiente" y sin rechazo. Pero teóricamente vas reintentando enviar hasta que ya tienes conexión y cuando ya la tienes, empiezas a enviar por orden.

Exacto, eso que ha dicho ermendalenda

Gracias. No sabia que se pudiera mandar con saltos y era lo que quería saber. Entonces la operativa cambia. Seguimos estudiando, aprendiendo y compartiendo.

[bmfranky]

Empezado por Rja750

Gracias. No sabia que se pudiera mandar con saltos y era lo que quería saber. Entonces la operativa cambia. Seguimos estudiando, aprendiendo y compartiendo.

Ojo, no se deve enviar con saltos, los envios han de ser correlativos, si no se puede enviar, bien por un problema tuyo , bien por un problema en la recepcion , etc...
Tienes que crear una cola de envios que pregunte periodicamente al servidor para saber si esta activo y enviarlos todos, hasta un maximo de 1000 y esperando los segundos que te indiquen o si llenas los 1000.

Pero los registros han de ir correlativos, no puedes enviar el 3 que has creado ahora y luego el 1 y 2 porque no estaba disponible el servidor, has de empaquetar 1,2 y 3 y enviarlos.