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

Siguiendo con lo comentado en el artículo anterior sobre creación de aplicaciones SAPUI5, en esta segunda parte vamos a ver con más detalle los ficheros más importantes que forman la base de un proyecto SAPUI5 y los modificaremos para ver en funcionamiento nuestra primera aplicación SAPUI5.

4. Ficheros principales de una aplicación SAPUI5

index.html

Como introdujimos en el artículo anterior, este fichero es el punto de entrada a la aplicación SAPUI5. En él encontramos tres partes principales:

Bootstrap: El bootstrap es el primer script que se ejecuta al cargar la aplicación SAPUI5. En él se establecen valores de configuración tales como el idioma (data-sap-ui-language) o el tema (data-sap-ui-theme) por defecto a utilizar. Así mismo, se cargan las librerías necesarias para la aplicación (data-sap, tanto las del core como las opcionales que vimos en el artículo sobre librerías SAPUI5: en este caso, al haber elegido m como librería base, la encontramos ya entre las librerías a incluir.

Lógica de negocio: Después del bootstrap se encuentra un segundo script en el que ya sí se comienzan a declarar e instanciar los elementos SAPUI5 necesarios: controles, vistas, etc. para después colocar estas en el área UI. En este casovemos cómo crea un control App a la que se añade la vista SAPUI5 que hemos creado como vista inicial. Después, mediante el método placeAt coloca esta App en content, que no es otra cosa que un DIV HTML declarado en el área UI.

Area UI: El área UI es un bloque de código HTML que es la base de la aplicación SAPUI5 a la que se le irá añadiendo código dinámicamente. Inicialmente cuenta únicamente con el elemento <BODY> y un <DIV> cuyo ID es content, al que como hemos visto anteriormente se hace referencia desde la lógica de negocio. Este código HTML se puede modificar cómo se desee, borrando o creando bloques HTML. Mediante el método addContent se irá pegando el código derivado de controles, vistas etc. en estos bloques HTML indicando siempre el ID de cada bloque.

Prueba.view.js

Como hemos visto, al haber generado una vista inicial en el proyecto, desde el index.html automáticamente se hace referencia a una vista SAPUI5, la cual se corresponde directamente con este fichero Prueba.view.js. En esta vista podemos crear diferentes controles que compondrán la interfaz de la aplicación SAPUI5: botones, textos, tablas, listas etc.

En una vista SAPUI5, sea el lenguaje que sea, veremos siempre dos elementos importantes: la referencia al controlador y el contenido.

En este caso al ser una vista Javascript, estos dos elementos se corresponden con dos funciones:

getControllerName: En esta función obtenemos la referencia al controlador que dotará de funcionalidad a la vista.

createContent: Función en la que iremos creando y añadiendo controles SAPUI5. Para ver un ejemplo sencillo, vamos a añadir una página que dentro tendrá un botón de la librería m. y rellenaremos sus propiedades y eventos.

Prueba.controller.js

Como podemos ver en el ejemplo anterior, a la vista Prueba se le ha asignado un controlador en el que se implementará la lógica necesaria para atender a eventos, realizar validaciones etc. El fichero Prueba.controller.js es el fichero que se corresponde con este controlador.

Por defecto, al crear automáticamente el controlador con el wizard este crea ya una serie de funciones comentadas que se corresponden con los eventos básicos de la aplicación (onInit, onBeforeRendering, onAfterRendering y onExit).

En el código del botón anteriormente creado en la vista, podemos ver que el control sap.m.Button responde a un evento press, para el cual se indica una función propia del controlador. Es decir, cuando se pulse el botón, la aplicación buscará el controlador asociado a la vista y ejecutará la función onPress que este tenga implementado. A continuación vemos el código del controlador:

Con todo esto, ya podemos ver en funcionamiento nuestro primer proyecto SAPUI5. Para ello, pulsamos con el botón derecho sobre el proyecto en el Project Explorer y seleccionamos la opción Run As –> Web App Preview con lo que se abrirá un navegador integrado en Eclipse donde podremos ver la aplicación SAPUI5 en funcionamiento:

Con esto ya hemos creado nuestra primera aplicación SAPUI5.

En este artículo se explicará cómo ajustar un contingente de absentismo en el Infotipo 2006 utilizando el Infotipo 2002 e Infotipo 0416 mediante la función QUOTA en el esquema de tiempos.

Los pasos a seguir serían los siguientes:

Revisar contingente a ajustar en Infotipo 2006. En función de si se quiere aumentar la cantidad de horas del contingente o la cantidad de horas Liquidadas del contingente se actualizará el Infotipo 0416 o el Infotipo 2012

Actualización de Infotipo 2012 ”Actualización de cantidad de horas del contingente” Para aumentar el número de horas del contingente se creará un registro en el Infotipo 2012 con esa cantidad. Por ejemplo 30 horas, por lo que las horas pasarán de 24 a 54 horas.

IMPORTANTE: Esta actualización se aplica al lanzar la evaluación de tiempos en la función de tiempos QUOTA.

Actualización de Infotipo 0416 ”Actualización de cantidad de horas liquidadas”. Para aumentar el número de horas liquidadas se creará un registro en el Infotipo 0416 con esa cantidad. Por ejemplo 15 horas, por lo que las horas liquidadas pasarán de 0 a 15 horas.

IMPORTANTE: Esta actualización se aplica directamente sobre el importe de horas del infotipo 2006.

Esta compensación de 15 horas se aplica directamente en el infotipo 2006.

Se observa que la cantidad de horas de liquidación ha sido modificada pero no el número de horas del contingente. Para que se apliquen las 30 horas introducidas en el Infotipo 2012 se debe ejecutar el esquema de tiempos.

Al ejecutar el RPTIME00 el día 10.07.2015 se aplica las horas al contingente del 2006:

Se puede observar como las 30 horas introducidas en el registro del Infotipo 2012 han sido aplicadas al contingente del Infotipo 2006.

Ya podemos ajustar contingentes de absentismo en SAP en el infotipo 2006.

En próximos artículos se explicará cómo parametrizar los subtipos del Infotipo 2012 y Infotipo 0416.

SAP Lumira es la evolución de la herramienta SAP Visual Intelligence.

SAP ha adaptado los aspectos de presentación y la funcionalidad para hacer de SAP Lumira una herramienta de manejo más sencillo para el usuario, con gráficos más atractivos, con mayor capacidad para el detalle, y con un modelo de visualización de datos self-service que se ha simplificado notablemente con respecto a la versión de Visual Intelligence.

En este artículo descubrirás todos los detalles que debes conocer sobre SAP Lumira y sus características principales.

La filosofía de SAP con esta herramienta, además de proveer al usuario con una aplicación analítica intuitiva y de uso sencillo, es crear una plataforma de story-telling. En cierto sentido se busca implementar el modelo tradicional del contador de historias al ámbito de las presentaciones corporativas. Mostrar datos en una pantalla y explicarlos no es suficiente para captar la atención del público; lo que propone SAP Lumira es una herramienta de soporte que permita al usuario darle un formato narrativo – con su introducción, nudo y desenlace – a sus informes, con el objetivo de cautivar a su audiencia.

Características generales de SAP Lumira

En esencia, SAP Lumira permite que los usuarios de negocio accedan, transformen y visualicen datos de cualquier tamaño bajo un modelo de self-service. La herramienta prioriza la simplicidad de su interfaz, mostrando sólo la funcionalidad que es relevante para cada momento, y el buen nivel de las presentaciones de datos, que permiten a los usuarios realizar análisis de forma rápida e intuitiva, sin necesidad de desarrollar scripts.

La interfaz de SAP Lumira se basa en drag-and-drop, un formato con el que es fácil familiarizarse, y con unos pocos clicks se pueden agregar, combinar y visualizar varias fuentes de datos. En este sentido, no es necesaria una formación al uso para empezar a usar Lumira, unos conceptos básicos de navegación y funcionalidad es suficiente para empezar a trabajar con Lumira.

Respecto a las capacidades de SAP Lumira:

Maximizar el conocimiento de los procesos de negocio, pudiendo escalar desde análisis panorámicos a gran escala a la visualización al máximo detalle de las variables de menor peso. La interfaz se adapta mostrando la funcionalidad relevante según el nivel de detalle deseado.
Acelerar la toma de decisiones gracias a la posibilidad de obtener soluciones a problemas complejas sin tener que tirar de listados de tablas y reportes con formatos predeterminados fijos. Gran flexibilidad en la interacción, pudiendo realizar preguntas complejas a la herramienta.
Formato self-service, que nos permite prescindir de los técnicos del departamento TIC.
Amplia capacidad para difundir y compartir informes de forma automatizada y/0 programable.
Integración lineal con dispositivos móviles.
Si alimentamos la herramienta con SAP HANA podremos realizar análisis de cualquier volumen de datos (Big Data) en tiempo real

Ahora que ya sabes un poco más sobre SAP Lumira, si quieres puedes proponernos nuevos artículos ampliado información, o preguntarnos tus dudas en los comentarios de este artículo. ¡Gracias por leer!

En este artículo se explica brevemente cómo abrir un periodo contable en SAP MM para movimientos de materiales.

Muchas veces nos hemos encontrado con el siguiente error a la hora de hacer un movimiento de material en el sistema SAP MM:

Sólo es posible contabilizar en los periodos Año/Mes y Año/Mes de la sociedad XXXX

Sigue leyendo para descubrir cómo solucionarlo.

En este caso se requiere desplazar el periodo contable para la contabilización de movimientos de materiales ya que el período actual no está abierto en SAP.

Este desplazamiento del periodo contable, implica que hemos pasado de periodo en SAP, y ya no se podrá realizar contabilizaciones en el periodo que se cierra. Siempre están abiertos dos periodos:

El periodo actual.
El periodo anterior.

Así que al desplazar al nuevo periodo, el periodo anterior quedará cerrado.

Comprobación del periodo actual

Desde la transacción (OMSY – Modificar Sociedad para gestión de materiales) verificamos que año y período actual están actualizados.

Desplazar el periodo contable

Se actualizará el periodo contable con el que periodo que queramos abrir para contabilizar los documentos de material. Mediante la transacción MMPV – Desplazamiento de periodo de maestro de materiales.

Añadiremos en la pantalla de selección:

Los datos de nuestra sociedad.

Nuevo periodo que queramos abrir.

Acción que deseamos realizar.

Una vez ejecutado el programa te indicará el nuevo periodo que se ha quedado activo:

En el caso de querer desplazar el periodo al siguiente y no se haya cumplido todavía el periodo actual, te devolverá un error:

Así es como se puede abrir un periodo contable SAP MM, para movimientos de materiales.

En este artículo vamos a hablar de algunas de las novedades que se han introducido en el lenguaje de programación ABAP desde la salida de la versión SAP 7.40. Con el lanzamiento de esta versión se introdujeron algunos cambios interesantes, que, junto con algunos otros añadidos posteriormente, vamos a comentar en las siguientes líneas.

Este será por tanto el primero de dos artículos donde presentamos las primeras novedades ABAP con SAP 7.40

Declaraciones inline

Una de las cosas que muchos programadores ABAP (sobre todo los que conocían también otros lenguajes de programación actuales) echaban en falta eran las declaraciones inline, o en una sola línea. Estas declaraciones son muy útiles ya que permiten declarar las variables en los puntos donde se van a utilizar, cogiendo así el tipo de dato por el contexto y evitando tener que declararlas previamente.

Este tipo de declaración se puede utilizar en muchos sitios, conocidos como posiciones de declaración. A continuación mostramos algunas de esas posiciones de declaración en ABAP, aunque hay muchas más:

Parte izquierda de una asignación

Esta funcionalidad resulta muy útil en muchos casos, ya que nos permite asignar el resultado de un cálculo, o el retorno de un método a una variable en una sola sentencia.

Así, podemos declarar una variable y asignarle un valor en una sola sentencia en ABAP.

DATA(porcentaje_descuento) = 25.

O podemos recoger el resultado de una llamada a un método (si tiene un único valor RETURNING).

CLASS cl_descuentos DEFINITION.
 METHODS calcular_descuento RETURNING VALUE(descuento) TYPE i.
 ...
 DATA(porcentaje_descuento) = cl_descuentos->calcular_descuento( ).

Sentencia LOOP

A partir de ahora no tendremos que crearnos una estructura si queremos recorrer una tabla interna en ABAP para la, nos bastará con utilizar la palabra clave DATA dentro de la sentencia del LOOP.

LOOP AT itab INTO DATA(wa).
 ...
 ENDLOOP.

Sentencia READ TABLE

Relacionado con lo anterior, también podremos leer un registro de una tabla interna en una estructura sin haberla definido previamente.

READ TABLE itab INTO DATA(wa) …

Sentencia SELECT

Otra gran utilidad añadida en ABAP con SAP 7.40, (con el Support Package 08) es la de poder hacer una consulta SELECT y guardar los datos en una tabla sin tener que crearla previamente. Esto es muy útil porque el sistema determina automáticamente el tipo de la tabla interna necesaria dependiendo de la consulta.

SELECT carrid, connid, cityfrom, cityto
 FROM spfli
 INTO TABLE @DATA(itinerario_vuelos).

Expresiones con tablas

Otra de las novedades es la posibilidad de utilizar corchetes ([ ]) para hacer accesos a las tablas internas de forma que podemos hacer tanto lecturas como escrituras en las tablas internas de una forma más rápida.

Podremos utilizar esta nueva funcionalidad para hacer las lecturas tanto por clave como por índice.

DATA(vuelo) = itinerario_vuelos[ carrid = 'AA' connid = '0007' ].

DATA(vuelo) = itinerario_vuelos[ 1 ].

Además, podremos utilizar estas nuevas expresiones con corchetes incluso dentro de otras expresiones como condiciones o bucles, por ejemplo.

IF itinerario_vuelos[ 1 ]-cityfrom = 'NEW YORK'.
 ...
 ENDIF.

Se han añadido también dos funciones nuevas para trabajar con tablas internas:
 "Obtener un indice concreto
 DATA(idx) = line_index( itab[ … ] ).

"Comprobar si la línea existe
 IF line_exists( itab[ ... ] ).
 ...
 ENDIF.

En el próximo blog seguiremos presentando más novedades ABAP con SAP 7.40

Como ya comentamos en el anterior artículo sobre las novedades ABAP con SAP 7.40, en este segundo artículo terminaremos de presentar dichas novedades para la programación en ABAP.

A continuación, listamos algunos nuevos operadores, os serán de gran utilidad en vuestro día a día con ABAP.

Nuevos operadores

Entre las novedades ABAP con SAP 7.40 tenemos, operadores nuevos muy conocidos en otros lenguajes de programación como NEW, VALUE, COND y SWITCH, …
Estos operadores se utilizan con la siguiente sintaxis.

... operator type( ... ) ...

NEW

Muy utilizado en la programación orientada a objetos sirve para crear objetos nuevos y, junto con las declaraciones inline vistas anteriormente nos permite hacer declaraciones como estas:
Antes

DATA oref TYPE REF TO class.
CREATE OBJECT oref exporting ...

Ahora

DATA(oref) = NEW class( ... ).

VALUE

VALUE es un operador que nos permite crear elementos del tipo indicado pero añadiendo los valores directamente.

Antes

DATA itab TYPE t_itab.
DATA wa LIKE LINE OF itab.
wa-col1 = 1. wa-col2 = 2.
APPEND wa TO itab.
wa-col1 = 3. wa-col2 = 4.
APPEND wa TO itab.

Ahora

DATA(itab) =
VALUE t_itab(
( col1 = 1 col2 = 2 )
( col1 = 3 col2 = 4 ) ).

COND y SWITCH

Estos operadores nos permiten escribir expresiones condicionales en nuestros programas, pudiendo sustituir código previo realizado con IF y CASE.

COND construye el resultado en base a una serie de expresiones lógicas (IF).

DATA(time) =
COND string(
WHEN sy-timlo < '120000' THEN |{ sy-timlo TIME = ISO } AM| WHEN sy-timlo > '120000'
THEN |{ CONV t( sy-timlo - 12 * 3600 ) TIME = ISO } PM|
WHEN sy-timlo = '120000' THEN |High Noon|
ELSE
THROW cx_cant_be( ) ).

SWITCH construye el resultado en base a comparaciones de tipo igula (CASE).

DATA(number) =
SWITCH string( sy-index
WHEN 1 THEN 'one'
WHEN 2 THEN 'two'
WHEN 3 THEN 'three'
ELSE THROW cx_overflow( ) ).

Estos son por el momento, todas las novedades ABAP con SAP 7.40.

En el artículo de hoy voy a hablar de los SAP proveedores CPD (Cuentas prodiversos en SAP), que son aquellos que suministran a la empresa sólo una vez o con muy poca frecuencia.

Además, también se aclarará en qué consisten los grupos de cuentas CPD, datos maestros de acreedores y los pedidos de compras SAP.

Como ya se ha comentado, los SAP proveedores CPD, son aquellos que suministran a la empresa con muy poca frecuencia, por este motivo no se crean registros maestros para estos proveedores en el sistema, ya que el acceso a estos datos ya no se necesitarán en un futuro.

De ahí que las cuentas colectivas se estructuren para proveedores CPD. Estas cuentas también se denominan cuentas CPD. (Opcional)

Dado que estas cuentas se utilizan para más de un proveedor, los registros maestros no contienen datos específicos del mismo. Por lo tanto, los datos como la dirección, el vendedor, los datos bancarios, etc. se deben introducir en pedidos de Compras SAP o en las facturas. Esta verificación de proveedores parametrizado en el grupo de cuentas CPD que se le asigna a cada proveedor.

Grupo de cuentas CPD

El grupo de cuentas es un resumen de cuentas basado en criterios que influyen en la manera en que se crean los registros maestros.

El grupo de cuentas CPD determina:

El intervalo de números a partir del cual se selecciona el número de cuenta cuando se crea una cuenta de mayor.
El formato de pantalla para crear cuentas de mayor en el área específica de la sociedad.

OMSG – Modificar grupos de cuentas: Acreedores.

Ese campo Cuenta pro diversos es el que dato que verifica ese grupo de cuentas como CpD.

Datos maestros Acreedores CPD

Los datos básicos se suelen usar para dar una descripción de los tipos de proveedores que están definiendo. (Los campos obligatorios y opcionales son parametrizables desde OMSG – Modificar grupos de cuentas: Acreedores)

*Ejemplo proveedor datos de dirección

Para crear registros maestros CPD, se debe especificar una cuenta asociada. Si se diferencia entre cuentas asociadas en la sociedad GL, también se deberá tener en consideración dicho aspecto al crear registros maestros CPD.

*Ejemplo proveedor gestión de cuentas: contabilización financiera

Pedido de compras SAP

En la realización de los pedidos de compras SAP (ME21N – Crear pedidos de compras) es el momento en el que los datos del proveedor serán obligatorios. Se deberá especificar concretamente los datos que consideremos obligatorios. (Para un proveedor normal estos datos los recogería del maestro de proveedores)

Se puede ampliar los detalles del proveedor para especificar los datos.

Como veis, es fácil gestionar cuentas prodiversos en SAP .

La forma en que entendemos la interfaz de usuario (UI) se ha convertido en un estándar en la interacción entre humano y máquina. No sólo se ha influido la forma de trabajar y de comunicarse de ya varias generaciones de usuarios, sino que ha contribuido a generar toda una industria dedicada a la optimización de tecnología UI.

En el presente artículo vamos a contar de forma resumida la historia de la interfaz hombre máquina y cómo surgió este modelo de tecnología UI y quiénes fueron las principales figuras involucradas.

Memex tal como lo concibió Vannevar Bush

Aunque es cierto que ya se empiezan a atisbar grandes cambios en este estándar, hemos de reconocer que no ha habido grandes cambios en los últimos años en lo que se refiere a tecnología UI: Sus paradigmas (combo pantalla-ratón teclado, ventanas superpuestas, menús desplegables, etc) siguen siendo los mismos.

El primer gran teórico de la interacción entre humano y computadora, es decir, de la interfaz de usuario, fue Vannevar Bush, un científico del MIT que colaboró con el ejército de los EEUU durante la Segunda Guerra Mundial. En 1945 publicó un artículo llamado “As We May Think”, en el que describía su visión de una herramienta de administración de la información a la que bautizó como Memex. Esta herramienta constaría de una mesa con un teclado y palancas que permitiría la consulta de de datos almacenados en microfilms que serían proyectados en pantallas translúcidas. El aparato incluiría también la posibilidad de que el usuario pudiera realizar modificaciones en los microfilms, de manera que el usuario pudiera asumir el rol de creador, además de realizar consultas. Teniendo en cuenta que los ordenadores de entonces eran enormes armarios que leían los datos de tarjetas agujereadas, no podemos sino calificar las ideas de Vannevar como visionarias.

Es importante resaltar que Vannevar entendía las ciencias de la información como una manera, no de automatizar procesos, sino de aumentar las capacidades innatas del ser humano. De hecho, el nombre de Memex proviene de Memory Extender.

Esta misma filosofía siguió Douglas Engelbart, al que debemos el desarrollo del embrión del actual modelo de Interfaz de Usuario. Engelbart había estado investigando aspectos relacionados con la interacción hombre-máquina en la Universidad de Standford durante la década de los 50. Fuertemente influenciado por Vannevar Bush, Engelbart veía el computador como un medio para aumentar las capacidades humanas, es decir, su visión era la de empoderar al usuario en vez de sustituir el trabajo humano por máquinas, interfaz hombre-máquina.

Si bien esa filosofía no se retomaría hasta nuestros días, Engelbart sentó las bases de la forma que a día de hoy tenemos de interactuar con los computadores. A principio de los 60, Engelbart asumió el cargo de director del ARC (Augmentation Research Center) y desarrolló nada menos que:

Combinación de computadora, teclado y pantalla como base para la interacción hombre-máquina. Además, desarrollo del ratón y del principio Point&Click.
Software de procesamiento de palabras con capacidad de hipertexto. Es decir, el abuelo del actual MS Word.
Principio de ventanas superpuestas, el germen del concepto visual principal de los sistemas Xerox y, posteriormente, Windows.
Comunicaciones basadas en texto entre computadoras.

La máquina de Engelbart

Ahí es nada. Resulta irónico que se dediquen tantas líneas, libros y películas a personajes como Steve Jobs y Bill Gates, y tan pocas al hombre al que estos últimos tanto deben. Engelbart creó un paradigma de comunicación hombre-máquina que sigue todavía vigente a día de hoy, a la espera de la siguiente gran revolución por venir.

Este es mi resumen sobre la historia de la interfaz hombre-máquina. Respecto a lo que puede que esté por venir dedicaremos nuestro siguiente artículo; Evolución Interfaz de Usuario: Natural User Interface.

Aunque el modelo de interfaz de usuario establecido por Douglas Engelbart, presentado en el anterior artículo sobre la historia de la interfaz hombre máquina, ha sido un rotundo éxito, como respaldan sus más de 50 años de trayectoria, no es ni mucho menos el último paso en lo que se refiere a formas de interacción hombre-máquina.

En este artículo sobre la evolución Interfaz de Usuario, nos vamos a centrar en el modelo que más repercusión mediática está teniendo, aunque ni mucho menos es el único. Nos referimos al Natural User Interface (NUI).

Natural User Interface se podría definir como un conjunto de métodos y mecanismos para que la conexión entre el humano y la máquina se produzca de la forma más intuitiva posible. Se podría decir que es una respuesta al modelo anterior, en el que el usuario tenía que hacer un esfuerzo en cuanto a ergonomía y fisionomía se refiere para comunicarse con la máquina. Lo que propone Natural User Interface es eliminar en la medida de lo posible el “hardware intermediario”, esto es el ratón y el teclado, y aprovecharse de los comportamientos naturales del ser humano para mediar con la máquina. Los comportamientos que se podrían asociar a NUI incluirían:

Movimientos y gestos naturales
Lenguaje verbal y no verbal
Gestos faciales
Trayectoria del ojo humano

Además, Natural User Interface incluye otros comportamientos humanos no tan visibles, como pueden ser los aspectos relacionados con la neuroergonomía. Estos contemplan cambios inconscientes o no voluntarios en el estado del cuerpo (sueño, temperatura, respiración, dilatación de la púpila, tasa cardiaca).
A día de hoy, el ejemplo más popular en cuanto a desarrollo embrionario de NUIs se refiere posiblemente sea el dispositivo Kinect desarrollado por Microsoft para la Xbox 360. La idea es eliminar el controlador clásico de videojuegos y usar los gestos espaciales del jugador como input. A continuación, un vídeo de demostración sobre las capacidades de este no-controlador:

Pinche aquí para ver el vídeo

Está claro que todavía queda mucho camino que recorrer para llegar al nivel de las NUIs de ciencia-ficción que se muestran en películas como Minority Report o Iron Man, pero pensamos que vamos por el buen camino. Otra cosa, es el uso que decidamos darle…

Esta es por el momento la tendencia de que sigue la evolución Interfaz de Usuario.

En un artículo anterior describimos el elemento UI Date Navigator. Este elemento ha sido modificado para la versión 7.4 de SAP NetWeaver, por lo tanto ciertas partes del artículo mencionado han quedado obsoletas para las nuevas versiones. A continuación se describen las modificaciones para poder seguir utilizando este elemento UI Date Navigator.

Las propiedades y eventos del propio elemento no han cambiado como tal. Sin embargo, lo que si se ha modificado ha sido el subelemento DateNavigatorMarking, que se encargaba de dar color a los días del calendario. Como antes, se debe añadir un subelemento de este tipo y también se define un nodo (de cardinalidad 0..n ó 1..n), pero en este caso se ha modificado el atributo Category por el atributo DaySemantics.

Si recordamos, el atributo antiguo debía tener un binding con el tipo WDY_MD_DATE_MARKING_CATEGORY, que permitía dar cuatro tipos de colores al calendario. La nueva propiedad, que se debe ligar al tipo WDUI_TABLE_CELL_DESIGN, permite utilizar cualquier color definido en el estándar de Web Dynpro for Abap. Además, se ha añadido la propiedad tooltip, con la que se puede dar una explicación a cada día del calendario, que se mostrará al pasar el cursor por el día correspondiente.

A parte de esta modificación en el DateNavigatorMarking, se ha eliminado la posibilidad de adjuntar una leyenda al calendario del tipo DateNavigatorLegend. Si se quiere añadir una leyenda al calendario, habrá que hacerlo con el elemento general para las leyendas, que es el Legend.

A este elemento se le pueden añadir dos tipos de subelementos. El primero es el Legend_Item, que sirve para poner una línea en la leyenda, explicando un color o un símbolo. Las propiedades que se le puede dar a este elemento son:

ImageSource: para indicar un icono o imagen a explicar.
Semantics: para indicar un color a explicar.
Striped: para indicar si el color es a rayas o no.
Text: para escribir el texto de la explicación.
Tooltip: por si se requiere una mayor explicación, que aparezca en un cuadro al poner el cursor por encima de la línea.

Con este elemento podemos poner a mano uno a uno las líneas de la leyenda. El segundo elemento que admite es el Multiple_Legend_Item, que permite con un solo elemento meter varias líneas a la leyenda. Para ello se debe crear un nodo de contexto (cardinalidad 0..n ó 1..n), con los atributos que se quieran rellenar de los mencionados en la lista anterior. Después, si el contexto se rellena con varias líneas, estas serán las que aparezcan en la leyenda. Una vez creada la leyenda, en la propiedad LegendID del calendario habrá que indicarle el ID de la leyenda recién creada.

Con estos cambios se puede seguir usando este elemento UI Date Navigator para Web Dynpro for Abap , con la mejora de que ahora se permiten muchos más colores en los días a resaltar.

Uno de los aspectos clave a la hora de desarrollar aplicaciones SAPUI5 es la necesidad de acceder a los diferentes elementos de la aplicación desde cualquier punto de la aplicación.

En artículos anteriores ya hablábamos del patrón Modelo-Vista-Controlador usado en SAPUI5 y vimos los ficheros de los que constan las aplicaciones SAPUI5 que se corresponden con cada uno de los componentes en los que se basa este patrón.

Es por tanto, sencillo darse cuenta de que en cualquier momento puede ser necesario por ejemplo, obtener desde un controlador el valor de un control representado en una determinada vista (por ejemplo el nombre de usuario) o acceder a un determinado modelo para utilizar sus datos desde una vista para, por ejemplo rellenar un combobox. ¿Cómo conseguimos conseguir esta información en las aplicaciones SAPUI5?

La respuesta a esta pregunta es: mediante las funciones de acceso al core.

Diferenciamos entre las siguientes tres funciones:

sap.ui.getCore()

Devuelve una instancia de la propia aplicación o core. En el core se puede guardar información global, almacenar modelos entre otras cosas. A nivel de aplicación sap.ui.getCore() es la más potente e interesante a la hora de desarrollar una aplicación SAPUI5.

A partir de esta instancia obtenida se puede acceder a otros objetos de la aplicación utilizando sap.ui.getCore().byId(“ID”), para como hemos dicho antes como ejemplo, obtener el nombre usuario introducido en un campo de un formulario. A continuación se muestra un ejemplo:

Vista: Definimos en la vista un campo de tipo Input para introducir el nombre con ID “miNombre” y un botón que cuando es pulsado ejecuta la función “onPress” definida en su controlador.

createContent : function(oController) {
return new sap.m.Page({
title: "Title",
content: [
new sap.m.Input("miNombre",{
type: sap.m.Input.Text
}),
new sap.m.Button("miBoton", {
text: "Pulsame",
type: sap.m.ButtonType.Accept,
press: oController.onPress})
] });
}

Controlador: Define la función “onPress” mostrando una alerta que informa sobre quién ha pulsado el botón en función del nombre de usuario introducido en el campo.

onPress:function(){
var miNombre = sap.ui.getCore().byId("miNombre");
alert("Boton pulsado por " + miNombre.getValue() + "!!");
}

jQuery.sap.domById()

Esta función devuelve elementos del DOM de Javascript. Funciona igual que la función document.getElementById(“ID”). Se puede utilizar para manipular el DOM o para asignar eventos.

Controlador: Obtiene la referencia del campo de texto con ID “miNombre” y le asigna funcionalidad al evento “onmouseover”.

onPress:function(){
var miNombreDOM = jQuery.sap.domById("miNombre");
miNombreDOM.setAttribute('onmouseover','alert("hover")');
}

jQuery.sap.byId()

Devuelve un objeto jQuery correspondiente a elementos del DOM de Javascript. Funciona igual que los selectores jQuery(“#ID”) o $(“#ID”). Es muy útil para llevar a cabo efectos visuales colores, efectos, tamaños de letras etc…

Controlador: Modifica el color del elemento cuyo ID sea miNombre y sus hijos.

onPress:function(){
jQuery.sap.byId("miNombre *").css("color","red");
}

Con estas tres funciones de acceso al core ya podemos acceder a los diferentes elementos de nuestra aplicación SAPUI5.

¿Qué es programar bien? Antes de responder a esta pregunta, tal vez debiéramos definir qué es para nosotros “programar bien”, porque seguro que cada uno tenemos una idea diferente sobre este concepto.

Para algunos un programa bien hecho es cualquiera que haga lo que tiene que hacer, para otros es el que menos tiempo tarde en hacerlo, o el que menos recursos necesite…

Parece claro que no hay una única respuesta a esta pregunta, así que vamos a aclarar a que nos referimos con “programar bien” aquí. Todos los factores mencionados son, por supuesto, muy importantes y a tener en cuenta, pero hay otro que muchas veces se nos olvida, y es de lo que vamos a hablar en este artículo, de cómo hacer que nuestros programas sean legibles por todos, ya que, estos consejos nos pueden ahorrar mucho tiempo y esfuerzo en el día a día.

Un programa bien hecho tiene que ser fácil de entender, tiene que poder seguirse de un vistazo, sin necesidad de invertir mucho tiempo en ello.

Buenas prácticas en programación: Utilizar nombres claros

Todos hemos visto programas en los que los nombres de las variables, los métodos o las funciones no tienen ninguna relación aparente con su funcionalidad. Y, aunque es cierto que resulta más cómodo llamar a una variable nm o tl, lo más probable es que nadie (incluidos nosotros mismos pasado un tiempo) entienda a que hacen referencia. Pero, si utilizamos numero_de_mes o tipo_de_libro, todos sabremos de lo que estamos hablando. En el siguiente ejemplo se pueden ver claramente las ventajas de utilizar nombres claros.

FORM calc_d.
IF nm = '02' AND tl = 'PO'.
pd = 25.
ENDIF.
IF nm = '06' AND tl = 'CF'.
pd = 15.
ENDIF.
IF nm = '09' AND tl = 'LE'.
pd = 20.
ENDIF.
ENDFORM.

Con este código no sabemos lo que estamos haciendo, ni la subrutina ni las variables tienen nombres que aclaren su funcionalidad. El siguiente, en cambio, empieza a aclararnos qué hace la subrutina y que valores guardan nuestras variables.

FORM calcular_descuento.
IF numero_de_mes = '02' AND tipo_de_libro = 'PO'.
porcentaje_de_descuento = 25.
ENDIF.
IF numero_de_mes = '06' AND tipo_de_libro = 'CF'.
porcentaje_de_descuento = 15.
ENDIF.
IF numero_de_mes = '09' AND tipo_de_libro = 'LE'.
porcentaje_de_descuento = 20.
ENDIF.
ENDFORM.

Aprender a programar bien: Evitar el uso de literales

Una vez que hemos conseguido que las variables tengan nombres que podamos entender, otra clave a tener en cuenta es la utilización de literales. En el ejemplo anterior utilizábamos ‘06’ y ‘CF’ directamente en el código, y, sí, el número de mes se puede intuir por el contexto (06 – Junio), pero, ¿qué significa CF? Justo son estas dudas las que queremos evitar, y, para ello, una manera de programar bien es la utilización de constantes. Nos llevará más tiempo de primeras, pero hará que nuestro código sea más entendible y más fácilmente modificable.

A continuación hemos sustituido los literales del ejemplo anterior por constantes más claras y explicativas.

CONSTANTS: febrero    TYPE string VALUE '02',
junio      TYPE string VALUE '06',
septiembre TYPE string VALUE '09'.
CONSTANTS: policiaco       TYPE string VALUE 'PO',
ciencia_ficcion TYPE string VALUE 'CF',
libro_escolar   TYPE string VALUE 'LE'.
FORM calcular_descuento.
IF numero_de_mes = febrero AND tipo_de_libro = policiaco.
porcentaje_de_descuento = 25.
ENDIF.
IF numero_de_mes = junio AND tipo_de_libro = ciencia_ficcion.
porcentaje_de_descuento = 15.
ENDIF.
IF numero_de_mes = septiembre AND tipo_de_libro = libro_escolar.
porcentaje_de_descuento = 20.
ENDIF.
ENDFORM.

Aquí sí que se aprecia claramente lo que nuestro código hace, de un vistazo, y sin tener que intuir nada. Esta es la diferencia de seguir buenas prácticas a la hora de programar, o no.

Antes de seguir para un momento y vuelve a mirar el código del que partíamos, con dos cambios sencillos hemos conseguido que un código ininteligible sea muy sencillo de seguir.

Cómo programar bien: Organizar el código

Otro de los hábitos más comunes entre muchos programadores es escribir todo el código seguido, sin separarlo u organizarlo de ninguna manera. Y esto también complica mucho su lectura, porque no sabremos qué se está haciendo en cada sitio, ni sabremos a donde ir cuando tengamos que hacer alguna modificación.

En ABAP tenemos varias herramientas para evitar esto: funciones, subrutinas, métodos, clases… La cuestión es utilizarlas para que nuestro código quede bien estructurado y su compresión sea más fácil.

Un buen ejemplo de esto lo podemos encontrar en la serie de artículos sobre Procesamiento de XML en ABAP, en el que se declaran tres subrutinas con objetivos muy claros y que organizan tanto de forma visual como lógica, todo nuestro código. Así, en vez de tener una llamada a una función seguida de un LOOP y un INSERT, todo del tirón, tenemos tres procesos bien definidos (Leer el XML, Transformar el XML y Guardar los datos).

Consejos para programar bien: Conclusión

Aunque a priori nos cueste más trabajo, siguiendo algunas pautas sencillas y cambiando un poco nuestros hábitos, podemos hacer que nuestro código sea mucho más entendible y utilizable por todos. Así, además de alegrarle el día al que tenga que leer nuestros programas podremos decir que sí, que sabemos programar bien.

En Febrero de este 2015, SAP lanzó la nueva versión de su suite de aplicativos de gestión de negocio, construida sobre SAP HANA y con toda la capacidad que ésta ofrece. SAP S/4HANA es la mayor innovación de SAP desde SAP R/3

¿Qué es SAP S/4HANA?

SAP S/4HANA es una suite de aplicativos informáticos de gestión integral de negocio de última generación. Se trata de un nuevo producto desarrollado sobre SAP HANA, la plataforma de procesamiento in-memory más avanzada a día de hoy y que se aprovecha de las últimas innovaciones de SAP para optimizar la experiencia de usuario con SAP Fiori.

SAP S/4HANA ofrece una gran simplificación en cuanto a gestión de procesos (modelo de datos, experiencia de usuario nuevo, toma de decisiones, modelos y procesos de negocio) y en cuanto a alineamiento con las últimas innovaciones tecnológicas (Internet of Things, Big Data, Business Networks, Movilidad).

En definitiva, SAP S/4HANA ha sido concebido como la herramienta de gestión idónea para impulsar la economía digital y el modelo de Industria 4.0.

¿De dónde viene el nombre de SAP S/4HANA?

SAP S/4HANA es la abreviatura para SAP Business Suite 4 HANA. Incorpora una cantidad masiva de innovaciones y desde el punto de vista tecnológico supone un salto incluso mayor que el de la transición de SAP R/2 a SAP R/3.

¿Qué opciones de implantación están disponibles?

Los partners de SAP ofrecen modelos de implantación on-premise (en las propias instalaciones del cliente), en la nube y modelos híbridos. Todos estos modelos de implantación están disponibles en el mercado.

¿Cuáles son las ventajas de migrar a SAP S/4HANA para un cliente de SAP?

La visión y estrategia de SAP es ayudar a sus clientes a impulsar la economía digital. Para realizar su visión, SAP está redefiniendo cómo el software de empresa crea valor.

SAP S/4HANA está diseñado para añadir valor en todas las líneas de industria y de negocio gracias a la sofisticación última: la simplicidad.

Desde una perspectiva de valor de negocio, esto significa que SAP S/4HANA crea oportunidades únicas para reinventar el modelo de negocio y organizativo de sus clientes y acompañar en la creación de nuevos modelos de gestión y de beneficio. Por un lado, las empresas ahora se pueden conectar fácilmente a personas, dispositivos y redes de negocio para ofrecer valor a sus clientes por cualquier canal – se trata de sacar partido a los conceptos Internet of Things y Big Data. Por otro lado, las empresas pueden simplificar sus procesos, gestionarlos en tiempos real y cambiarlos según vean necesario para maximizar su eficiencia – aquí el batch processing ya no es necesario.

Por último, los usuarios de negocio pueden consultar los datos que quieran, de la forma y con el nivel de detalle que quieran, en cualquier sitio, a cualquier hora, y en tiempo real: Se pueden controlar todos los aspectos de planificación, ejecución, predicción y simulación.

Desde una perspectiva de valor de sistemas de información, esto significa que SAP S/4HANA crea oportunidades para simplificar infraestructura y reducir el Coste Total de Propiedad (CTO) con SAP HANA. Primero, las empresas pueden concentrar todas sus fuentes de datos en un mismo sistema de gestión que centralice todas las operaciones de la empresa (ERP, CRM, SRM, SCM, PLM), lo cual además de reducir tiempos, permite ahorrar en hardware.

Además, tenemos la posibilidad de crear experiencias de usuarios basadas en roles concretos, lo cual incrementa la productividad a la vez que permite reducir costes de formación. Finalmente, se ofrece a la empresa el modo de implementación que mejor le encaje: cloud, servidores en las propias instalaciones, y modelo híbrido.

Conceptos clave sobre SAP S/4 HANA

Menor infraestructura de almacenamiento de datos y en el data footprint (rastros de datos dejados por el usuario)
Mayor integración entre procesos
Analíticas y reportes más rápidos
Simplificación en la gestión de procesos
Implementación simultánea de ERP, CRM, SRM, PLM
Convivencia de datos actuales (25%) y datos históricos (75%)
Capacidad de carga de datos ilimitada
Realización sencilla de predicciones, modelos y simulaciones
SAP HANA en tenencia múltiple: misma infraestructura que sirve a varias aplicaciones que a su vez pueden servir a varios clientes, organizaciones, etc.
Todo tipo de datos: social, textos, numéricos, geográfico, procesamiento, etc
Integración con cualquier dispositivo de movilidad
Modelo de implementación a la carta

Estas son en resumen las claves sobre la SAP S/4HANA, la suite de negocios más innovadora del grupo SAP.

En ocasiones, desde el punto de vista de un responsable, es interesante conocer qué opina el resto de empleados acerca de un tema en concreto. Una forma de llevarlo a cabo es preparar una encuesta de satisfacción personalizada.

Con la herramienta SAP SURVEY, SAP nos brinda la posibilidad de conocer las opiniones de nuestros empleados, con la posibilidad de personalizar y enviar por email cuestionarios a los usuarios y, posteriormente, visualizar las respuestas que han rellenado.

Transacción SAP SURVEY.

Su gran particularidad es que está integrado en el propio sistema, por lo que, entre sus múltiples posibilidades, se pueden enviar los resultados a BW y evaluarlos mediante sus propios métodos. A su vez, gracias al uso de una Biblioteca o Librería de aplicación, podemos personalizar aún más la encuesta de satisfacción personalizada, permitiéndonos, por ejemplo, alterar preguntas según qué usuario sea el receptor de la encuesta, validar campos, etc.

Survey Cockpit

Al entrar en esta transacción podemos crear o seleccionar una encuesta existente y así accederemos a la “Survey Cockpit“, que se definiría como la pantalla principal de control desde la que se gestiona todo lo referente a las encuestas.

En esta pantalla, a la izquierda, tendremos definidos los destinatarios o grupos de ellos, que van a ser objetivo de esta encuesta de satisfacción personalizada y, a la derecha, una previsualización del cuestionario a enviar, o, si ya ha sido respondido, podremos ver qué contestaciones han dado. También podemos ver el estado en el que se encuentra la encuesta (enviada, respondida, etc). Si el usuario receptor existe en nuestro entorno de SAP, no es necesario rellenar ni sus datos ni su e-mail, ya que automáticamente los busca en el sistema una vez introducido su uname.

Para comenzar una encuesta primero hay que formular la serie de preguntas que nos interesa que sean respondidas. Se crea mediante el botón “Nuevo” Botón de creación de un nuevo formulario y puede tener distintos formatos: desde cuadros de texto en los que el usuario ha de escribir la respuesta, a múltiples opciones de las que se ha de seleccionar una o varias (checkbox, radiobuttons, etc).

Envío del cuestionario

Una vez se ha seleccionado la encuesta y el grupo destinatario que va a ser objetivo de esta, al pulsar “Enviar cuestionario” Botón de envío de cuestionario para que sea respondido da comienzo y se envía mediante un email a los integrantes del grupo destino. Cuando el receptor está de acuerdo con las respuestas introducidas, con pulsar el botón “Enviar cuestionario” Botón de devolución de la encuesta respondida se enviará de vuelta y ya estará listo para ser analizado por su responsable mediante la Survey Cockpit.

Gracias a su facilidad de uso, la transacción SAP SURVEY es una intuitiva herramienta para tener control sobre las opiniones que tienen los usuarios acerca de un tema determinado. Además, debido a su gran profundidad, la encuesta de satisfacción personalizada puede ir desde la simpleza más absoluta hasta la complejidad que se desee.

Si en artículos anteriores, parametrización de viajes parte 1 y parametrización de viajes parte 2, aprendíamos a parametrizar los datos de un viaje en SAP HCM, En este artículo se explicará cómo visualizar los datos del clúster TE de viajes.

Para ello accederemos a la transacción PRTE (programa: RPCLSTTE)

Como vemos, podemos filtrar por diferentes criterios; así como por número de personal, número de la hoja de gastos, fechas del viaje…

Una vez seleccionado los criterios necesarios para la ejecución y ejecutemos el programa obtendremos un listado de los viajes resultantes y todas sus versiones:

En este caso en las columnas “P.VS” y “H.VS” vemos que todos los valores son 99; eso indica que la hoja de gastos no ha tenido modificaciones después de haberse transferido a nómina o FI. En el caso en el que una hoja de gastos se haya transferido y posteriormente se haya modificado, se creará automáticamente una nueva versión, para que SAP pueda calcular las diferencias entre ambas versiones.

Tablas del cluster TE de viajes

Si seleccionamos una de las líneas y hacemos doble clic o pinchamos sobre Icóno de búsqueda obtendremos las diferentes tablas que conforman el clúster de viajes. A continuación se hace un resúmen de las tablas más importantes:

PTRV_HEAD: En esta tabla tendremos los datos relacionados a la cabecera del viaje, así como la variante de reglamentación del viaje, el tipo de esquema seleccionado…
PTRV_PERIO: En esta tabla tendremos los datos relacionados al periodo en el que se ha liquidado el viaje, área de nómina correspondiente al empleado…
BELEG: En esta tabla veremos una entrada por cada clase de gasto introducida en la hoja de gastos. Por cada una de ellas veremos los datos de importe, fecha, tipo de cambio…
TEXT: En esta tabla encontraremos los comentarios introducidos a nivel de hoja de gastos
KMVER: Aquí veremos los datos relacionados al kilometraje
AEND: En esta tabla veremos todos los estados por los que ha ido pasando esta hoja de gastos
STATU: En esta tabla veremos el estado actual de la hoja de gastos
KONTI: Esta tabla contendrá las órdenes de imputación que el empleado haya introducido en la hoja de gastos. Mediante otra serie de tablas de costes podremos ver exactamente la imputación si es a nivel de hoja, de clase de gasto o de kilometraje. En el caso en el que esta tabla esté vacía significará que se contabilizará contra las órdenes del infotipo 0027 subtipo 02.
ROT: Una vez liquidada la hoja de gastos se rellena esta tabla, haciendo la conversión entre clase de gasto / CC-nómina. Estos datos serán los que posteriormente se transfieran a nómina o FI.

Como vemos, es sencillo visualizar los datos del cluster de viajes, ya que una vez que accedemos a la transacción PRTE, basta con seleccionar los criterios de búsqueda que más se ajusten a nuestras necesidades. Estos datos pueden ser muy útiles en el módulo SAP HCM.

En Web Dynpro for Abap (WD4A), a la hora de definir el contexto de una aplicación Web Dynpro tenemos que tener en cuenta cómo queremos definir los diferentes nodos para poder mostrar y recoger información del usuario. Por esto es muy importante definir correctamente las propiedades de los nodos del contexto. A continuación se explican las diferentes propiedades que podemos modificar.

Interface Node

En el artículo reutilización de componentes comentamos la posibilidad de reutilizar los componentes que creamos, y que los nodos pueden ser parte de la interfaz del componente reutilizado. Al marcar esta propiedad hacemos que este nodo sea visible para un componente que reutilice este contexto.

Input Element

En WD4A, esta propiedad es utilizada en la reutilización. Si la propiedad Input Element también está seleccionada, el nodo debe estar también mapeado al nodo definido en el Component Controller padre. Esto sirve para poder modificar el contexto en el componente padre.

Dictionary Structure

A un nodo se le puede relacionar con una estructura o tabla definida en el Diccionario de Datos. De este modo, los atributos de este nodo tendrán las mismas propiedades que en el diccionario. El problema de asignar esta propiedad, es que a este nodo únicamente se podrán meter atributos de esta estructura.

Cardinality

En tiempo de ejecución, las estructuras se rellenan con valores, y cada atributo puede tener varios valores (tablas). Para especificar cuántos valores puede contener un nodo, se usa la propiedad cardinality:

.1: Cero o un elemento permitidos (estructura).
.n: Cero o más elementos permitidos (tabla).
.1: Exactamente un elemento permitido (estructura).
.n: Uno o más elementos permitidos (tabla).

Por lo tanto, un nodo que tenga de cardinalidad máxima 1, es como una estructura ABAP, y un nodo que tenga n, será como una tabla interna.

Selection

Esta propiedad indica el número de elementos de la colección que pueden ser seleccionados. Habrá que tener en cuenta la propiedad anterior para definir esta, ya que no se podrá decir que se puedan seleccionar n elemento en una estructura.

Lead Selection

Un elemento de una colección de un nodo (tabla) puede ser seleccionado por un valor basado en índices. Exactamente un elemento de la colección del nodo puede ser marcado como Lead Selection. El Lead Selection del contexto de un nodo apunta bien a un solo elemento del nodo, ó, si no hay elemento seleccionado, tiene el valor de la constante: IF_WD_CONTEXT_NODE=>NO_SELECTION.

El valor del Lead Selection puede ser automáticamente inicializado con la propiedad Initialize Lead Selection.

Si el Lead Selection tiene valor:

Se pueden utilizar métodos especiales para acceder al Lead del nodo en el código del controlador.
Elementos del interfaz de usuario pueden ser asignados a los atributos de este elemento.

Singleton

En un contexto como el de la imagen en el que existe un nodo FLIGHTS con cardinalidad 0..n que contiene otro nodo BOOKINGS, con cardinalidad 0..n, la propiedad Singleton afecta de manera crítica a la relación entre el nodo FLIGHTS y el nodo BOOKINGS.

Si el nodo BOOKINGS tiene la propiedad Singleton con valor ‘false’, por cada elemento en la colección del nodo padre, existirá una instancia del nodo hijo BOOKINGS.

En cambio si el nodo BOOKINGS tiene la propiedad Singleton marcada, no importará cuantos elementos estén presentes en el nodo padre, siempre existirá una sola instancia del nodo hijo BOOKINGS, por lo que la colección BOOKINGS será Singleton en tiempo de ejecución.

Ventajas de nodos Singleton:

Acceso a datos ‘Lazy’. Los datos son creados cuando son realmente necesitados. Esto significa que si los datos no se requieren, el nodo hijo permanece sin procesar. También implica que colecciones dependientes no son creadas automáticamente para todos los elementos del nodo padre. La creación de la colección de nodo dependiente es retardada hasta el punto que el elemento relacionado de la colección padre obtiene el Lead Selection.
Menor consumo de datos.

Inconvenientes de nodos Singleton:

Mayor número de accesos a base de datos. Por lo que se puede ralentizar la ejecución de la aplicación.

Este es un pequeño resumen de la propiedades de los nodos del contexto más importantes, de Web Dynpro For Abap.

Vamos a realizar una explicación de cómo SAP gestiona los materiales y pedidos de consigna en SAP MM, es decir, del proceso que sigue la consignación en compras.

En la gestión de stocks en consignación, el proveedor suministra materiales y los almacena en sus dependencias. El proveedor queda como el propietario legal del material hasta que se tomen los materiales del almacén de artículos en consignación.

Es en este momento que el proveedor solicita el pago. El vencimiento de la factura se produce en períodos de tiempo prefijados. Además, puede acordar con el proveedor que asumirá personalmente la propiedad del material restante en consignación tras un determinado período de tiempo.

Registro de materiales

Una de los primeros requisitos dentro de los datos maestros será tener bien definido el dato del material que se quiera tener en consigna (MM01 – Crear maestro materiales), material en consignación.

En este punto dentro de la pestaña “Planificación de necesidades 2″ deberemos alimentar el campo clase de aprovisionamiento especial con 10 (Consignación).

Este tipo de aprovisionamiento especial de consignación conlleva que automáticamente la posición del pedido de compras que se haga en el futuro; esté marcada como posición de pedido de consigna (C).

Registro info

Otro de los datos maestros que debemos informar es la creación de un registro info de tipo consignación con el proveedor.

Se creará un registro info (ME11 – Crear Registro info) de tipo subcontratación.

Y ahí se añadirán los datos correspondientes al acuerdo entre la empresa y el proveedor de consignación.

Pedido de consigna

Llega el momento del aprovisionamiento del material y nos debemos crear el pedido de compras (ME21N – Crear pedido de compras).

En el caso de haber informado correctamente los datos maestros (Registro de material y registro info); al crear el pedido contra el material subcontratado, el pedido avisará para marcar como consigna (Tipo de posición – C)

Ya tenemos la base para comenzar con el aprovisionamiento de material y seguir con la consignación en compras. En el siguiente artículo, aprenderemos a realizar la entrada de mercancía asignándosela al pedido de consigna y liquidar así la consignación en compras.

En el artículo anterior, aprendimos a crear un pedido de consignación en SAP MM, partiendo de la creación de registo de materiales y registro info.

En este nuevo artículo, seguiremos con la gestión de consignación en compras, aprendiendo a controlar la mercancía mediante el pedido de consigna creado, ya que, una vez que el pedido llega al proveedor y éste envía la mercancía, se realiza la entrega entrante contra el pedido de consigna.

Entrada de mercancías

Se realiza la entrada de mercancías del material en consigna. Esto se puede realizar desde la transacción MIGO (Registrar movimientos de material) o desde la transacción VL31n (Crear entrega entrante) y de esta manera registramos la entrada de mercancías del pedido con nuestro material en consigna.

Debido a que en nuestro caso tenemos parametrizado que en el pedido nos exige realizar una entrega entrante en el control de confirmación de la entrega,

Vamos a utilizar la transacción Vl31n – Entrega entrante.

Una vez realizada la entrega del material de forma correcta y en las cantidades que le hayamos indicado; contabilizaremos en el sistema la entrada del stock.

Esta entrada nos determinará el siguiente movimiento:

Se contabiliza la EM, creando un movimiento 101-K entrada mercancía consigna. (MB03 – visualizar documento material)

Este movimiento de material no genera ningún documento financiero en las cuentas de existencias; ya que a efectos prácticos sigue perteneciendo al proveedor.
Al consultar los listados de stock del material, esta mercancía aparece asignada al proveedor. (Listad de stocks – MMBE)

Nos muestra seleccionando el registro, el número de proveedor de dicho material.

Traspaso de stock a propio

Al realizar el paso de stock del material al stock propio mediante un traspaso se realiza el movimiento 411 – K (traspaso consigna a propio).

Este documento material sí generará los documentos contables de existencias correspondientes.

Una vez hecho nuestro el stock de consigna mediante el movimiento 411 – K, el stock quedará actualizado. Descontará de la consigna del proveedor la cantidad traspasada y lo dejará en el almacén escogido.

Liquidación de la consignación

Registros de condición de mensaje – MRM1:

Es necesario que estén parametrizados los registros de condición KONS (Consignación) para los proveedores de consigna y de esta manera poder informarles del consumo del material en depósito. Esta información puede ser vía mail, fax o mensaje EDI.

Una vez ya tengamos el registro de condición creado; se realiza la liquidación del consumo del material traspasado al stock propio – Liquidación de consignación MRKO. (Es el equivalente a la MIRO.)

En esta transacción es tanto de consulta (Visualizar):

Como para la liquidación (Liquidar):

Automáticamente se genera un documento financiero visible desde la transacción FBL1N (listado de proveedores). Este documento se compensará con la salida de pagos al proveedor.

Una vez realizado todo este proceso, ya habrá finalizado la consignación en compras.

En el artículo anterior sobre los nodos de contexto de WD4A, comentábamos las propiedades del contexto, pero no mencionamos nada de la función supply. Este artículo explicamos que es y para que se puede utilizar.

La función Supply es un mecanismo para repoblar nodos hijos. Una función Supply puede ser asignada a cada nodo del contexto de un controlador. Esta función se llama automáticamente cuando se intenta leer los datos de un nodo de contexto inválido.

Esta invalidez ocurre cuando:

Una colección de un nodo es inicial. Todavía no se han cargado datos en el nodo.
La colección del nodo es invalidada por código (método invalidate).
El Lead Selection en la colección del nodo padre cambia. Esto solo ocurre para nodos hijos con la propiedad singleton marcada.

Para introducir una función de este tipo, le indicamos el nombre que le queramos dar en la opción Supply Function del nodo. Después, por forward navigation (doble clic sobre el nombre de la función), se crea un método en el controlador en que nos encontremos, donde se crea el código para introducir los datos en el contexto automáticamente. En esta función únicamente se debe crear la lectura de datos de base de datos.

El método creado en el controlador tendrá dos parámetros import. Un elemento de contexto, que corresponde al elemento padre del nodo, y un nodo de contexto, que es el propio nodo.

También en este método aparece una serie de código abap comentado. Este código nos ayuda a rellenar el nodo con los datos que queramos. Por lo tanto lo más fácil será descomentar las líneas de código que aparecen. Para explicarlo mejor utilizaremos el siguiente contexto de ejemplo, donde existe un nodo hijo con las reservas de un vuelo.

Primero aparecen unas líneas de código por si queremos coger los elementos del padre. Por ejemplo, para coger el id de Vuelo y la conexión para saber las reservas:

*  if necessary, get static attributes of parent element
DATA ls_parent_attributes TYPE wd_this->element_vuelos.
parent_element->get_static_attributes(
IMPORTING
static_attributes = ls_parent_attributes ).

Luego se accede a la base de datos o lo que se requiera para cargar el nodo, en el ejemplo, recogemos todas las reservas del vuelo:

* data declaration
DATA lt_sbook TYPE wd_this->elements_sbook.
DATA ls_sbook LIKE LINE OF lt_sbook.
* @TODO compute values
* e.g. call a data providing FuBa
SELECT * INTO CORRESPONDING FIELDS OF TABLE lt_sbook FROM sbook
WHERE carrid = ls_parent_attributes-carrid
AND connid = ls_parent_attributes-connid
AND fldate = ls_parent_attributes-fldate.

Y por último cargamos el nodo con los datos recogidos.

* bind all the elements
node->bind_table(
new_items            =  lt_sbook
set_initial_elements = abap_true ).

Así, en nuestra aplicación WD4A, mediante la función supply nos podremos asegurar de que siempre que se intente accede a la información del nodo, este tenga los datos correspondientes y así evitemos errores en tiempo de ejecución.

En este artículo se explicará cómo cargar y ver los datos del clúster de movimientos de tarjeta de crédito para el módulo de SAP HCM.

SAP dispone de un programa estándar que genera ficheros con movimientos de tarjetas de crédito para un empleado específico: RPRCCC_CREATE_TESTFILE

Para generar el fichero en SAP HCM, el empleado debe tener correctamente informados los infotipos 0002, 0008 y en el 0105 el subtipo 0011 con el nº de la tarjeta.

En esta pantalla tendremos que rellenar:

Compañía de la tarjeta de crédito: VI, MC…
Nº ejecución: es un ID para cada fichero ejecutado (solo se puede cargar un fichero por cada ID)
ID empresa: es un ID identificado de la compañía
Ruta donde se generará el fichero
Número de personal del empleado al que se le van a cargar movimientos de tarjeta de crédito

Para cargar los movimientos de tarjeta de crédito en SAP, utilizaremos la transacción estándar PRCC:

En esta pantalla tendremos que indicar:

ID empresa (mismo dato que hemos introducido en el paso anterior)
Test/Real: Si queremos simular o cargar realmente los movimientos en SAP HCM
Ruta donde tenemos el fichero a cargar

Una vez ejecutado el programa nos aparecerá una pantalla con los movimientos erróneos, y si damos para atrás nos aparecerán los movimientos correctamente cargados.

Una vez que hemos cargado datos en SAP HCM, podemos ver los movimientos cargados correctamente mediante la transacción PRCCD:

En este pantallazo podemos ver un movimiento cargado en SAP, pero que aún no se ha asignado a ninguna hoja de gastos: ; y otro movimiento que ya se ha asignado a una hoja de gastos:

Por otra parte, los movimientos de tarjeta de crédito que no han podido cargarse correctamente en SAP, se pueden visualizar a través de la transacción PRCCE:

Mediante esta transacción podremos arreglar los datos del movimiento que no se ha podido cargar; como por ejemplo si el número de tarjeta venía incorrecto, si el empleado no tenía cargada la tarjeta en el infotipo 0105 subtipo 0011… Una vez modificados los datos incorrectos podemos grabar las modificaciones, y mediante el programa RPRCCC_CREATE_CORRECTION_FILE podremos generar otro fichero para poder cargarlo en SAP.

Siguiendo esta breve explicación, podrás cargar y ver los movimientos de tarjeta de crédito de tus empleados, en SAP HCM.