Caso de éxito: portal web para que los socios de una corporación consulten y paguen sus cuotas en Cádiz

Este caso explica cómo se construye un portal de socios para consultar y pagar cuotas en línea. Una corporación con socios y cuotas anuales llevaba el control de quién es socio y quién ha pagado en una base de datos de escritorio. Funcionaba para el personal que la manejaba, pero los socios no tenían forma de consultar sus propios pagos ni de abonar lo pendiente sin pasar por la oficina. Este es el proyecto con el que construimos un portal web conectado a esa información, el camino que seguimos para trasladar los datos a una base de datos preparada para la web y los criterios que conviene tener en cuenta cuando una entidad se plantea algo parecido.

Proyecto para un cliente de la provincia de Cádiz. Caso anonimizado: por confidencialidad, la ubicación y los datos que podrían identificar al cliente se han modificado.

La situación de partida

El registro de la entidad vivía en una base de datos Microsoft Access con dos tablas:

• Usuarios. Los socios, con sus datos personales.
• Pagos. El registro de cada pago realizado.

El propio personal de la entidad entraba en esa base de datos para introducir y modificar la información. Es un método habitual y razonable mientras el volumen es pequeño y quien trabaja con los datos está siempre en el mismo puesto. Sus límites aparecen cuando se quiere que el socio participe: una base de datos de escritorio no está pensada para recibir visitas desde internet, ni para que cada persona vea solo lo suyo, ni para cobrar en línea.

Los socios, por tanto, no disponían de un canal web propio. Para saber si tenían una cuota pendiente o para pagarla dependían de una gestión manual con la entidad.

Lo que se pidió

La necesidad se puede resumir en una frase: que cada socio pueda entrar con su usuario, ver su situación de pagos y abonar en línea lo que tenga pendiente, sobre los datos que la entidad ya tiene, sin empezar de cero.

De ahí salió un alcance acotado, con cuatro pantallas:

1. Inicio de sesión. Cada socio accede con sus credenciales.
2. Perfil del socio. Sus datos personales, tal como constan en el registro.
3. Pagos de suscripción. El historial de las cuotas pagadas y las pendientes.
4. Pasarela de pago. Si hay algún pago pendiente, el socio puede abonarlo desde el propio portal.

Un alcance corto es una ventaja. Permite poner en marcha lo esencial, comprobar que funciona con usuarios reales y ampliar después con criterio.

La solución técnica

Construimos un portal web con Laravel, un framework de PHP de código abierto muy extendido, que ofrece de serie piezas que en un proyecto de este tipo importan: autenticación de usuarios, protección de formularios, acceso ordenado a la base de datos y una estructura de código que otros programadores pueden mantener.

Las dos tablas originales se trasladan de Access a MySQL, y el portal trabaja directamente sobre esa base de datos. Con ello la información deja de depender de un archivo de escritorio y pasa a un motor preparado para recibir consultas de muchos usuarios a la vez.

El portal se integró con dos proveedores externos. Esta parte es la que más se subestima cuando se planifica un proyecto: conectar sistemas de terceros exige entender cómo responden, qué ocurre cuando fallan y cómo se concilia lo que el proveedor dice que ha pasado con lo que el portal registra.

Cómo lo hicimos, paso a paso

El plan de proyecto dividió el trabajo en fases. Las duraciones que figuran son las estimadas en el plan, que indicaba un total aproximado de cinco a seis semanas.

1. Análisis. Una reunión inicial con el equipo de desarrollo y con los responsables de la entidad, y el análisis de los requisitos y del alcance. Es la fase que más condiciona al resto, porque en ella se decide qué entra y qué no.
2. Planificación (una semana prevista). Evaluamos la base de datos existente, determinamos qué cambios hacían falta y definimos la arquitectura y el diseño del portal.
3. Desarrollo (tres semanas previstas). Preparación del entorno de desarrollo, interfaz de usuario y experiencia de uso, integración con la base de datos, parte servidor para gestionar pagos y consultas, medidas de seguridad y pruebas de funcionamiento. El trabajo se organiza en entregas semanales, con una breve reunión con el cliente en cada una para mostrar el avance.
4. Pruebas y ajustes (una semana prevista). Pruebas del portal en distintos entornos (desarrollo, prueba y producción), corrección de errores y de problemas de rendimiento y optimización de la base de datos.
5. Despliegue y lanzamiento (una semana prevista). Preparación del entorno de producción, migración de los datos existentes a la base de datos adaptada, lanzamiento del portal y verificación de que todo funciona. Se incluyó la formación del personal que administra y atiende el portal.
6. Seguimiento y mantenimiento (continuo). Monitorización, resolución de incidencias posteriores, mejoras y actualizaciones periódicas de seguridad y de la base de datos.

El portal está en producción.

La migración de Access a MySQL: qué se cuida

Pasar los datos de una base de datos de escritorio a MySQL parece mecánico, pero es donde se esconden los problemas. Estos son los puntos que revisamos siempre en una migración de este tipo:

• Calidad de los datos de origen. Duplicados, campos vacíos, fechas en formatos distintos o nombres escritos de varias maneras. Es mejor detectarlos antes de migrar que después de abrir el portal a los usuarios.
• Claves e identificadores. Cada socio y cada pago deben tener un identificador estable, para que la relación entre ambas tablas no se rompa al cambiar de sistema.
• Codificación de caracteres. Los acentos, las eñes y los apóstrofos deben llegar intactos. Se trabaja con una codificación moderna y se comprueba con datos reales.
• Verificación de la migración. Se comparan recuentos y se revisan muestras de registros entre el origen y el destino, de modo que el equipo de la entidad pueda dar por buena la información.
• Conservación del original. El archivo de origen se conserva sin modificar hasta que el nuevo sistema está validado.

Pagos en línea: principios que aplicamos

Cuando un portal permite pagar, hay normas de prudencia que no dependen del proveedor elegido:

• El portal no guarda datos de tarjeta. El cobro lo gestiona la pasarela de pago, y el portal solo recibe el resultado de la operación. Así se reduce el riesgo y la carga de cumplimiento.
• El estado del pago se confirma desde el proveedor. No basta con que el socio vuelva a una página que dice «pago correcto»: el resultado debe llegar de forma segura desde el sistema de cobro y registrarse en el portal.
• Cada cuota queda trazada. Qué se pagó, cuándo y con qué resultado, de modo que la entidad pueda conciliar sus cobros.
• Los datos personales se protegen. Acceso solo con credenciales, contraseñas almacenadas de forma segura, comunicaciones cifradas y copias de seguridad. Los socios son personas físicas y sus datos están sujetos al RGPD.

Qué cambia para la entidad y para los socios

Los beneficios que persigue el proyecto, no resultados medidos, son estos:

• El socio puede consultar sus pagos y abonar los pendientes en línea, cuando le convenga.
• La información deja de depender de una base de datos de escritorio y pasa a una base preparada para el acceso web.
• El personal administrador cuenta con un portal que puede gestionar con la formación recibida.
• La plataforma queda sobre una tecnología abierta que cualquier equipo de desarrollo puede mantener. El código, los servidores, los dominios y las licencias quedan a nombre del cliente.

Lo que aprendimos

Un alcance corto se entrega mejor. Cuatro pantallas bien definidas se pueden probar de verdad con usuarios reales. Las ampliaciones llegan después, con la experiencia del uso.

Los datos mandan. El esfuerzo no está en las pantallas, sino en que los datos migrados sean fiables y en que el cobro y el registro estén siempre de acuerdo.

Las integraciones se planifican desde el principio. Los proveedores externos tienen sus propios plazos, formatos y casos límite. Dejarlos para el final es la forma más segura de retrasar un proyecto.

¿Cuándo compensa un portal así?

No toda entidad lo necesita. Suele tener sentido cuando se dan varias de estas condiciones:

• Hay un número de socios, clientes o usuarios suficiente como para que atender consultas de pago a mano ocupe tiempo cada semana.
• Los datos ya existen en una base de datos o en hojas de cálculo que se pueden aprovechar.
• Se quiere ofrecer un canal propio, con la imagen de la entidad, en lugar de depender de herramientas de terceros que no se adaptan.
• Se necesita saber con certeza quién ha pagado y quién no, sin cruzar listados.

Si su caso encaja, conviene empezar con un análisis de los datos de origen y un alcance pequeño, y dejar las mejoras para una segunda fase.

¿Tiene datos en una base de escritorio o en hojas de cálculo?

Podemos estudiar con usted qué se puede aprovechar, qué hay que limpiar y cuál sería el alcance mínimo de un portal para sus socios o clientes. Puede conocer cómo trabajamos en nuestras páginas sobre programación a medida y software de gestión, o contarnos su caso.

Portal de socios: lo esencial del proyecto

Un portal de socios funciona bien cuando parte de datos limpios y de una migración repetible. En este portal de socios, cada persona consulta su situación y paga sus cuotas con la pasarela integrada. El portal de socios está en producción y se integró con dos proveedores. Si una entidad todavía gestiona sus cuotas con hojas o bases antiguas, un portal de socios es un paso lógico.

Para ampliar información, puede consultar la documentación de Laravel.

Preguntas frecuentes

¿Hace falta tirar la base de datos actual para tener un portal?

No. Lo habitual es aprovechar los datos que ya existen y trasladarlos a una base de datos adecuada para la web, comprobando la migración antes de abrir el portal.

¿Puede el portal conectarse con otros servicios que ya usamos?

Sí. Es una parte frecuente de los proyectos de este tipo, y por eso se define desde el análisis. Cada proveedor tiene sus propias condiciones técnicas y es lo primero que revisamos.

¿Quién es propietario del código y de los datos?

El cliente. El código, los servidores, los dominios y las licencias quedan a nombre de la entidad, sin permanencias con nosotros.

¿Cuánto tarda un proyecto así?

Depende del alcance y de las integraciones. En este caso, el plan estimaba entre cinco y seis semanas para el desarrollo, incluidas las pruebas y el lanzamiento. Fijamos el calendario cuando el alcance está cerrado.

¿Pueden hacerlo si ya trabajamos con otra consultora?

Sí. Trabajamos directamente con empresas y también como subcontrata de consultoras e integradores, en marca blanca.