![]() |
![]() |
| 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
|
|||
|
|||
|
Cita:
|
|
#12
|
|||
|
|||
|
A los desarrolladores de TicketBai también les han expuesto a ese tipo de sanciones tan brutales???... porque vamos no es ni medio normal, que encima que les desarrollamos funcionalidades para hacerles el trabajo de inspección que ELLOS TENDRÍAN QUE HACER, además de eso te puedas encontrar con que alguna circunstancia asociada a eso te pueda arruinar la vida.
|
|
#13
|
|||
|
|||
|
Cita:
Te digo más: hemos tenido problemas muy raros y difíciles de resolver con TicketBAI (clientes que han hecho un estropicio difícil de replicar, prever, etc.) y TicketBAI lo que nos dice es "nada, tranqui, vuelvan a crear una factura y reenvía sin problema", restándole importancia. |
|
#14
|
|||
|
|||
|
Cita:
|
|
#15
|
|||
|
|||
|
Hoy les he enviado este email a los de VeriFactu, con algunas dudas, opiniones y "quejas" que llevábamos tiempo recopilando. Es un poco largo, pero creo que resume lo que hemos estado debatiendo por aquí últimamente.
A ver qué responden (si responden algo): Código:
Buenos días... Nos han surgido varias dudas que consideramos bastante importantes, además de otros muchos casos no previstos inicialmente pero que indudablemente surgirán en cuanto las empresas empiecen a generar/enviar VeriFactu de forma masiva... Os las planteamos con el fin de entender qué tenéis previsto que se deba hacer en cada caso, ya que consideramos que la documentación tiene partes que están sujetas a interpretación subjetiva. 1. Usuarios probando versión demo del software En un software de escritorio, los usuarios de software suelen descargar y probar el software durante un tiempo antes de comprarlo. Quieren crear un par de artículos, ver cómo se hace una factura, si les gusta cómo se hace, etc. Teniendo en cuenta que no permitís el envío de VeriFactu al entorno de Pruebas (lo cual nos parece un despropósito sin sentido y que no debería afectar a nada ni nadie), entendemos que pretendéis que el usuario dé de alta su certificado en el software (y en todos los softwares que esté probando), rellene los datos reales de su empresa, dé de alta un cliente real con NIF real y haga las facturas, se envíen a VeriFactu al entorno de Producción y luego se anulen automáticamente (o tenga que anularlas él). Nos gustaría saber si creéis que esto es lo que se debe hacer realmente, porque sinceramente, tras la experiencia que nos han dado 25 años desarrollando software de facturación, dudo mucho que los usuarios estén preparados para esto. El entorno de Pruebas debería estar disponible para que se pueda usar, obviamente que sea independiente y separado del Real, para poder probar que todo funciona correctamente antes de empezar. Lo que sí se debería impedir es alternar entre Pruebas y Producción, pero que se pueda probar el software, o hacer envíos de pruebas en caso de detectar una incidencia, etc. lo vemos completamente imprescindible. 2. Usuarios registrados que nos envíen copias de seguridad para resolver alguna incidencia En el software de escritorio los datos se almacenan de forma local, y se hacen copias de seguridad/respaldo cada X tiempo. Algunas incidencias difíciles de resolver en remoto requieren que el usuario nos envíe una copia de seguridad de sus datos, que recuperamos en nuestros equipos. ¿Qué pasará si debemos hacer una factura de prueba? Pues que en sus datos y config. estará activado VeriFactu en modo Producción. Tener esto en cuenta antes de hacer nada y liarla es bastante complejo, sobre todo teniendo en cuenta que tenemos clientes que NO están en VeriFactu, sino en TicketBAI o en otros países. 3. Usuarios con pérdida de datos, virus, PC roto, BD dañada, etc. Esto es algo más habitual de lo que se cree, por desgracia. A muchos usuarios se les rompe el PC, o se les infecta/encripta por un virus, o lo que sea. Imaginemos que una empresa lleva enviando VeriFactu varios meses, y de repente hoy ocurre algo y pierden los datos. Deberán, con suerte, recuperar una copia de seguridad de ayer (o incluso anterior si las han perdido también). Cuando lo hagan, habrá facturas que NO existan en el SIF, pero sí le constan a Hacienda porque ya fueron enviadas antes del desastre. Conclusión: se pierde en encadenamiento, porque la última factura que se envió no existe en el SIF. ¿Cual es aquí el procedimiento a seguir? Iniciar una nueva enumeración? Consultar con la AEAT cual fue la última factura enviada y obtener su huella para el encadenamiento? Rehacer las facturas que faltan una a una y enviarlas como "subsanación"? 4. Diseños de factura personalizados Nuestro software permite a los usuarios elegir entre varios diseños de factura, personalizarlos a medida o incluso crearlos desde cero. Para ello usamos un conocido diseñador de informes. que se incluye con el software. Ahora con VeriFactu tendrán que incluir en sus diseños de factura el QR de VeriFactu. Hemos intentado automatizarlo pero es imposible. En el 99% de los diseños no hay espacio libre para meter ese QR, y mucho menos al principio de la página, como "exige" Hacienda. Conclusión: no hay forma. Los clientes tendrán que añadir/personalizar su plantilla de factura para añadir el QR. Tratándose de miles de clientes, es inviable que nosotros podamos hacer eso, por no mencionar el coste que ello supone (horas de trabajo, precio...). Los clientes quieren usar su propia plantilla de factura, que han estado usando durante años, con sus colores, su diseño, etc. A los clientes nuevos se les puede predefinir el diseño especial/oficial para VeriFactu, pero los antiguos tendrán que adaptar el suyo sí o sí. Además, el SIF permite al usuario cambiar el modelo de factura cuando quieran, y el QR solo se incluye en uno. Y no, no es posible impedir eso (no puedes permitir modificar un diseño pero no elegir otro, no tendría sentido. Además, el diseñador de informes no lo desarrollamos nosotros). En fin, que como se puede apreciar, hay muchísimas consecuencias que creemos que no se han tenido en cuenta, dejando el 100% de responsabilidad sobre nosotros, lo cual es injusto, por no decir abusivo. Y hay muchas otras dudas que nos han surgido en las últimas semanas que también tendrán sus consecuencias: 5. Usuarios que no saben si son persona física o jurídica: Esto puede resultar inverosímil, pero ocurre, y mucho. Sobre todo con cooperativas, etc. 6. Permitir el envío al Entorno de Pruebas solo a nosotros como desarrolladores: habría que pensar cómo permitir que solo nosotros podamos hacerlo, pero sin embargo, en el mismo software, enviar a Producción cuando lo que se envíe sea nuestra facturación real. 7. "Autofacturación" en empresas agricultura: hay empresas que realizan auto-facturación (se facturan a sí mismas en nombre de un proveedor tercero). No es nuestro caso, pero hemos hablado con otras empresas de software que nos han trasladado también esta duda. Para esa funcionalidad tampoco parece haber respuesta, según nos han dicho. En definitiva, como opinión personal después de año y medio centrados exclusivamente en VeriFactu, sin recibir a cambio poco más que avisos de posibles sanciones y 100% de la responsabilidad, creemos sinceramente que hay cosas que se han planteado mal, o de forma incompleta. Entendemos que vuestra intención es que nos lo tomemos en serio, pero el estrés y ansiedad que nos ha generado todo esto es difícilmente compensable. Nuestro software lleva años con TicketBAI y la factura electrónica de México, Costa Rica, etc. sin tener que pasar por todo esto en ningún momento. Creo personalmente que las cosas se podrían haber hecho mejor, y espero que aún estemos a tiempo de ser algo más permisivos con algunos casos concretos. |
![]() |
|
|
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 |
|