The Seed Company Software

Una de las novedades incluidas en la versión 7.7 de la plataforma empresarial Velneo v7 es la inclusión del objeto Combo-view.

En este artículo vamos a explicar su funcionamiento con un ejemplo sencillo que podéis descargar aquí files.me.com/jovefer/ozz7rn

Usando tres Combo-view vamos a seleccionar un País de una lista. Después seleccionaremos las Regiones de ese País y por último seleccionaremos las Poblaciones de esa Región.

Vamos a explicar dos maneras de hacerlo:

• Usando variables globales

• Usando búsquedas en tercer plano y presentando la información en cestas.

Lo primero será crear 3 tablas: PAI (Paises), REG (Regiones) y POB (Poblaciones). Todas las tablas son maestras. En la tabla REG hay un campo enlazado a PAI y en la tabla POB hay un campo enlazado a la tabla REG.

Hemos creado también dos variables globales en memoria que podremos usar en las búsquedas

Una vez visto el proyecto  de datos vamos a ver los objetos que tenemos en el proyecto de aplicación

Deberemos crearnos 3 objetos Combo-view. Tal como indicamos en la siguiente imagen deberemos seleccionar la tabla a presentar .

En el Contenido pondremos el campo/s a mostrar. Aunque se nos permita poner mas de un campo y ponerlos en mas de una linea de texto hay que saber que aunque veamos todo el texto escrito al desplegar el combo-view, sobre el elemento seleccionado sólo podremos ver una línea.

También podremos seleccionar un campo Objeto Dibujo de nuestra tabla para mostrar antes del registro así como un icono en el caso de que no tengamos ninguna imagen asociada al registro.

Si queremos también podremos indicarle formularios de alta, modificación y baja. Podremos acceder a estos formularios pulsando con el botón derecho del ratón sobre el registro seleccionado en el Combo-view.

• DESARROLLO MEDIANTE VARIABLES GLOBALES

• Tendremos 3 búsquedas: PAI_VAR_GLO , REG_VAR_GLO y POB_VAR_GLO.
  • En la búsqueda PAI_VAR_GLO buscamos todos los registros de la tabla.
  • En la búsqueda REG_VAR_GLO buscamos por el índice PAI. Parte izquierda de la clave usando la variable global PAI.
  • En la búsqueda POB_VAR_GLO buscamos por el índice REG. Parte izquierda de la clave usando la variable global REG.
• En el formulario INI crearemos 3 Objetos Vista de datos tal como indicamos en la imagen siguiente. Ese Objeto Vista de datos se compondrá de la búsqueda correspondiente y del combo-view de cada tabla.

• Ahora deberemos crear los eventos que nos cargarán las Regiones y las Poblaciones
  • Evento REG_VAR_GLO. En este evento cargaremos en un combo-view las Regiones del pais seleccionado.

• Evento POB_VAR_GLO.En este evento cargaremos en un combo-view las Poblaciones de la Región seleccionada.

• Lo último será crear las conexiones de evento. Estas conexiones de evento se lanzarán mediante la señal Item: cambio de seleccionado de la Vista de datos de Paises y de Regiones. Ejecutando los eventos REG_VAR_GLO y POB_VAR_GLO respectivamente

• DESARROLLO MEDIANTE BUSQUEDAS EN 3er PLANO
  • Lo primero será crear 2 cestas: REG y POB.
  • Igual que en el caso de hacerlo mediante variables globales tendremos 3 búsquedas: PAI, REG y POB. La diferencia es que en las búsquedas REG y POB en vez de utilizar variables globales para resolver los índices PAI y REG usaremos variables locales  a las que daremos valor desde los eventos de búsqueda en el formulario INI.

• Tenemos 2 procesos: VER_REG y VER_POB. Estos procesos nos servirán para mostrar el contenido de la cesta en el formulario INI. Ambos procesos no tiene origen, el destino es la tabla que les corresponda: REG o POB y lo único que hacen es procesar la cesta correspondiente y devolver la lista a la salida

• En el formulario INI crearemos 3 Objetos Vista de datos .
  • El primer Objeto vista de Paises será igual que el creado para el caso de variables globales. El primer objeto será la búsqueda PAI y el segundo objeto será el Combo-view PAI
  • Los otros dos Objetos Vista de datos tendrán como primer objeto el proceso que les corresponda : VER_ REG o VER_ POB y como segundo objeto el combo-view correspondiente

  

• En el formulario INI tendremos los siguientes eventos:
  • Evento REG_3er_PLA.En este evento cargaremos en una cesta las Regiones del pais seleccionado.

• • Evento POB_3er_PLA. En este evento cargaremos en una cesta las Poblaciones de la Región seleccionada.

• Las conexiones de eventos las realizaremos igual que en caso de hacerlo mediante variables globales. Estas conexiones de evento se lanzarán mediante la señal Item: cambio de seleccionado de la Vista de datos de Paises y de Regiones. Ejecutando los eventos REG_3er_PLA y POB_3er_PLA respectivamente

Tanto si usamos el método de variables globales o de búsquedas en tercer plano deberemos crear en el formulario INI una conexión de evento que se lanzará al inicializarse el formulario que ejecute o bien el evento REG_VAR_GLO o REG_3er_PLA para que se inicialicen las Regiones con el valor del primer País de la lista.

• Impresoras lógicas

La impresora lógica es un objeto que nos servirá para que el usuario pueda elegir, en tiempo de ejecución, desde qué impresoras físicas van a salir sus informes.

En los informes deberemos elegir que la salida por defecto sea una impresora lógica y asociarle una de las impresoras lógicas creadas.

Cuando un informe tiene asociado una impresora lógica y ésta tiene asociada una impresora física, al mandar imprimir el informe saldrá directamente por la impresora asignada.

Si un informe tiene asociada una impresora lógica y esa impresora lógica no está asociada a una impresora física, al imprimirlo por primera vez, nos pedirá que elijamos la impresora física y ésta será asociada a la impresora lógica para las siguientes veces.

Si un informe no tiene asociada impresora lógica y tampoco se la asociamos en la instrucción Imprimir Informe, a la hora de imprimir nos pedirá que elijamos una impresora física y durante esa sesión será la impresora que coja por defecto para las siguientes impresiones.

Si el informe no tiene asociada una impresora lógica pero le asignamos la impresora lógica en la instrucción Imprimir Informe cada vez que queramos imprimir el informe nos pedirá que elijamos una impresora física.

La asociación de impresoras lógicas será guardada en un archivo en la caché local del vClient, en una carpeta llamada printers.  Esta caché es generada por máquina y usuario. Así que si más de un usuario ejecuta sesión en una máquina cada uno de ellos tendrá su propia asignación de impresoras.

• Archivo: Configurar impresoras lógicas

Para poder mostrar en ejecución la pantalla de asignación de impresoras deberemos crear una acción que ejecute el comando Archivo: Configurar impresoras lógicas.

• Comando Exportar informe a fichero

Este comando de lista nos permite generar un fichero (pdf o eps ) en disco a partir de un informe.

• Imprimir desde un formulario

Hasta la aparición de la v7 7.6 teníamos un problema para incluir un botón para imprimir un informe en un formulario.

Ejemplo: Tenemos un formulario de albaranes con sus datos de cabecera y un control objeto para mostrar las líneas del albarán. Si hacíamos cualquier cambio en la cabecera y pulsábamos un botón que ejecutase un proceso para imprimir el albarán nos encontrábamos con el problema de que no nos cogía los cambios realizados en la cabecera.

En la v7 7.6 podemos evitar esto usando la instrucción  Interfaz: Guardar la ficha en alta o modificación. Con el uso de esta instrucción se nos guardará el cambio realizado en la ficha y ya podremos imprimir nuestro informe sin problemas.

La versión 7.6 de la plataforma de desarrollo Velneo V7 trae novedades importantes en cuanto a las rejillas editables.

A parte de solucionar  alguna incidencia referida a la edición de números con decimales caben destacar las siguientes novedades:

• Señales a nivel de columna

A partir de ahora podremos asignar eventos a las columnas de una rejilla.

Como se muestra en la imagen podremos, por ejemplo, asociar un evento a la pérdida de foco de una columna.

• Nuevas señales de edición

También aparecen nuevas señales para controlar la edición:

Edición iniciada: El evento asociado a la conexión se disparará cuando se inicie la edición de un registro en la rejilla.

Edición aceptada: El evento asociado a la conexión se disparará cuando se finalice la edición, es decir cuando se guarden los cambios en la edición de un registro una rejilla.

Edición cancelada: El evento asociado a la conexión se disparará cuando se  cancele la edición de un registro de una rejilla.

NOTA importante sacada de la ayuda de la web de Velneo : “Debemos tener en cuenta que si en un evento de interfaz ejecutado desde una columna de una rejilla editable usamos el comando de instrucción de proceso Set retorno proceso = NO, su ejecución solamente hará que no se ejecuten otros eventos asociados asociados a otras columnas editables del registro que esté siendo editado. Por lo tanto, si queremos hacer que no se avance el foco o se cancele la edición del registro al editar una celda de una rejilla tendremos que hacerlo mediante el control de la señal de tecla pulsada (tabulador o enter).”

• Nuevo comando de interfaz: Obtener ficha en edición de la rejilla

Esta instrucción nos sirve para acceder a la ficha en edición.

Ejemplo: Ejecutamos en evento (imagen anterior) que es ejcutado al perder foco una columna FECHA de una rejilla editable. Si cambiamos el valor de esa columna, al perder foco el primer mensaje nos mostrará el valor incial de la ficha, y después de obtener la ficha el segundo mensaje nos mostrrá el valor cambiado.

Una de las novedades de la versión v7 7.5 que más agilizará el trabajo a los programadores es la opción de copiar y pegar Subobjetos.

Seleccionándolo en el panel de Subobjetos podremos, pulsando los botones de Copiar y Pegar , duplicar ese Subobjeto en el Objeto principal o pegarlo en otro Objeto.

Posibilidades de duplicado que nos abre el copiado / pegado de Subobjetos:

• Columnas en Rejillas. Así conseguiremos copiar todas sus propiedades y sólo tendremos que elegir el nuevo campo.
• Componentes de una búsqueda.
• Eventos, Conexiones de eventos y variables de un formulario.
• Campos e índices de tablas.
• ….

En TheSEEDGestión 1.0 tomamos la decisión de prescindir de los localizadores que nos ofrece la plataforma Velneo para montar nuestros propios localizadores.

Al final decidimos utilizar la misma pantalla tanto el mantenimiento de la tabla como para localizar registros de esa misma tabla.

Este post complementará al post anterior en el que explicábamos como montar un panel de búsqueda: http://www.theseedsc.com/blog/panel-de-busqueda/

Veamos como hemos de montar una pantalla de mantenimiento / localizador de artículos:

Tengo una tabla estática donde voy a decir cómo será la búsqueda: Alfabética, por Trozos, Palabras, Alguna palabra. Esta tabla está disponible en la open app vBase.

En la tabla ARTICULOS he de tener los siguientes índices: NAME, PARTS y WORDS. En los índices PARTS y WORDS añado los campos por los que voy a buscar. En nuestro caso añadimos las distintas referencias del artículo, su nombre y su nombre TPV. Además añadiremos los índices por los que querramos buscar los artículos. En nuestro caso buscaremos también por Estado, Marca, Familia, Proveedor, Area competencia, Fecha alta y Fecha modificación.

En nuestro caso tenemos una tabla PARAM_BUS que utizamos para tener los distintos campos de tablas por las que vamos a poder buscar.

Ahora vamos a ver el formulario y todos los objetos relacionados.

Tenemos:

• Dos rejillas: ART y ART_LOC.  La primera se visualizará en el formulario ART_MAN cuando estemos en mantenimiento de tabla y la segunda se visualizará cuando utilicemos el formulario en modo localizador. Además ART_LOC no tiene asignado un formulario de modificación, ya que en el formulario tendrá asignada una conexión de evento al hacer doble-click.

• Una cesta ART_PRV que utilizaremos para mostrar los registros.
• Un proceso ART_MAN que no hace nada. Tiene como origen .Ninguno y como destino la ficha de la tabla PARAM_BUS. Utilizamos este recurso ya que, desde una acción, no podemos disparar como objeto un formulario con origen una tabla. Y el formulario ART_MAN tiene como origen la tabla PARAM_BUS.
• Un proceso VER_AR. En este proceso tiene como origen la ficha de PARAM_BUS y como destino la lista de ARTICULOS.

• Una búsqueda ART. Esta búsqueda será disparada desde el formulario ART_MAN. En esta búsqueda añadiremos todos los índices por los que querramos buscar. Estos índices estarán condicionados a variables locales que recibirán valor desde un evento situado en el formulario ART_MAN.

• Un bloc ART. Este objeto es opcional y lo usamos para dar la opción al usuario final de ver la información de otra manera.
• Una acción ART. Esta opción disparará dos objetos. El Objeto1 será el proceso ART_MAN y el Objeto2 será el formulario ART_MAN. Como explicamos antes tenemos que disparar el proceso antes para conseguir que, cuando utilizamos el formulario como mantenimiento de artículos, lo devuelva a pantalla completa.
• Un formulario ART_MAN que utilizaremos de formulario de mantenimiento y de localizador. Este formulario que pertenece a la tabla PARAM_BUS se divide en varias partes:
• PARTE SUPERIOR

Botones para dar de alta, modificar, dar de baja, visualizar/ocultar los parámetros de búsqueda, refrescar los parámetros de búsqueda y exportar a excel.
Tenemos un combobox enlazado al campo BUS_TIP_ATP de la tabla PARAM_BUS y una variable local TXT_BUSQUEDA que utilizaremos para buscar por varios campos.

Botón que lanzará la búsqueda de artículos y un botón que sólo se verá si estoy accediendo como localizador que nos servirá para seleccionar un registro.

• PARTE CENTRAL

En esta zona tenemos los distintos campos, de la tabla PARAM_BUS, por lo que podremos filtrar la búsqueda de artículos.

Esta zona tiene condicionada la visibilidad a una variable local del formulario VER_BUSQUEDA.

• PARTE INFERIOR

En esta zona se encuentran los dos Control Objeto con los que visualizaremos los artículos dependiendo de que estemos en modo mantenimiento o en modo localizador. Cada control tiene una condición de visibilidad al valor de una variable local SOY_LOCALIZADOR.

En este control el primer objeto será el proceso VER_AR y después en cada uno una de las rejillas ART y ART_LOC.

Aunque tengamos dos control objeto igual, al inicializar el formulario no se calcularán los dos ya que sólo recalcularemos el objeto que visualicemos.

EVENTOS IMPORTANTES

INICIALIZAR

En este proceso lo primero que hago es dar valor a los campos de la búsqueda. Lo tenemos que hacer aquí y no utilizando el contenido incial de un campo ya que al disparar el formulario mediante Disparar objeto no respeta los contenidos iniciales de los campos de la tabla.

Lo siguiente que hago es vaciar la cesta ART_PRIV.

Después dependiendo de la variable LNZ que nos indica si queremos que se muestren los registros al cargar el formulario ejecutaré el evento que lanzará la búsqueda

Si no tiene valor LNZ controlaremos con SOY_LOCALIZADOR si tenemos que recalcular una rejilla u otra.

ALTA y BAJA.

Lo único que cambia en estos eventos es que hay que elegir o Interfaz: Formulario de alta o Interfaz: Fomulario de baja.

EDICION

La forma de editar las fichas de artículos es distinta dependiendo que sea un localizador o no ya que la rejilla ART_LOC no tiene formulario de modificación.

BUSCAR

En este evento lo primero que se hace es vaciar la cesta.

Creamos el manejador de objeto con la búsqueda ART pasándole los valores a las variables de la búsqueda.

Disparamos la búsqueda en 3er plano y el resultado lo agregamos a la cesta.

Después dependiendo de si accedo en modo localizador o no recalcularé un control u otro.

REFRESCAR

En este proceso lo primero es vaciar la variable TXT_BUSQUEDA, e inicializar el resto de campos de búsqueda. Después ejecutamos el evento BUSCAR para que nos devuelva toda la lista de artículos.

SELECCIONAR

Este evento se disparará desde el botón de la parte superior derecha y mediante una conexión de evento: Item:doble-click sobre el Control Objeto LISTA_LOC. Con este evento daremos valor a la variable local ARTICULO que retornaremos al evento que llame a este formulario para localizar un registro.

Ya sólo nos queda llamar a este formulario desde otro formulario.

En este ejemplo vamos a hacerlo desde nuestra tabla de líneas de albaranes.

El formulario de líneas de albaranes es el siguiente:

El botón de localizar artículos disparará el siguiente evento.

De este evento lo que nos interesa es la zona incluida en el recuadro rojo. Lo que hacemos es crear un manejador de objeto con el formulario creado anteriormente ART_MAN y le damos valor a la variable del formulario SOY_LOCALIZADOR. Así conseguiremos que nos muestre el botón para seleccionar registros y la rejilla de localizador con la que podremos seleccionar registros mediante el doble-click.

También podemos localizar artículos utilizando la variable local que  está dentro del recuadro rojo del formulario de líneas de albarán.

Al perder foco esta variable disparamos el siguiente evento.

De este evento lo que nos interesa es la zona incluida en el recuadro rojo.

Lo primero comprobamos que la variable tenga valor para seguir o finalizar el proceso.

Después llamamos a un proceso en el que le pasamos el valor de la variable y él se encarga de lanzar la búsqueda de artículos y, si el resultado es de más de un registro, lanza el localizador de artículos para seleccionar el que deseemos.

Por último recogeremos el valor del artículo para modificar la línea del documento.

____________________________________________________________________________________________________

Esperamos que el artículo os haya sido de ayuda. Y aunque os parezca mucho trabajo, para el resto de tablas sólo habrá que copiar la estructura y cambiar el origen de la tabla.

Para cualquier aclaración no dudéis en poneros en contacto con nosotros.

Un saludo.

En TheSEEDGestión 1.0 tenemos varias formas de configurar las condiciones de compra de nuestros artículos:

1.- Tarifas descuentos

Tenemos la opción de definir tarifas de descuentos que después podremos asignar a los Proveedores, Familias y Precios Especiales.

2.- Precios por Artículo

Podemos definir tanto el precio como los descuentos en la propia ficha del Artículo.

3.- Precios por Proveedor

Un Artículo puede tener distintos precios dependiendo del Proveedor al que se lo compremos. Además puedo definir distintos precios dependiendo de las unidades compradas: Precio Unitario y  5 escalados.

4.- Precios Especiales

Podemos configurar unas condiciones especiales Artículo / Proveedor para un determinado rango de fechas.

5.- Descuentos por Familia

Para un Proveedor puedo definir, para determinadas familias, unas tarifas de descuento distintas a las que tenga el Proveedor en su ficha.

Siguiendo con los artículos sobre la futura open app vBase hoy vamos a analizar la tabla Entidades y el resto de tablas relacionadas con ésta.

Como el anterior post esta información está sacada del Análisis funcional de vBase que se publicará en breve.

ENTIDADES

En esta tabla estarán todas las Entidades con las que nos relacionaremos.

En esta tabla se encontrarán los Clientes, Proveedores, Vendedores, Contactos, Direcciones, Empresas, Almacenes, etc.

Tendremos datos de la persona física o jurídica,  sus datos de contacto: emails, teléfonos, direcciones.

La diferenciación de Entidades la lograremos con la tabla Categorías.

CATEGORIAS

En esta tabla tendremos las distintas Categorías a las que pertenecerán las Entidades.

Algunas de estas Categorías serán reservadas y deberán ser creadas desde otros módulos de nuestro ERP como por ejemplo las Categorías: CLIENTES, PROVEEDORES, VENDEDORES, etc.

Estas Categorías podremos hacer que sean por Empresa o globales.

Las Categorías se relacionan con las Entidades a través de la tabla Entidad-Categoría.

TIPOS DE RELACION

Esta tabla contendrá los distintos tipos de relaciones que puede haber entre las Entidades.

Por ejemplo podemos crear el tipo de relación Contacto y en la tabla Relaciones de entidades marcaremos que una Entidad es contacto de otra Entidad.

CLASIFICACIONES

Esta tabla arbolada nos servirá para jerarquizar las Entidades.

Por ejemplo si estoy desarrollando una agenda telefónica podría crearme las Clasificaciones de amigos y familiares y así podría diferenciar, mediante la tabla Entidad – clasificaciones, los distintos contactos (Entidades) de mi agenda.

EMPRESAS

En esta tabla arbolada encontraremos tanto las Empresas con las que trabajaremos como las distintas Divisiones / Departamentos que queramos definir dentro de ellas.

Cada Empresa deberá tener un registro en Entidades que es donde estarán todos sus datos: CIF, dirección, emails, etc.

En la tabla Empresas de un usuario estarán las Empresas a las que puede acceder un usuario.

Hoy vamos a hacer una primera  aproximación a lo que será la próxima open app: vBase que será liberada en Junio.

Con este post queremos empezar una serie de posts en los que analizaremos la solución vBase utilizando como guía el Análisis Funcional de vBase que será publicado en breve.

Esta plantilla está siendo desarrollada paralelamente a la open app vConta por las empresas Guida21, HSM y The Seed además de contar con la colaboración de Velneo.

vBase consta de 3 proyectos de datos:

• Usuarios.
• Localizaciones.
• Entidades.

y de 3 proyectos de aplicación:

• Recursos.
• Usuarios.
• vBase.

En este primer post veremos las tablas de las que consta cada proyecto de datos.

USUARIOS

En este proyecto se encuentran las siguientes tablas:

• USR: Usuarios.
• USR_GRP: Grupos de usuarios.
• USR_GRP_USR: Usuarios de un grupo.
• CSS: Estilo CSS

LOCALIZACIONES

En este proyecto se encuentran las siguientes tablas:

Tablas maestras

• IDI: Idiomas.
• MON: Divisas.
• MON_CAM: Cambios de divisas.

Tablas que hacen referencia a la división territorial de cada país:

• PAI: Países.
• REG_1: Región 1.
• REG_2: Región 2.
• LOC_CPS: Localidades.
• TIP_VIA: Tipos de vía.

ENTIDADES

En este proyecto se encuentran las siguientes tablas:

Tablas maestras:

• REL_TIP: Tipos de relación.
• CLF: Clasificaciones.
• CAT: Categorías.
• CTT_TIP: Tipos de contacto.

Tablas de empresas:

• EMP: Empresas.
• EMP_USR: Empresas de un usuario.
• EMP_ENT: Empresa – Entidades.

En el próximo post analizaremos la función de cada tabla y como se relacionan entre sí.

En la versión 7.3 de la plataforma Velneo V7 nos hemos encontrados con 4 nuevos comandos de interfaz para utilizar en los eventos situados dentro de un formulario.

Estos comandos de interfaz que hacen referencia a la multi-selección son:

• Interfaz: Obtener multi-selección.
• Interfaz: Limpiar multi-selección.
• Interfaz: Añade ficha a multi-selección.
• Interfaz: Quita ficha de multi-selección.

Interfaz: Obtener multi-selección

Este comando permite obtener la lista de los registros seleccionados en una rejilla incrustada dentro del formulario.

Este comando hace la misma función que Interfaz: Procesar control sobre los seleccionados.

Interfaz: Limpiar multi-selección

Este comando permite quitar la lista de los registros seleccionados en una rejilla incrustada dentro del formulario.

En las versiones anteriores de la plataforma (6x) disponíamos de una funcionalidad similar. Si desde un botón situado en un fomulario la función a disparar era Ejecutar proceso rejilla: seleccionados o Ejecutar proceso rejilla: no seleccionados teníamos  un check que se llamaba Quitar los seleccionados tras proceso.

Interfaz: Añade ficha a multi-selección.

Este comando permite añadir una ficha a la lista de registros seleccionados en una rejilla incrustada dentro del formulario.

Esta ficha a añadir ha de estar inicializada en el evento mediante Crear nueva ficha en memoria o Crear copia de ficha en memoria ya que para seleccionar la ficha a añadir deberemos hacerlo a través de su Manejador de ficha.

Interfaz: Quita ficha de multi-selección

Este comando permite quitar una ficha a la lista de registros seleccionados en una rejilla incrustada dentro del formulario.

Esta ficha a quitar ha de estar inicializada en el evento mediante Crear nueva ficha en memoria o Crear copia de ficha en memoria ya que para seleccionar la ficha a quitar deberemos hacerlo a través de su Manejador de ficha.

Ejemplo

Usando como ejemplo la rejilla de la primera imagen vamos a montar un evento con estos comandos

Hoy vamos ver cómo montar un Panel de búsqueda alimentando la búsqueda con variables locales y guardando el resultado en una cesta.

Vamos a utilizar como ejemplo una búsqueda de Artículos, filtrando por Referencia, Nombre, Estado, Marca del artículo y período de alta en la base de datos.

Los objetos que vamos a utilizar serán:

1. Una tabla PARAM_BUSQUEDA
2. Una cesta privada de la tabla Artículos ARTICULOS_PRIVADO
3. Una búsqueda de Artículos ARTICULOS
4. Una rejilla de Artículos ARTICULOS
5. Formulario de la tabla PARAM_BUSQUEDA que es el que utilizaremos para realizar el mantenimiento de Artículos ARTICULOS_MANTEN
6. Una acción VER_ARTICULOS y dos procesos:
   1. VER ARTICULOS que nos mostrará el resultado de la búsqueda de artículos
   2. ARTICULOS que servirá para lanzar el formulario ARTICULOS_MANTEN

Lo primero será crear la tabla PARAM_BUSQUEDA. En esta tabla iremos creando todos los campos por los que queramos buscar en las distintas búsquedas del programa.

En esta caso metemos un campo enlazado a una tabla estática  EST_ARTICULOS donde están los distintos estados que pueden tener los artículos. Un campo al maestro de MARCAS y los campos referentes a la alta de los artículos.

La cesta ARTICULOS_PRIVADO será utilizada para meter ahí los registros resultantes de la búsqueda que hagamos. Desde el fomulario de mantenimiento lo que haremos será procesar la cesta para ver los registros. Esa cesta ha de ser privada.

Crearemos la búsqueda ARTICULOS. En esta búsqueda crearemos las variables locales que usaremos en la búsqueda

En las resoluciones de los distintos índices pondremos las distintas variables locales que hemos declarado.

Lo siguiente será crear un proceso VER_ARTICULOS que es el que utilizaremos para ver los artículos desde el formulario de mantenimiento.

Este proceso tendrá como origen la  ficha de PARAM_BUSQUEDA y como destinto la lista de la tabla ARTICULOS.

Lo siguiente será crear el formulario de mantenimiento ARTICULOS_MANTEN que es donde se ejecutará la búsqueda y se mostrarán los resultados.

El formulario lo hacemos de la tabla PARAM_BUSQUEDA para poder seleccionar los campos enlazados a otra tablas. Si el formulario fuera sin origen sólo podríamos usar variables y deberíamos controlar por proceso el acceso a datos de otra tablas.

Como se ve en la imagen el control objeto que mostrará los artículos tiene como primer objeto el proceso VER_ARTICULOS y como segundo objeto la rejilla ARTICULOS.

Eventos necesarios en este formulario:

• INICIALIZAR que se disparará al inicializar el formulario. Este evento nos limpiará la cesta. Con esto conseguiremos que al llamar al formulario la lista de registros se muestre vacía, no se mostrarán registros hasta que el usuario decida buscar. Esto está pensado así para optimizar la presentación del formulario en internet. También damos un valor incial a los campos por los que se han de buscar.

• BUSCAR que dispararemos desde el botón que realizará la búsqueda. En este evento lo primero que haremos será guardar en variables locales los valores de los campos por los que vamos a buscar. Limpiaremos la cesta. Crearemos un manejador de objetos para la búsqueda ARTICULOS a la que le pasaremos los valores a sus variables locales y ejecutaremos en 3º plano optimizando el tiempo de respuesta en la devolución de los registros.

Ya sólo nos quedará disparar este formulario.

Al tener el formulario ARTICULOS_MANTEN como origen una tabla no podemos dispararlo directamente desde un acción mediante Disparar objeto. Ya que sólo podemos disparar así a formularios sin tabla de origen.

Lo que hemos hecho es crearnos un proceso ARTICULOS que no tendrá ninguna línea de código. Sin tabla de origen y con destino la ficha de la tabla PARAM_BUSQUEDA.

La acción que disparará este formulario tendrá como Objeto1 el proceso ARTICULOS y como Objeto2 el formulario ARTICULOS_MANTEN.

Notas:

• En el evento INICIALIZAR hemos tenido que dar valores inciales a los campos que usaremos para buscar ya que no hemos conseguido que respete los valores inciales que tienen los campos en las tablas.
• Si se borra a mano el valor de los campos fecha éstos no se quedan realmente en blanco (Incidencia de QT que está resolviendo Velneo). Esto puede provocar que no salgan registros al buscar.

Esto es sólo una forma de hacerlo. Esperamos que os sirva para experimentar y mejorarlo.