Ventas por caja

2 comentarios

Cuando diseñamos una Base de Datos que será usada para guardar (entre otros) los datos de las ventas realizadas en las cajas (caso típico de un supermercado) debemos tomar en consideración los siguientes puntos:

  1. No debemos preocuparnos por verificar si hay suficiente cantidad en stock del producto vendido. ¿Por qué no? porque la prueba de que hay suficiente cantidad del producto está en las manos del cliente.
  2. Debemos prever el uso de tablas locales. Si por algún motivo la red dejara de funcionar eso no debería evitar que desde las cajas se sigan registrando las ventas.  Más tarde, cuando la red vuelva a funcionar, se actualizarán las tablas remotas y se vaciarán las tablas locales, de ser necesario.
  3. Mientras una caja está usando tablas locales cualquier cambio en el precio de venta de un producto realizado en el Servidor no será conocido por la tabla local y lo mismo ocurrirá si se agregan nuevos productos para la venta. Por lo tanto en algún momento habrá que correr un proceso de actualización para que el contenido de la tabla local de PRODUCTOS coincida con el contenido de la tabla remota de PRODUCTOS.
  4. La tabla local no puede ser borrada sino hasta después de imprimir y de confirmar la impresión del “zeta”. Se llama “zeta” a los datos que se imprimen cuando se cierra la caja, entre ellos: fecha, hora, cantidad total de productos vendidos, cantidad total de productos devueltos, importe total vendido, importe total devuelto, impuestos a pagar, etc. Por una cuestión de seguridad y de auditoría es conveniente que aún después de imprimir la “zeta” los datos de los productos vendidos y devueltos permanezcan en la tabla local durante algunos días.
  5. Cuando un cliente después de registrarse la venta de un producto desiste de su compra (quizás porque no le alcanza el dinero) se marca ese producto como borrado pero en la Factura que se entrega al cliente se imprimen el producto y su correspondiente negativo. Así mismo en la tabla de ventas se registran la venta de ese producto y su devolución.
  6. Cuando una venta se cancela totalmente (quizás porque el cliente se dio cuenta que no tenía dinero) se procede como en el punto 5, para todos y cada uno de los productos.
  7. En la tabla de detalles de movimientos de ventas se debe tener una columna donde guardar la fecha y hora de la venta (o de la devolución) de cada producto. De esta manera se podrá conocer exactamente lo que sucedió en cada caja, segundo a segundo.

Tamaño de la tabla local de PRODUCTOS

Para que una caja pueda continuar registrando ventas aunque se haya cortado la conexión con el Servidor es requisito que tenga una tabla local con los datos de los productos que puede vender (identificador, código de barras, nombre del producto, precio de venta). Normalmente esas columnas ocuparán menos de 100 bytes. Un supermercado no suele tener más de 60.000 productos distintos para vender. Entonces, 60.000 productos por 100 bytes de cada producto nos da un total de 6.000.000 de bytes para la tabla de PRODUCTOS. En esta época eso es casi nada.

Tamaño de la tabla local de detalles de VENTAS

El tamaño de cada registro de la tabla de detalles de las ventas debe ser inferior a 50 bytes (identificador del detalle, identificador de la cabecera, identificador del producto vendido, cantidad vendida, precio de venta, fecha y hora de la venta o devolución, marca de “zeteado” o sea que se cerró la caja). Suponiendo que se realice una venta por minuto durante las 24 horas del día y que en cada venta haya una promedio de 10 productos, tendremos: 1440 ventas por 10 productos en cada venta por 50 bytes en cada registro, es igual a: 720.000 bytes. Poquísimo.

Consideraciones con las tablas locales

  1. La tabla de PRODUCTOS debe ser actualizada periódicamente para tener siempre registrados en ella los nuevos productos y los precios de venta actualizados. Generalmente lo más adecuado es hacer esto como primera tarea del día. El programa de ventas verifica si la fecha de la tabla PRODUCTOS es igual a la fecha actual. Si no es así, actualiza la tabla de PRODUCTOS. Esto debería ser cuestión de segundos, jamás debería tardar más de uno o dos minutos.
  2. Por seguridad y auditoría, es conveniente que la tabla detalles de VENTAS tenga los datos de los últimos 7 días, entonces si algún problema ocurre en el Servidor se pueden reconstruir las ventas realizadas en cada caja. Más de 7 días es innecesario porque se supone que habrá backups más nuevos.

Impresión de la Factura para el cliente

Una medida de seguridad es ir imprimiendo la Factura a medida que se van registrando los productos. Cuando se registra el primer producto de una venta se imprimen la cabecera de la Factura y los datos de ese primer producto. Cuando se registran los datos de otro producto (o una devolución) se imprimen los datos de ese producto o de esa devolución. Y así sucesivamente hasta cerrar la venta, en cuyo momento se imprimen los totales, los impuestos, etc. De esta manera nos aseguraremos que TODO lo que se hizo en una caja se registró en nuestras tablas y también se imprimió en papel. Para la auditoría, esto es excelente.

Artículos relacionados:

Registrar los cambios a los precios de venta

El manejo de los precios de costo y de venta

Registrando los productos borrados

El índice del blog Firebird21

Anuncios

Registrando los productos borrados

5 comentarios

Cuando se están cargando los datos de una venta el usuario (quizás cajero) va registrando ítem tras ítem los productos vendidos y la cantidad vendida.

¿Pero qué sucede si el cliente después de haberse hecho el registro decide que no va a llevar ese producto, quizás porque no tiene suficiente dinero?

Supongamos el caso de un supermercado: mientras se van registrando los productos vendidos y las cantidades vendidas, el cliente decide que no llevará uno de los productos. Normalmente en esos casos se llama al “Supervisor de cajas” o “Jefe del salón de ventas” quien introduce su clave de acceso con la cual se le permite borrar los productos no deseados por el cliente.

¿Pero cómo registramos esa acción en nuestras tablas de ventas?

Una posibilidad es guardar solamente los productos efectivamente vendidos. El problema con esto es que no quedarán registrados los productos que se borraron ¿Y es importante tenerlos registrados? Pues sí, porque eso le permitirá al Gerente o al propietario del supermercado detectar fácilmente y rápidamente todas las ventas donde se borraron productos. Si no tuvieran esa información entonces no podrían saber con cuanta frecuencia se borran productos, cuales son los productos que más se borran, quienes son los cajeros que más problemas tienen, etc.

Operativamente nuestra aplicación de ventas debería funcionar así:

  • Cuando se registra el primer producto vendido se imprime la cabecera de la Factura y los datos de ese primer producto
  • Cada vez que se registra un producto, se imprimen sus datos
  • Cuando se borra un producto, se imprimen sus datos
  • Cuando se cierra la venta, se imprimen los totales, los impuestos, y toda la demás información relevante

Alternativamente, se puede dejar la impresión de la Factura para el final, después de haberse cerrado la venta, pero siempre en ella deberían imprimirse los datos de los productos borrados.

Si una venta se cancela totalmente (quizás porque cuando iba a pagar el cliente se dio cuenta que no tenía dinero consigo), debe quedar registrada esa cancelación.

De esta manera TODO lo que se hizo en la computadora del cajero quedará registrado en nuestras tablas y podremos reconstruir lo que sucedió en ella, segundo a segundo.

Para poder conseguir esto último es requisito que una de las columnas de nuestra tabla de detalles de movimientos de ventas corresponda a la fecha y a la hora en la cual se registró la venta de ese producto.

Artículo relacionado:

El índice del blog Firebird21