BigWings

Essa mensagem de erro acontece quando você faz a consulta de protocolo usando um XML diferente do autorizado pela SEFAZ. Depois de receber o protocolo de autorização o ACBr compara a tag digVal retornada pela SEFAZ com a tag DigestValue no grupo de assinatura, se estiverem diferentes quer dizer que não é o mesmo XML. Então não deve ter esse erro no momento da assinatura do XML, como você disse. Veja se realmente está assinando o XML antes de fazer a consulta.

Pode instalar o Fortes Report e reinstalar o ACBr marcando os componentes baseados nele. https://github.com/fortesinformatica/fortesreport-ce

Como o @Info-House mencionou, a rejeição 539 devia retornar a chave que consta na SEFAZ. Na consulta pela chave de acesso, desde que esteja usando o certificado do próprio emitente, deveria retornar a rejeição 562 "Código Numérico informado na Chave de Acesso difere do Código Numérico da NF-e [chNFe:99999999999999999999999999999999999999999999]" também com a chave que consta na SEFAZ como no exemplo. Agora se a SEFAZ não retorna a chave, fica difícil descobrir... pode tentar falar com o contador pra ver se ele tem esse XML. Uma forma de provar que a NFe foi emitida é tentar inutilizar a numeração, caso tenha a rejeição 241 quer dizer que foi emitida uma NFe com essa série/número.

Por enquanto eu também estou usando a 1.0.2 por causa das dependências da 1.1.1. Assinatura e validação de XML

Sobre a OpenSSL leia aqui:

É uma "feature" do Fortes Report. Você pode tentar usar o componente para Fast Report (precisa da licença comercial) que não tem esse problema.

Esse demo parece antigo, está com os fontes atualizados? Verifique a validade do certificado. Configure SSLType para LT_TLSv1_2.

Ao que parece a consulta está sendo feita para a nota carregada em vez da chave informada. Tente chamar o método NFE_LimparLista antes de fazer consulta por chave de acesso.

Se você olhar o tópico abaixo, o Elton fez uma varredura geral nas impressões DFe com relação as margens estarem em mm ou cm: Pelo tópico, NFCe em Fast era em mm, e o padrão do componente era em cm, então ficava 0.51 mm pra margem direita, 0.6 mm para a esquerda... Agora o padrão alterou para mm, ficando 5.1, 6, 8 e 8 mm, consequentemente mudando as margens no DANFE NFCe em Fast. Não tinha como manter como era em todos os documentos, algum ia ter modificação, foi feito da forma a ter impacto menor considerando todos os DFe. Pra finalizar, sugiro colocar a margem superior e inferior como 0, pra não cortar o rodapé do DANFe NFCe.

Dica, configura pro ambiente de homologação do AM. http://portalnfce.sefaz.am.gov.br/desenvolvedor/ambiente-de-homologacao-para-desenvolvedores/ NFCe em MG em homologação está MUITO problemático.

Não compreendi o problema, não apareceram aqui os prints.

Se o erro continua ainda deve ter conflitos. Abra esse fonte e veja como está a linha 95: Como pode ver não tem caractere "<" aí...

Você deve ter tido conflitos na atualização por conta de alterações locais. Use a opção "Resolve" do TortoiseSVN pra resolver os conflitos, ou reverta os fontes pra descartar as alterações locais.

Sim, isso não é erro da SEFAZ, está previsto na NT 2020.006 v1.10. Obrigado por reportar. Fechando. Para novas dúvidas, criar um novo tópico.

A mensagem de erro indica que estão faltando arquivos. A atualização via SVN Update finalizou sem erros? Tente repetir o processo.

O validador da SEFAZ ainda não foi atualizado. Já os schemas do ACBr estão validando:

Pedi o arquivo XML, não tem como testar aqui só com trecho de XML, que está correto aliás. O problema é a sua pasta de Schemas desatualizada. Você verificou a propriedade PathSchemas? Testou com o programa exemplo do ACBrNFe?

Anexe o XML.

Não é necessário um Schema diferente pra homologação, como a tag é opcional no layout, os novos schemas vão funcionar você informando ou não a tag. Então basta estar com a pasta de Schemas atualizada conforme já está na pasta ACBr\Exemplos\ACBrDFe\Schemas\NFe. Verificar também se está configurando a propriedade PathSchemas para uma pasta atualizada.

Certo, mas lembre de colocar o IFDEF na declaração do método na seção interface também.

Usa apenas essa versão? Você notou que eu passei duas formas de resolver? Qual delas você usou?

A assinatura desse método muda conforme a versão do Delphi. Se você implementou numa versão e está abrindo em outra pode ter esse erro, mas basta atribuir novamente. Ou usar IFDEFS, por exemplo: {$IFDEF DELPHI2009_UP} procedure TFTelaPrinc.BalancaLePeso(Peso: Double; Resposta: AnsiString); {$ELSE} procedure TFTelaPrinc.BalancaLePeso(Peso: Double; Resposta: string); {$ENDIF} begin [...] end; Insira a diretiva {$I ACBr.inc} pra usar o IFDEF.

Tente o método ACBrBoleto.Banco.MontarCampoNossoNumero.

As margens são em milímetros.

Na documentação não encontrei nada a respeito de email ou de uma forma de o banco enviar o boleto. Lembrando que a documentação seguida pelo ACBrBoleto é esta: https://svn.code.sf.net/p/acbr/code/tools/Bancos/Santander/H7815_Layout_Cobranca_CNAB_240_posicoes_padrao_Santander_Multibanco_Agosto_2020_V.3.4.pdf