ANTES DEL AMANECER DE RIPS

Las razones por las cuales se toman decisiones de última hora pueden ser diversas, ya
sabemos que la falta de planeación o el no focalizar los esfuerzos en lo importante suelen
derivar en dejar pendientes que luego son bloqueantes y es justo eso los que nos está
pasando en este momento; ¿Qué nos pasó? ¿Qué podemos hacer para evitarlo en el
futuro?, serán respuestas que entraremos a revisar con un café cuando pase la tormenta.

Ahora mismo nos enfrentamos a la esperada salida a producción, teníamos temas

pendiente de aprovisionamientos, permisos, más de 700 commits pendientes por desplegar;
el panorama por llamarlo de alguna manera parece emocionante.

Pasando por todos los inconvenientes de merges y despliegues, entramos en una de las
dependencias que a nivel de sistema tenemos, facturación electrónica, del cual
necesitamos información de las facturas la cual se supone accederemos por medio de un
servicio pero que no ha sido desplegado de manera completa (ésta es otra de las
preguntas que entraremos a revisar cuando tengamos el tiempo). y la versión que tenemos
actualmente en producción no está funcionando de manera correcta, lo que nos llevó a
plantear estrategias para cumplir con la validación de los valores de facturas por parte de
rips y la notificación de la aceptación o rechazo de las facturas por parte de fe.

La estrategia que trazamos para el día de mañana es básicamente que desde RIPS por
medio de un componente en spark accedemos a la información de la facturación logrando
hacer la validación (conocemos el terreno en spark y sabemos que hacer las validaciones
de este lado es rápido, más rápido incluso que con servicios rest), luego de la validación se
ejecuta un scheduler que lanzará un evento por medio de pubsub a una cola que estará
escuchando el proyecto de facturación electrónica donde procesaremos los mensajes y al
final realizar la aceptación o rechazo de facturas dependiendo del resultado de la validación.

El acercamiento por pubsub pese a ser parte de una estrategia temporal me parece mucho
más acertado que el acercamiento del servicio rest que tenemos (donde es FE quien hace
las validaciones).
De facturación electrónica se consume una vista que contiene los valores de id, nit, número
de factura y valor de la factura respondiendo a la query select id, idFactura,
nitProvedor, vrTotal FROM xmldata.

Los errores se almacenan en una tabla de rips donde tenemos los datos de nit, número de
factura y el detalle del error: BILL_ERROR_DETAIL(NIT, NUMERO_FACTURA, ERROR).

El mensaje de enviado por medio del pubsub responde a la siguiente estructura:

 ejemplo ejecución válida ejemplo ejecución con errores

Nota: si existe algún error en la remisión solamente se notificarán las facturas con error, en caso que la
remisión se valide de manera correcta se deben enviar todos los registros en bloques máximo de 500 facturas
por mensaje de pubsub.

Este planteamiento nos genera otras preguntas cómo romper el acoplamiento contra FE,
como FE responderá a la alta tasa de peticiones que lanzaremos desde RIPS.
respuestas que comenzaremos a evaluar luego de entregar está etapa, por lo pronto
tenemos un panorama preciso de cómo cumplir con la meta establecida.