En la anterior entrega se explicaba cómo SAP a partir de la versión 7.1 de Netweaver sustituía la herramienta JSPM por el nuevo SUM.

Con la interfaz gráfica JAVA abierta en el momento, de escanear el directorio con los paquetes .SCA, se muestran los que están aceptados para instalar:

Pulsando en el botón Show Details se muestran los detalles del paquete como lo haría la antigua JSPM:

Se continúa adelante con el support package seleccionado y el SUM se detiene para pedir un certificado CRL. Desde la Url indicada se descarga y se copia en el directorio EPS/in donde se encuentra el paquete .SCA a instalar y se pulsa Repeat para verificar el certificado:

Se verifica que haya una licencia válida. Si no hay una licencia de mantenimiento válida, se recomienda actualizarla antes de continuar, aunque es opcional:

Cuando verifica que todo es correcto, se muestra el resumen con las opciones seleccionadas:

Se muestra un mensaje sugiriendo realizar un backup justo antes de iniciar la actualización:

Cuando finaliza el proceso de actualización se muestra un informe para evaluar el proceso:

También se muestra el resumen en html que genera el programa SUM. Para ello basta con pulsar en el link ProcessOverview.html y se abrirá un navegador de Internet:

Antes de finalizar se solicita enviar a SAP el fichero .zip generado con el resultado de la actualización.

Se comprueba en la página de información (/nwa/sysinfo) de JAVA, donde se muestran los componentes de la instancia, que efectivamente el componente se ha actualizado con el nuevo support package:

¿Aún no sabes lo que es el posicionamiento SEO en buscadores? ¡Pues deberías!

En este artículo te vamos a explicar qué es el posicionamiento SEO, también llamado posicionamiento en buscadores, posicionamiento web, optimización de motores de búsqueda o posicionamiento orgánico.  Así mismo queremos darte las razones de por qué tu empresa lo necesita, y como aprovecharse de estas técnicas para generar beneficios.

1.- ¿Qué es el posicionamiento SEO?

SEO es un acrónimo inglés, que significa “Search engine optimization” o lo que es lo mismo, optimización de motores de búsqueda. Consiste en realizar una serie de técnicas específicas con el objetivo de posicionar un determinado website en las primeras posiciones de los resultados de búsqueda de los principales buscadores.

En España, hablar de posicionamiento SEO en buscadores es sinónimo de querer estar en las primeras posiciones de ciertos resultados de búsqueda en GOOGLE, puesto que es el buscador mayoritario.

2.- ¿Para que sirve el posicionamiento SEO?

Esta ampliamente demostrado que los primeros tres websites (excluyendo los resultados patrocinados) de las páginas de resultados son los que se llevan el 80% del pastel, es decir, el 80% de los “clicks” de usuarios. Es mas, el primer posicionado se lleva mas de la mitad de los clicks, por lo que parece evidente que es interesante aparecer en dicha posición.

Hagamos un ejercicio de imaginación que sirva como ejemplo: Si tenemos una tienda de lavadoras y queremos posicionarla en google; ¿No sería estupendo que cuando un usuario realice la búsqueda “comprar lavadora” aparezcamos los primeros? Creo que ya podemos hacernos una idea entonces de para qué sirve el posicionamiento web SEO.

3.- ¿Por qué necesito el posicionamiento SEO para mi web / empresa?

Fácil, porque tu competencia ya lo esta haciendo, casi con total seguridad. Cada día estas perdiendo clientes por descuidar el escaparate mas grande que tienes: Internet.

El posicionamiento SEO en buscadores comenzó a existir tan pronto se crearon los primeros buscadores, allá por los años 90, aunque no fue hasta principios del siglo XXI cuando llegó realmente la fiebre del SEO. Es decir, si no has hecho nada al respecto, puede que te lleven 10 años de ventaja.

Seguiremos en el próximo artículo respondiendo a otras dos importantes cuestiones: ¿En que consiste un proyecto de posicionamiento SEO? y ¿Cómo elegir una empresa de posicionamiento SEO en buscadores?

Como ya hablábamos en el anterior artículo sobre ¿Qué es el posicionamiento SEO?, la importancia de esta herramienta de marketing on-line es indiscutible. En esta segunda parte hablaremos sobre cómo llevar a cabo un proyecto de posicionamiento SEO de manera exitosa.

4.-  ¿En que consiste un proyecto de posicionamiento SEO en buscadores?

No es sencillo, la verdad. Posicionar una página web es un proceso largo y complicado, y estas dos variables se verán afectadas por otras tantas: Tipo de sector de la empresa/web, público objetivo, competencia, época del año, …

Siempre va a ser necesario desarrollar una hoja de ruta y un estudio del sector y de la competencia al principio del proceso. La planificación de un proyecto de posicionamiento SEO en buscadores lo es todo.

Además, un estudio de palabras clave (palabras por las que competiremos en las búsquedas, también llamadas keywords) será indispensable al principio del proceso de posicionamiento web.

Una vez realizados estos pasos preliminares, se lleva a cabo el grueso del proyecto. Esto consiste en ejecutar diversas acciones y estrategias que un SEO profesional conoce al detalle. Pero no nos engañemos, por lo general no se posiciona una web en unos días. Es mas bien cuestión de meses.

Una vez “terminado” el proceso de posicionamiento SEO en buscadores, se requerirá un mantenimiento periódico que asegure que los cambios en los algoritmos de los buscadores no afecten al posicionamiento orgánico conseguido, o que la competencia no nos adelante porque esta llevando a cabo nuevas acciones. Es decir, habrá que estar siempre alerta.

5.- ¿Cómo elegir una empresa de posicionamiento SEO en buscadores?

La profesionalidad de una empresa que se dedique a posicionar páginas web mediante técnicas de SEO, se ve enseguida. Asegúrate de que sigue todo el proceso y sobretodo, que no escatima en la planificación. Deben explicarte en todo momento la hoja de ruta a seguir y consensuar contigo las acciones a tomar.

Desconfía de aquellos que ofrezcan duros a pesetas, planes de posicionamiento muy baratos o en poco tiempo, o incluso de aquellos que te aseguren que vas a estar en la primera posición. Nadie puede asegurarte aparecer el primero, porque no es una ciencia exacta. Seguro que con un buen plan de posicionamiento SEO ganas visibilidad, clientes y reputación, pero ser primero no esta nunca asegurado.

Y después de leer esto… ¿Sabes ya qué es el posicionamiento SEO en buscadores?

Es habitual que durante el tratamiento de objetos del portal (carpetas, iViews, páginas, roles…)  en el Portal Content Studio nos aparezca un aviso informándonos de que no es posible modificar el objeto porque ya está abierto por otro usuario.

Cuando un usuario abre un objeto para su edición este se bloquea automáticamente para el resto de los usuarios. En estos casos, el objeto se abre en modo “Sólo lectura” y hasta que el usuario que tiene abierto el objeto no lo cierra o hasta que no se fuerza el desbloqueo de este, no es posible modificarlo.

En este artículo se va a explicar cómo es posible desbloquear estos objetos para poder editarlos.

En primer lugar, es necesario disponer del rol System Administrator lo que permitirá visualizar la pestaña “Gestión del sistema” del portal. En otro caso, se deberá esperar a que el objeto sea desbloqueado por el usuario que lo tiene abierto actualmente o a que se desbloquee por expiración de sesión.

Del menú que se abrirá al seleccionar esta pestaña hay que elegir la opción “Monitoring”. En la parte izquierda de la pantalla aparecerá un menú de navegación en el que visualizaremos dos elementos: “Portal”  y “Knowledge Management”.

Desplegando el primero de ellos nos encontraremos con la opción que nos permitirá gestionar los bloqueos de los objetos de portal “Bloqueos de objeto”.

Una vez seleccionada esta opción, en la parte derecha de la pantalla aparecerá una tabla con la lista de objetos de portal bloqueados en ese momento, en la que se indicarán entre otros aspectos el tipo de objeto bloqueado, el ID del objeto, qué usuario tiene bloqueado el objeto y el tiempo restante para el desbloqueo automático del mismo.

En caso de que la lista sea larga y se desee desbloquear un objeto concreto, es posible facilitar la búsqueda de este mediante un buscador que nos permite filtrar los objetos por su URL o por el identificador del usuario que lo tiene bloqueado.

En cualquier caso, para desbloquear un objeto, basta con seleccionarlo en la tabla y pulsar el botón “Desbloquear”.

Si el desbloqueo se completa con éxito aparecerá un mensaje informando de ello en la parte superior de la pantalla.

De esta manera, el objeto quedará libre para su edición.

Uno de los problemas con que se puede encontrar un consultor SAP BW a la hora de agrupar información de diferentes fuentes en una única, es seleccionar la opción adecuada. Hoy vamos a analizar la diferencia entre dos de esas opciones, el MultiSitio (Multiprovider) y el InfoSet. Sin entrar en el detalle de cómo se crean, veamos cómo se comporta cada uno de ellos y así entenderemos los casos concretos en que debemos elegir uno u otro.

Diferencias entre InfoSet y MultiSitio

MultiSitio (MultiProvider)

Agrupa todos los registros de los InfoProviders que lo componen. La cantidad de registros disponibles es, por tanto, la suma de los registros de cada InfoProvider. A la hora de crearlo se especifica cada InfoObjeto de que InfoProvider proviene, pudiendo elegir en caso necesario, más de uno. En el MultiSitio resultante, por tanto, no habrá InfoObjetos repetidos.

Infoset

Cruza los registros de los InfoProviders que lo componen. A la hora de crearlo se especifica por medio de que InfoObjetos se relacionan los InfoProviders.  Existe la posibilidad de cruzarlos de manera normal (inner join), que aparezcan todos los registros de uno de los componentes (left outer join) o que aparezcan los que no tienen en común (anti join).

Para su mejor comprensión, veamos los diferentes comportamientos con un ejemplo.

Tenemos un cubo y un ODS con diferente información sobre las incidencias de los clientes:

Cubo

ODS

Multicubo

Al juntarlos en un multicubo, se obtienen 12 registros (5 del Cubo + 7 del ODS). Cada uno con los campos correspondientes a su origen rellenos y vacíos el resto.

InfoSet

Veamos las diferentes opciones a la hora de enlazar los datos.

• Inner join

Al juntarlos mediante inner join, se obtienen 5 registros. Los que existen tanto en el Cubo como en el ODS. Todos los campos están rellenos y los que existen en ambas fuentes, aparecen por duplicado. La cantidad de registros disponibles es, por tanto, igual a la cantidad de registros que tienen informados esos campos en todos los InfoProvider.

• Left outer join

En este caso, la cantidad de registros resultante es igual a la de uno de los InfoProvider que lo compone, el ODS.  Por lo tanto, los datos del ODS estarán todos rellenos y la información del cubo se completará en aquellos registros que existan también en el cubo.

• Anti join

Por último, con el anti join, se obtienen los registros que sólo están en uno de los InfoProvider y no en el otro. En nuestro caso, los dos registros que están sólo en el ODS.

Así que solo hace falta tener claro que se quiere conseguir para elegir la opción adecuada.

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.

En este artículo te vamos a explicar qué puntos claves deciden si un CRM es bueno o no, y como aprender a analizarlos. Si necesitas cambiar de CRM o estas buscando tu primer CRM para mejorar la gestión de las relaciones con tus clientes, sigue leyendo.

Hay dos aspectos generales que un comprador jamás debería pasar por alto a la hora de embarcarse en un proceso de selección de CRM. El primero es que las soluciones CRM no sólo se refieren al uso de la tecnología. Implican un cambio o mejora de los procesos relacionados con las relaciones con el cliente. El segundo es que las soluciones CRM deben incluir un cambio de un marketing y gestión de ventas tradicional a un modelo relacional.

En cuanto a la solución CRM en sí, consideramos que ésta es ideal cuando cubre los siguientes puntos:

1)     Gestión de Oportunidades: OMS (Opportunity Management Service)

2)     Sistema de Configuración de Ventas: Permite la configuración de materiales, precios, promociones, servicios, opciones de financiación y marketing.

3)     Partner Relationship Management

4)     Sistema de Venta Interactiva: Capacidad de establecer relaciones comerciales sin necesidad de un operador. Incluye técnicas:

1. Cara a Cara
2. Web Colaborativa
3. Cliente Self-Service

5)     Compensación e Incentivos: Corresponde a la capacidad de gestionar los incentivos, planes de compensación y cuotas para transacciones susceptibles de generar comisiones de venta. Implica la existencia de herramientas de reporting y de utilidades de simulación de ventas.

6)     Gestión de Contenidos: Esta herramienta permite el acceso a los contenidos de cualquier naturaleza (textos, gráficos, animaciones, vídeos…).

7)     E-Service: Corresponde a herramientas que permiten a clientes, partners y clientes potenciales para relaizar consultas self-service e interacciones con la empresa vía internet, intranet o extranet.

8)     Gestión de Llamadas: Funcionalidad central de las aplicaciones de CSS (Customer Service Support). Se usa para llamadas y transacciones entrantes, y para la gestión de las transacciones del inicio al fin de la interacción.

9)     Field Service: Incluye herramientas de previsiones, gestión de contratos, garantías, servicio de componentes, gestión de infraestructura, inventario, seguimiento de defectos (Gestión de Calidad) y Reporting.

10)  Personalización: Capacidad de personalziar el entorno de contacto del cliente en función de múltiples parámetros (preferencias, datos relevantes de cliente, comportamientos, etc).

11)  Software Analítico: Capacidad de Elaborar estadísticas e Informes.

12)  Gestión de Marketing: Gestión de campañas, generación de perfiles, target groups y capacidades de segmentación.

13)  Escalabilidad: Posibilidad de adaptación a los cambios de la empresa, manteniendo los costes y el tiempo de respuesta al mínimo posible.

14)  Parametrización

15)  Rapidez de Implantación

Si quieres saber con cuántas de estas ventajas cuenta el CRM específico de SAP, te recomendamos que visites la siguiente página web: Ventajas de SAP CRM

Dakizuen bezala, duela gutxi BAI EUSKARARI ziurtagiriaren bigarren maila eskuratu genuen. Horrekin, erakusten dugu gure zerbitzuak euskaraz emateko gai garela eta hori ospatzeko Facebook lehiaketa bat prestatu dugu. Lehiaketa honen saria, irudian agertzen den padel pala da.

Lehiaketan parte hartzeko, sartu hemen eta egin iruzkin bat EUSKARAZ, hurrengo galdera erantzunez:

zer beste erabilera original eta desberdina emango zenioke padel erraketa bati?

Iruzkinik originalena egiten duen pertsona, padel pala honen irabazlea izango da!

Horrez gain, parte hartzen dutenen artean Oreka IT-ren bi produktu-sail zozkatuko dira. Parte hartu!

Ondoren dauzkazue lehiaketaren oinarriak:

Lehiaketaren oinarriak:

1. Oreka IT-ren Facebook-eko orrialdean padel pala baten irudi bat argitaratuko da. Irudi honetan lehiaketan parte hartzeko baldintzak erakutsiko dira. Hauek izango dira:
   1. Oreka IT-ren Facebook-eko orrialdearen jarraitzailea izatea: oraindik gure Facebook-eko orrialdearen jarraitzailea ez bazara, “Atsegin dut” botoian klik egin  https://www.facebook.com/OrekaIT orrialdean.
   2. Padel erraketaren irudian “Atsegin dut” botoian klik egitea.
   3. EUSKARAZ iruzkin bat idaztea padel palaren irudian, zer beste erabilera original eta desberdina emango zenioke padel pala bati kontatuz.
2. Lehiaketa honetan edozein nazionalitate eta herrialdeko pertsonak parte har dezake baldin eta komunikatzeko hizkuntza euskara bada.
3. Parte-hartzaile bakoitzak bakarrik iruzkin batekin parte-hartzeko aukera izango du.
4. Iruzkinik originalena egiten duen parte hartzaileak, irudian agertzen den padel pala irabaziko du. Lehiaketa honen antolatzaileak jasotako iruzkin guztien artean, iruzkin onena zein den erabakiko dute.
5. Parte hartzeko epea, 2014ko Otsailaren 24an goizeko 11etan hasiko da eta 2014ko Martxoaren 10ean goizeko 11etan bukatuko da.
6. Lehiaketaz gain, parte hartzaile guztien artean Oreka IT-ren bi produktu-sailak (katilu bat eta boligrafo bat) zozkatuko dira.
7. Lehiaketaren irabazlea, Oreka IT-ren Facebook-eko orrialdean argitaratuko da lehiaketaren amaieraren astean, baita zozketaren irabazleak ere.
8. Irabazleak Gasteizen bizitzen badira, Oreka IT-ren bulegoan jaso behar izango dute saria (Ikusi non gauden). Bestela, saridunekin harremanetan jarriko gara, saria emateko era bat erabakitzeko.
9. Lehiaketaren ardura guztia Oreka IT-k bere gain hartzen du, Facebook edozein motatako arduratik libratuz.
10. Facebook-ek ez du lehiaketa hau babesten ezta antolatzen ere.
11. Oreka IT-k parte hartzaileen kopuruaren arabera, lehiaketaren epea aldatzeko eskubidea gordetzen du. Halaber, lehiaketaren arautegia aldatu ahal izango du, edozein arrazoiengatik. Kasu hauetan, Oreka IT-ren Facebook orrialdean aldaketaren berri emango dugu eta irudian iruzkin bat idatziko dugu, parte hartzaile guztiei jakinarazteko.
12. Lehiaketa honetan parte hartzeak (aurretik aipatu diren 3 baldintzak betetzen) oinarriak onartzen direla esan nahi du.

Rellena este formulario para realizar tu reserva y te confirmaremos tu plaza, así como los datos importantes,  vía e-mail:

El próximo 3 de Abril, Oreka I.T. celebra una nueva jornada de ponencias presencial de caracter técnico, bajo el título “Administración e integración de sistemas SAP”, en la que se contará con la participación de varios ponentes así como la colaboración de las empresas Metaposta y Derten Sistemas.

Las jornadas se desarrollarán en la ciudad de Vitoria-Gasteiz, en una sala por determinar.

En esta ocasión se explicarán entre otras cosas, casos prácticos sobre integraciones SAP, sistemas de alta disponibilidad, virtualización de sistemas y se presentará el conector SAP con Metaposta.

Este es el programa del día:

1. Virtualización de sistemas SAP.
2. Sistemas SAP en alta disponibilidad.
3. Buenas prácticas para proyectos de Upgrade SAP. Casos prácticos.
4. Caso práctico: Conector SAP con Metaposta

Si estás interesado en acudir a esta jornada de ponencias de manera gratuíta, puedes reservar tu plaza rellenando el siguiente formulario. (Plazas limitadas hasta completar aforo):

¿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

En el artículo de hoy vamos a repasar cómo tratar las bajas de IT con recaídas en SAP PY. Veamos primero en qué consiste una baja con recaída. Cuando un trabajador, tras recibir la alta médica de una IT, posteriormente vuelve a causar baja por el mismo motivo, se dice que el trabajador se encuentra en baja por recaída. Para que una baja se considere recaída no deben transcurrir más de 180 días entre la fecha de alta médica y la nueva baja.

La baja con recaída deberá continuar con el cómputo de la duración de la baja original, igual que si la baja no hubiese sido interrumpida.

Por otro lado, para calcular la base reguladora diaria se utilizará la base de cotización del mes anterior a la recaída (Anteriormente se usaba la base de cotización anterior al primer mes de la baja).

Y hasta aquí lo que dice la ley, pero…

¿Cómo funciona en SAP PY?

Lo primero que se deberá hacer cuando nos encontremos ante una recaída será informar el infotipo 2001 correctamente. En el infotipo 2001 aparecerán dos registros, uno haciendo referencia a la baja original y otro a la recaída. Para relacionarlos, se usarán los campos “Vinculaciones” que aparecen en la parte inferior del infotipo.

En el primer registro se informará el primer campo (P2001-KENN1) con un valor numérico que identificará a la baja. En el segundo registro (la recaída) se deberá indicar el identificador de la baja en el campo de la derecha (P2001-KENN2). De esta forma SAP sabrá que los registros están relacionados, y tratará la segunda baja como una recaída.

Por otro lado, se debe parametrizar en el sistema el cálculo de la base reguladora diaria. Para ello se accederá a la vista V_T5EU3 y se elegirá el valor adecuado para la situación SBRRE (Si se quiere más información sobre la situación SBRRE, se puede consultar la nota 833764):

• Valor 0: La BRD en casos de recaída se toma del mes anterior al comienzo de la enfermedad original.
• Valor 1: La BRD en casos de recaída se toma del mes inmediato anterior al periodo de enfermedad o baja más reciente

Y ya sólo falta ejecutar la nómina y comprobar que el sistema calcula los importes correctos. Recordar que para comunicar el parte de baja a la Seguridad Social, se debe rellenar el infotipo 0768 – Mensaje FDI tal y como se explicó en un artículo anterior sobre SAP PY, donde deberemos marcar el campo de “Recaída”.