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