Skip to content

folvy_mrp_ii_mapa.md

Latest commit

 

History

History
59 lines (40 loc) · 7.07 KB

folvy_mrp_ii_mapa.md

File metadata and controls

59 lines (40 loc) · 7.07 KB
Raw

Folvy — Mapa MRP II (destino del aprovisionamiento)

Qué es esto: el destino completo del módulo de aprovisionamiento de Folvy, concebido como MRP II de ciclo cerrado de hostelería — un "SAP/Oracle con UI moderna que un cocinero usa sin manual". Es el plano del que cuelga cada pieza que se construya, para que ninguna se haga aislada y luego no encaje. Diagrama: folvy_mrp_ii_mapa.svg (SVG versionable, no imagen binaria).

Creado: 2026-06-03 · Actualizado: 2026-06-04 (recepción C2 + OCR C2.2 completos; FACTURA C3 COMPLETA C3.1–C3.5). Ciclo de compra cerrado de punta a punta.

Folvy MRP II

Decisión estratégica

El aprovisionamiento de Folvy NO es "un módulo de compras" — es MRP II de ciclo cerrado. El hueco de mercado para ganar: nadie en hostelería tiene la PLANIFICACIÓN (Apicbase, MarketMan, Toast se quedan en ejecución: compras + inventario + food cost). La planificación (previsión → plan maestro → explosión de necesidades → órdenes automáticas → ciclo cerrado con AvT) es territorio de SAP/Oracle, inusables en hostelería. Folvy = ese cerebro con cara de app.

Método (clave): copiar conceptos estándar y probados de ERP industriales (no inventar) y traducirlos a lenguaje de cocina para que sean manejables. Construir por capas pequeñas operativas, pero siempre con este mapa completo como destino.

Las 13 fases del ciclo

Planificación (el cerebro — nadie en hostelería lo tiene)

  1. Previsión de demanda — insumo verde. Cuántos platos por servicio/día/local, desde el histórico (~12K ventas) + estacionalidad + eventos. IA diferencial.
  2. Plan maestro de producción (MPS) — por construir. Qué y cuánto se produce.
  3. Explosión de necesidades (MRP) — insumo verde. Cada plato → su escandallo (BOM) → materias primas. Con factor de merma (gross). El corazón del cálculo.
  4. Balance contra stock — por construir. Necesidad − stock disponible − órdenes pendientes = lo que hay que comprar.
  5. Planificación de capacidad (CRP) — por construir. ¿La cocina/personal da abasto? Vincula con Horarios y Team.

Conceptos a traducir aquí (de ERP industrial): PAR level (= punto de reorden + stock de seguridad, con nombre que el cocinero entiende), lead time de proveedor, lote económico, backward scheduling. Fórmula MRP estándar: necesidad neta = (suministro + stock) − demanda − stock de seguridad.

Ejecución de compra (ciclo administrativo estándar PO→albarán→factura)

  1. Generación de órdenes de compra — por construir. Automática desde el balance (4), o por stock mínimo (PAR), plantilla de necesidades, o iniciativa. Agrupadas por proveedor preferente.
  2. Aprobación + envío — por construir. Gating por presupuesto/rol → envío al proveedor (email/PDF/API/EDI).
  3. Recepción (albarán) — CONSTRUIDA (04/06). goods_receipt + líneas + libro mayor de stock (WAC perpetuo append-only); auto-estado del pedido; anti-error (blind receiving). OCR de recepción C2.2 COMPLETO: escanear (foto/PDF) → leer+validar por base imponible → materializar → casar con memoria por proveedor → crear artículo al vuelo (copiloto IA) → aprender → resolver intermediarios → anti-duplicado → avisos de precio/caducidad. Supera a xtraCHEF/MarketMan (memoria por proveedor + copiloto).
  4. Factura + three-way match — COMPLETA (04/06; build verde, no probada en vivo aún). PO ↔ albarán ↔ factura cuadran; discrepancias cazadas (pediste 10, llegaron 9, te cobran 10). El control que protege al restaurador. C3.1–C3.5 HECHO: modelo supplier_invoice+líneas+N:M+abonos+FAC- (C3.1); OCR de factura reutilizando ocr-albaran (C3.2); motor three-way run_invoice_match precio/cantidad/no-recibido/IVA contra motor fiscal por fecha (C3.3); eslabón coste apply_invoice_costs corrige last_price→recompute→cascada + impacto en margen (C3.4); enrutado de aprobación por reglas importe/proveedor/local→rol (C3.5). Benchmark R365: IGUALADO (OCR+3way+aprobación+audit+abonos) y SUPERADO con el eslabón al MARGEN del plato, que nadie tiene. PENDIENTE: probar en vivo.

El flujo SIEMPRE es con pedido (norma estándar en hostelería y cualquier sector). Los datos sueltos de Llorente29 (factura sin pedido) son caso de prueba, no el flujo principal. Casos límite a cubrir: artículo no existe → crear ingrediente; proveedor no existe → crear; sin pedido → validar por totales internos (excepción, no norma).

Inventario, coste y cierre (el bucle que se cierra)

  1. Inventario perpetuo — por construir (EL TRONCO). Entradas (recepción) − salidas (consumo por ventas×escandallo) = stock en tiempo real por local/almacén. Conteos, mermas, caducidades, lotes con fecha (FEFO). Casi todo lo demás cuelga de aquí.
  2. Trazabilidad lote → ración → plato → cliente — a medias. APPCC (en Safety) + recipe_item_production_check (QA emplatado por visión IA) ya existen como piezas.
  3. Coste real vs teórico (AvT) — motor verde, dato pendiente. Teórico (escandallo×ventas) vs real (compras ± variación de inventario). La métrica reina. El motor de coste ya está; necesita el inventario poblado.
  4. Cierre por período + márgenes reales — por construir. La cima de la torre del coste.

El cierre realimenta la previsión → ciclo cerrado.

Estado: qué tiene Folvy ya (insumos verdes)

escandallos (BOM) · ~12K ventas (previsión) · ingredientes/proveedores/formatos/coste · familias AECOC · APPCC (trazabilidad) · recipe_item_production_check (QA emplatado) · motor de coste (→AvT) · purchase/purchase_line (documento suelto, a reconvertir en el ciclo).

Qué está vacío (por construir)

inventario/stock perpetuo · movimientos de stock · lotes/caducidad (FEFO) · conteos · previsión (tabla) · plan maestro · balance · capacidad · órdenes de compra (PO) · recepción/albarán · mermas · almacenes.

El tronco (SIGUIENTE FRENTE)

Inventario perpetuo (10). El ciclo de compra que lo alimenta (6-9) ya está: recepción (8) y factura (9) CONSTRUIDAS; órdenes/aprobación (6-7) parcial (pedido manual hecho, generación automática pendiente). La recepción ya escribe stock_movement + snapshot WAC. Falta el ciclo completo de inventario: conteos, mermas, caducidades, FEFO, consumo por ventas×escandallo. Sin inventario no hay balance (4), ni punto de reorden (5-6), ni AvT real (12). Es la pieza de la que cuelga el ciclo cerrado. Es el siguiente frente.

Conceptos del benchmark a traducir (referencia)

  • ERP industrial (SAP/Sage/Acumatica): reorder point, safety stock, lead time, lot size / EOQ, BOM con scrap factor, backward scheduling, three-way match, purchase requisition (la propone MRP) ≠ purchase order (aprobada).
  • Perecedero (NetSuite/RELEX/Katana): PAR level (Periodic Automatic Replenishment), FEFO (First Expired First Out), lotes con caducidad + alertas, auto-86 (quita del menú lo agotado, conecta con delivery), transferencias entre locales, conversión de unidades (granel→uso).