Dudas NO Verifactu
 

Hola,
Tengo la parte de verifactu casi acabada y ahora me toca empezar con la NO Verifactu y el registro de eventos.
Hay una cosa que no tengo clara, y no veo documentación sobre ello.

Por lo que entiendo,
- Hay que generar un registro de evento, tras seis horas de uso y al entrar y salir de la aplicación
- Para generar el registro se debe de comprobar si se detectan anomalías en:
- Registro de facturas
- Registro de evento
- .....

Mi principal duda es cuando se debe de generar el registro de evento.

Gracias

Antes de responder, aquí tienes un resumen de los conceptos más impotantes sobre eventos:
https://sede.agenciatributaria.gob.e...-eventos_.html

- Hay que generar un registro de evento, tras seis horas de uso y al entrar y salir de la aplicación
>> Correcto, pero no sólo esos, hay más registros de eventos a generar.
Puedes verlos aquí:


link a la documentación

Uno de los eventos disponibles es el 10 (que se lanza como dices cada 6 horas) y ese debe calcular un resumen y guardarse.

No acabo de entender lo último que preguntas.

Gracias por la respuesta.
Lo que no me queda claro es si cada vez que inicio o cierro la aplicación se deben de comprobar las anomalías y si detecto algo generar un evento de detección de anomalías, o ese es un proceso voluntario y debe de registrarse.
En el caso de evento de exportación o copia de seguridad se entiende que es cuando el usuario realiza la acción.

Son eventos diferentes, al menos nosotros los tratamos así.
El de entrada, el de salida, el de exportación y el de copia están claros.
Los de detección de anomalías (el 03 y el 05) los lanzamos bajo petición del usuario (cuando el usuario lanza la comprobación de forma manual). El 04 y el 06 van emparejados con los dos anteriores y se lanzan sólo si se detecta alguna anomalía (por ahora lo tenemos así).

Y luego está el 10, que por ahora nosotros lo estamos lanzando de forma periódica y automática cada 6 horas.

Hola, pero supongo que solo si el SIF, alcanza las 6 horas de funcionamiento, no?, Como considerais la salida del usuario que esta usando el programa , como cierre del mismo?, es por curiosidad.


Porque por ejemplo mi programa aunque no lo bloquee, se auto bloquea y provoca la salida del usuario del mismo, quedando en espera de que se vuelva a loguera de nuevo.


O seria inicio de aplicacion, cierre de aplicacion, lo que habria que tener en cuenta?, Gracias y perdon por la pregunta si es muy obbia.

Bueno, tenemos claro lo que hay que hacer a las 6 horas, pero no cuando se cumplen las 6 horas... :o:o:o
Tenemos una consulta abierta a ver lo que consideran "Inicio de funcionamiento" y "Fin de funcionamiento". Nosotros tenemos diferentes configuraciones, con 1..N usuarios, servidores, servicios y posibilidad de TS y no es tan claro lo de "Fin de funcionamiento" (sobre todo).

No te preocupes, no es nada obvia hasta que no aclaren lo que quieren.

Buenas, te han respondido algo a la consulta?

La información que tenemos hasta ahora es esta:

• Adicionalmente, el sistema informático deberá generar, por cada 6 horas que haya estado operativo y disponible para su uso, al menos, un registro resumen de los eventos sucedidos desde que se generó el registro resumen de eventos anterior, o bien desde el inicio de funcionamiento del sistema informático de acuerdo al Reglamento si no se hubiera generado aún ningún registro resumen de eventos anterior.
• El registro de resumen de eventos deberá generarse cada 6 horas, desde el anterior o desde el arranque de la aplicación.
• El sistema informático también deberá generar un registro resumen de eventos antes de cerrarse o apagarse.

caso de requerimiento
 

Buenas,



Estoy intentando comprender el tema de no verifactu para ver si finalmente lo implanto. Tengo muchas dudas para las que me gustaria contar, como siempre, con vuestra ayuda y comprension.


Lo primero que no entiendo es que en caso de que se encuenten errores hay que hacer esto:


f) Cuando el sistema informático detecte cualquier tipo de circunstancia que impida
garantizar o que vulnere o pueda vulnerar la integridad e inalterabilidad de los registros
de facturación generados, o de su encadenamiento, deberá:
1.º Mostrar una alarma que indique claramente este hecho. Dicha alarma no deberá
desactivarse hasta que no se pueda volver a garantizar la integridad e inalterabilidad de
los siguientes registros de facturación y su encadenamiento.
2.º Generar el correspondiente registro de evento que informe sobre el hecho
detectado, de acuerdo con lo especificado en el artículo 9


Bien, se supone entonces que no subsano nada, simplemente informo del error que he encontrado.

No va ha ser complicado reparar un determinado registro para que los siguientes se creen bien sin poder tocar nada?


Si mas tarde me requieren un periodo de facturacion y les envio lo que piden y tengo algun error por ejemplo en el nif que pasaria? Se supone que si no envio el registro no sé si esta bien o mal en caso de que por lo que sea se salte los filtros que yo pueda poner para detectar un nif erroneo, no censado, etc. , por ejemplo.
¿quizas al crear el xml o al lanzar la busqueda de errores hay antes que validarlo en el servicio de validaciones en https://prewww1.aeat.es/wlpl/TIKE-CO...troNoVerifactu como norma?




No sé, estoy un poco liado, perdonad. Agradeceria un monton que me aclararais que se debe hacer en lineas generales en el metodo no verifactu.



Por cierto, no estaria bien crear un tema para el modelo no verifactu en el que tengamos agrupada toda la informacion y dudas relacionada solo sobre esto ? Resulta complicado buscar informacion al respecto ya que la mayoria pasamos del no verifactu por lo que solo se hayan referencias al tema de forma muy dispersa entre los distintos hilos.


Espero no haber preguntado muchas gilipolleces :)


gracias

En NO-VERI*FACTU no se subsana nada, se generan registros de facturación y registros de eventos.
Hay varios procesos que revisan la integridad de esos registros creados.
Si detectas algun error es cuando debes:
1) Mostrar un aviso
2) Generar un registro conforme hay un error en la integridad de los registros (si, un poco rebuscado).

Piensa por ejemplo en un error relacionado con una copia/restauración de la B.D. (has perdido registros). Al revisar la integridad obtendrás algún error, pero una vez que es sistema se estabilice los registros se generarán correctamente, por lo tanto en ese momento eliminarás el aviso.

Correcto, no sabrás que estás generando algo mal hasta que ellos te lo comuniquen.
Al final, en este caso, lo que creo que quieren es que lo que generes no se modifique (inalterabilidad).

Gracias, neftali

Esto es lo que hasta ahora creo que me ha quedado claro.

Resumen del Modo a proceder en sistemas no verifacto:

- Se genera la factura
- Se crea, firma y se guarda con candado el xml que se enviaria en modo verifactu.(en verifactu no se firma el xml)
- Los eventos van tambien firmados.
- Cada 6 horas se crea como evento el resultado de un resumen .
- Cada vez que un usuario abra o cierre sesion se crea un registro de evento .
- Manualmente se puede lanzar un proceso para la deteccion de errores tanto en los registros de facturacion como en el registro de evento. Se informa mediante un registro de evento del lanzamiento del proceso correspondiente.
- Si el proceso anterior detecta algo puesss se genera el registro de evento diciendo que es lo que ha detectado y lanzo un aviso en la aplicacion que indique que el fin del mundo esta llegando. Este aviso lo mantengo hasta que en alguno de los posteriores procesos de deteccion que se lancen automaticamente no se vuelva a detectar incidencia alguna.
- En cualquier momento el programa debe de poder remitir a la aeat un determinado periodo de facturacion(Los xmls que tenemos bajo candado y firmados). La remision generara tambien su evento. El registro de eventos tambien se envia a la aeat. En la cabecera del envio se deberá informar el nodo <RefRequerimiento>.
- En el último envío (max 1000 registros) se deberá informar, en la cabecera, la finalización de la remisión de registros de facturación del requerimiento marcando el campo <FinRequerimiento> con el valor “S”
- El periodo de facturacion pedido bajo requerimiento y enviado y confirmado como correcto a la aeat ya no tiene porque seguir estando guardado fisicamente en el sif por lo que se puede borrar.


Por ahora creo que esto es lo que hay que hacer mas o menos y en resumen.

Algo mas a considerar ?


gracias