Empezando con S4/HANA. Business Partner (BP).

En las entradas publicadas en el blog normalmente hablamos de funcionalidad de la versión ECC del ERP de SAP (6.0 EHPX, antes llamado R3). Hace unos meses hablamos de los cambios más relevantes que nos podemos encontrar en el nuevo sistema S/4HANA y la forma de acceder a un sistema Cloud gratuito de demostración que ofrece SAP (ver post aquí).

Hoy vamos a dar un salto adelante y vamos a empezar a descubrir en detalle los cambios que nos encontraremos cuando decidamos migrar nuestro sistema al nuevo S/4HANA o cuando nos encontremos en un proyecto de implantación con la nueva versión.

En concreto, vamos a hablar de unos de los cambios más importantes y que más afecta a la parte de Gestión de Materiales (MM) o Ventas (SD), los Business Partners.

Antes de entrar en materia, os recomiendo leer y conocer las llamadas Simplification Lists. Es un documento donde Sap nos detalla toda la funcionalidad liberada en cada versión de S/4HANA. Allí se enumeran desde las transacciones que desaparecen en la nueva versión, cambios en los modelos de datos, nueva funcionalidad liberada o cambios respecto a las versiones anteriores, detalle de notas asociadas a cada punto, etc. La relacionada con la versión 1909 tiene más de 1000 páginas, todo un reto para entender todas las implicaciones a las que nos vamos a tener que enfrentar en un proyecto de migración o una nueva implantación.

Business Partner Approach

En las versiones anteriores manteníamos los datos de nuestros clientes o proveedores en diferentes transacciones (FKXX/MKXX/XKXX para proveedores o FDXX/VDXX/XDXX para clientes), cada una con sus respectivas tablas según el ámbito organizativo de los datos (LFA1/LFB1/LFM1 para proveedores, entre otras o KNA1/KNB1/KNVV para clientes). Ademas de otros objetos de negocio como podían ser unidades organizativas, personas, etc.

En S/4HANA se sustituye este enfoque y pasamos al objeto BUSINESS PARTNER como elemento centralizado donde se realizará toda la gestión de datos maestros asociados a los clientes y proveedores.

BP_013

Con el nuevo enfoque tenemos un único elemento organizativo (el Business Partner), al cual le podemos asignar diferentes roles según la relación que tengamos con el en nuestra organización. Por ejemplo, un empresa con la que trabajemos estará creada una única vez, pero podrá desempeñar el rol de cliente, de proveedor, etc. Esto nos permite trabajar con datos compartidos y unificados (datos de direcciones, contacto, datos bancarios), así como datos específicos asignados a cada rol (cliente en finanzas, cliente en ventas, proveedor en finanzas, proveedor en compras).

BP_004

Ademas, con la utilización de este elemento central se solucionan limitaciones que teníamos en el antiguo ERP como:

Definición de varias direcciones, cada una de ellas con un uso concreto.
Validez temporal de los elementos (direcciones, datos bancarios).

BP_001

Ampliación de la información disponible en los datos maestros (por ejemplo, identificadores fiscales según el país).
Definición de múltiples relaciones con el mismo BP.
Máximo grado de compartición de datos maestros y su reutilización.

En S/4HANA, las transacciones clásicas desaparecen y cuando las utilicemos, el sistema nos redireccionará a la transacción BP.

Usando el mismo BP, y asignándole los correspondiente roles, podremos tener un cliente para Finanzas (rol FLCU00 FI Customer) o para utilizar en el módulo de SD (rol FLCU01 Customer para ventas).

BP_002

O un proveedor (roles FLVN00 FI Vendor para ser utilizando en Finanzas y el rol FLVN01 Vendor para los datos de compras).

Funcionalidad.

A nivel funcional, la nueva transacción BP es bastante diferente a las clásicas que utilizabamos en la versión anterior. Cuando vayamos a crear un nuevo interlocutor (cliente o proveedor), lo primero que hacemos es crearlo de forma general, indicando que vamos a crear una organización y el BP role “000000 Business Partner (Gen)”.

BP_007

Es algo parecido a la creación de datos generales (a nivel de mandante) para un cliente o proveedor (direcciones, identificación fiscal, cuentas bancarias, etc).

Importante: en el campo Grouping indicaremos el valor que determinará la numeración del objeto (internamente también determinará el grupo de cuentas que se utilizará para la creación del interlocutor).

A continuación, una vez grabados los datos y asignada la numeración, podremos pasar a la ampliación del interlocutor con los diferentes roles. Entraremos en la transacción de nuevo en modo Update e indicaremos el nuevo rol que vamos a crear. Por ejemplo, con el rol FLCU00 FI Customer, crearemos los datos de Finanzas.

BP_008

Estos datos los tendremos a nivel de sociedad. Los mismo posteriormente si queremos crear las vistas de venta, con el rol FLCU01 Customer.

BP_009

Los datos requeridos en cada una de las secciones pueden variar según el BP role seleccionado. De esta forma, habremos creado el cliente y lo tendremos listo para utilizar tanto en finanzas (FI) como en ventas (SD).

Implicaciones técnicas.

La primera sorpresa, aparte de los cambios en la funcionalidad más que evidentes, es a nivel técnico. Resulta que el uso de los BP no implica la desaparición de los antiguas tablas de datos de clientes y proveedores, que se mantienen a nivel técnico por requisitos de compatibilidad y funcionamiento de los diferentes módulos (MM,SD, etc).

Para mantener este funcionamiento y que todo sea totalmente transparente para el usuario, Sap ha desarrollado lo que llama el Customer Vendor Interface (CVI), que permite, de forma automática, mantener la información en las tablas clásicas a partir de la información introducida en los Business Partner. Toda una sorpresa.

BP_012

Esto significa que, al dar de alta o modificar los datos existentes en un BP, automáticamente se actualizaran las correspondientes tablas de proveedores o clientes preexistentes.

A nivel de tablas, tendremos la información de los Business Parters en tablas BUTXX, pero seguiremos teniendo nuestras queridas KNA1, KNB1, KNVV o LFA1, LFB1 o LFM1.

BP_005

El CVI requiere una parametrización para definir las equivalencias entre los BP Grouping (es el elemento que nos permite realizar la numeración de los business partners y que se indica al crearlos), con los grupos de cuentas que utilizábamos en las transacciones clásicas de R3 al crear un cliente o proveedor.

BP_006

Habrá que alinear la numeración del BP definida a traves del Grouping con la numeración asignada en los Grupos de cuentas (esto puede ser un tema bastante complicado en una migración desde un sistema previo con miles de clientes o proveedores ya definidos).

BP_010

En la parametrización de la integración, asignamos al “Grouping” utilizado en el BP, el correspondiente “Account group” (grupo de cuentas), utilizado anteriormente al crear los clientes. Tanto para clientes, como proveedores (ver imagen siguiente).

BP_011

En el apartado de bibliografía os he dejado al documento HANA Cookbook Customer Vendor Integration (CVI), y el BP_Conversion_Activities_Document, donde se explica en detalle esta integración y la forma de configurarla.

Nota: la misma herramienta CVI nos permite preparar el upgrade a S/4HANA, de forma que cuando creemos un cliente o proveedor de la manera tradicional, el sistema creará automáticamente el BP asociado (para el periodo de transición antes de la migración y como una tarea necesaria dentro de este proceso). Y ya tendremos realizado uno de los pasos a realizar en la migración de forma previa.

Autorizaciones.

Además, tendremos que ajustar todos nuestros roles de autorización para trabajar con los nuevos objetos. Se mantendrán las autorizaciones clásicas para la compatibilidad con el antiguo modelo de datos, pero a su vez tendremos que habilitar acceso a las funciones de la BP con los objetos:

B_BUPA_GRP – Authorization Groups: podremos utilizar estar autorización para indicar que Business Parters podran ser editados por el usuario en base al valor del campo “Authorization Group” dentro de los datos maestros. Por ejemplo, a todos los BP que le hayamos puesto el valor “GROUP” (empresas del grupo), solo podran ser matenidos con los usuarios que tenga este objeto con dicho valor.
B_BUPA_ATT – Authorization Types: utilizando esta autorización, podemos definir que BP pueden ser mantenidos por el usuario, dependiendo de los valores de determinados campos. En la parametrización definiremos los nombres de los “Authorization types” y los campos que podrán ser utilizados para el chequeo.
B_BUPA_FDG – Field Groups: con esta autorización indicamos que grupos de campos y con que actividades pueden ser gestionados por el usuario (visualizados o modificados).
B_BUPA_RLT – BP Roles: con este objeto de autorización vamos a indicar que BP roles podrán ser editados por el usuario.

Como podéis comprobar, el irnos a S/4Hana no va a ser un camino fácil ni es un simple cambio de nombre. Vamos a prepararnos para muchos cambios.