App-Tpv: Proceso de Ventas
La segunda opción del menú que desarrollaremos es la de entrada de ventas. Es la más importante de la aplicación y también la que valorará más el cliente final, porque es la que conlleva el 90% del tiempo que los usuarios están en la aplicación.
Al entrar en la pantalla de ventas, en caso de que esté activado el indicador de la tienda de “$TPV_aPostie[‘postie_sw_usua_venta’]==1”, hemos de pedir siempre el usuario en pantalla:
Nos enseñará el código de usuario actual de la sesión, y nos permitirá cambiarlo. Si el usuario es el mismo que el usuario de la sesión, no pediremos el password, pero si es diferente sí que hay que pedirlo y validar en la tabla “pesusutie” que el usuario tiene acceso a la tienda en curso.
Una vez seleccionado el usuario, se validará que exista una “entrada” del mismo en la tabla “posusumov” en el día en curso, y si no hay entrada hemos de pedir una confirmación en pantalla:
Una vez seleccionado, se debe cambiar el identificador del usuario “en curso” comentado en el login.
Una vez pasadas estas validaciones, la entrada de ventas actual se ve tal que así:
El caso más habitual es escribir directamente la referencia del producto a buscar, para lo cual el usuario tiene actualmente tres formas de búsqueda: F3-por código de acceso, F4-por referencia (código principal del producto o sku), F5-por descripción. En la nueva aplicación lo práctico es que, al escribir lo que conozca del producto el usuario, el programa enseña un look-up de los productos localizados, buscándolos por los tres criterios juntos, por acceso, por referencia, y por descripción. Según como se desarrolle la fase de test de esta parte con el cliente, es posible que añadamos algunos parámetros de configuración para definir la manera en que deben ejecutarse estas búsquedas (qué campos a buscar, y si es solo por comienzo o por contenido en cualquier parte).
El look-up que debe aparecer debe tener este formato:
Este listado se obtiene de la tabla de Quartup “posarttic_v”, la cual ya retorna la descripción en el idioma del usuario/tienda, y los precios configurados en la tienda. El constructor de esta tabla de Quartup debe llamarse con los siguientes parámetros: posarttic_v(POSTIE_ID:xxx,CLASE_HABITUAL:H,COMPRA_VENTA:FV)
El valor “xxx” debe sustituirse por el ID de la tienda en curso. El indicador “CLASE_HABITUAL” hace que solo nos enseñe la clase habitual. El indicador “COMPRA_VENTA” hace que solo nos enseñe los productos vendibles en facturas.
Importante: fijaros que en la columna “precio” aparece el valor del precio y al lado una letra “N” que se llama “clase de venta”. La clase de venta es la que marca el precio del producto. Muchos productos tienen una sola clase de venta (la “N” llamada “clase normal”) y por tanto un solo precio, pero algunos productos tienen dos clases de ventas, pero las clases adicionales no aparecen en la lista, pero se podrán seleccionar después. Un ejemplo típico de producto con dos clases es la reparación de calzado, el producto es único y las clases son “H” para “hombre” y “M” para “mujer”.
Una vez seleccionado el producto, se asignarán los siguientes campos en la línea:
- Producto = cod_articulo (el campo a grabar en el fichero es el id_maesarti)
- Descripción = nombre
- Clase = posartcla_id
- Precio = posarttic_prec_mone
- Descuento = posarttic_dto_ofe (hay otros dtos. en la vista, pero se usan más adelante)
- Cantidad = GREATER(1, posarttic_cant_fija) se visualizarán los datos como se ve en la pantalla siguiente, y se pedirá la cantidad de la venta (el campo “cantidad” agarrará el foco automáticamente):
Desde la cantidad, es posible retroceder a la clase y cambiarla (el usuario está acostumbrado a retroceder con la “flecha arriba” y avanzar con el “intro” o “flecha abajo”, si es posible sería bueno conservar este formato). Si se cambia la clase, hay que volver a leer la tabla, pero cambiando el indicador de clases: posarttic_v(POSTIE_ID:xxx,CLASE_HABITUAL:T,COMPRA_VENTA:FV) Y filtrando con los campos: id_maesari / posartcla_id
Si no existe registro (si existe será único) se enseñará mensaje de que la clase no es usable:
Si existe registro, se cambiará el precio y el descuento por el que proceda. Si el campo “posarttic_sw_prec_modi” tiene el valor 1, entonces el campo “precio” es modificable, y después de la edición del campo “clase” (pero solo en estos casos del indicador a 1) se debe permitir modificar el campo “precio”. En caso de que se modifique el campo “precio”, nunca deberá ser inferior al “posarttic_prec_mone”. En caso de que esté activado el indicador “posarttic_sw_precio_0” al valor 1, entonces permitiremos el precio 0.
En caso de que el precio sea modificable, también se permitirá modificar el campo “descuento”. En caso de que haya un descuento máximo (campo “posarttic_dto_max” diferente de cero), se debe validar que el descuento introducido no sea superior al máximo. Si el dto máx es cero, no validaremos el campo descuento, y el usuario podrá entrar cualquier valor hasta 100. Sea como sea, el valor máximo del descuento es 100.
En caso de que se informe de un descuento, es necesario que el usuario lo valide por seguridad:
Los ficheros donde hay que grabar la preventa son los siguientes:
posprecab (cabeceras de preventas), con los campos (solo informamos de los campos que hay que informar al grabar, el resto se llenan con valores por defecto):
- cod_serie, código de serie extraído de la tienda postie.cod_serie_fv, obligatorio informarlo
posprelin (líneas de preventas), con los campos (solo informamos de los campos que hay que informar al grabar, el resto se llenan con valores por defecto):
- cod_serie, el mismo de la cabecera
- posprecab_id, nº de preventa, el mismo de la cabecera
- posartcla_id, ID de la clase
- id_maesarti, ID del producto
- posprelin_desc, descripción del producto
- posprelin_cant, cantidad
- posprelin_prec_mone, precio moneda
- posprelin_prec_euro, precio euro
- posprelin_dto_lin, % descuento
La cabecera solo la grabaremos al crear la primera línea, para evitar cabeceras temporales innecesarias.
Cerrar líneas de tiquet.
Después de entrar todos los productos de la venta, para empezar el cierre del tiquet, tenemos dos posibilidades: cerrar con cliente (F9) y cerrar sin cliente (F10):
Las pantallas con cliente y sin cliente son la misma, pero la posición del cursor es diferente en cada caso:
En la primera versión que haremos, fusionaremos las dos maneras de cerrar el tiquet, y siempre enviaremos el cursor al campo cliente. Si el usuario no quiere cliente, validará (con “intro” ?) y saltará al bloque de cobros. Si pulsamos “escape” retrocederemos de nuevo al bloque de “cliente”. Y si pulsamos “escape” desde el bloque de “cliente” retornaremos a las líneas. De esta manera la tecla “escape” es la tecla estándar de retroceso.
La entrada del “cliente” tendrá un look-up similar al de productos, pudiendo buscar por CIF o por nombre, y se buscará sobre la tabla “poscli”.
Móviles y Matrículas.
En la tabla posarttic_v se han añadido dos campos nuevos con el posible valor 0/1: posart_sw_matricula posart_sw_movil
Cuando alguno de estos indicadores está activado a 1, se deben pedir ciertos datos en un formulario específico.
Datos a entrar cuando está activado el indicador de matrículas. (se deben guardar en la tabla posdatmat):
Datos a entrar cuando está activado el indicador de móviles. (se deben guardar en la tabla posdatmov):
Reembolsos.
Desde la pantalla de inicio de tiquet, y solo cuando no hay ningún producto todavía, se puede activar una opción de reembolso: que pide lo siguiente (esto se graba en la tabla pospreree):
Después de entrar el tiquet a reembolsar, según la fecha del tiquet, se saca un aviso:
Y después de la información de orígen y cliente, nos permite confirmar las cantidades del tiquet original que se reembolsa:
Después de entrar las cantidades (lo único que se puede entrar), se confirma con F10:
Al confirmar, se crea una preventa, de la cual solo se pueden cambiar las cantidades:
Pero sí se pueden añadir más líneas, siempre en positivo:
Con esto podemos cerrar el tiquet. Pero al cobrar, si el total es negativo, en la forma de cobro se debe asignar “vale de devolución”, y solo permitir vales o efectivo:
Además, hay que pedir confirmación del vale de devolución:
En caso de que no se permitan vales (por fecha antigua) se debe avisar también:
Y solo permitirá entrar forma de cobro de oficinas:
Y se debe confirmar también:
Detalle de las validaciones de las formas de pago del tiquet:
- Solo se permiten las formas de pago de sw_fac/sw_ree según si el tiquet es positivo o negativo, respectivamente
- Si la forma de cobro tiene activado el sw_efectivo=1 o sw_vale=2 y es un tiquet positivo, entonces se permitirá entrar un importe que supere el del tiquet. En cualquier otro caso, no se permitirá que se supere
- Si el tiquet es positivo, dejaremos cerrar solo con un cambio positivo
- Si el tiquet es negativo, dejaremos cerrar solo con cambio cero
- Si la forma de cobro tiene activado el sw_avisar=1, entonces se generará un mensaje al seleccionarse, para evitar que el usuario lo haya seleccionado por error
En el histórico de tiquets, se verá que es un reembolso por tener un orígen:
