En ocasiones, se requiere modificar campos que se repiten en múltiples reports, por ejemplo, cuando se quieren eliminar hardcodes de los diferentes programas. SAP dispone de varias herramientas para poder localizar estos string, indicando en qué programas se encuentran. En este artículo, veremos el report RS_ABAP_SOURCE_SCAN, que nos permite encontrar mediante una serie de filtros y de manera detallada el string deseado en diferentes reports.

En el concepto de buscado, introducimos el string (o más de un string) que queremos buscar.

Por otro lado, se puede filtrar por:

• Programa
• Dynpro
• Tipo de programa
  • 1 –> Programa ejecutable
  • I –> Programa Include
  • M –> Modulpool
  • F –> Grupo de funciones
• Autor del programa
• Modificado por

Los objetos relacionados del Workbench ABAP se agrupan por paquetes; con este buscador podemos filtrar por qué paquetes se quiere realizar la búsqueda.

También por clase/interface:

Se puede desglosar los includes que muestra, incluso, ignorar todas aquellas líneas de comentarios en los que aparezca el string buscado.

Por último, nos permite elegir en que ámbito queremos buscar el string:

Una vez ejecutado, vemos algo así:

Como hemos dicho al comienzo del artículo, esta no es la única herramienta de búsqueda de strings, entre otras existen:

• La transacción EWK1
• El programa RPINCL10

Esperamos que esté artículo te haya sido de utilidad si necesitas buscar strings en reports ABAP. Puedes dejarnos tus preguntas en comentarios

La entrada RS_ABAP_SOURCE_SCAN: búsqueda de strings en reports ABAP se publicó primero en Blog de SAP: Actualidad SAP, Business Intelligence, SAP HCM, Abap....

En muchas ocasiones, en un departamento de mantenimiento, es necesario imprimir en papel el aviso y la orden de mantenimiento desde SAP PM.

Para ello, es necesario previamente crear el documento de trabajo de impresión, el formulario y el programa de edición si se quiere realizar un formulario o smartform propio con los datos de la empresa (logotipo, dirección), así como especificar la impresora o descargar el aviso o el orden. La parametrización para ese proceso es:

IMG: Mantenimiento y servicio al cliente -> Gestión de mantenimiento y servicios -> Órdenes de mantenimiento y servicios -> Control de impresión

Es necesario recordar que a través de la transacción SE71, se puede buscar o inclusive crear el formulario para imprimir la orden o el aviso de mantenimiento

Tras la definición del formulario, el documento de trabajo y el programa de impresión, podemos ya imprimir un aviso o una orden de mantenimiento.

Cabe resaltar que para imprimir una orden de mantenimiento es obligatorio que la orden se encuentre en Status Liberado, para ello, basta entrar en la transacción IW32, introducir la orden de mantenimiento y pinchar en el icono , de tal forma que la orden pase de estado abierto a Liberado, finalmente se presiona el botón “Guardar”, para realizar dicho proceso:

Una vez liberada la orden, si se quiere imprimir o extraer en PDF, se acude a la transacción IW3D introduciendo la orden que se quiere extraer. Otra opción es continuar en la transacción IW32 y acceder a la siguiente ruta:

Menú: Orden-> Imprimir-> Orden

Aparecerá el siguiente cuadro de diálogo, donde se deberá seleccionar el tipo de orden o aviso que se quiere imprimir indicando el dispositivo de salida correspondiente:

Presionando sobre el botón “Visualización de impresión” se podrá ver previamente el aviso o la orden en cada caso.

Así de fácil es obtener una  versión impresa de los avisos y órdenes de mantenimiento. Si tienes cualquier duda puedes dejarnos tus preguntas en comentarios o ponerte en contacto con nuestro departamento de SAP Logística.

Área SAP Logístca

La entrada Impresión de avisos y órdenes de mantenimiento desde SAP PM se publicó primero en Blog de SAP: Actualidad SAP, Business Intelligence, SAP HCM, Abap....

En un gran número de Organizaciones, la Comunicación Bancaria de las Facturas a Pagar a Proveedores y Recibos a Cobrar a Clientes se realiza mediante procesos manuales.

Periódicamente, personal del Departamento de Tesorería debe dedicar su tiempo a descargar Ficheros de Cobros y Pagos de SAP, para después volverlos a cargar en la Plataforma Web de cada Entidad Bancaria, o mandarlo por e-mail al Gestor del Banco, e incluso, entregarlo en Oficina en soporte físico. Una práctica que, además de consumir tiempo, entraña riesgos debido a la exposición de ficheros bancarios a manipulaciones manuales.

SAP Bank Communication Management (BCM) es la herramienta standard de SAP para una Comunicación Bancaria Automática, Centralizada y Controlada:

• Automática: se suprimen las acciones manuales a realizar sobre el Fichero. Además, de esta manera el riesgo por manipulación del Fichero es inexistente.
• Centralizada: se unifican los criterios y canales de comunicación bancaria una única pasarela de pagos.
• Controlada: además, SAP BCM permite incluir flujos para personas responsables que deberán autorizar el envío definitivo del Fichero de Pago al Banco.

Flujo de Comunicación Bancaria en BCM

Los pasos del proceso de Comunicación Bancaria en BCM son los siguientes:

1. Una vez generadas las facturas de Compras y Ventas, se ejecuta el Programa de Pagos a través de la transacción F110 para que recoja todas las facturas de clientes y proveedores que tenemos que pagar vía transferencia o cobrar vía giro de recibos.

La implantación de SAP BCM no excluye la Ejecución del Programa de Pagos

2. Generamos los lotes de pagos/cobros en BCM a través de la transacción FBPM1 en base a unas reglas definidas previamente por parte de la organización

3. Accedemos al monitor de aprobación (BNK_APP), donde tenemos aquellos lotes pendientes de autorizar por nuestra parte

Desde este monitor se ejecutan las acciones de autorización para la liberación del pago, desde el cual podemos realizar las siguientes acciones:

• Aprobar
• Rechazar
• Volver a presentar

Todas las acciones pueden ser tanto para un lote completo como para cada una de las facturas que componen los lotes.

Cabe destacar que se pueden establecer varios niveles de autorización pudiendo ser una firma única, firma mancomunada o firma solidaria.

4. Para cada acción dentro del proceso de autorización, el sistema nos pedirá una firma digital para autenticar la identidad.

5. Una vez finalizado el Flujo de aprobación es cuando se genera el fichero que posteriormente se enviará al banco de manera automática.

Esto dota de seguridad al proceso y se elimina el riesgo por manipulación de ficheros, ya que el medio de pago se genera finalizadas las aprobaciones y este es transferido de manera automática

6. Para finalizar, recibiremos la respuesta del banco sobre si los pagos/cobros enviados en el fichero se han procesado correctamente o no.

Monitor de SAP BCM

Desde la transacción BNK_MONI podemos llevar un seguimiento de todos los lotes generados en SAP BCM.

Desde este monitor, podemos obtener la siguiente información:

• Vemos en qué punto del proceso de autorización se encuentra cada lote
• Los pagos/cobros que conforman el lote
• Las reglas que se han aplicado al tratar ese lote
• Quien(es) es el usuario/usuarios que deben autorizar el lote
• El historial de status del lote y quienes han sido los usuarios autorizadores
• El fichero generado que será enviado al banco automáticamente

En definitiva, mediante SAP BCM, podemos evitar cualquier proceso manual a la hora de gestionar los pagos y cobros con los intervinientes de nuestra organización.

Esperamos que este artículo te haya sido de ayuda para conocer un poco más SAP BCM. Puedes dejarnos tus preguntas en comentarios o ponerte en contacto con nuestro equipo de SAP Finanzas & Controlling si estás interesad@ en esta solución.

Área SAP Finanzas & Controlling

La entrada SAP BCM – Bank Comunication Management se publicó primero en Blog de SAP: Actualidad SAP, Business Intelligence, SAP HCM, Abap....

Llevamos ya más de cuatro años escribiendo sobre SAP Fiori en este blog por lo que ya todos deberíamos saber en qué consiste y cómo forma parte indispensable de S/4HANA. En estos artículos hemos hablado de su arquitectura y de cuáles son los mínimos que necesita nuestro sistema para poder utilizar esta tecnología.

También hemos hablado de cómo se desarrollan aplicaciones con SAPUI5 y de cómo extender aplicaciones Fiori ya existentes. Para estos casos es necesario conocimiento de Javascript y de creación de servicios ODATA.

Pero ¿qué pasa si nuestro sistema no cumple los mínimos requeridos para la ejecución de estas aplicaciones? ¿Necesita mi equipo formarse en Javascript para que mi compañía pueda empezar a disfrutar de las ventajas que nos proporcionan las aplicaciones móviles?

Para estos casos, nace en Noruega la empresa Neptune Software, y para dar soporte a estas empresas, desde Oreka IT llevamos tiempo trabajando en nuestro partnership con Neptune.

¿Qué es Neptune?

Neptune software es una compañía con base en Oslo fundada en 2011 que durante estos años ha desarrollado una solución para la creación de aplicaciones FIORI de forma rápida para versiones de SAP desde SAP Netweaver 7.01.

El software se descarga desde su web en pocos minutos en un formato de ordenes de transporte y en poco tiempo. Nos permite crear estas aplicaciones sin apenas conocimientos de Javascript. Cualquier programador ABAP puede crearlas sin necesidad de formación extra.

Con tan sólo una clase ABAP y la generación de la aplicación desde el IDE proporcionado por Neptune, se pueden generar aplicaciones en pocos días.

La comunicación entre la aplicación y el backend de SAP se realiza mediante la conversión de las estructuras del backend en llamadas json nativas, por lo que tampoco es necesaria la creación de servicios web para el paso de información.

¿Por qué Neptune?

• Proporciona una plataforma de desarrollo online basada en drag and drop y low-code.
• Tu sistema no necesita ningún upgrade. Neptune funciona tanto en las versiones más modernas de S/4 HANA, en SCP Cloud Platform, como en versiones de SAP Netweaver, desde la versión 7.01.
• Más de 100 aplicaciones ya existentes para poder descargarse desde su catálogo.

• Las Apps creadas en Fiori y las creadas en Neptune pueden funcionar conjuntamente, por lo que lo invertido ahora seguirá pudiéndose usar tras las futuras migraciones.
• Los programadores ABAP no necesitan formación extra para la creación de Apps móviles para Android, iOS y Windows. Con un poco de conocimiento en javascript y sin necesidad de la creación de servicios ODATA.
• Las aplicaciones Neptune pueden trabajar de manera off-line.
• Los tiempos se reducen, los costes en formación se reducen y los costes en actualizaciones se reducen.

Puedes ver las aplicaciones creados con el software desde este enlace http://ides.neptune-software.com/neptune/sdk/neptune/appstore_demo.html .

Si tienes cualquier duda respecto a Neptune Sofware puedes dejarnos tus preguntas en comentarios o ponerte en contacto con nuestro área de User Experience & Integración-

Área User Experience & Integración

La entrada Aplicaciones FIORI usando Neptune Software se publicó primero en Blog de SAP: Actualidad SAP, Business Intelligence, SAP HCM, Abap....

Uno de los objetivos fundamentales a la hora de que una empresa industrial implemente SAP PM como herramienta para gestionar el mantenimiento de su empresa es, generalmente, con el objetivo de analizar los costes totales que suponen el mantenimiento de la empresa, como parte auxiliar del proceso de producción.

Es por ello, que a la hora de crear una orden de mantenimiento de SAP PM es importante que tenga su integración con el módulo de costes en SAP (CO).

La gestión de mantenimiento de una empresa industrial pasa fundamentalmente por tener definida una correcta estructura de mantenimiento, es decir, tener bien determinadas las ubicaciones técnicas, los equipos, los puntos de medición y asignados los materiales, herramientas propias del módulo de mantenimiento PM.

A partir de aquí, al crear una orden de mantenimiento, el punto de integración de PM-CO es la pestaña “Control” de la propia orden de mantenimiento, donde deberá definirse el esquema de cálculo de coste necesario y propio de la empresa en la que se quiere implementar el módulo.

Es importante indicar que a nivel estándar existen diferentes esquemas de cálculo de coste, generalmente para definidos para el proceso de fabricación y no tanto para el propio proceso de mantenimiento. Es por ello, que será más adecuado por lo tanto, crear un esquema de cálculo de coste propio para la empresa, en función de sus necesidades y  según qué tipo de costes se quieran analizar, bien sea como un coste general de mantenimiento, ligado a un centro de coste único para mantenimiento, bien sea como análisis de coste por inversión, ligado a los bienes de equipo (activos fijos en el módulo FI), o bien sea como análisis de coste ligado al propio proceso de producción donde se pueda realizar un recargo del coste del producto fabricado en función de los mantenimientos que haya tenido el propio proceso de producción, por poner ejemplos..

En todo caso, sea cual sea el objetivo del reporting de costes de mantenimiento, la forma de conocer los costes totales en una orden de mantenimiento, según el criterio elegido, es decir, según el esquema de cálculo de coste que se haya asignado, se verá en la pestaña “Costes”, presionando sobre la pestaña “Informe pl./real”.

Este informe nos dará una visión de los costes incurridos en mantenimiento según el procedimiento establecido anteriormente en Controlling.

Esperamos que este artículo te haya resultado de ayuda si estás buscando conocer los costes del mantenimiento de planta. Si tienes alguna duda, puedes dejárnosla en comentarios. ¡Un saludo!

Área SAP Logística

La entrada Mantenimiento industrial con análisis de costes con SAP PM y SAP CO se publicó primero en Blog de SAP: Actualidad SAP, Business Intelligence, SAP HCM, Abap....

En esta serie que comenzamos con este artículo, vamos a explicar conceptos básicos técnicos acerca de las bases de datos relacionales en SAP, enfocándonos especialmente en aquellos que tienen relevancia y marcan la diferencia cuando se trata de bases de datos HANA.

En este primer artículo vamos a repasar las características generales de las bases de datos relacionales en SAP.

Una base de datos relacional consiste en una colección de registros (informaciones) guardados en tablas. Estas tablas habitualmente están interrelacionadas, de donde, aparece la característica epónima.

Características de las tablas de una base de datos relacional en SAP

Las tablas de una base de datos relacional tienen algunas características importantes:

• No hay importancia en el orden de las columnas o filas.
• Cada fila contiene uno y solo un valor para cada columna.
• Cada valor para una columna dada tiene el mismo tipo.
• Las tablas tienen una clave primaria.
• Las tablas están relacionadas por claves externas.
• Para la recuperación de los datos se utilizan las consultas.

Objetos de una base de datos relacional en SAP

1. Los índices

Utilizando índices en las tablas de la base de datos relacional, se permite el acceso más rápido a los registros.  La utilización de los índices mejora el rendimiento de la búsqueda en tablas con millones de registros.

2. Las vistas

Las vistas se definen como uniones de tablas y tienen como propósito la realización de informes.  Una vez que incrementa el número de tablas que se necesitan para el informe, el impacto acumulado en el rendimiento aumenta también. Para mejorar el acceso a la información, habitualmente las vistas se utilizan junto con los índices. Las vistas se pueden relacionar también en función de los permisos de usuarios y los grupos.

3. Usuarios y grupos

Se puede establecer permisos por cada usuario, de modo que la información confidencial se mantenga privada y se evite que los usuarios realicen cambios no autorizados. Los usuarios pueden asignarse a grupos para facilitar la administración de permisos.

4. Procedimientos

Los procedimientos son rutinas contenidas en la base de datos que actúan sobre la información en la base de datos.

Es posible crear y nombrar procedimientos almacenados propios para ejecutar consultas específicas de la base de datos y realizar otras tareas de la base de datos (análisis y manipulación masiva de datos que necesitan mucho rendimiento).

5. Objetos Java

Dentro del Diccionario ABAP (transacción: SE11), SOLO las tablas y las vistas de la base de datos tienen los objetos de la base de datos correspondientes. Los elementos de datos / estructuras / tipos de tabla solo tienen objetos de tiempo de ejecución, no existen objetos de base de datos para ellos.

Índices en bases de datos relacionales en SAP

Los índices pueden ser de dos tipos:

Primario

Está creado automáticamente cuando la tabla se crea en la base de datos y contiene los campos clave de la tabla y un puntero a los campos no clave de la tabla.

Secundario

Es necesario si se accede con frecuencia a la tabla de manera que no se aproveche la clasificación del índice primario para el acceso.

Un índice puede considerarse una copia de una tabla de base de datos que se ha reducido a ciertos campos, que está siempre ordenado y que asegura el acceso más rápido a los registros de datos de la tabla, por ejemplo, mediante un algoritmo de búsqueda binaria.

El optimizador del sistema de base de datos decide si se debe usar un índice al acceder a los datos de una tabla concreta.

Por ejemplo, si queremos buscar todos los aviones que llegan al aeropuerto NY-1 en una tabla con todas las rutas de los aviones del mundo, será necesario un índice para facilitar el acceso a los registros. En este caso, el aeropuerto podría ser o no una clave externa.

En el siguiente artículo de la serie, mezclaremos estos conceptos con las nuevas características de las bases de datos en HANA. ¡No te lo pierdas!

Área de User Experience & Integración

La entrada Conceptos básicos sobre BBDD SAP y HANA (Parte I) se publicó primero en Blog de SAP: Actualidad SAP, Business Intelligence, SAP HCM, Abap....

Los informes de partidas individuales en SAP FI permiten obtener un estado de cuentas analítico de las contabilizaciones y saldos. Desde este informe estándar se pueden visualizar partidas abiertas, compensadas, operaciones CME, documentos preliminares y apuntes estadísticos.

En algunos casos, puede ser conveniente añadir algún campo extra que nos proporcione información adicional como podrían ser las cuentas y/o el nombre de proveedor o cliente, o incluso información proveniente de otros módulos relacionados.

Con el objetivo de mostrar el nuevo campo deseado en cualquiera de las listas de partidas abiertas (FBL1N, FBL3N o FBL5N), debemos llevar a cabo una serie de configuraciones. En este caso vamos a utilizar una BTE.

Las BTE (Business Transactions Events) son un tipo de extensión para el módulo FI de SAP que permiten una personalización de componentes del sistema, añadiendo código propio en las transacciones estándar.

Antes de comenzar con la configuración de la BTE, debemos modificar las estructuras estándar involucradas en los reportes. Las estructuras son RFPOS y RFPOSX. Para ello accedemos a la transacción SE11, donde debemos añadir una estructura APPEND con el campo nuevo que queremos que se visualice en los informes.

Podemos personalizar el Dominio y el Elemento de Datos de manera que en los informes adaptados se muestre la descripción que más nos convenga.

Ejecutamos el report RFPOSXEXTEND para que los cambios se hagan efectivos.

Una vez hecho esto, pasamos configurar la BTE. Lo primordial es saber qué evento debemos usar para activar la BTE necesaria. Para ello accedemos a la transacción FIBF. Clicando en ENTORNO tendremos dos tipos de puntos: Módulos P/S (Publish and Subscribe) y Módulos de Operación.

En nuestro caso, utilizaremos un evento en un Módulo P/S, concretamente será el “00001650  VISUALIZACIÓN PI: Completar datos por posición”, que nos permite añadir campos en los informes de partidas individuales. Este evento utiliza el módulo de funciones “SAMPLE_INTERFACE_00001650”.

Establecemos un producto que nos permitirá identificar la modificación de la vista del evento con el campo añadido. Esto lo hacemos desde “Opciones > Productos > de un cliente”.

Creamos un módulo de funciones Z como copia del “SAMPLE_INTERFACE_00001650” y lo relacionamos con el evento en “Opciones > Modulos P/S > de un cliente” de la transacción FIBF. Este módulo de funciones contiene el código donde recogemos los datos necesarios para la personalización.

Tras realizar estos pasos, ya tendremos disponibles de los nuevos campos en los informes de partidas abiertas. Para visualizar el resultado basta con añadir el campo en el Layout del informe:

Esperamos que este artículo te haya resultado útil a la hora de añadir campos nuevos en los informes de partidas individuales. Recuerda que si tienes cualquier duda puedes dejarla en el apartado de comentarios.

En este videotutorial puedes ver el proceso para añadir campos adicionales a informes de partidas en SAP. 

Puedes explorar muchos más videotutoriales y webinars en nuestro canal de YouTube,

La entrada Añadir nuevos campos en los informes de partidas individuales de FI, utilizando BTEs se publicó primero en Blog de SAP: Actualidad SAP, Business Intelligence, SAP HCM, Abap....

En cualquier empresa industrial, la estructura del área comercial de ventas se distribuye en Ventas a nivel Nacional y ventas a Nivel Exportación.

Al realizar una factura de ventas, se puede indicar los portes de dicha factura a través de la transacción V -31 Crear Incoterms, parte 1 o también a través de la transacción V -32 Crear con modelo Incoterms, parte 1, de tal forma que se definen las diferentes tarifas para los distintos códigos de portes creados previamente en la parametrización:

Así, de tal forma que al crear el pedido de ventas, cuando se recoge el porte CIP, por ejemplo, al entrar en condiciones de pedido, en el nuevo esquema de cálculo, en el Porte (Clase de condición: KF00) ya se recoge automáticamente la tarifa recogida para ese tipo de porte:

En el caso de que se quiera registrar un tipo de porte propio de la empresa, que no está definido en SAP, será necesario previamente definir los tipos de Incoterms y asignarlos a las versiones de Incoterms e inclusive se puede asignar a una población concreta. La ruta para ello sería:

SPRO: Comercial-> Datos maestros -> Interlocutor comercial -> Clientes -> Incoterms

Este proceso es muy recomendable para empresas con gran volumen de exportación. 

Esperamos que te haya sido de utilidad. Te recordamos que puedes dejar tu pregunta en la zona de comentarios o ponerte en contacto con nuestro área de SAP Logística.

Área SAP Logística

La entrada Portes en SAP SD se publicó primero en Blog de SAP: Actualidad SAP, Business Intelligence, SAP HCM, Abap....

En el artículo anterior repasábamos los conceptos generales más importantes acerca de las bases de datos relacionales en SAP. En este segundo artículo vamos a concretar más, viendo cómo aplican (o no) estos conceptos en las bases de datos HANA.

Las bases de datos en HANA funcionan de manera diferente a las bases de datos clásicas porque las tablas están basadas en columnas y no en filas como las bases de datos tradicionales. Los campos de columna de la base de datos de HANA se comportan como si hubiéramos creado manualmente un índice en cada campo de la tabla, pero sin ningún costo / gasto / inconveniente de los índices secundarios. Esto significa que ya no tiene sentido utilizar los índices que explicábamos en el artículo anterior de la serie.

Sin embargo, se pueden crear índices en la base de datos de HANA mediante el comando CREAR ÍNDICE. Hay dos tipos de índices en HANA.

Índices en bases de datos HANA

1. Índice invertido: los índices invertidos se refieren a una sola columna. Aquí, los datos de índice se almacenan en estructuras de memoria interna que pertenecen a la columna respectiva.
2. Índice compuesto: los índices compuestos se refieren a más de una columna. Primero, el contenido de estas columnas se agrupa en una columna interna y luego se crea un índice invertido para esta columna interna.

Vistas en bases de datos HANA

Las vistas ABAP en el diccionario de datos son conjuntos de datos lógicos que contienen datos extraídos en una o más tablas como una sola entidad. Una vista en una o más tablas se refiere a que los datos de una vista no se almacenan físicamente como los datos que se derivan de una o más tablas.

En SAP se admiten cuatro tipos de vista diferentes. Estos difieren en la forma en que se implementa la vista y en los métodos permitidos para acceder a los datos de la vista.

1. Las vistas de la base de datos se implementan con una vista equivalente en la base de datos.
2. Las vistas de proyección se utilizan para ocultar los campos de una tabla (solo proyección).
3. Las vistas de ayuda se pueden utilizar como método de selección en las búsquedas de ayuda.
4. Las vistas de mantenimiento le permiten mantener los datos distribuidos en varias tablas para un objeto de aplicación a la vez.

Las vistas de la base de datos implementan una unión interna. Los otros tipos de vista implementan una unión externa.

En SAP sobre base de datos HANA existen dos maneras de utilizar las vistas de la base de datos:

1. Definirlas al nivel del diccionario ABAP
2. Definirlas al nivel de la base de datos.

ABAP CDS VIEWS

Las vistas de SAP ABAP CDS se definen en el nivel del servidor de aplicaciones ABAP. Las vistas se crean y mantienen en archivos DDL (lenguaje de definición de datos), que residen en el servidor de aplicaciones ABAP. Forman parte del Diccionario de datos (SE11) y, por lo tanto, forman parte del sistema de transporte ABAP, la gestión del ciclo de vida, etc.

Las vistas usan Open SQL y tienen como objetivo apoyar el desarrollo de aplicaciones ABAP. El tipo de sistema de base de datos es irrelevante: no tiene que ser una base de datos HANA. Por lo tanto, el enfoque principal de las vistas ABAP CDS es crear vistas.

HANA CDS VIEWS

Las vistas de CDS de SAP HANA se definen en el nivel de base de datos de HANA. Las vistas se crean y mantienen en archivos DDL, que residen en el nivel de la base de datos en HANA XS (HANA Extended Application Services). Las vistas usan SQL nativo y tienen como objetivo apoyar el desarrollo de las aplicaciones nativas de SAP HANA. Usan características que son específicas de SAP HANA. Por lo tanto, solo se pueden usar con una base de datos HANA. El enfoque principal de las vistas de CDS de HANA es crear modelos en la base de datos de HANA.

Aquí tenéis una referencia a un artículo anterior del blog de Oreka IT en el que hablamos sobre los CDS.

https://orekait.com/blog/sap-hana-core-data-services-y-sus-vistas/

¿Open SQL y Native SQL son excluyentes?

La respuesta es simplemente NO, porque tienen su propia identidad y propósito.

Open SQL consiste en un conjunto de sentencias ABAP que realizan operaciones en la base de datos central en SAP Web AS ABAP. Se llama OPEN porque es independiente de la base de datos. (Open = independiente de plataforma). En fondo, los programas Kernel están ocupados convirtiendo la declaración Open SQL en declaraciones SQL nativas para que la base de datos en uso entienda el lenguaje.

Open SQL solo puede funcionar con tablas de base de datos que se han creado en el Diccionario ABAP.

En SQL nativo, se puede utilizar principalmente instrucciones SQL específicas de la base de datos. La interfaz SQL nativa los envía tal cual al sistema de base de datos donde se ejecutan. Como no se utiliza nada definido en el diccionario de datos ABAP, las tablas que se necesitan pueden existir solo al nivel de base de datos, por lo tanto, SAP no tiene una herramienta para verificar la sintaxis de estas consultas.

Con esta última pregunta y respuesta, acabamos este segundo artículo de la serie. En el siguiente describiremos un ejemplo práctico de una vista CDS en HANA.

Si tienes preguntas puedes dejárnoslas en el espacio de preguntas. ¡Muchas gracias por leernos!

Área User Experience & Integración

La entrada Conceptos básicos sobre BBDD SAP y HANA (Parte II) se publicó primero en Blog de SAP: Actualidad SAP, Business Intelligence, SAP HCM, Abap....

A día de hoy, las Organizaciones diversifican sus procesos de capital monetario entre varias entidades financieras, siendo habitual contar con diversas cuentas bancarias y líneas de crédito, que a su vez generan gran volumen de movimientos diariamente.

Que dicha información sobre los extractos bancarios se integre diariamente en la contabilidad financiera de la organización de manera fiable, temprana y automática es un proceso empresarial clave.

La conciliación bancaria es precisamente el proceso que equipara cada movimiento de la cuenta corriente bancaria con cada partida de la cuenta mayor de contabilidad financiera correspondiente:

SAP cuenta con la herramienta Electronic Bank Statement, que permite una conciliación automática de extracto con cuenta de mayor bancaria.

Una vez cargado el extracto en SAP, ya sea carga manual (transacción FF_5) o automática, EBS permite:

• Generar las contabilizaciones automáticas en cuentas de mayor,
• Compensar facturas abiertas tanto de cliente como de proveedor,
• Identificar registros del extracto que ya han sido contabilizados previamente en la contabilidad bancaria, evitando su doble contabilización.

En este proceso, gran parte de las líneas del Extracto se conciliarán de manera automática. No obstante, se requerirá intervención manual de usuario para líneas que el sistema no consiga interpretar de manera unívoca su contabilización. En el siguiente ejemplo se pretende ilustrar de manera general los status tras el proceso de conciliación automática:

El Cockpit de Posiciones de Extracto de SAP se compone de dos áreas de trabajo:

• Área de registros del extracto: presenta a modo de listado todos los registros del extracto,
  • Presenta el status de conciliación individual
  • Incorpora bloqueos por tratamiento
  • Navegabilidad al documento original de extracto bancario, tanto al extracto completo como únicamente a la línea concreta
  • Filtrado para mostrar solamente partidas con status de conciliación pendiente (rojo)
• Área de tratamiento individual de cada registro: muestra los parámetros de conciliación bancario de cada registro
  • Presenta el documento contable creado automáticamente
  • Permite una conciliación manual sin salir del monitor:
    • Contabilización en cuenta de mayor
    • Compensación de partida abierta de proveedor
    • Compensación de partida abierta de cliente
  • Se puede anular el documento generado y después volver a contabilizar

De la misma manera, la activación del SAP BCM en nuestro sistema permite el acceso al Monitor de Extractos Bancarios (Bank Statement Monitor – BSM), teniendo la información sobre la conciliación del último extracto bancario de todos nuestros bancos propios en un mismo punto:

El monitor BSM aporta la siguiente información acerca de un extracto concreto procedente de una cuenta bancaria específica:

• Banco propio + ID cuenta
• Código Bancario + Cuenta Bancaria
• Cuenta contable en la contabilidad financiera perteneciente al banco
• Número y fecha de extracto
• Importes inicial y final del extracto
• Importe final de la cuenta de mayor asociada a la cuenta bancaria
• Importe diferencial entre saldo final del extracto y saldo final de cuenta contable
• Status de proceso: ¿Existe alguna partida pendiente de conciliar?
• Status de diferencia: ¿Existe diferencia entre el saldo final de extracto y el saldo final de conciliación más allá de la tolerancia permitida?

Entre las funcionalidades del monitor BSM, se encuentra la de navegabilidad a Cockpit de Posiciones de Extracto para tratar la conciliación de sus líneas.

Para una carga de extracto de manera totalmente automática en SAP, es imprescindible que nuestra organización cuente con una licencia de pasarela de pagos (por ejemplo, SWIFT o EDITRAN), además de un servicio de comunicación en SAP cómo SAP PI o SAP CLOUD PLATFORM (aunque el servicio de comunicación se podría sustituir mediante código ABAP),

Una solución alternativa a licencias adicionales en el proceso de carga de extracto bancario, requiriendo como única tarea manual la descarga del fichero de extracto desde la web de la entidad financiera, es el flujo presentado a continuación:

De esta manera, podemos conseguir un proceso de carga de extracto muy automatizado, con una conciliación totalmente automática, sin incurrir en costes adicionales de licencias.

Esperamos que este artículo te haya ayudado a conocer un poco más el proceso de conciliación bancaria en SAP. Puedes dejarnos tus preguntas aquí debajo o ponerte en contacto con nosotros si estás interesad@ en implantar esta herramienta en tu empresa.

Área SAP Finanzas & Controlling

La entrada SAP Extracto Bancario: Carga y Conciliación Bancaria se publicó primero en Blog de SAP: Actualidad SAP, Business Intelligence, SAP HCM, Abap....

Si para toda empresa (ya sea B2B o B2C) el cliente es, o debiera ser, la piedra angular de su negocio, el área funcional encargada de trabajar en la relación con ellos tendría que ser gestionada de la forma más óptima y eficiente posible. Si tenemos en cuenta, además, que no debiera ponerse el foco únicamente en el cliente consolidado, si no también en los posibles clientes potenciales y en las personas que de algún modo han mostrado interés por los productos o servicios de nuestra empresa, esta función se va complicando más y más. Y si a esto le añadimos que hay organizaciones cuya principal fuente de negocio son su fuerza de ventas, y que, por tanto, cuentan con cientos o miles de representantes o vendedores, la necesidad de contar con un software informático que apoye esta tarea es totalmente inevitable.

Tradicionalmente, el seguimiento de la relación con los clientes se ha llevado a través de programas de CRM (Customer Relationship Managment). Aunque muchas de las soluciones de CRM que podemos encontrar en el mercado han evolucionado para incorporar distintas funcionalidades y niveles de alcance, las nuevas formas de comprar e interactuar con empresas han hecho necesario que este tipo de programas recojan también los datos no sólo de las compras de un cliente, si no también de sus interacciones mediante llamadas, emails, redes sociales, estadísticas en la tienda online, o aperturas de un boletín de noticias, entre otras muchas. Para dar una respuesta de 360º a la gestión integral de la relación con el cliente (y clientes potenciales) SAP lanza su propio portfolio de soluciones: SAP C/4HANA.

¿Qué es SAP C/4HANA?

Como hemos comentado, hoy en día una solución para gestionar la relación con el cliente debe abarcar mucho más que un mero seguimiento de las visitas, las ofertas o las ventas relacionadas con él. Podemos (y debemos) obtener mucha más información de las innumerables fuentes de datos de las que puede disponer una empresa hoy en día. Es por esto que SAP C/4HANA, suite desarrollada tras la adquisición de Hybris por parte de SAP, se compone de cinco soluciones distintas, totalmente relacionadas e integrables entre sí. Todas son soluciones cloud alojadas en servidores mantenidos y gestionados por el fabricante.

SAP SALES CLOUD

Gestor de la fuerza de ventas de la organización. Esta solución permite gestionar los datos de los clientes, los de los representantes o vendedores, así como las oportunidades y las ofertas de ventas. Permite también el seguimiento por áreas geográficas o unidades de venta, además de aportar análisis predictivos y detallados de las ventas, márgenes, campañas de ventas, etc.

Pueden crearse ofertas de venta o presupuestos directamente desde la herramienta, y realizar el seguimiento del estado del mismo. También permite implementar procesos de aprobación internos antes de enviar la oferta al cliente, o visualizar la agenda de los comerciales de nuestro equipo.

En conclusión, y simplificando mucho todas las funcionalidades que ofrece, permite llevar un seguimiento íntegro de la vida de un cliente, desde el primer contacto, hasta las ventas y ofertas que se le han presentado, así como realizar recomendaciones de productos o servicios según el histórico de cada cliente.

Cuenta además con aplicación de dispositivos móviles para que los vendedores puedan realizar el registro de sus visitas de forma rápida, así como de integración con herramientas Microsoft Office para la gestión de datos (Excel) o de sincronización de emails (Outlook).

SAP SERVICE CLOUD

Solución para la gestión integral del servicio postventa o servicio de atención al cliente, desde la propia interfaz de Sales Cloud. Permite realizar todo el proceso de ticketing de la empresa, desde la apertura de la incidencia al cierre de la misma, pasando por la gestión de contratos, cláusulas, periodos de validez, etc. Todo ello, recibiendo el feed-back del cliente en todo momento.

Entre otras muchas funcionalidades, integra las incidencias recogidas desde varios canales como mensajes en redes sociales, llamadas o emails, y redistribuirlas de la forma más eficiente entre el equipo de asistencia. Toda la información del histórico del cliente está al alcance de la mano, rápida y fácilmente, para poder ofrecer el mejor servicio postventa posible. También permite integrar IA conversacional para automatizar distintas acciones.

SAP MARKETING CLOUD

Solución para crear y gestionar las acciones de marketing online y campañas de ventas de la organización. Utiliza todas las interacciones que un cliente/contacto ha tenido con la empresa para realizar nuevas campañas de marketing, de forma que pueda realizarse un seguimiento oportuno que acabe convirtiendo las interacciones desconocidas en clientes. En otras palabras, una solución para conseguir la conversión de interacciones anónimas en clientes efectivos. Permite realizar distintas campañas basadas en envío de mails, llamadas, sms,… totalmente segmentadas, de acuerdo a distintos perfiles, y con informes de seguimiento y rendimientos detallados de cada una de ellas. Como hemos comentado antes, todas estas soluciones están muy relacionadas entre sí, en este caso, trayendo desde otras de las soluciones de C/4HANA todos los datos asociados a la vida de un cliente y presentarlos de forma global. A mayor cantidad de datos, mayor capacidad de segmentación, y por tanto, de diseñar la mejor campaña posible, la que puede convertir de forma más efectiva un posible interés en una venta.

SAP COMMERCE CLOUD

Solución destinada a desarrollar y mantener de forma rápida y eficiente comercios online capaces de gestionar pedidos y pagos, programar envíos, y ofrecer contenido personalizado a cada visitante, gracias a los datos obtenidos de SAP Marketing Cloud.

Ofrece “disparadores” adaptados a distintos sectores e industrias para poner en marcha lo más rápido posible el e-commerce.

SAP CUSTOMER DATA CLOUD

La última de las soluciones que componen la suite de SAP C/4HANA, pero ni mucho menos la menos importante. Esta solución es la base del proceso que hemos comentado anteriormente en la solución SAP Marketing Cloud. Aquí se almacenan todas las interacciones de clientes conocidos o desconocidos (mediante la asignación de IDs) con el objetivo de explotarlos en otras soluciones como Marketing o Commerce Cloud y convertirlos en contactos conocidos y con la mayor cantidad de datos asociados posibles. Podría decirse que es la capa “base” del resto de nubes, siendo capaz de asociar a una ID de contacto todos los datos provenientes de ellas.

Gracias a la integración con el resto de soluciones, puede facilitar el registro de nuevos contactos mediante, por ejemplo, suscripciones a newsletters o novedades desde el sitio web, incluso facilitando el registro desde perfiles de redes sociales, que recaban mucha más información del contacto.

Otro de los aspectos más interesantes de esta solución es la gestión y almacenamiento de permisos de comunicación, que ayuda a la empresa a adecuarse y cumplir la nueva ley de protección de datos (RGPD) aplicable en todo Europa. Si bien el resto de soluciones ofrece cierta funcionalidad en este aspecto, esta herramienta es la estrella para la gestión de permisos de contacto y borrado de datos a petición del interesado.

Se compone de tres grandes paquetes de funcionalidades:

• Customer Identity: identificación de interacciones anónimas en “buyer-persona” conocidos o semi-conocidos.
• Customer profile: creación de perfiles de audiencia
• Customer consent: mantenimiento de permisos de comunicación

Y si son soluciones cloud,… ¿puedo integrarlo con mi ERP on-premise?

Por supuesto. Todas estas soluciones, como hemos comentado, se alojan en servidores gestionados por el fabricante, pero, evidentemente, ofrecen distintas herramientas para establecer integraciones bidireccionales entre los datos registrados en la nube y el sistema SAP on-premise. Así, por ejemplo, puede alimentarse la lista de precios, productos o empleados de SAP Sales Cloud, o Marketing Cloud, con los datos disponibles en nuestro sistema. Y de vuelta, pueden actualizarse los maestros de clientes desde los datos mantenidos en las soluciones del portfolio C/4HANA.

En este artículo hemos hecho una aproximación muy general a SAP C/4HANA, y las soluciones cloud de las que se componte. Estas soluciones se adquieren e implementan de forma independiente las unas de las otras. En próximas publicaciones ampliaremos información de cada una de ellas.

Si estás interesad@ en adoptar alguna de estas soluciones para mejorar la fuerza de ventas de tu empresa, puedes ponerte en contacto con nuestro departamento de Customer Experience.

Área Customer Experience

La entrada ¿Qué es SAP C/4 HANA? La suite de CUSTOMER EXPERIENCE de SAP se publicó primero en Blog de SAP: Actualidad SAP, Business Intelligence, SAP HCM, Abap....

Diseñador de temas de “UI Theme Designer” o lo que es lo mismo “Diseñador de temas de Interfaz de Usuario”. Con esta herramienta de SAP, se puede crear y diseñar un tema personalizado adecuado a las necesidades del usuario. Se puede trasladar su Identidad Visual Corporativa de una forma profesional modificando las plantillas de temas proporcionadas por SAP.

Un tema personalizado es básicamente un tema nuevo creado a partir de un tema estándar de SAP que incluye cambios en base a la apariencia visual que necesita el cliente.

Para todo este cambio deberíamos tener unas nociones básicas sobre Diseño de Interfaz de usuario (también llamado Diseño UI) ya que se deben tener en cuenta varios conceptos como el tamaño y el tipo de letra, las imágenes de fondo y los colores de los controles. El tema definirá la apariencia visual de una aplicación que posiblemente un usuario va a utilizar a diario, así que es importante que tenga una apariencia limpia y consistente esto ayudara a los usuarios a concentrarse. Hablaremos más sobre Diseño UI en los próximos artículos del blog.

La entrada Videotutorial: SAP UI Theme Designer se publicó primero en Blog de SAP: Actualidad SAP, Business Intelligence, SAP HCM, Abap....

Cuando ejecutamos el MRP Live on HANA en nuestro sistema, tenemos la necesidad de conocer qué materiales se han planificado y la forma en que se han planificado dichos materiales.

Por medio del siguiente informe, podemos informarnos y configurar la forma de planificar materiales en MRP on HANA:

“Información y configuración de materiales en MRP en HANA” – Transacción: “md_mrp_force_classic”.

Este informe muestra todos los materiales que tienen vistas de MRP activas en el maestro de materiales y proporciona información sobre cómo se planificaron en la última ejecución de MRP Live.

Para cada material planificado en MRP Live (Transacción MD01N), enumera si se incluyó en la ejecución MRP Live on HANA, o en la ejecución MRP Clásica, o si ni siquiera se ha incluido en la planificación. Proporciona también la información sobre la limitación que evita que un material se incluya en la ejecución en MRP Live on HANA.

La clase de planificación del material depende de si es necesario para ello el tratamiento de una función determinada que no es permitida hasta entonces en la ejecución en MRP Live on HANA. Si es así, el material se tiene automáticamente en cuenta en la planificación de necesidades de material “Clásica”.

También nos proporciona información sobre la fecha y hora de la última ejecución de planificación e informa del último mensaje de texto que fue emitido por el sistema para los materiales en la última ejecución de planificación.

Utilización del informe

Por medio de la siguiente pantalla introducimos nuestra selección. Como resultado se muestra la siguiente información:

Inicialmente podemos realizar las siguientes acciones:

•  Cambiar de modo Visualizar a modo Modificar, y viceversa.

•  Resolver problema.

Seleccionando una única línea, navega a una pantalla en la que puede tratar el material para ir a la función determinada que no soporta MRP Live on HANA. En caso de que no exista ninguna solución estándar para solucionar el problema, el sistema muestra el mensaje correspondiente.

• Información sobre el último mensaje de texto de la ultima ejecución del MRP Live on HANA.

Para ello debe seleccionar una única línea.

Si cambiamos al modo Modificar, nos permite realizar las acciones siguientes:

• Seleccione previamente las líneas y haga clic en esta opción, si desea que en vez de MRP Live on HANA se planifique por MRP “Clásico”.

Mejora el rendimiento de MRP Live en SAP HANA, por ejemplo, para los materiales que, debido a una determinada limitación, no se pueden planificar en la ejecución en MRP Live on HANA.

En la siguiente ejecución de la planificación, el sistema planifica automáticamente el material con la lógica de planificación de necesidades de material “Clásica”.

Utilice esta opción para materiales que necesiten modificaciones en la lógica de planificación de BADIs. Para ello, verifique qué materiales requieren el tratamiento de una BADI durante la ejecución MRP y fije para estos materiales el indicador “Planificar siempre en planificación de necesidades de material Clásica”.

• Seleccione previamente las líneas y haga clic en esta opción, si desea anular/borrar el indicador “Planificar siempre en planificación de necesidades de material Clásica”.

• Seleccione previamente las líneas y haga clic en esta opción para permitir si se debe visualizar un material en las aplicaciones para la planificación de necesidades de material.

El sistema verificará automáticamente esta información si accede por primera vez a las aplicaciones y se graba en el campo “Material visualizado en aplicaciones MRP”.
Si modifica manualmente los datos maestros de un material, para que se incluyan en MRP Live on HANA, podrá indicarle al sistema que verifique si el material se visualiza ahora automáticamente en las aplicaciones MRP a causa de las modificaciones realizadas, por medio de esta a acción.

Esperamos que este artículo te haya sido de ayuda si estás trabajando en informar y configurar la forma de planificar materiales en MRP on HANA. Puedes dejarnos tus preguntas en comentarios, o ponerte en contacto con nuestro área de SAP Logística si estás interesad@ en implementar esta funcionalidad a tu sistema SAP.

Área SAP Logística

La entrada Información y parametrizaciones para materiales en MRP en HANA se publicó primero en Blog de SAP: Actualidad SAP, Business Intelligence, SAP HCM, Abap....

Como ya sabréis, existen modelos de funciones que se pueden aprovechar en diferentes puntos del código ABAP, de esta forma se simplifica una parte del programa, que suele ser algo más compleja, y se mejora el rendimiento de los programas. Los modelos de funciones pueden ser propios del sistema o bien programas propios de usuario (tipo “Z”).

En este caso vamos a hablar de la función “CSAP_MAT_BOM_READ” propia del sistema, que sirve para generar diferentes modelos de tablas de las Listas de Materiales (BOM).

Esto se debe a que hay varias tablas de las que podemos obtener información relevante a las BOM (Listas de Material), pero que a su vez no dan toda la información necesaria como la que puede llegar a proporcionar una transacción.

Los parámetros de entrada a proporcionar a la función son:

Como parámetro de salida (EXPORT) la función nos devolverá una estructura para indicar si la información requerida se ha encontrado o no, con algún tipo de mensaje de advertencia informando respecto si no ha podido ser obtenida o proporcionada al usuario.

Ahora bien, por otro, lado disponemos de múltiples tablas de salida que nos proporcionaran una amplia información, ya que incluyen múltiples campos que de por si las tablas propias del sistema no nos aportan.

Destacaremos estas dos primeras tablas de salida de las múltiples tablas que nos facilita esta función:

Me gustaría destacar que gran parte de la información proporcionada por estas tablas y en particular la primera, la podemos obtener por código a través de diferentes SELECTS a tablas de Base de Datos, pero concretamente hay un campo que a mi parecer es muy interesante ya que no existe como tal en ninguna tabla estándar:

El campo ”Valid_To – Fecha fin de validez”, es facilitado por la transacción ”CS03 – Visualización de Lista de Materiales”, indica la fecha hasta cuando un componente/material es válido para una lista de materiales, ya sea porque se ha modificado su cantidad a utilizar o porque ha sido sustituido por otro componente/material en su lugar.

Para comprender el porqué de la relevancia de esta función y sobre todo de este campo tenemos que ir a la tabla

STPO – Componentes lista materiales

Aquí podemos ver, que para la lista de materiales ”000033” en su posición ”80” tenemos diferentes componentes que entran y salen en la producción del material.

Para ver la importancia de la función destacaremos que en ningún momento se proporciona en esta tabla (ni en ninguna otra) la fecha de fin de validez de cada componente.

Para saber cuál es la fecha de fin de validez tenemos que comparar los Nodos y Contador de cada Componente (Comp.) con el Nodo Predecesor (NodPred) y Contador de las siguientes líneas de la misma posición:

-En caso de coincidencia resulta que la Fecha de Fin de Validez (Valid_To) de ese componente es la fecha de Inicio de Validez (Válido de) del siguiente componente o línea coincidente.  

-Si no existe coincidencia la Fecha de Fin de Validez (Valid_To) del componente es por defecto “31.12.9999”.

Como podemos observar la operativa (programación) para obtener esta información puede ser relativamente compleja (con la comparativa de nodos, contadores y fechas de diferentes líneas), por ello al utilizar esta función haciendo referencia directa a la tabla ”STPO” nos facilita estos datos directamente desde la tabla interna de salida (T_STPO) para la utilización posterior en nuestro programa.

Ejemplo en CS03 de los datos de la tabla STPO mostrada anteriormente

Cabe destacar que aparte de este dato de fecha fin de validez podemos obtener, en cada una de las líneas o registros, diferentes datos de utilidad como el código del propio componente, la cantidad empleada del mismo, unidades de medida, números de modificación… y otra serie de datos relevantes que podemos utilizar dependiendo de los requerimientos del programa del usuario.

Esperamos que este artículo te haya sido de utilidad. Recuerda que puedes dejarnos tus preguntas en comentarios o ponerte en contacto con nuestro departamento de SAP Logística.

Área SAP Logística

La entrada Función para la visualización de las listas de materiales se publicó primero en Blog de SAP: Actualidad SAP, Business Intelligence, SAP HCM, Abap....

Como ya comentamos en un artículo anterior, SAP ha lanzado toda una suite de soluciones para optimizar la experiencia del cliente, denominada C/4HANA. Junto a Service Cloud, Marketing Cloud, Commerce Cloud y Customer Data Cloud, SAP Sales Cloud completa este grupo de soluciones ofreciendo un potentísimo CRM. En este artículo comentaremos las principales características y funcionalidades que esta herramienta puede ofrecernos, y que iremos ampliando en futuros artículos.

¿Qué es SAP Sales Cloud?

Empecemos por el principio. Es posible que este nombre no te diga nada, pero si alguna vez te has acercado mínimamente al sector de las ventas o has trabajado de comercial, seguro que conoces el concepto de CRM. Los CRM son softwares destinado a gestionar la relación con nuestros clientes. Así, sirven para almacenar toda la información relevante de las cuentas de cliente que nos puedan ayudar a realizar mejores y más rápidas ventas en el futuro. Históricos, datos de contacto, intereses, oportunidades aceptadas o rechazadas, etc.

Si bien SAP ya contaba con una herramienta de este tipo para los sistemas on-premise, SAP Sales Cloud viene a sustituir esta herramienta por una mucho más potente, mejorada, y que se aloja en servidores gestionados por el fabricante. Es decir, es una de las últimas soluciones cloud ofrecida por SAP.

Esta herramienta, en conjunto con el resto de soluciones de la suite, pretende cubrir todo el ciclo lead-to-cash del ciclo de ventas. Es decir, todo el proceso desde un cliente potencial a la venta final.

¿Qué funcionalidades nos ofrece SAP Sales Cloud?

Sería imposible tratar todas las posibilidades que nos ofrece esta herramienta en un sólo artículo. Por hoy, y al tratarse de un primer acercamiento a la herramienta, vamos a comentar las principales y más básicas funcionalidades que podemos obtener.

• Gestión de maestros de cliente: en esta solución podemos crear y gestionar los datos maestros de los clientes. Datos de contacto, de facturación, de la entidad, etc. Nos ofrece la posibilidad de consultar y modificar los datos de las cuentas de cliente de una forma rápida y muy intuitiva.
• Gestión de leads: no todos los contactos que podemos tener en la empresa son clientes consolidados. Y tampoco deberíamos caer en el error de registrar un cliente potencial en nuestra base de datos de clientes consolidados. Para ello tenemos el concepto de “lead”, es decir, distintos contactos que de alguna forma u otra pueden convertirse en posibles ventas, y por tanto, en futuros clientes. Para ello, SAP Sales Cloud cuenta con un registro distinto al de la cuenta de clientes, que pueden convertirse fácilmente en cuentas consolidadas si finalmente se llega a la venta.
• Creación y gestión de ofertas y oportunidades: pueden crearse oportunidades y ofertas directamente desde la herramienta, además de realizarse todo el seguimiento de la misma. Gracias a la cantidad de variables que pueden registrarse, es posible detectar anomalías o fallos en el proceso de venta que nos permitan optimizar futuras oportunidades y mejorar nuestro ratio de conversión. Con SAP Sales Cloud pueden generarse directamente documentos de ofertas de ventas, esto es, presupuestos. Para ofertas de ventas más complejas, debería integrarse esta solución con SAP Callidus Cloud.
• Seguimiento de visitas, llamadas, y otros contactos: esta solución permite la creación de visitas comerciales y planificar y registrar llamadas telefónicas. Ofrece además vistas de tipo calendario para nuestras propias tareas o ver las de nuestro equipo, con las que ver la planificación semanal, por ejemplo, de nuestro equipo de ventas. Ofrece también la posibilidad de configurar las tareas que debemos realizar en cada visita. Por ejemplo, podemos crear una lista de tareas para nuestra fuerza comercial que le recuerde que tiene que mencionar una promoción específica, u ofrecer una encuesta de satisfacción. Así, se optimizar cada visita comercial.
• Gestión de datos de socios comerciales y empleados: esta herramienta también nos permite gestionar otro tipo de partners que podamos tener en nuestro proceso de venta, como socios comerciales o nuestros propios comerciales.
• Gestión y mantenimiento de productos, precios y descuentos, en caso de no alimentarse de los datos de nuestro sistema on-premise.
• Flujos de aprobación: pueden establecerse flujos de aprobación de ofertas para evitar que los comerciales cometan errores o apliquen descuentos excesivos. Así, sus responsables directos o superiores pueden aprobar las ofertas antes de mandarlas al cliente final.
• Campañas de ventas: podemos establecer distintos objetivos de ventas para las distintas áreas comerciales de nuestra empresa, así como diseñar campañas de envío masivo de emails o llamadas. En este aspecto, es importante mencionar que las funcionalidades para realizar campañas de ventas son suficientes para las necesidades básicas que puede tener un departamento de ventas y/o marketing, pero si se necesita tener una funcionalidad avanzada, SAP Marketing Cloud se integraría con los datos de cliente de SAP Sales Cloud para realizar campañas de ventas avanzadas.
• Analítica: esta herramienta ofrece una potente funcionalidad para la creación de informes y gráficos basados en los datos del CRM. Estos informes pueden generarse de una forma muy sencilla por parte del usuario final, con herramientas de drag-and-drop. También pueden crearse KPIs personalizados, dashboards, etc. No obstante, para informes avanzados y/o analíticas más complejas, la integración con SAP Analytics Cloud es muy simple y rápida.
• Gestión de permisos RGPD: desde la entrada en vigor de la nueva Ley de Protección de Datos, por la que es obligatorio tener el consentimiento expreso y registrado de nuestros contactos para las comunicaciones comerciales, es indispensable que nuestro CRM pueda gestionar y almacenar estos permisos. SAP Sales Cloud ofrece las funcionalidades básicas de gestión y modificación de permisos de contacto, de cara a realizar campañas o contactos para ventas sujetos a la normativa. No obstante, para obtener la funcionalidad total en este aspecto, SAP ofrece su solución Customer Data Cloud. 
• Gestión de roles de usuarios: definición de permisos y vistas para distintos tipos de usuarios.

¿Qué integraciones nos ofrece con otras herramientas?

SAP Sales Cloud puede conectarse con un sinfín de soluciones SAP y no SAP. Una de las conexiones más interesantes puede ser la que ofrece, de forma nativa y muy fácil de configurar, con herramientas de Microsoft Office. Por ejemplo, puede conectarse con Outlook para sincronizar contactos, visitas del calendario, registros de envío de email, etc. También ofrece conexión con Microsoft Excel para configurar informes, objetivos de ventas, etc.

Todas las soluciones de la suite de C/4HANA son fácilmente integrables entre sí, de forma que tengamos todos los datos de las distintas soluciones disponibles en las demás, y evitemos así duplicidades en los datos de clientes, contactos, etc.

SAP ofrece también conectores para integrar los datos de nuestro sistema on-premise con la nube, de forma que podamos tener los datos de nuestros clientes correctamente mantenidos, podamos traer los datos de productos y costes al CRM, etc.

No podemos contarlo como una integración o conexión, pero no podemos pasar por alto que SAP Sales Cloud ofrece una aplicación móvil disponible en los principales market places (Android e IOs) con las que llevar las funcionalidades más básicas de este CRM en nuestro dispositivo móvil. Así, no tendremos que esperar a estar frente al ordenador para registrar nuestra última visita o guardar un nuevo contacto. Ofrece también posibilidad de trabajar sin conexión y sincronizar los datos a posteriori.

¿….y qué interfaz nos ofrece?

Es posible que a estas alturas te estés preguntando: muy bien, teóricamente lo tenemos pero, ¿cómo se trabaja con él? Vamos a dejar aquí las vistas más habituales de la herramienta. Como verás, toda la interfaz es totalmente visual e intuitiva, basada en Fiori. Además, puede configurarse a la imagen corporativa de la empresa usuaria.

• Dashboard inicial: pueden configurarse distintas fichas y vistas de usuario

• Vista de calendario:

• Vista de mapa:

• Listado clientes:

• Vista informes:

• Vista app móvil:

Esperamos que este artículo te haya servido para conocer un poco más las solución de CRM en la nube de SAP, Sales Cloud. En futuras entregas abordaremos funcionalidades y tutoriales más específicos sobre esta herramienta, así como la personalización y ampliación del producto estándar.

Si estás interesad@ en implementar esta herramienta en tu empresa, puedes ponerte en contacto con nuestro área de Customer Experience.

Área Customer Experience

La entrada SAP Sales Cloud: la solución CRM de SAP en la nube se publicó primero en Blog de SAP: Actualidad SAP, Business Intelligence, SAP HCM, Abap....

En Agosto de 2019 dábamos de alta a nuestro empleado en SuccessFactors, Borja Luque. Tal y como vemos en su perfil de empleado.

Nada más proceder a su contratación, se generaba automáticamente un contingente de ausencias por vacaciones, es de decir, una bolsa de horas que se calculaba tomando como referencia la fecha última del año 31.12.XXXX y la fecha de contratación.

Vemos que su Validez de cuenta, es decir, su periodo de liquidación del contingente tenía una validez hasta final de año.

Tomó 10:48 horas de vacaciones, y aún le quedan pendientes 32 horas generadas en 2019.

Un momento, ¿dices que generó 32 horas en 2019 habiendo sido contratado en Agosto del mismo año?. Sí, sí, pero es que las reglas de acumulaciones las definimos nosotros mismo desde la transacción de business rule y, si, les pusimos a los empleados un contingente la mar de generoso.

Sin embargo, hemos decidido dejar de ser tan buenos y bajar dicho contingente de generación a 2,5 días por mes.

En detalles de cuenta de tiempo, podemos ver, la acumulación de la propia cuenta, es decir, la generación del propio contingente y, las ausencias que ha ido solicitando el propio empleado a lo largo del año.

Nos parece un poco injusto que, llegado el 01.01.2020, las horas que teníamos acumuladas hayan “desaparecido”, bueno, esa no es la palabra ya que hemos visto que siguen ahí, simplemente, no podemos utilizarlas.

Llegados a este punto, nos vemos forzados a hablar de: Time Off Period End Processing o Procesamiento del final de periodo para el tiempo libre si no nos gustan los anglicismos.

¿Y qué es esto? Pues es un término usado en SuccessFactors Employee Central Time Management que nos ayuda a tratar con las actividades de final de año para trasladarlas al siguiente periodo.

1. Nos permite trasladar los saldos de cuentas de tiempo antiguas (como la de arriba) a cuentas de tiempo nuevas.
2. Nos permite cerrar las cuentas cuya validez hay expirado.

Primer Paso: Creamos una PEP rule.

Empleando un poco de lógica, esta regla nos permitirá llevar los saldos de una cuenta obsoleta a una nueva y cerrar la primera.

Resumimos la lógica de la “Business Rule”:

La primera condición if controla si existe una nueva cuenta de tiempos de transferencia de saldos. Si la respuesta es “no”, actualizamos el saldo pendiente de la cuenta, creando un nuevo detalle que lleve el balance a cero (21:12 horas, en este caso). A parte, se cierra la cuenta existente.

Si la condición es “si”, la lógica de la regla, pondrá el saldo de la cuenta antigua a cero, la cerrará y trasladará el saldo a la nueva cuenta. Ojo, creando un detalle de cuenta, es decir, un registro y no, la cuenta persé.

Segundo Paso: Añadimos la regla al tipo de cuenta de tiempo.

Tercer Paso: Creamos una nueva cuenta de tiempo

Podríamos crear una cuenta a través de una regla automática o manualmente, en este caso, la hemos creado manualmente.

Cuarto paso: Simulación y ejecución PEP

Desde la transacción de Generación de calendarios de tiempo libre podemos simular y procesar la regla PEP que acabamos de crear.

Simulamos nuestra ejecución y nos da error:

Para consultar el error, podemos acudir a nuestro email (Siempre y cuando hayamos configurado un workflow ).

El error nos comenta que no podemos cerrar la cuenta por un error en la evaluación de tiempos, ya que éste empleado tiene imputaciones sin aprobar/enviar para determinados periodos. Además vemos que no se ha generado ningún saldo disponible.

Dicho esto, tendremos que corregir las imputaciones del tiempos del empleado y relanzar la evaluación de tiempos.

Tal y cómo vemos a continuación lanzamos y autorizamos, los tiempos de nuestro empleado:

Lanzamos y simulamos nuestros calendarios para generar la nueva cuenta de tiempo y cerrar la antigua. Vemos en el log que nos arroja es el correcto:

Por lo que ejecutamos en real:

Vemos como, si vamos a las cuentas de tiempo de nuestro empleado, se ha generado una publicación de cuenta:

Esperamos que este artículo sobre la gestión de saldos en la evaluación de tiempos de SAP SuccessFactors te haya resultado de interés. Puedes dejar tus preguntas en comentarios y las atenderemos lo más rápido posible. Si estás interesad@ en implementar SuccessFactors en la gestión de RRHH de tu empresa, puedes ponerte en contacto con nuestro departamento de SAP RRHH:

Área SAP RRHH

La entrada Evaluación de tiempos en SAP SuccessFactors: gestión de saldo se publicó primero en Blog de SAP: Actualidad SAP, Business Intelligence, SAP HCM, Abap....

Demo sobre SAP SuccessFactors, solución en la nube para el talento de SAP, donde vemos la gestión del rendimiento y objetivos.

La entrada SAP SuccessFactors: performance & goals DEMO se publicó primero en Blog de SAP: Actualidad SAP, Business Intelligence, SAP HCM, Abap....

Tras la teoría expuesta en los dos artículos anteriores sobre bases de datos relacionales en SAP y su aplicación en bases de datos HANA, vamos con este tercer y último artículo en el que vamos a exponer un caso práctico de vista CDS en HANA consumida desde una aplicación SAPUI5.

Conceptos básicos sobre BBDD SAP y HANA (Parte I)

Conceptos básicos sobre BBDD SAP y HANA (Parte II)

Objetivo

Para este ejemplo práctico hemos pensado crear una aplicación que muestre las ventajas de las vistas CDS HANA a través de las funciones nativas SQL y del servicio oData que tienen por defecto. Para cumplir nuestro objetivo necesitamos crear la vista y la aplicación, interconectándolas a través de un servicio oData para acabar mostrando un listado con el contenido de nuestra vista CDS HANA (en este caso, los detalles de todas las compañías de aerolíneas).

Creación de la vista CDS en HANA

Creamos la vista CDS en HANA y añadimos la anotación @OData.publish: true

Activación del servicio OData

Ejecutamos la transacción /IWFND/MAINT_SERVICE y buscamos por el nombre de nuestra vista CDS para activar/añadir el servicio y cargar los metadatos.

Creación de la app SAPUI5

Para facilitar las cosas, utilizamos una plantilla SAPUI5 y creamos una aplicación sencilla para la visualización de los datos.

Establecemos la conexión con el servicio oData.

Mapeamos los elementos de la lista con el EntitySet ZCDS_VIEW.

Si ejecutamos la aplicación, ya podemos visualizar los datos.

En nuestro ejemplo, hemos utilizado una vista CDS HANA, lo que significa que en la consulta Select podemos incluir funciones específicas SQL como UPPER, LPAD, RPAD etc.

Cambiando en mayúsculas el nombre de la compañía, con la función UPPER en la vista CDS, obtenemos:

De esta manera, podemos cambiar los datos mostrados en función de necesidades sin pasar por todos los registros devueltos para actualizarlos, como debería hacer después de una consulta OPEN SQL.

Conclusiones

Como hemos visto, las vistas tienen el propósito de facilitar la creación de los informes complejos, tras el análisis de un montón de datos interdependientes, por lo tanto, será suficiente solamente ver estos resultados. Si miramos en esquema del servicio creado no se permite la manipulación de los datos.

En caso de necesitar la actualización, creación o eliminación de ciertos registros, será necesario crear otro servicio oData que ofrezca la posibilidad de crear un EntityType con el tipo del @AbapCatalog.sqlViewName (en nuestro caso: ‘ZCDS_VIEW_N’).

Además, se puede aprovechar y redefinir, en función de las necesidades, las funciones CRUD (Create, Read, Update, Delete) del proprio EntitySet ya creado.

Por otro lado, las vistas CDS permiten la visualización de los datos en función de los permisos de cada usuario, grupo de usuario u otros parámetros, manteniendo el acceso controlado a los datos confidenciales

Con esto, hemos visto desde la teoría a la práctica las características más importantes de las bases de datos en SAP y en HANA y cómo pueden ser útiles para ser utilizadas en las aplicaciones de negocio que queramos desarrollar.

Puedes dejarnos tus preguntas en comentarios o ponerte en contacto con nuestro departamento de User Experience & Integration.

User Experience & Integration

La entrada Conceptos básicos sobre BBDD SAP y HANA (Parte III) se publicó primero en Blog de SAP: Actualidad SAP, Business Intelligence, SAP HCM, Abap....

En un artículo anterior, os hacíamos tanto una presentación general de la suite C/4HANA de SAP (orientada a la gestión de la experiencia del clientes), así como una primera aproximación a una de las soluciones que la componen: SAP Sales Cloud, el nuevo CRM de SAP en la nube.

Como ya comentamos en ese artículo, a lo largo de varias entregas vamos a centrarnos en esta solución, enseñando tanto las funcionalidades básicas como algún tip que os ayude a adaptar la herramienta desde la propia interfaz. Hoy, vamos a mostrar lo que podríamos considerar una de las bases de esta herramienta: el proceso que abarca  el registro de un lead, hasta la conversión en cuenta consolidada. Pero, antes de nada, una aclaración de términos teóricos:

• Lead: nuevo contacto que no está asociado a un cliente o cuenta ya existente en la empresa, y que puede suponer una posible oportunidad de venta. Es decir, serían aquellos contactos que podemos conseguir, por ejemplo, en ferias, reuniones, networkings, campañas de comunicación… que en cierta medida creemos que pueden tener alguna posibilidad de convertirse en una venta.
• Cliente: cuenta en la que ya hemos realizado alguna venta o presentado alguna oferta de venta. Estas directrices pueden parametrizarse de distintas formas, pero, por establecer un criterio válido para muchos casos, una vez entregada una oferta de ventas, ese lead pasa a ser un “Cliente potencial” y, en el caso de que acabe aceptando la oferta, se pasará a “Cliente”.

Una vez convertido un lead en una cuenta de cliente, este lead no podrá volver a editarse, por lo que las futuras modificaciones deberán hacerse directamente desde el sub-apartado “Resumen” o “Contactos” de la cuenta. Dentro de cada cliente, podremos ver los leads que están relacionados, así como ver dentro de cada lead su proceso de conversión a cliente.

CÓMO CREAR UN LEAD

Los leads se gestionan en el centro de trabajo “Ventas”, bajo el aparado “Leads”. No confundir con el sub-apartado “Leads de ventas” que ya desde versiones anteriores se marca como “obsoleto” y no se recomienda su uso.

En este apartado, nos encontraremos con un listado de los leads que se han registrado. Pueden consultarse los leads creados por el usuario, por su equipo, y una lista completa de todos los registrados.

Podemos acceder a la consulta o edición de cada uno de ellos desde el nombre del lead resaltado en otro color. En la parte de abajo a la izquierda, encontramos el siguiente icono  que usaremos para crear nuevos leads.

Es importante recordar que los campos y opciones que ofrece el formulario de creación de contactos es personalizable, por lo que los campos y las obligatoriedades que aquí mostramos son sólo un ejemplo.

Una vez que aportamos la información que tenemos y/o necesitamos del lead, podemos crearlo con el botón  . Este botón tiene una opción desplegable que nos permitiría sólo grabar, guardar y abrir (para insertar información ya desde la propia ficha del lead), o guardar y abrir uno nuevo (para guardar el lead actual y pasar directamente a un nuevo formulario de creación).

Es interesante, si el proyecto de implementación lo contempla, conocer la opción , con la que la herramienta hace una revisión de posibles contactos o leads duplicados en función de la sensibilidad que se  configure. Así, evitamos que haya duplicidades en los registros.

Uno de los aspectos fundamentales para la gestión de los leads es establecer correcto sistema de calificación de estados de los mismos. Según los estados que configuremos, las acciones que se pueden realizar con ellos son distintas. Así, por ejemplo, estableciendo un estado inicial de “Sin cualificar”, la gestión del lead no nos permitirá otra cosa que no sea completar datos hasta que consideremos que está apto para ser “Cualificado”. Las fases de cualificación pueden ser varias, y sólo algunas permitirán la conversión a cuenta u oportunidad. Como hemos comentado antes, una vez que se clasifique bajo el estado que permite la conversión, no podremos volver a modificarlo. Trataremos más a fondo la configuración de los estados de los leads en futuros artículos.

GESTIONAR LEADS

Una vez que se ha creado un lead, podemos acceder a la siguiente vista donde, por medio del icono del lápiz de la parte inferior izquierda, podremos editar los datos.

Las distintas pestañas nos ofrecen vistas de varios datos. Pueden habilitarse varias pestañas así que éstas son sólo algunas de ellas.

• Resumen: datos generales del lead.
• Feed: un tablón con las actualizaciones y modificaciones del objeto.
• Actividades: llamadas, citas o correos electrónicos asociados a este lead.
• Productos: productos o servicios en los que este lead podría estar interesado.
• Conversión: cuenta cliente y/o oportunidad con la que se ha realizado el proceso de conversión.
• Anexos
• Notas

CONVERTIR UN LEAD

Lo primero de todo, el lead debe estar en un estado que nos permita ser convertido. En es momento, el botón “Acciones” de la parte inferior derecha ofrecerá distintas opciones para ser convertido, como, por ejemplo, “Convertir en cliente” o “Asociar cliente”, esta última para asociar este lead con una cuenta de cliente que ya existe previamente, ya que, de lo contrario, se nos abrirá el cuadro de diálogo para crear una cuenta nueva.

CREAR UN CLIENTE NUEVO DESDE UN LEAD

Si elegimos la opción “Convertir en cliente”, se abrirá un cuadro de diálogo similar a la siguiente vista:

Como puede observarse, también hace una verificación de duplicados para evitar la creación de nuevas cuentas de cliente por duplicado, ya que el borrado de datos en Sales Cloud es limitado, y en muchas ocasiones sólo puede marcarse como “Bloqueado” u “Obsoleto”.

Grabamos, y accedemos al centro de trabajo “Clientes”.

Esta vista ofrece una lista de las cuentas de clientes, donde ya debería aparecer la que acabamos de convertir desde el lead.

Dentro de cada cliente, podemos ver distintas opciones, en las que profundizaremos en otros artículos. La pestaña que ahora mismo más nos interesaría sería la del “Rol”, donde definiremos si se trata de un cliente potencial o de un cliente consolidado u obsoleto.

Podremos considerar, aunque esto va en función de la situación de cada empresa, que un cliente potencial es aquel al que se le ha presentado una oferta de ventas, y un cliente consolidado aquel que la ha ofertado y por tanto, tendrá una facturación asociada.

Por último, y como comentábamos en las vistas de sub-menú de los leads, podemos ver la relación de conversión que se ha producido en un lead en el apartado “Conversión”.

Este es el proceso general para registrar nuevos leads y convertirlos en clientes en SAP Sales Cloud. Esperamos que os haya servido de ayuda, y recordad, que podéis dejarnos vuestras preguntas en el apartado de comentarios.

Si estás interesad@ en esta solución, puedes contactar con nuestro departamento de Customer Experince.

Área Customer Experience

La entrada SAP SALES CLOUD – Convertir un lead en cliente, proceso completo se publicó primero en Blog de SAP: Actualidad SAP, Business Intelligence, SAP HCM, Abap....

En 2021 entra en vigor TicketBAI en los Territorios Forales de Bizkaia, Gipuzkoa y Araba. El objetivo de TicketBAI es la lucha contra el fraude con los siguientes mecanismos:

• Aumentar el control sobre los ingresos generados por los negocios a través de pagos en efectivo.
• Proteger la competencia y, de paso, crear oportunidades de negocio.
• Asegurar una tributación acorde con los ingresos de cada organización, garantizando la legalidad de las declaraciones.
• Favorecer la protección y defensa del consumidor mediante la entrega obligatoria de un ticket por cada compra realizada.
• Reducir los costes del cumplimiento fiscal
• Proteger al consumidor

Para las organizaciones cuya competencia inspectora se encuentra en alguno de estos territorios, nacen nuevos requerimientos a la hora de emitir facturas y tickets y reportar la información de los mismos a la Agencia Tributaria correspondiente.

Todas las facturas emitidas deberán informarse de manera telemática

Los sistemas de la organización deberán adaptarse para el envío de cada factura vía fichero XML de manera individualizada.

Adicionalmente, cada factura deberá firmarse mediante certificado electrónico para dotar de seguridad al proceso. Serán validos los certificados de dispositivo, de representante de entidad jurídica o de persona física, sellos de empresa y certificados de autónomo. Adicionalmente, el encadenamiento de facturas requerido en el XML buscará que ninguna factura emitida quede sin declarar.

En el impreso de la Factura o Ticket, se deberá incorporar un Código QR

Las Facturas Emitidas deberán ser impresas en términos TicketBAI, incorporando Código QR TicketBAI e Identificativo TicketBAI. Todo dispositivo usado por la organización para emitir facturas o tickets, ya sea ordenador personal, TPV, tabletas etc. deberá incorporar el código QR correspondiente en cada documento.

El Código QR podrá ser escaneado mediante lector QR, y proporcionará la información de cómo la factura consultada se ha informado en la Agencia Tributaria:

Bizkaia BATUZ

En Bizkaia, conteniendo a TicketBAI, la iniciativa BATUZ también va a requerir el envío de todos los movimientos contables de la organización de manera telemática a Sede Electrónica de DFB tras el cierre del ejercicio.

De esta manera, Bizkaia proporcionará borradores de:

• IVA
• IRPF
• IS

Para todos los contribuyentes, a partir del año 2021.

Si tienes alguna pregunta sobre este nuevo requerimiento, o quieres saber cómo cumplirlo en tu empresa, no dudes en ponerte en contacto con nosotros. Podemos ayudarte con la adaptación de tus ERP SAP ya se trate de una gran empresa o PYME.

Área SAP Finanzas

La entrada TicketBAI entrará en vigor en el 2021 en la CAV se publicó primero en Blog de SAP: Actualidad SAP, Business Intelligence, SAP HCM, Abap....