BigWings

Fazendo mais testes, consegui simular o erro. Se configurar o componente para a versão 4.00, e fazer a consulta de uma NFe da versão 3.10 carregando o XML vai ocorrer o problema. Se configurar o componente para a versão 3.10 o problema não ocorre, pode confirmar?

Tem algo de errado com os teus fontes. Está acessando a URL da versão 3.10 mas usando o SoapAction da versão 4.00. O correto seria isto aqui: Veja se não tem um arquivo ACBrNFeServicos.ini ou ACBrNFeServicos.res desatualizado em algum lugar do disco que pode estar sendo usado na compilação no caso do .res ou na execução no caso do .ini. Faça um revert dos fontes se for o caso.

É possível desde que você tenha todos os dados dela. Veja o a função GerarChaveAcesso da unit ACBrDFeUtil.pas.

Qual a marca e modelo da impressora? Experimente configurar as propriedades: ACBrPosPrinter.LinhasBuffer ACBrPosPrinter.Device.Timeout ACBrPosPrinter.Device.SendBytesInterval Este último faz um Sleep...

"Se" houver a troca do cupom não teria problemas, mas quando a empresa não fizer isso e for autuada, pode ter certeza que vão jogar a culpa no sistema e você terá que responder por isso.

É ilegal pois impede o consumidor de fazer a consulta da nota, seja pelo QRCode ou pela chave da nota, o que torna ela sem nenhum valor fiscal.

Bom dia, Este outro tópico seu está relacionado ao problema acima?

Vai depender de qual engine de relatórios você está usando aí. O ACBr tem componentes para Fast e Fortes Report. Então estudar essa engine pra ver se há alguma configuração nesse sentido.

Já verificou a inscrição municipal se está correta? Se a prefeitura usar a inscrição municipal como chave pode identificar ela como sendo de outro CNPJ...

Essas configurações só afetam a conexão HTTP e só são usadas quando usando HTTPLib = httpWinInet, padrão do CAPICOM. Eu usei OpenSSL nos testes. Fiz teste agora com CAPICOM e só precisei marcar SSL 3.00 e a consulta funcionou normalmente. No seu caso a conexão está sendo estabelecida mas o webservice não está localizando o SoapAction passado como parâmetro no método de conexão. No ACBrNFeServicos.ini há as URL dos serviços para cada versão e é possível manipular o SoapAction para atender alguns webservices que não se adequaram ao padrão no caso da NFe 4.00. Só é estranho estar acontecendo isso na NFe 3.10 que já está em funcionamento há muito tempo. Veja pelo debug qual a URL está sendo acessada, e qual o conteúdo do parâmetro ASoapAction.

Essas URL já constam há algum tempo no arquivo ACBrNFeServicos.ini. Falta a SEFAZ disponibilizar, porém, a URL de recepção de evento em produção para a versão 4.00.

Não tem. O método DistribuicaoDFe precisa que a nota esteja no ambiente nacional, e manifestada, caso contrário retornará o cStat 137.

Já retornou a versão do ACBr pra essa revisão pra ver se o problema desaparece?

Algum arquivo ACBrNFeServicos.ini desatualizado na pasta do aplicativo.

Por normal você quer dizer produção? Não compreendi. A ciência é uma manifestação. Geralmente o cStat 136 é retornado quando a NFe não foi encontrada. Lembro de já ter tido esse problema quando enviei o evento em homologação para uma nota que tinha sido emitida em produção. Verifique também o tipo de emissão da nota, se não foi enviada em contingência SVC, por exemplo.

Está usando o mesmo ambiente que a NFe foi emitida para o evento?

Primeiro, não confunda NFCe (Nota Fiscal de Consumidor Eletrônica, modelo 65) com o CFe (Cupom Fiscal Eletrônico, modelo 59). Assumindo que esteja falando da NFCe já que postou nesse fórum: http://www.nfe.fazenda.gov.br/portal/exibirArquivo.aspx?conteudo=QK/Drpb/k7Y= http://www.nfe.fazenda.gov.br/portal/exibirArquivo.aspx?conteudo=YbZEjEHCuHQ= Quanto ao envio por email: Quanto à impressão: Mas há exceção em caso de emissão em contingência Off-Line:

Se é NFe ou NFCe, pois os webservices são diferentes. Fiz a consulta das duas notas pelo demo do ACBrNFe, sem erros, inclusive usando a versão 4.00 que ultimamente vem causando esse erro. [Window Title] Acbrnfe_demo [Content] Versão Layout: 4.00 Identificador: 43171223083871000111550010000001671000242499 Ambiente: 1 Versão Aplicativo: RS201710241713 Status Código: 100 Status Descrição: Autorizado o uso da NF-e UF: RS Chave Acesso: 43171223083871000111550010000001671000242499 Recebimento: 04/12/2017 09:53:23 Protocolo: 143170206064433 Digest Value: QmzMJoovgrwJlNUHt4Iz6gX9Gjs= [OK] Você está com os fontes atualizados?

Informe a configuração que está usando: UF, ambiente, modelo e versão. E a chave da NFe que está tentando consultar.

Está hard-coded no componente. Mas você tem os fontes, basta alterar. Mas já aviso que a nota será rejeitada.

É a maneira correta, sim.

Isso é feito automaticamente pelo componente para atender à especificação da NFe.

Ocorre o mesmo problema usando o demo do ACBr?

Em regra geral, o componente não manipula os valores das tags. Eles devem ser informados pela aplicação. Então provavelmente é algo no seu código. Use o debug.

Já tentou debugar pra ver o motivo de não atualizar o arquivo? Provavelmente é alguma configuração do componente que você não está setando ao criar o componente em tempo de execução.