Se encadenan los registros, no las facturas
 

Hola a todos, esto no es una consulta si no una conclusión a la que yo llegué tarde y me obligó a rehacer parte del código y de la estructura de tablas que tenía montado.

Cuando se habla de encadenar los registros se trata de encadenar los "envios" que se hacen a la AEAT, no el registro de la factura en sí.
Yo tenía este lio porque también queria hacer el tema de facturas encadenadas donde cada factura guarda un registro de la anterior.
Pero para el proceso de verifactu no funciona igual.

Para una factura podemos tener cinco registros de envio se hace falta.
Incluso podemos tener el envío de la rectificación de una factura anterior a la que tocaría ahora y no pasa nada.
Yo antes guardaba la información del encadenamiento en la propia factura, pero no me cuadraba tener que encadenar el envio de una subsanación de la misma factura ya que entonces no sabía donde guardar el resultado del envio anterior ni como encadenar una misma factura con ella misma.
Hasta que entendí que lo que se encadena son los registros de envio, no la factura en si.
Esto "obliga" a tener una tabla separada para los envios, que será la que se encadenará con el envio anterior y donde se guardará el hash del envio actual y un "enlace" al envio anterior.

Con la separación factura - envioregistro ya si que se puede enviar la misma factura para rectificar o hacer lo que queramos, ya que el encadenamiento se hará en el envioregistro, no en la factura en si.

Debido a la faena extra que me implicó el no entender la base del encadenamiento me ha parecido oportuno enviar este post, pero si veis que es información que sobra o se trata en otros mensajes (que he visto que dentro de otros hilos se comenta) me lo decis y lo borro sin problemas.

Saludos!

Uff
Creo que te estas liando
Hay que encadenar todos los registros a la hora de generarlos siempre con el último generado
Simplificadas,ordinarias,rectificativas,anulaciones y subsanaciones y para encadenar lleva algunos datos del registro anterior como fecha_hora y el hash del encadenamiento del anterior incluido en ese calculo

Pues yo opino igual, para nada se está liando. Al contrario, si o si, hay que crear una tabla de registro de envío de facturas, que es la que me proporciona el encadenamiento correspondiente.

Como ya se ha comentado en anteriores foros, no se encadenan las facturas por número de factura, sino por el orden en que se van enviando a Hacienda.

Pues suerte.
Saludos

Se encadenan en el orden que se van generando facturas sea del tipo que sea, incluso si hay subsanacion tambien, pero no por el envio.

Para aclarar mas este tema, poneos en un Sistema Veri*Factu, este se queda sin internet y por lo tanto no se puede enviar.

En este caso, estamos obligados a generar el Registro de Facturacion encadenado con su anterior si lo hay, este RF se guarda hasta que se pueda enviar.

Por lo tanto, el encadenamiento no se realiza en el envio, sino cuando creamos la factura y su correspondiente RF encadenado a su RF anterior si lo hay.

Correcto, se encadena al crear, no al enviar. Puedes crear sin enviar

Si queremos aclararnos, lo primero que hay que hacer es hablar con propiedad. "Registro de envío" como tal no existe, no se si os estáis refiriendo a "Registros de facturación".
Creo que estáis liando conceptos y cosas diferentes, porque estáis mezclando generación de "registros de facturación" con envíos.

El encadenamiento se hace entre "Registros de facturación". El que no tenga claro esto que pare de desarrollar y que vuelva a leer la documentación.

Correcto.

El encadenamiento no tiene nada que ver con el envío. 2 situaciones sencillas:
* Si estás en NO*VERIFACTU no se envía nada y los encadenamientos funcionan igual que en VERI*FACTU.
* Si estás en VERI*FACTU y no puedes enviar (por lo que sea) tienes que seguir encadenando.

Error.
Se encadenan "Registros de facturación", no las facturas como dices, pero nada que ver con el envío.
Puedes generarlas ahora y enviarlas dentro de 1 hora (por varias razones que pueden pasar). El encadenamiento debe seguir el orden en que las has generado ahora, no el orden en que las enviarás dentro de 1 hora.

Correcto.

Resumiendo...

Al generar una factura en ese momento se genera el "registro de facturación" y se encadena con el último generado (del mismo OT -si es que tenéis varios-).
1 Factura puede tener 1..N registros de facturación (1 se genera en el momento de grabar/generar la factura), no tiene nada que ver con el envío. El resto se pueden generar cuando la modificas o la borras.

Los "Registros de facturación" se encadenan con el anterior en el orden en que se generan (sean de la misma factura, o de otras, sean de alta o de modificación,...)

Hasta aquí no he hablado de envío, porque hasta aquí todo funciona exactamente igual sea VERI*FACTU o NO-VERI*FACTU (con la diferencia de que unos se firman y otros no).

A partir de este punto (cuando ya se han generado) van los envíos (o no), pero eso es otro tema.

Disculpa German, pero en el fondo estamos diciendo lo mismo pero de forma diferente.

Como tu bien dices, la clave de todo es que para "una factura existen N Registros de Facturación".

Esa es la clave, yo a esta tabla la he llamado registro de envío de facturas (normales, simplificadas, anulaciones), porque juego con el estado (pendiente de enviar, enviada con errores, etc). En los sistemas NO VERIFACTU lógicamente estarán pendientes de envío mientras no haya un requerimiento de Hacienda.

El inicio de este tema se refiere a eso, que no hay que encadenar facturas sino registros de .....

Si, el fallo es mío porque he puesto la palabra "envío". Lo que pasa es que en mi caso, y por ahora, no voy a dejar hacer una factura nueva hasta que no se envie a la AEAT la última que hemos hecho. Por eso estoy "igualando" el registro de factura con la del envio.
Pero no será lo habitual, tal y como comentais se deben poder ir creando las facturas e ir creando a la par los registros de encadenamiento.
La idea principal que quería transmitir era que se debe separar el registro de factura con la factura en sí, ya que una factura puede tener múltiples registros, por ejemplo porque no se ha aceptado del todo el envio y se tiene que subsanar creando otro registro, que puede ser hecho al cabo de unos dias y de haber enviado registros de otras facturas distintas.
Saludos!

Es posible, pero llamamos a las cosas diferente y por eso es posible la confusión.

^\||/

Yo creo que es una limitación muy grande, pero si tú tienes claro que a ti te funciona adelante, pero no se puede generalizar ese comportamiento.
Pero ten cuidado con las fechas que aparecen en ambos. FechaFactura vs FechaRegistroFacturación a ver si no van a "cuadrar" y vaa ser raro...

Correcto.

Entonces estamos de acuerdo.
1 factura -> N Registros de facturación.

Estábamos dándole vuelta a lo mismo... ;)

En cuanto a esto, tengo la gran duda de en qué se diferencian la fecha de la operación de la fecha de expedición de la factura, es decir, si se supone que la finalidad de Verifactu es que en cuanto se realice la factura se emita directamente a la AEAT, no tendría sentido que estas dos fechas fueran diferentes a menos que se haya tenido alguna incidencia, como el no haber podido emitir el RF en un día por algún caso. Y se supone que solo se debe decir cuál es la fecha de operación en caso de ser distinta de la fecha de expedición de la factura...
¿Alguien sabe de algún caso en el que se diera que estas dos fechas sean diferentes?
¿Alguien sabe si en el caso de no poder enviar el registro de Facturación el mismo día que se ha creado, si no al día siguiente por cualquier razón, la fecha de expedición de la factura es la fecha en la que se ha creado el RF o en la que se ha emitido a la AEAT? La misma pregunta para FechaHoraHusoGenRegistro

Si un albarán de ayer lo facturas hoy, la fecha operación será ayer y la fecha expedición será hoy. Y si hay rectificativas también varía

Hay varios casos en que la fecha de operación puede ser diferente: algunos de ellos:
Emitir una factura de canje(sustitutiva de un tiquet) de una fecha hasta de 4 años atrás, si el mes en que se emite no es el mismo debe ponerse obligatoriamente la fecha de operqcion(que yq va en cada línea de tiquet sustituido) aunque no está de más que la pongas en la cabecera
La dr los albaranes, que xomenta el post anterior también, pero te niwndo en cuenta que puede ser una recapitulación, se puede dar el caso que emitas una factura el mes siguoente(antes del día 16) y tendrías que indicar la fecha de operación del primer albarán. Esto es igual a si es un trabajo realizado y cobrado en el mes anterior, sin hacer falta albarán.
Si haces una rectif8cativa por sustituticiiñon y el mes es diferente a la original.

Hay que tener en cuenta que si quieren cruzar datos con los movimientos bancarios pueden detectar la diferencia de fecha, que si es en el mismo mes no pasa nada pero si son cantidades grandes que tenias que haber declarado en el periodo anterior(fecha operacion) lo mismo te cae un premio
Fecha operacion=fecha tributaria. Para calcular el periodo impositivo, aunque te paguen más tarde.
Pero solo obligatoria si son periodos diferenetes la de operacion con la de emisión, o sea meses diferentes.

Buenas!
Tengo una duda sobre el tema de los encadenamientos: he leído los hilos que he ido encontrando por el foro y como no quería abrir un nuevo hilo, formulo mi duda en éste ya que no me aclaro.

Tengo dos numeraciones de facturaciones con sus respectivas series:

facturas mensuales -> A-1 (serie A y nº de factura 1, luego dos, tres, etc...)
tickets -> T-100001 (serie T y nº de factura 100001, luego 100002, 100003, etc...)

En el momento de crear, por ejemplo, la factura T-100010, ¿su registro de facturación debería ir encadenado a la T-100009 o al último registro de facturación que se haya hecho (independientemente de la serie A/T)?

Lo pregunto porque he leído Orden HAC/1177/2024 (BOE de 29 de noviembre de 2024) lo siguiente:

Con el texto de esa cita (sobre todo la parte de "misma serie de facturación") me entran muchas dudas y no sé, en el caso que os he expuesto, cómo tendría que ser el encadenamiento de la factura T-100010.

Siempre con el RF enviado justo anterior al que quieras mandar, sea de la serie que sea. Otra cosa es que dividas en dos SIF diferentes por cada serie, entonces con el RF justamente anterior del SIF en el que estés.

Crro que has escrito eso de memoria y te has liado:
" Cada registro de facturación, de alta o de anulación, contendrá el siguiente conjunto de datos referido al registro de facturación, de alta o de anulación, inmediatamente anterior por orden cronológico de fecha de generación"
Lo de la serie no es correcto ni aparece como indicas.

Si os digo la verdad, esa cita me ha venido pasada desde una tercera persona dentro del trabajo. Como llevo leyendo este foro hace tiempo y veo las respuestas que sugerís, he dudado inmediatamente de la información que me han facilitado.