Punto de pedido y stock de seguridad: cómo se suman

Respuesta directa: dos términos con funciones distintas

El punto de pedido puede leerse como un umbral compuesto: por un lado, la demanda que se espera cubrir mientras llega la reposición; por otro, el stock de seguridad que se añade como buffer. En la notación de la Lecture 11 de Logistics Systems del MIT, la suma aparece como s = xL + kσL: xL representa la previsión durante el plazo y kσL el término de seguridad.

La diapositiva trata ambos como partes diferentes del mismo nivel. MIT OCW, Lecture 11, p. 9

La distinción parece sencilla, pero se pierde cuando una hoja o una pantalla muestra un número sin explicar qué suma ya contiene. Si el forecast de consumo durante el plazo se toma como umbral final, puede faltar el buffer. Si el valor mostrado ya incorpora ese buffer y alguien vuelve a añadirlo, la misma cantidad se cuenta dos veces. Son errores aritméticos de interpretación del dato, no una evaluación de una política de inventario concreta.

La pregunta útil, por tanto, no es solo «¿cuánto vale el punto de pedido?». También hay que saber qué parte del pronóstico cubre el plazo, cuál es la unidad de cada cantidad y si el resultado ya incluye el buffer. La página se concentra en esa relación; no explica cómo estimar el stock de seguridad, cómo calcular la variabilidad de la demanda ni cómo escoger el momento real de compra.

Cuando el forecast llega por periodos

En la práctica, una previsión puede estar expresada por semana o por mes, mientras que el plazo de reposición se mide en días. Si el horizonte termina justo al cierre de un periodo, la suma es directa: se incluyen los periodos cubiertos. La duda aparece cuando el plazo de 40 días empieza al comienzo de un bucket de 30 días. En ese caso, cubre un bucket entero y 10 días del siguiente.

Contar completo el segundo bucket incluiría 60 días de demanda en un horizonte que dura 40. Ignorarlo por completo contaría solo 30 días. Una fracción prorrateada puede representar los 10 días restantes si el periodo, la previsión y la unidad están definidos de forma compatible. Esa es una interpretación temporal del ejemplo documentado más adelante, no una regla general sobre cómo deben almacenarse o transformarse todos los pronósticos.

Antes de hacer una operación, conviene escribir la línea temporal. Por ejemplo: día 0, inicio del horizonte; día 30, fin del primer bucket; día 40, llegada supuesta; los días 30 a 40 ocupan 10 de los 30 días del segundo bucket. Esa representación deja a la vista qué fracción entra. Si la llegada estimada cae en una fecha distinta o los buckets no tienen igual duración, cambian las fracciones; no basta con reutilizar el 10/30 de otro caso.

El prorrateo presupone cómo se reparte la demanda

Multiplicar el valor mensual por 10/30 es una manera de asignar una parte del total a diez días. La operación no demuestra que el consumo real vaya a ser uniforme durante el mes. Si el bucket representa 120 unidades para 30 días, el cálculo lineal atribuye 40 unidades a cada tramo de diez días porque divide el total en tres partes iguales; eso es una suposición de reparto, no una observación diaria.

La diferencia puede importar cuando el forecast ya separa días o semanas, cuando una parada planificada concentra demanda, o cuando el periodo no tiene 30 días. En esos casos, reemplazar una serie detallada por una fracción mensual puede perder información que el dato original sí contenía. La pregunta editorial que plantea el ejemplo es más modesta: si solo se dispone de un total de bucket y se reproduce la convención ilustrada, qué fracción del bucket coincide con el horizonte.

Para decidir qué granularidad corresponde a un artículo concreto hace falta conocer la fuente y la construcción del forecast, algo que las dos fuentes de esta página no especifican.

También debe coincidir la unidad del forecast con la del umbral. Si una serie muestra 90 unidades por mes, pero el umbral está expresado en cajas, primero haría falta una conversión comprobada. Si el periodo se define como mes natural variable y no como 30 días, el denominador puede no ser 30. Esta página no convierte unidades ni propone una regla de calendario para un sistema; muestra por qué esos datos deben estar claros antes de interpretar la suma.

El ejemplo SAP: un mes completo y una parte del siguiente

SAP Help Portal presenta un ejemplo de cálculo del nivel de reposición para S/4HANA On-Premise, Sourcing and Procurement, versión 2025 FPS01, identificada como febrero de 2026. El pasaje consultado define el nivel como la suma del stock de seguridad y el forecast de requisitos que cae dentro del plazo de reposición. En la ilustración, la demanda se pronostica mensualmente y un mes se toma como 30 días en aprovisionamiento externo. SAP Help Portal, “Reorder Level Calculation”, versión 2025 FPS01

El cálculo enseña dos decisiones de lectura. Primero se determina qué parte de cada periodo cabe en los 40 días. Después se añade el stock de seguridad de 100 que la misma ilustración identifica. En esa expresión SAP conserva el buffer completo; no lo multiplica por 30/30 ni por 10/30. No se debe convertir esta observación de un ejemplo en una regla para otro ERP, producto, tipo de aprovisionamiento o configuración.

La nota de los 30 días es importante porque podría confundirse con una constante natural. El pasaje la vincula al caso de aprovisionamiento externo descrito en esa versión del producto. Si un lector trabaja con otro calendario, un plazo de fabricación, un bucket de semanas o una implementación distinta, necesita confirmar la definición local antes de trasladar la operación. La fuente consultada aporta un ejemplo concreto, no una especificación completa de todos los sistemas SAP.

Hay una limitación adicional de evidencia: el texto de SAP disponible aquí se conservó como un extracto seleccionado del resultado oficial de búsqueda. La página directa devolvió el shell de la aplicación, no el contenido completo. Por eso solo se atribuyen al material seleccionado la definición y los valores que aparecen en el extracto; no se infieren campos, parametrizaciones, fórmulas adicionales ni comportamiento de otras versiones.

Un ejercicio propio para detectar el bucket mal contado

Ahora usemos cifras distintas, creadas solo para explicar la aritmética. Imaginemos dos buckets mensuales de forecast: 90 unidades para los primeros 30 días y 120 para los 30 días siguientes. Supongamos un plazo ilustrativo de 40 días y un buffer ya establecido de 25 unidades. Todos los números se consideran unidades comparables. No describen un artículo ni un almacén real, y la página no calcula si el buffer de 25 es adecuado.

La previsión que cae dentro del horizonte es 90 unidades del primer bucket más una tercera parte del segundo: 90 + (10/30 × 120) = 130. Al añadir el buffer separado, el umbral ilustrativo queda en 130 + 25 = 155 unidades.

La operación está condicionada a que 120 represente la demanda de un bucket de 30 días y a que el periodo parcial se pueda prorratear linealmente para este ejercicio. Cálculo propio; esquema de términos: MIT OCW, Lecture 11, p. 9.

Ejemplo temporal comparado con SAP Help Portal, “Reorder Level Calculation”, 2025 FPS01 (extracto seleccionado).

El contraste ayuda a encontrar tres errores diferentes sin volver a definir cada concepto:

Los resultados no son alternativas recomendadas. Sirven para identificar qué componente se incorporó en una suma concreta. En una hoja real, no basta con que una celda se llame «punto de pedido» o «nivel de reposición»: habría que confirmar si contiene el forecast del plazo, un margen ya incluido o el total. La etiqueta de la columna ayuda, pero la definición del campo es la evidencia que permite interpretarlo.

El error del bucket completo y el del buffer repetido tienen causas distintas. El primero cambia el horizonte de demanda: utiliza más días de previsión de los que se habían declarado. El segundo mantiene el horizonte, pero duplica un componente. Separar el diagnóstico evita corregir una cifra modificando el dato equivocado.

Si el campo representa solo el componente de forecast, añadir SS puede ser parte de la suma explicada; si representa el total, esa misma operación deja de ser válida para esa celda.

Qué conviene comprobar en un campo ya existente

La página no prescribe un procedimiento de control, pero sí permite ordenar las preguntas antes de interpretar una cifra. Primero: ¿el campo es una previsión de demanda durante el plazo, un buffer, o el umbral resultante? Segundo: ¿qué unidad usa? Tercero: ¿qué periodo temporal usa el forecast y cómo se transforma el periodo parcial? Cuarto: ¿el valor mostrado incorpora ya el stock de seguridad?

Estas preguntas separan los dos sumandos sin dar por supuesto cómo se comporta un sistema particular. MIT OCW, Lecture 11, p. 9.

Un ejemplo de lectura ayuda a ver por qué importa. Si el reporte muestra 130 unidades y la definición local dice que es solo la cobertura pronosticada para el horizonte, compararlo con 155 del ejemplo propio no significa que el reporte esté necesariamente mal: el 25 se habría añadido en otro lugar o podría no formar parte de ese campo.

En cambio, si la definición local dice que 130 ya es el umbral completo e incluye un buffer de 25, la suma no coincide con esa definición. La diferencia describe una discrepancia entre el nombre o uso esperado y el contenido documentado; no demuestra, por sí sola, qué valor debería cargar una instalación.

Los símbolos también tienen que leerse según su fuente. En MIT, s es el umbral mostrado, xL la previsión durante el plazo y kσL el término de seguridad de la lámina. SAP, en su ejemplo, usa una descripción verbal de forecast y stock de seguridad. Esta página no afirma que ambos productos compartan nombres de campo, notación, calendario o implementación.

La correspondencia válida está en la relación conceptual ilustrada; la equivalencia técnica entre pantallas requiere documentación de la instalación. MIT OCW, Lecture 11, p. 9.

Si cambia el horizonte, cambia la cobertura

En el ejercicio, prolongar el plazo desde 40 hasta 50 días mueve el punto final 10 días más dentro del segundo bucket. La parte de forecast atribuida al plazo pasaría de 90 + 10/30 × 120 a 90 + 20/30 × 120, si se mantienen el mismo forecast, el mismo bucket de 30 días y el mismo prorrateo. Si el horizonte terminase justo al día 60, entraría el segundo bucket completo. La cuenta temporal cambia porque cambió el tramo cubierto.

Tampoco debe confundirse «plazo de reposición» con el intervalo entre revisiones de una política periódica. Este artículo no suma ese intervalo al plazo ni elige entre revisión continua y periódica. Si un resultado mezcla esos horizontes, la comprobación pertinente es volver a la definición de la regla concreta; no se resuelve añadiendo automáticamente otro bucket. La cantidad Q de un lote económico pertenece a una decisión distinta y no forma parte de estos cálculos.

Si el plazo empieza dentro de un bucket

El ejemplo anterior empieza en el límite del primer periodo. Supongamos ahora que el horizonte de 40 días comienza el día 10 de ese bucket y termina el día 20 del segundo. Quedan 20 días del primer forecast y entran 20 días del siguiente; con los mismos buckets de 30 días y una distribución lineal, la cobertura prevista es 20/30 × 90 + 20/30 × 120 = 140 unidades.

Si se mantiene el buffer dado de 25, el umbral de este ejercicio sería 165. Son cifras propias: SAP muestra una ilustración distinta que parte del inicio de un bucket.

Esta variante permite ver por qué no basta con comparar “40 días” con “un mes”. Para asignar los tramos hacen falta los límites de los buckets y el punto de inicio del plazo. Si el forecast ya está desglosado por día, repartir otra vez su total mensual perdería esa resolución. El cálculo tampoco incorpora el intervalo entre revisiones de una política periódica; solo cubre el plazo que se declaró.

Alcance: qué demuestran las dos fuentes y qué no

La Lecture 11 del MIT ofrece una estructura docente en la que el umbral suma demanda esperada durante el plazo y stock de seguridad. Su notación distingue los términos y las diapositivas comentan la selección del buffer en función de objetivos de coste o servicio.

El artículo usa la expresión para aclarar el puente entre componentes; no extrae de ella un valor recomendado de k, un nivel de servicio ni una configuración industrial universal. MIT OCW, Lecture 11, pp. 9–10

El ejemplo SAP disponible es más específico: habla de aprovisionamiento externo, un mes de 30 días, forecast mensual y plazo de 40 días. La fuente está identificada como versión 2025 FPS01 de S/4HANA On-Premise. Esos límites acompañan la cifra; separarla de su contexto puede hacer que una convención de ejemplo parezca una característica universal. La representación consultada fue un extracto seleccionado, no una captura íntegra de la ayuda SAP.

Preguntas frecuentes

¿El stock de seguridad forma parte del forecast del plazo?

No en las dos representaciones citadas: aparece como un término aparte que se añade a la cobertura de demanda prevista. En la notación MIT es kσL; en el pasaje SAP es el valor de stock de seguridad del ejemplo. Eso no establece cómo se almacenan ambos datos en cada pantalla.

¿Por qué no se suma todo el segundo mes en el ejemplo de 40 días?

Porque, con buckets de 30 días que comienzan al inicio del horizonte, los primeros 30 días cubren el primer bucket y solo quedan 10 días del segundo dentro de los 40. El extracto SAP representa esa parte como 10/30. Otro calendario o duración requiere revisar su propia base temporal.

¿El 100 de stock de seguridad de SAP es un objetivo?

No. Es el valor usado en la ilustración de esa fuente y versión. No es una recomendación de cuánto mantener para un artículo diferente.

¿Qué significa si el sistema ya muestra un número llamado ROP?

El nombre no basta para saber si el número contiene solo el forecast, el buffer o su suma. La definición del campo y de la regla local debe aclararlo antes de volver a sumar componentes.

¿Este cálculo decide cuándo hay que pedir?

No. La página explica cómo se relacionan dos componentes en un umbral. No evalúa el inventario disponible, la posición de stock, pedidos abiertos, una regla de revisión ni una orden real.