SAP archivos - Blog de SAP: Actualidad SAP, Business Intelligence, SAP HCM, Abap...

En el diseño SAP se puede especificar que un material se sustituya por otro en un momento determinado. Es en estos casos en los que hablamos de los materiales de reemplazo SAP.

Algunas situaciones en las que se puede dar el reemplazo de materiales en SAP son las siguientes:

Piezas baratas sustituyen a otras piezas más caras.
A partir de algunas fechas, las medidas de seguridad se cambian y es necesario reemplazar materiales.

Estos materiales de reemplazo se pueden realizar tanto en el plan maestro de producción (MPS) como en la planificación de necesidades (MRP).

Existen dos tipos de reemplazo de materiales en SAP, a continuación se describe cada uno de ellos:

1. Reemplazo de materiales simple

Un material a reemplazar se puede sustituir por otro material reemplazante a partir de una fecha determinada en cuanto el stock disponible desde el punto de vista del MRP sea cero.

En el momento que dicho material a reemplazar tenga como stock disponible cero para el cálculo del MRP, la necesidad secundaria para el material a reemplazar se traspasará al material reemplazante. En el caso de que no se disponga cantidad suficiente de stock en el material reemplazante, es este mismo el que se deberá aprovisionar.

Una vez que el material a reemplazar vuelva a contar con stock en el MRP, será este el que se volverá a utilizar.

Modificar el registro de materiales

En el registro de materiales del material a reemplazar se fijará el indicador 1, mientras que en el registro de materiales del material dependiente de reemplazar, el indicador será 3 (paralelo dependiente).

2. Reemplazo de materiales paralelo

Un grupo de materiales se sustituye por otro grupo de materiales. Cuando un componente se queda sin stock (material principal a reemplazar), también debe cambiarse el material dependiente. (L98 – R98 por L99 – R99).

Modificar el registro de materiales

En el registro de materiales del material a reemplazar se fijará el indicador 1, mientras que en el registro de materiales del material dependiente de reemplazar, el indicador será 3 (paralelo dependiente).

Modificar la lista de materiales

En la lista de materiales SAP PP que deseamos tratar, añadimos tanto los materiales reemplazados como los materiales reemplazantes.

Dentro de los detalles de posición de la lista de materiales se define un grupo de materiales reemplazados: y otro grupo de materiales de reemplazo.

En las posiciones de los campos reemplazados, añadiremos un grupo que los identifique:

Y dentro de las posiciones de materiales reemplazantes crearemos también un identificador para el grupo de materiales reemplazantes:

Si deseamos ver el resultado de nuestro reemplazo de materiales podremos seleccionar el botón “InfoEstratSal” y mostrará el listado con los resultados:

En este artículo se va a explicar cómo funciona el programa de SAP RPCS0000 que permite la planificación de la ejecución de programas en paralelo en SAP. Esto lo aplicaremos en posteriores artículos para dividir la ejecución de la nómina SAP en varios jobs.

Mediante el programa SAP RPCS0000 se puede planificar la ejecución en paralelo de ciertos programas relacionados con el cálculo de nómina en SAP.

Por ejemplo, se puede ejecutar la evaluación de tiempos (RPTIME00), repartiendo dicha ejecución en varios jobs en paralelo, de tal forma que se consigue agilizar el proceso de forma muy significativa.

Imaginemos que queremos ejecutar el RPTIME00 en 8 jobs en paralelo para agilizar el proceso. En este caso llevaremos a cabo los siguientes pasos:

Generar una variante de ejecución del RPTIME00, por ejemplo, “TIME EVAL”.
Ejecutar el programa SAP RPCS0000 indicando el programa a ejecutar “RPTIME00”, la variante de ejecución “TIME EVAL”, el número de jobs que se van a generar y el nombre de los jobs.
El programa ejecutará el RPTIME00 con dicha variante y dividirá la ejecución en 8 jobs que se ejecutarán en paralelo agilizando el proceso (es posible visualizar los jobs mediante transacción SM37).
Una vez finalizada la ejecución de los jobs se revisarán los spools para ver los resultados.

En próximos artículos se explicará cómo planificar la nómina utilizando este programa.

En el artículo anterior se indicó cómo funcionaba el programa RPCS0000. En este artículo ampliaremos esa información explicando cómo funciona el programa SAP RPCSC000. Este nuevo programa permite dividir la ejecución de nómina en varios jobs (únicamente la nómina).

El programa SAP RPCSC000 permite ejecutar la nómina de un país en varios jobs en paralelo de tal forma que se agiliza la ejecución del proceso. A diferencia del programa RPCS0000, el programa RPCSC000 sólo sirve para ejecutar en paralelo el programa de cálculo de nómina.

Imaginemos que queremos ejecutar la nómina de España (RPCALCE0) en 3 jobs en paralelo. Para ello, seguiremos los siguientes pasos:

Generar una variante de ejecución del RPCALCE0, por ejemplo, “NOMINA”
Ejecutar el programa RPCSC000 indicando la variante de ejecución “NOMINA”, el número de jobs que se van a generar y el nombre de los jobs.
El programa ejecutará el RPCALCE0 con dicha variante y dividirá la ejecución en 3 jobs que se ejecutarán en paralelo agilizando el proceso (visualizar los jobs mediante transacción SM37)
Una vez finalizada la ejecución paralela de los jobs se revisarán los spools para ver los resultados.

En artículos anteriores comentamos cómo crear una tabla con el UI Element Table de Web Dynpro y diferentes opciones relacionadas con este elemento Web Dynpro Abap.

En esta ocasión, hablaremos sobre los Web Dynpro UI Table Cell Variants, otra opción más para crear diferentes editores de celda en una misma columna de una tabla WD4A.

Cuando creamos una tabla en Web Dynpro, en cada columna hay que elegir un editor (input field, checkbox, link, text view…) por defecto para mostrar o recoger la información.

Si queremos que en una misma columna haya diferentes editores, lo primero será añadir un cell variant a la columna. Para ello, con el botón derecho sobre la columna, le damos a “insertar CELL VARIANT” y elegimos el tipo TableStandardCell.

En las propiedades de este elemento, lo importante es dar una clave de variante. Con esta clave se podrá manejar qué tipo de editor se mostrará en la tabla. Este campos es libre, por lo que podremos escribir cualquier texto.

El siguiente paso será crear un atributo en el nodo de la tabla. A la hora de informar el nodo, este atributo lo rellenaremos con la clave que hayamos indicado en la propiedad si queremos que en esa línea se muestre el editor alternativo, o lo dejaremos vacío si queremos que se muestre el que está por defecto.

Después, en las propiedades de la columna, deberemos hacer binding de la propiedad selectedCellVariant con el atributo que acabamos de crear.

Con ello conseguiremos que las líneas de la tabla que tengan en su atributo VARIANT_KEY la clave “VARIANT” muestren un link to action en vez de un text view.

Siguiendo con el ejemplo anterior, la siguiente imagen muestra como en la segunda línea hemos indicado la clave de la cell variant, para que muestre un link:

Así podremos personalizar mejor nuestras tablas y adaptarlas a requerimientos que pueda tener el programa a la hora de visualizar datos. Se pueden crear tantas variantes de celda como se quiera por columna.

En caso de querer que en varias columnas haya diferentes editores, deberemos crear un atributo por cada columna, para que se diferencien unos de otros.

Las hojas de ruta SAP PP registran las operaciones necesarias para fabricar un producto.

Para cada operación presente en una hoja de ruta SAP PP se especifican diferentes conceptos:

El puesto de trabajo en que se realiza la operación.
Los valores de propuesta que se deben utilizar para calcular las fechas, las capacidades y los costes de fabricación.
Si los costes de una operación se tienen en cuenta en el cálculo del coste.
Los materiales a emplear necesarios para llevar a cabo una operación.
El plan de costes se calcula para cada operación.

Existe la posibilidad de que un mismo producto tenga varias hojas de ruta SAP PP asociadas, ya que un mismo material puede fabricarse con diferentes puestos de trabajo de una misma empresa.

El sistema calcula la cantidad de actividad utilizada con la fórmula del puesto de trabajo y de los valores propuestos de la operación de la hoja de ruta SAP PP.

Esta actividad se valora utilizando las tarifas de la contabilidad de centros de coste o contabilidad de costes por procesos para calcular los costes plan de la operación.

La siguiente figura muestra la conexión existente entre los datos del puesto de trabajo y los datos de la hoja de ruta SAP PP:

Las creaciones de las hojas de ruta SAP PP se realizan obligatoriamente para los parámetros:

Material
Centro

El Grupo de Hojas de ruta se utiliza cuando varias hojas de ruta se quieren agrupar en un mismo número de grupo de hoja. En el caso de no indicar el número de grupo de hoja, automáticamente devolverá un número correlativo.

Para terminar, se indican las rutas para las diferentes operaciones con hojas de ruta SAP PP:

Crear hojas de ruta SAP PP

Logística -> Producción -> Datos maestros -> Hojas de ruta -> Hojas ruta específicas -> Crear CA01

Modificar hojas de ruta SAP PP

Logística -> Producción -> Datos maestros -> Hojas de ruta -> Hojas ruta específicas -> Modificar CA02

Visualizar hojas de ruta SAP PP

Logística -> Producción -> Datos maestros -> Hojas de ruta -> Hojas ruta específicas -> Visualizar CA03

Contribuir con el desarrollo personal y profesional de los empleados tiene una gran importancia para las empresas ya que ayuda a mejorar la productividad y aumentar la rentabilidad de las mismas. El control del desarrollo de personal debe ser un proceso continuo y coherente y por ello existen herramientas que nos ayudan durante el proceso, como el módulo de Desarrollo de Personal de SAP.

Si vuestra empresa ya utiliza SAP, quizá sea el momento de ampliar sus posibilidades y comenzar a usar el módulo de Desarrollo de Personal que SAP ofrece basándose en su larga experiencia.

Si queréis más información, deberéis estar atentos a las siguientes publicaciones ya que a lo largo de esta serie de artículos presentaremos las partes en las que está dividido este módulo.

El módulo de SAP para la gestión del desarrollo de personal en su conjunto, consigue que el sistema gestione todos los conocimientos de los empleados, sus planes de formación y sus carreras profesionales dentro de la empresa. Además, nos permitirá realizar evaluaciones a los empleados, planificando, revisando y evaluando conjuntamente con ellos sus progresos.

Podemos dividir el módulo en cuatro submódulos:

1. Gestión del talento

Permite gestionar y comparar los requisitos de conocimientos de las posiciones de la empresa con las cualificaciones de los empleados, sus preferencias y sus aspiraciones.

2. Sistema de calificación

Las calificaciones permitirán a los responsables evaluar a los miembros de la empresa de forma planificada, formalizada y ajustada. Estas calificaciones se podrán utilizar después para obtener información sobre las características, conducta y rendimiento del personal de la empresa.

3. Planificación de carreras y sucesión

En este componente se elaboran los planes de carrera del personal de la empresa, de forma que se tengan en cuenta las preferencias y objetivos de los mismos en el momento de realizar un plan de sucesión.

4. Planes de desarrollo

En este componente se elaboran planes globales e individuales de desarrollo tanto a corto como a largo plazo. El objetivo es proporcionar una cualificación correcta a los miembros de la empresa, creando un plan de actividades y subactividades que deberán de realizar los empleados para mejorar en su desarrollo personal.

Toda esta funcionalidad estará integrada con el resto de módulos de SAP, de forma que una buena calificación podrá repercutir en el sueldo del empleado o se podrá valorar qué persona es más válida o tiene mayor interés cuando un puesto se quede vacante dentro de nuestra organización.

¿Parece útil, no? A continuación os dejo la ruta del menú desde donde podréis ir investigando un poco entre la multitud de opciones para la gestión del desarrollo de personal que SAP nos ofrece.

En este nuevo artículo sobre SAP PP vamos a hablar de los puestos de trabajo, que junto con las listas de materiales y las hojas de ruta, forman parte de los datos maestros de la planificación de producción y control del Sistema R/3.

Las operaciones se llevan a cabo en un puesto de trabajo. Estos puestos de trabajo en SAP son business objects que pueden representar los siguientes puestos de trabajo reales:

Máquinas, grupos de máquinas
Líneas de producción
Puestos de trabajo de montaje
Empleados, grupos de personal

Los puestos de trabajo se utilizan en las operaciones y órdenes de trabajo de las hojas de ruta. (Las órdenes de trabajo se crean para la fabricación, la gestión de calidad, el mantenimiento y el sistema de proyectos como grafos)

Los datos con mayor influencia de los puestos de trabajo en SAP PP son:

1. Programación

Los tiempos de empleo y las fórmulas se registran en el puesto de trabajo para que se pueda calcular la duración de una operación.

2. Cálculo del Coste

Las fórmulas se registran en el puesto de trabajo para que se pueda calcular el coste de una operación. Además se asigna el puesto de trabajo a un centro de coste.

3. Planificación de la Capacidad

En el puesto de trabajo se registra la capacidad disponible y las fórmulas para el cálculo de la necesidad de capacidad.

3. Simplificación de la Actualización de Operaciones

En el puesto de trabajo, se pueden registrar varios valores de propuesta para las operaciones.

El siguiente gráfico muestra la utilización de los datos del puesto de trabajo:

Los puestos de trabajo en SAP PP se crean para un centro y se identifican mediante una clave. La clase de puesto de trabajo, que se define en el Customizing del puesto de trabajo, determina qué datos se pueden actualizar en el puesto de trabajo. Estos datos se agrupan por temas en pantallas y grupos de pantallas:

Datos básicos
Asignaciones Capacidades
Programación
Valores propuestos
Jerarquía
Datos técnicos

Por último, a continuación se indican las rutas para llevar a cabo las diferentes operaciones relativas a los puestos de trabajo en SAP PP:

Crear puesto de trabajo

Logística -> Producción -> Datos maestros -> Puestos de trabajo -> Puesto de trabajo -> Crear CR01

Modificar puesto de trabajo

Logística -> Producción -> Datos maestros -> Puestos de trabajo -> Puesto de trabajo -> Modificar CR02

Visualizar puesto de trabajo

Logística -> Producción -> Datos maestros -> Puestos de trabajo -> Puesto de trabajo -> Visualizar CR03

Listado de puestos de trabajo

Logística -> Producción -> Puestos de trabajo -> Evaluaciones -> Sistemas de información puesto de trabajo CR60

En este artículo se va a explicar cómo parametrizar absentismos y/o presencias en SAP HCM, mediante la parametrización de los campos en la tabla T554S.

Imaginemos que queremos crear una presencia en SAP con descripción “Horas Regulares”:

Para ello se accede a la tabla de detalle de modificación de clases de Absentismo/Presencia mediante la transacción SM30 y se pulsa el botón “Entradas nuevas”.

La tabla a tratar es la tabla T554S:

En esta pantalla se definen los siguientes campos para parametrizar absentismos y presencias en SAP:

Agrupador de subdivisión, clase de presencia y descripción.
Opciones generales: Se define si es una presencia (P) o absentismo (A) y la clase de enlace temporal para poder provocar colisiones entre absentismos y presencias.
Verificación entrada: Definimos como se va a comportar el sistema en caso de querer generar presencia en un día no laborable (W: Mensaje Warning, E: Mensaje Error).
Aquí también definimos el máximo de días que puede durar esta presencia (en este caso 999).
Cómputo y liquidación de contingente: Se define el contingente asociado a esta presencia. En este caso no existe contingente asociado, en caso de existir se indicaría en el campo “reglamento de cómputo”, que definiría como se computa dicho contingente en el infotipo 2005.
Control de calendario: Se define la letra del calendario que generaría dicha presencia en caso de generación de calendario para temas de bajas por IT…
Evaluación de tiempos: Se indica la clase de tiempos con la que está relacionada para que al lanzar la evaluación de tiempos se generen las clases de tiempos en función de lo definido en la tabla T555Y.

Estos son los campos básicos a parametrizar para definir un absentismo/presencia en el sistema. En futuros artículos se explicará cómo definir un reglamento de cómputo para un contingente de tiempos.

Cualquier elemento de la interfaz de usuario de una vista Web Dynpro Abap se puede tanto crear como modificar mediante código. De esta manera, existe la posibilidad de modificar dinámicamente el layout WD4A de una vista en tiempo de ejecución.

En este artículo vamos a ver algunas técnicas y métodos para hacer este tipo de modificaciones dinámicas en Web Dynpro Abap.

Layout dinámico en WD4A: wddomodifyview

Lo primero y más importante es hablar del método wddomodifyview. El código fuente para todos los cambios dinámicos tiene que ser definido en este método Hook estándar, ya que es el único método que recibe una referencia válida al nodo raíz de la jerarquía de elementos UI.

El método wddomodifyview es llamado justo antes de que el layout sea renderizado, por lo tanto, se ejecutará siempre que se desencadene un evento.

Principios para modificar dinámicamente WD4A UI

Se deben utilizar los siguientes principios a la hora de realizar manipulaciones dinámicas de UI:

Sólo se deben realizar manipulaciones de elementos UI cuando no es posible controlar el comportamiento a través de binding con el contexto en tiempo de diseño.
La manipulación de elementos UI sólo está permitida en el método wddomodifyview.
wddomodifyview tiene un parámetro booleano llamado first_time, que será abap_true la primera vez que se ejecuta, y abap_false en cualquier otro caso.
No se debe implementar código que modifica el contexto dentro de wddomodifyview. El contexto debería considerarse como de sólo lectura durante la ejecución de este método.

Modificación del layout WD4A mediante código

El siguiente paso para acceder o crear un elemento UI dinámicamente en WD4A es conseguir una referencia al elemento contenedor.

Este elemento contenedor podría ser RootUIElementContainer, elemento que existe por defecto en todos los controladores de vistas. Para obtener esta referencia, se deben utilizar métodos del parámetro de entrada view. Para acceder a un elemento arbitrario se puede llamar al método get_element(), pasando el ID del elemento como parámetro.

A continuación vemos un ejemplo de cómo coger un elemento UI, en este caso el RootUIElementContainer:

DATA: lr_ui_element   TYPE REF TO if_wd_view_element,
      lr_container TYPE REF TO cl_wd_uielement_container.
  CHECK first_time = abap_true.
 *Se coge la referencia al nodo raíz por ID:
  lr_ui_element = view->get_element( id = 'ROOTUIELEMENTCONTAINER' ).
* Cast necesario 
  lr_container ?= lr_ui_element.

Esta acción se puede realizar con cualquier elemento UI que exista en el layout, pasando su correspondiente ID y creando la referencia a su clase de elemento. Para cada elemento UI existe una clase describiendo el elemento existente. Todas estas clases son subclases de CL_WD_UIELEMENT. Estas clases usan la convención de nombres CL_WD_<tipo de elemento>, por ejemplo CL_WD_LABEL o CL_WD_TABLE.

Ahora vamos a mostrar cómo se añadiría un input_field con su etiqueta al nodo raíz. Primero creamos los elementos:

DATA:   lr_label TYPE REF TO cl_wd_label,
        lr_input TYPE REF TO cl_wd_input_field.
*se crea un inputField relacionado con un atributo del contexto
  lr_input = cl_wd_input_field =>new_input_field(
                  bind_value   = '<node_name>.<atribute_name>'
                  id           = 'INPUT_FIELD_<attribute_name>' ).
*se crea una etiqueta para el inputField
  lr_label = cl_wd_label=>new_label(
                id        = 'LABEL_<attribute_name>' 
                label_for = lr_input->id ).

Una vez creados y antes de añadirlos a un elemento contenedor, se deben ajustar las propiedades del elemento contenedor al que se va a añadir. Esto es especialmente importante en el caso de la propiedad Layout, ya que ésta influencia las propiedades de los elementos hijos.

Para asignar el layout deseado al elemento contenedor, debe ser llamado un método estático de la clase que representa el layout. Todas las clases de layout son sub-clases de CL_WD_LAYOUT. Por lo tanto, en el ejemplo que nos ocupa, en el que queremos añadir un input_field con su etiqueta al nodo raíz haríamos lo siguiente:

*se define el layout data para los elementos creados
  cl_wd_matrix_head_data=>new_matrix_head_data(
      element = lr_label ).
  cl_wd_matrix_data=>new_matrix_data(
      element = lr_input ).

En este ejemplo se utiliza el tipo de layout MatrixLayout. Es importante que el elemento contenedor donde se van a añadir los elementos tenga el mismo tipo indicado.

Por último, se añaden los elementos creados al contenedor:

  lr_container->add_child( the_child = lr_label ).
  lr_container->add_child( the_child = lr_input ).

Así es como se consigue crear elementos UI por código en Web Dynpro Abap.

Para modificarlos, deberíamos cogerlos de la misma manera que hemos cogido el elemento raíz, y utilizar los diferentes métodos disponibles en las diferentes clases de los elementos.

Por ejemplo, para modificar alguna propiedad, todos tienen un método llamado SET_<nom_propiedad>() por cada propiedad del elemento.

Para más información, se puede acceder a las clases de cada elemento (como hemos comentado CL_WD_<nom_elemento>) o en la ayuda de SAP, donde se encuentran descritos todos los elementos.

En muchas ocasiones, a la hora de personalizar nuestro portal corporativo SAP nos encontramos con una herramienta de diseño algo limitada: el Theme Editor. En este artículo se va a explicar qué alternativas tenemos para customizar SAP Enterprise Portal de una manera más libre y que permite lograr resultados más trabajados.

Limitaciones del Theme Editor del Portal de SAP

Como comentaba al inicio, la herramienta que por defecto está disponible en SAP Portal para dar formato a las páginas de framework del nuestro portal SAP es el Theme Editor. Esta herramienta, permite crear temas propios, basados en los temas predeterminados puestos a disposición por SAP, con los que crear una identidad corporativa propia para el portal.

Sin embargo, el Theme Editor limita en gran medida la capacidad del diseñador ya que sólo permite modificar algunas propiedades de ciertos elementos:

No es posible añadir nuevas reglas con las que personalizar elementos de la interfaz de usuario no tratados por defecto, ni por supuesto utilizar imágenes de fondo que no sean las a priori solicitadas por la propia herramienta.

Así mismo, tampoco es sencillo ampliar las reglas de estilo ya dispuestas por SAP. Para esto último, es posible llevar a cabo trucos, añadiendo propiedades CSS concatenadas a valores de las propiedades propuestas, de manera que se “cuelen” nuevas propiedades.

A continuación se muestra un ejemplo de cómo añadir la propiedad padding a una regla que a priori no trataba esta propiedad.

UI Theme Designer: Nuevas formas de diseñar el portal SAP

Todo esto puede quedar atrás si hacemos uso de la nueva funcionalidad que ofrece SAP Enterprise Portal desde su versión 7.30: UI Theme Designer.

Esta nueva herramienta surge sobre todo ante la aparición de SAP Fiori UX, con la que SAP pretende dar un paso adelante en lo que a trabajar la interfaz y experiencia de usuario se refiere.

Con la activación del UI Theme Designer, podemos abordar la personalización de nuestro SAP Enterprise Portal de dos maneras:

1. Utilizando la propia herramienta UI Theme Designer

Este método sigue con la idea de edición propuesta que ya conocemos del Theme Editor, pero ofreciendo una interfaz mucho más agradable y sencilla para no diseñadores con selectores de color, explorador de ficheros entre otros muchos aspectos.

El UI Theme Designer está disponible desde el rol de portal Content Management, accediendo al apartado Portal Display>UI Theme Designer.

2. Editando directamente los ficheros CSS de la interfaz web del portal SAP

Desde el rol de portal Content Management, disponemos de una nueva sección “Repository para recursos web”, a través de la que será posible cargar y descargar recursos web (CSS, imágenes etc.) propios de cada theme creado en el UI Theme Designer, ya sea modificando los ya existentes o incluyendo nuevos.

Esta opción es más compleja, pero aporta una mayor flexibilidad a la hora de diseñar una interfaz de usuario para nuestro portal corporativo SAP.

Como se puede ver en la imagen, dentro de la carpeta theming aparecen diferentes carpetas que agrupan recursos web para diferentes controles y elementos de la interfaz del portal (AFP para los elementos del Ajax Framework Page, UR>ls para controles de interfaces Web Dynpro etc.)

Dentro de cada una de esas carpetas encontraremos otra carpeta con el nombre de cada tema creado en el UI Theme Designer y dentro de estas segundas se encontrarán los ficheros CSS para cada navegador (o grupo de navegadores) para los que se prepara el portal de SAP.

Una vez localizados los ficheros generados por el UI Theme Designer, es posible descargar y recargar estos ficheros (CSS, imágenes, fuentes etc.) tantas veces como queramos, dejando libre la imaginación de los diseñadores, hasta ir consiguiendo la interfaz corporativa deseada para nuestro portal de SAP.

La importancia del módulo de Desarrollo de Personal de SAP muchas veces queda desplazada por otros módulos que tienen resultados más inmediatos. Pero, si las personas son el activo más importante de la empresa… ¿no deberíamos invertir más en una mejor gestión de las mismas?

En el anterior artículo, os explicamos un resumen de los cuatro componentes que forman el módulo de Desarrollo de Personal de SAP. Seguro que os quedasteis con las ganas de saber un poco más sobre ellos. Pues comenzamos con el primero: La Gestión del Talento.

Gestión del Talento

La Gestión del Talento es la base del módulo de Desarrollo de Personal. Su función es gestionar todos los conocimientos que los empleados tienen y las necesidades de la empresa. Para ello, cada trabajador tendrá asignadas sus cualificaciones y por cada cualificación se indicará el nivel de conocimiento.

Por ejemplo, un empleado podría tener como cualificación Inglés, con un nivel C1. Al conjunto de conocimientos de un empleado, le llamaremos el Perfil del Empleado.

Enfrentándose al perfil del empleado, encontramos el perfil de las posiciones o funciones, donde se indican las necesidades de la empresa mediante las cualificaciones y escalas correspondientes.

Aunque el proceso para la carga de los perfiles puede ser costoso, SAP ofrece varias herramientas para facilitarlo:

Carga de datos de forma rápida a múltiples empleados.
Actualización de datos a través del portal por los propios empleados.
Informes para conocer el estado de los perfiles.

¿Y toda esta información dónde la podemos ver? Tras activar la funcionalidad del Desarrollo de Personal, el infotipo 0045 cambiará de forma y nos mostrará los perfiles y subperfiles como vemos a continuación:

No se permitirá la modificación de los perfiles a través del infotipo de forma directa, sino que para su manejo se debe usar la transacción PPPM que abrirá una ventana que nos recuerda a la usada para la gestión de la estructura organizativa (PPOME).

En próximos artículos continuaremos conociendo los diferentes componentes del módulo de Gestión del Desarrollo de Personal en SAP.

Generalmente, cuando se habla de Internet of Things (IoT) se tiende a pensar en tecnologías Big Data donde enormes volúmenes de datos medidos en petabytes son almacenados y analizados para sacar tendencias y pautas. Lo que mucha gente no se da cuenta es que muchos casos relacionados con IoT tan solo requieren volúmenes de datos pequeños. ¿Qué se consideran “datos pequeños” o Small Data?

1. ¿Qué es Small Data?

Small Data son datos que por su volumen y formato son fácilmente accesibles y manejables y que de por sí, sin tratamiento, ya nos dan una información concreta. Es decir, small data nos provee con información que responde a una pregunta concreta o trata de un problema específico.

Ejemplos de Small Data podrían ser resultados de una jornada de fútbol, reportes de inventario o datos de ventas en una PYME, historiales de búsqueda, previsiones meteorológicas, etc.

2. Small Data VS Big Data

El concepto Small Data contrasta con el de Big Data, que por lo general se refiere a una combinación de datos estructurados y no-estructurados que son medidos en petabytes o exabytes. Como dijimos en un artículo anterior, Big Data se caracteriza por las 3 Vs: Volumen de datos, variedad de datos y velocidad a la que son (o deberían ser) procesados.

Estos 3 puntos hacen que el Big Data sea muy complicado de gestionar. Por el contrario, el Small Data se compone de secciones de datos fácilmente manejables.

3. Small Data Group

Small Data Group es un grupo dedicado a la investigación de todos los aspectos relacionados con Small Data. Su fundador es Allen Blonde, vicepresidente de Actuate Product Marketing and Innovation.

Respecto a Small Data, nos da la siguiente explicación:

“Small Data conecta a personas con datos recientes y concretos que ya poseen un significado intrínseco y que están organizados y estructurados para ser fácilmente accesibles, entendibles y manejables para el día a día. Estos datos pueden derivar de volúmenes de datos más grandes (Big Data) o de fuentes locales.”

4. Small Data: Ejemplos de uso

Small Data: Ejemplo de uso 1

Una turbina eólica contiene varios sensores para determinar la dirección y velocidad del viento, temperatura, vibración y otros atributos de interés. Las hélices de la turbina pueden ser programadas para recalibrarse automáticamente ante condiciones cambiantes del viento en función de la información alimentada al instante a través de Small Data.

Estos volúmenes de Small Data (i.e. una batería de Small Data por turbina) son incorporados un pool de datos de mayor volumen (Big Data) donde algoritmos de procesamiento de datos permiten descubrir tendencias y pautas de comportamiento. Estas pautas pueden revelar información de rendimiento de ciertos mecanismos en base a su histórico de mantenimientos. Por ejemplo, cómo el viento y las condiciones meteorológicas afectan al desgaste de los componentes de las turbinas, y de esto último poder desagregar la información para conocer el tiempo de vida útil de una pieza concreta de la turbina.

Small Data: Ejemplo de uso 2

Otro caso, es el uso de etiquetas inteligentes en frascos de medicinas. Small Data puede ser usado para determinar la ubicación del frasco, el estado del sello de la botella, las condiciones de temperatura y humedad de la ubicación del frasco.

Agregando las secciones de Small Data a un volumen de Big Data se pueden ejecutar algoritmos de análisis para, por ejemplo, determinar la raíz de la causa por la que una medicina se ha deteriorado o caducado: ¿Es ello debido a una compañía de transporte o a un comercializador? ¿Son problemas recurrentes que apuntan a un fallo en la cadena de suministro?

Resolver problemas como los de arriba puede suponer un ahorro enorme a compañías e instituciones. Recordemos: Small Data permite saber qué hace el objeto que está siendo analizado. Si lo que quieres es saber por qué el objeto está haciendo eso, Big Data es lo que necesitas.

Los sistemas SAP JAVA disponen de una herramienta que se llama SLD (System Landscape Directory) en la cual se guarda un catálogo de todos los productos y componentes de SAP.

Este catálogo se va actualizando a medida que SAP lanza nuevas versiones de sus productos, enhancement packages, support packages etc. De la misma manera SAP recopila mensualmente todas estas actualizaciones y confecciona unos paquetes para actualizar el catálogo del SLD.

En este artículo explicamos cómo actualizar el modelo CIM y el CR Content en SAP a través del SLD.

Para conseguir estos paquetes hay que acceder al SAP Software Download Center con un usuario y contraseña del portal de SAP, concretamente en la sección Support Packages and Patches -> Additional Components -> SAP CR CONTENT como se indica en la siguiente imagen:

Dentro de la sección SAP CR CONTENT los ficheros se organizan por años. Para realizar la actualización es necesario descargar dos tipos de ficheros:

El último fichero disponible correspondiente al Model Version. Este fichero tiene un nombre cimsapxxxxxx_x-xxxxxxxx.zip y es suficiente.
Los ficheros de contenido con el nombre CRDeltaXXXXXX_X-XXXXXXXX.ZIP. De este tipo de ficheros hay que descargar el último paquete disponible cada año para pasar de cada SAP CR Content Version a la siguiente versión.

Una vez descargados todos los ficheros de los paquetes necesarios, los tenemos que importar en el SLD desde la opción Administration-> Content Import:

1. Actualizar el CIM Model en SAP

Primero se debe actualizar el modelo CIM cargando el fichero nombrado cimxxxxxx.zip:

Tras pulsar “importar” se muestra un resumen del fichero y se pide confirmación para cargar el fichero:

Se muestra el progreso mientras se carga el paquete:

2. Actualizar el CR Content en SAP

Cuando el modelo CIM está actualizado con la última versión, se continúa importando cada uno de los ficheros CRDelta de cada año ya que son paquetes incrementales:

En el apartado Administration -> Details -> pestaña Data se muestra la versión y el nivel actual del modelo CIM y el contenido CR:

Mantener estos componentes del SLD actualizados es importante, sobre todo en el SLD del sistema Solution Manager, porque a la hora de actualizar un SP stack o instalar un EHP, para la generación de ficheros .xml mediante el Maintenance Optimizer del Solution Manager, éste consulta el catálogo de productos del SLD. En caso de no tenerlo actualizado la MOPz obliga a actualizarlo.

Para consultar más artículos sobre el Maintenance Optimizer:

http://orekait.com/blog/sap-solution-manager-maintenance-optimizer-12/

http://orekait.com/blog/como-actualizar-sap-solution-manager-7-1-a-sp-stack-08/

http://orekait.com/blog/tutorial-sap-aprobar-ficheros-de-download-basket/

El Real Decreto Ley 1/2015 de 27 de febrero crea una serie de medidas relativas al fomento del empleo en el ámbito de la Seguridad Social.

En su artículo 8 se establece un mínimo exento de cotización a la Seguridad Social para favorecer la creación de empleo indefinido.

En este artículo repasaremos los puntos más importantes acerca de estas medidas para el fomento del empleo indefinido.

¿Cuándo se aplica el beneficio en la cotización?

El beneficio en la cotización citado anteriormente se aplicará en un periodo de 24 meses, computados a partir de la fecha del contrato, que se deberá formalizar entre la fecha de entrada en vigor del Real Decreto Ley 1/2015 de 27 de febrero y el 31 de agosto de 2016.

¿Cuánto cotizan las empresas a la Seguridad Social?

La aportación empresarial a la cotización a la Seguridad Social por contingencias comunes se determinará conforme a la siguientes reglas:

Contratos Indefinidos a tiempo completo: Los primeros 500 euros de la base de cotización por contingencias comunes correspondiente a cada mes quedarán exentos de la aplicación del tipo de cotización en la parte correspondiente a la empresa.

Contratos Indefinidos a tiempo parcial: Cuando la jornada de trabajo sea al menos, equivalente a un 50 por 100 de la jornada de un trabajador a tiempo completo comparable, la cuantía señalada en el punto anterior se reducirá de forma proporcional al porcentaje de reducción de jornada de cada contrato.

¿Qué otros beneficios tendrán las empresas?

Finalizado el periodo de los 24 meses, las empresas que en el momento de celebrar el contrato cuenten con menos de 10 trabajadores, podrán aplicar, una deducción de los primeros 250 euros durante un período adicional de otros 12 meses en contratos indefinidos a tiempo completo o la parte proporcional en caso de contratos indefinidos a tiempo parcial.

¿Qué requisitos deben cumplir las empresas?

Las empresas que quieran acogerse a este beneficio en la cotización a la Seguridad Social deberán cumplir los siguientes requisitos:

Hallarse al corriente en el cumplimiento de sus obligaciones tributarias y de la Seguridad Social, tanto en la fecha de efectos del alta de los trabajadores como durante la aplicación del beneficio correspondiente.
No haber extinguido contratos de trabajo en los 6 meses anteriores, bien por causas objetivas o por despidos disciplinarios que hayan sido declarados judicialmente improcedentes.
Realizar contratos indefinidos que supongan un incremento tanto en el número de empleados indefinidos como en el número total de empleados en la empresa.
Mantener durante un periodo de 36 meses el nivel de empleo indefinido y el nivel de empleo total alcanzado. No se tendrán en cuenta las extinciones de contratos de trabajo por causas objetivas o por despido disciplinarios que hayan sido declarados improcedentes.

¿Qué condiciones pueden excluir del beneficio?

No será aplicable el beneficio en la cotización en los siguientes supuestos:

En las relaciones laborales de carácter especial previstas en el artículo 2 del texto refundido de la Ley del Estatuto de los Trabajadores.
Contrataciones que afecten al cónyuge, ascendientes, descendientes y demás parientes por consanguinidad o afinidad, hasta el segundo grado inclusive. Sin embargo, los trabajadores autónomos podrán formalizar contrataciones acogidas a estos beneficios con los hijos menores de 30 años que convivan con él o mayores de 30 años que tengan especiales dificultades para la inserción laboral.
Contratación de trabajadores cuya actividad determine su inclusión en cualquiera de los sistemas especiales establecidos en el Régimen General de la Seguridad Social.
Contratación de trabajadores que hubiesen estado contratados en otras empresas del grupo de empresas.
Contratación de trabajadores que en los seis meses anteriores a la fecha del contrato hubiesen prestado servicios en la misma empresa o entidad mediante un contrato indefinido.
El beneficio tampoco resultará aplicable a la cotización por horas complementarias que realicen los trabajadores a tiempo parcial cuyos contratos de derecho al mismo.

¿Es compatible con otros beneficios en la cotización?

Este beneficio será incompatible con cualquier otro beneficio en la cotización a la Seguridad Social, excepto en los siguientes casos:

En el caso de contrataciones indefinidas con personas beneficiarias del Sistema Nacional de Garantía Juvenil.
En el caso de contrataciones indefinidas con personas beneficiarias del Programa de Activación para el Empleo regulado en el Real Decreto-ley 16/2014, de 19 de diciembre.

¿Qué ocurre si las empresas no cumplen sus obligaciones?

En caso de incumplimiento de la obligación de mantenimiento de empleo:

Si el incumplimiento se produce desde la fecha de inicio del beneficio hasta el mes 12, se reintegrará el 100% de la bonificación o reducción.
Si el incumplimiento se produce desde el mes 13 y hasta el mes 24, se reintegrará la reducción por los meses que hayan transcurrido desde el mes 13.
Si el incumplimiento se produce desde el mes 25 y hasta el mes 36, se reintegrará la reducción por los meses que hayan transcurrido desde el mes 25.

Todas estas medidas relativas al fomento del empleo indefinido se recogen en la Artículo 8 del RDL 1/2015 de 27 de febrero.

http://www.boe.es/boe/dias/2015/02/28/pdfs/BOE-A-2015-2109.pdf

En este artículo se explicará cómo parametrizar los conceptos básicos de la liquidación de viajes dentro del módulo SAP HCM de Gestión de Viajes, para que un empleado pueda crear una hoja de gastos con diferentes clases de gastos.

Para comenzar con la parametrización de viajes en SAP HCM se explicarán la parametrizaciones básicas correspondientes a la parte de datos maestros:

Parámetros de control para gastos de desplazamiento
Clases de gastos de viajes

En esta primera parte, nos centraremos en el primero de estos puntos: Parámetros de control para gastos de desplazamiento.

1. Parámetros de control para gastos de desplazamiento

Mediante la transacción SPRO accederemos a la Guía de Implementación de Customizing SAP. Toda la parametrización relacionada con esta sección se realizará a través de la siguiente ruta:

Gestión financiera → Gestión de viajes → Liquidación de gastos de desplazamiento → Datos maestros

A) Definir/Borrar/ Restablecer variantes de reglamentación de viajes

Uno de los aspectos a configurar en la parametrización de viajes en SAP HCM, son las reglamentaciones de viajes. Estas son las normas para determinar el reembolso de gastos de viaje y su tratamiento fiscal. Podremos utilizar una única para un país o diferentes en caso de tener que aplicar diferentes criterios de reembolso.

En esta sección podremos entre otras operaciones copiar y crear una variante de reglamentación ya existente. Nosotros utilizaremos la propuesta para España:

B) Asignar áreas organización y característica TRVCT p.variantes reglam.viajes

En esta sección tendremos que determinar en base a las características de los empleados qué variante de reglamentación de viajes se deberá aplicar.

Podríamos incluso hacer una diferenciación teniendo en cuenta la sociedad del empelado para asignar diferentes variantes de reglamentación de viajes dependiendo de la sociedad a la que perteneciese el empleado.

C) Definir parametrizaciones previas globales

En esta sección se indicará para la variante de reglamentación indicada el tipo de moneda, la moneda en la que se liquidarán los importes de cada hoja de gastos de viajes, los datos relacionados a los impuestos etc.

D) Parámetros de control de los privilegios de viaje

Este punto es importante puesto que parametrizaremos todos los valores relacionados del Infotipo 0017; para identificar por cada tipo de empleado los diferentes grupos de reembolso, importes de reembolso etc.

GrReembLegalMan/Aloj: Este primer campo nos permite poder crear diferentes grupos en función del porcentaje de reembolso de manutención o alojamiento.
GrpR-M/A-Empresa: En este campo se podrán diferenciar los diferentes grupos de empleado en base a su reembolso (si van solo a gastos, gastos de un importe X, gastos importe Y…) definidos por la empresa.
ClGstViajePAgrupPers: Aquí se definirán los grupos de empleados para los cuales se podrán utilizar las mismas clases de gastos de viajes.
pers.gest.viajes: Este campo se puede utilizar para la verificación de autorizaciones en características.
GrpR-Costes de viaje: Aquí se podría diferenciar si existieran diferentes grupos de reembolso relativos a los costos de viaje.
Clase de vehículo: En el caso que el importe de reembolso sea diferente en base al tipo de vehículo; tendríamos que crear los diferentes grupos en esta sección.

E) Parámetros de control de datos de viaje

En esta sección se pueden definir diferentes áreas de viaje (si por ejemplo los importes de reembolso fueran diferentes por cada área de viaje). No explicaremos este apartado ya que no es necesario para una parametrización de viajes en SAP HCM básica .

Próximamente explicaremos como parametrizar clases de gastos de viaje.

Después de comenzar en el artículo anterior a conocer la parametrización de viajes en SAP HCM repasando los parámetros de control para gastos de desplazamiento, en este artículo se explicará cómo parametrizar las diferentes clases de gastos a utilizar en las hojas de gasto.

2. Clases de Gastos de Viaje

Al igual que veíamos para los parámetros de control para gastos de desplazamiento, para parametrizar las clases de gastos de viaje también utilizamos la transacción SPRO accediendo en esta a la Guía de implementación de customizing SAP.

Toda la parametrización de las clases de gastos en SAP HCM se realizará a través de la siguiente ruta:

Gestión financiera → Gestión de viajes → Liquidación de gastos de desplazamiento → Datos maestros

Desde la sección “Crear clases de gastos de viaje p.comprobantes individuales” se crearán las diferentes clases de gastos de viaje que pueda seleccionar un empleado al crear una hoja de gastos. Las clases de gasto pueden crearse únicamente para ciertos tipos de empleados o para todos; dependiendo de las agrupaciones definidas en el infotipo 0017 para el campo “ClGstViajePAgrupPers”.

A la hora de crear una clase de gasto definiremos la clave, una descripción, fechas de validez de la clase de gasto, categoría…

Un campo importante a tener en cuenta es el “Autoriz-cl.gast.vje.” ya que aquí definiremos los tipos de empleados que podrán usar esta clase de gasto (valores del infotipo 0017 parametrizados en el campo “ClGstViajePAgrupPers”).

Otro campo importante es “Los importes son” ya que aquí podremos definir el comportamiento de la clase de gasto para indicar si es una gasto previamente pagado por la empresa (como podría ser el caso de utilizar tarjeta de empresa), un gasto a devolver al empleado…

Además de esta parametrización, para que una clase de gasto pueda ser elegida a la hora de crear la hoja de gasto habrá que indicar para qué tipo de esquema de viajes es válida, e introducir la clase de gasto y las fechas para las que será válido para lo que se deberá acceder a la sección “Restringir clases de gastos de viaje para esquema de viaje“.

Con estos dos artículos damos por concluído este repaso a la parametrización de viajes en SAP HCM.

En los últimos tiempos SAP se ha propuesto mejorar la experiencia de usuario de sus aplicaciones, en especial las destinadas a usuarios finales de SAP. Para ello, ha creado la SAP User Experience Strategy, una estrategia en base a la que desde diferentes puntos de vista (NEW, RENEW y ENABLE) se quiere conseguir dicho objetivo.

Uno de los medios que han puesto a disposición de los desarrolladores para llevar a cabo la estrategia SAP User Experience es SAPUI5. Si aún no sabes qué es SAPUI5, no te preocupes, en este artículo lo explicamos y conoceremos más sobre su arquitectura.

¿Qué es SAPUI5?

SAPUI5 es un conjunto de librerías Javascript para el desarrollo y diseño de aplicaciones de negocio SAP basadas en HTML5. Es un framework de programación que facilita el desarrollo de aplicaciones web de lado cliente que cumplen los principios de la SAP User Experience Strategy.

Principios de las aplicaciones SAPUI5

Las aplicaciones SAPUI5 deben cumplir los principios de la estrategia SAP User Experience. A continuación los presentamos:

1. Aplicaciones SAPUI5 orientadas a roles

Las aplicaciones SAPUI5 deben estar pensadas para los usuarios que van a utilizarlas. Sólo deben mostrar los datos que un determinado rol de negocio quiere ver y ninguno más.

Se trata de dividir las transacciones que conocemos hasta ahora, en pequeñas aplicaciones orientadas a las tareas concretas del rol que las va a utilizar.

2. Aplicaciones SAPUI5 responsive

Las aplicaciones SAPUI5 deben ofrecer una interfaz de usuario atractiva, a la vez que sencilla e intuitiva que ofrezca una experiencia de usuario buena y equivalente sea cual sea la plataforma o dispositivo desde la que se acceda, independientemente de versión, sistema operativo, navegador, resolución etc.

3. Aplicaciones SAPUI5 simples

Las aplicaciones SAPUI5 además de estar orientadas a roles, deben ofrecer la funcionalidad de una manera sencilla y simple.

En el desarrollo de aplicaciones SAPUI5 se sigue la regla 1-1-3: 1 usuario, 1 caso de uso, 3 pantallas como máximo. Si la aplicación que estamos desarrollando no puede resumirse en 3 o menos pantallas, deberemos rediseñarla o dividirla en varias aplicaciones SAPUI5.

4. Aplicaciones SAPUI5 coherentes

Las aplicaciones SAPUI5 deben hablar el mismo idioma. Esto se refiere a que deben utilizar elementos y estilos comunes de manera que un usuario que sepa utilizar una aplicación SAPUI5, sepa utilizar cualquiera otra. Para ello, existen themes y recursos web a disposición de los desarrolladores SAPUI5.

5. Aplicaciones SAPUI5 disponibles al instante

Este principio está más relacionado con las aplicaciones SAP Fiori UX enmarcadas en el enfoque RENEW de la estrategia User Experience de SAP. Se refiere a la disponibilidad de una de estas aplicaciones Fiori, que también son aplicaciones SAPUI5 ya desarrolladas y puestas a disposición por SAP que pueden instalarse y usarse en poco tiempo.

Arquitectura de las aplicaciones SAPUI5

Como ya se ha comentado anteriormente, las aplicaciones SAPUI5 son aplicaciones de lado cliente que ofrecen una interfaz SAP a través de la que consumir o nutrir de datos a SAP.

Desarrollar una aplicación SAPUI5 significa por tanto, diseñar una interfaz y definir de dónde se va a obtener los datos que va a tratar esta interfaz. Para ello, se utiliza el paradigma MODELO-VISTA-CONTROLADOR del que derivarán 3 tipos de componentes a tener muy en cuenta:

Vistas: Ficheros en los que se diseñará la estructura y formato de la aplicación SAPUI5 en cuestión: layouts, controles, tablas, etc. Pueden desarrollarse en los siguientes formatos: Javascript, XML, HTML o JSON.
Controlador: Ficheros Javascript en los que se definirá la lógica de negocio de la interfaz, se atenderá a eventos, se realizarán validaciones y se crearán modelos con los que establecer la relación entre la aplicación y el backend de donde procedan los datos a tratar.
Modelo: Serán las fuentes de datos de los que se nutrirá la aplicación, podrán ser SAP o no SAP y podrán estar basados en diferentes formatos como JSON, XML u oData.

Esto es sólo una pequeña introducción para saber qué es SAPUI5. A partir de ahora iremos escribiendo artículos con los que acercarnos poco a poco al desarrollo de aplicaciones SAPUI5.

En este tercer artículo de la serie sobre Gestión del Desarrollo de Personal, vamos a profundizar en el componente que se utiliza para calificar a los empleados. Este componente proporciona el soporte necesario para crear sistemas de calificación y planificar, implementar y hacer informes sobre calificaciones.

Un sistema de calificación es un proceso en el que utilizando un modelo se evalúa a los miembros de la empresa para obtener información sobre las características, la conducta o su rendimiento.

Sistema de calificación SAP HCM

El primer paso en el proceso de calificación será crear un modelo de formulario y para ello SAP ofrece dos opciones de formulario:

Formulario flexible
Formulario predefinido

La diferencia radica en que con los formularios predefinidos, la interacción se realizará mediante el portal de SAP a través de una UI mucho más atractiva. Además, como el propio nombre indica, los formularios predefinidos se crearán mediante un asistente que reduce las posibilidades de configuración, pero que lo convierte en un proceso muy sencillo.

A continuación se puede ver la diferencia en los diseños de estos dos tipos de formulario del Sistema de Calificación SAP HCM:

Formulario flexible del Sistema de Calificación SAP HCM

Formulario predefinido del Sistema de Calificación SAP HCM

En ambos formularios el proceso es el mismo y comenzará introduciendo los criterios que se van a evaluar. Estos criterios pueden ser cualificaciones recuperadas de nuestro catálogo.

Una vez se dé por finalizada la calificación, la nueva valoración de nivel viajará hasta el perfil del empleado, asegurándose así que se mantienen los datos coherentes y actualizados.

En los formularios flexibles, las posibilidades de parametrización aumentan, pudiendo definir todas las fases que se deseen, indicar qué acciones tienen que realizar los participantes, añadir workflows, así como distintos atributos por cada criterio que se añada.

Por último, todas las calificaciones que se realicen o que se obtengan podrán ser consultadas en el perfil de los empleados (Infotipo 0024).

Hoy en día, cada vez es más habitual el intercambio de datos entre diferentes sistemas. Y, aunque en principio esto supone una gran ventaja, también puede llegar a ser un quebradero de cabeza si los sistemas utilizan formatos diferentes o incompatibles. Para facilitar estos intercambios, y definir un estándar que todos los sistemas puedan entender y utilizar, se creó el lenguaje XML (eXtensible Markup Language).

La mayoría de los lenguajes de programación son capaces ya de interpretar y procesar ficheros XML transformando sus contenidos al formato propio del sistema. En esta serie de artículos vamos a ver cómo tratar estos ficheros XML con ABAP de una forma sencilla.

1. Objetivo del tratamiento de XML con ABAP

Para que la explicación sea más clara y se pueda seguir mejor, vamos a explicar el proceso completo con un ejemplo sencillo. El objetivo de este ejemplo será obtener datos de un XML simple e importarlos en una tabla de nuestro sistema SAP. El fichero que vamos a utilizar contiene un catálogo de CDs musicales, que podemos encontrar en la web www.w3schools.com, y tiene la siguiente estructura:

<CATALOG>
	<CD>
		<TITLE>Empire Burlesque</TITLE>
		<ARTIST>Bob Dylan</ARTIST>
		<COUNTRY>USA</COUNTRY>
		<COMPANY>Columbia</COMPANY>
		<PRICE>10.90</PRICE>
		<AIR_YEAR>1985</AIR_YEAR>
	</CD>
	...
	<CD>
		<TITLE>Unchain my heart</TITLE>
		<ARTIST>Joe Cocker</ARTIST>
		<COUNTRY>USA</COUNTRY>
		<COMPANY>EMI</COMPANY>
		<PRICE>8.20</PRICE>
		<AIR_YEAR>1987</AIR_YEAR>
	</CD>
</CATALOG>

2. Proceso del tratamiento de XML con ABAP

El proceso para importar estos datos XML lo podemos dividir en tres pasos principales. Primero crearemos los objetos del Diccionario de Datos ABAP mediante la transacción SE11, después crearemos una Transformación Simple en la STRANS y, para finalizar, programaremos un report sencillo mediante la SE38 en el que utilizaremos lo creado previamente para procesar el fichero XML.

1) Creación de los objetos del Diccionario ABAP

Como hemos comentado, el primero de los pasos es crear todos los objetos en el Diccionario de Datos y, para ello, empezaremos creando los dominios y elementos de datos con los que trataremos los elementos del fichero. Necesitaremos crear un elemento de datos por cada una de las propiedades del CD (título, artista, país, …), y tantos dominios como necesitemos. Podríamos utilizar elementos ya existentes en nuestro sistema, propios o estándar, pero no es muy recomendable.

Una vez que tenemos creados los elementos de datos, crearemos una estructura ABAP que defina la estructura del propio fichero XML.

Esta estructura define cada uno de los CDs, pero como lo que queremos es recoger varios registros, necesitamos crear un tipo de tabla a partir de esa estructura. De esta manera, podremos recoger cada uno de los CDs en una tabla interna.

Finalmente, como lo que queremos es guardar los datos leídos del XML en una tabla ABAP de nuestro SAP ERP, crearemos una tabla de base de datos en el ABAP Dictionary. Utilizaremos lo definido anteriormente indicando, además, cuales son los campos clave, MANDT y TITLE.

Esto es todo por ahora, en los próximos artículos veremos cómo se crea una Transformación Simple y como se puede utilizar en un programa de carga de datos XML en ABAP.

En ocasiones puede ser de utilidad ofrecer a través de nuestro portal de SAP contenido para usuarios no registrados, es decir contenido anónimo. En este artículo vamos a explicar cómo configurar acceso anónimo a SAP Enterprise Portal en cuatro sencillos pasos.

Para ilustrar este proceso vamos a crear una página de portal que contenga un iView para subir documentos a un directorio del KM (Knowledge Management). De todas formas, el proceso es equivalente para cualquier otro tipo de iView.

A continuación se describe uno a uno los pasos para acceder anónimamente a este contenido del portal de SAP.

1. Crear un rol de portal Anónimo

En primer lugar, desde Portal Content Management, crearemos un rol de portal al que asignaremos el contenido que queremos ofrecer a los usuarios que accedan al SAP Enterprise Portal de manera anónima.

2. Asignar rol de portal al grupo Anonymous

En segundo lugar desde Identity Management, asignamos al grupo Anonymous el rol de portal creado en el paso anterior. De esta manera conseguimos que cuando se acceda al portal de SAP a través de la URL anónima, se visualice el contenido asignado a este rol de portal.

3. Crear el contenido anónimo

Después desde Portal Content Management crearemos el contenido anónimo propiamente dicho. Para el ejemplo que estamos tratando, en primer lugar crearemos un iView de tipo KM Upload y después una página de portal a la que añadiremos un enlace delta de este iView:

A) iView para acceso anónimo a portal SAP

Siguiendo los pasos habituales para la creación de iViews, creamos un nuevo iView del tipo que corresponda (en este caso, un iView de KM Upload).

Lo más importante de este paso es establecer la propiedad Authentication Scheme con el valor anonymous.

B) Portal Page para acceso anónimo a portal SAP

De igual manera, creamos en este caso una página de portal con el layout que deseemos. Lo más importante, de nuevo es establecer la propiedad Authentication Scheme con el valor anonymous.

4. Asignar contenido anónimo al rol del portal SAP

Como paso final, añadiremos la página de portal creada en el paso anterior al rol de portal inicialmente creado, marcando las opciones Entry Point y Visible.

De esta manera, si accedemos al SAP Enterprise Portal a través de la URL anónima http://dominiodelportal:puerto/irj/anonymous sin necesidad de login previo visualizaremos el contenido anónimo.

Como se puede ver en esta última imagen el acceso a través de esa URL se hace con el usuario j2ee_gst, que es el usuario anónimo del portal de SAP por defecto.

Por tanto, siguiendo los pasos anteriores y con las variaciones pertinentes en función del tipo de iview que se quiera publicar, tendremos preparado el contenido para cualquier usuario que acceda al portal sin identificarse.