Beneficios

Se inicia cuando: un funcionario de FEMORF registra un beneficio —un auxilio o un convenio con un proveedor— a nombre de una persona beneficiaria.

Termina cuando: el responsable registra su decisión: el auxilio queda decidido pero sin ningún movimiento de dinero, y el convenio vuelve a quedar pendiente porque hoy la decisión no alcanza a guardarse.

Participan: Funcionario de FEMORF, responsable de aprobación, asociado beneficiario y acciones automáticas.

Así funciona hoyFlujo ideal

Formularios: Beneficios, Registro de beneficio y Aprobación de beneficio.

flowchart LR
  subgraph funcionario["Funcionario de FEMORF"]
    F1["Consulta y filtra los beneficios"]
    F2["Elige a la persona beneficiaria"]
    F3["Registra el servicio, el valor y el número de cuotas"]
  end
  subgraph responsable["Responsable de aprobación"]
    A1["Revisa la solicitud pendiente"]
    A2{"¿Aprueba el beneficio?"}
    A3["Registra la decisión y su fecha"]
  end
  subgraph automaticas["Acciones automáticas"]
    S1["Guarda la solicitud como solicitada y reparte el valor en cuotas pendientes"]
    S2["Guarda la decisión e informa 'aprobado correctamente' en los dos casos"]
    D1{"¿Es un auxilio o un convenio?"}
    S3["No aplica ningún efecto financiero"]
    S4["Aplica los mismos efectos financieros se haya aprobado o rechazado"]
    D2{"¿Está parametrizada la cuenta de contrapartida?"}
    S5["Crea la cuenta por cobrar por el valor total y su registro contable"]
    S6["El cobro posterior nunca marca las cuotas como pagadas"]
  end
  B1["Bloquea el retiro parcial de aportes y el retiro voluntario<br/>[H-CAR-BEN-05]"]:::risk
  R1["Auxilio con la decisión y su fecha registradas"]:::success
  R2["El dinero del auxilio no se mueve por el sistema<br/>[H-CAR-BEN-03]"]:::risk
  R3["La decisión se descarta y el convenio sigue pendiente<br/>[H-CAR-BEN-02]"]:::risk
  R4["Deuda registrada al asociado aunque lo hayan rechazado<br/>[H-CAR-BEN-01]"]:::risk
  R5["Saldo congelado y bloqueo de retiros indefinido<br/>[H-CAR-BEN-04]"]:::risk

  F1 --> F2 --> F3 --> S1 --> B1
  S1 --> A1 --> A2
  A2 -- "No, rechaza" --> A3
  A2 -- "Sí, aprueba" --> A3
  A3 --> S2 --> D1
  D1 -- "Auxilio" --> S3 --> R1 --> R2
  D1 -- "Convenio" --> S4 --> D2
  D2 -- "No, hoy no lo está" --> R3
  D2 -- "Sí" --> S5 --> R4 --> S6 --> R5

  classDef risk fill:#fee2e2,stroke:#b91c1c,color:#7f1d1d;
  classDef success fill:#dcfce7,stroke:#15803d,color:#14532d;
  style funcionario fill:#eff6ff,stroke:#2563eb
  style responsable fill:#eff6ff,stroke:#2563eb
  style automaticas fill:#f5f3ff,stroke:#7c3aed

Esta es una propuesta por validar con FEMORF; aún no está implementada.

Formularios actuales relacionados: Beneficios, Registro de beneficio y Aprobación de beneficio.

flowchart LR
  subgraph asociado["Asociado"]
    P1["Inicia la solicitud"]
  end
  subgraph funcionario["Funcionario de FEMORF"]
    F0["Inicia la solicitud por el asociado"]
  end
  subgraph responsable["Responsable de aprobación"]
    F1["Revisa la solicitud y registra la decisión con su motivo"]
  end
  subgraph automaticas["Acciones automáticas"]
    S1["Valida elegibilidad, cupo y soportes"]
    S2["Envía la solicitud a la bandeja"]
    S3["Notifica el rechazo"]
    S4["Aplica el beneficio y el registro financiero con una regla de signos unificada"]
    S6["Envía la confirmación al asociado"]
  end
  D0{"¿Quién inicia la solicitud?"}
  D1{"¿Cumple los requisitos?"}
  D2{"¿Aprueba el beneficio?"}
  C1["Completa los datos y adjunta los soportes"]:::support
  C2["Corrige los requisitos observados"]:::support
  R1["Solicitud devuelta para corrección"]:::risk
  R2["Beneficio rechazado con motivo y sin efectos financieros"]:::risk
  R3["Beneficio aprobado y confirmado"]:::success
  U1["Supuesto por validar con FEMORF: iniciador y reglas de elegibilidad"]:::assumption

  D0 -- "Asociado" --> P1 --> C1
  D0 -- "Funcionario" --> F0 --> C1
  C1 --> S1 --> D1
  D1 -- "No" --> R1 --> C2 --> S1
  D1 -- "Sí" --> S2 --> F1 --> D2
  D2 -- "No" --> S3 --> R2
  D2 -- "Sí" --> S4 --> S6 --> R3
  D0 -.-> U1
  S1 -.-> U1

  classDef risk fill:#fee2e2,stroke:#b91c1c,color:#7f1d1d;
  classDef support fill:#f3f4f6,stroke:#6b7280,color:#374151;
  classDef success fill:#dcfce7,stroke:#15803d,color:#14532d;
  classDef assumption fill:#f3f4f6,stroke:#6b7280,color:#374151,stroke-dasharray:5 5;
  style asociado fill:#fffbeb,stroke:#d97706
  style funcionario fill:#eff6ff,stroke:#2563eb
  style responsable fill:#eff6ff,stroke:#2563eb
  style automaticas fill:#f5f3ff,stroke:#7c3aed

Pantallas del proceso

Listado de beneficios solicitados con su estado.

Ventana de registro de un beneficio para el asociado.

Reglas del proceso

El beneficio lo registra siempre un funcionario desde la pantalla de beneficios; el asociado no tiene ninguna forma de solicitarlo por su cuenta.
El registro identifica a la persona beneficiaria, el servicio del proveedor, la descripción, el valor total y el número de cuotas; la fecha de finalización se calcula sola.
La lista de personas ofrece a cualquier tercero activo: no se exige que sea un asociado activo del fondo.
El sistema no exige ningún soporte documental; la pantalla de aprobación muestra un botón de documento de respaldo que no está conectado a nada.
Al guardar, la solicitud queda en estado solicitada y su valor se reparte entre las cuotas indicadas, todas pendientes de pago; la última cuota absorbe la diferencia de redondeo.
Desde ese mismo momento, y antes de cualquier decisión, un convenio ya bloquea el retiro parcial de aportes y el retiro voluntario del asociado.
Un mismo beneficio no se puede volver a solicitar hasta que transcurra el tiempo de espera parametrizado, contado desde la fecha en que se registró el anterior; el estado del anterior es indiferente, uno rechazado también bloquea.
Los topes parametrizados de monto máximo, interés, permanencia mínima y número de cuotas no se validan en ninguna parte: se puede registrar cualquier monto y cualquier número de cuotas.
Una solicitud permanece pendiente hasta que el responsable registra una decisión, aprobada o rechazada; no existe forma de corregirla, reversarla, anularla ni darla por terminada.
Al registrar la decisión, el sistema aplica los mismos efectos financieros tanto si el beneficio se aprueba como si se rechaza, y el mensaje de confirmación dice siempre que fue aprobado.
Un auxilio aprobado no genera cuenta por pagar, ni registro contable, ni orden de desembolso: sólo quedan la decisión y su fecha.
Un convenio genera una cuenta por cobrar al asociado por el valor total y su registro contable; hoy esa operación se interrumpe siempre porque la cuenta de contrapartida no está parametrizada, y la decisión registrada se descarta.
El cobro de las cuotas sólo ocurre desde el anticipo de vacaciones, y ese cobro nunca marca las cuotas como pagadas.
El sistema no verifica permisos al registrar ni al aprobar un beneficio: basta con tener la sesión iniciada.
No se genera ningún documento, correo ni notificación en todo el proceso, y no queda registro de quién cambió cada dato del beneficio.
El registro financiero de los convenios usa una regla de signo distinta de la utilizada para el abono a crédito.

Diferencias y hallazgos

H-CAR-BEN-01 — Rechazar un beneficio produce los mismos efectos que aprobarlo

Al registrar la decisión, el sistema guarda lo que el responsable eligió pero nunca lo evalúa: continúa igual hacia la aplicación de los efectos financieros. En un convenio, rechazar crea la misma cuenta por cobrar al asociado por el valor total y el mismo registro contable que aprobarlo, y el mensaje que ve el usuario dice "aprobado correctamente" incluso cuando rechazó. En los auxilios la diferencia no se nota porque no se aplica ningún efecto en ninguno de los dos casos.

H-CAR-BEN-02 — Hoy ningún convenio se puede aprobar ni rechazar

La contrapartida contable del convenio se busca contra un concepto de caja general que no está parametrizado en el módulo de cartera, así que la operación se interrumpe siempre con un mensaje de error. Como todo se deshace, la decisión registrada se descarta y el convenio vuelve a quedar pendiente: no hay forma de cerrarlo desde la pantalla. Además, el mensaje de error nombra el concepto equivocado, lo que desvía el diagnóstico. No se pudo verificar si en el ambiente productivo esa cuenta sí está parametrizada; si lo estuviera, el proceso avanzaría y se materializaría H-CAR-BEN-01.

H-CAR-BEN-03 — Aprobar un auxilio no mueve dinero por el sistema

Aprobar un auxilio sólo guarda la decisión y su fecha: no genera cuenta por pagar al asociado, ni registro contable, ni orden de desembolso. Afecta a cuatro de los cinco beneficios parametrizados hoy (lentes y monturas, calamidad doméstica, funerario y educativo universitario). Si el auxilio se paga, es un trámite manual sin traza en el sistema.

H-CAR-BEN-04 — Las cuotas de un convenio nunca se marcan como pagadas

El único cobro existente, el descuento en el anticipo de vacaciones, rebaja el saldo de la cuenta por cobrar pero nunca marca la cuota como pagada. El estado de cuenta del asociado sigue mostrando cero cuotas pagadas y el saldo original completo aunque ya haya pagado todo, y los bloqueos de retiro que dependen de esas cuotas quedan activos de forma indefinida.

H-CAR-BEN-05 — Una solicitud sin aprobar, o rechazada, ya bloquea los retiros del asociado

El bloqueo del retiro parcial de aportes y del retiro voluntario se activa con sólo registrar un convenio, sin exigir que esté aprobado. Basta con dejar una solicitud registrada —o incluso rechazada— para que el asociado quede bloqueado. La validación de elegibilidad de retiro, en cambio, sí exige que el beneficio esté aprobado, de modo que los tres controles del sistema son inconsistentes entre sí.

H-03 — El pago de crédito y los beneficios aplican reglas de signo diferentes

El abono a crédito y los beneficios no usan el mismo criterio de signo sobre los saldos financieros. El flujo ideal propone una regla unificada antes de confirmar los efectos del beneficio.

El flujo ideal también agrega validaciones previas de elegibilidad, cupo y soportes, una bandeja de decisión con motivo, un rechazo que no aplica efectos financieros y una confirmación para el asociado.

Supuestos por validar con FEMORF

A-CAR-BEN-01: Supuesto por validar con FEMORF: debe confirmarse quién puede iniciar un beneficio y cuáles son sus reglas de elegibilidad.
A-CAR-BEN-02: Supuesto por validar con FEMORF: debe confirmarse si el pago de los auxilios se tramita hoy por fuera del sistema o si es funcionalidad pendiente de construir.
A-CAR-BEN-03: Supuesto por validar con FEMORF: debe confirmarse qué debe ocurrir con un beneficio rechazado y si el proceso necesita anulación y cierre del beneficio cuando el saldo llega a cero.