FireDAC na Prática: conheça meu livro sobre acesso a dados com Delphi

A atualização de um esquema XML pode parecer um ajuste pequeno quando vista apenas como uma mudança de atributo. Em uma integração fiscal, porém, um limite de cardinalidade define até onde um arquivo pode crescer sem falhar na validação estrutural. Por isso, a ampliação do maxOccurs do grupo {infoConta} em dois eventos da Declaração de Regimes Específicos (DeRE) exige atenção tanto de quem desenvolve emissores em Delphi quanto de quem responde pela consistência contábil das informações.

Em comunicado publicado em 21 de setembro de 2026, a Receita Federal do Brasil (RFB) e o Comitê Gestor do IBS (CGIBS) informaram a atualização do pacote técnico de XSD destinado à Produção Restrita — Empresas Piloto. A mudança elevou os limites do evento D-1011, Plano Geral de Contas Comentado, e do D-1101, Balancete Mensal. Os servidores desse ambiente foram atualizados na noite de 21 de setembro, e a recepção oficial de XML com os novos limites começou em 22 de setembro de 2026, conforme o comunicado da RFB no SPED.

Este artigo explica o que efetivamente mudou, separa o fato confirmado das implicações técnicas razoáveis e propõe um percurso de adequação. O ponto central é simples: o XML pode passar a comportar mais ocorrências de {infoConta} nos dois eventos indicados, mas a atualização não altera, segundo a comunicação oficial, regras de negócio, tipos de dados nem os demais campos dos leiautes.

A entrada de IBS e CBS na rotina das empresas optantes pelo Simples Nacional cria uma decisão operacional relevante: manter esses tributos no recolhimento unificado ou optar por sua apuração e recolhimento pelo regime regular. A escolha não equivale a sair do Simples Nacional para todos os tributos, mas altera processos de faturamento, documentos fiscais, apuração, controles de crédito e integração entre empresa, contador e sistema de gestão.

Para quem trabalha com contabilidade, a questão exige leitura cuidadosa das regras e dos prazos. Para desenvolvedores Delphi e equipes de ERP, ela exige modelagem de vigências, separação de cálculos e mecanismos de auditoria que evitem tratar uma opção semestral como simples parâmetro permanente de cadastro. Neste artigo, vamos diferenciar o que está confirmado em fontes oficiais, os pontos que dependem de validação específica e um roteiro prático para preparar pessoas e software.

Uma nota fiscal autorizada não é necessariamente uma nota tributariamente correta. Essa diferença, que já existia antes da reforma tributária, ganha importância com o Código de Classificação Tributária do IBS e da CBS, o cClassTrib. O autorizador consegue verificar se o código existe, se combina com o CST informado e se pode ser usado naquele modelo de documento. Ele não consegue, sozinho, conhecer todos os fatos da operação e decidir se o tratamento jurídico escolhido pelo contribuinte é o adequado.

O tema foi levantado no episódio “cClassTrib: o código que decide o imposto do item na nota”, do Radar Tributário. A ideia central é pertinente: deixar de receber uma rejeição não encerra a análise tributária. Mas algumas expressões usadas no vídeo, como “o código que decide o imposto”, precisam de contexto para não sugerir que um campo isolado substitui a interpretação da operação.

Neste artigo, explico o que o cClassTrib representa, o que as rejeições 1023, 1024 e 1025 realmente verificam, por que o NCM não produz um “de/para” universal e como contabilidade e desenvolvimento podem revisar a parametrização sem transformar uma tabela oficial em piloto automático.

Um sistema Delphi em produção raramente é apenas um conjunto de arquivos-fonte. Ele costuma concentrar regras de negócio acumuladas, integrações pouco documentadas, decisões tomadas sob restrições que já não existem e rotinas que funcionam porque foram ajustadas ao longo de muitos anos. Essa realidade pode gerar duas reações igualmente arriscadas: não mexer em nada ou decidir reescrever tudo.

A primeira conserva problemas conhecidos e reduz, aos poucos, a capacidade de adaptação. A segunda troca riscos visíveis por riscos novos: funcionalidades esquecidas, diferenças de comportamento, longos períodos sem entrega relevante e uma convivência difícil entre o sistema antigo e o substituto em construção. Entre esses extremos há uma disciplina de engenharia: modernizar progressivamente, em mudanças pequenas, verificáveis e reversíveis.

Modernizar não significa aplicar tecnologias recentes a qualquer custo. Significa aumentar a capacidade de entender, alterar, testar, entregar e operar o software com menos incerteza. Em um sistema Delphi, isso pode envolver desde tornar a compilação repetível até reduzir o acoplamento entre formulários VCL, regras de negócio e acesso a dados. O ponto de partida não é uma lista de ferramentas; é um diagnóstico honesto do risco.

Conheça o livro e leia uma degustação: acesse a página oficial de Delphi Vivo.

A adaptação da Nota Fiscal de Serviço eletrônica (NFS-e) aos campos de IBS e CBS exige uma distinção que parece simples, mas tem efeito direto no desenvolvimento de sistemas e na rotina contábil: autorização técnica não é sinônimo automático de conformidade tributária. Uma nota pode passar pelo autorizador sem rejeição sistêmica e, ainda assim, estar sem uma informação que já se tornou obrigatória para aquela operação.

Para equipes que mantêm ERPs em Delphi, integrações fiscais e rotinas de escrituração, essa diferença muda a forma de priorizar o trabalho. Não basta testar se o XML ou a requisição é aceito. É preciso saber para quais operações o preenchimento é exigido, qual ambiente deve emitir o documento e como demonstrar a correção de inconsistências quando elas forem identificadas.

Neste artigo, vamos separar os cronogramas aplicáveis em 2026, explicar o caso particular das microempresas e empresas de pequeno porte do Simples Nacional, traduzir o impacto para software houses e contabilidades e propor um roteiro de implantação. Como os marcos de outubro, novembro e dezembro de 2026 eram futuros na data da pesquisa que embasa este texto, a leitura deve ser prospectiva e acompanhada de revisão normativa antes da entrada em produção.

Sistemas emissores que continuam informando a chave da nota original apenas no grupo NFref estão encontrando um bloqueio concreto na autorização da NF-e de devolução. A SEFAZ já está aplicando em produção a validação que exige a referência dentro do produto de cada item devolvido. Quando o grupo prod/DFeReferenciado não é gerado no det, a nota pode ser recusada pela rejeição 321, identificando o item sem o vínculo exigido.

Não se trata apenas de informar a chave em outro lugar. Para cada produto da devolução, o ERP precisa transmitir a chave do documento de origem e o número que o produto ocupava naquela nota. Isso vale para devoluções parciais e também para a devolução integral: se a nota original possui cem itens e todos estão sendo devolvidos, os cem itens da nova NF-e precisam carregar a própria referência.

Para compreender o contexto mais amplo dessas adaptações, vale consultar o guia do ACBrNFe para a NT 2025.002 e o cronograma de obrigatoriedade dos documentos fiscais na Reforma Tributária. Este artigo se concentra em uma mudança operacional específica: a ligação entre cada item devolvido e o item correspondente do documento original.

Neste artigo, vamos entender por que a devolução está sendo bloqueada, quais dados devem acompanhar cada item, como tratar a devolução integral e como preencher o grupo DFeReferenciado usando o ACBrNFe em Delphi.