Un registro sirve si puedes reconstruir el hecho

Hay dos cosas que se parecen mucho y no son lo mismo: tener los papeles y poder reconstruir un hecho. La primera es un archivador. La segunda es poder contestar, sin llamar a nadie, quién entregó qué, a quién, en qué fecha, con qué documento vigente en ese momento y por qué se hizo así.

Si esa respuesta vive en tres planillas y en la memoria de la persona que estaba ese día, el problema no es de orden. Es de diseño: el sistema nunca guardó lo que después iba a hacer falta.

Lo que hay que guardar es el movimiento, no el estado

La tentación de todo software de gestión es guardar el estado actual. Es más barato, se ve más limpio y alcanza para operar. El problema aparece cuando alguien pregunta por el pasado: el estado actual no tiene pasado.

Nosotros guardamos cada transición como un hecho propio. Cada vez que algo cambia de estado queda registrado quién lo movió, con qué rol y en qué momento, y el motivo cuando lo hay — obligatorio donde hay que justificar una decisión, como la corrección de una entrega. No es un campo «última modificación»: es una línea nueva que se agrega a la historia de esa entidad, y las anteriores quedan donde estaban.

Suena obvio dicho así. En la práctica es la diferencia entre poder decir «el 4 de agosto a las 11:40, este operador movió este pedido a entregado» y poder decir «hoy está entregado».

La prueba de fuego son las correcciones

Todo registro real se corrige. Alguien anota una cantidad de más, se equivoca de fecha, agrega un producto que no correspondía. Lo que hace un sistema con esa corrección revela cuánto vale su traza.

Hay dos formas de resolverlo. Una es sobrescribir: el dato queda correcto y el error desaparece. Ordenado, y completamente inútil para una fiscalización, porque borra justo el hecho que alguien podría preguntar.

La otra es agregar. Cuando en nuestro producto se corrige una entrega ya registrada, la corrección exige un motivo —no es opcional— y deja un evento nuevo con el antes y el después de lo que cambió: qué producto se agregó o se quitó, qué cantidad pasó de un número a otro, si la fecha se movió. Los eventos anteriores no se tocan.

Si corregir un registro borra lo que decía antes, no tienes un registro: tienes el estado actual con buena presentación.

Lo mismo vale para los documentos del expediente. Cargar una versión nueva no reemplaza a la anterior: la anterior queda marcada como superada, con la fecha en que dejó de ser la vigente. Así se puede contestar la pregunta difícil, que no es «qué documento tiene hoy», sino «qué documento estaba vigente el día que ocurrió el hecho».

Tres preguntas para tu sistema de hoy

Antes de comparar herramientas conviene medir la que ya tienes. Si no puedes contestar estas tres en menos de un minuto, sin llamar a nadie, el problema no lo va a resolver una planilla mejor:

• ¿Quién registró la última entrega de esta persona, y a qué hora?
• Si alguien corrigió un registro la semana pasada, ¿puedes ver qué decía antes y por qué se cambió?
• ¿Qué versión de un documento estaba vigente el día en que ocurrió el hecho que te preguntan?

Lo que hoy no tenemos

Sería fácil cerrar acá diciendo que con nosotros la traza sale «exportable con un clic». No es cierto, así que no lo decimos: hoy no existe una exportación de la historia. Se consulta dentro del producto, entidad por entidad, y eso alcanza para responder una pregunta puntual pero no para entregar un archivo.

Es una carencia conocida y está anotada como tal. Si tu operación necesita entregar un archivo a un tercero de forma periódica, es mejor que lo conversemos antes de que sea un problema, y no después.

Lo que sí podemos afirmar es lo otro: que el dato exista, que tenga autor, rol y hora —y motivo donde el producto lo exige—, y que nadie lo pueda reescribir sin dejar rastro. Esa parte no se puede agregar después. O el registro nació así, o no nació.