![]() |
![]() |
| Paypal | FTP | CCD | Buscar | Trucos | Trabajo | Foros |
|
|||||||
| Registrarse | FAQ | Miembros | Calendario | Guía de estilo | Temas de Hoy |
![]() |
|
|
Herramientas | Buscar en Tema | Desplegado |
|
#1
|
|||
|
|||
|
Algunas aclaraciones para tranquilizar...
Han sido meses duros para todos. De confusión, intentos de interpretaciones de una documentación mal explicada, cambios, adaptaciones del software por requerimientos sin mucho sentido, cosas enrevesadas para complicarnos innecesariamente la existencia tanto a nosotros como a los usuarios finales... pero me gustaría dejar algunas cosas claras. Puede que no estemos todos de acuerdo, pero yo lo suelto, y que cada uno lo tome como quiera:
1. Hacienda NO puede hacernos responsables a nosotros de que algo falle. Y mucho menos en los primeros meses de funcionamiento. Eso es como culpar a Microsoft de los fallos de Windows y hacerles pagar una sanción. Todo software requiere parches, actualizaciones, etc. Si ellos creen que no, es que no tienen ni p... idea. 2. Que ellos "exijan" algo no significa que deba funcionar al 100% siempre. Hay cientos de incidencias que pueden ocurrir en el día a día (y ocurrirán). Nosotros tenemos claro que el software lo vamos a tener que retocar de aquí a Enero sí o sí. 3. No pueden exigir que la versión de nuestro software que se descargue el 1 de Agosto sea la misma que el cliente vaya a usar el 1 de Enero. ¿Acaso no puede haber otros errores en el software que deba corregir por ejemplo en Noviembre? Si yo exijo a MIS clientes que el 1 de Enero tienen que actualizar a la última versión sí o sí, es cosa mía, y Hacienda no me puede decir lo contrario. Faltaría más. 4. Sería inadmisible que ellos puedan tener errores (servidor caído, certificado del servidor caducado (pasó con TicketBAI hace tiempo)) y que seamos nosotros los responsables de tener que manejar toda la casuística posible que ni siquiera depende de nosotros. Podemos prever algunas cosas, pero no todas. 5. En el peor de los casos, los clientes no podrán facturar durante un tiempo. De la misma manera que no podrán facturar si hay un apagón, y tampoco somos responsables de eso. El cliente tiene que entender que ahora pueden fallar muchas cosas. Si se quejan, que vayan a llorar a la puerta del Congreso con los leones. 6. Y sobre lo de cobrar de más a los clientes actuales, o subir el precio del soporte técnico, o permitir el envío solo si tienen contratado el servicio técnico, etc. es lo más normal del mundo teniendo en cuenta el curro que nos hemos pegado todos durante más de un año con esta m..... El cliente que no lo quiera entender, tiene vía libre para cambiarse de software de aquí a Enero/Julio de 2026. No está obligado a seguir usando el nuestro si no le gusta. Dicho esto, les deseo a todos una buena entrada a VeriFactu, pero ya os aviso de que, de aquí a Diciembre, todavía pueden cambiar muchas cosas ![]() Echémonos una copita de vino o una caña virtual todos! |
|
#2
|
|||
|
|||
|
Te veo optimista, dios te oiga.
|
|
#3
|
||||
|
||||
![]() ![]() ![]()
__________________
La otra guía de estilo | Búsquedas avanzadas | Etiquetas para código | Colabora mediante Paypal |
|
#4
|
|||
|
|||
|
Joder, alguien a conseguido que yo vea un poco de luz al final de tunel.
Gracias por los animos |
|
#5
|
|||
|
|||
|
Lástima que yo no sea tan optimista y lo vea de otra forma: Nos hacen firmar una declaracion de responsabilidad. Llevo meses pensando que han cerrado el circulo perfectamente. Nuevo sistema que se mete hasta la médula del desarrollo. Nueve meses, da igual que tengas decenas de instalaciones a medida y las tengas que adaptar todas. Si quieres trabajar tienes que firmar un acuerdo de adhesion que te responsabilizará EN PRINCIPIO DE TODO y solo despues puede que te dejen demostrar que fue el hard, el usuario o lo que sea.
Última edición por xamminf fecha: 24-07-2025 a las 21:56:10. |
|
#6
|
|||
|
|||
|
Nuestro software es compatible con la factura electrónica de varios países (México, Costa Rica...), Ticketbai, SII...
Ningún país, ni ningún sistema de facturación electrónica, es tan exhaustivo ni exige que seamos nosotros los únicos responsables. Ninguno. Solo Verifactu. No tiene ningún sentido. No pueden lavarse las manos dejando toda la responsabilidad en las nuestras. Esta gente se cree que todas las empresas de software tienen 200 programadores trabajando sin descanso. Yo solo digo que Hacienda, por mucho respetito que nos dé, no está actuando como han actuado otros países con sus sistemas de facturación electrónica. En cualquier caso, yo la copita de vino me la merezco seguro 😅 |
|
#7
|
|||
|
|||
|
Cita:
Ójala me equivoque y tengas tu razón... Efectivamente hay que premiarse con una copita de vino, o varias, porque aguantar esto es muy difícil... |
|
#8
|
|||
|
|||
|
Cita:
|
|
#9
|
|||
|
|||
|
Cita:
![]() Yo por si acaso estoy haciendo un curso de Vudú a distancia por el CCC, si bien no arregla el problema al menos te echas unas risas pinchando con agujas el muñequito del que se tercie... |
|
#10
|
|||
|
|||
|
Cita:
Hacienda no puede "exigir sin más" y ya está, porque ni ellos mismos saben las consecuencias que puede traer esto una vez entre en vigor (o antes). El 90% de nuestros clientes todavía no se enteran de casi nada. En un comercio con 20 PCs conectados, en los que el Servidor se encarga de hacer los envíos a VeriFactu, habrá 20 dependientes (o los que sean) que solo van a hacer facturas. Si hay incidencias, se mostrarán al usuario para avisarle de que debe "corregir" una factura que dio error. ¿La va a corregir él? No, deberá haber alguien encargado de revisar las posibles incicencias y hacer la rectificativa, subsanación o lo que toque. CUANDO ÉL PUEDA. ¿Va Hacienda a decirnos cuándo exactamente? ¿Y si el encargado de eso está de vacaciones? Lo dicho, hay muchas cosas que pueden pasar y pasarán. Por mucho que Hacienda exija algo, no quiere decir que se pueda hacer como ellos lo han imaginado. Nosotros ya tenemos preparada la versión que saldrá para el día 29, pero ya te confirmo que a lo largo de la semana, y en agosto, lanzaremos un par de mejoras/retoques más. Y a nadie le va a importar. Por ejemplo, no nos ha dado tiempo de permitir "subsanar", solo "rectificar". Una vez el software esté 100% preparado para subsanar, lanzaremos una actualización. Y nadie me lo puede impedir. |
|
#11
|
|||
|
|||
|
Empieza a hacer falta una asociación de desarrolladores informaticos para que defiendan los temas fiscales, al final estamos igual que los asesores fiscales pero sin cobertura, no nos podemos organizar para una demanda colectiva y se traduce en una total indefensión ante un abuso de "salvese quien pueda". Hay tal ambigüedad en la intetpretacion de la normativa que no cabe en otra ĺógica que no sea en la intención de recaudar con sansiones inasumibles. Esto ha creado un estrés en nuestra profesión, que además, si estuvieramos organizados y nos declararamos en huelga, sería otro cantar.
Está claro que los grandes beneficiados van a ser 2 grupos principalmente: recaudadores y grandes empresas desarrolladoras. Pero los que estamos en el foro, tanto desarrolladores de grandes empresas como los de "andar por casa", creo que ya tenemos, gracias a todos los que han colaborado en este foro con aportaciones de gran valor, mínimo, vamos a poder seguir una trayectoria similar(o mejor) a la anterior de la normativa. El esfuerzo inmenso que hemos dedicado debe al menos darnos tranquilidad. Un abrazo y no hace falta que os desee suerte por que está claro que teneis los suficientes datos para defender vuestro desarrollo a cualquier potencial inspección. Última edición por ermendalenda fecha: 26-07-2025 a las 16:56:26. |
|
#12
|
|||
|
|||
|
Cita:
|
|
#13
|
|||
|
|||
|
Cita:
Pero no, esta gente no. Directos a Producción desde el día 1. Incluso antes de tiempo voluntariamente. Y luego claro, como están ya en Producción, pues si pasa algo tendremos que estar 24/7 atentos para arreglar urgentemente cualquier estropicio que encuentren. Estoy seguro de que un juez, por muy tonto que sea, nos acabaría dando la razón. Eso sí, si conseguimos que nos entienda ![]() |
|
#14
|
|||
|
|||
|
Bueno, yo estoy con lo que dice este señor. De hecho, a día de hoy no tenemos ningún cliente que haya sido sancionado por enviar tarde al SII, y después de varios años enviando facturas de una forma incorrecta, es cuando les han mandado una carta de recomendación de cómo hacer determinadas casuísticas bien. Así que supongo que al menos el primer año de VeriFactu será como un periodo de adaptación y pruebas, incluso para la propia AEAT. Si ven que el sistema no sirve para nada y ha dado más quebraderos de cabeza que los que quería evitar, pues no se extrañen que lo acaben quitando o modificando ciertas reglas.
|
|
#15
|
|||
|
|||
|
Cómo contactará Hacienda con nosotros, si fuera necesario? Lo digo porque TicketBAI tiene constancia del software, que está "homologado" por ellos. Tienen un registro de los desarrolladores, y envían una vez al mes, o cada X días, un informe detallado de incidencias a los desarrolladores de cada software.
Hacienda no tiene NADA. Si hay alguna incidencia, tendremos que enterarnos nosotros, contactar con ellos si ocurriera algo muy raro, o contactarán con el cliente final y luego él con nosotros, etc. En fin, está claro que las cosas no las pensaron muy bien. |
|
#16
|
|||
|
|||
|
Cita:
En cuanto a lo de que hacienda no tiene nada... cada vez que les enviamos un registro identificamos nuestra empresa y cif en el apartado de sistema informático, y con eso ya lo tienen todo, porque todos estamos registrados como empresas aunque no lo estemos como desarrolladores. |
|
#17
|
|||
|
|||
|
Cita:
Así de primeras con solo mirar los xml que generamos ya les estás mandando tu nombre y tu nif No se tienen que volver muy locos |
|
#18
|
|||
|
|||
|
Que tengan tu NIF no significa que tengan el email del Dpto. de Desarrollo de la Empresa. No se van a poner a enviar emails al propietario de la empresa, no?
TicketBAI tiene el email que se les dio para la homologación, en el que recibir notificaciones si hiciera falta. Nosotros hemos recibido algunas notificaciones de TicketBAI. Sobre todo al principio, ya hace tiempo que no. Sobre todo de Gipuzkoa (Araba y Bizkaia no). No sé, que puedan contactar con el NIF de la empresa desarrolladora de alguna manera, no justifica que sea la mejor forma de hacerlo. |
|
#19
|
|||
|
|||
|
Lo más desastroso de todo, en mi opinión, es que los clientes no puedan enviar al entorno de Pruebas, al menos en el periodo voluntario. Me parece un error grave que no han querido analizar a fondo.
Y no solo eso. Imagina que tienes una versión DEMO de tu aplicación, porque a todo el mundo le gusta probarla antes de comprarla, y estar incluso un tiempo haciendo facturas ficticias de prueba... ¿Qué haces, permites el envío a Producción y luego inmediatamente haces una Anulación? ¿Qué tipo de locura es esa? ¿Por qué no permiten el envío a Pruebas? ¿Qué razonamiento lógico han dado? ¿Qué te lo prohíbe? |
|
#20
|
|||
|
|||
|
Cita:
|
![]() |
|
|
Temas Similares
|
||||
| Tema | Autor | Foro | Respuestas | Último mensaje |
| Como distribuir actualización para algunas tablas de una BD Firebird | Mauro® | Firebird e Interbase | 8 | 17-05-2016 18:56:49 |
| Algunas imagenes para reirse un poco... | movorack | Humor | 0 | 21-06-2010 17:52:36 |
| algunas dudar sobre funcion para obtener directorio | javier20 | OOP | 1 | 20-06-2007 22:41:14 |
| TMediaPlayer... Algunas Preguntas de Utilidad para Todos | Niko | Varios | 2 | 18-04-2005 21:02:42 |
|