BigWings

Verifique se está configurando a versão correta no componente: ACBrNFe1.Configuracoes.Geral.VersaoDF := ve400;

Veja o vídeo abaixo:

Não confunda o número da remessa com o nosso número do boleto. Cada remessa pode conter vários títulos, mas a numeração de cada arquivo de remessa deve estar em sequência de acordo com a última remessa enviada ao banco. A rejeição informada no arquivo de retorno é por causa disso: Você informar o número da remessa para o componente desta forma: ACBrBoleto1.NumeroArquivo := <numero_remessa>;

Também está usando o certificado digital "RemoteID"? O campo SignatureValue do XML está realmente estranho, com uma sequência gigante de "AAAAAAA...", estranho que removendo essa sequência o validador acusa a assinatura como válida.

Algumas pastas estão mesmo vazias, não é um problema.

Coloque ele no formulário principal ou um data module que seja instanciado uma só vez.

Testei com um aplicativo de celular leitor de código de barras e leu corretamente. Experimente usar outro leitor.

Pode (dificilmente) ser o ambiente incorreto, uma mesma chave em homologação tem outro protocolo do que o de produção. Pode o protocolo estar errado mesmo, verifique e verifique de novo. Ou um problema na SEFAZ.

Não procede. O DANFe NFCe em Fortes tem mais contribuições que o em Fast, inclusive. Eu diria pra usar o DANFe NFCe em Fast apenas se você prefere ele (e tem a licença comercial que é requisito, ao contrário do Fortes que é open source.) O que houve foi a criação do novo componente específico para NFCe em Fast, que usava anteriormente o ACBrNFeDANFEFR, que servia tanto para NFe quanto NFCe em Fast, agora precisa usar o ACBrNFeDANFCEFR.

Cada chave deve aparecer pelo menos duas vezes, uma como resumo de NFe e outra como NFe completa. Além disso ainda pode se tratar de evento ou resumo de evento vinculado à NFe especificada, você verificou o tipo de documento que se trata esse retorno?

Essa pasta não existe no repositório, provavelmente é uma cópia local.

Versões mais antigas do Delphi não tem suporte a PNG. Tente usar uma imagem em bmp ou jpg.

Apenas inclua um componente RLPreviewSetup e configure a propriedade EnableButtons.

@douglaswf @Leandro Vignoto Enviei ajuste para o repositório, rev. 16555. Favor atualizar os fontes e testar novamente.

Realmente parece ter um erro na rotina. Pode anexar o XML para testes?

Veja que configurou a versão para ve200...

Sim.

Estranho, esse é erro de validação por falta de assinatura no XML. Está usando a opção "Consultar carregando XML" do demo? Que saiba a consulta não faz validação do arquivo.

Qual o erro?

Houve uma alteração recente que acredito resolver essa situação: function TNFeR.LerXml: Boolean; var ok: Boolean; i, j, k, nItem: Integer; Arquivo, Itens, ItensTemp, VersaoInfNFe, NumItem: AnsiString; Aspas, tagPag: String; begin Leitor.Grupo := Leitor.Arquivo; { ****** Remoção do NameSpace do XML ****** XML baixados dos sites de algumas SEFAZ constuma ter ocorrências do NameSpace em grupos diversos não previstos no MOC. Essas ocorrências acabam prejudicando a leitura correta do XML. } Leitor.Grupo := StringReplace(Leitor.Grupo, ' xmlns="http://www.portalfiscal.inf.br/nfe"', '', [rfReplaceAll]); Está com os fontes atualizados?

Estava comparando com o schemas do repositório, estão realmente diferentes. Tente informar o código com 9 dígitos, p.ex. 000118879.

Sua mensagem de erro é diferente, diz que o valor informado 118879 não é um valor válido para o campo. Olhando os schemas do provedor SJP, não faz sentido, deveria aceitar qualquer string com comprimento entre 1 e 20.

Provavelmente não é esse o XML onde ocorreu o erro, já que está inclusive autorizado pela SEFAZ.

Você precisa ver qual foi o IdCSC e CSC cadastrados na SEFAZ e informar no componente: ACBrNFe1.Configuracoes.Geral.IdCSC := <id do CSC>; ACBrNFe1.Configuracoes.Geral.CSC := <CSC>; Lembrando que o CSC para homologação e produção podem ser diferentes, dependendo da UF.