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.

[Carlos]

Creo que estos 'calores' nos están afectando.
Avanzo que estoy un poco oxidado con Veri*factu, pero:

-Es casos de fallo de internet que afecta al no envío del RF a Veri*factu (como el caso que comentan), lo suyo es dar valor al TAG INCIDENCIA del XML a enviar, tenga 1, 2 ó 328 RF detallados, y volver a enviar esos mismos datos de los RF ( de hecho yo modifico el XML creado [ no enviado] añadiendo ese TAG en él).
-Y tal como se está comentando, ni hablar de realizar una subsanación. (A cuento de qué si la factura es correctísima?)
-Y lo del botón en el SIF... Que queréis que os diga? Creo que no es correcto; yo no dejo en manos del usuario enviar o no enviar; se factura, se crea RF, se envía a Veri*factu. Punto pelota.

Por cierto cuando la firma digital usada para el envío caduque (*), estaremos en el mismo caso, y si se va el subministro eléctrico también, y si se 'jode' nuestro maravilloso SDD igual, etc. Pero los RF serán correctísimos.

(*) Habrá empresas que tardaran horas (o días) en disponer de la nueva firma digital. Y que hacemos entonces? Dejamos de facturar? Dejamos de crear los RF?... No, no, no. Se factura, se crean los RF y cuando se puede se envían a Veri*factu con la 'magia' del tag INCIDENCIA.

Cabecera->RemisionVoluntaria->Incidencia Valores 'S' ó 'N'

"Indicador que especifica si la remisión voluntaria de los registros de facturación se ha visto afectada por algún tipo de incidencia técnica (por ej. ausencia de corriente eléctrica, problemas de conexión a Internet, fallo del sistema informático de facturación…). Si no se informa este campo se entenderá que tiene valor “N”. Este campo forma parte del detalle de las circunstancias de generación de los registros de facturación. A rellenar sólo en los casos de remisión voluntaria «VERI*FACTU» cuando haya ocurrido alguna situación de este tipo."

Nada, que no tengo aire acondicionado y estoy sudando un 'montón'.

Saludos,
Carlos G.

[bmfranky]

Hola,perdón por contestar ahora pero creo que estamos mareando la perdiz:





1-> Una cosa es el registro de facturacion creado y sellado en tiempo al crear el Hash(Los datos de la o las facturas).


2-> Y otra diferente es el envió a Veri*Factu que puede tener 1 a 1000 registros , que es el que puede fallar por lo que sea y se ha de reenviar con el check de incidencia a S, para que no de el fallo 2004, que esta compuesto por la cabecera que es lo que se modifica y los x registros pendientes, que es lo que no se puede modificar.


Ademas antes enviar un nuevo registro, por buena praxis, como la normativa indica que los envíos han de ser encolados independientemente solo dependiendo de su tiempo de creación, tu programa de envío debería de enviar inmediatamente tras restaurarse la conexión el o los registros fuera de tiempo o pendientes, mejor dicho(Puede ser que sea un fallo puntual al enviar y en unos segundos estar activa la conexión, estando dentro de tiempo , hubo una incidencia en el envío así que habría que marcarla...) y luego empezar nuevamente la gestión de los envíos según se generen.


No se si realmente el que este equivocado sea yo, pero personalmente lo que encolo son los Registros de Facturación y el encabezado lo creo cada vez que intento el envío.


Saludos y feliz verano a tod@s.