Todos conocemos las transacciones que ofrece SAP para introducir en el módulo de finanzas de una manera más sencilla que la FB01 asientos contables o facturas. Estas son las conocidas como transacciones Enjoy:

• Registro de documentos de cuentas de mayor (FB50).
• Registro de facturas (FB60) o abonos (FB65) de proveedores.
• Registro de facturas (FB70) o abonos (FB75) de clientes.

Con la entrada del SII (Suministro Inmediato de Información) se han tenido que crear muchas clases de documento nuevas para diferenciar distintas operaciones que antes no era necesario. Esto puede causar confusiones a la hora de registrar ciertas facturas. En el siguiente artículo voy a explicar un par de opciones de este tipo de transacciones que nos han servido de mucha utilidad para evitar errores registrales.

Opciones de Tratamiento

En todas las transacciones Enjoy antes mencionadas existe el botón para configurar la forma de utilizar esta transacción. Estas opciones son específicas para cada usuario, no para el sistema en sí. Al pulsarlo sale la siguiente pantalla:

Las opciones más importantes a mi parecer son:

• Calcular impuestos sobre imptes. netos: El cálculo de IVA lo hará sobre importes brutos si no está marcado. Si lo está lo hará sobre el neto.
• doc.: Opción: Permite visualizar o modificar la clase de documento que se va a crear. Esto es muy importante para el SII, ya que según la operación se debe crear una clase de documento y otra.

El resto de opciones sirven para modificar la manera de trabajar, y cada maestrillo tiene su librillo. Para más información a cerca de cada opción, seleccionar la opción y pulsando el botón F1 aparecerá una explicación del mismo.

Clases de documento por defecto

A la hora de utilizar una transacción Enjoy, aparece ya una clase de documento por defecto. Si no se tiene habilitado el poder modificar la clase de documento, a la hora de contabilizar podemos crear el documento con la clase errónea. Para parametrizar las clases de documento por defecto se debe acceder a la siguiente ruta de la IMG de SAP:

Gestión financiera (nuevo) à Contabilidad principal (nuevo) à Operaciones Contables à Contabilización en cuentas de mayor Enjoy à Definir clases documento p.transacción Enjoy

En este punto de la parametrización es posible definir para cada sociedad, por clase de cuenta y por operación, qué clase de documento debe aparecer por defecto en las transacciones Enjoy.

Variantes de transacción

Otra opción para modificar los campos por defecto, e incluso modificar el orden por defecto de las columnas para introducir las posiciones de los documentos son las variantes de entrada. Estando en una transacción Enjoy se accede por el menú a Tratar > Variante de entrada > Crear variante de entrada. Aparece una pantalla como la siguiente:

Indicamos la transacción para la que queremos crear una variante y le damos un nombre a la variante. Pulsamos el botón  para crearla. Al hacer esto se abrirá la transacción, y entonces se rellenan los campos que se quieran guardar para usar por defecto. También se pueden modificar las columnas de las posiciones. Por ejemplo, yo he metido una clase de documento y un texto por defecto, y he cambiado la tabla de posiciones para que el centro de coste y el texto estén a la derecha del indicador de impuestos:

Cuando ya se ha modificado lo que se desee, al pulsar Intro aparecerá una pantalla por cada dynpro que tiene el programa. Aquí es donde debemos elegir si queremos que se guarden los campos por defecto. En el ejemplo anterior, si quiero que se me guarde en la variante la clase de documento y el texto, en su dynpro marco la casilla “Con contenido”.

Para la posición de las columnas, en la dynpro correspondiente marco la casilla “Tomar secuencia columnas”:

Finalmente, pulsamos el botón de Finalizar y grabar cuando ya hayamos guardado todos los campos que queríamos. Aparecerá un resumen con todas las dynpros. Guardamos y ya tendremos creada la variante.

Para utilizarla, cuando entramos en la transacción, se puede seleccionar en el menú

Tratar > variante de entrada > Seleccionar variante de entrada.

Otra opción más técnica sería crear transacciones con esta variante de entrada por defecto. Accedemos a la transacción SE93 y le damos a crear una nueva transacción de tipo “Transacción con variantes”. Se debe indicar la transacción y la variante que acabamos de crear:

Al ejecutar esta transacción nueva, la variante hará que por defecto se rellenen los campos que hemos guardado y la posición de las columnas será la que hemos definido en la variante.

Así es como podemos personalizar transacciones Enjoy en el módulo FI de SAP. ¿Os ha sido de ayuda esta pequeña guía?

Los ficheros realizados con lenguaje XML son muy comunes a la hora de intercambiar información entre diferentes sistemas. Es un lenguaje estándar fácil de entender, pero dependiendo de la complejidad del fichero la transformación puede volverse complicada. En este artículo explicaremos cómo transformar la información de un XML de varios niveles a ABAP para poder tratar esos datos.

Para poder explicar el funcionamiento de la transformación utilizaremos un ejemplo. El fichero XML utilizado en el artículo tiene el siguiente formato:

<DatosReceptoresEf4ktur>
    <DatosReceptor>
        <RazonSocial></RazonSocial>
        <Direccion></Direccion>
        <CodigoPostal></CodigoPostal>
        <Poblacion></Poblacion>
        <Provincia></Provincia>
        <Correo></Correo>
        <ContactoAdicional></ContactoAdicional>
        <CorreoEnvio></CorreoEnvio>
        <DescripcionDepartamento></DescripcionDepartamento>
        <Departamento></Departamento>
        <CIF></CIF>
        <DatosContratante>
            <CentroAdministrativo>
                <CentreCode></CentreCode>
                <CentreDescription></CentreDescription>
                <RoleTypeCode></RoleTypeCode>
                <CodigoEntidadRelacionada></CodigoEntidadRelacionada>
                <Name></Name>
                <FirstSurname></FirstSurname>
                <SecondSurname></SecondSurname>
<Address></Address>
                <PostCode></PostCode>
                <Town></Town>
                <Province></Province>
                <Pais></Pais>
                <ElectronicMail></ElectronicMail>
                <Telephone></Telephone>
            </CentroAdministrativo>
        </DatosContratante>
    </DatosReceptor>
</DatosReceptoresEf4ktur>

En el fichero habrá varios datos de receptores, y dentro de los datos contratantes podrá haber varios centros administrativos. También puede darse el caso de que un receptor no tenga ningún centro administrativo. Para poder importar los datos lo dividiremos en dos partes:

• la creación de objetos del diccionario ABAP
• la creación de la transformación

Creación de los objetos del diccionario ABAP

Nuestro objetivo en la SE11 es crear un tipo de tabla que tenga una estructura la cual pueda contener todos los campos que tiene el XML.

Si nos fijamos en la imagen el último campo de la estructura es otro tipo de tabla. Este tipo de tabla tendrá que tener una estructura para poder guardar todo lo que hay dentro de las etiquetas “DatosContratante”, es decir, todos los centros administrativos.

También, habría que crear, los dominios y elementos de datos necesarios para cada campo, en caso de no poder reutilizar otros ya creados.

Creación de la transformación

Una vez creados todos los objetos necesarios para albergar los datos del XML tendremos que realizar la transformación. Las transformaciones se crean en la transacción STRANS. Al darle al botón crear nos pedirá una descripción y la clase de transformación. La clase que elegiremos será “Transformación Simple”.

Para crear la lógica de la transformación utilizaremos el modo gráfico pinchando en la varita redondeada en la imagen.

Por defecto, nos aparece el elemento “ROOT” que borraremos (click derecho -> delete) para meter la estructura creada por nosotros en la SE11 (click derecho -> Insert new root).

De esta manera, se cargará la estructura y podremos arrastrarla a la otra columna para que nos cree la transformación para la plantilla que hemos cargado.

Prácticamente ya tenemos creada nuestra transformación. Sólo nos falta cambiar algunos elementos para finalizar.

Lo primero será ponerles el mismo nombre a las etiquetas que en el XML. Por ejemplo en el caso de “DatosReceptor” que la etiqueta sale con el nombre “Z……”.

También, el caso de “CorreoEnvio”, que en nuestra transformación la etiqueta tiene el nombre SENTMAIL porque es nombre del campo en la estructura creada en la SE11. Si nos fijamos en el código, veremos que dentro de cada etiqueta tenemos asignado el campo en el que se guardará ese valor.

Otro aspecto a tener en cuenta es que las etiquetas son “case sensitive”, así que hay que escribirlos exactamente igual al XML, controlando que coincidan las mayúsculas/minúsculas.

Antes de los cambios:

<?sap.transform simple?>
<tt:transform xmlns:tt="http://www.sap.com/transformation-templates" xmlns:ddic="http://www.sap.com/abapxml/types/dictionary" xmlns:def="http://www.sap.com/abapxml/types/defined">
  <tt:root name="DATOSRECEPTORESEF4KTUR" type="ddic:ZXMLRECEPTOR_TT"/>
  <tt:template>
    <DATOSRECEPTORESEF4KTUR>
      <tt:loop ref=".DATOSRECEPTORESEF4KTUR">
        <ZXMLRECEPTOR_ST>
          <DESCRIPTION tt:value-ref="DESCRIPTION"/>
<ADDRESS tt:value-ref="ADDRESS"/>
          <POSTCODE tt:value-ref="POSTCODE"/>
          <TOWN tt:value-ref="TOWN"/>
          <PROVINCE tt:value-ref="PROVINCE"/>
          <MAIL tt:value-ref="MAIL"/>
          <MAIL2 tt:value-ref="MAIL2"/>
          <SENTMAIL tt:value-ref="SENTMAIL"/>
          <DEPARTMENTDESCRI tt:value-ref="DEPARTMENTDESCRI"/>
          <DEPARTMENT tt:value-ref="DEPARTMENT"/>
          <CIF tt:value-ref="CIF"/>
          <DATOSCONTRATANTE>
            <tt:loop ref="DATOSCONTRATANTE">
              <ZCENTROADMIN_ST>
                <CENTRECODE tt:value-ref="CENTRECODE"/>
                <DESCRIPTION tt:value-ref="DESCRIPTION"/>
                <ROLETYPE tt:value-ref="ROLETYPE"/>
                <RELATEDENTITY tt:value-ref="RELATEDENTITY"/>
                <NAME tt:value-ref="NAME"/>
                <FIRSTSURNAME tt:value-ref="FIRSTSURNAME"/>
                <SECONDSURNAME tt:value-ref="SECONDSURNAME"/>
<ADDRESS tt:value-ref="ADDRESS"/>
                <POSTCODE tt:value-ref="POSTCODE"/>
                <TOWN tt:value-ref="TOWN"/>
                <PROVINCE tt:value-ref="PROVINCE"/>
                <COUNTRY tt:value-ref="COUNTRY"/>
                <MAIL tt:value-ref="MAIL"/>
                <PHONE tt:value-ref="PHONE"/>
              </ZCENTROADMIN_ST>
            </tt:loop>
          </DATOSCONTRATANTE>
        </ZXMLRECEPTOR_ST>
      </tt:loop>
    </DATOSRECEPTORESEF4KTUR>
  </tt:template>

Por último, como hemos dicho al principio del artículo, puede que algún receptor no tenga centros administrativos. Por lo tanto, no tendrá la estructura a partir de “DatosContratante”. Para que durante la deserialización de la transformación no nos salte el error de que no encuentra esas etiquetas deberemos añadir la siguiente etiqueta al código de la transformación: <tt:d-cond>. Después de los cambios de nombre anteriores y la condición:

 <?sap.transform simple?> <tt:transform xmlns:tt="http://www.sap.com/transformation-templates" xmlns:ddic="http://www.sap.com/abapxml/types/dictionary" xmlns:def="http://www.sap.com/abapxml/types/defined"> <tt:root name="DATOSRECEPTORESEF4KTUR" type="ddic:ZXMLRECEPTOR_TT"/> <tt:template> <DATOSRECEPTORESEF4KTUR> <tt:loop ref=".DATOSRECEPTORESEF4KTUR"> <DatosReceptor> <RazonSocial tt:value-ref="DESCRIPTION"/> <Direccion tt:value-ref="ADDRESS"/> <CodigoPostal tt:value-ref="POSTCODE"/> <Poblacion tt:value-ref="TOWN"/> <Provincia tt:value-ref="PROVINCE"/> <Correo tt:value-ref="MAIL"/> <ContactoAdicional tt:value-ref="MAIL2"/> <CorreoEnvio tt:value-ref="SENTMAIL"/> <DescripcionDepartamento tt:value-ref="DEPARTMENTDESCRI"/> <Departamento tt:value-ref="DEPARTMENT"/> <CIF tt:value-ref="CIF"/> <tt:d-cond> <DATOSCONTRATANTE> <tt:loop ref="DATOSCONTRATANTE"> <CentroAdministrativo> <CentreCode tt:value-ref="CENTRECODE"/> <CentreDescription tt:value-ref="DESCRIPTION"/> <RoleTypeCode tt:value-ref="ROLETYPE"/> <CodigoEntidadRelacionada tt:value-ref="RELATEDENTITY"/> <Name tt:value-ref="NAME"/> <FirstSurname tt:value-ref="FIRSTSURNAME"/> <SecondSurname tt:value-ref="SECONDSURNAME"/> <Address tt:value-ref="ADDRESS"/> <PostCode tt:value-ref="POSTCODE"/> <Town tt:value-ref="TOWN"/> <Province tt:value-ref="PROVINCE"/> <Pais tt:value-ref="COUNTRY"/> <ElectronicMail tt:value-ref="MAIL"/> <Telephone tt:value-ref="PHONE"/> </CentroAdministrativo> </tt:loop> </DATOSCONTRATANTE> </tt:d-cond> </DatosReceptor> </tt:loop> </DATOSRECEPTORESEF4KTUR> </tt:template> 

De esta manera, si lo que hay dentro de las etiquetas <tt:d-cond> no existe, la transformación lo obviará. No nos saltará ningún error y seguirá con el siguiente receptor. La transformación estaría finalizada, y tan sólo faltaría activarla para poder usarla.

Con lo explicado anteriormente ya tendríamos hecha la transformación del XML para poder pasar la información a ABAP. La forma de poder utilizarla en un report es mediante la sentencia CALL TRANSFORMATION.

Tal y como comentábamos en el artículo “SAP BI Lumira 2.0”, SAP liberaba en Agosto de 2017 Lumira 2.0, la cual es la evolución de las dos herramientas de BO para la elaboración de Cuadros de Mando. Se trata de un producto con dos interfaces diferentes: el antiguo Lumira pasa a llamarse a Lumira Discovery y Design Studio se renombra como Lumira Designer. En este artículo vamos a profundizar en los Composites, una de las novedades más sonadas de la herramienta centrada en el diseño profesional de aplicaciones de análisis: Lumira Designer.

Los diseñadores pueden crear sus propios componentes, reutilizables en todas las aplicaciones, llamados Composites. Estos elementos pueden ser composiciones de uno o varios componentes estándar de Lumira Designer. Utilizando la misma interfaz y lenguaje (BIAL) que usamos cuando estamos creando una nueva aplicación/cuadro de mando, podemos definir con qué componentes estándar (gráficos, tablas, etc) se va a componer. Es posible crear los eventos y métodos que va a emplear, y programar las rutinas necesarias para el correcto funcionamiento de la lógica del componente.

Estos Composites son reutilizables en todas las aplicaciones y son almacenados en la plataforma BI. Pueden usarse para definir componentes globales, como cabeceras, pies de página, pantallas de selección, etc… De tal manera que, si por ejemplo, queremos variar la cabecera de todas las aplicaciones (definidas mediante un Composite), en vez de ir retocando cada uno de los cuadros de mando, podríamos simplemente cambiar el Composite y estas modificaciones se harían vigentes en todas las aplicaciones que lo utilicen.

Varios ejemplos de Composites

Otro ejemplo de Composite podría ser la definición de un KPI Tile (recuadro o caja en la que se indica el resumen de cierto indicador). Mediante el uso de un gráfico, se puede mostrar el resumen de datos recogidos de un Datasource cualquiera, diferente según el escenario donde se quiera usar. De tal manera, en las aplicaciones donde se quiera reutilizar, bastaría con incluir este Composite y definir qué Datasource se quiere utilizar, de un funcionamiento exactamente igual que cuando se incluye un Chart o un Crosstab a la aplicación.

Los Composites son una herramienta muy potente que abre nuevas puertas en cuanto a la forma de elaboración de Dashboards, ya que pueden usarse para descomponer complejas aplicaciones en más pequeñas, con lo cual conseguimos que sean una combinación de partes más manejables.

Este ha sido el primer artículo que trata las innovaciones de Lumira Designer. En próximas reseñas comentaremos más novedades.

Como tratábamos en el artículo “SAP BI Lumira 2.0”, ya disponemos de la nueva evolución de SAP referente a la elaboración de Cuadros de Mando. Ha creado un nuevo producto llamado Lumira 2.0. con dos interfaces diferentes: Lumira Discovery y Lumira Designer, los cuales son las nuevas versiones de Lumira y Design Studio, respectivamente. En la reseña “SAP BI Lumira 2.0 – Novedades Lumira Designer (I)” presentábamos los Composites, una de las novedades que nos trae Lumira Discovery. En esta segunda parte vamos a exponer más innovaciones que se han realizado para esta herramienta.

Experiencia móvil mejorada

Se ha introducido un nuevo componente de tipo contenedor, llamado “Adaptative Layout”. Es un elemento similar al “Grid Layout”, para el que se puede fijar cuatro diferentes disposiciones: para tamaños de pantalla pequeños, medios, grandes y muy grandes. Según en qué tipo de pantalla estemos mostrando la aplicación, la localización de los elementos irá variando, adaptándose al tamaño de la misma.

También, se puede recoger por script el dispositivo donde se esté mostrando la aplicación, por lo que se permiten establecer condiciones en el propio código del cuadro de mando, modificando su comportamiento. Por ejemplo, programando ciertas acciones si la aplicación se está mostrando en un iPad.

La experiencia móvil es uno de los puntos por lo que está apostando SAP en la evolución de la herramienta. Muestra de ello es que, en la versión 2.1 de Lumira Designer, ha incluido un “Scroll container”, lo que permite que se pueda personalizar aún más la disposición de los elementos del Cuadro de Mando.

Mejoras en la exportación a PDF e impresión

Una de las mayores carencias de Design Studio a la hora de imprimir era que, para las tablas, no podía llevarse a cabo a lo largo de diferentes páginas. Esto se ha solucionado en Lumira Designer, ofreciendo varios tipos de impresión (tipo WYSIWYG, “lo que ves es lo que obtienes”, o pudiendo imprimir gráficos y tablas a lo largo de varias páginas).

También, se ha mejorado la calidad de exportación en cuanto a gráficos, soporte de impresión de GeoMaps, e inclusión de opciones de configuración de cabecera, pie de página… En este sentido, se han incluido muchas opciones de personalización de la impresión. Por ejemplo, pudiendo cambiar en tiempo de ejecución, entre otras tantas opciones, la orientación de la página, el nombre del PDF, etc…

Con esto damos por finalizada la presentación de dos de las novedades más importantes que se han incluido en Lumira Designer, referentes a la movilidad e impresión.

En una implantación de un nuevo sistema SAP, la carga de los maestros es una de las labores más importantes y costosas previas al arranque productivo. En la parte financiera, el inmovilizado suele suponer la carga con más registros y hay que realizarla con cuidado para que no afecte al balance inicial. Recientemente, hemos tenido un arranque de una máquina SAP S4/HANA 1610, y quería comentar como hemos lidiado en esta nueva versión de SAP a la hora de cargar el inmovilizado.

Como muchos sabréis, en SAP R3 la carga inicial de inmovilizado se podía realizar mediante la transacción AS91. En esta pantalla se rellenaban los datos del inmovilizado a cargar y también se indicaba sus valores de capitalización, amortización acumulada, valor residual… En un nuevo sistema SAP S4/HANA, la transacción AS91 sigue habilitada para crear el registro del activo, pero la opción para meter su valoración está desactivada.

En vez de utilizar esta opción, SAP HANA ofrece la transacción ABLDT. Esta nueva transacción permite introducir el valor del activo para cada área de valoración que previamente se haya parametrizado.

Como se ve en la imagen superior, en esta pantalla aparece un ALV para informar por cada área de valoración los importes del inmovilizado a migrar. El problema de esta transacción es que al tratarse de un ALV no es posible realizar una LSMW o un Batch Input, por lo tanto, solo es posible utilizarla de manera manual. Esto es inviable para una carga inicial, donde el número de inmovilizados suele ser bastante elevada.

En nuestro caso, para casos particulares de inmovilizados que requerían un cuidado especial se utilizó esta opción manual. Pero para la carga masiva de la gran parte de los activos, se optó por usar una BAPI estándar, la BAPI_FIXEDASSET_OVRTAKE_CREATE. Esta función simula la creación del activo por la AS91 y la valoración de la ABLDT. Así que nuestra opción fue realizar un programa Z que recogía los datos de todos los inmovilizados a cargar de una hoja Excel, y rellenar los campos de la BAPI y ejecutarla una vez por cada maestro a cargar. Para esto, se necesita la ayuda de un programador ABAP para que ayude con el programa y la utilización de la BAPI.

En el próximo artículo explicaremos cómo a partir de la versión 2.4 de Análisis for Office existe la posibilidad de customizar la interfaz de usuario en Excel, esta nueva funcionalidad de SAP permite adaptar los menús y funciones de la pestaña “Analysis” para adaptarse a las necesidades de cada tipo de perfil de los usuarios y consultores.

Para realizarlo habrá que crear nuevos perfiles desde la ventana “Customize User Interface”: 

Para definir un nuevo perfil basta con introducir un nombre en el campo “profile” y una vez guardado ya podremos utilizar este perfil o definirlo como si fuera estándar:

Una vez creado un nuevo perfil se pueden customizar los grupos y comandos de la pestaña Analysis:

• Marcar/Desmarcar grupos existentes: Las funcionalidades estándar de Analysis no se pueden borrar, pero se puede deshabilitar su acceso para los usuarios.
• Crear nuevos grupos:

• Crear nuevas funcionalidades: En los grupos estándares o personalizados, se podrán introducir nuevos elementos. Estos podrán ser Button, Separator, Split Button o Toggle Button. Para todos estos elementos, menos Separator, hace falta definir un Label, Macro, Size e Image.

• Macros:  Para implementar la funcionalidad de los nuevos elementos habrá que usar macros; guardadas en el libro de trabajo o externas como un Add-in de Excel.

Para recrear funcionalidades, contiene métodos APIs que pueden ser usados en las macros VBA, para llamar a estos métodos hay que usar “Application.Run” y los parámetros específicos de cada método, siendo el primero de ellos el nombre del método API.

Los perfiles creados se almacenan por defecto en: C:\Users\[usuario]\AppData\Roaming\SAP\Cof\User Interface. Ahí habrá un xml y una carpeta con las imágenes usadas para los iconos.

Por último, cabe mencionar que, si se desease distribuir estos perfiles en la compañía, hará falta copiar el archivo xml y la carpeta de imágenes a C:\ProgramData\SAP\COF\User Interface. De este modo será un perfil de la compañía y no podrá ser ni borrado ni modificado por un usuario final.

Vamos a publicar una serie de artículos explicando cómo se compone la cuenta de resultados en SAP.

Este es el primero de todos, contiene la definición de las partes organizativas como; ¿qué es una sociedad Fi?, ¿qué es una sociedad CO? y ¿qué es una sociedad PA? Además de la explicación y creación de las partes principales de la cuenta de resultados, las características y los campos de valor.

Para poder definir la cuenta de resultados, debemos tener preparados y estructurados los siguientes datos maestros en SAP:

• La sociedad financiera
• La sociedad de Costes
• La sociedad PA

La sociedad financiera, es la organización a efectos legales la cual tiene un impacto directo en el módulo financiero que se corresponde con la entrada/salida de mercancías, facturación de proveedores, facturación a clientes, etc.

La sociedad de CO, esta contiene todas las imputaciones de ingresos y gastos.

La sociedad PA, es la que representa en Controlling la estructura superior, la cual nos permite el análisis de las rentabilidades y márgenes.

La cuenta de resultados de CO-PA (Controlling Profitability Analysis) se basa en dos conceptos principales, estos son:

• Campos de valor.
• Características.

Los campos de valor representan cada una de las líneas de la cuenta de resultados. Los campos de valor pueden estar definidos en importe o en cantidad.

Las características, por su parte, representan los ejes de análisis de la cuenta de resultados. Estas nos permitirán por tanto filtrar y analizar la cuenta de resultados según la variable con la que se filtren los informes (línea de producto, país, cliente, etc.).

Iremos a la transacción ORKE, en ella encontraremos todos los puntos de parametrización que necesitamos para poder definir la cuenta de resultados.

Para definir las características accederemos a la siguiente estructura IMG:

IMG: Cuenta de resultados/Estructura/Definir sociedad PA/Actualizar características

Hacemos clic en el reloj y nos aparecerá la siguiente pantalla, en la que trabajaremos sobre el segundo bloque para crear las correspondientes características de nuestra cuenta de resultados. Para este ejemplo vamos a crear la característica “CLIENTE” y pulsaremos sobre este icono:

Una vez que le hemos asignado un nombre a la característica, que además debe empezar por WW, pulsaremos crear. En este momento debemos tomar alguna tabla modelo para este caso utilizaremos la tabla KNA1 que corresponde al Maestro de clientes y pulsamos validar.

Validamos la siguiente pantalla también:

Seleccionaremos la característica asociada al NIF del cliente, una vez hecho esto, pulsaremos. Nos aparecerá la siguiente pantalla en la que tenemos que asignarle el tipo con el que vamos a identificar este campo en la cuenta de resultados, elegiremos la opción 3, Texto y clave, y grabamos.

Ya tendríamos la característica WW001 creada, ahora debemos crear el campo de valor que más adelante le asignaremos.

Para definir los campos de valor debemos ir a través de este menú:

IMG: Cuenta de resultados/Estructura/Definir sociedad PA/Actualizar campos de valor

Los más normal es definir los campos de valor de tipo suma, luego con el signo de valor que se introduzca en el asiento contable, automáticamente el campo hará la operación con signo positivo o negativo.

Este proceso será parecido al anterior, pero los campos deberán comenzar por “VV”, para el ejemplo crearemos un capo de valor tal que “VV001”:

En siguientes artículos relacionaremos los campos de valor con las características y esta misma relación a la sociedad PA para la que corresponda hacer el análisis de rentabilidad.

Una vez implantada la solución básica para la gestión del Suministro Inmediato de Información, se han detectado varios aspectos sobre los que hacer evolucionar la solución, de manera que suponga un claro valor añadido para el cliente.

En este artículo damos una relación de los puntos de mejora que serán atendidos por futuros evolutivos de la solución básica SII desarrollada por Oreka IT. Cualquier persona que desee ampliar la información de este artículo, tiene la posibilidad de ponerse en contacto a través de la sección de contacto de la Web, o bien puede escribir directamente a nuestro departamento de SAP Finanzas & Controlling en este correo: e.huertos@orekait.com

1.    Integración FI-eDoc

Una mejora en la calidad de vida para el usuario sería disponer de información clara de las facturas que hayan sido enviadas al SII y las que quedan pendientes. Actualmente esta información sólo es visible en el monitor.

2.    Informe FI-eDoc

En la misma dirección que el punto anterior, un evolutivo que se desarrollará será disponer de la información de facturas enviadas y no enviadas de un solo vistazo, a través de un informe específico.

3.    Consulta de rechazos

Otra mejora de calidad de vida que se implantará será disponer a nivel de eDocument los motivos del rechazo de un documento. Actualmente, para acceder a esta información, es necesario seleccionar el documento y pulsar el botón del log. 

4.    Interlocutores sin NIF

Actualmente, cuando un proveedor o cliente no dispone de número de identificación, sus facturas se envían al SII con el número del maestro en SAP y una clave de identificador 04, para que el SII acepte la factura sin problemas.

Como mejora, se realizará una tabla Z para guardar los interlocutores sin NIF. Esta tabla será fácilmente accesible para poder solucionar de forma ágil los problemas derivados de la falta de NIF en el sistema.  

5.    Validación de NIFs

En el nuevo SII, los NIFs de las empresas están dados de alta con una razón social. En algunas ocasiones esta razón social no coincide exactamente con el dato maestro que se tiene en el maestro SAP. Esto supone que el eDocument de la factura se devuelva en estado rechazado al realizar el envío a la hacienda que corresponda y puede suponer un retraso en el plazo de información de la factura.

La mejora a desarrollar será ejecutar un proceso antes del envío al SII que tomará la información, nombre y NIF de los documentos contabilizados durante el día y conectará con el Web Service de la hacienda correspondiente para validar los datos. Para todos los no identificados se pondría un 07 en el campo NIF 2 y de esta manera la factura sería aceptada.  

6.    Cuadre de informe de IVA

El informe de declaración de IVA (S_ALR_87009895) reporta toda la información del IVA por documento contable y ofrece información de cada uno de estos en detalle. Si bien este informe muestra todo lo contabilizado en el sistema, por estándar no muestra si esas facturas han sido enviadas al SII o no.

Una vez implementada la integración FI-eDoc es posible saber si el informe de IVA que nos reporta SAP de lo contabilizado en el sistema cuadra con la información enviada al SII. 

7.    Navegabilidad FI-Monitor

En la solución estándar, desde el monitor es posible navegar a los documentos contables, pero no existe manera de hacer el camino inverso.

Como mejora, se habilitará una opción para que desde un documento contable se pueda navegar al monitor para consultar los eDocuments relacionados con dicho documento.

8.    Avisos por email

Actualmente no existe ninguna alerta o notificación automática para avisar del estado de las facturas enviadas al SII.

La mejora que desarrollará Oreka IT se basa en crear un workflow, de manera que una vez finalizado el envío de listas al SII en los procesos nocturnos se genere un email para el responsable con un listado de las facturas que se han enviado al SII. Desde este informe se podrían enviar todas o sólo las erróneas, y se mostrará la causa de esos errores.

El pasado viernes 20 de abril de 2018 celebramos un Webinar informativo sobre los cambios en el sistema SII y nuestra solución en el entorno SAP.

Creemos que puede ser de interés general, por lo que dejamos el vídeo completo del webinar para que podáis consultarlo cuando sea necesario. También dejamos en este enlace la presentación completa en formato PDF.

Si tienes cualquier duda o consulta, te animamos a que dejes un comentario y te daremos respuesta lo antes posible.

Si en el artículo “Retenciones judiciales. Infotipo 0887 (I)” se presentó las opciones de subtipos y grupos de deducciones que ofrece el infotipo estándar de retenciones judiciales 0887 (solución de SAP para embargar parte del salario de un empleado), en éste se explicarán los campos más relevantes del infotipo.

Dependiendo del subtipo y del grupo de deducción que se hayan seleccionado, los campos de infotipo varían. Aun así, la pantalla siempre se nos divide en dos bloques: retención y receptor.

Retención

Estos son los campos de este bloque:

• Identificador: Los identificadores se generan automáticamente y todos los registros con el mismo identificador se consideran la misma retención (no pueden superponerse en el tiempo ni no existir en un intervalo de tiempo). En el siguiente ejemplo, al modificarse el valor mensual que hay que embargar se hace un corte en el registro pero se mantiene el identificador.

El intervalo de valores posibles para el identificador y el próximo valor que tendrá se pueden consultar en la vista V_T5E_NRIV_P0887.

• Prioridad: Normalmente cuando hay que aplicar más de una retención judicial en un mismo periodo de nómina, se aplica primero la que se haya creado primero. Al crear una nueva retención judicial el sistema propone un valor en el campo prioridad, que se calcula sumando 100 a la retención con prioridad más baja, de esta forma siempre se retiene en orden temporal. Tened en cuenta que las prioridades con menor valor prevalecen. Aun así, puede que se decida que una retención posterior se deba aplicar primero. Para ello, al crear el registro se modifica el campo “prioridad” de forma que se apliquen cada uno de los embargos en el orden adecuado.

En el siguiente caso se embargará primero la retención con identificador 205 y después la retención con identificador 194, y no en orden cronológico.

• Porcentaje añadido: se indica un porcentaje de descuento que se aplica al importe sujeto a retención. Puede que un juez decida que además del SMI, un porcentaje del sueldo del empleado sea inembargable, por ejemplo, por la situación familiar del empleado. Este porcentaje inembargable adicional se indica en este campo.
• Valor mensual o deducción: Es el importe o porcentaje del salario que se debe embargar. A partir de este valor se calcula el importe a retener, ya que se debe tener en cuenta, dependiendo del tipo y grupo de retención, la parte inembargable. Esto es, no siempre se podrá retener el importe completo indicado en el infotipo.
• CC-nómina de base: concepto de nómina que se usará como base en las retenciones por porcentaje, subtipo 1.
• Descuento: porcentaje que se descuenta en el embargo en cada uno de los tramos de la ley de enjuiciamiento
• Deuda total: Importe total de la deuda.

Si se incluyen las retenciones de este infotipo en el cálculo de la nómina, el infotipo accede al clúster de nómina para mostrar información extra. Estos son los datos:

• Total deducido: Importe total deducido desde el comienzo de la retención.
• Periodo en nómina: último periodo de nómina en el que se aplicó la retención, si el registro está activo se toma el último periodo EN del cluster de nómina, si no lo está, tomar el periodo EN para la fecha final del infotipo.
• No retenido: Importe que no se pudo retener en el último cálculo de nómina. Por ejemplo, si se tiene que retener 1000€, sin límite por SMI, pero en ese periodo el salario embargable del empleado es de 950€, quedarán 50€ no retenidos.
• No trasferido: importe deducido pero que no haya sido transferido. En el cálculo de la retención se comprueba que los datos bancarios son correctos, siempre que sean necesarios. En caso de datos incorrectos, no se creará el pago en la BT y el importe se almacena en este campo para ser pagado en el siguiente periodo.

Receptor

En esta parte del infotipo se informan los datos necesarios para realizar el pago de la retención judicial. Si se informa el campo “clave de receptor” completará los demás campos relacionados con el receptor y la cuenta bancaria.

Las claves de receptor se definen en la vista V_T521B

Se le da admisibilidad según el subtipo de retención judicial en la vista V_T521C.

Con la información de estos dos artículos podrás gestionar las retenciones judiciales de los empleados.

Una de las últimas certificaciones oficiales que ha obtenido Oreka IT a nivel de empresa es “SAP S/4 HANA Asset Management”. A lo largo de este artículo vamos a explicar el objeto de esta certificación y qué valor añadido aporta a clientes y colaboradores.

Contexto: SAP S/4 HANA

A día de hoy las empresas operan en un mercado dinámico y altamente competitivo, por lo que alcanzar mayores niveles de excelencia operativa es un requisito para la viabilidad de estas.

Esto se traduce en que las empresas necesitan de plataformas que les provean de información precisa y en tiempo real. Además, les interesa disponer de sistemas con capacidades de análisis predictivo para detectar problemas en la gestión antes de que estos se produzcan. Por último, para asegurar la competitividad de la organización, se ha de empoderar a la fuerza de trabajo con herramientas que proporcionen la información y funcionalidad para gestionar los procesos de negocio de la organización sin problemas y de forma intuitiva.

En definitiva, a las empresas de nuestro tiempo les interesa ser rápidas, inteligentes e integradas. SAP S/4 HANA, el ERP de última generación de SAP, es la respuesta de SAP a estos retos.

Objeto de SAP S/4 HANA Asset Management

Asset Management es una solución vinculada al ERP SAP S/4HANA para que las organizaciones puedan gestionar los aspectos relacionados con activos de una manera holística, bien sean costes, riesgos, rendimiento, etc. Proporciona las funciones e información necesaria para encontrar la mejor manera de gestionar gastos de explotación (OPEX) e inversiones en bienes de capital (CAPEX), así como tener visibilidad total sobre los costes del ciclo de vida de los activos.

Resumen de capacidades de SAP S/4 HANA Asset Management

Operativa y mantenimiento de los activos

• Estrategia y rendimiento de activos
• Planificación y organización de actividades de mantenimiento
• Ejecución del mantenimiento
• Gestión de activos móviles

Medio Ambiente, salud y seguridad

• Gestión de incidencias
• Gestión de salud y seguridad
• Gestión planificada del medio ambiente: residuos, impacto ambiental, etc.
• Gestión del cambio
• Mantenimiento de actividades de seguridad y permiso para trabajar

Red de activos

• Función colaborativa para obtener información de activos
• Gobierno de la información relacionada con activos
• Mantenimiento predictivo y servicio

Valor de SAP S/4 HANA Asset Management

SAP S/4HANA Asset Management permite a las empresas gestionar de forma eficiente el ciclo de vida de los activos, gracias a sus capacidades funcionales y analíticas en tiempo real.

• Provee visión en tiempo real del rendimiento de los activos para apoyo en la toma de decisiones.
• Permite el uso de herramientas predictivas, de simulación y análisis para evaluar el comportamiento de los activos, presupuestos de planificación y previsión de costes de mantenimiento.
• Provee un punto de vista unificado de los datos de operación para poder gestionar los activos de forma unificada, de acuerdo con la ISO 550001.
• Soporta y promueve la gestión de riesgos relacionada con activos para minimizar disrupciones.
• Permite disponer de una visión unificada de los procesos de riesgo relativos a trabajadores, activos o medio ambiente.
• Facilita el uso de analítica, predicción y simulación para ganar mayor control. Por ejemplo, la posibilidad de convertir reportes de incidencias en actuaciones concretas de tipo preventivo.
• Integración completa con SAP S/4HANA en las áreas de finanzas, recursos humanos, producción, gestión de materiales, etc.

Si quieres saber más sobre los problemas que puede solucionar Asset Management y las situaciones para las que es adecuado, visita la segunda parte de este artículo: “SAP S/4 HANA ASSET MANAGEMENT – Problemas que soluciona 2/2”

En este artículo damos una relación de los principales puntos calientes que la solución SAP S/4 HANA Asset Management ayuda a solucionar, así como el resumen de la funcionalidad añadida que provee para tal efecto. Recordemos que SAP S/4 HANA Asset Management es una de las últimas certificaciones que ha obtenido Oreka IT.

Por tanto, este artículo puede servir de referencia para empresas que tengan uno o varios de los puntos calientes que detallamos a continuación.

1. Dificultad en obtener un punto de vista común sobre procesos de riesgo para trabajadores, activos o medio ambiente que puedan suponer un elevado coste para el cumplimiento de las normativas medioambientales o de salud y seguridad.

Integración nativa de gestión de incidencias, así como de la gestión de salud y seguridad, proporcionando una visión común. Esto reduce la complejidad en la gestión de riesgos y aumenta el rendimiento.

2. Habilidad limitada para analizar datos de EH&S (Medioambiente, Salud y Seguridad), para reducir riesgos en el puesto de trabajo. Por tanto, limitación para desarrollar medidas preventivas al respecto.

Herramientas analíticas integradas que se procesan datos en tiempo real para ayudar al equipo de prevención de empresa a actuar en el momento en que se producen las incidencias, así como a desarrollar planes preventivos en base a las analíticas históricas y las simulaciones.

3. La limitación para reportar y gestionar incidencias de forma efectiva conduce a un elevado número de partes de incidencia, accidente o enfermedad.

Acceso basado en roles a la aplicación para visibilizar y gestionar tareas y partes de trabajo según el contexto o área, lo que permite ganar visibilidad sobre estas.

4. Limitación para compartir y aprender de las mejores prácticas para labores de instalación y uso de equipamiento entre los diferentes operadores. Esto dificulta la mejora en el rendimiento de los bienes de equipo.

SAP S/4 HANA está integrado con SAP Asset Intelligence Network (Red de SAP de Inteligencia de Activos). Esto facilita el trabajo colaborativo y la difusión de buenas prácticas.

5. Carencia para integrar información de activos procedentes de fuentes diferentes, lo que produce que los datos maestros de los activos sean poco fiables.

La aplicación SAP Master Data Governance centraliza los maestros de todas las delegaciones y centros de la empresa. Así mismo, supervisa que dichos datos estén actualizados y que no haya divergencias.

6. Limitación para predecir el fallo o avería de algún bien equipo, lo que conduce a paradas no planificadas. Dificultad para predecir necesidades de recambios en bienes equipo conduce a un aumento en los costes de mantenimiento.

SAP S/4 HANA está integrado con la solución de Servicios y Mantenimiento Predictivo de SAP (SAP Predictive Maintenance and Service).

Y por si aún no lo has leído, aquí tienes la primera parte de este artículo sobre SAP Asset Management. 

El próximo 22 de Junio (viernes), Oreka IT celebra su jornada anual de ponencias, que tendrá lugar en la Cámara de Comercio de Álava, ubicada en la Calle Dato, en pleno centro de Vitoria-Gasteiz.

En ella contaremos con la participación de varios de nuestros consultores y responsables de área, que tratarán sobre algunas de las últimas novedades relacionadas con tecnología de gestión SAP. Como siempre, la idea de base para estas ponencias es explicar de forma clara, concisa y práctica qué valor real aportan las soluciones SAP al día a día de las empresas y organizaciones. Es decir, bajar a tierra sin caer en ambigüedades o en retórica comercial.

Esta jornada está especialmente orientada a profesionales de empresas y organizaciones que se gestionen con alguna de las diferentes soluciones SAP, pero pensamos que también puede aportar valor a personas que quieran estar al tanto de lo que se mueve ya no sólo en el mundo de la informática de gestión, sino en aspectos relacionados con transformación digital o Industria 4.0. No olvidemos que SAP es el mayor fabricante de software de Europa y tractor en lo que a innovación se refiere.

Además, este año contaremos con la participación de Helmut Hampp, presidente IDiA (Asociación Empresarial Innovadora) y antiguo CIO de B/S/H, donde estuvo a cargo de un equipo de cerca de 200 profesionales internos y externos para las 7 plantas del grupo. Helmut dará una ponencia conjunta con Jose Ignacio Carasa, nuestro director de producto e innovación, donde tratarán sobre la importancia del ERP en la Industria 4.0 y su encaje con el Roadmap de SAP. ¡Un auténtico lujazo!

Respecto al resto de ponencias, trataremos sobre los siguientes temas:

• Finanzas sobre SAP S/4 HANA: qué valor aporta el módulo de finanzas en el ERP de nueva generación de SAP.
• Migración de ERP a S/4HANA: paso que tendrán que asumir todas las empresas con SAP y sobre el que hay muchas preguntas. Os ayudaremos a resolverlas.
• SAP SucessFactors: solución Cloud de SAP para la gestión integral de recursos humanos.
• Lumira Discovery: solución para analítica, con visualización de datos por autoservicio que se pueden presentar con formato de historia.

En la parte final del evento, los que lo deseen podrán quedarse para disfrutar de pintxos y vinos del lugar, y compartir experiencias con otros profesionales de su mismo ámbito, además de tener la oportunidad de ponerse en contacto con nosotros para aclarar cualquier duda.

Lo interesados podéis ver el orden del día completo en el enlace a continuación, donde también podéis acceder al formulario de inscripción. Recordamos que el aforo es limitado y que, por supuesto, el evento es gratuito.

Enlace a sitio oficial de la jornada SAP 2018

En los artículos “Retenciones judiciales. Infotipo 0887 (I) y (II)” se presentó el infotipo estandar que gestiona los datos de retenciones judiciales a empleados en SAP. Una vez informado este infotipo se debe incluir una nueva funcionalidad al esquema de nómina para que se hagan las deducciones en el salario y se realice el pago del embargo.

Subesquema EGM0

Se añade el subesquema EGM0 después del subesquema correspondiente a las retroactividades. Este subesquema EGM0 se encarga de leer el infotipo 0887, crear el concepto /GM0, que será la base sobre la que se harán los embargos, calcular las retenciones teniendo en cuenta el los datos del infotipo; entre otros, la prioridad, el importe a retener y si debe limitarse la deducción al SMI; y crear el concepto de pago para el receptor.

CC-nóminas para retenciones judiciales

Tenemos 4 conceptos de nómina relacionados con las retenciones judiciales.

• /GM0 Retención: Resto imp.pago. Como se ha mencionado antes, es la base sobre la que se calculan los importes a retener. Se crea en la regla EGM0.

• /GM1 Retención: Suma deducción. Suma de todas las retenciones hechas correspondientes al periodo actual.
• /GMB Retención: Transferencia. Cada uno de los pagos hechos por cada retención. Esto es, si una retención X en el periodo anterior no se pudo realizar porque los datos bancarios fallaron y quedó el importe en el campo “No transferido”, en este concepto se habrá acumulado el importe no transferido en el periodo anterior y el importe correspondiente a este mes; mientras que en el concepto /GM1 solamente tendrá el importe de la retención X de el periodo actual.
• /GMT Retención: Suma transfer. Suma de todas las transferencias de retenciones judiciales.

Estos conceptos se generan en la función EGARN.

Tabla GARNT del cluster de nómina

Cuando hay retenciones judiciales para un periodo de nómina aparece en el cluster la tabla GARNT. Esta tabla tiene información sobre cada una de las retenciones realizadas en el periodo calculado y del periodo anterior.

En este caso, vemos que los dos registros de la tabla GARNT pertenecen a la misma retención judicial, a la retención con identificador 238. El primer registro es el correspondiente a la retención realizada en el periodo 08.2017, que se dedujeron 619,82€, y en el segundo registro corresponde al periodo 09.2017, que se retuvieron 1.395,86€ siendo el total deducido hasta la fecha 2.015,68€.

Si se calcula la nómina para el siguiente periodo, se arrastra el último registro de la tabla GARNT pasando a ser el primero y se crea uno nuevo con la retención del periodo calculado y el nuevo importe acumulado.

En el ejemplo anterior el importe no retenido es 0€. Esto no siempre es así, ya que si el importe total a embargar mensualmente es mayor que el importe embargable por ley, quedará parte sin retener. Este importe que no ha sido posible retener se guarda en este campo y se arrastrará a los siguientes periodos hasta que se retenga el importe completo.

Los campos como “Total deducido” o “Periodo en nómina” que se muestran en el infotipo 0887 se obtienen de la tabla GARNT.

Ya tienes todas las claves para incluir las retenciones judiciales de los salarios de empleados en el esquema de nómina con SAP.

Beneficios de los sistemas en base de datos en memoria, HANA Data Base.

En los últimos años, en todos los medios, tanto en los especializados en las T.I.s como en los medios generalistas, se escucha el concepto de la computación en la nube. En este aspecto, SAP no se queda atrás y está fomentando el cambio a los sistemas en la nube y a los sistemas con base de datos en memoria. Con el lanzamiento de SAP HANA en noviembre de 2011 hizo su apuesta por esta tecnología.

SAP S/4HANA como alternativa al Business Suite ERP 6.0

SAP es totalmente consciente que el producto SAP Business Suite ECC 6 se va a seguir desarrollando y manteniendo durante los próximos años. Esto es debido a que forma parte del software de gestión de muchas empresas en todo el mundo y con la introducción de la base de datos SAP HANA, la suite ECC 6 se convirtió incluso mejor en algunos aspectos fundamentales. Las nuevas funcionalidades desarrolladas para S/4HANA se revisarán, para analizar si también pueden ser desplegados en la suite ECC 6.0. Un buen ejemplo son los escenarios SAP Fiori self-services que se adoptan sin ningún problema en el ERP 6.

Por estos motivos, SAP considera que es perfectamente asumible optar por la opción SAP Business Suite ECC en los próximos años.

S/4HANA sólo funciona en SAP HANA

SAP HANA es la única base de datos en la que se puede instalar SAP S/4HANA. El rápido crecimiento de las aplicaciones basadas en la nube muestra claramente que la tecnología subyacente debe ser simplificada. El enorme potencial de una base de datos en memoria debe ser explotado para remodelar la forma en que se diseñan las aplicaciones de la empresa. Como resultado se aprecia una drástica simplificación del código de las aplicaciones. La base de datos SAP HANA ofrece formas radicalmente nuevas de resolver los desafíos de hoy y de mañana en las aplicaciones de la empresa. Adicionalmente de soportar SAP S/4HANA, la base de datos SAP HANA, se puede aprovechar para muchos otros escenarios como pueden ser: realizar estudios analíticos de big data e investigación científica de las nuevas aplicaciones de la IOT. A través de la federación de datos, SAP HANA puede integrarse fácilmente con otras bases de datos.

Mejora en el rendimiento del sistema

La base de datos SAP HANA con tecnología de base de datos en memoria, aprovecha la velocidad de la memoria del sistema, que es sustancialmente mayor que la velocidad de las bases tradicionales que residen en disco y tienen que estar constantemente cargando en memoria los datos, que residen en discos duros, para poder procesarlos.

Reducción de recursos necesarios para la administración

No sólo se aprecia la mejora en el rendimiento del sistema, sino que las tareas de administración del sistema ABAP y de la base de datos se ejecutan de una manera más rápida y ágil. Un claro ejemplo, es el tiempo necesario para realizar un backup de una base de datos relacional convencional, como pueden ser: Oracle, Sybase o MaxDB, en las que un backup de una base de datos de 500 Gb puede tardar sobre 3-4 horas, mientras que el backup en una base datos HANA se realiza en menos de 1 hora.

En caso de sufrir algún problema con el sistema, el tiempo necesario para restablecer el funcionamiento normal del sistema se reduce drásticamente.

Mantenimiento de los entornos de test e integración.

¿Necesita mantener sus sistemas de integración y test con datos actualizados? Con las bases de datos SAP HANA, no sólo se reduce el tiempo de creación y restauración de copias de seguridad de la base de datos, sino que estos backups se pueden utilizar para refrescar entornos en cuestión de minutos.

Análisis predictivo.

Realmente donde se aprecia la mejora en el rendimiento es en las operaciones de análisis predictivo en las que procesar grandes volúmenes de datos con una base de datos tradicional, requiere de procesos de fondo que pueden durar varias horas. Con las bases de datos en memoria, el tiempo necesario para finalizar estos procesos se reduce de tal manera, hasta el punto de poder realizar dichos análisis en tiempo real.

Conclusión

Nunca es fácil escoger el mejor momento para acometer cambios de calado en el ámbito de las infraestructuras tecnológicas de una compañía. Muchas veces, estos cambios se ven propiciados por la necesidad de renovar los equipos informáticos y en otras ocasiones el fin del soporte ofrecido por los fabricantes de las versiones de distintos productos como sistemas operativos, bases de datos o plataformas ERP. En otras ocasiones, las inversiones realizadas se orientan a aprovechar la mejora en los procesos de negocio y aumentar el retorno de la inversión.

En ambos casos, es innegable que dar el paso a migrar un sistema SAP ECC 6 a S/4HANA implica sumergirse en un proyecto que requiere de una planificación y una dedicación de recursos importante, no comparable con lo necesario realizar un mantenimiento anual para aplicar los Support Package stacks con las actualizaciones liberadas por SAP.

El futuro de SAP se encuentra orientado hacia SAP HANA y en los sistemas S/4HANA en la nube. Si está pensando o necesita actualizar su sistema ERP 6.0, tiene varias opciones que puede adoptar en función de su capacidad de asignar recursos al proyecto:

• Cambiar la base de datos a SAP HANA y mantener el ERP 6.0 actualizando a la última versión ya que SAP seguirá desarrollando la suite ECC 6.0 por algunos años más y migrar a S/4HANA más adelante.
• Sumergirse en una migración de su ERP 6.0 al nuevo producto S/4HANA y empezar a aprovechar y sacar todo el rendimiento a las mejoras que SAP desde Alemania ha introducido en sus distintas versiones de S/4HANA (1503, 1511, 1610, 1709 y 1809 en 2018).

Para conocer más aspectos interesantes sobre S/4HANA puede consultar el Blog Oreka I.T.

Que sí, que la nómina es uno de los temas más ‘peliagudos’ de Successfactors. Aunque es verdad que de momento Successfactors no tiene motor de nómina, SAP está dando grandes pasos para gestionar la nómina en la nube.

Entonces, ¿podemos dar unas pistas sobre cómo funciona la nómina en la nube? Pues de momento decirte que prácticamente puedes lanzar todos los procesos de nómina desde la nube y que éstos tienen integración directa con el sistema on-premise de SAP.

Con el Employee Central Payroll de SuccessFactors, un usuario podrá lanzar la nómina desde la nube y acto seguido proceder al cálculo de ésta gracias a un sistema ‘hosted’ de SAP.

Además, si se desea, el usuario podrá proceder al cálculo de la nómina desde un sistema on-premise, ya que SAP, gracias a su middleware de integración Dell-Boomi nos permite lanzar datos de nómina desde SAP Cloud a nuestro ERP, procesarlos y volverlos a importar para tener una visualización de los datos procesados. En verdad, incluso cuando los clientes trasladan todos sus módulos de HCM a la nube, éstos tienden a mantener sus sistemas de nómina on-premise (sobre todo si la nómina se controla desde el departamento financiero en vez del de RRHH), por eso, se puede integrar dichos sistemas de nómina on-premise con el Employee Central en la nube permitiendo que éstos reciban datos de los centros de costes de SAP ERP Financials y datos maestros de los empleados desde el Employee Central.

Es decir, al crear o actualizar los centros de coste, el middleware de integracion Dell-Boomi replicaría estos datos de forma automática para su posterior traslado al sistema cloud (a través de Idocs), donde el usuario podría asignar dichos centros de coste a determinados empleados y mantener una distribución eficaz de costes. Además, al actualizar los datos de empleados en el employee central, estos se replican y trasmiten al sistema on-premise para el cálculo de la nómina gracias al middleware arriba mencionado.

Por otro lado, una cosa es clara, y es que Employee Central Payroll no sólo te proporciona una visualización de los datos y una perfecta integración, sino que también nos permite automatizar y acelerar los procesos de nómina, reducir los riesgos y corregir las posibles desviaciones que puedan surgir del cálculo de ésta. Y no sólo los identifica, sino que asigna los errores a sus correspondientes responsables para que éstos los puedan corregir inmediatamente reduciendo el riesgo de solapamiento y proporcionando altos niveles de transparencia. En la app de ‘deliver analytics’ podremos crear benchmarking data y trocear los procesos de nómina para obtener un análisis analítico y gráfico de cada una de las fases que componen el proceso.

Otra ventaja digna de resaltar es la internacionalización disponible, con una presencia en más de 30 países, el sistema se adapta y actualiza automáticamente a la legislación vigente en cada país asegurando su cumplimiento.

Seguiremos hablando de Successfactors, mientras tanto, ¡pregúntanos cualquier duda que te haya quedado!

Los informes de partidas individuales (ya sean de proveedores, clientes o cuentas de mayor) son de los más utilizados en el módulo SAP Finanzas. Estos informes muestran los datos de cada partida individual almacenados en las tablas BSEG y en sus respectivas tablas de índices (BSIS, BSAS, BSID, BSAD…). Con la llegada de SAP HANA estas tablas desaparecen y toda la información, tanto de cabecera como de posición, se guarda en una única tabla, la Universal Journal (ACDOCA). Esto permite que los nuevos informes de partidas individuales puedan mostrar muchos más campos para una sola línea y que se ejecuten en menos tiempo.

Los nuevos informes son:

• FBL1H: Navegador de posiciones de proveedor.
• FBL3H: Navegador de posiciones de cuentas de mayor.
• FBL5H: Navegador de posiciones de cliente.

Estos nuevos informes no son un sustituto del informe de partidas abiertas correspondiente. Las funciones adicionales del informe de partida abierta (p.ej. correspondencia, modificación en masa, orden de corrección) no están disponibles en el navegador de partidas abiertas. Aun así, permiten visualizar mucha más información. En el siguiente artículo me voy a basar en la nueva transacción FBL1H, para explicar el funcionamiento de estos nuevos informes, ya que se utilizan de la misma manera los tres.

La pantalla de selección no varía en su parte general. Los filtros por sociedad y número de cuenta, y por fechas según el estado de la partida siguen apareciendo. La primera variación que nos encontramos son las restricciones adicionales. Al pulsar el botón de restricciones, se abre un pop-up con todos los posibles campos que se han parametrizado para poder usar como filtro adicional:

Este listado de campos para el filtro es parametrizable, y para poder modificarlos hay que pulsar el botón de parametrizaciones () que se encuentra en la barra de herramientas. Tras pulsarlo, se abre una pantalla para la configuración del informe, y con el botón “Configurar campos” se puede decidir qué campos de la ACDOCA serán visibles en el informe (Primera columna) y que campos pueden usarse en las restricciones adicionales (Segunda columna).

Al ejecutar el informe, la pantalla se divide en dos partes. La parte de la izquierda que muestra ALV del propio informe, y a la derecha el control de la visualización del informe.

La parte de la izquierda funciona igual que cualquier otro ALV estándar de SAP, con celdas navegables para acceder al detalle de las posiciones, de la cuenta o de la sociedad; las funciones básicas de búsqueda, sumatorios, filtrado u ordenación; botones para configurar la disposición…

Gracias al botón   es posible navegar al informe de partidas individuales clásico. Seleccionando las líneas que se deseen y pulsando este botón, se abrirá una pantalla con el informe clásico, en el cuál sí se podrán usar las funciones de modificaciones en masa o correspondencia.

En la parte derecha se encuentran diferentes acciones de visualización del informe, divididas por pestañas:

• En la pestaña de columnas, se pueden seleccionar de manera rápida que columnas se muestran en el ALV.
• En la pestaña “Layouts” se pueden elegir las diferentes disposiciones que se tengan guardadas del informe. Así, con un solo clic es posible modificar las columnas o filtros aplicados al informe según la disposición.
• En la pestaña “Acciones” es posible abrir un nuevo informe en otra ventana solo con las filas seleccionadas, o descargar a un fichero el ALV de manera sencilla.
• En la última pestaña de “Historial”, se guardan las ejecuciones del informe que se han realizado con anterioridad. Así si se cierra la pantalla y se podrá recuperar el informe que se estaba visualizando.

Con estos nuevos navegadores de partidas individuales podremos ver mucha más información en un solo informe que en los antiguos de partidas individuales, ya que muchos campos (como el nombre de proveedor, país, bancos propios…) que en el informe clásico no se visualizaban si es posible sacarlos en este.

Puedes encontrar muchos más artículos sobre SAP S4/HANA y el módulo de finanzas de SAP en nuestro blog. Y si no encuentras lo que buscas, ¡pregúntanos!

El pasado martes 26 de junio de 2018, el programa de radio “Radio Vitoria Gaur Magazine” nos realizó una breve entrevista en Radio Vitoria. En ella, el director general de OREKA IT, Iraitz Pérez de Goldarazena, explica brevemente nuestra trayectoria histórica y las características que nos destacan frente a otras consultoras.

Siendo conscientes del peso que tienen las PYMEs en el tejido industrial que nos rodea, queda patente el enfoque que tenemos hacia ellas, quienes empiezan a dar el gran salto a la transformación digital y a la industria 4.0. Todo ello sin olvidar nuestra experiencia en implantaciones de mayor tamaño.

Pero lo mejor es que lo oigas por ti mism@. ¡Aquí la tienes!

El pasado 22 de junio celebramos en Vitoria-Gasteiz la jornada anual de ponencias sobre SAP, en la que hablamos de las últimas novedades en esta tecnología.

Para todas aquellas personas que no pudieron acudir, vamos a publicar en nuestro blog la serie completa de ponencias en formato vídeo. Esperamos que te sean de utilidad, y te anime a acudir a la próxima edición de este evento. 

La importancia del ERP en tiempos de la industria 4.0 y su encaje en el roadmap de SAP

Empezamos por la ponencia que abrió la jornada, impartida por Helmut Hampp (presidente de IDiA) y Jose Carasa (director de productos SAP e Innovación de Oreka IT) en la que nos hablan de la importancia que tienen los ERP en la industria 4.0, y cuál es el encaje del roadmap de SAP en este fenómeno.

Puedes ver el resto de ponencias en los siguientes enlaces:

• Finanzas sobre SAP S4/HANA
• SuccessFactors
• Lumira Discovery

El pasado 22 de junio celebramos en Vitoria-Gasteiz la jornada anual de ponencias sobre SAP, en la que hablamos de las últimas novedades en esta tecnología.

Para todas aquellas personas que no pudieron acudir, dejamos publicadas en el blog las ponencias en formato vídeo.

Finanzas sobre SAP S4/HANA

Segunda ponencia de la jornada, impartida por nuestro consultor senior en SAP Finanzas, Rodrigo Mendaza, hablando sobre la gestión del módulo de finanzas en S4/HANA. Puedes ver los artículos escritos por Rodrigo en nuestro blog, aquí. 

Puedes ver el resto de ponencias en los siguientes enlaces:

• La importancia del ERP en tiempos de la industria 4.0 y su encaje en el roadmap de SAP
• SuccessFactors
• Lumira Discovery