Business Partner no S/4HANA: o que muda no cadastro e onde quebra

No SAP S/4HANA, cliente e fornecedor passam a ser papéis de um único objeto, o Business Partner (BP), e todo cadastro de cliente e fornecedor precisa ser convertido em BP antes da conversão do ERP. O dado geral passa a ser compartilhado entre os papéis, o BP vira a porta de entrada e a integração CVI sincroniza as tabelas antigas. A qualidade quebra nas decisões que ninguém tomou antes da conversão: quem junta, quem é dono do dado geral, como numerar e o que fica de fora.

"Paulo, pega lá os clientes e os fornecedores e joga pro S/4."

Ouvi variações dessa frase muitas vezes nos anos em que implementei SAP. E quem já abriu a transação BP depois de uma conversão feita assim conhece a cena: a mesma empresa aparece duas vezes, uma vinda de vendas e outra de compras, com endereços diferentes, e ninguém sabe dizer qual está certo. O sistema fez o que foi mandado. A decisão é que ficou para depois.

Este texto é para quem vai converter do ECC para o S/4HANA, ou já converteu e sofre com o cadastro de BP. Vou separar três coisas: o que a SAP documenta, a minha leitura operacional e o que eu recomendo decidir antes.

O que é o Business Partner no SAP S/4HANA?

Segundo a SAP, o Business Partner é o objeto central de dados mestres para todas as pessoas físicas e jurídicas com quem a empresa tem relação de negócio. A definição está na lição "Creating Business Partners" do curso de compras no SAP S/4HANA do SAP Learning. A mesma lição diz que o BP é mantido pela transação BP ou pelos apps correspondentes no SAP Fiori launchpad.

A SAP também deixa claro o pré-requisito: num projeto de conversão de SAP ERP para SAP S/4HANA, todos os registros mestres de cliente e de fornecedor do sistema precisam ser convertidos em Business Partners. Isso está na lição "Working with Business Partners", também do SAP Learning.

Se você quiser revisar os termos de dados mestres antes de seguir, o glossário da 4MDG ajuda.

O que muda no cadastro de clientes e fornecedores?

Muda a lógica do cadastro. No ECC, cliente e fornecedor eram registros separados, mantidos pelas transações antigas de cliente e de fornecedor. No S/4HANA, a empresa é cadastrada uma vez como BP e recebe papéis. Vou passar pelos pontos que a SAP documenta.

O dado geral passa a ser compartilhado

A SAP afirma que o dado geral de um Business Partner é compartilhado entre os diferentes papéis, como cliente e fornecedor. Nome, endereço e identificação passam a ser um registro só para vendas e para compras.

Um BP pode ter vários papéis

Um mesmo BP pode ter papéis como Customer, FI Customer e Vendor. Do lado de compras, a SAP cita os papéis Supplier (FLVN01) e FI Vendor (FLVN00). Os dados do fornecedor ficam em três níveis: gerais (nível do mandante), contábeis (empresa) e de compras (organização de compras).

A categoria define os campos

A categoria do BP (pessoa, organização ou grupo) define quais campos ficam disponíveis. Escolher a categoria errada na carga não é só um rótulo trocado: muda o que pode ser preenchido.

Vários endereços e dependência de tempo

No ERP 6.0 havia um endereço por registro mestre. No BP, a SAP documenta que é possível ter vários endereços e que há suporte a dependência de tempo para atributos e relacionamentos.

Numeração, agrupamentos e o mesmo número

Pela lição "Manage Customer/Vendor Integration", os agrupamentos de BP determinam as faixas de numeração. Os grupos de contas de cliente e fornecedor precisam ser vinculados aos agrupamentos de BP. As faixas podem ser internas ou externas, e existe a opção "same number" para manter o mesmo número no BP e no cliente ou fornecedor. A atribuição é de um para um: cada cliente ou fornecedor corresponde a um BP, e um cliente e um fornecedor também podem ser atribuídos ao mesmo BP.

O BP vira a porta de entrada e a CVI sincroniza

A Customer/Vendor Integration (CVI) garante que, quando um BP é criado ou alterado, as tabelas de cliente e fornecedor são atualizadas automaticamente. Em outras palavras, você mantém o BP e o sistema preenche e sincroniza os campos necessários no registro de cliente ou fornecedor correspondente.

Interfaces externas mudam de endereço

A SAP orienta que aplicações externas usem o módulo RFC RFC_CVI_EI_INBOUND_MAIN para criar e atualizar Business Partners. Interface que antes gravava direto em cliente ou fornecedor precisa ser revista.

Onde a qualidade do cadastro quebra na conversão para BP?

Daqui para baixo é leitura operacional, não documentação SAP. São os sete pontos onde, no cadastro brasileiro, a falta de decisão aparece depois do go-live.

1. O mesmo CNPJ como cliente e como fornecedor

Muita empresa compra e vende para o mesmo parceiro. No ECC, isso costumava gerar dois registros. Como o dado geral do BP é compartilhado entre papéis, o natural seria um BP com dois papéis. Se ninguém decidir juntar, você termina com dois BPs para a mesma empresa, cada um com o seu endereço e o seu histórico.

2. Matriz e filiais

No Brasil, cada estabelecimento tem CNPJ próprio. A matriz e as filiais compartilham a raiz (os oito primeiros caracteres) e cada uma tem a sua ordem. A pergunta que precisa de resposta antes da carga é: um BP por estabelecimento ou outra modelagem? Essa escolha afeta faturamento, recebimento fiscal e relatórios. Não existe resposta única, mas precisa existir uma decisão escrita.

3. Quem é dono do dado geral compartilhado

Se o endereço e os dados fiscais são um registro só, compras e vendas passam a mexer na mesma coisa. Sem dono definido, o comprador corrige o endereço de entrega pensando no fornecedor e muda o que o faturamento usa para o cliente. É um ponto que costuma virar briga entre áreas.

4. Numeração e agrupamentos versus grupos de contas antigos

Os grupos de contas do ECC precisam ser vinculados a agrupamentos de BP. Se os grupos antigos foram criados sem critério ao longo dos anos, esse mapeamento herda a bagunça. E a decisão de manter ou não o mesmo número afeta relatórios, interfaces e o costume dos usuários.

5. Inativos e bloqueados

A SAP exige que todos os registros de cliente e fornecedor do sistema sejam convertidos. Isso torna ainda mais importante tratar antes da conversão os cadastros que não deveriam seguir vivos: fornecedor sem movimento há anos, cliente bloqueado, registro criado por engano. A minha recomendação é tratar no ECC o que é arquivável, com critério documentado, e não carregar como se fosse ativo.

6. Interfaces que gravavam direto em cliente e fornecedor

Portal de fornecedores, CRM, e-commerce, ferramenta de homologação. Tudo que criava ou alterava cliente e fornecedor por fora precisa passar a entrar pelo BP. A SAP indica o RFC_CVI_EI_INBOUND_MAIN para isso. Interface esquecida é cadastro entrando sem regra.

7. CNPJ alfanumérico

A Receita Federal definiu que, a partir de julho de 2026, o CNPJ alfanumérico vale exclusivamente para novas inscrições, conforme a IN RFB nº 2.229/2024. O CNPJ continua com 14 posições: 8 da raiz, 4 da ordem e 2 dígitos verificadores. Quem já está inscrito mantém o número. A própria Receita orienta as empresas a adaptarem seus sistemas. Para o cadastro de BP, a minha recomendação é revisar campos, validações e programas customizados que tratam o CNPJ como número antes de a conversão consolidar essas regras.

O que decidir antes da conversão, e quem decide?

A tabela abaixo é um resumo de trabalho. A coluna "quem decide" é uma sugestão; cada empresa ajusta à sua estrutura.

Ponto de quebra	O que acontece se ninguém decidir	O que decidir antes	Quem decide
Mesmo CNPJ como cliente e fornecedor	Dois BPs para a mesma empresa	Regra para juntar e qual registro prevalece no dado geral	Dados mestres, com vendas e compras
Matriz e filiais	Modelagem diferente para casos iguais	Um BP por estabelecimento ou outra modelagem, por escrito	Dados mestres, fiscal e arquitetura SAP
Dado geral compartilhado	Uma área altera o que a outra usa	Dono de cada grupo de campos e fluxo de alteração	Governança de dados com as áreas
Numeração e agrupamentos	Grupos antigos sem critério viram agrupamentos sem critério	Mapa de grupos de contas para agrupamentos e uso do "same number"	Arquitetura SAP com dados mestres
Inativos e bloqueados	Cadastro morto convertido como se fosse ativo	Critério de inatividade e o que tratar antes no ECC	Dados mestres, financeiro e compras
Interfaces externas	Cadastro entrando por fora do BP	Inventário de interfaces e adequação para criar e alterar pelo BP	TI e integração
CNPJ alfanumérico	Validação customizada rejeita ou corrompe o identificador	Revisão de campos, validações e programas que tratam o CNPJ	TI, fiscal e dados mestres

Checklist do que limpar antes

• Listar os CNPJs que aparecem como cliente e como fornecedor ao mesmo tempo.
• Agrupar os cadastros pela raiz do CNPJ e conferir matriz e filiais.
• Validar razão social, endereço, inscrição estadual e situação cadastral em fontes oficiais.
• Padronizar endereço, nome e campos fiscais que serão compartilhados entre papéis.
• Definir o critério de inatividade e separar o que não deve seguir ativo.
• Mapear grupos de contas para agrupamentos de BP e decidir sobre o mesmo número.
• Inventariar as interfaces que gravam em cliente e fornecedor.
• Revisar campos e validações customizadas de CNPJ.
• Medir a qualidade antes e depois, com os mesmos indicadores.

Sobre o último item, escrevi como montar essa linha de base em como medir a qualidade do cadastro.

Como isso aparece num caso hipotético?

O exemplo a seguir é hipotético. A empresa é fictícia e os números são redondos, só para ilustrar.

A Distribuidora Exemplo tem, no ECC, 10.000 clientes e 4.000 fornecedores. Ao cruzar os CNPJs, o time de dados mestres encontra 500 parceiros que estão nos dois lados. Desses, parte está com endereço diferente em cada registro.

Sem decisão, a conversão leva os dois registros e cada um vira o seu BP. Com decisão, o time define que esses 500 viram um BP com dois papéis, escolhe qual endereço prevalece, confere na fonte oficial e registra quem passa a ser dono do dado geral.

No mesmo cruzamento, aparecem 1.000 fornecedores sem compra há muitos anos. O time define o critério, trata esses cadastros no ECC e evita carregar como ativo o que não está mais em uso.

Nada disso é tecnologia nova. É decisão tomada na hora certa.

Por onde começar?

1. Faça um retrato do cadastro atual: quantos clientes, fornecedores, CNPJs repetidos entre os dois lados e cadastros sem movimento.
2. Escreva as regras: juntar ou não, matriz e filial, dono do dado geral, critério de inatividade.
3. Saneie na origem, antes da carga, validando em fontes oficiais.
4. Feche o mapa de numeração e agrupamentos com a arquitetura SAP.
5. Revise as interfaces e as validações de CNPJ.
6. Teste a conversão em ciclos de carga e compare a qualidade antes e depois.

Se a sua conversão está no planejamento, vale ler também sobre migração de dados para projetos com SAP e sobre como reduzir riscos e custos na migração de dados. A página de migração para SAP S/4HANA mostra como tratamos esse trabalho.

Perguntas frequentes

Todo cliente e fornecedor precisa virar Business Partner na conversão?

Sim. A SAP documenta que, num projeto de conversão de SAP ERP para SAP S/4HANA, todos os registros mestres de cliente e de fornecedor do sistema precisam ser convertidos em Business Partners. Por isso, o tratamento de cadastros inativos e incorretos deve acontecer antes.

Um parceiro que é cliente e fornecedor deve ser um BP só?

O BP foi desenhado para isso: o dado geral é compartilhado entre papéis como cliente e fornecedor. A minha recomendação é definir a regra de junção antes da conversão. Sem essa decisão, a mesma empresa pode acabar em dois BPs.

Dá para manter o mesmo número do ECC?

A SAP documenta a opção "same number", que mantém o mesmo número no BP e no cliente ou fornecedor. Isso exige configuração específica de faixas de numeração (numeração externa e intervalos coincidentes), a validar com a arquitetura SAP.

Matriz e filial devem ser BPs separados?

Cada estabelecimento tem CNPJ próprio, com a mesma raiz e uma ordem diferente. Não há resposta única. O importante é a empresa escolher uma modelagem, escrever a regra e aplicar a mesma regra em todos os casos.

O que fazer com cadastros inativos antes da conversão?

Definir um critério de inatividade com financeiro, compras e vendas, tratar esses cadastros no ECC e evitar que sejam carregados como ativos. Como todos os registros de cliente e fornecedor precisam ser convertidos, a limpeza tem que vir antes.

O CNPJ alfanumérico afeta o cadastro de BP?

Pode afetar campos, validações e programas customizados que tratam o CNPJ como número. A Receita Federal adotou o formato alfanumérico para novas inscrições a partir de julho de 2026 (IN RFB nº 2.229/2024), mantendo 14 posições, e orientou as empresas a adaptarem seus sistemas. Quem já tem CNPJ mantém o número.

Como a 4MDG pode ajudar

A conversão para BP expõe o cadastro como ele está. A 4MDG faz migração de dados para o SAP, do legado ao SAP e do ECC para o S/4HANA. Saneamos e padronizamos os dados mestres na origem, antes da carga. Isso inclui deduplicação, padronização, enriquecimento e validação de cliente e fornecedor em fontes oficiais, como CNPJ, inscrição estadual, certidões e situação cadastral, com IA e mais de 600 bases públicas. Trabalhamos com mapeamento De/Para, testes de carga e cutover controlado, com metodologia integrada ao SAP Activate. Veja a página de migração de dados para SAP S/4HANA. Se quiser começar por um recorte real da sua base, você pode pedir o diagnóstico ou falar com a gente.

Fontes

• 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, acesso em 06/10/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, acesso em 06/10/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, acesso em 06/10/2026.
• Receita Federal, "CNPJ Alfanumérico": https://www.gov.br/receitafederal/pt-br/acesso-a-informacao/acoes-e-programas/programas-e-atividades/cnpj-alfanumerico, acesso em 06/10/2026.