Cita:
Empezado por nincillo
Per la verdad es que cuando te pones a pensar que puede haber varios equipos a la vez facturando con la misma serie, buff, la posibilidad de combinaciones es grande. Si se da el caso de que estén facturando simultáneamente, quizás el primer equipo aún no generó del todo el xml, y el segundo equipo está intentando leer información del xml que aún no se generó o no del todo... En fin...
|
Es un problema clásico de cola, con un recurso único. Cuando cualquier programa (de varios) está listo para encadenar (es decir, XML del registro generado hasta la parte EncadenamientoRegistroAnterior), se pone en cola para obtener esta información. Él que está en cabeza de la cola entra en sección crítica (mútex), recupera la información del último registro (ID, huella y hora de generación), recupera la hora actual, acaba de completar el XML, calcula su huella, graba el registro ya completado con su DatosControl (la firma se podrá actualizar más tarde, y evidentemente las incidencias también), este registro pasa a ser el último, y puede salir de la sección crítica, liberando para el siguiente en la cola.
El tema de los números de nueva factura pueden gestionarse de la misma manera, es decir atribulándose dentro de la sección crítica; pero no tengo claro si es un requisito imprescindible de los sistemas de facturación que los registros de factura tipo S0 sigan encadenados en orden estrictamente ascendente de número de factura en cada serie (muy posible que me he perdido algo aquí). Obviamente es muy preferible, pero creo que se puede haber circunstancias como las que describes que hacen que los números pueden resultar desordenados a veces, en caso de incidencia en la generación del registro después de haber obtenido un número de futura factura. Y desde luego, dado que el número de factura está mezclado con el número de serie en el campo IDFactura, no veo como Hacienda puede automatizar un control de este requisito.