Tema: SUM y JOIN
Ver Mensaje Individual
  #10 (permalink)  
Antiguo 15/11/2009, 07:42
Avatar de gnzsoloyo
gnzsoloyo
Moderador criollo
 
Fecha de Ingreso: noviembre-2007
Ubicación: Actualmente en Buenos Aires (el enemigo ancestral)
Mensajes: 23.324
Antigüedad: 17 años, 2 meses
Puntos: 2658
Respuesta: SUM y JOIN

Cita:
Necesito que cada venta se realice de forma individual, para cancelarlos llegado el momento.
LA cuestion de hacerlo asi, es que la aplicaicon esta enfocado a usar en una tienda, y se hacen muy rapido. La entrada de daos es por un lector. Cada venta se registra con un insert, y si se cancela la venta, se actualiza con cantidad y precio 0, ademas de crear otro registro de la cancelacion de la venta.
He usado un sistema parecido a la filosofia que se usa en contabilidad, todas las acciones estan registradas y no se borra nada, solo se anula con otro registro.
Bueno, ahora es un poco más claro de dónde vienen algunos detalles poco convencionales. En definitiva ha sido por la diferencia entre la visión de usuario, experimentado en contabilidad, más cercano a la programación, y la visión de los DBA que se orienta a un paradigma diferente.

En esencia, el funcionamiento de un sistema de ventas como el que describes requiere como mínimo de cuatro tablas, y puede que algunas más dependiendo de algunos detalles.

En ejemplo de cómo sería un diseño aplicable a facturación sería:


En ese contexto, cuando iniciaras una venta lo que se hace es dar de alta la venta en la tabla Factura, tras lo que recuperas el ID. Este ID se usa como parte del insert de los diferentes items de venta, todos los cuales llevan el ID del producto, que en tu caso debería ser el código leído por el lector de barras.
El cierre de la venta y la cancelación de la cuenta se producen entonces con el ingreso del Cobro, que refiere por FK a la factura. La cancelación de un ítem o la cancelación de la misma factura, puede bien seguir la misma lógica que tu planteas.
Obviamente, este modelo requiere la existencia de clientes ya dados de alta, pero eso mismo se podría resolver usando tanto los medios de pago (tarjetas, por ejemplo), como alta directa. El problema sería resolver la asignación de la venta si las facturas no llevan ID de cliente, caso en el que se podría pensar en un cliente anónimo, con un ID específico.

Para poder un realizar un modelo más cercano a lo que tu usas debería conocer cuáles son las reglas del negocio que aplicas para el ingreso de clientes...

¿Se entiende la idea?
__________________
¿A quién le enseñan sus aciertos?, si yo aprendo de mis errores constantemente...
"El problema es la interfase silla-teclado." (Gillermo Luque)