BigWings

Sim... provavelmente é um problema na página de consulta da SEFAZ.

Aparentemente a cidade mudou de provedor. Altere no arquivo Cidades.ini: [3127701] Nome=Governador Valadares UF=MG ;Provedor=Actconv201 Provedor=SigIss E tente novamente.

Peça a eles um exemplo de XML de envio de lote com o lote e o RPS assinados que passe no validador da receita. Vi aqui que o XML anexado pelo Solivan mais acima é validado normalmente pelo validador da receita. Nesse caso deve ter algo errado com o processo que você está fazendo. Você fez alguma alteração nos fontes do programa exemplo? E qual o resultado do método Gerar por exemplo? Faça teste usando o programa exemplo do componente.

Atualize os fontes.

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

Mas atualizou todos os fontes de todas as pastas? Após atualizar executou o ACBrInstall_Trunk2.exe marcando a opção de remover arquivos antigos? A mensagem tinha sido pro @edulamy.

Enviei correção para os warnings, rev. 19600. Você provavelmente não atualizou todos os fontes da pasta ACBr.

Eu disse no primeiro parágrafo. Achei que a NFCe podia ter sido emitida no mês 02 ou 04, informando mês 04 a consulta retornou a chave correta (mesmo ela tendo sido emitida em 2015).

No exemplo de impressão do evento, primeiro é necessário selecionar o XML do MDFe, depois o XML do evento. Você está selecionando o XML do evento duas vezes.

Testando num Windows 7, atualizado, SSLLib = libWincrypt: Mudando o SSLType: Então: - Defina o SSLType como LT_TLSv1_2 - Veja se o Windows está com todas as atualizações instaladas

Já entrou em contato com eles pra saber o que está errado na assinatura? Pelo que vi o "erro" informado pelo validador da receita é o arquivo ter duas assinaturas, o que pro provedor seria o correto. Já tentou os outros métodos de envio (Gerar, Enviar)?

Alterando o 5º e 6º dígito da chave pra 04 e ajustando o dígito, é possível consultar. Aparentemente a chave correta para a NFCe com essa série e número é: 51150407243216000127650010000320811000320819 Fazendo a consulta pública no portal da SEFAZ nota-se que ela não tem nada a ver com o XML anexado.

Informe o CPF no campo CNPJ. Veja o programa exemplo do componente.

A base de cálculo, alíquota e valor do ICMS próprio são obrigatórios na linha dos itens, então esse DANFE não está de acordo com a especificação do manual. Nada impede que se acrescente as informações referentes ao ICMS-ST, como já é feito no DANFE paisagem já sugerido acima.

Se tratando do mesmo assunto basta continuar no mesmo tópico, não há necessidade de abrir um novo. Vou fechar este.

Vi que já tem um tópico sobre o assunto:

Em se tratando de NFSe não dá pra esperar que sigam padrões. Está tendo algum erro no envio do lote?

Tente: ACBrNFe1.SSL.StoreLocation := slLocalMachine; Declare a unit ACBrDFeSSL na cláusula uses.

Qual .fr3 está usando? Tente definir a margem superior como 0.

Se é FMX então retire o Vcl da unit scope names e adicione "FMX" às diretivas de compilação do projeto. Mas se não me engano o Fortes Report não é compatível com FMX então você não pode usar componentes baseados nele em projetos FMX.

A mensagem de erro indica que foi encontrada a tag MetodoInfo no XML de envio de lote (*-env-lot.xml) e ela não existe segundo o schema. Fiz teste de envio pelo programa exemplo do componente e não tive o mesmo erro... também não encontrei menção nenhuma a geração dessa tag no fonte do ACBr, então é estranho que esteja recebendo essa mensagem. Faça teste pelo programa exemplo, e anexe o arquivo de envio de lote (*-env-lot.xml).

Descrição do erro HTTP 407: Usam proxy na rede? Está configurando o proxy no componente?

Pra isso é necessário alterar o código do componente, o método que insere a assinatura no XML vai apenas a tag X509Certificate, dentro da X509Data. Entretanto esse método é o mesmo para todos os documentos (NFe, CTe, BPe, NFSe...), simplesmente alterar o método significa ter problemas nos demais documentos. Talvez o @Rafael Dias possa comentar melhor.

Significa que o XML foi recusado pelo webservice. Pra saber o motivo você vai precisar debugar o código do componente, na unit ACBrDFe.SSL, método TDFeSSLHttpClass.Enviar. Coloque um breakpoint na linha: Result := ReadStrFromStream(FDataResp, FDataResp.Size); Veja se após a execução dessa linha a variável Result vai conter alguma informação. Se o erro HTTP é o 400 provavelmente terá aí um XML com o motivo da recusa. Veja a minha tentativa (informei um CNPJ qualquer para a prefeitura):

Você ainda está usando httpIndy... configure pra httpWinHttp.