Cambiar los precios no puede reescribir el pasado
Si tu matriz de tarifas es una tabla que se actualiza en sitio, el día que subas medio punto habrás cambiado también lo que cobraste hace seis meses. Suena a detalle técnico y es riesgo operativo puro.
Toda entidad de factoring tiene una tabla que relaciona la calificación del deudor con dos números: qué porcentaje de la factura se adelanta y a qué tasa mensual. Es la matriz de precios, y es el parámetro comercial que más se toca.
La forma obvia de guardarla es una tabla con una fila por calificación y dos columnas. Y la forma obvia de cambiarla es actualizar la celda.
Eso es exactamente lo que no hay que hacer.
El problema aparece medio año después
Imagina que en marzo subes medio punto la tasa de la banda B. Actualizas la celda, guardas, y a partir de ahí las cotizaciones nuevas usan el número nuevo. Todo correcto.
En septiembre, un cliente discute la liquidación de una operación de enero. Abres la operación, el sistema recalcula el desglose con la matriz vigente… y le enseña una tasa que en enero no existía.
No has cambiado lo que cobraste: eso está en la transferencia. Has cambiado lo que tu sistema dice que cobraste. Y en una conversación sobre dinero, eso es peor.
El mismo problema aparece, en versión más cara, cuando alguien de auditoría pide la reconstrucción de un trimestre.
Versionar al guardar
La solución es corta de escribir y hay que tomarla el primer día, porque retroactivamente es una migración desagradable.
La matriz de precios se versiona cada vez que se guarda. Guardar no actualiza filas: crea una versión nueva y completa. Y cada cotización apunta a la versión con la que se calculó.
Con eso:
- Recalcular una operación de enero usa la matriz de enero, siempre.
- Cambiar precios es una operación segura, porque no puede tocar el pasado.
- Puedes responder qué precios teníamos en marzo sin buscar en un correo.
- Y puedes comparar dos versiones, que es lo que de verdad quiere ver un comité antes de aprobar un cambio.
El coste es unas filas más en la base y un identificador de versión en la cotización. El beneficio es no tener nunca la conversación del párrafo anterior.
Lo que no hace falta versionar
Aquí conviene no pasarse, porque versionarlo todo tiene su propio coste.
Las reglas de admisión y las bandas de calificación se pueden actualizar en sitio, y la razón es que su historia ya está guardada en otro sitio: en la traza de cada decisión. Si cada decisión archiva qué regla se evaluó, con qué umbral y qué valor encontró, la política vigente en enero se puede reconstruir leyendo las decisiones de enero.
La diferencia con el precio es que una decisión se toma una vez y queda escrita, mientras que un desglose de importes se recalcula cada vez que alguien abre la pantalla. Lo que se recalcula necesita versión; lo que se archiva ya la tiene.
Es un criterio útil para el resto del sistema: ¿este número se vuelve a calcular alguna vez? Entonces necesita saber con qué parámetros nació.
Y que se pueda cambiar sin desplegar
Todo lo anterior da igual si para subir medio punto hay que abrir un ticket.
En la mayoría de sistemas que hemos visto, la matriz vive escrita a mano dentro del código, en una función que devuelve un diccionario. Funciona perfectamente hasta el día en que el comité de riesgos decide algo un jueves y la decisión entra en producción tres semanas después.
Sacar esa matriz a la base de datos y ponerla en una pantalla no es una mejora de comodidad. Es lo que convierte una política de precios en algo que su dueño puede ejercer.
Y con las versiones puestas, además, puede ejercerla sin miedo: lo peor que puede pasar al guardar es que exista una versión más.