BigWings

Por padrão o componente atualiza o arquivo XML com o protocolo de atualização retornado no método ACBrNFe.Consultar, assim você tem o XML completo.

O XML é salvo na assinatura, se a configuração Configuracoes.Arquivos.Salvar estiver marcada e Configuracoes.Arquivos.SalvarApenasNFeProcessadas desmarcada. Ou mostre a mensagem de validação completa, como sugeri antes.

Você pode configurar o componente para mostrar o erro de Schema. ACBrNFe1.Configuracoes.Geral.ExibirErroSchema := True; No caso desse XML, ele não está assinado. Por isso a validação falha:

Que saiba nenhum provedor implementa esse serviço. O que se faz executar o método de envio e tratar o retorno. Mesmo para NFe é recomendável parcimônia no uso do método de status de serviço. Se chamar o status de serviço antes do envio de cada nota, por exemplo, pode haver interrupção de respostas para o certificado por consumo indevido.

Se a linha de comando do dcc32.exe tiver mais de 32000 caracteres, vai haver erro. Existe uma opção no instalador "Usar arquivo de configuração .cfg" que pode ser usada para contornar esse problema.

Se você não ativou a diretiva para usar as DLLs MinGW, use as DLLs da pasta ACBr\DLLs\OpenSSL\1.0.2.13. Aplicação.

Eu tenho usado compilando o ACBr e aplicação com as DLLs MinGW, mas fiz testes apenas copiando essas DLLs para a pasta da aplicação e funcionou normalmente. O recomendável é usar toda a trinca WinCrypt: SSLCryptLib := cryWinCrypt SSLHttpLib := httpWinHttp SSLXmlSignLib := xsLibXML2 Lembre que usando httpWinHttp você deixa de depender das configurações avançadas do IE e passa a precisar informar a propriedade SSLType do componente para configurar para TLS 1.2.

Realmente parou de funcionar após a alteração do site. Tem discussão sobre isso e proposta de alteração neste tópico:

Por ser um componente não visual creio que essa abordagem não seria aceita. Uma solução seria criar um evento, por exemplo, OnCarregarNCMs que traga como parâmetros os dados para que o programador possa alimentar em seu progress bar de preferência.

O problema em questão é na URL do namespace do WSDL, essa URL sequer está inserida no arquivo por ser o namespace padrão para o serviço. O namespace é montado pelo método DefinirServicoEAction: procedure TNFeStatusServico.DefinirServicoEAction; begin if (FPConfiguracoesNFe.Geral.VersaoDF >= ve400) then begin if EstaVazio(FPServico) then FPServico := GetUrlWsd + 'NFeStatusServico4'; if EstaVazio(FPSoapAction) then FPSoapAction := FPServico + '/nfeStatusServicoNF'; end [...] Se não houver a alteração do namespace pelo ACBrNFeServicos.ini, o padrão é montar a URL da forma que mencionei mais acima. Então, ou você tem fontes modificados, ou está usando um ACBrNFeServicos.ini ou .res modificado. Vai ser preciso debugar para encontrar o motivo de gerar o namespace incorreto.

Está diferente, veja onde destaquei o F maiúsculo que no seu está minúsculo.

Aqui está incorreto. Deveria ser: http://www.portalfiscal.inf.br/nfe/wsdl/NFeStatusServico4/nfeStatusServicoNF Veja se está compilando com o ACBrNFeServicos.res atualizado, ou se não tem um arquivo ACBrNFeServicos.ini desatualizado na pasta da aplicação. Se necessário faça um rever tem toda a pasta do ACBr, e instale novamente usando a opção de apagar arquivos antigos.

Você deve informar os impostos aproximados item a item na tag Det[x].Imposto.vTotTrib e a soma deles na tag Total.ICMSTot.vTotTrib. Se o valor informado em Total.ICMSTot.vTotTrib for diferente da soma dos valores informados em Det[x].Imposto.vTotTrib você terá essa rejeição.

A versão 5.3 supostamente já tem essas propriedades onde está acusando o erro. Talvez o compilador ainda esteja encontrando fontes .pas ou compilados .dcu da versão antiga do Fast. Tente desmarcar a instalação do pacote ACBrGNREGuiaFR.dpk.

Aparentemente este é o problema. O mime-type deve ser conforme a imagem abaixo: Deve ter algo errado com os teus fontes.

Arquivo atualizado no repositório.

Chegou a testar com essa URL? Ela sequer abre... Em todo caso, segue arquivo atualizado. ACBrNFeServicos.ini

Esse erro geralmente indica IdCSC ou CSC errados. Então é preciso verificar se estão sendo informados corretamente, e se foram criados para o ambiente em que está sendo enviada a NFCe, produção ou homologação. Também acontece de alguns formatos de CSC virem corrompidos por algum motivo, verificar pelo debug se isso não está acontecendo.

Verifique se o Windows tem todas as atualizações instaladas. Configure a propriedade SSLType para LT_TLSv1_2.

O arquivo parece estar correto... Qual o conteúdo das variáveis AURL, ASoapAction, AMimeType na chamada desse método?

Você está tentando enviar carta de correção para NFCe? Use o arquivo do repositório, está mais atualizado.

Essa é a URL divulgada pela SEFAZ? Até onde sei a validação da URL é feita pelo ENCAT: http://nfce.encat.org/consumidor/consulte-sua-nota/ Você pode entrar em contato com a SEFAZ e solicitar a URL correta. Tendo a URL, editar o arquivo ACBrNFeServicos.ini e informar a URL de consulta no arquivo, na chave [NFCe_BA_H] para homologação e [NFCe_BA_P] para produção.

Está sendo analisado. Obrigado.

Geralmente isso acontece quando há retorno do webservice, mas em um formato que não é o esperado pelo ACBr. Minha sugestão é que configure o componente para gravar os arquivos de envio e retorno ACBrMDFe1.Configuracoes.Geral.Salvar := True; ACBrMDFe1.Configuracoes.WebServices.Salvar := True; E analise os arquivos de retorno. Suspeito que tenha a haver com a configuração de TLS 1.2.

Sim, basta copiar o arquivo ACBrNFeServicos.ini para a pasta do executável da aplicação.