Búsqueda y arrays, una forma de hacer multibúsquedas (y II)

Intentaré explicar con otro ejemplo una nueva forma de hacer multibúsquedas en una tabla de datos usando de nuevo los arrays de Velneo.

El planteamiento es sencillo pero suficiente para desarrollar dos formas de hacer una multibúsqueda sobre una misma tabla: una con una rejilla en la que escogemos los datos de quién queremos mostrar de dentro de una lista de ellos y otra en la que introducimos nosotros los datos como si fuese un histórico.

Tenemos dos tablas, una de CLIENTES  y otra de VISITAS,  ésta última histórica de la primera, en la que iremos guardando las visitas que le hacemos a cada cliente en diferentes fechas. No he querido crear más campos para que el ejercicio fuera lo más sencillo y claro posible.

Esquema inicial de tablas

Esquema inicial de tablas

Primer planteamiento: el objetivo es que la aplicación busque todas las visitas que se han hecho a los clientes que yo elija en una rejilla en la que me muestra todos los clientes. Es lo que he llamado en el mapa visitas múltiple  selección y los objetos usados se guardan en la carpeta del mismo nombre.

He creado una tabla DUMMY  en memoria que se va a cargar con todos los clientes cada vez que se necesite a través de un tubo de lista.

esquema dummy

Esquema de tablas con CLIENTES, VISITAS y DUMMY

Con un formulario especial de la tabla VISITAS donde se muestra una rejilla con todos los DUMMY,  editable en su campo %ESCOGER%,  que en principio vale 0, pero que podemos cambiarlo en esa rejilla a 1 para que nos  busque las VISITAS  a ese CLIENTEDUMMY. Tras tener escogidos los CLIENTES  que queremos el proceso utiliza una cesta de VISITAS  y la potencia de los arrays, para ir cargando en la cesta las visitas de cada uno de los CLIENTES seleccionados y mostrarlos al final en una rejilla de la tabla VISITAS. Como se puede observar, la tabla DUMMY  no tiene ningún tipo de conexión con las otras dos tablas.

proceso multi

Proceso con DUMMY y "multiselección".

En el proceso se crea una cesta local de visitas donde se irán añadiendo las visitas de los CLIENTES  elegidos.

Se vacía la DUMMY   y  se rellena posteriormente mediante un tubo de lista con todos los clientes. Se crea el array.

A continuación se muestra un registro de VISITAS en el que hay una rejilla con los datos de la DUMMY. El primer campo %ESCOGIDO% es editable y se puede cambiar su valor de o a 1.

Se carga la lista DUMMY  por el índice “escogido” ( formado por el código y con campo condición para indexar %ESCOGIDO% igual a 1 ) y se van añadiendo al array los códigos de los clientes guardados en el campo %CODIGO%  de la tabla DUMMY.

Por último se caga el array, y se va leyendo cada item, que irá modificando la variable global en memoria $COD-CLIENTE$ para así lanzar la búsqueda VISITAS-COD-CLIENTE  y añadir los resultados obtenidos a la cesta. Por último se muestra la cesta.

Este planteamiento se lanza en la opción de menú búsqueda múltiple con rejilla editable

Segundo planteamiento. el objetivo es que la aplicación busque todas las visitas que se han hecho a los clientes que yo haya introducido en una rejilla. Es lo que he llamado en el mapa visitas múltiple  dando altas y los objetos usados se guardan en la carpeta del mismo nombre.

He creado una tabla DUMMYDOS  en memoria  a la que se van a añadir los clientes que se quiera mediante un formulario de alta

esquema con dummydos

Esquema con CLIENTES,VISITAS y DUMMYDOS

Esta vez DUMMYDOS si que actúa como histórica de CLIENTES, pues necesito rellenar esta tabla con un localizador y para ello , necesito que CLIENTES sea maestra de DUMMYSDOS.

El proceso llamado varía un poco, pero también creo que es sencillo y fácil de comprender.

proceso dummydos

Proceso que alimenta la cesta de las visitas

En este caso, cuando se recorre la lista de DUMMYDOS,  el dato que se debe añadir al item del array es el puntero al CLIENTE, que guarda el campo %CODIGO% de la ficha del maestro CLIENTES.

El segundo  planteamiento se lanza en la opción de menú búsqueda múltiple con rejilla “alimentada”

Seguro que es mejorable, pero es sólo un ejercicio para ver cuánto partido le podemos sacar a Velneo.

Link de descarga del mapa completo y en el foro de Velneo.

EDICION (8-sep-2010)

Tal y como me comenta por e-mail mi compañero y sin embargo amigo 🙂 Adelo Herrero el primer planteamiento se puede hacer sin la tabla DUMMY  usando la misma tabla de CLIENTES para simular la multiselección con el campo %ESCOGIDO%.

Tienes toda la razón Adelo. Se agradece el comentario y subo al link de descarga la versión actualizada con tu sugerencia.

Un saludo.

Con Velneo se pueden hacer muchas cosas!!!

Hace poco, revisando la Wikipedia, me encontré con este artículo. Me pareció interesante desde el principio  y hoy mismo lo volví a revisar y me propuse dejar a un lado los programas habituales de gestión y dedicarle un tiempo a intentar simular dicho juego.

En principio , la idea se basa en una única tabla, VMAESTROS (aprovechando el almacén de objetos, :-)) que para que los cálculos fueran más ágiles, la hice en memoria.

Incluye cuatro campos además del código:

  • FILA , numérico de longitud 1, para guardar la fila en la que está la ficha
  • COLUMNA, numérico de longitud 1, para guardar la columna
  • VIDA, booleano, para indicar si la célula está viva ( valor 1 ) o muerta (valor 0)
  • SIGUIENTE, también booleano, que me dará el estado de la célula en el siguiente “turno”

De la tabla, sólo conservo el índice código y creé otro formado por la terna FILA-COLUMNA que me servirá para posteriores cálculos además de para mostrar las fichas con el objeto visual casillero, organizado por filas y columnas como si fuera una matriz.

Las premisas del juego so:

  • Una célula muerta con exactamente 3 células vecinas vivas “nace” (al turno siguiente estará viva).
  • Una célula viva con 2 ó 3 células vecinas vivas sigue viva, en otro caso muere o permanece muerta (por “soledad” o “superpoblación”).

El estado siguiente  de una célula  en la posición fila F columna C de su estado inicial y de los estados de las 8 células que le rodean

Trama de las celdas

Luego, el próximo estado de CF ha de depender de otros 8 valores y será calculado por la premisa primera del juego o de la segunda, dependiendo del estado de VIDA  de CF inicial. Y todo ha de calcularse para cada una de  las células.

Para eso utilicé el campo%SIGUIENTE%  en el que podré calcular el valor de CF en la siguiente “jugada”.

proceso recálculoEn el proceso se recorre la lista en modo lectura/escritura, para modificar el campo SIGUIENTE  llamando a la función TOYVIVA  a la que le pasamos los parámetros FILA, COLUMNA y VIDA.

función vida

Calcula el estado siguiente de la celda CF

Si el “no está viva” (parámetro _estado=0), entonces se ataca la segunda premisa y se ve el estado de las otras 8 células que le rodean y se cuentan cuántas de ellas viven. Si viven 3, se retorna como valor de función 1, es decir, en la siguiente jugada la célula estará viva.

Si “vive” (parámetro _estado=1) vamos a la primera premisa pero esta vez inicializamos el contador no a 0 como antes sino a -1 dado que la célula CF ya está viva pero no la podemos contar. Si encontramos que hay 2 ó 3 vivas seguirá viva y si no, morirá en la siguiente jugada.

Una vez la función me devuelve todos los valores, vuelvo a recorrer en el proceso la lista para pasarle al campo VIDA  el valor guardado en SIGUIENTE y volver a poner este último a cero.

Para que fuera algo más vistoso en cuanto a funcionamiento, creé dos menús

  • MENU INICIAL  en el que aparece el casillero para que podamos dar vida a las células que queramos con un click en cada casilla o ponerlas todas a cero. Todas las fichas se crean al iniciarse el programa en el proceso llamado desde el menú AUTOEXEC  con el proceso VMAESTROS (que genera una “matriz! de 40X40) pero que podeis cambiar por el llamado GENERA  que pide el número de filas y columnas a generar
  • MENU VIDA en el que se han sincronizado dos casilleros iguales, pegados uno encima del otro con una variable global booleana VISIBLE que hace los efectos del refresco tras los recálculos. A su vez, para que no se tenga que dar a una opción de menú cada vez que se quiera ver la evolución dinámica del juego, en este menú he puesto una opción texto estático en vertical llamada Recalcular, con la opción Timer, cada cuantos en 1, para que se repita cada vez que el timer del menú ( puesto cada 2000 milisegundos)

Espero que os guste  o que al menos os entretenga.

Para los foreros de Velneo , el enlace de descarga en el foro y para los que no , este enlace de descarga externa.

Un saludo.

Búsqueda y arrays, una forma de hacer multibúsquedas (I)

Hace poco, un amigo me planteó el siguiente problema  que se le daba en una aplicación.

En una empresa, hay una serie de departamentos. Dentro de cada departamento, hay niveles de acceso a la información de una tabla (NOTICIAS). Cada persona de la empresa tiene un determinado NIVEL  dentro de cada DEPARTAMENTO y una persona solo puede acceder a las informaciones de cada uno de sus departamentos y dentro de ellas a las que su nivel se lo permita. Por ejemplo, si hay 10 niveles y tengo asignado en el departamento de contabilidad el nivel 4, podré acceder a toda la información de contabilidad con nivel 4, 5, 6,7,8,9 ó 10.

El esquema de tablas que hice fue el siguiente:

Esquema

Esquema de tablas

La tabla CLASIFICACION  tiene como objetivo mantener un histórico de los DEPARTAMENTOS  y NIVELES que tiene en cada uno de ellos cada PERSONA de la empresa. Tiene solamente tres campos punteros a maestro PERSONAS, DEPARTAMENTOS y NIVELES  y un índice de clave única formado por los tres campos punteros.

La tabla NOTICIAS  ( puede también llamarse APUNTES o NOTIFICACIONES, como cada cual quiera ) tiene un campo CODIGO, NOMBRE y un puntero a DEPARTAMENTO y otro a NIVELES que le renombré como Nivel Mínimo. A su vez creé un índice formado por la terna DEPARTAMENTO-NIVEL .

Para que desde una ficha de modificación de persona, se muestren las NOTICIAS  que le corresponde, monté los siguientes objetos visuales:

  • variable global en memoria  DEPARTAMENTO
  • variable global en memoria NIVEL
  • variable global en memoria TOTAL NIVELES

Las tres numéricas

  • Una búsqueda en la tabla NOTICIAS: NOTICIAS-PERSONA, en la que se busca por dos índices, primero por el de departamento, parte izquierda, valor $DEPARTAMENTO$  al que se le cruza la búsqueda por el índice NIVEL, entre límites, limite inicial $NIVEL$ , límite final $TOTAL NIVELES$
Búsqueda

Búsqueda de noticias-personas

  • Un proceso con origen ficha de PERSONAS que alimenta la rejilla que se mostrará en el formulario de modificación de la persona,con  las noticias a las que tiene acceso.

Proceso

En este proceso son fundamentales tres cosas: la cesta y los dos arrays.

Un array es un vector, con muchas dimensiones, es una forma de guardar datos de forma momentanea en un proceso y acceder a ellos dentro del mismo proceso.

El primer array (array departamento), guardará en cada item el DEPARTAMENTO que se guarda de la persona en la tabla CLASIFICACION y en el segundo (array nivel ) , el NIVEL. Con ello conseguimos tener por cada persona la terna DEPARTAMENTO-NIVEL, cada una en un array.

Sólo nos queda hacer un bucle for que se repita un número de veces igual al número de items que tienen los arrays para ir llamando a la búsqueda NOTICIAS-PERSONAS sucesivamente e ir añadiendo los resultados de cada una de ellas a una cesta local, que al final procesaremos y será la que se muestra en el formulario.

Podeis descargarlo aquí http://forum.velneo.com/es/viewtopic.php?p=80270#80270

Sincronizaciones en menús ( I ): dos búsquedas

Una posibilidad a la que podemos dar buen uso y sacar partido rápido es la sincronización de objetos en un menú.

Los objeos que vamos a poder sincronizar entre sí serán

  1. Variables
  2. Búsquedas
  3. Casilleros
  4. HTMlL

Entre una variable y una búsqueda lo vimos aquí y ahora veremos entre dos búsquedas.

Supongamos el caso que nos comenta Javier. Tenemos por un lado una búsqueda de clientes y por otro lado una búsqueda de Facturas.

El objetivo es que una vez que tenga en un menú las dos búsquedas colocadas, al moverme por los registros de la de Clientes, me muestre en la de Facturas todas las facturas de dicho cliente seleccionado.

Para lograr esto necesitamos:

En la tabla Clientes:

  1. Una rejilla en la que mostrar los clientes: CLIENTES-SINCRO, por ejemplo.
  2. Una variable global en memoria  que llamaremos COD-CLIENTE en la que guardaremos el código del cliente sobre el que estamos
  3. Un proceso con origen lista de la tabla Clientes, y en la que su única linea de proceso será:              Modificar variable global, $COD-CLIENTE$, %CODIGO%

          Esta linea irá guardando en la varialble en memoria el código del cliente según nos vayamos     posicionando sobre sus registros. Le llamaremos ONCLIENT, por ejemplo.

    4. En la rejilla CLIENTES SINCRO, activaremos el check “Cambio selección simple ” y escogeremos el proceso ONCLIENT.

    5. Una búsqueda en la tabla CLIENTES , rejilla para ver resultado, CLIENTES-SINCRO y a la que llamaremos CLIENTESTODOS

En la tabla de Facturas:

  1. Una rejilla para mostrar los registros.
  2. Un índice alimentado por el campo CLIENTES, acepta repetidas.
  3. Una búsqueda por el índice CLIENTES, modo de buscar, parte izquierda de la clave, y resolviendo el CLIENTE  con la variable COD-CLIENTE , a la que llamaremos FACTURAS-CLIENTES , por ejemplo.

En un menú tipo formulario, pondremos las dos búsquedas CLIENTES TODOS y  FACTURAS-CLIENTES.

Hay que tener claro cuál de las dos búsquedas es la que “manda”. En este caso, es la búsqueda de CLIENTES, dado que al variar el cliente, variará la búsqueda de facturas para sólo mostrar las del cliente seleccionado.

Una vez colocadas en el menú, cogemos el foco sobre CLIENTES-TODOS. En la barra de menú, vamos a la opción Controles—Sincronizar. En el cuadro de diálogo que nos aparece, escogemos la búsqueda FACTURAS-CLIENTES  y ya tenemos sincronizadas las dos búsquedas.

¿Tubos?… ¿y eso qué es? (ii)

Les toca el turno ahora a los tubos de lista. Antes hemos visto que los tubos en general producen altas en una tabla de destino tomando datos de una tabla origen. En el caso de los tubos de lista, además, tanto el origen como el destino pueden ser no tablas de nuestra aplicación sino bases de datos externas.

Tubo de lista

Cuando en la galería de objetos escogemos un tubo de lista nos encontramos con este cuadro de diálogo. En él podemos ver las características esenciales de un tubo de lista:

Estilos:

Privado: Si se activa esta opción el tubo solamente podrá ser disparado desde donde el programador indique, si está desactivado el usuario final podrá dispararlo desde cualquier lista de la tabla de datos de origen del tubo. Hemos de tener en cuenta que en ejecución, cuando tenemos en pantalla una lista resultado de una búsqueda en la barra de Herramientas la opción Procesos, nos aparece un desplegable en el que podremos lanzar tubos o procesos SI NO ESTÁN MARCADOS COMO PRIVADOS
No indexar y hacer regen al final: Si se trata de un Tubo de importación, de puede activar o desactivar esta opción. Reduce enormemente el tiempo de duración de la importación de datos. Primero realiza la importación de datos y posteriormente regenera los índices de tabla de destino.  Antes de ejecutar un tubo de importación con esta opción activada, es aconsejable borrar previamente los registros de la tabla de datos de destino (la de Velneo) o que esta contenga muy pocos registros, pues esta opción ni comprueba los campos código ni lo indexa hasta que no se hayan importado todos los registros. Velneo recomienda  no utilizar nunca esta opción en el caso de que la tabla de destino tenga definido el contenido del campo código como Siguiente al último, pues, al no indexarse los registros al ejecutar el tubo, todos los registros importados quedarán con el mismo código. De hecho es siempre aconsejable que la importación la hagamos previamente a un tabla intermedia, no a la tabla definitiva, para evitar problemas. Una vez que hacemos todas las comprobaciones, con un nuevo tubo de lista pero esta vez interno, nos llevamos los datos de la intermedia  a la definitiva.

Usar contenido inicial campos destino: Si se activa esta opción al generarse los registros se dispararán los contenidos iniciales definidos en los campos de la tabla de datos de destino. Es aconsejable por tanto no crear en el tubo capilares para los campos de la tabla de destino que tengan establecido un contenido inicial.
Usar código automático en destino: Este estilo solamente estará activo cuando se haya desactivado el estilo anterior (usar contenido inicial campos destino). En el caso de que la tabla de destino sea maestra, es decir, que tenga definido un campo CODIGO y, si su contenido inicial es Siguiente al último, habrá que activar este estilo para que la codificación de los registros de la tabla de sea automática. Si este estilo está desactivado y el código se pasa en un capilar, si en la tabla de destino existe algún registro con el mismo código, el registro no será dado de alta.

Usar actualizaciones en destino: Si la tabla de datos de destino tiene definidas actualizaciones, si se activa esta opción al generarse los registros éstas serán disparadas, si no, no.

Además los flujos de la informacion pueden ser internos, de importación o de exportación. He de confesar que tanto el In-com Serie como el Out-com Serie no los he usado nunca, pero tengo entendido que son un primer intento de comunicación mediante puerto serie, antes de que ese objeto visual concreto se desarrollara.

En los casos de flujo Interno, es decir, cuando el origen y el destino son tablas de Velneo, es posible hacer un alta de ficha en un maestro de la tabla destino. Señalando la opción ¿Dar alta?, se activan las listas desplegables Maestro,  Formulario, y Formulario visualización final salida tubo. En la primera se elige la tabla maestra donde se desea realizar el alta. En la segunda se elige el formulario para el alta. En la tercera se indica el formulario donde se puede ver el resultado final del tubo.

La casilla de verificación ¿Pedir? se utiliza para declarar el formulario mediante el cual se puede introducir un valor fijo en uno o en varios campos de todas las fichas de destino.

La forma de crear los capilares es idéntica a la de los tubos de ficha.

 Una diferecia fundamental a la hora de elegir entre recorrer una lista para lanzar un tubo de ficha por cada uno de los registros o cargar una lista y lanzar un tubo de lista estriba en que a la salida del tubo de lista no podemos hacer nada en los registros recién dados de alta, es decir, en el tubo de lista no hay Pre y Post como en el de ficha. A veces esto puede ser una ventaja y otras no, eso depende del gusto de cada uno. Particularmente, cuando necesito hacer traspasos masivos uso el de lista pero en la mayoría de los procesos, prefiero los tubos de ficha pues me permiten un mayor control sobre la salida del tubo, en el Pre puedo modificar campos, por ejemplo. Pero esto debe tomarse no como una recomendación ha tener en cuenta, sino como un simple gusto personal o manía, llamadlo como querais.

En el siguiente artículo, veremos dos procesos de facturación de albaranes, uno con tubos de lista y otros con tubos de ficha.

¿Tubos?…¿y eso qué es? (i)

A raiz de una pregunta aparecida en le foro de Velneo hecha por lordnight en la que casi al final del hilo pedía una explicación sobre lo que son los tubos, me dispongo a dar una pequeña anotación sobre ellos.

Los objetos visuales de Velneo, aparecen en la parte derecha del vDeveloper y son la forma de comunicación entre la estructura y sus datos y el usuario final. Se encargan tambiénd de facilitarnos la vida y el trabajo a los desarrolladores y ahorrarnos un montón de quebraderos de cabeza. Uno de estos objetos visuales son los tubos.

¿..Y eso de los tubos qué hace en realidad?. Pues los tubos se usan para traspasar datos de una tabla a otra. Tienen una tabla origen y una tabla destino, con la particularidad de que en la salida del tubo, se producen altas de registros en la tablas destino.

Tubo de ficha

Los tubos conectan dos tablas entre sí y sólo dos tablas y no todos los campos tienen porqué “viajar” de una tabla a la otra. Para determinar que campos van a llevarse a la tabla de destino se usan los capilares. En un capilar escogeremos un campo de destino y el origen del dato, que puede ser un campo de la tabla origen o una concatenación de campos o de variables globales o de funciones, ya que de nuevo nos encontramos con el asistente de fórmulas. En este ejemplo concreto he creado un tubo de ficha para traspasar datos de las Lineas de Albarán a las lineas de facturas. Los capilares son el puntero a Artículo y la cantidad. El resto de los campos no los necesito llevar al destino, ya que en ella se ejecutarán al darse de alta los nuevos registros que salen por el tubo tanto los contenidos inciales de los campos , como los campos de tipo fórmula como los triggers o eventos de tabla que afecten a las altas así como las actualizaciones que tengamos definidas.

Los tubos pueden se suelen lanzar desde procesos y siempre desde una linea cuyo origen sea ficha de la tabla origen . Un tubo de ficha lanzado desde un proceso puede ser llamado de dos formas, con dos lineas dsitintas:

Tubo de ficha, en el que es necesario que hayamos definido un formulario de salida del tubo, un formulario que nos presenta la ficha para darla de alta en la tabla destino y Tubo de ficha sin pedir formulario, en el que no nos pide dicho formulario. Esta última es la más utilizada.

Si usamos Tubo de ficha simplemente y dicho tubo no tiene definido un formulario de salida, la linea de proceso no se ejecuta, con lo que es más recomendable usar Tubo de ficha sin pedir formulario

Acompañando a estas lineas de procesos de tubo de fichaTubo de ficha aparecen dos lineas cuyo origen es siempre la ficha de la tabla destino. En el Pre, podremos cambiar cualquier valor de cualquier campo del registro de salida, pero en el Post no, solo podremos hacer comprobaciones, por ejemplo, o guardar valores en variables locales o globales.

Los tubos pueden darnos un gran juego  a la hora de hacer cosas como facturar albaranes. Cuando veamos en el siguiente artículo los tubos de lista, haremos un ejemplo práctico de factuación de un único albarán en una factura o de varios albaranes en una única factura.

Sincronizaciones en Menús

Una de opciones de menú que se suele utilizar es la búsqueda, cualquiera de ellas, Busqueda que devuelve una rejilla con los registros encontrados ( excepto si no hay ninguno ), Busqueda permite vacío que nos devuelve la rejilla aunque sea vacía de contenido o la Búsqueda formulario que nos devuelve el resultado en una rejilla si encuentra más de un registro o en el formulario asignado como de modificación en la rejilla asociada a la búsqueda si sólo encuentra un elemento por ese criterio..

Las búsquedas son una de las pistolas que pueden lanzar dos balas. La primera bala es la búsqueda en sí y la segunda puede ser un formulario, un histórico , un gráfico o una página web. La más usada es posiblemente el histórico. Cuando nos movemos por los registros de la búsqueda , va mostrando los valores del histórico de la ficha marcada. Este es un primer paso de sincronización entre dos componentes, una búsqueda y el histórico.

Pero en muchos casos necesitamos movernos por registros de una tabla y que varíen los registros de otra relacionada con

ella sin que la relación sea directamete de maestro->histórico.

Esto lo podemos solucionar de una manera sencilla con la sin

cronización de búsquedas en un Menú. En los menús, podemos sincronizar varias cosas entre sí: variables globales, búsquedas, casilleros y páginas html. Empecemos por un caso sencillo.

Tenemos una aplicación en la que tenemos una estructura Cabecera de factuas , Lineas de Facturas, Clientes y Artículos.

En la tabla Cabeceras hemos creado un campo fecha y su índice correspondiente, acepta repetidas

Esquema

Lo que vamos a hacer primero es crear una sincronización en un menú, con una varible global fecha, en memoria, y una búsqueda de CFacturas por fecha.

Variable Fecha

El índice por el que vamos a buscar las facturas es la FECHA, de forma parte izquierda de la clave, y resolviendo por el valor de la variable $FECHA$.

Nos queda colocar los controles en un Menú que llamaremos Sincronización.

Barra del menú

En la barra encontramos los distintos controles que podemos usar. En nuestro caso usaremos un Calendario, que irá asociado a la variable $FECHA$ y una búsqueda que será la que acabamos de crear

También podríamos colocar un control de edición de variable, pero queda mejor en ejecucíón el control calendario.

 Una vez que los dos controles están colocados, tenemos que ver qué control manda.Menú sicronizado

Al variar la $FECHA$ tendrán que cambiar las facturas y mostrarnos las que sean de esa fecha determinada.

Luego $FECHA$ sincroniza a la búsqueda . Con un único click del botón izquierdo del ratón hacemos que el calendario coja el foco.

En la barra de herramientas, vamos a la opción Controles–>sincronizar y de las opciones que aparecen escojemos la búsqueda de facturas a fecha.

Con esto ya tenemos sincronizada la variable con la búsqueda.

Este caso es el más sencillo. Veamos a continuación cómo sincronizar dos búsquedas entre sí.

Tenemos el caso de de dos búsquedas, una de clientes ordenadas alfabéticamente ( índice Nombre ) y otra de todas las facturas por cliente (índice Clientes ) y queremos que al movernos por los registros de clientes, varíen las facturas y nos muestre sólo las de ese cliente seleccionado en la rejilla. El método es siempre el mismo.

Primero saber cuál de las dos búsquedas “manda ” sobre la otra. Al variar el cliente cambian las facturas.

Segundo crear una variable global en memoria que guarde en qué registro de la que manda estamos. Lo habitual y más lógico es guardar el códigod de la ficha.

Tercero. Un proceso con origen ficha de la tabla principal cuya única linea haga que se guarde en la variable global el valor del índice de la ficha.

Cuarto: indicarle a la rejilla usada en la búsqueda principal que tiene que lanzar ese proceso al cambiar de ficha ( flag “Cambio selección simple ” en la rejilla )

Quinto. Sincronizar la primera con la segunda búsqueda en el menú.

En nuestro ejemplo: la búsqueda de clientes ” manda ” o más correctamente SINCRONIZA  a la búsqueda de facturas. Una variable global en la que guardar el código del clientes seleccionado. Un proceso con origen ficha de Clientes en el que modificamos la anterior variable con el valor del campo código. Este proceso lo asignaremos como el que hay que disparar al activar el flag ” Cambio selección simple ” en la rejilla asociada a la búsqueda de Clientes

La búsqueda de Facturas la haremos por el índice Clientes, forma de buscar, parte izquierda de la clave y como límite inicial de la búsqueda, la variable en donde hemo guardado el código del cliente.

 

Por último sólo nos queda hacer que la búsqueda, la de clientes, SINCRONIZA la segunda búsqueda de Cabeceras de Facturas.

Si necesitásemos sincronizar esta segunda búsqueda con otra tercera, solo tenemos que seguir los pasos explicados para conseguirlo.

De este modo en un solo menú podemos tener tantas sincronizaciones como necesitemos.

A %d blogueros les gusta esto: