Programa de ventas

[[Delphius]]

Empezado por epenor

Muy bien Delphi, me refiero a la funcion SysErrorMessageParam(ErrorCode: Integer; Param: string): string; del programa de facturacion de caral.

Segun he visto en el codigo esa funcion captura los errores que puede cometer la persona que opera el sistema y asi evita que la aplicacion "explote". Por ejemplo, si se deja algun Edit vacio que sea not null en la DB y se intenta guardarlo.

No veo ningun procedimiento desde donde se llame la funcion, pero si se refleja su funcionamiento, asi que quieria saber si esa funcion puede ser usada en una aplicacion similar a la de caral, porque me parece una funcion un tangto "generica" (no sé si es el termino correcto) porque no tiene refencias de otras partes del codigo de la aplicacion.

Está dicha funcion enlazada de alguna manera con los try...finaly?

Disculpen mi novatada.

Hola epenor, Creo que estás un tanto confundido... el uso del try-finally es una cosa, lo que hacen esas funciones es otra. Creo que el ejemplo de caral demuestra que es lo que hacen.

No te enojes pero creo que estás enfocando mal tu esfuerzo, no le pongas demasiado detalles al aspecto del manejo de errores. Primeramente asegúrate de cumplir con los objetivos primarios:
1. Que el sistema se logre conectar a la base de datos
2. Que realize las funcionalidades necesarias para responder a los requisitos planteados para el sistema.

Después si se lo puede adornar.

Si sigues analizando aspectos que poco estén relacionados con el verdadero propósito perderás tiempo y además conseguirás únicamente tener una ensalada en el cerebro.

Haz caso a lo que te hemos aconsejado: plantea tus dudas y avances. ¿De que otro modo podremos asesorarte si no nos describes tu situación con los detalles adecuados?

Saludos,

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