Hace ya un tiempo, hablamos en este blog del UI Theme Designer como una nueva herramienta que ampliaba en gran medida las posibilidades de customización de nuestro portal SAP.

Sin embargo, la aparición de esta herramienta en SAP Portal no fue fortuita. Básicamente, UI Theme Designer iba a convertirse en una herramienta clave en la estrategia de lavado de cara de las interfaces de usuario SAP, junto con el framework de programación SAPUI5 y por supuesto junto con SAP Fiori.

En esta ocasión vamos a volver a ver en acción el UI Theme Designer, pero para dar estilo a aplicaciones Fiori o aplicaciones UI5 que tengamos publicadas en nuestro SAP Frontend Server como aplicaciones BSP (accesibles desde la transacción SE80).

Para crear un theme con el que personalizar estas aplicaciones disponemos de la transacción /ui5/theme_designer mediante la cual se abrirá el mencionado UI Theme Designer en una pestaña de navegador web.

Como se puede apreciar en la siguiente imagen, el UI Theme Designer es equivalente al que ya conocíamos en SAP Portal:

Al iniciarse se muestra la lista de themes actualmente disponibles tanto estándares como no estándares, los cuales es posible abrir, renombrar, reestructurar, duplicar…

Debemos tener en cuenta cuáles son los themes estándar de SAP actualmente disponibles para dotar de estilo a las aplicaciones UI5, que recordamos son aplicaciones basadas en JavaScript y HTML5. Estos temas son sap_bluecrystal, sap_goldreflection y sap_hcb.

Para crear un theme personalizado, es necesario basarse uno de los themes estándar: abrir el theme estándar, realizar sobre él las modificaciones que sean convenientes y después guardar con un nuevo nombre.

En cualquier caso, UI Theme Designer nos permite previsualizar una aplicación concreta con cualquiera de los themes disponibles. Para ello, añadimos una “Target Page” o página de destino  indicando la URL de la aplicación en el server.

Una vez hecho esto, será posible abrir la aplicación con el theme en cuestión e ir probando cambios en el tema sobre esa misma aplicación:

Desde el UI Theme Designer podemos modificar el estilo de las aplicaciones en tres niveles:

Rápido 

En este modo sólo se permiten modificar aspectos generales del estilo como la paleta de colores general.

Experto

En este nivel es posible modificar un grupo más amplio de propiedades. Así mismo estas propiedades se pueden clasificar por categorías: colores, dimensiones, fuentes, imágenes…

CSS

En este modo, se pueden añadir nuevas propiedades CSS que se priorizarán por encima de las definidas por defecto (css).

Sin duda con UI Theme Designer para SAP Fiori, ya no hay excusas para no personalizar y adaptar la interfaz de usuario de las aplicaciones SAP a la imagen corporativa de tu empresa.

El próximo 24 de Junio de 2016 (viernes), Oreka IT organiza una jornada de ponencias que tendrá lugar en la Cámara de Comercio de Álava, Vitoria-Gasteiz. En ella contaremos con la participación de varios expertos en consultoría informática SAP para exponer las últimas novedades en tecnología de gestión del ámbito empresarial. Algunos de los temas centrales girarán en torno a SAP HANA, el Análisis predictivo y Business Intelligence.

Básicamente se trata de un evento en el que hablaremos sobre innovación, y donde trataremos de responder a esta pregunta:

¿Cómo podemos optimizar la explotación de nuestra compañía mediante la tecnología in-memory de SAP?

El evento comenzará con la recepción de los invitados a partir de las 9:00 de la mañana, y tras las ponencias, habrá un lunch para todos los asistentes donde se podrá charlar y compartir opiniones.

El número de invitaciones es reducido, por lo que te recomendamos que confirmes tu asistencia ya enviando un e-mail a orekait@orekait.com con el asunto “Confirmación de asistencia a evento 24J”.

Orden del día

• 9.30: La importancia de la transformación digital en el ámbito corporativo
  • Pau Pujol-Xicoy
    SAP Account executive
• 9.45: SAP HANA. Introducción y visión global
  • Jose Carasa
    Director de productos SAP e Innovación
• 10.30: SAP BW powered by SAP HANA: Nuevos conceptos y posibilidades
  • Ekaitz Santiago
    Responsable de área Business Intelligence
• 11.15 – Pausa para café
• 11.45: SAP Predictive Analytics. Explicación teórica y caso práctico
  • Josu Ircio
    Consultor Análisis Predictivo
• 12:30: Cuadros de mando
  Design Studio 1.6.
  • Ángela Blanco
    Consultor SAP Business Intelligence
  • Borja Pérez
    Consultor SAP Business Intelligence
• 13.15: Lunch

Salón de actos de la Cámara de Comercio e Industria de Álava
C/ Dato 38, 01005 Vitoria-Gasteiz, Araba+

Si en el artículo de la semana pasada: “WD4A: Atributos del controlador” os enseñaba el manejo de los atributos del controlador, en este artículo vamos a hacer un pequeño resumen de todos los métodos del controlador, sus características y funcionalidades.

En la programación Web Dynpro for ABAP cada controlador tiene un número de métodos predefinidos, que son llamados por el WD Runtime en un orden predefinido. Estos son los llamados métodos HOOK. Todos estos métodos vienen vacíos, y se puede implementar el código que el programador desee.

Métodos comunes

Hay dos métodos que existen en cualquier controlador de una aplicación WD4A. Ya sea el controlador del componente, de una vista, de una ventana o un controlador custom, siempre aparecen y se ejecutan estos dos métodos:

• WDDOINIT: es el método que podríamos denominar como el constructor del controlador. Se ejecuta siempre la primera vez que se accede al controlador, es decir cuando se crea, y solo se ejecuta una vez. Recomendable para inicializaciones.
• WDDOEXIT: es como el destructor de la clase. Se ejecuta siempre que se destruye el objeto del controlador, por ejemplo cuando se cierra un pop-up, o cuando se cierra la ventana del navegador. Se suele utilizar para eliminar bloqueos.

Métodos del component controller

En todos los componentes WD4A existe un controlador propio, que es referenciado en todos los controladores que cuelguen del mismo componente. Este controlador, a parte de los comunes, tiene los siguientes métodos:

• WDDOBEFORENAVIGATION: método que se ejecuta antes de que comience una navegación entre vistas, es decir, cuando algún plug se ha disparado. Se suele utilizar para dar preferencias a los eventos de navegación.
• WDDOPOSTPROCESSING: este método se utiliza para la validación de datos cruzados de componentes. Cuando en un componente se reutilizan otros, es conveniente validar los datos de los componentes reutilizados.

Estos dos métodos tienen como parámetro un booleano llamad IS_CURRENT_ROOT. Como estos métodos se utilizan en todos los controladores de componentes, si estamos reutilizando varios, es necesario saber si el método que se está ejecutando es el que corresponde al propio controlador que está ejecutando la aplicación y no a uno reutilizado. Para ello sirve este parámetro.

Métodos de los controladores de vista

En cada vista que creemos en un componente, podremos utilizar los siguientes métodos hook:

• WDDOBEFOREACTION: Método que se ejecuta antes de que se lance una acción.
• WDDOAFTERACTION: Método que será ejecutado justamente después de que haya finalizado una acción. Si tras la ejecución de varias acciones queremos hacer algo siempre, como puede ser un refresco, conviene programarlo en este método.
• WDDOMODIFYVIEW: Método que sirve para modificar la interfaz de usuario por código.
• WDDOONCONTEXTMENU: Método que permite modificar el menú contextual de la vista mediante código ABAP. Este método es llamado justo antes que el layout sea renderizado y permite acceder a la jerarquía del menú contextual para poder modificarlo en tiempo de ejecución.

Métodos de los controladores de ventana

Para poder mostrar una vista, es necesario que una ventana la albergue para mostrarla a la hora de ejecutar una aplicación. Las ventanas, tienen como métodos predefinidos:

• WDDOONOPEN: es parecido al WDDOINIT, y se ejecuta siempre que se abra la ventana en la aplicación.
• WDDOONCLOSE: similar al WDDOEXIT, se ejecuta siempre que se cierre la ventana.
• HANDLEDEFAULT: este no es un método Hook como tal, pero por defecto está siempre en cualquier ventana que creemos. Es el evento que corresponde al plug por defecto que se crea en la ventana, y se ejecuta siempre que se acceda a la ventana.

Métodos definidos por el programador

Los métodos descritos arriba son los que ya vienen por defecto en los diferentes controladores del componente. A parte de esos, obviamente se pueden crear tantos métodos del controlador como sean necesarios. Lo que hay que tener en cuenta para crear un nuevo método es el tipo de método:

• Method: método normal, que deberá ser llamado utilizando la referencia al controlador (WD_THIS) para que se ejecute.
• Event Handler: este tipo de métodos son los manejadores de eventos, y se ejecutan cuando recogen un evento que se haya lanzado. Por ejemplo al ejecutar una acción o al dispararse un plug. De este tipo se crean automáticamente cuando definimos una acción en el controlador o creamos un inbound plug.
• Supply Function: son los métodos que se ejecutan cuando se intenta leer un nodo que no tiene datos, si en las propiedades del nodo se indica un método de este tipo.

Con este artículo ya tenéis la base para poder implementar vuestros propios métodos del controlador para cualquier aplicación Web Dynpro for Abap.

En este artículo se hará una introducción a los servicios de solicitud de absentismo y calendario de equipo, desde el portal SAP, tanto en ESS como MSS.

Solicitud de absentismo desde el portal SAP

Cada vez más empresas implementan el servicio de solicitud de vacaciones (permitiendo una planificación a futuro de las personas que van a estar disponibles en un periodo de tiempo).

Los aspectos básicos de parametrización de este servicio son:

• Configuración de grupo de reglas
• Definición de proceso de tratamientos para cada grupo de reglas
• Determinación de proceso de tratamiento para cada tipo de absentismo
• Mensajes de salida y notificaciones

De tal forma que es posible parametrizar diferentes tipos de absentismos, workflows de aprobación, etc. en función del tipo de empleado. Todas estas configuraciones se explicarán en futuros artículos.

Toda la parametrización relacionada con el servicio de solicitud de absentismo se realizará a través de la siguiente ruta:

Gestión de personal → Employee Self-Service (Web dynpro ABAP) → Horarios de trabajo

Servicio de calendario de equipo desde el portal SAP

Un complemento muy importante es el servicio de Calendario de equipo en solicitud de absentismo y en Manager Self Service (MSS). Este servicio permite a un empleado ver el calendario de absentismos y/o viajes aprobados que tienen sus compañeros, para poder coordinarse con ellos, así como a un manager, poder obtener dicha información de un solo vistazo.

Los aspectos básicos de parametrización de este servicio son:

• Configuración de grupo de reglas
• Determinar absentismos a visualizar
• Determinación de grupos de colores
• Configurar vista de selección de empleados

Toda la parametrización relacionada con el servicio de solicitud de absentismo se realizará a través de la siguiente ruta:

Gestión de personal → Employee Self-Service (Web dynpro ABAP) → Horarios de trabajo

Esta es la introducción al servicio de solicitud de absentismo y calendario de equipo desde el portal SAP. En próximos artículos, explicaré más a fondo las configuraciones relacionadas con estos dos servicios.

Recientemente hemos conocido que SAP ha sido una de las primeras empresas tecnológicas en ser reconocida por su política de igualdad de género. El Proyecto de Igualdad de Género (The Gender Equality Project) ha recibido un certificado que reconoce los resultados obtenidos en la integración de la mujer en este sector, el tecnológico, tradicionalmente masculino.

Aprovecho esta nueva entrada en nuestro blog para hablar de la igualdad de oportunidades entre mujeres y hombres en la empresa y cómo aplicaciones como Business Intelligence pueden ayudar en este objetivo.

En las últimas décadas, la presencia de la mujer en el mundo empresarial se ha incrementado notablemente. No obstante, dicha incorporación ha estado sujeta a grandes obstáculos, que nos distancian de una igualdad de oportunidades real y efectiva en ámbito laboral :

• Brecha salarial
• Concentración de las mujeres en determinados puestos de trabajo
• Escasa presencia de mujeres en cargos directivos
• Dificultades para la conciliación
• …

Normas

Con el fin de superar dichas realidades, la Ley Orgánica 3/2007, de 22 de marzo, para la Igualdad efectiva de Mujeres y Hombres establece “la obligatoriedad de las empresas privadas de más de 250 personas trabajadoras de negociar un plan de igualdad y el fomento de la elaboración y aplicación de los planes de igualdad de forma voluntaria en los demás casos”. La Ley 4/2005, de 18 de febrero, para la Igualdad de Mujeres y Hombres suma a esta obligación a las empresas participadas mayoritariamente con capital público.

Metodología

La metodología para aplicar dicha norma debe tener dos bases. Por un lado, el diagnóstico de situación de la empresa y, posteriormente, el propio plan para la igualdad.

En esta tarea, la publicación de Emakunde- Instituto Vasco de la Mujer relativa al diagnóstico y planes de igualdad  es la referencia para poder implementar un plan de igualdad de forma adecuada. En dicha publicación se destacan indicadores que dan valores numéricos con el fin de proporcionar información sobre el grado de igualdad en cada una de las situaciones.

• Indicadores internos:
  • Plantilla
  • Condiciones laborales
  • Gestión empresarial
  • Opinión
  • Diagnóstico externo
• Indicadores externos:
  • Compras
  • Comercialización
  • Precio
  • Comunicación corporativa
  • Publicidad
  • Información

Igualdad y Business Intelligence

Por otra parte, para realizar un seguimiento correcto de un plan de igualdad (Art. 40 punto 2 de la ley 4/2005, de 18 de febrero) implica disponer de una serie de datos que podamos explotar, analizar y representar en forma de informes.

En este sentido, Business Intelligence es una herramienta muy adecuada de cara a tener todos los datos relacionados con este seguimiento del plan de igualdad, y nos permite explotar los mismos para obtener informes visuales e intuitivos que nos den una información clara y precisa del estado de la política de igualdad en una empresa o institución.

Hacer una apuesta decidida por la igualdad  poco a poco se empieza a consolidar como cultura de empresa. Estas políticas de igualdad de oportunidades permiten la equiparación justa entre las personas, contribuyen al aprovechamiento del talento, aumentan la motivación y el compromiso con el trabajo.

Como vemos, SAP ha hecho una apuesta decidida a favor de estas políticas de igualdad en el ámbito laboral, además de poner a disposición  tanto de  empresas como  instituciones de un abanico de herramientas Business Intelligence que nos permiten estructurar los datos de forma ordenada y explotarlos de cara a la consecución exitosa de los hitos en dichas políticas.

Por lo tanto, podemos decir que en el mundo SAP,  igualdad y Business Intelligence van juntas de la mano .

En el artículo de hoy, os enseñaremos cómo crear un indicador de retención de impuestos en SAP.

Es común que cada año el estado defina unos nuevos tipos de retención, ya sea en actividades profesionales, autónomos, alquileres… Para el cálculo de estas retenciones en SAP FI se utilizan los indicadores de retención de impuestos. Aprenderemos cómo definirlos para su posterior uso.

Los indicadores de retención se agrupan por país, así que en cualquier acción que realicemos el sistema nos pedirá que introduzcamos el país a tratar.

Tipo de retención de impuestos

Lo primero de todo, es definir el tipo de retención. SAP FI permite crearlos de dos tipos, para contabilización en factura, o para contabilización en el pago (por ejemplo un anticipo). Para definir el tipo que nos convenga seguiremos la siguiente ruta dentro de la IMG de SAP.

IMG-> Gestion Financiera(nuevo)->Parametrizaciones básicas de gestión->financiera(nuevo)->Retención de impuestos->Retención de impuestos ampliada->Cálculo->Tipo de retenciones

En cualquiera de los dos casos, entramos en la pantalla y pulsamos entradas nuevas para crear un nuevo tipo de retención. Rellenamos el tipo de retención (dos caracteres) y el nombre que queramos. También podemos definir el importe base para el cálculo y la regla de redondeo.

Indicador de retención de impuesto

El siguiente paso es definir el indicador de retención del impuesto. Con esta acción, definiremos el porcentaje a retener cuando se utilice el indicador.

IMG-> Gestion Financiera(nuevo)->Parametrizaciones básicas de gestión financiera(nuevo)->Retención de impuestos-> Retención de impuestos ampliada->Cálculo->Indicador de retención->Definir indicador de retención de impuestos

En esta pantalla le damos un nombre al indicador, y definimos la parte sujeta a retención y el tipo de retención.

Ya hemos comentado que los indicadores son definidos por país. Por eso es necesario asignar esos indicadores a la sociedad donde se quieran utilizar. También será necesario activar la retención de impuestos ampliada en la sociedad de trabajo. Esto se puede realizar siguiendo la ruta:

IMG-> Gestion Financiera(nuevo)->Parametrizaciones básicas de gestión financiera(nuevo)-> Retención de impuestos-> Retención de impuestos ampliada->Sociedad

Ajustes de contabilidad

Por último, será necesario identificar las cuentas de mayor donde se quieran contabilizar estas retenciones. Para ello:

IMG-> Gestión Financiera(nuevo)->Parametrizaciones básicas de gestión financiera(nuevo)-> Retención de impuestos-> Retención de impuestos ampliada->Contabilización->Cuentas para la retención de impuestos->Almacenar cuentas para la retención de impuestos a pagar

Elegiremos el plan de cuentas que estemos utilizando, y asignaremos los diferentes indicadores que hayamos creado, con sus tipos de retención a una cuenta de mayor de nuestro plan de cuentas.

Así es como se crea el indicador de retención de impuestos en SAP FI. Con estos pasos, ya podremos trabajar con las retenciones de impuestos y asignarlas en el maestro del proveedor que tenga una retención de impuestos. Esto hará que al contabilizar las facturas o pagos, el sistema calcule las retenciones correspondientes automáticamente.

Desde un tiempo atrás, para actualizar un sistema SAP, ya sea ABAP o JAVA, se lanzó el paquete: Software Update Manager (SUM), que remplazaba el EHP Installer (ABAP) y el JSPM (JAVA).

En las primeras versiones del SAP SUM se iniciaba un servicio al que había que conectarse utilizando un plugin JAVA accediendo a la dirección:

http://<hostname>:4239.

Con el lanzamiento de las nuevas versiones de la herramienta  SAP SUM, el modo de acceso utilizando JAVA y el puerto 4239 ha de ser válido y se muestra el siguiente mensaje:

Configuración de SAP SUM

A partir de la versión SUM15 para iniciar el programa de actualización hay que seguir los siguientes pasos:

1. Instalar la última versión del SAP Host Agent
2. Descargar la última versión disponible del paquete SUM
3. Descomprimir el SUM. Se recomienda hacerlo en la ruta /usr/sap/<SID>/SUM que es donde el script de configuración espera encontrar el software.
4. Lanzar el script de inicio con los nuevos parámetros:
   # ./STARTUP confighostagent <SID>

Es conveniente hacerlo con el usuario root, porque se actualizan ficheros del directorio del saphostagent: /usr/sap/saphostagent

Este es un ejemplo de la ejecución del script:

Acceso GUI

Tras configurar el SAP SUM se muentran distintas URLs para actualizar los distintos tipos de sistemas: JAVA, ABAP, Dual stack, acceder como observador, …

Para acceder por http hay que utilizar el puerto 1128 y para https 1129.

JAVA     https://<hostname>:1129/lmsl/sumjava/<SID>/index.html
ABAP     https://<hostname>:1129/lmsl/sumabap/<SID>/doc/sluigui
Dual       https://<hostname>:1129/lmsl/sumjava/<SID>/dual.html
Observer https://<hostname>:1129/lmsl/sumobserver/<SID>/monitor/index.html

Al acceder a las URLs el servidor pide autenticación con el usuario administrador de la instancia:

Una vez se accede, se muestra la nueva interfaz de SAP UI5 donde se puede iniciar todo el proceso de actualización que comienza pidiendo un fichero .xml con un stack de parches:

Este ha sido un pequeño resumen sobre el nuevo modo de acceso GUI utilizando las nuevas versiones de SAP SUM. Si quieres seguir investigando, te dejamos un enlace con más información sobre el SUM SP 15.

En este artículo se explicará cómo cargar infotipos estándar de OM, en SAP HCM.

SAP dispone de un programa estándar para cargar algunos infotipos estándar de OM llamado RHALTD00. Los infotipos de workflows (del infotipo 1200 al 1299) no se pueden cargar mediante este programa y por ello, vamos a explicar cómo hacerlo de forma manual.

La estructura del fichero de carga verifica si en la tabla T777D existe una estructura de segmento IDOC (E1P****) para determinar los campos del fichero; en caso contrario se basa en la estructura estándar para el infotipo (P****).

Tipos de ficheros

A la hora de elegir el fichero a cargar podemos elegir entre dos tipos: Ficheros Lógicos y ficheros físicos:

Fichero lógico

Se parametriza un ID del fichero lógico, donde indicaremos la ruta física donde se guardará el fichero a cargar.

Fichero físico

Indicaremos la ruta física donde se ha guardado el fichero con la información a cargar.

Este programa generará un juego de datos que puede ejecutarse directamente (marcando la opción) o mediante el tratamiento del Batch-input (Sistema -> Servicios -> Batch input ó T-Code: SM35). El nombre del juego de datos lo indicaremos en el campo: Carpeta

Además indicaremos el usuario que genera el juego de datos; así como si es una ejecución en real/test y si queremos que el juego de datos se quede guardado (marcaremos la opción “Retener carpeta procesada”) una vez procesado.

Ejemplo carga Infotipo 1018

Comprobamos si existe la estructura E1P****:

Generaremos un fichero con esa misma estructura:

Se muestro un resumen de lo que se va a cargar. Podremos ejecutar la carga directamente desde aquí seleccionando “Ejecutar juego datos” ó “Procesar carpeta”:

Simplemente quedaría seleccionarlo y pulsar “Ejecutar”.

Así es como se deben cargar infotipos estándar de OM en SAP HCM, de manera manual.

En la gestión de finanzas, es muy común que surjan diferencias entre pagos y cobros de facturas. En el siguiente artículo, vamos a mostrar como parametrizar y cómo usar esta funcionalidad en SAP FI.

Es posible que al hacer un pago o un cobro de una factura de un proveedor o cliente, el importe no coincida en una pequeña cantidad. Estas diferencias en el importe se deben imputar a cuentas de gasto o ingreso.

Parametrización del origen de diferencias

Lo primero a parametrizar es el origen de diferencias, donde denominaremos el tipo de diferencias que queramos. Para ello debemos seguir la siguiente ruta dentro de la IMG de SAP FI.

Gestion financiera(nuevo) -> Contabilidad de deudores y acreedores -> Operac.contables -> Salida de pagos -> Salida de pagos manual ->Diferencias de pago ->Definir origen de diferencias.

Primero indicaremos la sociedad de trabajo y a continuación aparecerá la siguiente pantalla:

En esta listaremos el tipo de diferencias que queramos definir. En este ejemplo vamos a parametrizar una diferencia por tipo de cambio. Para ello debemos indicar un identificador de dos caracteres y dos textos, uno breve y otro explicativo.

El siguiente paso será definir las cuentas de mayor donde se deben imputar estas diferencias automáticamente. Salimos de esta pantalla y vamos a la siguiente ruta de la IMG:

Gestion financiera(nuevo) -> Contabilidad de deudores y acreedores -> Operac.contables -> Salida de pagos -> Salida de pagos manual -> Diferencias de pago ->Almacenar cuentas p.diferencias pago.

En esta pantalla, primero indicaremos el plan de cuentas de nuestra sociedad y veremos una pantalla como la que sigue:

Aquí, lo que tendremos que indicar es la clave del origen de diferencias que hemos indicado en la pantalla anterior y las cuentas donde se imputará esta diferencia, dependiendo de si es en el debe o en el haber para cuadrar el asiento.

Con esto ya tendremos parametrizado un origen de diferencias en SAP FI.

Ejemplo de uso

Para mostrar cómo funciona, vamos a ver un ejemplo al pagar una factura de proveedor. Tenemos una factura de proveedor de 1.000€.

Al pagarla con un pago manual (F-53), metemos 1.005€, ya que es lo que hemos tenido que pagarle al proveedor.

Cuando entramos a las partidas abiertas del proveedor, elegimos la de 1.000€. Como faltan 5€ por asignar, vamos a la pestaña de pago parcial o partida por el resto. En el campo Razón (Raz) pulsamos la ayuda de búsqueda.

Elegimos una de las opciones parametrizadas como origen de diferencias SAP FI. Tras seleccionar una y darle a simular, el sistema llevará esa diferencia a la cuenta que se haya parametrizado, según sea un ingreso o un gasto, para cuadrar el asiento. Se puede ver como eso s5€ de diferencia lo lleva a la cuenta de gasto que hemos parametrizado, ya que hemos pagado de más por la factura.

Así es como se parametriza el origen de diferencias en SAP FI para la gestión de la contabilidad.

2015. urteko otsailean, SAP-ek negozio kudeaketen aplikazioen suite bertsio berria atera zuen. Suite hau, SAP HANA plataforman sortu da, honek eskaintzen dituen aukera aurreratu guztiekin. SAP S/4HANA, SAP-ek SAP R/3-tik egiten duen berrikuntzarik handiena da.

Zer da SAP HANA?

Azken belaunaldiko negozio kudeaketa integralaren aplikazio informatikoen suite da. SAP HANA plataformaren gainean garatutako produktu berria da, azken hau, egun dagoen in-memory prozesatzerik aurreratuena egiteko ahalmena duen eta gainera, erabiltzaileak SAP Fiori-rekin duen esperientzia optimizatzeko, SAP-en azken berrikuntzak bere gain hartzen dituen plataforma da.

SAP S/4HANA-k, prozesuen kudeaketan sinplifikazio handia eskaintzen du (datuen eredua, erabiltzaile berrien esperientzia, erabakiak hartzean, ereduak eta negozio-prozesuak) eta teknologia berrikuntzekin bat egiten du (Internet of Things, Big Data, Business Networks, mugikortasuna).

SAP S/4HANA, ekonomia digitala eta Industria 4.0 eredua sustatzeko eraikitako kudeaketa tresna dela esan dezakegu.

Nondik dator SAP S/4HANA izena?

SAP S/4HANA, SAP Business Suite 4 Hana-ren laburdura da. Berrikuntza kantitate izugarria aurkezten ditu eta teknologiaren ikuspuntutik, SAP R/3-tik SAP R/4-ra egin zen aurrera pausua baino salto handiagoa da.

Ezartzeko zer aukera daude erabilgarri?

SAP partner-ak on-premise ezarpen-ereduak eskaintzen dituzte, hodeian eta eredu hibridoetan. Ezarpen eredu hauek guztiek merkatuan eskuragarri daude.

SAP S/4HANA-ren gakoak

• Datuak gordetzeko eta data footprint azpiegitura murritzagoa (erabiltzaileak utzitako aztarnen datuak).
• Prozesuen arteko bateratze handiagoa
• Ikerketa eta ekarpen azkarragoak
• Prozesuen kudeaketan erraztasuna
• ERP, CRM, SRM eta PLM moduluen inplementazio bateratua
• Eguneratutako datuen (%25) eta datu historikoen (%75) bizikidetza
• Datuak kargatzeko muga gabeko ahalmena
• Aurreikuspen, eredu eta simulazioak erraz egiten ditu
• SAP HANA joera anitzetan: aplikazio ezberdinen zerbitzari den azpiegitura bakarra, aldi berean, bezero, erakunde eta abar ezberdinetarako balio duena ere
• Mota anitzeko datuak: sozialak, testuak, zenbakiak, geografikoak, prozesuak, eta abar
• Edozein mugikortasun gailurekin integratzea
• Norbanakoen nahierara moldatzen den ezarpen eredua

Hauek dira SAP S/4HANA-ren gakoak, SAP taldearen negozio suite-ik berritzaileena.

Informazioa gazteleraz eskutratu nahi baduzu egin klik hemen.

Para obtener la información en castellano, visita nuestra entrada sobre SAP HANA.

En este artículo se explicará cómo configurar un grupo de reglas para el servicio de solicitud de absentismos (Leave Request) en SAP R/3.

Como se indicó en el artículo, Portal SAP: Solicitud de absentismo y calendario de equipo, existen 4 aspectos básicos en la parametrización de este servicio:

• Configuración de grupo de reglas
• Definición de proceso de tratamientos para cada grupo de reglas
• Determinación de proceso de tratamiento para cada tipo de absentismo
• Mensajes de salida y notificaciones

En este artículo se explicará cómo hacer la configuración de grupo de reglas.

Se accederá a la parametrización mediante la siguiente ruta:

Gestión de personal → Employee Self-Service (Web dynpro ABAP) → Horarios de trabajo → Notificación de absentismo → Tratar procesos

Configuración de grupo de reglas

Mediante las reglas, se puede identificar qué normas deben tener diferentes grupos de empleados con respecto a la solicitud de absentismos. Se crearán tantas reglas como casuísticas existan.

Existen dos tareas a realizar:

• Crear las diferentes reglas
• Asignarlas a los grupos de empleados mediante la característica WEBMO

Una vez creado el grupo de reglas, quedará algo similar a la siguiente imagen:

Después, se accede a la característica WEBMO para identificar el grupo de empleados a los que asignar dicha regla:

La estructura que utiliza esta característica es la PME95 que contiene los siguientes campos de selección y con los que se podrá definir para que tipo de empleado se asigna cada grupo de reglas:

En siguientes artículos, publicaremos cómo parametrizar los diferentes absentismos según grupo de reglas y la configuración de workflows y características para cada uno de ellos.

El paisaje corporativo sufrió una transformación radical desde que Internet tomó un papel protagonista en la forma de llevar a cabo las comunicaciones, además de ofrecer un universo de información al que hasta entonces éramos ajenos.

Gracias a Internet, podemos disponer desde un infinito abanico de contenidos audiovisuales a itinerarios formativos a medida, y es en este paradigma donde el Social Selling cobra más sentido que nunca y establece una nueva forma de venta.

En cierto sentido, Internet se ha convertido en una especie de sexto sentido del que dependemos para no sólo llevar a cabo nuestros trabajos, sino para ser conscientes de que socialmente existimos.

Dinosaurio: Alec Baldwin en “Glengarry Glen Ross”, una película de comerciales pre-Internet.

Social Selling: Concepto

Para muchos comerciales y desarrolladores de negocio el Social Selling ha pasado de ser “otro enfoque” a “el enfoque”. Gracias a las redes sociales, se puede contactar con cualquier persona que tenga presencia social (recordemos: si no figuras en Internet, no existes) y saber de un vistazo sus necesidades e inquietudes.

Antes, la industria dependía de los comerciales para educar al cliente potencial en nuevos servicios y productos. Ahora, el cliente potencial ya ha recorrido buena parte del camino:  antes de ponerse en contacto con un comercial, ya tiene la mayor parte de la información del producto o servicio que necesita.

En esto ha consistido buena parte de la revolución de Internet: ha puesto el conocimiento en manos de los consumidores, directamente y sin intermediarios. Esto es porque Internet provee con un modelo que es más rápido y eficiente, así de simple.

Dicho esto, definamos qué es Social Selling: Social Selling es cuando los profesionales de ventas usan redes sociales para ponerse en contacto directo con sus clientes potenciales, sus prospectos. Los profesionales de venta proveen valor al prospecto analizando sus problemas, respondiendo sus dudas y dándole soluciones a medida hasta que el prospecto se decide a comprar.

Social selling y las nuevas tecnologías de comunicación

En resumen, el profesional de la venta se apoya en las nuevas tecnologías de comunicación para aportar valor al posible cliente a través del conocimiento. Tenemos que añadir que, en la situación actual, los profesionales comerciales ya no generan procesos de venta, sino que participan en procesos de compra.

Echemos ahora un vistazo a algunos datos relativos a Social Selling:

1. El 77% de las compañías B2C (Negocio a Consumidor) han conseguido clientes a través de Facebook.
2. El 61% de las empresas B2B (Negocio a Negocio) usan plataformas sociales como LinkedIn para aumentar su cuota de leads.
3. El 74% de las empresas B2B usan Twitter para difundir contenidos y noticias.
4. IBM tuvo un incremento de ventas del 400% al participar en un programa piloto de Social Selling.

Vemos pues que la figura del comercial agresivo y dicharachero de metodología “abc” (always be closing) es cosa del pasado, casi tanto como competir sólo a precio. Los nuevos tiempos piden profesionales de venta cualificados, que sepan dar respuestas expertas a sus posibles clientes con el apoyo de un equipo especialista y que se apoyen en las nuevas tecnologías para crear leads.

Por último, es bastante elocuente que empresas como IBM apuesten por este nuevo modelo de hacer ventas. Si tu empresa todavía no ha abordado el concepto de Social Selling, redes como LinkedIn, Xing o cowork.OS, esta última enfocada a las sinergias entre emprendedores, pueden ser buenos lugares donde empezar.

Cuando hemos creado una nueva sociedad de SAP Controlling, uno de los primeros pasos que debemos hacer es dar de alta las clases de coste SAP. Este proceso puede ser muy costoso si lo realizamos manualmente, ya que puede que haya que crear más de 100 clases de coste. Por ello, en este sencillo artículo aprenderemos a crear clases de coste automáticamente.

En la siguiente ruta, tendremos los tres pasos necesarios para realizar la carga masiva de clases de coste:

Controlling->Contabilidad de clases de coste->Datos maestros->Clases de coste->Crear clases de coste primario y secundario automáticamente

Parametrización de las clases de coste

En la parametrización previa definiremos qué clase de coste SAP se creará con cada rango de cuentas contables, de un plan de cuentas que indiquemos. Por ejemplo, para el plan de cuentas español, las cuentas 6 son de gastos y las cuentas 7 de ingresos, por lo que deberemos indicar que el primer rango serán clases de coste de tipo 1 y el segundo de tipo 11.

Creación y ejecución del juego de datos

En el siguiente paso, crearemos un juego de datos para que ejecute la creación de todas las clases de coste. Deberemos indicar los siguientes datos:

• La sociedad  SAP CO que hemos creado, donde se darán de alta las clases de coste.
• La validez de las mismas.
• Un nombre y usuario para identificar el batch input.

El último paso, será ejecutar el batch input que hemos preparado. Accediendo por la ruta indicada arriba o por la transacción SM35, veremos que se ha creado el juego de datos.

Tras ejecutarlo y si todo ha ido correctamente, habremos creado una clase de coste primaria por cada cuenta de mayor de gasto e ingreso que tengamos dadas de alta en nuestra sociedad FI.

Con estos tres sencillos pasos, ya podremos crear clases de coste en SAP CO de manera automática.

En instalaciones SAP sobre GNU/Linux, en función de la versión del kernel del sistema operativo, al iniciar sesión con SAPGui, puede aparecer un mensaje de error indicando que el demonio UUID no está activo:

En este artículo vamos a tratar el error  de demonio no activo que en ocasiones puede aparecer en SAP Linux UUID.

Diagnóstico del error UUID

El error de demonio UUID no activo, se produce con las versiones de kernel más recientes de SAP. Se aconseja revisar la nota SAP 1391070 para solucionar el problema antes de continuar utilizando el sistema SAP.

Para diagnosticar el problema, en la nota mencionada se adjunta un script para verificar el estado del demonio UUID:

Si no está ya instalado, se instala el paquete UUID desde el repositorio correspondiente a la distribución de nuestro sistema operativo:

Arranque de servicio y chequeo final

Una vez instalado el paquete UUID, debemos iniciar o arrancar el servicio:

Una vez iniciado el demonio, el chequeo tras ejecutar el script proporcionado en la SAP note es correcto, y nos aparecerá un mensaje como el que vemos a continuación:

Ya no se muestra el mensaje de error del SAPGui anterior y de hecho, si accedemos a la transacción SICK veremos que ya, no aparecen errores:

Para más información, se recomienda visitar esta página; 1391070 – Linux UUID solutions

Con estas sencillas instrucciones, podemos solucionar el error de demonio UUID no activo que puede aparecer con las últimas versiones del kernel de SAP Linux.

SAP dispone de diferentes queries estándar, que nos pueden resultar de mucha utilidad en nuestros procesos y aplicaciones. En este artículo, se explicarán dos de esas queries SAP, en esta ocasión ambas se utilizan para visualizar datos de un viaje:

• S_AHR_61016401 – Datos marco viaje/Totales viaje
• S_AHR_61016405 – Datos marco viaje/Tot./Docum./Costes

La principal diferencia entre estas dos queries SAP, es que la segunda de ellas (S_AHR_61016405), incorpora datos de costes relacionados al viaje y se muestran todos los datos diferenciados en tres bloques en la misma pantalla.

S_AHR_61016401 – Datos marco viaje/Totales viaje

La pantalla de selección, nos permite filtrar tanto por datos del empleado, como por datos correspondientes al viaje (número de viaje, fechas, estados, importes…):

Los resultados se muestran en una línea por cada viaje de un empleado; pudiendo seleccionar un viaje y eligiendo una de las opciones siguientes:

• Viaje -> Nos abre la transacción PR05 para visualizar el viaje.
• Comprob.viaje ->Muestra las clases de gasto introducidas para este viaje.
• Asignación costes -> Muestra un resumen de los datos de costes relacionados.
• Vis.lista bloq.viaje ->Muestra un resumen del viaje (similar a la siguiente queri explicada).

S_AHR_61016405 – Datos marco viaje/Tot./Docum./Costes

La pantalla de selección nos permite filtrar, tanto por datos del empleado, como por datos correspondientes al viaje (número de viaje, fechas, estatus, importes, clases de gastos específicas…):

El resultado mostrado se diferencia en 3 bloques:

Resumen datos del viaje

Aquí se indica de forma resumida los datos generales del viaje: fechas, importes desglosados por dietas, alojamiento, estado en el que se encuentra el viaje, etc. Se puede modificar el layout mostrado para mostrar diferentes campos.

Clases de gasto

En este bloque se indican las diferentes clases de gasto introducidas para cada uno de los viajes:

Asignación de costes

En este último apartado se muestra un resumen de la asignación de costes relacionada al viaje:

Estas son las dos queries SAP, para la visualización de gastos de viaje.

Al desarrollar una nueva aplicación SAPUI5 una de las cosas que debemos pensar es cómo queremos estructurar dicha aplicación, y por tanto, qué controles SAPUI5 vamos a necesitar.

Los controles SAPUI5, son los elementos de interfaz de usuario con los que se va a llevar a cabo la interacción, ya sea de una manera pasiva o activa. En este artículo, vamos a estudiar y dar ejemplos de algunos de esos controles de una aplicación SAPUI5.

Actualmente existen infinidad de controles distribuidos en las diferentes librerías SAPUI5 (sap.ui.commons, sap.m…). En este artículo, sólo vamos a introducir algunos de ellos, pero es posible encontrar todo tipo de información útil sobre propiedades, eventos y agregaciones relacionada con cada control SAPUI5 en los siguientes enlaces:

• https://sapui5.hana.ondemand.com/#content/Controls/index.html
• https://sapui5.hana.ondemand.com/explored.html#

La forma de crear un control SAPUI5 dependerá del tipo de vista que se esté creando (XML, JS, JSON, HTML…) o de si el control se ha creado en el controlador de la vista, en cuyo caso siempre se creará mediante JS. En este artículo mostraremos algunos ejemplos usando XML.

Tipos de controles SAPUI5

SAPUI5 ofrece controles de todo tipo, desde los más simples como un Label o un Button hasta los más complejos como mapas geográficos dinámicos o gráficos. La clasificación de controles es la siguiente:

• Controles SAPUI5 simples: Label, Image, Button…
• Controles SAPUI5 para introducir valores: ComboBox, CheckBox…
• Controles SAPUI5 complejos: Table, Form, GeoMap…
• Layouts: Horizontal Layout, Vertical Layout…
• Diálogos: Dialog, Select Dialog, Table Select Dialog…
• Controles UX3: Shell, DataSet, NaviationBar…

Propiedades de controles SAPUI5

Cualquier control SAPUI5 dispone de una serie de propiedades que definen su apariencia en la interfaz. Es conveniente consultar la documentación anteriormente citada, para conocer qué propiedades disponen los distintos controles que queramos utilizar.

Para definir propiedades en XML se utiliza la notación propiedad=”valor” dentro de la etiqueta XML de apertura del control. A continuación, vemos la declaración de un Label (sap.m.Label) y un Input (sap.m.Input).

<Label id="Label1"
text="Ejemplo de Label"
textAlign = "Begin"
required="true"/>
<Input id="Input1"
type="Number"
placeholder="Tu numero"
/>

Eventos en controles SAPUI5

Como se comentaba anteriormente, los controles SAPUI5 son los elementos con el que el usuario interactúa, por esta razón, estos controles pueden reaccionar a diferentes eventos.

Mediante la definición de eventos SAPUI5 se establece cómo se comportará el control. La forma de definir eventos es similar a la forma de definir propiedades, solo que el valor puede ser una función anónima (en el caso de las vistas Javascript) o mediante una llamada a una función del controlador.

A continuación, vemos un ejemplo de definición de evento en un control ComboBox (sap.m.ComboBox) de una vista XML.

<ComboBox selectionChange="onChange">
<items>
<core:Item key="Fiori" text="Fiori"/>
<core:Item key="UI5" text="UI5"/>
<core:Item key="GW" text="Gateway"/>
</items>
</ComboBox>

En el controlador correspondiente deberá estar la implementación del evento en una función llamada “onChange”.

onChange:function(){
alert("On Change");
}

Igual que se ha comentado para las propiedades, para saber a qué eventos reacciona cada control se puede consultar la documentación.

Agregaciones de controles SAPUI5

Gran parte de los controles SAPUI5 tienen propiedades más complejas que las que se han mostrado en el apartado b). A este tipo de propiedades en lugar de asignar un valor concreto se les asigna una colección de valores o de otros controles SAPUI5. Este tipo de propiedades, se denominan agregaciones.

En el siguiente ejemplo, podemos ver la agregación columns en un control SAPUI5 de tipo Table (sap.ui.table.Table), que en lugar de ser un valor simple es una colección de controles de tipo Column (sap.ui.table.Column).

<t:Table id="Tabla1" rows="{path: 'tm>/temario'}">
<t:columns>
<t:Column>
<Label id="col1" text="Col1" />
<t:template>
<Text text="{tm>id}"/>
</t:template>
</t:Column>
<t:Column>
<Label id="col2" text="Col2" />
<t:template>
<Text text="{tm>nombre}"/>
</t:template>
</t:Column>
</t:columns>
</t:Table>

En la tabla anterior aparece el primer caso de DataBinding, en el que se enlaza la agregación rows con un modelo. Este concepto, es clave en el desarrollo de cualquier aplicación SAPUI5 será tratado en próximos artículos.

De momento, con estos conceptos sobre los controles de una aplicación SAPUI5 podemos comenzar a diseñar las pantallas de nuestra aplicación.

En la gestión de personal, contabilizar hojas de gastos puede ser una operación muy común. En este artículo, explicamos cómo hacerlo en SAP HCM.

Para poder contabilizar hojas de gastos, esta tiene que estar aprobada y liquidada previamente. La contabilización consiste en dos pasos:

• Creación de una ejecución de contabilización.
• Procesar la ejecución contable.

A continuación, se explica cómo crear la ejecución de contabilización.

Creación de una ejecución de contabilización

Una vez de que la hoja de gastos está aprobada y liquidada, podemos incluirla en una ejecución de contabilización. Para ello utilizaremos la transacción: PRFI

Esta transacción nos permite filtrar por varios criterios, pudiendo lanzar la ejecución de forma masiva por área de nómina o filtrar hasta por número de empleado y viaje que queramos incluir:

En esta selección deberemos indicar si es una simulación o si es un lanzamiento en real. Las simulaciones NO se podrán contabilizar en el paso siguiente.

En el botón “Datos marco” se deberá indicar la fecha contable a utilizar, la fecha del documento así como la clase de documento a generar.

Una vez ejecutado, se mostrará un resumen indicando por cada empleado las hojas de gasto que se han tenido en cuenta:

En este caso vemos que el empleado tenía una hoja de gastos con importe y varias hojas con importe 0. Todas ellas se incluirán en la ejecución de contabilización  indicada arriba. En este caso el nº: 1316

Este es el primer paso para contabilizar hojas de gastos en SAP HCM. En el siguiente artículo, explicaremos cómo procesar esta ejecución creada.

Si en SAP HCM: Contabilizar hoja de gastos (1 / 2), aprendíamos a crear una ejecución de contabilización, en este artículo se explicará cómo procesar dicha ejecución, para terminar de contabilizar hojas de gastos en SAP HCM.

Procesar una ejecución de contabilización

Una vez que tengamos una ejecución de contabilización creada, el siguiente paso es procesarla, para definitivamente contabilizar hojas de gastos. Para ello, utilizaremos la transacción estándar: PRRW

En la pantalla de selección podremos filtrar tanto por el usuario que haya creado la ejecución contable, como por la fecha de creación; así como por el propio número de ejecución contable:

Una vez ejecutado, veremos un resumen de las ejecuciones que cumplen los criterios:

Si en el primer campo aparece el icono  indica que es una ejecución en simulación; por lo que no se podrá contabilizar.

Para poder contabilizar una de las ejecuciones, seleccionaremos la línea deseada y pulsaremos . Se nos mostrará la siguiente ventana donde deberemos elegir cómo ejecutar la contabilización:

Una vez ejecutado se mostrará un resumen del proceso:

Si se muestra en verde, significará que se ha procesado correctamente; mientras que si hay algún problema se mostrará en Rojo.

Ejemplo de ejecución errónea:

En este caso, la orden asociada a la hoja de gastos está bloqueada, por lo que no se puede contabilizar. Para poder contabilizarla de nuevo; hay que deshacer la ejecución contable:  .

Deberemos arreglar los errores, en este caso abrir la orden o modificar la orden de la hoja de gastos por una orden válida; y volver a crear la ejecución y contabilizarla.

Con este tutorial, ya podremos contabilizar hojas de gastos en SAP HCM.

En este artículo veremos cómo se puede parametrizar un libro de caja para nuestra sociedad.

El libro de caja, es un libro auxiliar donde se registran todas las operaciones al contado que realiza la empresa. Estas pueden ser pagos o cobros en efectivo, u operaciones mediante cheques bancarios. En SAP FI existe la transacción FBCJ, como programa específico para registrar y tener un control más exhaustivo de estas operaciones.

Parametrización libro de caja

Primer paso: Instalar libro de caja

Lo primero que hay que hacer es crear el libro de caja para la sociedad en la que queramos trabajar. Para ello, en la imagen de referencia de SAP navegamos a:

Gestión financiera (nuevo) -> Contabilidad bancaria -> Operaciones contables -> Libro de caja -> Instalar libro de caja.

En esta pantalla, se debe indicar un número de libro de caja (4 caracteres) para la sociedad. En una misma sociedad pueden existir varios libros de caja. También es obligatorio indicar sobre qué cuenta de mayor se realizarán las operaciones contables y la moneda de las mismas. Para el PGCE se debe rellenar una cuenta 570.

Aquí también se puede indicar los tipos de documentos que se deben crear según las operaciones realizadas y además, existe un campo para dar un nombre al libro de caja.

Segundo paso: Actualizar intervalo del libro de caja

El siguiente paso necesario sería indicar un rango de números para los documentos, y para ello accedemos a:

Gestión financiera (nuevo) -> Contabilidad bancaria -> Operaciones contables -> Libro de caja -> Definir intervalo rango números p.documento libro de caja

Elegimos nuestra sociedad y pulsamos el botón de modificar intervalos. Si los queremos copiar de otra sociedad ya existente pulsamos  . Elegimos el rango y guardamos.

Tercer paso: Crear operaciones concretas

Para cada libro de caja de SAP FI, se pueden crear operaciones concretas de ingreso y gasto, habrá que definir cuáles de ellas son un gasto un pago a proveedor, cobro a cliente…

Gestión financiera (nuevo) -> Contabilidad bancaria -> Operaciones contables -> Libro de caja -> Crear, modificar, borrar operaciones contables

Para la sociedad de trabajo, se pueden crear tantas líneas como queramos. Los campos más importantes en esta tabla son:

• Tipo de operación contable (3º):

  C – pago de cuenta bancaria; B – pago a cuenta bancaria; R – ingresos; E – gastos; D – contabilización deudor; K –contabilización acreedor.

• Clasificación de la operación (5º):

  1 – gasto efectivo; 2 – ingreso efectivo o 3 – Ingreso cheques.

• Mayor (6º): Si las operaciones de este tipo queremos que vayan contra una cuenta de mayor en concreto.
• Modificable (10º): Para que esa cuenta que se indique sea fija o se pueda indicar a la hora de realizar la operación.

Cuando ya hayamos definido esta parametrización, es importante que la cuenta que hayamos referenciado para el libro de caja solo sea contabilizable automáticamente. Para esto, vamos a la definición de la cuenta en la sociedad (FSS0) y marcamos la casilla correspondiente:

Una vez realizadas todas estas configuraciones, ya podremos empezar a trabajar con nuestro libro de caja en la transacción FBCJ.

Estos son todos los pasos que debes seguir para parametrizar un libro de caja en SAP FI.

En este artículo aprenderemos a manejar la configuración de SSL en SAP Host Agent.

Con la nueva forma de iniciar y conectarse a la herramienta de actualización, Software Update Manager (SUM), SAP permite conectarse al servidor utilizando una conexión segura cifrada con un certificado SSL. El puerto en el que el SAP hostagent escucha con el protocolo HTTPS, por defecto es el 1129. Aprenderemos por tanto a configurar SAP Host Agent para que utilice el protocolo seguro.

Inicialmente, antes de realizar ninguna configuración adicional, después de instalar el paquete SAP Host Agent, el servidor sólo escucha en el protocolo no seguro (HTTP) y no escucha en el puerto 1129, protocolo HTTPS:

Para realizar la configuración SSL hay que utilizar el programa sapgenpse que se encuentra en los paquetes sapcryptolib y commoncryptolib. Para evitar problemas de seguridad, se recomienda descargar la última versión disponible en el SAP Support Portal: Descarga de la última vesión sapgenpse

Prerrequisitos

Hay que estar conectado con un usuario con permisos root para realizar los siguientes pasos.

Contexto

En este artículo se asume el nombre por defecto para el PSE del servidor. Para cambiar el nombre por defecto se puede usar el siguiente parámetro en el perfil de SAP Host Agent (host_profile):

ssl/server_pse = <ruta al PSE de Servidor>

Procedimiento

1. Inicialmente hay que establecer la variable de entorno SECUDIR para el usuario sapadm. Si el directorio /usr/sap/hostctrl/exe/sec no existe, se crea previamente y se establecen el propietario y grupo:

orekait.com:root> mkdir -p /usr/sap/hostctrl/exe/sec
orekait.com:root> chown sapadm:sapsys /usr/sap/hostctrl/exe/sec
orekait.com:sapadm> setenv SECUDIR /usr/sap/hostctrl/exe/sec

2. Se genera un fichero SAPSSLS.pse

orekait.com:sapadm> sapgenpse gen_pse -p SAPSSLS.pse -r <hostname>.csr "CN=<hostname>.orekait.com,O=SAP AG,C=DE"

3. Con la solicitud de firma se debe obtener un certificado firmado, bien por una autoridad certificadora (CA), o auto-firmando el certificado por uno mismo. El certificado firmado obtenido, se debe importar en el fichero PSE y añadirle credenciales para el usuario sapadm:

orekait.com:sapadm> sapgenpse import_own_cert -p SAPSSLS.pse -c <hostname>.cer -r ca-chain.pem
orekait.com:sapadm> sapgenpse seclogin -p SAPSSLS.pse -O sapadm

4. Reiniciar el SAP Host Agent.

Resultado

Si se el certificado se ha instalado correctamente, el SAP Host Agent escucha en el puerto 1129 el servidor para la comunicación SSL:

Siguiendo estos pasos ya tendremos finalizada la configuración SSL para SAP Host Agent. Para información adicional:

SSL Configuration for the SAP Host Agent