Packs SAP (PP, QM, PM)

Un pack es un conjunto de interfaces listas para un escenario de negocio. En lugar de averiguar qué BAPI llamar, qué campos exige y cómo interpretar el retorno, usted elige “Notificación por tiempo” y el CMS crea la Interfaz, la Entrega y los Errores de Negocio ya configurados.

Son tres packs, todos incluidos en el CMS — no hay módulo adicional que contratar:

El mismo asistente ofrece la biblioteca de Transformadores ISA-95 / B2MML. Los packs de apertura de tickets no aparecen en él: los instala la activación de la herramienta en Mesa de ayuda.

Requisito previo

El pack se instala sobre una Aplicación que ya tenga vinculada una Conexión Externa de tipo SAP RFC. Si no la tiene, el botón de instalar ni siquiera aparece.

Antes de empezar, entonces:

1. Cree la Conexión Externa SAP RFC y pruebe la conexión (ver SAP RFC / BAPI).
2. Cree la Aplicación que representa al sistema que va a conversar con SAP (su MES, por ejemplo), con Keep Alive de tipo SAP RFC apuntando a esa conexión.

Instalación

En la pantalla Aplicaciones, en la fila de la Aplicación, haga clic en el ícono de cajas. El asistente tiene cuatro pasos.

1. Pack

Elija entre PP, QM y PM. Arriba se muestra lo que ya está instalado en esa Aplicación — útil para no reinstalar por error.

2. Recetas

Cada receta es un escenario de negocio: una Recolección o una Entrega, con todo lo que necesita. Están agrupadas por categoría y marcadas con la dirección:

• Recolección — SAP alimenta su sistema (leer orden, leer características de inspección).
• Entrega — su sistema escribe en SAP (notificar producción, registrar resultado, abrir aviso).

Tres presets arriba:

3. Parámetros

Los valores de su planta, ingresados una vez y aplicados a todas las recetas elegidas. Varían por pack, pero los más comunes son:

4. Revisión

Nada se graba antes de este paso. Usted ve:

• Cuántos objetos se crearán, se actualizarán o están personalizados.
• La verificación de compatibilidad contra su SAP: para cada receta elegida, el CMS pregunta a SAP si la función existe y si los campos usados existen en ese release.
• La lista objeto por objeto, con el nombre exacto de cada Interfaz, Recolección, Entrega y Error de Negocio.

El botón Instalar solo queda disponible después de eso.

La verificación de compatibilidad

Es el paso que evita el peor modo de falla: interfaces que parecen correctas y fallan recién con el primer mensaje.

Como efecto colateral, la verificación llena la caché de metadatos: el popup “Parámetros Función SAP” de las pantallas de Recolección y Entrega pasa a abrir al instante, incluso sin SAP accesible.

Después de instalar

Las interfaces aparecen normalmente en Interfaces, Recolecciones y Entregas — no tienen nada de especial. Se pueden editar, desactivar o eliminar como cualquier otra.

Una Interfaz del pack siempre tiene una sola dirección. Las de lectura llevan el sufijo _C; cuando el mismo asunto tiene los dos lados, la de escritura recibe _E — es el caso de ..._PM_ATIVO_C y ..._PM_ATIVO_E. Las demás son de Entrega.

No es orden estético: una Entrega dentro de una Interfaz de Recolección haría que el programador la procesara por el camino equivocado (ver Registros), y por eso el catálogo de los packs tiene una prueba automática que rechaza la combinación.

Qué debe hacer su sistema

Cada Entrega creada tiene una URL de recepción con el formato /{{Interfaz}}/{{Definición}}, y un contrato de campos con nombres de negocio. Ejemplo de la notificación por tiempo:

{
  "ordem": "000060003285",
  "operacao": "0010",
  "quantidadeBoa": 480,
  "quantidadeRefugo": 12,
  "unidade": "ST",
  "apontamentoFinal": "X"
}

El pack traduce esos nombres a los campos de SAP (AUFNR, VORNR, YIELD, SCRAP…). Los campos obligatorios se validan antes de que el mensaje llegue a SAP: si falta ordem, el mensaje se rechaza de inmediato con un error claro, en vez de convertirse en una falla de RFC.

Con las Recolecciones ocurre lo inverso: las que tienen parámetro de entrada exponen una URL que su sistema llama pasando, por ejemplo, el número de orden, y recibe el detalle listo.

Errores de negocio ya mapeados

Cada Entrega viene con los errores más comunes de ese escenario traducidos a una frase que el operador entiende, en lugar del código de SAP:

Reinstalar y actualizar

El asistente puede ejecutarse cuantas veces sea necesario en la misma Aplicación. El paso de revisión clasifica cada objeto:

• A crear — todavía no existe.
• A actualizar — existe, fue creado por este pack y sigue igual a lo que el pack grabó.
• Personalizado — existe, fue creado por este pack y fue modificado desde entonces.

Cuando una versión nueva del CMS traiga una versión nueva de un pack, la lista de packs instalados muestra “actualización disponible”.

Desinstalar

El botón de desinstalar está junto a cada pack instalado, en el primer paso del asistente. No es un “deshacer” ciego: elimina lo que el pack creó y que sigue exactamente como lo dejó, y preserva el resto, diciendo por qué.

Si algo quedó preservado, el pack sigue listado como instalado — así usted puede desinstalar de nuevo tras resolver lo que quedó pendiente.

Permiso

El asistente se controla con la Herramienta /applications/packs, separada de /applications:

• Incluir — instalar un pack.
• Eliminar — desinstalar.

Cada instalación queda registrada en el log de auditoría con el pack, la versión, la Aplicación, las recetas elegidas y los parámetros ingresados.

Lo que el pack no hace

• No crea la Aplicación ni la Conexión. Son suyas; el pack solo las referencia.
• No cubre campos Z ni BAPIs personalizadas. El pack entrega la base; adaptarlo a lo específico de su empresa es trabajo de proyecto.
• No adivina las reglas de su planta. Qué centro, qué clase de movimiento, qué clase de aviso — eso es lo que usted indica en el paso 3.