![]() |
![]() |
| Paypal | FTP | CCD | Buscar | Trucos | Trabajo | Foros |
|
|||||||
| Registrarse | FAQ | Miembros | Calendario | Guía de estilo | Temas de Hoy |
![]() |
|
|
Herramientas | Buscar en Tema | Desplegado |
|
#221
|
|||
|
|||
|
Cita:
Lo que no vamos es llegar a diciembre y estar con el apuro que estuvimos este año. |
|
#222
|
|||
|
|||
|
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 |
|
#223
|
||||
|
||||
|
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. |
|
#224
|
|||
|
|||
|
Cita:
A partir de ahí, como si quieres ir por una carretera comarcal a 240 km./h. |
|
#225
|
|||
|
|||
|
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 |
|
#226
|
|||
|
|||
|
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. |
|
#227
|
|||
|
|||
|
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 |
|
#228
|
|||
|
|||
|
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.
|
|
#229
|
|||
|
|||
|
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... |
|
#230
|
||||
|
||||
|
No es un todo sigue igual. Todo seguía igual hasta el 1 de Enero, fecha configurada por defecto, o hasta que llegase la fecha elegida por el cliente anterior al 1 de Enero.
|
|
#231
|
|||
|
|||
|
Sí, esperar un año y volver a la misma situación que ahora. Si hay un año de plazo para hacerlo, hay tiempo, así que para qué vamos a apurarnos... Dentro de un año estaremos exactamente en este mismo punto.
|
|
#232
|
|||
|
|||
|
Cita:
|
|
#233
|
|||
|
|||
|
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 ![]() Última edición por Jarogo08 fecha: 04-12-2025 a las 16:07:12. |
|
#234
|
|||
|
|||
|
A lo mejor porque si un cliente no quiere enviar lo vas a perder y se lo va a llevar el listo de turno que se descojonará de ti como lo están haciendo los que han pasado de todo y ven a los que han cumplido como gilipollas.
|
|
#235
|
|||
|
|||
|
Esta era exactamente la explicación de los que hacían programas para generar B. Y hay una respuesta muy simple: yo no voy a arriesgar una multa de 150.000 para mí (el desarrollador), 50.000 para ti (el cliente) y una inspección para el resto de mis clientes (que si te pillan en algo con uno te van a mirar el resto de clientes, a ver que hay, y les va a encantar la idea), solo porque tú no quieras enviar (o hacer lo que sea que sea ilegal con mi participación consciente). Para mi estos clientes están mejor con la competencia.
|
|
#236
|
|||
|
|||
|
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 |
|
#237
|
|||
|
|||
|
No entiendo yo cómo pueden ser tan categóricos. El software no está hecho sólo para usuarios obligados por Veri*Factu; el software lo utilizan también usuarios no obligados (por ejemplo los de Navarra). Esos no tienen que tener activado ni Verifactu ni no Verifactu ¿O es que esta normativa no nos va a permitir producir para estos usuarios?
|
|
#238
|
|||
|
|||
|
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. |
|
#239
|
|||
|
|||
|
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.
|
|
#240
|
|||
|
|||
|
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. |
![]() |
|
|
Temas Similares
|
||||
| Tema | Autor | Foro | Respuestas | Último mensaje |
| Fecha de entrada en vigor de VeriFactu | espinete | General/Noticias | 162 | 11-04-2025 14:12:57 |
| Verifactu versus reglamento de facturación | ermendalenda | Temas legales | 2 | 21-11-2024 11:22:27 |
| Control ActiveX de facturación telemática de hacienda | david.bea | Providers | 14 | 13-04-2023 19:10:56 |
| Sistema de facturación | pablonill | Varios | 3 | 04-12-2007 18:34:56 |
| Facturación telemática de hacienda | adebonis | Servers | 2 | 01-06-2005 04:18:39 |
|