Daniel Simoes

Qual a sua IDE e S.O. ? Qual o seu tipo de certificado ? Qual UF e WebService ? libCapicom -> usa uma implementação interna do ACBr para abrir o certificado e usá-lo em uma comunicação segura... libCapicomDelphiSoap -> usa os métodos do Delphi para comunicação com SOAP

Em teoria deveria funcionar... afinal ela usará a chave que está no próprio XML... Pode ser que o código de inicialização da SSL, esteja passando pela rotina que tenta carregar o certificado...

Veja as propriedades de configuração do componente ACBrNFe

Como reproduzir o problema usando o Demo do ACBrNFe ?

Tente usar libCapicomDelphiSoap em SSLLib

Agora que vi que você "estava no assunto"... me desculpe... Acredito que o Juliomar já tenha enviado uma correção para esse problema com o D7

Se deseja propor modificações para os fontes... favor anexar (zip) as Units modificadas...

D7 Sucks... hoje em dia temos muito trabalho pra manter a compatibilidade com essa antiga IDE...

Na verdade o PosPrinter não usa essa DLL.. Dê mais detalhes do que você está tentando fazer...Muito poco provável que o A.V. seja causado pelo PosPrinter... Ttente com o Demo, PosPrinterTeste... tente com a versão já compilada e disponível aqui no fórum

Notamos que isso realmente é uma deficiência do D7... Hoje em dia manter a compatibilidade com o D7 está cadas vez mais complicado... limita muito o desenvolvimento... É provável que seja definida uma data limite para suporte do ACBr, de versões que não suportem UTF8

2.2 - Permaneça no assunto - Quando tiver uma dúvida diferente do assunto no tópico, poste em novo tópico. Não use algo equivalente a "aproveitando o gancho... [dúvida não relacionada com o tópico aqui]". Favor leia as regras do fórum.

Primeiro instale o Fortes Report... Se você não consegue instalá-lo... entre em contato com o suporte deles...

Especifique melhor o que você pretende fazer... Rodar o programa remoto e espetar o SAT na USB de uma máquina Local ?? Veja que o problema nesse caso não é do SAT ou do ACBr... é algo que depende única exclusivamente o TS... Se ele permitir "mapear" uma porta USB do Cliente para o Servidor pode funcionar... mas a meu ver, isso será uma eterna fonte de dor de cabeças... PDV sempre deve ser projetado para rodar de forma local...e é desejável que ele continue funcionado, mesmo quando completamente OFF-LINE

REgys, Eu notei o mesmo problema ontem, logo após o seu commit... parece que o Lzarus não reconhecia o arquivo como UTF8... Eu enviei uma possível correção para o problema, logo após

Na verdade é o oposto... Em sistema 64bits: SYSWOW64 -> DLLs 32 Bits system32 -> DLLs 64Bits Porque a MS fez isso... acho que só eles compreendem...

Aparentemente você não instalou o Fortes Report CE https://github.com/fortesinformatica/fortesreport-ce

Estranho... isso não deveria ser necessário, já que existe o conceito de arquivos UTF8 sem o BOM... e a TAG do tipo do XML deveria ser tudo o que o Browser precisa...

Ao invés de incluir o "BOM" no inicio do arquivo... experimente a adicionado no inicio do XML: <?xml version="1.0" encoding="UTF-8"?>

Nenhum desse erros é normal... provavelmente há algo errado na instalação da sua IDE...

Esse modelo realmente usa ppEscPosEpson

Mas todo o retorno dos WebServices já devem estar em UTF8... (UTF8 é o padrão exigido em todos os Documentos Fiscais Eletrônicos)... Então não seria necessária nenhuma conversão o XML retornado...

alguma coisa muito errada com o seu ambiente Delphi, "BufDataset" só existe no Lazarus

Como reproduzir o problema, usando o Demo do MDFe (pasta Exemplos) ?

Não distribua as mesmas DLLs em várias pastas... caso contrário fica impossível descobrir qual delas o Windows está usando... Se o seu sistema é 64bits e as DLLs são 32bits (essas são)... Você deve copiá-las para a pasta: SysWOW64

Copie todas as DLLs da pasta OpenSSL e XMLSec para a pasta do sistema ou na mesma pasta do seu .EXE