Lapachos Lending : Sesión de Revisión documentación de integración con ABL

11 hs

Actualizacion general

Juan Robles

• Ya tenemos la documentación de ABL

• Una vez que tengamos conectado el backend podemos crear un buyer y hacer una segunda call para hacer todo ese flujo.

• El iframe están revisando la documentación de lo pendiente.

Actualización Comprador y proveedor.

Juan Robles Oscar Regalado.

Andrés Carrero

• Actualizar buyer y actualizar el suplier: ¿Cuánto sentido tiene hacer una api para esa actualización?,

• Oscar: Ese endpoint es para actualizar el estatus, es para confirmarles los datos a lend2B de que se confirmaron los datos de ABL. Ahí se consume este servicio para actualizar el dato del estatus. Es de estatus nada mas para el MVP. Este endpoint seria de actualización de estatus simplemente, el momento seria cuando inicia sesión por primera vez.

• Momento de cambio de estado: Para considerarlo activos tienen que suceder dos cosas: el correo activo y acepte los términos y condiciones del lado de ABL, ahí cambia al estado activo.

• Los cambios de datos de los campos se hacen del lado de len2B y se envía para ABL

Revisión de la integración

Juan Robles Oscar Regalado.

Andrés Carrero

• Nuestro dato en común, es el ID que se genera en lend2B y es un numero entero.

• bankemail: Por la estructura de base de datos de ABL necesitan un correo para crear clientes y proveedores y siempre ese correo es creado por ABL para rol y ambiente.

• Fecha de aprobación o fecha de envió es el due. from approval. Falta definición de negocio para ver el valor que se envía.

Autorización y consulta a nuestras apis

Juan Robles

Oscar Regalado.

Andrés Carrero

• Necesidad de un token para consumir el resto de la api es un proceso de autorización.

• Todos los endpoints aparte requieren en su cabeza una api key que se envía por correo. Esto se planteo para restingir las peticiones que se hacen a la api.

• El sistema controla la cantidad de peticiones que se hacen a la APi.

• Ese token también se utiliza en el consumo de los Iframes.

• El tiempo de vencimiento es algo a confirmar sobre todo para saber como manejar el vencimiento.

Cambios en Endpoints

Elvis Bonilla Carlos Chacon Oscar Regalado.

Andrés Carrero

• Se va a cambiar el endpoint de Active Entity para desdoblarlo en dos.

Create invoice:

• Se va a eliminar created by.

• Se evalúa sumar el campo de hora.

• Fill name: pdf y xml, lo necesitamos si o si desde lend2B. Se consulta un endpoint de ABL para la descarga del archivo. Find invoice, ese invoice_id se lo devuelve a la creación de la factura. Hay que revisar este tema.

• DEBTOR-ID se va a eliminar. Es una lógica interna de lend2B. Elvis Bonilla

• Moneda por id.

• Faltan: Fecha de pago para el buyer y fecha de cobro para el supplier.

• En lend2B se va a sumar la respuesta de éxito y la respuesta de errores.

Actualización del estado de la factura endpoint de ambos lados, aceptación, declinación, rechazo:

const status_list = [ { status_id: 2, status_name: "rejected" }, { status_id: 3, status_name: "approved" }, { status_id: 4, status_name: "declined" }, ];

lend2B consume un servicio para notificar cuando paso a pagada, cuando se actualizaron los fondos. Este endpoint esta pendiente.

Entidades desde len2B:

• Get balance

• Activar buyer

• Activar supllier

Se van a actualizar las respuestas