Diego.Foliene

Olá comunidade ! Foi publicada a versão 1.01 desta nota técnica. Alterações Esta versão compatibiliza os códigos dos meios de pagamento conforme a tabela já existente e utilizada pela NF-e. A NT também trás algumas observações: Não há exigência de preenchimento ou uso dos campos de split payment em 2026 no ambiente de produção das empresas. A ativação efetiva desses campos ocorrerá somente quando o mecanismo de split payment entrar em vigência, prevista para 2027. Orientações adicionais e cronogramas serão divulgados oportunamente por meio dos canais oficiais do CGIBS e da RFB Datas As datas permanecem as mesmas da versão anterior. Leia a versão 1.01 desta nota técnica na íntegra AQUI.

Olá comunidade ! Foi publicada a versão 1.01 desta nota técnica. Alterações Esta versão compatibiliza os códigos dos meios de pagamento conforme a tabela já existente e utilizada pela NF-e. A NT também trás algumas observações: Não há exigência de preenchimento ou uso dos campos de split payment em 2026 no ambiente de produção das empresas. A ativação efetiva desses campos ocorrerá somente quando o mecanismo de split payment entrar em vigência, prevista para 2027. Orientações adicionais e cronogramas serão divulgados oportunamente por meio dos canais oficiais do CGIBS e da RFB Datas As datas permanecem as mesmas da versão anterior. Leia a versão 1.01 desta nota técnica na íntegra AQUI.

Olá comunidade ! No dia 04/02/2026 foi publicada a nota técnica 2026/001 para o BP-e trazendo informações sobre a vinculação de pagamentos ao DFe. Essa vinculação se faz necessária para que o processo de Split Payment Inteligente seja executado. É importante ressaltar que o vínculo indicado pelo contribuinte não necessariamente representa um pagamento efetuado e liquidado. Indica uma expectativa de pagamento que pode ou não se concretizar. Por exemplo: um boleto pode ser emitido e não pago. Alterações Adiciona no BP-e um "Grupo de informações da vinculação com a transação de pagamento" com a seguinte estrutura: <pgtoVinc> <pgto> <nPag></nPag> <idTransacao></idTransacao> <tpMeioPgto></tpMeioPgto> <CNPJReceb></CNPJReceb> <CNPJBasePSP></CNPJBasePSP> </pgto> </pgtoVinc> Cria o "evento de vinculação da transação de pagamento com o DFe - 110300" com estrutura semelhante ao grupo da vinculação e seu respectivo evento de cancelamento. Adiciona regras de validações para os novos campos e para o evento. Datas Implantação Homologação: 06/04/2026 Implantação Produção: 04/05/2026 E como fica o ACBr? Modificações no ACBr serão necessárias para atender a esta nota técnica. Foi criada a tarefa ACBR-9096 para a adequação das soluções ACBr. Leia a nota técnica na íntegra AQUI.

Olá comunidade ! Como todos sabem, desde o dia 01/01/2026 não é mais permitido a emissão de Cupons Fiscais Eletrônicos (CF-e) através do SAT (Veja mais sobre isso AQUI). Foi publicado no Portal do SAT orientações sobre como os contribuintes que emitiram CF-e indevidamente depois de 31/12/2025 devem proceder: ATENÇÃO - 02/03/26 - TRATAMENTO A SER DADO PARA CF-e-SAT EMITIDO APÓS 31/12/2025 Os contribuintes que emitiram CF-e-SAT após 31/12/2025 deverão proceder como segue em relação a esses CF-e-SAT: 1- se SN: declarar os valores devidos na PGDAS-D; 2- se RPA: escriturar regularmente esses documentos na EFD do ICMS/IPI; 3- proceder com o recolhimento do imposto devido nos prazos regulamentares (ou com os acréscimos legais, se aplicável), garantindo a inexistência de prejuízo ao erário. Realizar denúncia espontânea via SIPET, serviço "Denúncia espontânea", e utilizar um dos modelos SN ou RPA.

Hmmm, acho que entendi o seu ponto. Se eu tiver o opSimpNac com a opção 1 de Não Optante a menos que eu explicitamente defina indTotTrib com valor indSim, ao invés de gerar as tags do vTotXXX zeradas ele sempre vai cair na geração dessa tag e isso vai devolver o E0713. Mas nesse caso não adianta eu mudar a condição de geração da tag usando indNao seja para = ou <>. E mudar ela para considerar indSim deixaria a lógica no mínimo estranha levando em conta que é o valor de indNao que ele usa para gerar a tag. Enviei ao SVN na Rev-45204 um ajuste alterando a inicialização desse valor. Ao invés de sempre começar com indNao por default, agora vai começar com indSim. Por favor, atualizem seus fontes, reinstalem o ACBr com a opção "Apagar Arquivos Antigos" e façam novos testes. Ficamos no aguardo de um retorno.

Boa tarde pessoal! Essa é a relação de conversão, ou seja, o enumerado e o valor que gera no XML: indNao => 0 indSim => 1 Se abrirmos o arquivo AnexoVI-LeiautesRN_RTC_IBSCBS-V1.03.00 – NT007.xlsx, podemos ver que o único valor válido para este tag é zero. Então na verdade é o contrário, essa tag só pode ser gerada quando o valor de indTotTrib for igual a indNao. Por isso a validação usa <> indSim para definir se deve gerar a tag indTotTrib ou se deve tentar gerar as tags de valores. Para a tag pTotTribSN, se pesquisarmos no mesmo arquivo por essa tag na planilha RN DPS_NFSe, podemos ver apenas duas rejeições atrelas a essa tag. Caminho no XML Campo Regra Efeito Código Msg. Erro NFSe/infNFSe/DPS/infDPS/valores/trib/totTrib/ pTotTribSN Se a situação do emitente da DPS perante o Simples Nacional na data de competência informada for Não Optante, indTotTrib e pTotTribSN nunca poderá ser informado. Rej. E0713 Para Não Optante do SN os campos, indicador de informação de valor total de tributos e percentual aproximado do total dos tributos da alíquota do Simples Nacional (%), não podem ser informado. Se a situação do emitente da DPS perante o Simples Nacional na data de competência informada for MEI, o choice pTotTribSN nunca poderá ser informado. Rej. E0710 Para MEI pTotTribSN nunca poderá ser informado. Observem que em ambos os casos, na mensagem de erro é mencionado o valor de opSimpNac. A primeira diz: "Para não Optante do SN" => Entendemos aqui opSimpNac com valor 1 - Não Optante "(...) percentual aproximado do total dos tributos da alíquota do Simples Nacional (%) não pode ser informado" => Entendemos como o campo pTotTribSN não pode ser informado. A segunda diz: "Para MEI" => Entendemos aqui opSimpNac com valor 2 - Optante - Microempreendedor Individual (MEI); pTotTribSN nunca poderá ser informado => Campo de mesmo nome não deve ser informado. Com essa interpretação, entendemos que apenas quando o valor de opSimpNac for igual "2 - Optante - Microempreendedor Individual (MEI);" é que o grupo pTotTribSN deverá ser gerado. Por isso a condição if (NFSe.OptanteSN = osnOptanteMEEPP) then nos fontes para a geração dessa tag. Eu fiz um teste em meu ambiente e a tag pTotTribSN foi gerada corretamente. Por favor, revisem suas rotinas para confirmarem o correto preenchimento das informações. Se alguém tiver um arquivo XML de uma NFS-e autorizado pelo ambiente nacional que contradiga a interpretação prévia dessas regra e justifique a alteração no código, peço que disponibilize o mesmo para análise através de tópico na Área Privada do Fórum

Bom dia a todos. Foi criada a tarefa ACBR-8093 para tratar do caso. Assim que houver novidades vamos reportar aqui.

Olá comunidade ! Foi publicado Boletim Informativo pela Sefaz do Paraná reforçando que a partir de 01/04/2026, será obrigatório informar Código de Segurança do Responsável Técnico – CSRT nas notas fiscais eletrônicas modelo 55 emitidas em produção. Um agradecimento aos membros de nossa comunidade @armando.boza e @Victor H. Gonzales - Panda por compartilharem a informação. Vale reforçar que os membros da comunidade que são PRO e Corporativo tem acesso ao curso:

Olá comunidade ! Foi publicada a versão 1.30 da nota técnica 2022/002. Esta versão traz alterações no leiaute e também nas regras de validação da Sefaz visando flexibilização. Alterações Adiciona os novos valores válidos para o "motivo da desoneração do ICMS" (tag motDesICMS no arquivo XML). O grupo de Partilha de ICMS entre a UF de Origem e a UF de Destino (tag ICMSPart no arquivo XML) agora também pode receber o CST 20. Adiciona uma tag cBenefRBC para receber o "Código de Benefício Fiscal na UF aplicado ao item quando houver RBC". O grupo de ICMS20 ganhou campos para informação de valores de diferimento e diferimento do FCP. O grupo de ICMSPart ganhou campos para receber as informações de desoneração. As regras de validação E03a-10, E12-10, E14-10 e E16a-20 que verificam operação com o exterior ganharam uma exceção para não serem aplicadas quando CFOP for igual a 7552 ou 7501. A regra BA02a-10 que permite referenciar chave de acesso com o código numérico zerado foi atualizada para permitir também quando a nota for de ajuste. Datas Implantação Teste: Até 30/03/2026 Implantação Produção: Até 06/04/2026 E como fica o ACBr? Como a nota técnica traz alterações no leiaute, modificações nas soluções ACBr serão necessárias. Foi criada a tarefa ACBR-9067 para esta finalidade. Leia a versão 1.30 desta nota técnica na íntegra AQUI. Um agradecimento ao membro de nossa comunidade @Felipe Mariano por compartilhar a informação no canal #sefaz em nosso servidor do Discord.

Olá comunidade ! Conferindo no Portal da Nota Fiscal Eletrônica é possível observar que a Sefaz de São Paulo está com contingência agendada para o dia 08/03/2026, com previsão de início às 06h00 e término às 13h00 do mesmo dia. Para utilizar as soluções ACBr em contingência durante esse período siga as orientações do tópico abaixo: Um agradecimento ao membro de nossa comunidade @Felipe Mariano por compartilhar essa informação no canal #sefaz em nosso servidor do Discord.

Olá comunidade ! Conferindo no painel Situação SVC no dia 02/03/2026 às 11h24 é possível observar que a contingência para o estado de Goiás prevista até 20/03/2026 consta como desativada:

Olá comunidade ! Foi publicado o Correio Eletrônico Circular SEF/DIAT/Nº 04 / 2026 atualizando as tabelas 5.1.1, 5.2 e 5.3 da EFD. Em cumprimento do art. 1º e parágrafo único do art. 2º do Ato DIAT nº 073/2022 e art. 1º do Ato DIAT nº 035/2024 as seguintes atualizações foram efetuadas: Encerramento da vigência do ajuste SC020094 na Tabela de Códigos de Ajustes da Apuração do ICMS que não podem ser vinculados diretamente ao documento fiscal (Tabela 5.1.1); Inclusão dos ajustes abaixo na Tabela de Informações Adicionais da apuração - Valores Declaratórios - cBenef (Tabela 5.2A); Encerramento da vigência dos ajustes SC850104, SC850027 e SC850028 na Tabela de Informações Adicionais da apuração - Valores Declaratórios - cBenef (Tabela 5.2A); Inclusão dos ajustes abaixo na Tabela de Ajustes e Informações de Valores Provenientes de Documento Fiscal (Tabela 5.3); Encerramento da vigência dos ajustes SC50000060, SC10000129, SC10000074, SC10000109, SC10000110 e SC10000111 na Tabela de Ajustes e Informações de Valores Provenientes de Documento Fiscal (Tabela 5.3); As tabelas atualizadas podem ser encontradas AQUI.

Foi publicada a versão 26.1.E das tabelas fornecidas pelo IBPT, às quais já se encontram também em nosso SVN. As novas tabelas tem a vigência de 20/02/2026 até 31/03/2026. Para cumprimento da Lei 12.741/12, também conhecida como "De Olho no Imposto", não se esqueça de realizar a atualização de seus clientes. Fonte: De Olho no Imposto

Olá pessoal! Recebemos um retorno do pessoal da Fiorilli sobre nossos questionamentos. Vejam abaixo: 3 - Possível Referência Circular nas Validações (regEspTrib) Identificamos o que parece ser um cenário de "bloqueio lógico" em um de nossos usuários quanto à tag regEspTrib para um mesmo prestador de serviços para a cidade de Urânia/SP com a versão 3.8.1: Cenário A: Ao enviar regEspTrib = 0, retorna o Erro L125 com a mensagem "O Regime Especial de Tributação informado está diferente do que foi cadastrado para este contribuinte. O Regime Especial de Tributação correto é Microempresário e Empresa de Pequeno Porte (ME EPP), ou seja, REMOVA do xml essa informação" Cenário B: Ao remover a tag ou enviar valores de 1 a 6, retorno o Erro: N-E0175 com a mensagem "Quando o prestador optante pelo Simples Nacional tiver o regime de apuração dos tributos ocorrendo também pelo Simples Nacional, o regime especial de tributação do ISSQN deve ser "Nenhum" (regEspTrib = 0)". Pergunta: Pode verificar se existe uma inconsistência na rotina de validação cruzada desses campos? Parece haver uma referência circular que impede a autorização em ambos os casos dependendo de como estiver o cadastro do prestador. Resposta: Acredito que esse problema tenha sido resolvido. Necessário enviar: - regEspTrib = 0 (Nenhum) - opSimpNac (2 - Optante - Microempreendedor Individual (MEI), 3 - Optante - Microempresa ou Empresa de Pequeno Porte (ME/EPP)); - regApTribSN: 1 – Regime de apuração dos tributos federais e municipal pelo SN; 2 – Regime de apuração dos tributos federais pelo SN e o ISSQN pela NFS-e conforme respectiva legislação municipal do tributo; 3 – Regime de apuração dos tributos federais e municipal pela NFS-e conforme respectivas legilações federal e municipal de cada tributo; Exemplo: <regTrib> <opSimpNac>3</opSimpNac> <regApTribSN>1</regApTribSN> <regEspTrib>0</regEspTrib> </regTrib> Por favor, façam seus testes e nos deem um retorno sobre essa questão.

Muito obrigado por compartilhar a informação @armando.boza. Infelizmente isso vai contra uma orientação que recebemos do próprio pessoal da Fiorilli via e-mail : Acho que apesar de tudo, igual a nós, eles também estão correndo para adequar seus sistemas de emissão, então ainda devem estar fazendo muitas alterações e correções. Já é um progresso kkkk . Nós estamos em contato com eles via e-mail. Para essa questão na não sincronização e outras dúvidas. Uma delas é sobre essa rejeição que estão enfrentando, assim que tivermos novas informações compartilho aqui. Mas por hora, acho que a remoção do regime é saída mesmo.

Boa tarde! Os valores válidos para essa informação são: Por favor, faça um teste com esses valores e veja se eles lhe devolvem um resultado diferente.

Bom dia @thanicoletti. Muito obrigado por reportar! Bom dia @willians.wsac. Muito obrigado por compartilhar a informação. Atualização enviada ao SVN na Rev-44987

Olá comunidade ! Seguindo o proposto na Nota Técnica 2026.001, a Sefaz de SP disponibilizou dois novos web services para download dos arquivos XMLs da NFC-es emitidas no estado. São eles: NFCeListagemChaves: através de consulta, vai disponibilizar a lista de NFCe recebidas pela Sefaz num determinado período, para um determinado contribuinte; NFCeDownloadXML: através de consulta, vai disponibilizar o XML da NFC-e e dos eventos associados. Foi criado em nosso backlog a tarefa ACBR-9000 para integração dos novos web services as soluções ACBr. Assim que houver novidades será noticiado.

Planilha com os códigos de tributação do município para serem utilizados em Belo Horizonte/MG. O arquivo contém os itens válidos para serem informados no campo cTribMun no XML do Padrão Nacional. Um agradecimento ao membro de nossa comunidade @farnetani por disponibilizar o arquivo. Vale reforçar que essa informação é específica por município, portanto, o arquivo pode ser usado como base somente para Belo Horizonte/MG. TABELA CODIGO NFSE E NBS_FINAL.xlsx

Olá comunidade ! Foi publicada a Nota Técnica Nº 007 para NFS-e trazendo atualizações no leiaute do documento fiscal. Alterações Incluído o campo para receber o valor do "Indicador da operação de fornecimento favorecido com alíquota zero de CBS (conforme art. 451 e art. 466 da Lei Complementar nº 214/2025)" (tag indZFMALC no XML). Atualização do campo CST do grupo tribFed incluindo novos valores. Adição de novos valores para o campo tpRetPisCofins. Inclusão do campo "Valor Relativo às Retenções de Contribuições Sociais" (tag vRetCSLL no XML) Datas Temos relatos que levam a crer que os novos campos já foram implementados nos ambientes da API nacional. E como fica o ACBr? Os novos valores para tpRetPisCofins e o novo campo vRetCSLL já foram adicionados no leiaute. Assim que o campo indZFMALC estiver disponível notificaremos aqui neste tópico. Leia a Nota Técnica Nº 007 completa AQUI.

Olá comunidade ! No dia 13/02/2026, entre às 11h30 e 17h29, devido a uma instabilidade no sistema, a Sefaz de Goiás devolveu para as NF-e e NFC-e emitidas, números de protocolo com 17 caracteres a invés de 15 que é o tamanho correto. Esses documentos não foram compartilhados com o portal da NF-e nacional e a divergência no tamanho do número de protocolo pode ter gerado problemas na identificação dessas notas para os sistemas emissores. Devido a isso, a Coordenação de Documentos Fiscais da Secretaria da Economia definiu que: Para cada documento, a Secretaria da Economia vai gerar automaticamente novo protocolo de autorização, com 15 posições; Para que a empresa tenha ciência do novo número de protocolo, basta consultar a NF-e por sua chave de acesso utilizando o serviço web “NFeConsultaProtocolo” disponível em seu sistema emissor; Alternativamente pode ser consultado pela página da Secretaria da Economia, acessando exclusivamente com o certificado digital do CNPJ no endereço: Arquivo XML dos Documentos Fiscais (https://nfeweb.sefaz.go.gov.br/nfeweb/sites/nfe/consulta-publica/principal). Acessos sem o certificado digital resultam em erro; O compartilhamento dos documentos com a Receita Federal irá ocorrer de forma automática pela Secretaria da Economia; Será permitido o cancelamento de documentos emitidos indevidamente ou em duplicidade, até o dia 10 de março de 2026. Em caso de dúvidas, pode o e-mail [email protected] e o telefone (62) 3309-6950 podem ser utilizados para atendimento. Um agradecimento ao membro de nossa comunidade @valterpatrick por compartilhar a notícia original na qual esse tópico é baseado.