NFSe Ribeirão Preto com ISSNet

[andre@prodez]

Boa noite pessoal. Já deixo aqui meus agradecimentos a quem puder me ajudar.

Estou tendo dificuldades com a emissão da NFS-e para o novo provedor em Ribeirão Preto - o ISSNet. Não sei se todos já conseguiram fazer seus sistemas funcionarem nesse novo provedor. Eu ainda não, infelizmente. No GINFES sempre trabalhei enviando o RPS e aguardo o retorno do XML aprovado da nota, esse processo sempre se resolveu em alguns segundos. No ISSNet isso não está ocorrendo, demora cerca de 30 minutos e acaba retornando um erro de nota não processada.

Por email, tive um retorno do suporte da Nota Control informando para informar os links de acesso aos Web Services utilizando "https://..."; verifiquei que no aquivo ISSNet.ini todas as urls são informadas apenas com "http://..."; alguém precisou corrigir isso no arquivo ini desse provedor?

Será que esse método que uso hj de enviar o RPS e ficar consultando (no mesmo instante) o retorno da nota aprovada não irá funcionar com o ISSNet? Vcs estão trabalhando de forma diferente em seus sistema?

Abaixo vou mostrar um esqueleto de como implemento o envio da NFS-e, por favor, se puderem orientar uma forma mais correta que funcione com o ISSNet eu agradeceria muito, pois usava dessa forma com o GINFES e nunca tive problemas (isso já a muito tempo):

  //carrega as configuracoes para o Componente
  ConfigurarNFSe;

  //carrega os dados da NFS-e para o Componente
  CarregarNFSe;

  //envia o RPS para o provedor
  acbrNFSe.Enviar(QryNotasSe.FieldByName('NumRPS').AsInteger, false);

  //armazena as informacoes retornadas apos envio do RPS e autorizacao da NFS-e
  if acbrNFSe.NotasFiscais.Items[0].NFSe.Numero <> '' then begin
    QryNotasSe.FieldByName('NumNF').AsString := acbrNFSe.NotasFiscais.Items[0].NFSe.Numero;
  end;
  QryNotasSe.FieldByName('CodVerificacao').AsString := acbrNFSe.NotasFiscais.Items[0].NFSe.CodigoVerificacao;
  QryNotasSe.FieldByName('NrProtocolo').AsString := acbrNFSe.WebServices.EnviarLoteRPS.Protocolo; 
  QryNotasSe.FieldByName('NomeArq').AsString := acbrNFSe.NotasFiscais.Items[0].NomeArq;

  //grava a NFS-e
  QryNotasSe.Post;
 

Estou tb anexando um txt com as configurações que utilizo no componente "ACBrNFSe".

Por favor, agradeço desde já quem puder apontar o que estou fazendo de errado e me indicar um norte para conseguir emitir NFS-e com esse provedor ISSNet.

Obrigado. André Luis.

ConfigurarNFSe.txt

[Juliomar Marchetti]

chegou a ler

 

[andre@prodez]

10 horas atrás, Juliomar Marchetti disse:

chegou a ler

 

Bom dia Juliomar, obrigado pelo retorno.

Sim olhei os tópicos. Dei uma boa pesquisada no forum; eu já utilizo os componente ACBrNFSe para emissão da nota, fiz a implementação já faz um bom tempo, na época segui os fontes de exemplo; sempre funcionou certinho com o GINFES; mas com o ISSNet me parece que o tempo de resposta deles é muito lento e talvez a forma como estou trabalhando não seja adequada. Por isso estou pedindo ajuda para alguém que já esteja conseguindo emitir a NFS-e de Ribeirão Preto com o ISSNet, postei acima o esqueleto de como implementei (incluindo um txt com o fonte de como configuro o componente); pra ver se alguém me dar um norte de qual é a forma correta de trabalhar com esse provedor.

Por favor, se alguém puder me ajudar agradeço muito... Obrigado.

André Luis.

[Juliomar Marchetti]

Creio que ninguém esteja pois como mesmo viu nos tópicos está sendo bem discutindo o problema em si e tentando chegar a alguma solução para ajudar a todos

 

[andre@prodez]

Bom dia pessoal.

Alguém já conseguindo emitir NFs-e para Ribeirão Preto com ISSNet de uma forma que funcione?

Obrigado!!!

[andre@prodez]

Boa tarde pessoal. Estou caminhando aqui...

Passei a Enviar o lote sem fazer a consulta logo após o envio...

Para consultar o lote posteriormente estou usando a função:  ConsultarLoteRps

Alguém saberia me dizer como faço para identificar (usando essa função) se um determinado lote ainda não foi processado?

Percebi que essa função gera uma exceção qdo a NFs-e contem algum erro, mas qdo o lote ainda não tiver sido processada pelo provedor, ela tb irá gerar exceção ou algum código de erro?

A questão seria: tem como diferenciar um "erro na emissão da NFS-e" de um "retorno de lote ainda não processado"?

Ou sempre irá gerar uma exceção nos dois casos (não processada / erro) e ficaria a cargo do usuário interpretar a situação através da descrição da mensagem de retorno, seria isso?

Por favor, aguardo alguma orientação. Obrigado desde já.

André Luis.

Editado 15 Agosto, 2020 por andre@prodez

[andre@prodez]

22 minutos atrás, andre@prodez disse:

Boa tarde pessoal. Estou caminhando aqui...

Passei a Enviar o lote sem fazer a consulta logo após o envio...

Para consultar o lote posteriormente estou usando a função:  ConsultarLoteRps

Alguém saberia me dizer como faço para identificar (usando essa função) se um determinado lote ainda não foi processado?

Percebi que essa função gera uma exceção qdo a NFs-e contem algum erro, mas qdo o lote ainda não tiver sido processada pelo provedor, ela tb irá gerar exceção ou algum código de erro?

A questão seria: tem como diferenciar um "erro na emissão da NFS-e" de um "retorno de lote ainda não processado"?

Ou sempre irá gerar uma exceção nos dois casos (não processada / erro) e ficaria a cargo do usuário interpretar a situação através da descrição da mensagem de retorno, seria isso?

Por favor, aguardo alguma orientação. Obrigado desde já.

André Luis.

 

Essa informação seria a propriedade : ACBrNFSe.WebServices.ConsLote.LoteNaoProc  ?

Alguém pode confirmar isso?

[Italo Giurizzato Junior]

Bom dia André,

Tanto o provedor Ginfes quando o ISSNet seguem a versão 1 do layout da ABRASF, logo porque você não usa o método ConsultarSituacao logo após o envio?

O Consultar Situação vai retornar os seguintes valores:

1- Logo não enviado;

2- Lote em Processamento;

3- Lote processado com falha ;

4- Lote processado com sucesso.

Se o valor do campo Situacao for 3 ou 4 devemos executar o método ConsultarLoteRps, teremos como resposta a lista de rejeições caso a situação seja 3 ou a lista de notas caso a situação for 4

[andre@prodez]

Bom dia Italo. Obrigado pelo retorno.

Para fazer funcionar com o ISSNet passei a usar o componente com a propriedade ConsultaLoteAposEnvio como false; devido ao retorno desse provedor ser muito lento; dai passei a fazer apenas o envio do RPS num primeiro momento.

Após isso, libero o usuário pra consultar os RPSs enviados, e faço isso usando direto a função ConsultarLoteRps; - teria algum problema?

Nesse caso após executar essa função, pra eu saber se o lote foi processado (independente se com erro ou autorizado) eu posso verificar a propriedade ACBrNFSe.WebServices.ConsLote.LoteNaoProc ?

Vi tb que tem a propriedade "Situação" em WebServicess.ConsLote; ou seja o ConsultarLoteRps atualiza essas informações no componente... pois ai nem precisaria passar primeiro pelo ConsultarSituacao...

Obrigado!!!

André Luis.

[andre@prodez]

Italo, na verdade, minha preocupação é para seguinte situação:

- enviei o RPS para o provedor;

- depois de um tempo fiz a consulta ao RPS (usando ConsultarLoteRps por ex.)

- caso o lote desse RPS ainda esteja na fila no provedor, ele ainda não foi processado, qual retorno o componente da após executar essa consulta: gera uma exceção (erro); ou faz a consulta sem gerar erro e atualiza as informações de lote não processado.

Essa é a minha principal dúvida nisso. Obrigado!!!

André Luis.

 

[Italo Giurizzato Junior]

Boa tarde André,

Você até pode deixar a propriedade ConsultaLoteAposEnvio com o valor True.

Se o problema é lentidão, você pode configurar as propriedades:

AguardarConsultaRet: se informar por exemplo 5000 o componente vai esperar 5 segundos antes de executar automaticamente o ConsultarSituacao;

IntervaloTentativas: se informar por exemplo 3000 o componente vai esperar 3 segundos entre uma tentativa e outra;

Tentativas: se informar por exemplo 10 o componente vai executar a consulta 10 vezes;

TimeOut: se informar por exemplo 50000 o componente vai aguardar o webservice por 50 segundos antes de gerar uma mensagem de erro.

Como você pode ver, as vezes podemos resolver esses problemas de tempo de resposta alterando algumas propriedades de configuração do componente.

[andre@prodez]

Boa tarde Italo.

O problema estava meio absurdo mesmo, não sei se por conta do início das operações semana passada (troca do GINFES pelo ISSNet), mas eu estava com as seguintes configurações nessas propriedades:

AguardarConsultaRet: 2000

IntervaloTentativas: 3000

Tentativas: 600; (isso mesmo, 600, o que leva a ficar por 30 minutos tentando, e depois de todo esse tempo retornava um "erro desconhecido" - e o problema era não ter a resposta, pois em testes durante a madrugada funcionava)

TimeOut: 60000

Por isso acabei acreditando que a única solução nesse caso seria apenas enviar os RPSs pra depois ir consultando os retornos e gerando a NFS-e... realmente não sei se teria alguma outra saída pra isso.

Mas ai surgiu apenas aquela questão que citei acima, sobre o lote estar na fila e qual seria o retorno da consulta nesses casos.

De qq forma, muito obrigado pelos retornos.

André Luis.

[Italo Giurizzato Junior]

Bom dia André,

Me diz uma coisa, ao enviar o Lote o provedor retorna o numero do protocolo?

[andre@prodez]

10 horas atrás, Italo Jurisato Junior disse:

Bom dia André,

Me diz uma coisa, ao enviar o Lote o provedor retorna o numero do protocolo?

Boa noite Italo, desculpe a demora em retornar...

Sim, ao enviar o lote o provedor retorna o protocolo. Estou conseguindo consultar posteriormente o lote usando o RPS e esse número de protocolo.

O que está ocorrendo é que nos casos que ao enviar o lote ele permanece um certo tempo na fila sem processamento, caso nesse meio tempo eu faça uma consulta ao lote, o componente acaba gerando uma exceção indicando como lote processado com erro, veja o erro abaixo retornado pelo provedor (mensagem retornada na exception do ConsultarLoteRps):

Na realidade o lote ainda não foi processado e em consultas futuras ele poderá gerar a NFs-e normalmente. Portanto, nessas situações tenho tido dificuldade de diferenciar, após uma consulta, um lote ainda não processado de um de fato processado com erro, pois nas duas situações está gerando uma exceção de erro.

O ideal seria a consulta entender isso como lote não processado, mas talvez a forma como o provedor reporta não é possível identificar. Não sei se alguém conseguiu tratar essa situação. Me ocorreu a ideia de tratar de forma manual, testando realmente a string da mensagem procurando pelo texto "Nota nao processada" e, nesses casos, não indicar o RPS como processado com erro, mantendo ele ainda pendente de processamento. Não sei se to falando bobeira...rs.

André Luis.

[Italo Giurizzato Junior]

Bom dia André,

Em vez de consultar o lote, porque você não consulta a situação do lote?

 

[andre@prodez]

Em 19/08/2020 at 09:48, Italo Jurisato Junior disse:

Bom dia André,

Em vez de consultar o lote, porque você não consulta a situação do lote?

 

Boa noite Italo.

O que ocorreria caso eu executasse a Consulta a Situação do Lote em um provedor que não esteja na versão 1 do layout da ABRASF (esteja na versão 2 por ex.)?

Como eu identifico em qual versão determinado provedor está?

Obs.: no mesmo sistema eu tb trabalho com o provedor SimplISS.

 

Obrigado,

André Luis.

 

[Italo Giurizzato Junior]

Bom dia André,

Na unit pnfsConversao temos a função ProvedorToVersaoNFSe, você informa o provedor (enumerador) e ela retorna a versão do provedor, veja:

function ProvedorToVersaoNFSe(const AProvedor: TnfseProvedor): TVersaoNFSe;
begin
  case AProvedor of
    proABRASFv2, pro4R, proABase, proActconv2, proAgiliv2, proBethav2, proCoplan,
    proDigifred, proeReceita, proFIntelISS, proFiorilli, proGoiania,
    proGovDigital, proISSDigital, proISSe, proLink3, proMitra, proNEAInformatica,
    proNotaInteligente, proProdata, proPronimv2, proPVH, proSaatri, proSiam,
    proSisPMJP, proSystemPro, proTecnos, proVirtual, proVitoria,
    proVersaTecnologia, proSafeWeb, proWebISSv2,
    proSH3, proSiapNet, proISSJoinville, proSmarAPDv2,
    proAsten, proELv2, proTiplanv2, proGiss, proDeISS, proTcheInfov2, proSigep,
    proDataSmart, proDesenvolve, proCenti, proRLZ, proSigCorp, proGiap,
    proiiBrasilv2, proSimplISSv2, proMegaSoft, proModernizacaoPublica, proElotech,
    proFuturize: Result := ve200;

    proInfiscv11, proLencois: Result := ve110;
  else
    Result := ve100;
  end;
end;

No "case" da função acima o provedor que não constar na lista iniciada por proABRASFv2 e que não for o Infisc e lencois acaba caido no "else", logo a versão 1.

 

Temos também a função ProvedorToLayoutXML que retorna o layout do XML, veja:

function ProvedorToLayoutXML(const AProvedor: TnfseProvedor): TLayoutXML;
begin
  case AProvedor of
    proABRASFv1, proAbaco, proActcon, proBetha, ProBHISS, proCIGA, proDBSeller,
    proDSFSJC, proFISSLex, progeNFe, proGinfes, proGovBR, proISSCuritiba,
    proISSFortaleza, proISSIntel, proISSNet, proLexsom, proMetropolisWeb,
    proNatal, proNFSeBrasil, proPronim, proPublica, proRecife, proRJ, proSalvador,
    proSilTecnologia, proSimplISS, proSJP, proSpeedGov, proThema, proTinus,
    proTiplan, proWebISS: Result := loABRASFv1;

    proABRASFv2, pro4R, proABase, proActconv2, proAsten, proBethav2, proCenti,
    proCoplan, proDataSmart, proDeISS, proDesenvolve, proDigifred, proELv2,
    proElotech, proeReceita, proFIntelISS, proFiorilli, proFuturize, proGiss,
    proGoiania, proGovDigital, proiiBrasilv2, proISSDigital, proISSe,
    proISSJoinville, proLink3, proMegaSoft, proMitra, proModernizacaoPublica,
    proNEAInformatica, proNotaInteligente, proProdata, proPronimv2, proPVH,
    proRLZ, proSaatri, proSafeWeb, proSH3, proSiam, proSiapNet, proSigCorp,
    proSigep, proSimplISSv2, proSisPMJP, proSmarAPDv2, proSystemPro,
    proTcheInfov2, proTecnos, proTiplanv2, proVersaTecnologia, proVirtual,
    proVitoria, proWebISSv2: Result := loABRASFv2;

    proAgili,
    proAgiliv2:     Result := loAgili;
    proEgoverneISS: Result := loEGoverneISS;
    proEL:          Result := loEL;
    proEquiplano:   Result := loEquiplano;
    proGoverna:     Result := loGoverna;
    proInfisc,
    proInfiscv11:   Result := loInfisc;
    proISSDSF,
    proCTA:         Result := loISSDSF;
    proSiat:        Result := loSiat;
    proSP:          Result := loSP;
    proCONAM:       Result := loCONAM;
    proSmarAPD:     Result := loSmarAPD;
    proIPM:         Result := loIPM;
    proGiap:        Result := loGiap;
    proAssessorPublico: Result := loAssessorPublico;
    proSigISS:      Result := loSigISS;
    proWebFisco:    Result := loWebFisco;
    proLencois:     Result := loLencois;
  else
    Result := loNone;
  end;
end;

Através desta função você sabe se o provedor segue o layout da ABRASF versão 1 ou 2 ou se tem um layout próprio.

[JessicaForti]

http://www.ribeiraopreto.sp.gov.br/JW34/noticia/5299
Acreditamos que seja instabilidade com a ISSNET, alguns sistemas estão com o mesmo problema.
Alguém de vocês conseguiram solucionar?

[Jussara]

Hoje está apresentando esse erro, alguém mais está com esse problema? 

[julioqualy]

Em 03/09/2020 at 15:55, Jussara disse:

Hoje está apresentando esse erro, alguém mais está com esse problema? 

Jussara boa tarde,

 

Estamos tendo vários problemas até hoje com a emissão via ISSNet.

Lentidão no processamento dos lotes é o mais frequente, tivemos casos de liberar só no dia seguinte um lote enviado as 14hs, é totalmente inviável esta situação.

Tenho clientes reclamando diariamente. Entramos em contato diversas vezes e a resposta é sempre a mesma, que estão na fila de processamento e que temos que aguardar.

Hoje mesmo, no meio do dia, depois de várias notas já emitidas o provedor me informa que a serie da nota é inválida, sendo que são idênticas as já emitidas, complicado!

Infelizmente este provedor não esta dando conta do volume de notas da cidade de Ribeirão Preto, e tínhamos a esperança que passado o primeiro mês isso que resolveria, só que esta piorando a situação.

A título de informação, temos sistemas em Delphi que utilizam Acbr e em C# de autoria da empresa, nos dois casos temos os mesmos problemas.

 

Desculpem pessoal é mais um relato do estamos enfrentando em Ribeirão Preto com este novo provedor.

 

Att,

Júlio Ferdinando

[Italo Giurizzato Junior]

Boa tarde a todos,

Não adianta nós desenvolvedores reclamar com o provedor.

Temos que pedir para os nossos clientes abrir um protocolo na prefeitura relatando todos os problemas.

E esperar que a prefeitura tome alguma providencia. 

[balrog]

17 horas atrás, julioqualy disse:

Jussara boa tarde,

 

Estamos tendo vários problemas até hoje com a emissão via ISSNet.

Lentidão no processamento dos lotes é o mais frequente, tivemos casos de liberar só no dia seguinte um lote enviado as 14hs, é totalmente inviável esta situação.

Tenho clientes reclamando diariamente. Entramos em contato diversas vezes e a resposta é sempre a mesma, que estão na fila de processamento e que temos que aguardar.

Hoje mesmo, no meio do dia, depois de várias notas já emitidas o provedor me informa que a serie da nota é inválida, sendo que são idênticas as já emitidas, complicado!

Infelizmente este provedor não esta dando conta do volume de notas da cidade de Ribeirão Preto, e tínhamos a esperança que passado o primeiro mês isso que resolveria, só que esta piorando a situação.

A título de informação, temos sistemas em Delphi que utilizam Acbr e em C# de autoria da empresa, nos dois casos temos os mesmos problemas.

 

Desculpem pessoal é mais um relato do estamos enfrentando em Ribeirão Preto com este novo provedor.

 

Att,

Júlio Ferdinando

Realmente o pior serviço que já implementei, como explicar para um usuário que antes no GINFES era rápido e agora é lento, mas está tudo normal....?? é só esperar um dia!

O suporte e a prefeitura, não estão muito interessados em resolver isso.

Sobre o HTTP 500, tive esse problema quando segui as instruções do suporte...de alterar os namespaces do XML e cabeçalho para HTTPS...bizarro....não altere!

[julioqualy]

Italo boa tarde,

Entendo, e já esta sendo feito por nosso clientes, praticamente todos os dias eles entram em contato tanto com a Prefeitura como o provedor.

Mas somos sempre a linha de frente, o primeiro contato, então sempre acaba sobrando.

Mas vamos em frente.

 

Abs,

[cefantacini]

Eu tbem tenho cliente de nfse em Ribeirão Preto e Estou passando pelo mesmo problema, eu ate consegui emitir nota em homologação com o issnet depois da troca do ginfes, porem, ainda nenhuma em produção.  Sempre recebo a msg de nota não processada e erro desconhecido. Já enviei inúmeros e-mails para o suporte e nada. São varios dias para dar uma resposta e quando vem a resposta não esclarece nada. O cliente comprou o plano com suporte, ou seja, está pagando pra isso. É uma escola que emite mais de 500 notas por mês e já está indo para o segundo mês sem conseguir emitir nota pelo sistema. Está emitindo pelo site, porém é muito mais demorado....

[julioqualy]

1 hora atrás, cefantacini disse:

Eu tbem tenho cliente de nfse em Ribeirão Preto e Estou passando pelo mesmo problema, eu ate consegui emitir nota em homologação com o issnet depois da troca do ginfes, porem, ainda nenhuma em produção.  Sempre recebo a msg de nota não processada e erro desconhecido. Já enviei inúmeros e-mails para o suporte e nada. São varios dias para dar uma resposta e quando vem a resposta não esclarece nada. O cliente comprou o plano com suporte, ou seja, está pagando pra isso. É uma escola que emite mais de 500 notas por mês e já está indo para o segundo mês sem conseguir emitir nota pelo sistema. Está emitindo pelo site, porém é muito mais demorado....

Boa tarde,

Não apresenta  nenhum erro no processamento ?

Você recebe pelo menos o protocolo do lote?

Tivemos problemas semelhantes, recebíamos a confirmação do protocolo, no entanto, quando vamos consultar o lote ele informava que não existia. Para este caso é preciso entrar no sistema deles e solicitar uma quantidade de RPS, somente depois de liberado esta quantidade que eles vão processar o lote.

Posso te passar os detalhes de como solicitar caso seja este o problema.

Att,