En un artículo anterior explicamos cómo mostrar contenido en diferentes idiomas mediante un iView de tipo URL. Siguiendo con el tema de la traducción, en este artículo vamos a explicar cómo es posible traducir los diferentes objetos del portal de SAP: iViews, páginas, roles, carpetas etc.

Traduciendo los objetos de portal conseguimos definir los textos que se deben mostrar en función del idioma de login a la hora de identificar estos objetos en menús de navegación, masthead, bandejas etc. Es decir, se traducen los nombres de los objetos no el contenido de estos.

La traducción de objetos de portal gira en torno a los pools de trabajo que son contenedores de objetos a traducir que van cambiando de estado durante el proceso de traducción. Los cuatro estados posibles son: “Nuevo”, “Liberado para traducción”, “Traducido” y “Publicado”.

Para llevar a cabo la traducción de objetos de portal hay que acceder a Gestión de contenidos > Traducción de contenido de portal. Desde aquí se visualizarán dos secciones en las que se dividirá el proceso de traducción. Estas dos secciones son las siguientes:

• Coordinación del pool de trabajo
• Traducción de pool de trabajo

La primera parte del proceso se lleva a cabo desde la sección Coordinación del pool de trabajo desde donde crearemos el paquete de objetos de portal a los que se aplicará la traducción.

En primer lugar hay que crear un pool de trabajo. Para ello, en el menú de navegación visible a la derecha del menú de secciones, debemos navegar hasta la carpeta donde se desee crear el pool de trabajo. Sobre ella, abrimos el menú contextual y elegimos la opción Crear >Pool trabajo para iniciar la creación.

El primer paso de esta creación es establecer las propiedades generales del pool de trabajo: nombre, ID, prefijo, idioma maestro y descripción.

Después de confirmar estas propiedades generales, en un segundo paso, debemos seleccionar la opción “Abrir objeto para el tratamiento” para poder así empezar a asignar objetos a traducir al pool de trabajo.

Una vez abierto para su tratamiento, se mostrará en la parte izquierda una lista de objetos (que incluirá al propio pool de trabajo) a la que podremos ir añadiendo objetos a traducir. En la derecha aparecerá la lista de propiedades del pool de trabajo. En este momento, el estado del pool de trabajo es “Nuevo”.

Para añadir objetos, simplemente navegamos a través de las carpetas y seleccionamos el objeto a asignar. Abriendo el menú contextual sobre dicho objeto podremos elegir la opción “Añadir objeto al pool de trabajo” con lo que añadirá dicho objeto a la lista. En este ejemplo, vamos a traducir un conjunto de iViews y páginas sobre los gastos de viaje de la empresa.

Después de añadir todos los objetos a la lista,  se procederá a generar los datos de traducción. Para ello hay que pulsar el botón “Generar datos de traducción” visible en la parte superior.

Una vez generados los datos de traducción, aparecerá la lista de objetos creada a la que ya no será posible añadir más objetos a no ser que se cancele la generación. Por último, en esta primera fase, hay que liberar el pool de trabajo para su traducción. Pasando así al estado “Liberado para traducción”.

Una vez el pool de trabajo se encuentre liberado para la traducción,  aparecerá un mensaje similar al siguiente informando de que no se pueden añadir más objetos.

En este momento, pasamos a la segunda fase del proceso que se desarrolla en la segunda sección “Traducción de pool de trabajo” en la que se efectuará la traducción de los objetos propiamente dicha.

En esta sección se visualizará una tabla con la lista de pools de trabajo liberados para traducción. Entre ellos encontraremos el pool de trabajo que acabamos de configurar.

Al seleccionar uno de los pools de trabajo se cargarán en una tabla inferior una serie de detalles estadísticos referidos a la cantidad de textos  que se encuentran traducidos o sin traducir en los diferentes idiomas disponibles en el portal.

Se puede proceder a la traducción seleccionando el idioma fuente y el idioma objetivo en las listas situadas debajo de esta segunda tabla y pulsando el botón “Cargar para traducción”.

Con esto último se abrirá la lista de textos y se podrán ir seleccionado uno a uno para llevar a cabo su traducción.

Cuando todos los textos sean traducidos pulsando el botón “Grabar todo”, estos serán confirmados para el idioma establecido como idioma destino.

Una vez que se definan los textos para todos los idiomas disponibles, seleccionando el botón “Marcar como traducido” cambiará el estado del pool de trabajo a “Traducido”.

Por último,  regresando a la sección “Coordinación del pool de trabajo” y navegando hasta el pool de trabajo creado anteriormente,  se visualizará un mensaje similar al siguiente informando de que no se pueden añadir más objetos al pool ya que se encuentra en estado “Traducido”.

Además encontraremos la opción “Publicar traducción” mediante la cual se concluirá el proceso, publicándose los textos definidos anteriormente para los idiomas tratados.

Una vez publicada la traducción, el pool de trabajo cambiará su estado a “Publicado”, siendo posible a partir de ese momento iniciar un nuevo proceso de traducción con estado “Nuevo”.

Para comprobar si la traducción se ha realizado correctamente basta con cambiar el idioma de login, acceder de nuevo al portal y buscar los objetos traducidos en el menú de navegación en Gestión de contenidos > Contenido del portal. Como se puede ver, nuestras iViews y páginas sobre los gastos de viaje se han traducido correctamente a inglés.

Por todos es conocida la afición de SAP a cambiar las siglas y codificación de sus productos, módulos, soluciones, etc. Cuando hablamos del concepto ‘Rol’, no se queda atrás y la confusión puede ser curiosa. Por eso en este artículo hemos creído necesario aclarar este concepto para que no tengáis que preocuparos mas por ello.

Recordemos que en SAP se pueden gestionar los permisos de los usuarios mediante Roles y Perfiles, configurando en la transacción PFCG el nivel de acceso de cada uno llegando incluso a poder detallar por casi todos los objetos de negocio del sistema como por ejemplo sociedad, centro, almacen…

El concepto de autorización de SAP se puede diferenciar en dos pasos o niveles:

1. Si el usuario tiene acceso o no tiene acceso a la transacción, generalmente controlado por el objeto de autorización S_TCODE
2. Una vez dentro de la transacción, qué actividades y/o acciones puede hacer el usuario: crear un pedido, modificarlo, solo visualizarlo…

En este artículo no vamos a entrar en ese detalle, sino que vamos a comentar la diferencia entre un rol de SAP ‘clásico’ y un rol de portal.

En el portal el concepto Rol hace referencia a la ‘visibilidad’ que se tiene en el portal, a la estructura que se visualizar en el mismo:

Lo curioso y lioso del tema es que el objeto se llama igual que en los sistemas ABAP: Rol.

Para evitar confusiones, o alimentarlas más aún, los roles de SAP WAS ABAP en el portal los llaman Grupos; hay que tener cuidado con la terminología, pues.

Mapeo de Roles/Grupos en el portal de SAP

Para evitar tener que estar asignando roles y grupos en los dos sistemas, el portal permite relacionar Roles de Portal con Grupos (roles) de SAP ABAP:

Haciendo estas relaciones o mapeos, cuando creamos un usuario nuevo en el sistema Backend, basta con asignar los roles al usuario en la SU01 para que ‘herede’ o ‘arrastre’ los roles correspondientes en el portal, evitando como se ha comentado, tener que entrar a los dos sistemas a hacer la gestión de autorizaciones.

¿Pierdes mucho tiempo calculando incentivos y comisiones?

Tus competidores ya cuentan con un sistema de retribución variable ligado a la productividad ¿Y tú?

¿Sabes realmente cuánto cuesta el cálculo de incentivos en tu empresa? ¿Necesitas ponerte al día con un sistema de retribuciones ligado a laproductividad? Nosotros podemos ayudarte a optimizar estos cálculos de modo que sea un proceso completamente automático, para que no tengas que preocuparte mas de ello.

Por eso, desde Oreka IT queremos invitarte personalmente a nuestro próximo webinar online gratuito, en el que hablaremos sobre la gestión de incentivos automatizada. Para asistir a este evento necesitamos que nos confirmes tu asistencia para que podamos reservarte una plaza, por lo que deberás rellenar este sencillo formulario en nuestra web.

El webinar se impartirá  el día 5 de Noviembre a las 16:00 y será on line. Unos días antes te informaremos de la dirección web donde deberás conectarte.

A quién va dirigido:

• Responsables financieros, de informática y de RRHH
• Responsables de departamento interesados en la optimización de procesos internos

1. Gestión de datos maestros
2. Contabilizar horas productivas
3. Informe de incentivos
4. Integración con PY

—————————————————————————————————

Asko galtzen al duzu pizgarriak eta komisioak kalkulatzeko?

Zure lehiakideek produktibitatearekin lotutako ordainsari aldakorreko sistema bat daukate dagoeneko?

Ba al dakizu zenbat denbora behar duzun zure enpresaren pizgarrietako kalkuluak egiteko? Produktibitatearekin lotutako ordainsari-sistema batekin eguneratu behar duzu? Kalkulu hauek optimizatzen lagundu zaitzakegu, prozesua automatizatuz, gehiago arduratu behar ez zaitezen.
Hori dela eta, Oreka IT-tik online  egingo dugun gure hurrengo webinar-era etortzera gonbidatu nahi zaitugu. Han pizgarrien kudeaketa automatikoari buruz hitz egingo dugu. Doako gertaera honetan parte hartzeko, esaguzu mesedez konektatuko zaren, leku bat erreserba diezazugun. Horretarako, inprimaki erraz hau bete behar izango duzu gure web orrian.

Webinar-a Azaroaren 5ean, 16:00etan izango da on-line. Egun batzuk lehenago konektatu beharko zaren web helbidea bidaliko dizugu.

Webinar: SAP HCM-n pizgarrien kudeaketa

SAP HCM-ren bidez pizgarrien kudeaketa automatizatua nola egin erakutsiko da. Horretarako giza baliabideentzako HCM moduluak eta langilearen atariak ematen diguten funtzionalitatea eta neurrira egindako pizgarrietako kalkulu bat konbinatzen ditugu. Horrela, pizgarrien kudeatzaile eraginkorra, erraza eta automatikoa lortzen da. 45 minutu iraungo duen azalpenak, argibide teoriko bat, erakusketa praktikoarekin konbinatuko du.
nor bideratua:

• Finantza, informatika eta giza baliabideentzako arduradunak
• Barne-prozesuen optimizazioan interesatuta dauden sail arduradunak

Temario:

1. Datu maisuen kudeaketa
2. Ordu emankorrak kontabilizatzea
3. Pizgarriei buruzko txostena
4. Integrazio PY-rekin

Data: Azaroaren 5a, 16:00etan
Aurkezlea: Sonia España Diez

INSKRIPZIOA DOAN HEMEN

En alguna ocasión puede suceder que se carga algún support package en la cola parches de un sistema SAP, pero resulta que no se tiene que llegar hasta dicho nivel de parches o debido a los requisitos de alguno de ellos la herramienta SPAM se queda en un estado en el que no es posible actualizar el sistema ni resetear la cola de parches. Un ejemplo de esta situación puede ser a la hora de cargar un support package de tipo CRT, ya que suelen tener unos requisitos especiales, por ejemplo el parche:

ST 710: SP 0008, CRT for SAPKB70212 and SAPKU70109

Si se carga en el sistema el CRT indicado, la herramienta SPAM no permite actualizar los parches del componente BASIS SAPKB702 a un nivel inferior al SP12 por tener cargado el ST 710: SP 0008 que es CRT para el componente BASIS 7.02 SP12: SAPKB70212.

Esta situación se puede solucionar eliminando el support package ST710 SP8 cargado en el sistema.

A continuación se muestra cómo se elimina el último parche SP19 del componente

ST-SER 701_2010_1 SAP Solution Manager Service Tools Add-on Support Pkg.

Para poder eliminar un support package de la bandeja de entrada, en la transacción SEPS se accede al menú Pasar a -> Inbox:

Y en el Inbox se muestra la lista de SPs cargados. Aquí se selecciona el SP que está dando problemas (en el ejemplo se selecciona el componente SAPKITLOSJ) y se pulsa el botón de eliminar:

Se confirma la acción:

Y se muestra el nuevo estado del paquete, borrado:

De esta forma, a la hora de definir la cola ya no se muestra el support package eliminado:

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. En este artículo nos vamos a centrar solo en uno de ellos, el método WDDOBEFOREACTION.

Este método tan sólo se encuentra en los controladores de vistas, ya que son los únicos en los que se pueden implementar acciones. Este método se ejecuta siempre inmediatamente antes de que se ejecute una acción desencadenada por un evento (pulsar un botón, pulsar enter, seleccionar una fila…) y debe ser utilizado para hacer las comprobaciones necesarias para que la acción se ejecute correctamente.

La primera vez que se entra a implementar el código del método, aparecen comentadas las siguientes líneas de código:

 DATA lo_api_controller TYPE REF TO if_wd_view_controller.
   DATA lo_action         TYPE REF TO if_wd_action.

   lo_api_controller = wd_this->wd_get_api( ).
   lo_action = lo_api_controller->get_current_action( ).

   IF lo_action IS BOUND.
     CASE lo_action->name.
       WHEN '...'.

     ENDCASE.
   ENDIF.

Esta es una ayuda para saber en tiempo de ejecución que acción se va a ejecutar. En el atributo name del objeto lo_action se tiene el nombre de la acción siguiente. Así es posible implementar comprobaciones diferentes para distintas acciones. Por ejemplo, si se tiene un botón salir y un botón guardar asociados a acciones con el mismo nombre, antes de guardar se deben comprobar unos campos introducidos por el usuario, sin embargo al pulsar salir no. Por lo tanto, cuando el atributo name sea ‘GUARDAR’, se debe hacer la comprobación, pero cuando sea ‘SALIR’ no.

Cuando se estén haciendo las comprobaciones que se deseen, es posible que no se quiera que se ejecute la acción, si hay algo erróneo o vacío. Para parar la ejecución, se debe lanzar cualquier mensaje de error estando en el método WDDOBEFOREACTION. Con esto se consigue que las acciones de tipo estándar no se ejecuten. Es posible hace que una acción se ejecute igualmente aunque haya un error, indicando que su tipo sea independiente de validación.

En la pestaña de acciones es donde se indica el tipo de las mismas. En el ejemplo superior, se ha definido la acción GUARDAR como estándar, por lo que si hay algún error en la validación previa no se ejecutará aunque debiera de hacerlo. En cambio SALIR sí que se ejecutaría.

Una de las comprobaciones típicas es que el usuario introduzca todos los campos obligatorios. Para hacer que un campo se obligatorio, hay que indicarlo en el elemento UI del layout en su propiedad state.

Con esto se consigue que un pequeño asterisco rojo aparezca en el campo, indicando que es obligatorio rellenarlo, pero solo con eso no basta para que si no se rellena de un mensaje de error. Para ello, se debe escribir el siguiente código en el método WDDOBEFOREACTION.

La llamada a este método hará que todos los campos obligatorios que estén vacíos sean resaltados, y se escribirá un mensaje de error por cada campo en el área de mensajes.

Con la utilización de este método se puede conseguir un código más ordenado, haciendo que en las acciones no se tengan porque hacer validaciones, preocupándonos solo de lo que la acción debe realizar. Además, si debemos añadir alguna comprobación a posteriori, solo se debería tocar este método, y no todos donde sea necesario este nuevo chequeo.

Los resultados de nómina de SAP HCM se almacenan de forma encriptada en clusters.  Ello implica que para acceder a los resultados desde un programa no podamos hacerlo accediendo directamente a las tablas y la tarea se suele volver un poco engorrosa.

Por ello, en la nota 1764963, SAP nos proporcionó una clase que nos va a facilitar el proceso y va a permitir optimizar la lectura. La clase es CL_HRPAYES_PAYROLL_READER y a continuación se muestra un ejemplo de cómo utilizar los métodos de esta clase.

  STATICS lo_payreader TYPE REF TO cl_hrpayes_payroll_reader.
   DATA lt_rgdir TYPE hrpy_tt_rgdir.
   DATA lt_payes_result TYPE if_hrpayes_payroll_reader=>ty_t_payes_result.
   DATA ls_payes_result TYPE payes_result.
   DATA ls_rt TYPE pc207.
 <i>” </i><i>1- Crear objeto de la clase para un número de personal</i>
   CREATE OBJECT lo_payreader
     EXPORTING
       iv_pernr = p_pernr.
 <i>” 2- Leer la tabla rgdir para un periodo. Srtza = ‘A’ para leer sólo los   resultados actuales.</i>
   lo_payreader->get_rgdir(
     EXPORTING
       iv_fpbeg       = p_fecha_ini
       iv_fpend       = p_fecha_fin
       iv_srtza       = 'A'
       iv_reorg_rgdir = abap_true
     IMPORTING
       et_rgdir       = lt_rgdir[] ).
   IF lt_rgdir[] IS INITIAL.
     RETURN.
   ENDIF.

<i>”  3- Obtendremos los resultados de nómina para todos los periodos de la tabla lt_rgdir.
 </i>  lo_payreader->get_pay_result_table(
   EXPORTING
     it_rgdir        = lt_rgdir[]
     iv_read_only_buffer = abap_false
   IMPORTING
     et_payes_result = lt_payes_result[] ).

 <i></i>

<i>”  4- Recorremos los periodos y por cada periodo leemos los resultados almacenados en el cluster RE
 </i>  LOOP AT lt_payes_result[] INTO ls_payes_result.
     LOOP AT ls_payes_result-inter-rt[] INTO ls_rt

<i>”  5- Procesaremos los conceptos de nómina que nos interesen.</i>

ENDLOOP.
   ENDLOOP.

Con la llegada de Netweaver 7.3 y la desaparición del JAVA Visual Administrator desde versiones incluso anteriores el portal dispone de una multitud de herramientas y utilidades para muchos desconocidas.

Una de ellas es el Wizard de configuración, donde podemos lanzar Wizards para configurar automáticamente servicios del Portal como por ejemplo la configuración del ADS, la configuración de KM…

Para acceder al wizar hay que entrar al NWA del portal (http://hostname:5xx00/nwa) e ir a la pestaña Configuración->Scenarios

Al entrar, podemos ir a configurar unidades funcionales:

Donde podemos elegir qué Unidad Funcional como las arriba comentadas queremos activar:

Si la unidad tiene dependencias nos las marca y el sistema es capaz de configurarlas todas a la vez:

Y como se puede ver en la pestaña General, se puede leer una breve descripción de para qué sirve y lo que nos va a aportar:

Y si la unidad está ya activada, podemos consultar un log de resumen de la configuración realizada.

Como se puede ver, parece que SAP está trabajando duro en automatizar muchos costosos procesos de post-instalación y que tanta guerra dan muchas veces a los administradores de sistemas.

Se acabó configurar el ADS a mano!

Seguramente todos aquellos que trabajéis habitualmente con las características (Transacción PE03) de SAP HCM os habrá pasado alguna vez lo siguiente: Tras haber modificado algo en el árbol de decisión habéis tenido la necesidad de echar un vistazo o incluso recuperar la información del árbol estándar, tal y cómo SAP lo entrega.

Pues en este tutorial vamos a aprender que SAP almacena siempre las dos versiones, la estándar y la modificada, y aunque lo realice bajo el mismo nombre siempre podremos comparar o recuperar la versión de SAP.  Viendo el siguiente videotutorial vosotros mismo seréis capaces de acceder a la versión estándar la siguiente vez que lo necesitéis.

Pinche aquí para ver el vídeo

En este artículo se explicará la creación y configuración de un componente de coste para el proceso de planificación de costes de personal en SAP. Este pequeño tutorial se divide en dos partes.

Pasos a seguir en la configuración de un componente de coste:

1. Creación de cuenta simbólica
2. Creación de componente de coste y asignación de la cuenta simbólica
3. Asignación de la cuenta simbólica a uno o varios conceptos de nómina

Creación de cuenta simbólica

Tabla de customizing: V_T52EK

IMG: Gestión de personal – Planificación y simulación de costes de personal – Conjunto de datos – Crear cuenta simbólica

La relación existente entre un componente de coste y un concepto de nómina se realiza mediante la cuenta simbólica.

La relación cuenta simbólica – componente de coste es uno a uno mientras que la relación cuenta simbólica – concepto es una a varios.

De esta forma se puede relacionar directamente a un componente de coste con una o varias CC-nóminas para obtener el coste del componente para un empleado concreto.

Accediendo a la ruta de IMG se crea una nueva cuenta simbólica 1190 – Otros gastos salariales (IRPF / SS)

Creación del componente de coste y asignación de cuenta simbólica

Tabla de customizing: V_T77HCP_CITM

IMG: Gestión de personal – Planificación y simulación de costes de personal – Conjunto de datos – Crear componente de coste

Se crea el componente de coste 1190 – Otros gastos de salarios y sueldos

Se selecciona “Clase de coste” en CL.componente coste para poder relacionarlo con la cuenta simbólica creada en el paso anterior.

Con estos 2 pasos ya tendremos creado el componente de coste a utilizar en el proceso de planificación de costes.

Esta es la segunda y última parte de este tutorial cuya primera parte puedes leer aquí: Creación de componentes de coste en SAP (1/2).

Asignación de la cuenta simbólica a uno o varios CC-nóminas

Tabla de customizing: V_T52EZ

IMG: Gestión de personal – Planificación y simulación de costes de personal – Conjunto de datos – Asignar CC-nóminas a componentes de coste

Para poder obtener el importe de un componente de coste se debe indicar los conceptos de nómina de los que se debe obtener dicho importe.

Para ello, hay que relacionar la cuenta simbólica con el o los conceptos de nómina que se necesiten.

En este ejemplo vamos a relacionar los conceptos /401 y /551 con el componente de coste que hemos creado:

Se seleccionan el primer concepto y se relaciona con la cuenta simbólica que estamos utilizando.

IMPORTANTE: En esta tabla se parametriza si el concepto de nómina se tiene en cuenta para la contabilización de nómina, para la planificación de costes o en ambos casos. Esta parametrización se indica con las opciones del campo “Cl.proc.”

Si se selecciona Tratamiento normal se tendrá en cuenta tanto para la planificación de costes como a la hora de contabilizar la nómina.

Si se selecciona Sólo contabilización real se tendrá en cuenta solo al contabilizar y no en la planificación de costes.

Si se selecciona Sólo planificación de costes se tendrá en cuenta solo para planificación de costes.

Esto es importante porque muchas veces hay conceptos de nómina que utilizan una cuenta simbólica para contabilización de nómina y otra para planificación de costes.

En próximas post hablaré sobre la parametrización de la ejecución de planificación de costes.

Como consultores de HCM, debemos intentar siempre que los procesos que implantamos sean lo más eficientes y sencillos posibles para facilitar la tarea a los usuarios finales. Pero a veces nos sale nuestro lado más egoísta y nos centramos demasiado en cumplir con los objetivos del proyecto, sin dejar tiempo para explicarles a los usuarios todas las opciones que SAP tiene y que pueden usar para facilitar su tarea del día a día. Para ayudarles, podríamos comenzar por ejemplo explicándole la existencia de los parámetros de usuario de SAP HCM.

¿Qué son los parámetros de usuario en SAP HCM?

La mayoría de los parámetros de usuario en SAP HCM tienen como objetivo proponer valores en las pantallas de selección. Por ejemplo, gracias al parámetro OM_DATE los usuarios podrán hacer que la fecha por defecto para ver la estructura organizativa (PPOME/PPOSE) no sea la fecha actual. El valor del parámetro de usuario podrá ser distinto para cada usuario según las preferencias de cada uno.

Además existen parámetros de usuario en SAP HCM con otros objetivos cómo puede ser modificar la forma en la que se visualizan los datos u otros más útiles para los consultores o programadores.

NOTA: Los parámetros de usuario que proponen datos solo funcionan la primera vez que el usuario se loguee en el sistema. Las siguientes veces el sistema recuerda automáticamente el último valor introducido.

¿Cómo trabajar con los parámetros de usuario en SAP HCM?

Podremos acceder a nuestros parámetros de usuario en SAP HCM mediante la transacción su3 o mediante el menú: Sistema >> Datos prefijados >> Datos propios (System >> User profile >> Own data). Una vez dentro, tendremos que movernos hasta la tercera pestaña e introducir ahí el parámetro con el valor. Si lo que queremos es modificar los parámetros de un usuario distinto al nuestro utilizaremos la transacción su01.

Si nos encontramos en una pantalla de selección y queremos saber si se puede proponer por defecto el valor de un campo deberemos acceder a la información técnica del campo. Para ello deberemos posicionarnos dentro del campo, pulsar F1 y en la ventana que se nos abre pincharemos sobre el martillo. En los datos técnicos aparecerá el ID parámetro (no todos los campos lo tienen), que será el parámetro a usar para proponer un valor.

Aquí os dejo un listado de parámetros que se pueden utilizar para que cada vez que accedamos al sistema el campo tenga un valor por defecto.

En la entrada anterior explicamos cómo los parámetros de usuario de SAP HCM facilitan el trabajo diario con el sistema, al proponer datos por defecto.  Pero además, existen parámetros que no proponen datos si no que modifican la forma en la que se ve la información. Estos parámetros son más difíciles de descubrir. A continuación explicaré aquellos que pueden ser útiles en SAP HCM.

HR_DISP_INFTY_NUM

Este parámetro acepta los valores X o ‘ ’. Si el parámetro tiene el valor ‘X’, nos mostrará el número de infotipo junto con el nombre cuando estemos visualizando o modificando un infotipo. Un parámetro muy útil para los que necesiten aprenderse los números o los que se manejen mejor con los números que con los textos.

HRPE01_DISPLAYMODE / HRPE02_DISPLAYMODE

Estos parámetros son útiles para aquellos que lleven años trabajando con el módulo de PY de SAP. Toma los valores “TABLE” o “TREE” y  dependiendo del valor introducido, se modifica la forma en la que se visualizan los esquemas (PE01) o las reglas (PE02). La forma de visualización por defecto es TREE por lo que si se desea ver con forma de árbol no es necesario introducir el parámetro. En cambio, si se está acostumbrado a trabajar con la forma de visualización antigua, el parámetro evitará que tengamos que modificar la forma de visualización cada vez.

OM_FRAM_SCEN_DISPLAY

Este parámetro puede tomar los valores ‘X’ o ‘space’. Con el valor ‘X’ se nos mostrará el nombre técnico del framework del escenario de la PPOSE/PPOME. El nombre técnico será necesario para poder realizar parametrizaciones desde la IMG.

OM_OBJM_SCEN_DISPLAY 

Este parámetro puede tomar los valores ‘X’ o  ‘space’.  Con el valor ‘X’ se nos mostrará el nombre técnico del gestor de objetos de la PPOSE/PPOME.  El nombre técnico será necesario para poder realizar parametrizaciones desde la IMG.

OM_OBJM_NO_LAST_SEAR

Este parámetro puede tomar los valores ‘X’ o  ‘space’.   Con el valor ‘X’, el sistema no recordará la última búsqueda realizada en la PPOSE/PPOME y siempre se mostrará la ventana de Bienvenido.

 OM_TABTYPE_DISPLAY

Este parámetro puede tomar los valores ‘X’ o ‘space’. Con el valor ‘X’ se nos mostrará el nombre técnico  de una pestaña de la PPOSE/PPOME. El nombre técnico será necesario para poder realizar parametrizaciones desde la IMG.

OM_ARRAYTYPE_DISPLAY

Este parámetro acepta los valores ‘X’ o ‘space’. Si tiene el valor ‘X’ permite obtener los nombres técnicos de las columnas. Para poder ver los nombres, se habilita el botón “Datos técnicos” dentro de la configuración de las pestañas.

¿Qué es SAP SUP? SAP Mobile Platform (Sybase Unwired Platform)

SAP Mobile Platform (Sybase Unwired Platform), también llamado SAP SUP es la plataforma de movilidad para las empresas que propone SAP para simplificar la construcción y gestión de las tareas necesarias para conectar los dispositivos móviles de la empresa mediante workflows a las herramientas y ERPS de la oficina.

Como se puede ver en la imagen, SAP Mobile Platform (SAP SUP) proporciona una capa intermedia (middleware) entre diferentes fuentes de datos (SAP o no-SAP) y los dispositivos móviles que necesitan usar la información corporativa.

SAP SUP permite a los desarrolladores de aplicaciones móviles desarrollar en un entorno común independientemente de los dispositivos móviles que se usen (iOS, Android, Blackberry…). SAP SUP traduce automáticamente la aplicación en función del tipo de dispositivo y sistema operativo sobre el cual se quiera instalar la aplicación. Se comunica usando el estándar OData.

En el caso de necesidad de integración con sistemas SAP, es necesario, además, SAP Netweaver Gateway.

Hablaremos de SAP Netweaver Gateway, SAP SUP y otros productos de movilidad (mobility) de SAP en siguientes artículos.

Referencias:

http://en.wikipedia.org/wiki/Open_Data_Protocol

¿Qué es SAP Afaria?

SAP Afaria es la solución de Sybase (SAP) para la gestión de los dispositivos móviles y su seguridad en una compañía. Permite a los administradores de IT gestionar centralmente la seguridad, deployar aplicaciones y datos en remoto y de manera masiva en los dispositivos suscritos a SAP Afaria.

Desde SAP Afaria se pueden hacer copias de seguridad de los dispositivos de la compañía, deshabilitar funcionalidades, instalar aplicaciones corporativas… Incluso se puede activar el GPS del dispositivo y conocer la posición del mismo (sin querer controlar al personal…).

En definitiva una solución de ‘mobility‘ que permite a los departamentos de IT de las empresas centralizar la gestión de todos sus dispositivos móviles, en todos los aspectos.

Os dejamos aquí un video promocional de SAP AFARIA:

Pinche aquí para ver el vídeo

Hace poco os hablábamos de la nueva plataforma de mobility de SAP llamada SAP Afaria. Para los que aún no sepáis de qué va exactamente eso de SAP Afaria, os recomendamos leer este artículo sobre qué es SAP Afaria.

Hoy os dejamos un video demostrativo que hemos subido a nuestro canal de youtube, sobre cómo se suscribe un dispositivo iOS, en este caso, a un servidor SAP Afaria.

Pinche aquí para ver el vídeo

En artículos anteriores sobre WD se han comentado varias utilidades o elementos más o menos avanzados. En el siguiente tutorial quiero describir el proceso de algo tan básico en la programación WD como es la navegación entre vistas dentro de una misma ventana.

A los controladores de ventanas se les puede asignar varias vistas que van a formar parte de la aplicación. Para poder navegar entre ellas, se deben definir en las mismas Inbound y Outbound plugs y conectarlos mediante enlaces de navegación. Al generar los Outbound plugs en las vistas se crean automáticamente unos métodos (disparadores) para poder comenzar la navegación. Será el usuario el responsable de llamar a estos métodos para poder navegar, a través de acciones asociadas a eventos.

El siguiente gráfico explica el funcionamiento de la navegación:

A continuación se describe como se puede hacer una aplicación con la navegación que se muestra en el gráfico.

Lo primero de todo será crear un componente Web Dynpro. Al crear uno, normalmente se nos genera una vista por defecto con el nombre MAIN. A esta vista le añadiremos, en la pestaña de layout, un textView con el texto “Vista Main” y un botón con el texto “Cambiar Vista”.

Después, en la pestaña de Outbund Plugs crearemos uno para poder cambiar de vista. Simplemente hay que darle un nombre al plug para crearlo. Yo recomiendo que todos los Outbound plugs se nombren con el prefijo TO_ y el nombre de la vista a la que querremos navegar.

El último paso en esta vista será ejecutar el método disparador del plug. Para ello, creamos una acción en el botón, y en el pop-up que aparece, le damos un nombre a la acción y elegimos el plug que hemos creado.

Con este paso lo que conseguimos es que en el código de la acción se escriba la llamada al método disparador que se ha creado al definir el plug. Estos métodos siempre corresponden al controlador de la vista, y siempre se llaman fire_<nombre_plug>_plg. Por lo tanto, en este caso habrá la llamada resultaría:

wd_this->fire_to_vista2_plg( ).

A continuación, debemos crear la segunda vista. En esta vista añadiremos al layout un textView con el texto “Estamos en la Vista 2”. También habrá que definir un Inbound plug en la pestaña correspondiente. Al igual que los out, con darle un nombre el plug es creado. Recomiendo que estos se llamen FROM_ y el nombre de la vista de la que se viene.

Al crear un Inbound, se genera automáticamente un método handler. Este método será ejecutado por el runtime siempre que exista una navegación que entre por el Inbound plug correspondiente.

Ya tenemos las dos vistas creadas con sus correspondientes plugs. El último paso será crear el enlace de navegación. Este se debe hacer en la ventana de la aplicación. En la ventana creada por defecto ya está embebida la vista MAIN, así que deberemos añadir la nueva vista, mediante la opción “Incrustar Vista” del menú contextual.

Cuando se hayan introducido las vistas se debe realizar la conexión entre Inbound y Outbound plugs. Para ello, pulsando con el botón derecho en el Outbound Plug que se quiere relacionar, se elige la opción “Crear enlace de navegación”:

Después, se debe elegir con qué Inbound Plug de qué vista se quiere conectar el Outbound seleccionado y de esta manera ya quedará definida la navegación.

Con todo esto ya tenemos definida nuestra navegación entre vistas. Ya solo quedaría activar todo, crear una aplicación y probarla.

Esto serían los pasos para crear una navegación de una vista a otra. Si se quiere volver a la vista principal habría que repetir los pasos, tomando como vista de origen la vista 2. Es posible añadir tantos plugs como sean necesarios, e incrustar tantas vistas como se quieran en la ventana de la aplicación.

En Web Dynpro Abap se pueden utilizar cualquier ayuda de búsqueda que se cree en el diccionario de datos, pero también es posible crear ayudas específicas en los controladores. Las ayudas de búsqueda en Web Dynpro Abap son una de las utilidades que se pueden encontrar en cualquier programa de SAP que muestran al usuario una serie de posibles valores a introducir.

El desarrollador puede definir la ayuda de búsqueda que se va a utilizar, para un atributo en concreto, usando la propiedad Input Help Mode a la hora de definir el contexto. Existen cinco diferentes posibilidades:

• Desactivada. No se muestra la ayuda de búsqueda.
• Automática. La ayuda la determina Web Dynpro automáticamente de entre las posibles opciones que existan asociadas al tipo del atributo.
• Ayuda de búsqueda del diccionario. El desarrollador puede elegir la ayuda de búsqueda definida en el diccionario de datos
• Objeto Selector de Valores (OVS). Componente Web Dynpro predefinido, que implementa una ayuda de búsqueda definida por un diálogo.
• Programado por usuario. Componente Web Dynpro definido por usuario que implementa la ayuda de búsqueda.

A continuación se describen los pasos para poder crear una ayuda de tipo OVS.

Web Dynpro Abap Tutorial: Object Value Selector (OVS)

Existen situaciones en las que las ayudas del diccionario no son suficientes. Por ejemplo, la ayuda de búsqueda debería tener en cuenta campos de una vista o rellanar varios de estos. Sin embargo, los diferentes inputFields están relacionados con valores diferentes de nodos, los cuales hacen referencia a diferentes estructuras del diccionario. Esta ayuda de búsqueda compleja se puede implementar como parte de un componente Web Dynpro. El tipo de ayuda de búsqueda se denomina OVS.

Existe un componente reutilizable de Web Dynpro que permite la visualización de una pantalla de selección, consintiendo introducir restricciones para la recogida y visualización de datos. La información debe ser intercambiada entre dos componentes, por eso el OVS tiene que ofrecer un interfaz que:

• Reciba información sobre qué inputFields deben ser visualizados en la pantalla de selección.
• Reciba información sobre los valores iniciales de estos inputFields.
• Devuelva las entradas del usuario en estos inputFields.
• Reciba el resultado de la recogida de datos para mostrar la lista.
• Devuelva el conjunto de datos seleccionado al programa consumidor.

Cada vez que la ayuda requiera información del componente consumidor, el evento OVS es desencadenado por el otro componente. Además se manda un parámetro adicional, el phase_indicator, que indica el tipo de información que se solicita.

Un método event handler  tiene que subscribirse al evento del OVS. Dependiendo del valor del indicador de fase (phase_indicator), se pueden implementar diferentes secciones de código para recoger la información requerida y devolverla al componente OVS. A continuación se detallan las distintas fases:

Fase 0 (phase_indicator = 0)

Esta fase se denominada fase de configuración. Aquí, el consumidor puede definir qué textos van a ser visualizados por el componente OVS: la caja de diálogo del selection screen ó la lista de ayuda de búsqueda. Además, pueden ser definidas el número de columnas usadas de la estructura. Es una fase opcional, ya que si las estructuras definidas están relacionadas a elementos del diccionario, los textos serán recogidos del elemento de datos.

Fase 1 (phase_indicator = 1)

En esta fase, el consumidor puede definir qué inputFields van a ser visualizados en la caja de diálogo como filtro previo a los valores a mostrar en la ayuda de búsqueda. Estos se realizan exportando una estructura arbitraria que contiene estos campos. Se pueden suministrar valores por defecto para estos campos dando valores a los mismos.

Fase 2 (phase_indicaror = 2)

Esta fase es procesada después que el usuario haya apretado el botón en la caja de diálogo del OVS, o se ejecuta directamente si se omite la caja de diálogo. En esta fase el consumidor tiene que recoger los datos que serán mostrados en la lista de ayuda de búsqueda por el componente OVS.

Si se ha implementado la Fase 1, el consumidor necesita conocer lo que el usuario ha introducido en los campos de la caja de selección. La referencia a esta información está disponible en el parámetro query_parameters del objeto recibido (OVS_CALLBACK_OBJECT).

Si se ha omitido la Fase 1, se pueden utilizar los datos del propio contexto del controlador para filtrar los datos a mostrar.

Para exportar la lista de valores al componente OVS, el método set_output_table( ) tiene que ser llamado, pasándole una tabla interna con los posibles valores. Entonces la lista de valores es visualizada.

Fase 3 (phase_indicator = 3)

Después de haber seleccionado un valor de la lista, esta selección tiene que ser devuelta al componente consumidor. Por lo tanto, el evento OVS es desencadenado por cuarta vez. La referencia a la selección del usuario está disponible en la variable selection del objeto devuelto. En la sección de código seleccionada del event handler del componente consumidor, estos valores tienen que ser escritos en el contexto. Los datos seleccionados son mostrados como valores de los inputFields de la vista del consumidor.

Hasta aquí la teoría sobre el componente OVS. En los siguientes pasos se muestra como se puede definir el método a implementar las distintas fases antes mencionadas.

Receta para usar OVS

• Se declara el usage del componente WDR_OVS en el componente WD consumidor.

• El usage del interfaz del controlador del OVS tiene que ser declarado en la pestaña properties del controlador dónde se quiera implementar la ayuda de búsqueda, por ejemplo el component controller o un view controller.

• En la propiedad Input Help Mode del atributo al que asociar la ayuda de búsqueda, se debe indicar Object Value Selector. Después, en la propiedad OVS Component Usage que aparece debemos indicar el nombre que le hemos puesto al usage, OVS en el ejmplo de arriba.

• Lo siguiente es definir un Handler Method par el evento OVS del usage del componente OVS. Al crear este método, elegimos como evento el componente OVS, para que escriba parte del código que vamos a utilizar.

• Por último se debe implementar el Handler Method creado. Una vez realizada la implementación, al pulsar el botón de ayuda de búsqueda del atributo relacionado, aparecerá en un pop-up la ayuda de búsqueda creada.

Los meses van pasando y se acerca la fecha en la que las empresas tendrán que adaptarse al nuevo sistema de cálculo de las liquidaciones a la Seguridad Social.

El Proyecto Cret@ (Control de Recaudación por Trabajador a través de Internet), tiene como objetivo simplificar el proceso actual, evitando errores y reduciendo costes tanto a las empresas porque tendrán menos recargos, como en la administración.

¿Cuándo entra en vigor el proyecto cret@?

En estos momentos el proyecto se encuentra en una Fase Beta, donde algunas empresas ya están trabajando junto con la TGSS realizando los envíos y pruebas necesarias. En el mes de Junio comenzará una  Fase de Gestión, donde algunas empresas serán llamadas para realizar pruebas más exhaustivas tanto de los programas de nómina cómo de los programas de la TGSS.

De todas formas, en estas fases de pruebas, todas las liquidaciones reales  se deberán realizar a través del Sistema RED.

En octubre arranca el sistema de recaudación directa. Paulatinamente se irán incorporando al sistema todos los autorizados. Desde que se reciba la comunicación oficial y durante un plazo máximo de tres meses se podrán realizar pruebas a través del Wincret@ prácticas y realizar las comunicaciones reales mediante el fichero FAN. Una vez pasados los tres meses, las comunicaciones de liquidaciones reales se realizarán sólo a través del sistema de recaudación directa.

¿Qué cambios supone el nuevo sistema de recaudación direta?

La principal diferencia es que ya no se realizará una autoliquidación de las cotizaciones. Será la TGSS, la que con los datos que las empresas le envíen, y tras contrastarlos con las bases de datos del SEPE, INSS y Mutuas, lleve a cabo el cálculo de las cuotas de la Seguridad Social. Se va a pasar de un formato de autoliquidación a un formato de “facturación” por parte de la TGSS.

 La desaparición de las autoliquidaciones parece un cambio lógico que debería haberse realizado hace tiempo. ¿Por qué disponiendo la Seguridad Social de la mayoría de los datos para hacer los cálculos, son las empresas las que los realizan? ¿Por qué se trabajaba doblemente, teniendo después la TGSS que validarlos y realizar recargos en caso de errores?  Aunque el objetivo de este cambio es que la TGSS asuma una actitud proactiva que facilitará el trabajo a las empresas, no nos tenemos que olvidar de algo evidente: La TGSS tendrá disponible toda la información sobre nuestros ingresos (ingresos por los que cotizamos pero también sobre aquellos por los que no cotizamos) y  adquirirá un mayor control sobre todos nuestros datos gracias a la comunicación entre las distintas entidades.

Otro cambio que va a suponer una gran diferencia es que la cotización no se realizará a nivel de CCC como hasta ahora, si no que se realizará a nivel de trabajador. Esto supone, que las empresas podrán hacer liquidaciones parciales sólo con aquellos trabajadores consolidados.  Además, en un mes se podrán enviar tantas liquidaciones parciales como se desee hasta realizar la liquidación correctamente a todos los trabajadores.

¿Cómo se va a realizar la comunicación con la TGSS?

Vemos a continuación cómo será la forma de trabajar cuando Cret@ esté disponible:

1. El autorizado solicita la liquidación a la TGSS (Puede solicitarse hasta el penúltimo día del mes de recaudación).
2. La TGSS emite un borrador con los cálculos
3. La empresa debe corregir las discrepancias entre su sistema y las distintas entidades. Plazo: Hasta el penúltimo día del mes.
4. Si la empresa no ha solicitado el recibo anteriormente, la TGSS el día 24, 28 y diariamente a partir del 28 envía el Recibo de Liquidación  con aquellos trabajadores que estén consolidados.

Y hasta aquí el primer artículo sobre la reforma del sistema de liquidación. Todavía quedan muchas dudas que resolver, así que continuaremos informando según vayamos conociendo más información. ¡Habrá que estar atentos para que no se nos escape nada!

Podéis descargaros la presentación de la Seguridad Social sobre el Sistema de Recaudación Directa aquí .

En la mayoría de páginas o aplicaciones web existe la posibilidad de pasar parámetros en las direcciones URL con el fin de publicar el mismo contenido a través de varias URLs diferentes. A las aplicaciones Web Dynpro también se le pueden pasar parámetros vía URL, para poder utilizarlos como el programador desee. Existen una serie de parámetros estándar que afectan de distinta manera en la aplicación, divididos en tres grupos:

• Parámetros URL para Web Dynpro
• Parámetros SAP URL
• Parámetros de la aplicación Web Dynpro

En el siguiente enlace se puede ver una lista con los diferentes parámetros estándar de cada grupo. En el último grupo, a parte de los parámetros que ya existen por defecto, se pueden crear otros personalizados para una ventana Web Dynpro. En este artículo vamos a ver cómo utilizar y crear este tipo de parámetros.

Para definir parámetros propios, primero se debe modificar el plug de la ventana que se utiliza en la aplicación WD. En el método handle del plug (normalmente se utiliza default, el plug por defecto de la ventana) se pueden definir los parámetros de entrada que se quieran.

En este método es en el único sitio que se puede recoger los parámetros que creemos, así que en él se debería guardar el valor del parámetro en el contexto o en un atributo del Component Controller para poder utilizar el valor en el resto del componente.

Ahora, si se quiere dar un valor al parámetro al ejecutar la aplicación, se debe escribir el nombre del parámetro seguido de un ‘=’ y el valor que se quiera dar al final de la URL que ejecuta la aplicación, un ejemplo en el caso anterior sería:

http:// orekait.com:8000/sap/bc/webdynpro/sap/zblog?parametro1=pruebas&parametro2=X

Esto sirve para todo tipo de parámetros, tanto estándar como propios.

También existe la posibilidad de dar un valor por defecto a cualquier parámetro de la aplicación. Para ello se debe indicar su valor en la pestaña parameters de la aplicación en cuestión. En esta pestaña, se debe poner el nombre del parámetro y en la siguiente casilla el valor que tendrá por defecto.

En la ayuda de búsqueda podemos encontrar una lista de todos los parámetros de la aplicación que se pueden utilizar, tanto estándares como creados manualmente.

Una de las modificaciones que podríamos necesitar para adaptar nuestro sistema a la normativa SEPA es el IBAN de nuestros bancos propios.

Dentro de los datos maestros de financieros tenemos los bancos propios, que son los bancos que utiliza la empresa para emitir o recibir pagos y cobros.

En SAP cuando transportamos un banco propio, el IBAN de dicho banco no se transporta de manera automática junto con los otros datos. Para llevar está información al entorno productivo tenemos las siguientes opciones:

• Generarlo directamente en producción si los bancos propios están configurados como modificables.

  El procedimiento es el mismo que en los proveedores y clientes, se calcularía entrando en la  transacción FI12, seleccionando la cuenta del banco propio y pulsando el botón  .

• Transportar la entrada correspondiente de la tabla TIBAN donde se guardan todos los códigos IBAN que se van generando.

  En este caso se generaría el IBAN en el entorno de desarrollo, se accedería a través de la transacción SM30 a la vista de la tabla TIBAN (V_TIBAN), se seleccionarían los registros correspondientes a los códigos IBAN de nuestros bancos propios y se pulsaría la opción de transporte que tenemos en el menú.

  Crearemos una orden de transporte y marcaremos la opción “Incluir en orden”. La tabla TIBAN puede estar configurada de manera que no esté permitida la actualización ni visualización de la misma por lo que esta opción de transporte no siempre es posible.

• Implementar la siguiente nota que ha liberado SAP para que se transporte junto con el resto de datos del banco propio. 1913503 – FI12: IBAN of house bank is not transported