La mayoría de los campos de un sistema guardan lo que alguien escribió en ellos.
Un campo de fórmula hace lo contrario: guarda una instrucción, y el valor aparece recién cuando hace falta mostrarlo.
Esa diferencia, que parece técnica, resuelve uno de los problemas más viejos de cualquier planilla compartida.
Conviene entender qué se gana antes de mirar cómo funciona.
Un total escrito a mano envejece en el momento en que cambia alguno de sus componentes.
Un campo de fórmula se recalcula solo, así que no existe la posibilidad de que muestre un número desactualizado.
Al no ser editable, el campo no admite un error de tipeo ni una cuenta hecha con la calculadora del teléfono.
La regla queda escrita una sola vez y se aplica igual en los miles de registros del objeto.
Cuando alguien pregunta cómo se calcula un indicador, la respuesta está en la definición del campo y no en la memoria de una persona.
El alcance de lo que la fórmula puede mirar es lo que define qué preguntas puede responder.
Es el caso más directo, y sirve para restar, sumar o comparar valores que ya están en la misma ficha.
Restar la cantidad reservada de la cantidad en depósito para saber qué queda realmente libre es exactamente esto.
La fórmula también puede seguir una relación hacia arriba y traer un dato del registro padre.
Así una línea de pedido muestra el nombre del cliente sin que nadie lo copie, y una asignación de activo muestra el nombre del activo entregado.
Comparar una fecha guardada contra el día de hoy es lo que convierte una fecha muerta en un semáforo.
De ahí salen los campos que avisan cuántos días faltan para un vencimiento o cuántos pasaron desde que se creó un registro.
El tipo de resultado se elige al definir el campo y cambia por completo para qué sirve después.
Una fórmula que devuelve un número se puede sumar y promediar en un informe, mientras que una que devuelve texto sirve para etiquetar y agrupar.
Una que devuelve una casilla marcada o vacía funciona como una bandera, y es la forma más limpia de separar los registros que cumplen una condición.
También hay fórmulas de fecha, que calculan un vencimiento a partir de otra fecha, y fórmulas que devuelven un enlace directo a otro registro.
Un campo de fórmula es una herramienta de lectura, y eso define con precisión dónde encaja.
Se calcula en el momento de mostrarlo, así que su valor siempre corresponde al estado actual de los datos y no a una foto de un momento pasado.
Cuando el negocio necesita conservar el valor que tenía un dato el día que se cerró una operación, lo que corresponde es un campo común que se completa una vez y queda fijo.
Los dos conviven en el mismo objeto sin problema, y saber cuál pedir en cada caso es la mitad del trabajo de un buen requerimiento.
Hay tres señales que no fallan y se ven sin abrir la configuración.
La primera es que el campo se muestra en modo lectura aun cuando el resto de la ficha está en edición.
La segunda es que su valor cambia solo, sin que nadie haya tocado ese campo, apenas cambia alguno de los datos que lo alimentan.
La tercera es que en las importaciones masivas el campo no figura entre los que se pueden completar, porque no hay nada que cargar en él.
Reconocerlos rápido evita horas de búsqueda cuando alguien intenta corregir un número que en realidad se corrige en otro lado.
El ERP usa campos de fórmula en los lugares donde un dato mal copiado costaría caro, y conviene ver tres casos reales.
En el objeto Stock, la Cantidad disponible es una fórmula y no un número que alguien escriba.
El sistema la obtiene a partir de la existencia registrada y de la cantidad ya reservada, así que muestra lo que queda libre para comprometer en una venta nueva.
Al ser calculada, cada reserva que se toma se refleja en el acto, y nadie tiene que acordarse de ajustar el disponible.
Una póliza guarda su fecha de vencimiento, y un campo de fórmula la convierte en un estado legible.
La fórmula devuelve Vencida si la fecha ya pasó, Por vencer si cae dentro de los próximos treinta días, y Vigente en el resto de los casos.
Con eso, una Vista de lista de pólizas se convierte en un tablero de renovaciones sin que nadie compare fechas a mano.
Cuando se asigna un activo fijo a una persona, una fórmula arma el texto que se ve en la ficha del empleado.
Muestra el nombre del activo y le agrega la marca (Asignado) mientras la fecha de devolución siga vacía.
El día que se carga la devolución, la marca desaparece sola, porque el dato que la sostenía cambió.
Definir un campo de fórmula exige elegir el tipo de resultado, escribir la expresión y probarla contra los datos reales.
Ese trabajo lo hace EGA Futura, que administra la Org, así que tu empresa no necesita contratar a nadie que sepa programar para tener el cálculo que le falta.
Alcanza con describir la regla en palabras de negocio, del tipo avisar cuando falten menos de quince días para el vencimiento del contrato.
Es servicio incluido, y es la razón por la que estos cálculos se piden con la misma naturalidad con la que se pide una columna nueva en un informe.
Estas son las dudas que aparecen la primera vez que alguien intenta editar un campo que no se deja.
Porque es un campo de fórmula y no existe un valor propio para guardar en él.
Lo que se ve es el resultado de un cálculo, así que para cambiarlo hay que cambiar alguno de los campos que lo alimentan.
Si el resultado no es el esperado, el problema está en esos datos de origen o en la regla, y no en el campo que lo muestra.
No guarda un valor almacenado, porque se calcula en el momento de mostrarlo.
Eso también explica por qué el campo no aparece entre los que se completan al importar datos.
Sí, y es uno de sus usos más valiosos.
Un campo de fórmula funciona como columna, como agrupación y como criterio de filtro, igual que cualquier otro campo del objeto.
Una fórmula que devuelve un número se puede además sumar y promediar en el total del informe.
El campo se actualiza solo, sin que haya que guardar nada aparte.
Esa es justamente la ventaja: el valor mostrado siempre corresponde al estado actual de los datos.
Para eso conviene un campo común, que se completa una vez y queda fijo.
Una fórmula muestra siempre el valor de hoy, así que un precio histórico se registra en un campo propio del comprobante.
Los dos tipos conviven en el mismo objeto y cada uno responde una pregunta distinta.
Alcanza con describir la regla en palabras, diciendo qué tiene que mostrar el campo y a partir de qué datos.
EGA Futura administra la Org y lo implementa, así que quien pide no necesita saber escribir la expresión ni conocer los planes del ERP para hacerlo.
Esta sección es para quien escribe requerimientos sobre campos calculados o trabaja sobre la Org, y necesita nombrar bien lo que pide.
El tipo se elige al crear el campo y condiciona todo lo que se puede hacer después con el resultado.
| Tipo de retorno | Qué devuelve | Nota |
|---|---|---|
| Number | Un número con la cantidad de decimales que se defina | Se puede sumar y promediar en informes |
| Currency | Un importe con la moneda del registro | Respeta la moneda del campo CurrencyIsoCode |
| Percent | Un porcentaje | Útil para márgenes y cumplimientos |
| Text | Una cadena armada por concatenación o por condiciones | Sirve para etiquetar y para agrupar |
| Date y Date/Time | Una fecha calculada a partir de otra | Base de los cálculos de vencimiento |
| Checkbox | Verdadero o falso | La forma más limpia de marcar una condición |
Estas tres están definidas en la Org y sirven de referencia para redactar un pedido parecido.
| Campo API | Objeto | Qué calcula |
|---|---|---|
| EGAFutura__AvailableQuantity__c | Stock | La cantidad libre, a partir de la existencia y de la cantidad reservada |
| EGAFutura__ValidityStatus__c | Póliza | El estado de vigencia sobre la fecha de vencimiento, con aviso de treinta días |
| EGAFutura__HFFT_Activo_Asignado__c | Asignación de activo | El nombre del activo, con el sufijo (Asignado) mientras la devolución esté vacía |
Es el caso donde más importa conocer el valor exacto, porque un filtro escrito con otra palabra no devuelve nada.
| Condición | Valor devuelto |
|---|---|
| Fecha de vencimiento vacía | Vacío |
| Vencimiento anterior a hoy | Vencida |
| Vencimiento dentro de los próximos treinta días | Por vencer |
| Cualquier otro caso | Vigente |
Hay cuatro consecuencias de diseño que conviene tener presentes al redactar un requerimiento.
La primera es que un campo de fórmula no es editable por nadie, así que pedir que en un caso puntual se pueda corregir a mano implica pedir un campo distinto.
La segunda es que el valor refleja siempre el presente: si el negocio necesita el dato congelado al momento de una operación, corresponde un campo común completado por el proceso que registra esa operación.
La tercera es que las fórmulas leen datos del propio registro y de sus registros padre, así que un cálculo que necesite recorrer los hijos se plantea de otra manera y conviene decirlo al pedirlo.
La cuarta es que el resultado hereda la seguridad del campo de origen, o sea que quien no ve el dato que alimenta la fórmula tampoco ve el resultado, y eso se controla con la seguridad a nivel de campo.
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