Todo dado financeiro da empresa (faturas, boletos, status de pagamento, linha digitável, PDF) vivia trancado dentro do ERP, a Omie. E todo produto que precisava responder a uma pergunta simples, do tipo "esse cliente está em dia?", tinha que consultar a Omie naquele instante, com o usuário esperando na tela.
Funciona. Até a hora em que muita gente acessa ao mesmo tempo.
O Custo Real de Falar Direto com o ERP
A API do ERP não foi feita para a tela do cliente
A Omie, como qualquer ERP, abre a API para tarefas de administração, não para alimentar a tela do cliente em tempo real. Por isso ela impõe limites rígidos de uso. Os números abaixo não são nossos, são as regras da própria Omie:
- No máximo 240 chamadas por minuto por função, e 960 por minuto no total.
- Nenhuma chamada simultânea da mesma função. Quando isso acontece, ela recusa e descarta o pedido.
- Avisos de "consumo redundante" que obrigam a esperar cerca de um minuto antes de tentar de novo.
- Depois de poucos erros seguidos, ela bloqueia a função por 30 minutos.
Na prática, o que isso significa para o negócio: quando vários clientes acessam a área financeira ao mesmo tempo, parte deles começa a receber erro na tela. Em um horário de pico, a área financeira inteira pode ficar fora do ar. Não por falha do nosso produto, mas porque ele depende, ao vivo, de um sistema de terceiro que tem limite de uso.
Cada produto resolvia o mesmo problema sozinho
Sem uma camada central, cada equipe que precisava do dado financeiro tinha que aprender, por conta própria, a conviver com os limites do ERP, as tentativas de repetição e os nomes que a Omie dá para cada coisa. Era o mesmo código frágil copiado em vários produtos. Vários lugares para manter e vários lugares para quebrar.
Trocar de fornecedor era um risco alto
A empresa estava justamente migrando de Conta Azul para Omie. Com cada produto falando direto com o ERP, qualquer troca de fornecedor exigia reescrever a integração dentro de produto por produto. A escolha do sistema financeiro virava uma decisão técnica de alto risco, quando deveria ser uma decisão de negócio.
Cada fornecedor falava uma língua diferente
"Pago", "baixado", "liquidado", "em aberto", "vencido": cada fornecedor nomeia o status do pagamento do seu jeito. O produto final tinha que entender o vocabulário de cada um. Trocou de fornecedor, mudou o vocabulário, mudou a tela.
O Que Mudou: Um Módulo Financeiro no Meio
A solução não foi otimizar as chamadas à Omie. Foi parar de fazer cada produto falar com a Omie. Colocamos um único módulo financeiro entre o ERP e o resto dos produtos.
A analogia é simples: ninguém liga para a usina de energia para acender a luz de casa. Você aperta o interruptor. Toda a complexidade da usina fica do outro lado da tomada. Foi isso que construímos: o interruptor.
São três decisões que se reforçam.
1. Centralizar a integração em um lugar só
Toda a complexidade de falar com o fornecedor (limites de uso, controle de acessos simultâneos, tentativas de repetição, proteção contra falha em cadeia) passa a viver em um único componente, cuidado por uma equipe. Os produtos não sabem, e não precisam saber, que a Omie existe.
2. Guardar o dado já organizado
O módulo copia faturas e boletos para um banco de dados próprio, em um formato que não depende do fornecedor. O status de pagamento passa a usar um vocabulário único e estável (em dia, vence hoje, vencido, pago, cancelado), não importa de qual ERP o dado veio.
3. Os produtos consultam o nosso banco, não o ERP
A tela do cliente pergunta ao nosso módulo, pelo CPF ou CNPJ, e recebe a resposta na hora, vinda do nosso banco, rápido e estável. A instabilidade do ERP fica isolada do outro lado, longe do cliente.
Resultados: Garantias de Arquitetura
Este módulo está entrando em produção agora, junto com a migração de Conta Azul para Omie. Por isso não vou apresentar números de "antes e depois" que ainda não foram medidos. O que dá para afirmar com honestidade é o que essa arquitetura passa a garantir:
| Dimensão | Antes (produto fala com o ERP) | Depois (módulo central) |
|---|---|---|
| Quem aguenta o limite da Omie | Cada produto, na frente do cliente | Um único componente, longe do cliente |
| Horário de pico | Risco de a área financeira sair do ar | Leitura no banco local, sem tocar no ERP |
| Trocar de fornecedor | Reescrever cada produto | Trocar só dentro do módulo |
| Linguagem do dado | Vocabulário diferente em cada fornecedor | Vocabulário único e estável |
| Manutenção da integração | Espalhada e duplicada | Em um lugar só |
| Adicionar um novo fornecedor | Novo projeto em cada produto | Mais uma fonte no mesmo módulo |
Impactos para o Negócio
O cliente para de ver erro do ERP. A tela lê de um banco estável, e não de uma API que pode estar bloqueada temporariamente.
A escolha do fornecedor volta a ser do negócio. Trocar de fornecedor, ou usar mais de um ao mesmo tempo, deixa de ser um problema de engenharia e passa a ser uma configuração.
A equipe para de refazer o mesmo trabalho. Uma equipe cuida da integração. As outras apenas consomem um contrato simples e seguem evoluindo o produto.
O ecossistema cresce sem multiplicar o risco. Cada novo produto que precisa do financeiro apenas aperta o interruptor, em vez de construir uma nova usina.
Tecnologia Utilizada (Resumo Executivo)
- Integração resiliente: um único componente que respeita os limites do ERP, organiza as chamadas, repete sozinho quando necessário e se protege contra falhas em cadeia, sem derrubar o sistema.
- Banco de dados: PostgreSQL (padrão de mercado), com o dado já organizado.
- Backend: Python com FastAPI, preparado para muitas leituras ao mesmo tempo.
- Contrato estável: consulta por CPF ou CNPJ, com resposta padronizada e documentada.
- Custo de licença: US$ 0. Toda a base é open source.
Quando Faz Sentido Investir Nesse Tipo de Solução
Quando NÃO Faz Sentido
Próximos Passos
Se a sua empresa convive com:
- Telas que dependem da API de um ERP na hora, na frente do cliente
- O mesmo código de integração copiado em vários produtos
- Receio de trocar de fornecedor porque "vai quebrar tudo"
- Cada fornecedor falando uma língua diferente de status e valores
Então centralizar a integração em um único módulo transforma um ponto frágil em uma base estável, sobre a qual o resto do produto pode crescer com segurança.
Quer mapear onde o seu produto está dependente de APIs de terceiros? Fazemos uma análise gratuita e mostramos onde estão os pontos frágeis da integração atual, qual o risco de continuar falando direto com o ERP e um plano de centralização que não para o produto.
"Ninguém liga para a usina para acender a luz. Centralizar a integração é construir o interruptor."