Plant Cerebro
← temas
tema

Especificación Maestra — «Planter Full 2.0» (Inspirado y Superando a Mercado Libre Full)

<!-- ESTADO-VIVO:INICIO -->

⚡ ÚLTIMO ESTADO VIVO (Actualizado: 2026-10-29 19:13 · Orden Cronológico Inverso: Más Nuevo Arriba)

<!-- ESTADO-VIVO:FIN -->

Acuerdos Sellers Beta y Autogestión Planter (2026-10-30 · 16:22 hs)

  1. Reserva de mercadería en tránsito (pedido de Lucas Cunil, 00:22:12): estilo Amazon, permitir a comercios/consumidores reservar productos sin stock cuando la marca Planter ya tiene turno confirmado de entrega.
  2. Alquiler de depósito >60 días (propuesta de Mauro Stoessel, 00:23:38): evaluar para próxima etapa cobrar 1% diario sobre pallets Planter que superen 60 días sin rotar.
  3. Integración de Google Calendar de Turnos + OpenKey en plant-hub (01:14:00).

Última actualización: 2026-10-28 (Auditoría técnica de Mercado Libre Full API + sellers.plantinterno.com + Plant Hub + MongoDB vivet-web + Reglas de Negocio de Gabriel Busso y Mauro Stoessel)

Estado: Especificación Funcional y Técnica Completa — Lista para Implementación en sellers.plantinterno.com (Fase 1 Inmediata) y Plant Hub (apps/supplier · Fase 2)

Responsables: Gabriel Busso · Mauro Stoessel (Compras & Supply Chain) · Recepción Ezeiza

1. Resumen Ejecutivo: El Cambio de Paradigma Operativo

En el esquema tradicional de compras, el equipo de Compras persigue manualmente a las marcas en consignación (Planter), emite Órdenes de Compra (OCs) a mano, negocia cantidades por WhatsApp y reclama entregas atrasadas.

Con «Planter Full 2.0», Plant invierte el flujo exactamente igual que Mercado Libre Full (Envíos a Full), pero adaptado a alimentos y productos con vencimiento real en nuestro centro de distribución de Ezeiza:

  1. Compras deja de emitir OCs manuales y de perseguir marcas Planter: El portal (sellers.plantinterno.com hoy, y apps/supplier en Plant Hub) audita continuamente el stock físico en Ezeiza, las ventas omnicanal (Web B2C + Business B2B + Mercado Libre Full) y el stock en tránsito, y dispara alertas automáticas de reposición desde Portal Planter <avisos@plant.com.ar>.
  2. Recomendación inteligente para cubrir 45 a 49 días de venta real des-censurada: El sistema sugiere la cantidad exacta (redondeada a bulto cerrado UxBulto) para cubrir entre 45 y 49 días de demanda real (excluyendo días en quiebre para no subestimar productos estrella agotados, y descontando órdenes ya en tránsito).
  3. Idea de Mauro · Calculadora Dinámica en Vivo de Fecha de Vencimiento Mínima Exigida según Cantidad: A medida que la marca edita cuántas unidades quiere mandar en su Orden de Envío, el sistema calcula en tiempo real cuántos días tardarán en venderse esas unidades sumadas al stock actual ((Stock Actual + En Tránsito + Cantidad a Enviar) ÷ Venta Diaria Real) + 30 días de margen mínimo de vida útil para el consumidor final, y le muestra en vivo la Fecha de Vencimiento Mínima Exigida para aceptar ese lote en Ezeiza (o cuántas unidades máximas puede mandar si su lote vence antes, o el compromiso de promoción atada al lote).
  4. Idea de Gaby 1 · Simulador Persuasivo en Vivo de Pérdida de Ventas por Sub-Envío: Si un SKU vende 10 u./día (sugerido 450 u. para 45 días) y la marca tipea 10 u., el portal le advierte en vivo en rojo/ámbar antes de confirmar: *«Con 10 u. vas a quebrar stock en 1 día y vas a dejar de facturar $XXX.XXX este mes (quedando sin stock durante 44 días del ciclo)»*.
  5. Idea de Gaby 2 · Integración Directa con el Google Calendar de Recepción Ezeiza de Mauro + Puente Automático a purchaseOrders + Seguimiento 100% Automatizado por Mail:

2. Auditoría Exhaustiva de Mercado Libre Full (Envíos a Full)

Para diseñar «Planter Full 2.0», auditamos tanto la experiencia de usuario de Mercado Libre Full como la estructura técnica real de su API (/marketplace/fbm/user-products/{up}/replenishment y /inventories/{inv}/stock/fulfillment), que ya consumimos en scripts/ml_reposicion.py y worker/build_ml.py (750 productos auditados en vivo en ml:repo).

2.1. Pantallas y Flujo Operativo de Mercado Libre Full

Etapa en ML FullQué ve y hace el Seller en Mercado LibreDatos Técnicos en la API de ML (/replenishment y /stock/fulfillment)
1. Panel de Salud y Gestión de Stock FullTablero con semáforo de urgencia de envío, métricas de cobertura en días, filtros rápidos (*«Enviar esta semana»*, *«Enviar la próxima semana»*, *«Sin urgencia»*, *«Excedente»*, *«Restringidos»*) y buscador por SKU/EAN.• stock.shipping_urgency: THIS_WEEK (121 SKUs hoy en Plant), NEXT_WEEK (131), IN_TWO_WEEKS (72), NO_URGENCY (341), EXCEDENT (85).<br>• recommendation.recommendation_type: REPLENISH (227), NO_REPLENISHMENT (514), NO_REPLENISHMENT_BY_RESTRICTION (61).
2. Cálculo de Demanda y Sugerencia de EnvíoPara cada SKU, ML muestra las ventas de los últimos 30 días (unidades y $) y las últimas 6 semanas, descontando los días agotados para calcular la velocidad real, y sugiere cuántas unidades enviar antes de una fecha límite (replenishment_deadline).• sales.sales_totals: { gmv, quantity } (30d).<br>• sales.sales_history: array de 6 semanas con { units_sold, days_out_of_stock, campaigns }.<br>• recommendation.suggested_quantity: { value, measure_unit }.<br>• recommendation.replenishment_deadline: fecha tope de llegada al depósito.<br>• recommendation.replenishment_frequency: cada cuántos días conviene mandar (ej. 28 o 45 días).
3. Simulador de Cantidad a Enviar y Penalidades / BeneficiosEl seller puede aceptar la cantidad sugerida o modificarla. Si intenta mandar más del tope permitido o si tiene baja rotación, ML le bloquea el envío (NO_REPLENISHMENT_BY_RESTRICTION) o le advierte de cargos por almacenamiento prolongado (*stock antiguo > 60/90 días*). Si manda lo sugerido a tiempo, le otorga beneficios (eligibility_benefits, descuentos en colecta/almacenamiento).• stock.minimum_distributable_stock: stock mínimo de seguridad.<br>• eligibility_benefits: { type, discount }.<br>• Bloqueo duro cuando el seller supera su cupo de m³ o unidades en bodega.
4. Control de Productos con Vencimiento (Regla FEFO de ML Full)Para alimentos, suplementos y cosmética, ML exige que el producto ingrese al centro de distribución con una vida útil remanente mínima (típicamente 90 días mínimos al momento de la recepción + lote y fecha de vencimiento impresos de fábrica en cada unidad). Si vence antes de venderse, pasa a No apto para la venta (not_available: expired / soon_to_expire) y el seller debe retirarlo pagando cargo o autorizar descarte.• En /inventories/{inv}/stock/fulfillment?include_attributes=conditions: desglosa available_quantity vs not_available_quantity con condiciones damaged, expired, soon_to_expire, lost, transfer, withdrawal.
5. Preparación de Productos y Bultos Master (Master Case)Paso obligatorio donde el seller declara:<br>1) Si cada unidad tiene código universal legible (EAN-13 / GTIN) o si debe imprimir etiquetas de producto ML.<br>2) Cómo agrupa las unidades: Cajas Master (packages_master_case = unidades por bulto) o Pallets, e imprime las Etiquetas de Bulto / Caja Master (código de barras/QR por caja que dice qué OC/Envío es y cuántas cajas son: Caja 1 de N).• product.packages_master_case: unidades por bulto cerrado.<br>• Generación de PDF térmico ZPL / A4 con etiquetas de unidad (si no tiene EAN) y etiquetas de bulto/pallet.
6. Reserva de Turno en Muelle y Datos del Transporte (ASN)El seller elige modalidad de ingreso (Vehículo propio, Expreso/Transporte, Correo) y selecciona fecha y franja horaria de descarga en el calendario del depósito. Antes de ir, carga Patente, Chofer, DNI y N° de Remito. Si llega sin turno o fuera de ventana, el muelle rechaza el camión; si no asiste (No-Show), ML penaliza su cupo.• Agenda de turnos vinculada al Inbound Shipment ID (Envío #).<br>• Pase de ingreso con QR para portería y rampa de recepción.
7. Recepción, Conciliación y Reclamos de IngresoA medida que el depósito escanea los bultos, el estado cambia de *«Programado»* → *«En proceso de ingreso»* → *«Ingresado»* (o *«Ingresado con diferencias»* si hubo faltantes, sobrantes o rechazo por vencimiento corto/rotura).• Conciliación línea por línea: Declarado vs. Recibido vs. Rechazado (motivo: vencimiento corto / daño / sin EAN).

3. Cómo «Planter Full 2.0» Supera a Mercado Libre Full

Mercado Libre Full usa una regla rígida de vencimiento (ej. *«mínimo 90 días de vida útil para todo»*), que tiene dos fallas graves en alimentos saludables:

Con las reglas diseñadas por Gabriel Busso y Mauro Stoessel, Planter Full 2.0 supera a Mercado Libre Full en 6 dimensiones clave:

DimensiónCómo funciona en Mercado Libre FullCómo lo supera «Planter Full 2.0» (Reglas Gaby + Mauro)
1. Regla de Vencimiento en RecepciónEstática / Fija (ej. 90 días fijos sin importar si mandás para 10 días o para 180 días de venta).Dinámica según Cantidad Enviada (Idea de Mauro):<br>Vto Mínimo Exigido = Fecha Turno Entrega + Días que tardará en venderse (Stock Actual + En Tránsito + Cantidad a Enviar) + 30 días de vida útil para el consumidor final.<br>• Si mandás para 60 días de venta, te exige vencimiento > 90 días.<br>• Si tu lote vence en 70 días, el sistema te dice en vivo: *«Con ese vencimiento podés mandar máximo X unidades (40 días de venta), o tenés que dejar pre-aprobada una promo de liquidación atada a este lote»*.
2. Persuasión Comercial ante Sub-EnvíosSi el seller cambia de 450 u. sugeridas a 10 u., ML simplemente guarda 10 u. sin explicarle cuánto dinero va a perder.Simulador Persuasivo de Plata Perdida en Vivo (Idea de Gaby 1):<br>Si el SKU vende 10 u./día (sugerido 450 u. para 45 días) y la marca pone 10 u., aparece un banner interactivo inmediato:<br>⚠️ *«Con 10 u. vas a cubrir solo 1 día de venta. Vas a quebrar stock el [Fecha] y vas a dejar de facturar $XXX.XXX este ciclo (44 días con stock en cero).»*
3. Horizonte de Cobertura OmnicanalSolo mira las ventas dentro de Mercado Libre.Omnicanal 360° (45 a 49 días):<br>Suma la velocidad real de los 3 canales que abastece Ezeiza (plant.com.ar B2C + Business B2B + Mercado Libre Full), des-censurando los días sin stock y aplicando estacionalidad real.
4. Agenda de Recepción UnificadaTurnera cerrada exclusiva de ML.Sincronización Bidireccional con el Google Calendar de Recepción Ezeiza de Mauro (Idea de Gaby 2):<br>Unifica en un solo calendario los camiones de Compra Firme y los de Planter Full. La marca agenda desde sellers.plantinterno.com directamente sobre los huecos reales del Google Calendar de Ezeiza.
5. Emisión y Conciliación de OC en ERP/WMSSeparado del ERP interno de Plant.Inyección Automática en purchaseOrders (vivet-web + Plant Hub):<br>La Orden de Envío creada por la marca nace automáticamente como purchaseOrder oficial en Producción. Recepción Ezeiza recibe sobre esa misma orden y carga los vencimientos por lote (lotsTimestamps).
6. Reclamo y Reprogramación de Turnos VencidosPenalización punitiva seca o cancelación automática.Seguimiento Relacional 100% Automatizado (avisos@plant.com.ar):<br>Si pasa la fecha del turno y la purchaseOrder sigue pendiente de ingreso en MongoDB, el bot manda un mail institucional cálido y persuasivo cuantificando la pérdida por quiebre y ofreciendo reprogramar el turno en 1 clic sin que Compras pierda 1 minuto.

4. Auditoría del Código Actual en nuestros Repositorios (sellers.plantinterno.com vs. Plant Hub)

Cumpliendo el pedido de Gaby (3BF7E90CC193B9C6F7C4), auditamos línea por línea qué existe hoy en sellers.plantinterno.com (worker/build_sellers.py) y qué armó Juanchi en Plant Hub (apps/supplier y packages/business-logic/src/logistics/supplier-portal.ts).

4.1. Estado actual de la Turnera y Envíos en Plant Hub (Código de Juanchi)

En el repositorio /Users/gabrielbusso/Proyectos/plant-hub, existen dos capas construidas en momentos distintos:

  1. La UI del Portal de Proveedores (apps/supplier/app/(supplier)/envios/):
  1. Horarios 100% hardcodeados sin cupo real (getSupplierSellerSchedule en supplier-portal.ts:2074-2093): La función ignora _sellerId, no consulta cuántos camiones ya reservaron y devuelve siempre un bucle fijo de 14 días hábiles con las horas [9, 11, 14, 16]. Si 15 proveedores eligen el lunes a las 09:00 hs, les da turno a los 15.
  2. Desconexión total con el Google Calendar de Mauro: No lee ni escribe en Google Calendar. Si una marca saca turno en Plant Hub, Mauro y Recepción Ezeiza no se enteran en su calendario actual.
  3. El Wizard de Nuevo Envío (NewShipmentForm.tsx) NO incluye la elección de turno: El proveedor crea el envío en 4 pasos sin elegir turno, y recién después tiene que entrar al detalle del envío (/envios/[id]) y tocar el botón RESERVAR UN TURNO (lo que hace que la mayoría se olvide de sacar turno).
  4. Cableado pendiente en actions.ts con el modelo SupplierAdvanceShippingNotice: Aunque en asn-shipment.ts ya se programó el modelo nuevo SupplierAdvanceShippingNotice (con estados DRAFT → ANNOUNCED → IN_TRANSIT → ARRIVED_AT_DOCK → RECEIVING → PARTIALLY_RECEIVED / RECEIVED / REJECTED y mergeDeliverySlot para no pisar purchaseOrder.received), el archivo [apps/supplier/app/(supplier)/envios/[id]/actions.ts](file:///Users/gabrielbusso/Proyectos/plant-hub/apps/supplier/app/(supplier)/envios/[id]/actions.ts#L41) todavía sigue llamando a la función vieja reserveSupplierShipmentTurn que pisa received: { t: timestamp }.

4.2. Estado actual de sellers.plantinterno.com (worker/build_sellers.py)

  1. Lo que ya tiene en producción hoy:
  1. Lo que le falta hoy a sellers.plantinterno.com (y que agregamos en «Planter Full 2.0»):

4.3. Decisión Arquitectónica Recomendada (El Camino Óptimo)

  1. Fase 1 Inmediata (Esta semana en sellers.plantinterno.com + Google Calendar de Mauro + MongoDB vivet-web):
  1. Fase 2 Unificación en Plant Hub (apps/supplier):

5. Especificación Funcional y Matemática de «Planter Full 2.0»

5.1. Motor de Demanda Real Des-Censurada y Sugerencia 45 a 49 Días

Para cada SKU activo de la marca en Ezeiza, el motor calcula:

  1. Venta Diaria Real Omnicanal Des-Censurada (V_diaria_real):

$$\text{Unidades Vendidas}_{60d} = U_{\text{Web B2C}} + U_{\text{Business B2B}} + U_{\text{ML Full}}$$

$$\text{DíasActivos}_{60d} = \max\left(7,\; 60 - \text{DíasAgotado}_{60d}\right)$$

$$V_{\text{diaria\_real}} = \frac{\text{Unidades Vendidas}_{60d}}{\text{DíasActivos}_{60d}} \times K_{\text{estacional}}$$

  1. Stock Disponible Real + Stock en Tránsito Válido (Stock_Proyectado):
  1. Estados de Urgencia y Salud de Stock (inspirados en ML Full):
  1. Cálculo de Cantidad Sugerida para cubrir entre 45 y 49 días (Q_sugerida):

$$Q_{\text{bruta\_45}} = \max\left(0,\; \lceil 45 \times V_{\text{diaria\_real}} - (\text{StockDisponible} + \text{StockEnTránsito}) \rceil\right)$$

$$Q_{\text{bruta\_49}} = \max\left(0,\; \lfloor 49 \times V_{\text{diaria\_real}} - (\text{StockDisponible} + \text{StockEnTránsito}) \rfloor\right)$$

5.2. Idea de Mauro · Calculadora Dinámica en Vivo de Fecha de Vencimiento Mínima Exigida según Cantidad

Este es el corazón técnico del control de calidad en Ezeiza. En lugar de pedir una fecha de vencimiento estática, la Fecha de Vencimiento Mínima Exigida es una función matemática en vivo de cuántas unidades quiere enviar la marca:

A. Fórmula Matemática Exacta

Cuando la marca ingresa una cantidad a enviar $Q_{\text{enviar}}$ para un SKU y selecciona una fecha de entrega en Ezeiza $F_{\text{entrega}}$ (por defecto, el próximo turno hábil disponible o Hoy + 3 días):

  1. Días totales que tardará en venderse todo el stock acumulado en Ezeiza ($D_{\text{agotamiento}}$):

$$D_{\text{agotamiento}}(Q_{\text{enviar}}) = \left\lceil \frac{\text{StockDisponible} + \text{StockEnTránsito} + Q_{\text{enviar}}}{V_{\text{diaria\_real}}} \right\rceil$$

  1. Margen de Vida Útil Mínima para el Consumidor Final ($M_{\text{consumidor}}$):
  1. Días Mínimos de Vida Útil Exigidos desde la Recepción ($D_{\text{vto\_mín}}$):

$$D_{\text{vto\_mín}}(Q_{\text{enviar}}) = D_{\text{agotamiento}}(Q_{\text{enviar}}) + 30\text{ días}$$

  1. Fecha de Vencimiento Mínima Exigida en el Envase ($F_{\text{vto\_mín}}$):

$$F_{\text{vto\_mín}}(Q_{\text{enviar}}) = F_{\text{entrega}} + D_{\text{vto\_mín}}(Q_{\text{enviar}})\text{ días}$$

B. Ejemplo Numérico Real (Cómo reacciona la UI al instante)

Supongamos un SKU que vende $10\text{ u./día}$, hoy tiene $50\text{ u.}$ en stock (5 días de cobertura), $0$ en tránsito, y la marca va a entregar el 02/11/2026:

📅 Vto. Mínimo Exigido para 600 u.: ≥ 05/02/2027 (95 días desde la entrega)
*Porque 650 u. totales tardarán 65 días en venderse + 30 días de margen para el consumidor.*
C. Calculadora Inversa cuando el Lote de la Marca vence antes (Doble Salida Inteligente)

En la misma fila, la marca puede ingresar la Fecha de Vencimiento real de su lote ($F_{\text{lote\_marca}}$). Si $F_{\text{lote\_marca}} < F_{\text{vto\_mín}}(Q_{\text{enviar}})$:

  1. El sistema calcula instantáneamente el Tope Máximo de Unidades Aceptables sin Promo ($Q_{\text{máx\_lote}}$):

$$\text{DíasDisponiblesParaVender} = (F_{\text{lote\_marca}} - F_{\text{entrega}}) - 30$$

$$Q_{\text{máx\_lote}} = \max\left(0,\; \lfloor \text{DíasDisponiblesParaVender} \times V_{\text{diaria\_real}} - (\text{StockDisponible} + \text{StockEnTránsito}) \rfloor\right)$$

  1. Y le presenta un modal/alerta interactiva con 2 botones de resolución inmediata:
[ Ajustar envío a {Q_máx_lote} u. ] *(Cantidad exacta que se venderá 30 días antes del vencimiento de tu lote sin riesgo de merma).*
[ Mandar {Q_enviar} u. y pre-autorizar Promo 20% / 30% OFF a los 60/45 días antes del vto ] *(Acelera la velocidad de venta estimada en $\times 1.6$ para evacuar el lote a tiempo; queda grabado en la purchaseOrder como acuerdo comercial pre-aprobado).*

5.3. Idea de Gaby 1 · Simulador Persuasivo en Vivo de Pérdida de Ventas por Sub-Envío

Muchas veces una marca Planter tiene miedo de enviar 45 días de mercadería o envía "un poquito para probar" (ej. el sistema le pide 450 u. porque vende 10 u./día, y la marca escribe 10 u. o 50 u.).

A. Fórmula del Simulador de Lucro Cesante (Valorizado a Precio de Liquidación de la Marca)

Cada vez que la marca modifica $Q_{\text{enviar}}$ por debajo de $Q_{\text{sugerida\_45d}}$ (o deja en 0 un SKU en estado URGENTE / REPONER):

  1. Días cubiertos con ese envío ($D_{\text{cubiertos}}$):

$$D_{\text{cubiertos}} = \frac{\text{StockDisponible} + \text{StockEnTránsito} + Q_{\text{enviar}}}{V_{\text{diaria\_real}}}$$

  1. Fecha exacta en que se quedará sin stock ($F_{\text{quiebre}}$):

$$F_{\text{quiebre}} = \text{Hoy} + \lfloor D_{\text{cubiertos}} \rfloor\text{ días}$$

  1. Días que estará apagado/sin stock dentro del ciclo de 45 días ($D_{\text{sin\_stock}}$):

$$D_{\text{sin\_stock}} = \max\left(0,\; 45 - D_{\text{cubiertos}}\right)$$

  1. Unidades y Facturación Neta que la marca perderá de cobrar en el ciclo ($\text{PlataPerdidaMarca}$):

$$\text{UnidadesPerdidas} = \text{round}(D_{\text{sin\_stock}} \times V_{\text{diaria\_real}})$$

$$\text{PlataPerdidaMarca} = \text{UnidadesPerdidas} \times \text{PrecioCompraVigenteSinIVA}$$

*(Nota de seguridad de datos: Siempre se multiplica por el costo de liquidación de la marca purchasePrice neto de IVA, jamás exponiendo el margen de Plant).*

B. Comportamiento Visual en Vivo en la Fila y en el Resumen del Envío
🚨 ¡Vas a quebrar en 1 día! Con 10 u. te quedás sin stock el miércoles 29/10 y dejás de facturar $1.980.000 este ciclo (440 u. perdidas durante 44 días sin stock en Web, B2B y Mercado Libre Full).
[ Subir a 450 u. sugeridas (+$1.980.000) ]

5.4. Visor de Vencimientos Actuales en Depósito (lotsTimestamps) + Botón de Promo FEFO

Gracias al hallazgo en la base de producción (inventoryAdjustments), sabemos que Recepción Ezeiza ya guarda hoy la fecha de vencimiento exacta de cada lote ingresado en data.controlReason.lotsTimestamps[pid][lotId] = { e: "YYYY-MM-DD", q: cantidad }.

En la pestaña Stock en depósito de sellers.plantinterno.com:

  1. Cruzamos en el generador (build_sellers.py y en vivo vía mongoAggregate) los últimos inventoryAdjustments de tipo receive confirmados del proveedor para mostrar en cada SKU su Desglose de Lotes y Vencimientos en Ezeiza:
  1. Semáforo FEFO y Escalera de Acción Comercial:
⏳ Tenés 84 u. de Hummus Clásico que vencen el 15/12/2026 (48 días) y al ritmo actual sobrarán 36 u. sin vender.
[ Activar Promo 25% OFF en este lote para liquidarlo a tiempo ]

5.5. Idea de Gaby 2 · Integración con el Google Calendar de Recepción Ezeiza de Mauro + Puente a purchaseOrders + Bot de Seguimiento

Paso 1: Creación de la Orden de Envío y Agendamiento en el Google Calendar de Mauro

Cuando la marca termina de armar su Orden de Envío en sellers.plantinterno.com:

  1. Validación de Datos de Despacho:
  1. Selección de Turno en el Google Calendar de Recepción Ezeiza (Unificado con Mauro):
  1. Impacto Triple Automático al Confirmar el Envío (POST /api/envio/crear):

📦 [PLANTER FULL] {Marca} — OC #{number} ({totalUnits} u. · {boxesCount} bultos)

  1. Carátula / Remito Interno Planter Full (OC #18315) con código de barras/QR de la OC, turno confirmado en Ezeiza (Fecha + Hora + Dirección del Centro de Distribución Ezeiza) y tabla de SKUs con el Vencimiento Mínimo Exigido impreso en cada renglón.
  2. Etiquetas de Bulto / Caja Master (Bulto 1 de N ... Bulto N de N) listas para pegar en las cajas externas.
Paso 2: Control en Muelle de Recepción Ezeiza
  1. Cuando llega el transporte de la marca a Ezeiza en el turno agendado, el equipo de Recepción abre la OC #18315 en su pantalla habitual de Recepción.
  2. El operario controla las unidades físicas, la temperatura y carga la fecha de vencimiento del lote en lotsTimestamps.
  3. Si algún lote físico tiene vencimiento menor al Vto. Mínimo Exigido que declaró la marca, Recepción tiene el respaldo inmediato en la orden para rechazar el lote en rampa o exigir autorización de promoción.
  4. Al confirmar la recepción en Ezeiza (status: "received"), el sistema dispara automáticamente el mail de «Confirmación de Ingreso Exitoso en Ezeiza» detallando unidades pedidas vs. recibidas y los vencimientos registrados.
Paso 3: Máquina de Estados de Seguimiento 100% Automatizado por Mail (Portal Planter <avisos@plant.com.ar>)

Compras nunca más persigue a una marca Planter por teléfono o WhatsApp. Un cron diario (08:30 hs y 18:00 hs AR) en el Worker audita el estado de stock y de turnos y ejecuta 5 flujos automáticos de correo institucional (siempre redactados en plural como Equipo de Plant, nunca a nombre personal de Gabriel):

Disparador AutomáticoAsunto del Correo (avisos@plant.com.ar)Contenido Ejecutivo y Botón de Acción (CTA)
1. Alerta Semanal / Quiebre Inminente (≥ 1 SKU con cobertura < 21 días y sin OC en tránsito)⚠️ {Marca}: tenés {N} productos por quebrar stock en Plant (dejás de facturar ${MontoPerdido}/mes)Tabla visual con los SKUs urgentes, cuántas unidades sugiere enviar para cubrir 45–49 días, cuánto dinero pierde la marca por cada semana sin stock y botón directo:<br>[ Armar Orden de Envío y Reservar Turno en Ezeiza ]
2. Confirmación de Orden de Envío + Turno + Etiquetas (Al confirmar en el portal)✅ Turno confirmado en Ezeiza — Orden de Envío #{OC} ({FechaTurno} {HoraTurno} hs)Resumen de la OC #{OC}, dirección y mapa del depósito de Ezeiza, tabla de SKUs con sus Fechas de Vencimiento Mínimas Exigidas en muelle, PDF adjunto con etiquetas de bulto y botón:<br>[ Descargar Etiquetas de Bulto / Reprogramar Turno ]
3. Recordatorio Preventivo 24 hs antes del Turno (Turno = Mañana y status == "pending")🚚 Recordatorio de entrega mañana en Ezeiza — Orden #{OC} ({HoraTurno} hs)Recordatorio amable de que mañana los esperamos en Ezeiza en la franja reservada, recordando traer Remito y verificar que los lotes cumplan el vencimiento mínimo exigido. Si tuvieron un imprevisto:<br>[ Confirmar Asistencia ] · [ Reprogramar Turno en 1 Clic ]
4. Seguimiento Automático por Atraso / No-Show (Día +1 a las 09:00 hs) (FechaTurno < Hoy y purchaseOrder.status == "pending" en MongoDB)📅 ¿Reprogramamos tu entrega en Ezeiza? — Orden de Envío #{OC} pendiente de ingresoTono 100% empático y profesional: *«Notamos que ayer no pudimos recibir tu Orden de Envío #{OC} en el centro de distribución de Ezeiza. Para evitar que tus productos entren en quiebre de stock (lo que representaría una pérdida estimada de ${MontoPerdido} en ventas para {Marca} este mes), habilitamos nuevos horarios prioritarios para esta semana.»*<br>[ Elegir Nuevo Día de Entrega en 1 Clic ]
5. Escalamiento Automático por Atraso Crítico (Día +4) (FechaTurno + 4d < Hoy y status == "pending", con copia a compras@plant.com.ar)🚨 {Marca}: tus productos están entrando en quiebre — reprogramá tu Orden #{OC}Muestra los SKUs que ya quebraron o quiebran esta semana, el impacto acumulado en pesos y el link de reprogramación inmediata. Si pasan 10 días sin respuesta ni reprogramación, archiva la OC vencida y alerta a Compras.

6. Especificación Técnica de Implementación (sellers.plantinterno.com + Plant Hub)

6.1. Arquitectura de Datos y Endpoints en sellers.plantinterno.com (Cloudflare Worker + KV + MongoDB/Calendar Bridge)

En worker/build_sellers.py:

  1. Enriquecimiento del Payload por Marca (armar_marca() en build_sellers.py):
  1. Nuevas Rutas Backend en el Worker de sellers.plantinterno.com:
  1. Cruza las purchaseOrders con source == "planter_full_2_0" y status == "pending" en mongoAggregate.
  2. Si slotDate == Mañana, dispara el Recordatorio 24 hs antes y guarda el sello anti-duplicado en KV (mail:rem24:{poId}).
  3. Si slotDate < Hoy y sigue status == "pending", dispara el Mail Amable de Reprogramación Día +1 / Día +4 cuantificando la pérdida por quiebre y guarda el sello en KV (mail:late1:{poId}).
  4. Los lunes a las 09:00 hs, para toda marca con SKUs en estado URGENTE sin OC en tránsito y sin mail en los últimos 7 días, dispara el Mail Semanal de Reposición Sugerida 45–49d.

6.2. Diseño UI/UX en la Pestaña #stock de sellers.plantinterno.com

La pestaña Stock en depósito de sellers.plantinterno.com evoluciona de una tabla estática a un Centro Interactivo de Reposición Full:

  1. Kpis Superiores Interactivos (Píldoras de Filtro estilo ML Full):
  1. Columnas de la Tabla Interactiva de Reposición:

⚠️ Quebrás en X días y perdés de facturar $XXX.XXX este mes.

📅 Exigido: ≥ DD/MM/AAAA (X días) (= Xd de venta + 30d margen consumidor).

  1. Barra Inferior Flotante (Sticky Action Bar) + Modal de Turno en Google Calendar de Ezeiza:

📦 Orden de Envío: {SKUs} productos · {Unidades} u. ({Bultos} bultos) · Facturación proyectada: ${MontoTotal}

*(+ Alerta ámbar si está dejando plata en la mesa por sub-envío en algún SKU)*.

7. Plan de Ejecución e Hitos de Despliegue

  1. Paso 1 (Configuración del Calendario con Mauro): Obtener el ID del Google Calendar de Recepción Ezeiza que hoy usa Mauro (o compartirlo con permisos de edición a avisos@plant.com.ar / Service Account de Plant) para que el Worker lea los huecos libres y cree los turnos ahí mismo.
  2. Paso 2 (Despliegue en sellers.plantinterno.com — worker/build_sellers.py):
  1. Paso 3 (Sincronización en Plant Hub — apps/supplier):

8. Distinción Legal y Operativa sobre Vencimientos: Planter (Consignación) vs. Compra-Venta Tradicional y Auditoría de la Presentación / Acuerdo Planter

Fuentes verificadas:

8.1. Hallazgo Forense Crítico: HM Granola (Homemade) y Yasmín (Jasmine) SÍ son Marcas Planter (100% Consignación)

  1. El lunes 26/10/2026 a las 10:19 hs, Mauro Stoessel le envió a Gaspar un correo con el asunto literal "Marcas Planter con Corto VTO" (1a177b87c93eebb3), listando 9 marcas Planter:
  1. **Por qué es un error conceptual decir *"intento negociar un descuento y que no tengamos que absorber todo eso nosotros"* en una marca Planter:**
  1. Retirar inmediatamente su lote de Ezeiza a su cargo, o
  2. Activar una liquidación por corto vencimiento (-30% a -50% OFF) bajando en igual proporción el purchasePrice de liquidación de ese lote, de modo que la marca recupere el 50%–70% de su mercadería antes de que venza y el margen de Plant quede 100% intacto.

8.2. Qué Dicen Textualmente Hoy la Presentación, la Web y el Alta del Modelo Planter (y qué Cláusula se Agrega)

*"Como la mercadería permanece en propiedad de la marca hasta su entrega efectiva, las unidades que alcancen su vencimiento sin haberse vendido no generan liquidación ni pago alguno por parte de Plant y quedan a disposición de la marca para su retiro. Cuando un lote alcance menos de 60 días de vida útil remanente, el sistema notificará a la marca para que en un plazo de 48 hs opte entre: (a) retirar el lote de Ezeiza, o (b) activar descuentos de liquidación rápida (-30% a -50% OFF), reduciéndose en igual proporción el valor neto de liquidación (purchasePrice) de las unidades vendidas bajo dicha acción para recuperar capital antes del vencimiento."*

8.3. Matriz de Blindaje de Vencimientos según Modalidad Comercial (Riesgo $0 para Plant)

DimensiónModalidad Planter Full 2.0 (Consignación) (Homemade, Jasmine, La Zaranda, Mami Keto, etc.)Modalidad Compra-Venta Tradicional
Propiedad legal del stock en Ezeiza100% de la marca (Seller) hasta que se vende (StockQuant.ownerId = sellerEntityId). Si vence sin venderse, no entra en liquidación y Plant paga $0.Propiedad de Plant una vez recibida y facturada la Orden de Compra.
Barrera 1 · En la Puerta de Entrada (Pre-Envío y Recepción Ezeiza)Calculadora Dinámica de Mauro en el Portal (sellers.plantinterno.com):<br>Al turnar el envío, exige que el lote tenga como mínimo:<br>FechaVto ≥ FechaTurno + DíasAgotamiento(StockActual + EnTránsito + CantidadAEnviar) + 30 días (margen consumidor final).<br>Si el lote vence antes, el portal bloquea el excedente (limitando las unidades a lo que se vende 30d antes del vto) o exige que la marca deje firmada y pre-aprobada una Promo FEFO atada a ese lote.Techo Duro de Cobertura del Motor de Compras 2.0:<br>Se prohíbe comprar más de 30 días de cobertura total en productos secos/generales y 21 días en perecederos/vida útil corta, más validación de vida útil mínima en muelle contra lotsTimestamps.
Barrera 2 · Durante la Estadía en Ezeiza (Escalera Automática FEFO)Regla Automática contractual (Cero negociación de absorción):<br>• A los 60 días del vto: Alerta automática en el portal y por mail (avisos@plant.com.ar) para que la marca elija en 48 hs entre retirar su lote o autorizar liquidación FEFO.<br>• A los 45 días del vto (si el stock remanente supera lo vendible antes de Vto - 30d): Se activa la liquidación FEFO reduciendo en el mismo % el purchasePrice de liquidación de ese lote, o se pasa a retiro obligatorio de la marca.<br>• A los 30 días del vto (piso de calidad al consumidor): El lote se bloquea automáticamente para la venta (QUARANTINED / SOON_TO_EXPIRE) y queda a disposición de retiro de la marca (pago $0 de Plant).Alerta Temprana FEFO a los 75/60 días (lotsTimestamps):<br>Si un lote de compra firme cae por debajo de su curva de evacuación, dispara acción promocional inmediata y reclamo automático temprano al proveedor 60 días antes de vencer (y no sobre la hora).

Novedades

Novedades

Novedades

Novedades

Novedades Recientes

━━━━━━━━━━━━━━

Acabo de auditar el código en vivo de sellers.plantinterno.com (worker/build_sellers.py, sección #stock) contra la especificación maestra de *Planter Full 2.0*. Acá tenés exactamente qué está subido hoy y qué quedó en diseño listo para desplegar:

*1. Qué YA está en vivo hoy en el portal (sellers.plantinterno.com)*

• *Tabla «Stock y envíos» (#stock)*: Hoy tiene 4 columnas activas (*Producto*, *Stock en Plant + Full ML*, *Cobertura en días* y *Sugerido a 45 días*) más el cartel superior de alerta de quiebre (*«Para hacer: X producto se queda sin stock en N días. Mandá Y u.»*).

• *Limitación actual*: Ese Sugerido hoy es solo un número estático (calculado sobre B2C + B2B sin sumar ML ni descontar días quebrados) y *todavía no tiene la columna de vencimiento ni el flujo interactivo*.

━━━━━━━━━━━━━━

*2. Qué quedó diseñado en «Planter Full 2.0» pero AÚN NO se inyectó en producción*

• *1) Columna Vto. por lote al lado del Stock*: Quedó especificada y maquetada en el prototipo, pero falta conectarla en build_sellers.py leyendo la pestaña *Stock y Vencimiento* de la planilla de Mauro (Armar Pedido Cálculos) + lotsTimestamps de Ezeiza para que la marca vea la fecha exacta de vencimiento de su stock actual.

• *2) Alertas de Corto de Fecha (<60d / <45d) con decisión a cargo de la marca*: Hoy el portal solo alerta por *falta de stock* (<14 días), pero aún no muestra el banner de *lote próximo a vencer* para que el seller elija con un clic entre *autorizar un descuento de liquidación a su cargo* (bajando su liquidación en igual %) o *programar el retiro*.

• *3) Sugerencia y Orden de Envío interactiva desde el portal*: Falta convertir el número fijo de Sugerido en el flujo interactivo donde el seller:

— Ve el sugerido real omnicanal a *45–49 días* (*Plant + Business + ML Full*, descontando días en stock cero) y cuánta venta pierde en pesos si manda de menos.

— Carga qué cantidad va a enviar y qué *fecha de vencimiento* tiene el lote nuevo, validado en vivo contra la *calculadora de vencimiento mínimo de Mauro* (Días hasta agotar stock actual y nuevo + 30 días de margen al consumidor).

━━━━━━━━━━━━━━

👉 *¿Querés que pongamos ahora mismo a inyectar y desplegar estas 3 mejoras directo en el worker productivo de sellers.plantinterno.com conectadas a la hoja de Stock y Vencimiento de Mauro?* · 🔗 auditoria-vivet-vencimientos-plant-hub, monitores-planter, monitores-plantinterno, acuerdos-comerciales, radar-marketing, plant-cyber-2026, camaras-frio-ezeiza-reemplazo-compresor, motor-compras-2-0-plan-maestro-noviembre, arqueologia-comunidad-gabriel-busso-instagram, activacion-patrimonio-camaras-tixo-vivet, fabrica-multimedia-autor-omnicanal, auto-calculo-compras-reposicion-stock, biblioteca-viva-del-super-cerebro · 2026-10-29

Novedades Recientes

━━━━━━━━━━━━━━

Corrimos el escuadrón completo (claude --model opus --effort high + codex gpt-6.1-sol, sesión 01a189ae-1ed6-7650-a2a1-31635c31e628 + QA Playwright E2E) auditando el código de sellers.plantinterno.com, las colecciones reales de MongoDB Producción (campaigns, products, orders), la planilla de Marti y Gaspi (*"Datos Mercado Libre" → "Precios para ML"*) y el repositorio de *Plant Hub*.

*1. ¿Qué hacía hasta hoy el botón Autorizar descuento en sellers.plantinterno.com?*

• *El punto ciego que tenía*: cuando apretabas Autorizar descuento, el worker (stockBetaGuardar) *sólo guardaba un registro en el KV sellers:beta:promos* y el cartel decía que ya estaba activo en los 3 canales, pero *en realidad no tocaba nada*:

  1. Ni siquiera la función liquidar() (pdParaML) del propio portal leía ese KV (sellers:beta:promos).
  2. No creaba la campaña en MongoDB (campaigns con area: "compras") ni bajaba el precio en plant.com.ar / business.plant.com.ar (maxDiscounts).
  3. No le avisaba a *Marti Ramundo* ni a *Gaspi Howlin*, ni actualizaba la hoja *"Precios para ML"*, ni cambiaba el precio en *Mercado Libre* (ni en la publicación individual 1x ni en los packs NN-CODIGO).

*2. ¿Cómo funciona de verdad hoy el circuito en plant.com.ar, Business y Mercado Libre?*

• *En plant.com.ar (B2C) y business.plant.com.ar (B2B)*: son *dos pasos separados* en MongoDB Producción (lo verificamos con las 10 campañas de Cyber que cargaron hoy mismo):

  1. *Gaspi* crea el documento en campaigns con data.area: "compras". Eso hace que cada orden entregada salga estampada con items.<pid>.providerDiscount = { id, d }, para que la liquidación Planter le descuente ese porcentaje al proveedor.
  2. *Marti* actualiza en products los campos data.maxDiscounts: { g, d } y data.priceWithDiscount: { g, d } para que el descuento se vea reflejado en el precio al público en plant.com.ar (g) y business.plant.com.ar (d).

• *En Mercado Libre (la planilla de Marti y Gaspi)*:

  1. Hoy operan sobre la Google Sheet *"Datos Mercado Libre"* → pestaña *"Precios para ML"* (3.295 publicaciones MLA mapeadas, incluyendo unidades 1x y packs NN-CODIGO como 06- o 12-).
  2. En la *Columna E (CAMPAÑA ACTIVA)*, Gaspi escribe el formato exacto "{desc}% - ${costo_con_dto}" (hoy hay 575 filas activas así). *Detalle clave de packs*: en esa planilla, la fila del pack 12-CODIGO ya tiene en la Columna D el costo multiplicado por 12, por lo que en la Columna E de cada pack también hay que escribir el costo del pack con descuento ("{desc}% - ${costo_pack_con_dto}").
  3. Con esa Columna E, la planilla recalcula la *Columna R (PRECIO ML CON DTO)* descontando Comisión ML (18,6%), IVA, Percepciones y escalas de $ ENVIO Full para bajar el precio en Mercado Libre manteniendo *100% intacto el margen de Plant*.

*3. ¿Qué dejamos conectado y desplegado YA MISMO en sellers.plantinterno.com?*

• *1) Estado real autorizado → aplicado con tope por lote (unidadesLote)*: como detectó Claude Opus, si liquidáramos el descuento apenas la marca aprieta "Autorizar" pero antes de que Marti/Gaspi bajen el precio al público, le cobraríamos a la marca un descuento que el cliente nunca vio. Ahora nace como autorizado y, cuando se activa (aplicadoDesde), liquidar() (pdParaML) lo descuenta automáticamente en las ventas de Mercado Libre y Plant hasta agotar las unidadesLote de ese lote.

• *2) Cruce automático de todas las publicaciones MLA (1x y packs NN-CODIGO)*: al abrir o confirmar un descuento en sellers.plantinterno.com, el modal cruza el SKU contra ml:mapa y stockmap y muestra la *tabla completa de publicaciones MLA alcanzadas (individual y packs)* con el texto exacto listo para copiar y pegar en la *Columna E (CAMPAÑA ACTIVA: "25% - $3300")* de la planilla de Marti + el botón *«Copiar Col E para Precios para ML»*.

• *3) Capa persistente ml:mapa:camp*: guarda el costo promocional de cada MLA en una clave separada (ml:mapa:camp) que se superpone sobre ml:mapa, para que el cron de las 08:00 AM (refrescarMapaML) no lo pise si todavía no lo cargaron en el Excel.

*4. ¿Juanchi contempló eliminar el Excel de Marti y Gaspi en Plant Hub? (Los 4 huecos encontrados)*

• Auditamos todo packages/business-logic/src/mercadolibre/ en Plant Hub. Juanchi armó una base excelente (listing-prices.ts, listing-profitability.ts, listing-promotions.ts, omnichannel-price.ts), *PERO hoy NO puede jubilar el Excel de Marti y Gaspi* porque le faltan *4 piezas críticas*:

  1. *No existe providerDiscount en la base de datos de Plant Hub*: ni Promotion (marketing.prisma), ni OrderItem (order.prisma), ni SellerSettlement tienen providerDiscountBps (descuento absorbido por la marca). Hoy si creás una promo en Plant Hub, Plant absorbe el 100% de la pérdida y no se descuenta de la liquidación Planter.
  2. *Los guardrails de margen de Plant Hub bloquean los descuentos de proveedores*: tanto assertPromotionGrossMargin como calculateListingProfitability validan el precio con descuento contra purchasePrice bruto en vez de purchasePrice * (1 - providerDiscountBps). Si una marca autoriza -35% para salvar un lote, Plant Hub cree que Plant vende a pérdida (InsufficientListingMarginError) y *bloquea la promoción*.
  3. *listing-promotions.ts en Plant Hub es 100% de solo lectura (GET)*: sólo lee promociones de ML (GET /seller-promotions/items/{id}), pero *no tiene el POST /seller-promotions/items/{id}* para activar un PRICE_DISCOUNT con precio tachado en Mercado Libre ni propagarlo automáticamente a los packs NN-CODIGO (unitsPerListing).
  4. *La fórmula de rentabilidad ML (listing-profitability.ts) tiene un bug de IVA y le faltan Percepciones y Envío Full*: en la línea 26 el propio código tiene un comentario admitiendo que compara el precio ML *con IVA* contra el costo *sin IVA* (inflando el margen ~17 puntos), no resta *Percepciones (~3-5%)* y tiene freeShippingCostCents = 0 en vez de las escalas de envío Full de la planilla de Marti.

*5. Especificación lista para mandarle a Juanchi (¿querés que se la mande?)*

• Armamos el instructivo técnico exacto de 4 puntos para Juanchi (modelo SupplierDiscountAuthorization + providerDiscountBps en Promotion/OrderItem/SellerSettlement, costo efectivo en listing-profitability.ts corrigiendo IVA/Percepciones/Envío Full, y mutación POST en listing-promotions.ts propagando a packs NN-CODIGO) para que cuando una marca autorice un descuento o cambie un costo, impacte directo en Plant, Business y Mercado Libre y *jubilemos para siempre el Excel "Precios para ML" de Marti y Gaspi*. ¿Te parece bien que le mande esta especificación a Juanchi? · 🔗 plant-cyber-2026, monitores-planter, monitores-plantinterno, acuerdos-comerciales, radar-marketing, procedimiento-campanas-plant, planter, lunes-05-octubre-plan-ejecucion-gaby, estado-vivo-marcas-proveedores, motor-compras-2-0-plan-maestro-noviembre, mercado-libre-flex-congelados-simulador-mcp, arqueologia-comunidad-gabriel-busso-instagram, fabrica-multimedia-autor-omnicanal, auto-calculo-compras-reposicion-stock, envio-a-full-ml-estrategia-cyber, plant-hub, biblioteca-viva-del-super-cerebro #estrategia:cyber-2026 #objetivo:liquidacion-planter · 2026-10-29

Temas/planter-full-2-0-especificacion-maestra