Qué indica el valor asignado
La pantalla permite afirmar algo concreto: hay una cantidad asociada a una referencia y a cierto alcance. El nombre del campo no revela por qué se fijó, qué incertidumbre cubre ni si alguien contrastó el nivel con datos recientes. NC State sitúa el stock de seguridad junto a la demanda media durante el plazo; ese marco ayuda a leer el dato, pero no explica por sí solo la SKU.
El tutorial de NC State relaciona el buffer con variaciones en la tasa de demanda o en el plazo de reposición, y con el equilibrio entre quedarse sin existencias y mantener unidades adicionales. Ese marco explica para qué puede usarse un stock de seguridad; no valida una SKU ni determina una cantidad adecuada para una empresa concreta. NC State, «Safety Stock Analysis», apartado “What Happens when either Demand or Lead Time Varies?”, líneas 493–502.
Antes de interpretar la cifra, identifica cuatro datos que cambian su significado: la SKU exacta, la unidad de medida, el ámbito al que se aplica (por ejemplo, centro o almacén) y el método o política que la genera. El periodo también importa si el registro cambia por fecha. No conviertas unidades ni combines centros hasta entender qué objeto representa la pantalla.
Qué incertidumbre pretendía cubrir
NC State distingue dos fuentes: la demanda puede variar mientras el plazo se mantiene parecido, o el plazo puede variar aunque el consumo sea relativamente estable. Puede haber ambas, pero una no demuestra la otra. Una cantidad final en una ficha tampoco permite reconstruir cuál se consideró si no hay una política, nota o dato enlazado. NC State, «Safety Stock Analysis», líneas 498–502.
Para leer un valor ya registrado, busca el motivo escrito y su alcance. Una nota que menciona “plazo” dice qué propósito declara el sistema o quien mantuvo el dato; no acredita que los plazos se midieran de manera uniforme. Si la nota habla de demanda, tampoco prueba que la serie esté completa. La diferencia entre declaración y evidencia evita convertir una etiqueta en una conclusión sobre el método.
MIT ofrece una distinción útil: en su esquema de cobertura durante el plazo, la demanda esperada y el stock de seguridad aparecen como componentes distintos. La clase vincula la selección de parámetros con objetivos de servicio y coste. Esto ayuda a no llamar “seguridad” a toda la cobertura prevista ni a tratar dos campos como equivalentes solo porque aparezcan juntos.
Es material docente, no una descripción de tu ERP ni una fórmula para recalcular el valor de una SKU. MIT, ESD.260 Lecture 11, diapositiva impresa 9, líneas 157–173.
Si una política local menciona un objetivo de servicio o un coste de inventario, conserva ese criterio separado de la cifra de buffer. El valor por sí solo no revela qué nivel de servicio se buscaba, cómo se midió ni qué coste se priorizó; tampoco es una probabilidad de servicio o una garantía de cobertura.
Para entender la decisión declarada, hace falta localizar el documento que define ese criterio y comprobar que se refiere al mismo producto, horizonte y ámbito. MIT y NC State describen el compromiso entre servicio, faltantes y existencias; no fijan un objetivo aplicable a esta planta.
El registro y la previsión pueden usar periodos o unidades distintos. Si uno habla de cajas por semana y otro de piezas por día, primero debe existir una conversión documentada y una ventana temporal comparable. Sin esas definiciones, una coincidencia numérica no demuestra que se esté leyendo el mismo concepto. Esta página no calcula el punto de pedido ni la cantidad de reposición.
Qué registro podría aclarar el motivo
Si la nota atribuye la cifra a demanda o plazo, la tabla ayuda a pedir solo la evidencia relacionada con esa explicación: una serie con referencia, unidad y ventana definida, o hitos que aclaren qué intervalo se midió. Si falta ese registro, deja el motivo como declarado y no completes el periodo por intuición. NC State distingue ambos tipos de variabilidad; la tabla es una guía de lectura local, no un formato exigido por la fuente.
| Motivo declarado | Evidencia útil para comprobarlo | Lo que no se deduce del campo |
|---|---|---|
| Variación de demanda | Serie de salidas con referencia, unidad y periodos definidos | Que la serie esté completa o mida toda la demanda |
| Variación del plazo | Hitos y definición local del intervalo | Que todas las órdenes sigan el mismo recorrido |
| No documentado | Política o nota que explique el método | Que se usara una causa concreta solo porque aparezca en un tutorial |
El método cambia la lectura de una ficha SAP
SAP S/4HANA Cloud Public Edition, versión 2608, describe tres métodos relacionados con el stock de seguridad del maestro de producto. Este caso concreto ilustra por qué hay que identificar el método antes de interpretar una cifra: un nivel estático, un buffer medido en días y una necesidad delta fechada no significan lo mismo. La documentación citada no confirma qué versión utiliza una instalación particular ni cómo está configurada una SKU. SAP Help Portal, “Safety Stock Methods”, versión 2608.
| Método descrito por SAP | Qué representa en esa documentación | Cómo leer la cifra o línea | Lo que no demuestra por sí sola |
|---|---|---|---|
| Static safety stock | Nivel de stock que se mantiene disponible frente a demanda inusualmente alta | Como nivel de seguridad asociado al producto | Que se haya revisado recientemente o sea suficiente |
| Time-dependent days of supply | Buffers de safety days y target days durante un periodo definido | El primero es el umbral descrito; tras caer por debajo, el método repone hasta el objetivo | Que “días” equivalga a una cantidad fija de unidades en toda fecha |
| Time-dependent safety stock | Necesidades delta asociadas a fechas | Como cambio temporal con signo, no como saldo absoluto | Que un delta negativo represente stock físico negativo |
En el método de días de cobertura, SAP describe safety days como el buffer mínimo que activa el proceso y target days como el nivel hasta el que se vuelve a completar el stock. En la página citada, el descenso por debajo de safety days dispara aprovisionamiento o producción; el relleno llega al nivel de target days.
Son el umbral de activación y el objetivo de reposición de ese método, no dos nombres intercambiables para una sola cantidad. Además, “días” nombra una cobertura temporal: no es automáticamente el mismo número de piezas para dos artículos con demandas distintas. Para entender una cifra hay que conservar el periodo y el método, y consultar la base de demanda que use la instalación antes de convertir días en unidades.
La ayuda 2608 define para MZ la conversión diaria: días de cobertura multiplicados por la suma de requerimientos de la fecha. El ejemplo oficial siguiente muestra cómo cambia el resultado. SAP Help Portal, “Safety Stock Methods”, versión 2608 y “Maintain Time-Dependent Stock Levels”, versión 2608.
El método temporal usa otra magnitud: SAP describe las variaciones fechadas como deltas que pueden aparecer en las vistas de necesidades o cobertura. Si el nivel programado aumenta, la línea delta tiene signo negativo; si disminuye, es positiva. El signo representa un cambio planificado en el eje temporal, no un saldo físico negativo. SAP Help Portal, “Time-Dependent Safety Stock”, versión 2608.
Cuando «un día» no es una cantidad fija
La página oficial de ayuda incluye un ejemplo del método MZ, “time-dependent days of supply”. Para el intervalo ilustrativo YYYY-08-11 a YYYY-08-13, el registro contiene Safety DOS de 1 día y Target DOS de 2 días. Los requerimientos diarios son 110, 120 y 100 cantidades de material; el ejemplo no especifica una unidad física. SAP presenta el buffer y el objetivo resultantes en cada fecha. SAP Help Portal, “Example of Usage of Time-Dependent Days of Supply”, versión 2608.500.
| Fecha del ejemplo | Requerimiento diario | Safety DOS: buffer de 1 día | Target DOS: objetivo de 2 días |
|---|---|---|---|
| YYYY-08-11 | 110 | 110 | 220 |
| YYYY-08-12 | 120 | 120 | 240 |
| YYYY-08-13 | 100 | 100 | 200 |
La lectura concreta es que “1 día” no equivale a una pieza ni a una cantidad fija para todo el intervalo. SAP calcula el buffer como un día del requerimiento de la fecha activa; al pasar de 110 a 120 y luego a 100, cambia la cantidad asociada al mismo Safety DOS. El objetivo de dos días también varía.
Por eso, para interpretar el valor de una SKU hay que conservar el método, la fecha y el requerimiento diario que la aplicación está usando. El ejemplo no nombra una unidad física, así que estos valores no pueden etiquetarse como cajas, piezas u otra medida sin consultar la ficha del material.
La tabla también muestra por qué importa la validez. El 10 de agosto queda fuera del intervalo fechado: SAP presenta un requerimiento de 100, sin buffer de seguridad activo, y una recepción de 100. En el día 11 el stock anterior al requerimiento es cero; después del requerimiento de 110, la vista muestra −110 antes de una recepción de 330.
El 12, el nivel anterior al requerimiento es 220; al consumir 120 queda 100 y la recepción mostrada es 140. El 13, el nivel anterior es 240; tras el requerimiento de 100 queda 140 y la tabla no muestra recepción. Son cifras del ejemplo publicado por SAP, no movimientos observados ni resultados de una ficha real.
La propia página tiene una discrepancia interna: la fila tabular del 12 de agosto muestra un requerimiento de 120, mientras que su explicación narrativa dice que se considera 110. SAP Help Portal, “Example of Usage of Time-Dependent Days of Supply”, versión 2608.500.
El negativo intermedio no describe mercancía físicamente almacenada por debajo de cero: es el nivel planificado que la tabla muestra antes de contabilizar la recepción. Y la recepción de 330 no es el Safety DOS; en ese renglón confluyen el nivel que se pretende alcanzar y el requerimiento del día. Separar buffer, requerimiento, saldo anterior, saldo resultante y recepción evita atribuir al campo una cantidad que corresponde a otra columna.
La página de mantenimiento especifica además que los niveles temporales se mantienen para materiales y centros determinados, con intervalos de validez. En ese ejemplo, las fechas llevan el marcador YYYY; no se ofrece un año concreto. La ayuda señala que la aplicación trabaja con intervalos futuros y puede ajustar los extremos de intervalos vecinos cuando se modifica uno para que no queden huecos.
Para comparar una captura con la tabla, hace falta comprobar que la fecha real consultada está dentro del intervalo activo y corresponde al mismo material y centro; una secuencia de tres días no representa necesariamente toda la política del artículo. También importa distinguir el parámetro de su fuente: Safety DOS es un número de días, mientras el nivel de buffer se recalcula con la suma de requerimientos de la fecha.
La unidad física depende de la unidad base del material y no puede recuperarse de los números sin leer esa ficha. SAP Help Portal, “Maintain Time-Dependent Stock Levels”, versión 2608.500.
SAP documenta este ejemplo bajo el método MZ para S/4HANA Cloud Public Edition, “2608 Latest” (versión del contenido 2608.500). Eso acredita qué significa la secuencia dentro de esta documentación, no que una instalación de una empresa use MZ ni que sus parámetros coincidan. Para comparar un registro real con el ejemplo habría que confirmar la edición del producto, el método visible, la fecha de validez, la unidad base y la necesidad diaria del material.
SAP Help Portal, “Maintain Time-Dependent Stock Levels” y “Example of Usage of Time-Dependent Days of Supply”, versión 2608.
Si dos capturas de una SKU no coinciden
Antes de concluir que alguien cambió el parámetro, comprueba si ambas capturas muestran el mismo material, centro, método y fecha de validez. En el ejemplo publicado por SAP, Safety DOS se mantiene en un día, pero el buffer pasa de 110 a 120 porque cambian los requerimientos diarios de 110 a 120.
Esa diferencia es compatible con el mismo número de días aplicado a necesidades distintas; por sí sola no demuestra que se editara el dato maestro. La comprobación útil es comparar el valor temporal con la necesidad diaria de cada fecha. Si el método, la fecha activa o el ámbito no coinciden, no atribuyas la diferencia a una sola causa. El ejemplo tampoco permite juzgar si el buffer es suficiente.
SAP Help Portal, “Example of Usage of Time-Dependent Days of Supply”, versión 2608.500 y “Maintain Time-Dependent Stock Levels”, versión 2608.
Antes de aplicar esa lectura, identifica el procedimiento de planificación asociado al método. La ayuda de SAP 2608 vincula el método temporal con MRP D y MPS M, y describe incompatibilidades con perfiles de cobertura y de plazo de seguridad. Si la pantalla muestra otro método o perfil, el ejemplo no basta para traducir su campo: hay que consultar la ayuda correspondiente a esa combinación y versión. SAP Help Portal, “Safety Stock Methods”, versión 2608.
Las cuatro páginas citadas se consultaron en SAP Help Portal mediante el servicio oficial de contenido. Se conservaron las respuestas JSON completas y el HTML íntegro de data.body, con hashes separados para cada respuesta y cada cuerpo. No se retuvieron respuestas HTML crudas ni capturas visuales del portal. Los metadatos identifican el contenido como SAP S/4HANA Cloud Public Edition 2608.500, build 4477, “2608 Latest”; eso no confirma la edición, versión ni configuración de una instalación concreta.
Aplicación a una ficha con procedencia incompleta
Imagina una ficha ficticia: A-204, centro Norte, unidad base «pieza» y stock de seguridad 18. Una nota local dice que pretende cubrir incertidumbre del plazo, pero no enlaza el periodo usado ni la serie de observaciones. En la misma pantalla hay un saldo físico de 31 piezas. Esas cifras permiten describir lo que la consulta muestra, pero no dicen si el periodo de plazo está bien definido ni si el nivel basta. Las cantidades y el registro son inventados.
| Lo que se observa | Lo que permite decir | Lo que queda abierto |
|---|---|---|
| A-204, centro Norte, 18 piezas en el campo | El valor asignado y el alcance que muestra la ficha | Si el alcance es por ubicación o si hay otros niveles vigentes |
| Nota “incertidumbre del plazo” sin serie ni periodo | El motivo declarado en esa nota | Si los plazos fueron medidos, con qué definición o ventana |
| 31 piezas en stock físico | El saldo observado en esa vista | Su relación con reservas, pedidos en curso o la regla de reposición |
No sumes el stock de seguridad al saldo físico como si ambos fueran una misma magnitud. La ficha permite describir el valor consultado y la nota permite repetir el motivo declarado; ninguna de las dos acredita por sí sola suficiencia. Si falta la serie o el periodo, registra que no se localizaron en esa consulta, sin concluir que nunca existieron.
Qué pedir antes de aceptar una interpretación
Al pedir una aclaración, conserva en una misma consulta la referencia, unidad, centro, fecha y método que muestra la ficha. Distingue lo visible de un motivo declarado y de una conclusión sobre suficiencia; si falta la política, serie o periodo, anota esa brecha sin completarla por intuición ni tomar otra SKU como sustituto.
Preguntas frecuentes
¿Qué dato confirma a qué artículo corresponde la cifra?
Comprueba la referencia exacta, la unidad base y el ámbito que muestra el registro. Dos formatos del mismo producto o dos centros pueden tener valores distintos.
¿La ficha indica si el buffer cubre demanda o plazo?
No necesariamente. NC State describe variaciones de demanda y de plazo, pero el valor guardado no identifica cuál se consideró si la política o la nota local no lo explican.
En SAP Cloud 2608, ¿un día de Safety DOS equivale a una pieza?
No. El campo expresa tiempo: en el ejemplo oficial, un día se traduce a requerimientos diarios de 110, 120 y 100 cantidades; SAP no identifica la unidad física de esos valores.
¿Puedo sumar el buffer al saldo físico para decidir cuánto pedir?
No con esos dos datos solamente. El buffer es un parámetro; el saldo es una observación. Para conocer el pedido hacen falta la regla local y los pedidos, reservas y demás magnitudes que considere.
¿Por qué cambia el buffer en SAP si Safety DOS sigue en un día?
El ejemplo de SAP aplica ese día a requerimientos distintos en fechas distintas: 110 y 120 cantidades de material producen buffers de 110 y 120. Compara material, centro, método y fecha antes de atribuir la diferencia a una edición del dato.
Límite de esta lectura
Esta lectura describe un campo existente y separa su valor, su motivo declarado y la evidencia consultada; no recomienda una cantidad ni diagnostica faltantes. NC State y MIT aportan marcos educativos. SAP queda limitado a páginas de ayuda de S/4HANA Cloud Public Edition 2608 consultadas y conservadas; no confirman la versión, método o configuración de una instalación. Para interpretar otro producto hay que consultar su propia documentación y los criterios locales.