Duda encadenamiento facturas rechazadas o parcialmente aceptadas

[Jarogo08]

Empezado por richidemola

tu me estás diciendo que no, que hay que encadenarla con la última factura enviada

No sé donde leiste eso en mi respuesta

te lo vuelvo a poner:


SIEMPRE que crees un registro de facturación debe ir encadenado con el último que hayas creado.

Da igual si el último es de la misma factura, de otra, si es subsanación, si es anulación, si fue correcto, si fue incorrecto, si aún no lo enviaste, si ....

SIEMPRE encadenas con el último

[richidemola]

Si perdona, a lo mejor no me expresé bien, ya me lo aclaró el compañero.

Saludos.

[richidemola]

Otra duda, lo siento en el alma la verdad, es la última lo prometo.

Envío factura y es rechazada o aceptada con errores, al volver a enviarla genero un nuevo hash para ese segundo envío y resulta que la última factura que envié era esa misma factura por lo que la duda es si debo encadenarla con el hash anterior de esa misma factura, porque casualmente la última factura enviada es la misma que estoy reenviando o tengo que usar el hash de la última factura enviada anterior a esa?

[gcqZW]

Siempre la ultima que hayas generado, un pequeño apunto respecto al caso planteado por jarogo

si aún no lo enviaste

En este caso (véase no la has enviado por problemas técnicos) la encadenas con la anterior si aun no la has enviado, pero al volver a enviar a la AEAT tendrás que respetar ese orden para el envío (no podrás mandarlas en orden inverso por ejemplo, sino se te descuadra el encadenamiento), por ejemplo:

genero F1 y envío
genero F2 (encadenada a F1) y no puedo enviar por x problema
genero F3 (encadenada a F2) sigo sin poder
genero F4 (encadenada a F3) sigo sin poder
genero F5 (encadenada a F4) sigo sin poder
me doy cuenta que ya puedo
envío F2, F3, F4, F5 en bloque -> correcto
envío F2, F3, F4, F5 por separado -> correcto aunque no tiene mucho sentido ya que te dará error 2004
envío F5, F4, F3, F2 en bloque -> incorrecto ya que al crear los RF encadené al revés


edit: de todas formas si sigues teniendo dudas echale un ojo a los post de control de flujo que hay varios que lo explican todo genial y con toda la casuística posible.

[richidemola]

Vamos que siempre la encadeno con el hash de la última factura enviada aunque de la casualidad de que es la misma factura que la estoy reenviando por que era errónea, con el nuevo envío se genera un nuevo hash que debo asociar a ese registro, cambiando el hash anterior del envío erroneo, para que pueda ser usado en el encadenamiento de la siguiente factura el nuevo hash.

Todo aclarado, muchas gracias.

[Jarogo08]

Empezado por richidemola

Vamos que siempre la encadeno con el hash de la última factura enviada aunque de la casualidad de que es la misma factura que la estoy reenviando por que era errónea, con el nuevo envío se genera un nuevo hash que debo asociar a ese registro, cambiando el hash anterior del envío erroneo, para que pueda ser usado en el encadenamiento de la siguiente factura el nuevo hash.

Todo aclarado, muchas gracias.

Madre mía... vaya lío tienes!

Vamos que siempre la encadeno con el hash de la última factura enviada

vuelvo a insistir... no es con la última enviada, es con la última creada!!!!!

con el nuevo envío se genera un nuevo hash que debo asociar a ese registro

el hash lo generas antes de enviar: creas el registro de facturación y le asignas el hash. Y luego ya haces el envío cuando sea


Aunque estés una semana sin enviar (porque no tienes internet por ejemplo) deberías poder crear registros de facturación con su hash y encadenándolos como toque (efectivamente... con el último generado )

[richidemola]

A ver, es que yo no genero el hash cuando se crea la factura, yo las facturas que se crean las almaceno en una base de datos y las marco como NO enviadas, luego hay un demonio que obtiene todas las facturas pendientes de enviar en orden de creación, por cada factura sin enviar encontrada obtengo el hash y los datos de la última factura de la base de datos que se envió, ya sea correcta, incorrecta o parcialmente correcta, entonces genero el hash de la factura que voy a enviar encadenandola con la última que se envió y la envío, luego asocio el hash que se ha generado a la factura que acabo de enviar y la marco como enviada si no ha dado error, si ha dado error no se marca como enviada para que pueda volver a enviarse una vez corregida y cuando se vuelve a enviar el hash y los datos de factura que se obtienen son las de la última que se envió, y así sucesivamente, no genero un nuevo registro de factura cuando una factura es rechazada, simplemente actualizo su hash con el que le corresponda en función de la última factura que se envió que coincide con el último hash generado y enviado, yo creo que mi sistema vale también porque cada factura se encadenan siempre con la última factura generada, aunque sea el reenvio de una factura que tenía errores.

Por que si no vale me toca generar el hash al crear la factura usando el hash de la última factura que se generó para el encadenamiento, que tampoco es un problema pero me toca la moral modificar todos los archivos donde se generan facturas.

[bmfranky]

Hola, el encadenamiento es mas sencillo de lo que os complicáis , en general, os pongo un mini FAQ al respecto.


1 -> Como he de encadenar?, La operativa es , crear una lista o tabla o lo que queráis de encadenamientos y registros, Se crea un registro, para encadenar se consulta el ultimo almacenado, se crea este
encadenamiento y se encola al final de la lista, se envía y si hay algún error , lo subsano, anulo, modifico, creo otro..., Pues se crea un nuevo registro y se consulta la cola de la
lista para saber los datos a usar, y a jugar.



2 ->Que fecha hora uso?, Estas creando uno registro nuevo siempre , así que la que obtienes en el momento.


3 ->Con que factura encolo?, *Con ninguna, con los datos del ultimo registro creado, sea de lo que sea y de cuando sea, puedes estar rectificando una factura de hace tres meses, y
has de crear el registro hoy.


4 -> Si no envío, que fecha hora uso? ,La creación del hash, el Qr, y el registro de alta, baja y demás es el mismo, ahora, el envío puede ser en el momento, mas tarde o **nunca,
pero se encola en el momento de crear la factura, abono, modificación....


5 -> El registro anterior fue rechazado, he de usarlo para crear el nuevo?, Si, has de crearlo usando los datos de la cola de encadenamientos, se lo haya tragado o no, tu has de
guardar tanto el hash encolado como el registro creado y rechazado, modificar lo que sea necesario y crear un nuevo registro para comunicar los cambios a la aeat, con las
opciones necesarias para ello, pero siempre guardando los datos anteriores, una vez creados no pueden desaparecer ni ser alterados.




* Recordad que los registros, pueden ser de alta, baja , modificación y anulación...


**En los no Veri*Factu, se han de encolar los registros y guardarlos, pero no enviarlos si no se los requieren.


Espero que os quede algo mas claro.

[richidemola]

Empezado por Jarogo08

Madre mía... vaya lío tienes!





vuelvo a insistir... no es con la última enviada, es con la última creada!!!!!





el hash lo generas antes de enviar: creas el registro de facturación y le asignas el hash. Y luego ya haces el envío cuando sea


Aunque estés una semana sin enviar (porque no tienes internet por ejemplo) deberías poder crear registros de facturación con su hash y encadenándolos como toque (efectivamente... con el último generado )

Vale lo entiendo y así lo hace mi programa ahora, pero veo un problema a lo que dices de enviar los registros a la aeat en otro momento ya que para generar el hash del registro de facturación hay que usar el parámetro FechaHoraHusoGenRegistro con la fecha y hora en la que se creó el registro, si luego uso el mismo valor de FechaHoraHusoGenRegistro en el xml, si lo envío más tarde de 240 segundos me da error.

Vamos, que segun el web service el registro lo tengo que enviar no más tarde de 4 minutos desde que se genera, por lo que no creo que pueda estar una semana sin enviar los registros, a no ser que el valor de FechaHoraHusoGenRegistro en el xml no sea el mismo que se usó al generar el hash, si no que ese valor es la fecha y hora a la que se envía el registro, por que si no es así no le veo lógica a lo que dices de envíar los registros en otro momento.