|
Cita:
Lo que no vamos es llegar a diciembre y estar con el apuro que estuvimos este año. |
Cita:
Ellos no pueden decir "si alguien actualiza a la versión ya adaptada tiene que empezar a enviar" y quedarse tan panchos, porque puede que ESA actualización sea por otro motivo urgente que necesite el cliente (un bug chungo importante). Y no, no es viable tener en producción una versión del software adaptada y otra no. Eso es una locura. Una cosa es tener una versión del software y otra es un software grande, con 4 versiones diferentes, addons, módulos opcionales, etc. ¿hay que tenerlo todo duplicado porque Hacienda no se ha currado mejor las cosas? Pues no |
Yo tampoco lo entiendo así.
Los desarrolladores tenemos que tener el programa preparado desde Julio, eso es clarísimo, y el cliente podía actualizar su programa hasta el día 31 de Diciembre. Pero un cliente que hubiese actualizado ya la versión el 15 de Septiembre en mi opinión no estaba obligado a realizar los envíos hasta el 1 de Enero, sólo que si lo deseaba, podía realizar los envíos voluntariamente antes, no obligado. Es más, así lo hemos hecho nosotros, actualizados ya prácticamente todos los clientes, pero sólo enviando los que han querido hacerlo antes para evitarse el caos de Enero. |
Cita:
A partir de ahí, como si quieres ir por una carretera comarcal a 240 km./h. |
Cita:
Pues precisamente porque no es viable mantener varias versiones, si el cliente quiere que le soluciones el bug o quiere tener una nueva funcionalidad que actualice y que empiece en Verifactu |
Cita:
Pero entonces tu versión del 15 de septiembre tiene la opción Verifactu, la opción No Verifactu (si la tiene), la opción SII (si la tiene) y una última opción que es "todo igual". Lo siento, pero esa última opción dijeron mil veces que no se permite. |
Cita:
Claro, van a detectar a la primera que software echa para atrás los envíos. En cada uno de los envíos va el apartado de "SistemaInformatico", con el nombre y el Cif de nuestra empresa |
Yo creo que la parte que cuesta entender es que Hacienda lo único que ha planteado es un chantaje puro y duro, al estilo de la mafia calabresa o similar. No están por la labor de ayudar ni facilitar ni gallinaceas hembras en ácido acético. Os empeñáis en buscar la "lógica" de un comportamiento normal en alguien que no es normal y no ha planteado las cosas para facilitar la transición, sino para meter Verifactu a hostias (perdón por lo de Verifactu). Por cierto, así les ha salido de bien la jugada: Diciembre: 80% de las empresas sin actualizar. Y todavía lo venderán como un éxito.
|
Lo "bueno" que tenía la fecha del 1 de enero de 2026 es que en un mes se acababan todas estas interpretaciones: ya no habría dudas de cómo tenía que comportarse nuestro software y qué opciones debía tener o no
Ahora, esto se alarga un año más: uno lo entenderá de una manera, otro de otra, ellos no lo sabrán aclarar... |
Cita:
|
Cita:
|
Cita:
|
Cita:
Vuelvo a poner la respuesta de la AEAT: Cita:
Seré yo, pero es que no entiendo cómo de estos puntos (para mí tan claros) sacáis que podéis tener la versión homologada de vuestro software puesta en un cliente y que no envíe a Verifactu. Es que el punto 4 más claro no puede ser :confused: |
Cita:
|
Cita:
|
Cita:
Por ahora nosotros no tuvimos ese caso. PD: le podemos activar el modo SII y ya no se envía nada. Eso sí, bajo su responsabilidad: si tiene una inspección que diga porque está en modo SII. Pero no se lo digas a nadie |
Cita:
|
Cita:
Vale, pues estonces tu software tendrá las opciones: Verifactu, NO Verifactu, SII, TicketBai, No obligados -Navarra (o como quieras llamarle). Ahora, un cliente de Murcia no debería tener seleccionada esa opción, y si la tiene tendrá que explicar el porqué. Pero los usuarios que comentaban más arriba creo que no se referían a ese caso. Se referían a una opción para que la versión homologada de su programa permitiera no envíar porque el cliente aún no quiere estando obligado (el de Navarra no estaría obligado). Y eso es lo que insisto y defiendo que no debería permitirlo. |
Mi propuesta es la siguiente, nos ponemos de acuerdo todos los desarrolladores/as y en cada registro de facturación ponemos en la descripción de la venta: TA-TO-PAGAAAAOO ... ¿de que sirve? pues de nada, pero al menos nos descojamos con la que nos está cayendo.
|
ULTIMA RESPUESTA DEL BUZON DE LA AEAT:
La última información que nos consta en nuestro buzón es la que le trasladamos a continuación: No nos pregunten más qué hacer con los clientes que ya envían y quieren dejar de hacerlo porqué ni siquiera nosotros mismos sabemos que cojones decirles. Por último, le recordamos que desde este buzón se ofrece soporte informático a las especificaciones técnicas, funcionales y de contenido referidas en el Reglamento que establece los requisitos que deben adoptar los sistemas y programas informáticos o electrónicos que soporten los procesos de facturación de empresarios y profesionales, y la estandarización de formatos de los registros de facturación, aprobado por el Real Decreto 1007/2023, de 5 de diciembre, publicadas en la Orden HAC/1177/2024, de 17 de octubre. |
| La franja horaria es GMT +2. Ahora son las 19:21:16. |
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