Lapachos Lending : Sprint X

Introducción:

Sprint (de X semanas) de trabajo sobre la preparación del instanciado de Lend2B para el caso Goodyear Chile. Este ecosistema tendrá lógicas de negocio algo diferentes a lo que armamos para la DEMO de B2FI. El objetivo es construir esta instancia haciendo el máximo reciclaje posible de lo que ya tenemos.

Deberemos mantener el producto base almacenado para usos futuros, con sus ambientes tipo sandbox y producción.

Algunas definiciones base:

• Goodyear Chile únicamente operará con un modelo de extensión de cuentas por pagar. Una cuenta ancla emite facturas para su red de clientes. Se podrá extender el plazo de pago de esas facturas. No se utilizaran las funcionalidades de Adelantos de Cuentas por Cobrar.

• No existirá la posibilidad de ejecutar pagos directos sin financiamiento. Siempre habrá intermediación del Lender. Toda factura aprobada tendrá un proceso de extensión fijo y obligatorio.

• Al no tener la posibilidad de hacer el pago directo, toda factura aprobada termina siendo extendida. En definitiva, la misma aprobación de la factura generara directamente la solicitud de extensión.

• El modelo de financiamiento tiene un plan único, fijo y obligatorio para toda factura y todo cliente del ecosistema.

• La etapa de carga del “Prospecto Crediticio” dejara de existir. Esto simplifica el flujo de onboarding de nuevos Clientes.

• Modulo de Retenciones

Modelo Financiero-Crediticio:

El modelo que construimos para la demo de B2FI tiene varias distinciones respecto a lo que queremos construir ahora. Hago un breve repaso:

Cada cliente, a la hora de solicitar una extensión, definía una nueva fecha de pago que debía ser inferior a un máximo de dias de extensión configurados para su perfil.

Cada cliente tenía configurado un costo financiero personalizado.

Por cliente se definía un “porcentaje de traslado” que equivale a un porcentual de la tasa y de la comisión asumida por la cuenta ancla.

Paso a detallar la características del nuevo modelo:

La vida de una factura o cuenta por pagar/cobrar se dividirá en dos periodos distintos:

1. Financiación directa Goodyear (Cuenta Ancla): periodo entre el momento de la emisión de la factura y el momento de vencimiento original de la misma. Es un periodo único y fijo.

2. Extensión automática: periodo entre el primer vencimiento original y una nueva fecha de cancelación extendida. La distancia (en dias) tambien es única y fija.

Este plan de financiación es UNICO. Esto quiere decir que todo cliente y toda factura (al menos dentro de un mismo ecosistema) tendrá la misma estructura, los mismos plazos (para ambos periodos) y el mismo costo financiero (asumido siempre por la Cuenta Ancla en un 100%).

Las variables que definen el plan de financiación son:

1. Distancia periodo 1: marca los dias que hay entre la emisión y el primer vencimiento de factura.

2. Distancia periodo 2: marca los dias que hay entre el vencimiento original y la fecha única de extensión de la factura.

3. Costo financiero: es la TNA que asume en un 100% la Cuenta Ancla.

Las principales diferencias son:

• La Cuenta Ancla (el proveedor) dejara de definir una fecha de vencimiento original. Esa fecha se calcula partiendo de la fecha de emisión y sumando los dias del primer periodo.

• Al aprobar la factura se estará extendiendo el vencimiento a una distancia unica de extension. Esa fecha se calcula partiendo de la fecha original de vencimiento y sumando los dias del segundo periodo.

• La variable “% de traslado” dejara de existir. Todo el costo financiero será asumido al 100% por la Cuenta Ancla.

• El sistema comisional cambiara respecto a la forma de calcular cada comisión.

• La deuda Lender → Cuenta Ancla, que se materializa en la transacción de cancelación, tendrá un método de calculo distinto.

• La deuda Cliente → Lender, que se materializa en la transacción de extensión, tendrá un método de calculo distinto tambien.

Hitos del Sprint X

• Look and Feel B2FI a Lend2B

• Eliminar Adelantos. Únicamente estarán activas las funcionalidades de Extensiones

• Quitar carga de prospecto crediticio del flujo de onboarding de clientes

• Configuración crediticia general del ecosistema

• Configuración crediticia particular por cliente

• Flujo de carga de nueva factura

• Flujo de aprobación de factura

• Proceso de aprobación de solicitud de extensión

• Transacción de Cancelación

• Transacción de Extensión

• Sistema de comisiones

• Linea de crédito y disponibles

• Retenciones

Look and Feel B2FI

In Progress

Eliminar Adelantos. Únicamente estarán activas las funcionalidades de Extensiones:

Como hemos comentado en la introducción, el ecosistema Goodyear Chile NO tendrá habilitado la funcionalidad de ADELANTOS.

• De base deberemos quitar la pantalla de selección del tipo de funcionalidad, para todas las consolas disponibles. Luego de ingresar email y contraseña se accederá directamente a la consola para extensiones.

• Hay que eliminar tambien la acción para pasar de una funcionalidad a la otra.

• No existirán usuarios del tipo Proveedor. No será necesario contar con este tipo de consola.

• Toda otra función asociada a ADELANTOS no deberá estar activa.

Quitar carga de prospecto crediticio del flujo de onboarding de clientes

No vamos a necesitar esa etapa del flujo de onboarding donde se le pide al cliente que cargue documentación para su prospecto crediticio. Hay que eliminarla.

Recordemos que luego de hacer la carga de esta información se generaba el cambio de estado del Cliente de PENDIENTE a INTERMEDIO. A partir de ahora, la etapa de generación de contraseña será el trigger que modifica el estado de PENDIENTE a INTERMEDIO.

Luego de la generación de la contraseña definitiva, se saltea el paso de carga de prospecto crediticio y hay que llevar al usuario a la siguiente pantalla, a espera de la activación de la cuenta, por parte del Lender.

Configuración crediticia del ecosistema

El modelo financiero-crediticio que detallamos en la introducción será moldeado a partir de ciertas variables. Estas variables serán únicas para todo el ecosistema. Esto quiere decir que tomaran los mismo valores para cada una de las facturas extendidas, dentro del mismo ecosistema.

¿Cuáles son las variables?

1. TNA: costo financiero que asumirá al 100% la cuenta ancla. Se calcula de la misma forma que calculamos el interés anteriormente. Es un numero que puede tomar decimales. Ej: 12,5 = 12,5% = 0,125

Interés total a pagar = (Total Factura) * (1+TNA)^((dias de extensión)/365)) - (Total Factura)

2. Distancia periodo 1: dias enteros que hay entre la fecha de emisión de la factura y la fecha de vencimiento original.

3. Distancia periodo 2: dias enteros que hay entre la fecha del vencimiento original de la factura y la fecha extendida.

Pongo un ejemplo para entender el calculo:

Configuraciones generales:
TNA: 1,5

Distancia periodo 1: 30

Distancia periodo 2: 60

Datos de factura:

Total factura: 10.000

Fecha de emisión: 6/12/2023

Resultados:

Fecha vencimiento original: 6/1/2023

Fecha extendida: 6/3/2023

Interés total a pagar: 24.5

Transacción de cancelación: total factura - interés total = 10000 - 24,5 = 9975,5

Transacción de extensión: total factura = 10000

¿Cómo se configuran estas variables?

Quien tendrá la potestad para definir y reconfigurar estas variables será el Lender.

Deberemos crear una nueva interfaz (un nuevo modulo) en la consola del Lender para que pueda definir estas 3 variables:

1. TNA

2. Distancia periodo 1

3. Distancia periodo 2

¿Qué sucede cuando se modifican las variables?

Es importante definir que pasa al alterar las variables que ya estan configuradas, cuando ya hay facturas activas en el ecosistema.

En el momento de la creación de la factura, proceso que ejecuta la Cuenta Ancla, se definen estas 3 variables según lo que estaba configurado en ese momento. Pasada esta etapa, en el caso que se genere una reconfiguración de estas variables, NO habrá retroactividad sobre las facturas que ya estan creadas.

Configuración crediticia particular por cliente

El proceso de definición de variables crediticias particulares, de cada cliente, que ejecuta el Lender para poder activar al cliente seguirá existiendo. Tambien deberá seguir funcionando el flujo para modificar estas variables.

Recordemos que la primera configuración de las variables particulares funciona como trigger para el cambio de estado del Cliente de INTERMEDIO a ACTIVO. Eso debe seguir funcionando de la misma manera.

La única diferencia es que vamos a alterar las variables disponibles de configurar. Hasta ahora lo que tenemos es:

De todo esto lo único que deberá seguir apareciendo es la Linea de Crédito. Las demas variables ya no cumplen ninguna funcion.

Quizas si queremos configurar tasas moratorias. Pero calculo que será una configuración general de todo el ecosistema, mas que particular de cada cliente. Por ahora lo eliminamos.

Flujo de carga de nueva factura

El proceso de creación de una nueva factura será muy similar a lo que tenemos construido en B2FI. Se pide como campos mandatorios el numero de factura, la fecha de emisión, fecha de pago, monto, descripción, proveedor, cliente y archivo adjunto.

La UNICA diferencia que deberemos alterar es que la fecha de pago deberá autocompletarse automáticamente.

La lógica de definición es tomando como referencia a la fecha de emisión definida y sumando a esa referencia los dias definidos de DISTANCIA PERIODO 1.

Si, por ejemplo, defino como fecha de emisión el 7/12/2023 y tengo configurado 30 dias para el periodo 1 entonces la fecha de vencimiento original quedara definida al 7/1/2023.

¿Qué pasa cuando la fecha de vencimiento original cae sabado o domingo?

Flujo de aprobación de factura:

En la DEMO, el proceso de aprobación de una factura correspondía al momento en el cual el Cliente daba su “consentimiento” respecto a una nueva cuenta por cobrar/pagar creada por la Cuenta Ancla (el proveedor).

Luego de la aprobación de una factura, al Cliente se le activaban las funcionalidades para Extender o Pagar la factura.

Aca es donde radica la principal diferencia respecto a lo que queremos construir para Goodyear Chile.

Este ecosistema no tendrá la posibilidad de ejecutar pagos sin la intervención de un Lender que financie y de plazos extras.

En consecuencia, como no habrá mas de una posibilidad de selección, el proceso de aprobación de una factura tambien será la etapa de solicitud de extensión. Ambos procesos corren con la misma ejecución.

Tendremos que hacer las siguientes modificaciones:

1. Cambios en visualizaciones en el modal de aprobación de factura:

En primer lugar, la fecha titulada como “Fecha de emisión” debe pasar a llamarse “Fecha de vencimiento original”. Corresponde a la fecha del periodo 1 (fecha de emisión + X)

Debajo de fecha tendremos que agregar una campo titulado “Fecha extendida” que corresponderá a la fecha en la que el Cliente deberá cancelar su deuda pasado el periodo 1 y periodo 2 (fecha de emisión + X + Y).

2. Transición de estados:

La aprobación de la factura es a la vez la solicitud de la extensión. Entonces, al APROBAR la factura deberán modificarse la condiciones de ese registro para llegar a esa instancia de aprobación y solicitud de extensión.

Esto se resume en las siguientes transiciones:

• Cambio de Estado de PENDIENTE a APROBADA

• Cambio de Propietario de CLIENTE a EXTENSION EN PROCESO

3. Notificaciones:

Esta etapa debe funcionar como trigger para el envío de dos notificaciones:

1. Notificación de aprobación de factura - la recibe la Cuenta Ancla

2. Notificación de solicitud de extensión - la recibe el Lender

Proceso de aprobación de solicitud de extensión

Definimos que la aprobación de una factura, por parte del Cliente, ejecuta la solicitud de extensión que deberá recibir el Lender en su modulo de facturas.

La imagen muestra, desde el modulo de facturas del Lender, una nueva solicitud de extensión. Sobre ese registro se podrá revisar el disponible del Cliente y aprobar o rechazar la solicitud de extensión.

• Detalle de cada registro:

La estructura del detalle actual es:

La idea es mantener esos tres submódulo: Información de financiamiento ; Pago a Cuenta Ancla ; Cobro a Cliente, pero cambiando los datos.

En Información de financiamiento:

• Monto de la factura

• Distancia periodo 1

• Distancia periodo 2

• TNA

• Fecha de emisión

• Fecha de vencimiento original

• Fecha extendida

En Pago a Cuenta Ancla:

• Intereses

• Monto total a pagar

En Cobro a Clientes:

• Monto total a cobrar

• Rechazo de solicitud de extensión:

El proceso de rechazo de una solicitud de extensión se mantiene igual a lo que ya tenemos.

¿Qué sucede en relacion a los estados esas facturas que fueron rechazadas?

Debemos definir que transiciones de estados tendrá que tener una factura que sufre un rechazo en su solicitud de extensión.

Como este instanciado no cuenta con la posibilidad de ejecutar pagos sin financiamiento aquellas facturas que sufren un rechazo en su solicitud de extensión NO tiene razón para seguir estando “operativas”.

Entonces la transición de estado será:

• Deudor: EXTENSION EN PROCESO → CLIENTE

• Estado: APROBADA → CANCELADA

Entonces una factura CANCELADA es aquella que paso por una solicitud de extensión pero que por algún motivo fue rechazada. Este es un estado definitivo. No se podrá accionar de ninguna manera posible.

Tanto la cuenta ancla como el cliente deberán recibir notificaciones que indiquen que esta factura sufrio un rechazo en su solicitud de extensión.

Importante mostrar el motivo de rechazo en el detalle de esa factura que queda CANCELADA.

• Aprobación de solicitud de extensión:

El proceso de aprobación de una solicitud de extensión tambien sigue igual a lo que tenemos. El Propietario cambia de EXTENSION EN PROCESO a LENDER.

Es en este momento que se crean las dos transacciones asociadas a la extensión:

• Transacción de CANCELACION

• Transacción de EXTENSION

La aprobación de la extensión cambia el Propietario de la factura a manos del Lender. Se genera tambien una notificación en el Inbox del Cliente. Todo esto respeta el funcionamiento actual.

Transacción de Cancelación

La transacción de Cancelación sufrirá modificación respecto al método de calculo de esa deuda LENDER → CUENTA ANCLA.

Total Transacción Cancelación = Monto total de factura - Descuento

Descuento = Interés total a pagar = (Total Factura) * (1+TNA)^((dias de extensión)/365)) - (Total Factura)

Respecto al detalle de cada transacción habrá que hacer algunas modificaciones en los datos que se visualizan.

1. Fecha de vencimiento: corresponde a la fecha de vencimiento original de la factura. Es la fecha de emisión mas la distancia del periodo 1. Se mantiene igual a lo ya construido.

2. TNA: costo financiero definido en la configuraciones generales del ecosistema.

3. Dias de extensión: corresponde siempre a los dias configurados en la distancia del periodo 2.

4. % de traslado: este campo hay que eliminarlo

5. Comisión: este campo hay que eliminarlo

6. Monto total de la factura: se mantiene igual

7. Interés total: equivale al descuento total

8. Comisión total: hay que eliminar este campo

9. Monto total a pagar: Monto total de la factura - Interés total

Transacción de Extensión:

Esta transacción tambien tendrá modificación en cuanto al calculo de total. En la totalidad de los casos el valor de esta deuda será igual al valor total de la factura asociada. Dejaran de existir los termino de interés, comisión e interés moratorio.

Deberemos corregir tambien el detalle de este tipo de transacción.

1. Como no hay interés moratorio podemos unificar monto inicial, interés moratorio y monto total en un único campo de monto total, que siempre será igual al valor de la factura asociada.

2. La fecha de pago equivale a la fecha pasado el segundo periodo de extensión (t+90)

3. Todo el detalle (que esta por fuera del listado de arriba) lo podemos eliminar.

Sistema de comisiones

1. Configuración:

En cuanto a las variables y la interfaz de configuraciones de estos % comisiónales deberemos mantener exactamente lo que tenemos construido ahora.

Seguirán existiendo ambas variables, la comisión de cobro y la comisión de extensión. Ambos siguen siendo porcentajes que pueden tomar números con coma. En caso que el valor configurado sea 0 entonces ese comisión no deberá aparecer, en el momento que corresponda.

El % configurado debe queda impactado en la factura desde el momento de su creación. Si hago una alteración de estas variables eso no debe impactar sobre las facturas ya creadas. Esto define la No retroactividad de esta configuración.

2. Comisión de extensión:

Esta comisión seguirá creándose en el momento que se ejecuta la transacción de de cancelación.

Se calculara de la siguiente manera:

Comisión de extensión = Total de Factura * % comisión de extensión

3. Comisión de cobro:

Esta comisión seguirá creándose en el momento que se ejecuta la transacción de extensión.

Se calcula como:

Comisión de cobro = Total de Factura * % comisión de cobro

Retenciones

Por ahora no hay nada definido como para poder desarrollar.