Cita:
Empezado por JoseLeeTo
En mi caso, todavía no tiene claro mi empresa si será el Cliente el que decida si se acoge a VeriFactu o no, con lo que tengo que abrir ambas posibilidades mientras no me digan lo contrario (doble de curro para mi, obviamente).
|
Puedes leer toda la hilera de mensajes. Pero para resumir, creo que el consenso aquí es que tu cliente se va a decantar por un sistema Veri*Factu. Por qué, para que se decante para un sistema no-veri*factu, tiene que tener muy buenas razones, con todos las pegas que tienen estos sistemas.
Realmente, Hacienda está poniendo toda la presión que puede, en su comunicación (de momento), para que las cosas pasen por Veri*factu; por tanto la lógica para tu empresa es convencer al cliente de ir por este lado (y menos curro; o menos inversión, si tienes que venderlo a tu jefe; cosas de palabras).
Aparte de los que quieren ir siempre en contra de lo que dice Hacienda o el gobierno, por qué sí (y tienen todo el derecho de opinar así), creo que las únicas empresas que deben considerar no-veri*factu son las que tienen sistemas en casa que son más baratos de adaptar a este modalidad que al Veri*factu; si no, no tiene lógica ir por este lado.
Y esto antes de hablar del suplemento de costes por ser un sistema de facturación compatible no-veri*factu (con más funciones). Qué serán vendidos en menores cantidades, por tanto con menor retorno de las inversión para las empresas de software.
Cita:
|
Tenía entendido que en un sistema NO Verifactu, los XML se guardaban firmados en espera de ser enviados ante un requerimiento de la AEAT, pero ya no me queda nada claro con lo que me comentas de que NO hace falta almacenarlos, sino que como dices solamente se generarán los XML y se firmarán y enviarán en el momento que los requiera hacienda, pero no antes.
|
No me he explicado bien.
Por supuesto debes firmar en el momento de la generación, no en el momento del envío.
Pero una vez firmado, no estás obligado a almacenar los registros con el mismo formato XML que él que se hará el envío bajo requerimiento: puedes almacenar la firma en un lugar, el contenido de los nodos en otros etc. Solo debes estar en capacidad de garantizar que generarás un XML con el formato correcto para que la firma valide, en el momento de cumplir con algun requerimiento.
Dicho esto, si siguen con la necesidad de referirse a múltiplos esquemas XSD (que era lo opción presentada en el primer borrador que estaba), almacenar y luego presentar los registros dentro de un conjunto por el requerimiento será un lío por culpa de los múltiples xmlns: (hay mensajes anteriores que lo expliquen en la práctica). Si solo se necesita un solo espacio de nombres, es mucho más sencillo deconstruir el XML (y también firmar y validar; ganamos todos). Ya veremos... cuándo se publique.
