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.

Veamos con un ejemplo real la diferencia de actuación de los tubos de lista y de ficha.

Supongamos una aplicación en la que hacemos albaranes y facturas con una estructura de tablas como la siguiente.

He puesto las tablas de cabeceras de albaranes y de facturas como submaestra de años para aprovechar su código como contador y así que comience a contar en 1 en cada año ( ver articulo )

Así mismo las lineas son a su vez submaestras de las cabeceras correspondientes.

Los campos que tenemos en las tablas cabeceras son practicamente los mismo en una y en otra tabla , al igual que ocurre con los campos de las tablas lineas.

Hagamos ahora los objetos visuales que nos permitirán facturar un albarán.

El proceso general para hacerlo sérá: tenemos una ficha de Cabecera de Albarán de la que

 cuelgan sus históricos Lineas de Albarán. Tomaremos los datos de la CAlbarán y los pasaremos a un ficha de CFacturas. Una vez hecho esto, he de recorrer las lineas de LAlbaranes para hacer lo mismo, es decir, llevarlas a LFacturas pero indicándoles a dichas lineas a qué CFactura pertenecen. Para ello usaremos dos métodos. El primero mediante dos tubos de ficha y el segundo con un tubo de ficha y otro de lista.

Método 1: dos tubos de ficha

Crearemos primero el tubo de ficha para pasar datos desde una Cabecera de Albarán a una Cabecera de factura

Vemos que los capilares que usamos son pocos, no  utilizamos todos los campos, sólamente los que son necesarios para definir la factura al final del tubo, el cliente, el año y el almacén, en caso de ser multialmacén. El resto de los campos de CFactura, se “rellenarán” o bien por contenidos iniciales de los mismos o bien mediante actualizaciones desde las lineas 

Después creamos el tubo de ficha para las lineas en el que usaré dos capilares, el puntero al Artículo y la cantidad de unidades vendidas.

El proceso para facturar un único albarán será el siguiente.

 Proceso en el que ser realiza la facturación de un albarán.

Con lo que obtenemos la factura con sus lineas correspondientes. 

 Método dos: un tubo de ficha para las cabeceras y un tubo de lista para las lineas

Creamos el tubo de lista desde LAlbaranes a LFacturas, con los mismos capilares que los usados en el tubo de ficha. Los cambios irán en el proceso de facturación que se lanza desde la ficha de CAlbarán

Observar que en el post del primer tubo, ya no uso los Set para guardar valores en varialbles locales sino la instrucción de proceso

Guardar ficha, lo que nos permitirá usar un Tubo de lista con inducción. Esta inducción nos permite indicar a todas y cada una de las lineas de factura que se van creando a la salida del tubo de lista a qué ficha de maestro( CFactura) pertenecen.

La inducción hace que cada línea de la factura apunte a la misma cabecera, es decir, introduce el código del registro de la cabecera de la factura en el campo enlazado de los registros de Líneas de Factura.

Cualquiera de los dos métodos es válido. El primero, con tubo de ficha en las lineas, nos permite modificar los registros de salida del tubo, en cambio el tubo de lista no lo permite.

En el caso de tener que facturar varios albaranes en una única factura, podríamos hacer un proceso con origen lista de CAlbaranes para poder lanzarlo como una opción desde una toolbar en una  búsqueda de albaranes presentada en una rejilla multiselección, para ejecutarlo contra los seleccionados. Dividiremos así mismo el proceso en dos. En el primero, ordenamos la lista por Cliente para luego multipartirlo por ese mismo campo. Con ello logramos una “minilista” con cada todos los albaranes de un cliente, y por cada una de esas minilistas, ejecutamos el proceso que los factura.

 Proceso llamador 

Proceso llamado en el que se realiza la facturación de la minilista de los albaranes de un único cliente. Este proceso se repetirá por cada una de las multiparticiones que se obtengan en el proceso llamador.

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.

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.

Estimados amigos que entrais en este blog, permitidme al menos por esta vez, una reflexión muy personal .

 Desde que el 21 de septiembre de 2005 me dí de alta en el foro de Velneo, no he hecho más que disfrutar con él y con la gente que allí nos reunimos. No tengo más que palabras de agradecimiento hacia él. En dicho Foro he hecho grandes amigos, me ha permitido conocer a gentes de todos los lugares del Mundo y ponerme en contacto personal con ellos.

Disfruto cada día entrando en él y aportando o preguntando. De veras que es una gran comunidad, llena de entusiastas de Velneo y de detractores del mismo. Su grandeza reside en que nadie es apartado, nadie es criticado, nadie es maltratado.

A todo el mundo que se acerca con una duda o un problema, se le intenta ayudar, de forma desinteresada y altruísta. Eso si que es Globalización, eso si que es compartir conocimientos, eso si que es trasmitir.

Enhorabuena a todos los foreros o casi decir forofos de este FORO, con mayúsculas y a Velneo por haber tenido una idea tan buena con su creación y mantenimiento.

Gracias Foreros

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.

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 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.

Como componente final de las tablas tenemos las actualizaciones. Una actualización no permite modificar registros de otras tablas con las que estemos unidos mediante un puntero a singular,es decir, puedo modificar registros de tablas a las que apunte mediante un puntero a maestro, un puntero indirecto o un hermano contiguo.

Su mayor potencia reside en su autorecálculo. Me explico. Supongamos que mediante una actualización, voy llevando a un campo de la tabla Cabeceras de facturas el número de artículos que voy vendiendo. Cada vez que introduzco una linea y pongo las unidades vendidas, al dar de alta la linea se lanza la actualización y me aumenta el contador. Pues bien, si de nuevo entro en la linea y cambio el valor de las unidades, la actualización se rehace, deshace la actualización con el anteriro valor y la rehace con el nuevo. Pero si por alguna causa, borramos una linea, también se recalcula la actualización Y SIN TENER QUE ESCRIBIR NI UNA SOLA LINEA DE CODIGO.

Con  un ejemplo práctico veremos la potencia que encierran las actualizaciones. Supongamos una aplicación para hacer albaranes de venta. Vendemos artículos que tienen un stockaje de almacén y que pueden ir grabados con distintos tipos de IVA. Además queremos llevar en una tabla el IVA repercutido por meses de los distintos tipos de IVA por separado. 

TABLA TIPO TABLA DE DATOS PADRE
CLIENTES Maestro normal con clave numérica -
ARTICULOS Maestro normal con clave numérica -
ALBARANES VENTAS Maestro normal con clave numérica -
LÍNEAS ALBARANES VENTAS Sub Maestro ALBARANES VENTAS
FACTURAS Maestro normal con clave numérica -
LINEAS FACTURAS Sub Maestro FACTURAS

AÑOS. mestra normal con clave numérica

IVA ACUMUALDO. Histórica de Años
A las tablas se han añadido los siguientes campos:

Tabla de ARTICULOS:
IDENTIFICADOR PVP NOMBRE P.V.P. TIPO Numérico LONGITUD 3
IDENTIFICADOR IVA NOMBRE I.VA. TIPO Numérico LONGITUD 1 RANGO MÁXIMO 99 CONT. INI $IVA1$
IDENTIFICADOR PVP-SIN-IVA NOMBRE PVP sin IVA TIPO Fórmula Numérica
FÓRMULA fRedondear( 100 * %PVP% / (100+%IVA%),2 )
IDENTIFICADOR STOCK  NOMBRE Stock TIPO Numérico LONGITUD 2 SIGNO Activado

Tabla de ALBARANES VENTAS:
IDENTIFICADOR FECHA NOMBRE Fecha TIPO Fecha CONTENIDO INICIAL fHoy ()
IDENTIFICADOR NLINEAS NOMBRE Número de líneas TIPO NuméricoLONGITUD 2
Declaramos tres bases imponibles (una por cada tipo de IVA):

IDENTIFICADOR BASE1 NOMBRE Base Imponible 1ª TIPO Numérico LONGITUD 4 SIGNO Activado
IDENTIFICADOR IVA1 NOMBRE I.VA. 1º TIPO Numérico LONGITUD 1 RANGO MÁXIMO 99 CONT INI $IVA1$
Declaramos también otros dos IVA’s más.
IDENTIFICADOR IMP-IVA1 NOMBRE Importe I.V.A. 1º TIPO Fórmula NuméricaSIGNO Activado
FÓRMULA fRedondear(fPorcentaje(%BASE1%,%IVA1% ) )
fPorcentaje (Valor, porcentaje), devuelve el número resultante de aplicar el porcentaje al valor.

Declaramos otros dos campos para calcular el Importe de IVA 2º y del IVA 3º, respectivamente de igual forma que el anterior

IDENTIFICADOR TOTAL NOMBRE TotalTIPO Fórmula NuméricaSIGNO Activado
FÓRMULA %BASE1%+%BASE2%+%BASE3%+ %IMP-IVA1%+%IMP-IVA2%+%IMP-IVA3%
IDENTIFICADOR FACTURADO NOMBRE ¿Facturado?TIPO Booleano (Sí / No) CONTENIDO INICIAL 0
Tabla de LINEAS ALBARANES VENTAS:
IDENTIFICADOR CANTIDAD NOMBRE Cantidad TIPO Numérico LONGITUD 2
IDENTIFICADOR PVP NOMBRE P.V.P. TIPO Numérico LONGITUD 3 CONTENIDO INICIAL %ARTICULOS.PVP%
IDENTIFICADOR IVA NOMBRE % I.V.A. TIPO Numérico LONGITUD 1 CONTENIDO INICIAL %ARTICULOS.IVA%
IDENTIFICADOR IMPORTE-SIN-IVA NOMBRE Importe sin Iva TIPO Fórmula numérica SIGNO Activado
FÓRMULA %CANTIDAD% * %PVP%
IDENTIFICADOR IMPORTE-DEL-IVA NOMBRE Importe del Iva TIPO Fórmula numérica SIGNO Activado
FÓRMULA fRedondear(fPorcentaje(%IMPORTE-SIN-IVA%, %IVA%))
IDENTIFICADOR IMPORTE+IVA NOMBRE Importe con Iva TIPO Fórmula numérica SIGNO Activado
FÓRMULA %IMPORTE-SIN-IVA%+%IMPORTE-DEL-IVA%
La tabla FACTURAS tiene la misma estructura que la de ALBARANES VENTAS, a excepción de los campos NLINEAS y FACTURADO, que no los tiene.

TABLA AÑOS: nos quedamos con el campo código y borramos el campo nombre y los índices NOMBRE, PALABRAS Y TROZOS. Esta tabla, en la que sólo vamos a llevar los años, podemos cargarla de datos con un proceso llamado desde el AUTOEXEC-ON-INIT que tendrá la siguiente estructura

TABLA IVAREPERCUTIDO. Tendrá los campos

TRIMESTRE 1 IVA1: numérico , longitud 4 con 2 decimales y signo

TRIMESTRE 2 IVA1: numérico , longitud 4 con 2 decimales y signo

TRIMESTRE 3 IVA1: numérico , longitud 4 con 2 decimales y signo

TRIMESTRE 4 IVA1: numérico , longitud 4 con 2 decimales y signo

En estos campos llevaremos los IVAS repercutidos por trimestre, para las bases imponibles que correspondan al IVA del tipo 1.  Para los otros tipos de IVAS no tenemos más que hacer otros tantos campos del mismo tipo que el anterior, cuatro por cada tipo

La estructura de tablas queda como sigue

Para tener guardados los valores de los IVAS usaremos tres varialbles globales en disco, de tipo numérico y con longitud 3 y dos decimales.

Para guardar los datos generales de la empresa tenemos dos opciones, o bien usar también variables globales en disco en las que iremos guardando los datos de la empresa, como razón social, NIF, domicilio, código postal, población …. así como un objeto visual tipo dibujo para el logo de la empresa usado en los albaranes o las facturas u otra opción que suelo usar y que es crear una tabla llamada CONFIGURACION en la que se crean los diferentes campos que necesite para definir los datos generales de la empresa, incluidos uno o varios campos objeto dibujo en los que guardar distintos logos.

Con ella, nos evitamos tener que tocar con le vDeveloper un objeto dibujo si la empresa cambia de logo, por ejemplo. Para usarla desde las tablas de las cabeceras de Albaranes o Facturas, simplemente, hacemos un puntero a maestro en cada una de ellas a la tabla configuración, con lo que tenemos acceso a todos los campos sobre todo a la hora de imprimir los informes.

Para rellenar inicalmente los valores de la única ficha de esta tabla, podemos lanzár un proceso llamado desde el AUTOEXEC-ON -INIT que tenga las siguientes lineas

En este mismo proceso podríamos controlar si se ha dado valor a al menos una de las variables globales donde se guardan los IVAS y mostrar el formulario de Configuración en el que tendremos los controles de edición de las variables.

Al mismo nivel que Cargar lista->CONF…..                     

añadimos

if $IVA-1$=0

cargar lista , CONFIGURACION, CODIO

seleccionar ficha por posición->1

modificar ficha seleccionada con formulario, CONFIGURACION

Vayamos con las primeras actualizaciones. Desde la tabla de Lineas de facturas haremos actualizaciones a los campos donde guardamos las distintas bases imponibles, dependiendo del valor del IVA que se aplique al artículo de la linea. Para ello vamos a la carpeta de actualizaciones e insertamos una nueva. Toda actualización necesita un puntero a una ficha para poder actualizar un valor de la tabla apuntada con un valor de un campo de la tabla origen. En este caso, tenemos el puntero a maestro desde la tabla Lineas de Facturas a la tabla Cabeceras. Usaremos este puntero para actualizar las tres bases imponibles, dependiendo del tipo de IVA que se haya usado para la linea.

Para ello usaremo la fórmula condición para modificar. En el caso editado de la base 1, si el iva de la lineas es igual al guardado en la variable IVA 1 lanzaremos la actualización, modificando el campo BASE1, del modo acumular ( sumar a lo que ya había ) lo que está guardado en el campo IMPORTE SIN IVA.

Para el resto de los campos BASE, lo único que variará será la condición de modificación además del campo a modificar.

Si borramos, o modificamos una linea afectando el valor del campo IMPORTE SIN IVA la actualización, ella sóla y sin programar nada más, se encargará de corregir los datos anteriores y salvaguardar los nuevos

Hagamos ahora una actualización a través de un puntero a tabla de datos indirecta real. 

En la tabla Cabeceras de Facturas creamos un puntero indirecto a la tabla IVAS Repercutidos a través del índice de clave única AÑOS  de esta última tabla, resolviendo el AÑO del origen que el AÑO del destino, y activando el flag Dar de alta si no existe por si es la primera factura de un año determinado que introducimos y por tanto en la tabla IVAS Repercutidos aún no hay creado un registro para ese año.

Sólo nos queda lanzar una nueva actualización a través de este puntero para que nos lleve los ivas repercutidos en los trimestres adecuados de cada año.

 Para ello creamos una nueva actualización a través del puntero indirecto.La haremos para el primer trimeste del IVA 1.

La condición será que el trimestre de la fecha sea el 1 y actualizaremos el campo TRIMESTRE 1 IVA 1 con lo que haya guardado en el campo IMP-IVA 1  de la tabla Cabeceras de facturas.

Lo mismo haremos ,cambiano la condición para los diferentes trimestes e IVAS.

Podríamos también hacerlo para los doce meses de cada año. Sólo tenemos que hacer 12 campos por IVA y montar las actualizaciones de la misma forma.

Si tenemos también implementada a parte de compras en nuestra aplicación, podríamos llevar el IVA soportado en la misma tabla y llevar desde la Cabecera de Facturas de Compra todos los IVAs soportados por trimestre o por meses de cada año, y a la vez un campo fórmula en el que nos calculara la diferencia entre el soportado y el repercutido.

Como hemos visto, con las actualizaciones y los punteros y sin escribir ni una sola linea de código, hemos hecho toda la labor, todo en la parte izquiera del vDeveloper. Combinando toda la potencia de los componentes de las tablas con un buen análisis del problema, tenemos el 90% de la aplicación hecha, a falta de hacer los objetos visuales y de resolver cosas que Velneo no tiene implementadas de forma tan directa pero que haremos con los procesos.

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.

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.

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.

A partir de una pregunta aparecida en el foro Oficial de Velneo intentaré explicar cómo hacer búsquedas sencillas con el vDeveloper.

Según expliqué aquí , los índices de una tabla nos permiten tener los datos indexados por varios criterios para luego poder acceder a esos registros mediante las búsquedas.

Supongamos un ejemplo muy sencillo. Tenemos una tabla de Facturas en la que hemos creado dos índices, el índice Código, el propio de Velneo con su característica de clave única y alimentado por el campo Código siguiente al último  y un índice Fecha aceptar repetidas y alimentado por el campo fecha de la Factura.

Vamos a hacer un objeo visual búsqueda en el que mediante un formulario de petición de datos, busquemos una factura concreta por su código. La metodología a seguir, sea cual sea el índice a utilizar es más o menos siempre la misma:

1. Creamos una variable global en la que introducir el dato concreto a buscar. En nuestro caso es el código, de tipo numérico, luego nuestra variable será de tipo numérico, con la misma longitud de rando o superior al campo código y con persistencia en memoria independiente de cada tarea en segundo plano. La llamaremos  FACTURA  ($FACTURA$)

2. Creamos un Formulario para Búsquedas en la tabla Facturas, y en él pondremos un texto estático “Factura a buscar” y un control de edición al que le asignaremos la variable $FACTURA$

3. Creamos una búsqueda de la tabla Facturas, índice Código, forma de búsqueda parte izquierda de la clave, contenido inicial del campo la variable $FACTURAS$

4 Formulario inicial de la búsqueda: el que acabamos de crear.

Nos quedaría crear una opción de menú con la que lanzar la búsqueda. En ejecución se nos presentará el formulario para pedirnos el código de la factura a buscar y nos devolverá una rejilla con la factura encontrada.

Añadámosle una funcionalidad más a la búsqueda. Supongamos que me interesa usar el mismo formulario para buscar también las facturas entre dos fechas determinadas. Para que nos valga para ambas búsquedas a la vez, usaremos una característica de los índices en las búsquedas que es la condición activa.

Sigamos los mismos pasos.

1.Creamos dos variables globales tipo fecha $Fecha ini$ y $Fecha fin$

2. En el formulario especial para búsquedas ponemos dos controles de edición para poder dar valores a ambas variables fecha.

3. A la búsqueda le añadimos un nuevo índice con mezcla cruzar, fecha, forma de búsqueda entre límites, límite inicial $Fecha ini$ y límite final $Fecha fin$. La mezcla cruzar nos permite concatenar varios índices en una sola búsqueda. Si los indices están cruzados, la lista mostrada será la que compartan ambos criterios de búsqueda. Es como un Y booleao, los que cumplen un criterio Y los que cumplen el otro.

Usemos en el índice Fechas la condición de activo. Dicha condición al evaluarse su fórmula, hace que la búsqueda por ese índice se realice o no. Es decir si le ponemos una condición y se cumple, realizará la búsqueda con la mezcla que le hayamos indicado y de la forma que hayamos establecido. Lo más lógico en nuestro caso es que se realice entre fechas si se les dan valores a las dos variables globales    ( fCampoVacio( $FECHA-INI$)=0 ) & ( fCampoVacio( $FECHA-FIN$ )=0 ).

Lo mismo podríamos hacer para condicionar la búsqueda por el código  $FACTURA$ ! 0

Debemos por tanto forzar un contenido inicial a las variables cuando abramos el formulario de búsqueda, poner a cero $FACTURA$  y como vacías las dos fechas. Para ello , creamos un proceso con origen ficha de la tabla Factura. Sus tres lineas serán.

Tened en cuenta, que cuando se crea un proceso por primera vez, para que los camios se guarden, hay que salir por el icono de la puerta  , no cerrando con la X la ventana del proceso .

Por último nos posicionamos en el formulario especial para búsqueda y con la combinación Alt+Intro accedemos a su cuadro de propiedades y escogeremos este proceso como Proceso a ejecutar al crearse el formulario.

Ya tenemos hecha la búsqueda. Si queremos ir añadiendo índices a la misma, sólo tenemos que realizar los pasos y condicionar o no su uso, así como inicializando las variables en el proceso de apertura del formulario.