Inventory Events Layer - Eventos de inventario¶

Fecha: 2026-06-05

Estado: FUTURO DOCUMENTADO / NO IMPLEMENTADO

Scope: tenant

tenant_id: alpuntodeventa

Owner: Gabi / Carlos Canu

Fuente de verdad: docs/tenants/alpuntodeventa/business-observer/sources/INVENTORY-EVENTS-LAYER-FUTURE.md

1. Proposito¶

Esta capa futura existe para convertir cambios observados de stock en eventos comerciales utiles para APV.

La idea no es guardar una nueva fuente cruda de inventario.

La idea es detectar hechos relevantes a partir de fuentes futuras ya documentadas y volverlos legibles para negocio, supervision, compras y direccion comercial.

Su valor funcional seria ayudar a responder mejor preguntas como:

que SKU entro en quiebre
que SKU salio del quiebre
que faltante merece accion humana
que oportunidad comercial podria recuperarse
que recomendacion no conviene emitir por falta de disponibilidad

Esta capa no implica implementacion tecnica ahora.

No define tablas.

No define scripts.

No define SQL.

No define APIs.

No define IA.

Solo documenta una evolucion futura del observer.

2. Diferencia con SOURCE-002C y SOURCE-002D¶

La separacion funcional debe quedar explicita:

SOURCE-002C = foto diaria de stock cerca de las 17:00
SOURCE-002D = stock vivo liviano cada 10 minutos
Inventory Events Layer = eventos detectados a partir de esas fuentes

Lectura obligatoria:

SOURCE-002C conserva historia diaria de cierre
SOURCE-002D aporta seguimiento intradiario liviano
Inventory Events Layer interpreta cambios y los convierte en senales funcionales

Por lo tanto:

no debe confundirse evento con snapshot
no debe confundirse evento con stock actual
no debe mezclarse historia de cierre con estado vivo en una sola lectura

3. Eventos futuros posibles¶

Esta capa futura podria detectar y clasificar eventos como:

SKU quedo sin stock
SKU volvio a tener stock
SKU cayo debajo del minimo
SKU ingreso despues de un quiebre
SKU estrategico quedo sin disponibilidad
marca estrategica con faltantes
proveedor con faltantes recurrentes
stock volvio antes del snapshot de las 17:00
quiebre duro X horas estimadas
producto con demanda no atendida recuperable
producto no recomendable por falta de stock

Estos eventos no deben leerse como decisiones automaticas.

Deben leerse como senales funcionales futuras para priorizacion humana.

4. Casos de uso donde seria util¶

La capa futura tendria valor directo para:

UC004 Demanda no atendida: ayuda a detectar cuando una oportunidad pendiente podria recuperarse al volver el stock
UC005 Calendario operativo: ayuda a leer mejor la duracion aproximada del quiebre dentro de ventanas comerciales reales
UC007 Recomendaciones priorizadas: ayuda a no recomendar productos sin stock y a priorizar avisos de reposicion
UC008 Surtido y mix: ayuda a no empujar ampliacion o siembra sobre productos sin sostener disponibilidad
UC009 Proveedores y abastecimiento: ayuda a ver recurrencia, criticidad y velocidad aproximada de recuperacion

La capa no duplica esos UC.

Los alimenta con evidencia funcional adicional.

5. Ejemplos APV¶

Ejemplo 1¶

Baldo 500 gr

lunes 17:00 stock 0
martes 10:20 stock 120
evento: volvio a tener stock
accion futura: avisar a vendedores con clientes pendientes

Ejemplo 2¶

Krachitos

el stock cae debajo del minimo
evento: riesgo de quiebre
accion futura: elevar a compras o direccion

Ejemplo 3¶

SKU estrategico

sin stock durante varias ventanas observadas
evento: quiebre critico
accion futura: priorizar reposicion

6. Duracion estimada del quiebre¶

Combinando SOURCE-002C y SOURCE-002D, esta capa futura podria estimar:

hora aproximada de inicio del quiebre
hora aproximada de recuperacion
duracion estimada
impacto comercial probable

Regla obligatoria:

esa lectura seria una estimacion funcional y no una verdad exacta del momento real del movimiento de inventario.

La utilidad de la capa no estaria en prometer precision absoluta.

La utilidad estaria en dar mejor contexto comercial para priorizar.

7. Reglas de cuidado¶

no asumir venta perdida exacta
no culpar automaticamente a compras
no culpar automaticamente a proveedor
no generar alertas excesivas
no recomendar productos sin stock
no mezclar stock actual con snapshot historico
no automatizar decisiones sin revision humana

Regla madre:

un evento de inventario futuro debe ser una senal comercial util, no una conclusion automatica cerrada.

8. Roadmap futuro¶

Etapa futura 1¶

Tener SOURCE-002C implementado.

Etapa futura 2¶

Tener SOURCE-002D implementado.

Etapa futura 3¶

Detectar cambios simples.

Etapa futura 4¶

Clasificar eventos.

Etapa futura 5¶

Alimentar UC007.

Etapa futura 6¶

Medir impacto con UC003.

9. Estado¶

FUTURO DOCUMENTADO / NO IMPLEMENTADO

10. Confirmaciones de alcance¶

no se implemento codigo
no se crearon tablas
no se crearon scripts
no se toco runtime
no se toco VPS
no se ejecutaron conexiones
no se diseno SQL
no se disenaron APIs
no se diseno IA
la capa queda separada de SOURCE-002C
la capa queda separada de SOURCE-002D
la capa queda documentada como roadmap futuro