Duda sobre secuencia de envío de factura.

[JETA]

Hola, hoy en pleno verano no se porque estoy escribiendo estas lineas, pero es que me puse a pensar, ¿cómo debe ser el envío de las facturas a hacienda?

Pongo en contexto el caso que estoy analizando.

1- Imagínate que el lunes creas la Factura 005. El software genera su archivo, lo sella con su hash y se lo intenta mandar a Hacienda. Pero pum, el cliente se queda sin internet y el envío falla.
El martes, vuelve el internet y el cliente crea la Factura 006. El software coge el hash de la 005, crea el hash de la 006 y manda la 006 a Hacienda. Luego el cliente recuerda que la 005 no obtuvo respuesta de hacienda porque se quedo sin internet y pum envía la 005, esto generaría un nuevo hash, porque si no daría error de tiempo 2004, hacienda se la traga y no daría ningún problema.

2- Mi cliente tiene 2 administradoras, que se encargan de enviar factura, administradora A tiene la factura 0010 y la administradora B tiene la factura 0011, ambas tienen lista la fac, para enviarla a hacienda, pero la admin A le dieron ganas de ir a baño y no le dio al botón enviar a hacienda, entonces la admin B ¿Que debería hacer? , A - espera a su compi?, B- enviar la factura a hacienda, C - aprovechar e ir al baño también, D - C4g4rc3 en todo ?

Lo hash deberían ser consecutivos a las facturas? o deben ser consecutivos al hash anterior enviado a hacienda que pertenece a una factu x sin importar que esté ordenado al num fac.?

muchas gracias, a quien pueda responder.

Saludos.

[Rja750]

Veo dos fallos de análisis diferentes. La primera es que el encadenamiento seria correcto aunque el RF 005 haya sido fallo. El SIF debe avisar del error y el cliente debe hacer una Subsanación sin rechazo previo sobre el 005.
La segunda es que el SIF no puede asignar el Numero de RF ni el HASH hasta que no pulsas el botón de enviar, sobre todo si hay varios puestos y una sola BD. También tienes que tener en cuenta los tiempos de generación del RF y el tiempo del envío. Por lo tanto la primera operadora que pulse ese botón tendrá el ultimo lugar para encadenar (con el anterior y el RF llevará los tiempos de ese momento) y no la primera
operadora que llegue del baño.

[Neftali [Germán.Estévez]]

Empezado por JETA

1- Imagínate que el lunes creas la Factura 005. El software genera su archivo, lo sella con su hash y se lo intenta mandar a Hacienda. Pero pum, el cliente se queda sin internet y el envío falla.
El martes, vuelve el internet y el cliente crea la Factura 006. El software coge el hash de la 005, crea el hash de la 006 y manda la 006 a Hacienda. Luego el cliente recuerda que la 005 no obtuvo respuesta de hacienda porque se quedo sin internet y pum envía la 005, esto generaría un nuevo hash, porque si no daría error de tiempo 2004, hacienda se la traga y no daría ningún problema.

Lo que no acabo de entender es la parte subrayada (lo de generar un nuevo hash).
Las facturas (registros de facturación) se encadenan a medida que se guardan/generan. El envío es un proceso posterior, que como bien dices puede fallar, pero eso no afecta al encadenamiento.
En el caso que describes, nosotros lo que hacemos en reintentar el envío del 005 (el mismo registro de facturación generado inicialmente) cuando se restaura la conexión a internet.
Es posible que eso de un error de que han pasado los 240 sg., pero es correcto (por que es cierto). Pero la factura quedará aceptada.

Empezado por Rja750

Veo dos fallos de análisis diferentes. La primera es que el encadenamiento seria correcto aunque el RF 005 haya sido fallo. El SIF debe avisar del error y el cliente debe hacer una Subsanación sin rechazo previo sobre el 005.

En el caso de un error por pérdida de internet, no hay que generar una subsanación. La factura es correcta y el usuario no tiene nada que corregir.
En ese caso se DEBE reenviar el mismo Registro de facturación generado inicialmente cuando se restaure la conexión.
Hay que separar los errores de Internet/conexión de los errores en la propia factura (que sí se corrigen con una subsanación).
No tiene sentido pedirle al usuario que haga una subsanación de una factura que es totalmente correcta.

[Rja750]

Mi SIF no grabaria siquiera el RF si no hay conexion porque accedo a la BD que esta en la nube para encadenar
y ya necesitaría conectarme pero en el supuesto que en esas milésimas de segundos que hay entre la generación
del registro y lo guarde, genere el XML y envíe, se desconecte la conexión a internet y no llegue a enviar, siempre
podré volverlo a enviar tal cual está encadenado y registrado en mi SIF, al dia o dias siguientes sin tener en
cuenta tiempos ni nada (Lo que hoy te deja la AEAT mañana podria no dejarte, refiriendome a los tiempos) por
medio de una subsanacion y si queremos ampliar más el concepto de subsanar, podriamos pensar que estamos subsanando
la conexión errónea volviendo a intentarlo de nuevo. De hecho muestro el botón de reenviar en el formulario pero por detrás hay
una subsanación.

[Neftali [Germán.Estévez]]

Empezado por Rja750

si queremos ampliar más el concepto de subsanar, podriamos pensar que estamos subsanando
la conexión errónea volviendo a intentarlo de nuevo. De hecho muestro el botón de reenviar en el formulario pero por detrás hay
una subsanación.

No digo que no funcione, pero conceptualmente creo que es erróneo.
Estás haciendo una subsanación de una factura que no tiene nada que subsanar porque es correcta.

[JETA]

Empezado por Neftali [Germán.Estévez]

Lo que no acabo de entender es la parte subrayada (lo de generar un nuevo hash).
Las facturas (registros de facturación) se encadenan a medida que se guardan/generan. El envío es un proceso posterior, que como bien dices puede fallar, pero eso no afecta al encadenamiento.
En el caso que describes, nosotros lo que hacemos en reintentar el envío del 005 (el mismo registro de facturación generado inicialmente) cuando se restaura la conexión a internet.
Es posible que eso de un error de que han pasado los 240 sg., pero es correcto (por que es cierto). Pero la factura quedará aceptada.



En el caso de un error por pérdida de internet, no hay que generar una subsanación. La factura es correcta y el usuario no tiene nada que corregir.
En ese caso se DEBE reenviar el mismo Registro de facturación generado inicialmente cuando se restaure la conexión.
Hay que separar los errores de Internet/conexión de los errores en la propia factura (que sí se corrigen con una subsanación).
No tiene sentido pedirle al usuario que haga una subsanación de una factura que es totalmente correcta.

Con tu primera duda, lo digo porque al volver a enviar una factura debe ir con la hora actual del envio no? si queremos ser friquis se debe enviar el registro de factura con la fecha hora del momento del envío, para que no de error aunque te la acepte te dice que es un error (2004) no bloqueante y por eso la acepta, pero luego deberías subsanarla y si no la quieres subsanar se debería enviar un nuevo XML con la fecha hora del momento del envío.

Tu opción es válida pero la dejas aceptada con error.

Ahora me causa es una duda, yo por lo menos tengo 2 tablas una Facturas_Conexiones que guardo cada acción sobre una factura y otra con los datos de la respuesta de la AEAT ( tabla Facturas donde se almacena la factura con la respuesta de la AEAT) que es un registro único por factura, mi duda es, cual deberia ser mi último registro que tengo que encadenar? el de la tabla acciones o de la tabla con registro único??

de momento estoy tomando de la tabla Facturas_Conexiones.

[Neftali [Germán.Estévez]]

Empezado por JETA

Con tu primera duda, lo digo porque al volver a enviar una factura debe ir con la hora actual del envio no? si queremos ser friquis se debe enviar el registro de factura con la fecha hora del momento del envío, para que no de error aunque te la acepte te dice que es un error (2004) no bloqueante y por eso la acepta, pero luego deberías subsanarla y si no la quieres subsanar se debería enviar un nuevo XML con la fecha hora del momento del envío.

Creo que estás liando entre generar el registro de facturación y el envío (o no nos entendemos con las explicaciones, que también podría ser... ).
Cuando se guarda la factura se genera el registro de facturación y ese registro de facturación ya no se puede modificar. Luego se intentará enviar y será correcto, erróneo y fallará internet y se volverá a enviar, pero ese registro en todos los casos no es modificable.

Dices esto:
"Con tu primera duda, lo digo porque al volver a enviar una factura debe ir con la hora actual del envio no?"
No, eso es incorrecto. No puedes enviar el registro original modificando la hora del envío.

Entiendo que hay 2 opciones que son las que se han comentado:

1) Enviar el mismo registro de facturación (original), cuando se restablezca la conexión (que es lo que hacemos nosotros), asumiendo que ese registro se aceptará porque es correcto, pero la AEAT te dará una incidencia de que se ha enviado con más de 240sg. (error 2004)
En nuestro caso, eso se asume, porque además es lo correcto. Si el usuario ha tenido problemas de conexión debe saberlo y si ha sido un problema de la AEAT, pues también queda registrado.

2) Generar una subsanación de la factura (que es corecta ) y por lo tanto se generará un nuevo registro de facturación y se volverá a intentar enviar. Si va bien, no obtendremos ningún aviso de 240 sg. y si va mal se volverá a intentar más tarde (imagino) con el mismo procedimiento.

Este segundo caso, nosotros nos lo plateamos, pero para nosotros tenía 2 pegas:
a) El usuario no se entera que que puede tener problemas de conexión (eso no nos interesa, es como barrer el polvo bajo la alfombra) .
b) Estamos generando N subsanaciones de una factura que en si, es correcta, y no le veíamos sentido (aunque funcione)

Empezado por JETA

Tu opción es válida pero la dejas aceptada con error.

Correcto.
Si el usuario luego quiere refrescar el estado, puede hacerlo y la AEAT devuelve Aceptada y se actualiza a ese (desapareciendo el aviso).

Empezado por JETA

Ahora me causa es una duda, yo por lo menos tengo 2 tablas una Facturas_Conexiones que guardo cada acción sobre una factura y otra con los datos de la respuesta de la AEAT ( tabla Facturas donde se almacena la factura con la respuesta de la AEAT) que es un registro único por factura, mi duda es, cual deberia ser mi último registro que tengo que encadenar? el de la tabla acciones o de la tabla con registro único??

No entiendo a qué te refieres con "registro único" por factura.
Por cada operación que realizas en una factura debes generar un nuevo "registro de facturación".
Al generar el alta tendrás un registro. Si la modificas tendrás otro registro y si la anulas tendrás otro. Así que puedes tener N "registros de facturación" por cada factura.
Si realizas una subsanación eso es una factura nueva y tendrá su "registro de facturación" de alta.

Los "registros de facturación" se encadenan en orden de generación (teniendo en cuenta el RRSIF, NIF, Obligado tributario,... -lo especicado por la AEAT para encadenar-) independientemente de que sean de alta/modificación/anulación.