Desde el año 2.012 han transcurrido tres años de intenso trabajo técnico y judicial en el asunto de la condena a Gas Natural Andalucía S.A. para la devolución de cobros indebidos a casi 100.000 usuarios de Andalucía.

Sin entrar excesivamente en detalles farragosos, diremos únicamente que GN (Gas Natural) se escudaba siempre en el argumento de que las cifras calculadas por nosotros no coincidían al 100% con las cifras que tenían ellos. Naturalmente, nosotros extrapolamos las cantidades partiendo de datos incompletos. El lector se preguntará que si GN conocía las cantidades exactas a devolver ¿por qué no las indicaba al juzgado?. Se trata de una cuestión judicial: El demandante es el que ha de determinar la cifra, no el demandado.

Tras mucho proceso judicial, los magistrados de la Audiencia Provincial de Córdoba dictaminaron en un auto de diciembre de 2.014 que "hasta aquí llegó el carbón" y que el informe presentado por nosotros (descrito en el artículo anterior) fuese considerado probatorio. Por tanto,  las cantidades establecidas por nosotros son las que tendría que devolver GN en un plazo de cuatro meses. O sea que, definitivamente, y a costa de ganar algunas batallas menores, han perdido la guerra.......

Quedan 31.000 usuarios que ya no son clientes de GN a los que tenemos que devolverles nosotros unos 3,5 millones de euros. 

En fin, que el Tribunal de Córdoba nos encarga pagar 3,5 millones de euros a unos 31.000 usuarios de los que, naturalmente, no tenemos los datos bancarios ni otra información que el nombre (el NIF está incorrecto en muchos de los registros) la cantidad a devolver y la dirección postal; ahí es nada.

Lo que si que estaba claro es que la tarea tenemos que abordarla con recursos no diré que escasos, sino escasísimos, y con una información muy limitada. Nos hubiera encantado realizar campañas en radio, prensa y televisión para informar a los ciudadanos de que pueden reclamar el pago de las cantidades que les corresponden, también nos hubiera encantado disponer de una oficina administrativa y técnica para abordar las tareas, y muchas mas cosas pero nuestros fondos son limitados y no disponemos de provisión de fondos, así que se definieron las siguientes lineas maestras:

Se desarrollará un aplicación web compuesta de dos partes: Una visible por los usuarios, desde donde podrán reclamar su pago y otra parte invisible desde el exterior (de hecho, funcionan en máquinas distintas) que es la administración de toda la parafernalia.

Consideramos la posibilidad de utilizar certificados electrónicos como mecanismo de autenticación de los usuarios, pero tras meditar un poco, llegamos a la conclusión de que esto iba a ser un engorro: La tecnología empleada en estos procesos es de la Edad de Piedra: Se necesita una determinada versión de Java en el cliente, no funciona con todos los navegadores y además depende de la versión del navegador, tienes que tener un lector de DNI o en su defecto, el certificado digital instalado en el ordenador. Cuando estas cosas funcionen de manera independiente del navegador web y de la puñetera versión de Java, estas cosas tendrán su utilidad, de momento son sólo una traba (sí, ya se que la Administración se considera muy moderna y le encantan estas tonterías). Opción descartada

Lo siguiente sería considerar que los usuarios pudiesen enviar una copia escaseada de su NIF y de un certificado bancario donde apareciese el IBAN de la cuenta a la que realizar la transferencia. Una vez dispusiésemos de los documentos, se podría intentar una validación automática de los documentos mediante software OCR. También muy bonito pero resulta que el personal envía los documentos como les da la gana: Algunos envían el NIF al tamaño de una página A4, otros a tamaño natural (esto no sería problema, se escala la imagen y ya está), otros lo envían cabeza abajo (mas complicado de detectar), otros girado 90º, otros inclinado en ángulo aleatorio en tres dimensiones.....en fin, para qué seguir. Opción descartada, es imposible verificar la documentación de manera automática, sólo podremos hacerlo mediante reconocimiento visual.

También se ha considerado la posibilidad (aunque complica el software) de recibir el pago al contado (en efectivo o mediante talón bancario), no sólo mediante transferencia.

Por último, se decide enlazar la aplicación web con el site de la organización de consumidores y usuarios ¡ea!, www.eajaen.org que es bastante conocido y nutrir la aplicación de los beneficiarios que entren por dicho site.

Una vez decididas las líneas generales, se pasa a la fase de análisis y diseño; nada sencillo porque hay que informar a los usuarios (sólo se requiere el NIF como dato de entrada) de su situación, esto es, si son beneficiarios del auto descrito anteriormente o si ya han sido pagados por GN en autos anteriores o de forma amistosa. En caso de resultar positiva la identificación, hay que indicar la cantidad que se va a reembolsar y el usuario puede elegir el modo de pago deseado. Seguidamente se le solicitan los archivos escaseados permanentes y a partir de ese momento, queda todo registrado en la base de datos.

La parte de administración es mucho mas compleja, dado que es necesario gestionar el almacenamiento de información, la validez de los datos recibidos, el control de los medios de pago, etc., etc.

Al tratarse de una aplicación web, se diseñó en Java y con Tomcat como contenedor de servlet.  Naturalmente, se utilizaron Frameworks industriales en el desarrollo: Struts 2, Spring e Hybernate. Se instaló el entorno de desarrollo sobre un MacBook Pro con procesador i7 y 16 GB de memoria RAM, utilizando Eclipse como IDE de desarrollo.

El entorno de producción está basado en dos servidores convencionales con sistema operativo Linux, en hosting (no íbamos a poner nosotros los servidores en casa y acceder a ellos mediante ADSL).  El primero de ellos es el front end encargado sólo de la parte de la aplicación visible por el usuario, mientras que en el segundo, más potente, reside la base de datos y la parte de administración de la aplicación.

Por supuesto, la segunda máquina no está conectada a Internet y se encuentra enlazada a la primera mediante una VPN. Igualmente, el acceso a dicha máquina no es directo, sino también a través de VPN por cuestiones de seguridad.

La seguridad fue un asunto que nos obsesionó durante un tiempo porque pudimos observar que al día siguiente de poner a máquina front end en funcionamiento (aun sin la aplicación cargada, sólo el software básico) se producían ataques sobre el servicio SSH procedentes en su mayor parte de China.......increible, se conoce que hay millones de chinos que no tienen nada mejor que hacer que rastrear máquinas en Internet.

Por supuesto, se intensificaron las medidas de seguridad sobre el servicio (dejamos de tener ataques inmediatamente) y se construyó un cortafuegos bastante complejo mediante el uso de IPTables. Para controlar los posibles intentos de intrusión se instaló y configuró además Snort.

Una vez el sistema cumplía las normas, bastante exigentes, de seguridad que nos impusimos, se desplegó la aplicación front end a principios de mayo en modo aun de pruebas (la máquina aun no estaba enlazada con el site de la organización y no pertenecía a ningún dominio concreto) y tras resultar satisfactorias, el 15 de mayo entra en funcionamiento.

La parte de administración podía avanzar algo mas despacio porque aunque es la mas compleja, con mucha diferencia, no requería de una puesta en servicio completa tan temprana. A finales de mayo entra en funcionamiento de manera incompleta porque algunos de sus módulos se han ido desarrollando sobre la marcha. Esto no significa problema alguno, dado que no afecta en absoluto al front end de cara al público.

A día de hoy, ya ha finalizado nuestro plazo de devolución (terminó el 10/12/15) pero los beneficiarios que aun no hayan recibido su pago, pueden dirigirse al Juzgado Nº 1 de Córdoba para solicitarlo personalmente.