Cómo crear un modelo de comisiones utilizando DecisionRules Parte II

Las comisiones desempeñan un papel fundamental en varias industrias, especialmente en el sector financiero. En este artículo, nos sumergimos en la implementación práctica de la gestión y el cálculo de comisiones mediante DecisionRules.io. En la primera parte, exploraremos las capas del modelo de cálculo de comisiones, variables de reglas, gestión de activaciones y modelos de entrada/salida. En la segunda, veremos ejemplos de reglas concretas, integración de DecisionRules con sistemas externos e informes de comisiones.

Aplicación

Las comisiones suelen recalcularse una vez al mes como base para los pagos a los empleados. Pero con DecisionRules, puedes hacer estos cálculos en cualquier momento del mes a nivel de equipo o de corredor individual para aumentar su motivación.

Estructura del modelo

La solución debe ser capaz de calcular tres modelos de comisión diferentes. Para definir este complejo comportamiento por un lado y simplificar la integración por otro, hemos implementado una estructura jerárquica de reglas.

  • La 1ª capa representa la regla principal (Calcular comisiones) que es responsable de la integración en ambas direcciones DENTRO  y FUERA  y ejecuta las reglas en las capas siguientes.
  • La 2ª capa define diferentes modelos de comisiones y contiene una lista de todas las reglas de cada modelo.
  • La 3ª capa contiene las reglas finales que calculan la comisión final basándose en los datos de entrada. En esta capa se crea una regla para cada tipo de producto. Es posible definir varias versiones de una regla para cada tipo de producto y activarlas y desactivarlas según sea necesario.
model_structure

1ª capa

La regla "Calcular comisiones" está diseñada para evaluar todas las reglas aplicables para una entrada masiva, lo que significa que la entrada contiene todas las cuentas y/o operaciones de un corredor. Sin embargo, siempre es posible evaluar cualquier regla de forma aislada si es necesario o más fácil de implementar.

La regla tiene una propiedad de entrada “commissionType” que determina el tipo de comisión que se calculará, por lo que para cualquier subconjunto de estas comisiones la entrada puede seguir siendo la misma.

Esta regla no está pensada para ser cambiada, a menos que el modelo se modifique significativamente, como cuando se añade otro tipo de comisión. Si la estructura de las comisiones sigue siendo la misma y sólo se eliminan o añaden reglas, entonces sólo cambiaría el esquema de entrada para reflejar la estructura de sus datos de entrada.

1st layer

2ª capa

Esta capa organiza las reglas en modelos de comisiones individuales. Hay tres tablas, cada una para un modelo de comisión. Cada tabla contiene una lista de todos los identificadores de reglas de comisiones activas. Sólo se evaluarán las reglas actuales de estas tablas.

La tabla de comisiones de Mérito también contiene una columna en la que puede establecerse un grupo de exclusividad. Esta función permite definir más reglas para un mismo caso. Todas las reglas de este grupo de exclusividad se evalúan al mismo tiempo y sólo se concederá la comisión más alta. Esto crea una opción para diseñar múltiples niveles de comisiones de Mérito.

3ª capa

La última capa contiene la lógica real para evaluar las comisiones. Estas reglas se llaman desde el script orquestador Calcular Comisiones. Pero también existe la posibilidad de evaluarlas todas por separado en caso necesario.

Todas las comisiones tienen una regla independiente donde se almacena su lógica, por lo que cualquier regla puede modificarse de forma independiente.

Gestión de las reglas de la Comisión

Esperamos que el número de reglas aumente. La TI puede ser beneficiosa para un usuario empresarial que vea la oportunidad de dar rienda suelta a su creatividad. Para un administrador de aplicaciones, esto podría convertirse rápidamente en un dolor de cabeza. Por eso hemos introducido algunas técnicas para mantener el número de reglas en un nivel manejable.

Variables de regla

Para cada regla, podemos definir una variable de regla que resulta útil cuando un único valor se utiliza en varias secciones de un algoritmo, o cuando es necesario modificar fácilmente atributos significativos como el importe de la comisión.

rule variables

Un buen ejemplo puede ser un porcentaje de comisión utilizado como parte de una condición en la regla Comisión de ventas - Venta de préstamo, como se ha descrito anteriormente. Utilizando una variable, podemos cambiarla al mismo tiempo reduciendo la posibilidad de un error potencial.

usage of rule variables

Las variables de regla también pueden utilizarse del mismo modo que si formaran parte de la entrada.

Activación/Desactivación de la comisión

Como se ha descrito anteriormente ( Estructura del modelo - 2ª capa ), sólo se evalúan las reglas presentes en las tablas de Listas. Eso ofrece la posibilidad de gestionar fácilmente las comisiones activas; todo lo que tiene que hacer el administrador para desactivar una regla de comisión es desactivar su registro en esta tabla.

activate_deactive

También es posible establecer un tiempo de activación para una regla concreta, lo que da la opción de crear promociones limitadas en el tiempo o variar la configuración de las comisiones en función de la temporada.

set activation time for row

Modelos de entrada/salida

Los datos de entrada se estructuran en torno al corredor. Toda la información para el procesamiento de comisiones se envía en un solo batch y también las comisiones para corredores individuales se evalúan de una sola vez. La estructura de datos se crea como una matriz, por lo que es posible procesar diferentes tipos de comisiones para un solo corredor, un tipo de comisión para múltiples corredores o cualquier otra combinación.

Modelo de datos de entrada

La estructura de entrada se establece en el Modelo de E/S de la regla principal - Calcular Comisiones. La entrada se divide en tres partes:

Input data model
  • Tipo de comisión, un parámetro crítico que determina el modelo de comisión utilizado. Los valores posibles son: "VENTAS", "MÉRITO", "INGRESOS".
  • Tratos - la información necesaria sobre las transacciones realizadas. Esta estructura debe contener todos los datos requeridos por las reglas concretas que se van a evaluar.
  • Corredor, proporciona cierta información sobre el corredor que ha realizado la operación. Esa información es útil tanto para la tramitación de comisiones, donde el importe de la comisión puede depender del rango del vendedor (por ejemplo), como para la elaboración de informes.

La propiedad CommissionType es obligatoria en el procesamiento de comisiones. El contenido de las propiedades Deals y Consultant es variable y depende de la regla y los parámetros significativos para la lógica de negocio de la comisión.

Input JSON model

Modelo de salida

Aunque la estructura de entrada tiene algunos componentes obligatorios y muchos parámetros opcionales que varían según el modelo de comisión, la estructura de salida será siempre la misma:

Output data model
  • fecha de la evaluación
  • sucursal en la que trabaja el corredor
  • identificación del corredor
  • importe de las comisiones abonadas al corredor
Output JSON model

Modelo de entrada/salida de las reglas de la comisión

Cada regla puede tener un conjunto diferente de entradas a evaluar, por lo que la estructura de entrada es variable. Si observamos un ejemplo de la comisión de ventas SC_LOAN, su modelo de entrada se parece al de la imagen nº 1

La salida de cada regla de comisión tiene la misma estructura para que la salida final sea uniforme y sencilla de integrar. Puedes ver el modelo de salida en la imagen nº 2

Input/Output model of Commission Rules
Input JSON model
Image no.1
Output JSON model
Image no.2

Ejemplos de reglas de la Comisión

Echemos un vistazo a las reglas de la 3ª capa, que definen la lógica de negocio de las comisiones individuales. Cada modelo de comisión tiene sus especificidades al igual que cada clase de producto tiene las mismas.

Para cada ejemplo describiremos los datos de entrada necesarios, la lógica y los parámetros establecidos y también la salida de la regla.

Aunque las estructuras de entrada suelen variar en función del tipo de modelo de comisión, la salida será esencialmente la misma. Todas las reglas que pretendemos presentar pueden establecerse fácilmente en una forma sencilla de estructura de árbol, por lo que no es necesario tener conocimientos de programación. Esto puede ser útil para organizaciones en las que los recursos informáticos son muy escasos. Hay que tener en cuenta que, como para cualquier otra herramienta informática, se recomienda encarecidamente la participación de un administrador de aplicaciones en el proceso de desarrollo de nuevas reglas.

Comisión de venta - Venta de préstamos

En nuestro caso, la comisión de venta de un préstamo se calcula a partir de tres datos básicos:

  • importe del préstamo o límite de crédito
  • importe retirado
  • y el tipo de producto

Podría haber otros parámetros para calcular la comisión, pero hemos decidido utilizar una regla sencilla.

I/O JSON model

Para facilitar el mantenimiento, también se han definido dos variables de regla. Una define los valores porcentuales de la tasa de comisión, que se utiliza para calcular el pago de la comisión, y la otra especifica la proporción mínima del importe desembolsado.

rule variables

Esta regla se construye en forma de árbol de decisión y su aplicación adopta la siguiente forma:

decision tree
Condiciones

Sólo hay una condición que comprueba si el número de clientes supera o no el umbral predefinido.

Usamos la función ARRAY_FILTER para filtrar cualquier cuenta en la que la propiedad newClient no sea cierta, después CONTAMOS estas entradas y comprobamos si el recuento es mayor o igual que el valor umbral definido en las variables de la regla como ACC_COUNT_THRESHOLD.

Resultado positivo

Si se cumple la condición, el valor de la comisión se establece en un valor predefinido (en nuestro caso 30.000) y la propiedad adjudicada se establece en verdadero.

Resultado negativo

Si no se cumple la condición, entonces el valor de la comisión se fija en 0, la propiedad adjudicada se fija en falso y se genera un mensaje bajo el razonamiento que dice "No hay suficientes clientes nuevos" con el número de clientes nuevos que ha conseguido el corredor.

Integración

DecisionRules se integra a través de Restful API (documentación). Para los fines de nuestro estudio de caso, aprovechamos el procesamiento masivo de grandes conjuntos de datos. Asimismo, existe la posibilidad de invocar una única regla para una sola operación. Esto podría resultar útil en situaciones en las que un corredor necesita validar el importe de la comisión de una transacción que pretende realizar.

Llamadas a la API

La comunicación con DecisionRules que manejan volúmenes de datos mayores requiere el uso de una solución de software intermedio que facilite una comunicación fluida entre DecisionRules y la fuente de datos. Esta herramienta intermediaria gestionará la transmisión de datos, garantizando un intercambio seguro y eficiente de información y manteniendo la integridad de los datos.

La respuesta de la llamada a la API contiene una estructura de salida predefinida descrita anteriormente en detalle. Una vez procesada en el componente de middleware, puede utilizarse como fuente de otros procesos empresariales para aprobar las comisiones y el pago.

Para probar la solución, podemos utilizar la herramienta https://www.postman.com/ para imitar el middleware, visualizar la respuesta recibida y probar la lógica de trabajo dentro de DecisionRules.io.

Una llamada desde una aplicación postman puede tener este aspecto.

postman request

... y la respuesta de la regla de la comisión de ventas:

postman response

Informes

Los empresarios necesitarán un conjunto de informes que les proporcionen información sobre el importe de la comisión a pagar y también información detallada sobre un caso concreto para poder decidir posibles reclamaciones.

Power BI será nuestra herramienta preferida.

power Bi report

DecisionRules.io es capaz de almacenar información detallada sobre el procesamiento de cada regla, incluyendo los datos de entrada y la salida calculada. Este tipo de datos se almacenan en forma de registros de auditoría. Estos registros pueden ser recuperados a través de la API y procesados para la elaboración de informes en Power BI. Obtenga más información sobre los registros de auditoría en nuestra documentación: link

En nuestro ejemplo, la regla registra cierta información básica sobre el corredor junto con todos los datos utilizados en la evaluación de la regla, el importe de la comisión, el nombre y el tipo de comisión, la fecha en que se concedió la comisión e información anónima básica sobre la cuenta o el cliente.

Conclusión

En este artículo, hemos descrito cómo se implementan los modelos de comisión en DecisionRules y hemos descrito a grandes rasgos cómo funciona el modelo y la forma de evaluarlo. También hemos abordado la notificación de los resultados de las comisiones.

Hemos mencionado que DecisionRules.io no es una herramienta única que resolverá todos los aspectos del proceso de comisión, pero podría ser la fundamental que contendrá y gestionará los valiosos conocimientos.

En la próxima y última parte de esta serie profundizaremos en la implementación en DecisionRules.io para que puedas probarlo por ti mismo y experimentar con varios modelos de comisiones.

Más Artículos