Access - Consulta SQL varias tablas

Hola a todos, llevo acudiendo a este foro un tiempo y es genial, gracias a todos los que ayudais ;)


Estoy haciendo una bdd de ventas de articulos, y quiero hacer un formulario desde el cual el usuario pueda seleccionar un producto en stock (tabla articulos) y todos los demás datos de venta relativos a las otras tablas.

Estas son las relaciones de mis tablas....ciertamente esto de las relaciones es complicado se agradecen consejos...




Al crear la consulta SQL para dar origen de datos al formulario no fuí capaz de hacerlo directamente así que procedí a crear 2 consultas y combinarlas posteriormente, aqui las pongo:


Hasta ahí consigo unir las tablas en una consulta como quiero, el problema es que en el formulario no me permite editar/ingresar/borrar datos, tal vez debería hacerlas anidadas en lugar de por separado? estoy bastante perdido agradezco cualquier ayuda.


Saludos

Por una parte hay un transacion (puede ser una compra, una venta o un prestamo) ==> la tabla ventas

Por otra parte esa transacion tiene detalles o desglose ==> la tabla artículos_venta (yo la denominaría 'venta_detalles')

Adicionalmente hay una tabla artículos (que será común a entradas y salidas) que se relaciona con la de detalles de venta
Finalmente otra tabla (clientes) que se asocia con la de ventas.

¿Qué problema hay en crear un formulario para ventas y dentro de el un subformulario para sus detalles?.

Un combo selecciona al cliente y guarda su ID en la de ventas, en base al ID seleccionado o adjudicado a la venta, se muestran los campos de la tabla clientes que nos interesen (si al cliente se le selecciona mediante un COMBO, los detalles pueden venir de las columnas de ese mismo combo que 'normalmente' están ocultas o semi-ocultas)

En la de detalles de la venta se seleccionaría al articulo, se 'guarda' su ID en la detalles de la venta y en base a el (el ID), se muestran los campos que se necesiten (y reincido en lo de 'muestran' porque en teoría no debería ser posible manipularlos, solo visualizarlos, solo se modificaría 'cual' mediante su ID y 'cuantos' en el campo unidades).

Muchas gracias Enrique funciona perfectamente, no tenía muy claro como funcionaban los subformularios pero veo que es mucho mas simple de lo que estaba pensando. Lo único que me dió problemas era una integridad referencial que eliminé.

Gracias otra vez y saludos !!!

No se que relación ha sido eliminada, en principio que exista una relación de integridad entre las tablas (en ese diseño) es correcta, solo implicaría que en casos concretos (por ejemplo: una venta a un cliente 'que aun no existe como tal') implicaría la creación del cliente en tiempo de ejecución (bien sencillo por otra parte utilizando un formulario abierto en forma modal) y así con el resto.

En principio se da por supuesto que se inicia con la nueva venta y después se continua con los detalles de la venta, una relación de integridad entre ambas tablas seria escrupulosamente respetada y generada al cambiarse entre el formulario principal y el subformulario (en ese momento se grabarían los datos del principal y el nuevo registro podría asociar 'sus detalles').

Quedaría lo de intentar vender un producto que aun no recibió el alta en la tabla artículos, pero .... ¿eso no se debería hacer 'antes', al recibir la mercancía del proveedor? y aun en casos como ese se puede dar el mismo trato que se le dio al crear el nuevo cliente 'en tiempo de ejecución'.

Pues en principio la integridad referencial eliminada es la de esta relación:




El formulario principal toma los datos de:


Y el subformulario se basa en un formulario de la tabla de ventas vinculado por el Id_Venta.


PD: Perdón por no usar tu nomenclatura de "detalles" pero en realidad para mi los detalles estan en la tabla de ventas.... no en la de Articulos_Ventas y me lio un poco jeje

No cai en la cuenta de que en la tabla 'artículos_ventas' (respetando la nomenclatura original) el campo ID_Venta forma parte de la llave, esto es incorrecto, cuando se crea una doble llave como índice principal, requerira que la combinación de ambos defina a un registro único y dado que 'el segundo campo' (Id_Articulo) no existe en la tabla VENTAS, esa relación no se puede crear, pero 'eso mismo y por la misma causa' deberia ocurrir en su 'relaccion' con la tabla artículos.

En las relaciones de uno a varios (1==>N) solo exigen que la llave de 'la parte uno' este indexada como único y sin repeticiones, y 'la llave al completo' ha de conformar la relación.

Si se utiliza 'solo una parte' tendríamos que la conjunción de ID_Articulo <==> ID_Venta permite tanto la repetición de artículos como la de ventas, pero solo un binomio id_venta/Id_articulo, pero por separado habrá muchas ventas repetidas y muchos artículos repetidos (no se cumple lo de 1==>N al repetirse la parte 1 en las relaciones con otros conjuntos de datos).

Lo correcto seria 'quitarle la propiedad de llave' y para evitar la repetición del binomio crear un índice que exija esa 'unicidad' (los índices se crean cambian, modifican con el 'icono con el rayo' que aparece con la tabla en vista diseño).

De esa forma se tendría:
.- una relación (1 ==> N) entre ventas(1) y artículos_venta (N)
.- una relación (1 ==> N) entre artículos (1) y artículos _venta (N)
.- un índice compuesto de ID_art + Id_venta que evitaría que a la misma venta se le asignase dos veces (o mas) el mismo articulo.

Buff gracias Enrique, se me estan atragantando un poco las relaciones llegados a este punto....creo entenderte todo a excepción un poco de la creacion de indices que no los conocía, entiendo que es esta ventana pero no se muy bien que poner:



Y sobre las relaciones así quedan si te entendí bien



Pero creo que sigue mal, tengo articulos que tienen 1 o más unidades en stock, cuando realizo una venta de un articulo con una sola unidad no hay porblema, pero cuando tengo que hacer varias ventas separadas de un mismo articulo?, no puedo, nose si el problema aqui son las relaciones o la forma en que creé el formulario de ventas (la consulta sql esta arriba)

Ahora mismo estoy bastante satisfecho con el formulario y su subformulario que me dió bastante trabajo al desconocer vba, este sería el modelo que tengo, en el que el usuario:


1 - Busca un articulo por su Id_Art y se le cargan los datos de PVP, Catálogo, Uds_Stock etc
2 - Introduce los datos relativos a la venta
3 - Busca un cliente en el cuadro combinado y se cargan sus datos (o introduce un nuevo cliente pulsando su icono)
4 - Pulsa el boton de guardar y se resta las unidades vendidas de las Uds_Stock



Espero poder solucionar este pequeño lio con un poco de ayuda...GRACIAS

En esa ventana que muestras.....
Nombre del índice: Uno que diga algo
.- el nombre englobara a todos los campos de la segunda columna
.- un nuevo nombre indicara el comienzo de otro índice

En la muestra hay DOS índices con un campo cada uno (suelen 'auto-crearse' si se indexa un campo)

En la parte inferior:
Principal : si es la llave
Unica : si se puede repetir ese subconjunto (en este caso debería ser un SI para que no admita repeticiones)
Omitir nulos : a voluntad según se necesite

En la ventana de relaciones .... yo exigiría integridad referencial y actualización en cascada.

No se en que parte intervienen las unidades vendidas, una cosa es que exista producto y otra que se pueda vender una o cien unidades (a un mismo cliente o a varios).

El computo del Stock se puede llevar de diferentes formas, por ejemplo:
En base a la tabla Articulos_ventas:
Una suma de las unidades del mismo ID:
DSum("Uds_Venta", "Articulos_ventas","Id_Art = " & [aquí el id a consultar])

Nos daría el total de unidades vendidas (no importa a quien)
Si se hace lo mismo con la (siempre supuesta) tabla de compras, la diferencia entre ambas será el Stock real en el momento del calculo.

Si se desea 'anotar' en el campo Uds_Stock de la tabla Articulos las existencias en tiempo de ejecución, se tendrá que ser bastante exquisito en el trato de los datos (por ejemplo: modificaciones de la cantidad en tiempo de ejecución)

El tratamiento del almacén tiene que ser el adecuado al tipo de producto y empresa, no es lo mismo el de una tienda de ultramarinos (comestibles) que el de un Kiosco de revistas o de venta de lavadoras, el primero tiene perdidas causadas por los consumibles perecederos, el segundo suele tener un concierto para retrotraer mercancía no vendida (por ejemplo la prensa diaria) y el tercero ... a lo sumo por desfase de los modelos.

Te aconsejaría que finalizases etapas (eso si sin perder de vista la globalidad del conjunto), porque asumo que el proyecto tiene algo mas que estética (estética: algo que se debería consolidar en la etapa final, antes ... pueden sobrar/faltar cosas)

Gracias Enrique como me recomendaste dejé de un lado la "estetica" y revisé desde el principio las tablas y sus relaciones y me centré en eso hasta que "aparentemente" todo funcionaba como quería sin formularios, ahora estoy haciendo los ultimos retoques a los formularios etc "estética".

Finalmente estas son las tablas y sus relaciones, mas coherentes:




Ah ! y gracias por la idea de calcular el stock en función de la diferencia entre ventas y compras, es lo mas lógico ;)

Saludos !