FTP | CCD | Buscar | Trucos | Trabajo | Foros |
|
Registrarse | FAQ | Miembros | Calendario | Guía de estilo | Temas de Hoy |
|
Herramientas | Buscar en Tema | Desplegado |
|
#1
|
||||
|
||||
Bueno espero que lo que he dado hasta el momento, a) sea correcto y b) este claro.
Sigo con los modos de trabajo, siempre según mi experiencia, debemos tener en cuenta que los momentos de trabajo varían mucho de unos a otros, según los casos, debemos tener en cuenta las diferentes situaciones. Empresas o particulares, que necesiten una factura con sus datos, que pueden consumir a lo largo del mes y pagar con vales o a finales o principios del siguiente mes. Que nuestros camareros tengan comisión o queramos tener gestión de sus ventas o mesas simplemente. Estas dos variables, son importantes ya que varían mucho la velocidad de la venta desde nuestro punto. Estaréis de acuerdo con migo, que más de un 90% de los clientes de bares, cafeterías y restaurantes, son anónimos, salvo claras excepciones (centros de restauración de empresas o similares por ejemplo). en cambio usar un control de camareros, puede ser un requisito indispensable, sabiendo esto debemos hacer nuestro programa teniendo en cuenta las necesidades presentes y haciendo un poco el adivino por que también algunas futuras. Sabiendo esto, debemos saber que cuantos más parámetros, debemos meter, más lento irán los procesos, por ejemplo que cada vez que cambia de camarero, tenga que meter su clave, puede producir una perdida de tiempo de unos 5 minutos por hora e incluso más, en momentos de máxima aculturación eso es un gran error. He visto programas que incluso cuando se hace un nuevo ticket pide el camarero y es muy probable que sea el mismo, entonces por qué pedirlo nuevamente? Bueno después de soltaros toda la parrafada, os digo las situaciones como las he solventado. 1) Tiempos muertos o clientes con registro completo (el más lento de todos), podemos crear el ticket nuevo, seleccionando la mesa, taburete, etc del mapa*, elegimos el cliente y el camarero (pedirá clave o no según nuestra configuración), procedemos a introducir los artículos y listo**. 2) Tenemos ajetreo, en nuestra cafetería y los clientes son los típicos, que nos pueden pedir el ticket pero que no les hace falta que estén a su nombre, puede que nos nos interese saber su ubicación exacta, así que podemos ir un poco más rápido. 3) Tenemos el local lleno con un evento y todo son consumiciones, rápidas y directas, en este caso, lo mejor es una venta directa, según configuremos nuestra aplicación, será con control de camareros o no. yo lo que me he planteado es lo siguiente, puse un símbolo más (+) a lo que retrasaba y un menos (-) a lo que se volvería más rápido y me plantee más o menos el siguiente esquema. Seleccionar del mapa + no hacerlo - Elegir cliente + no hacerlo - Elegir comercial + no hacerlo - Comercial con clave + no hacerlo - Cobro con factura + Cobro con ticket + Cobro sin ticket - Cobro directo *** - si volvemos a los casos 1, 2 y 3 serían más o menos de la siguiente manera si cada + le sumamos 1 y cada - se lo restamos, cuanto menor sea el valor más rápido será el sistema Caso.....Mapa.....Cliente....Comercial....Clave....Factura....Ticket......Cobro Directo.....Puntos de velocidad ...1.........+...........+.............+...........OP.+.....OP.+........+/-................OP.-..............de 1 a 6 ...2.........OP.+......OP.+.........+...........OP.+.....OP.+........+/-................OP.-..............de -1 a 6 ...3.........-...........-..............OP+.......OP.+.....OP.+........+/-................OP.-..............de -4 a 4 Espero este esquema os resulte de utilidad como me lo fue a mi. En este esquema faltan otros apartados que pueden darse más adelante, por lo que no los menciono aún pero que vosotros mismo podéis ir hilando. También es importante a la hora de cobrar, nuestro programa, puede tener un sistema de control de entradas y salidas de los diferentes formatos de la moneda, que nos resultaría perfecto para tener arqueos controlados de la caja, pero en ciertos casos el cliente preferiré pasar de este con tal de atender muy rápidamente al cliente, así que es otro punto a tener en cuenta (lo trataremos más adelante detalladamente) * el mapa es el siguiente tema que trataremos ** listo por que podemos recuperar nuestro ticket en cualquier momento (ya lo trataré) *** El botón de cobro directo, no tiene en cuenta ni la devolución ni el capital entregado en el balance y el ticket, por lo que debemos usarlo en los casos de que el cliente no quiera el ticket.
__________________
Un saludo desde Canarias, "El abuelo Cebolleta" |
#2
|
||||
|
||||
El Mapa
Cuando decidimos montar nuestro programa de TPV, debemos tomar decisiones importantes, que harán a nuestro programa + comercial, pero que también puede hacerlo + o - productivo a la hora de trabajar. La decisión de usar un mapa de situación, dependerá entre otras muchas cosas de como nos hemos planteado hacer el programa, así como de exigencias del cliente, pero debemos saber que hacer un mapa de situación, aunque parezca complejo no lo es tanto, el mio esta hecho con mis propios Speedbutons para este tipo y además permite múltiples planos*. Dentro de cada plano disponemos de los diferentes elementos (taburetes, mesas, sillas de terraza, etc) que deben aparecer gráficamente en nuestro plano de situación, yo lo que he hecho es crear una tabla con la situación(los diferentes planos) y otra con la ubicación, los elementos especificando donde se encuentra el elemento (su situación), en esta última tiene registros como si esta ocupada, número de ocupantes, reservada, unida y número de unión, camarero, etc. Otra cosa buena que tiene un plano, es saber de manera visual las mesas que tenemos ocupadas y otros muchos detalles, el elegir visualmente que elemento vamos a a ocupar, etc. Existen programas de tpv, con planos super detallados y visualmente muy bonitos, otros simplemente con botones que representan los diferentes elemento, etc. Yo considero que es una buena manera de poder trabajar de una manera completamente visual. Pero esto es algo muy subjetivo y dependerá de cada uno Existen opciones muy variadas y componentes diversos, por ejemplo tenéis unos del maestro Neftalí que están muy bien, de hecho en un principio los use, pero luego los descarte, en mi aplicación por motivos prácticos al usar mis Speedbuttons, pero visualmente quedaban mucho mejor con su componente que con un TImagen como he usado yo. *El cliente puede tener varios salones, terrazas, etc y cada uno es un plano de situación diferente. Bueno si dios quiere mañana seguiré, con la grilla, el ticket, etc.
__________________
Un saludo desde Canarias, "El abuelo Cebolleta" |
#3
|
||||
|
||||
Bueno primero que nada espero hayáis tenido una gran fiesta de Fin de año y que este en el que entramos (2014) sea un año de parabienes para todos.
Me voy a meter con el ticket Primero esta parte la voy a dividir en 3 partes, ya que es una de las partes más importantes y representativas de nuestros programas, la primera va a ser la definición del mismo, la segunda debe ser el contenido y la tercera métodos de hacer el ticket. Vamos con la primera parte. El ticket es el comprobante que por regla general puede llevarse nuestro cliente, de hecho en muchos sitios y empresas, se admite el ticket como factura siempre y cuando tenga los datos necesarios, pero tener este no exime de tener/poder entregar facturas. Debemos crear unas tablas maestro detalle para nuestros tickets, en estas tablas debemos registrar los diversos datos del ticket y en el detalle los movimientos del propio ticket, de hecho yo uso tres tablas, el maestro, el detalle y la forma de pago. Yo personalmente prefiero en el maestro, poner campos completos, incluidos el total, se que esto incrementa nuestra tabla y por consiguiente la Base de Datos, pero con las capacidades de los equipos de hoy en día y la velocidad de los mismos, creo que es una gota en un océano, se que podría hacerlo por SQL, pero me es más cómodo y creo que más práctico de esta manera. Aparte de estas tres tablas en configuración uso un campo para tener el último número del ticket, de esta manera no estoy mirando el último registro de la tabla para saber por que número voy. Al igual que con todo debemos de plantearnos su estructura, antes de ponerse hacerlo, de hecho es bueno coger tickets de la compras, consumiciones, etc y comparar, ver que nos gustaría añadir, etc. El uso de una imagen en los tickets, es muy importante pero debemos saber, que no es posible con todas las impresoras y que de hecho hay impresoras que lo permiten pero al estar nuestro hadware (la impresora de tickets) o el del cliente, desfasado, puede que tengamos que usarlo como una impresora de texto únicamente. Elijamos el método que decidamos, debemos tener en cuenta que hay una serie de opciones que deben ser elegibles por nuestro clientes, por lo tanto deben estar en alguna parte, una tabla (configuración u otra), un fichero ini, un XLS, etc, como deben ser apertura del cajón, mostrar imagen en el ticket y la imagen, usar dos colores, etc.
__________________
Un saludo desde Canarias, "El abuelo Cebolleta" |
#4
|
||||
|
||||
El ticket y su contenido
Esto que parece un chorrada, es algo que se pasa por alto muchas veces, coger bolígrafos de publicidad, tickets, etc y leerlos con atención, pongamos el siguiente ejemplo Químicas XXX, S.L. Teléfono 999-999-999 A que se dedica esta empresa, puede ser un fabricante de productos de limpieza, de piscina, farmacéutico, etc o simplemente un distribuidor, no no los etc indicando, por eso debemos especificar bien y muy detalladamente algunos de nuestros datos ya que estos nos pueden representar y ser nuestra publicidad, también en el ticket. Nuestra ticket debe estar dividido en varias partes y este es más o menos el estándar: LA CABECERA (1) Logo (opcional) Nombre A que nos dedicamos Calle Provincia Código postal y población Teléfono y fax CIF o NIF Web DATOS DEL TICKET (1) Número del ticket Fecha y hora Terminal o persona que le atendió Elemento (mesa, taburete, etc) DATOS DEL DETALLE Unidades, descripción, precio ud., descuento y subtotal (2) TOTAL Total impuestos entregado (el importe únicamente) Devuelto (el importe únicamente) CIERRE Una frase de cierre como "gracias por su compra" (3) Claro esta, debemos tener en cuenta el ancho y la capacidad de caracteres de nuestro ticket yo en el mio uso 42 caracteres por linea, por lo que debemos limitar el ancho y es aveces preferible que no aparezca un dato como el email o la web si no va a poder leerse entero , esto deberemos decidir si hay campos del ticket que su lengt es mayor que el ancho disponible no salgan, así de simple. (1) Si alguno de los datos esta en blanco, simplemente no pasa por el ticket, evitando de esta manera un linea en blanco, salvo que en esa misma linea exista otro dato claro esta (2) en una linea mejor que en 2 (3) Esta frase debe poder ser preseleccionada, incluso en mi proceso de desarrollo previo pensé en poner dos frases una que pusiese según la hora del día más o menos la siguiente frase que pase (un buen día) o (una buena tarde) o (buena noche) Y otra para ofertas tipo café + sándwich 2'80 € (opcional) pues eso que el cliente pueda elegir si quiere que le aparezca en el ticket
__________________
Un saludo desde Canarias, "El abuelo Cebolleta" |
#5
|
||||
|
||||
Por último queda el método a usar, existen varios que conozca, a través de un report, tipo memo y por código de impresora, yo he usado los dos últimos, pero no descarto otros métodos más, hablo de los que he leído y de aquí en adelante de los que yo uso, para ello os pongo el código de las funciones que uso que suelo usar para ambos casos ya que más adelante aparecerá y sin esta parte será más compliacado entenderlo
el WriteRawDataToPrinte es del maestro SEONE el GetImpresora es del maestro Marcos Zorrilla el MyTextReplace es bajado de Planetadelphi.com Y CenterString no estoy seguro si es mía o la baje de algún lado Yo personalmente uso ambos sistemas y dejo que el cliente decida si quiere imprimir por código o ticket simple, esto lo hace en configuración mediante el campo método de impresión con dos valores posibles 1 o 2. Pongo una imagen de mi visor de tickets en esta me queda varias cosas que corregir, detalles como nº de artículos, ya que hace referencia al número de lineas y no de artículos, etc, pero os vale de ejemplo. El método por código es un poco más trabajoso y debemos tener en cuenta que en cualquier momento el cliente puede cambiar de impresora, resultando que los códigos ya no son válidos, el método de usar un memo, es 100% fiable ya que imprimimos nada más que un texto plano y podemos salvar que nuestra impresora admita acentos o no ya que los sustituiremos gracias a la función MyTextReplace, permitiendo imprimir en cualquier impresora que admita los códigos ASCII, por la tanto en todas, salvo especificas para otros países que no tengan la posibilidad de cambiar el idioma /(ejemplo caracteres, chino, cirilicos o árabes) Pongo el código de unos de mis primeros tickets por código y memo con selección de impresora normal o no (ya digo mi antiguo método
Como veis lo que hago es diversas llamadas a la tabla de configuración donde tengo definidos los campos con su código tipo TEXTCORTE, TEXTINICIAR, etc.
__________________
Un saludo desde Canarias, "El abuelo Cebolleta" |
#6
|
||||
|
||||
No se si os valdrá pero qui pongo alguno de los códigos usados en mis viejas EPDON TM 210 de las que no tengo drivers para mi windows 7, os advierto que puedo poner el texto a rojo, pero luego debo reiniciar mi impresora para que vuelva a salir a negro, no se por que es pero aquí os pongo casí todos, pero me reservo unos pocos para mi
Cita:
__________________
Un saludo desde Canarias, "El abuelo Cebolleta" |
#7
|
||||
|
||||
Bueno ya no sigo por hoy con el monologo y espero no estar haciendo el ridículo, se que lo que he puesto debería estar bien ya que lo he probado, pero no me gustaría estar dando mal la información por que yo este equivocado, de hecho os hablo por que he estado al otro lado de la barra y se que era lo que me hacia falta, pero eso no quiere decir que mi verdad pueda ser la única.
Sigo diciendo que no soy la persona más adecuada, para enseñar, ya que me queda mucho por aprender, pero estoy seguro y muy seguro de que muchas de las cosas de las que hablo están en la red o debieran estar, lo único que hago es unificarlas y darles un punto de vista determinado, claro esta el mio. Me considero bueno analizando problemas en los programas y a veces logro dar soluciones buenas, pero como me enseño mi amigo Jesús en programación normalmente a problema puede abordarse de varias maneras, que sean más o menos efectivas ya depende del programador, su experiencia y lo que quiera arriesgar. Como ya dije no pienso poner esta vez el programa ni módulos completos, sólo es la teoría de como debe funcionar un TPV. Que tengáis buen día.
__________________
Un saludo desde Canarias, "El abuelo Cebolleta" |
|
|
Temas Similares | ||||
Tema | Autor | Foro | Respuestas | Último mensaje |
Teoría del Infierno | fidel | Humor | 5 | 28-10-2016 01:00:14 |
Teoria y Practica | jcarteagaf | Humor | 0 | 18-08-2008 16:32:34 |
Teoría sobre Archivos de Recursos | MaMu | OOP | 3 | 15-04-2008 12:36:31 |
Frameworks, Persistencia: ¿Teoria? | Delphius | OOP | 8 | 12-04-2008 23:27:24 |
Teoría del Salario | obiwuan | Humor | 0 | 06-05-2003 22:00:43 |
|