Tag: NF-e

A alteração das regras catarinenses para operações com insumos agropecuários exige uma revisão que é, ao mesmo tempo, tributária e tecnológica. Para a contabilidade, o desafio é reconhecer corretamente a hipótese aplicável a cada saída. Para quem desenvolve ou mantém emissores fiscais em Delphi, o ponto é traduzir essa análise em cadastros, regras de decisão, vigências e testes que não simplifiquem indevidamente a operação.

O Decreto nº 1.427/2026, em vigor em 27 de fevereiro de 2026 e com efeitos a partir de 1º de março de 2026, introduziu alterações no RICMS/SC-01, inclusive na disciplina de insumos agropecuários do Anexo 2. A Tabela 5.2A de cBenef da SEF/SC, na versão consultada, passou a apresentar registros novos e também datas finais para registros anteriores.

O percurso deste artigo é deliberadamente prático: primeiro, separar o que muda no direito material do que muda na tabela de códigos; depois, compreender os três tratamentos que não podem ser confundidos — redução de base, isenção e diferimento —; por fim, organizar uma rotina de parametrização e validação para documentos fiscais. A premissa é simples: o cBenef deve decorrer da hipótese fiscal efetivamente enquadrada, e não apenas do nome comercial do produto.

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.

A evolução da NF-e e da NFC-e para acomodar informações relacionadas à CBS e ao IBS exige atenção coordenada de quem desenvolve software e de quem responde pela operação fiscal. Não se trata apenas de incluir campos em telas ou atualizar uma biblioteca de emissão: a preparação pode envolver serialização de XML, regras de negócio, cadastros, tabelas de domínio, testes de autorização e, no caso da NF-e, a geração do DANFE.

O ponto de partida é o Ato Técnico Conjunto nº 8/2026, disponibilizado em 1º de outubro de 2026. Ele aprovou cinco notas técnicas e o Informe Técnico 2025.002 v1.70 para NF-e, modelo 55, e NFC-e, modelo 65. Poucos dias depois, um aviso oficial alterou parte do calendário. Por isso, uma implantação segura começa por distinguir três coisas que frequentemente são confundidas: publicação da documentação, entrada em homologação e ativação em produção.

Neste guia, apresentamos o alcance confirmado do pacote, os cronogramas e os cuidados para ERPs e componentes Delphi. O panorama não substitui a leitura integral das regras de validação e estruturas XML nem os testes de cada emissor.

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.

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.

O sistema foi atualizado, os campos da reforma tributária apareceram na tela e uma nota foi autorizada. Isso demonstra que a emissão funcionou naquele cenário, mas ainda deixa uma pergunta importante: a parametrização representa corretamente as operações da empresa? O Portal Nacional da NF-e esclarece o alcance da autorização de uso: ela envolve verificações formais e de regras de conteúdo, sem transferir ao Fisco a responsabilidade pelo mérito da operação declarada. Por isso, contador e desenvolvedor precisam comparar decisões fiscais, dados do cadastro e informações efetivamente geradas.

A revisão proposta acompanha o caminho da decisão fiscal até a emissão: começa pelo preenchimento do cadastro, verifica a coerência dos códigos e o contexto da operação, confere o XML e a vigência das regras e, por fim, reúne as evidências dos testes. Ao longo desse percurso, é preciso distinguir uma rejeição técnica de um enquadramento fiscal inadequado, pois cada problema exige uma investigação diferente.

O blog já explicou por que uma nota autorizada pode estar tributariamente errada. Aqui, vamos transformar o entendimento em seis cenários de revisão do sistema de gestão empresarial, o ERP. O foco é a Nota Fiscal Eletrônica (NF-e), com fontes conferidas em 13 de outubro de 2026. Os testes propostos são procedimentos didáticos; não representam execução em um emissor real nem homologação de integração.

Se você desenvolve em Delphi e precisa implementar ou atualizar a emissão fiscal do seu sistema, conheça a Loja do Blog do Régys. Lá disponibilizo códigos-fonte de aplicativos para NF-e, NFS-e, CT-e, MDF-e e outras rotinas, que você pode estudar e adaptar ao seu projeto. É uma forma de partir de uma base existente e concentrar seu trabalho nas necessidades dos seus clientes.

Todos os fontes já estão atualizados para a Reforma Tributária, com as adequações correspondentes ao escopo de cada aplicativo. Entre os destaques também estão as atualizações das notas técnicas, a NFS-e Nacional e o CIOT completo com eFrete e os demais provedores suportados pelo ACBr. Esses recursos ajudam a conectar as mudanças fiscais ao trabalho prático de quem mantém sistemas em Delphi.

Acesse a loja, conheça os aplicativos disponíveis e escolha os fontes para o seu projeto. Confira as descrições e as condições de compra para encontrar a opção que atende à sua necessidade. Na continuação deste artigo, apresento os recursos com mais detalhes e explico como avaliar os fontes e as modalidades de suporte antes da aquisição.

Uma orientação sobre o cálculo do ICMS pode exigir mudanças na formação de preços, no faturamento e nos sistemas de gestão. Quando essa orientação envolve tributos novos, o risco não está apenas em errar uma conta: está em usar uma alíquota estimada como oficial, aplicar a fórmula sobre um preço que já contém imposto ou transformar o silêncio de uma Secretaria da Fazenda em autorização para excluir valores.

A discussão para 2027 é a inclusão do Imposto sobre Bens e Serviços, o IBS, e da Contribuição sobre Bens e Serviços, a CBS, na base do ICMS. Não se trata de uma nova alíquota nacional desse imposto. Há manifestações estaduais favoráveis à inclusão, mas documentos diferentes não têm necessariamente o mesmo alcance jurídico.

Este artigo explica os conceitos antes do cálculo, apresenta os percentuais oficialmente documentados e organiza as evidências por UF. O corte das informações é 7 de outubro de 2026. Para o panorama mais amplo de emissão e obrigações, consulte também o guia da reforma tributária em 2027.

Uma nota pode estar autorizada, a venda pode aparecer no contas a receber e o imposto ainda exigir conferência. Esses acontecimentos não são sinônimos. A reforma tributária aproxima documentos e pagamentos, mas continua sendo necessário identificar quando a operação ocorreu, quando o dinheiro foi liquidado e como o débito tributário foi extinto.

O recolhimento na liquidação financeira, conhecido como split payment, é uma das peças desse processo. Ele prevê a separação de valores tributários no fluxo do pagamento. Para quem administra uma empresa ou desenvolve seu sistema de gestão, a pergunta útil não é apenas “qual percentual será retido?”, mas “como explicar o caminho de cada valor?”.

Este artigo considera as fontes consultadas em 5 de outubro de 2026. Explica o conceito, suas implicações e uma proposta de conciliação, sem afirmar implantação universal em uma data não confirmada. O guia da reforma em 2027 contextualiza a transição; o artigo sobre recolhimento pelo adquirente explica um mecanismo diferente.

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 virada para 2027 não será uma simples troca de siglas no sistema fiscal. Empresas precisarão conviver com tributos antigos e novos, revisar cadastros e preços, adaptar documentos eletrônicos e conferir uma apuração cada vez mais dependente da qualidade das informações transmitidas. Para quem desenvolve um sistema de gestão empresarial (ERP) ou orienta uma carteira contábil, o problema começa quando essas mudanças são resumidas a uma frase: “em janeiro muda tudo”.

Não muda tudo ao mesmo tempo, nem da mesma maneira para todos. Algumas obrigações começaram em 2026; outras têm marco em janeiro de 2027; determinadas regras de validação entram depois. Uma nota técnica publicada também não significa que todos os seus campos sejam imediatamente obrigatórios em produção.

Este guia organiza a transição nacional e aprofunda cinco documentos: Nota Fiscal Eletrônica (NF-e), Nota Fiscal de Consumidor Eletrônica (NFC-e), Conhecimento de Transporte Eletrônico (CT-e), Conhecimento de Transporte Eletrônico para Outros Serviços (CT-e OS) e Nota Fiscal de Serviços Eletrônica (NFS-e). O objetivo é permitir que contador, empresa e desenvolvedor localizem a obrigação e a transformem em trabalho verificável.

Data de corte: 5 de outubro de 2026. Datas futuras abaixo são marcos documentados nessa data, não confirmação de implantação real. Regras locais, regimes setoriais e novos atos podem exigir complementação. Este é um guia nacional de consulta, não uma promessa de esgotar todas as situações tributárias possíveis.

Em 29 de setembro de 2026, a Receita Federal e o Comitê Gestor do Imposto sobre Bens e Serviços assinaram o Ato Técnico Conjunto nº 8. O documento aprova versões específicas de notas e informes técnicos aplicáveis à CBS e ao IBS em oito modelos de documentos fiscais eletrônicos. Para empresas de software, escritórios contábeis e contribuintes, trata-se de uma referência formal importante. Também é um texto curto que pode produzir uma interpretação longa e equivocada.

O risco está em ler “documentação aprovada” como sinônimo de “todas as regras obrigatórias imediatamente”. Não é isso que o ato estabelece. Ele identifica quais versões receberam aprovação conjunta, determina onde os documentos serão disponibilizados e vincula seus efeitos à publicação. As datas de homologação, produção e ativação de cada regra continuam nos respectivos documentos técnicos. Este artigo organiza esse mapa, destaca as mudanças mais relevantes e propõe um roteiro para adaptar sistemas sem transformar uma data isolada em cronograma universal.

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.

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.

O Despacho nº 42/2026 do Confaz ganhou relevância imediata porque divulga 13 Ajustes Sinief aprovados na 202ª Reunião Ordinária do conselho, realizada em 4 de setembro de 2026, e publicados no DOU em 14 de setembro de 2026. Para quem desenvolve sistemas fiscais em Delphi, mantém integrações com SEFAZ ou atua na contabilidade operacional, a importância não está apenas na existência dos atos, mas no fato de que eles tratam de documentos fiscais eletrônicos, procedimentos de emissão, rejeição, inutilização e especificações de integração.

Neste artigo, o caminho será o seguinte: primeiro, situar o despacho e o que ele confirma com segurança; depois, organizar os 13 Ajustes Sinief por tema; por fim, traduzir os efeitos práticos possíveis para rotinas de software e de escrituração, sempre distinguindo o que é fato confirmado nas fontes do que ainda depende da leitura integral de cada ato ou de atos técnicos correlatos.

O projeto mcp-brasil (desenvolvido por jxnxts) é um servidor que implementa o Model Context Protocol (MCP), permitindo que IAs como o Claude Desktop consumam dados de 27 APIs públicas brasileiras.

Diferente de uma integração comum de CEP ou CNPJ, este projeto abre as portas para que assistentes inteligentes "entendam" o cenário político, econômico e jurídico do país em tempo real, servindo como uma ferramenta poderosa para sistemas de auditoria e gestão.