[emailesc]

Bueno, ya les he enviado el escrito, se van a acordar de mi padre por el tocho, pero bueno... a ver si responden...

Buenos días.
Les traslado una serie de dudas que tenemos respecto a pruebas del software Verifactu en clientes (en nuestro caso es solo Verifactu), comienzo de uso del mismo, implementación en las unidades (en nuestro caso establecimientos de hostelería y restauración), y formación de clientes y empleados.
Las dudas surgen porque los desarrolladores tenemos dos fuentes de información: las órdenes ministeriales que definen y estructuran legalmente Verifactu, y las Preguntas y Respuestas que aparecen en la Web de Hacienda y que ofrecen interpretación y clarificación respecto puntos que puedan ser dudosos en los respectivos BOE’s, HAC y demás legislación al respecto.
Hay una tercera fuente de información, que es este canal por el que me dirijo a ustedes. No obstante este canal es “personal”, en el sentido de que la respuesta solo es conocida, en general, por el remitente, aunque las podemos compartir en diversos foros para conocer exactamente qué y qué no podemos hacer. No estamos encontrando que diversas preguntas y respuestas que estructuran de manera rígida las posibilidades de actuación en pruebas de producto, implementación, comienzo de uso y formación, luego no aparecen en el área pública de Preguntas y Respuestas, creando confusión y en algunos casos indefensión, ya que no tenemos la seguridad de que todos los usuarios y desarrolladores estemos jugando con las mismas reglas: si una empresa no entra en estos foros y las respuestas de que hablamos no aparecen en el área de Preguntas y Respuestas ni en las órdenes ministeriales, ¿cómo pueden conocer estos puntos que, repito, son críticos?
Les paso a exponer los puntos que a nosotros nos generan dudas:
1º Pruebas de nuestro propio producto: necesitamos testarlo en los clientes, porque las pruebas que hagamos nosotros no son suficientes para dar un producto confiable al mercado, y menos uno con responsabilidad fiscal. Respuestas que han dado a preguntas de usuario:
Si se desea poder probar el SIF, deberá ser con el certificado electrónico cualificado válido y admitido instalado (porque, si no es así, el SIF no puede estar operativo y ser usado). Desde ese momento, el usuario puede ya expedir facturas con él, que siempre serán "reales" (con su QR tributario, y cuyos RF de alta son remitidos a la AEAT) pero, en este caso, al ser expedidas con la intención de hacer pruebas (y no corresponderse con bienes entregados o servicios prestados), la normativa contempla que para las facturas expedidas que no sean tales, siempre y cuando no diga otra cosa el reglamento de obligaciones de facturación, aprobado por el Real Decreto 1619/2012, deberá procederse a la inmediata posterior anulación de ellas (para que no cuenten como facturas reales), por lo que luego deberían siempre ser anuladas por el usuario, remitiéndose entonces automáticamente a la AEAT el debido RF de anulación (sin perjuicio de que, además, el usuario "describa" esas facturas con algún texto que las califique "de pruebas"). Para facilitar esta operativa "de pruebas (o de formación) del SIF" y hacer más cómoda, tranquila y segura su realización por parte del usuario (evitando descuidos u olvidos), el SIF podría ofrecer una funcionalidad de "facturar en pruebas (o formación)" ya preparada para que haga todo esto automáticamente: dejar al usuario expedir 5 de mayo de 2025 20 facturas "reales" (con QR y remitido su RF de alta a la AEAT) pero "para pruebas/formación" (que deberá poder distinguir, por ejemplo, con numeración en una serie especial de tipo PRU 25 XXXX), describirlas visible y claramente como "de pruebas" y asegurarse de que siempre serán anuladas (con remisión de RF de anulación a la AEAT) una vez terminadas dichas pruebas o formación. De esta manera, el usuario se despreocupa, lográndose así el objetivo de poder probar el SIF (o enseñar su funcionamiento), ya que después se "arregla" oficialmente todo lo hecho en pruebas/formación, a la vez que se actúa cumpliendo con el RD 1007/2023, y siempre de forma transparente, ya que se deja el rastro que explica toda la operativa llevada a cabo.
Una prueba de producto en un entorno con responsabilidad fiscal y además con el certificado de un cliente, no es una prueba, es jugártela. ¿Qué pasa si el software funciona mal y envía 200 facturas que luego no se anulan? Aquí precisamente lo que necesitamos ver es si el software es fiable en todo momento, con usuarios no técnicos y en condiciones reales, no "de laboratorio".
Pero independientemente de la interpretación es un punto clave, que no aparece en el actual documento de Preguntas y Respuestas.

2º: Producto adaptado a Verifactu pero sin activar. En el BOE lo que dice es que el producto, después del 29 de julio, "debe estar adaptado", "cumple por diseño" y "tiene la capacidad de" de todo ello yo puedo interpretar que mi software puede cumplir todo eso pero estar desactivado hasta que el cliente decida o llegue el 1 de enero (empresas):
Respuesta ofrecida a Usuario:
NO puede darse que un producto ya adaptado funcione transitoriamente en modo "no adaptado" hasta el 1 de enero de 2026, o el 1 de julio de 2026
Otra Respuesta:
A partir del 29/7/2025 (que es cuando los productores y comercializadores de sistemas informáticos de facturación (SIF) están obligados a proporcionar solo SIF adaptados) los nuevos clientes solo puede contratar un SIF adaptado (el fabricante está obligado a ofertar únicamente productos adaptados) y éste debe actuar y funcionar acorde al reglamento. Es decir, remitir con normalidad los registros generados a la AEAT ya desde el primer momento

Si no puedo actualizar el producto antiguo y tengo que instalar o actualizar a un producto adaptado y y además tiene que empezar sí o sí con el (excepto que siga usando otro software no adaptado anterior), entonces la fecha del 1 de enero y el 1 de julio no es real, la fecha máxima es cuanto se tenga que hacer una actualización por obligación, por ejemplo un área del software desconfigurada o con error. En Preguntas y Respuestas no aparece. Sin embargo este es un punto capital, porque además se debe explicar claramente a los clientes: no puede ser que sea verdad pública que es obligatorio el comienzo como máximo el 1 de enero (para empresas) y yo “obligue” a mi cliente a empezar ya, no es creíble

3º: Implementación y Formación a los clientes. Cada equipo es diferente, en nuestro ordenador el software puede funcionar bien pero cuando lo llevas a producción en el equipo del cliente salen fallos. Eso lo sabe cualquier desarrollador. Necesitamos poder probarlo (después de haber hecho las pruebas de producto reales con clientes que comentábamos antes) en cada instalación y necesitamos formar a los empleados. Lo de hacerlo en un entorno de producción, enviando con el certificado del cliente, aunque sea una empresa de prueba (en nuestro caso por ejemplo eso de crear una empresa de prueba no es tan sencillo, no es una aplicación multiempresa), no es adecuado, vuelve a ser jugártela, y vuelvo a repetir la pregunta ¿Qué pasa si el sistema falla y se envían 200 facturas al entorno de producción y luego no se anulan? La respuesta en algunos casos podría ser: "El productor debe asegurarse de que su producto funciona correctamente". Pero claro, de eso se trata, de que podamos hacer pruebas en un entorno sin riesgo... que lo hay
Respuesta ofrecida a Usuario:
El servicio VERI*FACTU en preproducción de la AEAT ("entorno de pruebas") SOLO se proporciona a los fabricantes de SIF para que puedan realizar sus pruebas en la fase de desarrollo de los SIF de cara a asegurar que su producto funciona correctamente, pero NO en la comercialización de productos acabados.
Esto tampoco aparece ya en Preguntas y Respuestas ni aparece en el HAC, o al menos yo no lo he encontrado. Por otra parte los límites entre lo que es desarrollo y lo que es comercialización no sé si tienen una delimitación estándar reconocida. Por ejemplo, para mí las pruebas de producto en clientes reales son parte integral del desarrollo. No se pueden separar, ni conozco ningún desarrollo de software que no las haga, por lo que se debería, al menos en estas pruebas, poder realizarse con clientes reales pero enviando al entorno de pruebas al menos dos o tres semanas, lo cual tampoco supondría una excesiva carga para los servidores de prueba. En caso contrario, con nuestro primer cliente que instalemos el producto vamos a tener que hacer todo a la vez: pruebas de producto en campo, implementación del software en su negocio y formación de empleados, todo ello en un entorno con responsabilidad fiscal y multas que pueden llegar a 150.000 € y aunque entiendo que no llegarían a esos extremos por errores de los que hablamos, la indefinición y tensión de “lo que me puede costar un error” a mí o mi cliente, no es el entorno adecuado para trabajar.

Por todo lo anterior les pregunto:
· ¿Se pueden considerar los test de producto parte integral del desarrollo y enviar una serie de clientes al entorno de pruebas, en lugar de al de producción. Sea con el certificado del cliente o sea con el nuestro, para que no haya errores.
· ¿Se podrían poner estas preguntas y respuestas de estos forma clara y actualizada si procede en el área de Preguntas y Respuestas para que dispongamos de información tangible y proveniente de Hacienda para facilitar a nuestros clientes y no crean que nos inventamos las cosas? ¿Lo harán?
Les pido disculpas por la extensión del escrito, pero esto son puntos capitales para nosotros
Atentamente: