BigWings

Pra usar o ClientDataSet tem que distribuir a MIDAS.DLL na versão do seu Delphi.
Ou apenas incluir MidasLib no uses do seu .dpr que ela já vai junto ao .exe.

Como diz a mensagem de erro, a DLL da ACBrLib é uma DLL nativa do sistema operacional, e não uma DLL .net por isso não é referenciável no projeto.
Ela é carregada em tempo de execução, basta copiar a DLL e as dependências para o diretório da aplicação.

Está informando 3 parâmetros para um método que só aceita 2.
O Juliomar te passou o grupo deles no Telegram, é a forma mais rápida de conseguir ajuda.

Isso indica que é algo na sua rotina, precisa debugar e encontrar o erro.
Geralmente é quando você tenta acessar um item de uma lista sem testar antes, por exemplo:
ACBrNFe.NotasFiscais[0] // vai dar o erro se não tiver nada na lista Trocar para:
if ACBrNFe.NotasFiscais.Count > 0 then ACBrNFe.NotasFiscais[0]...  

Tem no portal do DIFAL:
https://difal.svrs.rs.gov.br/aliquotas

Sim, minha sugestão é que deixe de usar o método ACBrBoleto.EnviarEmail, e use ACBrMail.Send, sem vincular com o ACBrBoleto.
O método ACBrBoleto.EnviarEmail já usa o ACBrMail, então na prática não faz diferença. O que não faz muito sentido é ter parâmetros pra NÃO incluir o boleto no método de envio do ACBrBoleto.

Carta de correção no CTe é diferente da NFe, precisa informar a lista de grupos, campos e valores alterados.
Estude o programa exemplo do ACBrCTe.

Você pode configurar a propriedade FormatoAlerta pra exibir a ID, nome da tag, caminho completo da tag, e não apenas a descrição, nos alertas.
No caso aí parecem ser as tags Det[x].Imposto.ISSQN.cListServ e Total.ISSQNtot.dCompet.

Pra quem não entendeu, o problema foi informar outro país para o endereço do emitente da nota. Nesse caso só é aceito BRASIL.

Eu fiz com o teu XML e mostrou a nota.

O "servidor virtual" é a SVRS (SEFAZ Virtual do Rio Grande do Sul). Ela quem autoriza as NFCe da maioria dos estados do país. Não tem nada de errado aí.

Quando configurado como CAPICOM, o que não é recomendado, é usada a WinINet.dll para comunicação https.
Nesse caso a configuração SSLType do componente não vai fazer efeito, e sim as configurações avançadas do IE do Windows, marcar lá pra usar o TLS 1.2.
E precisa ter todas as atualizações de segurança instaladas como já mencionado.

Provavelmente um erro de codificação, está chamando duas vezes o método pag.Add ou pag.New.

Está no SVN, com a tabela atualizada, ainda hardcoded por enquanto.

Até onde sei só eles mesmo pegaram essa bucha.
Para NCMs que não constam na tabela existe na própria tabela a prerrogativa de usar as alíquotas listadas no código "00000000".
 

Acho que não seria uma simples substituição porque geralmente eles subdividem um NCM em vários.
Precisa analisar cada item e classificar corretamente.
No Discord alguém postou uma tabela de correlação, se interessar...
https://discord.com/channels/798697718800318484/841297523485573140/960511189027274802

A SEFAZ-MG alterou a URL de consulta via QrCode em produção.
Nos fontes do ACBr, entretanto, foi alterado para usar essa URL em produção e homologação. Assim passou a autorizar em produção mas rejeitar em homologação.
Ontem foi enviada uma correção para a URL de consulta via QrCode em homologação.
Atualize novamente os seus fontes, reinstale usando o ACBrInstall_Trunk2.exe, recompile a sua aplicação, e teste novamente. Certifique-se também que não há um arquivo ACBrNFeServicos.ini do diretório da aplicação.
No Discord do ACBr estão relatando instabilidade há pelo menos uma semana. Não tem relação com a alteração da URL (ou não deveria ter).

ACBrBoletoFC1.MostraSetup := False;

O seu arquivo ACBrNFeServicos.ini está desatualizado.
 

Está faltando configurar as propriedades SSLLib:
https://acbr.sourceforge.io/ACBrLib/DFe.html
No caso do Linux configure pra OpenSSL.

Quem grava o arquivo é o componente, só precisa estar configurado pra salvar os arquivos, e haver retorno do envio do evento com cStat 135, 136 ou 155.

Provavelmente é falta de suporte a TLS 1.2 na máquina.
Atualizar o Windows ou usar OpenSSL.