Cita:
Empezado por keno_71
rci cuando te conteste Hacienda por favor si es posible coméntala por aquí, estoy en el mismo caso y me gustaría aclarar eso. Gracias! 
|
Ya me han contestado y teniais razon
Cita:
No su planteamiento no es válido.
El encadenamiento debe ser siempre cronológico, ni por series ni por ningún otro criterio que no sea el cronológico de generación de los registros. El encadenamiento sigue el orden secuencial cronológico de la generación de registros de facturación (tanto de alta como de anulación), por lo que cualquier registro nuevo tiene que ir encadenado al registro de facturación inmediatamente anterior.
Si el SIF, por ejemplo, fuera utilizado por distintos Obligados Tributarios, entonces debe existir una cadena por cada NIF del Obligado. Y esta cadena siempre se formará en orden de creación de los registros (sean de alta o de anulación, es independiente). Es decir, el encadenamiento debe ser por SIF y obligado tributario (y siempre realizarse en orden cronológico de creación).
Y sobre si devuelve error o no el encadenamiento, sepan que actualmente no validamos el encadenamiento de los registros (ni si se trata del primer envío o no).
|
Voy a contestarles con una nueva pregunta porque algunos de nuestros clientes tienen mas de una tienda y tienen dos bases de datos (una en cada sede) y con una réplica de SQL Server, para que la información sea la misma en las dos tiendas, pero permitir que sigan trabajando cuando haya eventuales problemas de comunicación entre ellas.
Pero claro, el envío de datos entre una base de datos y la otra (con la réplica) no es inmediato. por lo tanto no podemos encadenar las facturas de una tienda con las de la otra. A ver que me dicen. Ya os contaré.
Muchas gracias