Appearance
Agenda — Proceso de Emisión de Eventos Automáticos
Módulo: general Tipo: Process Estado: Planificado Fecha: 2026-03-31
Descripción
Este documento describe el proceso mediante el cual los módulos del sistema (CtaCte, CRM, Membresías, Compras, Stock, Tesorería y cualquier módulo futuro) emiten eventos automáticos hacia la agenda de los usuarios. Define el contrato de emisión que todo módulo debe cumplir, los tipos de eventos que cada módulo puede generar, las reglas de audiencia predeterminada y el ciclo de vida de un evento de sistema.
Valor para el negocio:
- Permite que los módulos del sistema informen activamente a los usuarios sobre situaciones que requieren atención (vencimientos, alertas, seguimientos), sin que el usuario deba ir a buscarlos
- Centraliza las alertas en la agenda en lugar de dispersarlas en notificaciones heterogéneas por módulo
- Mantiene trazabilidad: cada evento de sistema referencia la entidad que lo originó, con navegación directa desde la agenda al módulo correspondiente
Contexto:
- Los eventos automáticos son generados por los módulos del sistema; nunca son creados directamente por el usuario
- El módulo emisor define la audiencia del evento: puede dirigirse a un usuario específico, un grupo, todos los usuarios de una sucursal o toda la empresa
- La referencia a la entidad que originó el evento siempre apunta a nivel sucursal (
sucXXXX) o empresa (public); nunca a nivel caja - Los eventos de sistema no pueden ser editados ni eliminados por los usuarios; solo pueden ser marcados como vistos de forma individual por cada destinatario
- La agenda ignora el modo prueba: los eventos de sistema se crean siempre en la base de datos oficial, independientemente del modo en que estaba operando el módulo que los emitió
Módulos Emisores y Tipos de Eventos
CtaCte — Cuenta Corriente
| Tipo de evento | Descripción | Audiencia predeterminada |
|---|---|---|
| Aviso de vencimiento de deuda | Se emite cuando un cliente tiene una deuda próxima a vencer o ya vencida | Configurable: usuarios responsables del cobro de la sucursal |
| Aviso de cuota impaga | Se emite cuando una cuota del plan de pagos de un cliente no fue cobrada en la fecha esperada | Configurable: usuarios de la sucursal del movimiento |
CRM
| Tipo de evento | Descripción | Audiencia predeterminada |
|---|---|---|
| Recordatorio de contacto programado | Se emite cuando se aproxima la fecha de un seguimiento planificado sobre un contacto | Usuario responsable del seguimiento |
| Alerta de inactividad de cliente | Se emite cuando un cliente no registra actividad durante un período configurable | Configurable: usuario asignado al cliente o grupo de ventas |
Membresías
| Tipo de evento | Descripción | Audiencia predeterminada |
|---|---|---|
| Vencimiento de membresía | Se emite cuando la membresía de un miembro está próxima a vencer | Configurable: usuarios de la sucursal |
| Renovación pendiente | Se emite cuando una membresía vencida aún no fue renovada | Configurable: usuarios de la sucursal |
Compras
| Tipo de evento | Descripción | Audiencia predeterminada |
|---|---|---|
| Vencimiento de factura de proveedor | Se emite cuando una factura de proveedor está próxima a vencer | Configurable: usuarios de administración de la sucursal |
| Orden de compra pendiente de recepción | Se emite cuando una orden de compra lleva más tiempo del esperado sin ser recibida | Configurable: usuarios de compras de la sucursal |
Stock
| Tipo de evento | Descripción | Audiencia predeterminada |
|---|---|---|
| Alerta de stock mínimo | Se emite cuando el stock de un producto cae por debajo del mínimo configurado | Configurable: usuarios de stock o compras de la sucursal |
| Alerta de producto sin movimiento | Se emite cuando un producto no registra movimiento durante un período configurable | Configurable: usuarios de stock de la sucursal |
Tesorería
| Tipo de evento | Descripción | Audiencia predeterminada |
|---|---|---|
| Vencimiento de cheque | Se emite cuando un cheque propio o de tercero está próximo a vencer | Configurable: usuarios de tesorería de la sucursal |
| Rendición pendiente | Se emite cuando una rendición de caja lleva más tiempo del esperado sin ser aprobada | Configurable: usuarios responsables de tesorería |
Proceso de Emisión
Paso 1: Detección de la condición de negocio
El módulo emisor detecta una situación que requiere notificación a los usuarios. Esta detección puede ocurrir:
- Como resultado de una acción del usuario (ej. guardar una factura genera un aviso de vencimiento)
- Como resultado de un proceso automático programado (ej. un proceso nocturno que evalúa vencimientos del día siguiente)
- Como resultado de un cambio de estado en una entidad (ej. un cheque cambia a estado "próximo a vencer")
Paso 2: Construcción del evento
El módulo emisor construye el evento con los siguientes datos obligatorios:
- Título: Texto descriptivo breve de la situación (ej. "Deuda vencida: Cliente ABC — $15.000")
- Tipo: Siempre "Sistema" para eventos automáticos
- Módulo de origen: Identificador del módulo que lo emite (ej.
ctacte,crm,membresias) - Prioridad: El módulo define la prioridad según la urgencia de la situación
- Referencia polimórfica: Schema de la entidad (nivel sucursal o empresa), tipo de entidad e identificador. Ej: schema
suc0001, tipoFACTURA_PROVEEDOR, id892 - Ruta de navegación: Dirección dentro del sistema para ir directamente a la entidad. Ej: ruta que lleva al detalle de la factura del proveedor
- Audiencia: Lista de targets de visibilidad que el módulo define según el tipo de evento
El módulo puede incluir de forma opcional:
- Descripción con mayor detalle de la situación
- Etiquetas para facilitar el filtrado (ej.
vencimiento,cobranza,proveedor)
Paso 3: Definición de la audiencia
El módulo emisor define la audiencia del evento. Las opciones son:
| Opción | Cuándo usarla |
|---|---|
| Usuario específico | Cuando el evento corresponde a una responsabilidad nominal (ej. el vendedor asignado a un cliente) |
| Grupo | Cuando el evento corresponde a una función (ej. el grupo de tesorería) |
| Grupo + sucursal | Cuando el evento corresponde a un grupo dentro de una sucursal específica (ej. el equipo de cobranzas de la sucursal suc0001) |
| Sucursal completa | Cuando el evento es relevante para todos los usuarios de la sucursal donde está la entidad |
| Empresa completa | Cuando el evento es relevante para toda la organización |
La audiencia de cada tipo de evento por módulo es configurable; el sistema provee valores predeterminados que el administrador puede ajustar.
Paso 4: Persistencia del evento
El evento se guarda en el schema public (nivel empresa) de la base de datos oficial. No se usa la base de prueba aunque el módulo emisor esté operando en modo prueba. El evento queda en estado "Pendiente" para cada destinatario hasta que sea marcado como visto.
Paso 5: Disponibilidad en la agenda
Inmediatamente después de la persistencia, el evento aparece en la agenda de cada destinatario con el indicador de no visto. El destinatario puede:
- Consultar el detalle del evento
- Navegar a la entidad de origen usando la ruta de navegación provista
- Marcar el evento como visto (acción individual; no afecta a otros destinatarios)
Ciclo de Vida de un Evento de Sistema
[Módulo detecta condición]
↓
[Evento creado — estado: Pendiente para cada destinatario]
↓
[Destinatario lo ve en su agenda con indicador de no visto]
↓
[Destinatario lo marca como visto]
↓
[Registro de lectura guardado — evento sale de la vista activa]
↓
[Evento consultable en historial con estado: Visto]El evento nunca se elimina automáticamente. Los eventos de sistema permanecen en el historial de la agenda indefinidamente para consulta futura, independientemente de si la condición que los originó fue resuelta.
Reglas de Negocio
RN-001: Persistencia siempre en base oficial
- Condición: Un módulo emite un evento de sistema
- Acción: El evento se persiste en la base de datos oficial (
bautista), independientemente del modo (prueba/oficial) en que esté operando el módulo emisor en ese momento
RN-002: Referencia polimórfica al nivel correcto
- Condición: El módulo emisor construye la referencia a la entidad de origen
- Acción: El schema de la entidad debe ser de nivel sucursal (
sucXXXX) o empresa (public). Si la entidad existe en un schema de caja (sucXXXXcajaXXXX), el módulo debe normalizar la referencia al schema de la sucursal padre
RN-003: Los eventos de sistema no pueden ser modificados por usuarios
- Condición: Un usuario intenta editar o eliminar un evento de origen Sistema
- Acción: El sistema deniega la acción. La única operación permitida es marcar el evento como visto
RN-004: El marcado de lectura es individual
- Condición: Un destinatario marca un evento de sistema como visto
- Acción: Solo ese destinatario ve el evento como "Visto". Los demás destinatarios mantienen su estado de lectura propio e independiente
RN-005: Los eventos de sistema permanecen en el historial
- Condición: Un evento de sistema es marcado como visto por un usuario
- Acción: El evento desaparece de la vista activa del usuario, pero sigue disponible en el historial de la agenda para consulta futura. No se elimina
RN-006: Audiencia predeterminada por tipo de evento
- Condición: Un módulo emite un evento de sistema
- Acción: El módulo aplica la audiencia predeterminada configurada para ese tipo de evento. El administrador del sistema puede ajustar esta configuración predeterminada
RN-007: Idempotencia de emisión
- Condición: El proceso de detección de condiciones se ejecuta más de una vez para la misma situación (ej. el proceso nocturno vuelve a detectar el mismo vencimiento)
- Acción: El sistema verifica si ya existe un evento de sistema activo (no visto) para la misma entidad y tipo de evento. Si existe, no crea uno nuevo para evitar duplicados en la agenda
Casos de Uso
UC-001: El módulo CtaCte genera un aviso de vencimiento
Actor: Proceso automático del módulo CtaCte (ejecutado de forma programada)
Precondiciones:
- Existe un proceso programado que evalúa diariamente los vencimientos de deudas de clientes
- Un cliente tiene una deuda con fecha de vencimiento igual al día siguiente
Flujo principal:
- El proceso detecta que la deuda del cliente "Comercial López" en la sucursal
suc0001vence mañana - El proceso verifica que no exista ya un aviso activo para esta deuda y este tipo de evento
- El proceso construye el evento con:
- Título: "Deuda próxima a vencer: Comercial López — $42.000"
- Tipo: Sistema / Módulo:
ctacte/ Prioridad: Alta - Referencia: schema
suc0001, tipoCLIENTE, id134 - Ruta de navegación: ruta hacia el detalle de la deuda del cliente en CtaCte
- Audiencia: Grupo "Cobranzas" filtrado por sucursal
suc0001
- El proceso emite el evento hacia la agenda
- El evento queda disponible en la agenda de todos los miembros del grupo "Cobranzas" que pertenecen a
suc0001 - Cada usuario ve el aviso con indicador de no visto en su agenda
Postcondiciones:
- Evento creado en
publicde la base de datos oficial - Todos los destinatarios ven el evento en su agenda como no visto
UC-002: El usuario navega al origen desde un evento de sistema
Actor: Usuario destinatario de un evento automático
Precondiciones:
- El usuario tiene en su agenda un evento de sistema generado por el módulo Tesorería (vencimiento de cheque)
- El evento incluye una ruta de navegación a la entidad de origen
Flujo principal:
- El usuario ve el evento "Cheque propio N°004521 vence en 3 días" en su agenda
- El usuario abre el detalle del evento
- El sistema muestra el detalle del evento: título, descripción, módulo de origen (Tesorería), fecha de vencimiento, ruta de navegación al cheque
- El usuario hace clic en "Ver cheque" (la ruta de navegación)
- El sistema lo lleva directamente al detalle del cheque dentro del módulo Tesorería
- El usuario gestiona el cheque desde Tesorería
- El usuario vuelve a la agenda y marca el evento como visto
Postcondiciones:
- El usuario gestionó el cheque desde el módulo correspondiente
- El evento queda marcado como visto en la agenda del usuario
UC-003: El administrador configura la audiencia predeterminada para un tipo de evento
Actor: Administrador del sistema
Precondiciones:
- El administrador tiene permisos de configuración de la agenda
- Existe la configuración de audiencia predeterminada para tipos de eventos de sistema
Flujo principal:
- El administrador accede a la configuración de tipos de eventos de sistema
- El sistema muestra la lista de tipos de eventos por módulo, con su audiencia predeterminada actual
- El administrador selecciona el tipo "Vencimiento de factura de proveedor" del módulo Compras
- El administrador cambia la audiencia de "Grupo Compras de la sucursal" a "Usuario específico: María García"
- El administrador guarda la configuración
- A partir de ese momento, los nuevos eventos de vencimiento de factura de proveedor se dirigen únicamente a María García
Postcondiciones:
- La configuración de audiencia queda actualizada
- Los eventos futuros de ese tipo se crean con la nueva audiencia
- Los eventos ya emitidos no se ven afectados
Consideraciones
Seguridad
- Los eventos de sistema solo pueden ser creados por los procesos internos del sistema; ningún usuario puede crear un evento con origen "Sistema"
- Los usuarios solo pueden ver eventos de sistema que estén en su audiencia; nunca pueden ver eventos dirigidos a otros usuarios
- La ruta de navegación al origen respeta los permisos del usuario: si el usuario no tiene acceso al módulo de origen, la navegación será denegada por ese módulo
Auditoría
- Cada evento de sistema registra el módulo que lo originó y la entidad de referencia
- Cada marcado de lectura registra quién y cuándo marcó el evento como visto
- El historial de eventos de sistema queda disponible para consulta indefinidamente
Rendimiento
- Los procesos que generan eventos de sistema masivos (ej. evaluación diaria de todos los vencimientos de la empresa) deben verificar la idempotencia antes de insertar, para evitar duplicados y carga innecesaria
- La tabla de audiencia de eventos debe soportar consultas eficientes por usuario destinatario, dado que es la consulta más frecuente (cargar la agenda del usuario)
- Los eventos de sistema vistos se consideran "archivados" a efectos de la vista principal; las consultas de la agenda activa los excluyen por defecto
Dependencias
Módulos internos
- Agenda (recurso): Este proceso depende del modelo de eventos definido en Agenda — Gestión de Eventos
- CtaCte: Emite eventos por vencimientos de deudas y cuotas
- CRM: Emite eventos por seguimientos programados e inactividad de clientes
- Membresías: Emite eventos por vencimientos y renovaciones pendientes
- Compras: Emite eventos por vencimientos de facturas de proveedores y órdenes pendientes
- Stock: Emite eventos por alertas de stock mínimo y productos sin movimiento
- Tesorería: Emite eventos por vencimientos de cheques y rendiciones pendientes
Dependencias de datos
- Debe existir la configuración de audiencia predeterminada por tipo de evento de sistema para que los módulos puedan emitir correctamente
- Los grupos y usuarios deben estar configurados para que la resolución de audiencia funcione correctamente
Documentación Técnica Relacionada
Criterios de Aceptación
- [ ] Un módulo del sistema puede emitir un evento automático hacia la agenda de uno o varios usuarios sin intervención del usuario
- [ ] El evento de sistema aparece en la agenda del destinatario con indicador de no visto
- [ ] El evento de sistema incluye el módulo de origen, la referencia a la entidad y la ruta de navegación
- [ ] El usuario puede navegar desde el evento hacia la entidad de origen en el módulo correspondiente
- [ ] El marcado de lectura de un usuario es individual y no afecta a los demás destinatarios
- [ ] El sistema verifica idempotencia: no crea un evento duplicado si ya existe uno activo para la misma entidad y tipo
- [ ] Los eventos de sistema se persisten siempre en la base de datos oficial, sin importar el modo de trabajo del módulo emisor
- [ ] La referencia polimórfica del evento siempre es de nivel sucursal o empresa; nunca de nivel caja
- [ ] El administrador puede configurar la audiencia predeterminada por tipo de evento de sistema
- [ ] Los eventos de sistema marcados como vistos permanecen en el historial de la agenda para consulta futura
Notas Adicionales
- Este documento describe el contrato de emisión que todo módulo debe respetar. Cada módulo implementará sus propias condiciones de detección y su propio proceso de construcción del evento, pero el resultado final debe cumplir con el contrato aquí definido
- La regla de idempotencia (RN-007) aplica por combinación de (módulo, tipo de evento, entidad de referencia). Si el módulo genera dos tipos de evento distintos para la misma entidad, ambos son válidos y no se consideran duplicados
- En futuras versiones se podrá añadir un sistema de notificaciones en tiempo real (badge en el sistema, emails) para los eventos de sistema. La arquitectura de la agenda está diseñada para soportar esta extensión sin cambios estructurales