Transformaciones de XML complejos a ABAP

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.

Actualizar tipo de tablas para transformaciones XML complejos a ABAP

SAP: estructura XML a ABAP

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.

SAP: estructura XML a ABAPSAP: estructura XML a ABAP

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”.

SAP: Transformación simple XML

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

SAP - lógica de transformación simple - XML

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).

Estructura - root - SAP - XML

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.

Cargar estructura creada - transformación XML

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.

 

Publicado en Programming, SAP, SAP España, SAP Netweaver | Deja un comentario

Personalización de transacciones Enjoy en SAP FI

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 Botón opciones de tratamiento SAPpara 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:

Opciones de tratamiento en SAP FI

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:

Variantes de transacción para modificar los campos por defecto SAP FI

Indicamos la transacción para la que queremos crear una variante y le damos un nombre a la variante. Pulsamos el botón Botón para crear variante - SAP FI 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:

Tabla de posiciones - transacciones Enjoy SAP FI

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:

Crear transacción de variantes Enjoy SAP FI

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?

Publicado en SAP, SAP FI - Finanzas | Deja un comentario

Optimización en SAP BW powered by HANA: Advanced ODSs y Delta Merge

En este artículo vamos a ver cómo en SAP BW powered by HANA tendremos la posibilidad de controlar el momento de realizar un Delta merge, o fusión de base de datos, para ciertos objetos y así optimizar el uso de memoria y el proceso de lectura de los mismos.

SAP HANA soporta tanto tablas con almacenamiento por líneas como por columnas. Estas últimas tienen buen rendimiento en las operaciones de lectura, pero mal rendimiento en las operaciones de escritura. Por este motivo, cada tabla con estructura de columnas está compuesta por dos espacios de almacenamiento:

  • la principal o “Main Storage”, optimizada para la lectura
  • y el almacenamiento delta, o Delta Storage”, optimizada para la escritura

Las operaciones de escritura se realizan únicamente en la memoria Delta. Con el fin de transformar los datos a un formato optimizado en términos de consumo de memoria y de optimización para lectura, debe ser transferida a la memoria principal mediante un proceso Delta Merge.

Proceso Delta Merge - SAP BW

Debido a que en SAP BW normalmente se procesa un número masivo de datos, el proceso de Delta Merge se realiza dentro de la aplicación y dependiendo del objeto se realizará automáticamente o debe ser lanzado de forma manual.

Para los diferentes objetos sobre los cuales puede almacenarse información, el proceso Delta Merge se realiza de diferente manera, y para alguno de ellos el proceso se realizará automáticamente, pero, para todo tipo de Advanced ODSs, el proceso de Delta Merge se maneja dentro de la aplicación de forma manual.

En la pestaña Actualización de los DTP existe un checkbox “Lanzar fusión bases de datos:

Lanzar fusión bases de datos - SAP BW

Una vez que el proceso se ha realizado con éxito, esta configuración controla el Delta Merge. Este checkbox está activo por norma general, pero existen casos especiales en los que no es recomendable tenerlo marcado.

Para esos casos excepcionales la alternativa para realizar la Delta Merge será mediante el proceso “Iniciar fusión delta” de las cadenas de procesos:

Iniciar fusión delta - Optimización SAP BW HANA

En este proceso habrá que especificar el objeto y su tipo para la fusión de la delta.

Especificar objeto y tipo para la fusión de la delta - SAP BW

 

Por último, hay que recalcar que el límite de 2 mil millones de líneas por partición también se aplica al almacenamiento delta, por lo que, tanto si se da un caso especial y hay que realizar una fusión delta en una cadena, como si se hace de forma automática en un DTP, siempre debe existir una fusión delta o la información se quedará almacenada en la memoria delta de una tabla, lo cual llevará a un uso subóptimo de la memoria y del proceso de lectura.

Rendimiento SIN Delta MergeRendimiento sin Delta Merge

 

Rendimiento SIN Delta Merge

Rendimiento CON Delta Merge

¿Conocíais esta utilización de Delta Merge y Advanced ODSs?

Recordad que en Oreka IT os podemos ayudar con vuestros proyectos SAP, instalación y mantenimiento. ¡Contáctanos!

Publicado en SAP, SAP BI - Business Intelligence, SAP Bussiness Warehouse, SAP España, SAP HANA | Deja un comentario

SAP MM-PUR: Pedido Límite

En este artículo vamos a explicar la funcionalidad de “Pedido límite” en el módulo MM de SAP.

En ciertas ocasiones, para cierto tipo de material de consumo (material no de almacén), puede que a nuestra organización no le interese contar con un proceso de re-aprovisionamiento muy controlado y medido, ya que esto conlleva unos gastos de gestión que no siempre aportan valor añadido.

Como herramienta de simplificación del proceso de reaprovisionamiento, SAP cuenta con el PEDIDO LÍMITE, que permite reducir los gastos de gestión hasta su mínima expresión.

El PEDIDO LÍMITE es de aplicación cuando concurren los siguientes factores:

  • Los materiales no se gestionan mediante stock, ni en cantidad ni en valor, sino que son materiales de consumo. De hecho, no existe registro maestro para estos materiales.
  • El proveedor suministrador es único y siempre el mismo.
  • El material se solicita con cierta periodicidad, por ejemplo, mensualmente.

Un posible escenario tipo podría ser el de una empresa de manufacturas, que requiere de material de oficina cada cierto tiempo. La suma del gasto en estos materiales no es considerada relevante, por lo que se establece un proceso de re-suministro ágil que no implique unos elevados costes de gestión.

En el PEDIDO LÍMITE no se realizan entradas de mercancías, y únicamente se efectúa un pedido inicial, con una única posición. Posteriormente, todas las facturas de compra que se reciban se referenciarán a ese único pedido. En este escenario, el volumen de documentos de compra a crear se reduce considerablemente:

SAP MM: cómo funciona el pedido límite

Aunque no se consiga un control pormenorizado de las entradas y salidas de material (este no el objetivo), el PEDIDO LÍMITE proporciona unos mecanismos de control muy interesantes:

  • Periodo de validez: Fecha de inicio y fecha final del pedido. Cuando se mecaniza una factura con referencia al PEDIDO LÍMITE fuera del periodo de validez del mismo, el sistema muestra un aviso.
  • Límite global: Importe límite a gastar, puede equipararse a un presupuesto. Cuando se mecaniza una factura con referencia al PEDIDO LÍMITE de manera que se excede el límite global, el sistema muestra un aviso.

La transacción en SAP para realizar un PEDIDO LÍMITE es la ME21N – Crear Pedido, y la clase de pedido la FO – Pedido Marco.

A nivel de cabecera, en la pestaña Datos adicionales, se informará del periodo de validez del pedido:

Validez del pedido y datos adicionales en "Pedido límite" SAP MM

Se completará una única posición:

  • Tipo de posición: P Límite
  • Texto breve.
  • Cantidad: 1
  • Grupo de Artículos.

En la pestaña Límites, a nivel de posición, se informará de:

  • Límite global: montante máximo a gastar en dicho pedido. Este valor se puede marcar como ilimitado.
  • Valor previsto: previsión del gasto.

Límites y valor en 'pedido límite' SAP MM S/4HANA

Si no se introduce valor alguno en el campo Límite global y se marca el flag Ilimitado, el suministro podrá ser por un valor ilimitado.

Una vez realizado el PEDIDO LÍMITE, se podrán contabilizar facturas sobre dicho pedido mediante la transacción MIRO – Entrar factura recibida.

Gestión de factura recibida en pedido límite - SAP MM

Visualizando el pedido (transacción ME23N – Visualizar pedido), se recoge información sobre el importe efectivamente gastado hasta la fecha y la relación de facturas referenciadas al mismo.

ME23N – Visualizar pedido en SAP MM para pedido límite

Como mecanismo de control, cuando se contabiliza una factura con referencia a un PEDIDO LÍMITE, el sistema realiza dos comprobaciones:

  1. ¿La fecha de la factura se encuentra dentro del periodo de validez del PEDIDO LÍMITE?
  2. ¿La contabilización de la factura hace que se supere el límite global del PEDIDO LÍMITE?

Si se da alguna de estas dos casuísticas, el sistema lanza sendos mensajes. Por estándar, dichos mensajes son de aviso (Warning), aunque el tipo de mensaje se puede modificar por parametrización.

Parametrización de avisos 'warning' en SAP MM

De esta manera, con la herramienta del PEDIDO LÍMITE se consigue un proceso de re-aprovisionamiento simplificado y ágil, sin renunciar al control presupuestario.

Esperamos haberos ayudado a comprender mejor el funcionamiento del Pedido Límite en el módulo MM de SAP para cierto tipo de materiales de consumo.

Publicado en SAP, SAP MM - Gestión de materiales | Etiquetado , , , | Deja un comentario

SAP S/4HANA 1610 código estándar modificable

A continuación se plantea una situación un tanto atípica en un sistema SAP.

Tras finalizar con éxito una instalación de un sistema SAP S/4HANA on premise 1610, los objetos workbench estándar del repositorio ABAP (reports, tablas, elementos de datos, dominios, etc.) son completamente modificables.

En un mandante de desarrollo donde la configuración de la transacción SCC4 permita realizar modificaciones sin restricciones y las opciones de modificación globales del sistema, transacción SE06, los objetos estándar del sistema se pueden modificar sin registrarlos en el SAP Support Portal.

En un mandante de desarrollo/formación las opciones más comunes son:

SAP S4/HANA

Y las opciones de modificación del sistema se encuentran en status Modificable:

Opciones modificables SAP

La versión de Netweaver es 7.51 y los componentes del sistema S/4HANA 1610 on premise son los siguientes:

Netweaver y SAP S/4HANA

 

El release instalado es SAP S/4HANA 1610 como se pude ver en el status del sistema:

Status del sistema S4/HANA

Los objetos estándar del repositorio ABAP es totalmente modificable:Objetos modificables en SAP S/4HANA

Al pasar a modificar el objeto, se muestran las siguientes ventanas advirtiendo que las modificaciones de objetos estándar no están permitidas:

Modificaciones no permitidas en SAP S4/HANA

Modificaciones no permitidas en SAP S4/HANA

Una vez seleccionado el idioma en el que modificar el objeto, se habilita la modificación del objeto estándar:

Habilitar la modificación del objeto estándar SAP S4/HANA

Lo mismo sucede a la hora de modificar un programa (report) o un módulo de función:

modificar un programa (report) o un módulo de función SAP S/4HANA

Se muestra la advertencia siguiente:

Advertencia modificación SAP S/4HANA

 

Advertencia modificación SAP S/4HANASi se desactiva el asistente de modificaciones, el objeto se puede modificar sin ninguna restricción:

Desactivar el asistente de modificaciones SAP S4/HANA

Desactivar el asistente de modificaciones SAP S4/HANA

El report es completamente modificable y se puede grabar y activar sin introducir ningún tipo de clave de registro del objeto:

El report es completamente modificable y se puede grabar y activar sin introducir ningún tipo de clave de registro del objeto

En esta situación se plantean varias cuestiones:

  • ¿Es consciente SAP de esta circunstancia?
  • ¿Está previsto que en un SP stack liberado SAP bloquee el código estándar?
Publicado en Administración de sistemas, SAP, SAP HANA, Varios | Etiquetado , , | Deja un comentario

Retenciones judiciales en SAP HCM: infotipo 0887 (I)

Puede que se tenga que embargar parte del salario de un empleado a partir de un procedimiento judicial o por orden de un organismo público. ¿Cómo lo podemos hacer? SAP implementa esta funcionalidad a partir del infotipo 0887.

El infotipo 0887 (Retenciones) permite crear y gestionar las retenciones judiciales que se aplican al salario de un empleado. El infotipo te permite seleccionar el tipo de retención, el grupo de deducción, la cantidad a pagar y el beneficiario del pago.

A continuación se van a explicar los subtipos que se tienen en el estándar y los grupos de deducciones que ofrecen.

Subtipos. Tipos de retención.

Subtipos infotipo 0887 en SAP

Estos son los subtipos del infotipo 0887.

  1. Deducción porcentual. Se calculará a partir de un porcentaje de la base de retención. Esta base de retención será un concepto de nómina que indicamos en el infotipo. Se puede usar el concepto /GM0 (Retencion: Resto imp.pago) que contendrá el neto de la nómina antes de aplicar las retenciones. Para poder usar el CC-nómina en el infotipo habrá que hacer una entrada en la vista V_T512Z (cc-nóminas admitidas).

Deducción porcentual en retención infotipo 0887

  1. Deducción del valor mensual. El importe a deducir cada mes se calculará a partir de un valor fijo.
  2. Deducción de valor hasta total. Se calculará a partir de valor fijo hasta llegar a un total.
  3. Deducción IPR: Se calculará teniendo en cuenta los intervalos definidos en la Ley de Enjuiciamiento Civil. Los porcentajes a embargar que define la ley de enjuiciamiento se parametrizan en la tabla T511K, en las siguientes constantes:

Subtipo retención - deducción IPR en SAP HCM

  1. Deducción IPR hasta total: Se calculará teniendo en cuenta los intervalos definidos en la Ley de Enjuiciamiento Civil hasta llegar a un total.

Se puede tener cualquier combinación de los subtipos 1, 2 y 3, pero los subtipos 4 y 5 no pueden coexistir. Esto es, pueden ocurrir a la vez cualquier combinación entre uno o más subtipos 1, 2 y 3 y un subtipo 4 o uno 5.

Grupo de deducción

Para todos los subtipos tenemos el grupo de deducción “Deducción limitado por SMIPR”. Esto significa que existe un salario exento de retención, normalmente el SMI. La cantidad inembargable está definida por la constante SMIPR (salario mínimo interprofesional diario) o por la constante SIPRE (indicador público de renta de efectos múltiples) de la tabla T511P. En la vista V_T5E92 se indica por cada subtipo y grupo de deducción cuál de las dos constantes se usará.

SAP HCM - grupo de deducción limitado

El subtipo 3 “Deducción de valor hasta total” tiene además del grupo de deducción anterior, los grupos “Pensión compensatoria” y “Pensión por alimentos”. Éstos no limitan las retenciones al salario mínimo interprofesional, sino que embargan la cantidad completa indicada en el infotipo.

En caso de necesitar nuevos grupos de deducción se pueden crear en la vista V_T5E92, a la cual podemos acceder a través de la SPRO:

Cálculo de la nómina
Cálculo de nómina: España
Retenciones judiciales
Asignar opciones a situaciones de retenciones.

Así es como se configuran las retenciones en el salario del empleado por requerimiento judicial o por orden de un organismo público en el módulo HCM de SAP. En un próximo artículo se detallarán los campos del infotipo 0887.

 

Publicado en SAP, SAP HCM - Recursos Humanos | Etiquetado , , , , | Deja un comentario

SAP BI Lumira 2.0

Después de un año de ser anunciada, y tras haber estado en boca de todos en el mundo de Business Intelligence, en agosto de 2017 se libera la nueva apuesta de SAP para la elaboración de Cuadros de Mando: Lumira 2.0.

SAP Lumira - Lumira Discovery - Lumira Designer

Ya lo comentamos en el artículo “SAP Design Studio: Roadmap y en las ponencias que dimos en la cámara de comercio de Vitoria en junio de 2016 con la temática “SAP HANA & Business Intelligence”: SAP sorprendía a propios y extraños anunciando que las experiencias de Lumira y Design Studio iban a combinarse en un producto con dos interfaces diferentes. Por un lado, el antiguo Lumira pasaría a llamarse a Lumira Discovery y Design Studio a Lumira Designer.

¿Qué hay de nuevo?

Pero las novedades no son solamente bautizos de nombres, hay importantes innovaciones. La primera es la interoperabilidad entre ambos clientes, ya que la tecnología es compartida. La idea de este concepto es que un usuario de negocio pueda perfeccionar un documento que él mismo ha creado en Lumira Discovery, añadiendo más posibilidades. ¿Cómo? Pasándoselo al departamento de IT y que éstos, usando Lumira Designer, modifiquen la aplicación programando las nuevas necesidades que se requieran (los documentos se guardan en un nuevo formato .lumx, reconocible en Lumira Discovery y Designer).

Lumira Discovery - Lumira Designer

Lumira Discovery: La herramienta on-premise, de BI para el descubrimiento del dato, visualización y análisis

Además, cada una de las interfaces ha ido evolucionando adaptando nuevas funcionalidades y posibilidades. Por la parte de Lumira Discovery, la que, en mi opinión, considero más importante, es poder conectarse a BW. Por fin pueden usarse los datos de BW para crear documentos sin tener que descargarlos a local. También, se ha mejorado la interfaz de usuario creando un menú principal en el que está toda la información centralizada: se puede acceder a todas las conexiones, documentos, etc. Hay muchas adiciones a nivel de aplicación, desde poder usar “arrastrar & soltar” para crear controles, creación de filtros, nuevos tipos de gráficos, formato condicional, opciones a los datos en formato tabla, etc.

SAP Lumira

Lumira Designer: La evolución de BusinessObjects Design Studio

Design Studio ha cambiado su nombre a Lumira Designer, desarrollando más facultades, las cuales hacen que se pueda crear cuadros de mando de una profundidad mayor si cabe. Las novedades más llamativas quizás sean los denominados “Composites” y el componente “Adaptative Layout”.

El nuevo término “Composite” hace referencia a los componentes propios creados en Lumira Designer, como combinación de varios objetos estándar, que pueden ser reutilizables en varios Dashboards. Para éstos, pueden definirse eventos propios, funciones y propiedades. De tal manera, si se hace un cambio en el mismo, se aplicará el cambio en todos los Dashboards en los que se esté utilizando.

Lumira - BusinessObjects Design Studio

Una de las novedades que más llaman la atención es el componente “Adaptative Layout”. Es un elemento de tipo container, similar al “Grid Layout”, para el que se puede definir cuatro diferentes disposiciones en función del tamaño de la pantalla en la que se esté mostrando el cuadro de mando (pequeña, media, grande y muy grande). De esta manera, es más fácil hacer un cuadro de mando “responsive”, que sirva tanto para un móvil como para un monitor de oficina, visualizándose con disposiciones distintas, de “apariencia Fiori”.

SAP Lumira 2.0

Relacionados con “Lumira Designer” hay multitud de cambios, mejoras y funcionalidades nuevas. Tantas, que las trataremos más a fondo en futuros artículos. Entre ellas se incluyen mejoras a los favoritos, exportación a Analysis for Office, impresiones de tablas completas vía conversiones a PDF, nuevos gráficos y simplificación de las opciones de estos, formatos condicionales, nuevos componentes… etc.

Planes de futuro: Lumira 2.1 para finales 2017

Lumira 2.0 es un producto en constante evolución. Tal y como nos comentó Jie Deng (Product Manager de SAP BusinessObjects Lumira y Design Studio) en el TechEd de Barcelona hace unas semanas, hay una nueva versión planeada (Lumira 2.1.) para finales de 2017, que traerá novedades como la posibilidad de que el usuario pueda crear y gestionar comentarios asociándolos a un dato concreto, creación de componentes de forma dinámica, etc.

El nivel de las aplicaciones realizadas por BO BI subirá varios niveles gracias a la explotación de todas estas nuevas capacidades que nos brinda Lumira 2.0.

El futuro Lumira 2.1

Publicado en SAP, SAP BI - Business Intelligence, SAP Bussiness Warehouse, SAP Lumira | Etiquetado | Deja un comentario

Sistemas SAP: Por qué es importante el mantenimiento Basis

El mantenimiento Basis de los sistemas SAP es un tema delicado ya que es el encargado de la disponibilidad del sistema y, por consiguiente, de la viabilidad del negocio. No obstante, existe una tendencia a no valorar suficientemente la importancia del mantenimiento Basis. Hasta que surgen los problemas. El equipo encargado de llevar a cabo las labores de mantenimiento Basis bien se podría comparar a la figura de un portero de fútbol: nadie se acuerda de él hasta que le meten gol.

Por ello, es clave elegir un partner capacitado que transmita experiencia, conocimiento, seguridad, cercanía, fiabilidad y que sepa llevar a cabo las actuaciones necesarias para sacar el máximo rendimiento a los sistemas SAP de una empresa u organización.

Sigue leyendo

Publicado en Administración de sistemas, Consultoría SAP, Oreka IT, SAP, SAP España, SAP Solution manager, Varios | 2 comentarios

Oreka IT & SAP Business One – Un equipo de éxito de para la digitalización de tu pequeña empresa

La capacidad de las pequeñas y medianas empresas para sumarse a la llamada cuarta revolución industrial determinará sus posibilidades de competir y sobrevivir en el mercado global en un plazo de entre cinco y diez años. Un escenario que ha llevado a situar la transformación digital en el centro de las estrategias corporativas, con un enfoque transversal que implica a todos y cada uno de los departamentos y profesionales de la organización. Y todo ello sobre un principio básico: no se trata sólo de automatizar procesos y tareas ya existentes, sino de innovar para optimizar la gestión, la distribución y comercialización, producción y la relación con empleados, clientes y proveedores.

En este artículo hablábamos de la importancia de la digitalización en las empresas.

Sigue leyendo

Publicado en SAP, SAP B1 - Business One, SAP España | Etiquetado , , , , , , , , , , , | Deja un comentario

SAP FI: Proceso diario para el envío de facturas al SII en SAP

En este artículo anterior os comentábamos las opciones para la nueva gestión del IVA con el SII en SAP.

En este artículo vamos a detallar el proceso y las diferentes opciones para el envío diario de facturas al SII con SAP FI.

Sigue leyendo

Publicado en SAP, SAP España, SAP FI - Finanzas | Etiquetado , , , , , | Deja un comentario