Daniel Simoes

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

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

O que quis dizer, é que pelo fato do ACBr ser OpenSource... você não ficará "na mão"... basta corrigir a URL nos fontes... Para o ACBrNFSe ficar pronto mais rápido... devemos TODOS... tentar analisar as modificações em curso, e ver como podemos ajudar o Italo...

Apliquei uma possível correção, para o problema da acentuação... favor atualizar e testar...

Ok, subi para o SVN, correções para os Extatos em EscPos e Fortes

Por favor forneça mais detalhas sobre o problema... Qual a exata msg de erro ? O que você tentou fazer ? O que não funcionou ? Como era pra ter funcionado ?

Sim, a troca de cabo, usando uma Serial física, seria o próximo passo...

Nada impede você de corrigir os caminhos no Trunk e disponibilizar as correções para a comunidade...

Sim, aparentemente está errado (imprimindo sempre o CFe.ide.nCFe) Por favor teste com a Unit em anexo ACBrSATExtratoESCPOS.pas