Tienes que tener claro varios aspectos de Verifactu para que puedas entender cómo debes encadenar:

1.- Un obligado tributario debe emitir facturas a lo largo de un año fiscal donde su campo SerieNumeroFactura no se repita.
2.- Se introduce el concepto de SIF (sistema informático de facturación) que es el encargado de emitir las facturas y generar los registros de facturación de cada factura, que posteriormente, enviamos a Aeat.
3.- Un mismo obligado puede tener varios SIF's, por ejemplo, un programa de facturación en el servidor central y un Tpv deslocalizado geográficamente que va enviando sus facturas generadas al SIF anterior para su recolección. Ambos pueden emitir facturas, por lo tanto, ambos deben generar sus registros de facturación y ambos deben enviarlos a la Aeat.
Si el Tpv no es capaz de generar facturas por sí mismo, debe enviar al SIf central el documento a emitir, el Sif central emitirá la factura, generará el registro de facturación, lo comunicará a la Aeat y le enviará la factura ya emitida al Tpv para que la imprima. Este es el caso de un sólo SIF con dos programas.
4.- El encadenamiento siempre es por SIF y fecha de creación del registro de facturación.

Espero haberte aclarado el asunto.

Ya. Pero el tiempo es lo que dice el programa que realiza el encadenamiento (no es la hora que dice el TPV sino la de la central, en el ejemplo). Entonces este orden por tiempo debe venir naturalmente.

No, segun entiendo, el tiempo, es el de generacion y entrega al cliente de la factura, que es el que se incluye en el QR.

La verdad es que ahun no he acabado de migrar mi programa a todos los requisitos y ya me estoy volviendo loco... ;-)

"generación" es en efecto sinónimo de encadenamiento (una incluye el otro). Es de lo que estoy hablando.
"Entrega al cliente de la factura" ocurrirá después. No tiene el porque de ser el mismo día, y por supuesto no a la misma segundo.

Creo que en el QR solo hay el día, no el detalle de la hora. Tiene que ser la fecha de expedición de la factura, que viene impresa en ella, y que no es exactamente lo mismo que el día de la fecha de generación del registro (son dos campos distintos; para saber si los contenidos deben ser idénticos, hay una discusión detallada sobre este tema en el hilo, y no quiero encender este debate otra vez.)

Tienes razon, la verdad depende del punto de vista, desde el mio , como genero la factura en el momento de realizar la Venta/ Reparacion, no tiene sentido que sean diferentes, pero si la venta, se difiere a la fecha de facturacion, es donde esta la pega.
Gracias ,por la respuesta, yo tampoco quiero encender ninguna discusion, intento entender el procedimiento a realizar y por ello doy "Mi" opinion, un saludo a Tod@s.

Hay una cosa que hay que tener en cuenta sobre el encadenamiento por SIF
Puede haber momentos desde un tpv que estés trabajando sobre una nube y cuando se caiga la nube trabajas en modo seguro sobre local.
Yo creo qie el SIF que hace el encadenamiento puede ser cada unidad de tov aunque trabaje sobre una nube y esa nube es la que genere el qr, puesto que cuando estés en modo local sigue por el mismo nunero y serie, se genera en local. No creo que la aeat sea tan Tiquismiquis y pretenda que entres en pánico.
Hay que se congruente en lo que puede ser un SIF. Para mi no hay una definición clara común.

No entiendo bien el planteamiento que haces. ¿ Podrías definirlo mejor ?

Encadenamiento En El Central
 

Alguien me podria decir que hacer en este caso?


Tengo tres usuarios que acceden a facturar a un servidor central. A cada uno se asigno la misma serie "FA" y el numero se le asigna a cada uno el ultimo + 1. Imaginad que asigno los numeros 1, 2 y 3 respectivamente. El problema es que los tiempos en que cada factura se cierra son distintos, osea, la factura 2 se cierra por completo antes que la factura 1 ya que consta de mas lineas y el usuario es mas lento. Lo mismo ocurre con la factura 3 , se cierra antes que la 1.


Totalmente listas y cerradas quedarian en este orden segun la hora de cierre:
fa-2 15:00:00

fa-3 15:05:00

fa-1 15:20:00


Como veis la serie y el numero es correlativo (1,2 y 3) pero la hora de cierre de la factura no. La encadenaria manteniendo entonces este orden basado en la hora de cierre (2,3,1) sin importar la serie y numero?


Si baso el encadenamiento en la fecha y hora de creacion y no de cierre entonces los numeros irian continuados (1,2,3) pero no sabria los totales de cada factura porque aun hay facturas abriertas y eso me impide encadenarlas. Ya se que con numeros y series temporales esto se subsanaria facilmente tal como dijo carlos en un post anterior pero estoy tanteando otras posibilidades.



En resumen....., se podria encadenar facturas de una misma serie cuyo numero no van correlativos en el tiempo? (asi podria indexar por hora de cierre, numero de factura) y se acabo el problema.

Ya te digo yo que te llaman a capítulo. La frase que dice textualmente el reglamento en su artículo 9, "... deberán generar automáticamente un registro de facturación de alta de forma simultánea o inmediatamente anterior a la expedición de cada factura." te obliga a utilizar un documento intermedio, ya que por expedición de la factura se entiende el momento en que se obtiene el número de factura válido para un documento y no el momento en que se termina la factura después de haber obtenido un número de factura válido y haber poblado todas sus líneas, descuentos, etc, de lo contario, no tendría sentido lo que dice ese punto del reglamento porque si no hemos terminado la factura no tenemos la información para generar el registro de facturación. Por ello, mi recomendación y creo que es la única solución, es que utilices un documento intermedio, llámalo nota de entrega, albarán, prefactura, etc. Una vez terminado dicho documento, solicitas un número de factura válido y emites la factura con ese contenido y además el registro de facturación. Esto te asegura otro punto del reglamento de facturación y es que debe haber una correlación entre los números de factura y su fecha de emisión

ok, gracias. Tengo en cuenta tu recomendacion

Hola
Conozco softwares que están trabajando normalmente online contra un servidor en la nube.
Ese servidor es el que tiene la base datos de tiquets y en la que se proceda, genera, guarda tiquets, contadores y series.
Pero, en las tiendas tienen un tpv que hace de backup y si cae la nube este tpv es el que hace de principal ahora.
Que pasaría si hacemos caso al planteamiento que hemos interpretado todos, incluido yo.
Ese tpv central en la Red local ya no tiene acceso a la nube y por tanto pierde el encadenamiento con el r4sto de tpvs del mismo cif que estén en otras sedes que no sean de la red local. Con lo cual se nos plantea un lío impresionante. Hasta ahora estos tpvs cuando entraban de nuevo en marcha con la nube volcaban a la nube lo que han generado localmente, pero seria imposible de insertar en el encadenamiento con el resto de equipos de otras sedes.
Ahora el mismo planteamiento a nivel local. Un servidor central que lo genera todo en la Red local, y si cae. Cada tpv sigue generando independientemente.
Por tanto, al menos en estas circunstancias y para mí el SIF debe ser cada tpv.

buenas,
por eso yo he hecho ese planteamiento en mi pregunta anterior porque si extrapolamos lo que yo planteaba sobre la fecha/hora de cierre de factura a la fecha/hora de llegada al servidor de la factura y se pudiera encadenar los registros por dicha fecha/hora de llegada sin importar la serie y numero seria solo el servidor el que generara secuencialmente el encadenamiento y envio pero sino es asi coincido contigo en que "el SIF debe ser cada tpv".

Yo lo que voy buscando es precisamente quitar a los tpvs el trabajo de encadenar y enviar,¿porque?, pues porque despues caducan los certificados, el cliente pasa de todo o no se quiere enterar y cuando se entera te pasa un embolao de mil pares de demonios que tu debes de solucionar para ayer. En fin, sigo dando vueltas al tema.

Sí, es la forma más segura, que cada tpv sea un SIF diferente dentro de la red generando su línea de facturación con el prefijo de su número de máquina, cada tpv encadena, genera y envía su registro de facturación.
Hay otra alternativa, mientras haya conexión con la nube o con la red de área local, se puede trabajar con un sólo SIF que sería el central y éste se encargaría de generar, encadenar y emitir los registros de facturación. Si un tpv queda fuera de la red por problemas técnicos, podría convertirse automáticamente en SIF dicho tpv y seguir generando sus facturas, encadenamientos y registros de facturación siguiendo otros contadores propios preparados para tal efecto. EN cuanto recupere la conexión, ese tpv deja de actuar como un SIF, mantiene sus contadores para la próxima vez, y se vuelve a integrar en el SIF central.
EL caso extremo, se cae la nube o servidor central, todos los tpv pasarían a trabajar en modo SIF. Ojo, siempre el mismo identificador de SIF para cada Tpv, o sea, que no lo cambie cada vez que cae.

El contador lo tienes que tener al final, además, si varios uauarios trabajan sobre la misma serie tienes que tener en cuenta un bloqueo de acceso del contador para que no puedan acceder simultáneamente 2 personas, ya ue podrías duplicar el número, trabaja mucho en este tema por que si no te vas a encontrar con un problema gordo gordo.

Lo de los certificados te pasaría solo si trabajas en modo No Verifactu, es una de las razones por lo que es recomendable que sea Verifactu, en ese caso no hay que firmar nada, y si necesitas el certificado para el envio es otro tema que no es tan problemático y tiene solución.

pero..... no me refiero a la firma del xml sino al certificado de autentificacion de la llamada soap y ese tiene que estar disponible en cada sif para poder firmar la peticion. Por lo tanto , si caducara, mientras que se dan cuenta y una cosa y otra (por muchos mensajes en rojo fusia que lance) tengo clientes capaces de tirarse un mes con estas alertas sin darle mayor importancia. Tengo cada cliente que pa mi se queda y en ese sentido intento que todo fluya con la menor interactuacion del cliente ya que , aunque no seria cosa mia despues de sacar unos cartelones diciendo que algo va mal, lo que no quiero es mas estres del que tengo y ellos son especialistas en crearme dicho estres

Por si os sirve como lo he hecho yo:
Aunque tengo certificados instalados en cada tpv, si se pegan un mes caducados me da un poco igual, por que solo lo uso para una última comprobación de los números de identificación fiscal y nombres de clientes contra el servicio de la AEAt, y si están caducados a pasado al menos por la comprobación del cif.
A ver,
1. Genero la factura con su XML HASH, QR y encadenamiento en el tpv
2.Envio el XML verifactu,el xml face y el pdf de la factura a un servidor que es el que se va a encargar de mandarlo COMO TERCERO a verifactu. Con lo cual he encadenado en un SIF y he enviado desde otro punto.
2.El control de errores lo lleva ese servidor que me envía un email con el reporte de Oks o KOs cada cierto tiempo.
3. Si el servidor central detecta que un tpv lleva 30horas sin enviar, me lo incluye en el reporte (durante 1 semana cada dia,mas tiempo es innecesario indica que se ha dejado de usar o ya es conocido el problema) de que ese tpv de ese comercio no está enviando desde tal fecha a tal hora.
4. Si un tpv empieza a enviar cosas extrañas, duplicadas, saltos de numeración etc, me manda un reporte inmediato.
Llevo con este diseño desde 2020 y me va del carajo
Algo de tranquilidad da.

Si, si que me sirve. El punto 2 me abre unas alternativas en las que no habia pensado. Hala!! otra noche sin dormir dando vueltas.(jiji)

Muchas gracias

Nada, suerte.
Si tienes como yo montón de tpvs, además de varias empresas, franquicias, etc. Es un sistema que funciona bastante bien. Eso sí, ten en cuenta el numero de tpvs que estén simultáneamente enviando, si vas hacer muchas comprobaciones como hago yo, para dimensionar bien el que pongas, lo tuvimos que cambiar por la carga tan inmensa ee tantos tiquets por wegundo
Por que yo compruebo hasta el hash y el encadenamiento, no me fio ni de mí