Diego Foliene

Olá comunidade ! Foi publicada a versão 1.14a desta nota técnica. Alterações Esta versão traz alterações de leiaute e regras de validação relacionadas as compras governamentais: Adiciona no grupo gCompraGov os elementos tpOperGov e refDFeAnt para receber respectivamente o tipo da operação com o ente governamental e a chave de acesso do documento anterior. O elemento tpEnteGov ganha os novos valores 5=Consórcio Público e 6=Comitê Gestor do IBS. Adiciona 11 novas regras de validação para os novos campos e valores validar os novos campos e valores adicionados. Datas Implantação Homologação: 06/04/2026 Implantação Produção: 04/05/2026 E como fica o ACBr? Alterações serão necessárias para adequar as soluções ACBr a essas modificações de leiaute. Foi criada a tarefa ACBR-9136 para esta finalidade. Leia a versão 1.09 desta nota técnica na íntegra AQUI.

Olá comunidade ! Foi publicada a versão 1.14a desta nota técnica. Alterações Esta versão traz alterações de leiaute e regras de validação relacionadas as compras governamentais: Adiciona no grupo gCompraGov os elementos tpOperGov e refDFeAnt para receber respectivamente o tipo da operação com o ente governamental e a chave de acesso do documento anterior. O elemento tpEnteGov ganha os novos valores 5=Consórcio Público e 6=Comitê Gestor do IBS. Adiciona 11 novas regras de validação para os novos campos e valores validar os novos campos e valores adicionados. Datas Implantação Homologação: 06/04/2026 Implantação Produção: 04/05/2026 E como fica o ACBr? Alterações serão necessárias para adequar as soluções ACBr a essas modificações de leiaute. Foi criada a tarefa ACBR-9136 para esta finalidade. Leia a versão 1.09 desta nota técnica na íntegra AQUI.

Olá comunidade ! Foi publicada a versão 1.09 desta nota técnica. Alterações Essa versão não traz alterações no leiaute da NF-e, ela modifica algumas regras de validação: Remove a rejeição "771 - Rejeição: Informado idEstrangeiro em operação interestadual" que validava operação interestadual com idEstrangeiro. Adiciona os NCMs 3808.91.93, 3808.91.94, 3808.91.96 e 3808.99.9 a exceção da regra de validação aplicada para a rejeição 835 que obriga a informação do numero da receita do defensivo agrícola em produto agrotóxico. Altera a regra da rejeição 836 que obriga a presença da informação da Guia de Trânsito Animal para que a além das condições atuais, a mesma seja aplicada quando finalidade de emissão for normal (finNFe=1). Datas Implantação Produção: 20/03/2026 E como fica o ACBr? Como essa NT não traz alterações de leiaute, modificações não serão necessárias nas soluções ACBr. Leia a versão 1.09 desta nota técnica completa AQUI.

Bom dia! Não me recordo de relato semelhante. Vou fazer alguns testes em meu ambiente e reporto aqui; @VEXCOM Sistemas - Valtair, por favor, pode disponibilizar o payload que enviou para a API e também o resultado de DebugHttpRequestContent para conferirmos como ficou a requisição que a API enviou ao web service do provedor.

Boa tarde! Essa mensagem ainda está dizendo que o campo está ficando em branco. Se mesmo enviando as informações dos tributos federais no payload ele não preencheu, então a informação não está sendo alimentada por esta campo. É preciso conferir qual é o campo correto. Vamos pedir um apoio ao time da API.

Bom dia! Por favor, tente realizar novo teste enviando informação de CST no elemento piscofins e CNAE no elemento cServ. { "provedor": "padrao", "ambiente": "producao", "referencia": "00000007", "infDPS": { "dhEmi": "2026-03-09T11:21:09.0689637-03:00", "dCompet": "2026-03-09T00:00:00-03:00", "prest": { "CPF": "96864370020", "regTrib": { "regEspTrib": 14 } }, "toma": { "orgaoPublico": false, "CNPJ": "37318313000100", "xNome": "OPERADOR NACIONAL DO SISTEMA DE REGISTRO ELETRONICO DE IMOVEIS ( ONR )", "end": { "endNac": { "cMun": "5300108", "CEP": "70308200" }, "xLgr": "SCS 9", "tpLgr": "Quadra", "nro": "0", "xBairro": "Asa Sul" } }, "serv": { "cServ": { "cTribNac": "210101", "CNAE": "Valor do tipo String", "xDescServ": "Visualização de matrícula", "cNBS": "113040000", "cSitTrib": "0" } }, "valores": { "vServPrest": { "vReceb": 0.0, "vServ": 11.08 }, "trib": { "tribMun": { "tribISSQN": 1, "pAliq": 5.0, "vBC": 11.08, "vISSQN": 0.33, "tpRetISSQN": 1 }, "tribFed":{ "piscofins":{ "CST": "Valor do tipo String" } } } } } }

Olá comunidade ! Foi publicado no dia 04/03/2026 a versão 1.11 do Informe Técnico 2024/001 atualizando a Tabela dos Meios de Pagamentos utilizada pelos documentos fiscais. Alterações Adiciona na Tabela os itens "23 - Pagamento Instantâneo (PIX) - Automático" e "24 - TEF - 'Book Transfer'". Datas Implantação Teste: 02/04/2026 Implantação Produção: 04/05/2026 E como fica o ACBr? Os novos valores precisarão ser adicionados nos fontes do ACBr. Para esta finalidade foi criado a tarefa ACBR-9097 para esta finalidade. Leia a versão 1.11 do Informe Técnico 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 ! 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: