Resumen del Pedido
Fecha Pedido | 28/04/2021 |
---|---|
Fecha Documento | 29/04/2021 |
Estado del Documento | EN PROCESO... |
Autor | Orlando Ojeda |
Version | 1.0 |
Descripcion | Mejoras para Disponibilizar informacion de TC y como cuenta origen Poder configurar y cobrar un porcentaje de Comision por las Transferencias de TP Dimo hacia las Billeteras |
Información del Proyecto
Proyecto | Mejoras para Disponibilizar informacion de TC y como cuenta origen |
---|---|
Dueño del Producto | Juan Almada |
Prioridad | URGENTE |
Administrador del Proyecto | Hugo Diaz |
Arquitecto | Orlando Ojeda |
Resumen Técnico
Se solicita modificar la forma en la que exponemos los datos de las Tarjetas de Crédito dentro de DIMO, incorporando un proceso de "vinculacion" de tarjetas habilitadas.
La idea es replicar un concepto similar a las preguntas de seguridad de las cooperativas, pero haciendo preguntas relacionadas a la tarjeta que el usuario desea habiltar dentro de DIMO.
Definiciones Principales:
- Ofuscar los datos de todas las tarjetas de Crédito del Usuario que se muestran en DIMO que no hayan sido vinculadas
- Esta definicion se aplica para TODOS los usuarios en DIMO, incluyendo a los usuarios provinientes de MiCabal quienes dejarán de tener una consideracion especial en el sistema, que les permite acceder a la TC sin haber completado su registro.
- La informacion del numero de tarjeta,disponible etc. se mostrará oculta. Ej: Tarjeta: **** **** **** ****
- Cuando el usuario intente acceder a su tarjeta se le solicitarán preguntas de seguridad relacionadas a la tarjeta seleccionada:
- Ult. 4 digitos de la tarjeta seleccionada (Nuevo) Obs: Para conocer que tarjeta esta seleccionando el usuario y no asumiendola, obligando tambien a que el usuario provea un dato mas de la TC
CVV
PIN
Fecha de vencimiento de plástico.
- Al responder las preguntas de seguridad, en caso de exito, se debe marcar la tarjeta como vinculada.
- Cuando el usuario quiere acceder a su tarjeta de crédito se le deben de realizar
Desarrollo:
Luego del relevamiento realizado y tras un analisis rapido, se pudo identificar de que sera necesario de modificar los programas en al menos los siguientes puntos:
Adaptaciones en el Frontend de DIMO, para consultar los parametros de comision por transferencias a Billeteras y pueda aplicar el cargo a la transacción..
Factibilidad
Soluciones Evaluadas | Descripción | ¿Aceptada? (Si/No) |
---|---|---|
| Cuando desde DIMO un usuario intenta realizar una transferencia a una Billetera por una Boca de Cobranza (PAGO) se realizará consulta para preguntar si se debe o no cobrar un cargo de comision para el tipo de Transaccion, el participante de Boca de Cobranza y la billetera seleccionada | - |
Impacto sobre Plataformas
Plataformas TI
Soluciones Evaluadas | Plataforma | Descripción |
---|---|---|
Solución 1 | Motor de Pagos | Configuración en el motor de Pagos de un nuevo atributo que permita configurar por cada billetera un tipoCuentaDestino "Wallet". Este parametro será utilizado posteriormente por el Frontend para preguntar si debe o no cobrar una comision y setear la transaccion hacia el sicoop. |
Motor de Cargos | Configuración en el Motor de Cargos los parametros que permitan definir el porcentaje de comision a cobrar a el usuario por las transferencias hacia billeteras | |
Frontend de Dimo |
| |
Visión Preliminar de Componentes de Plataformas Afectadas (Alto Nivel)
[ Imagen ]
Presupuestos
Recursos
Área/Función | Cantidad | Tipo de Asignación | Comentarios |
---|---|---|---|
Arquitecto de Proyecto | 1 | Full | |
Desarrollador Frontend | 1 | Semi-Full | Desarrollo de las adaptaciones para consultar los parametros de comision por transferencias a Billeteras y pueda aplicar el cargo a la transacción. |
Desarrollador Genexus | - | - | - |
Desarrollador JAVA | 1 | Semi-Full | - |
Desarrollador CEIBO | 1 | Semi-Full | - |
Analista CEIBO | 1 | On Demand | De darse algun problema en la aplicacion del Cargo, durante o posteriormente a el momento de la transaccion. |
Infraestructura | 2 | On Demand |
|
Tester | 1 | On Demand | Durante las pruebas funcionales de la solucion. |
Total | 6 | 1 (FULL) / 5 (On Demand) |
Tiempos Estimativos
Nº | Tarea | Tiempo Estimado | Obs |
---|---|---|---|
1 | Analisis | 6 hs | Realizado |
2 | Desarrollo | 16 hs | - |
3 | MOPP | 1 hs | - |
4 | Pruebas | 8 hs | - |
Total horas | 31 hs | - |
Deberá considerarse aparte recursos adicionales de OPERACIONES para apoyo durante la fase
de pruebas, en caso de que sea necesario..
Riesgos
Nº | Riesgo | Descripción | Observaciones |
---|---|---|---|
1 | Procedimiento Almacenado para aplicacion de Cargos | Verificacion de existencia del procedure creditopy.pkg_sicoop_trxs.sp_altaajustecargo , en OLPY Produccion. Pues este procedimiento es utilizado para el registro de cargos transaccionales | Se ha realizado la verificacion correspondiente solicitando al DBA el PCK de producción. Se ha encontrado en produccion el mismo y con los mismo parametros de entrada y salida. |
2 | Procesamiento correcto de la aplicacion de cargos bajo el concepto de la comision. | Como ha pasado bastante tiempo desde la ultima vez que se hizo una prueba de cargos transaccionales desde DIMO, desde el departamento de sistemas nos surge la duda de si podrian haber problemas al momento en que se da de alta la transaccion o se realiza un proceso de cierre o relacionados | - |