|
Cita:
|
Imagina que emito una factura y hacienda me devuelve la respuesta distinta a "Correcta" o "Aceptada con Errores"
Si no es en uno de esos casos hacienda no dispone del registro, no hay huella traceable, no hay registro a subsanar, no hay registro a emitir factura rectificativa, no hay nada. Por lo que entiendo que solamente debo hacer una "subsanación", "rectificativa" o "eliminación" de un registro que está registrado, si no está registrado nada podré hacer. Trasladaré la consulta directamente a hacienda, pero creo que me diran lo que yo percibo, que si no hay registro no hay factura "legal" por lo que si yo emito un documento de un registro no válido, pues evidentemente no va a tener validez fiscal. |
Cita:
Y a parte, se tienen que enviar los registros de facturación generados, independientemente de que sean aceptados o no. A ver que te dicen en la consulta, ya nos contarás. Saludos |
Cita:
Yo estoy totalmente convencido de que es así. La factura primero la emites, luego la envías y luego manejas el resultado. Aunque sea rechazada y no conste en sus registros hay que hacer una factura rectificativa de la misma. Eso ya lo he consultado y es así. Saludos. |
Efectivamente, eso de generar el registro y enviarlo a ver que tal no va a colar. Estas comprando papeletas para el premio gordo y va a ser para ti solo.
|
respecto a lo que ha comentado ermendalenda de que los servidores de aeat puedan estar caidos un tiempo....
¿se os ha ocurrido si sería factible comprobar si el servidor de Hacienda está caido? ¿y cómo? porque veamos: si estoy generando un envío con 300 facturas, con todo el encadenamiento de una y otra, y al enviar resulta que los servidores están caidos, me podría haber evitado todo el proceso previo para generar un xml con 300 facturas. Claro, si solo estoy con una factura y la envio sola, en la respuesta ya me entero. Pero si es un bloque de facturas... quizá debería haber buscado un hilo más apropiado, pero lo acabo de leer en este hilo, por eso este comentario/duda |
Cita:
Puedes enviar, por ejemplo, un envio sin registros, solo el soap y la cabecera sin nodos RegistroFactura, 5e devolverá el error 4102que no cumple el esquema pero verificas que funciona el servicio. Aunque tienes que considerar si te merece la pena gastar recursos en hacer una comprobación previa (siempre estás consumiendo recursos) Pero, en caso de error de envios, puedes aumentar el tiempo en los reintentos, ÿa que verifactu te dice que en caso de incidencias tienes que reintentar como máximo cada 1 hora. |
Cita:
Hay que decir, que la generaci´çon del registro de facturación y el encadenamiento tienes que hacerlo si o si, independentemente de que los servidores de hacienda estén caídos o no. Eso es independiente. En cuanto al envío, tal vez podrías evitar hacer cosas, pero no creo que sea factible (ni seguro 100%), porque las caídas de los servidores o las sobrecargas pueden ser puntuales. De forma que la comprobación te puede dar OK, pero el envío ERROR o viceversa. |
buenos días !
he estado mirando este hilo pero no he sacado una conclusión clara. Por lo que he entendido: 1) Hasta el 1 de julio de 2025, los programas pueden recibir actualizaciones. 2) Pasada esa fecha, ya no se podrá actualizar ni mantener programa alguno, a no ser que vayan a soportar el sistema verifactu. 3) Pasada esa fecha con un programa verifactu, ¿se podran enviar registros a la AEAT? ¿o será voluntario su envío hasta el 2026? X favor a ver si alguno puede aclararme este tema. gracias ! |
1 y 2 seguro que si, sobre la cuestión 3 no estoy muy seguro, por ahí leí que se podían enviar de forma voluntaria, pero no estoy muy seguro.
|
Cita:
Cita:
|
Buenos días,
Y en la "realidad" que vais a hacer? Les vais a suspender el mantenimiento hasta que decidan entrar? Gracias |
Cita:
Es que no van a poder hacer facturas si no es así. La opción de no actualizarse es no hacer facturas y trabajar en negro. responsabilidad suya. |
Cita:
Y en ese tiempo, desde julio hasta octubre-noviembre, es mi duda de si les podemos girar o no el mantenimiento mientras Gracias de nuevo |
Cita:
1. Después del 29 de julio no podrás comercializar (vender) ningún programa de facturación que no esté adaptado a VeriFactu (y opcionalmente No-VeriFactu). Pero los programas que ya tienes en uso antes de esa fecha, serán válidos y su uso será lícito hasta que VeriFactu sea de obligado cumplimiento para los obligados tributarios (esta fecha está por confirmar, pero se habla de 1 de enero de 2026). 2. Mejorar los programas que ya tienes en funcionamiento antes del 29 de julio, se supone que los puedes seguir actualizando/mejorando/corrigiendo errores mientras no haya entrado en vigor la normativa para los obligados tributarios. 3. Falta por aclarar este punto, pero suponiendo que el 1 de julio ya la AEAT tendría que tener todo operativo, supongo que se entraría en un periodo de gracia o de "pruebas" para ir verificando que todo va bien antes de su definitiva entrada en vigor para los obligados tributarios. |
Cita:
Lo entiendo y es comprensible. Hay que hacerles entender que cuanto antes se actualicen mejor, aunque no tienen obligación de activarlo, no se si tu programa permite eso. En el nuestro por ejemplo, en las nuevas versiones está "disponible", pero puedes no activarlo "por ahora". Pero si no quieren actualizarse, y prefieren quedarse con la versión antigua, no puedes darles soporte ni mantenimiento. Si lo haces te arriesgas a multas. Ya será decisión tuya si te saltas esa restricción o no. |
Cita:
"Me quedo" con esta opción que creo la más lógica Gracias a los dos ^\||/ |
Hola, mantenimiento , mientras no toques codigo , me imagino que si , hasta la entrada en vigor para ellos, osea si cae la base de datos y tu le recargas un backup , si y cosas similares, otra cosa es que se detecte un fallo de seguridad o , una opcion que falla por x, ahi si que no puedes aplicarles ningun parche ,ni nada de eso si no actualizan el programa a verifactu, en enero empresas, julio personas fisicas , se acabo , no puedes dar servicio si no cumple Veifactu en cualquiera de sus 2 versiones o SII o otra cosa que no conozca yo y este exento.
Eso si deveriais de dejar claro que la cuota que pagan no es un alquiler del programa , sino una gestion del funcionamiento correcto de las bases de datos... o cualquier cosa parecida que se os ocurra. |
Hola
por lo que he entendió es: 1)las empresas que facturen mas de 8 millones € deben de tener los programas listos para el 1 de julio 2)los programadores no podrán vender ni actualizar programas de facturación después del 29 de Julio si no cumple la normativa 3)el resto de empresas (menos de 8 millones) y autónomos no hay fecha pero supuestamente será enero y Julio del 2026 el que mas dudas me produce es el 1 de julio, primero el tema de los 8 millones, yo he entendido que esa es la cifra tope pero como el foro empieza diciendo 6 millones me han entrado dudas, Y otra cosa es el tema de las grandes empresas que deben usar el SII, en la empresa en la que trabajo solo conozco dos empresas que se puedan considerar gran empresa y usan el SII por lo que tengo entendido estas deben tenerlo listo para el 1 de julio pero también he leído que las empresas que usan el SII están exentas. También esta el tema de que estas empresas nos piden actualizaciones constantemente y no se si en este caso nos obligan también ha tener listo el verifactur. |
Cita:
Cita:
Cita:
Cita:
|
Cita:
|
Están exentas tanto de modo verifactu como de modo no verifactu, si vas por el SII te riges por las normas del SII y no por las de verifactu/no verifactu.
|
Yo lo que tengo claro es que no tocare ni haré ninguna acción de cualquier tipo a un cliente que en julio no haya actualizado a VeriFactu con su debido mantenimiento contratado.
|
Retomo esto porque tengo una duda que me lleva dando vueltas a la cabeza....
Si las empresas desarrolladoras tienen 9 meses para adaptar el software, PERO, se está trabajando para que los obligados tributarios empiecen a partir del 1 de enero de 2026... ¿Qué sentido tiene que mi software esté adaptado a fecha 29 de julio, si hasta el 1 de enero del año siguiente no entra en vigor? Tengo que tener un software 'capaz' de generar registros xml, firmarlos, generar un QR, mandarlo a hacienda, recibir la respuesta (contando que uso el sistema Verifactu) .... pero tenerlo desactivado hasta el 1 de enero??? Como van a comprobar que estoy cumpliendo con que mi software es compatible con Verifactu, si no voy a generar registros xml, ni QR ni nada hasta el 1 de enero?? Entiendo que puedan ofrecer a las empresas enviar los registros a partir del 29 de julio, pero en todo caso sería algo opcional, no obligatorio, no? No se, no le veo sentido la verdad, a ver si alguien me lo puede explicar. Gracias |
Cita:
Cita:
|
Cita:
Bueno... Le veamos más o menos sentido la ley es clara. A partir del 29 de julio tienen que estar todos los programas actualizados y a partir del 1 de enero empezará a enviar datos quien corresponda. Yo imagino que lo habrán hecho así para que intentar que no le pille el toro a mucha gente (cosa que seguramente pasará) y que no puedan poner pegas el día 1 de enero sabiendo que tendrían que estar operativos a partir de final de julio. Yo por mi parte intentaré que los clientes hagan pruebas antes de enero (cosa complicada) porque si es cierto que el principio del año 2026 entre lo que ya cae de por si (primeros de año, cierres y aperturas, etc etc etc) con el añadido del Verifactu va a ser memorable. Saludos. |
es decir, mi software tiene que estar adaptado a fecha 29 de julio, por si mi cliente quiere enviar de forma voluntaria los registros, antes de que sea de forma obligatoria el 1 de enero?
Interesante...... No se, como no ofrezcan algún tipo de beneficio por enviar registros voluntarios (como hicieron los de ticketbai), no creo que la gente quiera meterse en esos fregaos hasta que no sea totalmente obligatorio.... edit: lo que comentas newtron, llevas razón, pero no se como van a comprobar en caso de inspección , que un software esté adaptado o no, si no puedes generar qr's 'porque si' o 'de pruebas a ver si esto va' |
Cita:
Sobre la que comentas del envío antes de tiempo, mis clientes empezarán antes, por que el hacerlos todos a la vez y que haya un problema no da mucho margen a las correcciones. |
Nosotros vamos a ir poniendo a los clientes que no pongan muchas pegas que empiecen a enviar a partir de septiembre, así nos hacen de tester y no se junta todo el 1 de Enero, porque sino puede ser memorable la que se va a liar. De echo un cliente nos dijo que el queria empezar a enviar en cuanto abrieran la posibilidad.
|
Cita:
|
Por lo que tengo entendido sera a la definitiva.
|
Cita:
|
vale, pues gracias por las respuestas, supongo que es buena idea que los clientes que más 'predispuestos' estén, vayan haciendo envíos voluntarios ,para ir viendo como va el asunto
|
Cita:
Hasta donde yo sé, los nuevos clientes que empiecen con tu software a partir del 1 de agosto ya tienen que empezar con Verifactu. Es decir, si actualmente tienes 100 clientes con tu software pueden empezar el 1 de enero de 2026 a enviar, pero si por ejemplo el 15 de septiembre haces un nuevo cliente y le pones tu programa tiene que empezar sí o sí con Verifactu. Y por otro lado, esos 100 clientes que ya tienen tu programa pueden no esperar al 1 de enero y empezar con Verifactu antes. De esta manera puedes ir pasando al nuevo sistema poco a poco (yo que sé, cada semana vas pasando uno) y así cuando llegue el 1 de enero ya tienes X clientes en Verifactu (con lo que tendrás todo mucho más testeado) y no te empiezan los 100 de golpe. A ver si encuentro donde vi esta información Cita:
Saludos |
Cita:
No, a partir del 1 de agosto, tu programa, que vendas, instales , etc..**, ha de estar preparado para cumplir al 100% con verifactu*, no estas obligado a enviar registros verifactu. *O Veri*Factu y No-Veri*Factu, para el que quiera contemplar las 2 opciones. ** Si me apuras el que cobre mantenimiento de los programas , tambien habria de dar soporte a verifactu a partir de esa fecha. |
Cita:
|
Cita:
¿y eso que significa exactamente? Si vendo un programa en septiembre... ¿tengo que hacer todos los procesos (las facturas tienen que ir con QR, tengo que hacer el encadenamiento de registros, etc) pero no los envío? ¿y cuando llegue el 1 de enero? si encadeno la primera factura del año con la última de diciembre al enviarla supongo que dará error de huella, ¿no? Porque va a ir encadenada con otro registro previo pero para la AEAT será el primer registro ¿podrías aclararme esto un poco más? Muchas gracias de antemano |
Cita:
Según yo entiendo cualquier programa a partir del 29 de julio tendrá que estar adaptado a VeriFactu. Eso no quiere decir que a partir de esa fecha tenga que enviar ni imprimir qr ni nada de eso sino que tiene que estar adaptado para que el día 1 de enero o el 1 de julio activarlo y comenzar a funcionar adaptado a la nueva normativa. Saludos. |
Efectivamente, el programa tiene que estar adaptado y a partir del 1 de enero 2026 o 1 Julio del 2026 deberia tener la opcion de activarse para el modo Verifactu ( Obligatorio ) o NO Verifactu ( No obligatorio ).
|
Cita:
Cita:
¿y entonces qué mas da que esté adaptado o no? me refiero... ¿como controlan si está adaptado si no se va a usar? ¿que pasaría si no llego al 29 de julio con el programa adaptado pero sí lo tengo por ejemplo el 14 de septiembre? Perdonar las preguntas, pero es que estaba convencido que a partir del 29 de julio las nuevas empresas tenían que usar la nueva normativa y parece que estaba equivocado :eek: |
| La franja horaria es GMT +2. Ahora son las 06:12:39. |
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