Conversión Business Partners - Brownfield S/4 HANA

Uno de los stopper más comunes que muestra la ejecución del Simplification Item Check antes de iniciar el proceso de conversión de un sistema ECC a S/4 HANA, es la obligatoriedad de convertir los de clientes y proveedores a la figura de Business Partner o Interlocutor Comercial (a partir de ahora BP).

Resultado de la ejecución del programa Simplification Item Check

Como la palabra stopper indica, es obligatorio realizar esta conversión como requisito previo, y precisa de un análisis para ver qué escenario encaja mejor en nuestro cliente a futuro.

En base a nuestra experiencia, los factores que más influyen a la hora de encarar esta conversión son dos: el Modelo actual y la Calidad del dato. 
 

1. Modelo actual

En primer lugar, debemos de analizar cómo es el modelo actual de gestión de terceros. En base a esta premisa, son varios los puntos donde tenemos que hacer foco:
 

1.1.   Grupos de cuentas de clientes y proveedores

Los grupos de cuentas clasifican a los terceros existentes en el sistema, y debemos de establecer una analogía entre el grupo de cuentas del tercero y la agrupación comercial de nuestro futuro BP, pues será el punto de partida a definir de la parametrización.

Por tanto, para tomar esta decisión debemos involucrar a nuestro cliente; puesto que él sabrá mejor que nadie que grupos de cuentas puedan estar obsoletos, si se pueden establecer sinergias entre dos grupos de cuentas, si queremos conservar la numeración del cliente por delante de la del proveedor o viceversa, etc.
 

1.2.   Geografías

Uno de los puntos necesarios es la configuración de BP es el número de identificación fiscal. Cuando mayor sea el número de países en nuestro maestro, más complejo será la parametrización a nivel de número de identificación fiscal y, por ende, las posibles validaciones existentes en los desarrollos actuales.
 

1.3.   Customización

No es extraño encontrarnos en nuestro modelo actual la inclusión de campos a medida en el maestro. Esto es un factor a tener en cuenta puesto que tendremos que crear esos campos en el maestro de BP. (recordemos que las transacciones habituales de clientes y proveedores están obsoletas en S/4 HANA).
 

1.4.   Integraciones y desarrollos a medida

Es muy habitual que nuestro cliente tenga procesos desde los cuales se gestione la creación y modificación de terceros mediante las transacciones XD*, XK*, FD* y FK*.

Con la conversión a S/4 HANA, estas transacciones pasarán a estar obsoletas, de forma que redirige al usuario de forma automática a la transacción BP. Esto hace imperativo revisar y adaptar todos los procesos de creación/modificación/visualización que contengan un call transaction a cualquiera de estas transacciones (estos puntos de conflicto se pueden extraer con la ejecución del ATC - Abap Test Cockpit). En resumen, será necesario eliminar estos batch input y sustituirlos por un proceso de creación del BP y del cliente/proveedor mediante bapis y funciones estándar.

Resultado de la ejecución del ATC

2. Calidad del dato

Es evidente que cuanto más limpio esté nuestro maestro menos errores se producirán en el proceso de conversión. Campos como el código postal o el mail pasarán a validarse a la hora de ejecutar el cockpit de creación de BPs.

Sin embargo, el punto más crítico en cuando a calidad del dato, será cuando nos encontremos clientes y proveedores con un mismo NIF/CIF. Por defecto, ese cliente y proveedor confluirá en un único BP, por lo que es necesario que los datos de nombre, dirección, cuentas bancarias, etc. sean exactamente los mismos.

Llegados a este punto, podemos involucrar al cliente para que sea el mismo el que depure el maestro, o por el contrario nos deberá de indicar que maestro prevalecerá sobre cual.

Lecciones aprendidas

Cuentas bancarias

Como se ha comentado en el apartado anterior, la sincronización de datos entre un cliente y un proveedor con un mismo NIF/CIF es obligatoria. Por tanto, las cuentas bancarias que existan en ambos maestros deberán de ser unificadas:

a) Cuentas que estén en el cliente y que no están en el proveedor, y viceversa.

b) El orden y el ID de cada cuenta deberá de coincidir.

Este último ajuste puede provocar que se paguen/cobren partidas abiertas en cuentas que no toca. Por ejemplo: supongamos que tenemos una partida de cliente con ID 0001 y que en su maestro apuntase a la cuenta XXXX originalmente. Si tras realizar la unificación de cuentas con su proveedor asociado, el ID 0001 pasa a apuntar a la cuenta YYYY, estaremos realizando el cobro en una cuenta diferente a la inicial.
 

Rangos de números

Una vez realizado el proceso de conversión, verificaremos que tendremos BPs cuya numeración no coincide con su cliente y/o proveedor asociado. Esto es un gap con el que se tendrá que convivir, pero si se puede evitar en los nuevos BPs que se creen tras la conversión. Para ello, debemos de unificar los rangos de números de BP, cliente y proveedor para que las tres figuras compartan el mismo número; aunque sea necesario realizar un salto de numeración en alguno de los tres rangos.