Diferencia máxima de 120 segundos???
 

Buenas gente,

Me explota la cabeza con esto de la diferencia horaria ... el campo FechaHoraHusoGenRegistro se completa cuando se genera el fichero de alta, es decir, cuando se hace la factura simplificada o factura regular (o anulación o lo que sea), vale que lo vamos a enviar al instante (o en mi caso con un temporizador de 1 minuto), pero leñe:

- ¿que pasa si el usuario tiene un corte de suministro de red?
- ¿que pasa si tenemos una respuesta del envio anterior de esperar 60 segundos?

Esta restriccion de FechaHoraHusoGenRegistro no tiene sentido . ¿como lo gestionais?

Saludos.

Yo he puesto desde que creo el primer registro de facturación hasta que lo envio un contador y si se pasa de 120' marco como incidencia la cabecera, en principio no debe pasar más de unos segundos entre la creación y el envio. De momento lo tengo así, no se si le dare alguna vuelta más.
Por otro lado si no se puede enviar porque hay un corte, fallo router, el certificado esta caducado, etc.. lo marco tambien con incidencia S y cuando se pueda enviar se enviara.

Si, creo que no hay otra.

Hay otra, no mucho más pero mejorable

privado si queréis info

Con respecto a esto, ¿donde está establecido que la diferencia debe de ser máximo de 120 segundos (o lo establecido con la anterior respuesta al envío) con este campo?


En el documento de validaciones, lo único que dice es que este campo debe de ser "igual o inferior" a la hora del servidor de la AEAT, como es lógico.



Si hay algún otro sitio donde se establezca otra cosa, ¿podéis indicarme donde?

Pues ahora mismo no recuerdo muy bien donde lo lei ... pero el caso es que cuando hacía envios con tiempo pasado de esos 120 segundos el servidor de pruebas me los rechazaba, probaré de nuevo a ver.

A ver, es un algoritmo lógico,
En cada respuesta te devuelven en el nodo [tiempo]
El tiempo mínimo que tienes que esperar para el siguiente envío o, en sí defecto,si tienes ya 1000registros, el envío tiene que ser inmediato si tienes registrosdespues de ese tiempo de espera, PEROOO, como puedes tener un minuto de diferencia de margen con el reloj de ellos, te dan ese minuto para enviar. Y como el tiempo inicial de espera que te Dan es de 60segundos pues después de un envío esperas 60 segundos para el siguiente y si tienes algo tienes 60 para enviar por eso hablamos 120segundos, pero depende del escenario del que te encuentres en cada instante.

Simplemente fijese en lo que devuelve cuando hay error de desfase del registro.

Aún no he generado registros que superen el umbral, así que lo provocaré próximamente.

Lo que creo es que el documento de Validaciones, este extremo no está correctamente definido, pues hablan que esa fecha/hora debe ser menor o igual a la de la AEAT, es decir, que provocaría rechazo si es superior a la de la AEAT.

Se me ocurren varios casos en que puede suceder, que se envíe la factura, por ejemplo, el día siguiente, porque el último usuario conectado crea la factura, e inmediatamente sale del sistema y se marcha a su casa, la factura se puede quedar sin enviar porque aún no ha pasado el tiempo necesario para poder realizar el envío desde el anterior. Cuando se envíe, la fecha hora del registro es menor o igual a la de la AEAT, pero ya me estáis diciendo que me va a producir un aviso de error, supongo que sin rechazo, como dicen en el documento.

La acepta con errores, así que tampoco es tan grave pienso yo. Se puede quedar tranquilamente.

Hola, donde viste lo de igual o menor, he mandado registros con 5 segundos por delante y se los ha comido
Si mandas muy tarde tienes que marcarlo como incidencia. Y te recomiendo un apr de cosas, proceso en segundo plano de envío ue no lo puedan cerrar y una comprobación al apagar el equipo

Revisando he visto que si desde que se creo el RF hasta que se envia han pasado más de 120s lo marco como incidencia, no es normal que tarde tanto, algo esta pasando, así que como dijo ermendalenda yo tambien lo marco como incidencia.

Como era de esperar, tenéis toda la razón.

Habrá que marcar entonces como incidencia antes del envío, que ahí ya sabemos si nos pasamos o no de los 120 segundos.

Gracias a todos.

Lo de igual o menor está especificado en el documento de validaciones. Está claro de que no es así.

Lo del proceso en segundo plano, así lo estoy haciendo, y lo que quería decir con lo de cerrar la aplicación, es que si queda algo por enviar y aún no han pasado los 60 segundos (o los que sean que indique Hacienda), aunque hagas el proceso si no es la hora no envía. No sé, algo habrá que pensar para estos casos. Supongo que en nuestros clientes grandes este problema no existirá porque siempre habrá alguien con el programa abierto, pero los pequeños con 1 sólo puesto o pocos puestos, son los que casi me preocupan más. Pero bueno, esto creo que ocurrirá raramente. Se hace al día siguiente lo de incidencia, y tiramos para adelante.


De todos modos, ojo, porque estoy viendo que aunque las marque como "aceptadasconerrores", hay que proceder a su "subsanación". Ver puntos 4.3 y 4.4 del documento de validaciones. ¿o si le ponéis incidencia no las marca como aceptadas con errores?

Yo no creo que hay que subsanarlos en ese caso, ya que en la O.M. pone más adelante que este pueden requerir que aportes por que han sido las incidencias, aunque esto se dará, supongo, en casos extremos de demasiadas incidencias. Aunque no estaría de más que alguien lo consultara, pero no 1lo veo lógico, ya les has identificado que hay un problema y sería un doble trabajo y puede darse el caso que hayas tenido un problema de varios días y no vas a mandar 2 veces lo mismo, como incidencia y después como subsanacion, no lo veo.
Yo le he puesto que si no envía. A los 110 segundoa o más bien a [t]+50(es más correcto) que lo marque, pata dejar esos 10 segundos de margen de envío por posibles ralentizaciones o descuadres de horas respecto a la hora de ellos
Perdona perdona, corrijo, di lo has enviado sin marcar incidencia es otra historia, habrá que consultar si hay que mandarlo posteriormente como subsanacion, ya que en ese caso es que no tienes bien el control de flujo para identificarlo antes ee enviarla de que esta fuera de hora o tienes el reloj mal.

Hoy voy a probar a mandarlo fuera de plazo como incidencia, a ver si la respuesta es la misma. Luego digo.

Te la va aceptar ok.

Por otro lado, cuando me refiero a segundo plano, me refiero además, que este en otro ejecutable que no puedan cerrar, además, tanto Windows como Linux tienen opciones para ejecutar programas al apagar el equipo, con lo cual puedes meterme que se espere el tiempo que necesites para enviar lo que quede pendiente y si no queda nada cerrar la aplicación y ya se apaga automáticamente.
Ten en cuenta que en Windows si le das a apagar se cierra todo y después ejecuta lo que hayas puesto en la hilera de apagado, con lo cual tienes que reabrir el programa de envío y cerrarlo cuando acabe lo pendiente

Adjunto imagen de como lo tengo

Para añadir el scrip de apagado, que puede ser un exe, un bat....
se añade desde [ejecutar programa](cmd)/gpedit.msc
desspues vas en las directivas de seguridad local a [Configuracion del equipo][configuracion de windows][Scripts de inicio apagado] y en el lado derecho eliges apagado y le añades lo que quieras ejecutar.
Adjunto Imagen

Ya he enviado la consulta a verifactu si es necesario enviar la subsanacion.
Me responderán rápido como es habitual

Respondido

Pues si ,:cool:lo pone alli....

Ahora continuar con los otros 2000....

Servicio en Windows para envíos
 

Buenas tardes, para el envío de registros de facturación tenía pensado crear un servicio windows que cada x segundos (20 por ejemplo) se activara y si se cumplieran las condiciones para enviar registros a AEAT ( ya hubiera 1000 registros o más o que hubiera transcurrido el tiempo definido desde el último envío ) los enviara. Después de enviarlos, actualizaría el tiempo para el siguiente envío que me devuelve la AEAT.

La duda se me plantea en un sistema multiempresa, en el que hay que enviar los registros de facturación por cada empresa (objeto tributario). ¿ Se deberían enviar los registros de facturación de todas las empresas y luego actualizar el tiempo de espera o debería enviar la primera empresa, esperar el tiempo que marque aeat en su contestación, enviar la segunda empresa .... y así sucesivamente ?

Muchas gracias por vuestras respuestas.

Yo entiendo que cada empresa tiene que llevar su camino, es decir, cada empresa debe de enviar sus registros de forma independiente cumpliendo los parámetros de tiempo, número de registros, etc. Mi opinión es que deberías de crear un servicio por cada empresa para no liar mucho la cosa.



Saludos.

No hay que esperar tiempos entre envios de distintas empresas hay que cumplir los tiempos o n registros(1000) de la misma empresa, ya decides como programarlo, yo lo tengo diferenciado con arrays dentro del mismo modulo fe envio (servicio en segundo plano) . Pero como dice el compañero te puedd resultar más fácil separarlo en distintos servicios.
Otra cosa, no sé si es correcto decir de la misma empresa, ya que un servicio de envío puede estar funcionando para distintos SIF de la misma empresa por que centraliza los envios, no así el encadenamiento por alguna dificultad en ello, por ejemplo por que estés usando un servicio de envío por terceros (uses un cif para enviar todo), en ese caso tienes que tener en cuenta que cada SIF que gestiones en el envío tiene que ser independiente

Muchas gracias por vuestra respuesta.

Acabo de recibir contestación de verifactu y va por ese camino "El tiempo de espera es por cada SIF y dentro de cada SIF, por cada uno de los obligados tributarios.

La duda que me surge es que si opto por un único servicio para todas las empresas, se entiende que el algoritmo sería localizar las empresas con registros a enviar (que cumplan los requisitos de envío ) e iterar entre cada una de ellas haciendo el envío de estos registros.... Primero una empresa, luego la otra y así sucesivamente.

¿ Qué pasaría si hay un retraso significativo en la contestación de aeat para las siguiente empresas que estaban en cola de envío (podría no cumplirse el tiempo máximo de 120 segundos) ?

Con la opción de un servicio por empresa supongo que no pasaría esta situación....

Supongo que en ese caso lo mejor seria hacer hilos de ejecución (threads) independientes para cada cif emisor. Cada uno con su control de flujo.

Buenas tardes, me estoy volviendo un poco loca con este error:


Error no.: 2004 El valor del campo FechaHoraHusoGenRegistro debe ser la fecha actual del sistema de la AEAT, admitiéndose un margen de error de: 120 segundos.



Realizo la consulta de la hora en teoria "oficial" pero me sigue saliendo el mismo error. Algo no debo entender bien :confused:.


No será por los milisegundos...


Alguien tiene este problema?

Cuando creas el RF le pones la Fecha y Hora si cuando llegue al servidor de AEAT han pasado más de 120 segundos te devolvera ese aviso.

Lo envío inmediatamente, por eso no lo entiendo.

Hola, si es por los milisegundos, yo tenia ese problema al pasarle el timestamp, al final lo formatee yo en un string.


Para c# @rci me paso esta solucion.

Hola.


Prueba con esta forma de generar ese dato:

Código Delphi [-]
  DateTime:=now;
  XSDatetime := TXSDatetime.Create;
  XSDateTime.AsDateTime := dateTime;
  Factura.RegistroAlta.FechaHoraHusoGenRegistro := XSDateTime;

La variable XSDatetime es del tipo TXSDatetime y tienes que poner en el uses Soap.XSBuiltIns


Saludos.

Y lo hacía así pero me daba error:


Error no.: 1244 El campo FechaHoraHusoGenRegistro tiene un formato incorrecto.


Lo cambie por:

Código Delphi [-]XSDatetime := TXSDatetime.Create; XSDatetime.AsUTCDateTime :=getAhora;//Now; //XSDatetime.HourOffset:=1; //XSDatetime.UseZeroMilliseconds:=false; Factura.RegistroAlta.FechaHoraHusoGenRegistro :=XSDatetime;



Me lo acepta pero con errores:


Error no.: 2004 El valor del campo FechaHoraHusoGenRegistro debe ser la fecha actual del sistema de la AEAT, admitiéndose un margen de error de: 120 segundos. RefExterna=2219518
TimestampPresentacion: 26/02/2025 18:06:21

Buenas jodaws


Creo que no tienes bien el formato. Tiene que ser algo así (sin milisegundos y con el +01:00 de la franja horaria):


2025-02-26T12:18:25+01:00


Yo lo obtengo así y me va sin problemas (es en VB. NET)


Dim retorno As String = DateTime.Now.ToString("yyyy-MM-dd'T'HH:mm:ssK")


espero que te sirva!

Es que no lo puedo formatear yo o no sé como hacerlo, ya que tengo un tipo TXSDateTime. No le puedo asignar un string directamente... A ver si hay alguien en Delphi que lo haya solucionado y me da luz

Ok, ya sé lo que te pasa. Es por los milisegundos. Prueba a hacerlo así:

Código Delphi [-]
  XSDateTime.AsDateTime := dateTime;
  Factura.RegistroAlta.FechaHoraHusoGenRegistro := XSDateTime;
  Factura.RegistroAlta.FechaHoraHusoGenRegistro.FractionalSeconds:=0;

Saludos.

Muchas gracias a todos!Pues así lo ha hecho bien pero ahora me salta error en el cálculo de la huella :(


Edito: la huella debe estar en mayúsculas!

No das muchas pistas sobre lo que te pasa con la huella, por si te sirve de algo yo lo hago así:

Código Delphi [-]
  // Calculo huella
  sAux:='IDEmisorFactura='+Edit2.Text+'&NumSerieFactura='+Factura.RegistroAlta.IDFactura.NumSerieFactu  ra+'&FechaExpedicionFactura='+Factura.RegistroAlta.IDFactura.FechaExpedicionFactura;
 sAux:=sAux+'&TipoFactura='+ListaCampos[2]+'&CuotaTotal='+Factura.RegistroAlta.CuotaTotal+'&ImporteTotal='+Factura.RegistroAlta.ImporteTotal+'  &Huella='+Edit18.Text+'&FechaHoraHusoGenRegistro='+XSDateTime.NativeToXS;
  Huella:=UpperCase(HashSHA256(sAux));
  Factura.RegistroAlta.TipoHuella := TipoHuellaType._01;
  Factura.RegistroAlta.Huella     := Huella;

No creo que tengas mucho problema en adivinar unas cuantas variables que hay en esas líneas.


y la función HashSHA256:

Código Delphi [-]
function HashSha256(const APassword: string): string;
var
  SHA256: THashSHA2;
begin
  SHA256 := THashSHA2.Create;
  try
    Result := SHA256.GetHashString(APassword);
  finally
    FreeAndNil(SHA256);
  end;
end;

Saludos.

Muchas gracias y disculpad, quería decir que la huella debe estar en mayúsculas y ya me ha funcionado correctamente.