Product Requirements Document · v1.0

Inventory & E-Procurement Hub

Sistema autónomo de gestión e inteligencia de inventarios para restaurantes: captura facturas del SII, aprende las recetas reales, automatiza las compras B2B y protege el margen en tiempo real.

AutorAnder · Product

EstadoMVP desplegado (v0.1)

Última rev.20 jul 2026

StakeholdersProducto · Ing · Finanzas

Contenido

1 Resumen ejecutivo 2 Contexto y problema 3 Visión, objetivos y no-objetivos 4 Usuarios y personas 5 Casos de uso e historias 6 Alcance funcional por módulo 7 Motor de aprendizaje continuo 8 Integraciones 9 Requisitos no funcionales 10 Roles y permisos (RBAC) 11 Métricas de éxito 12 Roadmap y fases 13 Riesgos y mitigaciones 14 Supuestos, dependencias y preguntas abiertas 15 Glosario

1Resumen ejecutivo

El Hub es el cerebro operativo del restaurante. Elimina la digitación manual capturando las facturas electrónicas (SII), convierte cada compra en inventario aplicando rendimiento (yield), aprende matemáticamente cuánto consume realmente cada plato y usa ese conocimiento para calcular el food cost real, disparar alertas de fuga, reponer stock y armar pedidos B2B que se envían por WhatsApp. Cierra el ciclo financiero transformando facturas en cuentas por pagar y generando la nómina bancaria.

Propuesta de valor en una frase: el dueño deja de perseguir números; el sistema le dice en tiempo real cuánto cuesta de verdad cada plato, a quién le debe, dónde se está fugando margen, y arma sus compras con un clic.

Modelo de negocio

Tres palancas de monetización: (1) SaaS por local (suscripción base del Hub); (2) Marketplace B2B — las marcas y distribuidores firman para publicar su catálogo y pagan por estar habilitados y por colocación destacada/patrocinada; (3) Add-ons Pro — funciones premium desbloqueables, como el ajuste de inventario por voz.

Estado actual

v0.1 desplegado en Vercel con base Neon: Dashboard, E-Procurement (envío WhatsApp en modo demo) y Cuentas por Pagar funcionales sobre datos reales. El prototipo de handoff cubre además Marketplace, QR de bodega, ajuste por voz Pro y las pantallas del motor (calibración, anomalías, forecast, copiloto). Este PRD define el producto completo hacia v1.0.

2Contexto y problema

Por qué los ERP de restauración actuales no bastan.

Los restaurantes operan con márgenes estrechos (food cost objetivo 28–32%) y pierden dinero por tres fugas invisibles:

Fuga	Descripción	Costo típico
Digitación manual	Transcripción de facturas a planillas: lenta, con errores, siempre atrasada. El costeo mira al pasado.	4–6 h/semana + errores
Food cost estático	Recetas costeadas una vez y nunca actualizadas. Cuando sube el insumo o baja el rendimiento, el margen se erosiona sin que nadie lo note.	2–4 pts de margen
Compra desordenada	Pedidos por teléfono/chats sueltos, sin catálogo ni precios pactados, sin registro ni control.	Sobreprecio + quiebres

Por qué ahora: la facturación electrónica obligatoria (SII) hace que los datos de compra ya existan en formato estructurado; las APIs de WhatsApp Business permiten el checkout B2B; y el costo de cómputo para calibración estadística en la nube es marginal. La oportunidad es conectar estas piezas en un sistema que aprende.

3Visión, objetivos y no-objetivos

Visión

Convertir la gestión de inventario de una tarea administrativa reactiva en un sistema de optimización continua que protege el margen automáticamente y opera por excepción.

Objetivos (SMART)

ID	Objetivo	Meta
OBJ-1	Eliminar la digitación de facturas	< 15 min/semana
OBJ-2	Costeo al día vs. realidad	Desfase < 24 h
OBJ-3	Detectar fugas de margen a tiempo	Alerta < 24 h del evento
OBJ-4	Formalizar las compras	> 90% de OC con precio pactado y registro
OBJ-5	Mejorar el margen bruto	+2.5 a 4.0 pts en 90 días

No-objetivos (fuera de alcance)

No es un POS propio: se integra con el POS existente.
No es contabilidad general ni facturación de ventas.
No ejecuta pagos ni mueve dinero: genera el archivo de nómina; el pago lo realiza una persona en el banco.
No gestiona reservas, personal ni nómina de RRHH.

4Usuarios y personas

Cinco roles; cada uno ve la información acotada a su función.

Dueño / Administrador

"¿El negocio está sano y dónde pierdo plata?"

Necesita: visión de food cost, alertas y deuda de un vistazo. Frustración: se entera de los problemas a fin de mes. Éxito: corrige desviaciones el mismo día.

Chef / Jefe de cocina

"Quiero pedir sin llamar a nadie y saber qué me está costando."

Necesita: armar pedidos rápido, resolver auditorías de estación, ajustar recetas. Frustración: pedidos por chat sin registro; recetas que no cuadran. Éxito: pedido en 1 min y food cost bajo control.

Encargado de compras

"Necesito precios pactados y buenos proveedores."

Necesita: catálogos, listas de precio negociadas, scorecard de proveedores. Éxito: compra al mejor costo total, no solo mejor precio unitario.

Finanzas

"Que nada se pague dos veces ni fuera de plazo."

Necesita: cuentas por pagar claras, aprobar la nómina antes de exportar. Éxito: cero pagos duplicados o atrasados.

Proveedor (externo)

"Recibir pedidos claros y confirmar rápido."

Necesita: integrar su catálogo, recibir OC por WhatsApp, confirmar. Éxito: menos errores de pedido y cobro puntual.

5Casos de uso e historias de usuario

Historias clave con criterios de aceptación (formato Gherkin).

US-01 · Ingesta automática de factura

Como administrador, quiero que las facturas del SII entren solas y actualicen el inventario, para no digitar nada.

Dado que llega un DTE del proveedor al SII
Cuando el sistema lo captura
Entonces mapea cada línea a un insumo, aplica el yield, suma stock y genera la cuenta por pagar — sin intervención manual.

US-02 · Pedido por WhatsApp

Como chef, quiero armar el pedido desde el catálogo y enviarlo por WhatsApp, para no llamar al proveedor.

Dado un carrito con precios negociados
Cuando confirmo el pedido
Entonces se crea la OC, se formatea el mensaje y se dispara al chat del proveedor, quedando en estado "Enviado".

US-03 · Alerta de fuga de margen

Como administrador, quiero que me avisen cuando un insumo desaparece sin ventas que lo expliquen, para actuar a tiempo.

Dado un residuo de consumo > 2.5σ no correlacionado con ventas
Cuando el motor lo detecta
Entonces emite alerta crítica y exige auditoría de estación, sin contaminar el aprendizaje de recetas.

US-04 · Aprobar nómina bancaria

Como Finanzas, quiero revisar y aprobar la nómina antes de exportarla, para controlar los pagos.

Dado una nómina propuesta por el sistema en estado DRAFT
Cuando la reviso y apruebo
Entonces pasa a APPROVED y solo entonces puedo exportar el archivo bancario.

6Alcance funcional por módulo

Cada módulo con sus requisitos funcionales (RF), reglas de negocio (RN) y prioridad.

6.1 Ingesta SII & AI Mapping / Yield SII

ID	Requisito	Prioridad
RF-SII-1	Capturar DTE del SII por webhook y guardar el payload original.	P0
RF-SII-2	Extraer líneas (PurchaseItem) tal cual vienen en la factura.	P0
RF-SII-3	Mapear cada línea a un Insumo con IA (fuzzy + histórico) y factor de conversión + % de yield.	P0
RF-SII-4	Cola de revisión para mapeos bajo umbral de confianza.	P1
RF-SII-5	Generar movimiento PURCHASE_IN y la cuenta por pagar automáticamente.	P0

RN: ingesta idempotente por (proveedor, folio, tipoDTE). Ejemplo de yield: 10 kg "Merluza Entera" × 1000 × 60% = 6.000 g de "Filete de Merluza". Aceptación: ≥ 90% de líneas mapeadas sin intervención.

6.2 Inventario & costeo por capas INV

ID	Requisito	Prioridad
RF-INV-1	Ledger append-only de movimientos; el saldo es la proyección.	P0
RF-INV-2	Costeo por capas (WAC/PEPS) para reconstruir food cost histórico.	P0
RF-INV-3	Ficha de insumo: ledger, capas, recetas asociadas, punto de reorden.	P1
RF-INV-4	Unidades canónicas por dimensión (masa→g, volumen→ml, unidad→un).	P0

6.3 Autocalibración & food cost dinámico CAL

Núcleo del sistema. Compara consumo teórico (ventas POS × recetas) contra stock real, calibra las recetas reales y hace el food cost bidireccional (sube si el precio del insumo sube o si el rendimiento baja). La descalibración proporcional castiga ponderadamente los platos que comparten un insumo faltante. Detalle matemático completo en §7 y el documento del Motor.

ID	Requisito	Prioridad
RF-CAL-1	Estimar recetas reales por NNLS regularizado + actualización online (Kalman).	P0
RF-CAL-2	Recalcular food cost real por plato en cada calibración.	P0
RF-CAL-3	Descalibración proporcional + exigir auditoría de estación al Chef.	P1

6.4 Detección de anomalías y fugas ANO

RN: distinguir sesgo sostenido (escala con ventas → error de porcionado, realimenta receta) de pico aislado ($|e|>2.5\sigma$ → fuga/robo, alerta y excluir del aprendizaje). Requisitos: RF-ANO-1 clasificación de residuo P0, RF-ANO-2 alerta inmediata P0, RF-ANO-3 exclusión robusta de la calibración P1.

6.5 Perecibilidad & markdown PER

Seguimiento por lote y caducidad; si la proyección no consume el lote antes de vencer, sugiere "Especial del Día" o descuento automático en canales digitales. RF-PER-1 lotes con SLA P1, RF-PER-2 markdown óptimo P2.

6.6 E-Procurement & WhatsApp EPR

ID	Requisito	Prioridad
RF-EPR-1	Catálogo del proveedor con lista de precios negociada por cliente/sucursal.	P0
RF-EPR-2	Carrito con validación de mínimos y disponibilidad.	P0
RF-EPR-3	Generar OC con código correlativo y congelar precio al confirmar.	P0
RF-EPR-4	Formatear y enviar por WhatsApp Cloud API; registrar wamid y estado.	P0
RF-EPR-5	Timeline de OC (Enviada→Confirmada→Recibida) y 3-way match con el DTE.	P1

RN: fuera de la ventana de 24 h de WhatsApp se usa una plantilla utility pre-aprobada de Meta.

6.7 Auto-procurement multi-proveedor AUT

Para insumos bajo el punto de reorden, optimiza la selección de proveedor por costo total (precio + merma histórica + penalización por lead time, sujeto a MOQ) y dispara la OC con aprobación configurable. RF-AUT-1 sugerencia de reposición P1, RF-AUT-2 optimización de proveedor P2.

6.8 Cuentas por Pagar & nómina AP

ID	Requisito	Prioridad
RF-AP-1	Cada factura genera una obligación con estado y vencimiento.	P0
RF-AP-2	Generar nómina bancaria de lo que vence en 7 días, en estado DRAFT.	P0
RF-AP-3	Flujo de aprobación DRAFT→APPROVED→EXPORTED (separación de poderes).	P0
RF-AP-4	Exportar archivo bancario (CSV / PAIN.001).	P1

6.9 Alertas & Supplier Scorecard ALR

Monitor 24/7 de precios disparados, rompimiento de precios pactados y compras a proveedores no habituales. Scorecard por OTIF y estabilidad de precios. RF-ALR-1 alertas de precio P0, RF-ALR-2 scorecard P1.

6.10 Multi-sucursal & transferencias MSU

Órdenes de transferencia para mover stock procesado desde la cocina central a sucursales sin facturación (TRANSFER_OUT/IN al costo). Rebalanceo automático ante sobrestock con riesgo de vencimiento vs. quiebre. RF-MSU-1 transferencias P1, RF-MSU-2 rebalanceo automático P2.

6.11 Escandallos / menu engineering ESC

Laboratorio interactivo para crear platos y predecir rentabilidad con precios en tiempo real; reclasifica el menú en matriz BCG con food cost real. RF-ESC-1 simulador P1.

6.12 Copiloto de inteligencia operativa AI

Interfaz conversacional (WhatsApp/voz/app) para consultar causas raíz y registrar mermas/conteos con foto o voz. RF-AI-1 consultas de causa raíz P2, RF-AI-2 registro por voz/foto P2.

6.13 Marketplace B2B multi-tienda MKT

Evolución del panel de proveedores hacia un catálogo tipo Amazon: el restaurante compra a varias tiendas en un mismo carrito. Las marcas firman un contrato para publicar su catálogo y quedar habilitadas en el panel (modelo de negocio).

ID	Requisito	Prioridad
RF-MKT-1	Catálogo agregado de múltiples tiendas con búsqueda y filtro por categoría.	P0
RF-MKT-2	Carrito agrupado por tienda; genera una OC por tienda al confirmar.	P0
RF-MKT-3	Umbral de envío gratis por tienda con barra de progreso ("te faltan $X").	P1
RF-MKT-4	Onboarding de marcas: alta de catálogo, badge Partner y colocación destacada/patrocinada.	P1

RN: el envío gratis se evalúa por tienda sobre su subtotal (sin incluir envío); respeta el precio negociado por cliente cuando existe; solo tiendas con contrato activo aparecen en el catálogo. Bloquea checkout de una tienda bajo su MOQ.

6.14 Etiqueta QR de bodega & ajuste por voz (Pro) QR/VOZ

Cada insumo lleva una etiqueta QR imprimible para la repisa. Al escanearla, el bodeguero registra recepción, conteo, merma o transferencia desde el teléfono. El ajuste por voz es una feature Pro (de pago): interpreta comandos naturales ("saco 200 g de mantequilla") y genera el movimiento.

ID	Requisito	Prioridad
RF-QR-1	Generar e imprimir etiqueta QR por insumo (`inventoryhub://insumo/{id}`).	P1
RF-QR-2	Vista de escaneo con acciones rápidas; cada acción crea un `StockMovement` con usuario, hora y sucursal.	P1
RF-QR-3	Funcionamiento offline con sincronización posterior.	P2
RF-VOZ-1	Ajuste por voz con NLU en español (cantidad + unidad + acción + insumo), gated por plan Pro.	P2

RN: el ajuste por voz requiere entitlement activo; con baja confianza de reconocimiento, confirmar el movimiento antes de aplicarlo.

7Motor de aprendizaje continuo

Resumen; el desarrollo matemático completo está en el documento dedicado.

El motor estima las recetas reales $\hat R$ desde compras, ventas y conteos, y se recalibra periodo a periodo. La señal base es el balance de masa:

$$ I_t = I_{t-1} + P_t - \hat{R}\,X_t - \varepsilon_t $$

El food cost real de cada plato sale de la receta calibrada por el costo WAC de sus insumos:

$$ \text{FoodCost}^{\text{real}}_j = \frac{\sum_i \hat{R}_{ij}\,c_i^{\text{WAC}}}{\text{precio}_j} $$

Incluye calibración por NNLS regularizado, actualización online tipo Kalman, stock de seguridad estocástico y clasificación de anomalías (fuga vs. porcionado). → Ver especificación técnica completa del Motor.

8Integraciones

Sistema	Uso	Modo
SII / DTE	Ingesta de facturas electrónicas de compra	Webhook / API
WhatsApp Cloud API	Envío de OC y recepción de confirmaciones	API · plantillas utility
POS	Ventas por plato (consumo teórico)	API / import
Banco	Exportar nómina de pagos	Archivo (CSV/PAIN.001)
Clima & eventos	Señales para el forecast de demanda	API externa

9Requisitos no funcionales

ID	Requisito
RNF-1	Multi-tenant: aislamiento por organización, con Row-Level Security en Postgres.
RNF-2	Precisión monetaria: `Decimal` en importes; nunca `float`.
RNF-3	Idempotencia: ingesta y jobs seguros ante reintentos.
RNF-4	Auditabilidad: ledger append-only + calibraciones versionadas y reversibles.
RNF-5	Disponibilidad: serverless (Vercel) con base gestionada (Neon), objetivo 99.9%.
RNF-6	Rendimiento: dashboards < 1.5 s; jobs de calibración nocturnos.
RNF-7	Seguridad: secretos en variables de entorno; sin credenciales en el repo.
RNF-8	Localización: es-CL, CLP, formato de fecha local.

10Roles y permisos (RBAC)

Acción	Owner	Admin	Chef	Compras	Finanzas
Ver dashboard / alertas	✓	✓	✓	✓	✓
Confirmar mapeo SII	✓	✓	—	✓	—
Editar recetas / escandallos	✓	✓	✓	—	—
Armar y enviar OC	✓	✓	✓	✓	—
Gestionar catálogos / precios pactados	✓	✓	—	✓	—
Aprobar / exportar nómina	✓	—	—	—	✓
Resolver auditoría de estación	✓	✓	✓	—	—

11Métricas de éxito

North Star

Puntos de margen bruto protegidos por el sistema (food cost real evitado vs. la línea base del restaurante).

Métrica	Meta
Precisión consumo proyectado vs. real	Error < 3% por insumo
Reducción de quiebres de stock	−40% en insumos clave
Reducción de pérdidas por merma / fuga	−25% a 35% en 60 días
Tiempo en compras e inventarios	−70% de horas administrativas
Mejora de margen bruto	+2.5 a 4.0 pts
% facturas mapeadas sin intervención	≥ 90%
OC enviadas por WhatsApp / semana (adopción)	Tendencia creciente

12Roadmap y fases

Fase	Alcance	Madurez del modelo
v0.1 (hoy)	Dashboard, E-Procurement (WhatsApp demo), Cuentas por Pagar sobre datos reales.	Cold start (R₀ teórico)
v0.2	Ingesta real de DTE + AI mapping con cola de revisión. Motor de autocalibración sobre POS.	Aprendizaje (R̂ converge)
v0.3	Escandallos interactivo, transferencias multi-sucursal, webhook de estados WhatsApp + confirmación del proveedor.	Aprendizaje avanzado
v1.0	Auth + RLS, WhatsApp live con plantillas, nómina en formato bancario, portal de proveedores, auto-procurement.	Autonomía (supervisión por excepción)

13Riesgos y mitigaciones

Riesgo	Impacto	Mitigación
Mapeo IA impreciso	Inventario erróneo	Umbral de confianza + cola de revisión humana antes de afectar stock
Dependencia de WhatsApp (ventana 24 h, aprobación de plantillas)	Bloqueo del checkout	Plantillas utility pre-aprobadas + fallback a texto
Pagar de más / doble	Pérdida financiera	Separación de poderes: nada se paga sin aprobación humana
Datos del SII de baja calidad	Errores de costeo	Guardar payload original + reproceso; residuos aíslan ruido
Cold start del modelo	Recomendaciones pobres al inicio	λ alto ancla a R₀; se relaja al acumular datos

14Supuestos, dependencias y preguntas abiertas

Supuestos

El restaurante emite/recibe DTE electrónicos y tiene un POS con datos de venta accesibles.
Los proveedores clave aceptan integrar catálogo y recibir OC por WhatsApp.

Dependencias

Alta en WhatsApp Business Platform (Meta) y aprobación de plantillas.
Acceso al API/servicio de recepción de DTE del SII.

Preguntas abiertas

¿Cadencia de conteo físico óptima (diaria vs. semanal) por tipo de insumo?
¿Umbral de auto-aprobación de OC automáticas por monto?
¿Formato bancario exacto por banco para la nómina?

15Glosario

DTE	Documento Tributario Electrónico (factura del SII).
Yield	% de rendimiento: parte utilizable de un insumo tras limpieza/procesado.
Food cost	Costo de insumos de un plato como % de su precio de venta.
WAC	Costo promedio ponderado del inventario.
OTIF	On-Time In-Full: entregas completas y a tiempo.
MOQ	Cantidad mínima de pedido del proveedor.
NNLS	Mínimos cuadrados no negativos (calibración de recetas).
OC	Orden de compra.