BigWings

Já foi enviada correção para esse problema, na rev. 19893 do svn. Com a ressalva que usar xsMsXML ou xsMsXMLCapicom continua não recomendado, por ter problemas graves com certificado A3 já reportados aqui no fórum. O recomendado é usar xsLibXML2 (padrão libWinCrypt).

Veja se o tópico abaixo é o mesmo caso teu:

Anexe log do ACBrInstall.

O XML do tópico original está com estrutura errada, com o grupo impostoDevol fora do grupo <det>. Outra coisa, caso esteja informando a tag vIPI não deve informar a vIPIDevol. Esta última deve ser usada por não contribuintes do IPI que não desejam destacar a vIPI. Informando as duas vai causar diferença no total da nota, já que ambas devem ser somadas ao total da NFe.

Teste com o .ini anexo. GovDigital.ini

Por favor, veja a citação, minha mensagem tinha sido para o @DouglasGV. Você fez teste usando a unit que o Daniel anexou, ou atualizou novamente os fontes?

Apenas atualize os fontes, a unit já está disponível no repositório. E pela mensagem de erro os teus estão desatualizados.

Sim, o próprio evento já retorna a situação da NFe, e você pode também consultar a chave pelo método de consulta. As notas de emissão própria, que seria o caso de uma devolução de uma NFe recebida de terceiros, não são retornados pelo método. Afinal a empresa que está fazendo a consulta deve saber se gerou a nota de devolução ou não.

Se você está usando o componente de impressão para Fast Report - ACBrMDFeDAMDFEFR - vai ser um pouco diferente mesmo. O post citado é sobre o componente para Fortes Report - ACBrMDFeDAMDFEFortes. Tem uma contribuição em análise com novos FR3, que talvez possa lhe interessar, aqui: Sim... com a diferença que o componente para Fortes dispensa o uso do FR3.

Veja:

Obrigado por reportar. Corrigido no SVN, rev.19883.

Marque a opção de salvar os arquivos de envio e retorno, e analise o XML retornado pelo webservice, se houver.

Por favor, atualize os fontes novamente. Foram enviados alguns ajustes para o tratamento de erros de conexão http.

Não sei se entendi bem o que você quer, mas veja a configuração "Quebrar linhas em detalhe dos itens" na configuração de impressão. Pra ser impresso uma ao lado da outra essa opção deve estar desmarcada.

O que notei de errado que pode estar causando a rejeição: - nSeqEvento deve ser sempre 1 para esse tipo de evento. - No grupo infBanco deve ser informado codBanco e codAgencia ou CNPJIPEF. Nunca as três tags.

No demo foi normal, mesmo definindo MostraSetup = False. A minha versão do Fast é a 6.0 Standard com FastScript. Como o Juliomar disse, pode ser isso, só não temos como testar.

Tem tópicos no fórum pra resolver isso. Pesquise por "FormularioContinuo". Não consegui replicar. Ocorre com qualquer XML? O erro ocorre usando o demo disponível em ACBr\Exemplos\ACBrDFe\ACBrNFe\Delphi DANFe FR? Está usando o Fast Report comercial ou o que vem junto com o Delphi?

Já houve relato no fórum dessa opção causar problemas: Se me lembro ela afeta as declarações do tipo packed record que pode ter comportamento diferente de acordo com a opção de compilação. Então sugiro que mantenha no padrão do Delphi (8).

Os fontes do ACBr são originalmente escritos em Pascal, para Delphi e Lazarus. https://projetoacbr.com.br/fontes/ Para outras linguagens existe o ACBrMonitorPLUS, que é um aplicativo que faz integração via arquivos texto ou socket TCP, e a ACBrLib, que é uma DLL que pode ser instanciada pelas aplicações. A DLL é desenvolvida em Lazarus, tem um demo em C# aqui: https://svn.code.sf.net/p/acbr/code/trunk2/Projetos/ACBrLib/Demos/C%23/Sat/Demo Aqui tem a DLL já compilada (se não me engano está disponível apenas para assinantes do SAC ACBr):

É este que está usando? https://github.com/ACBrNet Esse projeto é paralelo, não é oficial do Projeto ACBr. Sugiro que informe problemas no issues do github.

O nome do arquivo é formado por: - Código do tipo do evento: 110111 - Chave do CTe: 42200504632696000120570010000041671949769479 - Sequencial do evento: 01 - Sufixo -procEventoCTe Aparentemente a chave gerada no nome do arquivo está diferente da chave que está sendo informada no evento. Você tinha algum XML carregado no componente no momento do envio do evento de cancelamento? O ideal é fazer a limpeza antes do envio, chamando. ACBrCTe1.Conhecimentos.Clear; ACBrCTe1.EventoCTe.Evento.Clear;

Se estão atualizados você está na revisão 19796, que foi a última alteração no arquivo GovDigital.ini: Perguntei se você testou com a revisão 19763, que era a versão anterior, onde foram atualizadas as URL. Na revisão 19796 foi alterado o namespace. Nos testes que fiz, na revisão 19763, a assinatura é validada com sucesso no site da receita, já na revisão 19796 a assinatura não é validada. Então se você está usando o .ini da revisão 19796, tente reverter o arquivo para a 19763 e testar.

O mesmo erro da revisão 19796?