Información del Proyecto
Proyecto | Motor de Limites Transaccionales | Prioridad | ALTA |
---|---|---|---|
Dueño del Producto | Juan Almada | Administrador del Proyecto | Hugo 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) |
---|---|---|
| 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:
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 |
| Solución 1 |
Autorizador CABAL |
| Solución 1 |
Backend DIMO |
| Solución 1 |
Frontend DIMO |
| Solución 1 |
Backend Corresponsalía |
| Solución 1 |
Frontend Corresponsalía |
| Solución 1 |
Motor de Transacciones Bancarias |
| Solución 1 |
Motor de Transacciones Redes de Cobranzas |
| 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 Genexus | 2 | Full/On Demand |
|
Desarrollador JAVA | 1 | On Demand |
|
Desarrollador REACT | 2 | On Demand |
|
Desarrollador CEIBO | 1 | On Demand |
|
Desarrollador PL/SQL | 1 | Full |
|
Infraestructura | 2 | On Demand |
|
Tester | 1 | On Demand | Durante las pruebas funcionales de la solucion. |
Total | 6 | 2 (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
Desarrollo | Pruebas | Despliegue |
---|---|---|
-d | -d | -d |
Riesgos
Riesgo | Descripción |
---|---|
Disponibilidad de los recursos para el desarrollo de la Solución | Podria haber variaciones en los plazos de entrega debido a que se contaria con desarrollo externo. |