Business Partner en S/4HANA: qué cambia y dónde se rompe la calidad

En SAP S/4HANA, cliente y proveedor pasan a ser roles de un único objeto, el Business Partner (BP), y todos los registros maestros de clientes y proveedores deben convertirse en BP como requisito previo de la conversión del ERP. Los datos generales se comparten entre roles, el BP se convierte en la puerta de entrada y la integración CVI sincroniza las tablas anteriores. La calidad se rompe en las decisiones que nadie tomó antes de la conversión: qué unificar, quién es dueño de los datos compartidos, cómo numerar y qué dejar fuera.

"Toma los clientes y los proveedores y pásalos al S/4."

Escuché variaciones de esa frase muchas veces en los años en que implementé SAP. Quien ya abrió la transacción BP después de una conversión hecha así conoce la escena: la misma empresa aparece dos veces, una desde ventas y otra desde compras, con direcciones distintas, y nadie sabe decir cuál es la correcta. El sistema hizo lo que se le pidió. La decisión fue la que quedó para después.

Este artículo es para quienes van a pasar de SAP ECC a SAP S/4HANA, o ya están en S/4HANA y sufren con los datos maestros de BP. Voy a separar tres cosas: lo que SAP documenta, mi lectura operativa y lo que recomiendo decidir antes. Algunos ejemplos vienen de Brasil, donde trabajo, y explicaré el contexto local cuando haga falta.

¿Qué es el Business Partner en SAP S/4HANA?

Según SAP, el Business Partner es el objeto central de datos maestros para todas las personas físicas y jurídicas con las que la empresa tiene una relación de negocio. La definición está en la lección "Creating Business Partners" del curso de compras en SAP S/4HANA de SAP Learning. La misma lección indica que el BP se mantiene con la transacción BP o con las apps correspondientes del SAP Fiori launchpad.

SAP también es clara sobre el requisito previo: en un proyecto de conversión de SAP ERP a SAP S/4HANA, todos los registros maestros de clientes y proveedores del sistema deben convertirse en Business Partners. Eso está en la lección "Working with Business Partners", también de SAP Learning.

Si quiere repasar los términos de datos maestros antes de seguir, el glosario de 4MDG le ayuda.

¿Qué cambia en los datos maestros de clientes y proveedores?

Cambia la lógica del registro. En ECC, clientes y proveedores eran registros separados, mantenidos con las transacciones antiguas de cliente y de proveedor. En S/4HANA, la empresa se registra una sola vez como BP y recibe roles. Estos son los puntos que SAP documenta.

Los datos generales se comparten

SAP afirma que los datos generales de un Business Partner se comparten entre los distintos roles, como cliente y proveedor. Nombre, dirección e identificación pasan a ser un único registro para ventas y para compras.

Un BP puede tener varios roles

Un mismo BP puede tener roles como Customer, FI Customer y Vendor. Del lado de compras, SAP menciona los roles Supplier (FLVN01) y FI Vendor (FLVN00). Los datos del proveedor están en tres niveles: generales (nivel de mandante), contables (sociedad) y de compras (organización de compras).

La categoría define los campos

La categoría del BP (persona, organización o grupo) define qué campos están disponibles. Cargar un registro con la categoría equivocada no es solo una etiqueta mal puesta: cambia lo que se puede completar.

Varias direcciones y dependencia temporal

En ERP 6.0 había una dirección por registro maestro. Para el BP, SAP documenta la posibilidad de tener varias direcciones y el soporte de dependencia temporal para atributos y relaciones.

Numeración, agrupaciones y el mismo número

Según la lección "Manage Customer/Vendor Integration", las agrupaciones de BP determinan los rangos de numeración. Los grupos de cuentas de cliente y proveedor deben vincularse a las agrupaciones de BP. Los rangos pueden ser internos o externos, y existe la opción "same number" para mantener el mismo número en el BP y en el cliente o proveedor. La asignación es uno a uno: cada cliente o proveedor corresponde a un BP, y un cliente y un proveedor también pueden asignarse al mismo BP.

El BP es la puerta de entrada y la CVI sincroniza

La Customer/Vendor Integration (CVI) garantiza que, cuando se crea o modifica un BP, las tablas de cliente y proveedor se actualizan automáticamente. Usted mantiene el BP y el sistema completa y sincroniza los campos necesarios en el registro de cliente o proveedor correspondiente.

Las interfaces externas cambian de destino

SAP indica que las aplicaciones externas deben usar el módulo RFC RFC_CVI_EI_INBOUND_MAIN para crear y actualizar Business Partners. Toda interfaz que antes escribía directamente en cliente o proveedor debe revisarse.

¿Dónde se rompe la calidad en la conversión a BP?

De aquí en adelante es lectura operativa, no documentación de SAP. Son siete puntos donde la falta de decisión suele aparecer después de la salida en vivo, sobre todo con datos maestros de Brasil.

1. La misma empresa como cliente y como proveedor

Muchas empresas compran y venden al mismo socio. En ECC, eso solía generar dos registros. Como los datos generales del BP se comparten entre roles, lo natural sería un BP con dos roles. Si nadie decide unificarlos, termina con dos BP para la misma empresa, cada uno con su dirección y su historial. En Brasil, la clave común suele ser el CNPJ, el número del registro nacional de personas jurídicas que asigna la administración tributaria federal brasileña (Receita Federal).

2. Casa matriz y sucursales

En Brasil, cada establecimiento tiene su propio CNPJ. La casa matriz y las sucursales comparten la raíz (los ocho primeros caracteres) y cada una tiene su número de orden. La pregunta que hay que responder antes de la carga es: ¿un BP por establecimiento u otro modelo? Esa elección afecta la facturación, la recepción fiscal y los informes. No hay una respuesta única, pero tiene que haber una decisión por escrito.

3. Quién es dueño de los datos generales compartidos

Si la dirección y los datos fiscales son un único registro, compras y ventas pasan a modificar lo mismo. Sin un dueño definido, el comprador corrige la dirección de entrega pensando en el proveedor y cambia lo que facturación usa para el cliente. Es un punto que suele generar conflictos entre áreas.

4. Numeración y agrupaciones frente a los grupos de cuentas antiguos

Los grupos de cuentas de ECC deben vincularse a agrupaciones de BP. Si los grupos antiguos se crearon sin criterio a lo largo de los años, ese mapeo hereda el desorden. Y la decisión de mantener o no el mismo número afecta informes, interfaces y la costumbre de los usuarios.

5. Registros inactivos y bloqueados

SAP exige que todos los registros de clientes y proveedores del sistema se conviertan. Por eso es aún más importante tratar antes de la conversión los registros que no deberían seguir vivos: proveedores sin movimiento desde hace años, clientes bloqueados, registros creados por error. Mi recomendación es tratar en ECC lo que se pueda archivar, con un criterio documentado, y no cargarlo como si estuviera activo.

6. Interfaces que escribían directamente en cliente y proveedor

Portal de proveedores, CRM, comercio electrónico, herramientas de homologación. Todo lo que creaba o modificaba clientes y proveedores desde fuera ahora debe entrar por el BP. SAP indica RFC_CVI_EI_INBOUND_MAIN para eso. Una interfaz olvidada significa registros que entran sin reglas.

7. CNPJ alfanumérico (solo Brasil)

Esta regla aplica únicamente en Brasil. La Receita Federal estableció que, a partir de julio de 2026, el CNPJ alfanumérico rige exclusivamente para nuevas inscripciones, según la IN RFB nº 2.229/2024. El CNPJ mantiene 14 posiciones: 8 de la raíz, 4 del orden y 2 dígitos verificadores. Quienes ya están inscritos conservan su número. La propia Receita Federal orienta a las empresas a adaptar sus sistemas. Para los datos maestros de BP, mi recomendación es revisar campos, validaciones y programas a medida que tratan el CNPJ como número antes de que la conversión consolide esas reglas.

¿Qué decidir antes de la conversión y quién decide?

La siguiente tabla es un resumen de trabajo. La columna "quién decide" es una sugerencia; cada empresa la ajusta a su estructura.

Punto de ruptura	Qué pasa si nadie decide	Qué decidir antes	Quién decide
Misma empresa como cliente y proveedor	Dos BP para una misma empresa	Regla de unificación y qué registro prevalece en los datos generales	Datos maestros, con ventas y compras
Casa matriz y sucursales	Modelos distintos para casos iguales	Un BP por establecimiento u otro modelo, por escrito	Datos maestros, área fiscal y arquitectura SAP
Datos generales compartidos	Un área modifica lo que otra utiliza	Dueño de cada grupo de campos y flujo de modificación	Gobierno de datos con las áreas
Numeración y agrupaciones	Grupos antiguos sin criterio se vuelven agrupaciones sin criterio	Mapa de grupos de cuentas a agrupaciones de BP y uso de "same number"	Arquitectura SAP con datos maestros
Inactivos y bloqueados	Registros sin uso convertidos como si estuvieran activos	Criterio de inactividad y qué tratar antes en ECC	Datos maestros, finanzas y compras
Interfaces externas	Registros que entran por fuera del BP	Inventario de interfaces y ajuste para crear y modificar por el BP	TI e integración
CNPJ alfanumérico (Brasil)	Una validación a medida rechaza o corrompe el identificador	Revisión de campos, validaciones y programas que tratan el CNPJ	TI, área fiscal y datos maestros

Lista de verificación de limpieza

• Listar los identificadores fiscales que aparecen como cliente y como proveedor a la vez.
• Agrupar los registros por raíz del CNPJ y revisar casa matriz y sucursales.
• Validar razón social, dirección, inscripción estatal (registro tributario estatal de Brasil) y situación registral en fuentes oficiales.
• Estandarizar dirección, nombre y campos fiscales que se compartirán entre roles.
• Definir el criterio de inactividad y separar lo que no debe seguir activo.
• Mapear grupos de cuentas a agrupaciones de BP y decidir sobre el mismo número.
• Inventariar las interfaces que escriben en clientes y proveedores.
• Revisar campos y validaciones a medida del CNPJ.
• Medir la calidad antes y después, con los mismos indicadores.

Sobre el último punto, escribí cómo construir esa línea base en cómo medir la calidad de los datos maestros.

¿Cómo se ve esto en un caso hipotético?

El siguiente ejemplo es hipotético. La empresa es ficticia y los números redondos son solo ilustrativos.

Distribuidora Ejemplo tiene en ECC 10.000 clientes y 4.000 proveedores. Al cruzar los identificadores fiscales, el equipo de datos maestros encuentra 500 socios que están en ambos lados. Algunos tienen una dirección distinta en cada registro.

Sin decisión, la conversión lleva los dos registros y cada uno se convierte en su propio BP. Con decisión, el equipo define que esos 500 serán un BP con dos roles, elige qué dirección prevalece, la verifica en la fuente oficial y registra quién pasa a ser dueño de los datos generales.

En el mismo cruce aparecen 1.000 proveedores sin compras desde hace muchos años. El equipo define el criterio, trata esos registros en ECC y evita cargar como activo lo que ya no se usa.

Nada de esto es tecnología nueva. Es una decisión tomada en el momento correcto.

¿Por dónde empezar?

1. Haga una foto de los datos maestros actuales: cuántos clientes, proveedores, identificadores fiscales repetidos entre ambos lados y registros sin movimiento.
2. Escriba las reglas: unificar o no, casa matriz y sucursales, dueño de los datos generales, criterio de inactividad.
3. Sanee en el origen, antes de la carga, validando en fuentes oficiales.
4. Cierre el mapa de numeración y agrupaciones con la arquitectura SAP.
5. Revise las interfaces y las validaciones del CNPJ.
6. Pruebe la conversión en ciclos de carga y compare la calidad antes y después.

Si su conversión está en planificación, vale la pena leer también sobre migración de datos para proyectos con SAP y sobre cómo reducir riesgos y costos en la migración de datos SAP. La página de migración a SAP S/4HANA muestra cómo abordamos este trabajo.

Preguntas frecuentes

¿Todo cliente y proveedor debe convertirse en Business Partner en la conversión?

Sí. SAP documenta que, en un proyecto de conversión de SAP ERP a SAP S/4HANA, todos los registros maestros de clientes y proveedores del sistema deben convertirse en Business Partners. Por eso, los registros inactivos e incorrectos deben tratarse antes.

¿Un socio que es cliente y proveedor debe ser un solo BP?

El BP fue diseñado para eso: los datos generales se comparten entre roles como cliente y proveedor. Mi recomendación es definir la regla de unificación antes de la conversión. Sin esa decisión, la misma empresa puede terminar en dos BP.

¿Se puede mantener el mismo número de ECC?

SAP documenta la opción "same number", que mantiene el mismo número en el BP y en el cliente o proveedor. Esto exige una configuración específica de rangos de numeración (numeración externa e intervalos coincidentes), a validar con la arquitectura SAP.

¿Casa matriz y sucursales deben ser BP separados?

En Brasil, cada establecimiento tiene su propio CNPJ, con la misma raíz y un número de orden distinto. No hay una respuesta única. Lo importante es elegir un modelo, escribir la regla y aplicar la misma regla en todos los casos.

¿Qué hacer con los registros inactivos antes de la conversión?

Definir un criterio de inactividad con finanzas, compras y ventas, tratar esos registros en ECC y evitar cargarlos como activos. Como todos los registros de clientes y proveedores deben convertirse, la limpieza tiene que venir antes.

¿El CNPJ alfanumérico afecta los datos maestros de BP?

Puede afectar campos, validaciones y programas a medida que tratan el CNPJ como número. Es una regla brasileña: la Receita Federal adoptó el formato alfanumérico para nuevas inscripciones a partir de julio de 2026 (IN RFB nº 2.229/2024), con 14 posiciones, y orientó a las empresas a adaptar sus sistemas. Quienes ya tienen CNPJ conservan su número.

Cómo 4MDG puede ayudar

La conversión a BP muestra los datos maestros tal como están. 4MDG realiza migración de datos a SAP, desde sistemas heredados a SAP y de ECC a S/4HANA. Saneamos y estandarizamos los datos maestros en el origen, antes de la carga. Eso incluye deduplicación, estandarización, enriquecimiento y validación de clientes y proveedores en fuentes oficiales, como CNPJ, inscripción estatal, certificados y situación registral, con IA y más de 600 bases públicas. Trabajamos con mapeo de origen a destino, pruebas de carga y una puesta en producción controlada, con una metodología integrada a SAP Activate. Vea la página de migración de datos a SAP S/4HANA. Si quiere empezar por una muestra real de su base, puede solicitar el diagnóstico o contactarnos.

Fuentes

• SAP Learning, "Working with Business Partners", curso Functions & Innovations in SAP S/4HANA Sales: https://learning.sap.com/courses/functions-innovations-in-sap-s-4hana-sales/working-with-business-partners_a6b68cce-1d88-41a5-b2c4-513775c98be6, consultado el 6 de octubre de 2026.
• SAP Learning, "Creating Business Partners", curso Purchasing in SAP S/4HANA: https://learning.sap.com/courses/purchasing-in-sap-s-4hana/creating-business-partners, consultado el 6 de octubre de 2026.
• SAP Learning, "Manage Customer/Vendor Integration", curso Managing Customer and Vendor Accounts: https://learning.sap.com/courses/managing-customer-and-vendor-accounts/manage-customer-vendor-integration_b3f948ee-b6e4-4f7c-85cd-08dc926ce427, consultado el 6 de octubre de 2026.
• Receita Federal (Brasil), "CNPJ Alfanumérico": https://www.gov.br/receitafederal/pt-br/acesso-a-informacao/acoes-e-programas/programas-e-atividades/cnpj-alfanumerico, consultado el 6 de octubre de 2026.