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