.png)
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.
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.
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.
.png)
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.
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.
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.
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.
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.
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.
Las variables de regla también pueden utilizarse del mismo modo que si formaran parte de la entrada.
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.
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.
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.
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:
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. |
|
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:
|
|
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
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.
En nuestro caso, la comisión de venta de un préstamo se calcula a partir de tres datos básicos:
Podría haber otros parámetros para calcular la comisión, pero hemos decidido utilizar una regla sencilla.
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.
Esta regla se construye en forma de árbol de decisión y su aplicación adopta la siguiente forma:
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.
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.
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.
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.
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.
... y la respuesta de la regla de la comisión de ventas:
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.
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.
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.
sales@decisionrules.ioPortal de serviciosPrograma de sociosTérminos y condicionesPolítica de privacidadEmpresa
%20(1).svg){kind=logo}
