ahora solo faltaria hacer el formulario de venta con list1 y con numero de factura, solo te pido si me pudieses hacer el control de numero de factura consecutivo desde 1 hasta infinito con archivo guadar ya seria mucho.
Venía a decirte que como ejercició está bien y hasta ahí, y que resolverte cada addedum solicitado, al final, acaba pareciendo más una tarea que un ejercicio.
Nota que, una vez más la asuencia de una especificación inicila y clara, obliga a cambiar cosas que se daban por 'definitivas', más aún se observa en la nueva petición que hay cosas en el aire, detalles ambiguos que al resolverlos uno debe decidirse por un lado, sin saber si luego será por el otro, y por tanto trabajo en vano.
Te comento por encima para que entiendas la diferencia de cosas y el problema de tirar al vuelo código sin una especificación.
Como mínimo esta debe estar perfectamente clara en tu mente (pero es algo que solo se adquiere con el tiempo), si no te entretienes a detallarla en papel o en un fichero... La ventaja del papel es que puedes mezclar texto y garabatos de forma rápida, guardaro en el bolsillo y llevártelo donde sea, que al momento que surja otra idea, puedes añadirla o modificar la previa. Así y todo al final procede pasarlo a un fichero, dejándolo libre de polvo y paja (tachones e ideas rechazadas)...
Antes de ponerte a escribir una sola línea de código, debes tener clara la especificación del problema a atacar. Si es simple, como digo puedes mantenerlo completamente en tu mente y hacer un esqueleto del mismo (en pseudocódigo), analizar alternativas y decidir según los objetivos perseguidos...
Añadir una ventana de ventas, implica todo esto:
- Añadir artículos a la venta. La que ahora es la 'ventana de compra', pasaría a ser esa de 'ventana de entrada de artículos'.
- Comprar artículos. Ahora la ventana de compra en vez de la actual de compra, sería la 'ventana de ventas', donde el vendedor expone todos sus artículos a la venta. Que igualmente con cada compra se pasarían al 'carrito de la compra' donde finalmente se acepta o se rechazan.
- Comprar un artículo definitivamente, debería reducir el 'stock' en venta. Por lo que esa 'ventana de artículos', debe al mismo tiempo añadir un campo con el concepto de 'stock disponible', y la 'ventana de entrada de artículos', debe modificarse, la cantidad (que antes implicaba la cantidad comprada), ahora indicaría la cantidad en stock disponible... El subtotal en este caso también cambiaría pues vendría a indicar el precio total del coste al proveedor. Además en esa misma ventana habría que poner otro precio, el de 'precio al cliente', pués el precio que ahí consta podría bien reflejar el precio al que el vendedor lo compró al proveedor.
- Si hay una ventana de ventas, es claro que habrá más de un cliente, pues el proyecto ahora mismo se aproxima más a uno para llevar control de sus propias compras, es decir un solo comprador (tú), administrando tus compras de aquí y allá. Una ventana de ventas, se aproxima más a la vista dle vendedor. En este caso hay más de una opción... ----- Se trata de (por ejemplo) una tienda de ropa?. Donde aunque solo hay un único vendedor (la tienda en sí), se personifica en cada empleado que atiende en la caja registradora... luego pueden considerarse varios vendedores. si miras tus tickets de compra de supermercados típicamente al final en la impresión de la factura verás el típico: "Le atendió Patricia".
----- Se trata de una plataforma de ventas (por ejemplo amazon, eBay). Donde cada venddor no tiene nada que ver con otro vendedor.
En ambos casos, interesa hacer constar la referencia del vendedor (el nombre o Id del vendedor en el caso del primeor y el Id o alias en e l caso del segundo). Sin embargo una diferencia entre ambos, modos es que el el primero no requiere una identificación (login) de usuario, ni por tanto una cuenta registrada a su nombre. El usuario accede a la tienda, compra, paga y se va con sus artículos comprados. En el segundo caso, el usuario para poder comprar debe estar registrado (aunque puede comprar y añadir compras al carrito, a la hora de pagar, se le exigirán las credenciales.
También una ventana de ventas, supone una factura por (lote), por cada comprador. Antes la ventana de compras, acuñaba el id de compras y artículo a medida que estos eran comprados... (por que es una facturación de 'compras' es decir para uso privado del comprador), ahora esos ids, cambian el momento de ser creados. El de artículo debe acuñarse cuando el vendedor añade sus artículos al stock y el de lote, cuando el comrador lo adquiere y deben acompañar.
Luego una 'ventana de ventas' (ventana de artículos en venta), exige otra 'ventana de artículos vendidos' para poder despachar las ventas. Si se trata del segundo caso, debe llevar el campo id o alias del comprador, que además estará asociado con un registor en otro fichero con sus datos (para el envio). Aquí además entra en conflicto la concurrencia de eventos... del tipo: qué pasa si mientras un comprador mete un artículo en su carrito, y le pulsa pagar pasa el tiempo suficiente tal que otro comprador haya adquirido el mismo artículo y por tanto ya no esté en stock, o lo esté pero no en la cantidad solicitada por el comprador?. Exige implementar un sistema eficaz de algún tipo de bloqueo, o bien comprobar en el momento exacto del pago artículo por artículo si aún están en stock. Sea el método elegido que sea, debe ser lo más flexible posible para que la experiencia del comprador no sea 'desagradable' y descarte comprar de nuevo en 'ese sitio' por su mala gestión del stock'.
Igualmente la que ahora es la ventana de compras, lo sería para cada comprador, pero debería adaptarse al caso concreto de cada tipo de 'venta' comentado (hay más opciones pero son los dos casos generales).
En segun que condiciones, puede interesar que cada lote comprado sea un fichero señalando en tal caso como nombre de fichero el id del lote. Al caso tales ficheros tendrían dos registros distintos. el primero es un resumen de la compra: Cantidad de artículos comprados, fecha, numero de lote (que coincidirá con el nombre dle fichero), e id o alias del comprador (si procede) y el monto total de la compra. Y le siguen los registros de compra de cada artículo.
Esto simplificaría enormemente la 'ventana de articulos vendidos', pues la lista, contendría (imprescindible tan solo) los IdLote y puede que cualquier otro campo más, como montototal de la venta del lote, o la fecha, etc.. y si es extenso, contendría justamente la linea completa del registor dle lote que ecabeza cada fichero (aunque lo veo excesivo)... al pulsar en una línea de esa lista, se leería el lote y se presentarían sus detalles debajo de esa lista o en una ventana aparte.
Hablando de ventas, también procede una búsqueda por 'comprador' (dando su Id, o alias). Igualmente si se trata de una plataforma de ventas, donde cada comprador puede hacer compras a distintos vendedores, procede hacer búsquedas por id o alias de vendedor. No en cambio si el tipo de ventas es de un solo vendedor y los 'vendedores' son solo los empelados capacitdo para manejar la terminal de ventas. Aunque incluso así, el propio vendedor (la tiemda), podría querer consultar la ventas que ha realizado al cabo del mes cada uno de sus empleados, en defintiva... con ventas las posibilidades se disparan y deben quedar previamente definidas y acotadas.
Otra cuestión menor es por ejemplo, tratándose solamente de un facturación personal de compras (loq eu creía que tenías entre manos hasta ahora), usar Ids de tipo integer satisfacen la aplicación. Las compras en un mes para una persona a lo sumo serán unos pocos cientos... pero para ventas, la cosa cambia... el número de compradores puede ser desconocido, luego un tipo 'integer' (2^15 en vb6), no es válido, debe ser al menos de tipo 'long' (2^31 en vb6).
Cuando el número de registors en un fichero es elevado (con compras por mes, no creo que suceda, peor sí con ventas por mes), los métodos de búsqueda secuencial, pierden todo interés por su ineficiencia (para unos cientos son válidos y más que aceptables a cambio de su simplicidad, pués una búsqueda representará en tiempo apenas un parpadeo), para más cantidades procede tirar de tablas hash, o ciertos tipos de árboles, pero son un tema más avanzado, para el que se precisa tener ciertos conocimientos mucho más sólidos en el lenguaje con que se opera.
En fin, tienes detalles suficientes para avanzar en cualquier dirección que quieras el proyecto (te aconsejo que lo guardes, copies y pegues y hagas las modificaciones en la nueva copia) y código en el que fijarte para construir lo que te falte y requieras. Como puedes leer son tantos detalles (solo he tomado algunos al vuelo, al pormenor son muchos más), que es inaceptable proceder sin una especificación bien detallada. El abanico de posibilidades se abre demasiado.
Cuando tomas un taxi, tu le dices a dónde vas, el taxista ya conoce la ruta más óptima sea en km. o en tiempo según el día de la semana, hora del día, etc... ahora si le dices... vamos al campo de fútbol y cuando llegas... ahora esa calle al final, luego cuando llega.. ahora gira a la izquierda y avanza hasta la segunda calle y luego... el taxista va a ciegas... a un taxista le dará igual si al final recorres 20km. o si tardas 30 minutos más, pues cobra por el tiempo, pero si desde un principio le explicas voy a tal sitio que está dentro de tal ciudad/barrio... a buen seguro sale más barato. Aquí pasa lo mismo, se va 'conduciendo a ciegas', pareces ir a un sitio, peor al llegar dices, 'No, ahora vamos a ese otro sitio'...
Lo que pretendo decirte, es que ...al final, no es la complejidad, pues se desgrana todo en un árbol de decisión y cada cosa con sus detalles queda recogida y puede ser adecuada y convenientemente implementada y además no se tarda tanto, es la falta de una especificación completa del sistema desde el punto uno... lo que impide dar una solución definitiva al tema.
Si un día llegas a vivir profesionalmente de esto, te darás cuenta que: los peores clientes, los que hay que evitar a toda costa, los que hay que reconocer desde un principio para decirles no o dejar claro todo desde un principio, es justamente el que opera de este modo, cambiando contínuamente cosas, que hacen que el tiempo empleado en parte de lo previo no sirva para nada, que los plazos se alargan y nunca se termina el proyecto y que en muchos casos intentarán mantener el precio inicial sin cambios, basado en su punto de vista porque 'son solo unos pequeños cambios'. Incluso aunque el presupuesto inicial fuera más que generoso, es fácil al final acabar perdiendo dinero, tiempo y puede que hasta la paciencia
Autor
para mantenerme 'ocupado'... miraré de echarle un ojo mañana, hoy ya lo tengo cubierto.
En línea
No sé a qué te refieres exactamente... Si es por poner algo de código, no acostumbro a hacerlo, casi siempre pongo las explicaciones pertienentes y pseudocódigo. Peor cuando veo código espagueti, entiendo que el interesado no tiene la ayuda necesaria para avanzar...
