Reposición Inteligente de Stock

¿Qué hace este flujo y qué problema resuelve?

Resumen ejecutivo: este flujo automatiza la reposición de artículos críticos mediante un proceso nocturno que detecta niveles bajos de stock, calcula la cantidad óptima a pedir teniendo en cuenta parámetros comerciales (punto de reorden, stock de seguridad, lote mínimo del proveedor) y genera las órdenes de compra en el ERP, notificando al proveedor por email. El objetivo es reducir roturas de stock, liberar tiempo del equipo de compras y asegurar continuidad en producción.

Problemática concreta: en empresas industriales y de consumo con catálogos de 50 a 5.000 referencias, el trabajo manual de identificación y generación de órdenes provoca errores humanos, retrasos en producción y sobrecarga administrativa. Ejemplo realista: en TeknoMetal S.A., las roturas en el insumo 'Acero-pieza A' causaron paradas de línea por 4 horas mensuales y pérdidas estimadas en 12.000 EUR/mes por retrasos. Con un flujo automatizado se reduce la dependencia del recuerdo humano y se acelera la reacción frente a desvíos de demanda.

Qué hace el flujo paso a paso:

• Programación nocturna (nodo Cron n8n) para ejecutar el proceso fuera de horas pico.
• Lectura de stock y movimientos desde el ERP vía API o consulta a BBDD (nodos HTTP Request / PostgreSQL / MySQL).
• Filtrado de artículos críticos definidos por compras (nodo Set + nodo IF).
• Cálculo de punto de reorden y cantidad óptima con un nodo Function (JavaScript) que incorpora MOQ (cantidad mínima de pedido), lotes de proveedor y rounding comercial.
• Creación de la orden de compra en el ERP (HTTP Request) con estado pendiente para revisión o directamente aprobada según política.
• Notificación por email al proveedor y al equipo de compras (nodo Email Send / SMTP).

Impacto esperado: eliminar roturas por olvido, reducir tiempo de generación de órdenes en un 80%, mejorar visibilidad sobre necesidades y acelerar lead time entre pedido y recepción. Métrica objetivo: reducir roturas en artículos críticos al 1% mensual y reducir ciclo compras en un 70%.

Roles y responsabilidades breves: Director de Compras / COO define parámetros por artículo (stock mínimo, máximo, punto de reorden, proveedor homologado, MOQ, lead time). Equipo IT/Data implementa y mantiene las conexiones ERP, la lógica de cálculo y la seguridad (credenciales, roles de API). Equipo de Compras valida órdenes en modo borrador las primeras 2 semanas y ajusta parámetros por excepción.

Recomendación operativa: arrancar con un piloto de 20-50 referencias críticas, operar en modo borrador (estado PENDIENTE_CONFIRMACION) durante 10-14 días, revisar métricas y excepciones, luego escalar al catálogo completo y activar envío automático.

Cuándo usar este flujo

Prerrequisitos

Antes de implementar el flujo, verifique y prepare los siguientes elementos:

• Acceso al ERP: credenciales de API con permisos para consultar inventario y crear órdenes de compra. Parámetros necesarios: [ERP_API_URL], [ERP_API_KEY], alcance de recursos y límites de tasa (rate limits).
• Catálogo estándar: para cada SKU crítico, disponer de: código interno, descripción, proveedor homologado, MOQ (cantidad mínima de pedido), lote comercial, lead time en días, stock mínimo, stock máximo, punto de reorden y consumo diario promedio.
• Esquema de comunicaciones: cuenta SMTP o servicio de correo transaccional para notificaciones a proveedores y confirmaciones internas. Parámetros: [SMTP_HOST], [SMTP_PORT], [SMTP_USER], [SMTP_PASS], plantilla de email.
• Ambiente n8n: instancia con nodos habilitados HTTP Request, Cron, Function, Set, If, Merge, SMTP Email Send, y, si aplica, nodos de base de datos (MySQL/Postgres) o conexión SFTP para extractos CSV.
• Seguridad y compliance: lista blanca de IPs, cifrado de credenciales en n8n (secrets), roles de acceso, y registro de auditoría de órdenes generadas automáticamente.

Datos de ejemplo para configuración inicial (ficticio y listo para copiar):

ERP_API_URL='https://erp.teknoexample.local/api'
ERP_API_KEY='[TOKEN_DE_INTEGRACION]'
SMTP_HOST='smtp.correoserv.com'
SMTP_PORT='587'
SMTP_USER='integraciones@miempresa.com'
SMTP_PASS='[SMTP_PASS]'
PROVEEDOR_DEFECTO='Provex Logistic'
TIEMPO_ARRANQUE_PILOTO_DIAS=14

Acciones previas requeridas por Compras:

• Definir y validar la lista inicial de SKUs críticos y sus parámetros de reposición en un spreadsheet compartido.
• Comunicar a proveedores clave el cambio de proceso y obtener emails o canales EDI para recepción de pedidos.
• Acuerdo para modo borrador: confirmar que el ERP aceptará órdenes con estado PENDIENTE_CONFIRMACION para revisión manual.

Consideración técnica: si el ERP no tiene API, se puede usar extracción nocturna vía consulta directa a la BBDD (nodo PostgreSQL/MySQL) o ingestion de CSV por SFTP. En ese caso, estandarice columnas y verifique zonas horarias para evitar inconsistencias en stock disponible.

Definición de parámetros de reposición

Objetivo: establecer los criterios cuantitativos y comerciales que guiarán el algoritmo de reposición. Sin parámetros claros, el flujo tomará decisiones imprecisas que pueden generar exceso de stock o roturas.

Pasos detallados:

1. Inventariado inicial: revisar la lista de SKUs críticos y asegurar que cada registro incluya: código SKU, descripción, proveedor homologado, MOQ, lote de compra (si aplica), lead time en días, consumo promedio diario, stock mínimo y máximo, punto de reorden actual. Responsable: Compras.
2. Calcular demanda diaria: usar 90 días de historial para obtener promedio diario y desviación estándar. Fórmula simple: demanda_diaria_prom = total_vendido_90d / 90. Considere estacionalidad para categorías de consumo variable.
3. Definir stock de seguridad: stock_seguridad = z * desviación_demanda * sqrt(lead_time), donde z es factor de servicio (p. ej., 1.65 para 95% servicio). Para directivos: elegir z según riesgo de falta: 1.28 (90%), 1.65 (95%), 2.33 (99%).
4. Establecer punto de reorden: ROP = demanda_diaria_prom * lead_time + stock_seguridad. Redondear según unidad de manejo (por ejemplo, a cajas de 10 uds).
5. Política de lote: definir cómo aplicar MOQ y lotes comerciales. Política típica: si cálculo sugiere pedir Q, pedir el mínimo k*MOQ donde k=ceil(Q/MOQ) y respetar lotes de empaquetado.

Configuración n8n sugerida:

• nodo Cron: programar ejecución diaria a 23:00. Settings: Mode='Every Day', Time='23:00'.
• nodo HTTP Request / PostgreSQL: recuperar histórico de ventas y stock actual. Example HTTP Request: Method='GET', URL='[ERP_API_URL]/inventory/sku?skus=[LISTA_SKU]', Headers: Authorization: 'Bearer [ERP_API_KEY]'.
• nodo Function (llamado 'CalculosReponer'): implementar lógica para calcular demanda diaria, desviación y ROP. Código ejemplo (usar en nodo Function):

  items[0].json.sku_list.forEach(sku => {
    const demanda_prom = sku.total_90d / 90;
    const desviacion = sku.stddev_90d || (demanda_prom*0.3);
    const z = sku.factor_servicio || 1.65;
    const stock_seg = Math.ceil(z * desviacion * Math.sqrt(sku.lead_time));
    const rop = Math.ceil(demanda_prom * sku.lead_time + stock_seg);
    sku.calculos = {demanda_prom, desviacion, stock_seg, rop};
  });
  return items;

• nodo Set: normalizar campos de salida con nombres comprensibles: sku, stock_actual, rop, demanda_prom, lead_time, moq, proveedor.

Consideraciones de negocio y técnica:

• El factor de servicio (z) debe aprobarse por Director de Compras; documente trade-offs entre nivel de servicio y capital inmovilizado.
• Considere SKU con demanda intermitente: para demandas con muchos ceros use modelos basados en cobertura de días (p. ej., mantener stock para n días mínimos) en lugar de promedio simple.
• Reglas comerciales: si un proveedor ofrece descuentos por volumen, agregue en la política una regla que permita agrupar pedidos dentro de ventanas de tiempo (p. ej., consolidar semanalmente) y calcule costos totales.

Ejemplo concreto:

SKU: TM-ACERO-A; proveedor: Provex Logistic; datos: stock_actual=60 uds, total_90d=900 uds (demanda_prom=10 uds/día), desviacion=3 uds, lead_time=5 días, MOQ=100 uds.

Cálculo: stock_seg = 1.65*3*sqrt(5)=11 (aprox). ROP = 10*5 + 11 = 61 uds. Con stock_actual 60 < ROP 61 → pedido necesario. Cantidad requerida = ROP - stock_actual = 1 uds; aplicar MOQ → pedir 100 uds. Orden sugerida: 100 uds (provoca rotación saludable y cumple MOQ).

Análisis nocturno del stock

Objetivo: ejecutar una extracción periódica y fiable del estado de inventario y consolidar señales de reabastecimiento antes de calcular pedidos. El análisis nocturno evita interferencias con operaciones diurnas y garantiza datos coherentes al cierre de jornada.

Flujo técnico fase por fase:

1. nodo Cron: disparador a las 23:00. Configuración: Mode='Specific Time', Timezone='[TIMEZONE]', Time='23:00'. Use el mismo timezone del ERP para evitar desplazamientos.
2. nodo HTTP Request / DB: extraer stock actual y movimientos del día. HTTP Request configuración ejemplo: Method='GET', URL='[ERP_API_URL]/stock/levels?skus=[LISTA_SKU]', Headers: Authorization: 'Bearer [ERP_API_KEY]', Response Format='JSON'. Si no hay API, usar nodo PostgreSQL: Query='SELECT sku, stock_actual, reserved, on_order, last_movement_date FROM inventory WHERE sku IN ([LISTA])'.
3. nodo Function de enriquecimiento: combinar datos de stock con parámetros de reposición previamente cargados (tabla maestra). Lógica: stock_disp = stock_actual - reserved. Si stock_disp <= rop → marcar para pedido.
4. nodo If: bifurcar items que necesitan reposición vs. no necesitan. Condición: json.stock_disp <= json.rop.
5. nodo Merge: consolidar lista de SKUs a procesar y preparar payload para cálculo de cantidades.

Consideraciones técnicas y de negocio:

• Reservations y órdenes pendientes: asegúrese que la extracción incluya 'reserved' o 'allocated' para no sobreestimar stock disponible. En TeknoMetal S.A. se detectaron 20% de discrepancia cuando no se descontaron reservas de producción.
• Zonas y almacenes múltiples: si opera con varios almacenes, la lógica debe permitir reglas por ubicación: por ejemplo, no consolidar SKUs de almacenes distintos si no existen acuerdos logísticos para traslado.
• Horarios y conciliación: ejecutar conciliación de movimientos del día previo antes de tomar decisiones; si el ERP registra movimientos nocturnos, programe el flujo después del cierre de inventario.

Configuración n8n práctica (paso a paso):

• Crear nodo Cron (nombre 'Cron - Reposicion Nocturna') y conectar a nodo HTTP Request ('ERP - Obtener Stock').
• En 'ERP - Obtener Stock': Method='GET', URL='[ERP_API_URL]/inventory/stockLevels', Query Parameters: 'skus' con expresión de input, Headers: Authorization: 'Bearer [ERP_API_KEY]'. Set 'Response Format' a JSON y 'Full Response' a false.
• Conectar HTTP Request a nodo Function llamado 'CalcularDisponibilidad'. Código a usar en Function (lista para copiar):

  const skuData = items[0].json.data; const maestra = $input.all().find(i => i.json.maestra)?.json.maestra || {};
  return skuData.map(s => {
    const skuMaster = maestra[s.sku] || {};
    const stock_disp = s.stock_actual - (s.reserved || 0);
    const needsReorder = stock_disp <= skuMaster.rop;
    return { json: { sku: s.sku, stock_actual: s.stock_actual, reserved: s.reserved, stock_disp, ...skuMaster, needsReorder } };
  });

• Agregar nodo If ('Necesita Reponer?') con condición 'json.needsReorder == true'. Salida true: seguir al cálculo de pedido. Salida false: registro de no acción en log interno (nodo Set + nodo Append to DB/CSV).

Ejemplo concreto:

Almacén: Planta Norte. SKU: TM-ACERO-A. Resultado extracción: stock_actual=60, reserved=10 → stock_disp=50. ROP calculado previamente=61 → needsReorder=true. El SKU pasa a la cola de cálculo de pedido. Notificar en el log por email interno a compras con resumen de SKUs marcados.

Cálculo del pedido óptimo

Objetivo: convertir la señal de reposición en una cantidad de pedido comercialmente válida y alineada con restricciones proveedor, inventario y coste.

Reglas que incorpora el cálculo:

• Pedir para alcanzar stock objetivo (por ejemplo, stock máximo o cobertura de X días).
• Respetar MOQ (cantidad mínima de pedido) y múltiplos de lote.
• Considerar órdenes pendientes en tránsito para evitar sobrepedido.
• Aplicar rounding comercial (por cajas, palets).

Configuración n8n y lógica técnica paso a paso:

1. Entrada: lista de SKUs marcada para reposición con campos: stock_disp, rop, stock_max, moq, lead_time, demand_prom, on_order.
2. nodo Function 'CalcularCantidadPedido': lógica principal. Código listo para copiar (usar en nodo Function):

   return items.map(it => {
     const s = it.json;
     const objetivo = s.stock_max || Math.ceil(s.demand_prom * (s.lead_time + 7));
     // cantidad necesaria para llegar a objetivo
     let qtyNeeded = Math.max(0, objetivo - s.stock_disp - (s.on_order || 0));
     // asegurar al menos ROP - stock_disp si se prefiere pedido mínimo
     if(qtyNeeded <= 0) qtyNeeded = s.moq || 0;
     // aplicar MOQ y múltiplos de lote
     const moq = s.moq || 1;
     const unidadesPorLote = s.lote || 1;
     const base = Math.ceil(qtyNeeded / moq) * moq;
     const finalQty = Math.ceil(base / unidadesPorLote) * unidadesPorLote;
     s.qty_order = finalQty;
     s.justificacion = `Objetivo ${objetivo} - stock_disp ${s.stock_disp} - on_order ${s.on_order||0}`;
     return { json: s };
   });

3. nodo Set: preparar payload de orden con estructura del ERP: proveedor_id, lines: [{sku, qty, price_unit_estimado}], fecha_requerida = fecha_actual + lead_time días.
4. nodo If 'Excepciones': detectar casos para revisión manual: qty_order >= [UMBRAL_VALOR_ALTO] o cambios en MOQ no previstos. En true enviar a estado PENDIENTE_CONFIRMACION y alertar a Compras; en false proceder a creación automática.

Consideraciones comerciales:

• Política de agrupación: para proveedores que aplican descuentos por volumen, se puede agregar una regla que agrupe pedidos por proveedor hasta una ventana (p. ej., 48 horas) y re-calcular cantidades óptimas de forma agregada.
• Caso de lead times largos: si lead_time > 14 días utilizar cobertura objetivo en días (ej. objetivo = demanda_prom * (lead_time + 7)).
• Integración con coste: si la empresa trabaja con control de costes, incluya el campo price_unit_estimated para permitir cálculo de impacto en capital comprometido.

Ejemplo concreto y resultado intermedio:

SKU TM-ACERO-A: stock_disp=50, stock_max=300, demand_prom=10/día, lead_time=5 días, on_order=0, moq=100, lote=100.

Objetivo = stock_max = 300. qtyNeeded = 300 - 50 = 250. Base al aplicar MOQ=100 → ceil(250/100)*100 = 300. Aplicar lote=100 → finalQty=300. Pedido sugerido: 300 uds. Justificación: objetivo 300 - stock_disp 50.

Flag de excepción: Si finalQty implica inversión superior a [UMBRAL_VALOR_ALTO] (por ejemplo, 25.000 EUR), ruta a revisión manual por Compras y Finanzas.

Creación de OC y envío al proveedor

Objetivo: materializar la decisión en una orden de compra en el ERP y notificar al proveedor con la información necesaria para preparar el despacho.

Pasos operativos con configuración n8n:

1. Preparar payload para ERP: utilizar nodo Set para construir el JSON conforme a la API del ERP. Campos típicos: {'provider_id': [ID], 'order_date': '[YYYY-MM-DD]', 'delivery_date': '[YYYY-MM-DD]', 'lines': [{'sku': 'TM-ACERO-A','qty':300,'unit_price':52.5}], 'notes':'Generada automáticamente - revisar'}.
2. nodo HTTP Request 'ERP - Crear OC': Method='POST', URL='[ERP_API_URL]/orders', Headers: Authorization: 'Bearer [ERP_API_KEY]', Content-Type: 'application/json', Body Parameters: raw JSON body desde nodo Set. Respuesta: almacenar order_id y order_status.
3. Estado de la orden: si en modo piloto usar estado 'PENDIENTE_CONFIRMACION' (campo status='PENDIENTE_CONFIRMACION') para revisar manualmente en ERP. Para modo automático usar status='ENVIADA' o estado equivalente que dispare workflow de proveedor.
4. nodo Email Send 'Notificar Proveedor': usar plantilla con variables: proveedor, order_id, lines. Configuración SMTP: Host='[SMTP_HOST]', Port='[SMTP_PORT]', From='compras@empresa.com', To='[email_proveedor]'. Ejemplo asunto: 'Orden de Compra [order_id] - [proveedor]'. Cuerpo en texto y adjunto PDF opcional.
5. nodo Function 'GenerarPDF' (opcional): generar resumen en PDF usando servicio externo o plantillas HTML convertidas a PDF para adjuntar al email.

Consideraciones técnicas y de negocio:

• Confirmación y recepciones: incluir en la OC campo fecha_requerida y condiciones de envío. Registrar order_id en la base interna para seguimiento y conciliación de recepciones.
• Errores en creación de OC: manejar respuesta HTTP no 200 con reintentos y alertas. Mantener log con motivo del fallo y payload para análisis.
• Política de envío: en piloto enviar email interno a compras y copia al proveedor. En producción, automatizar envío directo al proveedor si se tiene acuerdo contractual y condiciones claras.

Prompt listo para usar en nodo AI/Moderación (si aplica):

Revisa la siguiente orden de compra y detecta riesgos o anomalías: 
Proveedor: [PROVEEDOR]
Order ID provisional: [ORDER_TEMP_ID]
Líneas:
[LISTA_LINEAS]
Reglas: marca si existe overstock (>2x rotación mensual), pedido que excede MOQ inusual, discrepancia entre precio unitario y último precio conocido (>10%).
Respuesta requerida: lista de alertas con campo 'riesgo' y 'recomendación'.

Ejemplo concreto (flujo completo):

Input calculado: Order payload para Provex Logistic: provider_id=PVX-001, order_date='2026-07-15', delivery_date='2026-07-20', lines=[{sku:'TM-ACERO-A', qty:300, unit_price:52.5}].

Respuesta ERP: {order_id:'OC-2026-000452', status:'PENDIENTE_CONFIRMACION'}. Email enviado a compras@teknoexample.com y a compras@provexlogistic.com con asunto 'Orden de Compra OC-2026-000452 - Provex Logistic'.

Control final: registrar order_id, fecha_envio, usuario_aprobador (si aplica) y cierre del ticket de revisión. Monitorizar confirmación de proveedor dentro de 48 horas; si no responde, escalar a comprador asignado.

Output esperado del flujo

Salida operativa: cada ejecución nocturna produce un conjunto de artefactos que permiten a compras y operaciones tomar acciones o archivarlas automáticamente.

Artefactos principales por ejecución:

• Lista de SKUs evaluados con campos calculados: sku, stock_actual, stock_disp, rop, demanda_prom, qty_sugerida, motivo.
• Órdenes de compra generadas en ERP con order_id y estado (PENDIENTE_CONFIRMACION o ENVIADA).
• Emails de notificación enviados a proveedores y al equipo interno.
• Registro de excepciones y errores en log central (base de datos o CSV en SFTP).

Ejemplo concreto de output (JSON ficticio listo para usar):

{
  "execution_date": "2026-07-15T23:00:00Z",
  "skus_evaluados": [
    {"sku":"TM-ACERO-A","stock_actual":60,"reserved":10,"stock_disp":50,"rop":61,"demand_prom":10,"qty_sugerida":300,"proveedor":"Provex Logistic","justificacion":"Objetivo 300 - stock_disp 50"},
    {"sku":"TM-TORN-12","stock_actual":120,"reserved":0,"stock_disp":120,"rop":100,"demand_prom":4,"qty_sugerida":0,"proveedor":"FastParts S.A.","justificacion":"No requiere"}
  ],
  "ordenes_creadas": [
    {"order_id":"OC-2026-000452","provider_id":"PVX-001","status":"PENDIENTE_CONFIRMACION","total_lines":1,"total_amount":15750},
    {"order_id":null,"provider_id":"FAST-001","status":"NO_ACTION","reason":"No requiere"}
  ],
  "emails_enviados": [
    {"to":"compras@provexlogistic.com","subject":"Orden de Compra OC-2026-000452","sent":true}
  ],
  "errores": []
}

Indicadores de control que deben mostrarse en el dashboard diario:

• Número de SKUs con reposición propuesta
• Valor total de órdenes propuestas
• Órdenes en estado pendiente de confirmación
• Errores críticos en integración

Acción esperada por Compras: revisar órdenes en estado PENDIENTE_CONFIRMACION cada mañana, aprobar o ajustar cantidades y activar envío final al proveedor cuando proceda.

Problemas frecuentes y cómo resolverlos

Esta sección enumera errores típicos, síntomas observables, causas probables y acciones correctivas concretas. Incluye 5 problemas frecuentes con pasos de resolución.

1. Error 1: Fallo en la conexión al ERP
   • Síntoma: nodo HTTP Request devuelve 401/403 o timeout; ejecución queda en error.
   • Causa probable: credenciales incorrectas, token expirado, IP no autorizada o cambios en endpoint del ERP.
   • Solución:
   1. Verificar credenciales: pruebe la misma llamada desde Postman con [ERP_API_KEY].
   2. Comprobar logs del ERP para rechazos por IP; añadir la IP de la instancia n8n a la whitelist.
   3. Implementar reintentos exponenciales en n8n y alertas cuando fallen 3 intentos consecutivos.
   4. Documentar y rotar credenciales si el token ha caducado; configurar proceso de renovación automática si el ERP lo permite.
2. Error 2: Diferencias entre stock en ERP y stock en planta
   • Síntoma: el flujo genera pedidos para SKUs que físicamente no están agotados o no detecta roturas reales.
   • Causa probable: movimientos no registrados al cierre, diferencias de inventario o uso de distintas ubicaciones/almacenes sin consolidación.
   • Solución:
   1. Implementar conciliación diaria: comparar movimientos del día y realizar un proceso de ajuste manual para SKUs con discrepancias mayores a X%.
   2. Incluir campo 'reserved' en extracción y ajustar stock_disp = stock_actual - reserved.
   3. Definir una ventana de tolerancia inicial (por ejemplo, 24-48 horas) mientras se estabiliza la calidad de datos.
3. Error 3: MOQ provoca pedidos gigantes o sobrestock
   • Síntoma: pedidos resultantes con cantidades mucho mayores a la demanda real, generando inmovilizado elevado.
   • Causa probable: aplicar MOQ estrictamente sin considerar consolidación de pedidos o descuentos por volumen.
   • Solución:
   1. Revisar política de MOQ: negociar con proveedor escalas de MOQ por SKU o introducir ventanas de consolidación (p. ej., consolidar semanalmente).
   2. Implementar regla en el nodo Function que limite la cantidad máxima pedido por SKU en un periodo (ejemplo: no más de 3 veces la demanda mensual) y marcar excepción si se excede.
   3. Para SKUs costosos, activar revisión manual automática si el pedido excede un umbral económico.
4. Error 4: Fallo en envío de emails a proveedores
   • Síntoma: emails no llegan o quedan en cola SMTP; proveedores no reciben OC.
   • Causa probable: credenciales SMTP caducadas, bloqueo por filtro de spam, problemas de DNS o rate limits del proveedor de correo.
   • Solución:
   1. Comprobar estado de la cuenta SMTP y credenciales en n8n; probar enviando un email manual desde la misma cuenta.
   2. Configurar SPF/DKIM/DMARC para el dominio de envío para evitar filtrado por spam.
   3. Implementar reintentos y cola de envío en n8n; enviar copia a un email interno para confirmar emisión.
   4. Documentar plan B: si el proveedor no recibe email en 2 horas, notificar vía teléfono o EDI según acuerdos.
5. Error 5: Órdenes creadas con status incorrecto o duplicadas
   • Síntoma: el ERP muestra órdenes duplicadas o con estado ENVIADA cuando debían quedar en PENDIENTE_CONFIRMACION.
   • Causa probable: condiciones de modo piloto no aplicadas, malos mapeos en payload o re-ejecuciones sin idempotencia.
   • Solución:
   1. Implementar idempotencia: usar un campo external_reference o client_id en el payload con un identificador único por ejecución (por ejemplo, 'reposicion_[fecha]_[lote]'). El ERP debe aceptar external_reference para evitar duplicados.
   2. Verificar mapeos de campo para estado: confirmar que el campo 'status' en el payload coincide con valores aceptados por la API del ERP.
   3. Si el flujo puede ejecutarse manualmente varias veces, añadir un bloqueo temporal (lock) al inicio de la ejecución para evitar solapamientos.

Recomendación final para gestión de incidencias: mantener un registro centralizado de errores con asignación clara de responsables, SLA de resolución y pasos de mitigación temporal (por ejemplo, pasar a proceso manual mientras se corrige). Para directivos: establecer un dashboard con métricas de error (número de fallos, tiempo medio de resolución) y revisar semanalmente las excepciones críticas.

Adaptaciones del flujo para otros contextos

El flujo base se puede adaptar a distintos modelos de negocio y niveles de madurez tecnológica. A continuación, variantes prácticas y cómo implementarlas:

1. Consolidación por proveedor: en lugar de procesar SKUs individualmente, agrupar por proveedor para optimizar costes de transporte y MOQ. Implementación: tras cálculo de qty por SKU, agregar nodo Function que agrupe líneas por provider_id y recalcule lotes agregados. Ejemplo: en lugar de 3 pedidos de 100 uds cada uno, consolidar a 300 uds y negociar mejor tarifa.
2. Reposición por punto de venta (omnicanal): si se opera retail con múltiples tiendas, ejecutar reglas por ubicación y añadir nodo que recomiende transferencias inter-almacén como alternativa a compra externa. Técnica: incluir atributo warehouse_id y regla de jerarquía (reponer desde central antes de comprar).
3. Modo 'Justo a Tiempo' con forecast avanzado: sustituir promedio simple por forecast generado por ML. Integrar nodo HTTP Request hacia servicio de predicción (o usar nodo n8n HTTP para llamar modelo interno). El nodo Function adapta la demanda_prom por forecast_14d y recalcula ROP.
4. Integración EDI: para proveedores con EDI, sustituir el nodo Email Send por nodo HTTP Request/EAI que emita mensajes EDIFACT o XML. Configuración: transformar payload a formato requerido y entregar mediante SFTP/AS2 con credenciales del proveedor.
5. Gestión de emergencias: crear ruta de excepción para pedidos urgentes que bypassen MOQ cuando la producción está en riesgo. En n8n: nodo If que detecte flag 'emergencia' y genere OC con cantidad mínima necesaria, notificando a la dirección para aprobación retroactiva.

Ejemplo de empresa y variante aplicada: IndustriaPack S.A. tiene proveedores con descuentos por tonelada. Implementaron consolidación por proveedor y ventana de 72 horas; como resultado redujeron coste logístico en 18% y disminuyeron MOQ efectivo al negociar entregas trimestrales agrupadas.

Consideraciones para la selección de variante:

• Impacto en cash-flow: consolidación aumenta capital inmovilizado; evaluar con Finanzas.
• Acuerdo contractual con proveedores: EDI y entregas consolidadas requieren renegociación previa.
• Complejidad técnica: forecasting y ML implican infra adicional y gobernanza de modelos.

¿Qué hacer ahora?

Paso inmediato recomendado para directivos:

1. Seleccionar un piloto con 20-50 SKUs críticos y documentar sus parámetros de reposición en un spreadsheet compartido esta semana.
2. Solicitar a IT/Data preparar acceso de lectura al ERP y un entorno n8n de pruebas. Entregar los parámetros: [ERP_API_URL], [ERP_API_KEY], [SMTP_HOST].
3. Planificar periodo piloto de 14 días en modo borrador (estado PENDIENTE_CONFIRMACION) y medir: número de órdenes generadas, excepciones y reducción de roturas.

Plantilla rápida de checklist para arrancar:

• Lista SKUs crítica: completada
• Credenciales ERP: entregadas a IT
• Cuenta SMTP para notificaciones: configurada
• Periodo piloto: calendario aprobado

Contacto operativo propuesto: asignar un responsable en Compras y un referente en IT para sprints de 1 semana durante la implementación.