BigWings

Faça a consulta dessa chave no portal nacional da NFe e veja se realmente não consta evento de manifestação.

Os fontes são abertos. Você pode baixar os fontes e compilar o ACBrMonitorPLUS você mesmo. Pra baixar ele já compilado e empacotado, e ter suporte profissional por parte do ACBr, existe os planos SAC. https://www.projetoacbr.com.br/forum/sac/sobre/

Não entendi, qual a dificuldade?

Não existe esse CST. Aqui você informa que o emitente é do Regime Normal.

Nesse caso o problema parece estar na SEFAZ. Melhor entrar em contato e reportar.

Creio ser possível... Já tentou ver nos fontes como o ACBr faz a validação?

Tem alguns tópicos no fórum sobre isso, alguns bem antigos já. Nunca chegou a ser implementado no ACBr.

fpPagamentoInstantaneo é o PIX.

Aguardar a SEFAZ-MG em específico aplicar a NT 2020.006 em seu webservice. Em homologação a data era 01/02/2021, foi prorrogada para 01/03/2021 em MG e outras UF, mas só foi ativado de verdade ontem:

Atualize o arquivo ACBrNFeServicos.ini.

Existe o erro de validação por schemas locais que é feito pelo ACBr. E existe a validação por schemas feito do lado da SEFAZ, que é a rejeição que você está recebendo. Se você usou o método ACBrNFe.Enviar e recebeu essa rejeição quer dizer a validação local passou, mas a SEFAZ recusou. Isso porque a SEFAZ ainda não atualizou os schemas do lado dela, pra NT 2020.006 a previsão de entrada em produção é 05/04/2021.

Nos seus arquivos de configuração tem diferença no campo emit_cRegTrib: Veja se não é esse o problema.

Já está tudo atualizado no SVN. TpcnFormaPagamento = (fpDinheiro, fpCheque, fpCartaoCredito, fpCartaoDebito, fpCreditoLoja, fpValeAlimentacao, fpValeRefeicao, fpValePresente, fpValeCombustivel, fpDuplicataMercantil, fpBoletoBancario, fpDepositoBancario, fpPagamentoInstantaneo, fpTransfBancario, fpProgramaFidelidade, fpSemPagamento, fpRegimeEspecial, fpOutro); O 99 foi mantido, afinal ele ainda existe nos schemas, e só passará a ser recusado em produção a partir de 01/09/2021.

Não ficou claro como você está informando o CST ou CSOSN para o componente e qual deles. O emitente é optante pelo Simples Nacional? Como está informando a tag Emit.CRT?

Acho que você não entendeu. Você conseguiu assinar o XML? Se conseguiu anexe ele aqui. Mesmo com o XML assinado e fazendo a consulta, teve o erro de digestvalue?

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

Está correto, são os layouts implementados. Para NFCe existem componentes específicos. Essa propriedade TipoDANFE se aproveita de um tipo que é usado na verdade pra gerar o XML. TpcnTipoImpressao = (tiSemGeracao, tiRetrato, tiPaisagem, tiSimplificado, tiNFCe, tiMsgEletronica); Talvez o mais correto fosse remover a propriedade do componente DANFE e usar a informação do XML.

Defina a configuração NFE.Configuracoes.Arquivos.EmissaoPathNFe, dessa forma vai salvar sempre no mês da data de emissão da nota e não o mês da data que o arquivo foi atualizado.

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.