1º Entender Velneo y empezar

En este Blog, siempre se habla de la importancia de la Parte Izquierda de Velneo y la importancia de la base de datos y me he decidido a intentar explicar esto desde mi punto de vista.

Debeis tener en cuenta que no soy un formador experto, pero creo que os dará una visión distinta que en algunos casos os hará comprender mejor Velneo.

Reitero que es simplemente mi visión, como se la explicaría a un colega, sin demasiadas pretensiones academicistas .

Si deseais más exactitud antes o despues de estos Post  os puedo recomendar:

1º El seminario de la Landing Page para tener una vision Global de Velneo

2º Primeros Pasos de Velneo Una aplicación completa partiendo de la plantilla vGestion

2º Material de Arboleya.

     Video 1 Empezar un mantenimiento típico desde cero

    TIpos de Campos en Velneo

    Tipos de Tablas en Velneo

    Las Actualizaciones

Y por supuesto toda la formación oficial de Velneo

Vamos a incidir únicamente en la parte izquierda de Velneo, en la Base de datos, yendo de menos a más y veremos como esa es su verdadera esencia y él por qué de no necesitar programar procesoso apenas.

Empezaremos por las tablas, las relaciones y después las actualizaciones, el uso de valores iniciales, los campos fórmula, fórmula histórico,los trigers y nos percataremos de la enorme potencia de esta base de datos, al tener integrados todos los objetos visuales y procesos de la parte derecha con los datos de la izquierda.

Partiremos de conceptos que pueden ser muy básicos para algunos , pero deseo empezar desde lo más sencillo y utilizando la terminología de Velneo.

2º ¿Como definir los tipos de Tablas?

 

Lo primero que te vas a encontrar en Velneo a la hora de desarrollar en Velneo es cómo definir los tipos de tablas, maestras, submaestras, y el tremendo lío de las históricas, que no lo es si tienes los conceptos claros.

Primero

Iremos al esquema de tablas y definiremos los nombres de tablas que va a manejar nuestra aplicación y las crearemos sin entrar a definir ninguno de sus campos .

Se crearan automáticamente con el campo código, nombre y sus índices por defecto (Código, Alfabético , Palabras y Trozos de Palabra del Nombre)

Estos índices serán utilizados en el 80% de los casos y los respetaremos de momentos, no te molestan y casi seguro que los usas, si no es así ya los eliminaras cuando tengas tu aplicación terminada.

Limitate a ir creando una tras otra todas las tablas que vas a utilizar.

SEGUNDO ¿De que tipo?

 - MAESTRAS : Todas por defecto   y con el campo CODIGO, siguiente al último.

                                    En Velneo no tiene apenas importancia el campo código ( Ver Final Post 1)

- SUBMAESTRAS Solo cuando sean líneas o casos similares.   Por ejemplo Lineas de Albaran, de Pedido, de Factura , de Presupuesto

                 ¿Por Qué? Por que el Indice Código de una tabla  maestra se compone de un enlace a una tabla Maestra mas una segundo campo. Si este es Siguiente al última, tendremos gestionada de forma automática la gestión de líneas.

                 Hay otros casos que nos pueden interesar,  pero los dejaremos para más adelante. Por ejemplo en una estructura Paises, Provincias, Ciudades y que una vez localizado un Pais, el siguiente localizador nos muestre solo las provincias y despues las ciudades.

- HISTORICAS,  Si eres principiante NUNCA.

                   Crearla de este tipo, solo implica que no tiene campo código. Esto solo es una optimización, válida en los casos correctos, pero que de definirla incorrectamente nos va a suponer limitaciones en los diseños . Por tanto para nosotros no existe este tipo de tabla de momento

ARBOLADAS

-          Las dejaremos para cuando dominemos los conceptos básicos de Velneo

MAESTRO DE SEGUNDO NIVEL E  HISTORICO DOBLE

De estos tipos de Tabla nos olvidaremos ya que son variaciones de las anteriores y a nivel práctico no nos interesan para nada. Más que al tipo de tabla hacen referencia al asistente para crear una estructura determinada jugando con los tipos Maestra y los enlaces posibles.

 A practicar

 

Bueno pues ya puedes abrir el esquema de tablas y empezar a definir tablas, ya sabes Maestras y submaestras, no hay más. Que es una tabla tipo “lineas de .. “, pues creas la maestra que será la cabecera, y a continuación la submaestra que es la de lineas, y todas las demás Maestras. 

Cuestiones pendientes

1) ¿Por qué el campo Código no tiene importancia en Velneo?

Este campo al contrario que en otras bases de datos más antiguas solo lo utilizará el sistema para sus propios enlaces. No te obsesiones con este concepto y las manías de que el campo codigo de un artículo, incluya el código de proveedor o el tipo de producto o la gama. Eso ya vendrá después.

Si el campo código de un cliente es el 25, por ejemplo, en todas las tablas que apunten a ese cliente contendra el 25, pero a efectos prácticos el usuario final no tiene por que usarlo para nada.

o       Por ejemplo si hablamos de una tabla de Artículos, podremos crear un campo Referencia Propia, otro Referencia del Proveedor y todos cuantos queramos y de ellos crear a su vez los Indices correspondientes para localizar en cualquier sitio donde lo necesitemos estos registros por cualquiera de esos Índices.

o       Puedes crear nuevos campos combinando los anteriores o incluso alimentados por campos enlazados de otras tablas, que con valores iniciales se actualicen solo y crear un campo referencia con la gama, el material o lo que quieras para facilitar la localizacion, según la costumbre del usuario.

o       Pero además en Velneo con la potencia de los localizadores, utilizando los indices por Trozos y por palabras, más la posibilidad de crear campos con valores iniciales automáticos, localizar un cliente, articulo, proveedor, va a ser muy sencillo y en ningun caso tendrá nada que ver el campo código que definiste.

 

 

3º ¿Como enlazar nuestras tablas?

 

2º DEFINIR LOS TIPOS DE ENLACE

En primer lugar. Hemos definido todas las tablas como Maestras, no hay tablas Históricas, pero eso no quiere decir que no haya enlaces a Histórico.

 Aunque enrevesado no tiene nada que ver la definición de las tablas con los tipos de Enlace.

 Me explico:

 Dos tablas pueden ser maestras y podemos decir que una es histórica de otra aunque ambas sean Maestras. Estamos diciendo “Histórica” por la relación que hay entre ellas , no por su tipo. Por tanto TABLA HISTORICA digamos Pura no vamos a utilizar pero RELACIONES A HISTORICA o decir que una tabla es HISTORICA de otra sí.

De esta forma podemos tener cuatro tablas de tipo Maestro, como por ejemplo Paises, Provincias,Ciudades, y Clientes.

Sin embargo en clientes tendremos un puntero a Maestro (A Uno) a su ciudad, es posible que tambien a su Pais y a su Provincia, de Ciudades un puntero a su provincia y a su Pais, y de provincias a su Pais.

Al tener el puntero a Maestro y existir una relación a Maestro, también existirá el inverso. Es decir de Paises tendremos un enlace a historico a Ciudades, a Provincias o incluso a Clientes. Por ese motivo , por que hay un enlace a histórico (Plural, Uno a Muchos) . Diremos que Ciudades, Provincias o Clientes son Historicas de Paises (Hay varios Clientes, Provincias, Ciudades de uno solo País), aunque sean todas de tipo Maestro, es decir tengan campo código.  

 ¿Ha quedado claro esto? Si no haz el favor de volverlo a leer, ya que si esto no te queda claro, arrastraras un error que te hará incomprensible cualquier documentación.

Bien, sigamos, tenemos abierto nuestro Esquema de Tablas con todas las tablas que hemos definido.

Tan solo aparecerán enlaces entre aquellas que hayamos definido como Submaestras y Maestras. Es decir entre Líneas y sus Cabeceras. Por el hecho de haberlas definido Submaestras ya habrán generado algunos enlaces. Todas las demás estarán sueltas.

Intentaremos siempre ordenar nuestro esquema poniendo las tablas de líneas debajo justo de las de cabecera y veremos claramente  los enlaces entre ellas. Pedidos y Lineas de Pedidos, Facturas y lineas de Facturas, Partes y lineas de partes, etc.

TRUCO OBLIGATORIO : En el esquema de tablas siempre poner la Tablas Maestras arriba de las que son historicas de ellas. Eso facilitará enormemente la comprensión del esquema.

 Busquemos en nuestras Tablas las relaciones que hay entre ellas.

Si elegimos 2 tablas cualesquiera, ¿Que relación hay que definir entre ellas?

Fácil, solo hay que hacer la siguiente pregunta:

 ¿Un elemento de la tabla A, se relaciona con uno de la B o con varios de la tabla B?

 Si aplicamos esto a las tablas ya relacionadas por ser maestras y submaestras, veremos que

 Una linea de Facturas se relaciona con una sola cabecera de Facturas, luego habrá un enlace a Maestro.

Una cabecera de Pedidos, se relaciona con una o varias líneas de Pedido, una cabecera de Facturas se relaciona con una o varias líneas de Pedidos, es un enlace uno a muchos, por tanto es un enlace a Histórico, (En V7 se denomina Plural en lugar de Enlace a Histórico). 

EN LA PRACTICA : Siempre que hay una relacion entre dos tablas, en las que en la tabla B hay un enlace a maestro con la tabla  A, es decir un registro de B apunta a un único enlace de A,  siempre existe la relación inversa, siempre hay o debe haber un enlace a histórico de A hacia B.

TRUCO : Busquemos nuevos enlaces a Maestro que es lo más fácil y despues veremos claramente que existe la inversa (A Historico, o una a muchas)

De hecho en V7, este enlace a Plural, lo realiza Velneo de forma automática al hacer el puntero a Maestro, crea el enlace uno a varios inverso. En 6.x no, pero deberemos hacerlo manualmente en el 99% de los casos, de lo contrario siempre lo hecharemos de menos, salvo que utilicemos el enlazador que ya nos crea los enlaces en la tabla.

 Ahora podemos entender mejor el párrafo inicial.

Tenemos dos tablas Clientes y Países, Ambas son TABLAS Maestras. Pero de Cliente tenemos un Enlace a Maestro a País, puesto que un Cliente se relaciona con un único Pais.

Por tanto tenemos un enlace de Pais a sus Clientes, de un País todos los clientes, es decir un enlace a Plural, o un enlace a Historico.

Por tanto es habitual decir que Clientes es Historica de Paises, pero recordemos que el tipo de ambas tablas seguirá siendo Maestras.

¿Entonces por que tanto lío con los tipos de Tabla?

Solo por curiosidad os dire que si una tabla nunca es Maestra de otras, y nunca es en Ningún caso, es decir no tiene ninguna tabla , ni la tendrá que tenga un puntero a Maestro sobre ella, no es apuntada de esta forma por nadie, entonces no necesita Velneo un campo código para que se apuntada.

Por ejemplo, una tabla de estadisticas, no es normal que exista alguna tabla que tenga un puntero a un registro de está tabla y este sea único en todos los casos. Entonces y solo entonces podríamos haber definido la tabla como historica, pero ante la duda, si es maestra con su campo código no nos molestará para nada.

 Por tanto olvidaros de ese concepto, es solo una optimización y para nosotros que estamos empezando nos da igual.

 SIGAMOS ENLAZANDO NUESTRAS TABLAS

 En nuestro esquema de tablas tendremos otras tantas tablas aparte de las comentadas de Líneas y  cabeceras por enlazar, por ejemplo Clientes, Países, Artículos, etc.

 Pues procederemos a enlazarlas una a una. Para ello y desde el ESQUEMA DE TABLAS utilizaremos el Enlazador, ya que a efectos prácticos y didacticos es lo mejor.

Pero recordad que el Esquma de Tablas es un VISOR, lo que realmente manda, son los campos que contiene las tablas, sus enlaces y lo definido en la subcarpeta de la tabla como Enlaces a Historico en &.x o Plurales en V7.

Nos situaremos siempre en la tabla que es apuntada, en la Maestra.

Por ejemplo desde Cabeceras hay una relación a un Cliente, y desde Cliente a muchas Cabeceras.

Pues nos situamos en Cliente (La maestra rspecto a Cabeceras en este caso) , pinchamos el enlazador y arrastramos hasta Cabeceras, soltamos y ya nos ha creado las relaciones.

Una vez hecho esto, sería conveniente ver los campos y enlaces que se han creado en la tabla de clientes y cabeceras, esto nos facilitará la comprensión y recordad que lo podiamos haber hecho manualmente sin necesidad del esquema y el enlazador 

En Cabecera nos habra definido un Campo Cliente, que será un enlace a Maestro al cliente.

 En la relacion inversa

 En Cabecera nos habrá generado un nuevo índice con ese campo CLIENTES, y habrá creado una relación Historica o Plural en CLIENTES que apunta a todas las cabeceras, relacionándolo mediante este  índice creado.

 Por tanto, a medida que vayamos definiendo enlaces, estamos creando campos necesarios en nuestra base de datos.

De la misma forma generaremos todos los enlaces entre las tablas, generandose en ese momento los campos y los indices y los enlaces a Historico inversos por cada una de ellas.

Por ejemplo podemos repetir la operación desde paises, que en este caso es la maestra de Clientes, y desplazamos el puntero a Clientes (Que en este caso es la historica de paises)

 Espero que en este punto tengamos ya claro los Tipos de Tabla que necesitamos en un principio (Maestros y Submaestros).

 Y los enlaces que hay entre el resto de tablas, punteros a Maestros (Un registro apunta a un unico registro de otra tabla) y la inversa , enlaces a Historico (Un registro apunta a varios o muchos registros de otra)

 Para definirlos correctamente solo debemos definir los enlaces a Maestro, detectarlos y si lo hacemos con el enlazador nos hará los inversos automáticamente.

 Recuerda: Te situas en la Maestra y arrastras hacia la tabla Plural.

Veamos un ejemplo de como estaría ahora nuestro esquema de tablas

 

4º Un caso muy común, Muchos a Muchos

 

Lo más habitual es que muy pronto al intentar relacionar dos tablas nos encontermos con la siguiente casuística.

Un elemento de una tabla se relaciona con muchos de otra y a la inversa sucede lo mismo. Estamos buscando como aconsejamos los enlaces a Maestro y no lo encontramos, sin embargo estamos convencidos de que entre ambas debe existir una relación.

¿Que sucede? ¿Cual es entonces la que tiene el puntero a maestro sobre la otra?

Por ejemplo:

Nos encontramos   con una tabla que sea Obras de Teatro, y otra segunda que sea Actores.

Y nos encontramos usando nuestra pregunta

Una Obra de Teatro se relaciona con muchos Actores (Todos los que la han representado). Por tanto es un enalce de uno a Muchos, no es un enlace a Maestro que es el qué queremos buscar.

Y si analizamos Actores, nos damos cuenta que un Actor apuntará a muchas Obras, todas las que ha representado, por tanto tampoco es un enlace a Maestro.

La lógica nos dice que ambas tablas las quiero relacionar, pero “No puedo según lo comentado, no encuentro cual es la maestra y cual es la histórica”.

Ya que lo que queremos que haga nuestra aplicacion de forma fácil y directa, es que si tenemos una ficha de una Obra, obtener todos los actores que intervienen en ella. Y si tenemos la ficha de un Actor, saber todas las obras que ha representado

¿Qué sucede?

Pues fácil, lo unico que sucede es que nos olvidamos por definir una tabla. Esto es así en el 100% de los casos que nos encontremos esta situación. Queremos relacionar dos tablas, pero cualquier registro de ambas se relaciona con varios de la otra.

 En este caso la tabla que nos falta es Reparto. Que estara compuesta de Obra y Actor.

 Ahora sí. Un registro de reparto apuntara a un único Actor y también a una única Obra. Y por tanto desde cualquier registro de Repartos habra un enlace  un solo Actor, un enlace a maestro y por tanto Repartos será historica de Actores, y lo mismo sucedera con Obras. Un registro de Repartos, tendrá un enlace a maestro un puntero a la obra, y Repartos será  por tanto Histórica de Obras.

Simplemente nos faltaba una tabla nueva. Lo mismo sucede en la vida real con multiples ejemplos.

Otros ejemplos similares serán: Alumnos, y Profesores siempre y cuando  distintos profesores den distintas asignaturas a distintos alumnos. EN ese caso nos hara falta una tabla que se denomine Profesor-Asignatura, compuesto por dos campos enlaces a Maesto , el profesor y la asignatura

Una más la tabla Escandallos en cualquier programa de producción con los enlaces a Maestro  Compuesto y Componenente

Y una vez creada la tabla que necesitabamos ya podremos ya trabajar.

Luego veremos como al haber creado estas relaciones correctas, no tendremos que hacer nada en la parte derecha. Cómo en Velneo con una o dos lineas de proceso tenemos un monton de trabajo resuelto y sin necesidad de tener que resolver una Select

Desde un alumno si cargamos su histórico (Sus Materias) , tendremos todos sus Profesor-Materia y por tanto todos sus profesores.

Desde un profesor podremos cargar un histórico a todas sus Profesor-Materia. Y si volvemos a cargar el Histórico tendremos todos los alumnos de ese profesor.

En los manuales de referencia de Velneo , que se puede descargar del Foro, existen númerosos ejemplos, si quereis simplificarlos olvidaros de que alli sean tablas historicas (De tipo histórico) quiero decir y tratarlas todas como maestras, es decir con campo código, ya que como hemos comentado, es solo una optimización y no hay problema en definirlas como maestras.

5º Uno a muchos y puntero a Maestro sobre si misma

 

En la vida real se dá que estas relaciones que hemos comentado y que son las habituales, se pueden dar entre la mismas tablas.

Y aquí aparece ya una de las grandes ventajas de Velneo, puesto que no todas las bases de datos permiten este tipo de enlaces y mucho menos el enlace uno a muchos (Plural) sobre la misma tabla. Esto nos evitará soluciones enrevesadas a las que no hay más remedio que recurrir en la mayoria de Bases de datos comerciales cuando aboradamos la problematica de los escandallo.

 Por ejemplo

Una tabla de Socios, en las que hay un campo que es Socio Captador, o socio que lo a traido al club.

En ese caso un registro de Socios apunta a un registro de la misma tabla y solo a uno. Pues es un Puntero a Maestro, lo que pasa que sobre la misma tabla.

 Y a la inversa sucederá lo mismo, un socio a cuantos socios a traído, sera un enlace a Histórico, pero sobre la misma tabla. Simplemente crearemos un índice por Captador, y el registro apuntara a todos los registros que tengan ese captador.

Este tipo de relación nos facilitará enormemente cualquier programa de producción en el que intervengan escandallos. Ya que simplemente con la tabla Articulos y otra Compuesto-Componente, tendremos en todo momento un Articulo en que otros articulos está como componente y por que articulos (Compuestos) esta formado.

Si a estas relaciones directas le sumamos la potencia de los campos formula, formula historica y actualizaciones, los típicos procesos de calculo de costes , mano de obra, tiempos  de articulos productivos será cosa de niños.

En nuestro actual Esquema de tablas esto no se puede visualizar pero veamos como quedarian las tablas.

 

 

6º Una Tabla puede contener varios enlaces a maestro sobre otra

 Esto es evidente, pero sobre todo al principio y si no conocemos otras bases de datos, nos puede confundir.

Si tenemos una tabla de datos, por ejemplo cabecera de Facturas, es posible que existan varios enlaces a maestro sobre la misma tabla, por ejemplo Clientes o Entidades.

Pudiera ser que en la cabecera de factura tuvieramos los siguientes campos.

Cliente al que se le factura, Cliente o entidad donde se entrega la mercancía y cliente donde se envia la documentación. Los tres sería tres campos diferentes y todos enlazarian con diferentes registros de la tabla de clientes o entidades.

Es decir en la tabla clientes existirían 3 o 4 campos que serían enlace a maestro de la misma tabla Clientes, pero en cada caso podrían apuntar a distintos registros

Esto es obvio para muchos de nosotros, pero hay personas que se estan iniciando en esto de la programación con Velneo y no lo quería dejar pasar.

7º Los enlaces Historico (Uno, varios, ¿Cuantos debo crear?). Empezando a jugar con los índices.

En una relación uno a muchos por ejemplo Clientes con todas sus facturas, el primer enlace a historico que se creó sería utilizando en Facturas el Indice que nos creo Clientes, con la opción Acepta repetidas el Enlazador del esquema de tablas.

Pero no tenemos por que ceñirnos a esta relacion a historica únicamente.

Por ejemplo y adentrandonos más en el uso que después le daremos a los enlaces en Velneo.

Imaginemos que tenemos un formulario de Clientes, con su campo nombre, teléfono,etc y los botones de aceptar, cancelar, etc.

Es más que probable que sepamos que tan solo con poner una rejilla de historico en ese formulario, y le digamos que el historico es Facturas, en ejecución nos mostrará sin mas las facturas de ese cliente. En V7 lo que pondremos será un control que lance un proceso con una sola linea “Cargar Historico” y la rejilla correspondiente.

Pero es más, no solo las mostrará , sino que podremos dar de alta nuevas facturas de ese cliente, editarlas, y lo que deseemos, ya que no se trata de vistas, sino de elementos (Rejilla, formulario, etc) que estan definidos dentro de la base de datos, ya que en su creación dijimos de que tabla eran, y por tanto la base de datos ya define sus relaciones, bloqueos , actualizaciones y demas comportamientos  con las facturas sin tener que detalalr  nosotros nada más.

Pero el tema es que si nosotros no queremos visualizar las facturas en ese formulario por el orden que aparecen ¿Que podemos hacer?

Lo que quieras menos empezar a hacer procesos tipo ordenar.

Entonces…

Pues lo lógico es jugar con los índices.

Si queremos que aparezcan ordenadas por fecha, el indice que utiliza el historico debería ser Cliente- Fecha.

Si queremos que aparezcan por orden de Factura Cliente-Factura

¿Y si queremos que solo aparezcan las cobradas?

Pues si tenemos un campo cobrado booleano, crearemos un indice que sean solo las cobradas, es decir las que en ese campo este activo y por el orden que decidamos con el resto de los indices.

Y lo mismo sucedera, con si queremos oredenarlas por gama, o que solo aparezcan las de una gama determinada, etc.

Si queremos que aparezcan por ejercicio, nuestro índice será Cliente, Ejercicio, fecha y en la parte visual crearemos un encarpetado de histórico utilizando el ejercicio como clasificador. En V7, lo siento pero o no esta diponible o no lo se, cuestion de meses.

Y así todas las variaciones que se os quieran ocurrir.

RECUERDA : Ante la duda siempre es mejor CREAR UN INDICE, ya que la base de datos de Velneo no te va a penalizar en ejecución los indices que definas ni los registros que tengas.

y por supuesto podrás crear tantos enlaces a Historico entre dos Tablas, como Indices quieras utilizar.

Proximamante veremos esto más detenidamente

Una estrutura de Escandallos en Velneo, Producción

A  raíz de una pregunta en el foro de Velneo sobre las dudas de la posibilidad de crear programas de producción complejos,  he generado este pequeño artículo orientativo.

Precisamente antes de entrar en Velneo, realice muchos programas de producción y costes y alguno de ellos muy complejos: fabricación de pequeños electrodomésticos, fabrica de material quirúrgico , fabricación de tornillería y otro para el sector de la automoción. Y te puedo decir que no solo es posible lo que planteas sino impresionantemente sencillo y por supuesto sin salir para nada de Velneo. Pero como siempre hay que cambiar el Chip y pensar en la parte de datos.

Esto es posible  gracias a que la base de datos permite enlaces uno a muchos sobre la misma tabla, cosa que no tienes en ninguna otra base de datos, además de recursividad infinita, punteros a maestro sobre si misma , etc . Todos estos elementos  te permitirán  jugar con estructuras de escandallos de forma increíble.

Lo normal es que tengas  una tabla Artículos (En mi opinión puede comtener todos productos acabados, semiterminados y materia Prima e incluso puedes meter en el mismo mano de obra procesos, etc, eso ya al gusto)

Tienes otra tabla que es la que realmente nos interesa, que es Escandallo  ( Compuesto- Componente y Cantidad de componentes) , Evidentemente se puede ampliar. Compuesto es un puntero a Maestro (Artículos). Componente es otro puntero a maestro (Artículos). Artículos es donde tenemos la información ampliada y los enlaces a Facturas, etc , pero realmente la esencia de cualquier control productivo la tenemos en escandallos.

En Escandallos es donde tendrás estos enlaces singulares

Un enlace Histórico (Uno a muchos) de cada registro compuesto-Componente sobre  la misma tabla por el índice del campo Compuesto, con esto cada registro de escandallo esta relacionado con los registros del campo componente, pero que cuando te sitúas en ellos para ti son nuevos compuestos y así hasta el final del escandallo .

Por otra parte tienes otro enlace pero sobre el índice Compuesto, teniendo así cada pieza donde se incluye y así hasta los productos terminados.

Ojo que estamos trabajando sobre una sola tabla, es muy simple, pero hay que entenderlo. Podremos con esta estructura recorrer todo el árbol de producción de arriba a abajo o de abajo a arriba, tanto para visualizar, como para acumular los valores deseados. Podemos incluir en esos registros campos formula que operen con cualquier otro dato enlazado a través del registro Artículos.

Pero lo que es mas importante, no tendremos que resolver nada en ningún sitio, ni a nivel de ejecucion ni de programción, ya estña todo enlazado

Con esa estructura imaginemos hacemos  el ejercicio mas sencillo posible.

Presentamos un formulario que aparezca sobre la tabla escandallos. Un formulario que presente el Compuesto y como tiene un puntero a maestro visualizamos directamente todos los todos del articulo (Descripción, etc) y debajo una rejilla con los componentes , es decir una rejilla del histórico.

Si hacemos doble click  en cualquier componente, se vuelve a repetir la situación y así hasta el infinito.

Y por supuesto igual de forma inversa, cada componente en donde esta, creando otra rejilla de histórico y utilizando el enlace inverso.

Ya lo tenemos, si existe la relación y sin complicarnos mucho podemos en ese mismo registro poner un campo formula histórico que sea la suma de sus históricos, por ejemplo del precio de compra, del pmp, del precio de venta de los tiempos de montaje , de los defectos o de lo que queramos y tendremos los datos sin un solo proceso.

Ahora  si deseas optimizar convierte esos campos en actualizaciones, te aconsejo inicialmente campos formula para comprender el funcionamiento de los enlaces y ver los resultados inmediatamente.

Lo estas viendo, pues ahora complícalo todo lo que quieras, y si tuvieras que hace un proceso para alguna cosa muy especial, es lo mismo. Seleccionas una ficha o registro de la tabla escandallo. Cargas histórico y tienes la lista de todos sus componentes para tratar como quieras, recorres la lista uno a uno, cargas histórico y la operación se repite y a la inversa igual.

Con la misma estructura, simplemente añadiendo campos y campos formulas, tendrás valoraciones, costos, tiempos de montaje, defectos por producto terminado, y un largo etcetera. Pero lo mas importante es que todo está resuelto en la Base de datos y de una simplicidad abrumadora y realmente con una sola tabla y procesos cero.

Evidentemente es una simplificación pero con esa estructura tienes toda la esencia.