Painel de líderes

Olá pessoal, Foi implementado um novo provedor, trata-se do SysISS que segue a versão 2.02 do layout da ABRASF. Como todos sabem, não estamos mais realizando manutenção no componente antigo, logo o provedor SysISS só esta disponível no novo componente: ACBrNFSeX. Quem nos passou todas as informações sobre esse provedor foi o nosso amigo @Everson Clei, que mais uma vez agradeço pela contribuição e colaboração. Ele também nos informou que no momento o provedor atende as seguintes cidades: Rondon/PR, Prado Ferreira/PR, Lupionópolis/PR, Rancho Alegre/PR e Cafeara/PR. Caso mais alguém saiba de outras cidades atendidas pelo mesmo provedor ou de outros provedores já implementados, é muito fácil acrescentar novas cidades, basta seguir o passo a passo da postagem abaixo. Se você tem informações de um provedor que ainda não foi implementado faça como nosso amigo Everson, crie uma postagem aqui no fórum anexando a documentação: manual, Schemas (arquivos XSD), URLs de homologação e produção das cidades atendidas por esse provedor.

Boa tarde. Por favor, pode compartilhar o link em que encontrou este manual? Acredito que a orientação do @Renato Rubinho quanto a emissão de NFA-e ser somente pelo site procede. Veja este trecho retirado do MOC Visão Geral* No MOC - Anexo I Leaiute* temos o seguinte para a série que estava usando: No procEmi também temos: *O Manual e as NTS podem ser encontrados AQUI.

Boa tarde, Manual da NF-e? Qual manual? Eu não encontrei esse texto em nenhum manual da NF-e.

@cdsistemas Boa tarde ! A tarefa foi concluída. subimos para o SVN. Por favor atualize os repositórios ACBr e rode o instalador. Se puder testar e nos dar o feedback ! Obrigado

Boa tarde, No SVN do ACBr tem exemplo em Delphi e em Lazarus... http://svn.code.sf.net/p/acbr/code/trunk2/Exemplos/ACBrDFe/ACBrNFSeX/ Observe que o componente atual é o ACBRNFSex

Vou realizar as alterações necessárias e quando estiver com o arquivo xml posto aqui.

Bom dia. A Sefaz de MG atualizou as cadeias de certificado opcionais que podem ser instaladas em caso de problema. Na página SPED MG > Downloads há o seguinte recado: Um agradecimento especial ao membro @Rafael F. Mesquita por avisar no canal #sefaz em nossa comunidade do Discord.

Isso mesmo. Estou iniciando agora a implementação do GNRE e estava me baseando somente nas tabelas do Portal GNRE. Só que mesmo informando o 94 ele rejeita a chave de acesso por não ser chave de cte. Deve ter mais coisas em homologação diferentes da produção. Tabelas diferentes para homologação e produção são um verdadeiro entrave. Muito obrigada pela dica. No caso da GNRE homologação UF Favorecida SE, a guia DIFAL deveria ser receita 100102 (por operação UF emitente não inscrita). Porém essa receita exige o campo extra 94-chave de acesso cte. Porém eu tenho uma chave de acesso NFe. Ou teria que lançar na receita 100129 (FCP por operação)? Essa regra vale para produção também?

Bom dia! Se conferirmos em Ambiente de Teste GNRe > Página Principal > Configurações das UFs > Campos Adicionais selecionando Sergipe, uma das linhas coincide: Acredito que seja isso que esteja causando o problema. Veja que a receita coincide com o que você informou, ela está como obrigatória e o código coincide com a mensagem que está recebendo. Edit: Conferi também no ambiente de produção e realmente são diferentes os Códigos. Acredito que isso tenha causado a confusão.

Souza, Analisando o seu XML com um outro que tenho que foi baixado do Portal da NFS-e Padrão Nacional, notei as seguintes diferenças: No seu XML a série é 600 e o que foi baixado é 900 No seu XML consta o valor ZZ na tag cPaisPrestacao, no baixado não consta essa tag. Você deve estar atribuindo um valor diferente de zero e de 1058 ao campo: NFSe.Servico.CodigoPais

Olá pessoal, Mais um presente de grego para nós desenvolvedores, mais uma alteração no layout da NF-e, novos campos, novos ICMS. Vamos a um resumo sobre a Nota Técnica 2023/001: Essa Nota Técnica divulga novos campos e Regras de Validação da NF-e versão 4.0. Como existe a inclusão de novos campos facultativos no Leiaute (Schema XML), algumas Regras de Validação serão ativadas posteriormente, conforme observação em cada uma delas, visando garantir um prazo de adequação para as empresas. Já as regras existentes que não permitiriam a informação dos novos campos, tem o mesmo prazo de entrada do Leiaute (Schema XML). O prazo abaixo, portanto, se refere a entrada das alterações no Leiaute (Schema XML), e das regras que visam permitir a informação dos novos campos sem rejeição. Sobre as Datas de Entrada em Vigor - Mudança de Schemas e Regras N12-20, N12-30, N12-70 e W16-10 Ambiente de Homologação : até 03/03/2023 - Ambiente de Produção: 30/03/2023 Regras de Validação Alteradas Regra de Validação N12-20 - Incluída exceção nesta regra para permitir que o emissor enquadrado no Simples Nacional possa informar os novos Códigos de Situação Tributária criados pelo Ajuste SINIEF Nº 01/2023. Regras de Validação N12-30 e N12-70 - Inclusão do CST 61, criado pelo Ajuste SINIEF Nº 01/2023, na relação de CSTs permitidos na emissão de NFC-e (Regra N12-30) e na relação de CSTs permitidos na operação com Não Contribuinte da NF-e (Regra N12-70). Regra de Validação W16-10 - Inclusão do Valor Total do ICMS monofásico sujeito a retenção (tag: vICMSMonoReten) no somatório do Valor Total da NF-e (campo: W16) Sobre as Alterações de Campos Inclusão do Campo de Índice de Mistura do Biodiesel no Diesel B (tag: pBio) Criação de campo específico no Grupo de Detalhamento de Combustíveis para a indicação do índice de Mistura do Biodiesel no Óleo Diesel B. Este campo tem a finalidade de auxiliar no cálculo do volume do Biodiesel B100 a ser misturado com Óleo Diesel A, nas operações com Biodiesel Puro, ou do volume do Biodiesel B100 misturado nas operações com Óleo Diesel B. Inclusão do Grupo indicador da origem do combustível (tag: origComb) Este grupo deve ser preenchido para as operações com Biodiesel B100, Óleo Diesel B e GLP/GLGN. Serve para identificar as UFs do produtor ou do importador de B100 ou GLGN utilizados na mistura. Além da identificação da UF de Origem, há a necessidade de se informar se o produto é nacional ou importado. Criação do Grupo N02a- Grupo Tributação do ICMS = 02 (tag: ICMS02) Este grupo trata do regime de tributação monofásica própria do ICMS nas operações com combustíveis nos termos da Lei Complementar nº 192/2022 e Convênio ICMS 199/2022. Novo Código de Situação Tributária (CST = 02) criado pelo Ajuste SINIEF Nº 1/2023. Criação do Grupo N03a- Grupo Tributação do ICMS = 15 (tag: ICMS15) Este grupo trata do regime de tributação monofásica própria e com responsabilidade pela retenção do ICMS nas operações com combustíveis nos termos da Lei Complementar nº 192/2022 e Convênio ICMS 199/2022. Novo Código de Situação Tributária (CST = 15) criado pelo Ajuste SINIEF Nº 1/2023. Criação do Grupo N03a- Grupo Tributação do ICMS = 53 (tag: ICMS53) Este grupo trata do regime de tributação monofásica com recolhimento diferido do ICMS nas operações com combustíveis nos termos da Lei Complementar nº 192/2022 e Convênio ICMS 199/2022. Novo Código de Situação Tributária (CST = 53) criado pelo Ajuste SINIEF Nº 1/2023. Criação do Grupo N03a- Grupo Tributação do ICMS = 61 (tag: ICMS61) Este grupo trata do regime de tributação monofásica sobre combustíveis com ICMS cobrado anteriormente nos termos da Lei Complementar nº 192/2022 e Convênio ICMS 199/2022. Novo Código de Situação Tributária (CST = 61) criado pelo Ajuste SINIEF Nº 1/2023. Criação dos campos de Valor total do ICMS monofásico Campos Valor total do ICMS monofásico próprio (tag: vICMSMono), Valor total do ICMS monofásico sujeito a retenção (tag: vICMSMonoReten) e Valor total do ICMS monofásico retido anteriormente (tag vICMSMonoRet) criados no grupo de Total da NF-e (tag: total). Sobre as Datas de Entrada em Vigor - Novas Regras Ambiente de Homologação: até 03/07/2023 - Ambiente de Produção: 04/09/2023 Novas Regras de Validação Conforme informado em NT, estas regras não serão publicadas ao mesmo tempo que o Leiaute (Schema XML) para permitir uma implementação gradual das empresas e dos autorizadores, possibilitando inicialmente o preenchimento dos novos campos para atender a legislação sem maiores complicações. Regra de Validação I13-20 Apesar desta regra já existir previamente, a sua descrição foi completamente alterada para que ela fique compatível com a Tabela de Combustíveis Sujeitos à Tributação Monofásica. Por isso receberá o tratamento de nova regra, e somente entrará em vigor na data prevista na sua nova descrição. Ela visa garantir o correto preenchimento da unidade tributária exigida por lei para os combustíveis cujos códigos ANP se encontrem na Tabela de Combustíveis Sujeitos à Tributação Monofásica. Regras de Validação LA17-10 e LA17-20 Estas regras visam controlar o correto preenchimento do índice de mistura do biocombustível (tag: pBio) obrigando ou rejeitando o seu preenchimento conforme o combustível informado. Para isso, o código ANP (tag: cProdANP) informado na nota é confrontado com a coluna “cProdANP” da Tabela de Combustíveis Sujeitos à Tributação Monofásica, com a respectiva coluna “pBio” indicando se o índice deve ou não ser preenchido conforme determinado na descrição das regras. Regra de Validação LA18-10 Esta regra visa obrigar o preenchimento do grupo de origem do combustível (tag: origComb) conforme indicador da coluna “origComb”, a partir da correspondência entre o Código ANP do combustível (tag; cProdANP) informado na nota e a coluna “cProdANP” da Tabela de Combustíveis Sujeitos à Tributação Monofásica. Regra de Validação LA21-10 Caso informado o grupo indicador da origem do combustível (tag: origComb), é realizado o somatório dos percentuais originários para a UF (tag: pOrig) informados em cada ocorrência deste grupo para verificar se o total deste somatório é 100. Regras de Validação N12-100 e N12-110 O objetivo destas regras é verificar o correto preenchimento dos novos Códigos de Situação Tributária do ICMS criados pelo Ajuste SINIEF Nº 01/2023. Estes novos códigos somente poderão ser preenchidos quando se tratar de operação com combustíveis sujeitos à tributação monofásica do ICMS. Para isso, é verificado se o código ANP do produto (tag: cProdANP) informado na nota existe na Tabela de Combustíveis Sujeitos à Tributação Monofásica. Caso o código ANP exista na tabela o preenchimento destes CSTs é obrigatório, e caso não exista o seu preenchimento é proibido. Regras de Validação N38-10, N40-10 e N44-10 Estas regras visam validar o valor preenchido para a alíquota adrem do imposto nas diferentes modalidades de tributação monofásica dos combustíveis (próprio, com retenção e retido anteriormente). Para isso, é verificada a correspondência entre o código ANP do produto (tag: cProdANP) informado na nota e a coluna cProdANP da Tabela de Combustíveis Sujeitos à Tributação Monofásica, e a partir daí é validado o valor informado no respectivo campo da alíquota adrem de cada situação tributária com a coluna “adRemICMS” da tabela. Regras de Validação N39-10, N41-10 e N45-10 Estas regras visam garantir a consistência, para cada tipo de tributação monofásica sobre combustíveis, do Valor do ICMS, que deve ser obtido pela multiplicação da quantidade tributável pela alíquota adrem de cada situação tributária. Regras de Validação W06c-10, W06d-10 e W06e-10 O objetivo destas regras é realizar a totalização, respectivamente, do ICMS monofásico próprio, ICMS monofásico sujeito a retenção e do ICMS monofásico retido anteriormente, conforme valores informados nos itens da nota. E como fica o ACBr? Como o layout foi alterado por conta de novos campos, se faz necessário alterar o componente para que ele possa gerar se necessário for os novos campos. Consequentemente vamos disponibilizar uma nova versão do ACBrMonitor e do ACBrLibNFe. O componente ACBrNFe, quanto o ACBrMonitor e ACBrLibNFe vão estar prontos até o dia 03/03/2023 para que vocês possam realizar os testes em ambiente de homologação. Mais sobre esta NT Essa Nota Técnica tem o objetivo de atender o disposto no Convênio ICMS nº 199, de 22 de dezembro de 2022, que dispõe sobre o regime de tributação monofásica do ICMS nas operações com combustíveis nos termos da Lei Complementar nº 192/2022, e ao disposto no Ajuste SINIEF Nº 01/2023 em relação aos novos Códigos de Situação Tributária do ICMS. https://www.confaz.fazenda.gov.br/legislacao/convenios/2022/CV199_22 Sobre a Tabela de Combustíveis Sujeitos a Tributação Monofásica Para validação de algumas destas regras foi criada a Tabela de Combustíveis Sujeitos à Tributação Monofásica, que tem por objetivo facilitar a visualização da obrigatoriedade de preenchimento de campos e de alguns valores para cada produto sujeito a tributação monofásica sobre combustíveis. Os produtos presentes na tabela são identificados conforme o seu Código ANP. Além disso, a alíquota adrem de cada produto, será criada uma aba com o histórico de valores e a respectiva data de vigência. A criação desta tabela permite uma melhor parametrização dos ambientes autorizadores e das empresas, e evita que sejam feitas alterações constantes em Notas Técnicas para adequação das regras às novas situações que surgirem. As alterações necessárias na tabela serão feitas via Informe Técnico. A Tabela de Combustíveis Sujeitos à Tributação Monofásica se encontra publicada no Portal Nacional da NF-e, na aba “Documentos” opção “Diversos”. O prazo para entrada destas regras se encontra na descrição de cada uma delas.

Como a maioria já sabe, as soluções ACBr para emissão de NFSe são amplamente utilizadas por aplicações em todo o pais. Após levantamento recente, podemos afirmar que 99.9% das cidades com 200k habitantes ou mais já estão suportadas por nossas soluções. Mas calma, isso não quer dizer que as cidades com população menor não sejam suportadas, mas que ocasionalmente algumas podem AINDA não estar... Mais informações de como conferir se a cidade é ou não atendida neste artigo. O que fazer quando percebo que a cidade do meu cliente ainda não é suportada? O primeiro passo é identificar se de fato a cidade possui integração via WS e qual provedor atende esta cidade. Ciente do provedor e ele já estando no ACBrNFSeX, você pode criar um tópico relatando a nós, ou mesmo realizar o ajuste no arquivo INI e nos enviar. Saiba mais neste artigo de nossa Base de Conhecimentos. Agora se de fato é um novo provedor, você pode reportar a necessidade junto com a documentação num tópico do fórum ou mesmo colocar a mão na massa e realizar você mesmo a implementação! Apoie o ACBr fornecendo XMLs de Exemplo das seguintes Cidades Como citamos acima, temos um pequeno número de cidades com 200k habitantes ainda não atendidas, ou mais precisamente, 2 cidades, sendo elas: Camaçari/BA e Castanhal/PR. Basta enviar seu XML* para [email protected] fazendo menção a este tópico. *Fique tranquilo para remover as informações sensíveis antes do envio.

Boa tarde Guilherme, Eu validei a assinatura que consta no XML 2668.1-env.lot.xml e realmente esta invalida. Por outro lado fiz um teste usando o programa exemplo e tentei validar o XML de envio de lote através do mesmo site abaixo e a assinatura é valida. Não sei o que pode ter ocorrido. Receita Federal do Brasil - Validador de Assinaturas (fazenda.gov.br)

A variável imprimeSimp é que define se vai ser o simplificado ou não? Não está invertido o if? if imprimeSimp then begin ACBrNFe1.DANFE.TipoDANFE := tiSimplificado; ACBrNFe1.DANFE.ImprimirDANFEResumido(); end else ACBrNFe1.DANFE.ImprimirDANFE()

Boa tarde @jeffdelphi, Se puder detalhar um pouco mais ajuda na nossa compreensão da ocorrência. Tem alguma mensagem de erro? Pode postar o código que está usando. E sempre lembramos de atualizar o seu SVN e reinstalar o ACBr com a versão mais nova! Obrigado!

Boa tarde Willians, Essa desativação da validação da assinatura foi realizada somente em ambiente de homologação ou em produção também? Pois até onde sei o ambiente de homologação do provedor Fiorilli contem um bug que eles não admitem que é validar a tag Signature com o prefixo ns2, como podemos ver na mensagem de erro retornada pelo webservice: Invalid content was found starting with element 'ns2:Signature'.

Que bom que deu certo de descobrir a causa do problema! Muito obrigado por compartilhar a solução. Apenas uma última sugestão. Abandone Capicom.

Italo,boa tarde Descobri o erro,nao tinha nada a ver com pathschemas. Eram 2 erros: 1. Configurava esse parametro SSLLib com wincrypt e logo depois configurava novamente errado a. quando usava certificado A1 eu usava dm.ACBrNFSeX1.Configuracoes.Geral.SSLLib := libOpenSSL; b. quando usavca certificado A3 eu usava dm.ACBrNFSeX1.Configuracoes.Geral.SSLLib := libCapicom; 2.A senha do certificado so era preenchido quando usava certificado A1 dm.ACBrNFSeX1.Configuracoes.Certificados.Senha := AnsiString(w_senha); o Estranho e que funcionava normal na NF-e mas na NFs-e nao. Obrigado por tudo

Boa tarde, Contribuição aceita e integrada ao SVN em https://sourceforge.net/p/acbr/code/29364/ Obrigado @Paulo Alves N Junior.

Então o que tá mostrando ali é isso. mas tu deve de entrar em contato com eles para confirmar

Bom dia. Foi criada a #TK-3907 para análise da questão e parecer da equipe.

Olá Victor, na alteração ficou faltando uma correção. Segue a UNIT corrigida Marcelo ACBrBoletoRet_Bancoob.pas

Olá, Pesquisei sobre as especificações e realmente este modelo descreve que lê em telas de computadores ("A leitura de códigos na tela de smartphones ou computadores, boletos bancários, Danfes, códigos de barras danificados ou com baixa qualidade") Muito obrigado pela dica! Abraços, Sergio Oi Juliana, Como este tópico está aberto a muito tempo e o "programador Automaserv" me deu uma dica, pode considerar encerrado. Obrigado, Sergio

Bom dia @MSOL Vou passar um tópico sobre a NT que possa ajudar com alguma dúvida, mas o ideal é consultar o seu departamento fiscal ou o seu contador para te orientar da forma correta para evitar algum problema futuro de preenchimento que possa vir penalizar a software house.

Não. veja que só retorna a razão mesmo

Olá Pessoal, Abaixo temos informações sobre a convivência das versão 3.00 e 4.00 do CT-e, que vai até 31/01/2024. Colaboração do nosso amigo Alexandre Parabocz.

@Werner_Marques 31/03 subimos uma correção dos campos desconto2, desconto3 não estavam sendo gerados corretamente na remessa. como o @Renato Rubinho citou acima, os boletos foram homologados com sucesso com "0" zero. Neste post o usuário cita: "Passei pelo mesmo problema, ao tentar homologar mais um cliente. Porém já tenho outros clientes pleno funcionamento. Informo que fiz as alterações com os espaços mas o boleto foi igualmente rejeitado. E levei a contestação junto ao suporte, informando essa divergência. E hoje tive o ok, o arquivo remessa foi homologado, com os "0". " Por favor, caso não esteja atualizado, favor atualizar e gerar o boleto. Caso tenha o boleto rejeitado, por favor verifique com o suporte e se puder nos dar um feedback (pois seu post é anterior a atualização)

Bom dia! Tivemos um papo PRO com o excelentíssimo Marco Polo falando sobre a Tributação Monofásica de Combustíveis. Neste tópico tem o link desse bate papo e de outras informações que talvez possam lhe ser úteis:

Olá Victor, acabei de atualizar os fontes pelo SVN e entendo que a modificação feita não atende o requisito. Modificação feita: case HttpResultCode of 207: begin aJsonViolacoes := aJson.Values['resultado'].AsArray; for x := 0 to aJsonViolacoes.Count -1 do begin aJsonViolacao := aJsonViolacoes[x].AsObject; aJsonViolacoes := aJsonViolacao['status'].AsArray; ARejeicao := ARetornoWS.CriarRejeicaoLista; ARejeicao.Codigo := aJsonViolacao.Values['codigo'].AsString; ARejeicao.mensagem := aJsonViolacao.Values['mensagem'].AsString; end; end; 400,406,500 : begin aJsonViolacoes := aJson.Values['mensagens'].AsArray; for x := 0 to aJsonViolacoes.Count -1 do begin aJsonViolacao := aJsonViolacoes[x].AsObject; ARejeicao := ARetornoWS.CriarRejeicaoLista; ARejeicao.Codigo := AJsonViolacao.Values['codigo'].AsString; ARejeicao.mensagem := AJsonViolacao.Values['mensagem'].AsString; end; end; end; Onde está o problema no meu ponto de vista: HTTPResultCode=207 indica tanto sucesso de registro de boleto quanto erro. Não acho correto preencher a lista de violações de regras sendo que quando o boleto é registrado não houve violação de nenhuma regra. Insisto que quando aJsonViolacao.Values['codigo'].AsString estiver retormadp com 200, nada a fazer, boleto registrado com sucesso. Quando retornado com 400 aí sim tem problema a ser corrigido.

Bom dia! Primeiro de tudo, muito obrigado pela contribuição! Toda e colaboração sempre será mais do que bem vinda! A sua contribuição me parece correta e por isso foi enviada ao SVN na Rev-29335. Por favor, queira atualizar seus fontes, reinstalar o ACBr para realizar novos testes e reportar qualquer problema.

OK, Juliomar ! É um prazer ajudar meu amigo ! Segue em anexo a Unit corrigida. ACBrEFDBloco_1_Importar.pas

Olá pessoal, No Portal do CT-e da SEFAZ-Virtual do RS temos a seguinte informação: 11/04/2023 Nota Técnica 2023.002 - Eventos de Insucesso na Entrega v1.01 Especifica os eventos de Insucesso na Entrega e Cancelamento do Insucesso na Entrega do CTe. São eventos exclusivos da versão 4.00 Datas: 15/05/2023 em homologação e 17/07/2023 em produção [v1.01 - Correção no código do evento de cancelamento do insucesso] O correto é 110191 e não 110181 como consta na versão 1.00 da Nota Técnica.

Contextualizando. As configurações de SSLLib, CryptLib, HttpLib, XmlSignLib e SSLType são comuns a todos as soluções de Documentos Fiscais Eletrônicos do ACBr. Aqui vamos considerar os exemplos nativos, mas essas configurações também se aplicam ao ACBrMonitorPLUS e ACBrLib. As configurações SSLLib, CryptLib, HttpLib e XMLSignLib costumam ficar na aba Certificado dos programas exemplo e podem ser definidas via código da seguinte maneira: ComponenteDFe.Configuracoes.Geral.SSLLib := libOpenSSL ou libWinCrypt;//Dependendo do tipo de certificado ser A1 ou A3. ComponenteDFe.Configuracoes.Geral.CryptLib := cryOpenSSL ou cryWinCrypt;//Dependendo do tipo de certificado ser A1 ou A3. ComponenteDFe.Configuracoes.Geral.SSLHttpLib := httpOpenSSL ou httpWinHttp;//Dependendo do tipo de certificado ser A1 ou A3. ComponenteDFe.Configuracoes.Geral.SSLXmlSignLib := xsLibXml2; Se o certificado digital for A3 só vai ser possível usar as configurações do WinCrypt, por outro lado se for A1 poderá usar o WinCrypt ou OpenSSL. Recomendamos fortemente que o certificado seja A1. Desta forma podemos usar o OpenSSL e não precisamos nos preocupar com a versão Windows e suas atualizações. Além disso, o certificado não precisa ser instalado, pode ser lido de uma pasta onde esta salvo ou de um campo do banco de dados. Essas configurações influenciam comportamentos como protocolo de comunicação, assinatura, validação de schema, entre outros. Já a configuração SSLType costuma ficar na aba WebService dos programas exemplos e pode ser definida via fonte assim: ComponenteDFe.SSL.SSLType := LT_TLSv1_2; Como o nome sugere, essa configuração influencia se vai qual protocolo TLS ou SSL será usado na comunicação. Porque você está atrasado. Além de não suportar 64 bits, a Microsoft condenou a CAPICOM como obsoleta desde 2016. Então, se você ainda usa configuração de Capicom está usando algo defasado, aberto a erros e com brechas de segurança. A MsXML foi descontinuada pela Microsoft em 2014 e atualmente é considerada obsoleta. Usar essa configuração para assinatura ou validação significa usar algo ultrapassado, que não sofre manutenção e com maior propensão a erros. Se você vai usar certificado A3, não deve em hipótese alguma usar MsXML, sob risco de inutilizar a chave privada do certificado digital. Praticamente todos os DFes atuais estabeleceram que deve ser usado TLS1.2 na comunicação. Por isso, foi atualizado nos fontes para que os DFes usem como padrão TLS1.2 ao invés de LT_all. Se você mesmo assim ainda usa essa configuração, o componente vai usar o primeiro protocolo disponível e não o mais indicado. O que eu uso então? As configurações recomendadas por tipo de certificado podem ser encontradas neste tópico: Caso prefira, também pode acompanhar este vídeo com orientações e demonstração prática: Mais informações. Veja mais detalhes sobre como o ACBr deu Bye Bye para a Capicom neste tópico: No tópico abaixo foi relatado o problema com MsXML e perda da chave privada de certificados A3:

Boa tarde. Na cidade de Concórdia-SC ainda estão com a versão antiga do serviço, essa versão não retorna o xml da nota fiscal. No xml de retorno tem uma tag "conteudo_html", com essa informação é possível gerar o arquivo HTML para poder enviar para os clientes, porém, o ACBr remove essas informações do XMLRetorno. Para não mexer no conteúdo do XMLRetorno, pensei em criar uma nova propriedade, a HTMLRetorno, onde nessa propriedade será retornado esse conteúdo. Fiz vários testes e deu certo, consegui obter o html na minha aplicação e distribuir para os clientes. Estou enviando os arquivos alterados para validação. Obrigado. ACBrNFSeXProviderBase.pas ACBrNFSeXWebservicesResponse.pas ACBrNFSeXWebserviceBase.pas

Pessoal, estava tendo problema com esse erro na hora de associar minha software house com o cliente no sat. Acontece que eu tinha renovado o certificado, e fiquei um dia batendo a cabeça pra resolver esse problema, então descobri que lá no "Sistema de Gestão e Retaguarda do SAT-CF-e" na secretaria da fazenda, no cadastro da minha software house estava o certificado antigo, alterei para o novo e resolveu problema. Como não encontrei essa solução em nenhum tópico, estou abrindo esse para ajudar quem precisar. Abraços. Éber.