Revertir no es borrar

Revertir un pago no es borrar un pago. Esa distinción es la mayor parte de lo que separa un sistema de negocio de una app CRUD — y me llevó un tiempo sentirla, no solo saberla.

Cuando el dinero se mueve, pasan varias cosas: una cuota se salda, un saldo cambia, un documento cambia de estado, quizás un cheque queda comprometido. Deshacer eso no es eliminar una fila: es una segunda operación que revierte cada uno de esos efectos, con su propia fecha y su propio autor, dejando los dos eventos visibles.

Por qué tiene que funcionar así

• Alguien vio el primer estado. Se corrió un reporte, se envió un resumen, se tomó una decisión. Borrarlo hace que el sistema contradiga cosas que la gente ya tiene.
• La reversa es en sí misma un hecho auditable. Cuándo pasó, quién la hizo y, idealmente, por qué.
• La aritmética tiene que cerrar. Si el saldo se deriva de movimientos, la reversa es el movimiento que lo trae de vuelta — no la ausencia del original.

La consecuencia que todos subestiman

La reversa es una operación de primera clase, tan compleja como la original y muchas veces más — porque tiene que manejar los estados que la original no anticipó. Revertir un pago que ya fue parcialmente reimputado. Revertir una entrega cuando la mercadería ya salió.

Cada “deshacer” en un sistema de negocio necesita sus propias precondiciones: en qué estado tienen que estar las cosas para que esto sea reversible, y qué hacemos cuando no lo están.

Por eso “el undo lo agregamos después” casi nunca es cierto. No es un feature arriba de la operación: es la mitad de la operación — y es la mitad que se diseña última y se usa bajo presión.