A Trust-Code fechou.
Sua operação fiscal não pode parar.
A Trust-Code mantinha um fork da localização brasileira do Odoo desde a 8.0. Com o encerramento da empresa, dezenas de clientes ficaram com Odoo em produção sem mantenedor, sem roadmap e sem rota para a Reforma Tributária 2026. A KMEE migra para OCA l10n-brazil com método e SLA.
O que era o fork Trust-Code
No início da era Odoo 8.0, a Trust-Code (trustcode.com.br) 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 o repositório upstream. Foi uma decisão que prejudicou o ecossistema — fragmentou o esforço da localização brasileira e amarrou os clientes a uma única empresa.
Com o encerramento da Trust-Code, o resultado previsível aconteceu: o repositório ficou sem mantenedor, cada nota técnica nova da SEFAZ virou um problema individual de cada cliente, os saltos de versão (12 → 13 → 16) pararam, e a Reforma Tributária 2026 — que exige mudança estrutural no motor fiscal — não tem rota.
A lição, para quem está escolhendo Odoo no Brasil hoje, é direta: quem fica com localização fechada ou fork de uma única empresa fica refém. Quando essa empresa some, ou simplesmente decide não investir mais, o cliente fica desamparado. Quando você está no código upstream da OCA, troca de fornecedor sem trauma — o código continua o mesmo, qualquer integradora OCA pode pegar de onde a anterior parou.
O que isso significa em produção hoje
Versão Odoo congelada
Empresa parada em Odoo 12 ou 13 sem rota oficial para 16/17/18, porque o fork Trust-Code não acompanhou os saltos de versão da OCA.
Notas técnicas atrasadas
Cada NT da SEFAZ que mexe em schema XML, rejeição ou validação vira problema individual resolvido na raça pelo time interno ou freelancer.
Reforma Tributária sem rota
IBS/CBS/IS exigem mudança no motor fiscal. A OCA já tem PRs ativos. O fork Trust-Code, não — e o tempo está acabando.
SPED parcial ou inexistente
EFD ICMS/IPI, EFD Contribuições, ECD e ECF nunca foram fortes no Trustcode. Empresas operam com workaround externo ou ficam expostas em fiscalização.
eSocial e Reinf fora do escopo
O fork nunca cobriu folha + eSocial. Quem precisa montou stack paralela. A OCA hoje tem módulo autoral KMEE de eSocial completo.
Risco fiscal acumulado
Bugs de cálculo (ICMS-ST, DIFAL com FCP, retenção na fonte) que não voltaram para o upstream se acumulam — e o passivo cresce com o tempo.
Onde os dois mundos divergem
| Critério | Trust-Code (fork) | OCA l10n-brazil |
|---|---|---|
| Mantenedores ativos | Encerrada | Comunidade open-source com KMEE entre as mantenedoras principais |
| Branches Odoo suportadas | Última: 13 | 14, 16, 17, 18 ativas |
| Rota Reforma Tributária 2026 | Não existe | PRs IBS/CBS/IS em desenvolvimento |
| Notas técnicas SEFAZ | Sem absorção | Absorvidas em dias por mantenedores |
| EFD ICMS/IPI + Contribuições | Parcial / inexistente | 62 módulos, EFD em PR ativo (KMEE) |
| ECD + ECF | Não cobre | ECD nativo (v16); ECF em desenvolvimento |
| eSocial + Reinf | Fora do escopo | Módulo autoral KMEE em produção |
| CT-e / MDF-e | Cobertura básica | Nativo, completo |
| Padrão de PR (testes, runbot) | Sem CI público | Pre-commit, runbot, code review obrigatório |
| Custo por documento | Zero (mas sem suporte) | Zero (com suporte ativo) |
| Acesso ao código | GitHub público (estagnado) | GitHub OCA — vivo, AGPL/LGPL |
5 etapas para migrar com segurança
Diagnóstico fiscal e contábil
Levantamento de versão Odoo atual, customizações em cima do fork, volume de documentos fiscais por mês, estado de SPED e necessidade de eSocial/Reinf. Entrega: plano de migração com escopo e estimativa.
Plano de migração de dados
Definição do que migra 1:1 (parceiros, produtos com NCM/CEST), do que precisa mapping (CFOP, CST/CSOSN, regimes), saldos contábeis como abertura, histórico de estoque, e XMLs preservados para fiscalização.
Setup OCA na versão alvo
Recomendação atual: Odoo 16 + OCA l10n-brazil 16.0 (62 módulos production-ready). Instalação de l10n_br_fiscal, configuração do certificado A1, providers NF-e/NFS-e por estado/prefeitura, plano de contas brasileiro.
Paralelo controlado
1 a 3 meses operando os dois sistemas em paralelo, com conferência de NF-e gerados nos dois ambientes, validação SPED contra validador SEFAZ, e treinamento do time fiscal antes da virada.
Suporte pós-virada com SLA
Primeiros 90 dias com SLA dedicado e canal direto para o time fiscal e contábil. Depois, ciclo normal de squad/suporte mensal.
Localização fechada ou fork prende cliente. Localização OCA, não.
A KMEE já trouxe para OCA clientes em situações análogas:
- Forks privados de consultores autônomos sem manutenção
- Instâncias com módulos pseudo-OCA customizados de forma incompatível
- Implantações antigas de integradoras nacionais que descontinuaram suporte
- Localizações de terceiros descontinuadas em qualquer versão (8, 10, 12, 13)
Quando o seu Odoo está com o código upstream da OCA, trocar de fornecedor é uma decisão comercial, não um drama técnico. Qualquer integradora OCA pode pegar de onde a anterior parou — o código é o mesmo. É exatamente o oposto da experiência de quem fica preso em fork: lá, sair custa o mesmo que migrar, porque é migrar.
Esse é o critério que o cliente brasileiro deveria aplicar antes de comprar qualquer localização fiscal Odoo: esse código volta para a OCA? Se não volta, você está comprando um problema futuro.
Perguntas frequentes
Por que a Trust-Code fechou impacta meu Odoo em produção?
Porque o fork Trust-Code (Trust-Code/odoo-brasil no GitHub) era mantido pela equipe da empresa e nunca contribuiu de volta para a OCA. Sem mantenedor, novas notas técnicas da SEFAZ não são absorvidas, bugs reportados não voltam upstream, e a Reforma Tributária 2026 não tem rota. Você fica preso na versão atual sem caminho oficial para frente — esse é o risco central de adotar localização fechada ou fork: quando o fornecedor sai, o cliente fica desamparado.
Se eu migrar com a KMEE, vou ficar refém da KMEE?
Não. Esse é o ponto principal de migrar para OCA: o código fica no upstream público (github.com/OCA/l10n-brazil), com licença AGPL/LGPL e múltiplos mantenedores. Se um dia você decidir trocar de integradora, qualquer outra empresa que trabalhe com OCA assume o suporte sem trauma, porque o código é o mesmo. Quem comprou localização fechada ou fork passa pelo cenário oposto e fica preso ao fornecedor.
Posso continuar usando o fork Trust-Code mesmo sem suporte?
Tecnicamente, sim — o repositório no GitHub permanece público sob licença open source. Na prática, você assume integralmente o risco fiscal: cada NT da SEFAZ vira tarefa interna ou contratação pontual, e a Reforma Tributária 2026 vai exigir reescrita do motor fiscal que ninguém vai fazer no fork. É um custo crescente com horizonte conhecido.
Qual a diferença prática entre o fork Trust-Code e a OCA l10n-brazil?
A Trust-Code partiu de um desenho de 2014 e seguiu seu próprio caminho. A OCA reescreveu o motor fiscal (l10n_br_fiscal) para isolar regras tributárias do account.move, criando uma arquitetura que escala. Hoje os modelos de dados são incompatíveis na prática: migrar significa refazer o mapping fiscal e contábil, não só trocar módulo.
Quanto tempo demora a migração?
Depende do volume e da complexidade fiscal. Pequeno porte (até 200 NF-e/mês) leva 2–3 meses; médio (200–2.000 NF-e) leva 4–6 meses; grande (2.000+ NF-e, multi-CNPJ) leva 6–12 meses. Saltos de muitas versões (12/13 → 16) são tratados como migração estrutural, não upgrade.
Mantenho meus XMLs históricos e SPED de períodos anteriores?
Sim. XMLs de NF-e emitidas ficam preservados (a SEFAZ não exige re-emissão, mas exige consulta). SPED de períodos anteriores também — fica disponível para fiscalização posterior. A migração trata novos documentos no novo ambiente; o passado fica acessível.
E se eu não estiver na Trust-Code, mas em outro fork brasileiro descontinuado?
A mesma metodologia se aplica. Já migramos clientes vindos de forks privados, instâncias pseudo-OCA customizadas e implantações de outras integradoras que descontinuaram. O denominador comum é 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.
Vocês fazem upgrade direto de Odoo 12 Trustcode para Odoo 18 OCA?
Não recomendamos pular muitas versões em uma migração só. Em maio de 2026 a versão estável e production-ready da OCA é 16.0. Versões 17 e 18 ainda têm gaps em módulos account/sale/purchase brasileiros. Migrar para 16 hoje, com 17/18 vindo no roadmap, é o caminho de menor risco.
Quanto custa?
Não há licença por usuário ou por documento. Você paga implantação (escopo definido após diagnóstico), suporte mensal contínuo e infraestrutura. Tarifas de Pix/boleto são as do seu banco — não cobramos percentual sobre transação.
Está em Trust-Code ou em outro fork descontinuado?
1 hora de diagnóstico, plano de migração com escopo, prazo e riscos transparentes. Sem compromisso.