![]() |
Cita:
|
Por otro lado (y con el convencimiento de que al final Verifactu no se pondrá en marcha) mi pregunta es: ¿Si yo hago un nuevo desarrollo tiene que estar adaptado al p... Verifactu?, es decir, ¿Tengo que adaptar a Verifactu para NADA?
|
Sé que el 90% de nosotros no quiere meterse en líos, pero vamos, yo tengo clarísimo que me apuntaría...
Se puede estudiar con un abogado de contencioso-administrativo una "reclamación coordinada de responsabilidad patrimonial" contra la Administración/Estado, basada en daños económicos concretos provocados por cambios regulatorios y, especialmente, en la posible quiebra del principio de confianza legítima. La Ley 40/2015 exige que el daño sea real, económicamente evaluable e individualizado, y que exista relación causal con la actuación pública. Este caso tiene elementos bastante interesantes porque no hablamos de expectativas abstractas. Se pueden documentar cosas como: - contratación adicional de programadores específicamente para VeriFactu; - horas de desarrollo y consultoría externa; - formación específica del departamento de soporte; - campañas de publicidad ya pagadas; - cambios de tarifas y estrategia comercial; - compra de licencias, certificados o servicios; - desarrollo de nuevos productos o addons; - documentación, vídeos, manuales y material comercial; - costes derivados de comunicar a miles de clientes unos cambios que finalmente no entran en vigor en la fecha anunciada. Además hay jurisprudencia. El propio Tribunal Constitucional ha explicado que la confianza legítima está relacionada precisamente con inversiones que no se habrían realizado, o se habrían realizado de otra manera, si se hubiese sabido que iba a cambiar el escenario normativo. Existen casos en los que el Tribunal Supremo ha reconocido indemnización por un cambio normativo sorpresivo y ha limitado la indemnización precisamente a los gastos efectivamente realizados debido a la regulación, descartando expectativas de beneficios futuros. Así que hay precedentes. Hacienda probablemente alegaría que "las empresas sabían que VeriFactu era una regulación en evolución, el aplazamiento no elimina la obligación sino que amplía el periodo de adaptación, y todo el software desarrollado seguirá siendo aprovechable cuando entre finalmente en vigor." Pero el contraargumento sería bastante potente: las empresas no eligieron libremente adelantar inversiones por estrategia comercial, sino que tuvieron que preparar sus productos para unas fechas obligatorias establecidas jurídicamente y reiteradas por la propia AEAT. Y si además resulta que se cambia el calendario por segunda vez después de meses de documentación, jornadas informativas, especificaciones técnicas, servicios de pruebas y comunicaciones oficiales manteniendo aquellas fechas, la discusión sobre confianza legítima se vuelve bastante más interesante. Y este sector tendría todavía mucho más sentido hacerlo varias empresas juntas. No solo para repartir gastos jurídicos: demostrar que tanto las empresas grandes de software como las pequeñas y otros desarrolladores hicieron inversiones equivalentes siguiendo exactamente el mismo calendario oficial ayudaría a demostrar que no fueron decisiones empresariales extravagantes, sino una reacción razonable del sector a una obligación legal concreta. Creo que hay suficiente fundamento jurídico y económico como para que una asociación de desarrolladores de software encargue un dictamen serio a un despacho especializado en responsabilidad patrimonial del Estado. |
Ya me extrañaba a mi que con el bombo que se le dió el año pasado, este año parecia como si no existiera verifactu...
Al final siempre retrasos |
Cita:
|
Totalmente de acuerdo y no somos pocos.
Cita:
|
Para que amplíen los plazos tiene que haber alguna ley que apruebe ese cambio y como se han disuelto las cortes no se como lo van a hacer.
La diputación permanente no debería poder legislar esta ampliación por que no se trata de algo de carácter urgente. No nos extrañe que esto solo se trate de una maniobra política y se quede en nada y el día 1 del 2027 todos Verifactu |
Cita:
Nosotros nunca hemos dicho "Eh, qué c_ño pasa?" |
No estaría mal abrir un hilo para que todos los que queramos hacerlo lo podamos ir comentando, etc... a ver si entre todos... y además lo veo muy factible.
Cita:
|
Yo ya lo dije en su día, que en lugar de estar tocándonos los wev... a todos los desarrolladores, haber aprovechado el SII y meter a todo dios por ese sistema. Hubiese sido todo más fácil para todos, y usaría una plataforma altamente contrastada y que lleva en funcionamiento varios años y que daba un margen de 4 días naturales para los envíos.
Lo que hay que ver también es si el aplazamiento/adiós definitivo del VeriFactu se refiere solamente a "VeriFactu" y no al resto de la Ley Antifraude, y qué se hace con los que ya estaban enviando registros o la fecha para la obligatoriedad sobre los sistemas informáticos, etc. Esperemos a la publicación en BOE. Y todavía nos queda lo de la normativa de la Ley Crea y Crece y la plataforma SPFE, que en vista de elecciones generales a la vuelta de la esquina, muy probablemente también exista aplazamiento, y por ende, afectaría también a esa fecha de aplazamiento de Verifactu. |
Cita:
Es una mera "nota informativa" de Hacienda ... Cita:
|
Cita:
Huelga General !!!! |
Cita:
|
Cita:
Lo que tenemos que vigilar no es solamente si aparece un "Real Decreto-ley", sino específicamente si aparece en el BOE un Real Decreto que modifique la disposición final cuarta del Real Decreto 1007/2023 antes de las elecciones. Y hasta que eso ocurra, las fechas que jurídicamente constan hoy siguen siendo 1/1/2027 y 1/7/2027. Es decir, no bastaría con que Hacienda dijera "lo aplazamos hasta 2028" en una nota de prensa o comunicación. Para modificar una fecha establecida por una norma con rango suficiente, tiene que aprobarse la correspondiente modificación normativa. Que no digo que no lo harán, pero que por ahora no lo han hecho. |
No creo que todo el trabajo hecho con verifactu sea algo perdido, sino que cuando se tengan todas las especificaciones del "verifactu" final acordado por la unión europea para todos los paises miembros entonces sólo será necesario adaptar los cambios necesarios. Por lo que más bien es un adelanto que facilitará luego el trabajo. O eso creo.
|
con este nuevo aplazamiento, empieza a preocuparme la situacion siguiente:
que las empresas no quieran actualizar o cambiar su programa por la obligacion de enviar los registros. lei en el foro que alguien habia obtenido la respuesta de la AEAT diciendo que si se podia comercializar software adaptado, pero que no envia por el aplazamiento (el anterior). ahora no se donde esta ese hilo. ¿ hay alguna nota forma o informal sobre este asunto ? Saludos ! |
Me han contestado lo siguiente desde hacienda
Cita:
|
Verifactu / SII / TicketBAI / ViDA
Cuando me he enterado hoy del aplazamiento no me lo podía creer. Tierra trágame.
Como algún compañero ha comentado, es verdad que perdemos credibilidad con los clientes aunque no sea responsabilidad nuestra. Ya no se creerán nada, qué cachondeo... vaya cabreo llevo! Me ha cogido desprevenido, porque al implantar TicketBAI en el país vasco era lógico que el resto de España tuviera algo similar (excepto Navarra claro, que ya veremos qué pasa con el naTicket). Si no lo habéis hecho ya, os aconsejo que le echéis un vistazo a la hoja de ruta Verifactu y ViDA de AEDAF (Asociación de asesores fiscales) https://www.aedaf.es/es/documentos/d...da-y-verifactu España tiene que estudiar cómo converger a ViDA en el 2030, y aún no saben cómo hacerlo. :mad: Pueden basarse en el SII o en Verifactu, ambas opciones tienen sus pros y contras. El objetivo es enviar un sólo fichero estructurado al SPFE (Sistema público de facturación), con enviar el XML UBL ya tienen todo, no tienen que pedirnos que además cumplamos con Verifactu / TicketBAI (ya ni entro en la facturación FacturaE B2G). Bueno este es un pequeño resumen del documento. En fin, muy mal... muy enfadado estoy :mad: |
Lo mas sensato sería tener una alineación de especificaciones verifactu y factura electrónica, como una única cosa... llamémosle VIDILLA.
En la nota informativa que han colgado dicen literalmente: Una vez aprobada dicha alineación de los calendarios de implantación, se abordará una modificación centrada en conseguir la convergencia de los ámbitos de aplicación y ciertos aspectos técnicos de la normativa vigente teniendo en cuenta los futuros requisitos de reporte digital derivados de ViDA. A ver si alinean pronto los calendarios y abordan con diligencia "los ciertos aspectos técnicos" para tener en cuenta, no sólo los futuros requisitos de reporte derivado de ViDA, si no de convergencia de especificaciones de todo lo que un SIF debe cumplir para estar adaptado a la administración de las comunidades autónomas, la administración central del estado y la administración comunitaria. Yo antes que ir a los juzgados, que no me faltan ganas, lo que haría sería organizar el sector informático y que esté en esas mesas técnicas donde se tome en cuenta nuestras exigencias. Hasta ahora se han sentado con los grandes y estos, lo que han hecho en sus programas ha sido mediocre, a mi juicio, pero lo que sí han hecho es caja y volverán a hacerla. Los "pequeños" programadores no pintamos nada, no estamos organizados. Como esto de organizarse es complicado, yo lo intenté en Málaga en los años 90 impulsando una Asoción de Profesionales de las Nuevas Tecnologías APRONET, todos estamos muy ocupados, lo nuestro es trabajar a fuerza bruta.. seguimos siendo los que programamos mejor bajo presión. Si de verdad queremos que nos tomen en cuenta, hay que organizarse. Cabrearse no sirve de nada, bueno... sólo para sacudirse el cabreo.. que no es poco. Saludos colegas. Mucha Vída!! |
Cita:
No te se decir de dónde lo han sacado, ni con quien ha hablado, porque de eso se ha encargado el "departamento legal", pero la solución está aceptada por la AEAT y en la calle. |
Esta mañana, sobre esta situación, me han enviado referencia a la Consulta Vinculante de la DGT (Dirección General de Tributos) nº V0073-26 del 20-01-2026, realizada por una empresa de desarrollo de software, que tienen una aplicación adaptada al reglamento en la modalidad de "SOLO VERIFACTU", preguntando si pueden configurarla para que realice todos los procesos, pero detenga el envío de Registros de Facturación a la AEAT.
Básicamente le responden que, sólo es posible si el SIF tuviera también la modalidad de NO VERIFACTU, pues para realizar dicha detención, en los envíos que se estén realizando hay un apartado específico para avisar en qué fecha se va a pasar a la modalidad NO VERIFACTU, y no puede ser antes del 31-12 del año en curso. Por tanto, si el SIF es SOLO VERIFACTU, como también es mi caso, una vez que has empezado a enviar, no está permitido parar. |
Cita:
El caso que comentaba y que neftali ha contestado, es un software que NUNCA ha realizado envios en la empresa, solo ha sido actualizado o vendido nuevo, y que como digo esta preparado pero SIN enviar. Creo que queda aclarada mi duda. gracias ! |
Cita:
Es lo primero que aclara la V0073-2: un sistema solo es Verifactu si remite efectivamente los registros a la AEAT. Si no remite, no es Verifactu. Por eso no existe "Verifactu sin remisión". La única modalidad sin remisiones es la no-verifactu, cumpliendo evidentemente todos los requisitos que piden para esa modalidad, de control de eventos, etc. Si actualizas el software o lo instalas nuevo después de julio del 25, o estas en una o estás en otra, pero no existen métodos "híbridos" tipo mi versión es verifactu pero se activará el envío a futuro. Hasta aquí es lo que se conoce a nivel general por la ley, las faqs generales y de desarrolladores y las consultas vinculantes, que en todos sitios dice lo mismo, y por mucho que intentemos retorcerlo para que los clientes no tengan que entrar a capón enviando desde el inicio, todo lo que se ha dicho hasta ahora es problemático para empresa y cliente (excepto lo de que el cliente se ponga voluntariamente como exento y así el marrón se lo come solo el). Lo que no sabemos evidentemente es lo que le habrán dicho al departamento legal de Neftali porque es conocimiento privado, y por tanto no sirve de soporte ante hacienda si hay un problema: no puedes decir: "es que al departamento legal de Neftali le dijeron que sí se puede...". Y yo si fuese Neftali tampoco preguntaría mucho, porque mi impresión es que alguien ha tomado en su empresa una decisión "que puede ser controvertida" por decirlo de algún modo, para no perder clientes, y si preguntas mucho a lo mejor encima al final el marrón te lo comes tu. |
Cabezas de chorlito :)
Cuatro aplazamientos en tres años, una nota de un folio que ignora a los que cumplieron primero, y la promesa de retocar lo técnico después de que medio país ya lo tenga en producción. El único que sale bien parado es el que esperó sin hacer nada. Viva España coño! :)
|
Cita:
Pd: siempre nos quedará el maravilloso folleto propagandístico que hicieron, que ha conmovido a generaciones enteras y en el que nos indicaban que con esto nos ahorraban trabajo...:D |
Cita:
|
Cita:
|
Cita:
El cliente, al ponerse la nueva versión desde julio del 25, selecciona si se acoge Verifactu (no tenemos SII, ni TicketBAI, ni otros) o se declara exento ... ¡Pero lo escoge él! :D Y por lo tanto la responsabilidad es suya ... Si escoge "exento", puede activarse Verifactu cuando él lo crea conveniente (1/1/27 ó 1/7/27 ó 6/8/28 o cuando leches sea) ... Y una vez activado Verifactu, luego ya no lo puede desactivar :) ... Nota: Hay clientes que lo que hacen para "quitarse" de enviar a Verifactu, es eliminar su certificado electrónico de nuestro software o, simplemente, lo dejan caducar y no lo renuevan ... Pero en ese caso, otra vez es responsabilidad suya :cool: así que nosotros plin :D:D:D ... |
Cita:
|
Cita:
Para los que ya han enviado, algunos clientes (lo ha comentado otro compañero) están "desactivando" SIF marcando otras opciones, como TicketBAI o el SII en la configuración. De esta forma la decisión final es del usuario. A efectos prácticos es la misma que la otra, se deja de enviar información. Cita:
Cita:
No es serio, están bastante en contacto con la AEAT y el "departamento legal" es bastante potente, por otros temas empresariales; Así que si han decidido esto, es porque es consensuado y seguro 100%. Siento no poderos dar más detalles ni referencia que puedan servir a alguien más (no tengo acceso a esa información). No puedo poner pantalla del programa por temas "legales", pero os puedo decir más o menos el funcionamiento (cambio literales, pero espero que se entiendan las opciones). Al acceder a la configuración, las opciones de dividen en 2 grupos: ------------------------------------------------------------------------------------ * Los que están obligados a RRSIF [ ] Envío VERI*FACTU [ ] Trabajar con RF en modo NO-VERI*FACTU [ ] RRSIF aplazado hasta fecha obligatoria de activacíon * Empresa no obligada a RRSIF [ ] Trabajando con el SII [ ] Empreasa en territorio extranjero [ ] Empresa tributando con TicketBAI [ ] Personas físicas/ atribución de rentas no desarrollan act. econ. o contribuyentes IRNR sin EP. [ ] No aplicación por Art. 5 RD 1007/2023 ------------------------------------------------------------------------------------ Al final la empresa según su situación (y bajo su responsabilidad) DEBE escoger una de todas ellas. |
Cita:
|
Cita:
|
Cita:
|
Por aclarar un poco.
Si estamos en periodo de pruebas, se entiende este periodo aquel en que no estás obligado a enviar todavía a Verifactu, puedes usar un programa adaptado para enviar a hacienda y pararlo cuando quieras o usarlo de forma intermitente en beneficio del programa no adaptado del que dispones. Esto está bien claro en las Faqs de la Aeat en la página 8 file:///C:/Users/TPV/Downloads/Preguntas_frecuentes__FAQ_.pdf que cito ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- Pregunta : Una sociedad que opte por utilizar el sistema informático VERI*FACTU dentro del periodo de pruebas ¿es obligatoria la permanencia en dicho sistema hasta que finalice el año natural? Respuesta No. La Disposición final cuarta del RRSIF (Reglamento que establece los requisitos de los sistemas informáticos de facturación), modificada por el Real Decreto-ley 15/2025, de 2 de diciembre, establece que entrará en vigor de forma obligatoria el 1 de enero de 2027 para contribuyentes del Impuesto sobre Sociedades y el 1 de julio de 2027 para el resto de obligados tributarios mencionados en el artículo 3.1 del RRSIF, entre ellos, los contribuyentes del Impuesto sobre la Renta de las Personas Físicas que desarrollen actividades económicas. El periodo anterior a la entrada en vigor del RRSIF es un periodo de pruebas. Se podrá dejar de expedir facturas y remitir registros en prueba con un SIF modalidad VERI*FACTU y utilizar para facturar otros SIF (sistema informático de facturación), que podrían ser adaptados y funcionar en modo NO VERI*FACTU (si así lo permiten) o incluso sistemas antiguos no adaptados, mientras no tengan obligación: hasta el 31/12/2026 o 30/06/2027, según aplique. Una vez se tenga obligación de adaptación al RRSIF, es decir, a partir del 1/1/2027 o 1/7/2027, según aplique, si los obligados optan por comenzar a expedir facturas y remitir registros de facturación (RF) con un SIF VERI*FACTU, debe permanecer, al menos, hasta la finalización del año natural en el que se haya producido, de forma efectiva, el primer envío de los registros de facturación. ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- Por lo tanto, si algún cliente ha estado enviando a Verifactu con un programa Adaptado, puede dejar de hacerlo sin ningún problema y usar el sistema anterior No Adaptado sin consecuencias legales. No es que se pueda desactivar el envío a Verifactu de un sistema adaptado, es que dejas de usarlo y por ende ya no envía. Actualmente, no existe legalidad que ampare la desactivación del envío a Verifactu de un programa Sólo Verifactu, sólo hay que leerse la ley y la orden que la estructura y la aclaración que se hace desde la Aeat En relación con su consulta sobre la comercialización de un software de facturación en modalidad exclusiva VERI*FACTU y la gestión del periodo transitorio de los usuarios finales, les trasladamos las siguientes aclaraciones: 1. Distinción entre las obligaciones del Productor/Comercializador y del Usuario Final · Obligación del Productor/Comercializador: A partir de la fecha límite establecida en la normativa (29 de julio de 2025), los fabricantes y comercializadores están obligados a ofrecer al mercado sistemas informáticos de facturación (SIF) debidamente adaptados al Reglamento (RD 1007/2023 y Orden HAC/1177/2024) y acompañados de su correspondiente Declaración Responsable. · Obligación del Usuario Final (Empresario o Profesional): Conforme a la nota informativa del Ministerio de Hacienda, se prevé la modificación de las fechas de obligatoriedad de uso para alinear la implantación de VERI*FACTU con la Factura Electrónica B2B, fijando el nuevo horizonte de exigibilidad para la totalidad de obligados pendientes en octubre de 2028 (pendiente de publicación formal en el BOE). · Elección del Usuario: Durante el periodo previo a su fecha de obligatoriedad, el usuario final es libre de decidir si anticipa su adaptación e inicia voluntariamente la remisión en VERI*FACTU, o si continúa utilizando un sistema no adaptado bajo su propia responsabilidad. 2. Imposibilidad de "desactivar" las funciones en un SIF Adaptado Inviolabilidad por diseño: Un producto de facturación que haya sido certificado como SIF adaptado (sea "Solo VERI*FACTU" o "Dual") no puede incorporar mecanismos, interruptores o parches que permitan "desactivar" la generación de registros ni emitir facturas "ordinarias" al margen del control de trazabilidad e inalterabilidad. Manejo de clientes que no desean usar VERI*FACTU aún: 1. Si un cliente adquiere e instala un programa diseñado exclusivamente como "Solo VERI*FACTU", la propia naturaleza del software exige que toda factura expedida genere su correspondiente registro de alta y sea remitida a la AEAT. No es posible usar dicho programa sin generar registros. 2. Si el cliente desea agotar su periodo transitorio sin enviar datos a la AEAT ni someterse al RRSIF, no debe instalar/activar el SIF adaptado, sino continuar utilizando una versión tradicional (no adaptada) o no instalar el módulo de adaptación. 3. Recomendaciones de Buenas Prácticas para el Comercializador/Implementador Los fabricantes y comercializadores pueden ofertar y proporcionar sus productos como mejor consideren y bajo su propio criterio, bien sea por separado o conjuntamente (paquete) para su distribución y posterior uso por sus clientes (nuevos o antiguos, con o sin contrato de mantenimiento en vigor…). Si distribuye conjuntamente, por ejemplo, dos productos SIF, uno adaptado al RRSIF y otro -distinto- no adaptado, el cliente instalará y usará el que le corresponda de acuerdo con sus circunstancias. El cliente, es decir, el OEF usuario del producto SIF o receptor de la distribución (paquete) de productos SIF puestos a disposición en cualquier momento, deberá instalar y utilizar el/los SIF que le corresponda de acuerdo a la normativa que le resulte aplicable. Si bien no existe obligación específica al respecto, dado que el tercer párrafo de la disposición final cuarta del RRSIF obliga -a partir del 29/7/2025- a los fabricantes de SIF a que se refiere el artículo 1 del RRSIF a ofrecerlos adaptados al RRSIF (se entiende que a aquellos usuarios -nuevos clientes suyos- a quienes les sea de aplicación dicho Real Decreto), es recomendable que el fabricante informe de forma activa a sus clientes (tanto en el momento previo a la compra, como en el momento de esta y después, al instalarlo y configurarlo previamente a su uso, así como en algún apartado claramente visible del mismo tras su instalación) sobre a quién va destinado cada tipo de SIF que ofrezca (y, en particular, el que se pueda estar eligiendo por parte del usuario) y qué normativa le aplica, así como sus características. Asimismo, se recomienda registrar de forma segura la opción elegida (sobre qué producto instalar y usar) expresamente por el usuario una vez ha sido informado de las repercusiones legales de la misma. No obstante, la responsabilidad última por utilizar un SIF no adaptado al RRSIF cuando debería utilizarse uno adaptado a dicho RRSIF es del usuario obligado a expedir facturas (OEF) que lo utilice indebidamente. Atentamente, Atención al Usuario Departamento de Informática Tributaria Soporte técnico por correo electrónico: [email protected] Asistencia Telefónica / Chat: Puede solicitar cita previa para cuestiones informáticas en la Sede Electrónica de la Agencia Tributaria (sede.agenciatributaria.gob.es), dentro del apartado: Inicio - Todas las gestiones - Otros servicios - Asistencia y Cita |
Muchas gracias SgLorka,
Entiendo que esta consulta / respuesta es reciente. Así mismo lo había interpretado yo, y lo estaba comunicando y aplicando a mis clientes. |
Por cierto, con respecto a esto ...
Cita:
Ni publicación en el BOE, ni nada equiparable, quiero decir :rolleyes: ... |
Cita:
|
Sí, la pregunta / respuesta es reciente, es de hace menos de 1 semana.
Yo entiendo que la opción que propone Nefatí (RRSIF aplazado hasta fecha obligatoria de activacíon) sólo tiene cabida si el cliente ya tenía una versión anterior y se la han actualizado a Verifactu. En este caso, si el cliente ha estado enviando y ahora decide parar, la actualización puede "revertirse" y pasar a otro estado (RRSIF aplazado hasta fecha obligatoria de activacíon) donde no puede aparecer por ningúin lado la Declaración Responsable ni la palabra "Verifactu" en ningun aparte del programa ya que es un software No Adaptado al RRSIF. De esta forma, puede seguir trabajando y dejar de generar registros, Qr y envíos. Sin embargo, si el cliente es nuevo y el software adaptado se vendió después de 29/07/2025 no puede dejar de generar registros, Qr ni envíos. Revertir este programa a un estado "RRSIF aplazado hasta fecha obligatoria de activacíon" implicaría reconocer que se le ha vendido al cliente un software NO Adaptado despúes de la fecha límite. ¿ La Aeat va a controlar esto ?. No creo, pero como sé que ha pasado que se han hecho inspecciones tributarias por otros motivos a clientes míos, han mirado los programas de arriba a abajo, no estaban adaptados porque el cliente no lo quería hacer todavía, pero sí cumplian con con los puntos generales más importantes, eso sí, le pidieron la factura de compra del programa. |
Cita:
Seguimos con 1/1/27 :cool: ... Seguiremos esperando ... |
buenas a todos,
tengo otra avalancha de clientes que no quieren Verifactu, cómo lo estáis haciendo ? La idea de dejar el SIF con todos los controles salvo generar RF, envío y QR no es una idea válida ? Dejando la fecha de autoactivación a octubre de 2028 Vaya estrés otra vez, |
| La franja horaria es GMT +2. Ahora son las 09:08: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