Daniel Simoes

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

Por favor tente com a versão já compilada e disponível na área de Downloads do fórum... Qual modelo do ACBrSAT você está usando ? Muitos erros de A.V. são causados pelo modelo errado (o emulador usa cdecl)

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

Como posso reproduzir o problema, usando o projeto SATTeste.exe ?

Qual a sua IDE ? verifique se realmente você baixou a atualização... Na duvida apague a Unit e baixe novamente

O cabeçalho é normatizado pelas especificações do SAT... mas você pode usar o espaço de "Informações do Contribuinte" para isso.... o texto é livre...

O problema parece ser um conflito entre ACBrDevice e ACBrECFVirtualBuffer (que tinha esse mesmo DEFINE) Apliquei uma possível correção no SVN