![]() |
Cita:
|
Cita:
".....desde el día 23 de abril de 2025 se encuentran en producción y disponibles todos los servicios VERI*FACTU de la AEAT, tanto para la remisión/recepción voluntaria de registros de facturación (RF), como para el cotejo del código QR tributario y la consulta de datos" "Cualquier sistema que se comercialice adaptado al RD 1007/2023 podrá ser utilizado, con plena validez fiscal y sin consecuencias negativas de ninguna índole, desde ya mismo" |
Por lógica, repito, por lógica, el programa debe estar preparado para verifactu, pero no puede obligar al usuario a usarlo porque no está obligado hasta el 2026, así que por lógica, repito por lógica, debe haber una posibilidad de que no envíe datos. Aunque el programa esté preparado, pero si no es 01.01.2026 entonces debe permitir no enviar.
![]() |
Hombre, si existiera un programa que cumple con Verifactu y que es capaz de no enviar a petición del cliente tendrías toda la razón.
|
Cita:
Efectivamente: tu no estás obligado a enviar hasta julio de 2026, pero como todos los desarrolladores de software hemos cumplido con lo que dice la ley (:D) no vas a encontrar en el mercado ningún programa que te permita NO enviar. Y si por un casual lo encuentras (:D:D) te están vendiendo un software no homologado que no cumple la ley. Y por tanto igual te cae una sanción a ti y otra a quien te lo vendió |
Cita:
Y no, no hay "dos versiones" de un software en la nube. Te digo más: nuestro software requiere que el cliente, además, contrate un "servicio verifactu" (una suscripción) aparte. El software puede estar "preparado", pero el cliente tiene que contratar ese servicio para poder hacer los envíos, así que el software funciona con VeriFactu pero el cliente elige cuándo empezar a enviar. Lo que está claro es que si este tema está generando tanta polémica, es porque desde un principio ha sido mal planteado y mal explicado. Normal, teniendo en cuenta que quien hace la normativa probablemente no tiene ni idea de programación ni del mundo real. |
Cita:
|
Cita:
|
Cita:
Para mí está clarísimo que si vendo hoy un programa a un nuevo cliente tiene que empezar a enviar ya a Verifactu. Es la conclusión que saco de la documentación que han puesto. Que no quiere decir que sea la conclusión correcta. A lo mejor tienes tu razón y es como dices, lo tienes preparado pero no envías. Esperemos que de aquí a final de año no se metan mucho a inspeccionar que hace cada programa y cuando llegue enero ya no habrá lugar a malas interpretaciones |
Yo les acabo de mandar un correo con la pregunta a ver que me contestan.
Yo tambien estoy esperando a actualizar porque entiendo que en cuanto lo haga tienen que empezar a enviar. Ahora en Septiembre comenzaremos a ir cogiendo a algunos clientes para que empiecen a enviar. |
Cita:
https://www.clubdelphi.com/foros/sho...12&postcount=3 Cita:
|
Cita:
Uis Antonio... dime cuánto quieres que te compro ese logo :D |
Ya me contestaron:
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. En cambio, a partir de 29/7/2025 un cliente antiguo con contrato de mantenimiento en vigor puede decidir entre: a) Seguir usando el SIF no adaptado que tenía, sin actualizarlo (si el fabricante ofrece esta posibilidad) hasta que le toque cumplir con el RRSIF (1/1/2026 o 1/7/2026) b) Actualizar el SIF no adaptado que tenía a una versión adaptada (y que actúe como tal desde el primer momento) , o contratar y usar un nuevo SIF adaptado (el fabricante está obligado a ofertar solo "nuevos" producto/s adaptado/s). Añadir que debe hacerse constar que la fecha límite para el inicio de la comercialización exclusiva de productos adaptados es, como comentábamos más arriba, el 29 de julio de 2025. No obstante, nada impide que estos productos empiecen a comercializarse con anterioridad. En este sentido, los productos comercializados que hayan sido adaptados a la nueva normativa solo podrán usarse en modo adaptado, ya sea, no Veri*factu, ya sea Veri*factu. Por lo tanto, es decisión del usuario activarlo en una u otra modalidad, en el caso de que el producto comercializado contemple ambas. Por el contrario, 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, según los casos, fecha a partir de la cual su utilización pasa a ser obligatoria. En resumen, los productos comercializados como adaptados, deberán funcionar en alguna de las modalidades reguladas en el reglamento de sistemas informáticos de facturación RRSIF aprobado por RD 1007/2023, tal y como constará en la correspondiente declaración responsable suscrita por su fabricante. Por otro lado, hasta el momento de su obligatoriedad, se pueden seguir utilizando sistemas no adaptados de los que los usuarios dispongan (cuyo uso se puede simultanear con el de SIF adaptados; estos últimos podrían incluso dejar de usarse -en favor de los no adaptados- hasta que fuera obligatorio utilizarlos). Pueden revisar a este respecto la aclaración/FAQ a desarrolladores nº 1 "PERIODO TRANSITORIO" (junto con la nº 2 "CUÁNDO SE PUEDE EMPEZAR A USAR SISTEMAS INFORMÁTICOS DE FACTURACION ADAPTADOS AL RD 1007/2023" y nº 3 "CONSIDERACIÓN SOBRE FABRICACIÓN Y COMERCIALIZACIÓN DE UN ÚNICO PRODUCTO SIF VS. UN “CONJUNTO, PAQUETE O FAMILIA” DE PRODUCTOS SIF, EN LO QUE CONCIERNE A CUMPLIR O NO CON EL RD 1007/2023") del documento "Preguntas frecuentes de empresas de desarrollo (actualizado 16-05-2025)" publicado recientemente en la web de desarrolladores de la AEAT. |
Cita:
Exacto, lo que ya ponía en el documento de FAQs. Y aclarando una vez más (ya lo habían hecho, como se puede ver en el link que puse 3 comentarios más arriba y cuyo post es de hace más de un mes) que si está "homologado", "preparado", "adaptado" tienes que enviar. |
Cita:
Edito: Del párrafo en negrita se deduce que no van a tener en cuenta lo enviado con validez fiscal hasta que no sea el periodo obligatorio. |
Yo del párrafo entiendo que puedes usar uno no adaptado previo en vez (o a la vez) de uno adaptado (si tienes los dos) y enviar o no.
|
Cita:
Todo esto está documentado, la respuesta que le han dado a Faneka lleva meses publicada |
Cita:
Debemos ser los únicos que los vemos muy bien explicado, al menos lo referente a este punto :confused: |
Cita:
|
Cita:
Lo que es raro es que la aeat no hayan inventado una pegatina para poner en lugar visible, bueno mejor no doy ideas. |
Cita:
|
Cita:
|
Cita:
Ten e cuenta que hasta el 31 de diciembre puedes estar facturando con el mismo O.T. desde SIF sujetos a verifactu y no sujetos a la normativa y si finalmente lo que envias no suma lo que declaras poco pueden comprobar, ahora sí, te pueden requerir todas las facturas de un periodo para verificar que posteriormente no te hayas cepillado ventas, en cuyo caso solo ll podran comprobar contra los registros enviados. Validez fiscal? Si pero a medias, no vale para totalizaciones y de lo anterior al 29 de julio, si tienes las facturas bien pero no cuadran con los envios y hacen verificaciones te puedes acoger a lo que te han dicho, que eran errores del periodo volubtario, a mi tambien me contestaron en el email lo mismo |
Cita:
|
Cita:
|
En la pregunta 11 hay un trozo que dice así:
Por lo que se refiere a las facturas de prueba o para formación o de test, si bien se entiende su utilidad, no está aceptado en la normativa que un SIF operativo que factura "en real", ya sea VERI*FACTU (en cuyo caso apuntaría al entorno de producción) o NO VERI*FACTU, pueda producir “facturas ficticias” o facturas que no son tales. Por consiguiente, las facturas de prueba o facturas de formación, elaboradas con un SIF adaptado, 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. A este respecto, y aunque puede implementarse de diversas formas, 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"). Yo entiendo que si las pruebas que hagas tienen que ir a producción con el certificado correspondiente y te dicen que luego las anules, si deben tener "validez fiscal". |
Cita:
Cita:
|
Mi opinión es que en el momento en que a aeat acepta que hasta el día 1 de enero se pueden simultanear dos programas, uno adaptado y otro no, los datos que se envíen no pueden tener ningún tipo de trascendencia tributaria porque no están completos.
Por otro lado cuidadín con las opiniones de nuestro amigo Chatgpt que no son demasiado fiables (por lo menos interpretando la ley). Saludos. |
La validez fiscal (que se refiere a que el documento factura está construido según dicta el reglamento de facturación RD 1619/2012) y la trascendencia tributaria ( que indica que dicho documento oficializa una entrega de bienes o prestación de servicios y por ende ha generado un devengo del impuesto si lo tuviere ) son aspectos que van de la mano siempre. Cualquier factura emitida tiene una trascendencia tributaria. Todo lo que va a Producción tiene trascendencia tributaria y validez fiscal si es aceptado por el servicio Verifactu.
La obligatoriedad de informar a Verifactu a partir del día 1 de enero o del 1 de julio establece que "TODAS" las facturas emitidas deben ser informadas. Hasta ese momento, al no existir obligatoriedad, "NO TODAS" las facturas deben ser informadas a Verifactu ya que se puede seguir usando un programa no adaptado, pero las que son emitidas desde un programa adaptado tienen validez y trascendencia tributaria. Si por error, emitimos una factura a producción desde un programa adaptado por un importe de 5.000€ porque estábamos haciendo pruebas y se nos olvida Anularla, esa factura formará parte del libro de facturas expedidas del cliente y tendrá que declarar su IVA cuando corresponda. |
Cita:
Ahílasdao... yo me refería a que no pueden cotejar si has vendido 10 o 10000 si no están todas las facturas pero efectivamente cualquier factura que se suba debe de ser correcta. |
¡Buenos días! Hace poco más de un mes hice una consulta al soporte del VeriFactu sobre si las facturas tenían validez fiscal y si habría consecuencias por errores en el periodo entre el 29 de julio de 2025 y el 1 de enero de 2026. Les hice referencia al FAQs de desarrolladores, que empieza la pregunta 2 con el siguiente contenido:
Cita:
Cita:
|
Cita:
Correcto, tal cual lo había interpretado. El problema es que se confunden las fechas de Inicio y obligación, la misma confusión en distintos posts. Hay que tener en cuenta que la obligación no es la misma para cada escenario siendo el mismo O.T., es más, ya TODOS (a partitr del 29 de Julio) LOS QUE ESTËN OBLIGADOS A TENER UN SIF en Verifactu o no verifactu y los que lo hayan instalado sin estar obligados después del 28 de Julio, aunque no estuvieran obligados, ese SIF ya tiene transcendencia legal. En resumen: ya hay que descartar lo de no tener transcendencia legal. Eso era para antes del 29 de Julio. |
Hay que "engañar" a los clientes.
Se les convence de activar el VeriFactu en modo pruebas y se les dice que esto solo envía cosas al entorno de pruebas y luego el 01/01/2026 se da el cambiazo forzoso. Así podéis ir recopilando errores de los clientes sin bloquearles la facturación. Igual hasta usando un certificado propio con un SIF distinto para cada cliente y anonimizando los datos se podría hacer sin que se entere el cliente? En plan "una cláusula que permita pruebas controladas" en la letra pequeña del contrato? |
Cita:
Negativo. La aeat no quiere que el endpoint de pruebas sea usado por clientes finales. Es más, te dicen que si tienes que hacer alguna prueba en el cliente que envíes la factura al endpoint bueno y luego la anules. |
Cita:
AÑADO: Veo que ya lo han contestado. |
Cita:
Les falta seriedad a la AEAT para poder hacer eso. Se ve que viven muy felices en su mundo de yupi. Envidia sana. |
Cita:
Lamentablemente creo que ya hay alguno que está haciendo cosas bastante parecidas... Pd: si eso no funciona también está lo de levantarse con una cabeza de caballo en la cama, o lo de romperle las piernas al cliente si a pesar de todo no se deja engañar... |
Nosotros ya tenemos una quincena de clientes activados directamente en producción, que nos están ayudando a limar la aplicación con los problemas que se van encontrando, la mayoría de las veces con las identificaciones de clientes, porque llevan muchos años que han codificado como han querido los NIFS y los nombres, y ahora o están bien o no pasan. Los únicos que hemos usado el servidor de pruebas hemos sido nosotros.
|
| La franja horaria es GMT +2. Ahora son las 23:52:43. |
Powered by vBulletin® Version 3.6.8
Copyright ©2000 - 2026, Jelsoft Enterprises Ltd.
Traducción al castellano por el equipo de moderadores del Club Delphi