FILOSOFIA DE TRABAJO V7 HERENCIAS

Velneo
1

Creo un solucion MIS HEREDABLES con un proyecto Heredables donde meto todas las tablas maestras tipo como Clientes, Persona de contacto, entidades, Pais Provincia Localidad Dibujos...

Me gusta como queda y encantado

Creo otra solución Actividades deportivas y dentro de ésta el proyecto Paddle le digo que herede de la solucion Heredables y en principio muy contento porque ya todas las tablas maestra las tengo resueltas pero.. me encuentro que a la tabla Personas de contacto para este proyecto Paddle precisa de dos campos  que raramente se van a necesitar en cualquier otro tipo de proyecto; entonces que hago?  si modifico la estructura en mi solucion basica me va a efectar a todos mis proyectos visualizando dos campos que no vienen al caso.

Tendré que crear una tabla Persona de contacto a nivel del proyecto Paddle  que tenga como maestra Personas de contacto de la solucion Heredable y así al menos me evito tener que repetir todos los campos aunqe el formulario original tampoco me sirve..

En fin he estudiado el ejemplo de herencia inversa pero no le encuentro aplicación a este caso, caso nada extraño en l mundo de la gestión...

Posiblemete sea un mal planteamiento por mi parte de la fílosifia de trabajo de velneo no sé .. ya contareis..

 

 

 

2

Hola Benito,

Yo me he encontrado con el mismo planteamiento y tampoco se como enfocarlo. Hay tablas maestras que según la solución que queramos crear necesitan de campos que apuntan a otras tablas.

Ejemplo: Tengo un proyecto base que engloba todas las tablas maestras que pueden heredar otros proyectos, en las que se pueden encontrar "Clientes". Ahora bien, si desarrollo un proyecto de contabilidad, a la tabla "Clientes" le deberé asignar la cuenta auxiliar del PGC, en este caso no puedo, ya que ésta está en un nivel superior y no es heredable. Lo mismo me pasa con los proyectos de "Ventas" y "Compras", no pueden estar en proyectos distintos ya que hay muchos enlaces entre ellos.

Es de suma importancia tener muy claros estos planteamientos antes de arrancar una solución.

Saludos

Overall

3

@benito,

 

Datos Clientes, Datos Contables, Datos Unos, Datos Dos..... (proyectos posibles de datos distintos)

Aplicacion Clientes (Hereda datos Clientes)

Aplicacion Contable (Hereda datos Clientes y Datos Contables )

Etc....

Simplemente vas subdividiendo en proyectos pequeños para que puedan ser heredados en cualquier momento. Tendrás que usar herencia inversa para aprovechar los formularios correspondientes.

 

Mira el ejemplo de vGestión y verás una rama completa de herencias tal y como comento.

 

 

4

Hola, bueno me habies abierto un camino habrá que trabajarlo, evidentemente tener muy claro este planteamiento pienso que es básico para desarrollar con V7

Gracias

5

Hola,

Si, es cierto. Hay que tener muy claro cual va a ser nuestro planteamiento.

Saludos

Overall

6

 

Yo también estoy haciéndome estos mismos planteamientos:

¿Donde poner por ejemplo la cuenta contable correspondiente a una entidad? ¿En la caja BASE o en la caja CONTA? En la v6 estaba muy claro: como no existía la herencia tenía que ir todo junto. Pero en la V7 la cosa no está tan clara.

 

Está claro que tener una caja BASE que sea lo más genérica posible y contenga solo los datos generales es lo más adecuado. Lo mejor sería poner los datos contables en la caja CONTA, como una tabla histórica de ENTIDADES (aunque solamente exista un registro en ella para cada entidad).

 

Lo que no me cuadra es la forma en como montar esto a nivel de los formularios (usando la herencia inversa). En el ejemplo de la plantilla vGESTION que nos comenta velavisual, se usa una rejilla para mostrar estas tablas históricas (por ejemplo la de ENTIDADES DE GESTION que es la que contiene los datos de facturación de cada entidad). Esto lo encuentro lógico cuando hay realmente un plural entre el maestro y el histórico (mostrar los PEDIDOS en la ficha de un CLIENTE), pero no para el caso que estamos comentando de los datos contables de una entidad (no es un plural, aunque esté en una tabla histórica). Lo que se ha hecho en vGESTION lo encuentro, en mi opinión, poco intuitivo para el cliente final.

 

 

Continuando con este ejemplo de los datos contables de una entidad: he intentado montar los formularios para que, de manera transparente al usuario, se muestre en el formulario de ENTIDAD los DATOS CONTABLES, pero en formato de subformulario, no de rejilla. He probado mil cosas diferentes... con herencia inversa; sin herencia inversa; con eventos; con botones; con casillero; con variables globales; poniéndolo en un separador; poniéndolo directamente en un control objeto... pero no hay manera, no lo consigo. Lo que siempre me falla es la creación inicial de la ficha en blanco dentro de la tabla histórica.

 

No tengo mucha experiencia en Velneo... no sé si soy yo o es que realmente no se puede hacer. La duda que tengo es: si hubiera alguna forma directa y elegante de hacerlo, ¿no se hubiera ya utilizado en la plantilla vGESTION?

 

¿Alguien se ha planteado estos mismos temas y ha conseguido algo? Tengo la sensación que hacer una caja BASE como la de v6, llena de campos que corresponden a módulos superiores, sería desperdiciar toda la potencia que nos da la herencia en V7.

 

Un saludo!!

Xavi

__________________________________________________________

"La mala noticia es que el tiempo vuela. La buena, que tú eres el piloto."

Cashback (2006)

 

7

Hola. Me pregunto porqué no nos dan directamente la solución desde Velneo, este tema no está sujeto a interpretaciones, solo hay una   manera mejor de hacerlo, no olvidemos que el Gran Maestro está en Velneo, y nos podría iluminar.

 

Saludos.

   Miguel.

8

El problema es que para esto existen diversas soluciones, y dependerá de cada caso hacerlo de una u otra forma, pero por si os sirve de algo os explico como lo hicimos nosotros.

 

En la ficha de la entidad unicamente necesitamos un campo CUENTA_CONTABLE así que no tienen sentido herencias ni nada por el estilo, creamos el campo y listo. Además este campo no está enlazado con la contabilidad, si no que lo usamos por proceso cuando lo necesitamos.

 

Al mismo tiempo existe una tabla de cuentas contables que tampoco tiene por que estar enlazada con la de entidades, simplemente al dar de alta una entidad se crea por proceso la cuenta contable y se le pasan los datos.

 

Ahora tenemos los datos duplicados, pero realmente es la mejor opción, ya que la gestión y la contabilidad no tienen por que estar siempre en un programa, y además el uso que se le da a cada una de las tablas es totalmente independiente.

 

A todo esto, las entidades están en la base, pero existen dos proyectos a un nivel superior que son Gestión y Contabilidad. Ahora si desde la ficha de la entidad quiero mostrar un listado de asientos, solo tengo que crear un formulario con la rejilla en la caja de contabilidad y en la ficha de entidades lo inserto como punto de inserción.

 

Si necesito un listado de facturas hago lo mismo, un punto de inserción y le aplico el formulario correspondiente. La gran ventaja de este sistema es que si a un cliente no le meto la contabilidad, la pestaña en la ficha del cliente no aparece.

 

Espero que os sirva de orientación.

 

Un saludo

 

9

Me olvidaba, pero de esta forma tambien podemos conectar cajas que no están heredadas entre ellas, por ejemplo gestión y contabilidad.

 

Si desde un asiento quiero mostrar una pestaña con las facturas que están contabilizadas en ese asiento, creo un formulario en gestión con la rejilla de facturas, y creo un punto de inserción en la base. Ahora en la contabilidad puedo añadir la pestaña de facturas en un asiento.

 

Un saludo

 

10

Buen día.

Acaso no está debídamente documentado en la sección del manual correspondiente a herencia?.

Pregunto sin haber consultado dicha sección ni manual alguno, pero la lógica y el sentido común me dicen que ahí debe de estar la información requerida.

 

Saludos.

11

 

Respondo un poco tarde. Maldito virus del estómago... :-(

 

Estimado innovadb, estoy deacuerdo contigo con la solución que nos aportas para conseguir comunicar dos módulos que no se conocen directamente  entre ellos, usando tablas intermedias que están en una caja común inferior en la herencia, así como en usar la herencia para mostrar plurales, como los asientos y facturas de una ENTIDAD.

 

Pero mi duda no era esta. Creo que no he escogido un buen ejemplo con lo de la CUENTA CONTABLE de una ENTIDAD. Vuelvo al ejemplo inicial que puso Benito Lavandeira, ya que creo que es más gráfico y claro, y que resumiendo dice:

Supongamos que tenemos ya hecho un módulo BASE genérico, y que nos sirve para bastantes desarrollos. Pero llega un día que necesitamos desarrollar una aplicación con campos adicionales que no contempla, como por ejemplo la GESTION DE PADDLE.

 

¿Qué hacer en estos casos? Lo ideal a mi parecer sería dejar el módulo BASE tal y como está, y añadir todos esos campos extra en un nivel superior, en otra caja de datos (que podríamos llamar GESTION PADDLE). Entonces podemos crear una tabla histórica de ENTIDADES, con todos los campos adicionales (de hecho esto es lo que se ha hecho en vGESTION, con las tablas ENTIDADES y ENTIDADES DE GESTION). Hasta ahí todo correcto.

 

Mi problema se plantea en cómo montar los objetos visuales para mostrar toda la información de la ENTIDAD, de forma intuitiva para el usuario final, y incluyendo los nuevos campos que están en el módulo superior. La forma como lo hace vGESTION no me convence en absoluto, ya que ponen este registro histórico como una rejilla de plural, y en mi opinión no queda nada intuitivo el tener que crear manualmente otro registro adicional para cada ENTIDAD (la ENTIDAD DE GESTIÓN). Además esto puede llevar a pensar que se puede crear más de un registro relacionado para cada ENTIDAD, cuando a mi entender no puede ser así.

 

No encuentro la manera para hacer que toda la información de la ENTIDAD quede más integrada, y evitar recurrir a lo que se ha hecho en vGESTIÓN. He probado de todo, pero no consigo nada. No sé si es por mi falta de experiencia en Velneo, o porque no se puede hacer.

 

Muchas gracias y un saludo.

Xavi

__________________________________________________________

"La mala noticia es que el tiempo vuela. La buena, que tú eres el piloto."

Cashback (2006)

12

 

Estimado Gregorio:

 

La información sobre V7 que hay en la web (siempre bajo mi opinión personal) y como iniciado que soy desde hace poco a la herramienta, es un buena referencia técnica para consulta rápida de dudas (como una ayuda de las de toda la vida), pero no se puede considerar como material didáctico en muchos aspectos avanzados. Esta y muchas otras cuestiones, sobretodo para la gente que no conoce ya la v6, no se encuentran en el manual.

 

Por eso la importancia de este foro y la inestimable ayuda de todos nuestros compañeros. :-)

 

Un saludo.

Xavi

__________________________________________________________

"La mala noticia es que el tiempo vuela. La buena, que tú eres el piloto."

Cashback (2006)

13

Xavi:

Comprendo perfectamente el sentido de tus dudas. Es lo primero que pensé cuando vi la solución que aportaba vGestion.

No se como se pueda resolver; aunque en otra herramienta que utilicé en el pasado (synon2, ya obsoleta) existía el concepto de extended by. Es decir establecer una relacion 1 a 1 entre dos tablas que compartían el mismo código.

De esa forma se resolvía el añadir campos a una tabla base, físicamente eran dos tablas, pero lógicamente acuaban como una sola; tanto a efectos de diseño de interface como de visibilidad de campos a la hora de programar.

Por lo que he podido leer, este concepto no existe, ni ninguno que se le parezca. El de herencia inversa está genial para representar plurales "futuros" en una tabla base, pero quizás haría falta representar los campos de un "futuro registro" en un formulario base.

Quizás no haya visto la solución y la haya. Seguro que si la hay, aparecerá bajos estas líneas. Esta es la grandeza de esta comunidad.

14

Me temo que no se puede hacer tal como lo quieres, el problema es que no existe la herencia inversa entre tablas, pero se puede intentar simularlo.

 

En principio creo que tendriamos que incluir la tabla de paddle en la misma caja base, para poder dar de alta automaticamente un registro en ella cuando demos de alta una entidad, piensa que si la caja de paddle está a un nivel superior, la caja base no tiene acceso a ella para poder dar el alta. (Por lo menos a dia de hoy).

 

Ahora ya podemos simular el comportamiento deseado incluyendo una pestaña en la ficha de la entidad que muestra un formulario de la ficha de paddle, pero aún así necesitaremos un boton para poder editarla.

 

Por otra parte yo no adoptaría esta solución, si el nucleo tiene que ser compatible con la aplicación de paddle, yo añadiria directamente los campos necesarios en la tabla de entidades, y dependiendo del uso, los mostraria o no. Incluso si fuese necesario optaría por mantener 2 nucleos distintos, siempre y cuando las diferencias entre ellos fuesen lo suficientemente grandes.

 

Lo cierto es que aunque la versatilidad de la herencia es impresionante, no puede solucionar todas las situaciones.

 

Un saludo

15

de acuerdo xavipv...estaba pensando en voz alta.... seguiremos aguardando las mejoras. Saludos.

16

 

Muchas gracias innovadb y tcvsi, me habéis ayudado mucho con vuestros puntos de vista.

 

Bueno, de momento lo haremos igual a como se hacía con la v6, teniendo si hace falta varias versiones del módulo BASE. A ver si en un futuro Velneo nos sorprende aún más con nuevas funcionalidades para la herencia y la herencia inversa, ya que creo que es o puede llegar a ser uno de los pilares fundamentales de la V7.

 

Un saludo y grácias!

Xavi

__________________________________________________________

"La mala noticia es que el tiempo vuela. La buena, que tú eres el piloto."

Cashback (2006)

17

Que tal amigos,

 

Creo que he dado con la solución para este asunto o almenos una buena idea para que sea extendida por ustedes,

aqui la explicacion:

 

http://velnex.wordpress.com/2010/01/22/velneo-v7-herencia-y-maestros-distribuidos-en-v7/#more-435

espero que les sea útil

saludos,

18

Excelente idea y muy bien explicada, gracias por este aporte.

Aunque como muy bien indicas, esperemos que en un futuro quede todo incorporado de forma automática a V7.

 

19

 

Muchas gracias Cristianvg, funciona de maravilla!!

 

Tan solo un detalle. En el segundo proceso (el de modificación), el último comando no tendría que ser Modificar ficha seleccionada con formulario?

 

@tcvsi, ojala en futuras versiones nos den algo más automatizado para implementar esto de los datos distribuidos. El estar creando tantos procesos y eventos para lograr ciertos comportamientos me hace sentir como si no estuviera aprovechando el paradigma de lo que es Velneo: máxima senzillez y rapidez para hacer las cosas. ;-)

 

Un saludo.

Xavi

__________________________________________________________

"La mala noticia es que el tiempo vuela. La buena, que tú eres el piloto."

Cashback (2006)

20

Para responder la pregunta Mgalvez, encontre la forma incluirle el boton atras para el alta, para la modificacion es la misma filosofia pero no lo he hecho.

Creo con esto queda mas completa la forma de crear maestros distribuidos.

 

Saludos,

[attachment=7856,779]