Cálculos de Entrada Automática de FileMaker

En mi artículo anterior, hablé sobre la publicación en el Engineering Blog (inglés) de Claris titulada Top Tips: Optimizing Performance of FileMaker Custom Apps in the Cloud (inglés). Lea mi artículo anterior para obtener más detalles, pero en resumen, la publicación de Claris describe las formas en que puede optimizar la velocidad de su aplicación personalizada.

Mi artículo anterior analizó específicamente el uso de campos de cálculo no almacenados. Una de las alternativas a estos campos son los campos con cálculos de entrada automática, y de eso es de lo que voy a hablar en este artículo.

He creado un archivo de demostración para acompañar este artículo, titulado demo_2_v1.fmp12 (541 KB). Para abrir el archivo, necesitará estas credenciales:

• Nombre de cuenta: Admin
• Contraseña: admin

Campos de FileMaker con Cálculos de Entrada Automática​

En el archivo demo 1 que está disponible con mi artículo anterior, la tabla de productos tiene estos campos:

Cambiar el Tipo del Campo a Número

No fue necesario cambiar ninguno de estos campos con el fin de mejorar el rendimiento de la base de datos, ya que ninguno de los campos eran campos de cálculo no almacenados. Sin embargo, para ilustrar la forma en que funcionan los cálculos de entrada automática, cambié neto_c a un campo de número con un cálculo de entrada automática. Para ello, cambio su tipo, hago clic en el botón ‘Cambiar’ y luego hago clic en ‘Opciones…’ botón. Luego hice clic en la casilla de verificación ‘Valor calculado’:

Escribe la Fórmula de Cálculo

Se ha abierto la ventana de cálculo de FileMaker. Debido a que acababa de cambiar el tipo del campo de un cálculo a un número, en la ventana de cálculo estaba la fórmula que había estado en el campo de cálculo:

cantidad * precio_unidad

Esta fórmula estaba bien, así que hice clic en el botón ‘Aceptar’. La ventana de cálculo se cerró y volví a estar en la ventana de opciones. Ahora había otra casilla de verificación a considerar:

Configúrelo para Reemplazar el Valor Existente

Esta casilla de verificación controla si el cálculo se ejecuta una sola vez cuando el campo está vacío, o cada vez que la cantidad o el precio_unidad cambian. La opción de una sola vez sería útil si, por ejemplo, el precio se estableciera para rellenar cuando se seleccionara un producto. Sin embargo, para nuestros propósitos, necesitábamos que el campo de neto_c se actualizara cada vez que se cambiaba la cantidad o el precio_unidad, por lo que desmarqué la casilla de verificación y luego hice clic en el botón ‘Aceptar’.

Ahora, en lugar de mostrarme la fórmula en el cálculo, la columna ‘Opciones/comentarios’ en la lista de campos decía ‘Cálculo de autointroducción reemplaza el valor existente’. Hice clic en el botón ‘Aceptar’.

Un Cero no Deseado

Una cosa que noté inmediatamente en las pruebas fue que tan pronto como escribí un número en el campo de cantidad y salí del campo, el campo de neto_c contenía un cero. Como uno de los dos campos a los que se hace referencia en el cálculo de entrada automática había cambiado, el cálculo se ejecutó, pero el otro campo seguía vacío, por lo que FileMaker ejecutó el cálculo como si el campo vacío fuera un cero. Esto no estaba bien, así que necesitaba editar la fórmula de entrada automática.

Lo reescribí de esta manera:

If ( 
	not IsEmpty ( cantidad ) and not IsEmpty ( precio_unidad ) ; 
	cantidad * precio_unidad 
)

Luego lo escribí de manera más eficiente usando la función Let:

Let ( [ 
	c = cantidad ; 
	p = precio_unidad 
] ; 
	If ( not IsEmpty ( c ) and not IsEmpty ( p ) ; c * p ) 
)

Dejaré la discusión de la función Let para otro día, pero si desea más información, consulte la página de ayuda relevante FileMaker. Cualquiera de las dos fórmulas que utilice, el cálculo ahora solo se ejecuta si cambian tanto la cantidad como la precio_unidad.

El presentación de productos en el archivo de demostración le muestra cómo funciona esto en la práctica. En este diseño puede editar la cantidad y el precio_unidad y ver el cambio total neto.

Cálculos de Entrada Automática en Registros Relacionados

¿Cómo podemos actualizar los campos de los registros relacionados? Si editamos los productos en una factura, ¿cómo podemos reemplazar los campos de cálculo no almacenados en la factura que proporcionan el total neto, el total de impuestos y el total bruto?

El presentación de factura 1 en el archivo de demostración explora algunas soluciones posibles. El presentación enumera las facturas en el lado izquierdo. Haga clic en una de las facturas y podrá editar los productos en esa factura en el lado derecho. Mueva el ratón sobre la tabla de productos y verá que puede editar la cantidad, el producto, el precio y el porcentaje de impuestos.

Debajo de la tabla de productos hay tres filas de totales. La primera fila contiene los campos de cálculo no almacenados originales. Puede ver que estos se actualizan inmediatamente cada vez que cambia un valor numérico en la tabla de productos.

La segunda fila contiene campos numéricos que tienen cálculos de entrada automática como este:

Sum ( producto::neto_c )

En otras palabras, se espera que se actualicen automáticamente cuando neto_c cambios.

La tercera fila contiene campos numéricos que tienen cálculos de entrada automática como este:

Let ( 
	trigger = update_timestamp ; 
	Sum ( producto::neto_c ) 
)

Estos cálculos hacen referencia a un campo llamado update_timestamp, por lo que se actualizarán automáticamente cuando se edite ese campo. Un script que coloca una marca de tiempo numérica en ese campo se adjunta a los campos editables de la tabla de productos, que se activará cuando se guarden esos campos (‘OnObjectSave’).

Tres Resultados Diferentes

Si edita un valor numérico en la tabla de productos, verá tres resultados diferentes en estas tres filas de totales. En la primera fila, nuestros campos de cálculo no almacenados originales se actualizan de forma inmediata y precisa. En la segunda fila, ¡nuestros simples campos de cálculo de entrada automática no hacen nada! Esto se debe a que solo se pueden usar campos dentro de la misma tabla y registro para activar un cálculo de entrada automática.

En la tercera fila, nuestros campos de cálculo de entrada automática que tienen una referencia a un campo de activación separado parecen en primer lugar que funcionan correctamente porque los totales se actualizan. Pero luego te das cuenta de que en realidad a veces no se actualizan, y cuando lo hacen, actualizan un total a lo que debería haber sido hace un cambio.

Este comportamiento tiene su causa en la forma en que FileMaker guarda los campos y registra los cambios en la memoria caché. En términos generales, se produce porque una edición que acaba de realizar en un registro relacionado aún no se guarda en la memoria caché de FileMaker para que se recupere cuando se active el cálculo de la suma. Para el registro relacionado específico que ha editado, FileMaker utiliza el valor anterior que se encuentra en su memoria caché.

Resolviendo este Problema

Así que la fila 3 nos proporciona una solución que está cerca de hacer lo que queremos, pero es errática. El presentación de Facturas 2 proporciona un remedio a este problema. 

Además de tener el mismo guion que antes activado cuando se guardan objetos de campo editables (‘OnObjectSave’), hay otro guion que se activa cuando se confirma el registro (‘OnRecordCommit’). El guion tiene estos pasos (de los que he eliminado comentarios y líneas vacías):

If [ $$disable_script_trigger ]
    Establecer variable [ $$disable_script_trigger; Valor:Null ]
    Salir del guión [ ]
End If
Establecer variable [ $$disable_script_trigger; Valor:True ]
Consignar registros/peticiones [ Sin diálogo ]
Establecer campo [ factura::update_timestamp; GetAsNumber ( Get ( CurrentTimestamp ) ) ]

La mejor manera de averiguar qué está pasando con este guion es trabajar de abajo hacia arriba. Recuerde que el propósito principal de estos guiones que se activan es establecer el campo update_timestamp, de modo que los campos con cálculos de entrada automática actualicen sus valores. La línea 7 del guion edita el campo update_timestamp.

Para resolver el problema de las ediciones de los registros relacionados que aún no están disponibles para su suma, la línea 6 confirma el registro, que confirma todos los registros relacionados al mismo tiempo. Sin embargo, esto introduce un gran problema: si este guion se activa cuando se confirma el registro, ¿no hará que el guion no se ejecute de nuevo? ¿Y ese guion no hará que se ejecute otra copia del guion, y así sucesivamente?

¡Si!

Las líneas 1 a 5 del guion resuelven este problema. Estas líneas utilizan una variable denominada ‘$disable_script_trigger’. Cuando el guion se ejecuta la primera vez, ‘$disable_script_trigger’ no tiene ningún valor, por lo que la línea 1 se evalúa como False y el guion salta a la línea 5. La línea 5 establece ‘$disable_script_trigger’ en True. Cuando la línea 6 confirma el registro, se desencadena la segunda instancia del guion. Pero esta vez, la línea 1 se evalúa como True, porque ‘$disable_script_trigger’ se ha establecido en True. Así que la línea 2 borra la variable y la línea 3 sale del guion.

Reflexiones Finales​

En aplicaciones personalizadas que tienen una función de facturación, tiendo a recomendar tener campos de cálculo no almacenados y campos con cálculos de entrada automática. Los campos de cálculo no almacenados son muy útiles en el diseño utilizado para editar la factura porque proporcionan actualizaciones inmediatas sobre los totales de las facturas y la sobrecarga de rendimiento suele ser lo suficientemente pequeña como para ser imperceptible o trivial.

Los campos con cálculos de entrada automática se utilizan para los datos que deben resumirse más a lo largo del diagrama de relaciones o en los informes. El hecho de que estos campos se puedan indexar puede tener un efecto muy beneficioso en el rendimiento de la aplicación.