# SLOBs — el modelo del proyecto > Redefinición del 2026-08-07, a pedido de Matías. **Manda sobre lo que había antes.** > > El problema que resuelve: hasta hoy el proyecto hacía **una sola pregunta — ¿rota? —** y > todo lo demás (mal estado, sin costo, sin precio, depósitos raros, componentes, insumos) > entraba como excepción parchada en el front. Cada caso nuevo era un `if` más. Este documento > reemplaza esa lógica por una **clasificación explícita con un dueño por bolsón**. --- ## 1. Las tres preguntas, en orden El error de diseño era preguntar la rotación primero. La rotación es la **última** pregunta, no la primera: no tiene sentido decirle a un comercial que un producto no rota si además no se puede despachar, no tiene precio o está roto. ``` 1. ¿SE PUEDE VENDER? → aptitud física y legal → DAMIÁN (supply) 2. ¿ESTÁ LISTO PARA OFRECERSE? → costo, precio, ficha → MATÍAS 3. ¿ROTA? → cobertura > 12 meses → COMERCIAL ``` Sólo lo que **pasa 1 y 2 y falla 3** va al equipo comercial. Todo lo que falla 1 o 2 es un plan de acción de la mesa chica, con un responsable con nombre. **Corolario que hay que respetar:** un producto que falla la pregunta 1 o 2 **sigue contando en el valorizado inmovilizado**. No se lo saca del proyecto — se lo saca de la *oferta*. Inventario y oferta son dos cosas distintas y hasta ahora estaban mezcladas. --- ## 2. El universo, medido (2026-08-07) ### Todo el stock | | códigos | unidades | capital | |---|---|---|---| | **Todo lo que tiene stock** | 1.530 | 1.805.222 | U$D 2.508.767 | | No son códigos de producto (lotes, insumos) | 8 | 54.589 | U$D 657 | | Productos (`P*`) | 1.522 | 1.750.633 | U$D 2.508.110 | ### De ahí, qué es SLOB El motor deja afuera **877 códigos** con stock. La enorme mayoría, **con razón**: | por qué queda afuera | códigos | unidades | capital | |---|---|---|---| | **Rota bien** (cobertura < 12 meses) o está en gracia | 798 | 374.529 | U$D 952.147 | | Ficha inactiva en el catálogo | 45 | 5.363 | U$D 596 | | Sin costo cargado | 21 | 61.799 | sin valorizar | | Material POP (excluido a propósito) | 13 | 2.073 | — | **Universo SLOBs: 624 SKUs · 1.338.886 unidades · U$D 1.509.765.** --- ## 3. Los bolsones, con dueño Partición **exclusiva** — cada SKU cae en uno solo. El orden importa: se pregunta de arriba hacia abajo y el primero que aplica gana. | bolsón | SKUs | unidades | capital | % | dueño | |---|---|---|---|---|---| | **A · OFRECIBLE** — apto, dato completo, no rota | 469 | 1.183.646 | U$D 1.477.561 | **97,9%** | Comercial (Fede · Manu) | | **B · APTO, FALTA EL DATO** — se puede vender, no se puede ofrecer | 72 | 45.966 | U$D 10.874 + 34 sin valorizar | 0,7% | **Matías** | | **C · SIN CLASIFICAR** — nadie dictaminó si se puede vender | 17 | 6.881 | U$D 1.382 | 0,1% | **Damián** | | **D · MAL ESTADO, NADA SANO** — canal especial | 37 | 78.478 | U$D 15.282 | 1,0% | **Mesa chica** | | **E · FUERA DE ALCANCE** — showroom, consignación, reservas | 29 | 23.915 | U$D 4.666 | 0,3% | **Damián** + Matías | | **F · NO INVENTARIADO** — está físicamente, no está en el sistema | **?** | **?** | **invisible** | ? | **Damián** | ### El dato incómodo **El 98% del capital inmovilizado son 469 productos sanos, publicados, con costo y precio, que simplemente no rotan.** Todos los casos con particularidad juntos —mal estado, sin clasificar, sin costo, sin precio, showroom— son **el 2%**. Eso no vuelve inútil la limpieza: un producto trabado está trabado por más que su plata se cuente en otro lado, y sin resolverlo el equipo comercial ofrece cosas que no existen. Pero **la reunión con la mesa chica no puede presentarse como "acá está la plata"**. La plata está en el bolsón A, y ahí la palanca es precio y gestión comercial, no Supply. ### Dentro de A · OFRECIBLE | estadio | SKUs | capital | |---|---|---| | Estancado (>180 días sin mover) | 107 | U$D 398.351 | | Obsoleto (>730 días o nunca) | 100 | U$D 370.538 | | Lento (>90 días) | 75 | U$D 250.129 | | Dormido (>365 días) | 102 | U$D 238.328 | | Reciente | 85 | U$D 220.215 | - **62 SKUs por U$D 121.604 no están publicados en la web** pero son perfectamente ofrecibles. Es el caso de Thermos / ThermoCafé / Thermos Kids, que el RPC ya fuerza a visible. El resto hay que revisarlo de a uno. - **82 SKUs tienen algo de merma pero stock sano**: se ofrece el sano y se descuenta la merma. La merma de esos 82 es **U$D 13.542** en total. ### Dónde está físicamente el capital SLOB | clase de depósito | unidades | capital | % | |---|---|---|---| | vendible | 1.192.035 | U$D 1.463.135 | 96,9% | | fuera (showroom, consignación, reservas) | 99.167 | U$D 55.822 | 3,7% | | mal estado | 28.948 | U$D 20.801 | 1,4% | | a revisar (incluye el depósito SLOBS) | 18.736 | U$D 10.331 | 0,7% | *(suma levemente más de 100% por el tratamiento de sufijos de lote; los órdenes de magnitud son correctos)* **U$D 55.822 del inmovilizado está en depósitos que no son nuestros para vender.** Es una decisión abierta si ese capital debe contar en la meta del Desafío — ver §6. --- ## 4. Trampa: no valorizar el SKU entero cuando el problema es parcial **Este error ya se cometió y llegó a una presentación.** Al armar un bolsón, la tentación es sumar el `valorizado` del SKU. Está mal cuando lo que está trabado es una *parte* del stock: > La Mochila Bison tiene 1.948 unidades y **3** en mal estado. Su valorizado completo son > miles de dólares; la merma son centavos. Sumar el SKU entero al bolsón "mal estado" infla > el número por un factor de cientos. Medido: presentar "mal estado" por SKU completo daba **U$D 395.614**; valorizando sólo las unidades dañadas da **U$D 20.801**. **72 de 127 SKUs afectados tienen menos del 10% dañado.** **Regla: un bolsón se valoriza por las unidades que están en esa condición, no por el SKU.** La única excepción legítima es el bolsón D (100% trabado), donde coinciden. --- ## 5. Lo que hay que construir ### 5.1 `promointel.slob_clasificacion` — la clasificación deja de vivir en el código Hoy cada caso nuevo es un `if` en `index.html` y `comercial.html`. Con esta tabla el default se **calcula** con las reglas de §3, pero se puede **pisar a mano** sin redeployar. ```sql CREATE TABLE promointel.slob_clasificacion ( codigo text PRIMARY KEY, bolson text NOT NULL, -- A_ofrecible | B_falta_dato | C_sin_clasificar -- D_mal_estado | E_fuera_alcance | F_no_inventariado -- G_componente | X_no_slob dueno text NOT NULL, -- comercial | matias | damian | mesa_chica accion text, -- qué se decidió hacer estado_accion text DEFAULT 'pendiente', -- pendiente | en_curso | resuelto nota text, definido_por text, definido_at timestamptz DEFAULT now() ); ``` Reemplaza a `promointel.slob_excluidos` (que queda como el caso `X_no_slob`) y absorbe las anotaciones del CSV `docs/slobs_a_definir_v2.csv`, que hoy no las lee ningún sistema. ### 5.2 `promointel.slob_no_inventariado` — el único universo que el sistema no puede derivar Mercadería que está físicamente en el depósito y **no existe en Finnegans**. Por definición devuelve 0 filas en cualquier consulta: no hay forma de medirla desde la base. Si no hay un registro manual, ese universo no existe y no se le puede seguir el avance. ```sql CREATE TABLE promointel.slob_no_inventariado ( id bigserial PRIMARY KEY, descripcion text NOT NULL, deposito text, cantidad_est numeric, costo_est_usd numeric, reportado_por text, reportado_at timestamptz DEFAULT now(), codigo_asignado text, -- cuando se lo ingresa, acá va el código resuelto_at timestamptz ); ``` ### 5.3 Dos vistas, no una - **`comercial.html`** → sólo bolsón A. El comercial no debería ver nunca un producto que no puede vender. Hoy ve avisos y notas al pie explicando por qué algo no se ofrece; eso es ruido para él y pertenece a la otra vista. - **`index.html` → pestaña nueva "Plan de acción"** → los bolsones B a F agrupados **por dueño**, con el avance de cada acción. Es la pantalla de la mesa chica. --- ## 6. Decisiones abiertas | # | decisión | quién | por qué importa | |---|---|---|---| | 1 | ¿El showroom, la consignación y las reservas (**U$D 55.822**) cuentan en la meta del Desafío? | Matías + Nicolás | La base del trimestre está congelada; cambiarla mueve el objetivo | | 2 | Un producto con stock sano **y** stock en mal estado: ¿es del comercial (con la merma descontada) o de la mesa chica? | Matías | Son 82 SKUs. Hoy está implementado como lo primero | | 3 | Las recetas de los compuestos: qué códigos y en qué cantidad entra cada uno | Matías + supply | Las actuales están **inferidas de la numeración**, sin confirmar | | 4 | 21 productos con stock sano tienen la **ficha inactiva** en el catálogo (U$D 49.126 en todo el inventario). ¿Se reactivan o están bien dados de baja? | Matías | Nadie los ofrece porque el sistema dice que no existen | --- ## 7. Estado - [x] Universo medido y partido en bolsones - [x] Dueño asignado por bolsón - [x] `slobBolson()` implementado en `index.html` y `comercial.html` — verificado contra la medición: A 473 · B 73 · C 17 · D 37 · E 31 (la diferencia con la tabla de §3 son exactamente los 7 excluidos, que se aplican al correr el SQL) - [x] `comercial.html` sólo ofrece el bolsón A, con un pie de una línea - [x] Pestaña **Plan de acción** en `index.html`, agrupada por responsable - [ ] **Correr `docs/sql/slobs_modelo_bolsones.sql`** — hasta que no se corra, el front usa `slob_excluidos` como fallback y no hay snapshot de depósitos - [ ] Las anotaciones del CSV migradas a `slob_clasificacion` - [ ] Corregir la presentación de la mesa chica con la valorización por unidad (§4) ### Decisiones tomadas - **2026-08-07 · showroom / consignación / reservas** — no cuentan, pero **recién al congelar el Q4**. Mecánicamente el ajuste **impacta el objetivo, no la reducción**: si se descuenta de la base y del actual a la vez, los U$D 98.625 ya movidos no cambian; lo que baja es cuánto falta (el 10% pasa de U$D 147.478 a 145.242). Hacerlo hoy exigiría saber cuánto de la base del 1/7 estaba en esos depósitos, y **ese dato no existe**: la base se congeló por SKU y no hay historia de stock. Por eso arranca el snapshot diario. - **2026-08-07 · productos con stock sano y algo de merma** (82 SKUs, merma U$D 13.542) — van al **comercial con la merma descontada**. No se sacan de la oferta.