Sincronização de cadastros entre sistemas sem duplicidade

O vendedor cadastra o cliente no CRM como "Mercado Bom Preço". O financeiro, quando a primeira nota sai, cria no ERP "MERCADO BOM PRECO LTDA". O suporte, que usa outra ferramenta, abre chamado para "Bom Preço - Filial Centro". São três cadastros da mesma empresa, com três telefones, dois endereços de cobrança e nenhum vínculo entre eles.

Com produto e fornecedor acontece igual. O mesmo parafuso tem um código no ERP, outro na loja virtual e um terceiro na planilha de compras. Na hora de responder perguntas simples, como quanto esse cliente comprou no ano ou quantos chamados ele abriu, alguém precisa cruzar planilhas à mão e torcer para o nome ter sido digitado igual.

A resposta curta para a sincronização de cadastros entre sistemas é esta: para cada cadastro, escolha um único sistema dono; crie uma chave que identifique o registro em todos os sistemas; faça os demais receberem o dado em vez de criá-lo; e limpe as duplicidades antigas antes de ligar a sincronização. O restante do texto mostra como fazer cada uma dessas etapas sem trocar uma bagunça por outra.

Sintomas: o mesmo cliente com três cadastros

Cadastro duplicado raramente aparece como um problema único. Ele se espalha em pequenas fricções que viram rotina:

• Relatório que não fecha. O faturamento por cliente no ERP não bate com a carteira do CRM, porque metade das vendas está num cadastro e metade em outro.
• Cobrança no endereço errado. O cliente mudou de endereço, avisou o comercial, e o boleto continuou indo para o endereço antigo que estava no ERP.
• Produto com três nomes. O comprador pede reposição de um item que já está no estoque com outro código, e a empresa compra o que já tem.
• Fornecedor duplicado no contas a pagar. O mesmo fornecedor aparece com dois cadastros e dados bancários diferentes, o que abre espaço para pagamento em duplicidade.
• Retrabalho. Toda venda nova exige digitar o cliente duas ou três vezes.

Se dois ou três desses sinais aparecem com frequência, o problema não está nas pessoas que cadastram. Está na ausência de regra sobre quem cadastra o quê, e onde.

Por que acontece quando a empresa cresce

Na empresa pequena, existe um sistema e uma pessoa que cadastra. Conforme a operação cresce, cada área adota a sua ferramenta: CRM no comercial, ERP no fiscal e financeiro, plataforma de loja no e-commerce (como Shopify, Nuvemshop ou VTEX), sistema de chamados no suporte. Cada uma tem sua tela de cadastro e funciona bem sozinha. O problema nasce no encaixe:

• Cada sistema exige campos diferentes. O CRM aceita cliente só com nome e telefone; o ERP exige CNPJ, inscrição estadual e endereço completo. O comercial cria rápido no CRM, o financeiro cria de novo no ERP.
• Integrações feitas aos pedaços. Uma integração copia clientes do CRM para o ERP, outra copia do ERP para a loja, e nenhuma verifica se o registro já existe do outro lado.
• Sem chave comum. Cada sistema identifica o registro pelo seu código interno. Sem um identificador compartilhado, a única forma de cruzar é por nome, e nome escrito à mão nunca é igual.
• Importações em massa. Uma planilha de clientes de uma feira é carregada inteira, sem checar o que já existia.

Nenhum desses pontos se resolve trocando de ferramenta. Resolve-se com desenho.

Sistema dono do dado: quem manda em cada cadastro

O passo mais importante, e o mais adiado, é decidir por escrito qual sistema é a fonte da verdade de cada cadastro e, às vezes, de cada grupo de campos. Sem essa decisão, dois sistemas editam o mesmo dado e a sincronização vira cabo de guerra: um sobrescreve o outro e ninguém sabe qual versão ficou.

Um mapa típico, como ponto de partida para uma empresa com ERP, CRM e loja virtual:

Três decisões costumam gerar discussão e merecem atenção:

O dono pode ser por campo, não por registro inteiro. O cliente nasce no CRM quando ainda é oportunidade, mas os dados fiscais passam a ser do ERP quando a primeira venda é faturada. Isso é legítimo, desde que cada campo tenha um único dono em cada momento.

Quem não é dono não edita. No sistema que apenas recebe, o campo fica somente leitura, ou a alteração vira uma solicitação para o dono. Deixar editável "só por precaução" é o que recria a duplicidade.

Cadastro novo nasce num lugar só. Se o vendedor cadastra o cliente no CRM, o ERP recebe esse cliente pela integração em vez de o financeiro criar outro.

Quando o CRM atual não comporta essas regras, ou quando ele é exatamente a fonte da bagunça, vale ler quando um CRM sob medida vale a pena.

Sincronização em tempo real ou em lotes

Definido o dono, falta decidir como e quando o dado anda. Não existe uma resposta única; existe a frequência que o processo exige.

Na prática, o desenho mais robusto combina os dois: eventos para manter o dado atualizado e uma conciliação periódica para pegar o que escapou. A conciliação compara os cadastros dos dois lados e aponta divergências, em vez de sobrescrever tudo às cegas.

Em qualquer forma, três regras valem: receber a mesma mensagem duas vezes não pode criar dois clientes (idempotência); uma alteração antiga que chega atrasada precisa ser descartada; e cliente sem CNPJ válido ou produto sem NCM vai para uma fila de exceções que a operação corrige e reprocessa. Os princípios gerais, como API oficial, filas e monitoramento, estão em como integrar seu sistema com o ERP sem dor de cabeça.

Chaves, de-para e identificação de duplicados

Sincronizar exige que cada sistema saiba que o "cliente 4512" do ERP é o mesmo que o "contato 98" do CRM. Há duas formas de garantir isso.

Chave natural

É um dado do mundo real que identifica o registro: CNPJ ou CPF para clientes e fornecedores, código de barras (GTIN) para produtos que o têm. Funciona bem quando o dado é obrigatório e validado na entrada. Tem limites:

• Um mesmo CNPJ raiz pode ter várias filiais, e a empresa precisa decidir se cada filial é um cadastro ou um endereço do mesmo cliente.
• Pessoa física às vezes é cadastrada sem CPF numa etapa inicial de venda.
• Produto fabricado ou montado internamente não tem GTIN.
• O formato do campo precisa acompanhar mudanças de regra. O CNPJ, por exemplo, passa a admitir letras em novas inscrições; vale confirmar com o contador e o fornecedor do ERP que os sistemas aceitam o novo formato.

Chave própria e tabela de de-para

Quando a chave natural não basta, cria-se um identificador único do cadastro, gerado pelo sistema dono, e uma tabela de de-para que guarda, para cada registro, o código correspondente em cada sistema. É essa tabela que permite atualizar o cliente certo no CRM quando o ERP altera o endereço.

A tabela de de-para é parte da integração, não uma planilha à parte, e precisa de uma tela para a operação corrigir vínculos.

Como encontrar duplicados

Para os cadastros que já existem, a identificação combina regras exatas e aproximadas:

• Mesma chave natural (mesmo CNPJ completo, mesmo GTIN): duplicado certo.
• Nome normalizado (sem acento, sem "LTDA" e "ME", sem pontuação e espaços extras) igual ou muito parecido, combinado com mesmo CEP, telefone ou e-mail: duplicado provável.
• Apenas nome parecido: candidato, que precisa de revisão humana.

A regra prática é fundir automaticamente só o que é certo e mandar o provável para revisão. Fusão agressiva junta empresas diferentes com nomes parecidos, e desfazer isso custa mais trabalho do que revisar.

Limpeza inicial dos cadastros existentes

Ligar a sincronização sobre uma base suja só espalha a sujeira mais rápido. A limpeza vem antes, e segue um roteiro:

1. Extraia os cadastros de todos os sistemas para um ambiente separado, sem mexer na produção.
2. Padronize formatos: documentos, CEP, telefone, nomes e unidades de medida no mesmo padrão.
3. Valide o que dá para validar: dígito verificador de CNPJ e CPF, CEP existente, e-mail bem formado.
4. Agrupe duplicados com as regras de chave e semelhança, separando os certos dos prováveis.
5. Escolha o registro sobrevivente de cada grupo e defina, campo a campo, de onde vem o valor final: endereço fiscal do ERP, contato do CRM, o telefone mais recente.
6. Revise os casos prováveis com quem conhece os clientes e produtos, em lotes curtos e com prazo.
7. Preserve o histórico. Pedidos, notas e chamados ligados aos cadastros eliminados precisam apontar para o sobrevivente. No ERP, registros com movimento fiscal em geral não são apagados: ficam inativos e vinculados ao cadastro que permanece.
8. Monte a tabela de de-para inicial com o resultado e só então ligue a sincronização.

Contatos e clientes pessoa física são dados pessoais, e a LGPD (Lei 13.709/2018) vale para a limpeza: a cópia de trabalho precisa de acesso restrito e prazo para ser descartada. Retenção e base legal devem ser validadas com o jurídico.

O prazo varia com o volume e com quantos casos pedem revisão humana; em geral é uma fase de semanas, não de dias, e merece responsável e data. Comece por um cadastro só, geralmente cliente ou produto: entrega resultado mais cedo e ensina as regras que vão valer para os outros.

Regras para não voltar à bagunça

Base limpa sem regra volta a sujar. O que mantém os cadastros em ordem:

• Ponto único de criação. Cada cadastro nasce no sistema dono. Nos demais, o botão "novo cliente" some ou leva ao fluxo do dono.
• Busca antes de criar. A tela de cadastro procura pelo documento e por nome parecido antes de permitir um registro novo, e mostra o que já existe.
• Validação na entrada. Documento com dígito verificador, CEP consultado, campos obrigatórios coerentes com o que o ERP exige para faturar.
• Alteração sensível com aprovação. Troca de dados bancários de fornecedor e mudança de razão social passam por uma segunda pessoa e ficam registradas.
• Importação em massa pelo mesmo crivo. Planilha de feira ou de parceiro passa pela deduplicação antes de entrar.
• Indicadores de qualidade. Duplicados suspeitos, cadastros incompletos e tamanho da fila de exceções. Se sobem, alguma regra está sendo contornada.
• Responsável pelo dado. Cada cadastro tem uma área responsável pela qualidade, com autoridade para corrigir e para dizer não.

Para quem vende online, o cadastro de produto tem particularidades próprias de estoque, preço e conteúdo de vitrine, tratadas em integração entre ERP e e-commerce sem planilha no meio.

Perguntas frequentes

O que são dados mestres?

Dados mestres são os cadastros que vários sistemas da empresa compartilham, como clientes, produtos, fornecedores e tabelas de preço. Eles diferem das transações, como pedidos e notas, que se apoiam neles. A gestão de dados mestres define qual sistema é dono de cada cadastro, como os demais recebem o dado e como evitar duplicidades.

Dá para usar o CNPJ como chave do cliente em todos os sistemas?

Em parte. O CNPJ funciona bem como chave natural quando é obrigatório e validado na entrada, mas tem limites: filiais compartilham o mesmo CNPJ raiz, pessoa física às vezes é cadastrada sem CPF e o CNPJ passa a admitir letras em novas inscrições. Por isso, muitas empresas usam também um identificador próprio com tabela de de-para.

Como juntar cadastros duplicados sem perder o histórico?

Escolhendo um registro sobrevivente em cada grupo de duplicados e apontando para ele os pedidos, notas e chamados dos cadastros eliminados. No ERP, registros com movimento fiscal em geral não são apagados: ficam inativos e vinculados ao cadastro que permanece. A fusão automática deve se limitar aos duplicados certos, com revisão humana nos prováveis.

Quanto tempo leva a limpeza de uma base de cadastros?

Depende do volume de registros e de quantos casos pedem revisão humana. Em geral, a limpeza de uma base de cadastros é uma fase de semanas, não de dias, e merece responsável e data. Começar por um único cadastro, geralmente cliente ou produto, entrega resultado mais cedo e define as regras que valerão para os demais.

Como a Pervian Tech trabalha dados mestres

Na Pervian Tech, começamos pelo diagnóstico: quais sistemas guardam cada cadastro, o que cada um expõe por API e onde as duplicidades aparecem hoje. O diagnóstico inicial é gratuito e termina com o mapa de sistema dono, chaves e fluxos, que serve de base para qualquer caminho que a empresa escolha.

A partir daí, desenhamos a solução sob medida: limpeza da base atual com revisão da sua equipe nos casos duvidosos, tabela de de-para, sincronização por eventos com fila, reprocessamento e conciliação, e telas para a operação tratar exceções sem depender de desenvolvedor. Quando os sistemas atuais atendem, integramos o que já existe; quando não, construímos só a camada que falta. Esse desenho é trabalho de arquitetura de software, e as entregas típicas estão na página de integração de sistemas. Outros textos sobre o tema estão na categoria integrações.

O cronograma é definido em fases depois do diagnóstico, e o investimento é sob consulta, porque depende do número de sistemas, do volume de cadastros e do estado da base. Se a sua empresa ainda discute qual planilha tem o cliente certo, conte como seus cadastros funcionam hoje.