BigWings

Salve  o arquivo em anexo na sua pasta de schemas e tente novamente.
e110140NFCe_v1.00.xsd

Não, elas são compiladas para Windows e Linux.
Numa pesquisa rápida, me parece que é possível ativar compatibilidade binária com o Linux no FreeBSD.
https://docs.freebsd.org/pt-br/books/handbook/linuxemu/

Enviei para o SVN, rev. 37982, uma correção, implementada de um modo um pouco diferente da sua.
Favor fazer cópia do teu fonte atual, e atualizar com os do SVN, e fazer os testes.

Se está apenas alterando o formulário (.dfm) e não os fontes (.pas) só precisa copiar os arquivos .dfm alterados para a pasta ACBr\Lib, para que o linker do Delphi enxergue os arquivos na compilação.
Ou rodar o instalador do ACBr novamente, que já compila os fontes e copia os .dfm e demais arquivos necessários para a pasta Lib.
Cuidado ao compilar direto o pacote pelo Delphi, pra não ter arquivos .dcu diferentes espalhados pelo disco.

Não, só sendo Pro ou compilando você mesmo as DLLs.
 

ACBrNFSeX1.DANFSe.Cancelada := True;

Atualize os fontes, esta semana teve uma correção.

A consulta por chave não existe mesmo para CTe.
Ela foi implementada no ACBr porque imaginou-se que haveria algo no mesmo modelo que existe para NFe, mas a SEFAZ nunca chegou a disponibilizar.
Para CTe use a consulta por NSU ou por último NSU.

Se não me engano sim, o cadastro é do CPF do responsável legal, e vincula com o CNPJ da software house.

Pedi o XML justamente pra conferir isso.
- Qual serviço está sendo invocado
- Qual o NSU informado para consulta
Desconfio que esteja usando o método por NSU e não o por último NSU.

Isso é sobre folha de pagamento, não tem relação com o ACBrBoleto.

Você não usa o instalador do ACBr para compilar os pacotes?
Se tiver feito pelo instalador e pelo Delphi vai ter duplicidade de arquivos compilados (dcu, dcp, bpl) em pastas diferentes, que causa uma série de problemas.
Se for o caso, no instalador tem a opção de apagar arquivos antigos, basta executar o instalador novamente marcando essa opção.

Versão da DLL?
Pelo que vi o suporte ao Bradesco foi incluída recentemente:
 

Estranho porque a validação no componente é de janeiro de 2023.
Parece ser algo errado com as credenciais, o certificado foi gerado e enviado para o banco na criação da aplicação?
Você está emitindo em produção ou homologação (sandbox)?

O controle é separado por CNPJ, ter bloqueio em um não impede de fazer a consulta no outro, mesmo usando o mesmo certificado.

Também uso o Firefox, e acontecia isso, só parou quando aceitei os "Optional cookies".

O nosso número no Sicredi é formatado como AA/BNNNNN-D.
AA - Ano do documento
B - Byte de geração
N - Sequencial do nosso número
D - Dígito verificador
A parte que você informa para o nosso número no componente é apenas o sequencial NNNNN (5 dígitos), por isso a limitação.

Tenta ir nas opções de compilação do projeto e desabilitar a opção "Complete boolean eval".

Não entendi bem, mas pra mim:
- Se é NFCe entende-se que o cliente está utilizando o crédito.
- Na nota de devolução (entrada) indicaria uma aquisição de crédito pelo cliente.

Faça assim:
ACBrNFe1.Configuracoes.RespTec.IdCSRT := 1; ACBrNFe1.Configuracoes.RespTec.CSRT := '123456789...'; E na geração da nota:
ACBrNFe1.NotasFiscais[0].NFe.infRespTec.CNPJ := 1234001010200; ... Já será calculado o hash e gerado no XML.

O github não tem mais suporte a SVN, então precisa baixar direto via git.
 

Essa exceção está no método de envio do componente:

Chame ACBrNFe1.Notasfiscais.Clear antes do ACBrNFe1.NotasFiscais.Add na sua rotina de preenchimento.
Assim não vai ter mais de 1 nota carregada no componente ao transmitir.

Por causa do try..except no método Execute, como dito.
procedure TCustomRESTRequest.Execute; [...] begin [...] try [...] except // any kind of server/protocol error on E: EHTTPProtocolException do begin FExecutionPerformance.ExecutionDone; // we keep measuring only for protocal errors, i.e. where // the server actually answered, not for other exceptions. LContent := E.ErrorMessage; // Full error description // Fill RESTResponse with actual response data - error handler might want to access it ProcessResponse(LURL, LResponseStream, LContent); if (E.ErrorCode >= 500) and Client.RaiseExceptionOn500 then Exception.RaiseOuterException(ERESTException.Create(E.Message)); HandleEvent(DoHTTPProtocolError); end; // Unknown error, might even be on the client side. raise it! on E: Exception do begin // If Execute raises an Exception, then the developer should have look into the actual BaseException Exception.RaiseOuterException(ERESTException.CreateFmt(sRESTRequestFailed, [E.Message])); end; end; Sendo uma exceção do tipo EHTTPProtocolException ele faz os tratamentos, mas ignora a exceção em runtime exceto no caso da propriedade RaiseExceptionOn500 estiver ativada e o status de retorno for maior 500 ou maior.
Ele também chama o evento OnHttpProtocolError que você pode querer implementar (para logs por exemplo).

Já está implementado sim.