vBase. Estructura

Comenzamos nuestra serie de artículos sobre la vBase, explicando la organización de datos definitiva. Esquema de la solución:

Sigue leyendo

Anuncios

vBase definitiva

Con la salida de la versión 7.4 de v7, se publica lo que será la vBase estable. En esta vBase es fruto de la colaboración de Velneo con varias empresas, que empezó con una semana intensa de trabajo.

A esas jornadas, cada uno fue con su propia idea de vBase, y juntos llegamos a esta solución, de la cual estamos muy satisfechos.

Nuestro objetivo principal, incluso antes de ser elegidos para esta colaboración, era diseñar una vBase lo suficientemente abstracta, como para que pueda ser usada con aplicaciones totalmente opuestas (ejemplos: gestión clásica, académias, clubs deportivos,…..). Para ello habíamos empezado a contactar con otras empresas para consensuar ideas. Al ser elegidos para diseñar la vBase oficial, lógicamente, nos volcamos en el proyecto junto con el resto de equipo.

Ya en la v6 nosotros (Guida21), habíamos decidido basar nuestros desarrollos de las plantillas principales de Velneo (vBase, vConta) creciendo en funcionalidades, pero la experiencia de desarrollar aplicaciones para múltiples sectores, nos hacía encontrarnos una y otra vez, con la imposibilidad de tener una tabla de entidades común. Con esta vBase hemos conseguido que esto no nos vuelva a suceder. Hemos sido lo más ambiciosos en los planteamientos que el tiempo y los recursos nos han permitido.

La vBase que se ha publicado será totalmente estable a nivel de datos, es decir ya no desaparecerán campos ni tablas. La vConta se ha diseñado integrandola totalmente con esta, y es el mejor ejemplo de como operar con las entidades desde otras aplicaciones.

Voy a escribir algunos artículos que expliquen aspectos claves de esta vBase. Si quereis que escriba sobre algún apartado concreto me lo podeis indicar.

un saludo.

Jornadas análisis vConta

Hoy termina la semana de trabajo con Velneo, en la que estamos trabajando intensamente junto a Víctor García (Guida 21), Héctor Santoveña (HSM Software) y Jorge Velasco (The Seed Software Company), analizando y normalizando las futuras Open Apps de vBase y vConta.
La semana nos ha pasado muy rápidamente, personalmente ha sido una experiencia muy gratificante.
Nos va a dar mucha pena que finalice.
A lo largo de la semana hemos tenido momentos de acalorado debate que siempre han terminado con un resultado enriquecedor para todos. El poder contrastar la visión con el resto del equipo, el hecho que el objetivo común siempre ha sido claro por todos, hacer una vBase y vConta los más ambiciosa posible, la gran experiencia que cada uno aporta (propia y la de la lucha diaria con sus clientes) a conseguido que todos aprendamos y estoy seguro que lo que salga de aquí será una base muy sólida para la comunidad.

Os dejo un enlace al resumen de ayer, suscribo todos los comentarios de Jesus Arboleya, y esperamos repetir la experiencia. Aunque sabemos que este proyecto solo acaba de empezar.
Resumen del cuarto día de trabajo

Bueno os dejo que me voy a la última jornada, solo reiterar que está siendo un placer participar en esta experiencia.

Profundizando en vBase

Hemos estado profundizando en la estructura que debe tener el módulo vBase, para ser lo mas generalista posible y pueda ser utilizado para cualquier propósito. Como consideramos, al igual que otros desarroladores de v7, que este módulo deberiamos homologarlo lo mas posible, he procedido a contrastar mi planteamiento con otras personas con experiencia. Este es el caso de Hector Santoveña y Jorge Velasco. Nuestra intención es homologar los proyectos de datos, dejando los de aplicación para que cada uno aplique el estilo que desee. Una vez terminada la definición de campos publicaremos el proyecto para que pueda ser descargado por la comunidad.
Después de nuestras conversaciones, dividimos las tablas de la siguiente manera:

  • Universales. Tablas de uso universal, que podrían ser compartidas, por aplicaciones diferentes e incluso por clientes diferentes. Estas podrían estar en un proyecto separado, y compartido. Dentro de este apartado tenemos:
    • Divisas
    • Cambios de divisas
    • Idiomas
    • Paises. Dentro de los paises hemos desglosado hasta 2 divisiones
      • División 1 (comunidades autónomas)
      • División 2 (provincias)
    • Tipos de vías
    • Localizaciones: Códigos postales, localidades y calles. Esta es una tabla que nos permite obtener el código postal de una localidad o una calle indistintamente
    • Bancos, sucursales bancarias
  • Entidades y contactos. En este apartado disponemos de la tabla de entidades y todas sus relacionadas
    • Tablas maestras
      • Categorías
      • Tipos de relación
      • Clasificaciones. Para ser utilizada por el usuario final para cualquier fin.
    • Entidades
      • Entidades
      • Contactos. Relación de personas de contacto de una entidad
      • Direcciones. Direcciones postales
      • Relación entre entidades. Tabla de relaciones entre entidades
      • Categorías de una entidad
      • Centros o subdivisiones de entidad. Esta es una tabla de propósito múltiple, será utilizada para dividir la entidad en subentidades de control. Ejemplos: Centros de trabajo o de logística, Proyectos, centros de coste. Por ejemplo desde una gestión podría ser el almacén origen o destino de la mercancía.
  • Empresa
    • Empresas
    • Usuario por empresa
    • Entidades por empresa
  • Usuarios de la aplicación. Estas tablas las tenemos en un proyecto diferente, que es heredado por este.
    • Usuarios
    • Grupos de usuarios
    • Usuarios por grupo

Sigue leyendo

Hojas de estilo v7 (gdCSS)

Dentro de la v7 podemos utilizar hojas de estilo CSS, para configurar el aspecto de nuestras aplicaciones. Al igual que en la web 2.0 se separa el contenido y el diseño, estando este último en los ficheros .CSS. Entonces lo ideal es que nuestros desarrollos en v7 utilicen esta técnica, de forma que unos nos dediquemos al diseño de los datos y otros al de la estética.

Dado que yo soy de los que diseñan como organizar datos y no soy bueno en definir la estética, he decidido crear una aplicación que permita a los diseñadores experimentar como afectan los distintos estilos a los objetos de una aplicación en v7. De esta forma los diseñadores podrán ir creando trozos de código CSS reutilizable, viendo su resultado y configurando distintas hojas de estilo a utilizar por los usuarios, a modo de plantillas.

Para esto he creado un proyecto de datos, con la siguiente estructura:

Sigue leyendo

Almacén de objetos: Maestro código numérico

Vamos a describir lo que sería un mantenimiento de una tabla básica, lo que en la v6 se usaría dentro del almacén de objetos.

Tendremos un proyecto de datos y otro de aplicación, con una sola tabla MAESTRO.

Proyecto de datos

Los campos que contendrá esta tabla serán:

todos su índices, salvo CODIGO, están condicionados a que el valor del campo DEL sea 0, salvo el índice BAJA, que lógicamente estará condicionado a que el valor del campo DEL sea 1.

Proyecto de aplicación

El proyecto de aplicación lo empezaremos creando el formulario de mantenimiento. Para ello pulsamos el botón de formulario, y utilizaremos el
asistente de formularios.

Una vez creado el formulario con sus botones por defecto vamos a personalizarlo.
Sigue leyendo

Proyecto de datos común. vBase

Antecedentes

Vamos a desarrollar lo que será el proyecto de datos del que deberían partir todos nuestros proyectos. Los programadores que ya llevan un tiempo con Velneo, ya conocen sus plantillas, y saben que la primera y de la que parten todas es la
vBase. Así mismo sabrán que en el momento que empezabas a desarrollar o personalizar módulos, acababas modificando esa plantilla, y cuando aparecían nuevas plantillas, cada vez resultaba mas difícil, incluso imposible, integrarlas con tus desarrollos. Por otra parte si tu desarrollo no era una gestión o un entorno con clientes/proveedores, entonces o desarrollabas algo totalmente distinto, o “destrozabas” la vBase para aprovechar lo poco que te podía servir.

Con la v7 podremos encapsular los proyectos, de forma que puedan ser utilizados por otros, sin tener que realizar ninguna integración. Esto nos podría servir para que una empresa que tenga un CRM, lo pueda integrar con otra que tenga una facturación, sin complejos procesos. Claro que para ello tiene que haber una filosofía y un nexo común. Este nexo común, entiendo que debe ser este proyecto de datos “vBase”.

Por otra parte será muy importante que cada módulo que desarrollemos lo pensemos cerrado, en el sentido que su estructura interna no sea afectada por la integración con otros módulos. Tenga, como los objetos de v7, una/s entrada/s y una/s salida/s y el resto sea interno, y cuando exista una nueva versión, si esos puntos de entrada/salida no cambian, con solo sustituir una versión por otra estará todo operativo.

Partiendo de estos precedentes, aquí voy a explicar mi visión de lo que debería ser una vBase, de forma que pueda servir tanto para desarrollar un ERP o para hacer una aplicación para academia, donde en lugar de clientes tiene alumnos, y en lugar de proveedores tiene profesores.

Bien como decía en el artículo anterior, este proyecto de datos deberá contener las tablas que usaremos siempre en nuestras aplicaciones, y en cualquiera de ellas lo habitual es que interactuaremos con personas o empresas, y que necesitemos guardar sus datos personales (nombre, teléfono,…). Por lo tanto este proyecto girará alrededor de una tabla que llamaremos entidades.

Primeras tablas

Partiremos de la Open Apps de Velneo: http://velneo.es/71756/vbase/

Localización. En cualquier aplicación es habitual tener una tabla de provincias y/o países, que no permita ubicar a nuestros contactos. En algunos casos seguro que muchos habremos necesitado crear una tabla de comunidades autónomas, códigos postales o poblaciones.

Por lo tanto se deben crear varias tablas que no permitan, de forma flexible determinar el grado de detalle para definir una ubicación. Aquí no me voy a detener mas, y os remito a la estructura que han montado en Velneo para resolverlo.

Esquema de localización

Esquema de localización

Empresa que usa la aplicación.También es habitual tener una tabla donde guardemos los datos de la empresa o empresas que usan la aplicación. En algunos casos habremos creado solo unas variables de disco para guardar el nombre de la empresa, en otros seguro creamos una tabla con un registro donde guardábamos esos datos, y cuando necesitamos que nuestra aplicación fuera multiempresa, pues hemos usado esta tabla para crear todas las empresas necesarias.

Usuarios. También podemos tener una tabla de usuarios de la aplicación. En este caso podemos usar una tabla exclusiva para guardar su nombre o integrarlos en la tabla de entidades, donde ya podremos tener todos los datos personales habituales, y eso es lo que haremos.

Entidades. Esta es la tabla donde estarán todos nuestros contactos, sean empresas o personas físicas. Lo que yo entiendo es que debería ser una tabla como es la de contactos de cualquier programa de oficina o correo electrónico. Compatible con nuestros contactos de móvil, o de la agenda electrónica.

Profundizando Sigue leyendo