Programa de ventas

[HombreGordo]

Bueno, ya hace ya algún tiempo hice un programa de ventas, mira como funciona:

• Agregar registros es agregar asientos a la tabla.
• Unas multiplicaciones por ahí (por ejemplo: Cantidad por precio unitario).
• Sumar la columna de los totales.
• Imprimir por el Rave Reports.

No puedo enseñarte el código hecho porque es un trabajo privado, y esto que te dije puede ser fácilmente adivinado solo mirando el programa por encimita, pero si buscas todos los hilos que he hecho en este foro, puedes darte cuenta que todos giran alrededor del proyecto. Y sin mucha explicación te guiarás a la perfección, son unos hilos muy completos. Saludos a todos y gracias a quiénes me han ayudado a lo largo de mi vida en este foro.

[DJerez]

Epenor:
Si te interesa una guia de novato respecto a lo que querés hacer te recomiendo que aunque o tengas tiempo, te des una mirada a otros post referidos a cada aspecto que va a tener el programa.

Hace un tiempito me sucedió lo mismo, Delphius me dió una guía junto con Caral (Naty???) si bien terminé un poco excedido de tiempo el trabajo, me di cuenta que si sos un poco ordenado ni siquiera es necesario bajarte nada desde el FTP.

Si te interesa te puedo pasar parte de lo que terminé haciendo en Delphi7, es un control de stock y ventas. Quizás te sirva de guía. [email protected] Correo+MSN.

Abrazo a todos.

PD: Espero no moleste mi comment al resto de la gente.

[epenor]

Gracias a todos por sus sugerencias y consejos, he estado corto de tiempo y no he podido hacer casi nada con el proyecto, por eso hacia dias que no escribia. Desde mañana comenzaré a trabajar y plantear mis dudas.

Saludos a todos.

[epenor]

Aqui les traigo el diseño de la base de datos, quisiera saber su opinion al respecto.

[[Delphius]]

Hola epenor,
Por lo que veo del diseño está bien, aunque hay algunas cositas que deberías tener en cuenta. Vamos por lo más fácil primero.

¿Que debemos entender por suplidores? ¿Al proveedor de dichos artículos? O al encargado de reponer dichos artículos en las góndolas?

Bueno esto te lo pregunto, ya que esto te hará comprender mejor tu modelo del negocio.

Ya sea quien se encarga de abastacer las góndolas o el proveedor deberías tener muy en cuenta la relación. ¿Se trata de una relación 1-M? ¿Puede darse el caso en que un artículo sea repuesto o proporcionado por más de un suplidor/proveedor?

Segunda cuestión: si bien se trata de ventas... debe llevarse registros del stock. No veo en tu diseño que se lleve a cabo.

tercera cuestión, la más importante: ¿El precio que figura allí en la tabla artículos es el de compra o el de venta? ¿Nunca va a variar?
Noto allí un problema un tantito molesto. Tanto el precio de compra como de venta puede variar de un día a otro. Si nos basamos en tu diseño, ante cualquier modificación del valor perderíamos el valor anterior. Cualquier reporte o consulta sobre los "movimientos" de los precios no funcionaría.
Es necesario llevar este histórico.
De igual forma, sucede con el valor de los impuestos.... ¡pueden variar!

No se que tan exquisito deba ser tu sistema. Como ya te hemos indicado, puede ser algo básico... como también podría ser lo bastante completo y complejo. Necesariamente para opinar más sobre el tema deberíamos ponernos en tus zapatos y conocer los límites de tu sistema.
Al tratarse de un trabajo para la universidad tal vez sea básico, pero palabras como complejo, básico, fácil, difícil tienen un valor bastante subjetivo.

Una gran verdad es que hay muchas maneras de diseñar una base de datos... Cada uno puede tener una mirada distinta sobre la misma realidad. En ocasiones un diseño puede afectar el modo en como llevar a cabo la el diseño del sistema, y a la inversa... la manera en como se diseñe al sistema puede afectar a la manera en como se diseñe la base de datos.
¿Porqué te digo esto? Porque algunas cosas resultan más fácil para uno hacerlas a nivel de base de datos, y otras a nivel de sistema. Debes buscar el equilibrio entre tu experiencia y tus falencias para conseguir diseñar tanto la base de datos como al sistema.

Saludos,

[epenor]

Hola Delphius, dado que mi sistema es algo básico y para la universidad, lo que significa que no será un sistema para poner en producción, no tengo planeado llevar registro de la variacion de los precios. El precio que aparece en la tabla de articulos es el precio de venta (no almaceno precio de costo de los articulos). El stock lo pienso manejar con el campo "minino" de la tabla de articulos, así cuando queden por ejemplo 100 unidades de X articulo, mandaré un aviso de que se está acabando ese articulo.

Con respecto a los suplidores, en mi caso es lo mismo que proveedores.

Como puedes notar, esa base de datos es para algo realmente basico, solo para ventas al contado. Si estoy pensando cómo establecer privilegios a los usuarios, de manera que pueda tener 3 nives: vendedodes comunes que sólo facturen y consulten, vendedores avanzados que puedan adicionar articulos, o modificar algunas cosas y el administrador. (esto es un requisito del profesor)

Un saludo.

[[Delphius]]

Entiendo,
Entonces a mi modo de ver, está bien. No veo algo raro.

Nomás te aviso que lo que tu digas no siempre es lo que el profe dice y/o quiere. Por las dudas, habla con él y analiza apropiadamente los límites del sistema.
Si dices que es básico, y que dice que te vas a encargar de ventas... entonces es posible que esa tabla suplidores (no me agrada mucho el nombre, sería apropiado llamarla proveedores) esté demás. No veo que de utilidad tiene relacionar los artículos con los proveedores si no hay alguna función establecida.

Cuentas de que cuando llega a x cantidad mínima el sistema avisa. ¿Tienes contemplado la posibilidad de que se cuente con los medios para la compra y adquisisión de más artículos? Si es así, allí si tendría sentido disponer de esa tabla de proveedores, y además podría ser necesario contar con las tablas compras y detale_compras para llevar el registro de compras.

Saludos,