Dea Rq-1092 Sef Defensa

Documento de Especificación de Alcance
RQ-1092 Súper Efectivo Defensa

Gerencia de Tecnología
Req: RQ-1092 SEF Defensa (RSAT a T24)
Documento de Especificación
Doc.: Ver. V. 1.0
y Alcance
Contenido
1 Información General.............................................................................................3
1.1. Datos Generales................................................................................................................3
1.2. Participantes.....................................................................................................................3
2 Visión...................................................................................................................4
2.1. Propósito del Proyecto........................................................................................................4
2.2. Antecedentes....................................................................................................................4
3 Alcances y Restricciones.......................................................................................5
3.1. Alcance Organizacional.......................................................................................................5
3.2. Resumen de Alcance..........................................................................................................5
3.3. Restricciones y/o Limitantes................................................................................................6
4 Situación Actual....................................................................................................6
4.1. Diagramas de Procesos Actual.............................................................................................7
5 Situación Futura...................................................................................................8
5.1. Limitaciones de la propuesta Automatización Reenganche SEF.................................................9
5.2. Proceso de Reenganche Onboarding de SEF..........................................................................9
5.3. Bandejas de usuarios de agencia, call y créditos..................................................................28
5.4. Creación de Usuarios........................................................................................................29
5.5. Perfiles de acceso a OB.....................................................................................................29
5.6. Pagos en T24..................................................................................................................30
5.7. Reportes de SEF Reenganche............................................................................................30
5.8. Consultas de SEF Reenganchados......................................................................................34
5.9. Diagramas de Proceso Esperado..........................................................................................1
5.8.1 Diagrama de SEF Reenganche en Red Agencias.....................................................................1
5.8.2 Diagrama de SEF Reenganche en Call Center........................................................................2
5.10. Requerimientos Funcionales................................................................................................1
5.11. Requerimientos No Funcionales...........................................................................................2
5.12. Funcionalidad Excluida.......................................................................................................3
6 Especificación de la Solución.................................................................................3
6.1. Listado de Actores.............................................................................................................3
6.2. Diagrama de Actores..........................................................................................................3
6.3. Listado de Casos de Uso de Negocio.....................................................................................4
6.4. Diagrama de la Solución.....................................................................................................4
6.5. Listado de Reportes...........................................................................................................4
6.6. Matriz de Trazabilidad........................................................................................................5
6.7. Descripción de Casos de Uso...............................................................................................6
7 Aprobaciones de Usuarios.....................................................................................9
8 Glosario..............................................................................................................10
8.1. Definición de Términos.....................................................................................................10
9 Anexos................................................................................................................11
9.1. Anexo 1 – Dinámica Contable:...........................................................................................11
9.2. Anexo 2 – SMS confirmación nuevo producto:.....................................................................11
9.3. Anexo 3 – RCP Creación Factura 6925:...............................................................................11
9.4. Anexo 4 – Reporte Creación cuentas de ahorro on boarding:.................................................11
10 Control de Versiones...........................................................................................12
Información Confidencial Pág. 2 de 43

Doc.: Ver. V. 1.0
y Alcance
1 INFORMACIÓN GENERAL
1.1. Datos Generales
Ítem Descripción
Líder Usuario
Cargo
Área
Dirección/Oficina
Teléfono/Anexo
Gerencia Sponsor Gerencia de Producto
Gerente Sponsor Ricardo Ramos
Fecha de Aprobación de Iniciativa <<Fecha de Aprobación, formato: dd/mm/aaaa>>
Gasto/Inversión ☐Gasto ☒Inversión
Complejidad Muy alta Alta ¤Media ¡Baja
Código Proyecto PMO RQ ####
1.2. Participantes
Las siguientes personas han participado en el desarrollo del presente documento.
Iniciales Nombre y Apellido Gerencia/Área-Cargo Contacto Rol

Gerencia de Negocios /
SCH Sandra Chávez Gestor de Proyectos 993725260 Líder Funcional
Comerciales
Productos Prestamos / Jefe
GH Gilmar Herrera
de Productos
Productos TC / Especialista
JD Jorge Delgado
de Producto
CG Carmen Gutiérrez
CY Candy Yoplac
Mercedes Ribbeck
Patricia Maza
Pamela Campos
Frank Cabrejos
Gopika Leyva
Patricia Anampa
Carlos Delgado

Doc.: Ver. V. 1.0
y Alcance
Iniciales Nombre y Apellido Gerencia/Área-Cargo Contacto Rol

Angie Apaestegui
Humberto Lecca
Jhonny Espinoza
Pablo Martínez
Miriam López
Danilo López

Doc.: Ver. V. 1.0
y Alcance
2 VISIÓN
Banco Ripley tiene como misión ser el Retail Financiero Líder en el Perú. En consecuencia,
tiene como objetivo dar facilidades de financiamiento a sus clientes para que obtengan un
orden en sus cuotas mensuales, mediante el otorgamiento de un nuevo SEF (T24)-Defensa a
Clientes que posean deuda vigente en su TC (RSAT)
2.1. Propósito del Proyecto

Objetivo Nro. Descripción
Automatizar el ordenamiento de las cuotas de la TC, mediante el
OBJ-001
otorgamiento de un nuevo SEF (T24) - Defensa.
OBJ-002 Generar reportes de gestión y seguimiento los cuotealos generados.
2.2. Antecedentes
Actualmente no se cuenta con un producto para ofrecer de forma proactiva el
ordenamiento de la deuda de TC, por lo cual se requiere la implementación de la
funcionalidad SEF-Defensa.

Doc.: Ver. V. 1.0
y Alcance
3 ALCANCES Y RESTRICCIONES
3.1. Alcance Organizacional
Criterio Detalle
Países Impactados ☒PE – Peru
☐CL – Chile
☐CO – Colombia
☐Otro(s). Especificar: <<Especificar>>
Unidades de Negocio ☒Banco.
☐Tienda.
☐Otro(s). Especificar: <<Especificar>>
Usuarios impactados en el - Productos Activos
proceso - Medios de Pago
- Red de agencias
- Call Center
- Colocaciones
- Contabilidad
- Riesgos
- Seguros
Transaccionalidad
Esperada (adicional a lo No aplica
existente si corresponde)
Procesos de Negocio
Impactados No aplica
3.2. Resumen de Alcance

 Automatizar el proceso de ordenamiento de la deuda de TC (RSAT), mediante
una cancelación total de la deuda de la TC y el otorgamiento de un préstamos
SEF T24 - Defensa.
 Aplica solo para Clientes que posean saldo deudor en su TC, con operaciones de
2 o más cuotas.
 La TC debe ser pronto pagada en su totalidad y no se debe bloquear la TC.
 Se debe dar de alta un nuevo SEF en T24 (defensa) considerando el mismo
monto de la deuda de la TC.

Doc.: Ver. V. 1.0
y Alcance
 Canales: red de agencias y call center.

 Se atenderán mediante las siguientes herramientas: On Boarding (App/Web),
los SEF Defensa serán asistidas por lo colaboradores de Banco Ripley.
 El nuevo préstamo de SEF que se genere en T24, debe generarse con el código
del siguiente producto de T24:
Código Descripción
LD011010 Súper Efectivo
Para poder diferenciar los SEF originados para el ordenamiento de la deuda de

la TC, se añadirá el termino defensa dentro de las glosas a utilizar en los
módulos diferidos y la nueva factura.
 Se debe generar una nueva factura para el pronto pago de la TC a nivel RSAT.
 Se debe generar una nueva plantilla (RUO) para la carga de Ofertas SEF-
Defensa.
3.3. Restricciones y/o Limitantes

 No aplica entrega de saldo adicional al Cliente.
 En el alta del nuevo SEF no se debe considerar tipo de desembolso.

Doc.: Ver. V. 1.0
y Alcance
4 SITUACIÓN ACTUAL
Actualmente no se cuenta con una funcionalidad de ordenamiento de cuotas de TC de

manera proactiva.
1.
2.
3.
4.
4.1.
1.
2.
3.
4.
4.1.
4.1. Diagramas de Procesos Actual

1.
2.
3.
4.
4.1.
4.2.
No Aplica
5 SITUACIÓN FUTURA
La Automatización de la compra de deuda interna (TC RSAT)y el otorgamiento del nuevo SEF
Defensa se deben realizar en la plataforma On Boarding (OB), mediante la consulta a la base
RUO. La atención se realizará bajo el flujo express y el flujo estándar para los Clientes PEP.

Doc.: Ver. V. 1.0
y Alcance
SEF Defensa (RSAT – T24)

Reglas de Negocio de la automatización de la funcionalidad SEF Defensa que el OB debe
considerar
Reglas de Negocio
Igual a la deuda total de la TC en RSAT, a la fecha de la toma de la

Monto de la oferta
oferta.
Monto Mínimo y Mínimo = S/2,000.00
Máximo Máximo = s/50,000.00
Monto adicional s/00.00
TEA Debe ser la asignada por Riesgo en la oferta del RUO. Ruo
TEA Interés
Aplica tasa del préstamo sobre capital de cuota vencida Ficha Prod.
compensatorio
SEF - DEFENSA
Período de Gracia 0, 1 o 2. Según BD definido por Riesgo. Ruo
Plazo De 12 hasta 60 meses. Ruo

Rango Desembolso Prima Mensual
Hasta s/4,000 S/15.00
Seguro de Ficha
De s/4,001 hasta s/19,999 S/24.00
desgravamen producto
De s/20,000 hasta s/25,000 S/15.00
Desde s/ 25,001 a más S/20.00
Aplica tabla de factores de SEF Regular (LD011010) según cuota
Tabla de factores Onboarding
elegida.
El sistema OB debe permitir realizar la funcionalidad SEF-Defensa.
5.1. Limitaciones de la propuesta SEF Defensa

 No se puede incluir en la BD de ofertas a Clientes que tengan saldo deudor
de TC en una sola cuota o revolving.
 El Servicio de Pronto Pago de RSAT no considera las operaciones en

revolving y las pendientes en autorizar.

Doc.: Ver. V. 1.0
y Alcance
5.2. Proceso de SEF Defensa en OB

1.
2.
3.
4.
5.
5.1.
1.
2.
3.
4.
5.
5.1.
5.2.
5.2.1. Consultar Oferta
a) El sistema Onboarding deberá tener una ventana para ingresar el tipo de
documento en un combo box (DNI y CE) y el número de documento de
identidad. Pre definidamente mostrará el tipo de documento DNI.
b) Al momento de ingresar el documento oficial de identidad del cliente, el
sistema Onboarding validará si el Cliente se encuentra en la base de ofertas
elaborada por el área de riesgos (RUO) mostrando lo siguiente:
1. Tipo de documento, Número de documento y Nombre completa
del cliente.
2. Nombre del producto y modalidad de activación.
3. Fecha de vigencia de campaña (desde-hasta)
4. TEM y TEA con el símbolo de porcentaje a dos dígitos.
5. Plazo de la oferta en meses mínimo y máximo.
6. Periodo de Gracia.
c) En caso el Cliente no se encuentre en la base de ofertas elaborada por el área
de riesgos (RUO) el OB deberá mostrar una pantalla adicional indicando que
no tiene ofertas.
d) La oferta de SEF-Defensa deben ser cargados en una nueva plantilla RUO,
para lo cual Riesgos debe considerar la plantilla definida. (ver anexo xx)
e) Las ofertas SEF-Defensa deben seguir visualizándose en el RUO para la
consulta de los vendedores.

Doc.: Ver. V. 1.0
y Alcance
5.2.2. Validar Políticas

a) El OB debe validar que la deuda del Cliente en su TC (RSAT) sea mayor o igual
a s/ 2,000.00.
En caso que el Cliente no posea deuda o tenga saldo a favor se debe mostrar
un mensaje de error bloqueante indicando que no procede la funcionalidad
SEF-Defensa.
b) El OB debe validar que la TC originada en RSAT no se posea operaciones en su
última cuota, de darse este escenario el OB debe mostrar la oferta, pero
inmediatamente debe mostrar el siguiente mensaje bloqueante: “Cliente
posee operaciones con solo una cuota pendiente próxima a pagar”. Esto
debido a que el servicio de Pronto Pago (RSAT) no ejecuta el pago cuando el
Cliente se encuentra en su última cuota.
c) Se solicita que el OB valide de forma automática después de consulta de la
oferta que el Cliente no tenga alguno de los siguiente bloqueos:
 Para RSAT:
Bloqueos de contrato que inhiben el alta de un contrato (al cierre y
nuevos del mes), estas validaciones se realizan antes de la carga ,
pero igual el Sistema OnBoarding durante la vigencia de la oferta
debería validar si el cliente adquirió uno de estos bloqueos, de ser
positivo se debe bloquear el flujo en on boarding y no debe permitir
continuar, con el mensaje “Cliente con bloqueo de área Riesgos”.
TIPO_BLQUEO COD_BLQ DESCRIPCIÓN_BLOQUEO
CONTRATO 3 FRAUDE CLIENTE

CONTRATO 5 CANCELADA SOLIC. CLIENTE
CONTRATO 9 CANC. MAND. LEGAL
CONTRATO 10 DEMANDA -JUDICIAL

CONTRATO 12 FALLECIDO
CONTRATO 13 REFINANCIADO
CONTRATO 14 NO RECLAMADA
CONTRATO 49 BLOQUEO CORPORATIVO
CONTRATO 38 PASE A CASTIGO
CONTRATO 53 CUENTA CON GARANTIA

Doc.: Ver. V. 1.0
y Alcance
ENVIADO A REFINANCIAR OTRO

CONTRATO 55
APL
El alta se permite siempre y cuando el contrato se encuentre en

Estado Vigente, se inhibe si tiene los siguientes bloqueos automáticos:
TIPO_BLQUEO COD_BLQ DESCRIPCIÓN_BLOQUEO
CONTRATO 8 DEUDA VENC.OTRO PROD

CONTRATO 6 CANC.POLITICA DE EMPRESA
CONTRATO 16 MORA > 1
CONTRATO 25 AUDITORIA DE CREDITOS
CONTRATO 35 CESE DE PERSONAL
CONTRATO 36 BLOQUEO POR ATC
CONTRATO 39 REFINANCIADO EXTERNO
SOBREENDEUDAMIENTO -
CONTRATO 42
RIESGOS
CONTRATO 43 DETERIORO
DESACTIVA TARJETA CALL
CONTRATO 47
CENTER
CONTRATO 50 CAMPAÑA COBRANZAS
CONTRATO 56 POR INCAPACIDAD
CONTRATO 64 DEUDA VENCIDA FISA
 Para T24:
Se debe validar que no tenga ninguno de los siguientes productos:
PRODUCTO CODIGO
CONVENIO LD001002
CONVENIO FLAT LD001003
REFINANCIADO LD011013
JUDICIAL LD011014
CASTIGADO LD011015
REFINANCIADO FLEXIBLE LD011016
REFINANCIADO BASE LD011017

Doc.: Ver. V. 1.0
y Alcance
De tener un producto diferente a los antes mencionados este debe

estar al día en sus pagos.
De darse estos escenarios el OnBoarding debe mostrar la oferta, pero

inmediatamente debe mostrar el siguiente mensaje bloqueante: “Cliente con
bloqueo de área Riesgos”, esto debido a que Cliente puede adquirir uno de
estos bloqueos desde la carga de BD de oferta hasta el día que realiza la
solicitud del SEF Reenganche..
d) El monto del nuevo SEF T24 debe ser igual al monto de la deuda total de la TC
RSAT.
e) El Onboarding debe validar que el Cliente no se encuentre registrado en el

listado PEP y/o Listas negras. Para el caso de Clientes PEP, se debe mostrar un
mensaje informativo y seguir con el flujo de activación estándar.
Para Clientes registrados en alguna Lista Negra no se debe mostrar las ofertas
vigentes, solo el nombre del Cliente y el flujo debe ser bloqueado.
5.2.3. Consultar Deuda
a) El OB debe tener una grilla que muestre número de contrato de TC (originado

en RSAT), este campo debe autocompletarse con el nro. de contrato de la TC
a aplicar SEF-Defensa. (12 dígitos).
Debe tener otra grilla que muestre el saldo de deuda total de la TC RSAT a
ordenar (en moneda soles y dos decimales) al día de la ejecución (Capital +
intereses + comisiones + gastos + interés compensatorio – saldo a favor).
b) Se requiere guardar en un campo en el Overview de T24 el número del
contrato original de la TC (RSAT).
5.2.4. Simulación de SEF(T24)-Defensa
El sistema debe Simular el valor cuota considerando las siguientes variables:
En una sola línea debe mostrar los tres campos, acompañados del botón
simular/calcular:
 (A) Saldo deuda total de TC.- se debe mostrar en un campo no

editable resaltado con negrita el saldo deudor de la TC (RSAT) a la
fecha (Capital + intereses + comisiones + gastos + interés
compensatorio – saldo a favor).
Ejemplo: S/ 6,000.00

Doc.: Ver. V. 1.0
y Alcance
 (B) Monto neto a Entregar.- Se debe ocultar (no debe ser visible
para el usuario) este campo en la ventana consultar deuda,
debido a definiciones del negocio este producto no entregará al
Cliente saldo adicional.
 Monto de Préstamo Final – se debe mostrar en un campo no

editable el mismo valor del campo Saldo Deuda Total de la TC (A).
 Botón calcular: Se debe ocultar (no debe ser visible para el

usuario) este campo en la ventana consultar deuda.
 En la ventana Consultar Deuda se debe mantener los botones

“Regresar” y “Aceptar”.
En otra línea o ventana se debe mostrar la información con los siguientes campos:
 Monto de Préstamo Final- Monto que el cliente solicita acceder,

este es el monto calculado por el sistema (saldo de deuda total de
la TC RSAT).
* No se debe generar ITF al Pronto Pago.
 Meses de Gracia.- plazo adicional que el cliente puede acceder

para pagar su primera cuota. Puede ser hasta 2 meses; las
opciones para seleccionar serán: “0”- No Aplica Meses de Gracia,
“1” y “2” y aplicará según BD de la oferta SEF Defensa. OB debe
leer la BD de ofertas y debe parametrizar según esta indique.
 Día de Pago: el sistema debe autocompletar el campo con la

misma fecha de pago origen que tiene la TC en RSAT, pero este
campo debe ser editable (permitiéndole ingresar/digitar una fecha
distinta a la autocompletada entre el siguiente rango de días: 1 al
31)
 Nro. de Cuotas: es el número de cuotas que el cliente escoge para

el nuevo SEF Defensa creado en T24.
El plazo mínimo y máximo viene sugerido según la base del RUO el
usuario solo puede ingresar/digitar un plazo dentro del rango
sugerido del RUO, este campo es editable y el sistema no debe
permitir ingresar un número distinto al sugerido en el RUO.

Doc.: Ver. V. 1.0
y Alcance
Siempre y cuando las cuotas elegidas cumplan con la validación de

las Tablas de Factores.
 Al simular las variables mencionadas, el sistema debe entregar los

siguientes resultados:
 Primer Pago
- Es la fecha, compuesta del día/mes/año en la que el cliente
va a realizar su primer pago, solo el número del día siempre
debe coincidir con el campo “Día de Pago”, para el mes y año
el simulador hace el cálculo. El OB debe mostrar de forma
automática el cálculo del campo primer pago.
El campo que contiene esta información no debe ser editable.
- Las funcionalidades de primera fecha de pago y los días de
pago deberán permitir ingresar cualquier día del calendario (1
al 31) según el mes. Si en un mes determinado no hay el día
elegido como fecha de pago, tomará el último día del mes en
el cronograma de T24.
Nota: en el cálculo de la primera cuota, debe considerarse los
meses de gracias que el cliente eligió. (según sea el caso)
 Monto de Cuota
- Es el valor cuota mensual que el cliente debe asumir propio
del nuevo SEF-Defensa (T24), el monto del valor cuota debe
mostrarse con dos decimales y el símbolo de soles, en un
campo no editable (no permita modificación).
- El monto del valor cuota se genera en el sistema T24.
Nota: El OB deberá realizar los cálculos del monto final que el
cliente puede acceder a un SEF-Defensa (T24), dependiendo del
monto total de la oferta vs el número de cuotas que solicita,
considerando la tabla de factores vigente.
 TEA
 Es la tasa efectiva anual que el sistema debe calcular al leer la TEM
sin cargos, gastos y comisiones, la TEA debe mostrarse con dos
decimales y el símbolo de porcentaje, en un campo no editable.
 Esta tasa debe grabar en T24 para el cálculo de Interés
Compensatorio.

Doc.: Ver. V. 1.0
y Alcance
 TCEA
 Es la tasa costo efectiva anual que el sistema debe calcular al
sumar la TEA más cargos, gastos y comisiones, la TCEA debe
mostrarse con dos decimales y el símbolo de porcentaje, en un
campo no editable (no permita modificación).
Las funcionalidades de primera Fecha de Pago y TCEA deberán
funcionar tal y cual vienen funcionando actualmente en
producción.
 SEGUROS
On Boarding debe tener campos no editables con la información
de los seguros (desgravamen y protección de pagos)
Para los seguros de desgravamen:
OB debe reconocer el monto desembolsado (saldo deuda + monto
neto a entregar) del SEF Reenganche y de forma automática debe
autocompletar el campo seguro desgravamen con la información
registrada en la parametría de T24 (tabla).
Con las siguientes primas
Los seguros están en referencia al valor desembolsado según la
siguiente escala:
MONTO SEGURO DESGRAVAMEN EN T24

Los rangos y montos aplican
a partir del 01 de Septiembre
Rango Desembolso Prima
Hasta s/5,000 s/ 15.00
Mayor a s/5,000 hasta s/15,000 s/ 20.00
Mayor a s/15,000 s/ 25.00
Para los seguros de protección de pagos el campo debe

autocompletarse con el valor CERO, de acuerdo a parametría
actual de t24 (campo parametrizable)
5.2.5. Registro de Datos de Cliente
a) Se reutilizará el servicio de RENIEC para autocompletar algunos datos, si el

cliente ya existe en T24, la información se completará con la información
extraída de T24. Estos campos tienen condición editable, de ser necesaria
alguna actualización.

Doc.: Ver. V. 1.0
y Alcance
b) El OnBoarding debe mostrar las siguientes ventanas para la visualización y/o

actualización de los datos del Cliente:
 Ventana datos del Cliente: en esta ventana se deben crear 2 campos

nuevos a solicitud OC a fin de alinearnos a la resolución SBS 60-2015. Los
campos nuevos son:
- Nacionalidad (Nuevo)
- País de Residencia (Nuevo)
 Ventana de datos de Dirección.
 Ventana de Referencia Personal.
 Ventana de Protección de Datos. (opciones SI/NO, incluyendo la glosa
aprobada por Legal)
 Ventana de Modalidad de Desembolso.
c) Para el flujo de Call Center cuando se use el perfil Call Proveedor las ventanas
de datos de Cliente y de Dirección deben venir inhabilitadas (no editables),
para que el usuario no pueda realizar ninguna actualización en ambas
ventanas.
d) Después de culminar con el llenado de las ventanas de datos personales,

Onboarding debe activar de forma automática la ventana de Resumen de la
solicitud.
5.2.6. Modalidad de Desembolso
a) Dentro del flujo SEF Defensa no se debe mostrar esta ventana con ninguno de
sus campos o funcionalidades, debido a que el Cliente no se podrá llevar
ningún saldo excedente.
5.2.7. Resumen de Condiciones Pactadas con el Cliente

Después de ingresar las condiciones pactadas con el Cliente el OnBoarding debe
mostrar una ventana con el resumen de las condiciones pactadas, considerando
los siguientes campos:
 Oferta
o Nombre del producto: SEF DEFENSA.
o Monto total del SEF Defensa.
o Valor Cuota
o Número de Cuotas.

Doc.: Ver. V. 1.0
y Alcance
o TEA
o TCEA
o TEM
o Primer Pago
o Monto deuda de la TC
o Monto Neto.
 Datos del Cliente:

o Cliente:
 Nombre
 Dni
 Celular
 Correo electrónico
o Dirección.
o Referencia Personal.
o Archivos Adjuntos.
Edición de Datos del Cliente en la ventana Resumen

OnBoarding solo debe permitir la edición y actualización de todos los datos
personales para el canal de Red de Agencia (perfil vendedor).
Cada vez que se use el perfil proveedor Call Center en el canal Call Center se debe
mostrar la ventana resumen sin la opción de editar los datos del cliente. (ventana
“Cliente” y ventana “Dirección”)
5.2.8. Biometría
Se reutilizará el servicio de Validación Biométrica utilizado en OB.
Onboarding debe presentar dos flujos de SEF Defensa, uno que incluya validación
biométrica (Red de Agencia) y otro que no incluya validación biométrica (Call
Center).
 Para el canal de red de agencias, el flujo de SEF Defensa debe mostrar la
pantalla de validación biométrica, considerando los siguientes escenarios:
o Validación Biométrica, cuando exista una validación biométrica exitosa
ya no debe solicitarse la validación del SMS Token, el flujo debe
continuar en la aprobación.
o Validación Biométrica no exitosa (Enviar a Supervisor), cada vez que se
apruebe una solicitud en la bandeja del Supervisor “Enviar Supervisor”
el OB siempre debe solicitar la validación de SMS Token y el flujo solo
debe continuar con el ingreso correcto de los 6 digito del SMS Token. En

Doc.: Ver. V. 1.0
y Alcance
caso el código Token sea incorrecto el flujo se debe bloquear sin

consumir la oferta.
 Para el canal del call center, el flujo de SEF Defensa no debe mostrar la
pantalla de validación biométrica. Debiendo solicitar la validación SMS
Token para todas sus solicitudes.
5.2.9. Modalidad de Activación y Clave Token

Ventana del SMS Token.
 La ventana del SMS Token debe considerar lo siguiente:
o La ventana SMS Token debe mostrar el número telefónico donde
se ha enviado.
o El SMS Token debe tener una vigencia de 60 segundos, la ventana
debe mostrar un contador.
o La ventana SMS Token tener campos que permitan ingresar el
código enviado al Cliente.
o La ventana SMS Token debe tener una opción que permita
reenviar el código al mismo número registrado.
o La ventana SMS Token debe tener una nueva opción con el
nombre “No Continuar esta Solicitud” la cual permita dejar
inconclusa la atención de la solicitud sin consumir la oferta en el
RUO y sin generar las actividades automáticas del SEF Defensa, de
la misma manera al cierre del día (medíanoche) On Boarding de
forma automática debe pasar estas solicitudes al estado “Anulado
Auto.SEF Defensa”.
o En la ventana SMS Token no se debe considerar la opción “enviar a
Créditos”.
El SEF reenganche debe considerar las siguientes modalidades de activación:

 Flujo Express:
o Red de Agencias: Se requiere que la ventana del SMS Token solo
se muestre y active cada vez OB identifique que ha existido una
aprobación en la bandeja de “Envío al Supervisor”.
o Call Center: Se requiere que la ventana de SMS Token se muestre
y active después que el usuario le dio clic al botón continuar en
el resumen de la solicitud.
 Flujo Estándar: No debe existir SMS Token, y la solicitud en automático
deben ser dirigidas a Créditos. Solo aplica para Red de Agencias, no para
Call Center.

Doc.: Ver. V. 1.0
y Alcance
5.2.10.Validación por Créditos para PEP.

a) El sistema OB debe reconocer cuando la solicitud corresponde a un Cliente
pep para su atención en automático por Créditos con el flujo estándar.
Nota: en el mensaje sms debe enviar la cuenta del nuevo SEF Defensa en T24
y no la solicitud de Onboarding. Se requiere que esta información muestre el
número de contrato que empieza con “100” y no el que empieza con “AA”, en
el mensaje del alta del SEF que se envía al cliente.
b) En caso la validación del área de créditos sea negativa, ingresará la

observación a la plataforma Onboarding el motivo del rechazo u observación
y comentarios se visualizarán en la bandeja del vendedor.
c) Cuando se requiera aprobación de créditos en cualquiera de los flujos de
venta se deberá enviar un correo de forma automática a la bandeja
centraldecredito-con@bancoripley.com.pe , esta funcionalidad debe ser
parametrizable para que el banco ripley lo modifique si así lo requiera. Se
podrá cambiar el correo y cantidad de destinatarios.
El correo tendrá las siguientes características:

 Asunto: Aprobación SEF Defensa – Cliente PEP DNI 12345678 Juan
Arenas Gallardo
 Cuerpo:
- Estimados Srs. Créditos:
- Su apoyo para aprobación de SEF Defensa – Cliente PEP
 NOMBRE: Juan Arenas Gallardo
 Documento Oficial de Identidad: 12345678
 PRODUCTO: SEF Defensa
 MONTO: 5,000.00 SOLES
 MODALIDAD: RB3
 VENDEDOR: JUAN CARILLO ROBLES
 USUARIO: jcarrillo
 Correo del Vendedor
 AGENCIA
 CANAL
Lo subrayado será una plantilla del correo. Lo que no está subrayado será
información del préstamo.
d) Se solicita que OnBoarding tenga una lógica para que cada vez que lea la
oferta del RUO capture el producto y se agregue en el asunto del emailing
enviado a Créditos, esto es muy importante para que Créditos pueda
diferenciar los distintos productos que llegan a su bandeja.

Doc.: Ver. V. 1.0
y Alcance
5.2.11.Alta y Cancelación – Actividades Automáticas

Actividades que se generan de forma automática, después de una validación
exitosa de biometría, un ingreso correcto de código Token o aprobación del área
de Crédito (PEP):
a) Servicio Pronto Pago TC RSAT: Se cancela en RSAT y queda pendiente de
pago contable.
 Se solicita la creación de una nueva factura la cual tiene el número 6926 .
 La nueva factura 6926, tendrá los siguientes nombres: descripción corta
SEF-Defensa” y descripción larga “Súper Efectivo - Defensa”, esta factura
deberá tener una nueva dinámica contable (ver anexo #02) entregada por
las áreas de contabilidad, que considere el pago de la TC (RSAT) y la
creación del nuevo SEF-Defensa en T24. La Cuenta Tramite número
“#####” seleccionada por el lado deudor, deberá ser conciliada cuando se
realice el Alta del SEF en T24.
 Se debe considerar los siguientes datos para el abono del pronto pago de
la factura 6926:
- Referencia Pago: REPRO TCAT24 AJUSTE AUT
- BOLETA: TT2401
b) Servicio de bloqueo y baja de Contrato TC RSAT: Para el caso de esta nueva

campaña no se aplicará ningún bloqueo de TC en ninguna parte del proceso,
ni se dará de baja a la TC, son definiciones entregadas por el negocio.
c) Alta de SEF Defensa en T24

 El OB a través de sus servicios debe dar de alta al SEF Defensa en T24.
Considerando las siguientes condiciones:
Condiciones:
- Nombre del producto
- Nombre de la operación
- Monto de la cuota
- Número de cuotas
- TEA
- TCEA
- Primer Pago
- Glosa Reenganche: SEF-DEF
- Glosa Diferido: SEF-Defensa
 El desembolso del SEF se realizará en T24, abonando en la cuenta interna

“x confirmar”. La misma cta interna que debe afectar RSAT al realizar la
cancelación.

Doc.: Ver. V. 1.0
y Alcance
d) Servicio de Cuenta Interna con Pronto Pago: es el servicio que ejecutará la

liquidación de la factura 6926 generada en el servicio de pronto pago RSAT,
con cargo a la siguiente cuenta interna: #####
Nota: este servicio debe mitigar las casuísticas propias de pronto pago RSAT.
e) Módulo de Diferidos: Este servicio se debe incluir cuatro campos nuevos para
el módulo de diferidos que también deben visualizarse en el OverView de
T24:
 Glosa reenganche: se debe considerar el nombre: “SEF-DEF” para un

SEF Defensa (cancelación de deuda TC Rsat a T24).
 Glosa diferidos: se debe considerar el nombre de “SEF-Defensa”.
 Cuenta anterior: Número de TC RSAT.
 Arregement / Contrato anterior: Número de TC RSAT.
 Número de contrato anterior TC (RSAT): se debe considerar el
número de contrato origen de TC de RSAT.
 Modalidad de Activación: se debe mostrar la modalidad de
activación obtenida del RUO.
f) Actualización de Cliente T24: De existir modificación de los datos del Cliente

el onBoarding debe actualizar automáticamente los datos modificados en
T24.
g) Actualización del RUO: Una vez ejecutada la oferta de SEF Defensa el

onBoarding debe quemar la oferta en el RUO no permitiendo tomarla por
otra plataforma.
Importante: En caso el Cliente tenga las dos ofertas SEF y SEF Defensa al
momento que se acepte y se de alta una de ellas, el Onboarding de manera
automática e inmediata debe restringir y anular la otra oferta en el RUO. Con
el objetivo que no sea vendida en la plataforma OB.
5.2.12.Envío de SMS de Confirmación de nuevo producto

a) El OnBoarding después de la ejecución de las acciones automáticas debe
enviar un SMS al número celular del Cliente registrado en OB,
confirmando la aprobación del SEF Defensa, considerando los siguientes
datos:

Doc.: Ver. V. 1.0
y Alcance
 Nombre Cliente.
 Nombre Producto.
 Número de Préstamo T24. (10 dígitos, he inicia con 10)
 Deuda Total. (Monto de nuevo SEF Defensa)
 Primera Fecha de Pago.
5.2.13.Paperless SEF Defensa

a) Se reutilizará el servicio de paperless de notificación, consulta, envío y reenvió
de documentos en las diferentes actividades que se realizan en el contrato del
del SEF.
b) Los documentos que se deben enviar con un html vía email:
 Obligatorios Reenganche SEF:
o HTML
o Solicitud SEF
o Hoja de Resumen
o Contrato
o Cronograma de Pagos
o Seguros desgravamen
 Opcional, según acciones:
o Pago anticipado.
o Cuota comodín.
o Cambio de fecha de pago (solo aplica si cambió la fecha de pago
original)
5.2.14.Permanencia de solicitudes pendientes de aprobar

a) Las transacciones se deben concluir en el mismo día que se inician, de haber
solicitudes pendientes por aprobar, estas deben ser anuladas en todos los
sistemas donde intervengan de forma automática.
b) En caso se requiera atender al cliente otra vez se debe realizar el SEF Defensa
desde el inicio con una nueva solicitud.
5.3. Bandejas de usuarios de agencia, call y créditos.

Doc.: Ver. V. 1.0
y Alcance
Se reutilizarán todas las funcionalidades que actualmente tienen las bandejas de

OB y sólo se usarán las bandejas de los canales (red agencias y call Center).
En la bandeja, el usuario puede visualizar todos los productos que se atienden OB,
con sus respectivos usuarios.
OB debe mostrar una ventana donde el usuario pueda realizar la búsqueda de su
solicitud de reenganche SEF a través del DNI con los siguientes filtros:
 Status
 Tipo de documento
 Número de documento
 Rango de fechas (fecha inicio, fecha fin)
 Canal
Los estados que debe visualizar el usuario son:
 Finalizado
 Pendiente de autorización
 Cancelado
 Anulado auto reenganche
 Rechazado
5.4. Perfiles de acceso a OB

a) Se reutilizarán los perfiles que actualmente trabaja OB.
 Perfil Vendedor (Red de Agencias): Perfil que ejecuta la venta de los

productos en OB.
 Perfil Gestor (Red de Agencias): Perfil que ejecuta la venta de los productos
en OB.
 Perfil Supervisor (Red de Agencias): Perfil que aprueba o rechaza la
biométrica en caso de Cliente con discapacidad dactilar registrado en el DNI.
 Perfil Call Center: Perfil que ejecuta la venta en Call Center.
 Perfil Proveedor Call Center: Es un perfil existente que se le asigna a personal
externo del Banco (proveedores Call) para atender la solicitudes de SEF
Defensa. Se solicita para este perfil lo siguiente:
- Puede acceder o atender las ofertas de SEF Reenganche, SEF Regular,
SEF Defensa, reprogramación TC y reprogramación SEF, no debe tener
acceso al resto de ofertas, las ofertas distintas deben estar inhabilitadas
o bloqueadas.
- Los campos de datos personales y de dirección los campos deben estar
inhabilitados (no editables) no permitiendo una actualización de datos.
Solo debe leer los datos registrados del Cliente.

Doc.: Ver. V. 1.0
y Alcance
- En la ventana de Resumen no debe permitir realizar algún cambio en

datos personales o dirección.
 Perfil Central de Créditos: Perfil que aprueba, observa o rechaza las ventas
realizadas en OB.
b) En la asignación de funciones y perfiles se debe considerar el canal para un mejor

seguimiento de las ventas de los SEF Defensa, se debe considerar los siguiente
canales.
 Red de Agencias
 FF VV 1
 CALL CENTER
 OTROS
5.5. Pagos en T24

a) El SEF Defensa debe permitir recibir pagos en las diferentes modalidades y emitir
sus respectivos comprobantes.
b) Debe permitir abonar por los canales que el banco Ripley tiene a su disposición
como:
 Caja de banco.- Permite todas las modalidades de pago.
 Abono en automático desde una cuenta de ahorro.- Permite todas las
modalidades de pago.
 Por bancos externos.- Permite realizar pago de cuotas vencidas o vigente.
 Caja Tienda.- Permite el pago de la cuota vencida y/o la cuota vigente.
 HBK: Cuotas vencidas y/o vigente.
c) Los canales que se implementen a futuro para realizar los pagos en préstamos
deben considerar a los préstamos con funcionalidad reenganche.
5.6. Reportes de SEF Defensa

El sistema T24 guardará información de los SEF Defensa desembolsado con todas
las condiciones y/o propiedades con la finalidad de gestionar toda la información
para la posterior elaboración de reportes.
a) Las transacciones de SEF Defensa se deben reflejar en los reportes de
movimientos pasivos, alta de pasivos y el reporte ETRAN y en Reporte de
operaciones de transacciones mayores a 5K, 10 K, y 50k (t24) y en el actual
reporte de Ajustes de abono y pronto pago se mantendrá la factura 6926.
b) En la solución definitiva la información será registrada en una tabla del
ODS(Finx25p), la cual tendrá los 2 campos de ITF correspondiente al abono y al
redondeo. Adicionalmente esta información podrá ser consultada por un rango de
fecha, productos, contrato.

Doc.: Ver. V. 1.0
y Alcance
c) Se incluye print con los campos que se presentarán en el query
 Se cargará la información de las transacciones con la factura 6925 en una

nueva tabla y esta será usada por el usuario del área de control contable
para emitir el reporte en forma manual. Este modelo de reportería es
utilizado en otras áreas.
 El reporte tendrá los campos del reporte ajuste de abono y pronto
pago más los campos de itf de abono y redondeo.
d) El sistema T24 guardará información de todas las actividades realizadas en las

cuentas de los préstamos reenganche manteniendo un histórico de
transacciones ejecutadas en estos préstamos ya sean que se hayan ejecutado de
forma automática.
e) La información se almacenará por un periodo de 10 años. Considerar fecha y
hora por cada etapa del proceso para todos los reportes. El reporte debe
contemplar filtros para extraer información según necesidad.
 Fecha.- desde - hasta(debe considerar rangos de fecha). Se pondrá límite de
3 meses hacia atrás como máximo. Número de días máximo a consultar
entre ambas fechas.
 Canal: opción individual, multi canal y todos
 Cuenta del préstamo
 DNI del cliente
f) En el reporte de Stock préstamos y reporte de desembolso se debe validar que

viaje y se muestre la información en los respectivos campos:
También se deben agregar campos adicionales, los cuales se deben completar
con la información del SEF, y a la vez se debe validar que viaje la información al
reporte de stock de préstamos y reporte de desembolso.
Reporte de Stock de Préstamos
 CUENTA_ANTERIOR_REENGANCHE (Cuenta TC RSAT), campo existente
 MONTO_REENGANCHE (debe viajar vacío), campo existente
 MONTO_EFECTIVO (debe viajar vacío), campo nuevo
 MONTO_CUENTA_INT (debe viajar vacío), campo nuevo
 MONTO_CUENTA_EXT (debe viajar vacío), campo nuevo

Doc.: Ver. V. 1.0
y Alcance
 TIPO_DESEMBOLSO (debe viajar vacío), campo nuevo

 MOD_ACTIVACIÓN (debe viajar vacío), campo nuevo.
 NUM_CUOT_COMODIN (debe viajar vacío), campo nuevo
 NUM_MES_GRACIA, campo nuevo
Reporte de Desembolsos
 CUENTA_ANTERIOR_REENGANCHE (Cuenta TC RSAT), campo existente
 MONTO_REENGANCHE (debe viajar vacío), campo nuevo
 MONTO_EFECTIVO (debe viajar vacío), campo nuevo
 MONTO_CUENTA_INT (debe viajar vacío), campo nuevo
 MONTO_CUENTA_EXT (debe viajar vacío), campo nuevo
 TIPO_DESEMBOLSO (debe viajar vacío), campo nuevo
 MOD_ACTIVACIÓN , campo nuevo.
 NUM_CUOT_COMODIN, (debe viajar vacío), campo nuevo
 NUM_MES_GRACIA, campo nuevo
Esta información se enviará desde Onboarding a la Web de reportería.
g) Los SEF defensa deben registrarse en el reporte de altas de on boarding.
h) Los SEF defensa deben registrarse en el reporte Préstamos Cancelados.
i) Los SEF defensa deben registrarse en el Reporte de Seguros .
j) Los SEF defensa deben registrarse en el Reporte Pagos Préstamo Contable (data
exstore).
k) Los SEF defensa deben registrarse en el Reporte de errores en el proceso de

venta de Onboarding.

Doc.: Ver. V. 1.0
y Alcance

5.7. Diagramas de Proceso Esperado
5.8.1 Diagrama de SEF Defensa en Red Agencias
5.8.2 Diagrama de SEF Defensa en Call Center

5.8. Requerimientos Funcionales
Código Funcionalidad Descripción Prioridad

Consulta de oferta (RUO) de la Ventana que permita consultar la oferta de SEF C
RQF001 funcionalidad SEF Defensa en Defensa ingresando el número de documento
OB. del Cliente.
Se requiere que OB recupere la información C
correspondiente a deuda total al día de la
Consulta de deuda de TC
RQF002 ejecución de la operación de Pronto Pago de la
originado en RSAT.
deuda de la TC RSAT, incluyendo el capital,
todos los cargos, gastos, intereses de RSAT.
C
Validación de políticas que Validar las nuevas políticas que aplican para SEF
RQF003
aplican para SEF Defensa. Defensa (RSAT a T24)
C
Se mantiene la funcionalidad actual de OB con la
Simulación de valor cuota de
RQF004 salvedad que el monto a simular es el mismo de
pagos para el SEF Defensa.
la deuda de la TC RSAT.
Se reutilizará el servicio de validación C

Validación Biométrica y SMS biométrica. Asi también la validación de la clave
RQF005
Token. token enviada al Cliente mediante un SMS a su
celular.
Para la ejecución de la funcionalidad SEF C
Defensa se debe considerar los siguientes
RQF006 Alta del SEF Defensa. procesos automáticos:
- Pronto Pago de la TC RSAT.
- Alta de SEF en T24.
Envío de Documentación de Los documentos correspondientes al alta se C
RQF007
alta SEF vía Paperless enviarán por el servicio de Paperless.
Se debe permitir la visualización de las C
solicitudes en las bandejas de Red de Agencias,
Visualización de solicitudes en
RQF008 Call y Créditos.
Bandeja de usuarios
Se debe validar duración y anulación de
solicitudes pendientes.
Asignación de funciones por perfiles y canales C
RQF009 Gestión de perfiles de usuario.
de venta
El nuevo SEF creado en T24 debe reutilizar todos C
RQF010 Pagos en T24
los servicios de pago de préstamos existentes.
Reporte de los SEF según estructura detallada. C
RQF011 Reportes de SEF Defensa
Web de Reportería (DataEX)
RQF012 Módulo de Diferido El sistema debe integrar las transacciones al C
Doc.: Ver. V. 1.0
y Alcance
módulo de diferido.
Prioridad de Requerimientos Funcionales

C Crítico: Es indispensable la incorporación de esta funcionalidad.
N Necesario: Se considera importante para el comportamiento de la funcionalidad requerida.
D Deseable: Se considera una funcionalidad opcional.
5.9. Requerimientos No Funcionales
Código Descripción Tipo Prioridad
Actualización de documentos normativos, procesos, tarifarios y

RNF-001 RLE C
folletería.
RNF-002 Capacitación a la Red. RLE C
RNF-003 Comunicación a los clientes vigentes. RLE C
Tipo [Requerimientos no Funcionales]

USA Usabilidad
REN Rendimiento, Performance
DSP Disponibilidad
DIS Consideraciones de Diseño
SOP Consideraciones de Soporte y/o Licenciamiento
DOC Documentación, Sistema de Ayuda, Metodología, Estándares Aplicables
INT Interfaces de Hardware, Interfaces de Software, Interfaces de Comunicaciones
RLE Requerimientos Legales y de Derecho de Autor
SEG Requerimiento de Seguridad
Prioridad de Requerimientos no Funcionales

Doc.: Ver. V. 1.0
y Alcance
C Crítico: Es indispensable la incorporación de esta funcionalidad.

N Necesario: Se considera importante para el comportamiento de la funcionalidad requerida.
D Deseable: Se considera una funcionalidad opcional.
5.10. Funcionalidad Excluida

No aplica
6 ESPECIFICACIÓN DE LA SOLUCIÓN
6.1. Listado de Actores

N° Actor Descripción
Usuario de agencia, asesor comercial y asesor de call center,
1 Usuario de canal
operador Back Call Center.
Responsable de gestionar las cobranzas que realizarán los gestores
2 Supervisor
sean de Call Center o campo.
Responsable de aprobar las solicitudes de Reenganche SEF que no
3 Analista de Créditos
generen SMS Token.
6.2. Diagrama de Actores

Diagrama de Actores

Doc.: Ver. V. 1.0
y Alcance
6.3. Listado de Casos de Uso de Negocio
Código Casos de Uso Descripción
Realizar un SEF Defensa en OB desde la Realizar la consulta de la oferta de SEF Defensa de un

CUS001
Red de Agencias. Cliente y ejecutarla.
Realizar un SEF Defensa en OB desde Realizar la atención del Cliente, Realizar la consulta de
CUS001
Call Center. la oferta de SEF Defensa de un Cliente y ejecutarla.
6.4. Diagrama de la Solución
Diagrama de la Solución
6.5. Listado de Reportes

Se debe validar/verificar que toda la información obtenida del On Boarding con la nueva
funcionalidad de sef reenganche se guarde en los siguientes reportes, como en la actualidad :
Código Reporte Descripción

Reporte conteniendo los stock de SEF Defensa y el
REP001 Reporte de Stock y Desembolso
estado del desembolso.
Reporte propio del OnBoarding que registra todas las
REP002 Reporte de Altas en On Boarding
altas desde el OB.
Reportes de préstamos cancelados, aquí se debe
REP003 Reporte de Préstamos Cancelados registrar los pronto pagos de los SEF originados en
RSAT.
REP004 Reporte de Pagos (Data ExsTore) Reporte que refleja el motivo y numero de nuevo SEF.
Reporte que refleja los seguros generados por el SEF
REP005 Reporte de Seguros
Defensa.
Reporte de errores en el proceso de venta Reporte que refleja el estado de las actividades
REP006
de Onboarding automáticas de la Repro SEF en OB.

Doc.: Ver. V. 1.0
y Alcance
6.6. Matriz de Trazabilidad
Listado de Caso de Uso Listado de Reportes
Listado de
Requerimientos CUS002
CUS001
REP001
REP002
REP003
REP004
REP005
Código REQ
RQF001 X X
RQF002 X X
RQF003 X X
RQF004 X X
RQF005 X
RQF006 X X X X X X X
RQF007 X X
RQF008 X X
RQF009 X X
RQF010 X X
RQF011 X X
RQF012 X X

Doc.: Ver. V. 1.0
y Alcance
6.7. Descripción de Casos de Uso

6.8.1. CUS001 - Realizar un SEF Defensa en OB – Red de Agencias
Términos Definición
Código CUS001
Caso de Uso Realizar un SEF Defensa en OB en el Canal Red de Agencias
Los clientes que califiquen para un SEF Defensa y que cumplan las políticas internas de
Descripción General
crédito del Banco Ripley pasarán por el proceso de evaluación en OB.
Cliente debe poseer deuda mayor o igual a s/2,000.00 en la TC RSAT y debe estar dentro de la
Precondición
base de datos del RUO.
Pronto Pago a la TC RSAT, Alta de nuevo SEF en T24 y envío de documentación paperless al
Post-Condición
Cliente.
Actores Usuario Ejecutor, Supervisor Comercial y Analista de Créditos.

Involucrados e Los validadores del caso
intereses
Se realiza el pronto pago con éxito.
Garantías Mínimas Se da de alta el SEF en t24 con éxito.
Se envía la documentación paperless al Cliente con éxito.
Garantías en caso de Actualización de datos del cliente, baja de contrato en Rsat, nuevo cronograma de pagos.
éxito
Paso Acción
1 El Asesor Comercial debe ingresar tipo y número de documento de identidad en OB.
2 El Asesor Comercial debe seleccionar oferta de SEF Defensa en OB.
3 El Asesor Comercial debe Consultar deuda y simular las condiciones de Defensa en OB.
Flujo Principal 4 El Cliente Acepta condiciones.
5 El Asesor Comercial realiza Validación Biométrica del Cliente en OB.
6 El OB envía documentación paperless al email del Cliente.
7 El OB muestra mensaje de finalización del proceso con éxito.
Paso #05:
- Si no se puede ejecutar la validación Biométrica en el OB, el Asesor Comercial
debe seleccionar la opción “Enviar a Supervisor”, para que el Supervisor realiza
la autenticación manual del Cliente, y luego ingrese el código autorizador.
FA1
Flujo Alternativo - Después de ingresar el código autorizador se debe generar el código SMS Token,
el cual debe ser brindado por el Cliente, de no ser ingresado correctamente el
código Token se debe bloquear el flujo sin consumir la oferta.
Este flujo alternativo continua en el paso #06.
FA2
Relación con otros
Casos
Información Adicional
Prototipo
N/A

Doc.: Ver. V. 1.0
y Alcance
6.8.2. CUS002 - Realizar un SEF Defensa en OB – Call Center

Términos Definición
Código CUS002
Caso de Uso Realizar un SEF Defensa en OB en el canal Call Center
Los clientes que califiquen para un SEF Defensa de su SEF originado en RSAT y que cumplan
Descripción General las políticas internas de crédito del Banco Ripley pasarán por el proceso de evaluación y
reenganche automático en OB.
Cliente debe poseer deuda en su TC RSAT mayor o igual a s/2,000.00 y debe estar dentro de la
Precondición
base de datos del RUO.
Pronto Pago a la TC RSAT, Alta de nuevo SEF en T24 y envío de documentación paperless al
Post-Condición
Cliente.
Actores Analista de Call Center.

Involucrados e Los validadores del caso
intereses
Se realiza el pronto pago con éxito.
Garantías Mínimas Se da de alta el SEF en t24 con éxito.
Se envía la documentación paperless al Cliente con éxito.
Garantías en caso de Actualización de datos del cliente, baja de contrato en Rsat, nuevo cronograma de pagos.
éxito
Paso Acción
El Asesor de Call Center realiza la gestión de Call Center ingresando al OB para la
1
consulta de la oferta de SEF Defensa.
2 El Asesor de Call Center debe seleccionar oferta de SEF defensa en OB.
3 El Asesor de Call Center debe seleccionar las condiciones pactadas con el Cliente.
El Asesor de Call Center debe generar desde el OB el SMS TOKEN, el cual será enviado
4
Flujo Principal en automático al celular del Cliente.
El Asesor de Call Center debe generar ingresar en el OB el SMS TOKEN brindado por el
5
Cliente.
6 El Asesor de Call Center debe aceptar el resumen del SEF Defensa en OB.
7 El OB envía documentación paperless al email del Cliente.
8 El OB muestra mensaje de finalización del proceso con éxito.
Paso #05:
FA1 Si el Cliente no brinda el código Token se debe bloquear la solicitud sin consumir la
Flujo Alternativo
oferta.
FA2
Relación con otros
Casos
Información Adicional
Prototipo
N/A

Doc.: Ver. V. 1.0
y Alcance

Doc.: Ver. V. 1.0
y Alcance
7 APROBACIONES DE USUARIOS
Fecha
Gerencia/Área Rol Versión Usuario Validador Usuario Aprobador Adjunto
Aprobación
Producto v.1.0 Gilmar H. / Jorge
Velasco
Gerencia de Riesgos v.1.0 Candy Yoplac
v.1.0 Silvia Gómez / Lorena
Gerencia de Créditos
del Carpio
Cumplimiento v.1.0 Humberto Lecca /
Normativo Ana Lucia G.
Conducta del v.1.0
Angie Apaestegui
Mercado
Sub Gerencia de v.1.0 Mercedes Ribbeck /
Colocaciones y Walter Alfaro /
Pasivos Mariana Carrillo
Sub Gerencia de v.1.0
Patricia M. / Pamela
Operaciones de
C. / Jorge Falcón
Medios de Pagos
Regulatorios v.1.0 Carlos Delgado
Gerencia de v.1.0 Gópika Leyva /
Contabilidad Patricia Anampa
Control Contable de v.1.0 Frankz Cabrejos /
Operaciones George Berrios
Riesgos Operacional v.1.0 José Luis Carrera
Gerencia Negocios v.1.0
Danilo López
Seguros
Red de Agencias v.1.0 Pablo Martínez
Call Center v.1.0 Miriam López
Gerencia de Fraudes v.1.0 Juan Moises de la
Portilla
Tributación v.1.0 Harumi Zevallos
8 GLOSARIO
8.1. Definición de Términos
N° Concepto Definición
1 SEF SEF. Línea paralela a la tarjeta de crédito Ripley
3 RUO Repositorio Único de Ofertas
4 OB Onboarding
Core financiero donde se gestionan los préstamos,
5 T24
ahorros, CTS, etc. del Banco Ripley.

Doc.: Ver. V. 1.0
y Alcance
10 N/A No aplica

Doc.: Ver. V. 1.0
y Alcance
9 ANEXOS
9.1. Anexo 1 – Dinámica Contable:

<<Por incluir Dinámica contable RSAT y T24>>
9.2. Anexo 2 – RCP Creación Factura 6926:
9.3. Anexo 3 – Nueva Plantilla RUO SEF Defensa
9.4. Anexo 4 - Solicitud Modificación de Datos para paperless
Clave de ingreso a PDF:46566537
9.5. Anexo 5– HTML + Link de Agencias
Link asociado botón Ver agencias:
https://www.bancoripley.com.pe/pdf/red-agencias-banco-ripley.pdf?
utm_source=email&utm_medium=boton-agencias&utm_campaign=confirmacion-desembolso-
prestamo&utm_content=atencion-red-agencias

Doc.: Ver. V. 1.0
y Alcance
9.6. Anexo 6 – Simulador
9.7. Anexo 7 – HR
9.8. Anexo 8 – Póliza seguro Desgravamen

Doc.: Ver. V. 1.0
y Alcance
10 CONTROL DE VERSIONES
Fecha Versión Autor Descripción

24/05/2022 1.0 Sandra Chávez Elaboración del Documento

Dea Rq-1092 Sef Defensa

Cargado por

Información del documento

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Dea Rq-1092 Sef Defensa

Cargado por

Copyright:

Formatos disponibles

Documento de Especificación de Alcance

RQ-1092 Súper Efectivo Defensa

Información Confidencial Pág. 2 de 43

1.1. Datos Generales

Iniciales Nombre y Apellido Gerencia/Área-Cargo Contacto Rol

Información Confidencial Pág. 3 de 43

Iniciales Nombre y Apellido Gerencia/Área-Cargo Contacto Rol

Información Confidencial Pág. 4 de 43

2.1. Propósito del Proyecto

Información Confidencial Pág. 5 de 43

3.1. Alcance Organizacional

3.2. Resumen de Alcance

Información Confidencial Pág. 6 de 43

 Canales: red de agencias y call center.

Para poder diferenciar los SEF originados para el ordenamiento de la deuda de

3.3. Restricciones y/o Limitantes

 En el alta del nuevo SEF no se debe considerar tipo de desembolso.

Información Confidencial Pág. 7 de 43

Actualmente no se cuenta con una funcionalidad de ordenamiento de cuotas de TC de

4.1. Diagramas de Procesos Actual

Información Confidencial Pág. 8 de 43

SEF Defensa (RSAT – T24)

Igual a la deuda total de la TC en RSAT, a la fecha de la toma de la

Monto adicional s/00.00

Período de Gracia 0, 1 o 2. Según BD definido por Riesgo. Ruo

Plazo De 12 hasta 60 meses. Ruo

El sistema OB debe permitir realizar la funcionalidad SEF-Defensa.

5.1. Limitaciones de la propuesta SEF Defensa

 El Servicio de Pronto Pago de RSAT no considera las operaciones en

Información Confidencial Pág. 9 de 43

5.2. Proceso de SEF Defensa en OB

Información Confidencial Pág. 10 de 43

5.2.2. Validar Políticas

TIPO_BLQUEO COD_BLQ DESCRIPCIÓN_BLOQUEO

CONTRATO 3 FRAUDE CLIENTE

CONTRATO 9 CANC. MAND. LEGAL

CONTRATO 10 DEMANDA -JUDICIAL

CONTRATO 49 BLOQUEO CORPORATIVO

CONTRATO 38 PASE A CASTIGO

CONTRATO 53 CUENTA CON GARANTIA

Información Confidencial Pág. 11 de 43

ENVIADO A REFINANCIAR OTRO

El alta se permite siempre y cuando el contrato se encuentre en

TIPO_BLQUEO COD_BLQ DESCRIPCIÓN_BLOQUEO

CONTRATO 8 DEUDA VENC.OTRO PROD

Información Confidencial Pág. 12 de 43

De tener un producto diferente a los antes mencionados este debe

De darse estos escenarios el OnBoarding debe mostrar la oferta, pero

e) El Onboarding debe validar que el Cliente no se encuentre registrado en el

5.2.3. Consultar Deuda

a) El OB debe tener una grilla que muestre número de contrato de TC (originado

5.2.4. Simulación de SEF(T24)-Defensa

El sistema debe Simular el valor cuota considerando las siguientes variables:

 (A) Saldo deuda total de TC.- se debe mostrar en un campo no

Información Confidencial Pág. 13 de 43

 Monto de Préstamo Final – se debe mostrar en un campo no

 Botón calcular: Se debe ocultar (no debe ser visible para el

 En la ventana Consultar Deuda se debe mantener los botones

 Monto de Préstamo Final- Monto que el cliente solicita acceder,

 Meses de Gracia.- plazo adicional que el cliente puede acceder

 Día de Pago: el sistema debe autocompletar el campo con la

 Nro. de Cuotas: es el número de cuotas que el cliente escoge para

Información Confidencial Pág. 14 de 43

Siempre y cuando las cuotas elegidas cumplan con la validación de