Qual sistema deve ser o mestre do cadastro de cliente?

Normalmente o ERP, porque é ele que carrega as obrigações fiscais e o dado que precisa estar correto na nota. O CRM continua dono da informação comercial, como contatos, histórico e etapa de negociação. A divisão por entidade evita a maior parte dos conflitos.

Como impedir que o mesmo cliente seja criado duas vezes?

Padronizando o documento como chave, sem pontuação e com validação de dígito, e mantendo uma tabela de ligação entre os identificadores dos dois sistemas. Antes de criar qualquer registro, a integração consulta essa tabela. Cadastros novos sem documento devem ir para uma fila de conferência.

Preciso sincronizar em tempo real?

Depende do dado. Situação financeira do cliente e limite de crédito ganham muito com atualização rápida, porque afetam a venda no momento. Histórico de faturamento pode ser sincronizado algumas vezes ao dia sem prejuízo, o que reduz custo e complexidade.

Como integrar o CRM com o ERP sem duplicar cadastro

Integrar CRM e ERP sem duplicar cadastro depende de uma decisão tomada antes de qualquer código: definir qual sistema é o mestre de cada entidade e manter uma tabela de ligação entre os identificadores dos dois lados. Na prática que funciona, o ERP manda no cadastro fiscal e no financeiro, o CRM manda no comercial, e nenhum dos dois recria o que o outro já criou.

Por que a duplicidade acontece

A duplicação quase nunca vem de erro de programação. Vem de três causas de desenho:

Os dois sistemas podem criar cliente. O vendedor cadastra no CRM, o faturamento cadastra no ERP, e ninguém conferiu antes.
A chave usada para casar é fraca. Nome de empresa tem variação infinita: "Comercial Silva", "Comercial Silva Ltda", "COML SILVA LTDA ME".
Não existe registro do que já foi sincronizado. Sem isso, cada execução tenta criar tudo de novo.

Resolver essas três causas é 80% do trabalho.

Passo 1: divida a propriedade do dado por entidade

Escreva uma tabela como esta e valide com as áreas antes de programar. Ela vale mais que um diagrama bonito.

Entidade	Mestre	Vai para o outro lado
Cadastro fiscal do cliente (razão, CNPJ, endereço, IE)	ERP	Somente leitura no CRM
Contatos e telefones comerciais	CRM	Contato principal vai ao ERP
Oportunidade e funil	CRM	Não vai
Produto e preço de tabela	ERP	Somente leitura no CRM
Pedido de venda	Nasce no CRM, vira pedido no ERP	ERP devolve número e situação
Nota fiscal	ERP	Situação aparece no CRM
Título a receber e inadimplência	ERP	Situação aparece no CRM

A regra que evita dor: o campo tem um dono só. Onde não é dono, o sistema mostra o dado como leitura, idealmente com indicação da origem e do horário da última atualização.

Passo 2: monte a chave e a tabela de ligação

A chave de negócio para pessoa jurídica no Brasil é o CNPJ, normalizado: só dígitos, com validação de dígito verificador. Para pessoa física, o CPF, com o mesmo tratamento. Para o cliente estrangeiro ou o prospect que ainda não passou documento, é preciso um caminho alternativo.

Além da chave de negócio, crie uma tabela de ligação:

Campo	Exemplo
entidade	cliente
id_crm	4821
id_erp	000173
documento	12345678000199
criado_em	data e hora
ultima_sincronia	data e hora

Essa tabela é consultada antes de qualquer criação. Ela também responde rapidamente às perguntas de suporte: esse cliente já foi para o ERP, quando, e com qual código.

Para prospects sem documento, a prática mais segura é o CRM manter o registro apenas do lado dele, e a criação no ERP acontecer só no momento em que a venda avança e o documento é informado. Isso evita encher o ERP de cadastro que nunca vira cliente.

Passo 3: defina a direção de cada evento

Liste os eventos e o que cada um dispara. Um exemplo típico:

Oportunidade ganha no CRM dispara: verificar se o cliente existe no ERP, criar se não existir, criar pedido de venda, devolver número do pedido ao CRM.
Pedido faturado no ERP dispara: atualizar a oportunidade com número da nota e valor faturado.
Título vencido no ERP dispara: marcar a situação financeira do cliente no CRM, para que o vendedor veja antes de prometer nova entrega.
Endereço alterado no ERP dispara: atualizar a cópia de leitura no CRM.
Novo contato criado no CRM dispara: atualizar o contato principal no ERP, se for o caso.

Note que só um evento cria registro no ERP. Essa disciplina é o que mantém a base limpa.

Passo 4: escolha o mecanismo de transporte

Mecanismo	Quando cabe	Cuidado
Webhook do CRM para um serviço intermediário	CRM moderno com webhook	Precisa de endpoint público e reentrega
API do ERP chamada pelo intermediário	ERP com API documentada	Limite de requisições e autenticação
Consulta agendada com marca de alteração	ERP sem webhook	Depende de campo de data de atualização confiável
Arquivo em pasta ou FTP	ERP antigo e fechado	Atraso, arquivo parcial, codificação
Banco de dados direto	ERP local sem API	Quebra em atualização do fornecedor

O padrão mais robusto é um serviço intermediário que recebe eventos, grava numa fila e processa com retentativa. Ele é o único que conhece os dois lados, o que evita acoplar CRM e ERP diretamente e facilita trocar qualquer um dos dois no futuro.

Passo 5: trate divergência sem apagar dado

Mesmo com mestre definido, divergência aparece. Endereço atualizado no CRM por engano, razão social alterada no ERP, cliente que mudou de CNPJ por reestruturação societária.

O tratamento que funciona:

Não sobrescreva silenciosamente. Registre o valor anterior, o novo e a origem.
Gere pendência para o que é sensível. Dado bancário, limite de crédito e regime tributário não devem ser atualizados automaticamente sem conferência.
Tenha uma tela de mesclagem. Quando dois cadastros descrevem o mesmo cliente, alguém precisa poder unir, escolhendo o que fica e mantendo o histórico dos dois.

O que dá errado com frequência

Carga inicial sem limpeza. Se as duas bases já têm duplicatas internas, a integração vai multiplicá-las. A limpeza precede a ligação.
Campos com tamanho diferente. A razão social de 120 caracteres do CRM entra truncada no ERP e a comparação seguinte acha que mudou, gerando atualização infinita.
Laço de eco. A atualização que o ERP recebe volta como evento e dispara nova atualização. A solução é marcar a origem da alteração e ignorar o próprio eco.
Fuso horário. Comparar datas gravadas em fusos diferentes cria alterações fantasmas todo dia.
Ninguém olha a fila de erro. Sem alerta e sem responsável, a integração falha em silêncio e a divergência só aparece no fechamento do mês.

Como validar que ficou certo

Antes de considerar concluído, rode três conferências:

Contagem. Quantos clientes ativos existem de cada lado e quantos têm ligação registrada.
Amostra dirigida. Escolha vinte casos difíceis, não vinte fáceis: cliente com filial, cliente com nome parecido, cliente inativo, cliente estrangeiro.
Teste de repetição. Dispare o mesmo evento duas vezes e confirme que gerou um resultado só.

Uma integração bem feita entre CRM e ERP não é percebida pelo usuário: ele simplesmente para de digitar a mesma coisa duas vezes e passa a ver, na tela de venda, se o cliente está em dia.