Listado prácticas prohibidas
 

Con el fin de informar sobre los métodos de instalación y prácticas, en los que cada vez veo más irregularidades, os pongo un listado de las que he observado, espero que os sirva de referencia y que seais lo más legales posibles con el fín de establecer una equidad respecto a los clientes,para no perjudicar a las demás empresas desarrolladoras, están habiendo escape de clientes por que algunos lo permitís y otros se saltan las reglas, además de que produce potenciales peligros de sanción al cliente y a la misma desarrolladora:
-No se puede instalar a un cliente el Sistema Verifactu en modo envio de pruebas. El servidor de pruebas solo está para los desarrolladores y pora supuesto mucho menos emitir la factura con el QR de pruebas.
-No se puede poner un sistema dando la posiblidad de que NO emita la factura, ésta debe emitirse en algún formato que se ponga a dispoción al cliente "SIEMPRE", la quiera o no el cliente, que el receptor decida o no decida acceder a ella es su problema.
-No se puede instalar en Verifactu (o No Verifactu) y generar los registros XML's desde la Base de datos y anteriormente realizados en un SIF que no era de este reglamento por que se produciria un deajuste de una factura emitida sin QR y en nuestro sistema estaría identificada con QR.
-Las consultas de los registros a Verifactu para generar Libros de IVA y verificar encadenamientos es un proceso delicado y hay que tener en cuenta que no siempre se devuelven registros de la forma secuencial que esperamos.
-Regenerar facturas en nuestra Base de datos a través de los registros obtenidos (Xml's) no cumplen el reglamento ROF, por que noo crea una copia fiel de como se emitió.
-Las copias de seguridad son obligatorias y no te van admitir NUNCA, que ha sido una averia, o un Virus.
-Y por último : Poner un TPV en NO Verifactu y dando una posibilidad de no emisión de las facturas es de lo más grave que podeis hacer.

Añadid lo que creais que falte.

Eso que comentas del escape de clientes es inevitable, lo importante es que el cliente confíe en ti.

Al final si eres un pequeño desarrollador lo único que te afianza en el negocio es tener tu club de "FANS".

Anda que no se están creando empresas ad hoc para esto del verifactu. Muchas asesorías de mis clientes les están invitando a cambiar a un programa que ellos suministran. Supongo que con su respectiva suscripción. Algo muy goloso para el que ve negocio.

Al final muchos clientes se van a ir a estas soluciones por desconocimiento, mala información, o por interés. Luego ya vendrán los problemas y muchas de esas empresas habrán desaparecido.

Solo nos queda ser honestos con nuestros clientes y con nosotros mismos.

Yo ofrezco la solución y no intento convencer a nadie de nada. El que se queda tiene que estar convencido.

Muy buena lista, este punto no tengo muy claro lo que quieres decir.
En nuestras bases de datos hay registros Verifactu y anteriores a Verifactu, no empezamos con bases de datos limpias (aunque sería más sencillo), hay una fecha de inicio de Verifactu configurada en la base de datos, lo emitido con posterioridad a esta fecha está en Verifactu, con QR, y lo anterior no (sin QR)
Por lo demás también añadiría temas deontológicos que, sin bien no son ilegales, sí son éticamente cuestionables:
- Animar a los clientes a seguir usando Excel, apoyándose en lo que pone en las FAQ, sin decirles claramente lo que pone en las consultas vinculantes: que su caso va a depender de lo que se le ocurra al inspector, sin seguridad jurídica de ningún tipo, y luego si quieres pelea con Hacienda. Esta es típica de gestorías.
- Meter a clientes nuevos en No-Verifactu, por el gancho de "no se envían registros" sin explicar claramente los riesgos que tiene este sistema y la postura de Hacienda respecto al mismo.

Buenos días Grupo!

Un punto que se podría añadir a la lista:

- Permitir al usuario Activar/Desactivar Verifactu con un simple checkbox en la configuración por motivos varios como Sii, TicketBai, Exento, etc...

Quizás esta opción tendría que ser más restrictiva, solo accesible por la empresa desarrolladora e ir acompañada de algún documento de responsabilidad firmado por el cliente final?

Salud!

Sobre este tema, si leemos completamente la pregunta 3 de las FAQ's para Desarrolladores, incluida la NOTA ACLARATORIA, esta decisión, entre SUJETO o NO SUJETO a VERIFACTU, SII, TicketBai, etc, sólo debe producirse en la instalación, lo que en la práctica supone instalar 2 o más productos diferentes.

Podemos hablar sobre si esto es operativo o no, pero a mí me parece que lo deja no claro, sino CLARÍSIMO.

Es lo que pienso, por este motivo lo pondría también como que no es una buena práctica poner esta opción en la configuración del programa es más a nivel instalación u otro sistema. Pero he visto SIF que lo tienen abierto "al gusto" del usuario.

Te comento, hay una empresa dearrolladora "X", que le instala un software para asesores, pues bien, a la hora de instalar verifactu le da la opcion de generar todos los xmls anteriores a la instalacion y remitirlos.

!!! A la primera posición de la lista ya !!!

Me gusta más el que pone No verifactu en un tpv escondido y sin impresora, ese es genial y con mucha imaginación propia de los paises del Sur de Europa.
Claro aquí la culpa es del cliente.

Pues sí que lo supera, sí. :)

Como dice el gran filósofo de nuestro tiempo, Leo Harlem, "esa creatividad mal encauzadaaaa...!:D:D:D

Por mucho que lo intente si un inspecrorse po e un par de horas en el negocio y tiene un aplicacion oara ver lo que suben, están pillados.

Me ha asaltado una duda del primer post con lo de facilitar al cliente la factura por algún medio la quiera o no…

Nuestro soft manda como no puede ser de ningún otro modo todas las facturas a VeriFactu, pero tenemos un checkbox que ir el usuario puede marcar para “No imprimir ticket”. La mayoría lo hace para ahorrar papel y cuando un cliente le piden el ticket le dan a reimprimir última factura y se lo dan. ¿Esta opción no debe estar disponible?

Mi opinión es que no todas las empresas están obligadas a entregar factura por lo que no obligo a imprimir/enviar.

Obvio
Si te fijas, carrefour, mercadona, lidl... si tienes la app y has gestionado que te la envien , no sale tiquet y te lo emvian.
Si el enisor tiene distintas opciones para emitirla y según lo que le requiera el cliente, email, facturaelectroinca, pdf, app... pues eso sí, pero No emitirla está prohibido, otra cosa es que hasta ahora pasen la vista gorda, pero siendo realilistas, crees que despues de la obligacion del Qr, cuya intencion principal es que lo escanee el mayor numero dr cliente, van a seguir mirabdo a otro lado? La obligación de emitir no contiene "opcionalmente para el receptor"

Puff, crep que has mezclado, no todas lss empresas están obligadas a "emitir" pero la emisión está enlazada con la grabación. Si tienes un sif y grabas hay que emitir.. perp vamos no voy a entrar en esto porque es aparentemente subjetivo, y es mejor que pregunteis al informador.
Ña clave wsta en "expedir" y es obligatorio. Ya te digo

Pues ya me estás poniendo a pillar moscas. Yo tenia entendido que las empresas en módulos no tienen la obligación de emitir factura, por supuesto todo esto antes de Verifactu. Quiero recordar haberlo leido en alguna publicación oficial pero ya me pones en la duda.

Edito:

No sé si esto aclara algo:

No tienem obligación, por tanto es opxional usar un sif, el reglamdnto es claro, si usas un sif a verifactu del tiron con todas sua consecuencias.
Si no acuerdate de la clave 18, si no para que.

Bueno...será así... no te voy a decir que no.

Tu no te fies del todo por ai acaso tú verificalo, pero eso qie dices es lo que veo erronwo en casi todoa los sitios y a ver ai el que llevo el paso cambiado soy yo y mis interpretaciones galacticas.