Painel de líderes

Descobri onde estava o problema. Eu estava enviando via socket o mesmo conteúdo como se fosse o método via troca de arquivos "NFe.CriarEnviarNFe("C:\ACBrMonitorPlus\Entrada\Exemplos\0000002631.req",1,1)" e não o conteúdo do arquivo "ini". Seria interessante alterar a mensagem de erro. RESOLVIDO!

Bom dia, Fiz uma alteração na classe TACBrBancoCresol adicionando algumas espécies de documento que constam no manual de integração de boletos da CRESOL, porém na classe não tinha. O arquivo está em anexo. att ACBrBancoCresol.pas

Daniel, Entrei em contato com a SkyTef agora vou esperar as instruções. Obrigado

Boa tarde a todos! Problema: Hoje realizando testes de homologação de NFSe para cidade de Garibaldi - RS verificamos uma inconsistência na Unit: pnfsNFSeW_Infisc.pas {para Garibaldi - RS 4308607 Não existe as tags abaixo} if (NFSe.PrestadorServico.Endereco.CodigoMunicipio <> '4308607') then begin { Ambiente 1- Producao 2- Homologacao } Gerador.wCampoNFSe(tcStr, '', 'ambienteEmi' , 01, 01, 1, SimNaoToStr(NFSe.Producao), ''); { forma de emissao 1- portal contribuinte 2- servidor web 3- submetidos via Upload no portal 4- emissao via RPS } Gerador.wCampoNFSe(tcStr, '', 'formaEmi' , 01, 01, 1, '2', ''); { 1- construcao civil 2- outros casos } Gerador.wCampoNFSe(tcStr, '', 'empreitadaGlobal', 01, 01, 1, EmpreitadaGlobalToStr(NFSe.EmpreitadaGlobal), ''); end; Este provedor, ao menos desta cidade passou a considerar duas destas três tags que são elas: ambienteEmi formaEmi Solução encontrada: O que geramos foi rebaixar a condicional apenas para "empreitadaGlobal", com isso conseguimos gerar a emissão da NFSe em ambiente de homologação. Essa modificação será disponibilizada no repositório do ACBR ?

Boa tarde Jozimar, Favor anexar a unit alterada para que possamos analisar.

ok... você pode estudar os fontes do TEFDDemo, na pasta Exemplos... mas é fundamental, ter conhecimento do TEF... Primeiro escolha qual será o gerenciador TEF suportado... Se for trabalhar com o SiTef (líder do mercado), solicite informações de homologação com a SkyTEF - http://www.skytef.com.br/ Se for trabalhar com o Pay&Go: https://www.paygo.com.br/homologue-2/

Boa tarde, Notei que a quantidade de caracteres informado no campo xJust (justificativa do cancelamento) tem menos de 15 caracteres. Favor realizar um novo teste de tal forma que a quantidade de caracteres informado no campo xJust tenha no mínimo 15 e no máximo 255.

Use o método DistribuicaoDFePorUltNSU. Nele você passe o NSU = 0. Com isso, você terá como resposta os NSU's dos últimos 90 dias. Detalhe: O DistribuicaoDFePorUltNSU retorna apenas 50 NSU's por vez. Então caso tenha mais do que 50 você terá que executar mais de uma vez. E a cada execução, você passa o último NSU que você recebeu. Aí você me pergunta; como eu sei que tem mais do que 50 pra eu baixar? Simples, existe uma propriedade que consta o número máximo de NSU que tem no WebService. Então resumindo a lógica seria mais ou menos assim: iUltimoNSUGravado := GetUltimoNSUGravado; repeat ACBrNFe1.DistribuicaoDFePorUltNSU(IdEstado, aCNPJ, iUltimoNSUGravado); cStat := ACBrNFe1.WebServices.DistribuicaoDFe.retDistDFeInt.cStat; if cStat = 138 then {Documentos encontrados} begin iMaxNSUWebService := StrToIntDef(ACBrNFe1.WebServices.DistribuicaoDFe.retDistDFeInt.maxNSU, 0); for i := 0 to Pred(ACBrNFe1.WebServices.DistribuicaoDFe.retDistDFeInt.docZip.Count) do begin {Aqui você processa NSU por NSU. Inclusive grava o NSU no banco de dados} end; end; iUltimoNSUGravado := GetUltimoNSUGravado; until (iUltimoNSUGravado = iMaxNSUWebService);

O ACBR nao tem essa integração, fiz na munheca com a ajuda da própria Mamut. Entre em contato com eles que te ajudam nisso. Não há a necessidade de te enviar codigos pois eles ja possuem exemplos em Delphi.

Boa tarde. Problema resolvido. Não sei se pode ajudar alguém, mas os meus códigos eram esse, Prefeitura de Barrinha <ItemListaServico>07.02</ItemListaServico> <CodigoTributacaoMunicipio>900702</CodigoTributacaoMunicipio>

Obrigado por reportar. Fechando este tópico. Para novas dúvidas, crie novo tópico.

corrigindo acima PARA NÃO CONSUMIDOR FINAL, indfinal=0

a mudanças nas urls pra alguns estados começaram a valer desde segunda-feita - 20... para que está mudando gradativamente :@ mas de fato, só atualizar os fontes e compilar, ou atualizar os fontes e distribuir o arquivo ACBRNFeServicos.ini dentro da pasta onde fica teu executável

Uma duvida, digamos que eu apenas esteja citado como AutXML, a unica pessoa que pode dar a ciência seria o destinatario, correto? Se ele não der, eu não tenho acesso ao xml completo? ou eu poderia dar a ciência ?

Fabricio estou com essa necessidade também. Quanto voce cobraria para desenvolver isso. Speed Contribuição e Speed Fiscal? Ja tenho uma ERP rodando em clientes com tributação diferenciada. Obrigado

Queria saber o por que tem o retorno P, vou analisar mais uma vez o manual.

O comando de QRCode realmente é diferente do padrão Epson EscPos... e não é equivalente a nenhum das impressoras suportadas atualmente pelo ACBrPosPrinter Não parece ser difícil de implementar... mas isso é impossível, sem um equipamento na bancada, para testes...

Bom dia Luiz. É o que estamos discutindo neste tópico. Dê uma lida por completo nele que vai encontrar a solução.

Problema resolvido. Para a mensagem da aliquota bastou eu colocar 0.00 que passou. Estou procurando código de tributação do municipio. Obrigado.

Bom dia, As URLs do webservice se encontra no arquivo INI do respectivo provedor. Esses arquivos INI se encontram na pasta: ...\Exemplos\ACBrDFe\ACBrNFSe\ArqINI

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

Aparentemente o que está errado é o código de tributação do município. Já consultou o manual ou a prefeitura?

Algumas razões possíveis: - Não foi compilado o ACBrNFeServicos.res depois de alterar o ACBrNFeServicos.ini; - O compilador encontrou um ACBrNFeServicos.res desatualizado e usou ele em vez do correto; - Existe um arquivo ACBrNFeServicos.ini desatualizado no diretório da aplicação

Você tem o manual de impressão direta dela ? Manual onde é descrito os comandos EscPos que ela aceita e sintaxe dos mesmos... Pode ser que seja necessária uma atualização do Firmware...

To com o mesmo problema para Rondônia em Homologação, alterei os URLS no ini para como estava no site do encat, mas ainda continua acusando erro [NFCe_RO_P] Usar=NFCe_SVRS_P URL-QRCode=http://www.nfce.sefin.ro.gov.br/consultanfce/consulta.jsp URL-ConsultaNFCe=http://www.nfce.sefin.ro.gov.br URL-ConsultaNFCe_2.00=www.sefin.ro.gov.br/nfce/consulta [NFCe_RO_H] Usar=NFCe_SVRS_H URL-QRCode=http://www.nfce.sefin.ro.gov.br/consultanfce/consulta.jsp URL-ConsultaNFCe=http://www.nfce.sefin.ro.gov.br URL-ConsultaNFCe_2.00=www.sefin.ro.gov.br/nfce/consulta

Não existe mais frete por conta do emitente, desde a NFe 4.00.

Essa regra de validação é opcional por UF e, a partir do dia 20 de maio de 2019, foi ativada para o Estado do Rio de Janeiro. Sugerimos a leitura da: primeira linha da pág. 27 da Nota Técnica 2015.002 - v 1.41 disponível no Portal Nacional da NF-e. última linha da pág. 66 da Nota Técnica 2016.002 - v 1.61 (publicada em 10/09/2018) disponível no Portal Nacional da NF-e. Atenciosamente, Coordenadoria de Documentos Fiscais Eletrônicos Secretaria de Estado de Fazenda e Planejamento do Rio de Janeiro As dúvidas esclarecidas por meio desta mensagem têm caráter de simples orientação, não produzindo os efeitos do instituto denominado Consulta Tributária, definido pelos artigos 150 a 165 do Regulamento do Processo Administrativo Tributário, Decreto Estadual nº 2.473/79.

Bom dia É um problema recorrente da SEFAZ de MG. Ontem a tarde ocorreu comigo. Minutos depois consegui emitir. Creio que o motivo já está claro.

Tópico dividido de: Essa é a URL que consta no ACBrNFeServicos.ini, provavelmente o seu arquivo está desatualizado.

Na verdade, a minha interpretação da mensagem é que ela estava acusando uma tag de ser inválida, e em seguida dá sugestões de outra tag disponível (que é a vICMSSubstituto). Eu interpretei errado ou a Sefaz não deixou muito claro. O problema realmente era do lado da Sefaz mesmo. Para tentar resolver, fiz o teste do colega do outro tópico, e, ativando a propriedade "ForcarGerarTagRejeicao938" agora foi autorizada normal. Muito obrigado! Só para eu entender melhor, a única tag a ser tratada pela propriedade "ForcarGerarTagRejeicao938 " é "vICMSSubstituto", correto?

Italo muito obrigado pela orientação.

Provavelmente o seu método CriaConexao está sendo chamado mais de uma vez, antes de ser chamado o método DestroiConexao.

Luís, Primeiro, compare o XML gerado com o componente antigo (trunk1) com o XML gerado com o componente novo (trunk2). Segundo, os schemas utilizados para validação em ambos os casos, são exatamente os mesmos?

Boa tarde Antônio, Peço que não fique realizando a mesmo questionamento em vários tópico, por favor vamos seguir as regras do fórum. A sua duvida já respondi em uma outra postagem.

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

Boa tarde, O erro de agora era esse mesmo Ítalo. Consegui fazer o envio com sucesso agora (carregando via INI e enviando). Vou continuar os trabalhos e qualquer dúvida volto a postar. Muitíssimo obrigado pela ajuda.

Boa tarde Adilson, Você procurou no XML essa alíquota indevida que a mensagem se refere? Existem várias informações erradas no seu XML, enquanto você não passar as informações corretas o seu RPS vai ser rejeitado.

Exatamente! Homologuei assim também! esse mês passado. Não que seja errado você confirmar após a impressão mas o roteiro dessa forma passa ser exatamente o roteiro do PAF. Então você pode autorizar a NFC-e após a confirmação do TEF.

Na época das ECF, a regra do TEF era imprimir antes e confirmar depois. Agora com o SAT/NFC-e, a regra se inverteu: confirmar antes e gerar o documento fiscal / imprimir depois. Homologuei SiTEF dessa maneira no final do ano passado.

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

Problema corrigido no sefaz. Obrigado a todos.

ola para quem não tem TEF tpIntegra := tiPagNaoIntegrado; para quem tem TEF tpintegra:=tipagintegrado

Estou usando ACBrECFVirtualNFCe. Descobri a causa do problema. O problema acontece quando habilito a opção ImprimeLogoLateral no componente ACBrNFeDANFeESCPOS. Ao desmarcar essa opção, a impressão ocorre normalmente.

Boa tarde Pessoal, Os documentos: CT-e - Conhecimento de Transporte Eletrônico e CT-e OS - Conhecimento de Transporte Eletrônico Outros Serviços, possuem um evento chamado: Prestação do Serviço em Desacordo. O autor desse evento, ou seja, que envia ele para a SEFAZ é o tomador do serviço. Esse evento, permite ao tomador informar ao Fisco que o CT-e/CT-e OS que o relaciona esta em desacordo com a prestação do serviço. O tomador tem um prazo máximo de 45 dias a contar da data de autorização do CT-e/CT-e OS para enviar o evento. Detalhe importante: O evento tem que ser enviado para a SEFAZ do emitente do CT-e, supondo que o emitente seja de São Paulo devemos: 1. Configurar o componente para a UF do Emitente (Configuracoes.webservices.UF := 'XX'; // onde XX é a UF do Emitente do CT-e) 2. Ao alimentar o componente informar em cOrgao a UF do Emitente do CT-e. Como montar a rotina para enviar o evento: ACBrCTe1.EventoCTe.Evento.Clear; with ACBrCTe1.EventoCTe.Evento.Add do begin infEvento.nSeqEvento := 1; // Para o Evento de Prestação do Serviço em Desacordo nSeqEvento sempre = 1 InfEvento.cOrgao := UFtoCUF(xUF); // Devemos informar a UF do Emitente do CT-e infEvento.chCTe := Copy(ACBrCTe1.Conhecimentos.Items[0].CTe.infCTe.Id, 4, 44); infEvento.CNPJ := xCNPJ; // CNPJ do Tomador infEvento.dhEvento := now; infEvento.tpEvento := tePrestDesacordo; infEvento.detEvento.xObs := trim(sOBS); // minimo 15, máximo 255 caracteres end; iLote := 1; // Numero do Lote do Evento ACBrCTe1.EnviarEvento(iLote); No exemplo acima o XML do CT-e/CT-e OS foi carregado, mas não se faz necessário, caso não deseja carregar o XML basta informar a chave (44 dígitos) ao campo chCTe. No campo xObs deve constar uma observação do tomador que justifique o desacordo do serviço prestado. Em caso de dúvidas, clique aqui para criar um novo tópico.

Atualizado em: 16/05/2019 - Revisado em: 01/07/2022 Documentos Aceitos Atualmente NFCe Situação por Tipo de Documento NF de Venda ao Consumidor (Mod. 2): Nas operações de saídas a varejo realizadas fora do estabelecimento, relativas às saídas de mercadorias remetidas sem destinatário certo a que se refere o art. 330 do Regulamento do ICMS, aprovado pelo Decreto n. 6.080, de 28 de setembro de 2012, o contribuinte poderá, alternativamente, emitir a Nota Fiscal de Consumidor, modelo 2, desde que os documentos fiscais relativos à remessa e ao retorno sejam NF-e, modelo 55. ECF 85: Não aceito ECF 09/09: Não aceito NFCe: Exigido (Inclusive cadastro da SH junto a SEFAZ-PR) SAT: Não aceito MFe: Não aceito Situação Responsável Técnico Conforme publicado na NT 2018.005 versão 1.30 que pode ser vista aqui, a partir de 03/06/2019 serão exigidos somente os dados relativos a identificação do Responsável Técnico como CNPJ e demais itens. Quanto as informações relativas ao CSRT - Código de Segurança do Responsável Técnico, assim como nas demais UFs a exigência destas informações foi prorrogada para data a ser definida. Obs.: Os mecanismos para geração do idCSRT / CSRT ainda estão sendo preparados e sua liberação será divulgada no portal da SEFAZ-PR. Situação PAF-ECF: Não aceito Para uma visão geral dos documentos fiscais em todas as Unidades da Federação acesse nosso Mapa Fiscal. Para obter o guia de cadastro/credenciamento de sua Aplicação Fiscal junto ao SEFAZ, acesse nossa sessão de Downloads, os Requisitos Fiscais por UF. 

Olá Pessoal, Vejo muitos XML de CT-e que contem as informações sobre o Expedidor e o Recebedor. Quando devemos informa-los e em quais situações? Em um transporte de carga normal, ou seja, a transportadora pega a carga do Remetente e leva até o Destinatário não devemos informar o Expedidor e o Recebedor. O Expedidor e ou Recebedor só aparecem quando existe uma outra transportadora envolvida no transporte da carga e é essa transportadora que é informada como Expedidor ou como Recebedor. Vamos a um exemplo onde temos o transporte Normal, Redespacho e Redespacho Intermediário. Exemplo: Transportadoras envolvidas: A, B e C Remetente -> A -> B -> C -> Destinatário A transportadora A emite um CT-e Normal informando: Remetente: o remetente da mercadoria (quem vendeu) Destinatário: o destinatário da mercadoria (quem comprou) Recebedor: Transportadora B (o Recebedor foi informado pois a transportadora A não vai levar a carga até o Destinatário. o Expedidor não foi informado pois quem expediu a carga foi o Remetente que já esta informado) A transportadora B emite um CT-e de Redespacho Intermediário Remetente: o remetente da mercadoria (quem vendeu) - Opcional Destinatário: o destinatário da mercadoria (quem comprou) - Opcional Expedidor: Transportadora A (o Expedidor foi informado pois a carga não foi expedida pelo Remetente e sim pela Transportadora A) Recebedor: Transportadora C (o Recebedor foi informado pois a transportadora B não vai levar a carga até o Destinatário) A transportadora C emite um CT-e de Redespacho Remetente: o remetente da mercadoria (quem vendeu) Destinatário: o destinatário da mercadoria (quem comprou) Expedidor: Transportadora B (o Expedidor foi informado pois a carga não foi expedida pelo Remetente e sim pela Transportadora B. o Recebedor não foi informado pois quem vai receber a carga é o Destinatário que já esta informado) Note que a transportadora A pegou a carga do Remetente e levou até a transportadora B, esta por sua vez levou até a transportadora C, e esta por sua vez levou a carga até o destinatário.

Olá pessoal, Na postagem "Como obter o XML do Fornecedor" mostrei o uso do método DistribuicaoDFePorChaveNFe, nessa nova postagem vou mostrar mais dois métodos: DistribuicaoDFePorUltNSU e DistribuicaoDFePorNSU. Vamos a sintaxe, que por sinal é semelhante ao do DistribuicaoDFePorChaveNFe. DistribuicaoDFePorUltNSU( <código da UF do destinatário>, <CNPJ do destinatário>, <numero do ultimo NSU> ) DistribuicaoDFePorNSU( <código da UF do destinatário>, <CNPJ do destinatário>, <numero do NSU> ) Primeiramente vamos entender o que vem a ser esse tal de NSU. NSU - numero sequencial único, é um numero atribuído pelo Ambiente Nacional ao documento ora compartilhado pelas SEFAZ-Autorizadora. Exemplo: o emitente da nota é do Estado de São Paulo, logo a nota é enviada para a SEFAZ-SP esta por sua vez vai compartilhar com o Ambiente Nacional as notas que foram autorizadas, o Ambiente Nacional por sua vez atribui um NSU para cada nota que receber. Na verdade o Ambiente Nacional gera um resumo da nota e atribui o NSU a esse resumo primeiramente e não a nota propriamente dita. Um NSU só será atribuído a nota quando o destinatário enviar o evento de Manifestação do Destinatário. Lembre-se o NSU da nota será um numero diferente do NSU do resumo dela, e por ser gerado após o envio do evento de Manifestação do Destinatário, podemos concluir que o NSU da nota é maior que o NSU do resumo. Vamos agora entender como funciona os dois métodos mencionados acima. O método DistribuicaoDFePorNSU é o mais simples de entender, pois este simplesmente baixa o documento que possui o NSU informado. Note que usei o termo documento, pois o webservice DistribuicaoDFe pode retornar os seguintes tipos de documentos: Resumo de Nota, Nota Completa, Resumo de Evento e Evento Completo. Se o NSU informado no método DistribuicaoDFePorNSU for o NSU de um resumo, o que teremos como retorno será o XML do resumo e não o XML da Nota. Por outro lado o método DistribuicaoDFePorUltNSU nos retorna uma lista com até 50 documentos, cujos NSU são superiores ao NSU informado. Exemplo: DistribuicaoDFePorUltNSU( 35, 12345678000123, 450 ) ===> 450 é o valor do Ultimo NSU. Ao executar o método, como dito anteriormente poderá nos retornar uma lista com até 50 documentos, pois bem suponha que retorne 50, os NSU desse documentos retornados serão, 451, 452, 453, ...., 498, 499, 500. Lembre-se que nessa lista podemos ter Resumos de Notas, Notas Completas, Resumo de Eventos e Eventos Completos. Através de uma propriedade chamada Schema nos traz a informação do tipo de documento retornado. Temos também outras duas propriedades muito importantes, são elas: UltNSU e MaxNSU. A propriedade UltNSU nos informa o numero do NSU referente ao ultimo documento da lista, já a propriedade MaxNSU nos informar o maior NSU existente no Ambiente Nacional. Continuando o exemplo acima, vamos supor que após a execução os valores de UltNSU e MaxNSU são respectivamente 500 e 750. Era de se esperar mesmo que o valor de ultNSU seja 500 pois informamos 450 e foi retornado 50 documentos, logo o NSU do ultimo é 500. A próxima vez que formos executar o DistribuicaoDFePorUltNSU devemos informar o valor 500, para que ele retorne os documentos a partir de 501 que é o próximo da lista. E devemos repetir o procedimento até que o valor de ultNSU seja igual a maxNSU, desta forma vamos ter baixado todos os documentos disponibilizados pelo Ambiente Nacional. Lembre-se que o valor de MaxNSU tende sempre a crescer a medida que novas notas forem emitidas e compartilhadas com o Ambiente Nacional e a medida que o destinatário for enviando o evento de Manifestação do Destinatário. Entre uma execução e outra do DistribuicaoDFePorUltNSU você pode realizar a manifestação referente a cada resumo de nota obtido, ou seja, enviar o evento de Manifestação do Destinatário. Desta forma a medida que você vai avançando na lista o Ambiente Nacional já vai liberando a Nota Completa (notas manifestadas) e disponibilizando ela na lista. O DistribuicaoDFe não serve apenas para que possamos obter o XML do fornecedor, mas também descobrirmos se existe alguma empresa emitindo notas contra o nosso CNPJ sem no nosso consentimento. Você descobre isso através do DistribuicaoDFePorUltNSU e pode avisar a SEFAZ enviando o evento de Manifestação do Destinatário: Desconhecimento da Operação. Esse evento diz a SEFAZ que você não comprou desse fornecedor. Para saber mais sobre Manifestação do Destinatário vide a Nota Técnica 2012/002 versão 1.02 e para saber mais sobre o Distribuição DFe vide a Nota Técnica 2014/002 versão 1.02b, ambas estão disponíveis no Portal Nacional da NF-e.

Olá amigos, depois de mais um cliente ter perdido o certificado resolvi que ia tentar descobrir oque estava causando isso, e depois de muita peleja(são 4:00 da manhã ), acho que consegui chegar ao causador do problema, pelo menos tive sucesso em excluir um certificado por diversas vezes assinando um XML. E como muito se falava, não é diretamente o ACBR que está excluindo o certificado, pelo que constatei é a MSXML que está "reiniciando" o certificado e somando isso a mais algum problema está causando a exclusão. Se você assinar um XML e deixar o administrador do token aberto, verá que no momento da assinatura, no trecho "xmldsig.sign(dsigKey, CERTIFICATES);" o token muda de: Operacional >> Ausente >> Presente >> Operacional, como se o cartão fosse removido e inserido novamente. Pensei aí tem coisa! Tentei remover o cartão durante a assinatura mas não consegui simular a exclusão do certificado, imaginei que não estava sendo rápido o suficiente. Então coloquei um loop no trecho do ACBR que pega a chave privada do certificado, antes de executar a assinatura, percebi que até aí o PIN do certificado não era solicitado, somente mais a frente quando ocorre a assinatura com "xmldsig.sign(dsigKey, CERTIFICATES);". Porém quando removi o certificado da leitora e inseri novamente dentro do loop(o mesmo que a MSXML faz durante a assinatura) foi me solicitado o PIN e logo depois veio a mensagem: "O conjunto de chaves não está definido", olhando no administrador do token que estava aberto pude ver o certificado sendo excluído: O PIN que ele me solicitou foi para excluir o certificado! O que imagino que esteja acontecendo é que se você chamar o método Assinar repetidamente, antes de dar tempo do cartão ficar operacional novamente, o certificado pode ser excluído. Isso explicaria o porque da exclusão ser esporádica e também não acontecer com todos os sistemas, pois dependeria da lógica usada por cada um para assinar, como assinaturas em sequência ou mesmo mais de uma thread acessando o certificado. Fiz um vídeo mostrando o momento da exclusão, note que não consegui excluir na primeira tentativa, porque demorei muito pra inserir o cartão, estava com uma mão ocupada filmando, ia editar isso mas tô com muito sono. MODERAÇÃO: vídeo removido a pedido do usuário Vou dormir um pouco e amanha ver se me aprofundo no problema.

Vendo o seu vídeo e de acordo com as suas investigações... a única medida prática e efetiva, seria deixar na Tela, uma mensagem clara e visível ao usuário... "ACESSANDO CERTIFICADO DIGITAL. NÃO REMOVER O CARTÃO..." As empresas que emitem o Certificado, não tem qualquer relação com a MSXML.dll.. ela e feita pela Microsoft e está depreciada... Eu particularmente, recomendo a meus clientes, que evitem a todo custo, certificados A3... a diferença de preço entre um A3 e A1, me parece ser "economia a base da porcaria"... A3 gera muito suporte e trabalho... Ele seria mais seguro, é claro.... isso se todos não usassem "1234" na senha, ou colassem uma etiqueta com a Senha no cartão... então.. só vejo desvantagens em usar A3 O que provavelmente está excluindo o Certificado, é justamente isso... a falha na autenticação do mesmo... Isso é uma medida de segurança, que é de conhecimento de todos... se você digitar a senha errada várias vezes, a própria biblioteca de acesso ao certificado excluirá o mesmo...