La mayoría de las discusiones dentro de una empresa no son sobre el dato de hoy, sino sobre el de ayer.
Alguien recuerda que el precio era otro, que la fecha de entrega estaba más adelante, que el pedido nunca llegó a estar aprobado. El Historial de campo existe para que esa conversación tenga respaldo.
Es una funcionalidad de la Plataforma que anota, sola y sin que nadie se lo recuerde, cada cambio hecho sobre los campos que se eligieron seguir.
Cada vez que alguien guarda un cambio sobre un campo seguido, la Plataforma escribe una línea nueva con cinco datos.
| Dato | Qué responde |
|---|---|
| Usuario | Quién hizo el cambio |
| Fecha y hora | Cuándo lo hizo |
| Campo | Qué dato se tocó |
| Valor anterior | Qué decía antes |
| Valor nuevo | Qué quedó después |
Ninguno de los cinco se escribe a mano, y esa es exactamente la razón por la que el historial sirve como evidencia.
El seguimiento se activa campo por campo, y esa decisión es de negocio antes que técnica.
Seguir todo produce un ruido que después nadie lee. Seguir lo que importa produce una historia corta y clara de cada registro.
Son los que mueven dinero, los que fijan compromisos y los que habilitan a alguien a hacer algo.
Precio, descuento, cantidad, fecha comprometida, estado, cliente asignado y responsable del registro son los sospechosos habituales en cualquier empresa mediana.
Los descriptivos largos y los que se completan una sola vez al crear el registro llenan el historial sin agregar nada que alguien vaya a consultar después.
El historial se lee dentro del propio registro, como una Lista relacionada al pie de la ficha, ordenada de lo más reciente a lo más viejo.
También alimenta informes, y ahí cambia de escala. Deja de responder qué pasó con este pedido y pasa a responder cuántas veces se modificó un precio después de aprobado, o qué usuario reabre registros que ya estaban cerrados.
Tres situaciones se repiten en cualquier operación, y las tres se cierran de la misma manera.
Un cliente reclama que le facturaron distinto de lo acordado. Con el historial, la respuesta sale en segundos, con nombre y con fecha.
Un pedido avanzó sin la aprobación que correspondía. El historial muestra en qué momento el estado cambió y quién lo movió.
Cuando alguien pide trazabilidad sobre un dato sensible, el historial es la evidencia y no hay que reconstruir nada.
La Plataforma sigue hasta veinte campos por objeto, que alcanzan de sobra para el circuito habitual de una empresa mediana.
Para las operaciones que necesitan auditar más, existe EGA Futura Database Field History Expander, un complemento que lleva el seguimiento hasta sesenta campos por objeto.
El complemento registra lo mismo en cada entrada, con usuario, fecha, hora y valores anteriores, y está pensado para los objetos que concentran la operación crítica del negocio.
Qué incluye cada edición de EGA Futura ERP y cómo se suma el complemento está detallado en la página de precios.
En EGA Futura ERP el Historial de campo funciona sobre cualquier objeto del sistema, tanto los estándar de la Plataforma como los propios del ERP.
La operación crítica se concentra en unos pocos lugares, y ahí es donde el seguimiento se paga solo.
En Ventas se siguen el precio, el descuento y el estado de la orden. En Compras, el precio del proveedor y la fecha comprometida. En Inventario, los ajustes de cantidad. En la ficha del empleado, la remuneración y el puesto.
La configuración la hace el equipo de EGA Futura. Tu empresa define qué campos necesita auditar y por qué, y el equipo lo deja funcionando en la Org.
Es una diferencia concreta del modelo de trabajo: nadie de tu empresa necesita aprender a administrar la Plataforma ni contratar un especialista para resolver una tarea de configuración.
El requerimiento se escribe en una línea, del tipo "necesitamos saber quién cambia el descuento de una orden y cuándo", y con eso alcanza para que quede implementado.
Lo primero es mirarlo en el registro, que es el uso diario y resuelve casi todas las dudas del día.
Lo segundo es llevarlo a informes, para pasar del caso puntual al patrón. Un informe de cambios de precio por usuario y por mes muestra cosas que ningún reporte de ventas muestra.
Lo tercero es usarlo como insumo de las revisiones internas, porque el historial no depende de que alguien se acuerde de anotar lo que hizo.
El resto de las capacidades de control y trazabilidad están descritas en las características de EGA Futura ERP.
Estas son las dudas que aparecen cuando una empresa decide auditar sus datos en serio y tiene que elegir qué seguir y para qué.
No. Las entradas del historial las escribe la Plataforma y no son editables por un usuario del sistema, que es justamente lo que las vuelve confiables.
Un registro que cualquiera pudiera retocar no serviría como evidencia de nada.
En los campos calculados el valor se deduce de otros, así que lo que conviene seguir son los campos base que los alimentan.
Si seguimos la cantidad y el precio de cada línea, ya tenemos explicado cualquier movimiento del total.
El historial respeta los mismos permisos que el resto del sistema. Quien no tiene acceso a un registro tampoco ve su historial, y la seguridad a nivel de campo sigue valiendo igual.
Sí, y quedan con el usuario que ejecutó la operación. Es uno de los usos más útiles del historial, porque permite separar lo que tocó una persona de lo que tocó un proceso automático.
Desde el momento en que el seguimiento queda activo sobre ese campo.
Por eso conviene definir los campos críticos al inicio de la implementación, junto con el resto del circuito. Es una de las cosas que se conversan al armar la demostración del ERP.
Los que alguien vaya a consultar de verdad. Una lista corta y bien elegida se lee de un vistazo, y una lista larga se convierte en un archivo que nadie abre.
Para quien escribe requerimientos o trabaja sobre la Org.
El seguimiento se activa primero por objeto y después campo por campo. Cada cambio genera una entrada propia, asociada al registro que cambió.
Estos son los datos que la Plataforma escribe, con la aclaración que conviene tener presente al pedir un informe sobre ellos.
| Dato | Contenido | Nota |
|---|---|---|
| Usuario | Referencia al usuario | Es quien guardó el cambio, que puede no ser quien lo pidió |
| Fecha | Fecha y hora del cambio | Se muestra en la zona horaria configurada en la Org |
| Campo | El campo seguido | Conviene pedirlo por nombre de API, porque dos campos pueden tener etiquetas parecidas |
| Valor anterior | Lo que había antes | |
| Valor nuevo | Lo que quedó |
Esta tabla es la que evita que un requerimiento pida algo distinto de lo que después va a recibir.
| Caso | Comportamiento |
|---|---|
| Campos estándar y personalizados | Se siguen hasta veinte por objeto |
| Con EGA Futura Database Field History Expander | El seguimiento llega hasta sesenta campos por objeto |
| Campos de texto largo y de selección múltiple | Queda registrado que hubo un cambio, con su usuario y su fecha |
| Campos calculados, como una fórmula o un roll-up | Se siguen los campos base que los alimentan |
| Cambios hechos por una carga masiva o una integración | Se registran igual, con el usuario que ejecutó la operación |
| Consulta del historial | Disponible en la Lista relacionada del registro y en informes |
Un pedido de seguimiento se resuelve rápido cuando trae cuatro cosas: el objeto, la lista de campos con su nombre de API, quién va a consultar el historial y si lo va a mirar en la ficha o en un informe.
El dato que más conviene anticipar es el momento. El seguimiento registra desde que queda activo hacia adelante, así que los campos críticos se definen junto con el circuito y no después del primer conflicto.
Y una aclaración que ahorra una reunión: el historial responde quién cambió un valor, no por qué lo cambió. Cuando el motivo importa, el requerimiento suma un campo de causa al lado del campo seguido, y así el historial guarda las dos cosas.
Ventas, compras, inventario, finanzas y equipo, con la información al día y disponible desde cualquier dispositivo. Funciona en la nube, así que no hay servidores que mantener.
Quiero llevar mi Empresa a la Nube