EMBarbosa

Tem um tópico excelente sobre o assunto criado pelo Juliomar algum tempo atrás. Dá uma

Você fez testes com o exemplo do ACBrSPEDFIscal?

Não. Nós fazemos um hash. Sobre sua preocupação da concorrência, isso que estão fazendo das BPLs é contra a legislação do PAF-ECF. O PAF-ECF fala especificamente de todos os arquivos binários para execução. Inclui qualquer DLL. Todo arquivo BPL na verdade é um tipo especializado de DLL, então deveria ser incluído também.

Neste caso, é melhor verificar com o órgão homologador. Como disse anteriormente no caso das triggers que podem facilmente ser desabilitadas, eles podem recusar. Já vi alguns aceitarem. Mas também já vi recusarem. Então quero evitar dizer pra você ir em frente ou não. Se depois eles barrarem ou disserem que podia, isso não seria bom pra você, nem pra mim. (:

Por favor, descreva o passo a passo que está utilizando no DEMO.

Com certeza pode ser. Mas você está ligeiramente enganado. Você passa o NumCOO ao chamar o CRT ou CHQ. Daí o ACBrTEFD possui o evento onComandaECFAbreVinculado cujo objetivo é dar ao programador o controle sobre esse momento específico.

Não tem restrições para como você vai montar os dados, exceto uma parte. A parte que menciona a validação dos registros, identificando se foram alterados ou não. Essa parte, era específica em dizer que o método usado não poderia ser desabilitado facilmente. Daí, muitos homologadores podem recusar se essa parte de validação estiver em triggers. Caso não esteja envolvida essa parte, normalmente não há problemas.

Tente com o programa de exemplo.

Isso mesmo. Esse é o arquivo de Log da DLL. E o arquivo sintegra? Foi gerado corretamente para o mesmo mês que você queria? Em caso afirmativo, você poderia tentar novamente com o Monitor? A DLL vai gerar um log pra ele também, daí anexe-o aqui para podermos comparar.

Você está utilizando o envio de e-mail por Thread?

Mesmo na máquina problemática? Poderia anexar o log da DLL quando foi gerado na máquina com problemas?

Normalmente, no diretório do executável.

Campo IND_MOV do registro D001. Veja o exemplo do ACBrSPEDFiscal.

Não estou não. É que o ACBrMonitor internamente utiliza os componentes. Por isso diagnóstico poderia ser parecido. Se existisse algum exemplo da Bematech que você poderia utilizar para testar esse método e ele não funcionasse, poderíamos descartar problemas com os componentes e com o ACBrMonitor. Seria um problema que só o suporte da Bematech pode resolver.

O método ArquivoMFD_DLL chama usa a DLL da Bematech para gerar os arquivos. O método da DLL é Bematech_FI_RelatorioSintegraMFD. Então se você utilizar o exemplo da Bematech para esse método passando os mesmos parâmetros e não funcionar, é um problema externo ao ACBr. Veja como você poderia testar esse método na máquina com problema usando as mesmas datas e o mesmo nome de arquivo.

Verifique o log do ACBrECF. Parece que o ACBrTEFD até tentou abrir o vinculado, mas não conseguiu. Nesses casos ele parte pro gerencial. Isso é permitido.

Você poderia fazer um teste utilizando o exemplo da Bematech utilizando os mesmos parâmetros que está no log?

Você consegue acessar por algum exemplo do fabricante?

Por favor, não fique fazendo pelo fórum, em especial quando eles tem menos 24 horas úteis de espaço. Isso não é permitido Veja a 3.1. Se precisa de atenção direcionada e com essa velocidade, então sugerimos que assine o ACBrSAC. Sobre sua dúvida, o erro 110 pode acontecer quando a porta não está disponível ou o aplicativo não tenha permissão. Queira dar informações completas sobre o seu ambiente e o que você já tentou fazer. Veja sobre que tipos de informações podem ser úteis pra alguém que queira lhe ajudar.

Ok. Agora eu já compreendi o problema. O padrão desde o Delphi 6 é que a units dentro dos pacotes (packages) sejam separadas em Design-Time e Run-Time. Não deve existir dentro do pacote uma unit que seja Design-Time e Run-Time ao mesmo tempo. As units que começão com Design* (como DesignIntf e DesignEditors no problema apresentado) não estão disponíveis para compilação em Run-Time no Delphi e devem ser chamadas apenas pelas units "Design-Time" do pacote. Em especial nas versões mais novas acontece o erro mencionado (veja esta resposta no SO). Há um artigo no site da Embarcadero explicando sobre esse assunto neste link aqui. Embora o tema do artigo seja um pouco enganador, explica claramente o que deve ser separado. Notei até que o ACBrSAT segue este modelo com uma unit separada "ACBrSATReg.pas". Assim, pelos meus testes, nenhuma das duas units é realmente necessária nesta cláusula uses e podem ser removidas sem maiores prejuízos. Já fiz essas alterações e enviei o código no SVN. Testei tanto no Delphi como no Lazarus, e me pareceu OK. Vai ficar faltando decidir o que fazer exatamente com a procedure Register na unit ACBrECFVirtualSAT. Nota interessante: Ao fazer pesquisa sobre o assunto, um dos primeiros resultados do Google foi exatamente este post... o.O''

Se o documento é feito com enfoque no declarante, então tem de usar as de São Paulo. Consulte o contador para ter certeza.

Ok. Muito obrigado pela ajuda. Minha maior dificuldade em fazer as alterações é que no Lazarus está funcionando corretamente e a instalação no Delphi ficou correta. Preciso admitir que essa parte do código não é meu forte. Vou fazer uma pesquisa melhor e dar algum retorno, se possível ainda hoje.

Tradução aproximada Chegou a tentar isso? Mais alguém que está testando poderia verificar?

Estou fazendo correções para poder enviar esse código ao SVN. Alguém mais tem alguma alteração e gostaria compartilhar?

De nada. (: