Daniel Simoes

O uso de TCP para comunicação com o Monitor, não nenhuma relação com o Tipo de Certificado... Veja com mais atenção as telas de configuração... Você pode salvar a senha...

Aqui no fórum, na área do ACBrSAT, vários usuários disponibilizaram programas já compilados, para essa finalidade

Lembre-se que o ACBr é OpenSource... então você mesmo pode ler os fontes e descobrir como funciona... Rode o SATTeste.exe estude os fontes deste projeto... Veja o Capitulo 6 da na Especificação Técnica do SAT

Aguardo o seu retorno, com o passo a passo de como reproduzir o problema usando o Demo do ACBrNFe

Corrigido, obrigado por reportar...

Vamos tentar isolar o problema ok ? O ideal é usar a aplicação demo do ACBrNFe... pois se nela o problema ocorrer, eu também poderei reproduzi-lo... Se não ocorrer, pode ser algum ajuste necessário a ser feito nos seus fontes... Minha suspeita é que você está usando uma versão defasada do ACBrNFeServicos.ini / ACBrNFeServicos.res Observe que no componente ACBrNFe.Configurações.Arquivos.IniServicos, você pode especificar o caminho do "ACBrNFeServicos.ini"... isso é muito útil para modificar/testar URLs, sem precisar recompilar a aplicação...

Verifique se a lei permite isso... No caso do ECF... é explicito que o ECF deve estar no mesmo estabelecimento para o qual o mesmo foi lacrado...

Qual erro exatamente você está descrevendo ? No seu tópico inicial, você falou que já havia resolvido o problema do Schema...

Veja na Documentação da Especificação Técnica do SAT

O ECF está respondendo... e o ACBrECF está tratando a resposta, de acordo com o protocolo... Procure o suporte da Bematech

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...