SAP LMPC HJPT: leer el tablero y sus registros

Una vista del HJPT de SAP LMPC permite leer datos de planificación detallada, pero no basta por sí sola para demostrar que una operación se guardó ni que se ejecutó en planta. SAP describe la planificación como una simulación en memoria y los cambios solo adquieren efecto operativo cuando se guardan. La guía siguiente se limita a la solución LMPC/HJPT y a la documentación SAP versión 2026; no define cómo debe funcionar una caja Heijunka física ni otros tableros digitales.

SAP, Lean Manufacturing Planning and Control (LMPC), versión 2026, pp. 6–9 y 17.

Identifica primero qué sistema y qué vista estás leyendo

LMPC es una solución de consultoría SAP para planificación detallada de órdenes. El manual la distingue de la planificación de capacidad aproximada: para esa función separada, SAP menciona LRP. La tabla HJPT amplía la tabla estándar de planificación gráfica y se integra con funciones SAP de capacidad. Su alcance documentado incluye SAP ERP y S/4HANA en instalaciones locales o nube privada; SAP indica que no está disponible en S/4HANA Cloud Public Edition.

Son límites de producto descritos por SAP, no una clasificación general de métodos Heijunka. SAP, LMPC, pp. 6–9.

La distinción importa al leer una captura o una exportación. “Tablero Heijunka” puede aludir a una caja física con tarjetas, a una cuadrícula local o a una aplicación. En este artículo, HJPT significa la tabla de planificación detallada de SAP LMPC. Una conclusión sobre sus campos, perfiles o registros no se traslada sin más a una caja física, a otro módulo de SAP o a un producto distinto.

Esa frontera evita atribuir al nombre “Heijunka” un comportamiento que la fuente solo documenta para este sistema.

El propio manual advierte que presenta escenarios estándar, no todas las opciones existentes o personalizables. También dice que los ejemplos de configuración suministrados son ejemplos que deben adaptarse al sistema. Por tanto, una guía de lectura puede ayudar a reconocer el significado de un campo documentado, pero no permite confirmar que la instalación de una empresa use ese campo, que su perfil esté configurado igual o que un caso no descrito sea compatible. SAP, LMPC, pp. 11–13.

Antes de interpretar una posición, identifica el perfil, el modo de llamada y si se ven los tres componentes del HJPT. Según SAP, la vista suele combinar un área gráfica de planificación, una cuadrícula ALV con datos de órdenes y ventanas de gráficos de capacidad, inventario o relaciones entre órdenes. La disposición puede variar según la configuración. Que dos personas nombren “la tabla HJPT” no garantiza que estén mirando la misma composición o las mismas columnas. SAP, LMPC, p. 16.

La diferencia entre los componentes cambia lo que se puede inferir. El gráfico sitúa operaciones sobre un eje temporal; ALV presenta filas de datos de órdenes; los gráficos agregan otras lecturas, como utilización de capacidad. Si un informe conserva solo ALV, quizá permita comparar campos de fechas u órdenes, pero no muestra la posición gráfica de las órdenes en la línea de tiempo.

Si conserva solo una captura del gráfico, puede faltar el detalle de los campos que explican una asignación. No deduzcas el componente ausente por el diseño de una captura. SAP documenta expresamente el modo sin gráfico y la pérdida de la posición temporal en esa vista. SAP, LMPC, pp. 16 y 26.

Lee la línea de tiempo con sus condiciones

El HJPT construye una escala gráfica con requisitos de capacidad de las órdenes y capacidades disponibles de los centros de trabajo. Una línea vertical discontinua señala el día y la hora actuales del usuario. El manual explica que, con la configuración usual, no se planifica en el pasado. La posición de esa línea depende de la zona horaria del maestro de usuario; la función de planificación calcula independientemente de esa zona, que solo delimita el área que considera pasada.

SAP, LMPC, p. 12.

Este detalle cambia la lectura de un horario: un punto que aparece antes o después de la línea no es necesariamente una marca de tiempo universal. Depende del usuario y de la zona horaria que SAP lee en ese contexto. El manual advierte que una zona horaria incorrecta puede hacer que las órdenes aparezcan planificables en el pasado o limitar la planificación a un tramo futuro.

Eso no autoriza a diagnosticar la configuración mirando una sola captura; es una condición que debe verificarse con el contexto del usuario y del sistema. La guía aquí describe el límite interpretativo, no indica cómo modificar datos maestros.

También importa qué datos existían antes de abrir la planificación. SAP dice que una orden solo puede procesarse si tiene requisitos de capacidad y que los datos necesarios deben existir previamente. Para un caso estándar de producción menciona centros de trabajo con capacidad disponible y fórmulas de planificación, materiales con listas de materiales y rutas, y, cuando corresponda, versiones de producción. Si falta uno de estos antecedentes en la evidencia compartida, el HJPT no permite rellenarlo por intuición.

La fuente enumera estos requisitos como contexto de uso, no como lista exhaustiva para cualquier proceso. SAP, LMPC, pp. 11–12.

La vista ALV tiene otra condición de lectura: el orden visual de sus filas no siempre determina el orden en que una función procesa operaciones. Para el modo de fondo /LMPC/HJPT, SAP explica que los registros se ordenan por centro de trabajo y hora de inicio de los requisitos de capacidad, no por el criterio de ordenación guardado en el ALV.

Así, una tabla ordenada por número de orden puede servir para localizar una fila, pero no prueba que el procesamiento de fondo siguiera ese orden visual. SAP, LMPC, pp. 26–27.

Separa una simulación de un cambio guardado

El manual distingue el estado que se trabaja en memoria del que se guarda en la base de datos. Al comenzar, HJPT carga datos; las modificaciones se realizan en una simulación interna. SAP dice que esos cambios de simulación no son visibles en la base de datos y que se escriben de nuevo al guardar. También explica que una actualización puede anular acciones no guardadas sin salir de la transacción.

Por eso, una flecha movida, una fecha calculada o un botón presionado en una secuencia de capturas no bastan para afirmar que el cambio quedó persistido. SAP, LMPC, pp. 17 y 100.

La palabra “operativo” en esta descripción se refiere al efecto que SAP atribuye al guardado dentro del sistema. No demuestra que una máquina haya recibido una orden, que el material estuviera disponible o que la operación se ejecutara. La pantalla documenta planificación; para afirmar ejecución harían falta registros adecuados del proceso real. Esa separación es una inferencia sobre el alcance de la evidencia: el manual trata el plan en SAP, no certifica por sí mismo lo ocurrido físicamente.

Los bloqueos ayudan a explicar por qué una orden puede aparecer protegida durante una edición, pero no sustituyen la evidencia de guardado. En la entrega estándar descrita, SAP establece bloqueos a nivel de orden cuando se producen cambios. El manual añade que la configuración puede cambiar ese comportamiento para bloquear automáticamente órdenes de producción o proceso al llamar la tabla; no se bloquean automáticamente las órdenes planificadas de esa forma.

También menciona una columna “Lock” que puede mostrar bloqueos propios o externos. La existencia de un candado señala un estado de edición, no el resultado de guardar ni la ejecución de la orden. SAP, LMPC, p. 100.

Para revisar una evidencia, anota qué se sabe y qué falta: ¿la captura es anterior o posterior al guardado?, ¿la fila tiene un indicador de cambio?, ¿hay un par de registros de carga y guardado?, ¿la fuente muestra el mismo usuario y hora local? Si no hay respuesta en los materiales, la conclusión correcta es “no consta en esta evidencia”.

El manual no promete que una captura aislada conserve el historial de cambios y tampoco convierte un bloqueo en confirmación de persistencia.

Interpreta los campos del timetable como datos de planificación

La función S_FPL distribuye operaciones seleccionadas a intervalos definidos por el timetable LMPC. SAP documenta cinco campos que puede rellenar en ALV: número de timetable (TT_ID_TT), identificador de bloque (BLOCK_ID_TT), grupo de producción (PR_GRP_TT), fecha de inicio (STDATE_TT) y hora de inicio (STTIME_TT). Son campos de asignación y horario calculado; no equivalen a una marca de producción terminada. SAP, LMPC, pp. 223–225.

La condición de ejecución es decisiva. Si se usa la función sin despacho inmediato, SAP presenta los campos de timetable como resultado de una simulación de distribución. La fecha y hora indican el momento calculado por la lógica; si después se quiere efectuar el despacho, el manual describe otras funciones que reconocen la asignación.

En esa modalidad no inmediata, los datos de timetable no se guardan en la base de datos y se pierden cuando se recarga la información o termina la planificación. Por tanto, una exportación de esos campos puede respaldar que el sistema calculó una propuesta, pero no que una orden fue finalmente despachada. SAP, LMPC, p. 226.

Un BLOCK_ID_TT combina varios elementos separados por #: timetable, planta, centro de trabajo, número de bloque y día de la semana. Descomponerlo permite saber a qué bloque se refiere la asignación documentada. No aporta, por sí solo, un historial de cambios ni el orden completo de las operaciones de una orden. Si el identificador se presenta sin el resto de los campos o sin su leyenda, conserva esa limitación en vez de traducirlo a una secuencia completa.

SAP, LMPC, p. 226.

Hay una excepción importante para las órdenes con varias operaciones. SAP advierte que la asignación a intervalos del timetable no toma en cuenta las secuencias de operaciones. El manual dice que no debería usarse con órdenes de varias operaciones, salvo el caso acotado en que solo se planifique la operación del recurso cuello de botella por cada orden.

Es una limitación de esa función, no una afirmación de que todos los procesos o todos los tableros deban planificarse de esa manera. Una fecha asignada a una operación no permite reconstruir automáticamente la precedencia entre las demás. SAP, LMPC, p. 224.

La documentación de la lógica 1 añade otras condiciones al interpretar una asignación. El recorrido de días usa días naturales, no días del calendario de fábrica; una operación se asigna solo si cabe completa en un hueco de capacidad libre; las operaciones ya despachadas no se mueven. Si la planificación ya tiene órdenes despachadas, pueden quedar huecos que las operaciones nuevas no llenan. Estas reglas describen el algoritmo documentado.

No permiten concluir que un hueco visible sea un error ni que una secuencia distinta sea adecuada para la instalación concreta. SAP, LMPC, pp. 227–229.

Reconoce una vista de seguimiento que no admite cambios

SAP describe el perfil LMPC_T05 como un perfil de visualización pura: no permite operaciones de planificación ni arrastrar elementos. Su composición distribuye la tabla de capacidad, ALV y gráficos en ventanas separadas, pensadas como vista de monitor; en la configuración descrita, los datos se actualizan automáticamente cada 180 segundos. Esta información ayuda a clasificar una captura: si procede de ese perfil, no hay que tratarla como prueba de que alguien arrastró una orden desde esa misma vista.

El refresco periódico también significa que dos capturas separadas pueden corresponder a lecturas distintas. SAP, LMPC, pp. 35–36.

La precisión “en la configuración descrita” evita convertir el perfil de ejemplo en garantía de que todas las instalaciones usan exactamente la misma composición. El manual muestra qué es LMPC_T05 y qué limitaciones tiene; no identifica por esa descripción qué perfil se utilizó en una captura ajena. La identificación necesita evidencia de la instancia o del contexto de la captura. El nombre del archivo o el aspecto de una pantalla no bastan si el perfil no aparece documentado.

Qué aporta el registro LOAD/SAVE y qué deja fuera

La transacción /LMPC/PLTPR registra datos del HJPT en dos momentos: cuando se cargan (LOAD) y cuando se guardan (SAVE). SAP explica que para cada operación pueden mostrarse dos filas, una de lectura y otra de guardado, con las que se comparan los datos de planificación. Entre los campos documentados están número y tipo de orden, número de operación, estado de despacho, requisitos de capacidad, fechas y horas, centro de trabajo, planta, material, cantidad y estados de cabecera u operación.

Ese conjunto ofrece contexto para comparar una planificación antes y después del guardado; no convierte el log en un registro universal de todo lo que sucedió en planta. SAP, Transaction /LMPC/PLTPR HJPT Planning Table Log, versión 2026, secciones “Data Output” y “Restriction”; SAP, LMPC, pp. 524–528.

El momento de guardado condiciona qué filas existen. Según SAP, los datos se determinan al abrir HJPT y al guardar, pero los dos registros (LOAD y SAVE) solo se almacenan al ejecutar la función de guardado. Si se recarga sin guardar antes, vuelve a determinarse un registro LOAD. Una diferencia entre filas describe datos capturados en esos dos puntos; si no existe SAVE, la ausencia no demuestra que no hubiera una modificación temporal en pantalla.

Puede indicar que no llegó a registrarse un guardado según la lógica documentada, pero no explica por qué ni qué ocurrió fuera de HJPT. SAP, Transaction /LMPC/PLTPR, apartado “Data Output”; SAP, LMPC, p. 526.

El alcance del registro tiene límites adicionales. SAP indica que solo se pueden guardar datos leídos en HJPT y que los proveedores de datos correspondientes deben estar activos. Las filas se reducen a una por orden y operación para capacidad relevante de planificación; si hay suboperaciones, se conserva una de ellas bajo la condición descrita en el manual.

En segundo plano solo se actualizan las fechas de requisitos de capacidad después del código de acción, porque no vuelven a ejecutarse los proveedores. Así, “no aparece en el log” no equivale a “no existió”: el dato puede no haberse leído, no estar cubierto por el proveedor activo o no pertenecer al alcance de la salida. SAP, LMPC, pp. 527–528.

El protocolo también afecta a la instalación. El manual dice que registrar consume tiempo al guardar, usa memoria adicional y puede generar carga en la base de datos; recomienda usarlo durante pruebas, no en operación productiva. Cuando está activo, el registro se realiza en todo el cliente al guardar HJPT, sin limitarlo a un centro de trabajo o usuario concreto. El periodo predeterminado de conservación es de 28 días y puede cambiarse mediante parámetros del sistema.

Los tiempos de lectura y guardado corresponden a hora local del usuario. Estos límites hacen que una exportación del log deba leerse con su ventana temporal, alcance y contexto; no lo describas como auditoría completa ni como conservación permanente. SAP, Transaction /LMPC/PLTPR, “Note”, “Restriction” y “Data Output”; SAP, LMPC, pp. 524, 526–528.

Ejemplo de lectura, no de operación

Imagina un expediente didáctico con una orden ficticia O-17 y una operación ficticia 0010. En una captura, ALV muestra una fecha de inicio y el timetable identifica un bloque. En otra evidencia posterior, una fila LOAD y otra SAVE contienen los campos de esa misma operación. El ejemplo no describe una empresa real, no incluye mediciones ni demuestra un resultado.

Sirve para separar preguntas que a menudo se mezclan: qué se veía, qué proponía el cálculo y qué llegó a guardarse. SAP, LMPC, pp. 225–226; SAP, Transaction /LMPC/PLTPR, “Data Output”.

Los identificadores son inventados para el ejemplo; la tabla no reproduce una captura ni campos de una orden real. La interpretación se mantiene dentro de lo que permiten los campos que SAP documenta. Si la evidencia no identifica la modalidad de despacho, el perfil, los proveedores o el periodo seleccionado, esa falta de contexto permanece abierta. Una lectura cauta no rellena el hueco con una explicación probable.

Una comprobación útil antes de cerrar una conclusión

Para describir un artefacto concreto, conserva cinco elementos junto a la captura o exportación: versión del manual o del producto que se está usando como referencia; perfil y componentes visibles, si están identificados; fecha, hora local y usuario que contextualizan la lectura; estado de simulación o guardado que la evidencia realmente muestra; y alcance del registro, incluidos los campos disponibles y el periodo retenido. No es una lista oficial de SAP ni sustituye los controles de una organización.

Es una forma editorial de que otra persona pueda distinguir observación, inferencia y dato ausente. Las condiciones de versión, perfil, estado y retención proceden de los límites descritos por SAP. SAP, LMPC, pp. 9, 16–17, 35–36, 100; SAP, LMPC, pp. 524–528.

Si la vista y el log no identifican el mismo perfil, intervalo y orden, no los unas como si formaran una secuencia continua. Conserva la relación como no demostrada hasta que exista un registro que vincule ambas fuentes. La lectura queda entonces delimitada: qué calculó HJPT, qué se guardó y qué evidencia independiente confirma la ejecución física.

Preguntas frecuentes

¿HJPT es una caja Heijunka física o un tablero universal?

No. Aquí HJPT es la solución de planificación detallada de SAP LMPC. La documentación 2026 no establece que sus campos o comportamiento definan una caja física ni cualquier otra aplicación de tablero. SAP, LMPC, pp. 6–9.

¿Un cambio visible en el HJPT ya está guardado en la base de datos?

No necesariamente. SAP describe las modificaciones como simulación en memoria y señala que solo tienen efecto operativo al guardar. Una captura sin contexto de guardado no demuestra por sí sola persistencia. SAP, LMPC, pp. 17 y 100.

¿Los campos del timetable demuestran que se ejecutó una operación?

No. En una distribución no inmediata, esos campos representan una simulación y SAP dice que no se guardan en la base de datos; al recargar o terminar la planificación se pierden. La ejecución física requiere otra evidencia. SAP, LMPC, p. 226.

¿El registro /LMPC/PLTPR conserva todos los cambios?

No. SAP limita el registro a los datos leídos en HJPT con los proveedores correspondientes activos; los pares LOAD/SAVE se almacenan al guardar, el registro afecta al cliente y el plazo predeterminado es 28 días. SAP lo recomienda para pruebas, no para operación productiva. SAP, Transaction /LMPC/PLTPR, “Note”, “Restriction” y “Data Output”; LMPC, pp. 526–528.

¿El perfil LMPC_T05 permite planificar?

No. SAP lo describe como un perfil de visualización sin operaciones de planificación ni arrastre, con refresco automático cada 180 segundos en la configuración documentada. SAP, LMPC, pp. 35–36.