Las facturas no se borran

Un usuario pide borrar una factura. La respuesta correcta es que no se puede, y entender por qué enseña la mayor parte de lo que hace distinto al software de gestión.

Una factura no es una fila

Una factura no es un registro de tu aplicación. Es un documento con numeración secuencial, emitido a alguien, generalmente informado a la autoridad fiscal. Borrarla rompe la secuencia, elimina la evidencia de algo que genuinamente ocurrió, y deja a la contraparte con un documento que tu sistema niega que exista.

El dominio ya tiene la respuesta, y es más vieja que el software: un asiento no se borra, se contraasienta. La factura se anula, o se emite una nota de crédito contra ella. Ambos son registros nuevos que referencian al original. La historia se lee: esto pasó, y después esto lo deshizo.

La distinción se propaga por todo el modelo

• Cancelar es un estado y una fecha, no una ausencia.
• Una nota de crédito es su propio documento, con su propio número y sus propios renglones — no es una factura en negativo.
• Revertir un pago escribe un movimiento de reversión; el original queda.
• Incluso para registros internos, borrar destruye la respuesta a “¿qué decía el sistema el martes pasado?”.

El instinto del programador es el opuesto al del dominio

El instinto de programación dice que eliminar la fila es la forma limpia de deshacer. En un sistema de negocio es exactamente al revés: la fila es un hecho, y los hechos no dejan de haber ocurrido.

Una vez que lo internalizás, buena parte del diseño se simplifica. Casi nada se borra. Las cosas se reemplazan, se revierten o se cierran — y la trazabilidad es el producto.

Es uno de los principios con los que construimos los circuitos de dinero de nuestros sistemas: cobranzas, caja y cuenta corriente son libros mayores, no tablas editables. Cuando un auditor (o el dueño) pregunta qué pasó, el sistema tiene la respuesta completa.