29 Apr O que muda com a Reforma Tributária no JD Edwards?
Enquanto o debate público orbita alíquotas e cronogramas legislativos, as equipes de TI e Fiscal que operam o Oracle JD Edwards EnterpriseOne se deparam com uma questão mais específica: quais parâmetros, campos e rotinas do sistema precisam mudar e em que prazo?
O que muda com a Reforma Tributária não é um evento único. Ela avança por fases, cada uma com novos requerimentos que o ERP precisa absorver e validar antes de entrar em produção.
Este artigo detalha as mudanças técnicas trazidas pela Release 26 e os três novos requerimentos que chegam ainda em 2026, além dos dois caminhos disponíveis para adequar o sistema.
Como funciona o calendário de transição da Reforma Tributária?
O novo modelo tributário substitui cinco tributos — PIS, COFINS, IPI, ICMS e ISS — pelo IVA Dual, a CBS (Contribuição sobre Bens e Serviços, de competência federal) e o IBS (Imposto sobre Bens e Serviços, de competência estadual e municipal). Soma-se a eles o IS (Imposto Seletivo), incidente sobre produtos considerados prejudiciais à saúde ou ao meio ambiente.
O período de 2026 a 2032 é de convivência obrigatória entre os dois regimes. Os tributos legados reduzem progressivamente enquanto CBS e IBS crescem na mesma proporção e o JDE precisará calcular, registrar e conciliar os dois conjuntos sobre as mesmas operações simultaneamente, sem margem para inconsistência contábil.
For ERP, esse calendário se traduz em ondas consecutivas de exigências técnicas. A fase inicial foi ativada em janeiro de 2026, com CBS a 0,9% e IBS a 0,1% destacados nas notas fiscais. A próxima onda, com previsão para 2026, torna obrigatórios os requerimentos de Notas de Crédito, Notas de Débito e Eventos Fiscais.
O que muda tecnicamente no processamento de impostos do JDE?
A maior mudança estrutural está na lógica de determinação do imposto.
No modelo anterior, o JDE calculava os tributos pela combinação de CFOP, UF de origem e destino e regime tributário.
Com a Reforma, a Oracle introduziu uma novos critérios de seleção processados para o cálculo dos novos impostos, onde é definido por Natureza de Operação, Perfil do Destinatário e TIpo do Item, a Classificação Tributária e CST para cada um dos novos impostos
Esse novo motor determina automaticamente qual a logica a ser empregada para o cálculo do CBS, IBS e IS e precisa ser parametrizado de forma independente das regras legadas, que continuam vigentes durante o período de convivência.
A segunda mudança relevante está no layout do XML da NF-e. Os novos campos de CBS e IBS são calculados e destacados no documento fiscal, mas em 2026 não compõem o valor financeiro da operação — a chamada lógica de cálculo “por fora”.
Tecnicamente, isso significa que o sistema mantém dois conjuntos de valores em paralelo. Para garantir que esses dois conjuntos não gerem lançamentos contábeis sobrepostos, é necessário configurar Classes Contábeis específicas para CBS e IBS, separados das classes contábeis já existentes para PIS, COFINS e ICMS.
A terceira mudança afeta a conciliação financeira: o split payment.
Quando implementado em sua forma plena, esse mecanismo exige que, no momento da liquidação de um título, o sistema segregue automaticamente a parcela tributária e a direcione para as contas governamentais, entregando ao fornecedor apenas o valor líquido.
As rotinas de pagamento automático do JDE — em especial a Criação do Grupo de Pagamentos — precisarão ser reconfiguradas para suportar essa segregação por transação, com impacto direto nos instrumentos de pagamento e na bank reconciliation.
Há ainda uma mudança técnica pontual, mas de alcance amplo, prevista para julho de 2026: o CNPJ deixa de ser exclusivamente numérico e passa a aceitar caracteres alfanuméricos.
Todas as rotinas do JDE que validam ou formatam o CNPJ, inclusive objetos customizados que interagem com o Cadastro Geral (Address Book), precisarão ser revisadas para suportar o novo formato, sob risco de erros de sistema em cadastros e emissões de notas.
Quais são os novos requerimentos para Notas de Crédito, Débito e Eventos?
A fase inicial resolveu o cálculo e o destaque de IBS e CBS nas operações padrão. Os três requerimentos da tabela a seguir ainda não estão contemplados na maioria dos ambientes JDE ativos e passam a ser exigíveis na próxima etapa da Reforma.
| Application | Como o JDE opera hoje | O que o novo modelo exige | Risco em não atender |
| Credit Notes | Emissão via nota de devolução padrão com PIS/COFINS e ICMS. O vínculo ao documento de origem não é rastreado para fins tributários. | CBS e IBS devem ser calculados e destacados separadamente, com rastreabilidade ao documento de origem para o Comitê Gestor do IBS. A base de crédito precisa refletir os valores da operação original. | Rejeição pela SEFAZ. Crédito de IBS/CBS não aproveitável. |
| Debit notes | Nota complementar de acréscimo sem exigência de vínculo tributário ao documento de origem. | Acréscimos — juros, encargos, complementos de valor — devem referenciar o documento original e destacar CBS/IBS de forma segregada, respeitando a lógica do IVA Dual. | Inconsistência no histórico fiscal junto ao Comitê Gestor, com reflexo na Apuração Assistida. |
| Eventos Fiscais | Não há exigência estruturada de registro de ocorrências tributárias fora do fluxo padrão de NF-e. | Cancelamentos, contingências e situações que afetam débito ou crédito de IBS/CBS precisam ser registrados e comunicados ao Fisco. A localização brasileira do JDE precisará disponibilizar os novos campos para as solutions fiscais terceiras incluírem no SPED, conforme publicação dos leiautes. | Divergências na conta corrente fiscal da empresa, com risco de glosa de créditos futuros. |
Tabela: Novos requisitos fiscais no JD Edwards para 2026 — comparativo entre o comportamento atual do sistema e as exigências do novo modelo tributário.
O elemento técnico crítico nos três requerimentos é a integridade referencial entre o documento fiscal original e os documentos que o complementam ou ajustam.
O JDE precisa garantir rastreabilidade em nível de dado, não apenas no campo de referência do XML, mas nas tabelas de impostos que registram os créditos e débitos de IBS/CBS.
O Fisco utiliza essas informações para preenchimento prévio das guias de recolhimento via Apuração Assistida. Ou seja, qualquer divergência na cadeia documental equivale, na prática, a crédito não aproveitável.
Como atualizar o JD Edwards 9.2 para a Reforma Tributária?
A Oracle disponibiliza as funcionalidades fiscais para o Brasil via ESUs (Electronic Software Updates).
Para a fase inicial da Reforma, quatro ESUs de baseline constituem pré-requisito:
- JN20946, que cobre a infraestrutura da Localization Brazil;
- JN21082, responsável pelo motor de cálculo e pelas regras de negócio;
- JN20168, com melhorias no processamento de notas fiscais;
- JN20429, com atualizações em suprimentos e estoque.
Empresas que ainda não instalaram esse conjunto operam com a base incompleta mesmo para as exigências já vigentes desde janeiro de 2026.
Para os novos requerimentos — Notas de Crédito, Notas de Débito e Eventos Fiscais —, a Oracle prevê a liberação da atualização em julho de 2026.
O processo, no entanto, não se resume à instalação desta nova atualização. Ambientes com customizações em objetos que interagem com a Localização Brasil, como rotinas de geração de XML, contabilização fiscal, relatórios de SPED, exigem análise de impacto antes da aplicação de cada ESU.
O ciclo completo de instalação, testes em ambiente de qualidade, validação dos novos requerimentos e homologação junto à SEFAZ raramente se conclui em menos de dois meses em operações de médio e grande porte. Planejar após a liberação da ESU, portanto, é planejar fora do prazo.
MPL oferece o serviço especializado de configuração e validação para empresas na versão 9.2: aplicação das ESUs com análise de compatibilidade com objetos existentes, parametrização dos novos requerimentos — Notas de Crédito, Débito e Eventos — e testes de compliance em ambiente controlado antes da migração para produção, sem sobrescrever customizações em uso.
Como adequar o JD Edwards se minha empresa utiliza uma versão antiga?
A Oracle não disponibiliza ESUs de Reforma Tributária para versões anteriores à 9.2. Empresas que operam em versões legadas não têm caminho de atualização nativo, mas a obrigação fiscal permanece integralmente.
O Fisco não reconhece a versão do ERP as justificativa para a não conformidade. Assim, Notas de Crédito e Débito emitidas fora do padrão do novo modelo são rejeitadas pela SEFAZ, e Eventos não registrados geram divergências no histórico fiscal que afetam diretamente o aproveitamento de créditos de IBS e CBS.
Customizações extensas, dependências de objetos modificados ou restrições de ambiente também podem impedir a instalação da atualização da Oracle mesmo em empresas que estejam formalmente na versão 9.2. Nesses casos, o caminho é o mesmo, o desenvolvimento específico para o contexto do cliente.
Para esse cenário, the MPL desenvolve e configura solutions customizadas com a mesma cobertura funcional da atualização standard. Tudo integrado à arquitetura existente, sem exigir migração de versão como pré-condição. A solução respeita os objetos já customizados e os processos operacionais em curso.
There are more than 18 projetos de adequação tributária entregues no JD Edwards e relacionamento direto com o board da Oracle para o tratamento de casos que não têm resposta na documentação padrão.
A conformidade técnica não espera o encerramento da lei
A Reforma Tributária impõe sobre o JD Edwards uma responsabilidade que vai além da leitura das normas: exige integridade de dados em cada camada do ERP, da parametrização do motor de cálculo à rastreabilidade dos documentos fiscais complementares. Notas de Crédito, Notas de Débito e Eventos Fiscais são a próxima exigência, e o prazo entre a liberação das atualizações e a obrigatoriedade do compliance não comporta processos de configuração iniciados de última hora.
Quem está na versão 9.2 tem a atualização da Oracle prevista para julho e precisa iniciar o planejamento agora. Quem está em versão legada, ou com impedimento técnico para instalar a ESU, precisa de desenvolvimento específico, cujo ciclo de implementação e validação também demanda antecedência.

Sorry, the comment form is closed at this time.