vDeveloper: vayamos por partes (v)

El tercer elemento de una tabla son los triggers o eventos de tablas.

Con ellos vamos a poder lanzar procesos que se ejecutarán siempre con origen una ficha de una tabla. Van a sernos muy útiles a la hora de hacer comprobaciones, de modificar valores de campos dependiendo de las condiciones que establezcamos…. además se dá la ventaja de que tenemos la seguridad de que siempre se ejecutan pues no dependen de una pérdida de foco o de que el usuario haya pulsado un determinado botón.

Los eventos de tablas o triggers son de tres tipos: anteriores a , internos a y posteriores a.  A su vez se pueden lanzar desde tres sitios distintos: en un alta, en una modificación y en una baja. Por lo tanto, mezclando ambas cosas tendremos nueve maneras o formas de lanzarlos

 ¿En qué orden son lanzados los triggers?

1. Trigger anterior

2.La acción asociada: alta, modificación o baja

3. Trigger interno

4. Actualizaciones, que veremos a continuación

5. Trigger posterior.

A la hora de usar los triggers debemos de tener en cuenta varias particularidades: en la versión C/S no incluir  nada que implique la intervención del usuario, por ejemplo, visualizar un mensaje, mostrar un formulario, una pregunta, petición de un dato, etc. El motivo es que este tipo de operaciones se llevan a cabo en el Servidor, por lo que el mensaje o el formulario no serían presentados en el Cliente, sino en el propio Servidor. Si en un evento de tabla se incluyese algo que implicase la intervención del usuario, será obviado por el Servidor. Sólo en los triggers anteriores a se pueden cambiar valores de campos de las fichas , si ponemos una instrucción de proceso “modificar campo” ésta sólo se ejecutará si el trigger es anterior a.

Exitos con Velneo. CURSAR

Con permiso del departamento de I+D de textiles Saroni, os traigo un artículo publicado recientemente en el blog de Velneo de un caso de desarrollo. Tengo el placer de conocer personalmente a Juan y a  Héctor. Son dos grandísimos programadores que en poco más de un año han resuelto el problema informático de su empresa gracias a su trabajo y a Velneo. Como podeis comprobar además, su presentación está muy bien cuidada y el interface con el usuario es de un diseño elegante y bonito.

Enhorabuena a ambos.

Poco más de un año más tarde…..

Lo prometido es deuda, lo que sucede es que todo tiene que llegar a su tiempo:

Hace un poco más de un año, el Grupo Textiles Saroni empezó la búsqueda de un sistema de gestión integrado para resolver todas sus necesidades. Necesidades logísticas, de gestión, diseño, control de almacenes, producción; un sistema que permita la expansión de la empresa y al mismo tiempo un control de la misma.

Se realizó un sondeo en diferentes empresas. Se contactó con diferentes empresas de informática, sistemas basados en Oracle, SqlServer, y un largo etc.

El principal problema que nos encontramos en todas las versiones probadas era la no adaptación a nuestra forma de trabajo, no cumplir las necesidades mínimas, aplicaciones poco intuitivas y muy poco adaptables al modelo de empresa.

Al final nos decantamos por realizar el programa a medida. De nuevo otro sondeo para determinar el sistema de desarrollo para la aplicación, siempre hablando de un RAD, y viendo que nuestros recursos informáticos eran mínimos.

Al final se tomó como punto de partida Velneo, pensado en que con la futura versión V7, y con las características de la V6 podríamos desarrollar un programa adaptado a nuestras necesidades. Nos pusimos en contacto con Velneo

Fases en el desarrollo de Cursar:

Equipo de desarrollo compuesto por dos personas, tiempo empleado 15 meses.

Fase 1:

Formación del personal.

1 semana de formación de nuestro departamento de I+D. Dos personas fueron formadas en las características de Velneo. Modo de trabajo, tablas, punteros, formularios, consultas, informes, en definitiva todo lo necesario para la realización de la aplicación.

Fase 2:

Pruebas de campo.

Dedicamos dos meses para hacer pruebas y desarrollo de mini aplicaciones enfocadas a nuestras necesidades, además para hacernos con la forma de trabajo de Velneo y sus particularidades, el “cambio de chip”.

Fase 3:

Análisis de necesidades.

Nuestra empresa por la particularidad de la misma, trabaja para clientes diversos: Inditex, Etiem, Caramelo, Induyco, Women Secret, etc.. El estudio de necesidades es un poco abstracto, nunca tienes el estudio terminado, los cambios son constantes, nuevas normativas, nuevas adaptaciones, con lo que en otro sistema hubiese sido una odisea.

Velneo permite que las modificaciones no sean tan problemáticas; además la urgencia de un sistema de gestión interno nos hizo tener que trabajar con datos reales y con las mínimas pruebas, “necesito esto para ayer”, y todo esto en una empresa en constante evolución.

Otro problema añadido fue la descentralización de nuestra empresa, sedes en Coruña, Portugal y la sede central en Verín.

Fase 4:

Desarrollo.

Comenzamos el desarrollo, analizando la urgencia de cada caso.

Decidimos basar el desarrollo en la plantilla vGestión con sus pros y sus contras, pero la urgencia implicaba utilizar desarrollo ya realizado, aunque al final poco o muy poco queda de la base inicial, pero si nos ha servido para el conocimiento de la herramienta. Es una buena base para el desarrollo de una aplicación. Sin entrar en valoraciones, es un muy buen punto de partida.

Packing list, uno de nuestros dolores de cabeza. La diversidad de empresas con las que trabajamos hace que el packing list sea toda una odisea, tanto a nivel de informes como en forma de trabajo, tiendas, diferentes codificaciones, tallas, colores.

Nuestros primeros packing se hacían bien desde la web, o desde programas como Excel, donde en cualquiera de los dos casos los tiempos eran de horas.

Recuerdo como anécdota que el primer packing de Women Secret nos llevo 16 horas, entre etiquetas y embalado, eran 25.000 prendas, ahora con cantidades de 48.000 el packing puede rondar las 4 o 6 horas.

Control de pedidos. En este sector es muy importante el control de las fechas de servicio, así como las cantidades servidas, etiquetado, control de cada cliente y pedido. Esto era una odisea. Todo un reto preparar un informe de prendas pendientes de servir, o prendas servidas. Ahora con Velneo, y nuestro programa Cursar, todo esto está en tiempo real, con estado de etiquetas, alarmas, y un largo etc..

En cada una de las fases nos encontramos con problemas, desde el desarrollo del modulo de distribución hasta la agenda de tareas, todos y cada uno de ellos solucionados de una u otra manera.

De ahí el eslogan de nuestro departamento de I+D:

“Si el problema tiene solución, cual es el problema.”

Fase 5:

VServer y primeras pruebas.

Dada la necesidad de un programa, las pruebas fueron mínimas, siempre trabajando con datos reales, y hasta la fecha con escasos problemas. Gracias a la estructura de tablas y al buen manejo de índices, el departamento de I+D se preocupa de programar y analizar.

Toda esta fase de implementación no supuso grandes quebraderos de cabeza. El único quebradero de cabeza fué la poca capacidad de subida de nuestras ADSL, lo que nos hizo tener que desarrollar Cursar con el mínimo consumo de recursos. Nuestra aplicación compilada en .vam no llega a un megabyte, mientras que hablamos de 2,5 megas el mapa.

Todo esto junto con las pruebas realizadas con Citrix Metaframe, hace que nuestro programa corra sin problemas desde Coruña y Portugal con una ADSL de 384Kb de subida.

La ventaja de Citrix es la integración con el escritorio dado que en Terminal Server, la mensajería de Velneo suponía un problema, así como las impresoras remotas.

En poco más de un año nuestra aplicación se compone de los módulos de:

Compras.

Ventas.

Control de Pedidos.

Ventas a clientes, pedidos pendientes, estado de pedidos, control de etiquetas, etc..

Gestión documental.

Un apartado muy importante dentro de la empresa. Inicialmente toda la información de modelos, fotos, escalados, pedidos en pdf, toda la documentación generada en las campañas se almacenaba en carpetas. Las búsqueda eran eternas, y siempre sin saber en qué carpeta guardó el usuario toda esa información. Esto en Cursar y con Velneo y su servidor de disco está solucionado y, lo mejor de todo, sin ocupar espacio en la base de datos, miles de fotos y pdf’s, documentos accesibles con un solo clic.

Modelos – Premodelos.

Toda la gestión de modelos y premodelos, fechas de aprobación, calidades, temporadas, carta de colores, tallas, existencias.

Medidas modelos.

Control de escalados, medidas, rectificaciones, corte, patrón, gestión documental.

Presentaciones de modelos a clientes, versiones, reservas…

Packing List.

Aprobaciones de color.

Multialmacén.

Agenda tareas – departamento – secciones

Empleados, salarios, vacaciones.

Control de acceso a tablas, por tabla y usuario

Control de diseño.

Modulo de distribución, con control por proceso, tinte, corte, etc..

Módulo de control de versiones, un premodelo puede tener múltiples versiones con escandallo por cada una de las versiones.

Y un largo etc..

Resumiendo, nuestro departamento de I+D con esta herramienta ha desarrollado un programa con el cual hemos reducido horas de trabajo al usuario, teniendo a su vez cantidad de información y documentación en la que basar futuros diseños, cálculos de costes, y un largo etc. La información es poder, pero una buena información, filtrada y preparada para que todos la puedan entender.

Los requerimientos iniciales de Grupo Textiles Saroni no eran llegar a un programa que controlara todo, pero los usuarios, visto las posibilidades del sistema, cada día piden cosas nuevas a Cursar. Se puede hacer, pues …. después de un pequeño estudio, si se puede, “pero ya tenemos datos”.

El secreto de la nueva era del software es que este se adapte a la empresa, que sea sencillo y, muy importante, que sea intuitivo y amigable dado que el usuario pasa horas delante del programa. Todo esto nos lo permite Velneo. Nuestro programa nació pensando en la V7, pero no hemos tenido problema para desarrollarlo en V6. Ahora esperamos impacientes la V7, multidioma, multiplataforma, y un largo etc…

“Si el problema tiene solución, cual es el problema.”

Equipo de I+D de Grupo Textiles Saroni.

Juan José Pérez Pérez

Héctor Valladares Mangas.

 

 

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

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.

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.

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.

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.