Daniel Simoes

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

Me desculpe se pareci ofensivo.. não foi essa a intenção... é que na correria de ler e analisar todos os casos... alguns detalhes passam desapercebido... Fiz um teste com um TM800F que temos aqui... e a impressão do Consumidor ocorreu com sucesso... Veja a foto: Parece haver uma confusão nesse comando... No Ato Cotepe o comando "IDENTIFICAÇÃO DO CONSUMIDOR NO RODAPÉ" é descrito como "150".. mas no manual da Bematech está como "149".. e na TM800F realmente foi o 149 que funcionou... Por favor verifique com o fabricante se houve alguma modificação nesse comando, na TM900F...

Copie as DLLs do OpenSSL, que estão no SVN, versão.14 para a mesma pasta do seu .EXE

De acordo com a Especificação Técnica o máximo é 10 Você tem várias ocorrências iguais.. Porque não agrupá-las em uma só ?

Cada ECF tem um protocolo completamente diferente... entao ao se funciona na Epson 85, não tem relação nenhuma com a a Epson 09 Por favor seja mais específico... De qual ECF você está falando ? Se são problemas semelhantes em vários ECFs, por favor abra um novo tópico para cada modelo...

Não tenho esses equipamentos para teste mas a ideia é a mesma... Copie a DLL do novo fabricante em uma nova pasta, e configure o ACBrMonitorPLUS

Oi Amarildo... Para a linha 09/09 da Epson é necessário usar o TmVirtualPort... Veja esse post

Deve ser algo nos seus fontes... No Demo do ACBrNFe está normal...

Use o fórum do Trunk2... http://www.projetoacbr.com.br/forum/forum/55-trunk2/ e sempre abra um novo tópico para um novo assunto... Veja as regras do fórum: http://www.projetoacbr.com.br/forum/announcement/1-sim-nós-temos-regras/

Há algo muito estranho no seu Log... Você está usando o Trunk2 ? Seus fontes estão atualizados ? Veja: Provavelmente o comando para a Identificação do Consumidor é essa linha do Log: Observe que o CNPJ está com Pontos (essa pode ser a origem do problema) Porém nos fontes atuais, é filtrado para enviar apenas os números, (repare no método "OnlyNumber") procedure TACBrECFEscECF.EnviaConsumidor; begin try with EscECFComando do begin CMD := 149; AddParamString(LeftStr(OnlyNumber(Consumidor.Documento), 14)) ; AddParamString(LeftStr(Consumidor.Nome, 30)) ; AddParamString(LeftStr(Consumidor.Endereco, 79)) ; end; EnviaComando; Consumidor.Enviado := True ; except end ; end;

Apliquei uma correção no SVN, que deve resolver o problema...

Observei o problema ocorrendo... vou verificar...

O ACBrSAT não faz a validação de Schemas, assim como ocorre no ACBrNFe... Se quiser implementar, e contribuir, será ótimo...

Não existe campos para isso na NFe 3.1.. use as observações adicionais

Boa observação... obrigado... Enviei correções para o SVN baseado na sua sugestão...

Veja nos fontes... o ACBrSAT já faz isso...

Você diz, que: Ajustar o valor da propriedade no Object Inspector não é persistida no DFM ?