Valeria Melchior Maite AnayaJuan Robles Ivan Joaquin Martinez Sanchez

• Fecha de inicio: 23/10/2025

• Fecha de cierre: 13/11/2025

Objetivo del Sprint: Desarrollar los flujos y tareas que permitan el cierre de una operatoria básica de otorgamiento de un Préstamo, incluyendo el cobro del mismo al Cliente final y el pago de liquidaciones y comisiones al Comercio.

Tabla de contenidos

1. Modificaciones en Asociación

Como ya se detalló en Sprints anteriores, la creación de una Asociación en la Consola Admin implica la definición del entorno del ecosistema para el Modelo de negocio seleccionado.

En base a esta definición se deben realizar modificaciones en el alta de una Asociación que permitan diferenciar parámetros a cargar, asociados a distintos Modelos de negocio.

Se solicita incorporar un nuevo campo luego de Modelo de negocio y antes de Cuenta bancaria con el nombre Capital Lender a invertir

Este campo debe ser obligatorio y numérico aceptando solo dígitos mayores a 0. De esta forma si se deja el campo en 0 se debe mostrar el mensaje: El importe debe ser mayor a 0

El Capital a invertir por parte del Lender implica el monto máximo que el mismo destinara a este negocio, es decir su propia Línea de crédito. En próximos Sprints se avanzara sobre:

• Sumatoria de los capitales de un Lender en los diferentes negocios en los que opere

• Gestión de sus disponibles, es decir de su capital a invertir menos sus inversiones efectivas (sus prestamos)

Este primer bloque (incluyendo el nuevo campo de Capital a invertir) de datos a seleccionar y/o completar aplica para cualquier tipo de Modelo de negocio, incluyendo:

• Cuenta bancaria: Se utilizara para el ecosistema definido (cobro y/o pagos) pudiendo ser la misma en diversas Asociaciones.

• Gastos administrativos: Se utilizara para el ecosistema definido en particular. Pendiente definición de aplicación en el Modelo Consumo B2C

  • Fecha de inicio de vigencia de gastos administrativos: Ídem Gastos administrativos

  • Fecha de fin de vigencia de gastos administrativos: Ídem Gastos administrativos

Los bloques siguientes aplicaran en forma especifica al Modelo de negocio seleccionado con los cual se solicita agregar Títulos que diferencien los mismos.

Título: Modelo B2B Capital de Trabajo

• Ventanas de aprobación: Sin cambios en el presente Sprint

• Aranceles del servicio: Sin cambios en el presente Sprint

Agregando un nuevo bloque con el Titulo: Modelo B2C Consumo

• Gestión de prestamos: Debe incluir los siguientes campos a completar:

  • Vigencia de Score crediticio: A detallar mas adelante

  • Código de verificación de celular: A detallar mas adelante

  • Plazo de pago de liquidaciones: A detallar mas adelante

  • Comisiones a abonar: A detallar mas adelante

  • Plazo de pago de comisiones: A detallar mas adelante

En próximos Sprints se pueden agregar campos o nuevos bloques

Importante: Al seleccionar Nueva Asociación todos los bloques deben estar grisados. Solo cuando se selecciona el Modelo de negocio se debe habilitar la carga de los bloques:

→ Si se selecciona Modelo B2B Capital de Trabajo

• Ventanas de aprobación

• Aranceles del servicio

→ Si se selecciona Modelo B2C Consumo

• Gestión de prestamos

1.1 Vigencia de Score crediticio

Como se detalló en el Sprint 35, el proceso de verificar el Score Crediticio de un Cliente implica la consulta vía APIs al Proveedor de Servicio de Scoring.

Los datos de respuesta deben ser guardados durante el tiempo que se defina en el nuevo campo Vigencia de Score crediticio

Este campo es obligatorio y numérico aceptando solo dígitos mayores a 0 y hasta 365 . De esta forma:

1. Si se deja el campo en 0 se debe mostrar el mensaje: El importe debe ser mayor a 0

2. Si se carga un valor mayor a 365 se debe mostrar el mensaje: El importe debe ser menor o igual a 365

La vigencia se aplica considerando la fecha de la respuesta del Servicio + Campo Vigencia de Score crediticio

Ejemplo: Vigencia del Score: 90 días

Cliente nuevo

• Fecha de consulta: 07/10/2025

→ Hasta el 05/01/2026 la respuesta esta vigente

1. Si el Cliente solicita un nuevo Préstamo el 20/12/2025 aplica el score guardado en la base del Lender.

2. Si el Cliente solicita un nuevo Préstamo el 06/01/2026 NO aplica el score guardado en la base del Lender y se debe volver a consultar cambiando o no el resultado pero si la nueva vigencia.

Cliente activo

• Fecha de consulta: 25/07/2025

→ Hasta el 23/10/2025 la respuesta esta vigente

1. Si el Cliente solicita un nuevo Préstamo el 20/10/2025 aplica el score guardado en la base del Lender.

2. Si el Cliente solicita un nuevo Préstamo el 21/10/2025 NO aplica el score guardado en la base del Lender y se debe volver a consultar cambiando o no el resultado pero si la nueva vigencia.

1.2 Código de verificación del celular

Como se detalló en el Sprint 35, cuando el Cliente selecciona una oferta crediticia se debe avanzar en la validación de la identidad del mismo.

La primera etapa se realiza mediante la verificación del Nro. de celular cargado en el Alta del Cliente enviado un código de verificación al mismo, a través de un servicio de terceros que envíe mensajes de SMS. A confirmar integración.

En la Consola se muestra un modal similar al siguiente:

El campo con el Nro. de línea celular debe mostrar el numero cargado, aunque debe poder permitir su actualización. Si se modifica el mismo debe reflejarse esto en la pantalla con los datos del Cliente.

Al seleccionar Enviar SMS se debe habilitar un nuevo modal que permita ingresar el código de verificación que el Cliente recibió en su celular

→ Si el Código cargado es erróneo o se venció el periodo definido para su validez, debe mostrarse en la Consola nuevamente el modal anterior

• Se informa que el Código es erróneo

• Solicita el envío de un nuevo SMS para volver a cargar el nuevo Código

La cantidad de veces que un código puede ser cargado sin ser correcto debe ser un parámetro a definir a nivel de la Asociación.

Este campo es obligatorio y numérico aceptando solo dígitos mayores a 0 y hasta 10 . De esta forma:

1. Si se deja el campo en 0 se debe mostrar el mensaje: El importe debe ser mayor a 0

2. Si se carga un valor mayor a 10 se debe mostrar el mensaje: El importe debe ser menor o igual a 10

Ejemplo: Código de verificación cargado en 3 intentos

Se puede rechazar hasta tres veces un código por ser erróneo. Al rechazar el siguiente intento, la solicitud debe ser rechazada.

En la Consola del Comercio se debe mostrar un modal similar al siguiente:

Al Aceptar el registro en la sección Prestamos debe mostrar el estado Rechazado y con el sub estado Celular no verificado.

1.3 Plazo de pagos de liquidaciones

Cuando el Préstamo fue otorgado y el Cliente adquiere el bien motivo del mismo, el Lender debe liquidar el Comercio el Importe financiado

El plazo para estos pagos desde que el Préstamo pasa a estado Aprobado debe estar definido desde Asociaciones.

Este campo es obligatorio y numérico aceptando solo dígitos mayores a 0 y hasta 10 . De esta forma:

• Si se deja el campo en 0 se debe mostrar el mensaje: El importe debe ser mayor a 0

• Si se carga un valor mayor a 10 se debe mostrar el mensaje: El importe debe ser menor o igual a 10

1.4 Comisiones a abonar

De acuerdo a definiciones del Negocio, el Comercio debería cobrar una comisión por cada otorgamiento, es decir, por cada Solicitud de Préstamo que llega al estado Aprobado

La comisión a abonar al Comercio puede ser:

• Un % sobre el Importe a financiar que puede o no incluir un piso y un tope. A definir calculo

• Un monto fijo independientemente del Importe a financiar

La definición del esquema de comisiones debe ser cargada a nivel de la Asociación

Criterios de carga:

Si se carga una comisión solo debe poder seleccionar una de las dos opciones:

• El esquema variable

• El esquema fijo

Pero para la opción de esquema variable , se puede o no definir importes de piso y de base.

Adicionalmente la carga de comisiones no son obligatorias, es decir, puede haber una Asociación para la cual no se abonen comisiones. Si fuera así, las secciones de Comisiones en ambas Consolas (a detallar mas adelante) deben estar grisadas

Si se completan ambos son numéricos:

1. Para la opción de % se deben aceptar dígitos mayores a 0 y hasta 100. Para los pisos y topes se deben aceptar dígitos desde 0 y hasta 500.000.

   1. Si se deja el campo % en 0 se debe mostrar el mensaje: El % debe ser mayor a 0

   2. Si se carga un valor % mayor a 100 se debe mostrar el mensaje: El % debe ser menor o igual a 100.

   3. Si se carga un piso y un tope, el importe del tope no puede ser menor al piso: El importe del tope no puede ser inferior al piso.

2. Para la opción de importe fijo se deben aceptar dígitos mayores a 0 y hasta 500.000.

   1. Si se deja el campo en 0 se debe mostrar el mensaje: El importe debe ser mayor a 0

   2. Si se carga un valor mayor a 100 se debe mostrar el mensaje: El importe debe ser menor o igual a 500.000.

A definir mas adelante calculo y disponibilizacion de comisiones a pagar

1.5 Plazo de pago de comisiones

Como se detallará en el punto sobre la sección Comisiones, a diferencia de lo especificado para las liquidaciones al Comercio de los importes financiados en cuanto a pagos constantes en base a las fechas de otorgamientos para el caso del pago de comisiones se debe realizar uno por periodo incluyendo todas las comisiones calculadas en el mismo.

A nivel de Asociación, es necesario en principio definir el período de negocio en el cual se generaran comisiones a pagar para luego determinar en que plazo se pagaran esas comisiones

En un principio las opciones a seleccionar para el Período de negocio para comisiones pueden ser las siguientes:

• Mes calendario

• Quincena calendario

• Semana calendario

¿Cómo es el Periodo de negocio cada selección ?

1. Para el Mes calendario se toman los Prestamos desde el 01 al ultimo día de cada mes

2. Para la Quincena calendario se toman los Prestamos desde el 01 al 15 y desde el 16 hasta el ultimo día de cada mes. Hay dos períodos de negocio en un mes

3. Para la Semana calendario se toman los Prestamos desde el 01 al 7, desde el 8 al 14, desde el 15 al 21 y desde el 22 hasta el ultimo día de cada mes. Hay cuatro períodos de negocio en un mes

Las opciones pueden ser diferentes y pueden cambiar.

La selección de una opción es obligatoria si se definió un esquema de comisiones

El plazo para el pago de comisiones se define a partir de la finalización del periodo de negocio en cada mes:

Este campo es obligatorio y numérico aceptando solo dígitos mayores a 0 y hasta 10 . De esta forma:

• Si se deja el campo en 0 se debe mostrar el mensaje: El importe debe ser mayor a 0

• Si se carga un valor mayor a 10 se debe mostrar el mensaje: El importe debe ser menor o igual a 10

¿ Cómo aplica esta doble selección?

Ejemplo:

• Período de negocio para comisiones: Mes calendario

• Plazo para el pago de comisiones: 2 días hábiles

Para el mes de octubre:

• Período de negocio para comisiones: Del miércoles 01 de octubre al viernes 31 de octubre

• Plazo para el pago de comisiones: 2 días hábiles

Las comisiones se pagarán entonces el lunes 03 de noviembre

Ejemplo:

• Período de negocio para comisiones: Semana calendario

• Plazo para el pago de comisiones: 2 días hábiles

Para el mes de octubre:

• Períodos de negocio para comisiones:

  • Del miércoles 01 de octubre al martes 07 de octubre

  • Del miércoles 08 de octubre al martes 14 de octubre

  • Del miércoles 15 de octubre al martes 21 de octubre

  • Del miércoles 22 de octubre al viernes 31 de octubre

• Plazo para el pago de comisiones: 2 días hábiles

  • Para el Período del miércoles 01 de octubre al martes 07 de octubre: jueves 09 de octubre

  • Para el Período del miércoles 08 de octubre al martes 14 de octubre: jueves 16 de octubre

  • Para el Período del miércoles 15 de octubre al martes 21 de octubre: jueves 23 de octubre

  • Para el Período del miércoles 22 de octubre al viernes 31 de octubre: martes 04 de noviembre

2. Consola Lender

Se avanzará en el presente Sprint en la sección del Menú:

• Liquidaciones

• Comisiones (nueva sección no detallada en el Sprint 35 que se debe posicionar luego de Liquidaciones y antes de Planes)

• Modificaciones en Prestamos

2.1 Liquidaciones

Esta sección debe permitir la gestión de pagos a los Comercios, de los Importes financiados a los Clientes finales, muy similar a la actualmente desarrollada para el pago de liquidaciones a los Proveedores en el Modelo B2B WC

Al seleccionar Liquidaciones se debe acceder a una pantalla similar a la de Liquidaciones en la Consola de Lapachos Lending del Modelo B2B WC.

• Titulo: Liquidaciones

• Filtros:

  • Nombre de la Entidad

  • ID Comercio

  • Estado

  • Ordenar por

    • Nombre de la Entidad

    • ID Comercio

    • Fecha de liquidación

    • Fecha de pago

• Columnas:

  • Detalle

  • Nombre de la Entidad

  • ID Comercio

  • Fecha de liquidación

  • Fecha de pago

  • Importe a pagar

  • Estado: Pendiente, Pago confirmado y Pago no confirmado

  • Acciones: Informar pago

Importante:

1. La Fecha de liquidación es la fecha definida para abonar la liquidación en base a la fecha de otorgamiento + Campo Plazo de pago para un determinado Comercio

2. El Importe a pagar es la suma de todas los importes financiados a liquidar en una determinada fecha para un Comercio

Cada registro debe mostrar el total a abonar a un determinado Comercio en una determinada fecha.

La generación de cada registro debe realizarse a las 0 hs. del día corrido siguiente, de forma tal que refleje el total de liquidaciones derivadas del total de otorgamientos del día.

Ejemplo:

Liquidaciones pendientes:

Se debe mostrar:

El registro en estado Pendiente se genera cuando el Préstamo pasa a estado Aprobado. La única acción posible es Informar pago

En Detalle se debe mostrar el listado de Prestamos que componen esa Liquidación de forma tal que el Lender tenga una información mas detallada de lo que debe abonar. Al seleccionarlo se solicita mostrar el titulo Información de financiamiento y un modal similar al siguiente:

La otra opción en Detalle, Historial, se debe mostrar el recorrido de los estados: Pendiente, Pago con firmado y Pago no confirmado

A detallar procesos de pago manual y pago automático en el punto 3

2.2 Comisiones

Como se mencionó anteriormente, las comisiones se disponibilizarán y por ende abonarán una vez por mes y estarán basadas en los otorgamientos de un determinado periodo de negocio.

Esta sección debe permitir la gestión de pagos de Comisiones, muy similar a la actualmente desarrollada para el pago de liquidaciones a los Proveedores en el Modelo B2B WC

Al seleccionar Comisiones se debe acceder a una pantalla similar a la de Liquidaciones en la Consola de Lapachos Lending del Modelo B2B WC.

• Titulo: Comisiones

• Filtros:

  • Nombre de la Entidad

  • ID Comercio

  • Estado

  • Ordenar por

    • Nombre de la Entidad

    • ID Comercio

    • Fecha de liquidación

    • Fecha de pago

• Columnas:

  • Detalle

  • Nombre de la Entidad

  • ID Comercio

  • Fecha de liquidación

  • Fecha de pago

  • Importe a pagar

  • Estado: Pendiente, Pago confirmado y Pago no confirmado

  • Acciones: Informar pago

Importante:

1. La Fecha de liquidación es la fecha definida para abonar las comisiones calculadas durante el Campo Período de negocio + Campo Plazo de pago para un determinado Comercio

2. El Importe a pagar es la suma de todas las comisiones liquidar para un Comercio

Cada registro debe mostrar el total a abonar a un determinado Comercio en una determinada fecha.

La generación de cada registro debe realizarse a las 0 hs. del día corrido siguiente a la finalización del período de negocio, de forma tal que refleje el total de comisiones derivadas del total de otorgamientos del día.

Se adjunta Excel con ejemplo de calculo de comisiones

https://docs.google.com/spreadsheets/d/1wgGkb2g6vz6kbWZA2EjLsgZyzUwL_iZzgEYHHIBkZkc/edit?gid=1760778394#gid=1760778394

El registro en estado Pendiente se genera cuando el finaliza el Período de negocio para los Préstamos en estado Aprobado. La única acción posible es Informar pago

En Detalle se debe mostrar el listado de Comisiones que componen esa liquidación de forma tal que el Lender tenga una información mas detallada de lo que debe abonar. Al seleccionarlo se solicita mostrar el titulo Información de financiamiento y un modal similar al siguiente:

La otra opción en Detalle, Historial, se debe mostrar el recorrido de los estados: Pendiente, Pago con firmado y Pago no confirmado

A detallar procesos de pago manual y pago automático en el punto 3

2.3 Préstamos

En el Sprint 35 se solicitó el desarrollo de la sección de Prestamos para el Modelo B2C Consumo en considerando en un principio que la misma no incluía acciones posibles por parte del Lender.

Por definición de Producto, la acción de pago de un Préstamo por parte de un Cliente final se realiza por fuera de las Consolas y el Lender solo podrá acceder a la información asociada a los pagos por reportes externos (a definir fuente, periodicidad, formato, etc.)

En base a lo anterior, el Lender debe poder informar el pago de cada cuota en su Consola de forma tal de actualizar el disponible del Cliente y la evolución de cada financiación.

Se solicita incorporar los campos en negrita al detalle:

• Tipo de documento Cliente

• Nro. de documento Cliente

• Nombre y Apellido Cliente

• Fecha emisión

• Fecha de vencimiento (fecha de vencimiento de la ultima cuota)

• ID Comercio

• Importe financiado.

• Importe del Préstamo

• Cuotas

• Estado: Aprobado, Pago cuota confirmado y Pago confirmado

• Acciones: Validar pago de cuota

La nueva columna Cuotas debe tener el formato XX/XX donde las X son números y corresponden a:

1. Los dos primeros dígitos deben mostrar las cuotas abonadas

2. Los segundos dígitos deben mostrar el total de cuotas.

Ejemplo:

---> Si un Préstamo se otorgó en una solo cuota: 00/01. Al abonar el mismo en la fecha de vencimiento: 01/01

---> Si un Préstamo se otorgó en tres cuotas : 00/03. Al ir abonando las cuotas en los vencimientos: 01/03, 02/03 y finalmente 03/03.

Al seleccionar Validar pago de cuota sobre el registro del Préstamo se debe acceder a un modal similar al siguiente:

En el cual se muestren los siguientes datos:

• Detalle del plan de cuotas a pagar (grisado)

• Fecha de vencimiento de cada cuota (grisado)

• Importe cobrado para cada cuota

• Referencia: campo libre que acepte valores alfanuméricos. Máximo de 50 caracteres y no mandatorio

• Comprobante de pago. Debe permitir subir archivos pero no debe ser mandatorio

Los campos grisados no pueden ser modificados.

¿Cuándo se puede validar el pago de una cuota?

• El Préstamo debe estar en estado Aprobado.

• A definir otras posibles condiciones

A medida que se van pagando las cuotas se deben ir completando los campos correspondientes

Con el objetivo de evitar errores en la validación de cuotas (ejemplo: por error valido el pago de la Cuota 4 en vez de la Cuota 2) se define que solo se puede validar la cuota con la Fecha de vencimiento mas cercana a la fecha actual y sin pago registrado anterior (es decir, en estado Pago cuota confirmado) . Se deben cumplir ambas condiciones.

Cuando el Lender valida el pago el estado del Préstamo debe pasar a un nuevo estado: Pago cuota confirmado.

La acción de Validar pago cuota se vuelve a habilitar para el pago de las siguientes cuotas pero el estado no cambia hasta tanto se informe el pago de la última cuota pasando de Pago cuota confirmado a Pago confirmado e inhabilitado la acción de Validar pago de cuota.

Importante: NO se esta contemplando el pago con mora o la falta de pago de una cuota

3. Consola Comercio

Se avanzará en el presente Sprint en la sección del Menú:

• Liquidaciones

• Comisiones

3.1 Liquidaciones

La sección Liquidaciones del Menú NO incluirá acciones posibles por parte del Comercio. Esto implica que solo permitirá visualizar las Liquidaciones en sus diferentes estados: Pendiente, Pago confirmado o Pago no confirmado.

Al seleccionar Liquidaciones se debe acceder a una pantalla similar a la de Liquidaciones en la Consola del Proveedor del Modelo B2B WC.

• Titulo: Liquidaciones

• Filtros:

  • Estado

  • Ordenar por

    • Fecha de liquidación

    • Fecha de pago

• Columnas:

  • Detalle

  • Fecha de liquidación

  • Fecha de pago

  • Importe a cobrar

  • Estado: Pendiente, Pago confirmado y Pago no confirmado

Importante:

1. La Fecha de liquidación es la fecha definida para abonar la liquidación en base a la fecha de otorgamiento + Campo Plazo de pago para un determinado Comercio

2. El Importe a cobrar es la suma de todas los importes financiados a liquidar en una determinada fecha para un Comercio

Cada registro debe mostrar el total a abonar a un determinado Comercio en una determinada fecha.

La generación de cada registro debe realizarse a las 0 hs. del día corrido siguiente, de forma tal que refleje el total de liquidaciones derivadas del total de otorgamientos del día.

En Detalle se debe mostrar el listado de Prestamos que componen esa Liquidación de forma tal que el Comercio tenga una información mas detallada de lo que debe cobrar. Al seleccionarlo se solicita mostrar el titulo Información de financiamiento y un modal similar al siguiente:

La otra opción en Detalle, Historial, se debe mostrar el recorrido de los estados: Pendiente, Pago con firmado y Pago no confirmado

A detallar procesos de pago manual y pago automático en el punto 4

3.2 Comisiones

La sección Comisiones del Menú NO incluirá acciones posibles por parte del Comercio. Esto implica que solo permitirá visualizar las comisiones en sus diferentes estados: Pendiente, Pago confirmado o Pago no confirmado.

Al seleccionar Comisiones se debe acceder a una pantalla similar a la de Liquidaciones en la Consola del Proveedor del Modelo B2B WC.

• Titulo: Comisiones

• Filtros:

  • Estado

  • Ordenar por

    • Fecha de liquidación

    • Fecha de pago

• Columnas:

  • Detalle

  • Fecha de liquidación

  • Fecha de pago

  • Importe a cobrar

  • Estado: Pendiente, Pago confirmado y Pago no confirmado

Importante:

1. La Fecha de liquidación es la fecha definida para abonar las comisiones calculadas durante el Campo Período de negocio + Campo Plazo de pago para un determinado Comercio

2. El Importe a cobrar es la suma de todas las comisiones liquidar para un Comercio

Cada registro debe mostrar el total a abonar a un determinado Comercio en una determinada fecha.

La generación de cada registro debe realizarse a las 0 hs. del día corrido siguiente a la finalización del período de negocio, de forma tal que refleje el total de comisiones derivadas del total de otorgamientos del día.

En Detalle se debe mostrar el listado de Comisiones que componen esa liquidación de forma tal que el Comercio tenga una información mas detallada de lo que debe cobrar. Al seleccionarlo se solicita mostrar el titulo Información de financiamiento y un modal similar al siguiente:

La otra opción en Detalle, Historial, se debe mostrar el recorrido de los estados: Pendiente, Pago con firmado y Pago no confirmado

A detallar procesos de pago manual y pago automático en el punto 5

4. Pago de Liquidaciones

Para el pago de Liquidaciones se deben desarrollar los flujos y tareas asociadas tanto para:

• Pago manual

• Pago automático

En ambos casos, idénticos a los ya implementados para el pago de Liquidaciones en el Modelo B2B WC.

4.1 Pago manual de Liquidaciones

Consola Lender

Cuando se selecciona Informar pago se debe mostrar lo siguiente:

Titulo: Informar pago de liquidación

Con los datos:

• Fecha de liquidación

• Fecha de pago. Campo obligatorio a completar. La misma no debe ser posterior a la fecha de ejecución. Habilitar el calendario para la selección de la fecha.

• Importe pagado. Campo obligatorio a completar informando el importe que efectivamente abonó. Formato numérico que acepte decimales.

Los campos para el comprobante de pago y de retenciones se mantienen.  

Por definición de Producto, la acción de informar el pago de una Liquidación implica el cambio de estado del Pendiente a Pago confirmado. Esto quiere decir que lo que informa el Lender se toma como cierto.

Adicionalmente se deben actualizar los datos incluidos en Detalle en la sección de Liquidaciones del Menú, dado que deben mostrar la información asociada al pago y ya no las de financiamiento:

Pendiente detallar notificaciones y validaciones

Consola Comercio

Cuando el estado de la Liquidación pasa a Pago confirmado se deben actualizar los datos incluidos en Detalle en la sección de Liquidaciones del Menú, dado que deben mostrar la información asociada al cobro y ya no las de financiamiento:

Pendiente detallar notificaciones y validaciones

¿Qué pasa si el Comercio no acepta o no considera correcto el pago realizado por el Lender?

Se solicita incluir una nueva sección con el nombre Gestiones al Lender (tal cual esta incluida para el Modelo B2C WC) en el menú de la Consola del Comercio:

• Inicio. A desarrollar en próximos sprints. Dejar grisado sin opción de acceder.

• Préstamos

• Clientes.

• Liquidaciones.

• Comisiones

• Gestiones al Lender

Al seleccionar esta ultima, se debe mostrar la opción de Reclamo por liquidaciones o comisiones no registradas

Titulo: Reclamo por liquidaciones o comisiones no registradas

Campos a seleccionar:

• Tipo de cobro. Se debe poder seleccionar entre dos opciones: Liquidación o Comisión

• Fecha de liquidación. Solo se deben disponibilizar las fechas asociadas a registros con estado Pago confirmado

• Motivo de rechazo:

  • Importe incorrecto

  • Comprobante erróneo

  • Falta comprobante

Al seleccionar Aceptar

La acción de reclamar la revisión del pago no modifica el estado del Pago confirmado

Pendiente detallar notificaciones y validaciones

Consola Lender

Se solicita incluir una nueva sección con el nombre Solicitudes a completar (tal cual esta incluida para el Modelo de negocio B2C WC) en el menú de la Consola del Lender:

• Inicio. A desarrollar en próximos sprints. Dejar grisado sin opción de acceder.

• Clientes.

• Comercios

• Prestamos

• Liquidaciones

• Comisiones

• Planes

• Relaciones y planes A desarrollar en próximos sprints. Dejar grisado sin opción de acceder.

• Roles y perfiles. A desarrollar en próximos sprints. Dejar grisado sin opción de acceder.

• Solicitudes a completar

Al seleccionar esta ultima, se debe mostrar la opción de Envió de comprobante de liquidaciones o comisiones pagadas accediendo a una pantalla similar a la de la misma opción para el Modelo B2B WC.

• Titulo: Envió de comprobante de liquidaciones o comisiones

• Filtros:

  • Nombre de la Entidad

  • ID Comercio

  • Tipo de pago

  • Ordenar por

    • Nombre de la Entidad

    • ID Comercio

    • Fecha de liquidación

    • Fecha de pago

• Columnas:

  • Detalle

  • Nombre de la Entidad

  • ID Comercio

  • Tipo de pago (Liquidación o Comisión)

  • Fecha de liquidación

  • Fecha de pago (Fecha informada por el Lender en el primer pago)

  • Importe a pagar

  • Acciones: Actualizar pago

Al acceder a Detalle se deben mantener los datos asociados al pago realizado por el Lender dependiendo del Tipo de pago:

1. Si el reclamo esta asociado al pago de una liquidación:

2. Si el reclamo esta asociado al pago de una comisión:

Al seleccionar Actualizar pago se repetir el proceso detallado anteriormente debiendo el Lender completar todos los campos del modal de Informar pago

Importante: Teniendo en cuenta que al informar nuevamente el pago puede haber cambios se deben actualizar los datos incluidos en Detalle en la sección de Liquidaciones del Menú

Pendiente detallar notificaciones y validaciones 

Consola Comercio

La acción de informar nuevamente el pago de la liquidación debe actualizar los datos incluidos en Detalle en la sección de Liquidaciones del Menú.

Por definición de Producto, el reenvío o la actualización de los datos del pago de la Liquidación por el Lender solo generará notificaciones al Comercio (a definir como) cerrando el proceso de pago manual de Liquidaciones

Cualquier reclamo posterior del Comercio deberá gestionarse por fuera de los flujos de las Consolas.

Pendiente detallar notificaciones y validaciones 

4.2 Pago automático de Liquidaciones

4.2.1 Generación transacción PayOut

Cuando se genera la Liquidación en estado Pendiente y existe una integración con un riel de pagos, se debe generar una Transacción de PayOut (TX) con el estado Pago programado que debe contener los siguientes datos:

• Importe a debitar (Importe de la Liquidación)

• Cuenta bancaria a realizar el debito. (Cuenta del Lender informada en los datos de alta del mismo)

• Cuenta bancaria a realizar el crédito (Cuenta del Comercio informada en los datos de alta del mismo)

• Fecha de debito (Fecha de liquidación)

• Otros datos a definir (agregar: moneda, referencia de pago, concepto, etc.). Customización a nivel mercado.

Los datos detallados son considerados como mínimos pero dependiendo del Mercado, puede haber campos adicionales: tipo de cuenta origen / destino. Si coincide el titular, tipo de transferencia (honorarios / factura / etc.).

Consola Lender

Al generar una TX para la ejecución automática de la Liquidación, en la Consola del Lender se debe deshabilitar la opción de Informar pago a fin de no permitir la posible duplicidad de pago (manual y automática)

Al querer seleccionar el icono usado para Informar Pago debe aparecer el texto: Pago programado

4.2.2 Ejecución transacción PayOut

Cuando se llega a la Fecha de liquidación de la Liquidación, se debe ejecutar la TX, es decir, solicitar al riel de pagos que debite en la cuenta del Lender y acredite en la Cuenta del Comercio el Importe de la Liquidación, pasando la misma al estado Pago en proceso.

De acuerdo al tipo de implementación que se realiza con el riel de pago, se puede tener ejecuciones programadas por lotes o bien ejecuciones online.

a. Ejecución por lotes: Seguramente se deberá generar y subir un archivo a un sitio indicado por el riel, X días antes de la ejecución. Una vez resueltas las TXs se recibirá o descargará el archivo con los resultados por TX.

b. Ejecución online: Seguramente existirán APIs que utilizaremos para el envío y recepción de respuestas sobre el resultado de cada TX.

Durante el proceso de ejecución, en la Consola del Lender se debe mantener deshabilitada la opción de Informar pago a fin de no permitir la posible duplicidad de pago (manual y automática)

Al querer seleccionar el icono usado para Informar Pago debe aparecer el texto: Pago en proceso

Independientemente del esquema de integración con el riel de pagos, la respuesta del mismo con los resultados de la/s TX/s puede ser:

4.2.2.1 Transacción aprobada

Ante la respuesta satisfactoria del riel:

• La TX pasa al estado Pago confirmado

• La Liquidación pasa a Pago confirmado (tanto en la Consola del Lender como en la Consola del Comercio).

• El icono usado para Informar pago en la Consola del Lender debe estar deshabilitado.

• Se deben actualizar los datos incluidos en Detalle en la sección de Liquidaciones del Menú de ambas Consolas dado que deben mostrar la info asociada al pago y ya no las de financiamiento:

Consola Comercio

Cuando el estado de la Liquidación pasa a Pago confirmado se deben actualizar los datos incluidos en Detalle en la sección de Liquidaciones del Menú, dado que deben mostrar la información asociada al cobro y ya no las de financiamiento:

Por definición de Producto, la respuesta afirmativa del riel se considera como definitiva de forma tal que si el Comercio tiene algún reclamo o diferencia en la acreditación de la Liquidación, deberá gestionarse por fuera de los flujos de las Consolas.

4.2.2.2 Transacción rechazada

Se definen tres motivos por los cuales un pago no puede ser confirmado dada la respuesta del riel:

• Pago rechazado - Error cuenta origen o destino (cuenta inhabilitada o inexistente)

• Pago rechazado - Cuenta origen sin fondos (sin fondos disponibles)

• Pago rechazado - Falla técnica (timeout, error de comunicación, otros)

4.2.2.2.1 Pago rechazado por cuentas inexistentes/inhabilitadas

Las acciones a implementar dependerán del sub motivo del rechazo

4.2.2.2.1.1 Pago rechazado por error en cuenta origen

Cuando no se logra hacer el debito en la cuenta informada por el Lender:

• La TX pasa al estado Pago rechazado - Error cuenta origen

• La Liquidación pasa a Pago no confirmado (tanto en la Consola del Comercio como en la Consola del Lender).

• El icono usado para Informar pago en la Consola del Lender se debe habilitar (esto implica generar un nuevo pago en estado Pendiente por informar)

Importante: Cuando la TX para el pago de una Liquidación es rechazada por un error en la cuenta origen se debe permitir que el Lender informe el pago independientemente del momento en el cual se le solicite la actualización de su cuenta o la realiza.

Esto se debe a que, dado que siempre se pasa al proceso manual cuando hay un rechazo por error en cuenta origen, no es necesario esperar a la actualización de cuenta para permitirlo.

Este cambio debe aplicar también en el Modelo B2C WC para las TX rechazadas por error en cuenta origen del:

• Comprador para el pago de Prestamos

• Lender para el pago de Liquidaciones

Consola Admin

De la misma forma que sucede con TXs rechazadas por error en la cuenta de debito del Lender para el pago a un Proveedor en el Modelo B2B WC, el Admin debe generar la tarea de Actualización de cuenta bancaria dentro de la sección Gestiones al Lender de su consola cuando la TX para el pago de una Liquidación a un Comercio se rechaza.

Se solicita hacer los siguientes cambios en la tarea de actualización de cuenta de debito:

• Tanto para el Modelo B2B WC como para el B2C Consumo el campo Tipo de operación debe estar grisado hasta tanto se seleccione la Asociación.

• Eliminar la selección de Habilitar opción de informar pago para cualquier Modelo de negocio.

Actualmente para cualquier TX rechazada por cuenta errónea se debe pagar en forma manual dicha operación modificando la cuenta para las futuras.

• La selección de una Asociación, debe definir la habilitación de los campos siguientes:

a. Si es una Asociación con el Modelo B2B WC se habilitan:

1. Tipo de operación

2. Nro. de factura

b. Si es una Asociación con el Modelo B2C Consumo no se habilitan los demás campos.

¿Qué implica esto?

Para este modelo de negocio, al menos en una primera instancia, la nueva cuenta aplica a todo pago por parte del Lender, independientemente del tipo, ID de operación o fecha de liquidacion

Al Aceptar el pedido de actualización

 Consola Lender

Dentro de la sección Solicitudes a completar, se debe agregar la opción Actualización de cuenta bancaria

• Titulo: Actualizar cuenta bancaria

• Filtros:

  • Nombre de la Entidad

  • ID Comercio

• Ordenar por

  • Nombre de la Entidad

  • ID Comercio

  • Fecha de liquidación

• Columnas:

  • Detalle

  • Nombre de la Entidad

  • ID Comercio

  • Fecha de liquidación

  • Importe a pagar

  • Acciones: Actualizar cuenta bancaria

Al acceder a Detalle se debe mostrar un modal similar a

Al seleccionar Actualizar cuenta bancaria

Importante: Se debe eliminar la opción de Liquidación vencida no pagada inclusive en el Modelo B2B WC dado que en Sprints anteriores se definió que cuando una TX es rechazada por error en la cuenta de debito o de crédito, la operación asociada a la misma se debe pagar en forma manual. La nueva cuenta aplica para las operaciones programadas en el futuro

Cuando impacta el cambio en la cuenta, se deben pasar al estado Pago cancelado todas las TXs asociadas a las Liquidaciones en estado Pendiente, generando nuevas TXs con el dato de la nueva cuenta en estado Pago programado asociándolas a las mismas Liquidaciones.

Importante: Al menos en un principio para el caso de pagos de Liquidaciones, no se define tiempos para completar la tarea de actualización de cuenta bancaria y/o selección de Informar pago.

4.2.2.2.1.2 Pago rechazado por error en cuenta destino

Cuando no se logra hacer el crédito en la cuenta informada por el Comerio:

• La TX pasa al estado Pago rechazado - Error cuenta destino

• La Liquidación pasa a Pago no confirmado (tanto en la Consola del Comercio como en la Consola del Lender).

• Al seleccionar el icono de Informar pago en la Consola del Lender debe aparecer el texto Pago no confirmado.

Importante: Si existe como servicio la consulta de validez de la cuenta, previo a realizar la transacción, evaluar la posibilidad de poder hacerlo.

Consola Lender

Se solicita agregar una nueva sección en el Menú para las Gestiones al Comercio.

• Inicio. A desarrollar en próximos sprints. Dejar grisado sin opción de acceder.

• Clientes.

• Comercios

• Prestamos

• Liquidaciones

• Comisiones

• Planes

• Relaciones y planes A desarrollar en próximos sprints. Dejar grisado sin opción de acceder.

• Roles y perfiles. A desarrollar en próximos sprints. Dejar grisado sin opción de acceder.

• Gestiones al Comercio

• Solicitudes a completar

Al seleccionar Gestiones al Comercio, se debe mostrar un formato similar al que hoy se aplica para la Actualización de cuenta bancaria en el Modelo B2B WC

Titulo: Actualización de cuenta bancaria

• Nombre de la Entidad

• Fecha de liquidación

Consola Comercio

Se solicita agregar una nueva sección en el Menú para las Solicitudes a completar.

• Inicio. A desarrollar en próximos sprints. Dejar grisado sin opción de acceder.

• Préstamos

• Clientes.

• Liquidaciones.

• Comisiones

• Gestiones al Lender

• Solicitudes a completar

Al seleccionar Solicitudes a completar, se debe mostrar un formato similar al que hoy se aplica para la Actualización de cuenta bancaria en el Modelo de Negocio B2B WC

• Titulo: Actualizar cuenta bancaria

• Filtros:

  • Fecha de liquidación

• Ordenar por

  • Fecha de liquidación

• Columnas:

  • Detalle

  • Fecha de liquidación

  • Importe a pagar

  • Acciones: Actualizar cuenta bancaria

Al acceder a Detalle se debe mostrar un modal similar a

Al seleccionar Actualizar cuenta bancaria

Consola Lender

Dentro de la sección Solicitudes a completar se debe agregar la opción Verificación de cuenta bancaria

• Titulo: Actualizar cuenta bancaria

• Filtros:

  • Nombre de la Entidad

  • ID Comercio

  • Fecha de liquidación

• Ordenar por

  • Nombre de la Entidad

  • ID Comercio

  • Fecha de liquidación

• Columnas:

  • Detalle

  • Nombre de la Entidad

  • ID Comercio

  • Fecha de liquidación

  • Importe a pagar

  • Acciones: Actualizar cuenta bancaria

Al acceder a Detalle se debe mostrar un modal similar al siguiente:

Al acceder a Verificar cuenta se accede a un modal similar a:

Si el Lender verifica que la cuenta informada es correcta y pertenece al Comercio:

Cuando impacta el cambio en la cuenta, se deben pasar al estado Pago cancelado todas las TXs asociadas a Liquidaciones en estado Pendiente, generando nuevas TXs con el nuevo dato de la cuenta en estado Pago programado asociándolas a las mismas Liquidaciones.

Por otro lado, se debe habilitar el icono de Informar pago para la Liquidación en estado Pago no confirmado y se avanza con el proceso de pago manual ya detallado. Esto implica generar un nuevo pago en estado Pendiente por informar

Si el Lender NO verifica que la cuenta informada es correcta y pertenece al Comercio se debe generar una nueva tarea de Actualización de cuenta bancaria en la sección de Solicitudes a completar en la Consola del Comercio.

Al seleccionar Actualizar cuenta se accede nuevamente a un modal similar al siguiente:

Se repite todo el proceso de Verificación de cuenta bancaria en la Consola del Lender

4.2.2.2.2 Pago rechazado por cuenta origen sin fondos

Cuando no se logra hacer el debito en la cuenta informada por el Lender porque la misma no tiene fondos suficientes:

• La TX pasa al estado Pago rechazado - Cuenta origen sin fondos

• La Liquidación pasa a Pago no confirmado (tanto en la Consola del Comercio como en la Consola del Lender).

• Al seleccionar el icono de Informar pago en la Consola del Lender debe aparecer el texto Pago no confirmado.

Cuando la TX es rechazada se debe poder gestionar políticas de reintentos. Las mismas son definidas a nivel de Mercado

• Importes: % del Importe a pagar (al menos por ahora aplica siempre el 100%).

• Cantidad de reintentos: A completar el campo.

• Periodicidad de reintentos: A completar el campo.

Pendiente definir en próximos Sprints el esquema de carga de las Políticas de reintentos a aplicar al Modelo B2C Consumo

Resultados de ejecución de reintentos

Si luego de alguno de los reintentos, se accede a fondos para el pago de la Liquidación se continua con el proceso detallado para la Transacción aprobada.

Si con los reintentos no logra cobrarse la Liquidación, se debe habilitar el icono de Informar pago y se avanza con el proceso de Pago manual. Esto implica generar un nuevo pago en estado Pendiente por informar

Pendiente de definir tiempos para informar el pago.

4.2.2.2.3 Pago rechazado por falla técnica

Esta situación sucede cuando por algún motivo, falla la comunicación entre el Admin y el riel de pago o entre el riel de pago y el Banco, no se logra generar el débito en la Cuenta bancaria del Lender:

• La TX pasa al estado Pago rechazado - Error técnico

• La Liquidación pasa a Pago no confirmado (tanto en la Consola del Comercio como en la Consola del Lender).

• Al seleccionar el icono de Informar pago en la Consola del Lender debe aparecer el texto Pago no confirmado.

   

  Cuando la TX es rechazada se debe poder gestionar políticas de reintentos. Las mismas son definidas a nivel de Mercado

  • Importes: % del Importe a pagar (al menos por ahora aplica siempre el 100%).

  • Cantidad de reintentos: A completar el campo.

  • Periodicidad de reintentos: A completar el campo.

  

  Pendiente definir en próximos Sprints el esquema de carga de las Políticas de reintentos a aplicar al Modelo de Negocio B2C Consumo

Resultados de ejecución de reintentos

Si luego de alguno de los reintentos, el error técnico se resuelve se continua con el proceso detallado para la Transacción aprobada.

Si con los reintentos no logra cobrarse la Liquidación, se debe habilitar el icono de Informar pago y se avanza con el proceso de Pago manual. Esto implica generar un nuevo pago en estado Pendiente por informar

Pendiente de definir tiempos para informar el pago.

5. Pago de Comisiones

Para el pago de Comisiones se deben desarrollar los flujos y tareas asociadas tanto para:

• Pago manual

• Pago automático

En ambos casos, idénticos a los ya implementados para el pago de Liquidaciones en el Modelo B2B WC.

5.1 Pago manual de Comisiones

Consola Lender

Cuando se selecciona Informar pago se debe mostrar lo siguiente:

Titulo: Informar pago de comisiones

Con los datos:

• Fecha de liquidación

• Fecha de pago. Campo obligatorio a completar. La misma no debe ser posterior a la fecha de ejecución. Habilitar el calendario para la selección de la fecha.

• Importe pagado. Campo obligatorio a completar informando el importe que efectivamente abonó. Formato numérico que acepte decimales.

Los campos para el comprobante de pago y de retenciones se mantienen.  

Por definición de Producto, la acción de informar el pago de Comisiones implica el cambio de estado del Pendiente a Pago confirmado. Esto quiere decir que lo que informa el Lender se toma como cierto.

Adicionalmente se deben actualizar los datos incluidos en Detalle en la sección de Comisiones del Menú, dado que deben mostrar la información asociada al pago y ya no las de financiamiento:

Pendiente detallar notificaciones y validaciones

Consola Comercio

Cuando el estado de la Comisión pasa a Pago confirmado se deben actualizar los datos incluidos en Detalle en la sección de Comisiones del Menú, dado que deben mostrar la información asociada al cobro y ya no las de financiamiento:

Pendiente detallar notificaciones y validaciones

¿Qué pasa si el Comercio no acepta o no considera correcto el pago realizado por el Lender?

Se solicita incluir una nueva sección con el nombre Gestiones al Lender (tal cual esta incluida para el Modelo B2C WC) en el menú de la Consola del Comercio:

• Inicio. A desarrollar en próximos sprints. Dejar grisado sin opción de acceder.

• Préstamos

• Clientes.

• Liquidaciones.

• Comisiones por venta.

• Gestiones al Lender

Al seleccionar esta ultima, se debe mostrar la opción de Reclamo por liquidaciones o comisiones no registradas

Titulo: Reclamo por liquidaciones o comisiones no registradas

Campos a seleccionar:

• Tipo de cobro. Se debe poder seleccionar entre dos opciones: Liquidación o Comisión

• Fecha de liquidación. Solo se deben disponibilizar las fechas asociadas a registros con estado Pago confirmado

• Motivo de rechazo:

  • Importe incorrecto

  • Comprobante erróneo

  • Falta comprobante

Al seleccionar Aceptar

Cambiar por ¡Reclamo enviado con éxito!

La acción de reclamar la revisión del pago no modifica el estado del Pago confirmado

 Pendiente detallar notificaciones y validaciones

Consola Lender

Se solicita incluir una nueva sección con el nombre Solicitudes a completar (tal cual esta incluida para el Modelo de negocio B2C WC) en el menú de la Consola del Lender:

• Inicio. A desarrollar en próximos sprints. Dejar grisado sin opción de acceder.

• Clientes.

• Comercios

• Prestamos

• Liquidaciones

• Comisiones

• Planes

• Relaciones y planes A desarrollar en próximos sprints. Dejar grisado sin opción de acceder.

• Roles y perfiles. A desarrollar en próximos sprints. Dejar grisado sin opción de acceder.

• Solicitudes a completar

Al seleccionar esta ultima, se debe mostrar la opción de Envió de comprobante de liquidaciones o comisiones pagadas accediendo a una pantalla similar a la de la misma opción para el Modelo B2B WC.

• Titulo: Envió de comprobante de liquidaciones o comisiones

• Filtros:

  • Nombre de la Entidad

  • Tipo de pago

  • Ordenar por

    • Nombre de la Entidad

    • Fecha de liquidación

    • Fecha de pago

• Columnas:

  • Detalle

  • Nombre de la Entidad

  • Tipo de pago (Liquidación o Comisión)

  • Fecha de liquidación

  • Fecha de pago (Fecha informada por el Lender en el primer pago)

  • Importe a pagar

  • Acciones: Actualizar pago

• Importe neto a pagar

• Acciones. Actualizar pago

Al acceder a Detalle se deben mantener los datos asociados al pago realizado por el Lender dependiendo del Tipo de pago:

1. Si el reclamo esta asociado al pago de una liquidación:

2. Si el reclamo esta asociado al pago de una comisión:

Al seleccionar Actualizar pago se repetir el proceso detallado anteriormente debiendo el Lender completar todos los campos del modal de Informar pago

Importante: Teniendo en cuenta que al informar nuevamente el pago puede haber cambios se deben actualizar los datos incluidos en Detalle en la sección de Liquidaciones del Menú

Pendiente detallar notificaciones y validaciones 

Consola Comercio

La acción de informar nuevamente el pago de la liquidación debe actualizar los datos incluidos en Detalle en la sección de Liquidaciones del Menú.

Por definición de Producto, el reenvío o la actualización de los datos del pago de la Liquidación por el Lender solo generará notificaciones al Comercio (a definir como) cerrando el proceso de pago manual de Liquidaciones

Cualquier reclamo posterior del Comercio deberá gestionarse por fuera de los flujos de las Consolas.

Pendiente detallar notificaciones y validaciones 

5.2 Pago automático de Liquidaciones

5.2.1 Generación transacción PayOut

Cuando se genera la Comisión en estado Pendiente y existe una integración con un riel de pagos, se debe generar una Transacción de PayOut (TX) con el estado Pago programado que debe contener los siguientes datos:

• Importe a debitar (Importe de la Comisión)

• Cuenta bancaria a realizar el debito. (Cuenta del Lender informada en los datos de alta del mismo)

• Cuenta bancaria a realizar el crédito (Cuenta del Comercio informada en los datos de alta del mismo)

• Fecha de debito (Fecha de liquidación)

• Otros datos a definir (agregar: moneda, referencia de pago, concepto, etc.). Customización a nivel mercado.

Los datos detallados son considerados como mínimos pero dependiendo del Mercado, puede haber campos adicionales: tipo de cuenta origen / destino. Si coincide el titular, tipo de transferencia (honorarios / factura / etc.).

Consola Lender

Al generar una TX para la ejecución automática de la Comisión, en la Consola del Lender se debe deshabilitar la opción de Informar pago a fin de no permitir la posible duplicidad de pago (manual y automática)

Al querer seleccionar el icono usado para Informar Pago debe aparecer el texto: Pago programado

5.2.2 Ejecución transacción PayOut

Cuando se llega a la Fecha de liquidación de la Comisión, se debe ejecutar la TX, es decir, solicitar al riel de pagos que debite en la cuenta del Lender y acredite en la Cuenta del Comercio el Importe de la Comisión, pasando la misma al estado Pago en proceso.

De acuerdo al tipo de implementación que se realiza con el riel de pago, se puede tener ejecuciones programadas por lotes o bien ejecuciones online.

a. Ejecución por lotes: Seguramente se deberá generar y subir un archivo a un sitio indicado por el riel, X días antes de la ejecución. Una vez resueltas las TXs se recibirá o descargará el archivo con los resultados por TX.

b. Ejecución online: Seguramente existirán APIs que utilizaremos para el envío y recepción de respuestas sobre el resultado de cada TX.

Durante el proceso de ejecución, en la Consola del Lender se debe mantener deshabilitada la opción de Informar pago a fin de no permitir la posible duplicidad de pago (manual y automática)

Al querer seleccionar el icono usado para Informar Pago debe aparecer el texto: Pago en proceso

Independientemente del esquema de integración con el riel de pagos, la respuesta del mismo con los resultados de la/s TX/s puede ser:

5.2.2.1 Transacción aprobada

Ante la respuesta satisfactoria del riel:

• La TX pasa al estado Pago confirmado

• La Comisión pasa a Pago confirmado (tanto en la Consola del Lender como en la Consola del Comercio).

• El icono usado para Informar pago en la Consola del Lender debe estar deshabilitado.

• Se deben actualizar los datos incluidos en Detalle en la sección de Comisiones del Menú de ambas Consolas dado que deben mostrar la info asociada al pago y ya no las de financiamiento:

Consola Comercio

Cuando el estado de la Liquidación pasa a Pago confirmado se deben actualizar los datos incluidos en Detalle en la sección de Comisiones del Menú, dado que deben mostrar la información asociada al cobro y ya no las de financiamiento:

Por definición de Producto, la respuesta afirmativa del riel se considera como definitiva de forma tal que si el Comercio tiene algún reclamo o diferencia en la acreditación de la Comisión, deberá gestionarse por fuera de los flujos de las Consolas.

5.2.2.2 Transacción rechazada

Se definen tres motivos por los cuales un pago no puede ser confirmado dada la respuesta del riel:

• Pago rechazado - Error cuenta origen o destino (cuenta inhabilitada o inexistente)

• Pago rechazado - Cuenta origen sin fondos (sin fondos disponibles)

• Pago rechazado - Falla técnica (timeout, error de comunicación, otros)

5.2.2.2.1 Pago rechazado por cuentas inexistentes/inhabilitadas

Las acciones a implementar dependerán del sub motivo del rechazo

5.2.2.2.1.1 Pago rechazado por error en cuenta origen

Cuando no se logra hacer el debito en la cuenta informada por el Lender:

• La TX pasa al estado Pago rechazado - Error cuenta origen

• La Comisión pasa a Pago no confirmado (tanto en la Consola del Comercio como en la Consola del Lender).

• El icono usado para Informar pago en la Consola del Lender se debe habilitar (esto implica generar un nuevo pago en estado Pendiente por informar)

Importante: Cuando la TX para el pago de una Comisión es rechazada por un error en la cuenta origen se debe permitir que el Lender informe el pago independientemente del momento en el cual se le solicite la actualización de su cuenta o la realiza.

Esto se debe a que, dado que siempre se pasa al proceso manual cuando hay un rechazo por error en cuenta origen, no es necesario esperar a la actualización de cuenta para permitirlo.

Este cambio debe aplicar también en el Modelo B2C WC para las TX rechazadas por error en cuenta origen del:

• Comprador para el pago de Prestamos

• Lender para el pago de Liquidaciones

Consola Admin

De la misma forma que sucede con TXs rechazadas por error en la cuenta de debito del Lender para el pago a un Proveedor en el Modelo B2B WC, el Admin debe generar la tarea de Actualización de cuenta bancaria dentro de la sección Gestiones al Lender de su consola cuando la TX para el pago de una Comisión a un Comercio se rechaza.

Se solicita hacer los siguientes cambios en la tarea de actualización de cuenta de debito:

• Tanto para el Modelo B2B WC como para el B2C Consumo el campo Tipo de operación debe estar grisado hasta tanto se seleccione la Asociación.

• Eliminar la selección de Habilitar opción de informar pago para cualquier Modelo de negocio.

Actualmente para cualquier TX rechazada por cuenta errónea se debe pagar en forma manual dicha operación modificando la cuenta para las futuras.

• La selección de una Asociación, debe definir la habilitación de los campos siguientes:

a. Si es una Asociación con el Modelo B2B WC se habilitan:

1. Tipo de operación

2. Nro. de factura

b. Si es una Asociación con el Modelo B2C Consumo no se habilitan los demás campos.

¿Qué implica esto?

Para este Modelo de negocio, al menos en una primera instancia, la nueva cuenta aplica a todo pago por parte del Lender, independientemente del tipo, ID de operación o fecha de liquidacion

Al Aceptar el pedido de actualización

 Consola Lender

Dentro de la sección Solicitudes a completar, se debe agregar la opción Actualización de cuenta bancaria

• Titulo: Actualizar cuenta bancaria

• Filtros:

  • Nombre de la Entidad

  • ID Comercio

• Ordenar por

  • Nombre de la Entidad

  • ID Comercio

  • Fecha de liquidación

• Columnas:

  • Detalle

  • Nombre de la Entidad

  • ID Comercio

  • Fecha de liquidación

  • Importe a pagar

  • Acciones: Actualizar cuenta bancaria

Al acceder a Detalle se debe mostrar un modal similar a

Al seleccionar Actualizar cuenta bancaria

Importante: Se debe eliminar la opción de Liquidación vencida no pagada inclusive en el Modelo B2B WC dado que en Sprints anteriores se definió que cuando una TX es rechazada por error en la cuenta de debito o de crédito, la operación asociada a la misma se debe pagar en forma manual. La nueva cuenta aplica para las operaciones programadas en el futuro

Cuando impacta el cambio en la cuenta, se deben pasar al estado Pago cancelado todas las TXs asociadas a las Comisiones en estado Pendiente, generando nuevas TXs con el dato de la nueva cuenta en estado Pago programado asociándolas a las mismas Comisiones.

Importante: Al menos en un principio para el caso de pagos de Liquidaciones, no se define tiempos para completar la tarea de actualización de cuenta bancaria y/o selección de Informar pago.

5.2.2.2.1.2 Pago rechazado por error en cuenta destino

Cuando no se logra hacer el crédito en la cuenta informada por el Comerio:

• La TX pasa al estado Pago rechazado - Error cuenta destino

• La Comisión pasa a Pago no confirmado (tanto en la Consola del Comercio como en la Consola del Lender).

• Al seleccionar el icono de Informar pago en la Consola del Lender debe aparecer el texto Pago no confirmado.

Importante: Si existe como servicio la consulta de validez de la cuenta, previo a realizar la transacción, evaluar la posibilidad de poder hacerlo.

Consola Lender

Se solicita agregar una nueva sección en el Menú para las Gestiones al Comercio.

• Inicio. A desarrollar en próximos sprints. Dejar grisado sin opción de acceder.

• Clientes.

• Comercios

• Prestamos

• Liquidaciones

• Comisiones

• Planes

• Relaciones y planes A desarrollar en próximos sprints. Dejar grisado sin opción de acceder.

• Roles y perfiles. A desarrollar en próximos sprints. Dejar grisado sin opción de acceder.

• Gestiones al Comercio

• Solicitudes a completar

Al seleccionar Gestiones al Comercio, se debe mostrar un formato similar al que hoy se aplica para la Actualización de cuenta bancaria en el Modelo B2B WC

Titulo: Actualización de cuenta bancaria

• Nombre de la Entidad

• Fecha de liquidación

Consola Comercio

Se solicita agregar una nueva sección en el Menú para las Solicitudes a completar.

• Inicio. A desarrollar en próximos sprints. Dejar grisado sin opción de acceder.

• Préstamos

• Clientes.

• Liquidaciones.

• Comisiones

• Gestiones al Lender

• Solicitudes a completar

Al seleccionar Solicitudes a completar, se debe mostrar un formato similar al que hoy se aplica para la Actualización de cuenta bancaria en el Modelo B2B WC

• Titulo: Actualizar cuenta bancaria

• Filtros:

  • Fecha de liquidación

• Ordenar por

  • Fecha de liquidación

• Columnas:

  • Detalle

  • Fecha de liquidación

  • Importe a pagar

  • Acciones: Actualizar cuenta bancaria

Al acceder a Detalle se debe mostrar un modal similar a

Al seleccionar Actualizar cuenta bancaria

Consola Lender

Dentro de la sección Solicitudes a completar se debe agregar la opción Verificación de cuenta bancaria

• Titulo: Actualizar cuenta bancaria

• Filtros:

  • Nombre de la Entidad

  • ID Comercio

  • Fecha de liquidación

• Ordenar por

  • Nombre de la Entidad

  • ID Comercio

  • Fecha de liquidación

• Columnas:

  • Detalle

  • Nombre de la Entidad

  • ID Comercio

  • Fecha de liquidación

  • Importe a pagar

  • Acciones: Actualizar cuenta bancaria

Al acceder a Detalle se debe mostrar un modal similar al siguiente:

Al acceder a Verificar cuenta se accede a un modal similar a:

Si el Lender verifica que la cuenta informada es correcta y pertenece al Comercio:

Cuando impacta el cambio en la cuenta, se deben pasar al estado Pago cancelado todas las TXs asociadas a Comisiones en estado Pendiente, generando nuevas TXs con el nuevo dato de la cuenta en estado Pago programado asociándolas a las mismas Comisiones.

Por otro lado, se debe habilitar el icono de Informar pago para la Comisión en estado Pago no confirmado y se avanza con el proceso de pago manual ya detallado. Esto implica generar un nuevo pago en estado Pendiente por informar

Si el Lender NO verifica que la cuenta informada es correcta y pertenece al Comercio se debe generar una nueva tarea de Actualización de cuenta bancaria en la sección de Solicitudes a completar en la Consola del Comercio.

Al seleccionar Actualizar cuenta se accede nuevamente a un modal similar al siguiente:

Se repite todo el proceso de Verificación de cuenta bancaria en la Consola del Lender

5.2.2.2.2 Pago rechazado por cuenta origen sin fondos

Cuando no se logra hacer el debito en la cuenta informada por el Lender porque la misma no tiene fondos suficientes:

• La TX pasa al estado Pago rechazado - Cuenta origen sin fondos

• La Comisión pasa a Pago no confirmado (tanto en la Consola del Comercio como en la Consola del Lender).

• Al seleccionar el icono de Informar pago en la Consola del Lender debe aparecer el texto Pago no confirmado.

Cuando la TX es rechazada se debe poder gestionar políticas de reintentos. Las mismas son definidas a nivel de Mercado

• Importes: % del Importe a pagar (al menos por ahora aplica siempre el 100%).

• Cantidad de reintentos: A completar el campo.

• Periodicidad de reintentos: A completar el campo.

Pendiente definir en próximos Sprints el esquema de carga de las Políticas de reintentos a aplicar al Modelo B2C Consumo

Resultados de ejecución de reintentos

Si luego de alguno de los reintentos, se accede a fondos para el pago de la Comisión se continua con el proceso detallado para la Transacción aprobada.

Si con los reintentos no logra cobrarse la Comisión, se debe habilitar el icono de Informar pago y se avanza con el proceso de Pago manual. Esto implica generar un nuevo pago en estado Pendiente por informar

Pendiente de definir tiempos para informar el pago.

5.2.2.2.3 Pago rechazado por falla técnica

Esta situación sucede cuando por algún motivo, falla la comunicación entre el Admin y el riel de pago o entre el riel de pago y el Banco, no se logra generar el débito en la Cuenta bancaria del Lender:

• La TX pasa al estado Pago rechazado - Error técnico

• La Comisión pasa a Pago no confirmado (tanto en la Consola del Comercio como en la Consola del Lender).

• Al seleccionar el icono de Informar pago en la Consola del Lender debe aparecer el texto Pago no confirmado.

   

  Cuando la TX es rechazada se debe poder gestionar políticas de reintentos. Las mismas son definidas a nivel de Mercado

  • Importes: % del Importe a pagar (al menos por ahora aplica siempre el 100%).

  • Cantidad de reintentos: A completar el campo.

  • Periodicidad de reintentos: A completar el campo.

  

  Pendiente definir en próximos Sprints el esquema de carga de las Políticas de reintentos a aplicar al Modelo B2C Consumo

Resultados de ejecución de reintentos

Si luego de alguno de los reintentos, el error técnico se resuelve se continua con el proceso detallado para la Transacción aprobada.

Si con los reintentos no logra cobrarse la Comisión, se debe habilitar el icono de Informar pago y se avanza con el proceso de Pago manual. Esto implica generar un nuevo pago en estado Pendiente por informar

Pendiente de definir tiempos para informar el pago.