Tag: XML

Uma venda de R$ 250,00 com ICMS de 18% tem R$ 45,00 de imposto quando o preço coincide com a base de cálculo. Se esse for o único tributo embutido, sobram R$ 205,00 de valor líquido. Para duas unidades, o líquido unitário fica em R$ 102,50. Esses três números aparecem em partes diferentes do XML, e saber de onde cada um veio facilita tanto a emissão quanto a investigação de uma rejeição.

A Nota Técnica 2026.008 v1.01 introduz campos para identificar o valor líquido do produto ou serviço na NF-e e na NFC-e. Para implementar o leiaute, o primeiro passo é separar a formação do preço, a apuração do imposto e a totalização da nota. Essa distinção fica mais clara ao percorrer a mesma venda com base integral, redução de base e quantidade fracionária.

A Declaração de Regimes Específicos, ou DeRE, passa por uma atualização técnica relevante para quem desenvolve, mantém ou opera sistemas fiscais. A Receita Federal e o Comitê Gestor do IBS (CGIBS) comunicaram a aprovação da versão 1.3.0 da documentação técnica pelo Ato Técnico Conjunto RFB/CGIBS nº 6, de 28 de setembro de 2026. Não se trata apenas de um novo manual: o pacote reúne regras de negócio, tabelas, leiautes XML e esquemas de validação que afetam a preparação, a transmissão e o processamento das informações.

Para escritórios contábeis, áreas fiscais e fornecedores de ERP — inclusive equipes que trabalham com Delphi — o ponto central é transformar a documentação em processos verificáveis. Isso envolve revisar cadastros, plano de contas, geração de XML, tratamento de retornos e rotinas de fechamento. Neste artigo, vamos separar o que foi confirmado oficialmente, o que isso sugere para a arquitetura do sistema e quais cuidados precisam orientar a implantação.

Conferência de 23 de outubro de 2026: o FAQ oficial continua identificado como versão 1.00, de 8 de setembro de 2026. O portal registra alterações em produção restrita em 20 de outubro: reposicionamento de CST/cClassTrib, novos fatos geradores e grupo vAjusteBC. Os anexos e XSD de homologação têm identificação 20261020; isso não deve ser confundido com o catálogo de produção. Consulte Atualizações e Implantações e a documentação de homologação para conferir o ambiente utilizado.

A evolução da NFS-e padrão nacional coloca desenvolvedores, software houses e áreas contábeis diante de uma tarefa que parece simples, mas exige método: distinguir o que é explicação operacional do que efetivamente representa uma mudança técnica aprovada e aplicável ao sistema emissor. Essa diferença importa especialmente na preparação para IBS e CBS, porque uma interpretação precipitada pode gerar desenvolvimento desnecessário, testes no ambiente errado ou comunicação fiscal inadequada ao cliente.

O ponto de partida é o material oficial de Perguntas e Respostas da NFS-e. No Portal consultado, o arquivo disponibilizado está identificado como versão 1.00, de 08/09/2026, e a página de publicação está datada de 16/09/2026. Ele ajuda a navegar por dúvidas sobre temas como cadastro, emissão, XML, APIs e IBS/CBS. Mas seu uso correto depende de reconhecer seus limites documentais.

Este artigo explica por que o FAQ é um instrumento útil de trabalho, como evitar conclusões além das evidências e de que forma equipes Delphi e profissionais da contabilidade podem estruturar uma rotina de conferência entre orientação, documentação técnica e regras fiscais.

Uma devolução pode estar corretamente calculada e, ainda assim, carregar uma referência insuficiente para o autorizador. Se o ERP guarda apenas a chave da nota original no cabeçalho, falta uma informação importante para o novo fluxo: qual item daquele documento está sendo devolvido em cada linha da NF-e atual.

A NT 2025.002 reúne adequações da Nota Fiscal Eletrônica para a reforma tributária, incluindo o Imposto sobre Bens e Serviços (IBS) e a Contribuição sobre Bens e Serviços (CBS). Entretanto, implementar sua versão 1.52 não significa refazer indistintamente todas as funcionalidades previstas desde 2025. O histórico dessa revisão destaca a correção da regra VC02-50 e a mudança de prazo da VC02-14, ambas relevantes para devoluções.

O roteiro deste artigo concentra-se nessas alterações e nas regras próximas necessárias para implementá-las. Vamos acompanhar o vínculo entre os itens, a geração do grupo DFeReferenciado, as verificações de emitente e destinatário e os testes que ajudam a diagnosticar rejeições. A conferência documental considera as versões 1.51 e 1.52 e o comunicado posterior de cronograma, consultados em 14 de outubro de 2026.

Um cliente informa que o produto deve custar R$ 300,00. O sistema precisa emitir a nota, demonstrar os tributos e identificar o valor líquido. Em outra venda, a empresa define primeiro quanto deseja atribuir à mercadoria antes dos tributos e pede ao sistema que forme o preço final. Os dois pedidos parecem semelhantes, mas exigem percursos matemáticos diferentes.

Durante a transição tributária, essa diferença ganha outra camada: Imposto sobre Circulação de Mercadorias e Serviços (ICMS), Imposto sobre Bens e Serviços (IBS) e Contribuição sobre Bens e Serviços (CBS) podem participar da mesma operação com bases distintas. Além disso, o modo de representar um valor no documento fiscal não determina, sozinho, como ele será tributado.

Este artigo explica os cálculos nos dois sentidos, relaciona os resultados aos campos da Nota Fiscal Eletrônica (NF-e) e apresenta critérios para conferir um sistema de gestão empresarial (ERP). O foco é uma venda simplificada, com as premissas expostas. As regras e o cronograma foram conferidos em 14 de outubro de 2026; datas futuras mencionadas correspondem às previsões dos documentos consultados.

Imagine que a equipe já tenha revisado os cálculos tributários do sistema de gestão empresarial (ERP). Mesmo assim, ao adaptar o emissor, surgem outras perguntas: onde gravar os novos valores, em que posição gerar cada elemento XML, quando um grupo pode aparecer e qual rejeição deve ser evitada. Essas decisões pertencem ao contrato técnico do documento fiscal.

A NT 2026.008 acrescenta informações de valor líquido e de ICMS previsto no pagamento antecipado à Nota Fiscal Eletrônica (NF-e) e à Nota Fiscal de Consumidor Eletrônica (NFC-e), com diferenças de aplicação entre os modelos. O trabalho envolve persistência, geração do XML, totalização e testes. Atualizar apenas a tela ou o componente de emissão não garante que todas essas partes continuem coerentes.

Este artigo trata dessas adaptações, sem desenvolver fórmulas de formação ou decomposição de preços. A análise foi conferida em 14 de outubro de 2026, usando a versão 1.00 disponível no catálogo consultado. Datas posteriores são previsões documentais; antes de liberar uma atualização do emissor, é necessário reconferir versão, pacote de esquemas e cronograma aplicável.

Um emissor de NF-e costuma tratar a inscrição estadual como informação indispensável do cadastro da empresa. Retirar essa obrigatoriedade de uma tela, entretanto, não resolve a implementação da NT 2026.007. A ausência da IE passa a participar de decisões sobre o modelo do documento, a identificação do emitente, o serviço autorizador e os grupos tributários enviados no XML.

A versão 1.10 também altera verificações cadastrais e condições dos testes. Isso alcança rotinas que podem estar espalhadas pelo ERP: cadastro de empresas, seleção de endereço de serviço, geração dos itens, recepção de rejeições e registro de eventos. Uma alteração localizada apenas no serializador pode produzir um XML aparentemente coerente, mas incompatível com o fluxo de autorização.

Este artigo apresenta um roteiro de implementação dessas mudanças, com atenção às condições e às exceções de cada regra. O foco é preparar o emissor e a equipe de suporte, sem repetir o panorama das demais notas técnicas. A conferência documental foi realizada em 14 de outubro de 2026 e considera a NT 2026.007 v1.10, a informação técnica da tabela de CFOP e o comunicado posterior sobre o cronograma.

Uma taxa alta de preenchimento pode transmitir a impressão de que uma implantação está quase concluída. Em um sistema empresarial, porém, a presença de um campo é apenas uma das perguntas. Também importa saber quais estabelecimentos o utilizam, em quais operações ele aparece e se o conteúdo representa corretamente o tratamento tributário aplicável.

O balanço divulgado pela Receita Federal em 9 de outubro de 2026 oferece um exemplo dessa diferença. No recorte de empresas obrigadas considerado na notícia, aproximadamente 86% dos documentos traziam destaque da Contribuição sobre Bens e Serviços (CBS). Entre os estabelecimentos emissores daquele universo, cerca de 67% haviam destacado o tributo em todas ou em parte das emissões.

Os percentuais são compatíveis, mas respondem a perguntas diferentes. Este artigo explica essa diferença e mostra como aproveitá-la para avaliar a adaptação de um ERP, sem transformar uma estatística de preenchimento em certificado de conformidade. A consulta foi realizada em 14 de outubro de 2026, preservando o período e as limitações do balanço original.

Uma integração pode transmitir uma mensagem sem conseguir registrar o evento fiscal pretendido. Também pode montar um XML aparentemente coerente com uma tabela e descobrir, na validação, que o esquema publicado exige outro nome de campo. Na manifestação do adquirente da NFS-e Via, esses dois problemas merecem atenção antes de escrever a rotina de envio.

A NT SE/CGNFS-e nº 010, versão 1.00, acrescenta a modalidade de pagamento sem cobrança e os eventos de aceite e rejeição pelo adquirente. Este artigo se concentra na implementação desses eventos: contrato XML, identificação, validação, assinatura, comunicação e acompanhamento. O objetivo é transformar a documentação em um plano técnico verificável, sem repetir a análise normativa e o calendário geral do Ato nº 7.

A conferência considera os arquivos disponíveis em 14 de outubro de 2026, incluindo o pacote de esquemas versão 1.01 atualizado. Foram executados ensaios locais de estrutura e tipos, descritos adiante. Não houve assinatura com certificado real, transmissão à API nem homologação de um XML completo.

Uma atualização fiscal pode chegar ao sistema por caminhos diferentes: um ato aprova documentos, uma nota técnica descreve campos e um comunicado informa quando os ambientes serão atualizados. Quando esses papéis se confundem, a equipe pode implementar uma versão incorreta ou cobrar do cliente uma informação que ainda não está disponível no ambiente utilizado.

O Ato Técnico Conjunto RFB/SUFIS/CGIBS/Diretoria-Executiva nº 7, de 28 de setembro de 2026, reúne duas frentes que precisam ser acompanhadas separadamente: a Nota Fiscal de Serviço eletrônica de padrão nacional, a NFS-e, e a NFS-e Via, voltada à exploração de rodovias mediante cobrança de pedágio. Embora apareçam no mesmo ato, elas possuem documentação, alterações e cronogramas próprios.

Este artigo explica o alcance dessa aprovação, destaca mudanças que afetam cadastros e sistemas empresariais e mostra como organizar a adaptação. As datas e versões refletem a documentação conferida em 14 de outubro de 2026. Como o calendário recebeu atualização nessa mesma data, ele deve ser novamente conferido antes de cada implantação.

A virada para 2027 exige mais do que atualizar duas alíquotas no cadastro fiscal. Um sistema de gestão empresarial, ou ERP, precisa reconhecer a operação, selecionar seu tratamento tributário, emitir o documento correto e acompanhar os efeitos sobre pagamentos, créditos e apuração. Se essas etapas usarem regras de momentos diferentes, o problema pode aparecer apenas no fechamento fiscal, quando corrigir a origem já será mais trabalhoso.

Este artigo reúne os principais pontos para desenvolvedores, equipes fiscais e profissionais de contabilidade planejarem essa implantação. O recorte considera as fontes oficiais consultadas em 7 de outubro de 2026. Obrigações estabelecidas, cronogramas técnicos e recomendações de arquitetura são apresentados separadamente: uma funcionalidade anunciada para testes não equivale a uma exigência geral em produção.

Uma venda de dezembro pode voltar ao depósito em janeiro. Para o cliente, a devolução parece uma reversão simples. Para a empresa, ela atravessa uma mudança de tributos: a operação original pertence a um período e o retorno da mercadoria acontece em outro. Se o sistema recalcular tudo usando apenas as regras da data atual, pode perder justamente a informação necessária para tratar a transição.

A Contribuição sobre Bens e Serviços (CBS) não deve ser usada como uma borracha que apaga o histórico de PIS/Pasep e Cofins. Existe regra específica para bens devolvidos a partir de 2027 relativos a vendas anteriores. O objetivo deste artigo é explicar essa regra e propor um procedimento de conferência, sem transformar um exemplo em receita universal de emissão.

A pesquisa foi encerrada em 5 de outubro de 2026. O guia das obrigações de 2027 apresenta o panorama; aqui, o foco é a ligação entre venda, mercadoria devolvida, documento e crédito. Leia também o procedimento técnico de referência por item na devolução com ACBr, que trata de outra parte do problema.

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 referência de uma NF-e de devolução precisa ser analisada pela versão da regra e pelo ambiente de autorização. A NT 2025.002 versão 1.53 alterou a orientação de exclusividade por item: o documento publicado admite referenciar a chave no cabeçalho ou no item, sem empregar as duas formas simultaneamente. Isso muda o diagnóstico de sistemas que estavam sendo preparados com base nas versões anteriores.

Para o desenvolvedor, o trabalho continua envolvendo a origem dos produtos, a geração correta do XML e os testes do emissor. Este artigo explica as alternativas de referência, a diferença entre o número do item atual e o original e o preenchimento nas classes atuais do ACBrNFe. A operação fiscal e sua tributação devem ser definidas com o responsável contábil.

Atualização de 1º de novembro de 2026: o texto original de setembro afirmava que toda devolução já exigia referência por item em produção e apresentava DFeReferenciado dentro de prod. A revisão corrige essas afirmações à luz da NT 1.53, publicada na SVRS em 30/10/2026, e dos fontes atuais do ACBr. Também esclarece o cronograma: a alteração está prevista para homologação até 09/11/2026 e produção até 16/11/2026; não é apresentada aqui como implantação nacional já concluída. A URL e a data original foram preservadas. A capa permanece uma ilustração conceitual.

A Secretaria Municipal da Fazenda de São Paulo disponibilizou, em setembro de 2026, um novo arquivo XSD para a Nota Fiscal de Serviço eletrônica (NFS-e), com alterações nos campos relacionados ao Imposto sobre Bens e Serviços (IBS) e à Contribuição sobre Bens e Serviços (CBS). Também atualizou o Manual de WebService para a versão 3.3. A notícia parece tratar de uma troca pontual de esquema, mas o efeito para quem mantém um ERP é maior: muda o contrato que define quais elementos podem ser enviados, em que ordem, com quais tipos e sob quais regras de validação.

O cuidado inicial é separar três assuntos que costumam aparecer misturados. São Paulo continuará com seu emissor municipal; o leiaute local está sendo compatibilizado com a reforma tributária; e as obrigações e datas de preenchimento dependem do cronograma oficial vigente. Portanto, baixar o XSD não basta, assim como não é seguro concluir que toda empresa paulistana passou a emitir diretamente no sistema nacional. Este artigo explica o que foi atualizado, como organizar a implementação e quais verificações reduzem o risco de rejeições e divergências fiscais.

O Portal Nacional da Nota Fiscal de Serviço eletrônica publicou, em setembro de 2026, a primeira versão de um documento com mais de 170 perguntas distribuídas em 30 temas. O material nasceu de dúvidas enviadas por municípios, contribuintes e empresas de desenvolvimento e cobre desde ativação municipal, cadastros e erros de CEP até APIs, cancelamento, locação, NFS-e Via e os novos grupos de IBS e CBS. São 125 páginas que mostram uma mudança maior do que a simples troca de um emissor.

A NFS-e nacional tornou-se uma infraestrutura de dados compartilhados. Municípios podem manter emissores próprios ou adotar os emissores públicos nacionais, mas precisam compreender o Ambiente de Dados Nacional (ADN), cadastros complementares, eventos e regras de interoperabilidade. Para as empresas e os ERPs, o desafio é distinguir obrigação de emitir, obrigação de compartilhar e obrigação de preencher os campos da reforma tributária. Este artigo organiza os pontos que merecem ação prática e indica onde a documentação oficial deve prevalecer sobre suposições do sistema antigo.

Preencher um código aceito pelo sistema autorizador não resolve, sozinho, a classificação tributária de uma operação. O desenvolvedor precisa relacionar a decisão fiscal à tabela correta, ao modelo de documento e ao período de vigência. Quando essas etapas ficam misturadas, é fácil transformar um exemplo encontrado na internet em uma configuração permanente, mesmo que o caso real tenha características diferentes.

Este artigo organiza a consulta de CST, cClassTrib e crédito presumido para quem mantém emissores de NF-e em Delphi. A revisão considera o Informe Técnico 2025.002 versão 1.71, publicado em outubro de 2026, e os dados consultados no portal oficial da SVRS em 1º de novembro de 2026. A proposta é mostrar como conferir e manter as informações, sem apresentar uma lista congelada como se ela resolvesse todas as operações ou antecipasse mudanças futuras.

Atualização em 1º de novembro de 2026: foram revisadas as referências às tabelas, retiradas descrições desatualizadas e corrigida a confusão entre Informe Técnico e Nota Técnica. A orientação de que todos os documentos colocariam os campos no mesmo nível também foi removida. O enquadramento de cada operação deve ser sustentado pela legislação e pela análise fiscal, não apenas pela aceitação técnica do XML.

Para adaptar um emissor Delphi à NT 2025.002, não basta acrescentar campos ao cadastro de impostos. É necessário escolher a classificação tributária correta, preencher os grupos correspondentes no ACBrNFe e conferir o XML com as regras aplicáveis à operação e ao ambiente de autorização. Compilar o projeto é uma etapa; gerar um documento coerente é outra.

Este artigo organiza esse trabalho para quem mantém um sistema emissor. O foco é a estrutura de IBS e CBS, os cuidados com a totalização e um roteiro verificável de atualização. O exemplo trata de uma hipótese simples de tributação integral; não é uma configuração fiscal universal para qualquer empresa ou produto.

Atualização de 1º de novembro de 2026: a versão original, de novembro de 2025, citava a NT 1.32. Esta revisão considera a versão 1.53 publicada na SVRS em 30/10/2026 e corrige os códigos de CST, o exemplo de classificação, a posição dos campos e a orientação de somar os novos tributos em 2026. As URLs e a data original foram preservadas. A capa é uma ilustração conceitual já pertencente ao blog, não uma captura de um sistema fiscal.