Diego Foliene

Esta rejeição ocorre quando as validações do web service da Sefaz não encontram o grupo gIBSCBS no arquivo XML nos casos em que ele é necessário. (ind_gIBSCBS = 1 na Tabela de Classificação Tributária ) Portanto, para sanar este problema é preciso preencher as informações relacionadas no arquivo XML: Para aqueles que usam o componente nativo para Delphi/Lazarus ACBrNFe uma maneira de fazer é: uses ACBrNFe.Classes; procedure RotinaQueAlimentaNFeNoComponente; var NotaF: NotaFiscal; Produto: TDetCollectionItem IBSCBS: TIBSCBS; begin NotaF := ACBrNFe.NotasFiscais.Add; //Preenchee as demais informações... Produto := NotaF.NFe.Det.New; //Adiciona o item. IBSCBS := Produto.Imposto.IBSCBS; IBSCBS.CST := TCSTIBSCBS.Valor; IBSCBS.cClassTrib := 'cClassTrib'; //Preencher as propriedades de: IBSCBS.gIBSCBS.XXXX end; Para quem utiliza a solução ACBrMonitorPLUS ou ACBrLibNFe deve preencher no arquivo INI que alimenta a nota as informações: [IBSCBS001] CST= cClassTrib= [gIBSCBS001] vBC= vIBS= [gIBSUF001] pIBSUF= vIBSUF= pDif= vDif= vDevTrib= pRedAliq= pAliqEfet= [gIBSMun001] pIBSMun= vIBSMun= pDif= vDif= vDevTrib= pRedAliq= pAliqEfet= [gCBS001] pCBS= vCBS= pDif= vDif= vDevTrib= pRedAliq= pAliqEfet= [gTribRegular001] CSTReg= cClassTribReg= pAliqEfetRegIBSUF= vTribRegIBSUF= pAliqEfetRegIBSMun= vTribRegIBSMun= pAliqEfetRegCBS= vTribRegCBS= [gIBSCredPres001] cCredPres= pCredPres= vCredPres= [gCBSCredPres001] cCredPres= pCredPres= vCredPres=

Olá pessoal! Foram enviados ao SVN ajustes que adicionam uma nova funcionalidade ao componente ACBrNFe: a leitura e geração de arquivos JSON a partir dos dados de uma NFe, bem como a leitura de arquivos JSON contendo os dados de eventos. O JSON (JavaScript Object Notation) é um formato leve de troca de dados, bastante utilizado em APIs modernas pela sua simplicidade de leitura e facilidade de integração com diferentes linguagens e plataformas. A adição dessa funcionalidade no componente traz diversas vantagens, como maior flexibilidade para importar e exportar informações fiscais em um formato amplamente aceito, integração facilitada com sistemas externos (web, mobile ou nuvem) e apoio em testes e automações sem a necessidade de manipular apenas XML Essa nova funcionalidade está disponível por meio dos seguintes métodos: ACBrNFe.NotasFiscais.LoadFromJSON: Procedure que recebe como parâmetro um arquivo JSON contendo os dados que compõem a NFe/NFCe, ou o caminho para esse arquivo. ACBrNFe.NotasFiscais.GerarJSON: Function que retorna uma string em formato JSON com os dados de uma NFe/NFCe. ACBrNFe.EventoNFe.LerFromJSON: Procedure que recebe como parâmetro um arquivo JSON contendo os dados que compõem o evento, ou o caminho para esse arquivo. Visando trazer maior familiaridade para os desenvolvedores que utilizarem essas rotinas, os arquivos JSON gerados e lidos por elas foram construídos seguindo a mesma nomenclatura e estrutura do leiaute oficial da NFe e dos eventos. Dessa forma, quem já está habituado a trabalhar com os XMLs da NFe perceberá que a adaptação para o JSON é simples e direta. Tomemos este XML de uma NFCe gerado com dados fictícios, por exemplo: <NFe xmlns="http://www.portalfiscal.inf.br/nfe"> <infNFe Id="NFe35240892390477000149650010000000011919433382" versao="4"> <ide> <cUF>35</cUF> <cNF>91943338</cNF> <natOp>VENDA</natOp> <indPag>0</indPag> <mod>65</mod> <serie>1</serie> <nNF>1</nNF> <dhEmi>2024-08-14T16:54:00.000Z</dhEmi> <tpNF>1</tpNF> <idDest>1</idDest> <cMunFG>3505203</cMunFG> <tpImp>4</tpImp> <tpEmis>1</tpEmis> <cDV>2</cDV> <tpAmb>2</tpAmb> <finNFe>1</finNFe> <indFinal>1</indFinal> <indPres>1</indPres> <procEmi>0</procEmi> <verProc>ACBr-Monitor</verProc> </ide> <emit> <CNPJ>92390477000149</CNPJ> <xNome>RAZAO SOCIAL</xNome> <xFant>FANTASIA</xFant> <IE>449301071500</IE> <CRT>3</CRT> <enderEmit> <xLgr>LOGRADOURO</xLgr> <nro>1</nro> <xCpl>COMPLEMENTO</xCpl> <xBairro>BAIRRO</xBairro> <cMun>3505203</cMun> <xMun>BARIRI</xMun> <UF>SP</UF> <CEP>12345678</CEP> <cPais>1058</cPais> <xPais>BRASIL</xPais> <fone>11111111</fone> </enderEmit> </emit> <det nItem="1"> <prod> <cProd>123456</cProd> <cEAN>7896523206646</cEAN> <cBarra>ABC123456</cBarra> <xProd>NOTA FISCAL EMITIDA EM AMBIENTE DE HOMOLOGACAO - SEM VALOR FISCAL</xProd> <NCM>94051010</NCM> <CEST>1111111</CEST> <CFOP>5101</CFOP> <uCom>UN</uCom> <qCom>1</qCom> <vUnCom>100</vUnCom> <vProd>100</vProd> <cEANTrib>7896523206646</cEANTrib> <cBarraTrib>ABC123456</cBarraTrib> <uTrib>UN</uTrib> <qTrib>1</qTrib> <vUnTrib>100</vUnTrib> <vFrete>0</vFrete> <vSeg>0</vSeg> <vDesc>0</vDesc> <vOutro>0</vOutro> <indTot>1</indTot> </prod> <imposto> <vTotTrib>0</vTotTrib> <ICMS> <ICMS00> <orig>0</orig> <CST>00</CST> <modBC>3</modBC> <vBC>100</vBC> <pICMS>18</pICMS> <vICMS>1800</vICMS> </ICMS00> </ICMS> <IPI> <IPITrib> <CST>00</CST> <vBC>0</vBC> <pIPI>0</pIPI> <vIPI>0</vIPI> </IPITrib> </IPI> <PIS> <PISOutr> <CST>99</CST> </PISOutr> </PIS> <COFINS> <COFINSOutr> <CST>99</CST> </COFINSOutr> </COFINS> </imposto> </det> <total> <ICMSTot> <vBC>100</vBC> <vICMS>1800</vICMS> <vProd>100</vProd> <vNF>100</vNF> <vTotTrib>0</vTotTrib> </ICMSTot> </total> <transp> <modFrete>9</modFrete> </transp> <pag> <detPag> <tPag>01</tPag> <vPag>100</vPag> </detPag> </pag> <infAdic> <obsCont> <xCampo>ObsCont</xCampo> <xTexto>Texto</xTexto> </obsCont> <obsFisco> <xCampo>ObsFisco</xCampo> <xTexto>Texto</xTexto> </obsFisco> </infAdic> </infNFe> <infNFeSupl> <qrCode>https://www.homologacao.nfce.fazenda.sp.gov.br/qrcode?p=|2|2|1|EA3AA74775103726161ECA855F5C17EDC996517A</qrCode> <urlChave>https://www.homologacao.nfce.fazenda.sp.gov.br/consulta</urlChave> </infNFeSupl> </NFe> Seu JSON equivalente seria: { "NFe": { "infNFe": { "Id": "NFe35240892390477000149650010000000011919433382", "versao": "4", "ide": { "cUF": 35, "cNF": 91943338, "natOp": "VENDA", "mod": 65, "serie": 1, "nNF": 1, "dhEmi": "2024-08-14T16:54:00.000Z", "tpNF": "1", "idDest": "1", "cMunFG": 3505203, "tpImp": "4", "tpEmis": "1", "cDV": 2, "tpAmb": "2", "finNFe": "1", "indFinal": "1", "indPres": "1", "procEmi": "0", "verProc": "ACBr-Monitor" }, "emit": { "CNPJ": "92390477000149", "xNome": "RAZAO SOCIAL", "xFant": "FANTASIA", "IE": "449301071500", "CRT": "3", "enderEmit": { "xLgr": "LOGRADOURO", "nro": "1", "xCpl": "COMPLEMENTO", "xBairro": "BAIRRO", "cMun": 3505203, "xMun": "BARIRI", "UF": "SP", "CEP": 12345678, "cPais": 1058, "xPais": "BRASIL", "fone": "11111111" } }, "det": [ { "nItem": 1, "prod": { "cProd": "123456", "cEAN": "7896523206646", "cBarra": "ABC123456", "xProd": "NOTA FISCAL EMITIDA EM AMBIENTE DE HOMOLOGACAO - SEM VALOR FISCAL", "NCM": "94051010", "CEST": "1111111", "CFOP": "5101", "uCom": "UN", "qCom": 1, "vUnCom": 100, "vProd": 100, "cEANTrib": "7896523206646", "cBarraTrib": "ABC123456", "uTrib": "UN", "qTrib": 1, "vUnTrib": 100, "indTot": "1" }, "imposto": { "vTotTrib": 0, "ICMS": { "ICMS00": { "orig": "0", "CST": "00", "modBC": "3", "vBC": 100, "pICMS": 18, "vICMS": 1800 } }, "IPI": { "IPITrib": { "CST": "00", "vBC": 0, "pIPI": 0, "vIPI": 0 } }, "PIS": { "PISOutr": { "CST": "99" } }, "COFINS": { "COFINSOutr": { "CST": "99" } } } } ], "total": { "ICMSTot": { "vBC": 100, "vICMS": 1800, "vProd": 100, "vNF": 100, "vTotTrib": 0 } }, "transp": { "modFrete": "9" }, "pag": { "detPag": [ { "tPag": "01", "vPag": 100 } ] }, "infAdic": { "obsCont": [ { "xCampo": "ObsCont", "xTexto": "Texto" } ], "obsFisco": [ { "xCampo": "ObsFisco", "xTexto": "Texto" } ] } }, "infNFeSupl": { "qrCode": "https://www.homologacao.nfce.fazenda.sp.gov.br/qrcode?p=|2|2|1|EA3AA74775103726161ECA855F5C17EDC996517A", "urlChave": "https://www.homologacao.nfce.fazenda.sp.gov.br/consulta" } } } Observem que os nomes das chaves correspondem exatamente ao nome das tags e os níveis das tags foram representados de maneira semelhante no JSON. É a mesma coisa para os eventos, vejam um exemplo de JSON de um evento de cancelamento: { "envEvento": { "idLote": "123456789012345", "evento": [ { "versao": "1.00", "infEvento": { "cOrgao": "35", "tpAmb": "2", "CNPJ": "11111111000111", "chNFe": "35240111111111000111550010000001231000001234", "dhEvento": "2024-07-29T10:00:00-03:00", "tpEvento": "110111", "nSeqEvento": "1", "versaoEvento": "1.00", "detEvento": { "versao": "1.00", "descEvento": "Cancelamento", "nProt": "135240000000123", "xJust": "A operacao foi cancelada por motivos comerciais." } } } ] } } Se compararmos, essa estrutura é semelhante ao leiaute apresentado no MOC e ao XML de envio gerado. Vale reforçar que, apesar da nova funcionalidade, o XML é o documento fiscal eletrônico oficial e deve ser armazenado para fins fiscais. Contamos com a colaboração de todos para testar as rotinas e reportar quaisquer problemas encontrados. Sua participação é essencial para aprimorarmos as soluções para toda a comunidade. Até a próxima pessoal.

Olá pessoal! No dia 15/09/2025 foi publicada a versão 1.00 desta nota técnica que estabelece uma nova forma de emissão para o BPe. Base conceitual BPe TA O Bilhete de Passagem Eletrônico para Transporte Aéreo (BPeTA, modelo 63) é um documento emitindo e armazenado eletronicamente para acobertar operações de transporte aéreo de passageiros. Chave de acesso A chave de acesso do BPe TA será composta pelos elementos na ordem apresentada: cUF - Código da UF do emitente do Documento Fiscal - 02 caracteres AAMM - Ano e Mês de emissão do BPeTA - 04 caracteres CNPJ - CNPJ do emitente - 14 caracteres mod - Modelo do Documento Fiscal - 02 caracteres serie - Série do Documento Fiscal - 03 caracteres nBP - Número do Documento Fiscal - 09 caracteres tpEmis - forma de emissão - 01 caractere cBP - Código Numérico que compõe a Chave de Acesso - 08 caracteres cDV - Dígito Verificador da Chave de Acesso - 01 caractere Ela será validada pelo sistema de autorização e haverá rejeição em caso de duplicidade. Relação de web services Será disponibilizado novo web service específico para autorização de BPeTA com o envio sendo feito através de modelo síncrono, enviando 1 BPeTA por vez. (bpeRecepcaoTA) Os web services de consulta de situação (bpeConsultaBP), consulta de status de serviço (bpeStatusServicoBP) e registro de eventos (bpeRecepcaoEvento) serão adaptados para atender também ao BPeTA. Leiaute Bilhete de Passagem Eletrônico para Transporte Aéreo - BPeTA O novo modelo possui leiaute próprio contendo campos semelhantes aos já presentes em outros modelos do BPe, campos relacionados a Reforma Tributária e campos próprios ao modal de transporte, por exemplo: Grupo de Informações de detalhamento da Passagem (infPassagem) Data e hora de embarque (dhEmb) Data e hora de validade do bilhete (dhValidade) Informações do passageiro (infPassageiro) Grupo de informações da viagem do BPe (infViagem) Código voo viagem (nroVoo) Sigla IATA da Companhia que opera o voo (SiglaCiaOperVoo) Tipo de Viagem (tpViagem) Etc... Datas Não há datas de implantação definidas na publicação. Implantação Homologação: - Implantação Produção: - E como fica o ACBr? O componente ACBrBPe será alterado conforme diretrizes estabelecidas na nota técnica para que possa ser emitido o BPe TA através do mesmo. Criada a tarefa ACBR-8054 para esta finalidade. Qualquer novidade será divulgada neste tópico. Leia nota técnica na íntegra [AQUI]

Olá pessoal! No dia 15/09/2025 foi publicada a versão 1.09 desta nota técnica. A nova versão não traz alterações no leiaute, mas modifica regras de validação e datas. Alterações Adiciona uma observação para que seja utilizada a pAliqEfet caso o grupo de redução (gRed) seja preenchido nas regras de validação que verificam se o valor do diferimento municipal e estadual diferem do calculado. Altera algumas datas conforme observação reproduzida na íntegra: Datas Implantação Homologação: Até 28/07/2025 Implantação Produção: 06/10/2025 E como fica o ACBr? Como não houve alteração no leiaute, modificações nos fontes do ACBr não se fazem necessárias. Leia a versão 1.09 desta nota técnica na íntegra [AQUI]

Olá pessoal! No dia 15/09/2025 foi publicada a versão 1.09 desta nota técnica. A nova versão não traz alterações no leiaute, mas modifica regras de validação e datas. Alterações Adiciona uma observação para que seja utilizada a pAliqEfet caso o grupo de redução (gRed) seja preenchido nas regras de validação que verificam se o valor do diferimento municipal e estadual diferem do calculado. Altera algumas datas conforme observação reproduzida na íntegra: Datas Implantação Homologação: Até 28/07/2025 Implantação Produção: 06/10/2025 E como fica o ACBr? Como não houve alteração no leiaute, modificações nos fontes do ACBr não se fazem necessárias. Leia a versão 1.09 desta nota técnica na íntegra [AQUI]

Olá pessoal! No dia 15/09/2025 foi publicada a versão 1.09 desta nota técnica. A nova versão não traz alterações no leiaute, mas modifica regras de validação e datas. Alterações Adiciona uma observação para que seja utilizada a pAliqEfet caso o grupo de redução (gRed) seja preenchido nas regras de validação que verificam se o valor do diferimento municipal e estadual diferem do calculado. Altera algumas datas conforme observação reproduzida na íntegra: Datas Implantação Homologação: Até 28/07/2025 Implantação Produção: 06/10/2025 E como fica o ACBr? Como não houve alteração no leiaute, modificações nos fontes do ACBr não se fazem necessárias. Leia a versão 1.09 desta nota técnica na íntegra [AQUI]

Olá pessoal! Nasce um novo documento fiscal eletrônico! A Nota Fiscal da Água e Saneamento Eletrônica, abreviada como NFAg é um modelo nacional de documento fiscal eletrônico. Ele será identificado pelo modelo 75 e substituirá a sistemática atual de emissão da Nota Fiscal para Água e Saneamento, com validade jurídica garantida pela assinatura digital do emitente. O documento foi publicado em forma de minuta e aguarda ato conjunto normativo para publicação definitiva. O Portal da Nota Fiscal da Água e Saneamento Eletrônica - SVRS pode ser acessado para mais detalhes. Os manuais publicados também já foram disponibilizados em nossa Biblioteca Tools. E o ACBr onde entra nessa história? De maneira semelhante aos demais documentos fiscais eletrônicos, a equipe de consultores do Projeto ACBr vai analisar os manuais disponibilizados e conforme viabilidade, criar um novo componente para comunicar com os web services fornecidos e auxiliar no processo de emissão deste novo documento seguindo as diretrizes estabelecidas em seus respectivos manuais de orientação.

Olá pessoal! No dia 15/09/2025 foi publicada a versão 1.09 desta nota técnica. A nova versão não traz alterações no leiaute, mas modifica regras de validação e datas. Alterações Adiciona uma observação para que seja utilizada a pAliqEfet caso o grupo de redução (gRed) seja preenchido nas regras de validação que verificam se o valor do diferimento municipal e estadual diferem do calculado. Altera algumas datas conforme observação reproduzida na íntegra: Datas Implantação Homologação: Até 28/07/2025 Implantação Produção: 06/10/2025 E como fica o ACBr? Como não houve alteração no leiaute, modificações nos fontes do ACBr não se fazem necessárias. Leia a versão 1.09 desta nota técnica na íntegra [AQUI]

Obrigado por reportar. Fechando. Para novas dúvidas, criar um novo tópico.

Olá, pessoal! Temos recebido diversos relatos de membros da nossa comunidade sobre problemas na transmissão de NF-e e NFC-e que contenham os novos campos incluídos pela Reforma Tributária. Os relatos têm em comum: Rejeições do tipo Falha no Schema ou mensagens de erro relacionadas ao schema. As mesmas UFs envolvidas. Indícios de que a tag vIBS, adicionada no grupo gIBSCBS na versão 1.20 da Nota Técnica 2025/002, está associada ao problema. Recebemos a informação de que as UFs de SP, MT, MS e PR ainda não estão aceitando as informações do IBS conforme a versão 1.20 da NT 2025/002. Por isso, todo o grupo de IBS deve ser suprimido no ambiente de homologação. Por outro lado, as UFs de RS e GO já estão validando as informações em homologação, ou seja, antecipando a implementação prevista na NT. Seguiremos atualizando este tópico à medida que novas informações forem sendo disponibilizadas.

Olá pessoal! No dia 04/09/2025 foi publicada a Instrução Normativa nº 1608/2025-GSE. Essa norma regulamenta a vinculação dos meios de pagamento ao respectivo documento fiscal eletrônico por meio de integração sistêmica, abordando o tema em sete artigos. O Artigo 1 estabelece que deve haver integração sistêmica entre o documento fiscal eletrônico emitido e seu respectivo pagamento eletrônico nas operações de circulação de mercadoria realizadas por contribuintes do ICMS, detalhando em seus incisos que: Será considerado interligação tecnológica a comunicação direta, imediata e integrada entre o sistema de pagamento e o software emissor do DFe, sem intervenção humana; Contribuintes MEI estão dispensados dessa obrigatoriedade; Já o Artigo 2 torna essa vinculação obrigatória tanto para a Nota Fiscal Eletrônica (NF-e, modelo 55) quanto para a Nota Fiscal de Consumidor Eletrônica (NFC-e, modelo 65) nas operações cujo pagamento foi feito através de: Cartões de crédito, de débito, de loja ("private label") ou pré-pagos; Transferência eletrônica de recursos via Sistema de Pagamento Instantâneo - PIX; Ele defina ainda, os casos em que a obrigatoriedade não se aplica a operação, sendo eles: Operações em que é dispensada a emissão do documento fiscal. Nota fiscal emitida no regime Nota Fiscal Fácil (NFF); Venda realizada com entrega e pagamento em domicílio (delivery). Não presencial intermediada em site ou plataforma de terceiros. Vale reforçar que para os casos mencionados acima que estão dispensados da obrigatoriedade, não estão isentos de preencher as informações necessárias conforme o MOC. No Artigo 3 é definido que no comprovante de pagamento dessas operações deve constar no mínimo: CNPJ e Nome Empresarial para pessoa jurídica ou CPF e nome cadastral podendo mascarar alguns caracteres para pessoa física. O código de autorização ou identificação do pedido. A data e hora. O valor da operação. O identificador do terminal em que ocorreu a transação nos casos em que se aplica. É estabelecido no Artigo 4 que deve constar no arquivo XML do respectivo documento fiscal, as informações correspondentes ao pagamento no grupo "YA - Informações de pagamento". É definido também em parágrafo único, que nos pagamentos posteriores a emissão do documento, as informações de pagamento devem ser vinculadas ao mesmo através do evento de conciliação financeira - ECONF. O Artigo 5 veda o uso e permanência de equipamento no recinto de atendimento ao público que permita o registro e processamento de operações sujeitas ao ICMS sem a vinculação do pagamento ao documento fiscal por meio de integração sistêmica. O cronograma de implantação é estabelecido no Artigo 6 explicando que para aplicação do mesmo deve ser considerada a soma da receita de todos os estabelecimentos do contribuinte localizados no estado: Por fim o Artigo 7 menciona que a Instrução em questão entra em vigor na data de sua publicação. Leia a Instrução Normativa nº 1608/2025-GSE na íntegra [AQUI] Vale reforçar para aqueles que usam as soluções ACBr: Componente nativo para Delphi/Lazarus, ACBrMonitorPLUS e ACBrLib, já estão prontos para receber essas informações que são requisitadas para vincular os meios de pagamento ao documento fiscal eletrônico, estando de acordo não só com esta requisição, mas também com RS, MT e CE. Os membros da comunidade ACBr que são Corporativo e PRO, possuem acesso aos cursos disponibilizados pelo ACBr, o que inclui o Integração dos Meios de Pagamento aos Documentos Fiscais Eletrônicos e o E-Conf: Integrações de Pagamentos O Projeto ACBr pode ajudar com a solução do TEF, veja mais [AQUI]

Olá pessoal! Ao acessar o Portal da Nota Fiscal Eletrônica, é possível observar que a Sefaz de São Paulo possui contingência agendada, com previsão de início às 06h00 do dia 14/09/2025 e término às 16h00 do mesmo dia. Para utilizar as soluções ACBr em contingência durante esse período, siga as orientações do tópico abaixo: Ao consultar a página Sobre a NF-e de SP é possível observar que existe uma manutenção programada neste mesmo dia começando às 08h00 e terminando às 14h00 o que justifica a contingência.

Boa tarde! Como colocou as dlls na pasta do .EXE junto a Lib e mesmo assim persistiu o problema, é possível que ainda assim, a aplicação esteja lendo as dlls de outro lugar. Isso pode ocorrer se tiver no Path do Windows uma referência a elas. Por favor, se possível, tente realizar um teste. Crie um pasta em um local seguro¹ ¹ Por seguro, quero dizer um local que não possa ser facilmente apagado, a área de trabalho, por exemplo, não é um local seguro. Dentro dessa pasta adicione as dlls de dependência da LibXML2 e da OpenSSL. (Lembre-se de pegar as dlls de acordo com a arquitetura que compila sua aplicação, conforme mencionado nas postagens anteriores). Na barra do Windows, pesquise por variáveis de ambiente. Na janela que aparecer, busque por variáveis de ambiente na aba avançado. Edite a variável Path adicionando essa pasta que você criou no passo 1. Faça log-off do usuário ou reinicie a máquina. Faça um novo teste de consulta de status de serviço.

Boa tarde! Não há atualmente nada que faça este processo. Pelo que descreveu, me parece que a informação do Link está sendo devolvida no XML da NFSe, correto? Se for, não acho uma boa alterarmos o seu conteúdo. Por favor, para este caso em específico, não atenderia a sua necessidade usar o método ACBrNFSeX.LinkNFSe ? Como é você que vai chamar o método, você pode controlar a informação, então você pode passar só o número sem a informação do ano.

Obrigado por reportar. Fechando. Para novas dúvidas, criar um novo tópico.

Olá pessoal! No dia 02/09/2025 foi publicada a versão 1.02 desta nota técnica. Alterações Esta versão não traz alterações no leiaute, mas altera e posterga a ativação de algumas regras de validação: Implementação em produção postergada para 13/10/2025. cStat: 452 - Rej: Solicitada resposta assíncrona para Lote com somente 1 (uma) NF-e. cStat: 805 - Rej: A SEFAZ do destinatário não permite Contribuinte Isento de Inscrição Estadual. Implementação futura para o modelo 55. cStat: 865 - Rej: Total dos pagamentos menor que o total da nota. cStat: 391 - Rej: Não informados os dados do cartão de crédito / débito nas Formas de Pagamento da Nota Fiscal. Implementação futura. cStat: 300 - Rej: Tipo da IE do Destinatário difere de Não Contribuinte no cadastro da UF. Datas A implementação tanto em homologação quanto em produção das mudanças propostas deve ocorrer até 08/09/2025 ou data prevista na própria regra de validação. E como fica o ACBr? Como não ocorreram alterações no leiaute, modificações no ACBr não se fazem necessárias. Leia a versão 1.02 desta nota técnica na íntegra [AQUI]

Bom dia! Por favor, certifique-se de que as dlls de dependência da LibXML2 foram devidamente distribuídas junto a sua aplicação. Lembre-se de escolher elas seguindo a mesma arquitetura da Lib, ou seja, se você usa ACBrCTe32.dll, então vai pegar as dlls da LibXML2 da pasta x86, caso utilize ACBrCTe64.dll, então vai pegar as dlls da pasta x64.

Bom dia! Esse erro lhe é devolvido quando a aplicação falha em inicializar a dll. Por favor: Verifique se as dlls da LibXML2 se encontram junto do seu .EXE; Confirme se está usando as dlls da arquitetura correta, considerando a arquitetura da Lib e não a arquitetura do SO, por exemplo, se você usa a Lib ACBrNFSe32.dll, vai pegar as dlls da pasta x86 e se usa a ACBrNFSe64.dll, então vai pegar as dlls da pasta x64. Confira se está usando as configurações recomendadas por tipo de certificado. Caso esteja utilizando um ambiente Linux, é importante que crie um link simbólico, conforme mencionado nesta AULA.

Foi publicada a versão 25.2.C das tabelas fornecidas pelo IBPT, às quais já se encontram também em nosso SVN. As novas tabelas tem a vigência de 20/08/2025 até 30/09/2025. 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! Ao acessar o Portal da NFCom de MG o seguinte aviso é exibido informando sobre indisponibilidade do ambiente de homologação entre os dias 18/08 e 20/08.

Olá pessoal! Foi publicada a versão 1.08a desta nota técnica. Alterações Esta versão não traz alterações de leiaute, ela apenas altera a redação de algumas regras de validação corrigindo obrigatoriedade da aplicação, campo a ser validado e cálculo. Datas Foram mantidas as mesmas datas da versão anterior. E como fica o ACBr? Modificações não são necessárias na solução ACBr, visto que não houve modificação de leiaute. Leia a versão 1.08a desta nota técnica na íntegra [AQUI]

Olá pessoal! Foi publicada a versão 1.08a desta nota técnica. Alterações Esta versão não traz alterações de leiaute, ela apenas altera a redação de algumas regras de validação corrigindo obrigatoriedade da aplicação, campo a ser validado e cálculo. Datas Foram mantidas as mesmas datas da versão anterior. E como fica o ACBr? Modificações não são necessárias na solução ACBr, visto que não houve modificação de leiaute. Leia a versão 1.08a desta nota técnica na íntegra [AQUI]

Olá pessoal! Foi publicada a versão 1.08a desta nota técnica. Alterações Esta versão não traz alterações de leiaute, ela apenas altera a redação de algumas regras de validação corrigindo obrigatoriedade da aplicação, campo a ser validado e cálculo. Datas Foram mantidas as mesmas datas da versão anterior. E como fica o ACBr? Modificações não são necessárias na solução ACBr, visto que não houve modificação de leiaute. Leia a versão 1.08a desta nota técnica na íntegra [AQUI]