Cita:
Empezado por ermendalenda
Bueno. creia que los que ibamos a adaptaar el software solo para envios directos nos ibamos a librar del registro de eventos, supongo que solo será en ciertos casos.
|
Los registros de eventos están definidos por el artículo 8.3 del RDL 1007/23, y el artículo 14.1 piede que haya acceso a ellos. Luego viene el artículo 16 quién... exente de cumplir los artñiculos 8 y 14, por ser estos cubiertos por la funcionalidades del sistema de registración en Hacienda.
Por su parte, el proyecto de OM es claro (artículo 3,
Particularidades aplicables a los “Sistemas VERI*FACTU”): «[...] en tanto actúen como sistemas VERI*FACTU, no les serán de aplicación los artículos [...] y 9 de esta orden.» Y aunque sea de manera indirecta, el artículo 2 escribe: «[...] la gestión de los registros de facturación y, en su caso, de eventos de [...]».
Lo leo como qué cuando estás en modo Veri*factu, no tienes que preocuparte de los registros de eventos, Hacienda se hace cargo.
Cita:
|
Por que una consulta a verifactu, nos hacen referencia a que en ese caso hay que generar el evento del error.
|
¿Puede ser que hacen referencia al contenido del campo «Incidencia», que a mi juicio tiene una lógica similar a un "evento de error" por un sistema Veri*factu? (O.M: artículo 16.5)
Cita:
|
Ahora, además, me queda la duda si el evento se envia
|
En el protocolo que han propuesto hasta la fecha, no hay forma de enviar registros de eventos en formato estructurado (a la imagen de lo descrito en el artículo 8.3). Cuando sí está previsto para los requerimientos.
Es cierto que pueden faltar cosas (como por ejemplo una interfaz de consulta, que parece está algo prevista). Pero para los eventos en modo Veri*factu, no hay nada previsto.
Además una parte importante de las especificaciones de eventos tal como se describen en la O.M., es el hecho de ir firmados en el instante de su generación. Si en un sistema Veri*factu no hay firma, creería una avenida enorme para problemas de integridad de estos registros de eventos.