Cita:
Empezado por CarlosR
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.
|
¿ Hay alguna forma de controlar que una empresa está en el SII para que el programa no envíe las facturas ya que se enviarán en 4 días como muy tarde? y en caso contrario (no están en el SII) qué lo envíe inmediatamente. Actualmente nuestros clientes son los que nos dicen que tienen SII y le activamos el módulo de envío, pero el envío es manual. El cliente un año puede estar en el SII y al año siguiente no.
¿Cómo lo tenéis pensando vosotros? para que el programa siempre funcione en verifactu pero tenga esa excepción con los del SII y no haya un control manual por parte nuestra. Gracias!!
Hace 2 Semanas
Temas Similares
Modo Hilado