NFS-e - Consulta NFS-e por RPS

[Antonio Gomes]

Apos efetuar a consulta, de NFS-e por RPS, retorna o erro list index is out of bounds (0)

 

Para tanto, resolvi testando a lista de notas se tem alguma carregada, pois essa consulta não tem a nota ainda criada, apenas o RPS.

Segue trecho com problema:

    // Necessário para o provedor Governa
      if TNFSeConsultarNfseRPS(Self).FNotasFiscais.Count > 0 then
      begin
        ChaveAcessoPrefeitura := TNFSeConsultarNfseRPS(Self).FNotasFiscais.Items[0].NFSe.Prestador.ChaveAcesso;
        CodVerificacaoRPS :=  TNFSeConsultarNfseRPS(Self).FNotasFiscais.Items[0].NFSe.CodigoVerificacao;
      end;

Segue código fonte alterado.

ACBrNFSeWebServices.pas

[Italo Giurizzato Junior]

Boa tarde,

Uma pergunta, a ChaveAcessoPrefeitura e CodVerificacaoRPS é opcional para esta consulta?

[Antonio Gomes]

Não sei te dizer, só sei que quando vai consultar uma nota pelo numero de RPS que não foi transmitida, não retorna nota, logo, não existe aquele vetor maior que zero.

Não for isso que está tentando entender, explique novamente.

[Italo Giurizzato Junior]

Se você utiliza o método ConsultarNFSeporRps é levantada uma exceção caso não tenha sido carregado o RPS.

Agora se você utiliza as chamadas diretas do Web Service do componente não é feita essa verificação dai o erro.

Note que no XML do RPS existe essas duas informações nas TAGs: ChvAcs e CodVer

[Antonio Gomes]

Então pelo que entendi, ao chamar essa função tenho que ter carregado o RPS? Pois não faço isso, apenas chamo essa função afim de saber se a nota foi gerada.

Eu chamo essa função antes de transmitir um RPS, pois tenho que detectar se o programa foi fechado pelo usuário, se não conseguiu desde a ultima transmissão.

[Italo Giurizzato Junior]

Bom dia,

Todos os provedores exige que seja informado o numero, serie e tipo do RPS para realizar a consulta, mas o provedor Governa exige mais essas duas informações.

Eu não vou alterar a assinatura de um procedimento ou função acrescentando novos parâmetros só por causa de um provedor.

Sendo assim a solução adotada é carregar o XML do RPS antes de realziar a consulta.

 

[Antonio Gomes]

Então porque não testou apenas o provedor governa ? Se é só pra ele? E não deixar levantar excessão para o resto? Muito mais fácil resolver 1 problema que criar vários não ? Pensa....

Ou melhor, colocar um if exclusivo para o provedor = governa...

Para piorar a coisa, gera uma nota em um provedor ai, coloca a alíquota errada, simulando um usuário com suas peripécias.

Em seguida manda a consulta por RPS para ver se gerou a nota para você.

Verá que não tem aqueles campos para preencher....

Você parece que olha sempre o melhor caso da transmissão, que sempre vai sair tudo certo, e na realidade não é bem assim.

Mesmo assim mudei no meu fonte aqui para atender aqui.

[Italo Giurizzato Junior]

Eu tive um professor que dizia: quanto mais você escreve, mas você erra.

Em uma aplicação quanto mais informações o usuário tem que digitar mais ele vai errar.

É por isso que eu procuro nas minhas aplicações parametrizar o máximo possível, ou seja, colocar em tabelas de configuração no banco de dados.

No caso da alíquota, se o usuário tem que digitar toda vez que for emitir uma nota, com certeza uma hora ele vai errar. Por outro lado se essa informação esta parametrizada, ela não precisa ser digitada evitando assim o erro.

O que você esquece é que o seu problema é pontual, onde a sua aplicação vai usar somente esse provedor ou mais algum outro.

Eu por outro lado estou escrevendo um componente que tem que satisfazer mais de 50 provedores.

Como lhe disse dos 58 provedores (para ser exato até o momento) somente o Governa exige mais essas duas informações na consulta.

Se eu for começar a colocar essas diferenças como parâmetros nos métodos vai chegar uma hora que vamos ter dezenas de parâmetros.

O componente ainda não esta 100% para todos os provedores e com a migração para o Trunk2 estou analisando todos os fontes para tentar reduzir o máximo possível de IF Provedor.

Quero um código o mais limpo possível.

[walter faria]

Boa tarde,

1-Ao Enviar o RPS o componente não esta trazendo o numero do protocolo ou como pego esta informação ?
 para enviar o RPS:

ACBrNFSe1.Enviar(CodNFS, false);
protocolo:= ACBrNFSe1.NotasFiscais.Items[0].NFSe.Protocolo;
e estaficando vazio esta variável

2-Como posso pegar os dados do protocolo, da NFSe pela consultaporRPS? 

 

***Provedor GINFES.

Obrigado

 

[Italo Giurizzato Junior]

Boa tarde Walter,

O componente possui uma propriedade de configuração chamada ConsultaLoteAposEnvio ela esta com o valor True?

[walter faria]

Citar

 

Boa tarde, Italo.
Esta sim , mesmo assim não retorno o protocolo quando consulta por RPS .

Obrigado

[Italo Giurizzato Junior]

Walter,

O numero do protocolo você só obtêm ao enviar, no consultar essa informação não é retornada.

Lembre-se que no caso da NFS-e o numero do protocolo equivale ao numero do recibo da NF-e.

No caso da NF-e o numero do recibo você só obtêm ao enviar.

[walter faria]

Mas no caso de não receber o Numero ao enviar , porque isso acontece ?

Obrigado

[Italo Giurizzato Junior]

Walter,

O método Enviar sempre retorna o numero de protocolo, se não retornar isso significa que ocorreu uma falha no retorno.

E neste caso não tem como recuperar essa informação.

É a mesma coisa da NF-e, você enviar e ocorre um erro no retorno não tem como recuperar o numero do recibo.

Lembre-se:

                Retorno do Envio

NF-e -> Recibo = Protocolo <- NFSe

[Antonio Gomes]

5 horas atrás, walter faria disse:

Mas no caso de não receber o Numero ao enviar , porque isso acontece ?

Obrigado

Ou voce pode enviar uma consulta baseado no numero do RPS, se nao voltar informacao, retransmita-a. Faço isso direto com essas internet perebentas de cliente, tem que ficar fazendo testes e mais testes se teve retorno na transmissão.

 

Outra coisa, a nota com ginfes nem sempre é instantâneo o retorno com o numero da NFS-e, ja vi ficar o dia todo sem um retorno.

[walter faria]

Em ‎05‎/‎02‎/‎2016 at 16:30, Italo Jurisato Junior disse:

Walter,

O método Enviar sempre retorna o numero de protocolo, se não retornar isso significa que ocorreu uma falha no retorno.

E neste caso não tem como recuperar essa informação.

É a mesma coisa da NF-e, você enviar e ocorre um erro no retorno não tem como recuperar o numero do recibo.

Lembre-se:

                Retorno do Envio

NF-e -> Recibo = Protocolo <- NFSe

Italo, bom dia

Como eu pego o numero do Recibo , caso o numero do protocolo seja possível pegar ( no momento do envio ) ?

Obrigado

[Italo Giurizzato Junior]

Boa noite Walter,

Na NFS-e não existe o numero do Recibo e sim o numero do Protocolo.

O numero do Protocolo você só obtêm ao ler o retorno do envio.

 

[walter faria]

Italo, bom dia.

Você tem arquivo txt de como utiliza NFSe, igual os CT-e , para alimentar o AcbrNFS com estas opções ?

Estou meio confuso de como usar AcbrNFS, quero usar de uma forma para não perder estes dados : Recibo, Protocolo .

Quero saber em que momento utilizo métodos : ConsultarSituacao, ConsultarLoteRps  

Obrigado

[Antonio Gomes]

6 horas atrás, walter faria disse:

Italo, bom dia.

Você tem arquivo txt de como utiliza NFSe, igual os CT-e , para alimentar o AcbrNFS com estas opções ?

Estou meio confuso de como usar AcbrNFS, quero usar de uma forma para não perder estes dados : Recibo, Protocolo .

Quero saber em que momento utilizo métodos : ConsultarSituacao, ConsultarLoteRps  

Obrigado

Eu uso ConsultarLoteRPs pra saber se o rps foi transmitido, ginfes tem de dar problema as vezes, timeout etc..

já o ConsultarSituacao, é quando vc sabe que seu fonte foi transmitido, ai tem os 4 numeros de retorno - ver manual. Nesses números tem a ação a tomar.

[Italo Giurizzato Junior]

Boa noite Walter,

Se tratando de NFS-e não existe numero de recibo e sim numero de protocolo, que só é obtido ao ler o conteúdo do retorno do método Enviar.

A titulo de exemplo estudo o programa exemplo do componente ACBrNFSe.