Casi todos los problemas de datos de una empresa entraron al sistema por la puerta de adelante.
Nadie los cargó mal a propósito. Alguien tenía apuro, alguien no sabía que ese campo importaba, alguien completó lo que tenía a mano y pensó en volver después. Después nunca llega.
La regla de validación es el mecanismo que convierte una expectativa en una condición, y una condición en algo que el sistema verifica solo, todas las veces.
El recorrido es siempre el mismo, y por eso resulta previsible para quien carga.
| Momento | Qué ocurre |
|---|---|
| El usuario completa la ficha y guarda | La Plataforma evalúa las condiciones definidas sobre ese objeto |
| La condición se cumple | El registro se guarda con normalidad y nadie se entera de que hubo una revisión |
| La condición no se cumple | El guardado se detiene y aparece el mensaje de la regla |
| El usuario corrige | El registro entra en el siguiente intento de guardado |
La regla no corrige el dato ni lo completa sola. Frena y explica, que es exactamente lo que hace que la corrección la haga quien tiene el dato en la mano.
Las exigencias posibles cubren casi todo lo que una empresa quiere asegurar sobre su información.
| Tipo de exigencia | Qué asegura | Ejemplo |
|---|---|---|
| Presencia | Que un dato esté cargado | Una cuenta sin identificación fiscal no se guarda |
| Formato | Que el dato tenga la forma acordada | Un código de producto con la cantidad de dígitos correcta |
| Coherencia entre campos | Que dos datos no se contradigan | Una fecha de entrega anterior a la del pedido |
| Rango | Que un número esté dentro de lo permitido | Un descuento por encima del tope autorizado |
| Condición según el estado | Que algo se complete antes de avanzar | Cerrar un ticket sin cargar la causa de cierre |
| Dependencia del perfil | Que la exigencia cambie según quién carga | Un tope de descuento distinto para el equipo de ventas y para la gerencia |
Una regla que bloquea sin explicar genera un llamado a soporte. Una regla que explica bien resuelve el caso en el momento y sin ayuda de nadie.
El mensaje se puede mostrar arriba de la ficha, cuando el problema es de coherencia entre varios datos, o directamente debajo del campo que hay que corregir.
Lo segundo es casi siempre mejor, porque señala el lugar exacto en vez de dejar a la persona buscando.
El mensaje dice qué falta y qué hacer, en el idioma de quien trabaja. "La fecha de entrega no puede ser anterior a la fecha del pedido" resuelve. Un aviso genérico sobre un error de validación no resuelve nada.
Este punto es el que más se subestima al evaluar un sistema, y es el que separa una regla de una simple advertencia en pantalla.
La regla vive en la base de datos, no en la pantalla. Se aplica igual desde el navegador, desde la aplicación móvil, en una importación masiva y cuando otro sistema envía datos por una integración.
Eso significa que no existe una puerta lateral por donde entren registros que no cumplen la condición, y es lo que permite confiar en el dato después.
Una regla de validación es barata de crear y cara de sufrir si está de más.
Demasiadas exigencias frenan la operación y empujan a la gente a inventar datos para poder guardar, con lo que el remedio termina siendo peor que la enfermedad.
El criterio sano es exigir lo que se va a usar. Un dato que ningún reporte mira y ninguna decisión necesita rara vez justifica bloquear a alguien que está atendiendo a un cliente.
En EGA Futura ERP las reglas de validación funcionan sobre cualquier objeto, y son la pieza que más se ajusta durante una implementación.
Aparecen siempre las mismas, porque responden a problemas que se repiten en cualquier operación.
En Cuentas, no dar de alta un cliente sin su identificación fiscal. En Ventas, impedir un descuento por encima del tope y frenar una fecha de entrega anterior a la del pedido. En Compras, exigir la condición acordada antes de emitir la orden. En Servicio, pedir la causa de cierre antes de cerrar un ticket.
La condición la define tu empresa y la implementa el equipo de EGA Futura. El pedido se escribe en una línea de negocio, del tipo "no queremos facturar a un cliente sin identificación fiscal", y el equipo lo deja funcionando en la Org.
Ese reparto es una ventaja concreta: las reglas de una empresa cambian con el tiempo, y cada ajuste se resuelve pidiéndolo, sin que nadie de tu empresa tenga que aprender a configurar la Plataforma.
También se define el mensaje, que es parte del requerimiento y no un detalle final. Quien conoce el negocio sabe mejor que nadie cómo explicarle el problema a quien carga.
Las reglas se evalúan al guardar, así que actúan antes de que cualquier automatización posterior se dispare.
Se combinan bien con los tipos de registro y con los perfiles, y por eso una misma exigencia puede ser más estricta para un equipo que para otro sin duplicar nada.
Y como se aplican también a lo que llega por integración o por carga masiva, sostienen la calidad del dato en los circuitos donde nadie está mirando la pantalla. El resto del control operativo se ve en las características de EGA Futura ERP.
Estas son las dudas que aparecen cuando una empresa decide poner orden en la carga de datos y tiene que elegir qué exigir y con cuánta dureza.
Un campo obligatorio exige que haya algo cargado, siempre y para todos.
Una regla de validación exige una condición, que puede depender del estado del registro, del perfil de quien carga o de la relación entre varios campos. Es mucho más fina y por eso se adapta mejor a un circuito real.
La regla actúa al guardar, así que los registros históricos quedan como están hasta que alguien los edita.
Por eso conviene ordenar los datos existentes junto con la puesta en marcha de la regla, y ese trabajo se planifica una sola vez.
Sí, y es una de sus mayores ventajas. La regla vive en la base de datos, así que se evalúa igual desde el navegador, desde el celular, en una importación y cuando otro sistema envía información.
Sí. La condición puede mirar el perfil de quien carga o el tipo de registro, así que un tope de descuento puede ser distinto para ventas y para la gerencia.
Las necesarias para proteger lo que después se usa en una decisión o en un reporte.
Exigir de más empuja a la gente a completar cualquier cosa para poder guardar, y ese dato inventado hace más daño que el campo vacío que se quería evitar.
Describiendo la condición y el mensaje que tiene que ver quien carga. Con eso alcanza para que el equipo la implemente. Conviene revisar el circuito completo en una demostración del ERP.
Para quien escribe requerimientos o trabaja sobre la Org.
Una regla de validación se define sobre un objeto y se evalúa cada vez que un registro de ese objeto se guarda, sin importar el origen de la operación.
Un requerimiento completo trae estas cinco piezas, y con ellas la regla se implementa sin ida y vuelta.
| Parte | Qué define | Nota |
|---|---|---|
| Objeto | Sobre qué registros actúa | Conviene nombrarlo por su nombre de API |
| Condición de error | Cuándo se bloquea el guardado | Se escribe como la situación que se quiere impedir |
| Mensaje de error | Qué lee quien carga | Es parte del requerimiento, no un texto que se completa al final |
| Ubicación del mensaje | Arriba de la ficha o debajo de un campo | Debajo del campo cuando el problema es de un dato puntual |
| Estado | Si la regla está activa | Se puede desactivar para una carga histórica planificada |
El alcance de lo que la condición alcanza a ver define qué se puede pedir sin inventar nada.
| Origen del dato | Disponible en la condición |
|---|---|
| Campos del propio registro | Sí, incluidos los calculados |
| Campos del registro padre relacionado | Sí, a través de la relación |
| Perfil y datos del usuario que guarda | Sí, y es lo que permite exigencias distintas por equipo |
| Tipo de registro | Sí, y es la vía limpia para reglas por circuito |
| Si el registro se está creando o editando | Sí, y sirve para exigir solo en el alta |
| Suma de registros hijos u otros objetos | Se resuelve apoyando la condición en un campo calculado del propio registro |
La primera decisión es qué pasa con las cargas masivas y con las integraciones. Como la regla se aplica igual en esos caminos, un archivo de importación con un solo registro fuera de condición se frena, y el requerimiento tiene que decir si eso es lo deseado o si esos casos se preparan antes.
La segunda es el orden de ejecución. Las reglas de validación se evalúan antes de que corran las automatizaciones posteriores, así que una condición que espera un valor que otra automatización va a completar más adelante se comporta distinto de lo que su autor imaginaba.
Y la tercera es el mensaje. Una condición correcta con un aviso confuso genera tickets todos los días, y el costo de eso se paga en soporte y no en configuración.
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