BigWings

O nosso número como é impresso no boleto é formatado pelo componente, não faz muito sentido armazenar ele dessa forma no banco de dados... Mas creio que possa chamar o método de formatação: NossoNumeroFormatado := ACBrBoleto1.Banco.MontarCampoNossoNumero(ACBrBoleto1.ListadeBoletos[xx]);

NFCe sempre informar indIEDest=9 com IE em branco, está no MOC.

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

Acredito que a implementação atual seja apenas para DANFE NFe. Você pode inserir as informações na tag infAdProd para exibir no DANFE NFCe.

Também pode definir o número de cópias na configuração. https://acbr.sourceforge.io/ACBrLib/ConfiguracoesdaBiblioteca18.html

Se teve o erro é por ter apenas um evento carregado, o índice máximo que pode informar é 0. Você também pode colocar em um for: for I := 0 to ACBrNFe1.EventoNFe.Evento.Count - 1 do begin tpEv := ACBrNFe1.EventoNFe.Evento.Items[I].InfEvento.tpEvento; nSeq := ACBrNFe1.EventoNFe.Evento.Items[I].InfEvento.nSeqEvento; end;

Essa tag foi removida do CTe a partir da versão 3.00. Se ainda aparece no DACTE pode ser removida...

EVENTO 2: ACBrNFe1.EventoNFe.Evento.Items[1].InfEvento.nSeqEvento; Mas porque está carregando mais de um evento? No caso da carta de correção apenas a última enviada é válida.

O instalador do ACBr realmente não compila em 64bits, por isso é incluído no library path o caminho para os fontes. Como disse o Juliomar, o problema é com o Fast Report, se você incluir um componente frxReport e tentar compilar em 64 bits provavelmente terá o mesmo erro. Verifique se tem os fontes do Fast informados no library path para o compilador em 64 bits, ou o diretório dos .dcu 64bits:

Nesse caso sempre vai passar 1 como número da remessa, alguns bancos exigem o envio na sequência correta, caso contrário ela é rejeitada.

Tem um série de erros indicando que não encontrou as classes do Fast Report, mas o pacote DANFE compilou normal. Tem alguma alteração local nos seus fontes? Alguma pasta ou arquivo marcada em vermelho na pasta do ACBr? Se tiver você pode tentar fazer o revert pelo Tortoise. Ou tentar baixar novamente os fontes em outra pasta.

O número da remessa é o segundo parâmetro do comando, deve ser controlado pela tua aplicação.

Acho que não existe mais a versão "free". Você pode baixar os fontes e compilar. Ou fazer uma conta trial pra baixar a versão SAC.

Anexe o log do instalador.

Bem provável que tinha esse fonte solto na pasta do ACBr e foi adicionado ao projeto com esse caminho. Olha no seu .dpr se não está referenciando essa unit RxCurrEdit.pas. E se tem referência a ela nas outras units do projeto, use o "Find in files" do Delphi pra procurar.

Porque é a versão do compilador e não da IDE.

Veja se o library path não está apontando para mais de uma instalação do Fast Report.

Não existe esse arquivo nessa pasta. Provavelmente está com erro na instalação da RXLib. Qual a mensagem de erro exata na compilação?

Não é preciso efetuar a manifestação de Confirmação. Apenas a manifestação de Ciência já é suficiente para ter acesso ao XML completo. Não faz sentido exigir a confirmação, já que isso indica que a mercadoria foi recebida pelo destinatário e impede o emitente de cancelar a nota. Mas aguardar o tempo de processamento da manifestação pelo ambiente nacional e geração de novo NSU com o XML completo é necessário sim, isso pode levar desde alguns segundos até minutos, horas e em alguns casos até dias.

Anexe os logs de instalação.

Usando Fortes ou Esc/Pos? Na versão em Fortes Report você pode salvar o PDF. Que saiba não tem como "abrir" um PDF pelo Fast Reports para impressão. Gerado o PDF você pode chamar a aplicação própria, p. ex. o Adobe Reader para imprimir.

Somando os itens, a SEFAZ está correta, o valor total deve ser 1.030,68, que é a soma dos valores informados no vProd de cada item. Lembre que você deve arredondar o valor em cada item, e somar só após o arredondamento.

Versões diferentes do Fortes no caminho de compilação. Está executando o instalador do Fortes e do ACBr?

Testei aqui com mais de um certificado e o resultado de CertNumeroSerie foi o mesmo tanto com OpenSSL quanto WinCrypt. Você fez o teste com o programa exemplo? Qual o ambiente de compilação?

Correção no svn, rev. 20812.