Trust-Code fechou: como migrar da localização Trustcode para OCA l10n-brazil

A Trust-Code (trustcode.com.br), no início da era Odoo 8.0, forkou a localização brasileira da OCA e seguiu um caminho próprio em Trust-Code/odoo-brasil — desenvolvimento paralelo, sem contribuir de volta para a OCA. Foi uma decisão que prejudicou o ecossistema da localização brasileira do Odoo e prendeu os clientes a uma única empresa. Quando a Trust-Code encerrou, o desfecho foi previsível: dezenas de clientes ficaram com Odoo em produção sem mantenedor, sem roadmap, e com cada nota técnica nova da SEFAZ virando um problema individual.

Este é o risco central de adotar localização fechada ou fork da OCA — e a lição comercial mais importante deste post. Não é teoria: aconteceu, está acontecendo e vai voltar a acontecer com qualquer cliente que confiar a localização fiscal a um único fornecedor que não devolve o código para a comunidade.

Este post é para quem está nessa situação: o que de fato você herdou, quais são os caminhos realistas, e por que a migração para a OCA l10n-brazil é a única que devolve sustentabilidade à operação.

O que era o fork Trustcode

Por volta do Odoo 8.0 a localização brasileira da OCA ainda estava em formação. A Trust-Code optou por forkar a localização da OCA e seguir um caminho próprio em repositório separado, com seu próprio conjunto autoral: cálculo de impostos, NF-e, NFS-e (vários providers prefeitura), CT-e, integração com APIs bancárias, account brasileiro. Era funcional para o nicho de implantação direta da Trust-Code, mas — e este é o ponto que pesa hoje — o desenvolvimento seguiu paralelo, sem contribuir de volta para a OCA. As correções, melhorias e novos módulos ficavam no fork; a OCA seguia o seu próprio rumo, evoluindo sem absorver o que era feito do outro lado.

O problema não foi o fork em si — foi o que ele virou ao longo dos anos:

• Divergência crescente, sem reconciliação. Enquanto a OCA reescreveu o motor fiscal (l10n_br_fiscal) para isolar regras tributárias do account.move, o fork Trust-Code seguiu evoluindo o desenho original de 2014. Os dois mundos nunca foram reconciliados — não há sequer caminho de migração público entre eles.
• Migração de versão como projeto isolado. Cada salto (8 → 10 → 12 → 13) no Trust-Code era uma migração paralela à da OCA, feita com recursos próprios. Cliente parado em 12 ou 13 hoje não tem rota oficial pública para 16/17/18.
• Dependência forte da equipe. O conhecimento de “por que esta linha existe” estava na cabeça dos desenvolvedores da Trust-Code. Quando o time se desfez, o repositório ficou sem alguém que decida o que pode quebrar.
• Notas técnicas SEFAZ não absorvidas. Cada NT (manifesto, EFD, ajustes de validação de schema, BCB para Pix) precisa de alguém para implementar e testar. Sem mantenedor, isso simplesmente não acontece.

Se você abrir o GitHub Trust-Code/odoo-brasil agora e olhar a frequência de commits, a história fica visível por si só.

O que isso significa em produção

Quem opera hoje em cima do Trustcode normalmente convive com algum subset destes sintomas:

• Atualização de versão Odoo congelada. Você tem Odoo 12 ou 13 e o caminho para 16/17 não existe — porque o fork não foi para frente.
• Notas técnicas atrasadas. NT da SEFAZ que mexe em schema XML, validações ou rejeições é resolvida na “raça” pelo time interno ou por consultor freelancer.
• Reforma Tributária 2026 sem rota. IBS/CBS/IS exigem mudança estrutural no motor fiscal. A OCA já tem PRs ativos cobrindo isso. O fork Trustcode, não.
• EFD/ECD/ECF parcial ou inexistente. A escrituração nunca foi forte no Trustcode (o foco sempre foi documento eletrônico). Empresas que precisam de SPED contábil completo já operam com workaround externo.
• eSocial e Reinf fora do escopo. O fork nunca cobriu folha + eSocial. Quem precisa, montou stack paralela.
• Risco fiscal acumulado. Cada bug de cálculo (ICMS-ST, DIFAL com FCP, retenção na fonte) que não foi corrigido upstream é risco que cresce com o tempo.

Se sua empresa está em qualquer um desses pontos, adiar a migração é o caminho mais caro. Não pelo custo do projeto em si, mas pelo custo de operar sem rede de suporte enquanto a SEFAZ continua publicando NTs.

Por que OCA, e não outro fork ou localização fechada

A OCA (Odoo Community Association) é a infraestrutura comunitária que substituiu, na prática, o modelo de “cada integradora mantém o seu”. Os principais argumentos:

1. Você nunca fica refém de um fornecedor. Esse é o argumento central. Com o código no upstream da OCA, trocar de integradora é uma decisão comercial, não um drama técnico. Qualquer parceiro OCA pega de onde o anterior parou. Em fork fechado, sair custa o mesmo que migrar — porque é migrar.
2. Mantenedores múltiplos e independentes. A comunidade open-source — com a KMEE entre as mantenedoras principais — revisa PRs no mesmo repositório. Se uma empresa some, o código continua. Já aconteceu antes (Trust-Code), e o l10n-brazil seguiu rodando.
3. Versão sempre atual. O l10n-brazil tem branches ativas para 14, 16, 17 e 18. Cada salto de Odoo é tratado como tarefa coletiva, com cobertura pela comunidade.
4. Padrão de qualidade da OCA. PRs precisam ter testes automatizados, descrição em inglês, pre-commit (black, isort, flake8), runbot verde. O bar técnico é mais alto do que o de qualquer fork privado.
5. Notas técnicas SEFAZ entram em dias. Quando o BCB ou a SEFAZ publica NT, normalmente em poucos dias há PR aberto na OCA. KMEE costuma estar entre os primeiros — temos 22.000+ linhas de EFD PIS/COFINS em PR ativo, e o módulo de eSocial autoral foi doado para o l10n-brazil.
6. Reforma Tributária 2026 já em andamento. IBS, CBS e IS estão sendo modelados na OCA. Quem está em OCA hoje vai herdar isso de graça; quem está em fork legado vai precisar reescrever.
7. Sem custo por documento. A localização da Odoo SA cobra Avalara por NF-e/NFS-e emitida. A OCA, não — você emite contra seu próprio certificado A1, sem percentual sobre transação.

Esses pontos estão detalhados na nossa LP de localização fiscal brasileira.

O caminho técnico de migração

Migrar de Trust-Code para OCA não é “trocar o módulo e seguir”. O motor fiscal é diferente. As tabelas de mapping (CFOP, CST, NCM, regime tributário) estão em modelos diferentes. Lançamentos contábeis foram feitos por uma lógica que não vai casar 1:1 com a nova.

A metodologia que usamos na KMEE para migrar clientes de localizações de terceiros (Trust-Code, integradoras que fecharam, forks privados) tem 5 etapas:

1. Diagnóstico fiscal e contábil

Levantamento de:

• Versão Odoo atual e versão dos módulos Trustcode em uso
• Customizações em cima do fork (sempre tem)
• Volume de documentos fiscais por mês (NF-e, NFC-e, NFS-e, CT-e, MDF-e)
• Estado de SPED (EFD ICMS/IPI, EFD Contribuições, ECD, ECF)
• Necessidade de eSocial/Reinf
• Integrações externas (bancos, marketplaces, antifraude)

O entregável é um diagnóstico com escopo de migração e estimativa.

2. Plano de migração de dados

Definimos:

• Cadastros que migram 1:1 (parceiros, produtos com NCM/CEST, contas bancárias)
• Cadastros que precisam de mapping (CFOP, CST/CSOSN, regimes tributários, modelos fiscais)
• Saldos contábeis (a serem importados como abertura na nova base)
• Histórico de movimentação de estoque
• XMLs de NF-e emitidas (preservados para fiscalização — SPED não exige re-emissão, mas exige consulta)

3. Setup OCA na versão alvo

Recomendação atual (maio de 2026): Odoo 16 + OCA l10n-brazil 16.0, que tem 62 módulos cobrindo o ecossistema fiscal completo. Versões 17/18 ainda têm gaps em account/sale/purchase brasileiros.

Setup envolve:

• Instalação do l10n_br_fiscal (motor) + módulos de documento eletrônico
• Configuração do certificado digital A1
• Provider NF-e (varia por estado/município) e NFS-e (varia por prefeitura)
• Plano de contas brasileiro (l10n_br_coa_generic)
• Mapping de CFOPs, CSTs, NCMs do cliente

4. Migração assistida com paralelo controlado

Não viramos a chave em produção em um sábado. O padrão é:

• Período de paralelo de 1 a 3 meses, com Odoo+OCA recebendo mesma operação do Odoo+Trustcode legado
• Conferência de NF-e geradas nos dois sistemas (mesmo XML semântico esperado)
• Validação de SPED gerado no novo ambiente vs validador SEFAZ
• Treinamento do time fiscal em paralelo

Quando o paralelo está estável e o time confia no novo, a virada é planejada (normalmente fim de mês fiscal).

5. Suporte pós-virada com SLA

Os primeiros 90 dias pós-virada são os mais sensíveis. Cobrimos com SLA dedicado e canal direto com o time fiscal e contábil. Depois, entra o ciclo normal de squad/suporte mensal.

Não está na Trust-Code mas tem fork de outra integradora

A mesma metodologia se aplica a quem está em fork de qualquer outra integradora que fechou ou abandonou o roadmap. Já migramos clientes que estavam em:

• Forks privados de consultores autônomos sem manutenção
• Instâncias com módulos brasileiros pseudo-OCA, mas customizados de forma incompatível
• Implantações antigas de outras integradoras nacionais que descontinuaram suporte

O denominador comum é o mesmo: tirar o cliente da dependência de um único fornecedor e devolver para o ecossistema OCA, onde o código é coletivo e tem múltiplos mantenedores.

Quanto tempo leva

Depende do volume e da complexidade fiscal, mas em média:

Porte	Documentos/mês	Customizações	Tempo estimado
Pequeno	até 200 NF-e	poucas	2–3 meses
Médio	200–2.000 NF-e	médias	4–6 meses
Grande	2.000+ NF-e, multi-CNPJ	extensas	6–12 meses

Saltos de muitas versões (Odoo 12 ou 13 → 16) são tratados como migração estrutural, não upgrade. Tentar passar via --update all pulando versões em produção fiscal é receita para perder dados e travar emissão.

Por que a KMEE

Há mais de uma década co-mantemos a OCA l10n-brazil. Isso significa:

• Conhecemos a mecânica interna do motor fiscal — não estamos aprendendo enquanto migramos
• Quando aparece bug em campo, conseguimos corrigir upstream e devolver para a comunidade no mesmo ciclo
• Temos histórico documentado de migrações partindo de Trust-Code, TOTVS, SAP B1, Sankhya, Senior, Omie e ContaAzul
• O time fiscal/contábil/RH da KMEE já operou em paralelo a virada de cliente real — não é primeira vez

E, importante: depois da migração, você não fica refém da KMEE. Como o código fica no upstream da OCA, qualquer outra integradora OCA pode assumir o suporte se um dia você quiser trocar. É exatamente o oposto da experiência Trust-Code — e essa é a única forma honesta de comprar uma localização fiscal hoje no Brasil.

Se sua empresa está em Trust-Code, em outro fork descontinuado, ou em qualquer localização fechada / fechada-com-roupa-de-aberta, agende um diagnóstico em /contato/. Levamos cerca de 1 hora para entender seu cenário e devolver um plano de migração com escopo, prazo e riscos transparentes.

A OCA l10n-brazil está viva, com release ativo e múltiplos mantenedores. Não dá para passar Reforma Tributária em fork morto — e não vale a pena entregar de novo a sua localização fiscal a uma única empresa que pode sumir no próximo ciclo.