Protocolo NFS-e

[Dulio]

Olá equipe SAC ACBR.

Tudo bem com vocês?

Preciso de ajuda com a emissão de NFS-e usando o provedor WebISS em Palmas – TO.

Nós usamos um RPS por Lote.

Nosso código de emissão de NFS-e funciona desde a fase de homologação do servidor.

No entanto, de uns tempos para cá, aleatoriamente ocorre o seguinte erro ao Emitir NFS-e.

(figura 1: Erro ao Emitir NFS-e)

Um de nossos clientes relatou que em quase toda 1ª emissão de NFS-e do dia o erro ocorre.

Após o erro, o protocolo do RPS não é gravado no BD, mesmo que o Lote\RPS tenha sido recebido pelo servidor WebISS. Neste momento, naturalmente, o registro da NFS-e permanece com o status 1 – NÃO ENVIADO no banco de dados.

Analisando o Log implementado em meu executável, constatou-se que sempre que o referido erro ocorre, o Protocolo não é retornado\armazenado nos atributos:

·         dmNFSe.ACBrNFSe.NotasFiscais.Items[0].NFSe.Protocolo;

·         dmNFSe.ACBrNFSe.WebServices.ConsSitLoteRPS.Protocolo;

Ou seja: os atributos que armazenam o Protocolo do RPS ficam em branco.

 

Ao executar a mesma instrução de Envio novamente, aparece o erro “RPS JÁ INFORMADO”, pois estou tentando Emitir uma NFS-e com um RPS já associado a um protocolo anterior.

 

 

 

(figura 2: Rps já informado)

 

 

Nesses casos, minha equipe de suporte está sendo acionada e nós temos que procurar manualmente no site do webISS o número do protocolo associado ao RPS, para só então executar a função de Processar e atualizar o RPS.

(figura 3: Consulta Protocolo por RPS no site WebISS)

 

 

 

 

Durante os testes, foi identificado que a exceção “1 – O tempo limite da operação foi atingido” ocorre na linha 870 ao chamar a instrução dmNFSe.ACBrNFSe.Enviar( Lote );

(figura 4: método de envio de RPS da NFS-e)

 

 

O código seguinte, de concluirNfse(), simplesmente salva o protocolo e situação retornados pelo objeto acbrNfse e os grava no BD. Segue o código para fins de avaliação:

(figura 5: método concluirNFSe() )

 

 

Nós tentamos fazer algumas alterações para esse tipo de situação de contingência, mas não obtivemos sucesso. Nossa última tentativa foi disparar na exceção do método EnviarNFSe (figura 4) a instrução para recuperar o número do protocolo e o armazenar no BD em seguida.

Tentamos utilizar a instrução  dmNFSe.ACBrNFSe.ConsultarNFSeporRPS(...) para de alguma forma recuperar o Protocolo, mas não obtivemos êxito.

(figura 6: método enviarNFSe() com contingência para recuperar o protocolo)

Sempre que se forçava o delphi em debug a executar a exceção, nos era retornada a seguinte mensagem:

(figura 7: erro ConsultarNFSePorRps)

 

 

Temos algumas perguntas a fazer e gostaríamos que os senhores nos orientassem na melhor abordagem:

1_Há alguma forma de reproduzir a exceção “tempo limite a operação foi atingido” em modo de debug? Em quais situações ela costuma ocorrer?

2_Qual a instrução correta para gravar no BD o número do protocolo após o evento Enviar(Lote) ?

·         dmNFSe.ACBrNFSe.NotasFiscais.Items[0].NFSe.Protocolo;

·         dmNFSe.ACBrNFSe.WebServices.ConsSitLoteRPS.Protocolo;

 

3_Se no momento de disparar o método Enviar(Lote), ocorrer a exceção de “tempo limite da operação foi atingido”, como posso recuperar o número do protocolo na exceção logo em seguida? Qual seria a instrução para substituir a dmNFSe.ACBrNFSe.ConsultarNFSeporRPS(...) ?

4_Em um outro caso de contingência, onde a internet do emitente tenha caído, não seja possível recuperar o Protocolo de imediato e a NFS-e fique com o status 1 – Não processado no BD, como devo proceder para que o executável identifique que já houve uma tentativa de emissão desse RPS, acesse o servidor webISS, recupere o protocolo e Consulte a situação do lote ao mesmo tempo?! K

 

 

Atenciosamente,

Equipe Inorte Sistemas.

Edited August 5, 2016 by Dulio

[Italo Giurizzato Junior]

Boa noite Dulio,

Se tratando de NFS-e temos tomar o cuidado de não engessar a aplicação, pois os provedores que seguem a versão 1 do layout tem o método Consultar a Situação do Lote e não tem os Métodos Gerar, Enviar Síncrono e Substituir NFS-e.

Já os provedores que seguem a versão 2 não tem o método Consultar a Situação do Lote e tem os o  Gerar, Enviar Síncrono e Substituir NFS-e.

Conclui-se que a sua aplicação tem que estabelecer um fluxo dependendo do provedor.

Para os provedores que seguem a versão 1 o numero do protocolo só consta no retorno do envio, os demais métodos não retornam essa informação.

Já os provedores que seguem a versão 2 alem de constar no retorno do envio, pode constar também no retorno da Consulta ao Lote.

No caso dos provedores que seguem a versão 1 se ocorrer um erro após o envio, não sabemos se o lote realmente foi enviado ou não, sendo assim devemos consultar a situação do lote, caso a resposta seja Lote não recebido, ai sim o devemos enviar novamente.

O que fazer com relação a falta do numero do protocolo quando ocorrer o erro, vejo dois caminhos, pesquisar no site ou atribuir um numero padrão ( -1 ) desta forma você saberia quais as notas que ocorreram problemas no envio.

Se tratando dos provedores que seguem a versão 2 se ocorrer erro durante o envio, devemos executar o ConsultarNFSeporRPS (pois o ConsultarLoteRps necessita do numero do protocolo) se a resposta for RPS inexistente no banco de dados (do provedor), ai sim devemos enviar o lote novamente, caso contrario já vamos ter como resposta o XML da NFS-e e como dito dependendo do provedor teremos o numero do protocolo também.

Lembre-se que temos os métodos ConsultarSituacao, ConsultarLoteRps, ConsultarNFSePorRPS e ConsultarNFSe, cada um tem a sua finalidade.

Não sei se de uma forma direta ou indireta consegui responder todas as suas questões.

Espero ter ajudado.