Cita:
Empezado por newtron
No sé si me estoy perdiendo algo pero yo veo claramente que los programas hay que prepararlos para ser VERIFACTU y simplemente poner una opción para que los registros se envíen de forma automática o no. De esta manera el que quiera que envíe y el que no que tenga una opción para enviar los registros (entre fechas imagino) si se los requieren.
Saludos.
|
Sinceramente creo que se está perdiendo en un laberinto de normas. NO verifactu es mucho mucho mas restrictivo que verifactu. Encima el responsable de la autenticación, conservación y verificación de los datos del cliente es usted no su cliente.
Se firman los registros en NO verifactu, en cambio en verifactu no.
Se firman los eventos. Los requerimientos de la AEAT van a ser continuados, etc.etc.etc.
No tengo a mano ahora mismo toda la documentación al respecto pero ante la duda yo también aconsejo usar "solo verifactu". Opción en la que se renuncia a usar NO verifactu. Si el programa tiene las dos opciones debe cumplir la mas restrictiva que es NO verifactu.
En mi anterior comentario he aludido a que generaré dos ejecutables. Uno para dual verifactu / NO verifactu y otro ejecutable para solo verifactu. Solo verifactu es apriori el que pondré en producción.
No sé si al final sacaré el dual a producción porque tengo serias dudas de la responsabilidad que puedo adquirir, inclusive teniendo precios significativamente mayores para dar dicho soporte que tal vez no me compense el esfuerzo y riesgo.
En mi opinión debería leerse la documentación de la AEAT antes de poner en producción su proyecto. Mi consejo es que se acoja a solo veri*factu si tiene dudas.
Un saludo.