Tabla de contenidos
A nivel local, el 90% de las fórmulas que se diseñen utilizarán el lenguaje STORM debido a la simplicidad y eficiencia a la hora de establecer las sentencias que se requieren.
A continuación, se presentan ejemplos para fórmulas de tipo asignación, validación y alarmas que se pueden diseñar para su ejecución en STORM User.
De igual forma, este lenguaje tiene una serie de funciones que realizan búsquedas y asignaciones en base de datos, lo que permite acceder a los históricos de la información para comparar, validar o modificar la información.
Las fórmulas de asignación poseen una estructura sencilla, que corresponde a la definición de operaciones matemáticas para realizar la asignación a una celda del formulario. También es posible, basados en esa estructura, asignar valores que resultan de cálculos entre celdas de diferentes formularios.
Teniendo en cuenta la necesidad de información del cliente y el diseño del formulario, se pueden realizar operaciones en sentido horizontal o vertical. Cuando en necesario sumar diferentes registros de una misma fila, como lo plantea la premisa a continuación, se puede realizar de la siguiente manera:
Cálculo para TOTAL DÍAS REPORTADOS EN EL MES - NOMINA
En donde TOTAL DÍAS REPORTADOS EN EL MES - NOMINA corresponde a un campo del formulario, y lo que busca es totalizar los días reportados en ese registro en los que el trabajador realizó labores, estuvo incapacitado, tuvo vacaciones, etc. La fórmula de este caso podría plantearse así:
Por otro lado, si lo que se requiere es totalizar las columnas, es posible definir tipos de campo Total y filas totales (aquellas con código 999999) que, junto con campos numéricos + y -, realizan las respectivas operaciones de sumas y restas dependiendo al tipo de campo anteriomente mencionado cuando se utiliza la función TOTAL().
Dicha función recibe un string con el código del formulario en el que se quiere ejecutar los totales (TOTAL('<Código del Formulario>')). La siguiente premisa presenta un ejemplo de un cliente que requería totalizar una columna de su formulario de Nómina:
TOTAL CONCEPTO SUELDO - NÓMINA
Y se definió la siguiente fórmula:
Este tipo de asignaciones siempre debe hacerse a una variable COMODIN, la cual se mapea al campo total o a la fila 999999.
STORM también permite realizar fórmulas de asignación en su lenguaje que dependan de una condición, cumpliendo la siguiente estructura:
SI (condición que utiliza un operador lógico) ENTONCES RESULTADO = a SINO RESULTADO = b
Para el siguiente caso, se necesitaba asignar un valor a una celda a partir de una condición. La premisa es la siguiente:
Definir la tasa con la que se calcularán los intereses en el formulario de BALANCE POR TERCEROS.
Y la fórmula que controlaba el comportamiento se planteó así:
Las fórmulas de validación en lenguaje STORM se caracterizan por tener una estructura condicional, es decir:
SI (condición que utiliza un operador lógico) ENTONCES CORRECTO/INCORRECTO
SINO INCORRECTO/CORRECTO
Si son planteadas de una forma que no corresponde con esa estructura, el sistema mostrará un error controlado como el de la siguiente imagen:
Siendo así, la validación más común que los clientes pueden llegar a solicitar es que si el valor de una lista es X, entonces Y debe ser diligenciado, o Y no puede ser mayor que un valor Z, entre muchos otros escenarios. Para aterrizar un poco más estos escenarios, se puede utilizar la siguiente premisa como ejemplo para formular:
SI TIPO PERSONA ES JURÍDICA COLOMBIANA, DEBE DILIGENCIAR DÍGITO DE VERIFICACIÓN
Teniendo en cuenta que TIPO DE PERSONA corresponde a una lista que fue parametrizada en el sistema, el valor JURÍDICA COLOMBIANA corresponde a un parámetro de dicha lista, y DÍGITO DE VERIFICACIÓN es una celda del mismo formulario; la fórmula podría plantearse de la siguiente manera:
En el caso anterior, se deben tener en cuenta las siguientes observaciones:
- Es aconsejable formular las validaciones expresando de forma explícita el caso para el cual se debe generar el error.
- Cuando se quiera utilizar el valor que fue diligenciado en el formulario, es preferible que la variable que representa dicho valor se encuentre dentro de la función NULL(), la cual retorna el valor de la variable que se diligencia o el número 0 si la celda referenciada es nula.
- Para el valor de la variable TIPO_PERSONA, el cual corresponde a la lista anteriormente mencionada, nótese que se compara con el código del parámetro y no con la descripción del parámetro (el tipo de persona JURÍDICA COLOMBIANA corresponde al código del parámetro 3 de la lista), lo que indica que se debe tener mucho cuidado a la hora de parametrizar las listas y formular sobre dichos parámetros, así como realizar ajustes sobre las mismas, ya que implica ajustar las fórmulas que las utilizan.
- La función ISNULL() permite verificar si el valor de la variable que contiene es nulo o si contiene datos. Para el primer caso devuelve verdadero y para el segundo, falso. En ese sentido, se verifica si la celda DÍGITO DE VERIFICACIÓN (representada por la variable DIG_VERIFIC) contiene datos o no.
- Toda sentencia condicional en lenguaje STORM debe finalizarse con FIN_SI, que es lo que le indica al sistema hasta dónde van las instrucciones que debe ejecutar para dicha condición. Si no se le indica el FIN_SI a la condición, el sistema genera el siguiente mensaje de error:
Otro ejemplo puede ser comparar valores numéricos de una celda de un formulario con un valor fijo, como lo sugiere la siguiente premisa:
EL VALOR INICIAL DEL CONTRATO DEBE SER MAYOR O IGUAL A CERO
La fórmula quedaría definida de la siguiente manera:
Otros valores fijos pueden ser llamados por medio de funciones del sistema. Para el siguiente caso, se busca realizar una comparación entre dos fechas: una que se diligencia en el formulario, y la otra, la fecha de corte del envío que se está realizando. La premisa sería la siguiente:
LA FECHA SUSCRIPCIÓN CONTRATO NO DEBE SER MAYOR A LA FECHA DE CORTE
Para llamar la fecha de corte del envío que se está realizando, se utiliza la función FECHA_CORTE(), de la siguiente manera:
Nota: La función FECHA_CORTE() no recibe ninguna variable. |
El último caso para esta sección puede hacer referencia a validar que un registro de un formulario sea único dentro del mismo, para lo cual se utiliza la función BUSCAR_OCURRENCIAS_MEM(). Una premisa que hace referencia a este caso puede ser:
LA LLAVE DEL CONTRATO NO DEBE REPETIRSE DENTRO DEL FORMULARIO HOJA DE VIDA DEL CONTRATO
* Entiéndase como llave, un campo o una combinación de campos que identifican de manera única cada registro (fila) del formulario.
La fórmula que se plantea para este caso puede ser:
BUSCAR_OCURRENCIAS_MEM() devuelve el número de ocurrencias en donde se cumplan las condiciones definidas. La variable que recibe la función se parametriza de la siguiente manera:
Cuando se utiliza una función de BUSCAR OCURRENCIAS, la variable debe utilizar la función BFC: Búsqueda por Filtro Columna. Los campos Informe, Nit y Fecha de corte son opcionales (puede seleccionarse la opción No Aplica). En los campos de Formulario y Bloque, se elige el formulario en el que se realizará la búsqueda (esto implica que utilizando esta función, se pueden buscar valores de un formulario dentro de otro que corresponda al mismo envío). En la tabla que se presenta debajo de los campos anteriores, se eligen las columnas que se van a comparar del formulario donde se realizará la búsqueda, el operador de comparación (mayor que, menor que, igual a, etc.), se define si el valor con el que se va a comparar es fijo o variable y, si es variable, se ubica la celda en donde se encuentra ese valor (del mismo o de un formulario distinto).
Así como es posible ejecutar esta búsqueda a nivel local, también es posible realizar consultas a la información que se encuentra en base de datos utilizando la función BUSCAR_OCURRENCIAS(), la cual funciona y se parametriza igual que BUSCAR_OCURRENCIAS_MEM().
La única distinción que debe hacerse entre las dos (2) funciones es que BUSCAR_OCURRENCIAS() solo se ejecuta a nivel de servidor, así que alguna fórmula que la contenga debe tener desmarcado el check Funciona sobre el cliente.
En algunos casos es necesario utilizar ambas funciones en la misma fórmula cuando sea necesario garantizar que un registro sea único, tanto en base de datos como en el formulario diligenciado, o que un dato de un formulario exista en otro formulario o en la base de datos, entre otras situaciones. A continuación, se presenta un caso en donde se le está realizando una modificación a un contrato a través de un formulario, y el cliente define la siguiente condición:
EL CONTRATO QUE ESTÁ MODIFICANDO DEBE EXISTIR
Esto quiere decir que el contrato pudo ser registrado en un formulario enviado en una fecha de corte anterior, o el contrato está siendo registrado junto con sus respectivas modificaciones en el mismo envío. Para este caso, se diseñó una fórmula con la siguiente estructura:
Si se analiza esta fórmula, se puede observar que la búsqueda de la llave del contrato inicia en la base de datos (envíos previos) y si no se encuentran coincidencias, se realiza la búsqueda en el contexto del envío (actual). Nótese que las condiciones se definen para que el error se dispare únicamente cuando ha revisado ambos casos y no solo en base de datos.
- Eventos
Las fórmulas de tipo Alarma que se diseñan para ejecución en STORM User son únicamente eventos como cargue de listas dependientes y bloqueos/desbloqueos de celdas, y se asocian a celdas específicas de un formulario y no por el módulo de asociación de fórmulas.
Uno de los eventos más comunes para el cargue de listas dependientes es el de departamentos y municipios. Previo a realizar la formulación de dicho evento, es necesario contar con una serie de listas:
- Una lista con todos los departamentos del país.
- Listas con todos los municipios de cada departamento (es decir una lista con los municipios de Cundinamarca, una con los municipios de Boyacá, etc).
- Y una lista maestra que contenga todos los departamentos y todos los municipios.
Una vez creadas estas listas, se deben realizar las dependencias correspondientes entre los parámetros de la lista de departamentos, con cada lista de municipios por departamento. La lista maestra se coloca en el campo designado para el municipio, y en STORM User, este campo cargará los municipios respectivos dependiendo del departamento que se escoja.
La fórmula que controla el cargue de las listas dependientes en el campo de municipios se define de la siguiente manera:
La función CL() indica el cargue de la lista dependiente, y recibe como argumentos: CL(<Código del formulario origen>,<Bloque origen>,$fila (si se ejecuta en una fórmula heredable),<Código de la columna origen>,<Código del formulario destino>,<Bloque destino>,$fila (si se ejecuta en una fórmula heredable),<Código de la columna destino>).
Para el caso de las listas de departamentos y municipios, la columna 92 contendría los departamentos, y en la columna 96 se cargarían los municipios respectivos, dependiendo del departamento que se escoja. Una vez definida la fórmula, esta se asigna como evento a la columna 92 del formulario 3003.
El funcionamiento de los eventos de bloqueo y desbloqueo de celdas es muy similar a lo descrito para el cargue de listas dependientes. Se parte de una condición deseada dentro de un formulario, si dicha condición se cumple, ejecutará la respectiva condición, y si no se cumple, ejecutará la instrucción contraria.
Este tipo de eventos se utilizan cuando se diseñan formularios muy extensos que piden cierta información conforme se van diligenciando y obvian otra que no es necesario diligenciar, así que permiten tener un mejor control de la información de interés y hacen el diligenciamiento mucho más manejable.
El ejemplo más sencillo es partiendo de los valores de una lista, se bloqueen y desbloqueen celdas, por lo que su formulación sería:
La estructura de la función para bloquear y desbloquear celdas es la misma, y sus parámetros son: BC/DC(<Código del formulario>,<Bloque>,$fila (si la fórmula se define como heredable),<Código de la columna>).
Se debe tener en cuenta que la fórmula debe hacerse tal que siempre quede la celda desbloqueada y disponible para diligenciar cuando no se cumpla la condición de bloqueo.
- Alertas
Conceptualmente, las alertas tienen una estructura muy similar a las validaciones:
SI (condición que utiliza un operador lógico) ENTONCES ALERTA '<mensaje de alerta>'
Su formulación se realiza prácticamente de la misma manera, a excepción del uso de la palabra clave ALERTA, la cual se utiliza para definir el mensaje de alerta que se visualiza en el respectivo reporte cada vez que se satisface la condición.
A continuación, se presenta un ejemplo de formulación de una alerta, en donde se emplean diferentes conceptos y funciones:
Las asignaciones a Base de Datos son bastante útiles para casos en donde se requiera modificar información rendida en fechas de corte anteriores con motivo de modificaciones o actualizaciones. En general, este tipo de fórmulas se diseñan dependiendo de los criterios que exponga el cliente, es decir, se pueden formular con una estructura de asignación sencilla o siguiendo una serie de condiciones. A continuación, un ejemplo basado en las modificaciones que se le pueden realizar a un contrato que se encuentra en base de datos, según lo que se diligencie en un formulario, bajo la siguiente premisa:
SI EL TIPO MODIFICACIÓN ES PRÓRROGA DEBE ACTUALIZAR PLAZO DE EJECUCIÓN DEL CONTRATO
Y la respectiva fórmula se planteó de la siguiente manera:
Se puede observar que la asignación a base de datos está condicionada por el valor de la lista OPCIÓN_MODIFICACIÓN: Prórroga, así como por una búsqueda en base de datos de la llave del contrato, en donde se verifica que el contrato que se quiere modificar existe, y finalmente, la función de ASIGNAR_OCURRENCIAS(), la cual recibe una variable como parámetro, se debe asignar a la variable COMODIN ubicada dentro de la función BD() que le indica al sistema que el mapeo de la variable COMODIN corresponde a un formulario en base de datos. La parametrización de la variable que recibe la función se realiza de la siguiente manera:
Al utilizar la función ASIGNAR OCURRENCIAS(), la variable debe utilizar la función ABFC: Búsqueda y Asignación por Filtro Columna.
La primera parte de la parametrización se realiza exactamente de la misma manera que con la función BFC: Búsqueda por Filtro Columna, donde básicamente se le indican las condiciones de búsqueda para identificar en cuáles registros debe realizar la asignación.
En la segunda parte (Valores a efectuar la asignación) se debe definir la operación a realizar en los registros donde se encuentre la ocurrencia, la columna del formulario en donde se ejecutará dicha operación, establecer si la operación utiliza un valor fijo o proveniente de un formulario, y finalmente definir el valor.