Consulta con diseño de BD

[Petolansa]

Buenas gente, mi consulta es la siguiente, estoy diseñando las tablas de un sistemita de gestion para una optica, la cual uno de los modulos es la facturacion de ventas.
Al observar otros diseños de BD noto que al momento de diseñar la tabla de ventas siempre se realiza otra de movimientos de ventas, o sea que en la de tabla ventas se asienta todos los datos de la venta en general, y en la otra de movimientos, se asientan todos los detalles de la venta, o sea todas las lineas de los articulos que se venden, los precios unitarios de cada uno de los productos con sus codigos etc.
Mi pregunta es la siguiente, esta es la manera correcta de diseñar el modulo de ventas, o sea con una tabla para los detalles y otra para asentar el total de la venta. Por favor agradeceria alguna guia de como diseñar BD, pero por lo pronto me gustaria saber si esto es asi, y porque motivo se diseña de esta forma.


Desde ya muchas gracias

agradecido de antemano.

[[Delphius]]

Hola Petolansa,
El modelo relacional trabaja así. Y si, asi es la manera en que se debe hacer.

Todo se resume en base al paradigma en el que se apoya el modelo relacional. Recuerda que lo que dice el paradigma que todo se resume en operaciones elmentales, que permiten "reconstruir" un objeto representativo de la realidad.

Veamoslo con un ejemplo. Una venta no existe, no la vemos caminando. Pero a pesar de ser un elemento abstracto a los fines del problema, es un elemento a representar. En la jerga: pertenece al dominio.
Ahora bien, una venta estará compuesta por uno o más artículos. Sabemos que como mínimo podemos vender uno. Si vemos a la venta como una sola "cosa" no hay manera de saber otras representaciones que le pertenecen al mismo dominio.
Si decimos que venta es la sucesión o la lista o detalles de por lo menos un artículo. Descubrimos otra porción del problema y otra entidad de la realidad: los artículos. Y bajamos a otros niveles de abstracción.

Ahora, lo que sabemos es que el modelo relacional "parte" o disgrega a una o varias entidades en porciones más atómicas. Gracias a la relaciones que se construyen por la identidad referencial o manejos de claves primarias y foráneas, junto con las operaciones: left, join, union y demás. Conseguimos unir aquellas partes para reconstruir aquel elemento que estamos representando.

No se si me explico. La cantidad de niveles con que contará tu base de datos seguirá el mismo nivel de profundidad que tenga en análisis del problema. Tus tablas se armarán de acuerdo a lo que DESES (mejor dicho DEBES) registrar.

Si tienes más dudas, avisame.
Y perdona si lo que dije suena un poco "académico". Me cuesta un poco encontrar algunas palabras sencillas para explicarte.
Hazme saber si no se entiende... voy a hacer un mayor esfuerzo para la próxima.

[Petolansa]

Gracias Delphius y si se entiende, y quedo claro lo de la tabla de detalles y luego la de ventas, lo que me queda sin entender, es lo siguiente, en que momento se hacen los calculos para pasar los datos de la tabla de detalles a ventas, ej en que momento se calculan importes y stock, desde ya muchas gracias y espero no preguntar tanto.

[ContraVeneno]

Aca los calculamos cuando se cierra la venta...

Vamos, que manejamos diferentes etapas.

Cuando inicia la venta, se crea un folio para ser procesado, este folio puede tener su registro maestro (Código del cliente, fecha, quien lo atiende, demás datos generales) pero podría no contener detalles (el cliente todavía no se decide que quiere).

En esta etapa puedes agregar o quitar tantos artículos quieras, haciendo los cálculos de totales correspondientes de manera temporal.

Cuando el cliente por fin se decide que es lo quiere y esta listo para pagar. En ese momento se guarda toda la información y se hace el cálculo final de totales y se guardan en la base de datos. En fin, que el folio en proceso, paaa a ser folio cerrado. Se genera el ticket o recibo y no se pueden hacer más cambios.

Si fuera necesario, se podría generar una factura con esa información, lo cuál cambia el estatus de el folio a facturado.

Considera tambien cancelaciones, devoluciones (o notas de crédito) y/o devoluciones parciales.

Pero en fin, para contestar tu pregunta, los cálculos de totales, se van haciendo según se agreguen artículos en el detalle, pero no se guardan como datos finales.

Cuando se cambia de "proceso" a "cerrado", en ese momento hacemos los cálculos de totales y guardamos la información definitiva.


la facturación, cancelación o devolución, se hacen en base a un folio cerrado, un folio en proceso es libre de moverse cuantas veces quiera.

Así que, como te podrás dar cuenta, para nosotros es muy importante llevar un control muy estricto a la hora de manejar el estatus de los movimientos.

[sinalocarlos]

A fin de darle otra vuelta al tornillo, me permito entrometerme, no sin antes pedir las debidas disculpas por ello

en mi caso no calculo los totales a fin e evitar inconsistencia de datos, es decir calculo totales solo en reportes, en realidad a nivel cabecera, por llamarlo de algún modo, nunca guardo totales de los detalles, ahora que leo lo anterior me pregunto en realidad es necesario guardarlos?, si el numero de veces que consulto por dichos totales es reducido no es mejor calcularlos "on the fly"? que se me esta pasando??


saludos

[Petolansa]

Gracias por su ayuda gente, y a medida que aumentan las respuestas voy entendiendo cada vez mas, y siento que toy mas cerca de cerrar los diseños de las tablas de una vez.
Por lo que me respondes, tengo entenddio que se puede hacer todo temnporalmente hasta finalizar la centa y asentar los datos definitivos de una vez.
Mi incertidumbre es la siguiente.

yo tenia pensado crear las siguientes tablas

VENTAS
nrofac - nro de factura
fecfac - fecha de factura
horfac - hora de factura
tipfac - tipo de factura
etc

y asi sucesivamente detalles y bajo esta tabla guardar el importe final, y en esta otra tabla que detallo a continuacion tenia pensado los siguientes campos

VENTASMOV
numcfac - numero de factura
dfecmov - fecha del movimiento
ccodpro - codigo del producto
prepro - precio producto

donde los campos en un futuro aparecerian de la siguiente manera

VENTAS
nrofac fecfac horfac tipfac impfac
00001 08/08/2007 13:30 A 123,00


VENTASMOV
numfac dfecmov ccodpro prepro
00001 08/08/2007 123 100,00
00001 08/08/2007 345 23,00


Quisiera que opinen si esto estaria bien, la funcion de la tabla ventas mov es para llevar el control de stock y precios de la venta por linea y la de ventas guardaria el precio del total sin detalles del producto. Esto es correcto?

Desde ya muchas gracias, agradecido de antemano

[Casimiro Notevi]

Empezado por Petolansa

[..] Por lo que me respondes, tengo entenddio que se puede hacer todo temnporalmente hasta finalizar la centa y asentar los datos definitivos de una vez. [..]

Eso depende de las necesidades de cada uno, en mi caso, mis clientes quieren todo en tiempo real, si en un tpv están vendiendo un tornillo, los demás tpvs deben ver la cantidad que quedan, exactamente, en ese momento. Y no esperar a que termine de procesar la venta completa para actualizar el stock.
Como bien te han comentado los compañeros, todo depende de cada caso.

[[Delphius]]

Petolansa, Como podrás ver... parte de lo tratado aqui como en otros hilos se ha perdido debido a una falla que hubo.

No se si abrás leído las respuestas y recomendaciones que se te fueron dando. Si no has leído dichas respuestas, hazlo saber para que nuevamente tratemos el tema y podamos evacuarte las dudas.

Exitos con tu diseño.
Saludos,

EDITO:Recuerdo que una parte de lo dicho aquí lo tenía copiado a mi disco. Recuerdo que expuse esto:

Gracias Delphius y si se entiende, y quedo claro lo de la tabla de detalles y luego la de ventas, lo que me queda sin entender, es lo siguiente, en que momento se hacen los calculos para pasar los datos de la tabla de detalles a ventas, ej en que momento se calculan importes y stock, desde ya muchas gracias y espero no preguntar tanto.

Me alegro que me entiendas.
No tengas miedo de preguntar... aqui estamos para ayudarnos.

¿Cuando calcular? Como te dije antes: todo dependerá del estudio y análisis del dominio.
En la forma práctica, se resume así:
1. Se arma un nuevo registro Maestro o cabecera (o como prefieras llamarle).
2. Por cada registro Esclavo, o detalle (o como prefieras):
2.1. Calcular el subtotal: Cantidad x Precio del artículo.
2.1.1. "Pedir" o extraer: de la tabla Artículos (o de donde corresponda) lo necesario: ID, Descripción y Precio.
2.2.2. Reducir en dicha Cantidad el stock:
2.2.2.1. Actualizar el stock de dicho Artículo en la tabla stock, o movimiento de estock.... todo dependerá de como se lleva.
2.2.2.2. Ingresar en la tabla "Pedidos" si la cantidad de stock cae en el límite del stock mínimo. Si es que se manejan los pedidos... y si el análisis corresponde...

Ahora, esta manera de trabajar se puede conseguir de miles de manera: con procedimientos almacenados, tiggers, etc... Y bajo diferentes paradigmas o enfoques: POO, lo clásico: estructural...

Esta es una manera... como te dije, todo dependerá de tu problema de tu análisis. Te recomiendo, si es que no lo estás realizado, de que lleves un buen esquema visual del problema: Parte de unos Casos de Usos... son buenos para detectar estos tipos de cosas.

Si puedes dar más detalles de como estás llevando el trabajo te podemos ser de mayor ayuda.