teoría de un TPV

[[José Luis Garcí]]

Necesidades de un TPV: en este caso voy a tratar sobre un TPV, bastante especifico para una cafetería, piscolabis, bar, etc.
En un tpv de estas características puede hacerse con pantallas livianas o pesadas, me refiero con esto a que tenga pocas o muchas opciones, de que va a depender esto, pues de las necesidades del cliente, pongamos ejemplos para entenderlo mejor:

Caso 1 nuestro cliente es un restaurante, donde los camareros tienen un terminal o incluso terminales portátiles, el gerente tiene su propio terminal, la cocina tiene otro y por último la caja tiene el suyo propio, en este caso:
El camarero. solo necesita los productos, y la ubicación de las mesas y si acaso pasar notas a cocina o caja para la cuenta, el resto le sobra.
El gerente necesitará saber la entrada y salida de productos, los pedidos, el balance de como va el día etc.
En cocina necesita saber los pedidos y si existe alguna anotación sobre ese pedido, ejemplo que el cliente sea alérgico a un alimento o condimento
La caja sólo necesita tener control de los tickets y del dinero y cobros, sean por talones, vales, cupones, tarjeta, efectivo, etc.

Caso 2 Tenemos un bar con servicio de plancha y algo de cocina, pero trabajan la mujer y el marido únicamente
En este caso lo más probable es que necesiten una pantalla que les permita hacer todo (o casí) para no tener que perderse en múltiples pantallas.

En el caso 1 necesitamos varias pantallas adecuadas a cada puesto (livianas) en cambio en el segundo caso necesitamos una pantalla genérica con casi todas las opciones (pesada).

Esto no tiene nada que ver con la rapidez y funcionalidad del programa, ya que de ello va a depender de como lo planteemos y lo codifiquemos, según mi humilde opinión después de haber tenido un bar con cocina, la situación en el mismo eran las siguientes

1: El bar tenia varias horas muertas, en las que había muy pocos clientes o no había clientes.
2: El bar tenia sus horas (desayunos, almuerzos y medias tardes) en que entraban varias personas y se animaba algo pero eran periodos de 2 horas a 3 horas como mucho, el trabajo era más intensivo, pero sin agobiar.
3: El bar tenia algún evento cercano y la entrada de clientes era bastante fluida
4: El bar estaba junto a la entrada del estadio de fútbol, la entrada horas antes y después del partido eran brutales, podías tener ochenta o más pedidos a la vez, en estos casos era estresante y necesitaba personal auxiliar

claro según fuese el día y la situación necesitabas mayor o menor rapidez y el software que tenia no era precisamente super veloz, se trataba de un software que no tenia imágenes y con muy pocas opciones, poco atractivo y aunque en principio parecía que sería rápido resulto no ser lo suficiente el software tenía las siguiente opciones.

8 colores para distinguir las familias y artículos
Nombre, familia y precio del artículo
Total de ventas
No tenía password ni de acceso y ni de nada

sencillo y rápido pensé yo, claro los problemas eran los siguientes

Tenia múltiples pantallas de bebidas, con lo que buscar una en un momento determinado se volvía una locura y como lo único que podías era poner un color y el texto y por pantalla podías tener 24 artículos y muchas veces eran casi idénticos, ejemplo (chupito Ron Telde, Vaso Ron Telde, Chupito Ron Abana oro, vaso Ron Abana oro, etc) y eso sólo el ron que podía ser color malva y tenia 8 tipos de ron diferentes y se pedían en los diferentes formatos que estaba puesto, pues los fui creando según se iban pidiendo, salvo algunos que eran más genéricos y los cree de entrada. Esto lo hacía tedioso y lento

A la hora de cobrar te preguntaba el importe entregado por el cliente, sacaba el calculo de la devolución y preguntaba si imprimir ticket, despues de esto si optabas o no por imprimir el ticket, abría el cajón, imprimía el ticket (si habías decidido hacerlo y mantenía la pantalla 5 segundos +/- con el importe de la consumición, el entregado por el cliente y la devolución no permitiendo hacer nada durante este tiempo, lo cual paralizaba bastante.

Principalmente estos factores, junto con no controlar el stock, que al sacar el cierre si le decías imprimir te lanzaba todos los ticket y no tenia opción de un resumen y que no tenia configuración salvo para los datos de la empresa, el no tener control de clientes, etc, demostraron la mala elección del programa, pero no me voy a a quejar. (a toro pasado)

según siempre mi opinión una de las mayores faltas en lo programas de TPV son la de diferencias diversos modos de trabajo y la de tener la opción de familias y productos únicamente Sobre este último time trataré en el siguiente hilo.

[Ñ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í]]

Tratando la pantalla principal del TPV trataremos el combate entre

(1)Familias y productos contra (2)Familias. Subfamilias y productos

Ventajas e inconvenientes de cada sistema:

Ventajas de 1, menos pulsaciones, Desventajas caos de productos y probablemente múltiples pantallas de una familia
Ventajas de 2, mas control y mejor visualización de los datos, Desventajas, que como mínimo habrá que pulsar una vez más

veamos como podemos organizar los siguientes grupos de artículos ( lo que encontréis entre paracentesis será el número de artículos relacionados a este grupo que puede contener ejemplo cerveza (botellin marca 1, botellin marca 2, botella marca 1, botella marca 2, botella marca 1 sin alcohol, botella marca 2 sin alcohol, media caña, caña, caña grande))

Menús (4), Primeros(20), segundos(20), aguas(6), refrescos(4), zumos(3), batidos(6), helados(10), hamburguesas(4), perritos(3), entrantes(20), vinos(8), rones(6), cervezas(10), coñacs(3), whisky(4), Ginebra(3), Cremas(2), Licores(4), Tequila(2) bocadillos(10), Cafés(10), sandwiches(4), patatas de paquete(3), chicles(12), chocolates(5), flanes(2), fruta(1), bollería(6), etc

Priero definiremos que en un pantalla nos puede mostrar unos 16 artículos a la vez

Hagamos un árbol de familias para el sistema 1 y su contenido

Comidas con (Menús (4), Primeros(20), segundos(20), entrantes(20), helados(10), flanes(2), fruta(1))=77 artículos/16= 5 pantallas
Bebidas alcohólicas con (vinos(8), rones(6), cervezas(10), coñacs(3), whisky(4), Ginebra(3), Cremas(2), Licores(4), Tequila(2))=42 artículos/16= 3 pantallas
Otras Bebidas con ( aguas(6), refrescos(4), zumos(3), batidos(6),Cafés(10))=29 artículos/16= 2 pantallas
Golosinas con ( patatas de paquete(3), chicles(12), chocolates(5))=20/16 = 2 pantallas
Bollería y bocadillos (bocadillos(10), , sándwiches(4), , bollería(6))=20/16= 2 pantallas
Comida rápida (hamburguesas(4), perritos(3))=7/16= 1 pantalla

Hay que tomar esto como lo que es un ejemplo ya se que podríamos dividirlo más para que quedara más disuelto, e incluso poner parte de los artículos de bebidas alcohólicas en otras bebidas (algunos licores y cervezas sin ) y viceversa (café irlandés), pero creo como ejemplo queda claro y eso que faltan muchísimos artículos, como pizzas, burritos, bebidas, postres etc.

Hagamos el árbol de familias del sistema 2, recordad que tiene subfamilia y dentro de esta los artículos

Comidas con (Menús (4)/16=1 pantalla
Primeros(20)/16=2 pantallas
segundos(20)/16=2 pantallas
entrantes(20)/16=2 pantallas
helados(10)/16=1 pantalla
flanes(2)/16=1 pantalla
fruta(1)/16=1 pantalla )
)

Bebidas con (vinos(8)=1 pantalla
rones(6)=1 pantalla
cervezas(10)=1 pantalla
coñacs(3)=1 pantalla
whisky(4)=1 pantalla
Ginebra(3)=1 pantalla
Cremas(2)=1 pantalla
Licores(4)=1 pantalla
Tequila(2)=1 pantalla
aguas(6)=1 pantalla
refrescos(4)=1 pantalla
zumos(3)=1 pantalla
batidos(6)=1 pantalla
Cafés(10)=1 pantalla)

Golosinas con (patatas de paquete(3)=1 pantalla
chicles(12)=1 pantalla
chocolates(5)=1 pantalla)

Bollería y bocadillos con (bocadillos(10)=1 pantalla
sándwiches(4)=1 pantalla
bollería(6)=1 pantalla)

Comida rápida con (hamburguesas(4)=1 pantalla
perritos(3)=1 pantalla)

Como podemos ver podemos ver los artículos casi siempre en una única pantalla, salvo excepciones, por lo que será visualmente más rápido, pongo una imagen para que quede más claro

Primero veamos una cogida al azar de internet del sistema 1 (espero no vulnerar derechos algunos, la pongo a modo de ejemplo simplemente)



y ahora del sistema que yo propongo el 2




Realmente no se si existen en usos ya este sistema en otros TPV, de momento yo no lo he visto.

Debo de de decir que ambos sistemas consiguen el mismo fin, pero personalmente creo que es mucho más rápido el 2 que el primero.

Por hoy no voy a seguir pero hay aun un puñado de temas que creo deberían tocarse y procurare hacerlo en los próximos días.