Cita:
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.
Cita:
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.