Algunas aclaraciones para tranquilizar...

[Rja750]

Empezado por espinete

Han sido meses duros para todos. De confusión, intentos de interpretaciones de una documentación mal explicada, cambios, adaptaciones del software por requerimientos sin mucho sentido, cosas enrevesadas para complicarnos innecesariamente la existencia tanto a nosotros como a los usuarios finales... pero me gustaría dejar algunas cosas claras. Puede que no estemos todos de acuerdo, pero yo lo suelto, y que cada uno lo tome como quiera:

1. Hacienda NO puede hacernos responsables a nosotros de que algo falle. Y mucho menos en los primeros meses de funcionamiento.
Eso es como culpar a Microsoft de los fallos de Windows y hacerles pagar una sanción. Todo software requiere parches, actualizaciones, etc. Si ellos creen que no, es que no tienen ni p... idea.

2. Que ellos "exijan" algo no significa que deba funcionar al 100% siempre. Hay cientos de incidencias que pueden ocurrir en el día a día (y ocurrirán).
Nosotros tenemos claro que el software lo vamos a tener que retocar de aquí a Enero sí o sí.

3. No pueden exigir que la versión de nuestro software que se descargue el 1 de Agosto sea la misma que el cliente vaya a usar el 1 de Enero. ¿Acaso no puede haber otros errores en el software que deba corregir por ejemplo en Noviembre?
Si yo exijo a MIS clientes que el 1 de Enero tienen que actualizar a la última versión sí o sí, es cosa mía, y Hacienda no me puede decir lo contrario. Faltaría más.

4. Sería inadmisible que ellos puedan tener errores (servidor caído, certificado del servidor caducado (pasó con TicketBAI hace tiempo)) y que seamos nosotros los responsables de tener que manejar toda la casuística posible que ni siquiera depende de nosotros.
Podemos prever algunas cosas, pero no todas.

5. En el peor de los casos, los clientes no podrán facturar durante un tiempo. De la misma manera que no podrán facturar si hay un apagón, y tampoco somos responsables de eso.
El cliente tiene que entender que ahora pueden fallar muchas cosas. Si se quejan, que vayan a llorar a la puerta del Congreso con los leones.

6. Y sobre lo de cobrar de más a los clientes actuales, o subir el precio del soporte técnico, o permitir el envío solo si tienen contratado el servicio técnico, etc. es lo más normal del mundo teniendo en cuenta el curro que nos hemos pegado todos durante más de un año con esta m.....
El cliente que no lo quiera entender, tiene vía libre para cambiarse de software de aquí a Enero/Julio de 2026. No está obligado a seguir usando el nuestro si no le gusta.

Dicho esto, les deseo a todos una buena entrada a VeriFactu, pero ya os aviso de que, de aquí a Diciembre, todavía pueden cambiar muchas cosas

Echémonos una copita de vino o una caña virtual todos!

Creo que esta es la actitud. Me alineo con estas palabras. Ya hemos hecho lo más complicado y no dejemos que las incongruencias de la AEAT, que ni ellos se las creen, nos amarguen la inauguración de nuestro software. Habrá retoques en el código pero sabremos modificarlo porque hemos llegado hasta aquí, algunos de nosotros se han quedado en el camino porque no ha sido fácil. Ahora estamos en la línea de salida. ¿Vamos a dejar que esta gente nos quite el sueño?. Conmigo la llevan clara!! y me voy a tomar una cervecita fresca y virtual con todos vosotros

[Decanato]

A los desarrolladores de TicketBai también les han expuesto a ese tipo de sanciones tan brutales???... porque vamos no es ni medio normal, que encima que les desarrollamos funcionalidades para hacerles el trabajo de inspección que ELLOS TENDRÍAN QUE HACER, además de eso te puedas encontrar con que alguna circunstancia asociada a eso te pueda arruinar la vida.

[espinete]

Empezado por Decanato

A los desarrolladores de TicketBai también les han expuesto a ese tipo de sanciones tan brutales???... porque vamos no es ni medio normal, que encima que les desarrollamos funcionalidades para hacerles el trabajo de inspección que ELLOS TENDRÍAN QUE HACER, además de eso te puedas encontrar con que alguna circunstancia asociada a eso te pueda arruinar la vida.

No. Nosotros ya tenemos el software adaptado para TicketBAI desde hace años, y no, para nada hay tanta responsabilidad. Pero ni para TicketBAI ni para ninguna otra factura electrónica con la que trabajamos (México, Costa Rica...)

Te digo más: hemos tenido problemas muy raros y difíciles de resolver con TicketBAI (clientes que han hecho un estropicio difícil de replicar, prever, etc.) y TicketBAI lo que nos dice es "nada, tranqui, vuelvan a crear una factura y reenvía sin problema", restándole importancia.

[Decanato]

Empezado por espinete

No. Nosotros ya tenemos el software adaptado para TicketBAI desde hace años, y no, para nada hay tanta responsabilidad. Pero ni para TicketBAI ni para ninguna otra factura electrónica con la que trabajamos (México, Costa Rica...)

Te digo más: hemos tenido problemas muy raros y difíciles de resolver con TicketBAI (clientes que han hecho un estropicio difícil de replicar, prever, etc.) y TicketBAI lo que nos dice es "nada, tranqui, vuelvan a crear una factura y reenvía sin problema", restándole importancia.

Es que a ver, es lo natural y lo sensato... Entiendo que te puedan meter una sanción por distribuir un programa que no se ajusta al RF, o incluso que no lleve implementado VeriFactu, pero que te puedan empapelar por mal funcionamiento o errores que se puedan producir en el software es que no sé si es hasta constitucional

[espinete]

Hoy les he enviado este email a los de VeriFactu, con algunas dudas, opiniones y "quejas" que llevábamos tiempo recopilando. Es un poco largo, pero creo que resume lo que hemos estado debatiendo por aquí últimamente.
A ver qué responden (si responden algo):

Buenos días...

Nos han surgido varias dudas que consideramos bastante importantes, además de otros muchos casos no previstos inicialmente pero que indudablemente surgirán en cuanto las empresas empiecen a generar/enviar VeriFactu de forma masiva...

Os las planteamos con el fin de entender qué tenéis previsto que se deba hacer en cada caso, ya que consideramos que la documentación tiene partes que están sujetas a interpretación subjetiva.

1. Usuarios probando versión demo del software
En un software de escritorio, los usuarios de software suelen descargar y probar el software durante un tiempo antes de comprarlo. Quieren crear un par de artículos, ver cómo se hace una factura, si les gusta cómo se hace, etc. 
Teniendo en cuenta que no permitís el envío de VeriFactu al entorno de Pruebas (lo cual nos parece un despropósito sin sentido y que no debería afectar a nada ni nadie), entendemos que pretendéis que el usuario dé de alta su certificado en el software
(y en todos los softwares que esté probando), rellene los datos reales de su empresa, dé de alta un cliente real con NIF real y haga las facturas, se envíen a VeriFactu al entorno de Producción y luego se anulen automáticamente (o tenga que anularlas él).

Nos gustaría saber si creéis que esto es lo que se debe hacer realmente, porque sinceramente, tras la experiencia que nos han dado 25 años desarrollando software de facturación, dudo mucho que los usuarios estén preparados para esto.

El entorno de Pruebas debería estar disponible para que se pueda usar, obviamente que sea independiente y separado del Real, para poder probar que todo funciona correctamente antes de empezar. Lo que sí se debería impedir es alternar entre Pruebas y Producción, pero que se pueda probar el software,
o hacer envíos de pruebas en caso de detectar una incidencia, etc. lo vemos completamente imprescindible.

2. Usuarios registrados que nos envíen copias de seguridad para resolver alguna incidencia
En el software de escritorio los datos se almacenan de forma local, y se hacen copias de seguridad/respaldo cada X tiempo. Algunas incidencias difíciles de resolver en remoto requieren que el usuario nos envíe una copia de seguridad de sus datos, que recuperamos en nuestros equipos.
¿Qué pasará si debemos hacer una factura de prueba? Pues que en sus datos y config. estará activado VeriFactu en modo Producción. Tener esto en cuenta antes de hacer nada y liarla es bastante complejo, sobre todo teniendo en cuenta que tenemos clientes que NO están en VeriFactu, sino en TicketBAI o en otros países.

3. Usuarios con pérdida de datos, virus, PC roto, BD dañada, etc.
Esto es algo más habitual de lo que se cree, por desgracia. A muchos usuarios se les rompe el PC, o se les infecta/encripta por un virus, o lo que sea.
Imaginemos que una empresa lleva enviando VeriFactu varios meses, y de repente hoy ocurre algo y pierden los datos.
Deberán, con suerte, recuperar una copia de seguridad de ayer (o incluso anterior si las han perdido también). Cuando lo hagan, habrá facturas que NO existan en el SIF, pero sí le constan a Hacienda porque ya fueron enviadas antes del desastre. 
Conclusión: se pierde en encadenamiento, porque la última factura que se envió no existe en el SIF. ¿Cual es aquí el procedimiento a seguir? Iniciar una nueva enumeración? Consultar con la AEAT cual fue la última factura enviada y obtener su huella para el encadenamiento? 
Rehacer las facturas que faltan una a una y enviarlas como "subsanación"?

4. Diseños de factura personalizados
Nuestro software permite a los usuarios elegir entre varios diseños de factura, personalizarlos a medida o incluso crearlos desde cero. Para ello usamos un conocido diseñador de informes. que se incluye con el software.
Ahora con VeriFactu tendrán que incluir en sus diseños de factura el QR de VeriFactu. Hemos intentado automatizarlo pero es imposible. En el 99% de los diseños no hay espacio libre para meter ese QR, y mucho menos al principio de la página, como "exige" Hacienda. 
Conclusión: no hay forma. Los clientes tendrán que añadir/personalizar su plantilla de factura para añadir el QR.
Tratándose de miles de clientes, es inviable que nosotros podamos hacer eso, por no mencionar el coste que ello supone (horas de trabajo, precio...).
Los clientes quieren usar su propia plantilla de factura, que han estado usando durante años, con sus colores, su diseño, etc. A los clientes nuevos se les puede predefinir el diseño especial/oficial para VeriFactu, pero los antiguos tendrán que adaptar el suyo sí o sí.
Además, el SIF permite al usuario cambiar el modelo de factura cuando quieran, y el QR solo se incluye en uno. Y no, no es posible impedir eso (no puedes permitir modificar un diseño pero no elegir otro, no tendría sentido. Además, el diseñador de informes no lo desarrollamos nosotros).
En fin, que como se puede apreciar, hay muchísimas consecuencias que creemos que no se han tenido en cuenta, dejando el 100% de responsabilidad sobre nosotros, lo cual es injusto, por no decir abusivo.

Y hay muchas otras dudas que nos han surgido en las últimas semanas que también tendrán sus consecuencias:

5. Usuarios que no saben si son persona física o jurídica: Esto puede resultar inverosímil, pero ocurre, y mucho. Sobre todo con cooperativas, etc. 
6. Permitir el envío al Entorno de Pruebas solo a nosotros como desarrolladores: habría que pensar cómo permitir que solo nosotros podamos hacerlo, pero sin embargo, en el mismo software, enviar a Producción cuando lo que se envíe sea nuestra facturación real.
7. "Autofacturación" en empresas agricultura: hay empresas que realizan auto-facturación (se facturan a sí mismas en nombre de un proveedor tercero). No es nuestro caso, pero hemos hablado con otras empresas de software que nos han trasladado también esta duda. 
Para esa funcionalidad tampoco parece haber respuesta, según nos han dicho.

En definitiva, como opinión personal después de año y medio centrados exclusivamente en VeriFactu, sin recibir a cambio poco más que avisos de posibles sanciones y 100% de la responsabilidad, creemos sinceramente que hay cosas que se han planteado mal, o de forma incompleta. 
Entendemos que vuestra intención es que nos lo tomemos en serio, pero el estrés y ansiedad que nos ha generado todo esto es difícilmente compensable. Nuestro software lleva años con TicketBAI y la factura electrónica de México, Costa Rica, etc. sin tener que pasar por todo esto en ningún momento. 
Creo personalmente que las cosas se podrían haber hecho mejor, y espero que aún estemos a tiempo de ser algo más permisivos con algunos casos concretos.

[emailesc]

Chapó !!! por el contenido y por la valentía de describirlo tal como es y lo pensamos muchos !!!

[espinete]

Empezado por emailesc

Chapó !!! por el contenido y por la valentía de describirlo tal como es y lo pensamos muchos !!!

Y hubiera sido más "agresivo" si no hubiera salido a por un café hace un ratito
No servirá de nada porque esta gente no acepta críticas, pero yo me quedé a gusto

[ermendalenda]

Empezado por espinete

Hoy les he enviado este email a los de VeriFactu, con algunas dudas, opiniones y "quejas" que llevábamos tiempo recopilando. Es un poco largo, pero creo que resume lo que hemos estado debatiendo por aquí últimamente.
A ver qué responden (si responden algo):

Buenos días...

Nos han surgido varias dudas que consideramos bastante importantes, además de otros muchos casos no previstos inicialmente pero que indudablemente surgirán en cuanto las empresas empiecen a generar/enviar VeriFactu de forma masiva...

Os las planteamos con el fin de entender qué tenéis previsto que se deba hacer en cada caso, ya que consideramos que la documentación tiene partes que están sujetas a interpretación subjetiva.

1. Usuarios probando versión demo del software
En un software de escritorio, los usuarios de software suelen descargar y probar el software durante un tiempo antes de comprarlo. Quieren crear un par de artículos, ver cómo se hace una factura, si les gusta cómo se hace, etc. 
Teniendo en cuenta que no permitís el envío de VeriFactu al entorno de Pruebas (lo cual nos parece un despropósito sin sentido y que no debería afectar a nada ni nadie), entendemos que pretendéis que el usuario dé de alta su certificado en el software
(y en todos los softwares que esté probando), rellene los datos reales de su empresa, dé de alta un cliente real con NIF real y haga las facturas, se envíen a VeriFactu al entorno de Producción y luego se anulen automáticamente (o tenga que anularlas él).

Nos gustaría saber si creéis que esto es lo que se debe hacer realmente, porque sinceramente, tras la experiencia que nos han dado 25 años desarrollando software de facturación, dudo mucho que los usuarios estén preparados para esto.

El entorno de Pruebas debería estar disponible para que se pueda usar, obviamente que sea independiente y separado del Real, para poder probar que todo funciona correctamente antes de empezar. Lo que sí se debería impedir es alternar entre Pruebas y Producción, pero que se pueda probar el software,
o hacer envíos de pruebas en caso de detectar una incidencia, etc. lo vemos completamente imprescindible.

2. Usuarios registrados que nos envíen copias de seguridad para resolver alguna incidencia
En el software de escritorio los datos se almacenan de forma local, y se hacen copias de seguridad/respaldo cada X tiempo. Algunas incidencias difíciles de resolver en remoto requieren que el usuario nos envíe una copia de seguridad de sus datos, que recuperamos en nuestros equipos.
¿Qué pasará si debemos hacer una factura de prueba? Pues que en sus datos y config. estará activado VeriFactu en modo Producción. Tener esto en cuenta antes de hacer nada y liarla es bastante complejo, sobre todo teniendo en cuenta que tenemos clientes que NO están en VeriFactu, sino en TicketBAI o en otros países.

3. Usuarios con pérdida de datos, virus, PC roto, BD dañada, etc.
Esto es algo más habitual de lo que se cree, por desgracia. A muchos usuarios se les rompe el PC, o se les infecta/encripta por un virus, o lo que sea.
Imaginemos que una empresa lleva enviando VeriFactu varios meses, y de repente hoy ocurre algo y pierden los datos.
Deberán, con suerte, recuperar una copia de seguridad de ayer (o incluso anterior si las han perdido también). Cuando lo hagan, habrá facturas que NO existan en el SIF, pero sí le constan a Hacienda porque ya fueron enviadas antes del desastre. 
Conclusión: se pierde en encadenamiento, porque la última factura que se envió no existe en el SIF. ¿Cual es aquí el procedimiento a seguir? Iniciar una nueva enumeración? Consultar con la AEAT cual fue la última factura enviada y obtener su huella para el encadenamiento? 
Rehacer las facturas que faltan una a una y enviarlas como "subsanación"?

4. Diseños de factura personalizados
Nuestro software permite a los usuarios elegir entre varios diseños de factura, personalizarlos a medida o incluso crearlos desde cero. Para ello usamos un conocido diseñador de informes. que se incluye con el software.
Ahora con VeriFactu tendrán que incluir en sus diseños de factura el QR de VeriFactu. Hemos intentado automatizarlo pero es imposible. En el 99% de los diseños no hay espacio libre para meter ese QR, y mucho menos al principio de la página, como "exige" Hacienda. 
Conclusión: no hay forma. Los clientes tendrán que añadir/personalizar su plantilla de factura para añadir el QR.
Tratándose de miles de clientes, es inviable que nosotros podamos hacer eso, por no mencionar el coste que ello supone (horas de trabajo, precio...).
Los clientes quieren usar su propia plantilla de factura, que han estado usando durante años, con sus colores, su diseño, etc. A los clientes nuevos se les puede predefinir el diseño especial/oficial para VeriFactu, pero los antiguos tendrán que adaptar el suyo sí o sí.
Además, el SIF permite al usuario cambiar el modelo de factura cuando quieran, y el QR solo se incluye en uno. Y no, no es posible impedir eso (no puedes permitir modificar un diseño pero no elegir otro, no tendría sentido. Además, el diseñador de informes no lo desarrollamos nosotros).
En fin, que como se puede apreciar, hay muchísimas consecuencias que creemos que no se han tenido en cuenta, dejando el 100% de responsabilidad sobre nosotros, lo cual es injusto, por no decir abusivo.

Y hay muchas otras dudas que nos han surgido en las últimas semanas que también tendrán sus consecuencias:

5. Usuarios que no saben si son persona física o jurídica: Esto puede resultar inverosímil, pero ocurre, y mucho. Sobre todo con cooperativas, etc. 
6. Permitir el envío al Entorno de Pruebas solo a nosotros como desarrolladores: habría que pensar cómo permitir que solo nosotros podamos hacerlo, pero sin embargo, en el mismo software, enviar a Producción cuando lo que se envíe sea nuestra facturación real.
7. "Autofacturación" en empresas agricultura: hay empresas que realizan auto-facturación (se facturan a sí mismas en nombre de un proveedor tercero). No es nuestro caso, pero hemos hablado con otras empresas de software que nos han trasladado también esta duda. 
Para esa funcionalidad tampoco parece haber respuesta, según nos han dicho.

En definitiva, como opinión personal después de año y medio centrados exclusivamente en VeriFactu, sin recibir a cambio poco más que avisos de posibles sanciones y 100% de la responsabilidad, creemos sinceramente que hay cosas que se han planteado mal, o de forma incompleta. 
Entendemos que vuestra intención es que nos lo tomemos en serio, pero el estrés y ansiedad que nos ha generado todo esto es difícilmente compensable. Nuestro software lleva años con TicketBAI y la factura electrónica de México, Costa Rica, etc. sin tener que pasar por todo esto en ningún momento. 
Creo personalmente que las cosas se podrían haber hecho mejor, y espero que aún estemos a tiempo de ser algo más permisivos con algunos casos concretos.

Es muy bueno y tiene muchos puntos xomunes para los demás, esa es la única forma de que vayan suavizando la interpretacion de la normativa, de ellos no va a salir y solo es viable de esta forma, exponiendole los problemss que hacen que te hagan perder capacidad rn los servicips y por tanto repercuta en menos ventas. Lo lógico es que se lo pasen a un responsable y arreglen, al menos, algunas de los problemss que les detallas.
Lo que se han sacado de la manga con loss programas de pruebas es irracional y deja muchsimos servicios fiera del mercado, no solo las demos, han querido hacer un apaño c9n lo de enviat inmediatamente la anulación, pero como comentas se le escapan muchas cosas.
Yo tuve que estar 2 semanas cruzandome correos por qur mi software es multiuso y al final no se enteraban de nada, ellos han hecho un estudio básico del mercado y se estan tropezando con una galaxia de combinaciones que no controlan ni quieren estan obseilnados con cerrar el virculo tanto que la están liando y tengo claro que ll que van a encontrar es que cada uno ha hechp lo que ha podido para poder seguir funcionando sorteando como pueda tanta regla.