Page tree
Skip to end of metadata
Go to start of metadata
Fecha27/04/2021
Estado del Documento

BORRADOR

Autor
Version1.0

Información del Proyecto

ProyectoMotor de Limites TransaccionalesPrioridad

ALTA

Dueño del ProductoJuan AlmadaAdministrador del ProyectoHugo Diaz

Resumen Técnico

Se pretende crear un motor que administre todos los limites y perfiles transaccionales que puedan tener los usuarios de CABAL, es decir a los usuarios de Tarjetas de Credito, Tarjetas Prepagas DIMO y usuarios de la App Dimo.

A este Motor se deberán conectar todas las plataformas transaccionales, para poder registrar y validar las transacciones antes de procesarlas.

Durante el análisis de factibilidad se observo que se tendrán cambios en todos los flujos transaccionales ya establecidos.

Problemas Detectados

En Fecha 15/06/2021, se detecto en el ambiente de Testing un problema o bug en las validaciones de los acumuladores de los Limites Transaccionales.

Detalles del BUG:

  • El problema se da al obtener los montos acumulados de Transferencias del Usuario. (Para posteriormente validar si supera o no el limite diario, mensual, etc.)
  • La razón del problema es que el sistema va limpiando y desactivando los acumuladores de los días anteriores del mismo mes, para dar lugar al nuevo acumulador que tiene los importes acumulados del día + el de los días anteriores, desactivando el día anterior

    Ejemplo: Dia 16 = Dia 15 + Importe... Dia 15: Dia 14 + Importe, ...., etc. )
  • Cuando ESTAS en un MES SIGUIENTE, ya no puede limpiar los acumuladores anteriores (ya que solo limpia los del mes actual)
  • Al obtener los acumuladores vigentes, que "técnicamente" debería traer solo UNO, trae en su lugar el del registro del mes anterior y el del mes actual, que acabo de dar de alta.

  • Esto ocasiona el error "com.tesabiz.utils.jpa.DaoTooManyRowsException"
  • El problema según lo relevado inicialmente se origina en la clase java del Backend de DIMO DPerfilLimiteTransaccionalClienteImp en el método superoLimites(...) y se podría resolver cambiando el método que se consulta desde aquí de dClienteLimiteTransaccionalAcumuladorSpec.getAcumuladorCliente(...) a dClienteLimiteTransaccionalAcumuladorSpec.getAcumuladorClienteActivo(...)

Observaciones:

  • En PRE no esta pasando por que esta desactivado el control del limites de transferencias y acumuladores

  • En PRO, nunca se ha utilizado esta funcionalidad del sistema
  • El parámetro para habilitar o no el uso de los limites transaccionales se configura en los dominios del sistema (T_DOMAIN, se tiene matenedor) y se puede verificar con la siguiente consulta:

    SELECT TD.DOM_VALUE,  -- S/N
           TD.DESCRIPTION,
           TD.ROWID
    FROM T_DOMAIN TD
    WHERE TD.DOMAIN_TBZ = 'CONSTANTES_DIMO'
    AND   TD.DOM_NAME = 'USAR_PERFIL_LIMITE_TRANSACCIONAL_POR_DEFECTO'
    ;


Factibilidad

Soluciones

Evaluadas

Descripción 

¿Aceptada?

(Si/No)

  1. Motor de Limites Transaccionales

Cuando cualquier plataforma de CABAL, quiera realizar una transacción de PAGO, ADELANTO, COMPRAS, TRANSFERENCIAS, etc, esta plataforma deberá conectarse motor de limites transaccionales.

Dentro de este motor se deberán realizar las configuraciones sobre los perfiles transaccionales de cada plataforma, y en cada plataforma se deberá tener un registro de los perfiles de cada usuario.

En este motor también se deberán poder parametrizar los limites transaccionales por participante.

En este Motor se podrá configurar por:

  1. Plataforma
  2. Perfil de Usuario
  3. Canal
  4. Transacción
    1. Tipo Transacción
    2. Código de Servicio
    3. Tipo Cuenta Origen
    4. Tipo Cuenta Destino
  5. Controlar por
    1. Cantidad
    2. Monto
  6. Limites
    1. Diarios
    2. Quincenales
    3. Mensuales
  7. Acciones a Tomar
    1. Alertas
      1. Visualización en por Pantalla
    2. Bloqueo Preventivo de Transacciones
      1. Bloquear por tiempo
      2. Bloquear y agendar llamada desde CALLCENTER
    3. Rechazo de transaccion

El motor deberá registrar todas las transacciones realizadas por el usuario y en base a eso ejecutar las reglas de control según su perfil de usuario y en base a eso realizar alguna de las acciones indicadas en las configuraciones. 

El Motor deberá tener una opción de excepciones, en donde se podrá configurar los usuarios a los cuales no se les realizara ningún tipo de validación de los perfiles.

Si

Impacto sobre Plataformas

Plataformas TI

Plataforma

Descripción 

Soluciones

Evaluadas

Motor de Limites Transaccionales

  1. Crear programas de:
    1. Validación de Transacción
      1. Crear de reglas de validación.
      2. Validar la transacción según las reglas.
      3. Registrar el movimiento de la transacción.
    2. Registro de movimientos.
    3. Ejecución de Acciones
  2. Crear Mantenedores de:
    1. Plataforma
    2. Perfil de Usuario
    3. Transacción
    4. Limites
    5. Acciones
    6. Reglas
Solución 1
Autorizador CABAL
  1. Incluir en las Reglas de Autorización la llamada al servicio de Validación de Transacción.
Solución 1
Backend DIMO
  1. Llamar a servicio de Validación de Transacción.
Solución 1
Frontend DIMO
  1. Mostrar Mensaje al usuario.
    1. Transacción rechazada por superar el limite
      1. Diario
      2. Quincenal
      3. Mensual
    2. Bloqueo de transacciones por tiempo determinado
Solución 1
Backend Corresponsalía
  1. Llamar a servicio de Validación de Transacción.
Solución 1
Frontend Corresponsalía
  1. Mostrar Mensaje al usuario.
    1. Transacción rechazada por superar el limite
      1. Diario
      2. Quincenal
      3. Mensual
    2. Bloqueo de transacciones por tiempo determinado
Solución 1
Motor de Transacciones Bancarias
  1. Llamar a servicio de Validación de Transacción.
Solución 1
Motor de Transacciones Redes de Cobranzas
  1. Llamar a servicio de Validación de Transacción.
Solución 1

Visión Preliminar de Componentes de Plataformas Afectadas (Alto Nivel)

Flujo de Procesos para envío de Notificaciones SMS

En el Proceso de Ejecutar Acción de la Regla, solo si la acción es de rechazo de la transacción no se registrara el movimiento.

Recursos

Área/Función

Cantidad

Tipo de Asignación

Comentarios
Arquitecto de Proyecto

1

On Demand
Desarrollador Genexus2Full/On Demand
  1. Crear Mantenedores de:
    1. Plataforma
    2. Perfil de Usuario
    3. Transacción
    4. Limites
    5. Acciones
    6. Reglas
  2. Motor de Redes de Cobranzas
    1. Llamar a servicio de Validación de Transacción.
  3. Motor de Transacciones Bancarias
    1. Llamar a servicio de Validación de Transacción.
Desarrollador JAVA1On Demand
  1. Backend DIMO
    1. Llamar a servicio de Validación de Transacción.
  2. Backend CORRESPONSALIA
    1. Llamar a servicio de Validación de Transacción.
Desarrollador REACT2On Demand
  1. Frontend DIMO
  2. Frontend CORRESPONSALIA
Desarrollador CEIBO1On Demand
  1. Incluir en las Reglas de Autorización la llamada al servicio de Validación de Transacción.
Desarrollador PL/SQL1Full
  1. Crear programas de:
    1. Validación de Transacción
      1. Crear de reglas de validación.
      2. Validar la transacción según las reglas.
      3. Registrar el movimiento de la transacción.
    2. Registro de movimientos.
    3. Ejecución de Acciones
Infraestructura2On Demand
  1. DBA
  2. Administrador de Servidores
Tester1On DemandDurante las pruebas funcionales de la solucion.
Total62 (FULL) / 9 (On Demand)
Deberá considerarse aparte recursos adicionales de OPERACIONES para apoyo durante la fase
de pruebas, en caso de que sea necesario..

Tiempos Estimativos

DesarrolloPruebasDespliegue
-d-d-d

Riesgos

RiesgoDescripción
Disponibilidad de los recursos para el desarrollo de la SoluciónPodria haber variaciones en los plazos de entrega debido a que se contaria con desarrollo externo.