Daniel Simoes

Apliquei uma correção para o problema...

Pelo que Li no fórum... O Elgin é idêntico ao DIMEP... (ambos tem a mesma fábrica)

O manual se chama ACBrMonitor.chm, e é instalado quando vc faz a instalação completa... Ainda não há uma maneira fácil de acompanhar o Change-log... Para ver as melhorias e modificações é necessário ver os arquivos "Change-Log.TXT" do PLUS e de todos os componentes que ele possui... nos fontes do ACBr

Verifica se a porta Serial criada está pelo TMVirtualPort está com sinal de Exclamação no Painel de Controle... Se SIM, o driver não foi instalado corretamente

Você diz: que quando Alimenta o CFe com RTSimplesNacional, o CFe gerado não é aceito pelo SAT ? Li os tópicos anteriores,mas não achei em nenhum deles um exemplo do XML recusado em anexo...

Use o InteliSAT da Tanca... ele analisa o seu XML e aponta por problemas http://tanca.com.br/drivers.php?cat=24&sub=43

Eu desconfio que o problema não seja exatamente o parâmetro... Pode ser um TimeOut baixo... Em alguns modelos de ECFs, o ACBrECF é capaz de detectar que o mesmo está trabalhando (o ECF possui comando de Status que pode ser chamado durante a execução de comandos demorados)... em outros modelos, isso não é possível, então é necessário estimar um Tempo mínimo para o comando, e defini-lo em TimeOut... antes da execução... Note que no seu caso, o exception ocorreu após 1 minuto do envio do comando... -- 19:15:44:117 TX -> [FS]F[234]130815192742[181] Daruma: Falha no Envio do CMD. Tentativa: 1 - Erro: 0 - Estendido: 0 -> Erro não documentado Cod.Aviso: 0 19:16:44:193 RX <- -- Desativando a porta: COM1 ----------------- ERRO ----------------- Impressora Daruma não está respondendo ---------------------------------------- Se fosse problema de sintaxe do comando... o erro ocorreria na hora...

Obrigado pelas explicações... Notei que "TACBrSATResposta.SetRetornoStr" já é feito um bom tratamento para evitar Exceptions em resposta fora do padrão... Modifiquei os fontes de ACBrECFVirtualSAT.pas para usar as propriedade de "Resposta" e não os campos do Array...

Sim, você pode capturar a Exceção e ignorá-la... No meu sistema, eu capturo os dados da Redução Z antes de executar a Redução, e também depois da mesma... De posse de ambos os INIs, eu faço um merge, dando preferência as informações do INI após a Redução Z

Acho que não tem como tirar as dependências dessas DLL do .EXE.. elas são injetadas pelo ACBrNFe, através da Unit "libxmlsec", que faz declaração dos métodos de forma estática No Trunk, era possível compilar os fontes com CAPICOM ou OpenSSL... no Trunk2, não... ambos os fontes são compilados... A grande vantagem é poder mudar de SSL em RunTime (OpenSSL é ótimo para certificados A1) Talvez você precise rever a estratégia... como por exemplo, distribuir um Instalador (Inno ??) que quando executado, copia as DLLs e atualiza o binário..

Obrigado... já está no SVN...

Henrique, Vou deixar para outro commiter analisar... Não tenho Delphi e FastReport... Mas desde já agradeço o seu empenho..

Boa analise.. Atualmente o Quickreport não é mais mantido pelos desenvolvedores do ACBr... Mas se quiser anexar uma Unit com as modificações eu posso subir...

Todas as propriedade do certificado estão em ACBrNFe.SSL.xxx

Só havia observado essa msg quando o ECF era novo e ainda não havia nenhuma redução Z Nao há o que fazer do Lado do ACBr... O mensagem de Erro vem do próprio ECF

Prezado... Já foi respondido a você, por várias vezes, que o problema está no Fortes continue no Trunk... ou aguarde o pessoal do Fortes corrigir o SAC nao lhe dá o direito de exigir uma correção ou desenvolvimento específico... Leia o contato...

Não compreendi... Existe algum problema no Trunk2, que você deseja relatar ?

O número em questão é a data e hora... Ela permite o ajuste do relógio do ECF em até 5 min voce tem um parâmetro no comando da ReducaoZ que permite desativar o envio dessa hora A redução Z chega a ser impressa ?

Apenas o Exemplo do ECFTeste em Lazarus tem exemplos de como usar os ECFs virtuais

Agora sim tudo faz sentido... Quando escrevi a classe da ACBrEscBematech, copiei métodos a Unit do antigo DANFE NFCe do Trunk... e lembro que achei muito estranho o calculo usar o valor 255 e não 256... Na verdade o ACBr já possui um método que faz essa conta... ele está na ACBrUtil, e já é usado na Classe da ACBrEscEpson... {----------------------------------------------------------------------------- Converte um "AInteger" em uma String binária codificada como Little Endian, no tamanho máximo de "BytesStr" Exemplos: IntToLEStr( 106 ) = chr(106) + chr(0) ---------------------------------------------------------------------------- } function IntToLEStr(AInteger: Integer; BytesStr: Integer): AnsiString; Apliquei modificações no SVN para usar esse método

Esse novo método "TpEventoToDescStr" está definido em pcnConversao.pas... Recompile o seu package PCNComum. Verifique se a sua Unit pcnConversao.pas foi atualizada corretamente

Conversei com o suporte da Epson... realmente é um problema do Firmware 01.01.00

Tópico movido para a área aberta, para analise dos técnicos da Epson...

Sim.. nesse caso você pode tentar fazer o Merge das correções do Trunk2 no Trunk... por sua conta...