BigWings

Depois da consulta você pode ler as informações do componente pra obter os dados dos eventos, e verificar se o evento de cancelamento está presente. ACBrNFe1.Consultar; for I := 0 to ACBrNFe1.EventoNFe.Evento.Count - 1 do if ACBrNFe1.EventoNFe.Evento[I].InfEvento.tpEvento in [teCancelamento, teCancSubst] then begin ... end; Também pode usar o segundo parâmetro do método de consulta pra extrair do retorno os arquivos XML dos cancelamentos e salvar eles em disco. ACBrNFe1.Consultar(nChaveNFe, True);

Pode ser falta da MIDAS.DLL compatível na máquina. Como esse componente usa o ClientDataSet, precisa distribuir a DLL ou adicionar a unit MidasLib no uses do seu projeto pra embeddar a mesma na sua aplicação.

Tenta colocar o ACBrNFeDANFCEFR e o frxReport num mesmo formulário ou data module, e abre o .fr3 por ele.

Está usando o componente para DANFe NFCe?

Está enviando no modo assíncrono? Precisa armazenar o número do recibo e fazer a consulta deste mais tarde pra obter o retorno do processamento. Se você envia uma NFe por vez pode tentar o modo síncrono que não existe recibo, o retorno vem imediatamente.

Precisa entrar em contato com a prefeitura/provedor pra saber se eles disponibilizaram novos schemas pra atender esse código. Ou se é só aceito na emissão pelo portal.

Sobre a validação de chaves e inutilização, isso é do lado da SEFAZ, nada a fazer no ACBr ou na sua aplicação. Mas houve uma alteração nos fontes pra adequar a NT. O deu lado é manter os fontes do ACBr e schemas atualizados.

Obrigado por reportar. Fechando. Para novas dúvidas, criar um novo tópico.

Se não está encontrando o arquivo .inc as diretivas não vão funcionar...

Obrigado por reportar. Fechando. Para novas dúvidas, criar um novo tópico.

Tente alterar essa linha pra DELPHI2006_UP. Atualizado não, você pode tentar ajustar os que já existem para o FR4 ou fazer um próprio.

Lentidão na página da receita.

Isso já não foi implementado?

12002 se não me engano é timeout. Está enviando ou emitindo em contingência? Se enviando, acredito que esteja carregando um XML de uma NFCe que foi emitida anteriormente em contingência e usando o método de envio. Verifique a conexão com a internet, aumente o timeout (ACBrNFe1.Configuracoes.WebServices.Timeout := 30000), verifique as configurações SSLLib e SSLType.

Use a contingência offline. Ide.tpEmis := teOffLine;

Já tem um tempo que os .fr3 não suportam mais o FR4.

Chegou a ver o post do Italo no subfórum de notícias? Aparentemente, se as SEFAZ cumprirem o prazo, a partir do dia 03/05/2021 já pode começar a enviar a tag xPag.

A cada pesquisa ele te retorna o próximo UltNSU, e também o MaxNSU, se eles forem iguais não existem mais documentos, caso contrário, você pode pesquisar novamente pelo UltNSU retornado.

Até onde sei a contingência para o BPe é offline, funciona semelhante a NFCe.

Deve ser algo na sua rotina. Se fosse algo no ACBr você teria o mesmo problema numa impressão de DANFE carregando o XML, por exemplo.

A sua aplicação é 64bits? Se for 32 o correto é copiar as DLLs da pasta x86, de preferência para a pasta da aplicação. Mesmo que executando em Windows 64.

O ambiente de homologação é da SEFAZ, não do monitor, ele apenas direciona as URL de acordo com a configuração. E sim, precisa cadastrar o CSC pra homologação. Alguns estados usam o mesmo CSC em homologação e produção, em outros o mesmo CSC é usado nos dois ambientes.

O CSC/IdCSC deve ser obtido na SEFAZ pra cada emitente de NFCe, e informado na configuração.

Verifique a configuração DFe -> WebServices -> NFC-e -> Versão QRCode. Deve estar 2.

Esse erro é de validação local contra schemas. Só precisa atualizar a pasta de schemas, prefira os que são distribuídos com o ACBr na pasta ACBr\Exemplos\ACBrDFe\Schemas.