EMBarbosa

Você viu esse outro

A sugestão foi entrar em contato com a certificadora TEF. Você tentou fazer isso? Qual certificadora? Qual foi a resposta deles?

É normalmente algum problema na instalação. Tente fazer uma limpeza no computador e reinstalar o ACBr usando o ACBrInstall. Veja esse

Eu sugiro você entrar em contato com a secretaria que estabelece o prazo para saber da posição deles.

Você tem mais de uma versão do Delphi instalado?

A NFC-e trata da mesma maneira que tratava no Cupom Fiscal, que é a mesma maneira que trata na Nota de Venda a Consumidor (Série D). É melhor você verificar com o contador do seu cliente. Contadores diferentes podem dar informações diferentes, por isso eu sou um pouco cauteloso ao aconselhar sobre esses assuntos.

Isso... E ele assina com base no quê?

Sabe, se você explicar exatamente qual o erro e o ambiente ajuda. Acho que você poderia seguir as recomendações do segundo post no tópico

Eu não recomendo ProcessMessages := True. Isso faz com que o Device execute um Application.ProcessMessages. Não deveria ser necessário a nenhuma aplicação utilizar esse método. Se está perdendo códigos, então sua venda frenética não está implementada corretamente. Procure aqui no fórum sobre isso, já foi amplamente discutido. Muitas pessoas acham que Application.ProcessMessages é um comando mágico que faz a aplicação não parecer congelada. Mas, isso está muito longe da verdade. Essa pergunta e suas respostas ajudam um pouco.

Favor, continuar em:

E lá não foi explicado o motivo do erro?

Por favor pesquise antes de postar, talvez sua dúvida já está respondida em outro post. Experimente nosso mecanismo de Busca com algumas palavras chaves e surpreenda-se com os resultados. No topo da página, você encontrará a caixa de busca

Creio que sim. Passe NULL para os campos que precise que sejam gerados em branco. Em caso de problemas, por favor, crie outro tópico mencionando os dados preenchidos e o erro do validador.

Por favor, continuem sobre o problema que iniciou dia 12/02/2015 em:

Por favor, continuem sobre o problema que iniciou dia 12/02/2015 em:

Por favor, continuem sobre o problema que iniciou dia 12/02/2015 em:

Não deveria ficar prejudicado não. O TimeOut só faz efeito para esgotar o tempo de espera do ECF. Já faz algum tempo que estamos recomendando o TimeOut de 10 no mínimo e nunca tivemos problemas neste sentido. Pelo contrário, se o TimeOut for muito pequeno, o ACBrECF vai fazer mais tentativas do que pode ser necessário. Isso sim vai lhe prejudicar e pode ter efeitos colaterais indesejados. Além disso, no caso de USB, é normal o tempo ser mais lento. Você adicionou mais uma camada na comunicação de duas vias.

A sua pergunta na verdade é a seguinte: É possível dois programas utilizarem a mesma porta de comunicação ao mesmo tempo? E a resposta, em geral, é não. Você poderia ter um aplicativo tipo COM redirector que poderia conectar nessa porta e simular duas portas onde seus aplicativos conectariam e receberiam ao mesmo tempo os valores replicados da porta original. Isso, no entanto, nem sempre funciona...

Então você vai precisar adicionar algum jeito de carregar os arquivos blob na sua classe de persistência. Você não vai conseguir carregar arquivos grandes usando um simples "SQL insert values" como se fosse o campo fosse um VARCHAR. É uma limitação do Firebird 2.5 como pode ser visto no tracker do próprio Firebird aqui.

Procure aqui no fórum por "Não foi possível localizar o ponto de entrada do procedimento"

Se você não está fazendo a assinatura usando o ACBrEAD, como está sendo feito a assinatura?

Seria necessário analisar a classe da Daruma e verificar se o ECF a princípio retorna o erro SEM PAPEL. O ACBrECF deve retornar sempre o que o ECF retorna. Se o ECF retornar "não está em linha", então há pouco o que o ACBrECF possa fazer. Você poderia verificar?

Ficou parecendo mesmo que é um problema de comunicação. Não sei se é o que ocorre, mas pode ser que o componente não esteja recebendo um OK do ECF e daí tenta enviar novamente. Veja essa parte abaixo onde o ACK é diferente de 6: Não sei se vai fazer diferença, mas a configuração de timeout está muito baixa. Aumente para 10.

Se a impressora retornar o erro de sem papel, o ACBrECF deveria gerar uma exception do tipo EACBrECFSemPapel. Assim você poderia capturar esta exception específica.