Dá para integrar qualquer ERP?

Praticamente sempre existe um caminho, mas o custo e o risco variam muito. Com API documentada é trabalho de dias ou semanas; sem API, resta leitura de banco, troca de arquivos ou automação de tela, que funcionam mas são frágeis e exigem manutenção contínua.

Por que integrar com ERP grande demora tanto?

Porque o gargalo raramente é o código. É liberação de licença do módulo de integração, criação de ambiente de homologação, aprovação de acesso, e a agenda do parceiro que sustenta o ERP. Planeje o cronograma pelas dependências, não pelo esforço de desenvolvimento.

O que é camada anticorrupção nesse contexto?

É um módulo próprio que fica entre o seu sistema e o ERP, traduzindo os dados do ERP para o modelo do seu sistema. Se o ERP mudar de versão ou for substituído, você reescreve só essa camada em vez de mexer na aplicação inteira.

Integrar com TOTVS, SAP ou Omie: o que cada um permite

A capacidade de integração de um ERP depende muito menos da marca e muito mais da categoria a que ele pertence. Um sistema em nuvem com API REST documentada, um ERP corporativo de grande porte e um legado instalado no servidor da empresa exigem estratégias, prazos e interlocutores completamente diferentes. E, em todos os casos, os detalhes exatos mudam por versão, módulo contratado e cláusula de contrato, o que faz da descoberta técnica a primeira tarefa obrigatória do projeto.

Categoria 1: ERP em nuvem com API pública

Omie, Bling, Tiny, ContaAzul e sistemas de porte parecido nasceram para serem integrados. O padrão que se encontra aqui:

API REST com documentação pública, acessível sem contrato adicional.
Autenticação por chave de aplicação ou token gerado no painel, às vezes com fluxo de autorização por aplicativo.
Limite de requisições por período, quase sempre existente. Ele define se você vai poder varrer a base inteira todo dia ou vai precisar de consulta incremental por data de alteração.
Paginação obrigatória em listagens e notificações por webhook com cobertura desigual: costuma haver evento de pedido e de nota, e pode não haver para outros objetos.

O que ainda dá trabalho nessa categoria: campos personalizados que cada empresa criou, regra fiscal específica do negócio, e o fato de que a API expõe o que o produto faz, não o que você gostaria que ele fizesse. Se o ERP não tem o conceito de reserva de estoque, nenhuma API vai criar isso para você.

Categoria 2: ERP de grande porte

TOTVS (Protheus, Datasul e a linha corporativa) e SAP são plataformas configuráveis, com módulos vendidos separadamente e customizações feitas ao longo de anos. A integração normalmente acontece por uma destas vias:

Web services expostos pelo próprio ERP, cobrindo processos padrão.
Camada ou barramento de integração do próprio fabricante, contratada à parte.
Middleware de mercado que a empresa já usa para conversar entre sistemas.
Acesso a banco de dados em leitura, com visões preparadas pelo time do ERP, quando o resto está inviável.
Rotinas de importação e exportação de arquivo, ainda comuns em processos fiscais e contábeis.

O ponto que muda o cronograma: o gargalo raramente é técnico. É licença do módulo de integração, disponibilidade de ambiente de homologação, aprovação de acesso pela área de segurança e agenda do parceiro que sustenta o ERP. Já vi projeto de duas semanas de desenvolvimento levar três meses porque o ambiente de testes não existia.

Outro detalhe importante: customização quebra suposição. Um campo que na documentação é obrigatório pode estar desativado naquela implantação; um processo padrão pode ter sido substituído por rotina própria. Por isso nenhum orçamento sério para essa categoria sai sem uma conversa técnica com quem mantém o ERP.

Categoria 3: legado on-premise sem API

O sistema roda num servidor dentro da empresa, foi feito há muitos anos, e o fornecedor sumiu ou não tem interesse em abrir integração. Sobram três saídas, todas com custo:

Acesso direto ao banco de dados. É a mais usada. Em leitura, funciona razoavelmente bem: você monta consultas, replica para uma base intermediária e trabalha a partir dela. Em escrita, é perigoso: gravar direto nas tabelas pula as regras que a aplicação aplica e pode corromper dados de um jeito que só aparece no fechamento do mês. A recomendação prática é ler do banco e escrever pela aplicação, quando houver qualquer caminho para isso.

Troca de arquivos. O ERP exporta CSV ou TXT numa pasta em horário programado e importa arquivos que você deposita lá. Simples, auditável e limitado: sempre em lote e sensível a mudança de layout sem aviso. Vale exigir checagem de contagem de linhas e pasta de erro.

RPA, automação de tela. Um robô opera a interface como se fosse uma pessoa. Resolve quando não há mais nada, e traz todos os riscos: quebra a cada atualização de tela, precisa de máquina dedicada, guarda credencial de usuário real e deixa rastro de auditoria confuso (a ação aparece como se fosse do funcionário). Trate como ponte temporária, não como arquitetura.

Tabela por categoria

Categoria de ERP	Forma típica de integração	Esforço relativo	Riscos	Quem precisa participar
Nuvem com API pública	REST com chave, webhook parcial	Baixo	Limite de requisições, campos personalizados	Desenvolvedor e usuário-chave do ERP
Grande porte	Web services, camada própria, middleware, banco	Alto	Licença, homologação, customizações locais	Parceiro do ERP, TI interna, segurança, jurídico
Legado sem API	Banco, arquivo em pasta, RPA	Médio a alto	Escrita insegura, layout que muda, robô que quebra	Fornecedor do legado (se existir), TI, dono do processo
Solução de nicho	Varia caso a caso	Imprevisível	Documentação inexistente	Fornecedor, obrigatoriamente

Esforço aqui é ordem de grandeza de mercado, não medida exata. O mesmo ERP em duas empresas pode dar trabalho muito diferente conforme o quanto foi customizado.

As perguntas para fazer ao fornecedor do ERP antes de orçar

Leve esta lista para a reunião. As respostas mudam o preço mais do que qualquer requisito funcional:

Existe API ou web service documentado? Qual a versão da documentação e ela é pública?
Há custo de licença para o módulo de integração ou para liberar as chamadas? É por chamada, por usuário de integração, ou fixo?
Qual o limite de chamadas por minuto, hora ou dia? O que acontece quando estoura?
Existe ambiente de homologação com dados de teste? Quanto tempo leva para provisionar?
Quem dá suporte à integração? O fabricante, o parceiro implantador, ou ninguém?
Há webhook ou notificação de evento, ou tudo é consulta periódica?
Como é a autenticação e qual a política de rotação de credencial?
Que customizações existem nesta implantação que fogem do padrão?
Qual a política de atualização de versão e quem avisa quando algo muda no contrato de dados?
A licença permite acesso ao banco em leitura, se for necessário?

Se o fornecedor não responder a metade dessas perguntas, o projeto tem risco de cronograma independentemente de quem for desenvolver.

O padrão anticorrupção: não deixe o ERP entrar no seu sistema

O erro estrutural mais caro é espalhar chamadas ao ERP por toda a aplicação. Quando isso acontece, o formato de dados do ERP (nomes de campo, códigos internos, regras de status) contamina o sistema inteiro, e qualquer mudança de versão obriga a mexer em dezenas de lugares.

A alternativa é uma camada de integração própria que:

Expõe para o seu sistema um modelo de dados limpo, com os nomes do seu negócio.
Traduz esse modelo para o formato do ERP em um único lugar.
Concentra autenticação, tentativa de reenvio, tratamento de limite de requisições e log de auditoria.
Guarda a última resposta válida, para que uma queda do ERP não derrube a operação inteira.
Permite trocar o ERP reescrevendo apenas ela.

Essa camada custa algum tempo a mais na primeira entrega e paga esse tempo na primeira mudança relevante. Empresas que crescem trocam de ERP; sistemas acoplados ao ERP antigo viram argumento para não trocar, que é o pior tipo de dívida técnica: aquela que trava uma decisão de negócio.

A ordem correta do projeto

Uma sequência que reduz surpresa:

Descoberta técnica com acesso real ao ambiente, não com base em documentação. Uma ou duas semanas com escopo e preço próprios.
Prova de conceito com um objeto de ponta a ponta (um pedido, um cliente), em homologação.
Definição da camada anticorrupção e do contrato de dados interno.
Implementação por objeto, do mais simples ao mais crítico.
Reconciliação e monitoramento antes de considerar entregue: comparação periódica dos dois lados e alerta quando a integração para.

Orçar integração com ERP sem a etapa 1 é chutar. Em projetos assim, a Retti Tech separa a descoberta técnica do restante justamente porque o preço honesto do desenvolvimento só existe depois que se sabe o que o ERP daquela empresa realmente permite fazer.