Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés.
# Problemas y soluciones comunes
## Problemas de datos comunes
### El historial de demanda tiene formatos de fecha mixtos
Los sistemas de origen pueden exportar las fechas como DD/MM/YYYY MM/DD/YYYY, o YYYY-MM-DD, a veces, dentro del mismo archivo. Es posible que el sistema las analice de forma incorrecta y asigne los pedidos a meses incorrectos.
**Solución:** Estandariza los formatos de fecha en tu proceso de exportación. Si no puede controlar la fuente, añada la validación de fecha en el SQL de su flujo de datos.
### Cantidades negativas en el historial de pedidos
Las notas de crédito, las devoluciones o las anulaciones pueden aparecer como cantidades negativas. Estas pueden distorsionar los promedios de la demanda y confundir el modelo.
**Solución:** filtra solo las cantidades positivas o filtra por el estado del pedido (por ejemplo, solo Paid/Invoiced los pedidos).
### Los recuentos de registros no coinciden con el sistema de origen
+ La mayoría de las veces se debe a colisiones de claves compuestas: si dos registros comparten el mismo identificador único, uno sobrescribe al otro.
+ También puede ocurrir si los criterios de filtrado de la asignación de datos excluyen los registros que espera ver.
Proporciona un ejemplo específico de producto y sitio web y el número de registros esperado para que el equipo pueda detectar la discrepancia.
### En el sistema aparecen los pedidos que no existen en el ERP (o viceversa)
+ Los pedidos gestionados o retirados entre una publicación y otra del informe desaparecerán en la siguiente actualización, pero es posible que sigan apareciendo en las excepciones generadas a partir de los datos del día anterior.
+ Los pedidos recién creados no aparecerán hasta la próxima actualización de datos.
Este es el comportamiento esperado: las excepciones se actualizarán en el siguiente ciclo de evaluación cuando se carguen datos nuevos.
### Los archivos de entrada del plan incluyen productos de otras plantas o unidades de negocio
Si las exportaciones de su sistema de origen incluyen productos que están fuera del ámbito de su proyecto de previsión:
+ **El sistema filtrará automáticamente hasta el producto maestro.** Solo los productos presentes en el archivo maestro de productos se incluirán en la previsión. Sin embargo, si un gran porcentaje del archivo de entrada está fuera del alcance (por ejemplo, más del 50% de las filas), esto indica que es necesario restringir la exportación de origen.
+ **Comprueba la tasa de cobertura de tus productos con regularidad.** Después de cada carga de datos, comprueba qué porcentaje de productos de tus archivos de entradas de ventas y previsiones coincide con el producto maestro. Si la cobertura cae por debajo del 80%, investiga si el ámbito de exportación de origen ha cambiado o si es necesario actualizar el producto maestro.
+ **Out-of-scope los productos incluidos en los insumos del plan pueden provocar totales inflados.** Si sus archivos EDI o SIOP incluyen productos de otras plantas, la señal de previsión agregada será mayor de lo que debería ser. Asegúrese de que los archivos de entrada del plan estén filtrados con la misma gama de productos que el producto maestro antes de cargarlos.
## Problemas frecuentes de excepciones y recomendaciones
### El mismo producto y sitio aparecen varias veces en la lista de excepciones
Esto puede suceder cuando la regla subyacente genera una excepción independiente para cada fecha válida del horizonte de proyección.
Ponte en contacto con tu equipo de soporte para ajustar la regla y marcar solo la fecha de incumplimiento más temprana por producto y sitio.
### La recomendación no coincide con lo que veo en el gráfico
La recomendación la genera un agente de IA que analiza los datos disponibles en el momento en que se creó la excepción. Si los datos han cambiado desde entonces, la recomendación puede hacer referencia a pedidos o cantidades que ya no están actualizados.
+ Comprueba la fecha y hora de la excepción: si tiene más de un día de antigüedad, es posible que la recomendación esté obsoleta.
+ Si la recomendación es claramente errónea (por ejemplo, omite un pedido grande visible en el gráfico), envía tus comentarios con el visto bueno hacia abajo e informa de la excepción específica a tu equipo de soporte.
### La fecha de impacto o la fecha de caducidad no parecen correctas
+ La fecha de impacto muestra cuándo comienza el problema con el inventario (por ejemplo, cuando se empieza a agotar existencias o si el exceso supera el umbral).
+ La fecha de caducidad debe tener en cuenta el tiempo de espera para que tengas tiempo de actuar antes de que se materialice el problema. Si actuar antes es igual a la fecha de impacto, es posible que no se incorpore el plazo de entrega. Informe de ello a su equipo de soporte.
### Las recomendaciones hacen referencia a pedidos que no encuentro en el ERP
Las instantáneas del ERP cambian a diario. Es posible que un pedido al que se hacía referencia en la recomendación de ayer se haya gestionado, cancelado o reprogramado en la versión actual del ERP.
Se trata de una limitación de datos conocida. ERP-based Se pueden añadir datos históricos de consumo para proporcionar un mejor contexto.
## Problemas comunes de precisión
### Forecast es significativamente peor que una simple media móvil
Si su pronóstico de ASC es una pérdida frente a una media móvil de 6 meses en el WAPE agregado, compruebe estas causas comunes:
+ **Hay demasiados volume/inactive productos de bajo alcance.** Los productos con una demanda escasa e intermitente son difíciles de superar para cualquier modelo a un simple promedio. Utilice una regla de preprocesamiento para limitar la previsión a los productos con un historial de demanda significativo (por ejemplo, al menos 6 meses de demanda distinta de cero).
+ **Capacitación sobre antecedentes obsoletos o contaminados.** Si su historial de pedidos se remonta a muchos años, es posible que los patrones de demanda antiguos no reflejen la realidad actual. Considera la posibilidad de aplicar una regla de preprocesamiento para limitar el historial de formación a los últimos 3 o 5 años o para sustituir los períodos anómalos (por ejemplo, el COVID) por valores normalizados.
+ **La demanda se dispara debido a los pedidos únicos.** Un solo pedido grande al por mayor puede crear una falsa tendencia al alza en los datos de formación. Usa una regla de preprocesamiento para limitar los valores anómalos de la demanda mensual a un múltiplo de la media final (por ejemplo, 5 veces).
+ **Las reglas de consenso se aplicaron en la dirección equivocada.** El agente de LLM puede malinterpretar el lenguaje de las reglas. «Disminuir en un 27%" puede aplicarse como un aumento. Valide siempre los resultados consensuados con los valores de referencia comparando productos y meses específicos. Utiliza un lenguaje de multiplicación explícito («multiplica por 0,725») en lugar de un lenguaje direccional («reduce un 27,5%»).
### Over-forecasting sesgo (previsión sistemáticamente superior a la real)
Un sesgo positivo significa que está pidiendo más de lo necesario en todo el catálogo. Causas habituales:
+ **El modelo se basa en un período de crecimiento.** Si los últimos años mostraron un crecimiento que no continúa, el modelo extrapola una tendencia que ya no existe.
+ **Las reglas de consenso están acumulando ajustes al alza.** La existencia de varias reglas, cada una de las cuales aumenta la previsión (sesgo de desabastecimiento, aumento de la tendencia, alza estacional), pueden agravarse. Revisa qué reglas están activas y comprueba si todas se aplican a los mismos productos.
+ **Deleted/discontinued productos que aún están dentro del ámbito de aplicación.** Los productos con una demanda inferior y que aún se están pronosticando mostrarán una sobreprevisión sistemática.
### Under-forecasting sesgo (previsión sistemáticamente inferior a la real)
Un sesgo negativo significa que se prevé constantemente una demanda inferior a la real, lo que se traduce en posibles desabastecimientos y en un aumento de los costes. Causas habituales:
+ **No se incorporan señales de previsión externas.** Si has cargado las entradas del plan (p. ej., previsiones de clientes basadas en el EDI o planes de producción del SIOP) pero tus reglas de consenso no las aplican, la previsión se basa de forma predeterminada en la base estadística, que puede que no capte las señales de demanda que ven tus planificadores. Verifique que las reglas de consenso estén modificando realmente la salida comparando la ConsensusForecast exportación con la exportación Forecast (línea base). Si son idénticas, las reglas no funcionan.
+ **Combinaciones dispersas de producto y sitio que reducen el agregado.** Si realiza una previsión con una granularidad entre el producto y el sitio, pero muchas combinaciones tienen una demanda nula o casi nula, el modelo produce pronósticos pequeños distintos de cero para las combinaciones inactivas. No suman mucho de forma individual, sino que, en conjunto, arrastran la previsión total por debajo de los valores reales. Usa una regla de preprocesamiento para excluir las combinaciones con un historial de demanda insuficiente o utiliza la opción condicional de rellenar cero en las entradas de tu plan para indicar explícitamente que «no se espera demanda» en el caso de las combinaciones inactivas.
+ **El modelo no ha captado una tendencia de crecimiento reciente.** Los modelos estadísticos ponderan los datos históricos. Si su empresa ha crecido significativamente en los últimos meses, pero el modelo tiene años de historia con volúmenes más bajos, estará a la zaga de la tendencia. Esto suele mejorar con el tiempo a medida que el modelo acumula datos más recientes. Mientras tanto, considere una regla de consenso que utilice un promedio inferior de los datos reales recientes como límite mínimo para las semanas de pronóstico más adversas.
+ **Year-over-year desajuste de estacionalidad.** Si el patrón de demanda de este año difiere del de años anteriores (por ejemplo, aumento estacional más temprano, lanzamiento de nuevos productos), es posible que el modelo no prevea lo suficiente durante el período divergente. Compruebe si el subsesgo se concentra en semanas o meses específicos que difieren del patrón del año anterior.
### La precisión del pronóstico se degrada significativamente en horizontes más largos
Es normal que la precisión empeore a medida que aumenta el horizonte de previsión; la semana 1 siempre es más precisa que la semana 8. Sin embargo, si la degradación es más pronunciada de lo esperado:
+ **Las señales externas solo ayudan a corto plazo.** Si tienes reglas de consenso que incorporan las previsiones de los clientes (EDI) para las primeras semanas, la precisión será notablemente mejor a corto plazo y disminuirá cuando las normas dejen de aplicarse. Esto es lo que cabe esperar: considere la posibilidad de ampliar las normas para que abarquen más semanas con un enfoque combinado (por ejemplo, una 50/50 combinación de señal externa y línea de base para semanas a medio plazo).
+ **La base de referencia vuelve a ser una media a largo plazo en horizontes más largos.** Los modelos estadísticos se vuelven menos seguros en horizontes más largos y tienden hacia la media histórica. Si la demanda reciente está por encima de la media histórica, las semanas posteriores parecerán estar sesgadas por debajo de la media histórica. Se trata de un comportamiento del modelo, no de un problema de configuración.
+ **La volatilidad de la demanda hace que los horizontes más largos sean intrínsecamente más difíciles.** Si su demanda tiene una alta variabilidad de una semana a otra (coeficiente de variación superior a 0,5), incluso un modelo perfecto mostrará un error elevado en horizontes más largos. Céntrese en la evaluación de la precisión en las primeras 3 o 4 semanas, que es el período de planificación práctico para la mayoría de las operaciones.
### La previsión externa (EDI/customer previsión) no mejora la precisión cuando se utiliza en las reglas de consenso
Si ha añadido reglas de consenso para incorporar las previsiones externas, pero la precisión no ha mejorado:
+ **Es posible que la señal externa no cubra suficientes productos.** Por lo general, el EDI o las previsiones de clientes solo cubren un subconjunto del catálogo de productos (normalmente entre el 30 y el 50%). Los productos sin señal externa siguen utilizando la línea de base. Comprueba tu tasa de cobertura: si está por debajo del 50%, el impacto en la precisión agregada será limitado.
+ **Es posible que la señal externa no sea lo suficientemente precisa como para ayudar.** Mida la precisión de la previsión externa de forma independiente antes de utilizarla en las reglas. Si su WAPE es peor que el valor de referencia, incorporarlo perjudicará en lugar de ayudar. Considere limitar la regla a sitios o productos específicos en los que se demuestre que la señal externa es mejor (por ejemplo, un WAPE ponderado por volumen inferior al 50%).
+ **La señal externa no muestra ceros.** Muchos sistemas EDI solo envían registros de productos con pedidos activos: omiten los productos con demanda cero en lugar de informar explícitamente de cero. Si tu regla de consenso dice «cuando el EDI sea igual a 0, establece la previsión en 0», nunca se activará porque no hay registros cero. Es necesario generar registros cero sintéticos durante el preprocesamiento para las combinaciones de producto y sitio que no tengan señal externa ni un historial de ventas reciente.
+ **La precisión de la señal externa varía según el horizonte.** Las previsiones de los clientes suelen ser más precisas para la semana siguiente (básicamente, pedidos confirmados) y se degradan rápidamente. Una regla que utilice la señal externa directamente durante todas las semanas puede afectar a la precisión en horizontes más largos. Considera un enfoque escalonado: sustituirlo directamente para las semanas 1 a 3, combinado para las semanas 4 a 6, y de referencia solo para las semanas 7 o más.
### Las reglas de planificación no entran en vigor
Si una regla de consenso no parece cambiar la previsión:
+ **Es posible que la regla haya sido anulada por una regla de mayor prioridad.** Las reglas se aplican en orden de prioridad. Una regla posterior puede deshacer una anterior. Compruebe el orden de las reglas.
+ **Es posible que la condición de la regla no coincida con ningún producto.** Si la regla hace referencia a un atributo del producto (por ejemplo, product\_group\_id) que no está en los metadatos del artículo, no coincidirá silenciosamente con ningún atributo.
+ **Se malinterpretó el lenguaje de la regla.** El agente LLM genera código a partir del lenguaje natural. La redacción ambigua puede producir resultados inesperados. Sea lo más específico y literal posible. Usa nombres de campo exactos, multiplicadores explícitos y condiciones claras.
### El resultado del plan de consenso es idéntico al pronóstico de referencia
Si la ConsensusForecast exportación tiene los mismos valores que la exportación Forecast (línea base), las reglas de consenso no se ejecutaron. Causas habituales:
+ **Las dimensiones no coinciden en la unión.** El motor de consenso une las entradas del plan con la base de referencia en las columnas de dimensiones (identificador del producto, identificador del sitio, fecha). Si los nombres de las columnas difieren entre la base de referencia y las entradas del plan (por ejemplo, la línea base usa item\_id mientras que EDI usa product\_id), la unión no produce coincidencias y todas las reglas se ajustan a la línea base predeterminada. Compruebe que el mapeo de dimensiones de su configuración de flujo de datos mapea correctamente los dos esquemas.
+ **El formato de fecha no coincide.** La línea base puede almacenar las fechas como 2026-03-02, mientras que las entradas del plan las almacenan como 2026-03-02. T00:00:00.000Z Si la combinación requiere una coincidencia exacta, las fechas en las que se tenga en cuenta la zona horaria y en las que no se tenga en cuenta la zona horaria no coincidirán. Comprueba que las columnas de fecha se conviertan al mismo formato antes de unirlas.
+ **Las entradas del plan no están cargadas.** Compruebe que los archivos de entrada del plan (EDI, SIOP, etc.) se hayan ingresado correctamente. Compruebe los recuentos de registros del sistema: si no muestran filas para una entrada del plan, es posible que el archivo no se haya podido cargar.
+ **El forecast\_id de consenso coincide con el forecast\_id de referencia.** Si ambas exportaciones comparten el mismo forecast\_id, el motor de consenso produjo una copia directa de la línea base sin procesarla. Esto indica un problema a nivel del sistema: ponte en contacto con tu equipo de soporte con el forecast\_id y el demand\_plan\_run\_id.
### Las reglas de consenso se aplican a productos o sitios incorrectos
Si una regla que solo debería aplicarse a sitios o categorías de productos específicos afecta a todo el catálogo:
+ **Es posible que la condición del site/product filtro haga referencia a una columna incorrecta.** Si la regla dice «aplicar a los sitios de [lista]», pero el código generado comprueba una columna que no existe o tiene valores diferentes, es posible que el filtro pase silenciosamente todas las filas. Para verificarlo, selecciona algunos productos específicos que NO deberían verse afectados por la regla.
+ **El orden de prioridad de la regla puede estar invertido.** Las reglas se aplican como una cadena en la que las reglas posteriores anulan las anteriores. Si se aplica una regla general (por ejemplo, «usar la línea de base para todo») después de una regla específica (por ejemplo, «usar el EDI para estos 50 sitios»), la regla general anulará la regla específica. Asegúrese de que las descripciones de las reglas indiquen claramente el orden de prioridad.
### Los valores de pronóstico son fraccionarios (por ejemplo, 2.500,37 unidades)
Los modelos estadísticos producen valores continuos, no enteros. Si su empresa vende unidades enteras, paquetes de cajas o cantidades mínimas de pedido:
+ **Agrega una regla de redondeo como último paso de consenso.** Aplicando una regla simple de «redondear al entero más cercano» después de todas las demás reglas de consenso, se eliminarán los valores fraccionarios. Los valores por debajo de 0,5 se redondearán a cero, lo que resulta adecuado para combinaciones de muy baja demanda.
+ **Considere la posibilidad de redondear a cantidades operativas.** Si tus productos se envían en tamaños de paquete estándar (por ejemplo, cajas de 12 o palés de 48), redondear al tamaño de paquete válido más cercano puede mejorar tanto la usabilidad como la precisión de la previsión. Para ello, es necesario incluir los datos sobre el tamaño del paquete en tu producto maestro. Comparta sus datos de MOQ o tamaño del paquete con su equipo de soporte para explorar esta opción.
### La cobertura de productos disminuye significativamente después de agregar reglas de preprocesamiento
Las reglas de preprocesamiento que filtran los datos de formación (por ejemplo, «solo pronosticar productos con al menos 8 semanas de demanda distinta de cero») pueden reducir drásticamente la cantidad de productos de la previsión si los datos son escasos a nivel de producto o sitio:
+ **Compruebe la granularidad.** Un producto puede tener 52 semanas de demanda a nivel de producto, pero solo 3 semanas en cualquier combinación individual de producto y sitio. Si se aplica un umbral mínimo de historial a nivel de producto y sitio, se excluirá la mayoría de las combinaciones. En su lugar, considere aplicar el umbral a nivel de producto o reducirlo significativamente.
+ **Realice una prueba antes de la implementación.** Antes de activar una regla de preprocesamiento, cuente cuántas combinaciones de producto y sitio pasan el filtro en comparación con el total actual. Si se excluye más del 20%, es probable que la regla sea demasiado agresiva. Comience con un umbral indulgente y ajústelo gradualmente.