NFSe Provedor Goiânia com problema de Envio

[infopointerp]

Eu atualizei o componente e estou recebendo o retorno: 

            <Mensagem>Erro desconhecido. Nao foi possivel identificar o erro ocorrido na solicitacao.</Mensagem>
            <Correcao>Entre em contato com a prefeitura para maiores informacoes.</Correcao>

Coloquei o programa antigo e consegui autorizar.  Comparando o xml gerado os dois são iguais, mas quando gera o soap deles os dois diverge na parte da assinatura.

Não consegui achar uma forma de resolver isso. Vou postar os dois xml aqui o soap de envio autorizado o que o sistema está gerando agora que está gerando aquele retorno acima.

 

 

7534-ger-nfse-soap-REJEITADO.xml 7534-ger-nfse-soap-AUTORIZADO.xml

[Italo Giurizzato Junior]

Boa tarde,

Você esta com todos os fontes de todas as pastas atualizados?

Se sim, verifique se a unit ACBrNFSeNotasFiscais possui uma bolinha vermelha em seu ícone.

Se não tem, chegou a reinstalar a suite ACBr com o ACBrInstall_Trunk2 com a opção de apagar arquivos antigos marcado?

[infopointerp]

Eu apaguei a pasta toda e baixei novamente os fontes. Vou tentar essa opção de apagar os antigos.

 

[infopointerp]

Atualizei os fontes para a revisão 20818 que é a mais recente e marquei para apagar arquivos antigos.

Recebi a mesma rejeição.

Pelo que eu analisei olhando o xml autorizado e o cancelado os dados são os mesmos com as mesmas tags. Apenas quando vai no soap que a assinatura muda e cria tags de fechamento, que um caso deles é o DigestMethod:

&lt;DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"&gt;&lt;/DigestMethod&gt;

[Italo Giurizzato Junior]

Bom dia,

Qual é o valor que você esta passando para a propriedade de configuração: SSLLib?

[infopointerp]

Bom dia,

Estou passando os valores abaixo:

SSLCryptLib := TSSLCryptLib.cryOpenSSL;
SSLHttpLib := TSSLHttpLib.httpOpenSSL;
SSLXmlSignLib := TSSLXmlSignLib.xsLibXml2;

SSLType := TSSLType.LT_TLSv1_2;

[Juliomar Marchetti]

Faz o seguinte informa somente o SSLib para WinCrypt os demais comente enão altere

[infopointerp]

Vou tentar

[infopointerp]

Comentei as configurações anteriores e configurei apenas:

      with Configuracoes.Geral do
         SSLLib := TSSLLib.libWinCrypt;

O retorno continua o mesmo.

[Italo Giurizzato Junior]

Por favor faça um teste usando o programa exemplo do componente.

Com a seguinte configuração:

[infopointerp]

Vou tentar por ele e depois dou retorno.

[infopointerp]

Boa tarde,

Consegui fazer o envio. Eu pego o xml do RPS gerado carrego no componente e mando Gerar().

O retorno foi:

Inicio TNFSeGerarNFSe
Método..... : Gerar
Código Erro : L001
Mensagem... : Erro desconhecido. Nao foi possivel identificar o erro ocorrido na solicitacao.
Correção... : Entre em contato com a prefeitura para maiores informacoes.
Provedor... : Goiania

ERRO: Erro desconhecido. Nao foi possivel identificar o erro ocorrido na solicitacao.
Entre em contato com a prefeitura para maiores informacoes.

 

Caso queiram olhar aqui no meu computador me envia mensagem que passo a conexão.

[Italo Giurizzato Junior]

Boa tarde,

Eu não entendo essa obsessão de gerar o XML, salvar ele, depois carregar para por fim enviar.

Não seria muito mais pratico alimentar o componente com os dados do serviço prestado e por fim executar o método disponibilizado pelo provedor para o envio do RPS?

Que no caso de Goiânia somente o método Gerar foi disponibilizado.

No programa exemplo do componente ACBrNFSe temos o botão [ Enviar um RPS (Gerar) ] que exemplifica a execução do método Gerar.

Temos que ter em mente que se tratando de NFS-e não existe padrão.

Temos provedores que requerem que somente o RPS seja assinado, outros requerem que somente o Lote de RPS seja assinado, outros requerem que tanto o RPS quanto o Lote sejam assinados, outros não tem que assinar nada.

Outra coisa os Schemas disponibilizados (quando disponibilizam) pelos provedores nos permite validar o envio do lote de RPS, a consulta, o cancelamento, mas não permite que validamos somente o RPS.

Logo não faz nenhum sentido em querer gerar o XML, validar o mesmo ou nem validar por falta dos Schemas, carregar o XML do RPS através do LoadFromFile ou LoadFromStream para depois executar um dos métodos de envio.

Outra coisa muito importante é que o método chamado Gerar tem a finalidade de Gerar o RPS e enviar para o webservice do provedor, na maioria dos provedores o serviço GerarNfse acessado pelo método Gerar do componente só aceita apenas UM RPS por vez, ou seja, não permite o envio de um lote.

O serviço GerarNfse trabalha no modo síncrono, ou seja, no retorno já temos o resultado do processamento, logo se o RSP foi processado com sucesso teremos o XML da NFSe no retorno.

Fica a dica.

[infopointerp]

Boa tarde,

Fica até difícil responder sem querer causar algum atrito. Não estou aqui procurando causar problemas para ninguém, estou apenas passando o problema que peguei e não consegui resolver sozinho que pela minha comparação entre os dois gerados está na assinatura.

O que está autorizando está funcionado com a "obsessão do xml" e está funcionando perfeitamente sem nenhum problema e está autorizando até agora.

Sobre a "Obsessão" quando eu estava implementando e fazia Fluxo:

- Alimenta Componente
- Consulta RPS
- Enviar

Na parte de consulta teve provedor que na coleção de itens NotasFiscais ficou mais de 1 e ai tinha que pegar e ver qual era o que eu estava enviando, e não conferi se isso ainda acontece. E por testes eu pego o xml gerado na primeira geração e carrego e envio, já to com ele ali pronto para usar, porque não usar?

E outro fato agora que estamos usando o "XML Obsessão" agora para gerar a impressão do RPS e depois que a prefeitura volta enviamos esse gerado anteriormente para ela sem alterar os dados, assim como é feito na NFC-e.

Das outras partes estou ciente sim de como tudo funciona. Eu estou usando dessa forma e está autorizando sem problemas para outros 5 provedores.

Mas no fim eu só queria que fosse verificado porque a assinatura está diferente e sem tem como verificar ou me falar o que tenho que fazer para corrigir.

Só quero autorizar a nota do cliente e seguir a vida.

Vou alimentar o componente e enviar para ver se esse é o problema então.

Obrigado

 

 

[infopointerp]

Alimentei o componente e mandei gerar, mesmo resultado.

Vou tentar desbravar o componente e enviar sem a diferença que pontuei anteriormente na assinatura e ver se vai dar certo.

Obrigado pela atenção.

Caso forem olhar e precisar de algo estou a disposição, meu foco é autorizar a nota.

[Italo Giurizzato Junior]

Boa noite,

Por conta da falta de padronização entre os provedores eu prefiro deixar o componente fazer o trabalho dele, pois ele trata todas as diferenças.

Mas vamos lá, fiz uma alteração no arquivo INI do provedor e uma correção no fonte do componente, vamos ver se agora vai funcionar.

Por favor atualize os fontes e faça novos testes.

Note que fiz uma alteração no arquivo Goiania.ini

 

[infopointerp]

Bom dia,

Vou atualizar e tentar novamente.

[infopointerp]

Bom dia,

O ajuste no Ini que ajusta as tags de assinatura deu certo, mas o recebimento pelo WS ainda continua na mesma rejeição.

Estou utilizando o exemplo do componente, certificado instalado e alimentando o componente direto e mesmo assim não deu certo o envio.

Peguei esse soap gerado e comparei com o que foi autorizado e o que encontrei de diferença é apenas a parte da assinatura, fora isso não encontrei mais nada que possa gerar o problema.

Eu fiz um teste diretamente na "TDFeSSLHttpClass.Enviar", peguei o soap certo e carreguei no lugar do gerado do componente e consegui o retorno certo dizendo que já existe o RPS.

Estou anexando os dois xml para que possa verificar. Agora não sei mais o que pode ser o problema.

7534-ger-nfse-soap.xml 7534-ger-nfse-soap-Certo.xml

[Italo Giurizzato Junior]

Bom dia,

Notei que na assinatura o valor do DigestValue e SignatureValue são diferentes de um arquivo para o outro.

Ocorreu a troca de certificado digital?

O DigestValue muda quando alguma informação no XML esta diferente, mas pelo que notei o problema não é esse.

Se não me falha a memória o SignatureValue muda se mudar o certificado.

Agora se o certificado é o mesmo, o problema pode esta na rotina que realiza a assinatura.

Em ambos foi utilizado o valor xsLibXml2 para a propriedade XMLSignLib?

 

[infopointerp]

Vou conferir a forma que está sendo utilizada e ver se fica igual. 

[infopointerp]

Não consegui resolver, a parte da assinatura. Conectei no cliente peguei o certificado e instalei na minha máquina e recarreguei, mesmo assim não deu certo.

Peguei os dois xml e enviei para a prefeitura e esperar o retorno.

Obrigado

[Italo Giurizzato Junior]

Bom dia,

Vai ser necessário voltar as revisões dos fontes até descobrir em qual revisão passou a ocorrer o problema.

Desta forma vai ser possível identificar a unit que foi alterada e cuja alteração esta provocando o erro.

[infopointerp]

Eu tentei pegar o fonte do mês 3 desse ano mas não tinha dado certo, talvez seja porque não fiz aquela limpeza dos arquivos mais antigos.

Mais tarde vou ver se pego uma revisão antiga e tento ver se vai dar certo.

[infopointerp]

Boa tarde,

Encontrei o problema que é o tipo do SSL, anteriormente eu estava usando capicom (SSLLib := libCapicomDelphiSoap) e agora com OpenSSL ou WinCrypt retorna a mensagem de "Erro desconhecido. Nao foi possivel identificar o erro ocorrido na solicitacao."

Outra coisa que está gerando problema é no envio devido a usar "UseCertificateHTTP" com o Delphi rio (CompilerVersion >= 33) que retorna a mensagem: 'Erro ao ajustar INTERNET_OPTION_CLIENT_CERT_CONTEXT: 6' no (TDFeHttpIndy.OnBeforePost). Mas talvez depois que achar a diferença do capicom para o openSSL essa erro não vai dar mais.

Eu não sei o que eu posso verificar a diferença na hora do envio para fazer funcionar com OpenSSL ou winCrypt. Caso precise de algo me avise por favor.

 

 

 

 

[Italo Giurizzato Junior]

Boa tarde,

Sempre faça os testes usando o programa exemplo.

Fez a configuração que propus na minha postagem do dia 27/10/2020?