Consultorio Velneo: ¡Actualizaciones al poder!

Muy interesante la pregunta que me hace David Cueva desde Juarez (México) y que creo que se puede resolver mediante la creación de 3 campos y 1 actualización ¿no te lo crees?.. Sigue leyendo.

Actualizaciones al poder

La pregunta en cuestión es la siguiente:

Tengo un formulario de mantenimiento a x unidad…en el tengo datos de la unidad a servir, fecha, y un boleano que me indicara cuando el mantenimiento actual..esta terminado….abajo….una vista de datos donde esta la rejilla de lineas de mantenimiento (editable)…donde tengo el servicio a dar…y entre otras cosas un campo de finalizado…..
lo que no puedo lograr es que al momento que todas las lineas (servcios), esten en finalizado si….en ese instante me habilite el campo Terninado en el formulario…si hay algun servicio sin terminar…debe permanecer deshabilitado…
Mediante control de evento y eventos….lo hace..pero a destiempo…no en tiempo real…..
Antes de continuar, es muy recomendable que, si no lo has hecho ya, leas este artículo acerca de las actualizaciones.

Definiendo el problema

Básicamente David tiene un registro (maestro) en el que hay que cambiar un campo de tipo booleano en función de si todas sus líneas (plural) están en estado terminado o no (te recomiendo leer también este otro post sobre las relaciones entre tablas).

David lo ha conseguido mediante maneadores de evento pero el problema es que no consigue que el valor del campo booleano se actualice en tiempo real.

Siempre digo que todo lo que podamos hacer en el proyecto de datos, es recomendable hacerlo ahí. Velneo se encargará de realizar las operaciones necesarias para actualizar los registros.

Pues vamos a ello…

Creando los campos necesarios

Para aplicar la solución, en el registro del mantenimiento vamos a crear dos campos de tipo numérico:

  • NUM_LIN_TOT: iremos acumulando en este campo el número de líneas que tiene el registro en cuestión.
  • NUM_LIN_TER: iremos acumulando en este campo el número de líneas que estén terminadas.

Además vamos a modificar el contenido inicial del campo booleano (le llamaremos B_TER) que nos indica si el mantenimiento está terminado o no:

  • choose(#NUM_LIN_TOT= #NUM_LIN_TER, 1, 0)

De esta forma conseguiremos que el campo se marque como “Terminado” cuando el nº de líneas terminadas sea igual al nº de líneas totales.

Velneo se encarga del resto: Actualizaciones al poder

Ahora sólo nos falta que los campos para el número de líneas se vayan actualizando de forma automática.
Para ello vamos a crear una actualización en la tabla de líneas de mantenimiento que actualice el maestro de mantenimientos.
Una vez creada, vamos a dar de alta dos componentes:
Nº de líneas totales
Actualización sencilla… cada vez que demos de alta una línea del mantenimiento… se acumula 1 en el campo NUM_LIN_TOT.

Nº de líneas terminadas

Mediante este componente de actualización, iremos añadiendo 1 al nº de líneas terminadas pero solamente cuando la línea esté terminada (la condicionamos a que el campo B_TER esté a 1).

Conclusión

Pues si esperabas algo mas de dificultad… lo dejaremos para otro día. Con estas sencillas instrucciones, David conseguirá lo que se propone.

Cuando el valor del campo NUM_LIN_TER sea igual al del campo NUM_LIN_TOT, querrá decir que todas las líneas estarán terminadas y por tanto el campo booleano B_TER se marcará a 1.

Ya sabes que si tienes alguna duda sobre Velneo, puedes hacérmela llegar a través del formulario de contacto e intentaré responderla.

Déjame un comentario mas abajo y comenzamos el debate.

La entrada Consultorio Velneo: ¡Actualizaciones al poder! aparece primero en AyudaVelneo.

Novedad Velneo 21: Apertura de proyectos en modo solo lectura

A partir de la nueva versión Velneo 21 aparece en vDevelop una nueva opción de apertura de proyectos en modo solo lectura, facilitando así el desarrollo en equipo. Proyectos siempre accesibles.

Características principales:

  • Podrás copiar objetos y subobjetos
  • Podrás cambiar a edición directamente
  • Seguridad ante cambios no deseados

En el seminario online de presentación de las novedades, Alejandro Gonzáles nos enseñó como sacarle el máximo partido a esta novedad:

Podéis conocer la lista de novedades más destacadas de esta versión en la página de novedades.

Este artículo Novedad Velneo 21: Apertura de proyectos en modo solo lectura es original de Velneo.

Novedad Velneo 21: Nuevo sistema de extensiones de vDevelop

Con la llegada de la nueva versión Velneo 21 aparece un nuevo sistema de extensiones para hacer crecer la funcionalidad del editor de proyectos vDevelop. Una gran innovación que además viene acompañada de varias extensiones, para cada uno de los niveles de suscripción. vDevelop infinito.

Características principales:

  • Infinitas funcionalidades
  • Evolución sin dependencias
  • Oportunidad de negocio
  • Extensiones para todos los niveles

En el seminario online de presentación de las novedades, Mario Conde nos mostró toda la potencia de este nuevo sistema:

Podéis conocer la lista de novedades más destacadas de esta versión en la página de novedades.

Este artículo Novedad Velneo 21: Nuevo sistema de extensiones de vDevelop es original de Velneo.

Creación de un menú arbolado paso a paso

Cuando nos acercamos a probar una nueva plataforma de desarrollo, lo primero que queremos es ejecutar algún ejemplo para “ver” como quedaría nuestra aplicación en ese nuevo entorno.

A los desarrolladores que se acercan a Velneo les ocurre lo mismo. Para ello cuentan con el menú arbolado.

menú arbolado

Este planteamiento tiene un problema: quieren “copiar” su aplicación en la nueva plataforma. Idéntica. Mismos menús con las típicas opciones de:

  • Alta de registros
  • Editar registros
  • Eliminar registros
  • Buscar registros
  • Imprimir informes

Os estaréis preguntando el porqué de esta reflexión.

Todo lo anterior viene por este post del foro en el que Carlos dice:

Quiero hacer una app que tiene a la izquierda un dock con opciones arboladas (treeview) al pulsar una rama se contrae o despliega, y al pulsar una hoja ejecuta una acción que abre un formulario. Esta es la base de cualquier sistema pero no me sale. O lo que lei no es -life is soft-. Ejemplo que en access me llevaría 1 hora (ya se que lo domino).

Velneo tiene sus peculiaridades y es verdad que al principio, sobre todo si no has cambiado el “chip”, puede que no descubras todo su potencial… y te des por vencido.

Ya he hablado de ello en “17 errores que te impiden arrancar con Velneo V7“.

En los cursos que he realizado, siempre digo que en Velneo hay que comenzar por el final, es decir por el resultado que queremos obtener:

  • Si quiero lanzar un localizador, primero tendré que tener creada la rejilla a incrustar en dicho localizador y antes el formulario a mostrar al seleccionar un registro. Después crearé el localizador y por último la acción a disparar.
  • Si quiero mostrar un registro desde una búsqueda, primero tendré que crear el formulario de edición de la ficha, después crearé la rejilla (a la que asociaré el formulario creado anteriormente) y por último la búsqueda y la acción.

Pues con las opciones de los menús pasa exactamente lo mismo.

Pasos previos a la creación del menú arbolado

En Velneo lo mas “natural” es tener una única opción de menú para realizar todo el mantenimiento de un módulo… Ya se lo que estaréis pensando “¡sacrílego como es eso posible!”: con el uso de un formulario que “actúa” como menú al que dotamos de toda la funcionalidad que el usuario va a necesitar.

Si no te lo crees te invito a leer antes de continuar “Destripando un formulario menú de vErp” o “Sincronizar vistas de datos en un formulario sin origen“.

¿Ya los has leído?… Pues continuemos.

Con este montaje en el que sólo utilizamos un formulario, logramos simplificar nuestro menú arbolado.

Siguiendo la lógica que te acabo de explicar, el siguiente paso será crear las distintas acciones que vamos a disparar desde nuestro menú.

Montando nuestro menú arbolado

Una vez que hemos montado nuestro formulario que actuará de menú, ha llegado la hora de crear los objetos necesarios para lanzarlo desde el menú arbolado.

Vamos a suponer que queremos montar algo como lo de la siguiente imagen:

Opciones del menú arbolado

Tendremos que crear un árbol de opciones con:

  • Maestros
    • Opciones del menú maestros
  • Oportunidades
    • Tareas
    • Oportunidades
    • Resumen de oportunidades
  • Control de horas
    • Opciones del menú control de horas

Vamos a crear los objetos necesarios para el menú de oportunidades.

Creando las acciones

Necesitamos 3 acciones:

  • TAR_CRM_MEN: lanzará el menú de tareas
  • OPO_CRM_MEN: lanzará el menú de oportunidades
  • RES_OPO_CRM_MEN: lanzará el menú de resumen de oportunidades.

Cada una de las acciones debe quedar como esta de la imagen:

 

Acción oportunidades

Lo importante de la acción son las siguientes propiedades:

  • Comando: en este caso “Disparar objetos”.
  • Objeto 1: objeto a disparar. En este caso el formulario OPO_CRM_MEN que es el que hemos visto en la imagen anterior.

La estructura de las demás acciones será la misma que esta, cambiando las propiedades por los otros módulos a crear.

Por ejemplo la acción de “Tareas” quedaría así:

Acción tareas

Una vez definidas todas las acciones, ha llegado el momento de crear los menús.

Creando los menús

Vamos a crear 4 objetos menú para montar nuestro árbol:

  • MEN_MAE_CRM: para mostrar las opciones de maestros.
  • MEN_OPO_CRM: para mostrar las opciones de oportunidades. En este caso, incluiremos las siguientes acciones:
    • TAR_CRM_MEN
    • OPO_CRM_MEN
    • RES_OPO_CRM_MEN
  • MEN_RES_CRM: para mostrar las opciones de resumen de horas.
  • MEN_GEN: menú que incluirá, en lugar de acciones, los tres menús anteriores.

El menú de oportunidades, quedará como el de la imagen inferior:

Menú oportunidades

Ya tenemos casi construido nuestro “lego”. Nos falta poder visualizar nuestro menú de opciones.

Visualizando el menú arbolado

Como diría un amigo mío, “ya está todo prácticamente a medias”. Tenemos los objetos creados pero todavía no podemos visualizar nuestro menú arbolado.

Para poder hacerlo, vamos a crear un formulario… ¡siiiiiii! vamos a  visualizar nuestro menú arbolado dentro de un formulario.

Menú general vCrm

Si os fijáis en el formulario, la propiedad “Tabla asociada” está vacía… es un formulario sin origen.

Dentro del formulario hemos creado un control de tipo “Menú arbolado” cuyas propiedades son:

Propiedades menú arboladoi

En la propiedad “Estilo“, le indicamos que sólo queremos una rama abierta y que con el simple click, dispara la acción.

En la propiedad “Objeto“, le indicamos el menú que queremos mostrar… en este caso “MEN_GEN”, que es el que incluía los otros tres menús de opciones.

Ya estamos terminando nuestro montaje. Sólo nos falta decidir desde donde vamos a lanzar nuestro formulario “Menú arbolado”.

Modificando el marco “Autoexec”

Para ello, en nuestro marco “Autoexec”, vamos a crear un nuevo subobjeto, en este caso un “Dock”:

Dock menú arbolado

  • En la propiedad “Objeto“, le indicamos el objeto a incluir. En este caso nuestro formulario “MEN_GEN”.
  • En la propiedad “Posición” le indicamos dónde queremos mostrarlo. En este caso a la izquierda.

Y ahora si… por fin podemos ejecutar nuestra aplicación y nos aparecerá un maravilloso menú arbolado a la izquierda de la misma.

¿Has comenzado a cambiar ya el “chip” Déjame tu opinión mas abajo en los comentarios.

La entrada Creación de un menú arbolado paso a paso aparece primero en AyudaVelneo.

Modelo de datos abstracto

Un modelo de datos es un lenguaje orientado a hablar de una base de datos, que permite describir las estructuras, las restricciones de integridad y las operaciones de manipulación de los datos.

En este artículo nos vamos a centrar en el “modelo de datos abstracto”

Si te has perdido el primer post de esta serie, te recomiendo leerlo antes de continuar…

¿Seguro que lo has leído ya?

Pues continuamos.

Modelo de datos abstracto

¿Qué es un modelo de datos abstracto?

Cada una de las tablas de nuestra aplicación se divide en:

  • Registros: Tipo de información que vamos a almacenar en nuestra tabla
  • Campos: Propiedades del mismo tipo de cada uno de los registros que forman un registro
  • Índices:  Estructura de datos que mejora la velocidad de las operaciones, por medio de identificador único de cada fila de una tabla, permitiendo un rápido acceso a los registros.

Aplicando la “teoría del kiwi“, que mas da que sean clientes, que proveedores, que contactos, que vendedores, que …. Al final todos estos tipos (registros) tendrán unas propiedades (campos) comunes.

Por lo tanto podemos crear una tabla común (“Entidades”) que englobe a todos ellos.

Puestos a abstraer…

  • ¿Qué diferencia hay entre las líneas de un presupuesto y las líneas de un pedido?
  • ¿Qué diferencia hay entre las líneas de un albarán de venta y las líneas de una factura de venta?
  • ¿Qué diferencia hay entre las líneas de un albarán de compra y una factura de compra?
  • Y ¿entre un cobro y un pago?

Si os fijáis, no me he referido en ningún momento a los datos que guardamos (registros) si no a las propiedades que tienen (campos).

Ventajas e inconvenientes de este modelo de datos

Como casi todo es relativo… este modelo de datos también tiene sus ventajas y sus inconvenientes. Vamos a verlas tomando como ejemplo la tabla de “Entidades“:

Ventajas del modelo de datos abstracto

Evitamos tener duplicada la información. Si, por ejemplo, una entidad es de tipo cliente y además nos vende, no tendremos que volver a dar de alta toda su información para que también sea proveedor. Tendremos que ser nosotros como programadores los que dotemos a las aplicaciones de los mecanismos para diferenciar los distintos tipos de registros que guardaremos en la tabla.

Creamos campos en el proyecto de datos una sola vez. Al tener una sola tabla (por ejemplo de entidades) si añadimos un nuevo campo, ya estará accesible para los distintos tipos que tengamos en la tabla (por ejemplo un nuevo teléfono).

Creamos objetos en el proyecto de aplicación una sola vez. Es probable que tengamos el mismo formulario de edición para todos los tipos de entidad. Por lo tanto si añadimos un nuevo campo (el ejemplo de un nuevo teléfono) , con crearlo en un único formulario bastará.

Inconvenientes del modelo de datos abstracto

Creación de mas índices en la tabla. Por lo tanto las reindexaciones consumirán mas tiempo. Al tener todas las entidades en la misma tabla, a nivel de datos las tendremos que tener diferenciadas para cuando nos pidan la información.

Mas registros en la misma tabla. Al tener los datos del mismo tipo almacenados en la misma tabla, habrá mas registros por tabla. En entidades no resulta problemático pero ¿y en líneas de documentos?.

Peligro de superar la longitud máxima recomendable del registro. La longitud recomendada para los registros está fijada en 4000 bytes... aunque siempre podemos utilizar tablas de extensión.

Consideraciones a tener en cuenta a nivel de tabla

Como hemos dicho anteriormente,

en este modelo de datos, debemos ser nosotros como programadores los que deberemos crear los mecanismos para diferenciar la información que guardamos en las distintas tablas.

Siguiendo con el ejemplo de la tabla de “Entidades“, vamos a ver  como podemos crear estos mecanismos.

Campos a crear en la tabla

Para diferenciar los distintos tipos de entidad que guardaremos en la tabla, tendremos que crear un campo booleano por cada uno de los tipos. Esta es la estructura de campos para los tipos de entidad en vErp:

Campos para el modelo de datos abstracto

 

Además a nivel de tabla, también tendremos que encargarnos de crear los distintos índices para que el usuario pueda obtener los datos por tipos de entidad:

Ïndices en modelo de datos abstracto

 

En este caso hemos creado un índice por id, nombre, palabras y trozos por cada uno de los distintos tipos de entidad que vayamos a tener en nuestra base de datos.

Consideraciones a tener en cuenta a nivel de objetos de interfaz

Ya que estamos…. ¿por qué no facilitarles la vida a nuestros usuarios?

Vamos a proporcionarles las herramientas para que puedan obtener la información por los distintos tipos de entidad que hayan guardado.

A nivel de proyecto de aplicación, esto lo conseguimos por medio de los localizadores:

Localizadores en modelo de datos abstracto

 

En este caso hemos creado un localizador por cada uno de los tipos de entidad que tenemos y en cada uno de ellos, le hemos añadido los índices correspondientes creados anteriormente. De este modo podemos añadir acciones para que el usuario además de obtener los datos generales de todas las entidades, pueda localizar los datos de un tipo concreto.

¿Se te ocurre alguna ventaja o algún inconveniente mas de este modelo de datos? 

Déjame un comentario mas abajo y comenzamos el debate.

La entrada Modelo de datos abstracto aparece primero en AyudaVelneo.

Aprende a usar componentes de búsqueda II

En el artículo anterior “Aprende a usar componente de búsqueda” vimos cómo podíamos condicionar componentes de búsqueda y lanzar ésta de una forma sencilla. Al tener un solo componente podemos lanzar la búsqueda tanto en primer plano como en tercer plano ya que la diferencia de velocidad de carga de los registros es casi inapreciable… Pero ¿y si tenemos más de un componente por el que buscar? En este caso si o si tendremos que lanzar la búsqueda en tercer plano ¿Sabes el motivo? Sigue leyendo si quieres averiguarlo… ¿Por qué mis búsquedas van lentas en primer plano? Cuando comenzamos nuestros desarrollos con Velneo V7 normalmente las búsquedas las montamos como en el ejemplo del artículo anterior y si queremos buscar por otros campos… montamos otra búsqueda. Además solemos programar en local porque es más rápido a la hora de probar, porque las comunicaciones son malas, porque los datos mejor en mi equipo que en la nube, porque… etc.. etc.. etc.. (mira, esto me ha dado una idea para otro post… ¿Por qué tenemos que programar en cloud?). Bajo estas circunstancias, búsquedas con un solo componente y trabajando en local, da igual lanzar [...]

El artículo Aprende a usar componentes de búsqueda II fue publicado en Ayudavelneo por Francisco José Vila Martín

Aprende a usar componentes de búsqueda

En este artículo “Optimiza tus aplicaciones con búsquedas en tercer plano“, Juan Infante me pedía si podía detallar la utilización de los componentes de búsqueda y las búsquedas para cargar los datos en una rejilla… Pues vamos a ello Para empezar… ¿qué es un componente de búsqueda? Un componente de búsqueda es un subobjeto del objeto búsqueda que permite definir tanto el índice o índices por los que se realizará la búsqueda como el modo en el que ésta será realizada. Una vez que tenemos claro qué son los componentes de búsqueda, vamos a aprender a utilizarlos… En la definición del componente hemos visto que es un subobjeto que permite definir el índice por el que se realizará la búsqueda… pues es obvio que previamente tendremos que crear esos índices en la tabla en cuestión. Al crear el componente de búsqueda, tendremos que definir sus propiedades: Identificador: (obligatorio) tendremos que indicarle el identificador del componente de búsqueda. Nombre: (optativo) nombre descriptivo del componente. Estilos: (optativo) en esta propiedad podemos marcar si el componente de búsqueda es privado o no. Mezcla: (optativo) si añadimos más de un componente a la búsqueda, tendremos que definir como queremos que el componente [...]

El artículo Aprende a usar componentes de búsqueda fue publicado en Ayudavelneo por Francisco José Vila Martín

Tipos de campos en Velneo V7

Después de ver los distintos tipos de tabla de que disponemos, vamos a ver en este artículo los distintos tipos de campos que tenemos a nuestra disposición en Velneo V7 En Velneo V7 lo que programamos son objetos y subobjetos. Pues los campos son subobjetos del objeto tabla. Tipos de campos en Velneo V7 Debemos primeramente distinguir entre: 1.- Campos enlazados a otras tablas 2.- Campos sin enlazar a otras tablas Campos enlazados a otras tablas Si indicamos que el campo está enlazado, tendremos que definir en la propiedad “Tabla enlazada” la tabla con la cual queremos enlazar el campo. Podemos seleccionar tanto tablas de nuestro proyecto de datos como de otros proyectos de datos que estamos heredando. Además, asumirán las propiedades del campo ID de la tabla enlazada. Vamos a ver en detalle los distintos tipos de campos enlazados que podemos tener: Maestro: Enlaza la tabla de datos actual mediante el campo a la tabla de datos maestra elegida en la propiedad Tabla enlazada en la Lista desplegable Identificador. Una tabla puede apuntarse a sí misma a través de un enlace de este tipo. Estática: Enlaza la tabla de datos [...]

El artículo Tipos de campos en Velneo V7 fue publicado en Ayudavelneo por Francisco José Vila Martín

Tipos de tabla en Velneo V7

Con este post de hoy vamos a iniciar una serie de artículos dedicados al proyecto de datos en Velneo V7. Comenzaremos revisando los distintos tipos de tabla que podemos utilizar en nuestras aplicaciones. Se suele decir que una vez que hemos creado nuestros proyectos de datos, y sus objetos, tenemos nuestra aplicación terminada al 70 u 80 por ciento. Para que esto sea cierto, las tablas y todos sus subobjetos tienen que estar perfectamente definidos. ¿Qué tipos de tabla podemos crear? Antes de ver los distintos tipos de tabla que tenemos a nuestra disposición, vamos a definir que es una tabla: “Es el objeto de proyecto de datos que sirve para almacenar la información de manera organizada. Una tabla organiza la información en fichas o registros.” En Velneo programamos objetos, y la tabla no deja de ser un objeto mas. Es importante saber que una vez que creada una tabla, no será posible modificar su tipo. Vamos a ver los tipos de tabla de los que disponemos para realizar nuestras aplicaciones: Maestro normal con clave numérica La tabla tiene un campo ID de tipo numérico que va de 1 a 4 bytes, y un índice correspondiente de clave única. Todos [...]

El artículo Tipos de tabla en Velneo V7 fue publicado en Ayudavelneo por Francisco José Vila Martín