Hola soy corlo
ahora en pantalla principal hay list1 y list2
en el list2 es donde se va entrando los articulos desde el formulario y en el list1 es donde se guardan los datos del list2 al list1 para poder sumar el contado y tarjeta de credito
A la hora de entrar los datos al list2 desde el formulario lo hace bien, el problema es para guardar todos los datos del list2 a una fila del list1 asi sucesivamente con numero de ticket 1,2,3, etc del list1
a la hora de guardar seria:Command2_click()
N de ticket, fecha y hora, metodo de pago, total en el list1
en el metodo de pago esta en la pantalla principal no desde el formulario
a la hora de leer seria list1_click()
N ticket, Fecha y hora, Producto, Precio Unitario, cantidad, subtotal, total, en el list2
Gracias
Puedes poner alguna captura (o más de 1 si no queda visible todo en una sola) que sirva para orientarse mejor?. Y explicar desde lo que se ve en ella?
La redacción deja que desear y no termina de entenderse bien que tienes actualmente y a dónde quieres llegar, o sea, cuál es el problema que tienes...
...pareciera que lo que tratas de hacer es el típico 'carrito de la compra', de ser así, al fnal hay que validar o anular la compra, es decir en ese caso son dos procesos, en un o se realiza la elección de los artículos y cuando se quiera se acepta o anula, si se acepta, se procede al pago (se elige la modalidad de pago (para todas las fácturas en el carrito de la compra), se acuña la fecha de ese momento y se asigna el Id de compra para cada artículo.
...en todo momento se supone un mismo y único usuario, si fueran varios, habría que añadir la identificación del usuario al registro (un id de usuario registrado y mantener también un fichero con el registro de los usuarios, cuyos campos podrían ser (a modo de ejemplo):
Id, nombre y Apellidos (3 campos), Alias, fecha de alta, y opcionalmente teléfono. Datos como: numero de documento de identidad y datos bancarios, no son adecuados si no se establece un sistema de seguridad, como se supone que es un ejercicio de prácticas y no una aplicación real, puede obviarse o crearse ficticiamente y por tanto saltarse las cuestiones relativas a la seguridad.
Debería poderse buscar un registro de usuario desde el fichero partiendo de su Alias e Id. Pueden existir nombres completos idénticos (se da en la realidad), pero no alias, por ello al intentar registrar un usuario debe asegurarse que no existe ya, de suceder debe soliicitarse otro alias, también debiera exigirse que los alias tenga un mínimo de caracteresy un máximo y determinar que caracteres se toleran para el alias (A-Z, a-z, 0-9, rechazando el resto, incluso espacios (son traicioneros al escribirse o al filtrar 'strings') para evitar problemas con determinadas funciones de tratamiento de texto).
Para que la búsqueda de Alias sea rápida los alias únicos deberían ir (también) a un fichero (nuevo). Así este fichero podría tener asociados pares Alias-Id, siendo los alias de tamaño prefijado (se rellena con espacios a su derecha si es más corto). En el fichero se escriben de forma contínua, pero en memoria deben constar en una tabla hash... Como estás verde con tratamiento simple de ficheros y funciones de búsqueda, las tablas hash de momento quedan fuera de tu alcance, así que puedes obviar este fichero y hacer las búsquedas secuencialmente en el registro de usuarios (anteriormente ya te incluí dos ejemplos de búsqueda secuencial en un fichero de registros).
Lo principal es lo de arriba... al menos hasta que lo soluciones.
Hola
asi es serapis, es para un carrito de la compra, que los datos introducidos desde el formulario, van al list2, esto sale bien
pongo fecha a la hora de crear nueva factura , lo tengo que poner asi 14-12-2021, con la barra no me lo acepta.
el problema es:
a la hora de guardar los datos vayan a una fila del list1, para luego leer desde el list1 y vayan toda la lista de la compra los datos al list2
de esta manera tendria todos los dias controlados
con una carpeta por mes
list1
N de ticket fecha y hora metodo de pago total
total contado
total tarjeta de credito
en el list2
N ticket fecha y hora producto Precio por Unidad cantidad subtotal
. contado Total
Nuevo Guardar Imprimir . tarjeta de credito
Todo esto es en un formulario
Te lo hago asi porque no se como hacerlo como crear una imagen de fichero y luego subirlo al foro
el tema de sumar el contado y la tarjeta de credito en el list1 , ya esta solucionado
Gracias
Al lado de la tecla F12, a su derecha, tienes la tecla para capturar la pantalla, luego te va a un programa de imagen y pegas la imagen desde el portapapeles (menú edición -> pegar), luego recortas la imagen si es muy pequeña respecto de la pantalla completa y la guardas en un formato con compresión preferenetemente en jpg (excepto si hay mucho texto que deba ser leído, en ese caso en png, que conserva mejor los detalles del texto), luego lo subes a una página d ealojamiento de imágenes, copias el enlace 'para foros' y lo pegas en tu mensaje, y cuando envíes el mensaje aparecerá la imagen... es algo muy básico y se tarda más en explicar que en hacerlo.
Cuando haces compras de varios artículos a la vez, se introduce el concepto de 'lotes- pedido', es decir una compra de uno o más artículos en el mismo pedido.
La importancia de esto radica en poder asociar todos esos artículos juntos con un único pago y una única transacción.
Esto requiere modificar profundamente el programa... exige un fichero 'pedidos', que se compone de 3 registros (como mínimo)
estructura Lote
id pedido
cantidad articulos
id de la lista de articulos.
fin estructura
Como la lista es una cantidad variable, los registros no son de tamaño uniforme, como siempre pasa, hay varias soluciones, la rápida de programar y lenta de operar porque es recorrida secuencialmente o la lenta de programar pero más eficiente.
Entonces si optas por la opción rápida la estructura previa (type), te vale, si prefieres una más óptima, habrá dos ficheros, uno de pedidos, que aligera la estructura previa y hace los registros de tamaño uniforme:
estructura Lotes
id pedido
cantidad articulos
posicion
fin estructura
El campo posición indica donde s elocaliza en otro fichero el comienzo de los articulos para esa lista...
...y por tanto otro fichero que contiene únicamente ids de artículos... puede optarse por mantener en la cabecera la cantidad de ids que contiene el fichero o simplemente calcularse toda vez que cada campo tiene el mismo tamaño en bytes (2 para vbInteger o 4 para vbLong).
Entonces cuando se lee un lote, se accede al registro en el fichero lotes:
dim lote as lotes
lote = getRegLote(index)
y se crea un array con la cantidad que señala lote.numArticulosLote para acto seguido leer desde el fichero articulos
dim articulos() as integer ' long?
redim articulos(0 to lote.NumArticulosLote -1)
get #canalArticulos, (lote.posicion * 2)+1, articulos ' x2 porque cada id es un vbInteger? y por tanto ocupa 2 bytes y +1 porque vb6 considera el primer byte del fichero como 1 y no 0).
' el tamaño del array instruye a cuantos valores debe leer... por eso hay que dimensionar el array antes.
Finalmente con el array de ids, se pueden localizar en el fichero que guardas los detalles de cada artículo...
Otra opción (la sencilla de implementar y más lenta para considerar lotes), es omitir estos ficheros y a cambio modificar la semántica (signoficado y comportamiento) del campo numTicket (en el único fichero de compras-mes.dat).
Justamente el id compra (numticket que llamas tú), pasa a ser considera el id lotes que sigue siendo único y autoincremental... pero ahora se asocia se asocia con cada artículo que se compra en un mismo lote, es decir todos los artículos comprados en un lote tienen el mismo idLote (numTicket), y conviene añadir un nuevo campo (también único e incremental) así cuando se localiza un pedido se localizan todos los artículos con el mismo idLote, aunque lo habitual es que como estarán contiguos en el fichero se limita a buscar el primero, y luego leer los siguientes registros mientras el idLote sea el mismo.
Es decir el reconocimiento del lote sigue ese patrón.
El idCompra identifica cada compra así se puede discriminar cada artículo de un lote y facilita poder buscar también un solo idCompra en todo el fichero.
La lógica tras un carrito de la compra es la siguiente (a la noche si veo que tengo tiempo suficiente, te hago un breve código de ejemplo, peor en vez de modificar lo actual, creo una nueva ventana, para no tocar lo previo).
En una ventana (como hasta ahora) se puede elegir el artículo a comprar (esa parte depende de tí enteramente poner a disposición dle 'cliente' los productos disponibles, así como su precio). Hay un botón añadir al carrito...
Cuando se pulsa ese botón es cuando ese artículo, la cantidad y el precio por unidad se pasan al listado del carrito de la compra (conviene una ventana flotante y no modal para esto).
En ese momento, no se les asigna ni número de ticket, ni fecha... solo cuando se pulsa 'aceptar' el carrito d ela compra.. es decir esa ventana debería tener al menos estos 3 botones:
Aceptar, Cancelar y eliminar el/los items seleccionados del carrito de la compra
- Si se pulsa cancelar: se pide confirmación y si se confirma se vacía el listado.
- Si se pulsa eliminar items: se pide confirmación para eliminar los 'selectedcount' items... y si se confirma, se borran empezando desde el final del listado hacia el primero cada item seleccionado.
- Si se pulsa aceptar, entonces se fija la fecha de 'ahora' y se toma el idLote, y se envía a guardar los articulos en el listado, cada idCompra se genera al guardar el registro, pero idLote se debe pasar ya el mismo para todos esos artículos.
Lo que resta, es (cuando se solicite) volver a cargar el lote comprado... a decir verdad, interesaría que el listadod e compras, fuera diferenciando cada lote con un color de fondo distinto, algo que un listbox no permite, por eso decía que para listas complejas, es preferible un control tipo 'grid' (flexGrid), que admeás contiene columnas y permite ordenar por columnas automáticamente.
Lo que cambia sobretodo en este listado, es que el lote al tratarse de una compra 'atómica', y tener todos sus artículos comprados misma fecha, mismo idLote y mismo metodo de compra, no s epermitirá eliminar un solo artículo del lote, o se elimina todo el lote o nada, pero no artículos sueltos del lote.
Con todo es preferible el método para lotes de varios ficheros, pero empieza por modificar solo para usar un fichero único y más adelante haces copia del proyecto y lo modificas para tener varios ficheros...
hola serapis
es justo lo que necesito, guardar la informacion y leerla, si me pudiese hacer un ejemplo seria lo suyo, porque asi se ve la manera de trabajar con dos end type, el primero seria la entrada de los articulos, osea la grabacion, y el segundo end type seria leer la compra de la informacion, gracias.
Hola.
Ayer no tuve tiempo de hacer nada, hoy (viernes), si qué el justo para copiar el proyecto y empezar a modificar... es casi empezar desde cero. Mañana en otro ratito lo completo... no estará probado (al menos a fondo, seguramente si pruebe lo esencial), porque me llevaría más tiempo del que le quiero dedicar... así que correrá de tu cuenta corregir los errores que se me hubieren colado. Eso sí, si te surge un problema que no consigues localizar, detalla el problema y reviso la causa del problema.
Es muy, muy importante, antes de meterse en un proyecto (incluso aunque sea un ejercicio), tener una especificación (aunque sea en prosa y no en pseudocódigo) de lo que se va a hacer, precisamente para evitar eso... un cambio tan profundo, que todo lo anterior prácticamente no sirva para nada. Empezar de cero hubiera sido más corto que modificarlo todo, peor he preferido modificarlo para guardar consistencia dentro de lo posible con lo previo (mantener nombres, orden de cosas, etc...), para que sea más aseqible entenderlo conforme a lo ya tratado (la memoria ayudará en eso).
Siempre hay cambios que hacer, cosas de última hora o elecciones particualres por preferencias, conveniencias o inconvenientes, pero cuando los cambios adectan toda la estructura del programa, es más fácil empezar desde cero, y eso, sí hay que tratar de evitarlo, porque entonces es tiempo perdido todo lo que se hizo previamente.
Ufff.... cuanta pereza me ha dado... Rehacer desde cero las cosas es aburrido cuando pudo evitarse pensando un par de minutos antes de ponerse a escribir ni una sola línea de código, que e slo que quiere hacerse...
No he probado todo, cosas como guardar el carrito a fichero y recuperarlo (ante un cierre inesperado), o eliminar un lote no lo he probado. Los errores que pudiera haber te toca corregirlo.
Descarga del ZIP con todo el proyecto:
https://workupload.com/file/CBPxfcwTLuE (148kb. aprox. el peso se debe sobre todo a las 3 capturas de imagen, que olvidé sacar de la carpeta.. como tampoco sobrna las dejo).
He dejado también el fichero de factura de ejemplo e el zip.
He aprovechado para poner los botones con colores.
Un vistazo de como se ve...
(https://i.ibb.co/b7jShhz/Facturaci-n-00.png)
Como se puede apreciar, la ventana de comprar ahora carece de ciertos textbox (como la fecha), que se pasan al carrito de la compra.
En el carrito de la compra se van recofgiendo los artículos comprados, juntos forman un mismo lote que se pagan de una única vez, por ello, campos como a fecha y método de pago y número de lote, se asocian con todos los artículos ahí comprados de una vez.
Puede seleccionarse algún artículo y elimarse de ahí, antes de pagar (no está probado ese botón).
(https://i.ibb.co/ZfSZ6zK/Facturaci-n-01.png)
La ventana principal, ahora dispone de más posiibilidades de sumar totales... puede solicitarse para todos los pedidos o solo para un pedido (el seleccionado), cuya suma se muestra a la derecha.
La suma total, además de mostrar las sumas de 'al contado' y 'con tarjeta de crédito', tambien suma el total de ambos.
Además se ha provisto una función para formatear los valores y así poder proporcionar más vistosidad...
(https://i.ibb.co/7v52gSG/Facturaci-n-02.png)
Tendrás que mirar a fondo el proyecto, modificar lo que quieras. Igualmente la opción de imprimir factura queda a tu esfuerzo, así como porbar o corregir cualquier detalle que no funcione como se espere... no me apetece repasar a fondo que todo funciona bien... algo tendrás que hacer tú también. Si me he asegurado al menos que comprar artículos, añadirlos al carrito, y guardarloa fichero y leerlo de fichero, esté correcto.
Hola Serapis
lo mirare mas a fondo ya te digo que es lo que necesitaba muchisimas gracias
con aplicaciones asin , visual basic 6.0 no esta caido todavia, se pueden hacer muchas cosas.
muchas gracias
...es el 'patito feo' de la programación. El caso es que es el lenguaje que más adeptos ha tenido en el mundo... allá por el 200 eran muchos millones... probablemente pase mucho tiempo antes que otro lenguaje adquiera esas cifras (y que no sea metido con martillo en la Universidad, sino basado en el boca a boca entre sus usuarios).
Yo lo adoro con la misma intensidad que lo odio.
A favor tiene la virtud de lo rápido que puedes desarrollar casi cualquier cosa...
En contra tiene, las severas limitaciones que posee en determinadas áreas (muchos suelen suplirlas tirando de APIs, pero a mi me gusta usar solo cuando es imprescindible o cuando la solución en vb6 es enormemente más trabajosa).
Muchos lo han criticado incluso por cuestiones que son falsas (como que es un lenguaje interpretado, mal informados supongo que por la herencia del BASIC (de los 80 reflejado en los ordenadores Spectrum, Commodore, etc...), que en versiones previas si lo fue y al principio fue también compilado). Esos mismos que veían una enorme desventaja en los lenguajes interpretados y la lentitud asociada, ahora no lo tienen en cuenta cuando hablan de Python (por ejemplo).
En cualquier caso, un lenguaje muere cuando el último programador (que lo usaba) deja de usarlo...
Hola serapis
se que me vas ha enviar al carajo
faltaria arreglar lo de buscar articulo y eliminar registro por lote. he probado varias cosas y no me ha funcionado
gracias
Bueno... tengo vacaciones ya hasta después de año nuevo, aunque ya me han buscado tareas en casa :-X para mantenerme 'ocupado'... miraré de echarle un ojo mañana, hoy ya lo tengo cubierto.
Esto quedaría mejor usando una capa de persistencia que implementara SQL Lite...
https://github.com/RobbiNespu/VB6-Sqlite3 (https://github.com/RobbiNespu/VB6-Sqlite3)
Me suena a mucho usar el patrón Command (Cada operación a SQLLite una entidad Command esto para ejecutar SQL y convertir los datos a Estructuras o viceversa) junto al Chain of responsibility [Opcional]...
Te recomiendo usar patrones de desarrollo para que este tipo de adaptaciones te resulten a futuro de fácil mantenimiento.
https://profile.es/blog/patrones-de-diseno-de-software/ (https://profile.es/blog/patrones-de-diseno-de-software/)
Las operaciones para guardar datos en archivos es siempre mejor SQL-Lite que usar archivos en formatos planos... a la larga es tedioso e imaginate antes cuando no existía el SSD la latencia era peor.
Saludos.
Cita de: BlackZeroX en 23 Diciembre 2021, 05:36 AM
Esto quedaría mejor usando una capa de persistencia que implementara SQL Lite...
Por supuesto...
Pero es un usuario que esta empezando, aprendiendo. Si no sabe usar ficheros, me temo que una base de datos mucho menos.
Antes de aprender a correr, debe uno aprender a andar (tropezarse, caer y levantarse)...
Más que nada, busca aprender, no tener un código optimizado. Pasar de un código espagueti a uno estructurado, es un paso que debe dar, fijándose, repitiendo y cuando adquiera un poco de soltura ya profundizará.
He sacado un rato hoy para completar lo que faltaba...
...eran pequeños detalles, por ejemplo al buscar artículos, requería eliminar los espacios al ser una cadena de longitud fija los caracteres faltantes son espacios, y al ingresar el texto de búsqueda, uno nunca añade tales espacios... etc, etc...
He añadido de paso la posibilidad de búsqueda parcial usando patrones. En el código como comentario he dejado algún ejemplo (si mal no recuerdo).
Y pequeños cambios, como añadir un 0 más a los decimales cuando totaliza (para que no redondeee a solo 2 decimales), etc...
Descarga (esta vez me acordé de apartar las imagenes):
https://workupload.com/file/mg4XLfn97CN (aprox. 27kb)
muchas gracias serapis
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.
muchas gracias
feliz navidad y un prospero año nuevo 2022
javascript:void(0);
Cita de: Serapis en 23 Diciembre 2021, 22:41 PM
Por supuesto...
Pero es un usuario que esta empezando, aprendiendo. Si no sabe usar ficheros, me temo que una base de datos mucho menos.
Antes de aprender a correr, debe uno aprender a andar (tropezarse, caer y levantarse)...
Más que nada, busca aprender, no tener un código optimizado. Pasar de un código espagueti a uno estructurado, es un paso que debe dar, fijándose, repitiendo y cuando adquiera un poco de soltura ya profundizará.
Cita de: Serapis en 26 Diciembre 2021, 15:39 PM
He sacado un rato hoy para completar lo que faltaba...
Cita de: corlo en 26 Diciembre 2021, 16:51 PM
solo te pido si me pudieses hacer el control de numero de factura consecutivo desde 1 hasta infinito con archivo guadar ya seria mucho.
@Serapismmm... sin comentarios, yo antes hacia lo mismo que tu.
Solo algo que llegue ver de forma profesional:
Sea el lenguaje que sea note que mas del 80% de los desarrolladores con los que conocí (chavos/jóvenes/señores ya sea que tengan MAESTRIA/DOCTORADO o solo licenciatura), tienen en su mayoría bastante tiempo (Yo era uno de ellos) y no usan patrones es mas cuando tienen que cambiar una regla de negocio afectan a varios elementos pues no existe un patrón del mismo, sus pruebas unitarias son repetitivas, muchos de ellos le corren (detestan) a los patrones pues no los comprenden o no los conocen.
Si hay que Gatear/Pararse/Caminar/Correr que sea guiado.
Saludos.
Cita de: BlackZeroX en 27 Diciembre 2021, 05:46 AM
@Serapis
mmm... sin comentarios, yo antes hacia lo mismo que tu.
:huh: 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...
Nadie discute que para viajar lejos, el avión el barco o un tren, lo hacen más barato.
Y para desplazamientos cercanos, un autobús o el metro también lo son.
...pero a pesar de todo eso, la gente sigue prefiriendo usar su propio vehículo, cuando puede incluso a pesar de que le salga algo más caro (viajar y manetener el vehículo), porque al final esos medios de transporte tienen 'paradas' y con tu vehículo, vas exactamente al punto donde necesitas (aunque luego en la práctica hay que aparcar donde haya espacio y por tanto toque andar lo mismo que si se hubiere usado el bus), y sobretodo con los horarios que quieras, sin depender de si, ya no hay buses o si el siguiente tardará 30 minutos en pasar...
Mira a tu alrededor y verás que al final sea con bici, monopatín, ciclomotor o coche (carro), la gente prefiere su propio vehículo casi siempre a un medio colectivo.
Hay un orden en las cosas... las bases de datos están al final del aprendizaje (de hecho jamás recomendaría SQLLite, sino SQLServer)... al comienzo los ficheros de texto, e incluso en ese punto, los de acceso secuencial y acceso aleatorio.
Cuando tenga la experiencia necesaria, es de esperar que avance. Saltar de la nada a las bases de datos, solo sirve para tener una nebulosa de como las cosas se hacen por debajo...
Me parece que lo interesante para Corlo, más incluso que resolver su problema con este ejercicio, es que acabe de entender la diferencia entre el código espagueti y un código organizado (ni siquiera le propongo utilizar clases), suele conseguirse con algo de paciencia, cuando comparan, acabarán por notar una diferencia por el contraste. Justo cuando hay un contraste entre el modo de hacer hasta ahora y el modo en que se ve algo (reciente o no), es cuando la gente tiene la oportunidad de avanzar (más rápido).
En cualquier caso, el hilo no va sobre filosofía del aprendizaje. Que cada cual se remita a lo que su interior le dicte, incluso creyendose en posesión de la verdad o del error, pues al final es sólo su tiempo (y no el de otro) lo que hay en juego.
Hola serapis
solo seria un codigo para controlar el numero de factura para guardarlo en archivo
en un text1.text numero de factura y un list1 y guardarlo, solo el numero de factura
como toda la informacion esta guardado en un archivo, yo antes lo hacia en dos archivos, uno en guardar el indice y el otro guardaba los demas items.
Gracias
Cita de: corlo en 26 Diciembre 2021, 16:51 PM
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 :laugh: :laugh: :laugh:
Hola serapis
muchas gracias por todo he aprendido mucho contigo , gracias por la explicacion pero no quiero tantas cosas, ya iré avanzando poco a poco
de verdad muchas gracias
Cita de: Serapis en 27 Diciembre 2021, 13:22 PM
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.
Diste al clavo :)
Los siguiente ya es fuera del tema y es solo un consejo.
@CorloTe recomiendo antes de escribir código dibujarlo (boceto) y a un lado poner las acciones... que agrupes por tipo de elementos y acciones, posteriormente que las programes en modo micro, es decir solo ese fragmento de código después ya los unes y veras que es mas facil pensar en fragmentos que en un todo...
Cuando me refiero a tipo de acciones me refiero por ejemplo, tengo productos que acciones se puede hacer con los productos, tengo carritos que acciones se pueden hacer con estos... tengo clientes que acciones se pueden hacer con los clientes, etc... después cada uno de estos los metes a una cajita (llamese bas o clase cls) y posterior defines de todos estos cuales son los importantes y los plasmas en tu código (pero sin programarles todavía nada solo los declaras).
pj:
bas de productos
public function cargarProductos() as productos()
rem sin código
end function
public function buscarProducto(byval value as string) as Producto()
rem sin código
end function
public function actualizarProducto(byval value as Producto) as boolean
rem sin código
end function
bas de carritos
public function crearCarrito() as Carrito
rem sin código
end function
public function retomarCarrito(value as Long) as Carrito
rem sin código
end function
public function cerrarCarrito(value as Carrito) as boolean
rem sin código
end function
public function pagarCarrito(value as Carrito, totalPagado as Single, tipoPago as MetodoPago) as boolean
rem sin código
end function
Después de que tengas estos pues ya se implementan en los Forms (frm).
Saludos.