Documentación del Sistema

Appearance

Agenda — Gestión de Eventos ​

Módulo: general Tipo: Resource Estado: Planificado Fecha: 2026-03-31

Descripción ​

La Agenda es un sistema centralizado de gestión de eventos disponible para todos los usuarios del ERP. Permite organizar, registrar y hacer seguimiento de actividades del negocio: reuniones con clientes, tareas internas, recordatorios y alertas automáticas generadas por otros módulos del sistema.

Valor para el negocio:

  • Centraliza en un único lugar todos los eventos relevantes para el usuario, ya sean creados manualmente o generados automáticamente por módulos como CtaCte, CRM, Membresías, Compras, Stock o Tesorería
  • Mejora el seguimiento de vencimientos, contactos y tareas clave, reduciendo el riesgo de omisión de actividades críticas
  • Permite visibilidad compartida entre usuarios, grupos y sucursales, facilitando la coordinación de equipos
  • Vincula eventos directamente a entidades del sistema (clientes, facturas, membresías, cheques, etc.) para navegación rápida al contexto del evento

Contexto:

  • La agenda es una sección propia del menú principal, accesible desde cualquier módulo
  • Cada usuario tiene su propia agenda personal, pero puede crear y ver eventos compartidos con otros usuarios, grupos o toda la sucursal/empresa según el modelo de visibilidad
  • Los módulos del sistema pueden emitir eventos automáticos hacia la agenda de uno o varios usuarios; estos eventos son solo lectura y se marcan como vistos por cada destinatario individualmente
  • La agenda opera siempre sobre la base de datos oficial del sistema; no se ve afectada por el modo de trabajo prueba/oficial de los módulos transaccionales

Frontend (Perspectiva de Usuario) ​

Vistas ​

  • Vista calendario: Visualización mensual, semanal y diaria de los eventos del usuario. Muestra eventos propios y eventos compartidos visibles según las reglas de audiencia
  • Vista listado: Tabla de eventos filtrable en paralelo al calendario, con columnas de título, tipo, fecha, estado y prioridad
  • Formulario de evento: Pantalla de creación y edición de un evento, con todos sus campos y configuración de audiencia
  • Panel de detalle: Vista de solo lectura de un evento, desde la cual se pueden realizar acciones (editar, eliminar, marcar como visto, navegar al origen)

Interacciones del Usuario ​

  • Crear un evento manual eligiendo tipo (Tarea, Aviso, Reunión), completando los campos requeridos y opcionales
  • Editar un evento existente (solo si el usuario es el creador del evento)
  • Eliminar un evento (solo si el usuario es el creador)
  • Marcar un evento de sistema como visto, haciéndolo desaparecer de la vista activa
  • Definir la audiencia de un evento: personal, usuarios específicos, grupos, sucursal o empresa completa, con posibilidad de combinar múltiples targets
  • Configurar recurrencia en un evento: frecuencia (diaria, semanal, mensual, anual), intervalo y fecha de fin opcional
  • Asignar un color personalizado y etiquetas libres a cualquier evento
  • Adjuntar archivos a un evento
  • Agregar comentarios/notas internas a un evento
  • Navegar al origen de un evento automático (ej. ir a la factura vencida que disparó el aviso)
  • Filtrar la agenda por: tipo de evento, estado, prioridad, etiquetas, rango de fechas, módulo de origen
  • Cambiar la visibilidad de un evento ya creado (solo el creador puede hacerlo)

Estados de UI ​

  • Los eventos se distinguen visualmente por tipo (ícono o forma) y por el color personalizado definido por el usuario
  • Los eventos de prioridad Crítica y Alta tienen resaltado visual diferenciado en el calendario
  • Los eventos de sistema no vistos muestran un indicador visual de pendiente (badge o punto de color)
  • Al marcar un evento de sistema como visto, desaparece de la vista activa pero permanece consultable desde el historial
  • Las tareas completadas permanecen visibles en el calendario con estilo visual de completado (tachado o atenuado)
  • El formulario de reunión muestra automáticamente el campo de hora de fin como requerido
  • Vista vacía cuando no hay eventos en el período visualizado

Backend (Perspectiva de Datos de Negocio) ​

Entidades de Negocio ​

  • Evento: Unidad central de la agenda. Puede ser una tarea, un aviso, una reunión o un evento automático del sistema
  • Audiencia del evento: Conjunto de destinatarios de un evento. Define quién puede ver el evento además del creador. Puede incluir usuarios individuales, grupos, sucursales o toda la empresa
  • Configuración de recurrencia: Parámetros que determinan con qué frecuencia y hasta cuándo se repite un evento
  • Adjunto: Archivo vinculado a un evento
  • Comentario: Nota interna agregada por un usuario sobre un evento
  • Registro de lectura: Marca por usuario que indica que un evento de sistema fue leído/visto

Datos Necesarios ​

Evento:

  • Título (requerido)
  • Tipo: Tarea / Aviso / Reunión / Sistema (requerido)
  • Estado: Pendiente / En progreso / Completado / Cancelado / Visto (requerido)
  • Prioridad: Baja / Media / Alta / Crítica (requerido)
  • Origen: Manual / Sistema (requerido)
  • Fecha y hora de inicio (requerida)
  • ¿Ocupa todo el día? (requerido)
  • Fecha y hora de fin (requerida solo para Reunión)
  • Descripción (texto libre, opcional)
  • Color personalizado en formato hex (opcional)
  • Etiquetas libres (lista de textos, opcional)
  • Contexto de sucursal en que fue creado (para trazabilidad, no afecta la visibilidad)
  • Módulo de origen del sistema (solo para eventos automáticos: ej. ctacte, crm, membresias)
  • Ruta de navegación al origen (solo para eventos automáticos: dirección dentro del sistema para ir a la entidad que generó el evento)
  • Referencia polimórfica a entidad del sistema: schema de la entidad, tipo de entidad y su identificador (todos opcionales, aplican cuando el evento está vinculado a una entidad del ERP)
  • Referencia al evento padre (solo para instancias generadas por recurrencia)
  • Usuario creador (requerido)
  • Fechas de creación y última modificación (auditoría)

Audiencia del evento:

  • Tipo de destinatario: Usuario / Grupo / Sucursal / Empresa
  • Identificador del destinatario (ID de usuario o grupo; vacío para Sucursal y Empresa)
  • Schema de sucursal como filtro adicional (opcional; cuando se usa junto a USUARIO o GRUPO, restringe la audiencia a los miembros de esa sucursal)

Configuración de recurrencia:

  • Frecuencia: Diaria / Semanal / Mensual / Anual
  • Intervalo (cada cuántas unidades se repite; ej. cada 2 semanas)
  • Días de la semana seleccionados (solo para frecuencia Semanal)
  • Fecha de fin de la recurrencia (opcional; si no se define, la serie es indefinida)

Adjunto:

  • Nombre del archivo
  • Ruta o referencia de almacenamiento
  • Tipo de contenido

Comentario:

  • Texto del comentario
  • Usuario que lo escribió
  • Fecha y hora de escritura

Registro de lectura (para eventos de sistema):

  • Evento al que corresponde
  • Usuario que lo leyó
  • Fecha y hora de lectura

Relaciones de Negocio ​

  • Un evento pertenece a un usuario creador
  • Un evento puede tener múltiples entradas de audiencia (targets de visibilidad)
  • Un evento puede tener una configuración de recurrencia
  • Un evento recurrente puede tener múltiples instancias generadas (hijos); cada instancia referencia al evento padre
  • Un evento puede tener múltiples adjuntos
  • Un evento puede tener múltiples comentarios, cada uno de un usuario
  • Un evento de sistema puede tener múltiples registros de lectura, uno por cada usuario destinatario que lo marcó como visto
  • Un evento puede estar vinculado a una entidad del sistema mediante la referencia polimórfica (cliente, proveedor, factura, membresía, cheque, etc.)

Validaciones de Negocio ​

  • El título es obligatorio en todos los tipos de evento
  • Los eventos de tipo Reunión deben tener fecha y hora de fin
  • La fecha de fin debe ser posterior a la fecha de inicio
  • Un evento no puede marcarse como Completado si está en estado Cancelado
  • Solo el usuario creador puede modificar o eliminar un evento de origen Manual
  • Los eventos de origen Sistema no pueden ser editados ni eliminados, solo marcados como vistos
  • La referencia polimórfica, cuando se usa, siempre apunta a una entidad de nivel sucursal o empresa; nunca a nivel caja
  • La visibilidad de un evento solo puede ser modificada por su creador
  • Las instancias de una serie recurrente son independientes entre sí: completar una no afecta a las demás

Reglas de Negocio ​

RN-001: Fecha de fin obligatoria en Reunión

  • Condición: El tipo de evento es Reunión
  • Acción: El campo de fecha y hora de fin es obligatorio. No se puede guardar la reunión sin él

RN-002: Exclusividad de edición por creador

  • Condición: Un usuario intenta editar o eliminar un evento Manual
  • Acción: El sistema verifica que el usuario sea el creador. Si no lo es, la acción es denegada

RN-003: Eventos de sistema son solo lectura

  • Condición: El evento tiene origen Sistema
  • Acción: El usuario no puede editar ni eliminar el evento. La única acción permitida es marcarlo como visto

RN-004: Recurrencia genera instancias independientes

  • Condición: Se activa la recurrencia en un evento al crearlo
  • Acción: El sistema genera las instancias futuras según la configuración. Cada instancia es un evento independiente con referencia al evento padre. Completar o modificar una instancia no afecta a las demás

RN-005: Referencia polimórfica acotada al nivel sucursal o empresa

  • Condición: Un módulo del sistema vincula un evento a una entidad (factura, cheque, membresía, etc.)
  • Acción: El schema de referencia debe ser de nivel sucursal (sucXXXX) o de empresa (public). Nunca se usa el schema de una caja (sucXXXXcajaXXXX) como referencia polimórfica

RN-006: La agenda no respeta el modo prueba

  • Condición: Un usuario trabaja en modo prueba en cualquier módulo transaccional
  • Acción: Los eventos de la agenda siempre se persisten en la base de datos oficial. No existe una "agenda de prueba"

RN-007: Visibilidad compuesta con contexto de sucursal

  • Condición: Se define audiencia de tipo Grupo o Usuario con un schema de sucursal como filtro
  • Acción: El evento es visible únicamente para los miembros del grupo (o el usuario específico) que además pertenecen a la sucursal indicada. La pertenencia a la sucursal se determina por el schema asignado al usuario en el sistema, nivelado hacia arriba al nivel sucursal

RN-008: Visibilidad modificable por el creador en cualquier momento

  • Condición: El creador de un evento quiere cambiar su audiencia
  • Acción: El creador puede ampliar o reducir la audiencia del evento en cualquier momento. Los usuarios que ya no estén en la audiencia dejan de ver el evento

RN-009: Visibilidad de eventos de sistema es configurable por tipo

  • Condición: Un módulo del sistema emite un evento automático
  • Acción: Cada tipo de evento de sistema define su propia configuración de audiencia predeterminada (usuario específico, grupo, sucursal, empresa). El emisor del evento decide quiénes son los destinatarios al momento de crearlo

RN-010: Marcado de lectura individual en eventos de sistema

  • Condición: Un evento de sistema es visible para múltiples usuarios
  • Acción: Cada usuario gestiona su propio estado de lectura de forma independiente. El hecho de que un usuario marque el evento como visto no afecta el estado de los demás destinatarios

Casos de Uso ​

UC-001: Crear un evento de tipo Tarea ​

Actor: Cualquier usuario autenticado

Precondiciones:

  • El usuario está autenticado en el sistema
  • El usuario accede a la sección Agenda

Flujo principal:

  1. El usuario selecciona "Nuevo evento"
  2. El sistema muestra el formulario de creación
  3. El usuario elige tipo "Tarea"
  4. El usuario completa el título, fecha de inicio y prioridad
  5. El usuario define la audiencia: elige "Grupo" y selecciona el grupo deseado; opcionalmente filtra por sucursal
  6. Opcionalmente agrega descripción, color, etiquetas y adjuntos
  7. El usuario guarda el evento
  8. El sistema crea el evento con estado "Pendiente" y lo muestra en el calendario de todos los destinatarios

Flujos alternativos:

  • 4a. El usuario no completa el título → El sistema muestra error de validación y no guarda
  • 5a. El usuario elige visibilidad "Personal" → El evento solo es visible para él mismo
  • 7a. El usuario activa recurrencia → El sistema solicita frecuencia, intervalo y fecha de fin opcional. Al guardar, genera las instancias futuras

Postcondiciones:

  • Evento creado con los datos ingresados
  • Evento visible en la agenda de todos los destinatarios definidos en la audiencia
  • Si tenía recurrencia, las instancias futuras están disponibles en el calendario

UC-002: Marcar un evento de sistema como visto ​

Actor: Usuario destinatario de un evento automático

Precondiciones:

  • El usuario tiene en su agenda un evento de origen Sistema en estado no visto
  • El usuario accede a la sección Agenda

Flujo principal:

  1. El usuario visualiza el evento de sistema en el calendario o listado (aparece con indicador de no visto)
  2. El usuario abre el detalle del evento
  3. El sistema muestra la información del evento, el módulo de origen y el enlace de navegación al origen
  4. El usuario puede hacer clic en el enlace para ir a la entidad que generó el evento (ej. la factura vencida)
  5. El usuario selecciona "Marcar como visto"
  6. El sistema registra la lectura con la fecha y hora actual para ese usuario
  7. El evento desaparece de la vista activa del calendario del usuario (pasa a historial)

Flujos alternativos:

  • 4a. El usuario no navega al origen y marca el evento como visto directamente → El flujo continúa desde el paso 5
  • 7a. El usuario consulta el historial de eventos vistos → El evento aparece con el estado "Visto" y la fecha de lectura

Postcondiciones:

  • El registro de lectura del usuario queda guardado con fecha y hora
  • El evento deja de aparecer en la vista activa del usuario
  • Los demás destinatarios del evento mantienen su propio estado de lectura independiente

UC-003: Crear una Reunión con recurrencia semanal ​

Actor: Cualquier usuario autenticado

Precondiciones:

  • El usuario está autenticado en el sistema

Flujo principal:

  1. El usuario selecciona "Nuevo evento" y elige tipo "Reunión"
  2. El usuario completa título, fecha y hora de inicio, y fecha y hora de fin (obligatorio para Reunión)
  3. El usuario activa la recurrencia, elige frecuencia "Semanal", selecciona los días de la semana y define una fecha de fin de la serie (opcional)
  4. El usuario define la audiencia: selecciona usuarios específicos como destinatarios
  5. El usuario guarda el evento
  6. El sistema crea el evento padre y genera todas las instancias futuras según la recurrencia definida

Flujos alternativos:

  • 2a. El usuario no completa la fecha de fin → El sistema muestra error indicando que es obligatoria para Reuniones
  • 3a. El usuario no define fecha de fin de la serie → Las instancias se generan indefinidamente

Postcondiciones:

  • Evento padre creado con la configuración de recurrencia
  • Instancias futuras generadas y visibles en el calendario de todos los destinatarios
  • Cada instancia es independiente y puede ser completada o cancelada de forma individual

UC-004: Gestionar la visibilidad de un evento existente ​

Actor: Creador del evento

Precondiciones:

  • El usuario es el creador del evento
  • El evento es de origen Manual

Flujo principal:

  1. El usuario abre el detalle del evento desde el calendario
  2. El usuario selecciona "Editar"
  3. El sistema muestra el formulario con los datos actuales, incluyendo la audiencia configurada
  4. El usuario modifica la audiencia: agrega un nuevo grupo o sucursal, o elimina destinatarios existentes
  5. El usuario guarda los cambios
  6. El sistema actualiza la audiencia del evento

Flujos alternativos:

  • 4a. El usuario reduce la audiencia eliminando un grupo → Los miembros de ese grupo dejan de ver el evento en su agenda
  • 4b. El usuario cambia a visibilidad "Personal" → Solo el creador puede ver el evento a partir de ese momento

Postcondiciones:

  • La audiencia del evento queda actualizada
  • Los usuarios que se agregaron pueden ver el evento en su agenda
  • Los usuarios que se removieron dejan de ver el evento

UC-005: Vincular un evento a una entidad del sistema ​

Actor: Cualquier usuario autenticado

Precondiciones:

  • El usuario está creando o editando un evento Manual
  • Existe una entidad en el sistema a la que vincular el evento (cliente, proveedor, membresía, etc.)

Flujo principal:

  1. En el formulario del evento, el usuario elige vincular el evento a una entidad
  2. El usuario selecciona el tipo de entidad (Cliente, Proveedor, Membresía, etc.)
  3. El sistema muestra un buscador de la entidad seleccionada
  4. El usuario busca y selecciona la entidad específica
  5. El sistema guarda la referencia al tipo, identificador y sucursal de la entidad
  6. El evento muestra en su detalle el vínculo a la entidad, con posibilidad de navegar a ella

Postcondiciones:

  • El evento queda vinculado a la entidad del sistema seleccionada
  • Desde el detalle del evento se puede navegar directamente a esa entidad

Consideraciones ​

Seguridad ​

  • Solo los usuarios autenticados pueden acceder a la agenda
  • Un usuario solo puede ver eventos en los que figure como destinatario según las reglas de audiencia, o de los que sea el creador
  • Las acciones de edición y eliminación están restringidas al creador del evento; el sistema verifica esta condición antes de ejecutar cualquier modificación
  • Los eventos de sistema son protegidos contra modificación por cualquier usuario; solo se admite el marcado de lectura
  • La audiencia con filtro de sucursal garantiza que un usuario de una sucursal diferente no vea eventos dirigidos a otra sucursal, salvo que tenga visibilidad de Empresa

Auditoría ​

  • Creación de eventos: quién creó, cuándo, desde qué contexto (sucursal)
  • Modificación de eventos: qué cambió, quién lo modificó y cuándo
  • Eliminación de eventos: quién eliminó y cuándo (el evento se marca como eliminado, no se borra físicamente)
  • Marcado de lectura en eventos de sistema: quién, cuándo

Rendimiento ​

  • Se espera un volumen moderado de eventos por empresa: decenas a cientos de eventos activos por usuario
  • Los módulos transaccionales pueden generar eventos automáticos masivos (ej. vencimientos masivos de CtaCte), por lo que la tabla de audiencia debe estar bien indexada para consultas por usuario
  • Los eventos de sistema vistos se archivan para no afectar la performance de la vista activa
  • Las búsquedas más frecuentes son por rango de fechas y por usuario destinatario

Dependencias ​

Módulos internos ​

  • Usuarios y Grupos (public): La agenda depende del sistema de usuarios y grupos para resolver la audiencia de cada evento. Los grupos (grupos, rel_grupos_usuarios) ya están disponibles en el schema de empresa
  • CtaCte: Fuente de eventos automáticos por vencimientos de deudas o cuotas de clientes
  • CRM: Fuente de eventos automáticos por seguimientos, llamadas o visitas programadas
  • Membresías: Fuente de eventos automáticos por vencimientos y renovaciones de membresías
  • Compras: Fuente de eventos automáticos por vencimientos de facturas de proveedores
  • Stock: Fuente de eventos automáticos por alertas de stock mínimo
  • Tesorería: Fuente de eventos automáticos por vencimientos de cheques y rendiciones pendientes

Dependencias de datos ​

  • Debe existir al menos un usuario creador para poder crear eventos
  • Los grupos deben estar configurados para utilizar visibilidad por grupo
  • Para vincular eventos a entidades, las entidades (clientes, facturas, membresías, etc.) deben existir en el sistema

Documentación Técnica Relacionada ​

Criterios de Aceptación ​

  • [ ] Un usuario puede crear un evento de cualquier tipo (Tarea, Aviso, Reunión) con los campos requeridos
  • [ ] El sistema exige fecha de fin al crear una Reunión
  • [ ] Un usuario puede definir una audiencia compuesta combinando múltiples targets (usuarios, grupos, sucursales) con o sin filtro de sucursal
  • [ ] Solo el creador puede editar o eliminar un evento de origen Manual
  • [ ] Los eventos de sistema aparecen en la agenda del usuario destinatario como solo lectura
  • [ ] El usuario puede marcar un evento de sistema como visto; el marcado es individual y no afecta a otros destinatarios
  • [ ] Un evento con recurrencia genera instancias futuras visibles en el calendario; completar una instancia no afecta a las demás
  • [ ] Un evento puede vincularse a una entidad del sistema mediante referencia polimórfica; el usuario puede navegar a esa entidad desde el detalle del evento
  • [ ] El usuario puede asignar color, etiquetas, adjuntos y comentarios a cualquier evento
  • [ ] La agenda muestra una vista de calendario (mes/semana/día) y una vista de listado filtrable
  • [ ] Los eventos de la agenda no se ven afectados por el modo prueba/oficial de los módulos transaccionales
  • [ ] El creador puede modificar la audiencia de un evento en cualquier momento; los cambios se reflejan inmediatamente para los destinatarios afectados

Notas Adicionales ​

  • Las notificaciones (alertas en tiempo real, emails) no están contempladas en esta versión. Pueden incorporarse en una iteración futura
  • La ubicación física o URL de videoconferencia para reuniones no está contemplada en esta versión
  • El sistema de visibilidad por sucursal se basa en el schema asignado a cada usuario en la base de datos central (ini), nivelado al nivel sucursal. Si un usuario tiene asignado suc0001caja001, el sistema lo considera perteneciente a suc0001 para efectos de visibilidad
  • En empresas sin sucursales (todos los usuarios en public), la visibilidad "Sucursal" equivale a la visibilidad "Empresa"
  • Los eventos automáticos del sistema emiten su propia configuración de audiencia al momento de crearse; ver Proceso de emisión de eventos automáticos