Appearance
Validaciones y Reglas de Negocio del Modulo de Membresias
Modulo: Membresias Tipo: Resource Estado: Implementado Fecha: 2026-01-27
Descripcion
Problema que resuelve
El modulo de membresias gestiona entidades con reglas de negocio complejas que deben garantizarse transversalmente en todas las operaciones. Sin validaciones centralizadas, los siguientes riesgos se materializan:
- Categorias defecto duplicadas: Podrian existir multiples categorias marcadas como "defecto", generando ambiguedad al asignar automaticamente categoria a nuevos miembros
- Titulares duplicados en grupos familiares: Un grupo familiar podria tener mas de un miembro marcado como titular principal, generando inconsistencia en la facturacion y responsabilidad
- Facturacion con condiciones incorrectas: Las facturas de membresia podrian generarse con condiciones de venta inadecuadas (contado, diferentes plazos), rompiendo la uniformidad del proceso
- Bajas inconsistentes en grupos familiares: Un miembro titular podria ser dado de baja sin designar reemplazo, dejando al grupo familiar sin responsable
Solucion implementada
Se implementa un conjunto de validaciones de negocio centralizadas que garantizan la integridad de los datos del modulo:
- Categoria defecto unica: Al crear o modificar una categoria como "defecto", se resetean automaticamente las demas
- Miembro principal unico: Se valida que solo exista un miembro titular por grupo familiar
- Condicion de venta uniforme: Toda facturacion de membresia se genera con condicion de Cuenta Corriente a 30 dias
- Baja con gestion de titular: Al dar de baja un miembro titular, se requiere designar nuevo titular
Valor de negocio
- Integridad de datos garantizada: Las reglas de negocio criticas se aplican automaticamente en todas las operaciones
- Prevencion de errores: Se evitan estados inconsistentes que podrian generar problemas en facturacion, cobros o gestion
- Proceso de facturacion uniforme: Todas las facturas de membresia siguen la misma condicion de venta, simplificando el cobro
- Responsabilidad clara en grupos familiares: Siempre existe un titular unico responsable del grupo
Contexto del sistema
Estas validaciones se aplican transversalmente en:
- Gestion de categorias de membresia: Validacion de categoria defecto unica
- Gestion de grupos familiares: Validacion de miembro principal unico
- Facturacion por lotes: Condicion de venta fija
- Baja de miembros: Validacion de titular y gestion de reemplazo
Proceso de Negocio
Validacion 1: Categoria Defecto Unica
Regla de negocio
En el sistema de membresias, una categoria puede marcarse como "defecto" para que se asigne automaticamente a nuevos miembros. Solo puede existir UNA categoria marcada como defecto en todo el sistema (por tenant).
Flujo de validacion
- El usuario crea o modifica una categoria marcandola como "defecto"
- El sistema verifica si ya existe otra categoria marcada como defecto
- Si existe otra categoria defecto: el sistema la desmarca automaticamente (la cambia a "no defecto")
- La nueva categoria se guarda como defecto
- Solo una categoria queda marcada como defecto
Comportamiento automatico
| Operacion | Accion automatica |
|---|---|
| Crear categoria como defecto | Desmarcar la categoria defecto anterior (si existe) |
| Modificar categoria marcandola como defecto | Desmarcar la categoria defecto anterior (si existe) |
| Eliminar categoria defecto | No se asigna automaticamente otra como defecto |
| Crear/modificar categoria sin defecto | No se modifica ninguna otra categoria |
Validacion 2: Miembro Principal Unico por Grupo Familiar
Regla de negocio
Cada grupo familiar debe tener exactamente un miembro designado como titular principal. El tipo de relacion del miembro indica si es principal o no. Las operaciones que puedan dejar al grupo sin titular (o con mas de uno) requieren acciones correctivas.
Escenarios de validacion
Escenario A: Cambio de tipo de relacion de un miembro
| Situacion | Se requiere reemplazo | Motivo |
|---|---|---|
| Tipo actual NO es principal | No | No se afecta al titular |
| Tipo actual ES principal, nuevo tipo ES principal | No | El grupo mantiene un titular |
| Tipo actual ES principal, nuevo tipo NO es principal | Depende | Solo si es el unico titular |
| Tipo no cambia | No | Sin efecto |
Escenario B: Eliminacion de un miembro del grupo
| Situacion | Se requiere reemplazo | Motivo |
|---|---|---|
| Miembro eliminado NO es principal | No | No se afecta al titular |
| Miembro eliminado ES principal y hay otro principal | No | Otro principal cubre |
| Miembro eliminado ES principal y es el unico | Si | El grupo quedaria sin titular |
Flujo de validacion
- Se detecta una operacion que podria afectar al titular (cambio de relacion o eliminacion)
- Se verifica si el tipo de relacion actual es principal
- Si NO es principal: la operacion procede sin restriccion
- Si ES principal: a. Se verifica si hay un nuevo tipo que tambien sea principal (en caso de modificacion): si lo hay, procede sin restriccion b. Se cuenta la cantidad de titulares en el grupo c. Si es el unico titular: se requiere designar un nuevo titular antes de proceder d. Si hay otros titulares: la operacion procede sin restriccion
Validacion 3: Condicion de Venta Fija para Facturacion de Membresia
Regla de negocio
Todas las facturas generadas por el proceso de facturacion de membresias se emiten con la condicion de venta de Cuenta Corriente a 30 dias. No se permite otra condicion de venta para la facturacion masiva de membresias.
Justificacion de negocio
- Las membresias son servicios periodicos que se facturan y luego se cobran, no se pagan de contado
- La uniformidad de condicion simplifica el proceso de cobro y la generacion de cupones de pago
- La deuda queda registrada en la cuenta corriente del socio para su posterior cancelacion
Aplicacion
| Aspecto | Valor fijo |
|---|---|
| Condicion de venta | Cuenta Corriente |
| Plazo | 30 dias |
| Ambito | Toda facturacion masiva de membresia |
| Excepciones | Ninguna |
Validacion 4: Baja de Miembro con Grupo Familiar
Regla de negocio
Cuando se da de baja a un miembro, si este es el titular principal de un grupo familiar, se debe designar un nuevo titular antes de proceder con la baja. Ademas, la baja dispara automaticamente la remocion del miembro del grupo familiar.
Datos requeridos para la baja
| Dato | Obligatoriedad | Descripcion |
|---|---|---|
| Fecha de baja | Obligatorio | Fecha efectiva de la baja |
| Motivo de baja | Obligatorio | Razon de la baja (maximo 500 caracteres) |
| Nuevo titular | Condicional | Obligatorio si el miembro es titular principal del grupo |
Datos del nuevo titular (si aplica)
| Dato | Obligatoriedad | Descripcion |
|---|---|---|
| Miembro reemplazo | Obligatorio | Identificacion del miembro que sera el nuevo titular |
| Tipo de relacion | Obligatorio | Tipo de relacion del nuevo titular (debe ser de tipo principal) |
Flujo de validacion en baja
- Se solicita la baja del miembro con fecha y motivo
- El sistema valida que la fecha y motivo estan presentes
- El sistema verifica si el miembro pertenece a un grupo familiar
- Si pertenece y es titular principal: a. Se valida que se proporcionaron datos de nuevo titular b. Se valida que el nuevo titular existe y pertenece al grupo c. Se valida que el tipo de relacion del nuevo titular es de tipo principal
- Se procesa la baja
- Se dispara automaticamente la remocion del grupo familiar (via evento de dominio)
- Si se designo nuevo titular: se ejecuta el reemplazo antes de la remocion
Frontend (Perspectiva de Usuario)
Vistas
Las validaciones no agregan vistas nuevas, sino que se manifiestan en las vistas existentes:
Gestion de categorias de membresia
- Al marcar una categoria como defecto, las demas se desmarcan automaticamente (reflejado en el listado)
Gestion de grupos familiares
- Al intentar cambiar el tipo de relacion del titular unico, se solicita designar reemplazo
- Al intentar eliminar al titular unico del grupo, se solicita designar reemplazo
Baja de miembros
- Formulario de baja con campos obligatorios (fecha, motivo)
- Si el miembro es titular de grupo: aparece seccion adicional para designar nuevo titular
Facturacion por lotes
- La condicion de venta "Cuenta Corriente 30 dias" se aplica automaticamente sin intervencion del usuario
Interacciones del usuario
- Crear/modificar categoria como defecto: El sistema desmarca automaticamente la categoria defecto anterior; el usuario no debe hacerlo manualmente
- Cambiar tipo de relacion del titular: Si es el unico titular, el sistema solicita designar reemplazo antes de confirmar
- Eliminar titular del grupo: Si es el unico titular, el sistema solicita designar reemplazo antes de confirmar
- Dar de baja a miembro titular: El formulario de baja incluye seccion para designar nuevo titular
- Ejecutar facturacion masiva: La condicion de venta se aplica automaticamente, el usuario no la selecciona
Estados de UI
- Error de validacion en baja: Si no se proporciona fecha, motivo o nuevo titular (cuando es requerido), se muestra mensaje de error
- Reemplazo de titular requerido: Se muestra formulario para seleccionar nuevo titular cuando se detecta que es necesario
- Categoria defecto actualizada: Al marcar una categoria como defecto, se muestra confirmacion del cambio automatico
Backend (Perspectiva de Datos de Negocio)
Entidades de negocio involucradas
Categoria de Membresia
Clasificacion de miembros con indicador de defecto.
| Dato de negocio | Relevancia para validacion |
|---|---|
| Indicador de defecto | Solo una categoria puede tener este indicador activo |
Grupo Familiar
Agrupacion de miembros con un titular responsable.
| Dato de negocio | Relevancia para validacion |
|---|---|
| Miembros del grupo | Lista de miembros con su tipo de relacion |
| Titular principal | Miembro(s) con tipo de relacion principal |
| Cantidad de titulares | Se valida que siempre exista al menos uno |
Tipo de Relacion
Define el rol de un miembro dentro del grupo familiar.
| Dato de negocio | Relevancia para validacion |
|---|---|
| Indicador es_principal | Determina si el tipo de relacion corresponde a un titular |
Solicitud de Baja de Miembro
Datos requeridos para procesar la baja.
| Dato de negocio | Relevancia para validacion |
|---|---|
| Fecha de baja | Obligatoria, debe ser una fecha valida |
| Motivo de baja | Obligatorio, maximo 500 caracteres |
| Nuevo titular | Obligatorio si el miembro es el unico titular principal |
Validaciones de negocio
| Validacion | Descripcion | Enforcement |
|---|---|---|
| Categoria defecto unica | Solo una categoria puede ser defecto | Automatico al crear/modificar |
| Titular unico por grupo | Solo un titular principal por grupo | Validado al modificar/eliminar miembro del grupo |
| Condicion de venta CCC 30 | Toda facturacion de membresia es CCC 30 dias | Aplicado automaticamente en facturacion masiva |
| Baja con fecha | La fecha de baja es obligatoria | Validado al solicitar baja |
| Baja con motivo | El motivo de baja es obligatorio | Validado al solicitar baja |
| Baja titular con reemplazo | Si es titular unico, se requiere reemplazo | Validado al solicitar baja |
Reglas de Negocio
RN-001: Unicidad de categoria defecto
Descripcion: En todo momento, solo puede existir una categoria de membresia marcada como "defecto" dentro de un mismo tenant. Si se marca una nueva categoria como defecto, la anterior pierde su marca automaticamente.
Condicion: Se crea o modifica una categoria marcandola como defecto.
Accion:
- Buscar si existe otra categoria defecto en el tenant
- Si existe: desmarcarla (cambiar su indicador de defecto a falso)
- Guardar la nueva categoria con el indicador de defecto activo
- Solo una categoria queda como defecto
RN-002: Un titular principal por grupo familiar
Descripcion: Cada grupo familiar debe tener exactamente un miembro con tipo de relacion principal. Las operaciones que afecten al titular validan esta condicion.
Condicion: Se modifica el tipo de relacion de un miembro o se elimina un miembro del grupo.
Accion:
- Si el miembro afectado no es el titular actual: permitir sin restriccion
- Si el miembro afectado es el titular:
- Si hay otro titular en el grupo: permitir la operacion
- Si es el unico titular: requerir designacion de nuevo titular antes de proceder
RN-003: Condicion de venta uniforme en facturacion de membresia
Descripcion: Toda factura generada por el proceso de facturacion masiva de membresias se emite con la condicion de venta "Cuenta Corriente a 30 dias". No se permite seleccionar ni modificar esta condicion.
Condicion: Se ejecuta el proceso de facturacion por lotes de membresias.
Accion:
- Aplicar automaticamente la condicion de venta "Cuenta Corriente"
- Aplicar plazo fijo de 30 dias
- No ofrecer al usuario la posibilidad de cambiar la condicion
- Toda factura del lote se genera con esta condicion uniforme
RN-004: Baja de miembro titular requiere reemplazo
Descripcion: Cuando se da de baja a un miembro que es el unico titular principal de un grupo familiar, se debe proporcionar la informacion del nuevo titular. Sin reemplazo, la baja no puede procesarse.
Condicion: Se solicita la baja de un miembro que es titular unico de un grupo familiar.
Accion:
- Validar que se proporcionaron los datos del nuevo titular
- Validar que el nuevo titular es un miembro existente del grupo
- Validar que el tipo de relacion asignado al nuevo titular es de tipo principal
- Ejecutar el reemplazo de titular
- Procesar la baja del miembro anterior
- Remover al miembro del grupo familiar
RN-005: Datos obligatorios en baja de miembro
Descripcion: Para procesar la baja de un miembro, se requieren obligatoriamente la fecha de baja y el motivo. El motivo no puede exceder 500 caracteres.
Condicion: Se solicita la baja de un miembro.
Accion:
- Validar que la fecha de baja esta presente y es una fecha valida
- Validar que el motivo de baja esta presente y es una cadena de texto
- Validar que el motivo no excede 500 caracteres
- Si alguna validacion falla: rechazar la solicitud con mensaje explicativo
Casos de Uso
CU-001: Marcar categoria como defecto
Actor: Usuario Administrador de Membresias
Precondiciones:
- Usuario autenticado con permiso de gestion de categorias
- Existe al menos una categoria de membresia
- Puede o no existir una categoria defecto actualmente
Flujo principal:
- El usuario accede a la gestion de categorias de membresia
- El usuario selecciona una categoria y la marca como "defecto"
- El sistema detecta que ya existe otra categoria defecto
- El sistema desmarca automaticamente la categoria defecto anterior
- El sistema guarda la nueva categoria como defecto
- El listado muestra solo la nueva categoria con la marca de defecto
Postcondiciones:
- Solo la nueva categoria esta marcada como defecto
- La categoria anteriormente marcada ya no es defecto
- Los nuevos miembros que se creen recibiran la nueva categoria defecto
Flujos alternativos:
- No habia defecto anterior: La nueva categoria se marca como defecto sin afectar a ninguna otra
- Se desmarca defecto sin marcar otra: Ningun categoria queda como defecto (los nuevos miembros no tendran categoria automatica)
CU-002: Dar de baja a miembro titular de grupo familiar
Actor: Usuario de Membresias
Precondiciones:
- Usuario autenticado con permiso de baja de miembros
- El miembro esta activo
- El miembro es el unico titular principal de su grupo familiar
- Existen otros miembros en el grupo que pueden ser titular
Flujo principal:
- El usuario solicita la baja del miembro
- El sistema detecta que el miembro es titular unico del grupo familiar
- El sistema solicita los datos de fecha de baja, motivo y nuevo titular
- El usuario ingresa la fecha de baja y el motivo
- El usuario selecciona al nuevo titular entre los demas miembros del grupo
- El usuario selecciona el tipo de relacion principal para el nuevo titular
- El usuario confirma la baja
- El sistema reemplaza al titular del grupo
- El sistema procesa la baja del miembro
- El sistema remueve automaticamente al miembro del grupo familiar
Postcondiciones:
- El miembro esta dado de baja
- El miembro ya no pertenece al grupo familiar
- El grupo familiar tiene un nuevo titular principal
- Se registro la fecha y motivo de baja
Flujos alternativos:
- Falta fecha o motivo: El sistema rechaza la solicitud y muestra mensaje de error
- No se designa reemplazo: El sistema rechaza la solicitud indicando que se requiere nuevo titular
- Miembro no es titular: La baja se procesa normalmente sin solicitar reemplazo
CU-003: Facturacion masiva con condicion de venta fija
Actor: Usuario de Facturacion
Precondiciones:
- Usuario autenticado con permiso de facturacion de membresias
- Existen miembros activos con membresia vigente
Flujo principal:
- El usuario configura los parametros de facturacion (periodo, punto de venta, rango)
- El usuario inicia la facturacion por lotes
- El sistema genera las facturas para cada socio activo
- Todas las facturas se generan con condicion de venta "Cuenta Corriente a 30 dias"
- La deuda queda registrada en la cuenta corriente de cada socio
Postcondiciones:
- Todas las facturas tienen la misma condicion de venta
- Todas las deudas estan en cuenta corriente con plazo de 30 dias
- El usuario no intervino en la seleccion de la condicion de venta
Consideraciones
Seguridad
- Solo usuarios con permisos apropiados pueden ejecutar operaciones que disparan validaciones
- La designacion de nuevo titular solo puede ser un miembro existente del grupo
- Las validaciones se aplican a nivel de negocio, no son evitables desde la interfaz
Auditoria
| Operacion | Informacion registrada |
|---|---|
| Cambio de categoria defecto | Categoria anterior y nueva, usuario que realizo el cambio |
| Reemplazo de titular | Titular anterior y nuevo, grupo afectado, usuario |
| Baja de miembro | Fecha, motivo, nuevo titular (si aplica), usuario |
Rendimiento
- La validacion de categoria defecto unica se ejecuta en la misma transaccion que la creacion/modificacion
- La validacion de titular unico se ejecuta con una consulta de conteo rapida
- La condicion de venta fija no genera consulta adicional (es un valor definido en el proceso)
Dependencias
Funcionalidades relacionadas
- Categorias de membresia: Entidad sujeta a la validacion de defecto unica
- Grupos familiares: Entidad sujeta a la validacion de titular unico
- Tipos de relacion: Definen si un miembro es titular (indicador es_principal)
- Facturacion por lotes: Proceso con condicion de venta fija
- Baja de miembros: Proceso con validacion de titular y datos obligatorios
- Eventos de dominio: La baja dispara la remocion automatica del grupo familiar
Criterios de Aceptacion
- [x] AC-001: Al marcar una categoria como defecto, las demas categorias defecto se desmarcan automaticamente
- [x] AC-002: Solo una categoria puede estar marcada como defecto en un mismo tenant
- [x] AC-003: No se puede cambiar el tipo de relacion del unico titular sin designar reemplazo
- [x] AC-004: No se puede eliminar al unico titular de un grupo sin designar reemplazo
- [x] AC-005: Si el miembro afectado no es titular, las operaciones proceden sin restriccion
- [x] AC-006: Si hay otros titulares en el grupo, las operaciones proceden sin restriccion
- [x] AC-007: Todas las facturas de membresia se generan con condicion "Cuenta Corriente a 30 dias"
- [x] AC-008: No se permite seleccionar otra condicion de venta para facturacion de membresias
- [x] AC-009: La baja requiere fecha de baja obligatoria
- [x] AC-010: La baja requiere motivo obligatorio (maximo 500 caracteres)
- [x] AC-011: La baja de un titular unico requiere datos de nuevo titular
- [x] AC-012: Los datos del nuevo titular incluyen miembro reemplazo y tipo de relacion
- [x] AC-013: El reemplazo de titular se ejecuta antes de la remocion del grupo
Notas Adicionales
Interaccion entre validaciones
Las validaciones de este documento interactuan con los eventos de dominio documentados por separado. La baja de un miembro (validada aqui) dispara automaticamente un evento que remueve al miembro del grupo familiar (documentado en "Eventos de Dominio"). La validacion de titular se ejecuta ANTES de la baja, mientras que la remocion del grupo se ejecuta DESPUES como efecto colateral del evento.
Condicion de venta hardcoded
La condicion de venta "Cuenta Corriente a 30 dias" esta definida de forma fija en el proceso de facturacion. Esta decision de negocio refleja que todos los socios tienen cuenta corriente y que la membresia es un servicio periodico que se factura y luego se cobra. Si en el futuro se necesitara soportar otras condiciones de venta, seria necesario parametrizar esta configuracion.
Historial de Cambios
| Fecha | Version | Autor | Descripcion |
|---|---|---|---|
| 2026-01-27 | 1.0 | Sistema | Documentacion de funcionalidad implementada |