Este es un recorrido de producto, no el caso de ningún club real: describe cómo se conectan las pantallas de ClubWare, sin cifras inventadas ni un club en particular. La pregunta que resuelve es en qué momento exacto del camino entre el PIN del gerente y la pantalla del socio queda decidido -sin que nadie lo note- si el motivo del ajuste va a llegar visible o va a quedarse fuera (según lo visto en el ajuste manual de gerente en ClubWare nunca le dice al socio por qué se le cobró).
1. El gerente detecta que una cuenta necesita un ajuste
El recorrido empieza fuera del flujo normal de consumo del POS: un socio reclama un cargo mal capturado, o el club decide condonar parte de una deuda. Para eso existe el ajuste manual -una herramienta legítima, no un atajo-, pero ClubWare no deja que cualquiera la use: exige el PIN numérico del gerente, verificado en el servidor, nunca confiando en un flag que venga del cliente.
2. El gerente escribe el motivo -- y el sistema no acepta cualquier cosa
Antes de registrar el cargo o el abono, ClubWare pide un motivo. No es un campo decorativo: el esquema de validación exige mínimo 10 caracteres y máximo 500, y rechaza la operación completa si el gerente intenta dejarlo vacío o escribe un relleno demasiado corto. El monto puede ser positivo (aumenta la deuda del socio) o negativo (la reduce, por ejemplo una condonación) -en ambos casos, el motivo es obligatorio por igual.
3. El movimiento se guarda con dos etiquetas distintas
Aquí es donde el sistema separa dos cosas que un socio podría confundir: el concepto del movimiento, que siempre queda como el texto fijo "Ajuste manual de gerente" (para que se distinga de un consumo o un pago normal), y el motivo real que el gerente escribió, que se guarda en una columna aparte. Las dos etiquetas conviven en el mismo registro, y las dos se devuelven cuando alguien consulta ese movimiento.
4. El dato llega completo hasta el navegador -- de cualquiera de los dos lados
El motivo del ajuste no se queda atrapado en la base de datos ni se filtra antes de llegar al cliente. Tanto la pantalla que usa el staff para ver la ficha de un socio como el endpoint que el propio socio consulta desde su portal reciben la misma respuesta completa, con el motivo incluido. No hay una versión "recortada" para el socio: el backend no distingue.
5. Una pantalla lo pinta, la otra no
A partir de ahí, las dos pantallas divergen sin que el backend tenga nada que ver. La ficha del socio que usa el staff imprime el motivo debajo del concepto, en una línea aparte, cada vez que existe -y agrega un candado visual si el movimiento fue autorizado por un gerente. La pantalla "Mis movimientos" del portal del socio, en cambio, sólo tiene cuatro columnas fijas: fecha, tipo, concepto y monto. El motivo llegó hasta esa pantalla en la misma respuesta -pero nadie escribió la línea que lo pinta.
Qué guarda el sistema en cada etapa
| Etapa | Qué guarda ClubWare | Visible al staff / al socio |
|---|---|---|
| 1. Gerente inicia el ajuste | PIN verificado en servidor | Ninguno todavía |
| 2. Motivo capturado | Texto de mínimo 10 caracteres, obligatorio | Sólo existe si pasa la validación |
| 3. Movimiento guardado | Concepto genérico + motivo en columna aparte | Ambos campos quedan en el registro |
| 4. Consulta del movimiento | API devuelve el tipo completo, motivo incluido | Llega igual al staff y al portal del socio |
| 5. Renderizado en pantalla | Sin cambios en el dato | Staff: sí lo pinta. Portal del socio: no lo pinta |
En la etapa 5 no hay ninguna restricción de backend ni de seguridad -es la misma respuesta, el mismo dato-: es sólo que una de las dos pantallas nunca se terminó de escribir. Puedes estimar cuánto representa eso, con tus propios números, en la calculadora de exposición por ajustes manuales sin motivo visible.
Preguntas frecuentes
¿En qué paso exacto se pierde el motivo del ajuste para el socio?
En el paso 5: el dato llega completo hasta el navegador del socio en la respuesta de la API, pero el componente de su pantalla nunca lee ese campo al armar la tabla.
¿ClubWare notifica al socio cuando se le hace un ajuste?
El flujo descrito no incluye un aviso activo (correo, notificación) en el momento del ajuste; el socio depende de entrar a su portal y revisar sus movimientos, donde tampoco encontrará el motivo hoy.
¿Este recorrido aplica a ajustes positivos y negativos por igual?
Sí: el motivo es obligatorio tanto si el ajuste aumenta la deuda del socio como si la reduce, y en ambos casos el mismo gap aplica -el staff lo ve, el socio no.
Ve el recorrido completo en tu propia demo
Te mostramos en vivo el ajuste manual con PIN de gerente, y qué pasa exactamente cuando el motivo llega a la pantalla del socio.
Agenda una demo gratis