EMBarbosa

Olá Vagner,
   Me parece que alguns campos mudaram de posição na versão 3.0a do MDF-e. Talvez seja isso que tenha acontecido.
   Por exemplo, agora o RNTRC faz parte da seção "infANTT" e não mais da seção "Rodo"...
   Veja o modelo no manual on-line do ACBrMonitor Plus:
https://acbr.sourceforge.io/ACBrMonitor/ModeloMDFeINI.html

É verdade. Há uma configuração no SAT da Nitere por exemplo. Veja esse tópico:
 

Olá Armando.
   No momento não temos algo que atenda o VB6. Talvez mais adiante consigamos mover o ACBrTEFD para Lib, mas não está nos planos agora.

Não sei o banco de dados que você está usando, mas se o erro for ocasionado em outra transação pode ser porque essa conexão está configurada para "wait". Então até que a outra transação feche ou esgote o tempo limite, a aplicação vai ficar aguardando o BD. Nesse caso bastaria configurar para "no wait".

Muito obrigado pela contribuição.
Fiz a implementação baseada nela.
Subi as alterações para o SVN na Revisão  18020.
Pelo que vi está tudo certo.
Queira por favor atualizar, testar e reportar qualquer problema.
Mais uma vez obrigado.
Só uma informação: não é necessário anexar arquivos ".DCU", apenas os arquivos ".pas" que forem modificados.

Muito obrigado pela contribuição.
Fiz a implementação baseada nela.
Subi as alterações para o SVN na Revisão  18019.
Pelo que vi está tudo certo.
Queira por favor atualizar, testar e reportar qualquer problema.
Mais uma vez obrigado.

A versão 32 roda em 64 sem problemas. Você pode usar apenas ela sem problemas.

Não acredito que seja isso.
Isso está parecendo ser algum antivírus ou programa de proteção bancária. Eles costumam causar esse problema.

Já enviei uma correção ao SVN. Podem atualizar novamente por favor.
Desculpem a confusão...

Olá,
   @Daniel Simoes, acho que isso já foi implementado nas novas versões do TEF Pay&Go. Eu só não sei quais campos devem ser preenchidos.
   Veja esse tópico se te ajuda:
 

As UFs nessas duas respostas são diferentes. Será que não é isso?

Muito obrigado pela contribuição.
Fiz a implementação baseada nela.
Subi as alterações para o SVN na Revisão  17860.
Pelo que vi está tudo certo.
Queira por favor atualizar, testar e reportar qualquer problema.
Mais uma vez obrigado.

Criei um tópico de notícias sobre o componente:
 

ok. Então não é isso.
Quando é por gerenciador padrão moda antiga (troca de arquivos) a transação TEF em curso pode ser cancelada, desde que o cancelamento seja feito antes da confirmação. O que acontece é que no caso de múltiplos cartões, assim que você envia uma próxima transação TEF, a anterior é confirmada. Mas isso não parece ser o seu caso.
No seu caso o que parece estar acontecendo é que o gerenciador padrão não está aceitando o cancelamento por meio do NCN, embora não esteja retornando nenhum erro após o comando.
Pelo menos em teoria você pode usar o CNC para fazer os cancelamentos. Por meio dele, até onde me lembro, o gerenciador padrão não abre nenhuma tela. O grande problema dessa implementação é que se a energia cair, você precisa fazer todo o tratamento na sua aplicação. Inclusive salvar em um arquivo as transações pendentes.
Geralmente usamos o CNC quando alguém vem devolver um produto e quer cancelar a transação...
 
Eu sugiro você relatar o que está acontecendo ao pessoal da GetCard mencionando o que está utilizando os componentes ACBr. Talvez exista uma outra configuração que estamos deixando passar despercebido.
Por exemplo, eu encontrei um modelo antigo (veja o post do Daniel acima) em que usava o comando 'DSF' no lugar do 'NCN' e 'CAN' no lugar do 'CNC'. Isso poderia explicar o motivo de não estar aceitando o cancelamento. Mas não tenho certeza que é esse o caso.
Poderia tentar um contato com eles e nos dar um retorno? Talvez com o manual deles.

Isso pode ser o formato da conexão. Não tenho certeza que seja como você diz que os dados estão em memória.
Isso está relacionado ao controle de transações. Eu particularmente não tenho muita experiência com esse componente IBConnection. Mas se o jeito de fechar uma transação é usar o Close, então é isso que você precisa fazer.
Mas o ideal é fechar a transação assim que ela deixar de de ser útil e não antes do próximo Select.
Pra ser mais preciso, eu necessito de um programa que exemplifique o seu problema para analisar aqui na minha máquina.

Muito obrigado pela contribuição.
Fiz a implementação baseada nela.
Subi as alterações para o SVN na Revisão  17812.
Pelo que vi está tudo certo.
Queira por favor atualizar, testar e reportar qualquer problema.
Mais uma vez obrigado.

Olá,
   Acabei de testar aqui no Demo do Delphi com essa alteração e parece estar funcionando corretamente. Eu utilizei o botão "Gerar NFe" apenas removendo o comando de assinatura. Testei tanto em homologação como produção.
Veja:
- <dest> <CNPJ>00000802007376</CNPJ> <xNome>HC PNEUS</xNome> - <enderDest> <xLgr>Rua Coronel Aureliano de Camargo</xLgr> <nro>973</nro> <xBairro>Centro</xBairro> <cMun>3554003</cMun> <xMun>Tatui</xMun> <UF>SP</UF> <CEP>18270170</CEP> <cPais>1058</cPais> <xPais>BRASIL</xPais> <fone>1532599600</fone> </enderDest> <indIEDest>1</indIEDest> <IE>0731791900112</IE>    Será que não há alguma alteração nos seus fontes? Será que eles estão atualizados?
  

Esse campo deve ser usado quando está incluído serviços (que são sujeitos ao ISSQN) juntamente com produtos. Nesse caso, o Emitente precisa verificar com o contador qual o comportamento de descontos dados à "compra" como um todo (desconto dado no Subtotal): Esse desconto deve ser rateado nos serviços ou apenas nos produtos?

Muito obrigado pela contribuição.
Fiz a implementação baseada nela.
Subi as alterações para o SVN na Revisão  17776.
Pelo que vi está tudo certo.
Queira por favor atualizar, testar e reportar qualquer problema.
Mais uma vez obrigado.

Mesmo depois de instalar o "Fortes CE" você precisa reinstalar o ACBr e marcar os componentes do Fortes.

Muito obrigado pela contribuição.
Fiz a implementação baseada nela.
Subi as alterações para o SVN na Revisão  17692.
Pelo que vi está tudo certo.
Queira por favor atualizar, testar e reportar qualquer problema.
Mais uma vez obrigado.

Muito obrigado pela contribuição.
Fiz a implementação baseada nela.
No entanto tive que fazer diversas alterações para seguir o novo modo de implementar as balanças. Queira observar que agora, geralmente, apenas precisamos implementar os métodos InterpretarRespostaPeso e SolicitarPeso.
Subi as alterações para o SVN na Revisão  17688.
Pelo que vi está tudo certo mas queira por favor atualizar, testar e reportar qualquer problema.
Mais uma vez obrigado.

Rapaz, acabei esquecendo de te dar um retorno. Desde 3 de setembro já estava pronto.
Muito obrigado pela contribuição.
Fiz a implementação baseada nela.
Subi as alterações para o SVN na Revisão  17568.
Pelo que vi está tudo certo.
Queira por favor atualizar, testar e reportar qualquer problema.
Mais uma vez obrigado e desculpe o atraso.

Taí um erro que eu não vejo a muito tempo. Esse erro é gerado quando se tenta criar um TTimer e não tem sucesso.
Isso pode acontecer por alguns motivos.
O mais comum é que você está criando muitos TTimers no seu projeto. Há um limite no Windows da quantidade de Timers que podem ser criados por aplicação.
A correção por tanto é reduzir o número de timers que você utiliza. Você pode tentar, por exemplo, usar o mesmo timer para diferentes funções.
Mas pode ser outro problema relacionado aos timers... Por exemplo pode ser outra aplicação que causa o problema... Veja esse relato:
http://www.delphigroups.info/2/35/440863.html
 

Para ajudar, caso o link caia. Pelo que eu entendi, o resumo é esse:
A contratante emite o CT-e de todo o percurso, porque ela é quem é responsável pela realização do transporte perante o cliente, mesmo que contrate outra transportadora. Enquanto subcontratada pode ser dispensada de emitir o CT-e (de acordo com a UF). Mas mesmo se dispensada, se ela desejar emitir o CT-e, ela só emite depois que a transportadora contratante emitiu o CT-e dela. Ainda assim, geralmente depois da entrega feita.