Programa de ventas

[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,

[epenor]

Bueno, cambiaré el nombre por proveedores se escucha mejor. Tengo la tabla articulos y proveedores relacionada porque pieson sacar algun reporte articulos por proveedores.

No tengo contemplado generar ordenes de compra porque entonces se me hará mas extenso el asunto, solamente necesito el modulo de facturacion. El aviso del stock minimo es simplemente una alerta para que no se agote un articulo súbitamente. Aun no estaria mal la parte de manejar las compras de manera básica, asi podría hasta adicionar automaticamente los articulos de la orden.