Erro ao enviar RPS, arquivo retorna vazio

[junior augusto]

Boa tarde!

Estamos com problema no envio do RPS para os provedores GINFES (cidade de SÃO JOSÉ DO RIO PRETO/SP) e PRONIMV2 (MIRASSOL/SP). Seguindo o DEMO do ACBrNFSe, segue as telas abaixo o problema encontrado.

Na imagem debug_1, mostra que o nome do arquivo está vazio.

Na imagem debug_2, mostra o erro enquanto estamos debugando o sistema.

Na imagem debug_3, mostra a mensagem de erro ao usuário final, mas mesmo com o erro, a nota foi gerada no site da GINFES, conforme mostra a imagem gerou_nfse.

Precisamos de uma orientação de como corrigir o problema.

[Italo Giurizzato Junior]

Boa tarde Augusto,

Esse erro também ocorre no programa exemplo?

Notei que as imagens se referem a sua aplicação.

[junior augusto]

sim, veja as imagens em anexo.

fiz os testes agora usando o próprio exemplo do ACBr.

nossa última atualização do componente ACBr foi em 20/02/2020. Houve alguma correção referente a emissão de notas de serviço, depois dessa data, que necessite a atualização ?

[Italo Giurizzato Junior]

Augusto,

Você configurou corretamente o programa, no que diz respeito as pastas onde devem ser salvos os XMLs?

[junior augusto]

Italo,

Segue as telas das pastas e os arquivos gerados nas mesmas. Tentei fazer a consulta de NFSe por RPS e retornou : ERRO: Campo telefone do tomador informado incorretamente. O campo telefone do tomador devera ter tamanho maximo de 11 caracteres, mas veja nas imagens que o exemplo tem apenas 8 dígitos.

[Italo Giurizzato Junior]

Bom dia Augusto,

Inclua o DDD no numero do telefone, por exemplo: 1622223333

[junior augusto]

Bom dia Italo,

Foi incluso o número do DDD, mas voltou no primeiro erro da abertura do tópico.

 

[Italo Giurizzato Junior]

Augusto,

Noto que pela sua imagem onde aparece o Total de Cidades (1140) os seus fontes estão desatualizados.

Pois o arquivo Cidades.ini já contempla 1184 cidades.

Se os fontes estão atualizados, então você não esta fazendo uma atualização completa, esta esquecendo de atualizar a pasta Exemplos.

Um arquivo INI (Cidades.ini ou <provedor>.ini) desatualizado pode gerar erros.

Notei que você fez alterações no programa exemplo, fazendo com que ele carregue um XML e o imprime.

Você não deve ter o conceito correto da NFS-e em mente.

O componente ACBrNFSe gera e envia o XML do RPS e temos como retorno o numero do protocolo que atesta que o lote de RPS foi recebido pelo webservice.

De posse do numero do protocolo mais o numero do lote devemos consultar a situação do Lote, teremos como resposta uma das seguintes situações:

1. Lote não recebido, 2. Lote em processamento, 3. Lote processado com falhas, 4. Lote processado com sucesso.

Se a situação for 3 ou 4 devemos consultar o lote, teremos como resposta a lista de rejeições caso a situação for 3 ou o XML da NFSe se for 4.

É o XML da NFS-e salvo na pasta Notas que devemos carregar para imprimir o DANFSE.

[junior augusto]

Boa noite Italo,

Agradeço sua explicação, fiz alguns testes e quando o retorno da consulta é 3 ou 4 está tranquilo, porque se for 3, dependendo do erro, reenviamos o RPS e se for 4, carregamos o arquivo de retorno e imprimimos a NFSe, mas quando é 2, qual o procedimento correto a ser feito ? Devemos aguardar algum tempo e fazer a consulta do lote, usando o método ConsultarLoteRps ? 

[Italo Giurizzato Junior]

Bom dia Augusto,

Exatamente, se a situação for 2 devemos executar o método ConsultarLoteRps.

 

[junior augusto]

Boa tarde Italo,

Desculpe a demora em responder, mas temos um outro problema. No componente a propriedade ConsultarLoteAposEnvio, nós configuramos para = TRUE e as vezes o RPS é enviado tranquilamente, mas tem vezes que ocorre o erro de Access Violation e não chega no nosso tratamento de erros, mas a nota é gerada no servidor da prefeitura. Veja as telas abaixo, o que pode ser feito para resolvermos. A primeira imagem é do erro e a segunda é do processo, onde nós temos o Envio do RPS, veja que tem um try except, mas não cai dentro dele quando dá o erro de Access Violation.

 

[junior augusto]

Italo,

Melhorando a explicação acima, segue a sequencia dos arquivos XML gerados pelo processo.

No arquivo 02_04_etapa_5.png, mostra a mensagem que o RPS não está na base de dados, mas foi gerada sim, tanto que depois fizemos a consulta e a nota estava lá.

 

[Italo Giurizzato Junior]

Boa tarde Augusto,

Quanto a violação de acesso é preciso descobrir se esta ocorrendo no componente ou na sua aplicação.

Pelo que entendi não é sempre que ocorre, ai fica difícil de descobrir.

O Ginfes é meio problemático, quando não é uma coisa é outra com problema.

Será que a violação de acesso não esta ocorrendo logo nas 3 primeiras linhas do seu except?

Tem (..).Items[0].(...), não seria interessante checar se essa lista realmente possui itens? 

[junior augusto]

Certo, vc disse bem, o erro é intermitente, mas no caso da sua sugestão, como poderíamos checar se a lista tem itens ? e caso não tenha, o que poderíamos fazer, uma vez que a nota já foi gravada no site da prefeitura ?

[Italo Giurizzato Junior]

Augusto,

Notei agora que se a cidade não for Mirassol é executado o método Enviar caso contrario é o Gerar.

Esse tipo de abordagem para mim esta errada.

O seu maior problema é o seguinte, nas linhas que contem o Items[0] você faz referencia a classe GerarNFSe que tem haver com o Gerar e não com o Enviar.

Esta ai o seu erro.

Quando ocorre um erro não necessariamente no envio do lote, mas sim não consulta por exemplo ele cai ai e vai checar o retorno, mas esse retorno que esta sendo checado é do Gerar e não do Enviar.

Logo na lista de retorno do GerarNFSe não existe nenhum item.

Você deve separar as coisas.

Você deve ter um tratamento para o Enviar e outro para o Gerar.

[junior augusto]

Boa noite Italo,

Muito obrigado pelos esclarecimentos.

Vou fazer as alterações e tratamentos conforme sua orientação e tão logo tenha os resultados, retorno com mais informações.