Crear base de datos para un sistema de facturacion y ventas

[ebalmaceda]

Buenas noches, quiero crear un pequeño sistema que permita llevar las ventas realizadas en un comercio y permitir ver si el cliente tiene deudas y demas, pero no termino de decidir como. Tengo esto:

tabla_clientes
ID
nombre
apellido

tabla_ventas
ID
ID_cliente
fecha

tabla_ventas_detalle
ID_venta
ID_producto
cantidad

Bueno, la cosa seria que la tabla "ventas" guada la fecha y el ID de la venta y el cliente que compro y en la tabla "detalle" se relaciona el IDVenta con los productos vendidos en esa operacion.

Mi duda es, la siguiente:
Quiero tener la posibilidad que el cliente pague o que no lo pague y le quede la deuda.

Lo primero que se me ocurre es que se calcule la deuda del cliente mediante una sumatoria de la tabla_ventas y luego se anules con la tabla "pago_clientes", donde se guardarian los pagos que realiza el cliente.

Es esta la mejor opcion? Supongo que lo que planteo es un problema generico ya que hay miles de sistemas que permiten esto, pero no se como solucionarlo.

Gracias!!

[ebalmaceda]

Nadie che? Se ve que fue un lio mi explicacion. Abrazos.

[gnzsoloyo]

No. No es un lío, lo que sucede es que el tema no entusiasma, nada más.
De cuando en cuando aparece alguien, como en tu caso, buscando ayuda para resolver un modelo de datos del que se pueden encontrar decenas, y que no representa mayor desafío para diseñarlo. La idea de un sistema de facturación es algo tan habitual y usado, que se encuentra en todos los ejercicios básicos cuando cursas Base de Datos I en la facultad, o cuando haces un curso de programación en algún lenguaje.
En un ejemplo que ha venido a ocupar el lugar que antiguamente tenía el caso "hacer una agenda personal"...
¿Se entiende la idea?
Si por lo menos lo que nos dices tuviera algún tópico más interesante... Algo motivador, como por ejemplo que nos mostraras realmente un DER de lo que tienes desarrollado, tal vez.
Pero así, con tan poco, se siente como que buscaras reinventar la rueda. Sin pretender ofender.

Viendo tu problema de los pagos, lo único que puedo aclararte es que lo que debes analizar es el tipo de entidades que surgiría de los diferentes casos de pago. Esa es l la clave de tu solución.
¿A qué me refiero?
A que cuando empiezas a programar y se te plantea un sistema como este, es común que el programador piense: "bueno, viene el cliente y paga, entonces hay una entidad 'Pago'", y eso no es precisamente exacto, porque estás mirando sólo un único escenario, y no todos.
Por supuesto que reconocer muchos de esos escenarios requiere experiencia, así que por empezar yo te sugeriría que tomes una hoja de papel y escribas uno a uno los casos de pago que en tu sistema se pueden presentar, y recién allí te pongas a ver cómo se puede reconocer y documentar cada caso, de tal modo que la oepración completa se pueda reconstruir...
¿Una ayuda?
Un pago de una compra puede ser:
- Pagado en efectivo.
- Pagado con tarjeta de crédito.
- Pagado con tarjeta de débito.
- Pagado con formas combinadas.
- Pagado parcialmente.
- Imputado a notas de crédito.
- Imputado a cheques.
- Imputado a cuentas corrientes.
- Imputado a una cuenta corriente dependiente de otra cuenta mayor.
- Tener responsable de pago diferente al titular del la compra.
- Imputado a canje por deuda sin nota de crédito.
- Cubierta por pago realizado a facturas anuladas.
- Facturado por cambio de producto.
- otros casos que no se me ocurren en este momento... (si, pueden existir más).

Y a todo esto no estoy considerando políticas comerciales del negocio, gestión de clientes, descuentos, promociones, impuestos aplicables, etc. Todo lo cual debes tener muy en cuenta al momento de diseñar un sistema de facturación.

De todos modos, volviendo a tu pregunta, el tema de los pagos parciales tiene que ser resuelto en función de los tipos de pago realizables en el sistema, y la forma de documentar los pagos.
Define esas cosas y podrás avanzar.

[ebalmaceda]

Muchas gracias por tu explicacion, fue genial realmente y agradesco el esfuerzo.