Saltar al contenido principal

Resumen

La sección BOM define la estructura de producto para tu Fábrica (Factory): de qué está hecho cada producto, qué componentes se requieren, en qué cantidades y bajo qué condiciones de variante. Las BOMs son la base para la planificación y (eventualmente) la programación: el optimizador las usa para determinar qué necesita producirse aguas arriba para cumplir la Demanda aguas abajo. ProDex lleva dos objetos en forma de BOM relacionados pero distintos:
  • BOMs estándar — recetas de producción planas usadas por la simulación y la planificación. Una Entidad (Entity) de salida, una lista de componentes de entrada con cantidades y una condición de variante opcional.
  • Plantillas (Templates) de Configuración — estructuras de producto configurables usadas por el Configurador (Configurator). Definen el espacio de opciones (qué sustituciones son válidas), no una receta plana.
Ambos viven en la sección BOM de la interfaz. Sirven a diferentes preguntas: las BOMs estándar responden “¿cómo hacemos esto?”; las Plantillas de Configuración responden “¿qué variantes son válidas para este producto configurable?”.

Cómo funcionan las BOMs

Una BOM enlaza una Entidad (un producto o material) con sus componentes: otras BOMs que deben producirse o consumirse para crear una unidad del padre. Esto forma un grafo acíclico dirigido (DAG) desde los productos terminados hasta las materias primas. Es un DAG, no un árbol, porque el mismo componente puede aparecer en muchos padres. Por eso también existe where-used (dónde se usa): dado un componente, encontrar cada padre que lo consume. ProDex clasifica automáticamente cada material basándose en su posición en el grafo de BOM:
  • SKU — tiene componentes Y no es consumida por ninguna otra BOM. Productos terminados vendibles. Los Pedidos (Orders) de Demanda referencian SKUs.
  • INTERMEDIATE — tiene componentes Y es consumida por al menos otra BOM. Producido internamente; fluye aguas abajo hacia los productos terminados.
  • RAW — no tiene componentes. Adquirido externamente. Una BOM sin componentes es RAW incluso si nada la consume actualmente.
No estableces las clasificaciones manualmente: se derivan automáticamente a medida que construyes el grafo.
La clasificación de material restringe las entradas de planificación. Los Pedidos de Demanda solo aceptan Entidades clasificadas como SKU. Los Pedidos de Suministro solo aceptan Entidades clasificadas como RAW. Si una Entidad no se clasifica como esperas, corrige el grafo de BOM en lugar de anular la clasificación.

Cómo crear una BOM estándar

  1. Navega a BOM en la barra lateral
  2. Haz clic en New BOM
  3. Selecciona la Entidad que produce esta BOM
  4. Dale un nombre y una descripción opcional
  5. Añade componentes: para cada componente, selecciona la BOM hija y especifica la cantidad requerida por unidad de salida
  6. Opcionalmente añade una condición de variante
  7. Haz clic en Save
Cada BOM tiene alcance de Fábrica y se comparte entre todos los Modelos (Models) y configuraciones de planificación dentro de esa Fábrica. El orden de creación importa. Construye primero las Entidades hoja (definiciones de Entidad), luego las BOMs para esas hojas (que se clasifican como RAW), después los ensamblajes que las consumen, trabajando capa por capa hacia los productos terminados. ProDex rechaza ciclos en la escritura: cada BOM debe apuntar solo a hijos que ya existen.

Referencia de esquema

Un registro de BOM lleva:
CampoNotas
entity_id (requerido)La Entidad que produce esta BOM
nameEtiqueta legible
descriptionOpcional
variantCondición de variante opcional (ver abajo). Vacío/faltante = receta por defecto
componentsArreglo de entradas {bom_id, quantity}

Condiciones de variante

Una sola Entidad puede tener múltiples variantes — por ejemplo, el mismo producto producido bajo diferentes configuraciones (tamaño, color, grado). Las condiciones de variante le dicen al planificador qué BOM aplica a qué línea de Demanda. Las condiciones de variante usan un esquema de predicados tipados, no el lenguaje de DSL/Expresión (Expression). Cada Entidad declara un espacio de configuración mediante sus atributos, y el campo variant de una BOM es una lista de condiciones sobre esos atributos, todas unidas con AND. Los cuatro tipos de condición:
  • boolean — el atributo es verdadero (o falso)
  • discrete_text — el atributo coincide con uno de una lista de valores de cadena permitidos
  • discrete_number — el atributo coincide con uno de una lista de valores numéricos permitidos
  • range — el atributo numérico cae dentro de los límites [min, max]
Una BOM sin variant es la receta por defecto para esa Entidad: coincide con cualquier cosa. Una BOM con un variant coincide con una línea de Demanda o Inventario solo cuando la variante de la línea es un subconjunto de la condición de la BOM. Así es como el planificador elige qué receta aplica a un pedido de “roble rojo de 12 pulgadas” cuando tienes BOMs separadas para rojo, roble y 12 pulgadas. La plataforma valida que ninguna par de BOMs para la misma Entidad lleve condiciones mutuamente solapadas: el solapamiento significa ambigüedad, y el optimizador no elige.

Plantillas de Configuración

Las Plantillas de Configuración son un tipo de objeto separado que vive junto a las BOMs estándar en esta sección. Definen el espacio de opciones para una familia de productos configurables — clases de opciones, opciones, anidamiento recursivo — y alimentan al Configurador, donde los usuarios (con asistencia del agente) recorren el árbol de opciones y resuelven a una lista concreta de partes.
Las Plantillas de Configuración no son BOMs. Una Plantilla no puede usarse en simulación o planificación; produce Configuraciones guardadas, que llevan la lista de partes resuelta para un Pedido específico. Si una funcionalidad que necesitas pertenece a la planificación de producción estándar, construye una BOM. Si estás modelando configure-to-order, construye una Plantilla. Consulta Configurador para el modelo mental completo.

Explosión de BOM

La explosión de BOM expande recursivamente una BOM padre al conjunto completo de materiales requeridos para producir una unidad. La salida es un listado de texto en formato de árbol indentado con cantidades acumulativas y anotaciones de profundidad: útil para entender estructuras de producto multinivel y verificar los datos de tu BOM antes de ejecutar un plan. La explosión es siempre a profundidad completa: no hay parámetro de límite de profundidad. La columna de cantidad acumulativa es el valor real: responde “¿cuántas unidades RAW a nivel hoja consume una SKU terminada?”, considerando cada multiplicador a lo largo del camino.

Where-used

Where-used es lo inverso de la explosión: dada una BOM, encuentra cada BOM que la consume (directa o indirectamente), con la cantidad consumida en cada nivel. Los ancestros son aguas abajo: fluyen hacia los productos terminados que dependen de este componente. Where-used es la herramienta correcta para análisis de impacto. Si el tiempo de entrega de un componente cambia, where-used te muestra cada producto terminado afectado y cuántas unidades del componente necesita cada uno. Puede ejecutarse de forma superficial (solo padres directos) o recursivamente (árbol completo aguas abajo).

BOMs y planificación

Una vez definidas tus BOMs, alimentan al módulo de Planificación. El metadata.json del Modelo de Planificación lleva un campo explícito boms que lista qué BOMs participan.
Las BOMs no listadas en el campo boms del Modelo de Planificación son invisibles para el optimizador, incluso si existen en la Fábrica. Una confusión común: “Agregué una BOM pero el optimizador dice que no puede hacer X.” Revisa primero la lista boms del Modelo.
El optimizador de planificación usa las BOMs listadas para:
  • Determinar qué materiales intermedios necesitan producirse para cumplir la Demanda de SKUs
  • Aplicar consumo de Recursos (Resources) en cada nivel vía resource_requirements.json
  • Emparejar cada línea de Demanda con la variante correcta de la BOM mediante coincidencia por subconjunto
  • Respetar la precedencia: la producción intermedia debe ocurrir antes que los SKUs que la consumen
Los cambios en las BOMs surten efecto en la siguiente ejecución de planificación; los resultados de planificación existentes no se recalculan retroactivamente.