FTP | CCD | Buscar | Trucos | Trabajo | Foros |
|
Registrarse | FAQ | Miembros | Calendario | Guía de estilo | Temas de Hoy |
|
Herramientas | Buscar en Tema | Desplegado |
|
#1
|
||||
|
||||
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" |
#2
|
||||
|
||||
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" |
#3
|
||||
|
||||
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" |
#4
|
||||
|
||||
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" |
#5
|
||||
|
||||
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" |
#6
|
||||
|
||||
Gracias por la clase, magistral y cercana, como siempre.
Un saludo
__________________
Cuando los grillos cantan, es que es de noche - viejo proverbio chino - |
#7
|
||||
|
||||
Fantástica explicación.
Gracias.
__________________
Germán Estévez => Web/Blog Guía de estilo, Guía alternativa Utiliza TAG's en tus mensajes. Contactar con el Clubdelphi P.D: Más tiempo dedicado a la pregunta=Mejores respuestas. |
|
|
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 |
|