Las ubicaciones técnicas SAP PM, representan el lugar en el que se realiza una tarea de mantenimiento. Además, también representa un área del sistema en la que puede montarse un objeto. Estos objetos se denominan equipos.

En este artículo vamos ha hablar sobre las ubicaciones técnicas de SAP PM y los objetos denominados ‘equipos’, que podemos montar en estas.

Definición de una ubicación técnica en SAP PM

La ubicación técnica SAP PM es la estructura jerárquica de varios niveles que se organiza de acuerdo a los siguientes criterios:

• Espaciales.
• Técnicos o de procesos.
• Funcionales.

En mantenimiento se utilizan ubicaciones técnicas si:

• Se quiere reproducir la estructura de sistemas técnicos de la empresa de acuerdo a criterios funcionales.
• Hay que realizar medidas de mantenimiento sobre un área funcional común.
• Se registran medidas de mantenimiento de zonas homogéneas.
• Se deben guardar datos para su posterior evaluación.
• Control de costes para supervisar parte del sistema.

Alta de una ubicación técnica en SAP PM

Para dar de alta una ubicación técnica primero se debe tener definido por parametrización el indicador de estructura.
Este indicador especifica los siguientes factores:

• Cantidad de niveles jerárquicos de un sistema técnico.
• Longitud de la clave de los niveles.
• Carácter separador.
• Tipo de caracteres permitido, letras, números o ambos.

Las ubicaciones técnicas permiten montar y desmontar los equipos sobre los que se realizarán los mantenimientos. También facilitan la actualización de datos ya que se heredan de los niveles superiores a los inferiores.

Ficha de una ubicación técnica en SAP PM

La ficha de ubicación técnica se divide en dos partes. Unos datos de cabecera obligatorios y varias pestañas para completar la información.

Los datos de cabecera son la identificación de la ubicación técnica, de acuerdo a su posición en la jerarquía, el tipo, la denominación y el status del sistema.

Después se completan los datos necesarios de las diferentes pestañas:

• General, es la pestaña donde se encuentran los datos generales de la UT tales como peso, tamaño, fecha de adquisición, datos de fabricación, …
• La pestaña de emplazamiento, es donde están los datos referentes al emplazamiento físico de la ubicación técnica, así como la dirección.
• Pestaña de organización donde se encuentran los datos referentes a la sociedad así como los diferentes elementos sobre los que se pueden imputar los costes referentes al mantenimiento de la UT, y de los equipos que están montados en ella. También se puede informar datos de los responsables de planificación para la UT.
• Estructura, se trata de la pestaña en la que se ve la relación de la ubicación técnica respecto a otras de la misma estructura, así como los posibles equipos que estén montados en ella.

Para crear una nueva ubicación técnica seguiremos la ruta:

Logística -> mantenimiento -> Gestión de objetos técnicos -> Ubicación técnica -> Crear.

A continuación, se muestra un pequeño listado de las transacciones SAP relacionadas con las ubicaciones técnicas SAP PM:

1. Crear la ubicación técnica; transacción IL01
2. Modificar una ubicación; transacción IL02
3. Visualizar las ubicciones tecnicas; transacción IL03

Una vez creadas las ubicaciones técnicas podremos visualizar la estructura mediante la transacción IH01.

Esto muestra el listado jerarquizado con todas las ubicaciones técnicas, equipos e incluso lista de materiales que están montados en una ubicación técnica para tener una visión completa de la estructura.

Con esto ya podrás dar de alta ubicaciones técnicas SAP PM y completar sus fichas.

En este artículo se habla sobre qué es una BAPI en SAP y  cómo encontrar la más adecuada para tu aplicación.

Las BAPIs (Business Application Programming Interfaces) son las interfaces estándar de SAP. En concreto, son piezas de código en forma de módulo de funciones, usadas en la integración entre componentes de SAP, así como con componentes externos.

Dicha integración de componentes, se realiza a nivel de negocio, no a nivel técnico, lo que permite una mayor estabilidad en la unión e independencia de la tecnología de comunicación subyacente.

Las BAPIs están ligadas en forma de método a los objetos de negocio de SAP, ocupados de cubrir múltiples procesos de datos dentro del sistema. Todas las BAPIs tienen una serie de características en común:

• Son métodos de un objeto de negocios.
• Todas están definidas como funciones RFC (Remote Function Call).
• Evitan las ventanas de dialogo durante el procesamiento.

Métodos de Objetos de Negocio

Los objetos de negocio son similares a las clases, esto es, una serie de atributos, métodos, eventos y campos clave para una aplicación de negocio o escenario específico.

Los objetos de negocio se recogen en un repositorio (BOR – Business Object Repository) accesible desde la transacción SWO1. Como parte de ese repositorio se pueden visualizar los métodos de cada objeto de negocio, que se corresponden a las diferentes BAPIs del sistema.

Alternativas a los Batch Input

Las BAPIs tienen varias funciones:

• Generar reports.
• Como comunicación entre sistemas SAP o entre sistemas SAP y sistemas NON-SAP.
• Para la migración de datos.

Teniendo en cuenta está última funcionalidad, las BAPIs en SAP representan una alternativa a los métodos tradicionales como los Batch Input (mediante CALL TRANSACTION). La principal ventaja con respecto a estos es que, al tratarse de un desarrollo propio de SAP, no se verá afectado por modificaciones futuras. En el caso de los Batch Input un cambio en una dynpro entre versiones puede por el contrario provocar un error.

Diferencias entre BAPI y RFC

Todas las BAPIs son funciones RFC, pero no todas las funciones RFC son BAPIs. Las principales diferencias entre ambas son:

Encontrar la BAPI adecuada

En muchas ocasiones, el mayor problema a la hora de utilizar una BAPI es precisamente encontrar la adecuada a nuestras necesidades.

Aparte de opciones externas (Comunidad SCN, MundoSAP), el sistema nos ofrece su propia herramienta de búsqueda mediante la transacción BAPI. Gracias a esta transacción y conociendo el objeto de negocio, obtendremos de modo sencillo las principales BAPIs disponibles en SAP, así como información relacionada útil como la release de liberación, la descripción de la BAPI o el nombre de la propia función a utilizar.

Al comienzo de este artículo se muestra una imagen del explorador de BAPIs de SAP.

Con esta información ya sabemos qué es una BAPI en SAP y lo que es más importante aún, cómo elegir la que mas se adecua a nuestras necesidades.

En este articulo sobre SAP Design Studio, hablamos del Crosstab y chart, componentes fundamentales de esta aplicación.

Tras leer los artículos “SAP design Studio: Cuadros de mando” y “SAP design Studio: Arquitectura” entendemos que la forma de explotación de la información en SAP Design Studio se basa en creación de Datasources (que podrían definirse como “las vistas de queries a usar en Design Studio”). Si ésta es la fuente, ¿Qué opciones tenemos de cara a mostrar esa información en nuestra aplicación?

Design Studio ofrece una gran variedad de componentes. En este primer artículo vamos a describir las formas más básicas, y, por ello, más importantes, de representar la información: tablas y gráficos, conocidas como Crosstab y chart.

Antes de ir presentándolos es importante saber cómo se asigna un Datasource a un Crosstab, o cualquier otro componente que lo permita. La forma de hacerlo es seleccionando éste en las opciones de Data Binding del componente.

Al buscar por Datasources es importante resaltar que lo que nos van a aparecer serán los alias de los que hayamos definido anteriormente.

Todos los componentes tienen unas opciones básicas de configuración y otros, como los gráficos, tienen una ventana de propiedades adicionales.

La gran mayoría, tienen ciertos eventos en los que se puede programar código en lenguaje BIAL, el cual está basado en Javascript (por ejemplo, al pulsar sobre una línea de una tabla puede hacer que se desencadenen ciertos eventos, como podría ser el filtrado de ciertos elementos en un gráfico).

Crosstab

Componente básico que muestra los datos de un Datasource en una tabla. La estructura de la tabla será tal cual la hayamos definido en la vista inicial.

Chart

Elemento a través del cual los datos de un Datasource son convertidos en un gráfico. Hay múltiples opciones de tipo de gráfico, que van desde los de líneas, columnas, dual stacked, de calor, etc.

En la versión 1.6 de Design Studio aparece un nuevo tipo de componente para poder mostrar gráficos: el Infochart. La diferencia de éste más evidente respecto al Chart es que tiene otra “vista inicial” parecida a la de los Datasources, en la cual se pueden realizar ciertas parametrizaciones. Profundizaremos en las diferencias del Chart Vs Infochart en otro artículo.

Estos dos componentes son los que consideramos como “básicos”. Debido a que puede programarse código en eventos (onSelect: qué pasa al seleccionar elementos en la tabla o el gráfico), con solo utilizar ambos ya puede crearse un flujo de navegación rudimentario en un Cuadro de Mando.

Seguiremos hablando de componentes importantes de la aplicación SAP Design Studio en próximos artículos.

En este artículo veremos cómo usar configuración dinámicas SAP PI (Process Integration).

Adaptadores de comunicación en SAP FI

Existen en este módulo de SAP diferentes tipos de adaptadores que permiten establecer todo tipo de comunicaciones: RFC, File, SOAP, HTTP, Mail, IDOC…

Cada uno de estos adaptadores en SAP PI ofrece diferentes parámetros para configurar correctamente dicha comunicación. Estos parámetros cambian en función de si el adaptador es de tipo Sender o de tipo Receiver.

La mayoría de estos parámetros son estáticos, esto es, hay que configurarlos desde el Integration Builder introduciendo valores en los campos correspondientes del adaptador. En la siguiente imagen vemos la configuración de un canal de comunicación con adaptador RFC Receiver con los siguientes parámetros estáticos:

• Application Server
• Logon User
• Logon Password
• Logon Language
• Logon Client
• …

Es solo un ejemplo, ya que de hecho, la mayoría de los adaptadores tienen este tipo de parámetros estáticos.

Dynamic Configuration SAP PI

Con las nuevas versiones de SAP Process Integration (SAP PI 7.31, SAP PO 7.40…), cada vez son más los adaptadores que permiten la configuración dinámica de adaptadores. Es decir, adaptadores cuyos parámetros pueden variar en función del mensaje que se vaya a transmitir durante la integración.

A esto se le conoce como Dynamic Configuration y se consigue utilizando un mapeo Java o una UDF (User Defined Function) en la parte de diseño de SAP PI, el Enterprise Service Builder.

Un caso muy claro de este tipo de configuraciones dinámicas, se da en los adaptadores de tipo File. Por ejemplo, un adaptador File Receiver que va a dejar un fichero .TXT cuyo nombre depende de la fecha y hora en el que se produzca el procesamiento.

Usar dynamic configuration

A continuación vamos a ver qué pasos hay que llevar a cabo para configurar dinámicamente este tipo de parámetros:

Activar y configurar los atributos de mensaje específicos del adaptador (variables)

Los adaptadores que permiten Dynamic Configuration disponen de una opción para activar este tipo de atributos. En función del adaptador aparecerán más o menos opciones. En función de estas opciones se debe hacer la correspondiente configuración.

Crear una UDF o mapeo Java para establecer valor dinámico

En el Enterprise Service Builder, se debe un mapeo de mensaje con una UDF (o mapeo Java). Utilizando código JAVA podemos dar valor al atributo variable que corresponda. A continuación se muestra el código para establecer dinámicamente el nombre de un fichero:

Date fecha = new Date();
DateFormat dateFormat = new SimpleDateFormat("yyyyMMdd_000000000");
String nombreDinamico = " dateFormat.format(new Date()) +"_FACTURA.txt";
DynamicConfiguration conf = (DynamicConfiguration) container.getTransformationParameters().get(StreamTransformationConstants.DYNAMIC_CONFIGURATION);
DynamicConfigurationKey key = DynamicConfigurationKey.create("http://sap.com/xi/XI/System/File","FileName");
conf.put(key, nombreDinamico);
 

Con estos dos pasos, conseguiremos que el nombre del fichero que genere el adaptador File Receiver sea dinámico en función de la fecha y hora actual.  Este es solo un ejemplo de esta interesante capacidad de SAP PI.

Como habrás podido comprobar, las configuraciones dinámicas en SAP PI son muy sencillas y añaden funcionalidades muy interesantes a nuestras aplicaciones.

En esta serie de artículos hablamos sobre el archivado en SAP. Mostraremos cuáles son los pasos necesarios para archivar y leer registros en SAP.

En el primer artículo veremos qué tipo de objetos se pueden archivar y los pasos previos que hay que dar para que el archivado y su posterior lectura de información funcionen de la manera que queremos.

Llega un momento en el que una tabla de la base de datos puede llegar a contener una enorme cantidad de registros y como resultado las consultas se hacen demasiado largas como para que sean eficientes.

Mediante archivado en SAP, lo que queremos conseguir es que los registros que nosotros deseemos conservar sean almacenados en un fichero desde el cual la información siga siendo accesible. Al mismo tiempo, queremos que esos registros desaparezcan de las tablas de la base de datos para aligerar las consultas.

El archivado puede realizarse de cualquier tipo de objeto:

• Ventas y Distribución (SD)
• Gestión de Materiales (MM)
• Ejecución de logística (LE)
• Gestión de Almacenes (WM)
• Mantenimiento de Planta
• Servicio al Cliente (PM/CS)
• Planificación de la producción (PP)
• …

Archivado de Orden de Ventas (Sales Order)

Durante esta serie de artículos realizaremos un archivado en SAP de una orden de ventas.

La transacción utilizada para los archivados es SARA.

Preparar el archivado

Por defecto SAP nos da unas infoestructuras preparadas para poder mostrar la información una vez archivada.

Existe la posibilidad de crear nuestras propias infoestructuras o modificar las existentes, para los catálogos de campos (field catalogs) que encajen con el tipo de objeto que queremos archivar. Los catálogos de campo queremos utilizar se pueden determinar a partir de la próxima tabla.

Para preparar el archivo de la estructura info hay dos opciones:

Desde la transacción SARA -> Sistema de información ->Customizing

Desde la transacción SARI -> Customizing

Según el tipo de objeto y el objeto de archivo elegiremos la estructura info archivo a modificar.

En este paso elegimos los campos que más adelante queremos visualizar.

En caso de que hayamos modificado la infoestructura del objeto SAP o creado una nueva, tenemos que activarla pulsando el botón .

Si se han realizado modificaciones en la estructura info después del archivado y borrado hay que activarlo de nuevo. Para ello acudimos a la transacción SARI ->

Elegimos cualquiera de las dos opciones y pulsamos .

Una vez lista la preparación previa al archivado en SAP, en próximos artículos se continuará con el proceso de archivado y borrado.

En el artículo anterior “Componentes de Design Studio (I) – Crosstab y Chart”, explicábamos dos de las formas más importantes de visualización de datos dentro de SAP Design Studio.

Hoy, hablamos del componente más trivial a la hora de ofrecer cierta navegación en un Cuadro de Mando: Dropdown box. Mediante este componente, el usuario puede seleccionar un elemento de un array previamente definido.

Además, explicaremos cómo vincular ciertos valores de un Datasource a propiedades de los componentes mediante el “Binding”.

Binding

Antes de profundizar en Dropdown box, es importante hablar de la opción “Binding” que existe en la gran mayoría de las propiedades de los componentes, no solamente en los Dropdowns.

Esta opción nos permite vincular el valor de una propiedad al valor de un Datasource.

Por ejemplo, podríamos hacer que en un texto siempre apareciese el valor de un ratio, o que los elementos de un array, como es el Dropdown, dependieran de los valores de cierta característica de una query.

Es una alternativa que facilita muchísimo el trabajo: ahorra muchas líneas de código y simplifica el flujo de la aplicación, ya que recoge valores de forma automática y los pinta, también, instantáneamente.

Sin embargo, en mi opinión, recomiendo evitarla si se puede, ya que según va evolucionando una aplicación y requiere que se hagan acciones cada vez más complejas, hay momentos en los que no funciona como se esperaba (a veces es mejor tener el control absoluto de qué pasa y cuándo, a costa de perder esta simplificación automática del proceso).

Vista esta propiedad, vamos a comenzar hablando del Dropdown box.

Dropdown box

Es un elemento que permite al usuario escoger un valor de una lista.

• Cuando un dropdown está inactivo, solo muestra un valor.
• Cuando es activado (pulsado sobre él), muestra un listado de valores, entre los cuales el usuario ha de seleccionar uno de ellos.
• Cuando el usuario selecciona un nuevo valor, el control vuelve a su estado inactivo, mostrando únicamente el valor seleccionado.

Dropdown inactivo

Dropdown activo

¿Y cómo se construye ese listado de valores que pueden escogerse? Pues puede ser manualmente, introduciendo uno a uno cada elemento, o usando la propiedad “binding”, que hemos explicado anteriormente.

Crear listado de valores manualmente

Propiedad Binding

Caso práctico

Hemos escogido que van a poder seleccionarse todos los valores de la característica mes existentes en el Datasource de alias DS_1. También se nos da la opción de qué hacer en el destino, es decir, podemos decidir qué va a poder pasar con estas selecciones.

Por defecto se nos sugiere hacer un filtrado. Por ello, hemos seleccionado que con la opción escogida se va a realizar un filtrado en la característica mes en el Datasource de alias DS_2.

Ya tenemos un Dropdown con un array de elementos listo para poder ser usado. Pero, ahora mismo, si se selecciona algún elemento de la lista no pasará nada (ya hemos visto que si se usa el Binding, sí).

¿Cómo pueden crearse sentencias que desencadenen acciones y dónde se programan?

Podremos crear sentencias que desencadenen acciones gracias al lenguaje de programación específico para SAP Design Studio denominado BIAL. Este lenguaje, puede programarse en cada uno de los eventos de los componentes.

Por medio de este lenguaje de programación, puede darse la profundidad necesaria a cada una de las aplicaciones de Design Studio.

Con todo esto, ya podemos utilizar el componente Dropdown box en los cuadros de mando de nuestras aplicaciones SAP Design Studio.

En el anterior artículo Archivado en SAP: Introducción y preparación previa (1 / 3) se habló de los pasos previos que debemos dar para poder archivar y posteriormente visualizar esa información archivada.

En esta ocasión veremos cuáles son los 3 pasos que debemos seguir para guardar y eliminar la información:

• Paso 1: Planificación de borrado. Activa los indicadores de borrado.
• Paso 2: Archivado. Guarda los registros en un fichero.
• Paso 3: Elimina los registros archivados.

Debemos tener en cuenta que antes del archivado en SAP existen unas parametrizaciones previas, que pueden hacer variar el tiempo que se tarda en archivar y las formas en las que se archiva la información.

Planificación de borrado

En la transacción SARA ->

La función de este primer paso es la de activar los indicadores de borrado de los registros que deseamos archivar.

Es necesario crear una variante para ejecutar la planificación. Introducimos un nuevo nombre para la variante y la creamos.

En ella se detallarán los documentos que se quieran archivar .

El siguiente paso es elegir el momento de iniciar el proceso, para ello pulsamos .

Aquí elegiremos si queremos ejecutar el proceso de manera inmediata o programarlo para un momento concreto.

Ejecutamos y miramos en el job si se ha realizado correctamente .

Archivado en SAP

Los registros SAP elegidos para archivar se escribirán en el fichero previamente seleccionado.

Debemos crear otra variante que deberá contener los mismos registros que hemos introducido en el paso de planificación de borrado, ya que son los que tienen el indicador de borrado activado .

Si no queremos archivar los registros, pero queremos hacer una simulación para ver que en caso de hacerlo no ocurrirán errores, activaremos el modo test.

En caso de querer llevar a cabo el archivado, deberá estar marcado el modo productivo.

Tras esto, realizamos los mismos pasos realizados durante la planificación de borrado para la Fecha inicio.

Ejecutamos y miramos en el job si se ha realizado correctamente .

Borrado de registros archivados

Los registros archivados en el paso anterior serán eliminados de la base de datos de manera permanente.

De nuevo, podemos seleccionar la pestaña modo test, para simular el borrado de registros archivados en SAP para ver como iría el proceso, sin llegar a eliminar de la base de datos.

Seleccionar el archivo a borrar

Seleccionamos el fichero que archivamos, y esté será el que le indique a SAP cuales son los registros que debe eliminar.

De nuevo, realizamos los mismos pasos realizados durante la planificación para la ‘Fecha inicio’ y el parámetro de spool.

Con todo actualizado Ejecutamos  y miramos en el job si se han borrado los registros .

Llegados a este punto, la orden ya está archivada y eliminada de la base de datos.

Con solo 3 pasos ya somos capaces de realizar una planificación, archivado y borrado de registros en SAP. En la última parte del artículo ‘Archivado en SAP’, explicaremos cómo leer la información directamente desde el archivo.

En el siguiente artículo veremos cómo filtrar el contenido de los usuarios de SAP Portal por desktop.

Este contenido se asigna a los diferentes usuarios usando roles de portal, es algo bastante intuitivo y eficiente a la hora de gestionar permisos y perfiles de usuario en SAP, esta técnica puede derivar en una situación algo incómoda.

Hay veces que un usuario con diferentes roles, al acceder al portal se encuentra con un montón de ítems de diferente naturaleza en su menú (Top Level Navigation) del portal de SAP.

Esos ítems se corresponderán con los Entry Points o puntos de acceso definidos en los diferentes roles de portal que tenga asignado.

Sin ir más lejos, esta situación puede darse cuando un usuario con permisos de administración (content_admin_role, user_admin_role, system_admin_role…) tiene también asignados roles de negocio.

¿Cómo podemos solventar esta situación y permitir a un mismo usuario acceder al portal de SAP utilizando distintas perspectivas que le permitan ver en cada caso el grupo de ítems deseado?

El término clave para dar con la respuesta a la pregunta anterior es Filter ID, y es que SAP Portal nos permite filtrar el contenido por Desktop utilizando un identificador común entre diferentes Desktops y puntos de acceso, de manera que sólo serán mostrados los Entry Points cuyo ID de filtro coincida con el del propio Desktop.

Activación del filtrado por Desktop

Esta funcionalidad, ha de ser activada previamente desde el SAP Netweaver Administrator (nwa) de SAP Portal. Concretamente es necesario activar y configurar el siguiente módulo de portal:

La propiedad anterior acepta 3 posibles valores:

• 0 – Filtrado desactivado: Independientemente del Desktop se mostrarán todos los puntos de acceso habilitados en los roles que el usuario tenga asignados.
• 1 – Filtrado activado: Cuando no existan coincidencias se mostrarán todos los puntos de acceso habilitados en los roles que el usuario tenga asignados.
• 2 – Filtrado activado: Cuando no existan coincidencias se mostrarán todos los puntos de acceso que tengan un Filter ID.

Por lo general, estableceremos el valor 1 para activar el filtrado de contenido por Desktop.

Para continuar la explicación, seguiremos con el ejemplo de un usuario de portal SAP con roles de administración y con roles de negocio.

ID de filtro en los Desktops

Para que este usuario pueda acceder de manera diferenciada a cada tipo de contenido crearemos dos Desktops diferentes:

• Desktop A (Filter ID – Administration): Copia del Desktop AFP estándar de SAP donde visualizará el contenido relacionado con administración de contenido, usuarios y sistemas del portal.
• Desktop B (Filter ID – fiori): Copia del Desktop FLP estándar de SAP donde visualizará un Fiori Launchpad con los distintos iviews de negocio.

ID de filtro en Desktop A

ID de filtro en Desktop B

Para poder acceder a cada uno de los Desktop se crearán los correspondientes alias y reglas.

ID de filtro en los Entry Points

Una vez definidos los IDs de filtro en cada Desktop asignaremos contenido a cada uno estableciendo el correspondiente Filter ID a los Entry Points de los distintos roles.

El contenido de administración será mostrado en el Desktop A, por tanto, los Entry Points que queramos visualizar deberán llevar ID de filtro “Administration”.

En cambio, el contenido de negocio que queramos mostrar en el Desktop B, deberá llevar el ID de filtro “fiori”.

Con estos 3 pasos, este usuario del que hemos ido hablando a lo largo del artículo podrá acceder de manera diferenciada, por un lado, al Desktop A para realizar tareas de administración del portal de SAP:

Y cuando, en cambio, quiera acceder al contenido negocio, accederá al Desktop B en el que sólo verá el contenido buscado.

Tras los artículos “Cuadros de mando”, “Crosstab y chart” y “Dropdown box y binding” sabemos que SAP Design Studio es una herramienta enfocada en la creación de cuadros de mando, con un gran número de componentes. Que éstos tienen eventos activados por el usuario y que desencadenan una serie de acciones.

¿Pero qué lenguaje de programación es usado en Design Studio para crear estas acciones? El denominado SAP BI Action Language (BIAL).

SAP BI Action Language

SAP BIAL es un subconjunto de Javascript/ECMAScript. Es muy similar a cualquier lenguaje de programación orientado a objetos, consistente en objetos, métodos y propiedades, que son ejecutados en función a eventos.

La ejecución de cada uno de los scripts se realiza en el momento que el usuario interactúa con el componente. Cada componente tiene una serie de uno o más eventos que son mostrados en su ventana de propiedades.

Los eventos más comunes suelen ser “On Select” y “On click”. Como excepción, hay cuatro eventos especiales en BIAL que no pertenecen a los componentes, si no a la aplicación en sí.

• On Variable Initialization: En la inicialización de variables.
• On startup: En el inicio de la aplicación.
• On Background Processing: En background, este evento es llamado mediante código de programación.
• On Before Prompts Submit: Una vez que el usuario introduce los valores iniciales en la pantalla de selección.

Sintaxis de las sentencias de llamada

Las sentencias ejecutan el método de un objeto, y tienen la siguiente sintaxis:

<componente>.<método>(<argumentos>)

• <componente> es el nombre del alias de un Datasource o del componente en la aplicación, por ejemplo “DS_1” o “Button_1”.
• <método> es la operación que se va a ejecutar al componente que tiene a su izquierda. Los métodos disponibles dependen del tipo de componente. Los alias de Datasources, por ejemplo, contienen funciones para filtrar datos, y los componentes visuales (como gráficos, iconos, etc) contienen funciones para modificar la visibilidad (si se muestra), si está activo o no, etc.
• <argumentos> es una lista de expresiones separada por comas, que son pasados al método. Los argumentos pasados deben cumplir los requerimientos del método.

Cada sentencia finaliza con punto y coma (“;”).

Sentencias condicionales en BIAL

BIAL también permite sentencias de condición (if) y en cada versión de Design Studio se van añadiendo nuevas funcionalidades, por lo que cada vez es más completo.

Por ejemplo, en la versión 1.3 de Design Studio introdujeron por primera vez los arrays, y en la 1.6 añadieron los métodos “pop” y “push”.

El conocimiento y uso de ciertas sentencias de programación en BI Action Language es básico para ofrecer cierta navegación en el Cuadro de Mando. Gracias a la posibilidad de programar líneas de código, podemos llegar a alcanzar una inmensa profundidad de desarrollo en los mismos.

Ahora ya podemos decir que sabemos algo más sobre BIAL, el lenguaje de programación que utiliza SAP Design Studio.

En el siguiente artículo se exponen las principales razones por las cuales deberíamos considerar como importante el Solution Manager.

Esta plataforma es la solución estándar de SAP para llevar a cabo una monitorización al detalle de los sistemas de éste, siendo el pilar en que se apoya el mantenimiento exitoso de los mismos.

Por ello, no debería sorprendernos que sea uno de los aspectos más críticos y que más atención merece en las implementaciones y mantenimiento de los sistemas de gestión SAP.

SAP Solution Manager

SAP Solution Manager, si bien no deja de ser una maquina técnica que en principio es invisible para los usuarios de negocio, cuenta con una serie de prestaciones y capacidades que, bien utilizadas, la convierten en uno de los sistemas más importantes de la empresa.

Respecto a novedades, en julio de 2016 SAP liberó la versión 7.2 dando de plazo para migrar a la versión 7.1 hasta el 31 de diciembre de 2017.

Son muchas las razones por las que nosotros recomendamos migrar a la nueva versión, pero a continuación exponemos las que a nuestro parecer son las más significativas:

Experiencia de usuario mejorada a través de SAP Fiori

La última versión incorpora Fiori Launchpad, que proporciona una interfaz gráfica e intuitiva que reemplaza a los workcenters de la versión anterior.

Los cuadros de mando (dashboards) para el control de indicadores se han migrado de Adobe Flash a HTML5 . Ya es posible visualizarlo en cualquier dispositivo sin necesidad de aplicaciones adicionales.

Monitorización en SAP Solution Manager

En la nueva versión, se ha ampliado la gama de dashboards para la monitorización de indicadores relacionados con:

• Seguridad
• Incidentes
• Disponibilidad
• Rendimiento del sistema
• Otros aspectos críticos para la correcta operatividad de los sistemas

Con la nueva versión tenemos la posibilidad de crear dashboards a la medida del cliente de forma sencilla, mediante plantillas predefinidas. Esto incluye paneles para monitorizar no sólo métricas técnicas sino métricas de negocio.

Vemos pues que, con la nueva versión, Solution Manager ha salido del armario de sistemas para entrar en la lógica del negocio y en aspectos más relacionados con el día a día de los usuarios.

Gestión de Procesos de Negocio

SAP ha renovado completamente la funcionalidad de Business Process Management. En esta nueva versión, se ha introducido una herramienta gráfica de modelado de procesos empresariales basada en el estándar BPMN 2.0.

Esto supone una mejora significativa en la comunicación entre las áreas de Negocio e Informática, al proporcionar una visualización intuitiva de los procesos de la empresa.

Soporte en Solution Manager

Soporte en sistemas híbridos

Debido a que el alojamiento de entornos y servicios en la nube es un fenómeno al alza, Solution Manager 7.2 está pensado para dar soporte a sistemas en la nube, como puede ser el caso de SuccessFactors.

Soporte implementación de HANA y S/4HANA

La versión 7.2 esta optimizada para gestionar sistemas basados en HANA y S/4HANA. Además, también cabe la posibilidad de hacer la instalación directamente en HANA.

Conclusión

En resumen, se puede decir que SAP ha transformado el Solution Manager en algo más que una herramienta de soporte, mejorando la parte funcional para ser una herramienta esencial para el negocio.

Las mejoras incluidas en 7.2 simplifican el mantenimiento y la creación de procesos de negocio, abarcando desde la documentación de la solución a la gestión del cambio.

Más allá del lado funcional, el lado técnico también ha sido actualizado, incluyendo mejoras en la interfaz de usuario gracias a SAPUI5 y Fiori.

Y no hay que olvidar la inclusión de SAP HANA en la licencia para Solution Manager 7.2.

Ahora, cualquiera puede ejecutar Solution Manager 7.2 en SAP HANA sin el costo de la licencia.

Una vez conocida la importancia de SAP Solution Manager 7.2, podemos empezar a hacer uso de todas sus ventajas.

En este último artículo hablaremos de los distintos métodos de lectura de la información archivada en SAP y aprenderemos cómo leer los ficheros archivados.

La información archivada en SAP debe ser accesible para su lectura. Para acceder a dicha información, se utilizan las siguientes herramientas:

• La propia transacción SARA
• Archive explorer
• Navegador de ficheros archivados

Leer ficheros archivados desde la transacción SARA

SARA ->

Nos da la posibilidad de insertar el documento archivado que queramos mostrar.

Seleccionamos el fichero.

Archive explorer

Otra opción para visualizarlo es:

SARA -> Sistema de información  -> Archive Explorer

SARI -> Archive Explorer

En el sistema de información de archivos, se nos permite utilizar la estructura info archivo. La configuración de dicha información se explicaba en el primero de los artículos; “Archivado en SAP: Introducción y preparación previa” artículos dedicados al archivado en SAP para la posterior visualización de los registros.

Para poder acceder a la información, la infoestructura debe estar rellenada. Ésta se rellena automáticamente durante la fase de borrado, o más adelante de forma manual activandola otra vez.

En el explorador de archivos además de dar la opción de seleccionar el documento a mostrar, también se ofrece múltiples opciones de filtrado.

Al hacer doble click sobre uno de los documentos de ventas nos dará las siguientes opciones de visualización.

De los mostrados hablaremos más en detalle del Documento venta y del DRB: Pedido SD.

Documento venta

Si elegimos esta opción mostrará el documento tal y como lo mostraba la transacción original en la que se visualizaba.

También es posible acudir a la transacción original e introducir el número del documento.

En ambos casos, mostrará en la esquina inferior izquierda de la pantalla, un mensaje declarando que el documento que se busca ya no existe en la base de datos y puede que esté archivado.

DRB: Pedido SD

El DRB se utiliza para mostrar objetos de negocio y los enlaces o relaciones entre ellos.

Por lo general, estos documentos fueron creados como parte de un proceso de negocio o forman parte de un proceso de negocio común.

DRB puede mostrar datos archivados y también datos dentro de la base de datos.

Archive File Browser (Navegador de ficheros archivados)

Por último, hablamos del navegador de ficheros de archivos (transacción AS_AFB), que muestra una vista técnica de tablas archivadas, como el Navegador de Datos (transacción SE16) lo hace para los datos de la base de datos.

El navegador de ficheros archivados, es particularmente útil para alguien que esté buscando problemas que hayan podido ocurrir durante el archivado o para aquellos que quieran buscar ficheros archivados.

Con este artículo sobre cómo leer ficheros archivados, ponemos fin a la serie de artículos que nos ha mostrado paso por paso como realizar un archivado en SAP de la base de datos.

A estas alturas todos hemos oído hablar de SAP S/4 HANA y de sus ventajas sobre el ERP tradicional. Estas ventajas o cambios quedan recogidos en la lista de simplificación (Simplification List en inglés).

Por eso, antes de plantearnos una migración o una nueva implantación en SAP S/4 HANA necesitamos comprobar este documento para saber en detalle lo que cambia dentro del sistema con respecto a versiones anteriores del ERP.

¿Qué es la lista de simplificación de SAP HANA?

La lista de simplificación es un documento publicado por SAP para cada versión de SAP S/4 HANA, detallando las novedades de dicha versión con respecto al ERP tradicional y/o a otras versiones anteriores.

En otras palabras, es una agrupación de objetos de simplificación pertenecientes a las diferentes áreas de aplicación o áreas funcionales, en el que uno debería basarse para la mayor parte de la fase de preparación antes de comenzar un proceso de implantación o migración de SAP S/4 HANA.

La estructura de la lista de simplificación es muy sencilla; cada objeto de simplificación consta de una estructura fija que incluye:

• Descripción: Pequeña explicación acerca de los cambios técnicos existentes, así como área de aplicación/funcional a la que pertenece.
• Información relacionada con el proceso de negocio: Explicación de la incidencia del objeto de simplificación en el proceso de negocio.
• Recomendaciones: En el caso de existir código propio dentro del ámbito de aplicación, se detalla cómo adaptarlo (basado en notas de SAP).
• Notas de SAP: Pueden detallar comprobaciones previas a realizar o los procesos de adaptación del código de cliente. Esta estructura es, a veces, ampliada dependiendo de la complejidad del proceso.

Categorías de simplificación

Dependiendo del impacto, los objetos de simplificación pueden ser categorizados en tres tipos:

• Funcionalidades rediseñadas para la plataforma in-memory SAP HANA: Hay muchas funcionalidades nuevas que aprovechan toda la capacidad que ofrece la base de datos SAP HANA.
• Consolidación de funcionalidades existentes: Funcionalidades que han sido optimizadas y/o unificadas para mejorar su eficiencia, pero que en esencia funcionan igual.
• Sin equivalente funcional: Es posible que existan funcionalidades disponibles en el ERP tradicional, que no lo estén para SAP S/4 HANA. Esto es así porque SAP S/4 HANA no se considera un sucesor legal del ERP tradicional. En cualquier caso, funcionalidades alternativas están a menudo contempladas o previstas.

La lista de simplificación 1610

La última versión de SAP S/4 HANA que existe en la actualidad es la 1610 (16 – 2016, 10 – Octubre) con su correspondiente lista de simplificación. Como es habitual con la documentación de SAP, sólo está disponible en inglés.

Documentación de la lista de siplificación en formato PDF

Documentación SAP S/4 HANA, lista de simplificación en formato pdf.

Documentación de la lista de siplificación en formato XLS

Incluido como datos adjuntos en la nota 2313884.

Como ejemplos destacados de funciones empresariales representativas de la lista de simplificación 1610 se pueden destacar:

• El nuevo sistema de Interlocutores comerciales (Business Partners). Nota de impacto de negocio: 2265093.
• Extensión de la longitud del campo de material. Nota de impacto de negocio: 2267140.

Conclusión

En definitiva, la lista de simplificación es el documento de referencia en el que basarse para preparar una implantación en SAP S/4 HANA, donde se describen, para cada versión del sistema, todas las novedades con incidencia en el negocio.

Una vez comprobado este documento, podemos decidir si realizar una migración o una nueva implantación conociendo todas sus ventajas y cambios respecto a versiones anteriores.

Con el siguiente artículo aprenderás a definir la asignación de una clase de gasto a un cc-nómina en SAP.

Una vez tenemos parametrizadas las diferentes clases de gastos, éstas deben ser asignadas a un cc-nómina para su correcto funcionamiento (independientemente de si se procesan las hojas de gasto en nómina o no).

Para ello accederemos al siguiente punto de parametrización:

Por una parte parametrizaremos la relación clase de gasto-cc-nómina; y por otra las dietas a su correspondiente cc-nómina.

Clase de gasto – CC-nómina

A nivel de clase de gasto podemos definir si se utiliza únicamente un cc-nómina para todo el importe; o si necesitamos dividirlo en dos (parte exenta, parte sujeta):

Dieta – CC-nómina

Si se utilizan dietas estándar deberemos parametrizar por cada dieta utilizada está asignación para el correcto funcionamiento de reembolso de importes automáticos.

Las dietas estándar van asociadas a clases de gasto específicas de SAP:

Una vez elegida la dieta deseada, se parametriza de la misma manera que las clases de gastos, pudiendo definir uno o dos conceptos de nómina:

Con los conocimientos adquiridos mediante este artículo, podremos definir la asginación de una clase de gasto a un CC-nómina en SAP.

Al hilo del artículo anterior  ‘¿Por qué debería importarte SAP Solution Manager 7.2?‘ hoy daremos nuestra opinión acerca de qué nos parece más adecuado, si hacer upgrade del Solution Manager anterior o re-implementarlo.

Cuando la versión 7.1 fue liberada, también nos hicimos esta misma pregunta y, teniendo en cuenta la dificultad de las migraciones en ese momento y el poco uso que se le daba a la versión 7.0, el consejo general era re-implementar Solution Manager 7.1 desde cero.

Migración del solution manager a HANA

Si bien con la versión 7.2 la pregunta se vuelve a poner sobre la mesa, las circunstancias son diferentes. El caso es que buena parte de los clientes sí que han venido explotando la funcionalidad de la versión anterior del Solution Manager, y existe una natural reticencia a perder todo el trabajo dedicado hasta ahora.

SAP es consciente de esta situación y por eso ha diseñado una ruta de actualización que incluso permite la migración de la base de datos a HANA como parte del proceso.

Recordemos que SAP permite migrar el Solution Manager a HANA sin coste de licencia para ir familiarizándose con la nueva base de datos. Esta ruta de migración está recomendada también para reducir el impacto en los procesos de negocio, de modo que para el usuario esta migración sea transparente.

Independientemente de que opción elegir, hay que comentar que la nueva versión está actualizada a la última tecnología y divide la pila JAVA y la pila ABAP para un mejor funcionamiento.

Además, los componentes CRM y PPM también se actualizan a la última versión de EHP y versión respectivamente.

Conclusiones sobre la actualización de SAP Solution Manager a 7.2

Con el fin de facilitar el cambio a la versión 7.2, SAP ha diseñado varios servicios de actualización.

En resumen, tal como gestiona SAP la actualización a la nueva versión 7.2, lo más recomendable para un sistema donde los sistemas se monitorizan, se generan EWAs y se controlan los procesos de negocio, lo adecuado es actualizar.

Sin embargo, si el cliente solo utiliza el Solution Manager para lo mínimo, como es sacar el XML necesario para actualizar los sistemas satélites, nuestra recomendación es hacer una implementación nueva y limpia.

Como en todas las actualizaciones, habrá que realizar tareas después para asegurar la estabilidad del sistema que variará en función de la utilización que se le haya dado a la versión anterior.

Lo que sí está claro es que el mantenimiento de Solution Manager 7.1 termina a finales de 2017, por lo que la planificación de pasar a la versión 7.2 tiene que afrontarse seriamente en un futuro próximo.

Dicho esto, ahora está en vuestras manos decidir si actualizar o re-implementar Solution Manager. ¿Qué es lo mejor para tu negocio?

¿Cuántas veces te ha sucedido que necesitas saber si existe una nota que solucione el error que se esta produciendo en tu sistema SAP R/3?

Descubre en este artículo la herramienta que ofrece SAP, mediante la transacción ANST, para detectar entre otras cosas, la nota o notas de corrección SAP no instaladas en el sistema que te ayudarán a solucionar un problema determinado.

Herramienta de correción SAP

Imaginemos que surge un error en una transacción estandar, esta herramienta que proporciona SAP, ofrece la posibilidad de lanzar la transacción y analizar la ejecución para localizar cuáles son las notas que faltan de instalar en el sistema SAP R/3.

Una vez analizada la ejecución se visualiza una lista con los objetos de workbench clasificados por componente de aplicación, en la que se deben seleccionar los componentes y áreas de aplicación que se desean analizar.

Ejemplo de lista

• Cálculo de nómina (Payroll)
• Finanzas (Finance)
• Logística (Logistics)
• Base

Algunas veces, resulta imposible determinar de forma unívoca los componentes que causan un problema. En este caso, se pueden seleccionar varios componentes.

También puede suceder que se exploren notas para un componente determinado y que, por ello, se obtengan notas para otro componente. Esto puede suceder porque el componente de nota SAP no siempre es idéntico con el componente de los objetos que se corrigen en la nota.

Ejecución de la transacción ANST

A continuación, se muestra paso por paso como realizar una ejecución con la transacción ANST para detectar las notas que no estan implemetadas en tu sistema.

Imaginemos que tenemos un error en una transacción estándar o que se necesita actualizar alguna transacción dado que se han producido modificaciones legales.

En este caso, se necesita actualizar la generación del Certificado de Retenciones dado que los cambios legales han provocado cambios en el mismo.

Se carga la transacción ANST.

Introducir la transacción “PC00_M04_C11X” y darle una descripción a la ejecución.

Ejecutar la transacción para reproducir el error que se esta produciendo o como en este caso, para visualizar el formulario que se desea actualizar.

Una vez ejecutado, pulsar botón hacia atrás “F3” hasta llegar a la transacción ANST.

Seleccionar los componentes que se quieren analizar y pulsar “Búsqueda de nota”

Se mostrarán las notas relacionadas con la ejecución que estan publicadas por SAP y no estan instaladas en el sistema.

Esta transacción ofrece multiples posibilidades, por ejemplo, visualizar las tablas de parametrización que influyen en la ejecución.

Para ello, se deben seleccionar los componentes y áreas de aplicación que se desean analizar y pulsar sobre el botón “Tablas Customizing”.

Se mostraran las tablas de parametrización clasificadas en componentes.

De esta manera, ya sabes como detectar las notas no instaladas en tu sistema R/3 para solucionar cualquier error que éste pueda producir.

Cuando accedemos a un infotipo de SAP PA, podemos comprobar quién y cuándo ha realizado la última modificación de los datos de un empleado.

Pero en ocasiones, podría sernos de mayor utilidad disponer de un historial de modificaciones completo. En este artículo se detallan las herramientas que SAP pone a nuestra disposición para disponer de un log de modificaciones de los infotipos SAP PA.

Para ello SAP nos proporciona algunas herramientas, como el report RPUAUD00, que podremos utilizar tras una sencilla parametrización.

Parametrización SAP

Accedemos a la ruta:

Gestión de personal → Gestión de personal → Herramientas → Revisión → Definir documento de modificación

La parametrización se divide en tres puntos, donde indicaremos para qué infotipos y campos queremos guardar el historial.

Infotipos relevantes p.documento

Indicaremos los infotipos relevantes para mostrarse en el log.

Definición de grupos de campos

Por cada infotipo guardado anteriormente, se indican los campos para los que se quieran guardar las modificaciones. Cada uno de ellos, debe ir asignado a un grupo. Lo que implica, que cuando un campo sufra una modificación, el log de modificaciones  SAP mostrará todos los campos que pertenezcan al mismo grupo.

Propiedades grupos campos

Por último, por cada uno de los grupos de campos e infotipos definidos en los pasos anteriores, indicamos el protocolo. Pudiendo ser estos:

• L: protocolo a largo plazo
• S: protocolo a corto plazo

Los protocolos a largo plazo están clasificados por número de personal e infotipo. Por tanto, elegiremos esta opción si lo que queremos es identificar quién y en qué momento ha realizado una modificación, creando, borrando o modificando un registro de uno de los infotipos marcados.

Los protocolos a corto plazo están clasificados según la ultima fecha de modificación. Se utilizan para evaluar datos con otros sistemas externos a SAP.

A partir de aquí, por cada modificación realizada sobre los infotipos y/o campos indicados en la parametrización, se creará un registro de modificación en base de datos.

Los cuales podremos consultar posteriormente mediante el report RPUAUD00, al que también podemos acceder desde el menú de SAP:

Recursos Humanos → Gestión de personal → Gestión → Sistemas de información → Informes → Documentos → Modific.infotipo → Modificaciones registradas en log en los datos de los infotipos

Utilizaremos la pantalla de selección del report para poder filtrar el log de modificaciones SAP y ver las modificaciones en un periodo o día concreto; Por empleado, infotipo, fecha y/o usuario de la modificación, protocolo a largo o corto plazo, etc.

Haciendo doble click en cada uno de los registros, veremos en detalle los datos de las modificaciones.

Éstos nos muestran entre otros datos, los valores anteriores y los nuevos por cada campo del grupo en el que haya habido una modificación.

A partir de ahora no tendrás ningún problema para obtener el historial completo de modificaciones de un infotipo PA.

En muchas ocasiones, cuando queremos imprimir cierta información como listados, informes o formularios, recurrimos a las órdenes SPOOL de SAP.

Dependiendo del tipo de información o más bien de su formato, se generan distintos tipos de órdenes que podemos tratar desde la transacción SP01.

En este artículo vamos a ver cómo agrupar en una sola orden, el contenido de otras ya existentes.

Órdenes de tipo ADSP en SAP

En nuestro caso, trabajaremos con órdenes de tipo ADSP, es decir PDF. Con esto, obtendremos una nueva orden SAP con tantas partes como órdenes se hayan agrupado.

Para crear la nueva orden, utilizaremos la función ADS_SR_OPEN, pasándole como parámetro obligatorio el tipo de orden que queremos crear (LIST, OTF, SMART, ADSP…).

Podemos indicar también distintas propiedades de la orden de SAP:

• Dispositivo de salida,
• El número de copias
• Salida inmediata
• Borrar tras imprimir
• …

Utilizaremos también la función ADS_GET_PATH para obtener la ruta del servidor donde almacenaremos el contenido de esta nueva orden de spool creada.

Pasamos ahora a tratar todas aquellas órdenes que queramos agrupar. Por cada una de ellas, seguiremos el siguiente proceso:

ADS_SR_READ_CONTENT_DIR

Obtenemos un listado con todas las partes que conforman el contenido de la orden. Por ejemplo, si el número de la orden es el 7974, la función nos devolverá una tabla interna con las siguientes entradas:

TRINT_FILE_GET_EXTENSION y ADS_SR_READ_CONTENT

Obtenemos la extensión y el contenido de cada una de las partes obtenidas anteriormente.

El siguiente paso será conformar el nombre de cada una de dichas partes para que puedan posteriormente formar parte de la nueva orden creada. Por ejemplo, si el número de la nueva orden es el 7979, las partes obtenidas de la orden 7974 deberán quedar de la siguiente forma:

• SPOOL0000007979_00001.cfg
• SPOOL0000007979_00001.pdf
• SPOOL0000007979_00001.xfd

Por cada orden a agrupar, incrementaremos el número de la parte, es decir:

• SPOOL0000007979_00002.cfg
• SPOOL0000007979_00002.pdf
• SPOOL0000007979_00002.xfd

OPEN DATASET, TRANSFER y CLOSE DATASET

Una vez conformado el nombre de cada parte, las iremos dejando junto con su contenido en la ruta del servidor obtenida anteriormente.

ADS_SR_CONFIRM_MULT

Cuando hayamos tratado todas las partes de la orden, escribiremos en la nueva orden aquellas partes que queramos que se visualicen desde la SP01. También podemos utilizar la función ADS_SR_CONFIRM e ir escribiéndolas una a una.

ADS_SR_CLOS

Por último y una vez tratada cada orden que queramos agrupar, cerraremos la nueva orden creada.

A parte de las ya citadas, podemos utilizar también las siguientes funciones:

GET_PRINT_PARAMETERS

Obtiene, entre otros, el nombre del dispositivo de salida asignado al usuario que ejecuta el programa. Este dato se utiliza para crear la nueva orden en la función ADS_SR_OPEN.

FPCOMP_CREATE_PDF_FROM_SPOOL

Pasándole como parámetros el número y parte de una orden, devuelve las propiedades (contenido y número de páginas) de dicha parte. Podemos utilizar el número de páginas en la función ADS_SR_CONFIRM.

Tras este artículo ya tenemos los conocimientos necesarios para agrupar las órdenes SPOOL de SAP.

En los artículos ‘¿Por qué debería importarme el SAP Solution Manager?‘ y ‘Solution Manager: ¿Actualizar o re-implementar?’ se hablaba de aspectos destacables de esta plataforma.

En el artículo de hoy, dejamos un vídeo del Webinar impartido el pasado 4 de mayo, en el que hablamos sobre Solution Manager 7.2.

¿Qué es SAP Solution Manager?

Como venimos comentando a lo largo de los últimos artículos publicados sobre Solution Manager, está es la plataforma estandar que proporciona SAP para la monitorización de todos sus sistemas. Es por esto precisamente, por lo que es tan importante para llevar a cabo implementaciones y mantenimientos de todos los sistemas de gestión SAP.

Además, cuenta con unas prestaciones y capacidades que pueden resultar muy útiles en la gestión general de una empresa.

Resumen Webinar SAP S0lution Manager 7.2

En el webinar que se presenta, hablamos sobre todos los cambios introducidos en la nueva versión liberada a finales del pasado 2016, y hacemos una pequeña demostración de un sistema de monitorización y alertas.

• Principales cambios en la nueva versión.
• Mejores prácticas de migración o actualización.
• Pasos generales de configuración.
• Demo sistema de alertas y monitorización.
• Presentación de paquete de migración desarrollado por Oreka IT.

Además, os damos unas cuantas razones para actualizar y las claves para saber cómo  hacerlo.

Esperamos que os guste y os sea de utilidad.

En este artículo se hace un pequeño repaso de qué es Success Factors en SAP y cómo funciona.

Success Factors fue fundado en 2001 por Lars Dalgaard, como un software para la gestión del talento del empleado y fue adquirido por SAP en 2012.

Sigue leyendo si quieres saber cuáles son sus pricipales componentes.

Success Factors cubre prácticamente todos los procesos de Recursos Humanos en la nube (Cloud), mediante Data Centers localizados globalmente, que permiten almacenar y gestionar toda la información.

Mediante este sistema en la nube, permite que varios clientes compartan infraestructuras, bases de datos, aplicaciones…aunque cada uno disponga de sus propias instancias.

Todo ello, dotado de movilidad y permitiendo consumir las aplicaciones en entornos multidispositivo y multiplataforma.

Success Factor, principales compoenentes

A continuación, se especifican los componentes de Success Factor.

Núcleo HR

• Employee Central: Núcleo central donde almacenamos todo lo referente a los datos maestros de los empleados y la estructura organizativa. Aquí ha cambiado la estructura tal y como la conocíamos en OM. Nos encontramos con nuevos conceptos de estructura organizativa, salarial y de puesto.
• Employee Central Payroll: Ofrece las mismas características que la nómina On-Premise, pero vía solución en la nube, con un formato seguro, escalable y flexible.

Soluciones de talento con Success Factor

• Recruiting: Te guía por cada una de las fases de tus procesos de selección, asegurando a los reclutadores contratar a los mejores talentos de manera rápida.
• Onboarding: Ayuda a convertir las nuevas contrataciones en empleados comprometidos, motivados y productivos.
• Learning: Mejora las habilidades de tus empleados, creando una cultura del conocimiento con un enfoque flexible y abierto.
• Performance & Goals: Mejora el proceso de evaluación, de una manera continuada y aumenta el compromiso de los empleados.
• Compensation: Premia el rendimiento con un presupuesto optimizado y asegura la retención del talento.
• Succesion & Development: Ayuda a identificar el talento y ayudarles a desarrollarlo para cubrir futuras necesidades de la compañía.

Soluciones analíticas en Success Factor

• Workforce Analytics: Mejora la toma de decisiones ayudando a las empresas a encontrar respuestas a las preguntas clave y proporciona orientación para ayudar a resolverlas.
• Workforce Planning: Planificación de plantilla, con visión a largo plazo y pronosticando necesidades futuras. Y planificación operacional con demandas a corto plazo y determinando si se necesitan recursos adicionales para cumplir objetivos.

Colaboración social

• SAP Jam: Herramienta colaborativa que permite la interacción entre los miembros de la compañía y con los procesos de negocio.

A continuación, detallamos algunas de sus ventajas respecto a SAP HCM (On-Premise):

• Implementación más rápida
• El trabajo se realiza de manera remota
• Actualizaciones automáticas (trimestralmente)

Pero las diferencias entre Success Factors (Cloud) y SAP HCM R3 (On-Premise) las dejamos para próximos artículos, donde hablaremos de la integración entre ambos sistemas, así como su modo de coexistir en diferentes escenarios.

En este punto, ya podemos considerar a Success Factors como la evolución natural de SAP HCM.

En este artículo, se describen las diferentes opciones que ofrece SAP para realizar la gestión de reconocimientos médicos, de los trabajadores de la empresa en el área de recursos humanos.

Infotipo 0028: Servicios médicos

Este infotipo permite almacenar información y resultados de un determinado reconociendo médico.

Puede especificar distintas clases y áreas de reconocimientos, así como especificar los resultados de los diferentes tipos de reconocimientos.

Componente Medio ambiente, Salud y Seguridad (SAP EH&S)

Este componente ofrece una gestión más extensa en el área de la medicina laboral, permitiendo la planificación y ejecución del reconocimiento preventivo, gestión de campañas de vacunación o cualquier otro tipo de test especifico de la compañía.

Descripción general del proceso:

• Datos básicos: Nos permite especificar los datos necesarios para gestionar los reconocimientos utilizados en su empresa, definiendo y asignando exámenes médicos o protocolos de vigilancia de la salud.

• Planificación de horarios: Nos permite definir qué personas necesitan registrarse para los reconocimientos y planificar las citas para cada uno de ellos.

• Servicio médico: Podemos gestionar y almacenar los datos de los reconocimientos médicos, incluso se pueden importar los resultados desde sistemas externos. Puede gestionar el historial clínico del empleado y realizar actividades de seguimiento.

• Reporte, nos permite el análisis de la información.

Como podéis observar, este componente permite una gestión completa tanto de los reconocimientos médicos, como de los protocolos especiales, para las personas que puedan estar expuestas a agentes nocivos o realicen actividades que supongan un riesgo para su salud.

Una vez visto el artículo, podremos gestionar cada una de las clases y áreas que necesitemos para almacenar la información y los resultados de los reconocimientos médicos de nuestros empleados en SAP. Es decir, sabremos cómo gestionar reconocimientos médicos en SAP.