Modificar una regla de negocio puede cambiar quién reúne los requisitos para un servicio, cuánto se cobra o cómo se clasifica una operación. La decisión importante no es solo qué regla aplicar a partir de ahora, sino qué hacer con los registros creados bajo la versión anterior. Recalcularlos puede corregir resultados, pero también alterar saldos, informes y decisiones ya comunicadas. Mantenerlos intactos preserva lo ocurrido, aunque puede perpetuar un error o una política que ya no corresponde.
Para decidir cómo aplicar cambios retroactivos en reglas de negocio, conviene separar la fecha de vigencia de la fecha de registro, medir las consecuencias y definir qué historial se conservará. La política adecuada puede ser prospectiva, retroactiva o específica para determinados casos. Debe quedar decidida antes de publicar el cambio y ser comprensible para producto, operaciones, tecnología y las personas afectadas.
Una regla nueva no define por sí sola el tratamiento del pasado
Una regla determina cómo evaluar una situación, pero no necesariamente qué hacer con resultados que ya se calcularon. Por ejemplo, modificar un criterio de elegibilidad podría cambiar el resultado de solicitudes anteriores. Sin una decisión explícita, distintos equipos pueden interpretar el cambio de maneras incompatibles: la aplicación usa la regla nueva, un informe conserva el cálculo anterior y una intervención manual introduce un tercer resultado.
Empieza por identificar el motivo del cambio. No es igual corregir un error de implementación que cambiar una política, responder a una obligación aplicable o mejorar un umbral para el futuro. Si la regla anterior funcionaba como se había definido y la organización cambia de criterio, aplicar el cambio al pasado puede modificar decisiones legítimas tomadas entonces. Si el cálculo estaba equivocado, conservar todos los resultados puede perpetuar daños. El motivo no resuelve automáticamente el tratamiento, pero sí ayuda a establecer qué resultados se deben investigar y quién debe aprobar la decisión.
Define también qué significa “registro existente”. Puede referirse a una operación ya iniciada, una operación cerrada, un pago liquidado o una decisión comunicada. Esos estados tienen consecuencias diferentes. Clasifica los registros por estado y no asumas que todos pueden modificarse con el mismo procedimiento.
Separar fecha de registro y fecha de vigencia
La fecha en que el sistema guarda una operación no siempre coincide con el periodo al que pertenece la regla. Una solicitud registrada hoy puede referirse a un servicio prestado el mes pasado; una corrección recibida ahora puede describir una condición que ya existía. Por eso, modela al menos dos nociones temporales:
- Fecha de registro: cuándo el sistema recibió o guardó el dato.
- Fecha de vigencia: desde cuándo la regla debe considerarse válida para evaluar una operación o periodo.
Según el dominio, puede ser necesario precisar además la fecha efectiva de la operación, el momento de cálculo o el periodo facturado. No añadas fechas sin una necesidad concreta: define cuáles cambian el resultado y cómo se interpretan. El equipo debe poder responder, para un caso dado, qué regla era válida para la fecha relevante y cuándo se registró la información utilizada.
Este modelo evita tratar una regla como si siempre hubiera sido igual. También permite corregir datos tardíos sin confundir una modificación del registro con una modificación de política. Documenta el criterio para resolver fechas límite, zonas horarias, operaciones que cruzan periodos y registros incompletos.
Elegir entre aplicación prospectiva, recálculo o corrección selectiva
Hay tres estrategias habituales. La aplicación prospectiva usa la regla nueva solo para operaciones cuya fecha de vigencia sea posterior a la acordada. Mantiene los resultados anteriores y suele ser apropiada para cambios de política cuando se quiere respetar las condiciones existentes. Su riesgo es dejar sin corregir resultados afectados por un defecto real.
El recálculo retroactivo vuelve a evaluar un conjunto definido de registros con la regla nueva. Puede ser adecuado si el cálculo anterior fue incorrecto o si una decisión formal exige corregir periodos anteriores. Antes de elegirlo, comprueba si el resultado puede cambiar saldos, pagos, acceso a servicios, obligaciones o informes ya cerrados. El recálculo técnico no determina por sí mismo qué ajuste corresponde: un resultado distinto puede requerir una compensación, una aprobación o una comunicación separada.
La corrección caso por caso limita la intervención a registros con un error, una reclamación o una condición específica. Es útil cuando el alcance es acotado o las excepciones requieren revisión humana, pero puede ser lenta y desigual si no hay criterios de inclusión y resolución. Registra por qué cada caso se incluye o excluye y quién tomó la decisión.
Compara las opciones con preguntas concretas: ¿qué problema se corrige?, ¿qué personas y periodos afecta?, ¿qué resultado se habría producido con cada versión?, ¿hay operaciones cerradas o comunicadas?, ¿qué aprobaciones son necesarias?, ¿se puede revertir la actualización sin perder evidencia? Si la respuesta sobre impacto o autoridad es incierta, detén la ejecución masiva y resuelve esa incertidumbre primero.
Medir efectos y dependencias antes de tocar registros
Un valor recalculado puede alimentar otras decisiones. Sigue el recorrido desde el dato de origen hasta saldos, informes, decisiones, comunicaciones y sistemas conectados. Un cambio en la clasificación de una operación, por ejemplo, puede afectar una vista analítica y una integración que consume esa clasificación, aunque no cambie el registro financiero original. No basta con comprobar que la tabla principal contiene el valor esperado.
Prepara una simulación que compare el resultado actual con el propuesto para el alcance elegido. Resume cuántos registros cambiarían, cuáles son los casos extremos y qué dependencias recibirían modificaciones. Si el impacto es amplio o difícil de interpretar, separa el trabajo por periodos, estados o grupos operativos. Define de antemano qué diferencias son esperadas, qué excepciones requieren revisión y qué resultado obliga a detener el proceso.
Comprueba también efectos secundarios. Una actualización no debe enviar por accidente notificaciones repetidas, duplicar movimientos ni volver a aplicar ajustes manuales. Si otros sistemas reaccionan ante un cambio de registro, determina si el recálculo debe activar esas reacciones, evitarlas o generar una comunicación distinta. La decisión debe formar parte del diseño, no quedar implícita en el mecanismo de actualización.
Conservar historia, explicar decisiones y controlar la ejecución
No sobrescribas el único valor disponible si después será necesario explicar por qué cambió un resultado. Conserva el valor anterior, el valor nuevo, la regla aplicada, las fechas relevantes, el motivo y la referencia a la aprobación correspondiente. La forma técnica dependerá del sistema, pero el historial debe permitir reconstruir qué decisión se tomó para cada registro.
Diseña el recálculo como un proceso controlado: delimita el alcance, ejecuta la simulación, valida muestras con operaciones y negocio, aprueba las excepciones y aplica el cambio en etapas cuando sea posible. Después, compara los resultados reales con los previstos y revisa las dependencias. Define quién puede pausar la ejecución, cómo se corrige un fallo y qué evidencia se conservará. No confundas revertir una actualización con borrar el rastro de lo ocurrido.
La comunicación también forma parte del cambio. Indica qué periodo se revisó, qué resultado puede variar, cuándo se verá reflejado y a quién acudir ante una discrepancia. Si las personas ya recibieron una decisión o un importe, establece antes quién comunica la corrección y cómo se trata cada caso. Evita prometer que no habrá consecuencias mientras el análisis siga incompleto.
Lista de comprobación antes de publicar el cambio
- Describe el motivo del cambio y distingue una corrección de un cambio de política.
- Define la fecha de vigencia, la fecha de registro relevante y los estados incluidos.
- Elige por escrito entre aplicación prospectiva, recálculo retroactivo o corrección selectiva.
- Identifica saldos, informes, decisiones, comunicaciones e integraciones que pueden cambiar.
- Simula el resultado y valida excepciones con responsables de negocio y operaciones.
- Conserva valores anteriores, regla aplicada, motivo y aprobaciones.
- Prevé cómo evitar notificaciones repetidas, movimientos duplicados y pérdida de ajustes manuales.
- Define comunicación, supervisión, criterios de pausa y tratamiento de discrepancias.
Un cambio retroactivo bien gestionado no es simplemente ejecutar un nuevo cálculo sobre datos antiguos. Es una decisión de producto y operación sobre qué resultados se consideran válidos, para qué fechas y con qué evidencia. Cuando la vigencia, el alcance y las consecuencias están claros, el equipo puede corregir lo necesario sin borrar el contexto que permite explicar el pasado.