> ## Documentation Index
> Fetch the complete documentation index at: https://docs.prodexlabs.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Restricciones y Objetivos Personalizados

> Extiende un modelo de planificación con reglas y metas que el optimizador integrado no cubre: créalas con Dexter, luego revísalas y ajústalas en el panel de Restricciones Personalizadas.

Beta (ProDex configura esta función por organización. ¿No la ves? Pide a tu representante de ProDex que la active para tu organización.)

## Descripción general

El optimizador ya impone la física de la producción sin que configures nada. Cada escenario — el nombre que la interfaz da a una [ejecución de planificación](https://docs.prodexlabs.com/es/product/planning-runs.md) — respeta el **balance de materiales** (el inventario trasladado entre intervalos, consumido y repuesto a medida que se fabrican las cosas), el **consumo de la lista de materiales y de recursos** (cada unidad producida reduce sus componentes y los recursos que requiere su ruta), la **capacidad de recursos** como un tope estricto, el **plazo de entrega de producción** (la salida llega algunos intervalos después de empezar) y las **órdenes de plazo estricto**. Por encima de eso optimiza un objetivo fijo: el equilibrio entre cumplir la demanda a tiempo y mantener el inventario en su objetivo — los [dos objetivos integrados](https://docs.prodexlabs.com/es/product/planning-models.md#los-dos-objetivos).

**Las restricciones personalizadas y los términos objetivo personalizados son el punto de extensión para todo lo que esos elementos integrados no expresan.** Te permiten agregar reglas como tamaños de lote mínimos, un tope de cuántos productos distintos corren en un intervalo, duraciones mínimas de corrida o exclusiones mutuas — y agregar metas como "mantener la producción estable" o "penalizar la variedad" que se ponderan junto con la demanda y el inventario. Ambas se crean en el [modelo de planificación](https://docs.prodexlabs.com/es/product/planning-models.md#restricciones-personalizadas) y se aplican a todos los escenarios contra él.

> [!NOTE]
>
> Esto es funcionalidad experta. La mayoría de los modelos nunca la necesitan — la estructura integrada y el equilibrio demanda/inventario cubren la gran mayoría de los problemas de planificación. Recurre a reglas personalizadas solo cuando una restricción operativa real no tiene lugar en el modelo estándar.

## Creación con Dexter

Las nuevas restricciones personalizadas se crean a través de Dexter. **Describe la regla en lenguaje simple a [Dexter](https://docs.prodexlabs.com/es/product/dexter/chat-and-tasks.md)** — "no fabriques ningún SKU en un lote menor a 500 a menos que no estemos fabricando nada de él" — y Dexter la expresa como una restricción precisa sobre el modelo, y luego la valida mediante el mismo compilador del optimizador que corre al momento de resolver. Si la regla no se puede expresar o no compila, lo sabes de inmediato en lugar de en la siguiente resolución.

Debajo, cada regla es una entrada que el compilador entiende: una sola restricción, o un solo término objetivo ponderado. Tú describes la intención; Dexter se encarga de la codificación y de los detalles numéricos delicados. El resto de esta página es un recorrido por lo que se puede expresar, para que sepas qué puedes pedir.

## El panel de Restricciones Personalizadas

Abre la sección **Restricciones Personalizadas** del modelo para ver lo que lleva, en dos listas: **Restricciones** y **Términos Objetivo**. Cada restricción muestra su tipo de restricción; cada término objetivo muestra si se minimiza o se maximiza y su peso. Cada fila tiene dos pestañas:

* **Descripción de IA** — un resumen en lenguaje simple de la regla, escrito por IA a partir de su definición.
* **Definición** — la regla como un formulario editable: sus variables, expresiones, límites y penalización. Cambia un valor y **Guarda**, o **Cancela** para descartar el cambio.

Para cambiar una regla con palabras en lugar de eso, elige **Editar con agente**, describe el cambio y **Enviar al agente**. Dexter actualiza la regla en el modelo. El ícono de papelera elimina una regla después de que confirmes. Si la validación del escenario seleccionado encuentra un problema con una regla, el problema aparece en la fila de esa regla.

**Añadir objetivo** en la lista de **Términos Objetivo** ofrece dos objetivos comunes:

| Objetivo | Qué agrega |
| - | - |
| **Adherencia de inventario** | Reduce las desviaciones de los objetivos móviles de inventario |
| **Cumplimiento a tiempo** | Reduce las penalizaciones por retraso en los pedidos de demanda |

Cada uno se agrega como un término minimizado con peso 1, que puedes ajustar después en su pestaña **Definición**. Agregar uno le da peso adicional a ese objetivo integrado, por encima del [Comportamiento del solucionador](https://docs.prodexlabs.com/es/product/planning-models.md#los-dos-objetivos) del modelo.

## Qué puedes referenciar

Una regla personalizada se construye a partir de las propias **variables de decisión** del optimizador — las cantidades que el solucionador está eligiendo. Estas son las únicas variables que una regla puede mencionar, y cada una se indexa como el solucionador la rastrea. Los nombres de abajo son los que muestra la pestaña **Definición**.

| Variable | Qué representa | Indexada por |
| - | - | - |
| `produced` | Cuántas unidades de un material producible fabricar, iniciadas en un intervalo | intervalo, material |
| `order_interval` | Si una orden de demanda se cumple en un intervalo dado (sí / no) | orden, intervalo |
| `order_demand` | Cantidad total de SKU demandada en un intervalo (derivada de las asignaciones de órdenes) | intervalo, SKU |
| `start_of_interval` | El inventario de un material al inicio de un intervalo | intervalo, material |
| `end_of_interval` | El inventario de un material al final de un intervalo | intervalo, material |
| `inventory_material_loss` | Qué tan lejos está el inventario de un material de su objetivo, por material | intervalo, material |
| `inventory_loss` | Pérdida de inventario agregada de todos los materiales en un intervalo | intervalo |
| `total_inventory_loss` | Pérdida de inventario de todo el horizonte (un solo número) | — |
| `total_lateness_penalty` | Penalización por retraso de demanda de todo el horizonte (un solo número) | — |

Las dimensiones de índice significan:

* **intervalo** — un bloque de tiempo en el horizonte, numerado desde `0` (el primer intervalo).
* **material** — un material referenciado por el nombre de su entidad. Si la entidad tiene varias variantes, la regla fija la que quiere decir con una condición de variante.
* **orden** — una orden de demanda, referenciada por su nombre.
* **SKU** — una entidad de producto terminado.

> [!NOTE]
>
> **`produced` solo acepta materiales producibles** — intermedios y SKU. Las materias primas no las produce el plan (llegan como [suministro](https://docs.prodexlabs.com/es/product/demand-and-supply.md#órdenes-de-suministro)), así que una regla no puede restringir la "producción" de una materia prima. Las variables de inventario (`start_of_interval`, `end_of_interval`) aceptan **cualquier** material, incluidas las materias primas.

## Bloques de construcción

Las reglas se ensamblan a partir de un conjunto pequeño y componible de piezas. Dexter las ensambla por ti, y la pestaña **Definición** las muestra como campos de formulario; de cualquier forma, definen el límite de lo que una regla puede decir.

**Aritmética.** Suma, resta y niega cantidades; multiplica por una constante (o por una variable sí/no); divide entre una constante. Dos variables de decisión no se pueden multiplicar entre sí — el modelo se mantiene lineal para que el solucionador pueda probar la optimalidad.

**Las agregaciones** acumulan una cantidad sobre un conjunto de intervalos, materiales, órdenes, SKU o recursos, con un filtro opcional para incluir solo algunos de ellos:

| Agregación | Qué te da |
| - | - |
| **suma** | El total de una cantidad sobre el conjunto — p. ej. todo lo producido de un SKU a lo largo del horizonte |
| **contar** | Cuántas condiciones del conjunto son verdaderas — p. ej. cuántos intervalos producen un SKU en absoluto |
| **mín** / **máx** | El valor más pequeño o más grande en todo el conjunto |

**Las funciones de forma** convierten una cantidad cruda en la forma que realmente le importa a una regla o penalización:

| Función | Efecto |
| - | - |
| **abs** | Distancia a cero, ignorando el signo |
| **parte positiva** (ReLU) | La cantidad por encima de cero, y nada por debajo — ideal para "solo cuenta el exceso" |
| **zona muerta** | Cero hasta un umbral, y luego empieza a morder — perdona desviaciones pequeñas |
| **limitar** (clamp) | Mantener un valor dentro de un piso y un techo |
| **lineal a trozos** | Una curva personalizada a través de puntos que especificas — costo o recompensa no lineal que sigue siendo amigable para el solucionador |
| **si / entonces / si no** | Elegir una de dos cantidades según una condición |
| **búsqueda en tabla** | Leer un valor de una tabla fija por posición |

**La lógica** compone las condiciones que prueba una regla:

* **Comparaciones** — menor que, como máximo, mayor que, al menos, igual, distinto.
* **y / o / no**, **implica** ("si A entonces B"), y **sii** ("A exactamente cuando B").
* **al menos / como máximo / exactamente *k*** — cuántas condiciones de una lista pueden (o deben) cumplirse a la vez.
* **para todo / existe** — una condición debe cumplirse en todos los miembros de un conjunto, o en al menos uno.

## Tipos de restricción

Una regla toma una de estas formas:

| Tipo | Qué hace |
| - | - |
| **Simple** | Una relación que debe cumplirse — `producido del SKU X en el intervalo 0 ≤ 5`. |
| **Para todos** | La misma relación aplicada a lo largo de un conjunto de índices — el tope de arriba, pero para *cada* intervalo. |
| **Condicional** | Si se cumple una condición, entonces debe cumplirse una relación — "si esta orden se cumple en el intervalo 2, produce al menos 100 de su SKU para entonces." |
| **Flexible** | Una relación que *debería* cumplirse; se permite una infracción pero agrega una penalización al objetivo en lugar de prohibir el plan. |
| **Todos distintos** | Un conjunto de cantidades debe tomar todos valores distintos. |
| **Cardinalidad** | Como máximo / al menos / exactamente *k* de un conjunto de relaciones pueden cumplirse. |

### Estricta vs. flexible

Una restricción **estricta** es inviolable: el solucionador no devolverá un plan que la incumpla, y si ningún plan puede satisfacerla el escenario resulta [no factible](https://docs.prodexlabs.com/es/product/planning-runs.md#cuándo-un-escenario-no-es-factible). Usa restricciones estrictas para límites físicos o contractuales genuinos.

Una restricción **flexible** es una preferencia con un precio. Al plan *se le permite* incumplirla, pero cada infracción agrega una penalización al objetivo, así que el optimizador evita incumplirla a menos que hacerlo compre lo suficiente en otro lado. La penalización viene en dos estilos:

* **Por unidad** — el costo escala con *cuánto* se incumple la regla (cada unidad por encima de un tope cuesta la penalización).
* **Fija** — un costo plano en el momento en que la regla se incumple, sin importar en qué medida.

Suavizar una regla es la solución habitual cuando una restricción estricta vuelve no factibles los escenarios pero la preferencia subyacente es real — mantienes la presión sin el precipicio.

## Términos Objetivo Personalizados

Más allá de las restricciones, puedes agregar **términos ponderados al objetivo mismo**. Un término es una expresión más un peso y una dirección (minimizar o maximizar); se incorpora junto a los dos términos integrados (retraso de demanda y pérdida de inventario), así que el optimizador equilibra tu meta contra las estándar de forma automática.

Así es como expresas metas que las predeterminadas no llevan — minimizar un indicador de costo, premiar una salida más suave, o penalizar algo ante lo que las integradas son indiferentes. El peso fija qué tan fuerte habla el término en relación con la demanda y el inventario; un peso pequeño empuja levemente el plan, uno grande lo domina.

> [!TIP]
>
> ¿Restricción o término objetivo? Si la regla es una línea que el plan no debe cruzar, hazla una **restricción**. Si es una preferencia hacia la que quieres que el plan se incline pero no a cualquier costo, hazla una **restricción flexible** o un **término objetivo** — esos le permiten al optimizador sopesarla en lugar de fallar.

## Ejemplos resueltos

Tres reglas que muestran el rango, cada una apoyada en las variables de arriba. Pedirías esto en lenguaje simple; la descripción de la forma de cada regla muestra lo que Dexter construye.

### Tamaño de lote mínimo

> "No produzcas ningún SKU en una cantidad por debajo de su tamaño de lote mínimo — pero cero está bien."

Para cada intervalo, una regla dice `producido del SKU = 0` **o** `producido del SKU ≥ 500`. Es un **para todos** sobre los intervalos que envuelve un **o** de dos comparaciones sobre `produced`, lo cual prohíbe el término medio incómodo ("un puñado de unidades") mientras sigue permitiendo que el plan omita el SKU por completo. Hazla una regla **flexible, por unidad** en su lugar y los lotes por debajo del mínimo se vuelven simplemente caros en lugar de imposibles.

### Limitar productos distintos por intervalo

> "Nunca corras más de tres productos distintos en un solo intervalo."

La producción se planifica por material por intervalo, así que esto cuenta la variedad dentro de un bloque de tiempo. Para cada intervalo, una regla dice `contar de materiales producibles con produced ≥ 1  ≤  3` — una agregación de **contar** sobre materiales producibles, comparada contra 3, aplicada **para todos** los intervalos. Limita los cambios de configuración al acotar cuántas cosas están en curso a la vez.

### Premiar corridas más largas (un término objetivo)

> "En igualdad de condiciones, prefiere planes que corran menos productos distintos por intervalo."

El mismo conteo de productos distintos, sumado a lo largo de todo el horizonte, se convierte en un término objetivo de **minimizar** con un **peso pequeño**. No prohíbe la variedad como lo hace el tope — inclina suavemente al optimizador hacia consolidar la producción, y cede cuando cumplir una fecha de vencimiento o un objetivo de inventario vale el cambio de configuración adicional.

## Para tener en cuenta

* **Cada regla la valida el compilador del optimizador.** Una regla que Dexter no puede expresar se rechaza cuando la crea. Una edición que guardas en la pestaña **Definición** se comprueba cuando el escenario se valida, y cualquier problema aparece en la fila de la regla. Una regla que compila pero entra en conflicto con el plan sale a la luz cuando corre el optimizador. Consulta [validar las entradas](https://docs.prodexlabs.com/es/product/planning-runs.md#validar-las-entradas).
* **Un conjunto demasiado ajustado puede volver no factible un escenario.** Un piso de producción mínima apilado contra un tope de salida máxima puede excluir juntos todos los planes posibles; el escenario entonces resulta no factible sin solución. Relaja la regla que está limitando, o suavízala. La guía completa de recuperación está en [cuándo un escenario no es factible](https://docs.prodexlabs.com/es/product/planning-runs.md#cuándo-un-escenario-no-es-factible).
* **Cambia una regla a la vez.** Porque las reglas personalizadas interactúan entre sí y con la estructura integrada, agrégalas o ajústalas de forma incremental y vuelve a ejecutar, para que puedas ver cuál movió el plan — o lo rompió.
* **Dexter maneja las sutilezas numéricas.** Algunas codificaciones solo son sólidas en cantidades enteras como `produced` (las pruebas de igualdad exacta y desigualdad no aplican de forma limpia a los niveles de inventario continuos, que se comparan con rangos en su lugar). Tú describes la intención en lenguaje simple; Dexter elige una codificación que el solucionador pueda manejar.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.