teoría de un TPV

[Ñuño Martínez]

Una magnífica iniciativa, José Luís. Ahora tengo un poco de prisa, pero quizá más adelante aporte yo también algo.

[[José Luis Garcí]]

Empezado por Ñuño Martínez

Una magnífica iniciativa, José Luís. Ahora tengo un poco de prisa, pero quizá más adelante aporte yo también algo.

Perfecto entre más ideas y opiniones mejor.

[[José Luis Garcí]]

intento subir un vídeo pequeño hecho de mi programa como ejemplo espero se pueda ver

[Casimiro Notevi]

[[José Luis Garcí]]

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.

[[José Luis Garcí]]

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.

[[José Luis Garcí]]

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.