BigWings

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.

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

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.