Inventario, ventas y cierre de caja para restaurantes y tiendas

En una línea

Un sistema que sabe cuánto tienes en cada sede, descuenta insumos por receta y le deja al contador el archivo listo. Hoy es una demo funcional lista para un piloto. Todavía no hay un cliente operando con él, y lo digo desde el principio.

Contexto

Primero construí el sistema de inventario de mi propia tienda, Empire Essence, para no pagar un CRM externo. Funcionaba para un solo negocio y con campos de perfumería. Cuando empecé a hablar con dueños de restaurantes y tiendas, escuché el mismo dolor una y otra vez. Ahí nació Restocore: un producto aparte, pensado desde el comienzo para varias sedes y varios tipos de negocio.

Dos prospectos me ayudaron a darle forma:

• Un grupo de restaurantes con varias sedes. Usaban un software que no les cumplía y buscaban opciones antes de que se les venciera el contrato.
• Una tienda de repuestos para cascos. Vendía en mostrador y llevaba el inventario y el cierre de caja a mano.

El problema

Los dos negocios son distintos, pero se quejaban de lo mismo:

• No saben cuánto tienen en cada sede sin ir a contar.
• El cierre de caja se hace en cuaderno o en Excel, y nadie lo puede revisar después.
• El contador recibe los datos tarde y desordenados.
• En el restaurante, cada plato vendido debería descontar sus ingredientes. Hoy nadie lo hace, así que las pérdidas no se ven.

Lo que pidió el restaurante, palabra por palabra: estabilidad, inventario robusto, compras, una base de clientes para domicilios y una pantalla fácil de manejar.

El enfoque

Antes de escribir código decidí qué no construir. Un POS con facturación electrónica ante la DIAN no se hace desde cero: es regulado, caro de mantener y ya existen proveedores autorizados. Restocore trabaja al lado del POS, no en su lugar. Importa las ventas del POS por archivo y se encarga de lo que el POS no resuelve bien: inventario, recetas, compras, cierre y datos limpios.

Segunda decisión: un solo código para dos tipos de negocio. Cada instalación escoge su modo. Restaurante usa recetas, domicilios y sugerido de compra. Tienda usa variantes con SKU y venta de mostrador. Así cada mejora sirve a los dos.

Tercera decisión: la IA solo donde ahorra trabajo real, y siempre con una persona al final. El ejemplo es la lectura de facturas.

Qué construí

• Inventario por sede con kardex: cada entrada y salida queda registrada con quién la hizo.
• Ventas de mostrador o por receta, con descuento automático de insumos.
• Compras, costo promedio y sugerido de compra.
• Cierre Z guardado por sede y por día.
• Importación de ventas del POS por archivo.
• Usuarios con roles. Administrador, caja y bodega. La caja no ve costos ni puede borrar movimientos. Cada usuario solo ve las sedes que tiene asignadas.
• Respaldos diarios con restauración probada en pruebas automáticas.
• Exportación a Excel para que el dueño saque sus datos sin pedirme permiso.
• Comprobante de ventas para el contador, en beta. El formato final se confirma con el contador de cada cliente.
• Un agente que lee la factura del proveedor, en foto o PDF, valida NIT, sumas, IVA y cantidades, y propone la compra. Una persona la revisa lado a lado y la confirma. Nada se guarda sin esa confirmación.
• Un instalador para el computador o servidor del cliente, con respaldo y forma de revertir una actualización.

Cierre del día, exportaciones y respaldos

Cierre Z. Un cierre por sede y por día: totales por medio de pago (cinco medios), ventas, descuentos, base, efectivo contado, la diferencia y quién cerró. Una vez guardado, las ventas posteriores de ese día quedan bloqueadas, y una venta y un cierre no se pueden cruzar. Los cierres anteriores quedan para consulta.

Comprobante para Siigo (beta). Para el contador: un comprobante contable diario por sede y rango de fechas, con débitos por medio de pago y créditos a ingresos e IVA, controlado contra la Z guardada. Hasta 500 filas por Excel sin partir un día, y un ZIP cuando son varios. Faltan la plantilla del contador y la prueba de importación en Siigo, por eso sigue en beta.

Exportar a Excel. Inventario, movimientos por fechas, compras, ventas y recetas, con números, fechas y pesos en formato real. Solo el administrador.

Respaldos. Una copia diaria consistente por la API de SQLite, con verificación de integridad y rotación de 14 días. En Windows, una tarea programada a las 12:30 y al iniciar sesión, más una copia verificada con SHA-256 a una carpeta sincronizada (OneDrive o Drive). El comando de restauración pide confirmación, valida el archivo y revoca las sesiones. Una prueba automática crea datos, respalda, borra movimientos y restaura el contenido exacto.

Importación del POS. El administrador sube el CSV o XLSX del POS (hasta 5 MiB), mapea las columnas una vez por sede, empareja los productos con equivalencias guardadas, revisa una vista previa (totales, descuentos, negativos, productos sin receta, líneas rechazadas y duplicadas) y confirma en una sola transacción. Cada línea lleva una huella para no importarse dos veces, y la importación completa se puede deshacer con movimientos de ajuste.

Fuera del alcance, a propósito. La facturación electrónica y el POS siguen con un proveedor autorizado. No se procesan pagos. Una instalación por empresa.

Demo y estado

• Estado: demo funcional, lista para piloto. Datos ficticios.
• Pruebas: 396 pruebas automáticas aprobadas.
• Seguridad: dos revisiones adversariales. La última, del 19 de octubre de 2026, no encontró hallazgos críticos ni altos. Los medios y bajos se corrigieron.
• Pendiente: el ensayo de instalación en el equipo real del primer cliente y la medición del agente de facturas con facturas reales.

La propuesta para el primer cliente arranca con una sede piloto y 30 días de medición. Con esos números se decide si se amplía a las demás.

Lo que aprendí

• Una revisión honesta vale más que una propuesta bonita. La primera versión de mi propuesta prometía inicio de sesión, respaldos y exportación que el producto no tenía. Una revisión adversarial lo encontró antes de enviarla. Construí esas piezas antes de prometerlas.
• Decir qué no haces da confianza. Cuando explico que no reemplazo el POS ni la facturación electrónica, el dueño se relaja. Sabe que no le voy a cambiar todo.
• Los datos del cliente mandan. El formato contable, las reglas del cierre y las recetas se confirman con su gente. Yo no las adivino.

Qué se rompió y cómo lo encontré

• Mi primera propuesta prometía cosas que el producto no tenía. Inicio de sesión, respaldos y exportación a Excel estaban en la propuesta antes de existir en el código. Una revisión adversarial de la propuesta (7 de octubre de 2026) lo atrapó antes de enviarla. Construí esas piezas, con pruebas, antes de volver a prometerlas.
• La revisión de seguridad encontró puertas abiertas. El 12 de octubre la revisión encontró que no había límite al tamaño de las peticiones HTTP, ni autorización por sede, y que las sesiones sobrevivían al cerrar sesión. Corregido: límite de 256 KiB por petición, cada usuario ve solo sus sedes, sesiones revocadas al salir y al cambiar rol o clave, espera progresiva ante intentos fallidos. La evidencia de antes y después quedó en el proyecto.
• La importación del POS y el agente de facturas tenían siete hallazgos. Una segunda revisión adversarial, el 14 de octubre, encontró siete problemas en el manejo de archivos (tamaño, tipo, filas descomprimidas). Los siete corregidos, con 33 pruebas de regresión.

¿Tu negocio tiene este dolor?

Si llevas el inventario en Excel o en un cuaderno, o si tu cierre de caja depende de una sola persona, hablemos. Te muestro la demo sobre tu caso antes de cotizar nada.

Escríbeme por LinkedIn