Velneo - Criterio a seguir

 
Vista:
Imágen de perfil de G.Asensio
Val: 3
Ha mantenido su posición en Velneo (en relación al último mes)
Gráfica de Velneo

Criterio a seguir

Publicado por G.Asensio (49 intervenciones) el 07/09/2005 10:19:44
Queria lanzar una consulta al foro. No es una consulta técnica y puntual, mas bien es un consejo sobre el criterio a seguir.

L
Valora esta pregunta
Me gusta: Está pregunta es útil y esta claraNo me gusta: Está pregunta no esta clara o no es útil
0
Responder
Imágen de perfil de G.Asensio
Val: 3
Ha mantenido su posición en Velneo (en relación al último mes)
Gráfica de Velneo

RE:Criterio a seguir

Publicado por G.Asensio (49 intervenciones) el 07/09/2005 10:46:29
Quisiera lanzar una consulta al foro. No es una consulta técnica y puntual, mas bien es un consejo sobre el criterio a seguir.

Llevo poco tiempo con Velazquez y despues de unos pocos "experimentos", me he decidido a realizar una aplicación de Gestón Comercial Generica. Tengo algunas dudas de como afrontar dicha apliación, estas son algunas de ellas:

-En cuanto a los Clientes y Proveedores, quisiera saber que es mas usual o mas conveniente o mas operativo y que pros y contras tendria, crear una tabla de "Clientes" y otra de "Proveedores", o por el contrario unificarlos en una única tabla donde un campo nos defina el tipo de registro que es (cliente o proveedor)

-Lo mismo, en cuanto a los albaranes de compra o venta, crear 2 tablas o unificarlos en una. Seria mejor unificarlos en una única tabla, para que entreenlazar datos de compras y ventas fuese mas sencillos?

-Por último se me ocurre que todos los documentos existentes (Pedidos de compra y venta, Albaranes de compra y venta, Movimientos manuales de almacen), podria estar en una única tabla, que en realizadad aglutine todos los movimientos realizados en el almacen por las diferentes vias.

En realidad quisiera saber que ventajas e inconvenientes me puedo encontrar mas adelante cuando la aplicación este mas avanzada, segun el funcionamiento de Velazquez. Si seria viable a 3 opciones o solo algunas de ellas y los mas importante, como los teneis resuelto vosotros.

Perdonad si me he extendido demasiado, pero para mi es importante conocer la opinión que puedan tener otros programadores de Velazquez mas experimentados que yo.

Un saludo al foro.
Valora esta respuesta
Me gusta: Está respuesta es útil y esta claraNo me gusta: Está respuesta no esta clara o no es útil
0
Comentar

RE:Criterio a seguir

Publicado por Jesús Morales (21 intervenciones) el 07/09/2005 20:00:04
Hola amigo... Bienvenido al mundillo del Velazquez... Bueno hace ya algún tiempo que no escribo en este foro... pero a ver si te puedo ayudar...

Como todos compartirán, o casi todos el principio básico de solucionar un problema de software es el siguiente "DIVIDE Y VENCERAS",,, siempre ha sido así... Las técnicas que describes de poner todos los clientes, proveedores, vendedores, etc... se utiliza antes cuando los discos duros eran pequeños y los era primordial ahorrar espacio pero hoy en día las cosas han cambiado muchos... yo cuando empezé en esto hace muchos años hacía una tabla llamada INDIVIDUOS donde ponian todos los registros de cualquier tipo de personas que llegaban, clientes proveedore vendedores amigos... etc... No era nada utíl pero ahorraba un poco de precioso espacio en el disco hoy en día esta técnica está practicamente obsoleta, luego te recomiendo que pongas una tabla para cada cosa... Si no lo haces tendrás un follón del carajo de indices que al final te puede hasta despistar...
Valora esta respuesta
Me gusta: Está respuesta es útil y esta claraNo me gusta: Está respuesta no esta clara o no es útil
0
Comentar

RE:Criterio a seguir

Publicado por velalogica (5 intervenciones) el 08/09/2005 00:46:41
Vamos por partes

Pregunta:
-En cuanto a los Clientes y Proveedores, quisiera saber que es mas usual o mas conveniente o mas operativo y que pros y contras tendria, crear una tabla de "Clientes" y otra de "Proveedores", o por el contrario unificarlos en una única tabla donde un campo nos defina el tipo de registro que es (cliente o proveedor)

Respuesta:
-En este caso, la tendencia general es unificar clientes y proveedores en una misma tabla, "entidades" (por ejemplo), con un par de campos booleanos para activar si es cliente, si es proveedor o si es ambos a la vez. En este último caso, si los separas en tablas diferentes vas a tener la información de una misma entidad duplicada, por un lado en la tabla clientes y por otro en la de proveedores.

La información ducplicada suele provocar problemas a la hora de actualizarla, al cambiar campos que haya en ambas tablas, como los números de teléfono, y es posible que el usuario acabe actualizando uno (la ficha del cliente) y otro no (la ficha de proveedor) y al final no se sepa qué dato es el bueno, qué teléfono es el bueno.

Y te voy a poner un ejemplo práctico para que lo veas más claro: Imagina que implantas la aplicación en una empresa de distribución que tiene como cliente a una imprenta. Si esta imprenta a la vez hace trabajos de papelería para la empresa de distribución ambos serán entre sí cliente y proveedor a la vez, y este tipo de caso es bastante común (comprar al que te compra).

Pregunta:
-Lo mismo, en cuanto a los albaranes de compra o venta, crear 2 tablas o unificarlos en una. Seria mejor unificarlos en una única tabla, para que entreenlazar datos de compras y ventas fuese mas sencillos?

Respuesta:
En este caso es mejor dos tablas separadas. Aquí no hay duplicidad de información, pues un mismo albarán o es de compra o es de venta. Nunca será ambos a la vez.

Aunque el hecho de unificarlos en una sola tabla pueda parecer inicialmente simplificar el esquema general de la aplicación (menos tablas), complica más el hecho de tener que condicionar en todo momento el comportamiento de la aplicación para diferenciar entre compras y ventas.

Pregunta:
-Por último se me ocurre que todos los documentos existentes (Pedidos de compra y venta, Albaranes de compra y venta, Movimientos manuales de almacen), podria estar en una única tabla, que en realizadad aglutine todos los movimientos realizados en el almacen por las diferentes vias.

Respuesta:
Lo más común es diferenciar en tablas diferentes los procesos de compra y venta (oferta-> pedido-> albarán-> factura). En el caso de la tabla de movimientos es mejor que sea única diferenciando en un campo el tipo de movimiento, es más fácil tanto para programar el control de existencias como para consultar luego la información (imagina consultar los movimientos de tu cuenta bancaria, por un lado las entradas y por otro las salidas). Las líneas de albarán de proveedor generan movimientos de tipo entrada y las líneas de albarán de cliente generan movimientos de salida. Además esto con Velázquez Visual es muy fácil y creo que hay algún tutorial al respecto (échales un vistazo).
Valora esta respuesta
Me gusta: Está respuesta es útil y esta claraNo me gusta: Está respuesta no esta clara o no es útil
0
Comentar
Imágen de perfil de G.Asensio
Val: 3
Ha mantenido su posición en Velneo (en relación al último mes)
Gráfica de Velneo

RE:Criterio a seguir

Publicado por G.Asensio (49 intervenciones) el 08/09/2005 18:53:21
Gracias por responder tan ràpida y detalládamente.

Estas cuestiones las he planteado, para adelantarme a los problemas que me puedan surgir con Velazquez. No tengo el dominio suficiente de la herramienta como para tener una perspectiva sobre la forma de operar con Velazquez en determinados procedimientos que tendre que solventar posteriormente (entradas-salidas de almacen, datos de compra-venta de un artículo, etc...)

-En cuanto a la primera pregunta (Clientes, Proveedores), veo que los dos diferis, con argumentos perfectamente válidos. Yo hasta el día de hoy siempre los he definido en tablas separadas y la verdad es que no creo que tenga mayor trascendencia hacerlo de una forma u otra.

-En cuanto a unificar los albaranes de compra y venta en una única tabla, yo con la herramienta con la que trabajo actualmente, lo tengo resuelto de las dos formas. Inicialmente separaba los albaranes de compra y venta, pero tenia que crear una tercera tabla extractos, donde por cada movimiento de entrada-salida, compra-venta, tenia que crear un registro, con el fin de tener todo el historial de movimientos en la tabla extractos. Es por esto que posteriormente unifique las lineas de albaranes (compra-venta), en una única tabla donde ya tenia todos los movimientos organizados evitandome de esta manera el crear otra tabla y tener que actualizarla. además a la hora de cotejar y mezclar datos estadísticos, de compra-venta de un artículo solo tengo que tirar de una única tabla.

Es concretamente este segundo punto (unificar albaranes), el que me interesaria saber vuestra opinión:
1. Si los separo, como controlais los movimientos de almacén?, creando y actualizando una tercera tabla?. En cuanto a los datos estadísticos de compras-ventas, como es posible en Velazquez cotejar dos tablas distintas (compras, ventas) sin usar temporales?. Como lo resolveis?

2. Por el contrario, seria factible y mas operativo unificarlos, segun el criterio que he planteado?.

Estos son mis dilemas, quiero dar pasos firmes y evitar equivocarme sin antes haber sondeado vuestras opiniones.

Un saludo.
Valora esta respuesta
Me gusta: Está respuesta es útil y esta claraNo me gusta: Está respuesta no esta clara o no es útil
0
Comentar

RE:Criterio a seguir

Publicado por velalogica (5 intervenciones) el 08/09/2005 20:29:59
Como sabes, en programación, como en muchas otras cosas en la vida, no hay verdades absolutas. Y como pasa en este caso es posible que encuentres dos (o más) soluciones totalmente opuestas para un mismo problema, y con argumentos convincentes para apoyarlas.

Por mi experiencia, yo clientes y proveedores las unificaría sin dudarlo por lo que comenté en el post anterior. En el caso de los albaranes ya podríamos estar discutiendo un mes entero y no llegar a ninguna conclusión.

Llegados a este punto conviene ser prácticos, ¿qué datos necesitas? ¿dónde pretendes implantar tus aplicaciones? ¿cuántos usuarios crees que vas a tener?

Planteate estas preguntas, y posiblemente llegues a alguna conclusión. Verifica qué resultados o estadísticas pretendes sacar y puede que te aclare algo más el esquema de tablas.

Por otro lado, la tabla de movimientos debería ser unica, y en esta tabla indicas el tipo de movimiento (entrada/salida/regularización...) y mediante un arrastrado (ver tutoriales) puedes llevar el saldo. Las tablas de líneas de albarán te deberían generar y actualizar los movimientos de entrada (compra) o salida (venta) de muchas maneras: a través de un proceso, tubo, evento de tabla, actualizaciones...

En cuanto a resultados, depende de qué estadísticas quieres, por artículo, por cliente, por almacén, por meses ... o combinados todos a la vez...
Valora esta respuesta
Me gusta: Está respuesta es útil y esta claraNo me gusta: Está respuesta no esta clara o no es útil
0
Comentar
Imágen de perfil de G.Asensio
Val: 3
Ha mantenido su posición en Velneo (en relación al último mes)
Gráfica de Velneo

RE:Criterio a seguir

Publicado por G.Asensio (49 intervenciones) el 13/09/2005 12:18:36
Gracias una vez mas por la respuesta;

Como bien dices, no existe un único criterio a seguir, si no que perfectamente se podria hacer de las dos formas mencionadas, yo concretamente tengo hechas aplicaciones con los dos formatos y me funcionan perfectamente. al unificar lineas de albarán en una tabla he conseguido evitar el tener que crear y actualizar la tabla de movimientos ya que en las lineas de albarán ya lo tengo todo clasificado por tipo de movimiento, con lo cual a la hora de sacar movimientos de almacen o datos estadisticos unificados de compra-venta (cuanto he vendido de lo que le he comprado a un proveedor...), lo extraigo de esta tabla. Simplemente me interesaba saber como lo resolveis normalmente con Velazquez.

En cuanto a las lineas de albarán, como las creais?, como tabla histórica o como submaestra de cabeceras de albarán?. En el manual comenta las 2 posibilidades. Cual seria la mas correcta y que ventajas tendría una u otra?.

Un saludo.
Valora esta respuesta
Me gusta: Está respuesta es útil y esta claraNo me gusta: Está respuesta no esta clara o no es útil
0
Comentar