| espinete |
30-07-2025 12:26:05 |
Ya tengo respuesta de VeriFactu. Esta vez han sido bastante rápidos.
Como siempre, sus respuestas dan por sentado muchas cosas, y dejan claro que no tienen ni idea del mundo real.
Esta es la respuesta que me han dado, y luego lo que les voy a responder yo
Código:
1. Con carácter general, un producto comercializado, no debe enviar a los servicios de preproducción de la Agencia Tributaria, sino que el envío debe producirse a los servicios en producción.
Se recuerda que el servicio de preproducción solo se pone a disposición de los fabricantes en fase de pruebas de sus productos de facturación.
Sobre la posibilidad de utilizar el modo de pruebas con remisión a preproducción antes de que se haya configurado definitivamente para el usuario, es decir, en el proceso de instalación y configuración inicial:
para realizar una remisión al servicio "de pruebas" de la AEAT el software deberá ser manejado exclusivamente con la identificación del fabricante, y nunca con la del usuario,
y sólo a los efectos de hacer “una prueba inicial" para confirmar que se ha instalado y configurado adecuadamente y que, por tanto, funciona correctamente.
2. No existe en toda la normativa alusión a la generación de facturas de "pruebas o similares" (facturas ficticias para diversos fines, como formación) en un sistema informático de facturación (SIF) operativo que factura "en real",
ya sea V*F (en cuyo caso apuntaría al entorno de producción) o no. Por consiguiente las facturas de prueba o formación, siempre que lleguen a ser facturas propiamente hablando (es decir que se generen de forma real,
y que no sean simples borradores o prefacturas no confirmadas), deben ser tratadas como si de facturas reales se tratara a los efectos del RD 1007/23 y resto de normativa de desarrollo.
Ver más detalles en la aclaración/FAQ a desarrolladores nº 11 «BORRADORES DE FACTURA, “PRE-FACTURAS”, FACTURAS PROFORMA, ALBARANES, FACTURAS DE PRUEBA…"» del documento " Preguntas frecuentes de empresas de desarrollo (actualizado 16-05-2025) " publicado recientemente en la web de desarrolladores de la AEAT.
3. Tenga en cuenta que los sistemas que funcionan en modo VERI*FACTU tienen la gran ventaja de que al remitirse los registros de forma inmediata, es la AEAT quien custodia y conserva la información de dichos registros.
En la situación planteada, siempre que lo deseen pueden hacer uso de los servicios web de consulta para recuperar toda la información de los registros enviados a la AEAT pudiendo recuperar los datos de esos últimos registros que no fueron incluidos en la última copia de seguridad.
Tras una restauración de datos, lo ideal es detectar el desfase entre la numeración interna y lo registrado en la AEAT realizando las consultas que le indicábamos. Una vez detectado, puede consultar el detalle de todos los registros que se han extraviado.
Si desde la consulta recuperan la información de esos registros, deben mostrar al usuario que esas facturas ya fueron enviadas y opcionalmente restaurar el contenido del XML recibido. Obviamente deben continuar la facturación desde el siguiente número disponible.
Al consultar con la AEAT los registros de facturación, pueden visualizar y recuperar las huellas de dichos registros. De esa forma podrán continuar con el correcto encadenamiento de los registros en orden cronológico de generación de registros en el SIF, es decir,
el registro generado en último se encadenará con la huella del registro inmediatamente anterior, que habrá podido reincorporar y verificar su huella desde los servicios de consulta de la AEAT.
Si todo esto no fuese posible, ante la imposibilidad de encadenar un nuevo RF (a generar) con el RF anterior (por no disponer de este), evidentemente se deberá empezar un nuevo encadenamiento a partir del nuevo RF a generar, cosa que,
en teoría, solo debería ocurrir en algún caso excepcional de "destrucción" de lo que constituye el SIF (de su instalación, del hardware base que le da soporte, de su almacenamiento...),
cuya solución (reparación, reposición, reinstalación...) supondría la aparición de lo que se consideraría un nuevo SIF (con una nueva identificación/instalación), el cual no tendría "primer RF anterior", que es la única excepción contemplada por la orden ministerial HAC/1177/2024 (artículo 7.b).
4. De acuerdo con la OM HAC/1177/2024, la ubicación del código QR tributario debe estar en la parte superior de la factura. Se pretende con ello ubicarla en un lugar destacado y común para todas las facturas (ordinarias y simplificadas "tiques"),
de modo que el cliente pueda fácilmente reconocer dónde se halla el QR para verificar la validez de la factura. No obstante, y de manera excepcional, se podría ubicar en otro lugar siempre y cuando existieran razones de peso que justifiquen la necesidad de dicho cambio. A este respecto, debería indicarse claramente dónde se ubica el código QR de validación, para evitar confusiones.
Al margen de lo anterior, en relación con las razones que se aportan para el cambio, entendemos que a la hora de configurar el sistema hay que valorar si las razones son "de peso" como para que justifiquen la necesidad de apartarse de la regla general.
En este sentido se realizan los siguientes comentarios:
En primer lugar, es de suponer que lo expresado en la consulta solo se refiere a las facturas "completas u ordinarias", que llevan destinatario, y no a las facturas simplificadas(*), sin destinatario, también denominadas "tiques", que, por tanto, podrían llevar sin problemas el QR al principio.
(*) Habitualmente son menos extensas en cuanto a contenido y más numerosas, lo que plantearía una operativa más engorrosa, lenta e ineficiente (entre otras cuestiones, en el uso de papel si llevaran parte preimpresa),
y más proclive a generar problemas o incidencias relacionadas con la necesidad de encajar correctamente lo preimpreso con el contenido generado por el sistema informático de facturación (SIF).
En cuanto a las facturas "ordinarias" (con destinatario), hay que indicar que la ubicación del QR al principio de la factura, es decir, localizado al comienzo del contenido generado por el SIF, no tiene por qué afectar necesariamente a las cuestiones esgrimidas,
ya que será el SIF el encargado de ajustar el contenido generado al espacio disponible en el papel. A este respecto, en el anexo del "Documento de Detalle de las especificaciones técnicas del código QR de la factura",
disponible en la Sede electrónica de la AEAT, se incluyen diversas posibilidades de ubicación del QR que se consideran compatibles con su ubicación al principio de la factura y que no tienen por qué cambiar la situación del resto de elementos preexistentes, sin provocar, por tanto, los efectos que ha mencionado).
Por otro lado, ya en términos generales a este respecto, cabe señalar que esta forma de expedir las facturas (mediante la composición de una parte preimpresa con otra generada electrónicamente,
especialmente en la medida en que lo preimpreso esté más estrechamente vinculado -en cuanto a su posición o al grado de completitud que aporta- al contenido generado por el SIF) no parece la más apropiada hoy en día porque, entre otros posibles inconvenientes, es menos práctica y flexible que generar su contenido completo desde el SIF. Por ejemplo, obliga a imprimir siempre la factura, lo que no permite generar informáticamente y en origen un PDF de la factura completa (obligando, en su lugar, a escanearla con posterioridad para conseguirlo, pero en formato imagen, menos útil). Esto mismo también impide que sea enviada -por el sistema informático- automáticamente
y de forma directa al cliente vía correo electrónico o aplicación de mensajería, cosa muy común hoy en día y especialmente fomentada por los emisores debido a la comodidad que supone para el cliente (inmediatez y guardado) y, sobre todo, por el ahorro de tiempo
y costes que implica para el emisor: dispositivos de impresión, papel y otros consumibles (como tinta, tóner...), intervención y operativa manual, etc.
Por último, mencionar que el planteamiento de ubicación al principio de la factura pretende alinearse con el espíritu del artículo 29.2.j) de la Ley 58/2003, de 17 de diciembre, General Tributaria, introducido por el artículo de la Ley 11/2021, de 9 de julio,
de medidas de prevención y lucha contra el fraude fiscal. Así se logra dar máxima visibilidad al QR tributario, dado que conviene al objetivo de lucha antifraude para el que nace dicho QR, siendo un pilar fundamental del mismo.
De esta forma se garantiza que destaque -al ser lo primero que aparece en la factura- y llame más la atención a su receptor (muchas veces, consumidor), favoreciendo su uso y contribuyendo a la concienciación y colaboración ciudadana en este cometido,
además de suponer una demostración más de calidad y transparencia en materia de cumplimiento fiscal relacionado con la actividad de facturación de quien expide las facturas, lo que contribuye a proyectar una buena imagen.
Ubicar el QR en otro sitio podría contribuir a restarle protagonismo ("escondiéndolo" o "camuflándolo") y desvirtuar la efectividad de su cometido.
5.Cuando exista duda sobre si el emisor es persona física o jurídica, se debe consultar el censo de la AEAT (a través de la Sede Electrónica o mediante consulta censal automatizada si se dispone de integración con los servicios web).
No es aceptable dejar el dato a interpretación del usuario sin verificación previa.
6. Remitimos a la respuesta proporcionada en la consulta 1.
7. Entendemos que, en la mayoría de casos, el obligado a la emisión no dispondrá de certificado electrónico y aún en el caso de que sí lo tuviera, debería cederlo a la cooperativa con los riesgos que ello conlleva.
Para este tipo de situaciones, deberán optar o bien porque el obligado a la emisión realice un apoderamiento ante la AEAT para otorgar el poder de remisión de los registros de facturación a la cooperativa, o bien deberán optar por la vía de la colaboración social:
Pueden optar, porque la cooperativa, en el caso de que forme parte de algún colegio profesional con convenio con la AEAT, pueda darse de alta como colaborador social y así poder remitir en nombre de terceros los registros de facturación.
Otra posibilidad es que ustedes, como empresa desarrolladora, opten por suscribirse al convenio 017 de colaboración social especialmente creado para empresas desarrolladoras que remitan registros de facturación.
De esta forma, si integran y usan el certificado electrónico de la propia empresa desarrollara podrían remitir en nombre de terceros todos los registros de facturación que generen desde su SIF.
Esto es lo que voy a responderles ahora:
Código:
Buenos días...
Gracias por vuestras respuesta, pero insistimos en que dichas respuestas o soluciones no obedecen a la realidad. Aunque todo pueda tener, para vosotros, una lógica y razonamiento basado en reglamentos,
leyes, etc. lo cierto es que tanto para nosotros los desarrolladores, como para los usuarios, no todo es tan factible. Una cosa es pretenderlo y otra conseguirlo.
En lugar de hacer alusión a las leyes, reglamento, etc. agradecería que fuerais capaces de proponer una solución al problema que supone, por ejemplo, el uso de una "versión demostrativa",
ya que dudo mucho que nuestros clientes acepten la respuesta que nos habéis remitido. Concretamente nos referimos a lo siguiente: poder probar el SIF y hacer facturas de prueba, enviándolas en todo caso al Entorno de Pruebas, siempre que sea antes del 1/1/26 o 1/7/26 (según el caso).
Proponéis que, para poder enviar facturas de prueba, se deba usar nuestro certificado de desarrollador, lo cual obviamente descartamos ya que no vamos a distribuirlo libremente en cada instalación.
Por no mencionar que, además, ese mismo certificado es el que utilizaríamos nosotros de forma interna para nuestra propia facturación, con lo cual se estaría usando tanto para Pruebas como para Producción (nosotros).
El hecho de que no exista en la normativa alusión a "facturas de prueba" no es la solución a la duda planteada. Los usuarios necesitan (lo han necesitado durante 30 años) probar el software antes de comprarlo,
y no les basta con abrirlo y cerrarlo. Que para probarlo ahora deban cargar su propio certificado, rellenar todos los datos, enviar la factura y luego anularla o rectificarla es un paso atrás y tendrá consecuencias a la hora de conseguir nuevos clientes.
La única posibilidad planteada (usar un certificado del fabricante) requeriría que dicho certificado fuera diferente al que usaremos nosotros simultáneamente para nuestra propia facturación, lo cual no es posible por motivos obvios.
La única alternativa, por lo tanto, es impedir que hagan facturas de prueba, o que si las hacen, las rectifiquen/anulen posteriormente. Y todo esto asumiendo que el usuario no está probando varios SIF diferentes, en cuyo caso, habrá hecho pruebas también en los demás.
Que el QR deba ir al principio para que el usuario final pueda localizarlo nos parece completamente innecesario, ya que un QR creo que ya destaca lo suficiente como para diferenciarlo del resto de componentes de una factura (logo, texto, etc.).
En cualquier caso, nuestra intención es colocarlo en la parte superior, pero es en esa parte donde suele ir el logotipo de cada empresa, datos fiscales, etc. No hay más que ver cualquier factura expedida por cualquier empresa para darse cuenta de que en la mayoría de los casos, hay más espacio en la parte inferior que en la superior.
No obstante, haremos lo posible para que, de forma predeterminada, el QR se imprima en la parte superior.
Sin embargo, no podremos controlar que el usuario final diseñe su propio diseño de factura a su gusto y lo coloque donde él quiera. Eso es inevitable y en ningún caso podremos hacer nada para evitarlo, salvo advertirlo en la documentación.
Lo único factible técnicamente ahora mismo es intentar detectar si el diseño de factura que se va a imprimir incluye o no el QR, y si no es así, impedir imprimir (o exportar a PDF).
No entendemos por qué el hecho de recuperar/restaurar una copia de seguridad antigua (de hace 3 días por ejemplo) requiere o supone la aparición de un nuevo SIF con una nueva identificación/instalación.
El PC es el mismo, la empresa es la misma, el software es el mismo, no se ha actualizado, ni reinstalado, etc. Solo los archivos (datos) se han recuperado.
No nos queda más remedio que acatar la normativa, pero sinceramente, creo que no estamos preparados, ni nosotros ni vosotros, para lo que se nos viene encima. La normativa, reglamento, requisitos, condiciones, etc. están muy bien como teoría,
pero en la práctica, en el día a día, en el mundo de los mortales al que hay que bajar de vez en cuando, las cosas no funcionan así, y menos impuestas casi de un día para otro. Solo espero que cuando todo esto entre en vigor, seáis igual de permisivos que han sido en TicketBAI, Costa Rica, México, Guatemala y el resto de países durante los primeros meses/años de implantación.
Un saludo y suerte
|
