EMBarbosa

Veja o arquivo Leiame.txt. Tente desinstalar e remover todos arquivos .bpl e .dcu relacionados com o ACBr antes de instalar novamente.

Jean, Isso daí é apenas para impressoras que não fazem essa impressão automaticamente. A maioria das impressoras MFD (se não todas) já fazem a Leitura da Memória Fiscal automaticamente. Sendo assim, acho que o ACBrECF não o faz... mas tenho que olhar no código pra ter certeza dessa informação. Se não fizer, você pode implementar com facilidade usando os eventos do ACBrECF.

Jaime, Até entendo o que você diz. Mas o objetivo não é impedir as alterações para que os valores gerados nos arquivos sejam exatamente iguais aos recolhidos? Trabalhando com Hash, cumpre exatamente esse objetivo. Além do mais não me lembro de nenhum "lacre eletrônico de dados" seguro da maneira que eles pedem, (se alguém conhecer, avise aí!).

com0com +1! É o que há!

Fabrício, Welkson, Nesse caso, é melhor verificar com o homologador antes. Pois a lei não parece ser específica. Acho que quando fui homologar (no ano passado) quem implementou dessa maneira, não teve problema algum. Mas como não foi o meu caso, não me lembro ao certo...

se o tratamento não funciona assim é porquê o método AcNFE.NotasFiscais.Items[0].EnviarEmail não está levantando uma exception. Talvez a exception esteja sendo tratada lá dentro, ou não seja mesmo levantada. Você precisa verificar debugando.

Você provavelmente está usando Delphi 7 ou anterior. Para resolver, apague essa linha pois ela não é necessária para o funcionamento do componente.

Depois de emitida não. Nesse caso é antes de emiti-la. Para depois de emitida você deve usar o DadosUltimaReducaoZ. Faz uma busca aí no fórum. Se não me engano já tem tópicos explicando as diferenças das duas. Por exemplo, usando a DadosReducaoZ, não se esqueça que o COO vai estar com número menor.

JACBr ???

Não faço uso da ACBr32.dll. Mas imagino que você precise deixá-la na pasta do executável ou em uma pasta do PATH do Windows (como Windows\system32).

Você poderia tentar no DEMO do ACBrTEFD para ter certeza que não é algo no componente.

Faça pesquisa antes de postar. Existe diversos tópicos explicando o abaixo: Não há um componente ACBr de notas fiscais eletrônicas de serviços totalmente pronto. Há um no Branches, mas não todo finalizado. Essa área do fórum é sobre o ACBrNFe. Se está com dúvida na implementação em Delphi/Lazarous use a área do fórum adequada para isso. obrigado,

Aqui está compilando normalmente. Antes da alteração que eu fiz não estava nem compilando. Agora precisaria de alguém com uma impressora ECFFiscNet pra poder testar a geração do arquivo.

isso foi resolvido?

Pessoal o código do TACBrECFFiscNET.ArquivoMFD_DLL não estava compilando, dizendo que : Fiz alteração na definição do método xDLLATO17GeraArquivo, passando os parâmetros para PAnsiChar como já foi utilizado nos outros métodos. Favor conferir.

Puxa. Muito bom! Excelente notícia.

O que eu achei mais interessante é pra um comando simples não deveria ocorrer esse tipo de erro. O log tem 3 erros de "Aguardando resposta do comando anterior" para apenas duas requisições de NumCOO. Precisa mesmo testar com o ECFTeste para eliminar possibilidades de outras concorrências. Caso não funcione, poderia testar com o Device.processmessages := false? EDIT: Ahh não, acabei de ver que são 4 erros. Dois para cada requisição de NumCOO.

Esse tópico não é o mesmo que esse abaixo? viewtopic.php?f=12&t=2133

Favor não postar tópicos duplicados. Se precisar de novas informações ou atualizações, utilize o antigo viewtopic.php?f=12&t=2056 Faça pesquisa no fórum antes. Obrigado,

Faça um Build do SPED.

Queira tentar novamente Wilson. O André aumentou o tamanho limite dos anexos de ~ 50MB para ~100MB.

Talvez seja algum problema com o RAR. Tente com o winzip.

pode postar o site por favor? Obrigado,

Ok. Se precisar de alguma ajuda, me avise.

Verifique o DEMO do ACBrECF na pasta EXEMPLOS\ACBrECF. Nele há uma função de Teste de Velocidade no menu Cupom Fiscal. Teste com ele.