BigWings

Esse pacote fqb230 não é requisito do pacote ACBr_NFeDanfeFR. Talvez você tenha alterações locais que incluiu ele na lista. Ou algum problema na instalação do FastReport. Tente fazer revert das alterações se houver e instale novamente.

Anexe o log do instalador.

Você anexou apenas o XML de retorno. A regra de validação verifica se a data e hora da entrega é superior à data e hora de emissão do CTe e não superior à data e hora atual.

Tem que ser sequencial, no teu XML está 003, 002, 001...

Dificilmente vai encontrar alguém aqui que conheça o teu ERP, mas se está contratando, o lugar correto é o fórum de classificados, vou mover o tópico pra lá. Tente também o diretório de freelancers: https://www.projetoacbr.com.br/forum/companies/category/2-consultores/

Veja o que eu disse antes: Nessa NFe primeiro foi feita uma Confirmação, depois disso foi feito o Desconhecimento. Já houve a correção para Desconhecimento, não tem mais como emitir uma terceira manifestação definitiva. Nesse caso deve se consultar o contador pra ele orientar no que fazer.

Sim.

Sim, basta enviar nova manifestação com a correta. Mas só pode corrigir uma vez, não é possível enviar mais do que duas manifestações do tipo Confirmação, Desconhecimento ou Operação não realizada para uma mesma NFe.

Apenas lembrando que não são todos os provedores que incluem a tag indicando que aquele XML é produção ou homologação. Quando essa tag não existe no XML é usada a configuração do componente para que a impressão do DANFSE exiba a mensagem de emitida em ambiente de homologação. Então antes de imprimir o DANFSE se deve ajustar ela de acordo. ACBrNFSE1.Configuracoes.WebServices.Ambiente

Obrigado por reportar. Fechando. Para novas dúvidas, criar um novo tópico.

Foram atualizados todos os fontes de todas as pastas? Depois de atualizar, foi executado o ACBrInstall_Trunk2.exe para compilação, instalação dos pacotes e demais ajustes no Delphi?

Se está gerando chave diferente é porque alguma informação está diferente no novo XML. O mais provável é a tag cNF (código da nfe) que se você não informar ou informar 0 o ACBr gera um código aleatório. Se você não armazenou essa informação no banco de dados, vai precisar extrair o código da chave de acesso correta retornada na mensagem. Pra isso pode usar a função ExtrairCodigoChaveAcesso da unit pcnAuxiliar.

Tente apenas carregar o XML e consultar novamente para atualizar o arquivo. Você pode passar True para o segundo parâmetro do método ACBrNFe.LoadFromFile para forçar nova geração do XML. Depois assinar, validar e executar o método de consulta.

Isso é erro da SEFAZ do MS, está retornando assinatura junto do protocolo de autorização. Pelo tópico acima isso já foi corrigido.

Essa rejeição indica que você não informou os dados do grupo infLotacao, que são o CEP ou coordenadas do local de carregamento e descarregamento. É exigido quando o emitente é uma transportadora (tpEmit=1 ou 3) e o MDFe tem apenas um documento.

Creio que se trate disto: https://github.com/ACBrNet Esse projeto não é oficial do ACBr, você não vai encontrar nada sobre ele aqui. As DLLs daqui você compila usando o Lazarus ou caso seja assinante SAC pode baixar as DLLs já compiladas. Creio que não tenha ainda uma DLL para consulta de CNPJ. Downloads da ACBrLib: https://www.projetoacbr.com.br/forum/files/category/36-acbrlib/ Demos da ACBrLib: http://svn.code.sf.net/p/acbr/code/trunk2/Projetos/ACBrLib/Demos/ Manual: https://acbr.sourceforge.io/ACBrLib/ACBrLib.html

Creio que tenha baixado outro projeto. Que saiba o ACBr não está no Nuget. O ACBr tem código fonte em Pascal para Delphi e Lazarus. Para outras linguagens existe aplicativo de integração (ACBrMonitorPLUS) e DLLs (ACBrLib).

blcksock

Não entendi o "envia mas ninguém recebe". Se ninguém recebe como sabe que enviou? Tente: ACBrMail1.SMTP.Sock.SSL.SSLType := LT_SSLv2; Ou outra configuração no SSLType.

Você não especificou qual a configuração está usando para SSLType. Hoje é definido por Nota Técnica que os webservices só devem aceitar conexões usando TLS 1.2. Quando está configurado como httpWinHttp o ACBr usa a winhttp.dll do Windows, se o Windows não estiver atualizado, essa DLL não tem o suporte necessário a TLS 1.2. Já usando httpOpenSSL é usada a DLL própria, não dependendo do Windows. Então o recomendado é ter o Windows atualizado, configurar SSLType como LT_TLSv1_2 mas deixar esta configuração aberta para possíveis configurações incorretas dos webservices.

Parece o mesmo erro reportado aqui: A solução seria editar o arquivo Fiorilli.ini, na seção [Assinar] e desativar a assinatura para o RPS, Lote, RpsGerar, até encontrar uma configuração que o webservice aceite.

Até onde sei, é um parse HTML na página de consulta completa da nota, gerando um XML a partir daí, e assinado pelo próprio FSist. Se você tiver um XML baixado por esse site pode conferir: - Se o XML está assinado pelo emitente da nota. - Se o digest value da assinatura é o mesmo digest value do protocolo de autorização, no XML e na consulta no portal ou consulta de protocolo.

O que o FSist faz não será implementado no ACBr, se é o que está sugerindo.

Pelo arquivo de configuração das cidades você pode ter uma ideia: https://svn.code.sf.net/p/acbr/code/trunk2/Exemplos/ACBrDFe/ACBrNFSe/ArqINI/Cidades.ini A cidade de Passo Fundo - RS consta na lista, listado no provedor Thema.

Confirmei o bug no D7, correção já no SVN, rev. 20697.