BigWings

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.
 

Devia ser assim:
<pag> <detPag> <indPag>0</indPag> <tPag>17</tPag> <vPag>25.00</vPag> <card> <CNPJ>16501555000238</CNPJ> <cAut>ASHDKJAHD10903120ASHDAH</cAut> <CNPJReceb>06372697000108</CNPJReceb> <idTermPag>SN4AD81MG9Q</idTermPag> </card> </detPag> </pag>  

O que falta é o elemento <adi> com os dados da adição, em pelo menos um dos itens da nota.

Só ir na documentação:
https://www.firebirdsql.org/file/documentation/reference_manuals/reference_material/html/langrefupd21-intfunc-lower.html
https://www.firebirdsql.org/file/documentation/reference_manuals/reference_material/html/langrefupd20-trim.html
https://www.firebirdsql.org/file/documentation/reference_manuals/reference_material/html/langrefupd25-intfunc-replace.html
TRIM e LOWER é a partir do Firebird 2, REPLACE a partir da 2.1.
Pra versões antigas, vai precisar procurar uma UDF.
Eu usava essa abaixo, não lembro se é compatível com FB 1.5:
https://firebase.com.br/downloads.php?id=14

Mas gerou o hash completo no XML?
Seus fontes do ACBr estão atualizados?

Por enquanto está implementado apenas para o extrato SAT.

Geralmente isso é por ter schemas de NFe, CTe, MDFe na mesma pasta.
Os três documentos tem o método DistribuicaoDFe, mas o da NFe é em versão diferente.
No caso precisa ter uma específica para o schemas de CTe e informar no componente.

Parece ser falta das DLLs da LibXML2, copie elas da pasta DLLs do ACBr para a pasta do seu exe.

https://svn.code.sf.net/p/acbr/code/tools/PosPrinter/Daruma/DR800_CMD-REV05.pdf
 

Ambos são o código do cedente/beneficiário, com 7 dígitos.

Pelo manual, isso não pode ser feito, essas colunas devem indicar o valor das tags vICMS e pICMS, então para emitentes do Simples só vai ser mostrado quando usando o CSOSN 900 destacando o imposto.


O que você poderia fazer é criar novas colunas para as tags do crédito do Simples.
O usual é só informar o valor do crédito do simples nas informações complementares da nota. Se desejar informar por item, pode adicionar na infAdProd.

Tente configurando como TLS 1.1.
Veja também o tópico abaixo:
 

O problema é com os A3, tenho outros A1 na mesma máquina funcionando.
Testa com LT_TLSv1_1.

Tenta desativar a configuração de RetirarAcentos no componente.

http://portalabbc.org.br/images/content/manual operacional.pdf

O que entendi desse manual é que se a data resultante for mais de 3000 dias atrás (em relação a data atual) considerar ele como vencimento futuro.
E se além disso, for mais de 5500 dias a frente, cai no range de segurança, então considerar como inválido.

Tente configurar para TLS 1.1.
Se não der certo siga as instruções do tópico abaixo:
 

Precisa configurar o certificado para a requisição.
No Postman isso é feito em Settings - Certificates - Client certificates.
Pode informar o teu PFX e a senha.

Geralmente isso é configuração incorreta da ACBrNFe1.Configuracoes.WebServices.UF.

É o mesmo problema que tem na NFe, você deve estar usando os schemas oficiais, com o regex dele, e usando a LIBXML2 que é o padrão do ACBr, vai ter erro de validação em qualquer string com menos de 3 caracteres.
A solução é simples, basta usar os schemas disponibilizados pelo ACBr na pasta ACBr\Exemplos\ACBrDFe\Schemas\NFSe. Foi feito um pequeno ajuste nos schemas para contornar esse problema.

Testei aqui só trocando [BoletoXXX] por [DuplicataXXX] e mostrou as parcelas:

 

O ideal é que isso seja tratado pela aplicação antes da emissão para evitar rejeição do tipo. NCM e CFOP é algo simples de tratar.
Mas sim, em caso de rejeição, gera novamente o XML corrigindo apenas a informação que causou a rejeição, assina e transmite.